Contents


Secure and protect Cassandra databases with IBM Security Guardium

Improve security and compliance for open source databases

Comments

The proliferation and increased use of NoSQL and big data systems aligns perfectly with the increased monetization of stolen data and the resulting increase in data breaches, creating a perfect storm of cybercriminal opportunity. Although breaches on NoSQL systems are relatively rare when compared to relational systems, we expect these incidents to rise as more valuable data is stored in these new systems.

For readers who are already familiar with Guardium, having an overview of the architecture and where to install S-TAPs® will likely be enough to get you started. If you are new to Guardium, this article can help you get started, but it cannot supplant the need for at least some basic understanding of Guardium adminstration and configuration.

Overview of Cassandra and DataStax

Apache Cassandra is in the class of NoSQL database systems; specifically, it is a column-based store. Its architecture is different from other NoSQL systems because it does not rely on either a master-slave (like HBase) or sharded architecture (such as MongoDB). It instead has a “ring” architecture, in which each node in the system communicates with all other nodes. The architecture is designed to facilitate performance, scaleout, and continuous availability. An understanding of the basic architecture is helpful for understanding how to deploy Guardium monitoring agents.

DataStax is the company that delivers support and additional enterprise features for Cassandra, such as enhanced security and search.

The Related topics section of this article includes some helpful references on Cassandra basics and the differences between Apache Cassandra and the DataStax distribution.

Although the underlying storage model is column based, Cassandra has its own query language, Cassandra Query Language (CQL), that is used to access data. You can use the query language commands through one of three options: shell (cqlsh), a graphical tool called DevCenter, or a variety of program drivers.

Note: A Thrift API is still supported as well for legacy applications. Guardium supports the monitoring of access through the legacy API as well.

Table 1 is a mapping between Cassandra constructs and relational constructs. Example commands are courtesy of the Cassandra Query Language Reference.

Table 1. Mapping between relational database and Cassandra concepts
Relational ConceptCassandra CQL CommandsCQL Examples
DatabaseKeyspaceCREATE KEYSPACE
ALTER KEYSPACE
CREATE KEYSPACE Excelsior WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 3 };
Table and materialized viewColumn FamilyCREATE TABLE
CREATE KEYSPACE
CREATE TABLE emp ( empID int, deptID int, first_name varchar, last_name varchar, PRIMARY KEY (empID, deptID));
CREATE MATERIALIZED VIEW cyclist_by_age AS SELECT age, birthday, name, country FROM cyclist_mv WHERE age IS NOT NULL AND cid IS NOT NULL PRIMARY KEY (age, cid);
IndexIndexCREATE INDEXCREATE INDEX user_state ON myschema.users (state);
ColumnColumn (which can also be a collections of items)INSERT INTO emp (empID, deptID, first_name, last_name) VALUES (104, 15, 'jane', 'smith');

Security in Cassandra

Cassandra evolves its authentication and authorization model as it matures. Because the NoSQL space is young and still evolving, security mechanisms are evolving rapidly to keep up. For this reason, it is important that you research the latest documentation for both Cassandra and DataStax Enterprise to get the most current information.

Roles and permissions

You can set up users internally in Cassandra (e.g., CREATE USER, ALTER USER, and so on.) and as of 2.2, you can even use role-based access controls such as CREATE ROLE, ALTER ROLE, and so on.

Permission management to objects (data) is handled by using familiar GRANT and REVOKE statements. By default, authentication is disabled in Cassandra. You can set up password authentication. DataStax Enterprise supports authentication via Kerberos and LDAP.

Encryption: DataStax Enterprise includes support for transparent data encryption of data as it is written to disk, but it requires a secure local file system. In addition, if you require the commit logs to be encrypted, you will need a file system encryption capability such as that delivered by IBM Security Guardium Data Encryption.

Auditing: This is an area where Guardium provides significant added value. Although Cassandra has a general logging facility (which can be used for troubleshooting and point-in-time recovery) it would require a significant amount of work for an organization to create timely audit reports. And as stated in the product documentation, "increasing logging levels can generate heavy logging output on a moderately trafficked cluster."

DataStax Enterprise provides an audit logging facility, which must be enabled on all nodes to capture all desired events. Log events can be written to the file system (which can quickly grow quite large and be difficult to analyze) or to Cassandra tables.

