This tip is part of SearchSecurity.com's Intrusion Defense School on How DAM can help detect and trace attacks....
For more in-depth tutorials, visit SearchSecurity.com's Security School page.
There are few IT security challenges more difficult than protecting databases and the data they store, especially from the most common database and Web application attack: SQL injection. Even though relational database management system (RDBMS) vendors, IT security professionals and application developers are all aware of these attacks, they remain a problem because the attacks are difficult to detect and stop without compromising business operations.
More on DAM
- Check out this Information Security magazine feature on how DAM can help with security and compliance by tracking everything going on in the database.
- See common DAM software deployment issues to avoid.
- Learn why IBM's acquisition of Guardium does not validate DAM as a viable security market segment.
What's more, SQL injection is one of many common avenues of assault that allows attackers to take complete control of a relational database. The complexity of the relational platform, coupled with multiple applications moving data in and out of the system -- each supporting a variety of business functions -- makes it difficult to differentiate good from bad. When attacks look like normal database commands, you have to do more than a casual inspection of events.
For those who may not be familiar with the technology, database activity monitoring (DAM) systems are advanced security platforms used to detect misuse of relational databases. DAM is unique in that it analyzes database queries in near real time to differentiate between normal operations and attacks. The systems collect information from different sources, provide several forms of advanced analytics, alerting or even halt malicious activity. No other security product focuses on database activity in this way, or offers the level of granular inspection provided by DAM.
Prioritize which data, transactions to protect
The first step in any DAM deployment is deciding what you want to protect. In any discussion of database monitoring best practices, it's not practical to monitor every event because your monitoring system would be larger than the databases it was designed to protect. You need to have some understanding of what data and/or transactions are important. There are three ways to do this:
- Interview database administrators and application developers who set up the databases because they typically know where sensitive data resides, and which databases support critical business functions.
- Inspect database contents using data discovery and database crawlers. Monitors can, at the very least, detect sensitive data as it moves in and out of the database. Some vendors also provide crawlers to search database content as an add-on option. These inspection tools locate sensitive information through a combination of meta data and content analysis techniques to determine what needs to be protected.
- Observe SQL statements and database transactions. Most DAM systems are deployed in monitor-only mode for the first few weeks so the organization can develop an understanding of what is happening with the database. In essence, you profile how applications use the database, and what typical queries look like. Then policies can be developed and implemented to detect misuse.
Based upon what you find, you can define rules of what activities are allowed, and what suspicious activity should generate an alert.
How to capture database events
Now that you know what types of transactions are important, you need to decide how you want to collect database events. Every database monitor offers multiple methods for data collection, and each comes with advantages and disadvantages.
Agents installed on the database platform are common because they capture all SQL activity, which is desirable for understanding if a query was intended to be malicious without compromising database performance.
Native audit features collect events, but don't always gather the original SQL queries, and cost a great deal more in terms of performance overhead.
Network collectors offer a quick and easy way to collect a majority of SQL activity, but miss some transactions and activity performed by administrators working at the console.
Agents are the de facto deployment for security of critical databases. Native auditing for compliance and network monitoring of non-critical databases is common, but used more in special cases.
Defining basic database security
Now that you are collecting events from critical systems, it's time to implement your security policies. DAM works by analyzing database queries, and you have many options to specify which statements are examined and how. The fundamental features you can expect a database activity monitoring solution to provide are:
- Monitoring and discovery
- Alerts and reports
- Verification of work orders
- Catching misuse
- SQL capture for auditing
Most policies are enforced by examining attributes of the database query: whom the user is; what columns the user is viewing; what application they are using; how much data did they touch; and time of day are all commonly used to define security policies. You assign an arbitrary value to each of these attributes, and the monitoring system will generate alerts when the user exceeds the defined threshold. For example, you may want to alert on all queries after midnight, or after 3 failed login attempts, or any time someone accesses credit card data.
Database activity monitoring systems have greatly advanced their capabilities in the last couple of years. What used to be purely monitoring and altering now provides a reliable method of blocking attacks and actively resisting misuse. The advanced features you should find with most DAM products include:
- SQL injection detection
- Blocking and virtual patching
- Identifying specific application users
- Session termination
- Behavioral monitoring and insider threat detection
But advanced analysis means advanced policies that are specific to your environment, and these don't come from your vendor. In order to detect and block SQL injection attacks, you need to define legitimate SQL queries you wish to allow from the application. If you can't implement a database patch in a timely fashion, you need to write a policy to detect the attack and deploy DAM to block the threat. Hopefully, your DAM vendor will help with these policies if your database vendor does not.
In order to perform behavioral monitoring, in essence detecting abnormal behavior, you need to define what's considered normal. To identify specific application users -- not just the generic accounts that connect from the application to the database -- you need to provide the means to lookup IP addresses or pass user credentials. If a serious threat is detected, you need to determine if you want to disconnect¬ the user or lock the account from being accessed. All of these advanced features require custom work on your part; while DAM vendors provide templates and tools from which to build your policies, detection and enforcement are specific to your environment, so the policies must be customized by you.
There are several operational aspects to managing DAM platforms that you want to employ from the outset to save yourself time and trouble in the long run. These include:
Separation of duties: Both for security and compliance reasons, the people who write policies and review the reports should not be the database administrators that manage the monitored databases. Similarly, a DBA for one group should not be allowed to use DAM tools to peer into other groups of databases. The idea is to provide checks and balances to detect fraud, so divide up roles and responsibilities within the DAM product.
Long-term storage: Database activity monitoring platforms don't commonly have the storage capacity of security information and event management (SIEM) and log management platforms. While they provide some correlation capabilities, these products focus on statement-level analysis, not long-term storage and management. Events are seldom kept within a DAM product for more than 30 days. If you need to perform forensic analysis on a 90- or 180-day window, plan on adding storage to an existing DAM server or leveraging log management systems help in this area.
Scalability: There are three critical issues to scalability of DAM; transactional volume, network topology and the resources dedicated to the monitoring. DAM architectures are comprised of local data collectors, appliances that analyze events and generate alerts, and management appliances that provide central policy management and reporting. You need to ensure each of these pieces can reliably communicate with one another, and that you can collect events from databases deployed in virtual environments. To maximize your DAM investment, it's best to understand the type of events you want to analyze, and filter everything you are not worried about. The fewer events means reduced storage and processing overhead. When monitoring databases that process millions of requests per hour, filtering can dramatically cut your investment in appliances or servers to support monitoring.
Database activity monitoring is a mature technology, and its focus on database transactions provides an effective means of securing data and blocking malicious actions. But getting value out of a monitoring platform requires investment in building rules, alerts and reports to address the security issues you face.
Further, careful section of deployment options is needed to avoid creating administration headaches or performance problems. There are many uses for DAM, so you will need to have a clear idea of what your priorities are going in, and focus on getting the basics working first before you move onto more advanced security features.
About the author:
Adrian Lane is CTO and security strategist for information security research and analysis firm Securosis.