Read the Original Article at http://www.informationweek.com/news/showArticle.jhtml?articleID=223000103
The need to secure databases isn't new, but with the rapid growth of multivendor, multi-instance database environments, it's becoming increasingly difficult for companies to tell whether queries are coming from authorized applications and users, or from unauthorized snoops or even malicious attackers.
Companies also are owning up to long-standing security blind spots, such as database administrators who play multiple roles, viewed as one part system administrator, one part developer. These privileged super-users work with sensitive data frequently, and with that freedom comes the potential for accidental or intentional abuse.
One of the most promising technologies for staying on top of this state of affairs is database activity monitoring, or DAM. These systems let companies monitor database events, in real time if they want, in hopes of responding to unauthorized activity. Some DAM products provide features for privileged-user monitoring and basic database auditing, two areas that have been underserved.
These products are still expensive; appliances run $25,000 to $50,000 each, while agent-based offerings cost $5,000 to $25,000 per database. There are tough architectural decisions to be made, especially for distributed enterprises. Expect some turf warfare among database, network, and security teams. But seeing as our databases are increasingly attack targets, a DAM system might be worth the investment.
DAM products monitor SQL activity in real time across multiple database platforms and generate alerts based on policy violations. The systems can aggregate and to some degree correlate activity from multiple database products, including Microsoft SQL Server and Oracle. Some products also provide the additional benefit of monitoring and storing records of activity outside the target databases, which can come in handy if the systems housing those databases are compromised.
Three Categories Of DAM
Systems can be grouped into three categories: Network monitoring, local agent monitoring, and remote monitoring.
Network monitoring products are typically appliances. With them, you need to consider if you want to do active or passive network monitoring.
In an active or inline setup, the appliance sits between the target database and the network infrastructure, and all SQL activity passes through the appliance before it reaches the database server. The DAM appliance looks for policy violations using pre-set rules, very similar to how intrusion-prevention systems work, with similar trade-offs. An active model lets IT go beyond just auditing and monitoring to proactively putting a halt to questionable activities. The downside is that it can hurt database performance, limit database scalability, and potentially disrupt service with false positives.
In a passive setup, the DAM network appliance monitors activity by capturing and evaluating copies of the data stream between clients and database servers. This approach is similar to the active model in that the product monitors SQL traffic via the network, but the appliance doesn't play an inline role. Passive deployment lets a single DAM appliance scale to monitor a large number of devices because it simply needs to see copies of traffic. It's deployed using the same port-mirror/spanning technique that many intrusion-detection systems use. Passive deployment eliminates the latency that could be introduced with an active inline system, and devices can be installed without any service interruption. In terms of blocking, you can do session resets based on specific patterns, but the appliance's ability to stop malicious activities is limited.
Neither passive nor active network monitoring requires modifications to the databases being protected. There are clear disadvantages to network monitoring, however. The biggest: They're blind to activity that doesn't cross the network, such as local console connections.
Agent-based auditing is often used to fill gaps left by network-based approaches. This collection technique requires installation of a software agent on the database server that collects and monitors activity using techniques such as hooking loop-back interfaces and doing local sniffing, or attaching sensors to the cache memory. While these products get around some of the blind spots found in network-based appliances, they have their own downsides. Performance can be a problem. Also, agents must be developed for every database type (for example, SQL Server 2003 and 2005), and agents must be deployed on every target database. Not an unintrusive project by any means.
In this model, the collector appliance is given administrative access to target databases, and native database auditing is turned on. The product then pulls audit logs from the database systems for analysis. This approach can be less database-intensive than an agent-based setup if a minimal amount of logging is enabled, but it still imposes some load on the database. You need to consider the overhead associated with generating and copying audit logs.
And the system requires an administrative account on the database. Because of these issues, the passive approach still remains the least impactful.
Who Needs It?
DAM makes the most sense for organizations that need to know where their critical data is and what's happening to it in real time, because of their own security and risk assessments or regulatory compliance requirements.
We're seeing midsize to large financial institutions, retailers (online or brick and mortar), and healthcare providers as early adopters. The common thread: All have lots of sensitive data to protect, and all are subject to one or more regulations related to monitoring against data misuse and theft.
If you decide to deploy database activity monitoring, know that it requires cooperation among multiple groups, and don't underestimate the dependencies on various IT specialties.
For example, for inline products the network team will have to design and provision span ports on critical switches--ports that, in some organizations, are in short supply as they're often used for intrusion detection and network monitoring. With agent-based products, both system administrators and DBAs will need to be involved, as you'll be introducing yet another "moving part" on systems for which they're responsible. The larger the organization and more extensive the DAM deployment, the more people you'll need to bring to the table. CIOs should get those teams lined up early. Key responsibilities that must be assigned include: laying out the deployment architecture, setting up data access policies, writing report templates, managing report distribution, and monitoring and responding to alerts.
On an ongoing basis, DAM as a function should be owned and managed by security teams, not DBAs. This is an important distinction: DBAs have an important part to play, mainly during DAM setup, based on their domain knowledge of the database environment. On an ongoing basis, though, they should have very limited involvement. Remember, eliminating that blind spot of DBAs with data access is a big reason you're considering database activity monitoring.
Of course, it can be a challenge to prevent your DBAs from taking a negative perception of "big brother watching." Communicate early and often. The decision to adopt database activity monitoring should be communicated as a positive risk management tool that fits the larger trend of spending less of the security budget on perimeter defenses and more on defense-in-depth strategies that protect the corporate crown jewels: the databases.
Paresh Amin is a consultant with Chicago-based security firm Neohapsis. Write to us at firstname.lastname@example.org