As we will discuss in the next section, Guardium can improve audit reporting and dissemination and also the ability to conduct real-time alerting and near real-time analytics.

How Guardium facilitates compliance and protects Cassandra databases

If you are unfamiliar with Guardium, this section offers a quick review of how Guardium works, and the value it brings to complement or replace native database security auditing controls. For the purpose of this article, we’ll focus on Guardium Activity Monitoring. Capabilities such as database discovery, data classification, and vulnerability assessment are not currently available in Guardium for Cassandra at this time.

How Guardium activity monitoring works

As shown in Figure 1, Guardium continuously monitors data activity by using lightweight software probes, called S-TAPs, without relying on logs. The S-TAPs also do not require any configuration changes to the Cassandra servers or applications. The other major component in the Guardium architecture is the collector, which is tamper-resistant hardware, software, or virtual appliance. This architecture is optimized for speed and facilitates separation of duties.

Figure 1. Guardium architecture
staps on each cassandra node feed to a collector with security policy
staps on each cassandra node feed to a collector with security policy

To keep the processor usage on the database servers very low, the S-TAPS immediately intercept messages at the OS level and forward data activity to the collector. Depending on how much activity you decide to audit, the processor usage on the cluster should be no more than 2-4 percent.

The analysis engine on the collector (known as the sniffer) parses the data and will fire alerts for policy violations as defined by the policy rules. Real-time alerts provide near instant visibility into suspicious or anomalous events. These alerts are visible on the Guardium user interface and can be sent via email and/or integrated immediately with your security intelligence and event management system, such as IBM QRadar®, Splunk, or other similar systems.

Audited data events are stored in the collector's tamper-resistant repository, which is inaccessible other than by the Guardium interfaces and cannot be deleted.

Value of Guardium for Cassandra

As we discussed, Guardium integrates with the OS kernel to provide in-depth, granular visibility into data access. Depending on who, what, where, when, and how that access is occurring, security policies can perform a number of actions; some examples of these actions are logging the event into its protected database, sending a real-time alert to a security information and event management (SIEM) service or software, blocking access, and even redacting result set data. In addition, this same platform and security policy can be used with any of your other enterprise databases, including relational databases and other NoSQL systems such as MongoDB.

These capabilities provide significant added value of reliance on native auditing, including:

  • Separation of duties: For security and compliance, it's an accepted best practice not to enable privileged users, such as DBAs, to also be in control of security; in addition, it’s critical to monitor everything that they do on any system that includes sensitive data. The information security team can administer Guardium regardless of whether audit logging is enabled on the database server or not.
  • Speed of detection and integration with security operations: Real-time alerts can be specified for a wide variety of conditions, and you will learn how to specify those here. When breaches occur, being able to detect and react quickly can mean the difference between a hugely damaging loss and a minor inconvenience.

    You can send alerts by using email or through SNMP to another monitor system. Built-in integration with IBM QRadar and HP ArcSight message types can also be used to automatically forward alert conditions from syslog to those systems. You can customize alert messages to be sent to other systems as well, such as Splunk.

  • Speed of compliance reporting: Demonstrating compliance can be time consuming and burdensome as these often require some level of regular review and sign-off. Guardium not only lets you create the reports that you need to satisfy audit requirements, it also has a robust workflow capability that integrates into your business processes and saves all sign-offs and reviews as part of the audit trail. You'll read more about this later in the article.

    Guardium includes hundreds of prebuilt reports, including reports that are designed to jump-start compliance reporting for SOX, HIPAA, PCI-DSS, and Data Privacy. See Related topics for a link to a developerWorks article on using accelerators.

    Figure 2. Compliance accelerators
    Menu item Accelerators that includes PCI, Basel II, Data Privacy and Sarbanes-Oxley
  • Speed of ad hoc analysis: Guardium includes speedy text search and browse capability for database activities, errors, and violations. You can use common search techniques, including faceted browse and text search, together or in combination to quickly do ad hoc investigations of audit data. The following example in Figure 3 shows how easy it is to find out who recently issued a DROP TABLE command by browsing to the DROP TABLE in the verb facet and clicking it to filter the search results to all DROP TABLE events.
    Figure 3. Using Quick Search to investigate activities
    click on command in facet and then see filtered                                 results
    click on command in facet and then see filtered results

    In addition to search, there are other analytics and visualization techniques to help with detection and analysis including:

    • Threshold alerts, which can detect when events occur over time, such as an excessive number of downloaded records by a particular user over time.
    • Outlier detection, which does sophisticated cluster analysis of user activity to help you find abnormal activity that might otherwise go undetected.
    • Investigation and threat dashboards to help analysts understand activity and detect abnormal activity more quickly.
  • Support of secure archiving: Audit information must be stored for a defined period of time, sometimes years. Guardium is designed with these kinds of requirements in mind and provides secure archiving capabilities for this very reason.
  • Data protection: Guardium can block user access by cutting the network connection to the database. You can also use dynamic data redaction to obfuscate private data in results sets when they are obtained via a "backdoor" access by using privileged IDs.

