Today’s post focuses on the administering Database Security Platforms. Conceptually DSP is pretty simple: collect data from databases, analyze it according to established rules, and react when a rule has been violated. The administrative component of every DSP platform follows these three basic tasks: data management, policy management, and workflow management. In addition to these three basic functions, we also need to administer the platform itself, as we do with any other application platform.

As we described in our earlier post on DSP technical architecture, DSP sends all collected data to a central server. The DAM precursors evolved from single servers, to two-tiered architectures, and finally into a hierarchal model, in order to scale up to enterprise environments. The good news is that system maintenance, data storage, and policy management are all available from a single console. While administration is now usually through a browser, the web application server that performs the work is built into the central management server. Unlike some other security products, not much glue code or browser tricks is required to stitch things together.

System Management

• User Management: With access to many different databases, most filtering and reporting on sensitive data, user management is critical for security. Establishing who can make changes to policies, read collected data, or administer the platform are all specialized tasks, and these groups of users are typically kept separate. All DSP solutions offer different methods for segregating users into different groups, each with differing granularity. Most of the platforms offer integration with directory services to aid in user provisioning and assignment of roles.
• Collector/Sensor/Target Database Management: Agents and data collectors are managed from the central server. While data and policies are stored centrally, the collectors – which often enforce policy on the remote database – must periodically synch with the central server to update rules and settings. Some systems require the administrator to ‘push’ rules out to agents or remote servers, while others synch automatically.
• Systems Management: DSP is, in and of itself, and application platform. It has web interfaces, automated services, and databases like most enterprise applications. As such it requires some tweaking, patching, and configuration to perform its best. For example, the supporting database may need pruning to clear out older data, vendor assessment rules require updates, and the system may need additional resources for data storage and reports. The system management interface is provided via a web browser, but only available to authorized administrators.

Data Aggregation & Correlation

The one characteristic Database Activity Monitoring solutions share with log management, and even Security Information and Event Management, tools is their ability to collect disparate activity logs from a variety of database management systems. They tend to exceed the capabilities of related technologies in their ability to go “up the stack” in order to gather deeper database activity application layer data, and in their ability to correlate information. Like SIEM, DSP aggregates, normalizes, and correlates events across many heterogenous sources. Some platforms even provide an optional ‘enrichment’ capability by linking audit, identity and assessment data to event records. For example, providing both ‘before’ and ‘after’ data values for a suspect query.

Despite central management and correlation features, the similarities with SIEM end there. By understanding the Structured Query Language (SQL) of each database platform, these platforms can interpret queries and understand their meaning. While a simple SELECT statement might mean the same thing across different database platforms, each database management system (DBMS) is full of its own particular syntax. DSP understands the SQL for each platform is able to normalize events so the user doesn’t need to know the ins and outs of each DBMS. For example, if you want to review all privilege escalations on all covered systems, a DAM solution will recognize those events, regardless of platform and present a complete report, without you having to understand the SQL.

A more advanced feature is to then correlate activity across different transactions and platforms, rather than looking only at single events. For example, some platforms recognize a higher than normal transaction volume by a particular user, or (as we’ll consider in policies) can link a privilege escalation event with a large SELECT query on sensitive data, which could indicate an attack. All activity is also centrally collected in a secure repository to prevent tampering or a breach of the repository itself. Since they collect massive amounts of data, DSPs must support automatic archiving. Archiving should support separate backups of system activity, configuration, policies, alerts, and case management; and encrypt under separate keys to support separation of duties.

Policy Management

All platforms come with sets of pre-packaged policies for security and compliance. For example, every product contains hundreds, if not thousands, of assessment policies that identify vulnerabilities. Most platforms come with pre-defined policies for monitoring standard deployments of databases behind major applications such as Oracle Financials and SAP. Built-in policies for PCI, SOX, and other generic compliance requirements are also available to help you jump-start the process and save many hours of policy building. Every single policy has the built-in capability of generating an alert if the rule is violated – usually through email, instant message or some other messaging capability. Note that every user needs to tune or customize a subset of pre-existing policies to match their environment, and create others to address specific risks to their data. They are still far better than starting from scratch.

