InfoSphere Guardium data security and protection for MongoDB, Part 3
Reporting, automating, and blocking
Protect and secure a new generation of databases
Content series:
This content is part # of # in the series: InfoSphere Guardium data security and protection for MongoDB, Part 3
This content is part of the series:InfoSphere Guardium data security and protection for MongoDB, Part 3
Stay tuned for additional content in this series.
The first part of this article series introduced MongoDB and InfoSphere Guardium. It provided some background on how InfoSphere Guardium can help you feel more secure about using MongoDB in more applications because of its ability to thoroughly monitor and audit data activity. You learned the architecture of the solution and some of the recommendations on securing MongoDB using its native capabilities as well as the benefits that InfoSphere Guardium brings.
The second part of the series got into the nitty gritty details of configuring the solution and explained how to create security policy rules for a variety of use cases.
This final article in the series describes more of what you can do with InfoSphere Guardium, including:
- Searching and browsing audit data.
- Creating reports, and configuring an audit process to route the report for review.
- Blocking suspicious users. This particular capability is only available with the Advanced Activity Monitor.
Viewing audit results: Searching and reporting
This section describes a couple of different options for working with audit data:
- Ad hoc search (new in this release)
- Activity reports
Search and browse
The quick search facility, available from the top banner of the Guardium UI when enabled, provides fast search and browse capability for database activities, errors, and violations. This capability uses search indexing, which runs every one to two minutes. You can use common search techniques, including faceted search and text search, together or in combination to quickly do ad hoc investigations of audit data.
The search includes the following:
- A histogram view of statistics of the who, where, what, and when facets of database activities. Click on any of these facets to narrow your search.
- Free-text search that searches all indexed audit data. For example, you could enter the string 'john' and it will search all indexed data to find john, whether it appears in the DB User, OS User, Client, Error, in the message details, and so on.
The search and browse feature is disabled by default. To enable it you can
run the following grdapi as a CLI user:
grdapi
enable_quick_search.
To access this capability, enter a search term or click on the flashlight in the top banner of the InfoSphere Guardium UI, as shown in Figure 1.
Figure 1. Accessing search and browse of audit data
Use the facets on the left to choose value to add to the filter. For example, if you want to see if anyone has recently dropped an object, you would choose your timeframe and then select MongoDB as the DB Type and drop as the verb.
Figure 2. Browsing through audit data using the histogram (facets)
This narrows the result and includes details, including the object dropped, the time, and the db user who issued the command. Due to space constraints, not everything is shown in Figure 3.
Figure 3. Filtered search results
Creating reports
InfoSphere Guardium includes many built-in report definitions as well as a rich report building capability. Some reports are populated with data automatically; for others, you must modify the run time parameters to populate the report, such as specifying the correct date range.
If you see a report you like, you can also clone the query that is used to generate that report and tweak it to suit your needs. For example, let's assume you like the report called "Admin Users Login." If you are logged in as an admin, you will find this report on the Daily Monitor tab. If you click on the report, you may see the message No data found, as shown in Figure 4. The usual causes for this message are if the date range does not include a timeframe where that activity appears or if some other aspect of the query condition is not met.
Figure 4. A built-in report in which query results are not found
By clicking on the yellow pencil below the report, you can see the base query used to create the report, which looks like Figure 5. The top half includes the columns in the report and the bottom includes the conditions. You can see that one condition for the report is a runtime parameter for the Admin Users group.
Figure 5. The query used to generate the report
To see who is in the Admin Users group, you can go to the Group Builder tool. Assuming you are logged in as an admin user, navigate to the Group Builder from the Tools tab.
Figure 6. Group Builder menu
When the Group Filter opens, click Next. From the list of existing groups, select Admin Users, and click Modify.
If your MongoDB admin users are not in the list, you can add them, as shown in Figure 7.
Figure 7. Adding a new administrative user to the group
If the report still doesn't show data, you can customize the report to change the data range. To do this, click on the Customize icon (blue pencil ) in the upper right of the report, as shown in Figure 8.
Figure 8. Customize the report by clicking on the blue pencil in upper right of report portlet
Then you can change the date range (as we have in Figure 9) to include a time range that includes the entire previous week (NOW -1 week), when we know there was activity.
Figure 9. Extending the date range of the report
Now the report shows data, such as shown in Figure 10.
Figure 10. Report now shows data
We've barely scratched the surface of report customization and creation. However, in Related topics there is a link to a "how to" topic in the InfoSphere Guardium Information Center that can help you get started.
Use a data mart to improve performance of predefined reports
You can use your own or Guardium predefined queries and reports to create a data mart that you can use to significantly improve the performance for your frequently used reports. A data mart is a designated table that is based on your desired report structure. You define the data mart's data granularity for summarization purposes (such as minutes, hours, days, or weeks) and schedule it to run periodically. Because the structure is predefined, it eliminates the need to do runtime joins or other resource-intensive database activities.
Data marts can be especially effective when used with the regular reporting that you may need to do on the Guardium Aggregators on large amounts of data. Because the data mart reflects the structure of the report, there is no need for complex, multi-table joins, thereby significantly improving the performance of those reports.
Any report can be turned into a data mart by clicking on the Data Mart Builder link at the bottom of the report, as shown in Figure 11.
Figure 11. Icon to go into the Data Mart Builder
In the Data Mart builder, you can specify how often you want the query to run, and when you save it a default report is created using that definition. The data is populated continuously per the granularity and schedule that you select.
Figure 12. Data Mart Configuration
Creating a report of audit data and adding it to a workflow for review
Running reports and getting approvals is not anyone's idea of fun. The more this process can be automated, the less time you have to spend worrying about it and the greater your ability to have the audit trail you need for compliance officers or auditors. With Guardium, you can use an audit process to schedule the reports to run and be sent automatically to the reviewers. The system will keep track of who has reviewed or signed off. All required actions can be securely executed through the web interface, including reviewing results, providing approvals, commenting, and escalating an action.
Figure 13. Audit process can automate routing of reviews and signoffs
Although there's not space to go into great detail about creating an audit process, we did want to show you the highlights. In this example, we want to create an audit process that sends a copy of our Privileges report to the appropriate person for review.
Figure 14 shows what our report looks like.
Figure 14. A report we created called MongoDB Privilege Report
To add it to an audit process, go to the Audit Process Builder (from Tools, if you are logged in as admin) and create a new process. You will be asked to create receivers, who are the people (or roles) who will receive the results of the audit process. Then you add the report as a task in this audit process, including the time period you want the report query to cover (for example, NOW -1 DAY until NOW). A process can have multiple tasks, which might consist of a set of reports or other activities.
Figure 15. Audit process builder
You can schedule the task to run periodically, such as every day at midnight. That way, administrators or DBAs will have the report in their email in the morning. Their approvals (if required) and comments will be kept as part of the audit trail for this process.
Figure 16 gives an example of an email that was sent that includes a PDF of the report.
Figure 16. Example e-mail from audit process
Blocking access (with Advanced Activity Monitoring)
There may be cases in which it is critical to block users from access to particular data. A typical use case would be blocking administrator access to sensitive data or when an unknown user is discovered in the system. This capability, which is available in the Advanced Activity monitoring license, can help protect your data when:
- Outsourced DBAs are used who need to be restricted from access to sensitive data
- When there are concerns over an existing or imminent insider or external breach
This capability relies on S-GATE, which is an extension of the S-TAP that you activate by modifying some parameters in the guardtap.ini file. The S-GATE parameters are called "firewall" parameters. Because the use of S-GATE can introduce some latency, we recommend that you enable S-GATE in the initialization file but that you turn it on only when certain specific conditions are met using a policy action called S-GATE ATTACH. Listing 1 provides an example of the firewall parameters you modify in the guardtap.ini file.
firewall_installed=1 <This enables the S-GATE capability to be used firewall_fail_close=0 firewall_default_state=0 <S-GATE off by default but can be turned on using a policy rule firewall_timeout=10
Assuming that the S-GATE ATTACH rule has been activated, the process works as follows (See Figure 17 for an illustration of the steps):
- When an unauthorized user connects to MongoDB and enters a command, the S-GATE recognizes that this particular session is one that must be watched.
- The command is held by S-GATE.
- The command is compared against the policy to see if there is a policy violation, such as accessing a particular sensitive object or group of objects.
- If the policy rule is violated and your policy action is S-GATE TERMINATE, S-GATE will terminate the session and the command will not be allowed to continue to the Mongo server. If the command is allowed, then the statement is allowed to go to the server.
Figure 17. Overview of the blocking process
There are many different combinations that can be used to set up blocking for your needs. The most important thing is to ensure that you do not use this for normal business applications because of the latency introduced to check all the incoming commands against the policy.
For our policy, we will block access to any sensitive data objects from anyone who is not in the "authorized user group." This group may consist of specific IDs for an authorized application, for example. Table 1 is a summary of the rules we'll be creating and the groups that are used in each rule.
Table 1. Rules and groups used to create our sample policy rules
| Rule description | Groups used in the rule |
|---|---|
| Watch unauthorized users (Enable S-GATE for any activity by a user who is NOT in the authorized user group for these objects.) | Authorized users (modify built-in group) |
| Block unauthorized users (to sensitive data) | Authorized users (modify built-in group) MongoDB Sensitive Objects (created earlier, in Part 2 of this article series) |
Now we'll describe the rules you need to activate blocking under the right circumstances.
First, as shown in Figure 18, specify the S-GATE attach conditions in which everyone who is not an authorized user will activate S-GATE. Note that this will have a performance impact, so you only want to activate S-GATE attach under limited circumstances. It is not recommended to use this with application traffic.
Figure 18. Set the conditions under which to start watching data activity
Next, if any of those users access sensitive data, go ahead and terminate the connection.
Figure 19. Set the conditions under which to terminate the user's connection
Notice that when a session is blocked, this will get written as a policy violation, which you can also see on the Incident Management tab. If your rule includes an action to alert, this will also get written to SYSLOG so that it can be forwarded to a SIEM system for follow-up and investigation by security personnel. There is also an option to quarantine a user for a specified period of time to allow for security investigations to take place.
Summary
This article series has done a deep dive on the InfoSphere Guardium support for MongoDB, but the capabilities described herein are applicable across a wide variety of database systems, which reflects the widely heterogeneous data processing systems that represent both past, present, and future database technologies. Database and data processing technologies evolve rapidly to fulfill the needs of new applications and use cases. MongoDB is one of the leading providers of "NoSQL" technology, and as such, is being used alongside traditional relational databases in many organizations who need new technologies to handle new data processing problems. Thus, having a data security and monitoring solution that can also be used across both relational and NoSQL technologies just makes sense.
InfoSphere Guardium is built on a foundation that can adapt and quickly deliver data monitoring capabilities across a wide variety of databases, including other NoSQL systems such as Cassandra and CouchDB, relational, mainframe data (including DB2, IMS, and VSAM) or Hadoop-based systems such as InfoSphere BigInsights, Cloudera, Greenplum Hadoop, and Hortonworks Data Platform.
In this article series, we have demonstrated the result of work that IBM and 10gen have done together to develop and validate InfoSphere Guardium capability for MongoDB. Together, these offerings can provide a NoSQL option that offers the security and auditing capabilities often required by organizations for compliance with a wide variety of privacy and financial regulations.
Downloadable resources
Related topics
- The InfoSphere Guardium website includes links to white papers, demos, and more.
- Download MongoDB here.