Planning your deployment

This article focuses on the basics of installing and configuring a single collector system for capturing Cassandra activity. For enterprise deployments, you will need to consider how many collectors you will need to handle the expected load and you will need to use either distributed reporting or aggregator appliances to conduct reporting on the collected traffic that might be dispersed across multiple collectors.

The Related topics section of this article includes a link to a redbook on Guardium deployment. If you are new to Guardium, we highly recommend that you use experienced Guardium services or Business Partners to help you with initial deployment and to help you develop your initial security policy.

Installation and configuration

Before you begin, gather the following information:

  • Make sure that the necessary ports are open to ensure proper flow of traffic between the Guardium collector and the Cassandra nodes, Guardium installation manager client and server, and so on. The Related topics section includes a link to a technote that lists ports used by Guardium.
  • From IBM FixCentral, download the latest S-TAP for your OS and check the kernel compatibility matrix to ensure that the K-TAP (kernel tap) matches your OS kernel level, or that it works by using flex loading.

    The kernel compatibility matrix is on FixCentral. Look for the K-TAP Bundle section of Guardium download and click on the KTAP_List_of_Modules_<version> link as shown in Figure 4.

    Figure 4. Accessing the K-TAP - kernel compatibility matrix
    described above, showing the link ktap_list_ofModules_V10 lin specifically
    described above, showing the link ktap_list_ofModules_V10 lin specifically

    For more information on flex loading, see the technote in Related topics.

  • Record the ports used by Cassandra for both Thrift and CQL. The default is 9160 for Thrift and 9042 for CQL, but it's conceivable that the DBAs changed the defaults for improved security.
  • Record the IP addresses or host names of the Cassandra nodes.
  • Record the IP address or host name of the Guardium collector that will be logging real-time traffic.
  • Make sure that the Guardium collector is installed with the default collection profile policy (see the following screen capture in Figure 5) before traffic starts flowing to the collector.

    This policy records each instance of a unique connection, consisting of a five-part tuple consisting of the client IP, source application, database user, server IP, and service name–this is to avoid flooding the collector with traffic.

    Note: Cassandra does not use service names, so this value is hardcoded in Guardium.

    Figure 5. Accessing the default policy
    Go to Protect , Policy  Finder and select Default - Ignore Data Activity for Unknown Connections
    Go to Protect , Policy Finder and select Default - Ignore Data Activity for Unknown Connections

Install the S-TAPs

Because data can be accessed by using any node in Cassandra, you must install S-TAPs on all nodes. Using the Guardium Installation Manager is the recommended way to install S-TAPs, but you can use the shell installer as well.

Configure the inspection engines

When your S-TAP successfully installs and displays as green in the S-TAP control panel, you can then tell Guardium specifically what kind of traffic to listen for by configuring Guardium inspection engines with the correct Cassandra ports for your environment.

In our case, we want Guardium to listen for both Thrift messages (default port 9160) and Cassandra query language traffic (default port 9042). You can do this by configuring inspection engines from the appliance, either by using the UI or the Guardium API commands from the command line interface.

To go through the UI, navigate to Manage>Activity Monitoring>S-TAP Control, and click the blue pencil icon for the appropriate S-TAP host. Expand Add Inspection Engine. Figure 6 shows what it looks like for one S-TAP host.

Figure 6. Configured inspection engines for Cassandra
Shows completed engines for CQL and Thrift.
Shows completed engines for CQL and Thrift.

An alternative is to log in to the Guardium appliance with one of the CLI user IDs and run the Guardium API create_stap_inspection_engine, as shown in Listing 1.