Activity monitoring policies include user/group, time of day, source/destination, and other important contextual options. And these policies should offer different analysis techniques based on attributes, heuristics, context, and content analysis. They should also support advanced definitions, such as complex multi-level nesting and combinations. If a policy violation occurs you can specify any number of alerting, event handling and reactive actions. Ideally, the platform will include policy creation tools that limit the need to write everything out in SQL or some other definition language; it’s much better if your compliance team does not need to learn SQL programming to create policies. You can’t avoid having to do some things by hand, but policy management should be as point-and-click easy as possible.

For common types of policies, including detecting privileged user activity and quantity thresholds on sensitive data, policy wizards are extremely useful. One of the distinguishing characteristics of activity monitoring tools is that they don’t just collect and log activity – they analyze it in real or near-real time for policy violations. While still technically a detective control (we will talk about preventative policies later), the ability to alert and respond in practically real time offers security capabilities far beyond simple log analysis. Successful loss-bearing database attacks are rarely the result of a single malicious query – they involve a sequence of events leading to the eventual damage. Ideally, policies will be established to detect the activity early enough to prevent the final loss-bearing act. Even alerts triggered after the fact facilitate immediate incident response, and investigation can begin immediately, rather than after days or weeks of analysis. Policy wizards are extremely useful – especially for common policy types, such as detecting privileged user activity and count thresholds on sensitive data.

Assessment policies are just as critical as monitoring policies, but they are handled differently. Unlike monitoring policies, most assessment policies will be provided by the vendor. New database vulnerabilities are discovered all the time, and to keep pace DSP vendors need to develop and distribute new policies to address new threats. Most vendors provide new policies on a weekly or monthly basis. Unlike monitoring policies, vendors typically do not share the underlying SQL with customers. The code to detect vulnerabilities, as well as the vulnerability research data, is considered “secret sauce”. If you want to customize vulnerability scans you will either need to develop your own or work with your vendor. Policy management interfaces for assessment and monitoring are both available through web interfaces, but not typically integrated – both because the underlying code that supports the policies is entirely different, and to provide separation of duties between monitoring and assessment audiences.

Reports & Workflow

• Reports: As with nearly any security tool, you’ll want flexible reporting options, but pay particular attention to compliance and auditing reports to support compliance needs. Aside from all the security advantages we’ve been talking about, many organizations initially deploy monitoring to meet database audit and compliance requirements. Built-in report templates are universally available, and save valuable time in getting your product deployed. Some vendors work directly with auditors from the major firms to help design reports for specific regulations like SOX. Reports should fall into at least three broad categories: compliance and non-technical reports, security reports (incidents), and general technical reports.
• Change management: Although many organizations have rigorous change management policies for the database platform and underlying system, far fewer enforce change management at the query level (which is invisible to traditional change management tools). Some DSP solutions offer integration with external change management and workflow tools for closed-looped tracking of query-level changes. The requested change is approved in the change management system and a ticket number issued. The DBA enters that ticket number as part of their session, and all database changes (even to individual field updates) are recorded and correlated back to the original change ticket. Changes without associated tickets are logged in compliance reports and may trigger a security alert, depending on supporting policies.
• Integration: DSPs collect a wealth of information from databases that, due in part to the way data is collected, is not available to other systems. Enterprise DSP deployments often ‘react’ to events by streaming data to other security services. Vulnerability reports and alerts on suspicious activity are often formatted and sent to SIEM and Log Management platforms. In many cases customers have databases disconnect active sessions and lock user accounts based on perceived threats. DSP handles real time alerts and maintains its own event repository, but works in tandem with these other systems to help both near-real-time reaction and forensic auditing.

In our next post we ll cover the common use cases.