Listing 1. Use Guardium APIs to create inspection engines
grdapi create_stap_inspection_engine client=0.0.0.0/0.0.0.0 protocol=Cassandra ktapDbPort=9160 portMax=9160 
portMin=9160 stapHost <ip of Cassandra server where associated STAP is installed>

grdapi create_stap_inspection_engine client=0.0.0.0/0.0.0.0 protocol=Cassandra ktapDbPort=9042 portMax=9042 
portMin=9042 stapHost <ip of Cassandra server where associated STAP is installed>

Sample security policy

The following screen capture in Figure 7 shows the security policy summary that we'll use to illustrate how to achieve certain goals, such as masking sensitive data on returned data.

Figure 7. Sample policy used for this article
shows 7 rules. all are discussed below..
shows 7 rules. all are discussed below..

Important: Do not use this policy "as is." It is best to start with basic monitoring before you add advanced capabilities such as blocking and redaction. Blocking, in particular, can impact performance and the implementation must be done with care.

As mentioned previously, we recommend that you go through the exercise to go through connection profiling and filter out trusted connections as needed. We also recommend that you go through the exercise of determining which tables are "sensitive" and put those tables into appropriate groups by using the Guardium group builder. In addition, you will benefit from also having groups of users (such as administrators, DBAs, or application users) so that you can create your policy rules based on who is accessing the data.

Policies consist of different kinds of rules:

  • Access: Logs activity from the database client to the database server.
  • Exception: Logs exceptions returned from the database such as error codes or failed logins.
  • Extrusion: Acts on the result set, such as redacting values.

Use filtering criteria in the rule to determine when that rule should fire, such as access by particular users to particular objects. Whitelisting and blacklisting are supported.

The policy that we illustrate will cover the following use cases:

Skip logging of activities on certain objects

This rule action is used to avoid logging items of no interest when it is not possible to filter out those items on the S-TAP. (Use Ignore the S-TAP session to filter out trusted sessions on the S-TAP, which can improve performance on the collector.)

In our case, we wanted to make it easier to focus our reports on the relevant results. Thus, we filtered out access to system tables because Cassandra does a lot of system table checks for each query. Because these queries are attached to the query activity, we cannot filter these items out by using the Ignore the S-TAP Session action. We used the group builder to create a member, called CassandraSystemObjects, and added the member system% to it. You can add more members or instead add specific system objects that you are comfortable filtering out.

Note: This example is for illustration purposes only. It should by no means be taken as a recommendation to filter on system object access. As an alternative, you could go ahead and log system access and filter out certain objects at the report level.

Figure 8. Skip the unnecessary logging of some monitored activities
the object field is highlighted and there is a call out that shows the group builder icon. The action is skip logging
the object field is highlighted and there is a call out that shows the group builder icon. The action is skip logging

Detect possible brute force attack - multiple failed logins

The failed login rule lets you specify an action that occurs whenever there are multiple failed logins within a user-specified period of time. The rule is very simple: Select the exception type of LOGIN_FAILED and the number of tries before you reset the timer. The rule below specifies that there were three failed logins within 5 minutes.

Figure 9. Track excessive failed logins attempts
excpt type is login_failed. minimum count is 3, reset interval is 5. action is log only
excpt type is login_failed. minimum count is 3, reset interval is 5. action is log only

The following screen capture in Figure 10 illustrates what the accumulated failure would look like in the Policy Violations / Incident Management report in Guardium:

Figure 10. Policy violation - more than three failed logins in 5 minutes
excpt type is login_failed. minimum count is 3, reset interval is 5. action is log only
excpt type is login_failed. minimum count is 3, reset interval is 5. action is log only

Detailed monitoring of all privileged user activity

Regulations such as PCI require that all access by privileged users (such as DBAs or system administrators) be audited in detail. You can use the white list approach as we demonstrate here, which compares the database user with your group of privileged users. Or you can use a black list, which would turn on detailed monitoring for all users that are not application users, for example.

Figure 11. Detailed monitoring of privileged users
dbuser field has Privileged group and LOG FULL DETAILS is action.
dbuser field has Privileged group and LOG FULL DETAILS is action.

Send alerts for inappropriate access by privileged users

Our next rule is a natural follow-on. In this example, we continue monitoring the same set of privileged users, but we add on more conditions: The objects that are accessed (in the Cardholder group) and what commands are used. We specify it to send an alert to our SIEM system if this rule is triggered (Figure 12). We are also logging a policy violation to Guardium so we can show you what that looks like in the Policy Violations/ Incident Management report (Figure 13)

Figure 12. Send alert when privileged users access cardholder objects by using DML or SELECT
severity field is high, commands is a group called DML + SELECT, DBuser is Privileged and object is a group called cardholder objects. There                         are two actions: 1 is alert once per session and 2 is log only
severity field is high, commands is a group called DML + SELECT, DBuser is Privileged and object is a group called cardholder objects. There are two actions: 1 is alert once per session and 2 is log only

Here is the Policy Violation / Incident Management report (Comply > Reports > Incident Management) that shows the high severity violation.

Figure 13. High severity policy violation
shows a red icon next to the violation to indicate a high severity violation.
shows a red icon next to the violation to indicate a high severity violation.

Block access by unknown connection to highly sensitive object

If you have the advanced edition of Guardium, you can consider the use of blocking for specific situations. With blocking (known as S-GATE in Guardium), certain sessions are specially monitored. This is known as "attaching." Actions by users in that session are then checked against the policy rule to see whether they are attempting to access certain tables that you specify in that rule. If so, the rule is triggered with the action S-GATE Terminate, and their connections are cut before their request can go through to the database.

Because of the need to check each command in the attached session against the policy rule, you must be careful about which sessions are attached or you can accidentally impact performance for applications. Use blocking only for protection against backdoor access or to prevent users with elevated credentials from accessing sensitive data.

We have two rules to support blocking: The first rule attaches to any privileged user session. The second one blocks any access by privileged users against customer tables.

Figure 14. One rule to attach to a session and one rule to block on access to a particular object or object group
extract shows attach on db user privileged group and second rule shows block on block on object %customer%. .
extract shows attach on db user privileged group and second rule shows block on block on object %customer%. .

Redaction of results sets

Finally, let's look at one last rule, an extrusion rule, where we want to prevent privileged users from seeing private data. Extrusion rules require that you change the "master" configuration of inspection engines to enable inspection of returned data.

Navigate to Manage > Activity Monitoring > Inspection Engines and click Inspect Returned Data, as shown below. Then click Restart Inspection Engines.

Figure 15. Configure the inspection engine to look at returned data
described in text above.
described in text above.

Now you're ready to add the new extrusion rule to your policy. Edit your policy and add another extrusion rule. Add the conditions that will trigger the redaction of result sets, such as particular users and client IPs. (Note that extrusion rules cannot be specified by object. Guardium is looking for the pattern in all results for that specified connection.)

Next, you must specify the regular expression that Guardium will use to examine the result sets for matching patterns. Guardium includes several prebuilt regular expressions, but you can create your own or modify the existing ones to match what it is you are trying to redact.

To access the regex builder, click the RE icon next to the Data pattern field in the rule.

Figure 16. Regular expression icon brings up the regular expression builder
described in text above.
described in text above.

Select one of the built-in identifiers or create and test your own using the built-in tester, as exemplified in Figure 17.

Figure 17. Choose an existing pattern or build your own
the type chosen is personal identifier which shows a list of types including us social security number.
the type chosen is personal identifier which shows a list of types including us social security number.

Save and reinstall your policy.

Figure 18 is an example of what redaction would look like if the policy rule is applied for U.S. Social Security numbers.

Figure 18. Social Security numbers are masked in results sets for privileged users
everything but last 4 digits is masked with an asterisk.
everything but last 4 digits is masked with an asterisk.

Compliance reporting automation

A frequently used Guardium capability is the ability to create audit processes. You can assign one or more tasks (such as a particular report) to run on a schedule and send the results to the appropriate set of reviewers in the correct workflow order.

In this case, we decide that we want to create a daily report on all database GRANT statements. We need our PCI reviewer to be made aware of it and then we need our Audit supervisor to sign off on it.

What we did to support this use case is clone one of the built-in reports that matched closely to what we wanted. In our case, we chose the report entitled Execution of Grant Commands.

Tip: To find likely candidate reports, navigate to My Dashboards, Create a new Dashboard. Click Add a new report. In the filter bar, type "grant" and you'll see several possible candidates.

To modify the report, add it to your dashboard and then click the blue pencil icon in the upper left section of the report, which brings up the query for that report. In the query builder, click the Clone button, at which point you can give the report query a new name in the upper part of the query builder. You can add or remove columns (fields) from the report and modify search conditions. In our case, we remove source program name and service name and add the Full SQL field.

Our report now looks like the following screen capture in Figure 19:

Figure 19. Our modified Daily Privileges report
report includes columns client ip, server ip, db user name, database name, object  name (the user granted privileges), full sql and total access.
report includes columns client ip, server ip, db user name, database name, object name (the user granted privileges), full sql and total access.

Now we need to add this report to an audit process, schedule it, and send it to appropriate reviewers.

To create a new audit process, navigate to Comply > Tools and Views > Audit Process Builder. The builder walks you through the process. The figure below shows our audit process, Daily Reports, with the Privileges Daily Report as a task that runs once a day. The reviewers are users with pci and audit roles

Figure 20. Audit process builder helps us create a compliance workflow
The task is our Daily Privileges Report, it runs once  a day and the receivers are pci and audit. .
The task is our Daily Privileges Report, it runs once a day and the receivers are pci and audit. .

You can send report results to users by email, but in our case our audit users will be logging directly in to Guardium to see their activities. (Note that it is very easy to customize the UI and permissions for different roles. See Related topics for a link to a video on how to do this.)

Assuming that our PCI user reviews the report, it then gets added to the to-do list of our Audit supervisor, AuditMan, who will see an alert in his to-do list icon in the dashboard as shown in Figure 21.

Figure 21. To-do list indicator in the banner
The  clipboard icon in guardium banner has a red box with a 1 in it indicating there is 1 todo. t. .
The clipboard icon in guardium banner has a red box with a 1 in it indicating there is 1 todo. t. .

AuditMan will see the report results and then can make comments, escalate, or sign off. These comments and statuses will be stored with the audit process results, which can be archived and retrieved as needed should your organization need to retrieve that for internal or external auditors.

Figure 22. Available workflow actions for audit process tasks
Extract of audit process result for daily privileges report - top part includes buttons for sign results, escalate, download pdf and comment .
Extract of audit process result for daily privileges report - top part includes buttons for sign results, escalate, download pdf and comment .

Summary of capabilities

We hope you will find this article helpful in configuring and using IBM Security Guardium to help protect sensitive data in Cassandra from hackers and insider threats and helping you meet your compliance requirements.

The following table highlights the features and capabilities that are available in the Guardium platform for Cassandra.

Table 2. Guardium platform support for Cassandra
CapabilityGuardium offering
Granular monitoring and auditingData Activity Monitor
Real-time and threshold alertingData Activity Monitor
Advanced analytics (outliers, threat detection)Data Activity Monitor
Search and browse of audit dataData Activity Monitor
Robust REST-based APIData Activity Monitor
Dynamic data redactionData Activity Monitor
BlockingData Activity Monitor (Advanced)
File level data encryptionData Encryption
Monitoring and alerting of activity on files, such as database configuration files or data filesActivity Monitor for Files
Blocking access to filesActivity Monitor for Files (Advanced)

Appendix: Connection profiling

Connection profiling is a handy way to get an overall view of database accesses to help you determine whether there are connections that can be considered trusted and filtered out on the S-TAP or if there are others that are suspicious. The connection profiling list report shows each unique connection and provides a count of the number of times that connection is made during the reporting period specified. The report below shows that the Cassandra connection we used for this article was used 36 times.

Figure 23. Connection Profiling List report
cassandra connection is highlighted.
Full-sized figure - connection for cassandra is highlighted.

From this report, you can invoke the Guardium API to add connections to groups, such as suspicious connections or trusted connections that can be used in your security policy rules moving forward.

To invoke the API from the user interface:

  1. Right-click the connection row in the report.
  2. Scroll down and select Invoke..., then create_member_to_group_by_desc.
  3. Change the description to one of your existing connection groups. Then click Invoke Now.
Figure 24. Adding connections to groups directly from the Connection Profiling List report
text above describes the flow shown in this series of screenshots..
ext above describes the flow shown in this series of screenshot.

If you don't want to see this connection in your connection profile report any more, choose the default group, Connection Profile List.


Downloadable resources


Related topics


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Security, Information Management
ArticleID=1029928
ArticleTitle=Secure and protect Cassandra databases with IBM Security Guardium
publish-date=04192016