Dam

You Have to Buy Data Security Tools

By Rich

When Mike was reviewing the latest Pragmatic Data Security post he nailed me on being too apologetic for telling people they need to spend money on data-security specific tools. (The line isn't in the published post).

Just so you don't think Mike treats me any nicer in private than he does in public, here's what he said:

Don't apologize for the fact that data discovery needs tools. It is what it is. They can be like almost everyone else and do nothing, or they can get some tools to do the job. Now helping to determine which tools they need (which you do later in the post) is a good thing. I just don't like the apologetic tone.

As someone who is often a proponent for tools that aren't in the typical security arsenal, I've found myself apologizing for telling people to spend money. Partially, it's because it isn't my money... and I think analysts all too often forget that real people have budget constraints. Partially it's because certain users complain or look at me like I'm an idiot for recommending something like DLP.

I have a new answer next time someone asks me if there's a free tool to replace whatever data security tool I recommend:

Did you build your own Linux box running ipfw to protect your network, or did you buy a firewall?

The important part is that I only recommend these purchases when they will provide you with clear value in terms of improving your security over alternatives. Yep, this is going to stay a tough sell until some regulation or PCI-like standard requires them.

Thus I'm saying, here and now, that if you need to protect data you likely need DLP (the real thing, not merely a feature of some other product) and Database Activity Monitoring. I haven't found any reasonable alternatives that provide the same value.

There. I said it. No more apologies -- if you have the need, spend the money. Just make sure you really have the need, and the tool you are looking at really delivers the value, since not all solutions are created equal.

–Rich

Pragmatic Data Security: Discover

By Rich

In the Discovery phase we figure where the heck our sensitive information is, how it's being used, and how well it's protected. If performed manually, or with too broad an approach, Discovery can be quite difficult and time consuming. In the pragmatic approach we stick with a very narrow scope and leverage automation for greater efficiency. A mid-sized organization can see immediate benefits in a matter of weeks to months, and usually finish a comprehensive review (including all endpoints) within a year or less.

Discover: The Process

Before we get into the process, be aware that your job will be infinitely harder if you don't have a reasonably up to date directory infrastructure. If you can't figure out your users, groups, and roles, it will be much harder to identify misuse of data or build enforcement policies. Take the time to clean up your directory before you start scanning and filtering for content. Also, the odds are very high that you will find something that requires disciplinary action. Make sure you have a process in place to handle policy violations, and work with HR and Legal before you start finding things that will get someone fired (trust me, those odds are pretty darn high).

You have a couple choices for where to start -- depending on your goals, you can begin with applications/databases, storage repositories (including endpoints), or the network. If you are dealing with something like PCI, stored data is usually the best place to start, since avoiding unencrypted card numbers on storage is an explicit requirement. For HIPAA, you might want to start on the network since most of the violations in organizations I talk to relate to policy violations over email/web/FTP due to bad business processes. For each area, here's how you do it:

• Storage and Endpoints: Unless you have a heck of a lot of bodies, you will need a Data Loss Prevention tool with content discovery capabilities (I mention a few alternatives in the Tools section, but DLP is your best choice). Build a policy based on the content definition you built in the first phase. Remember, stick to a single data/content type to start. Unless you are in a smaller organization and plan on scanning everything, you need to identify your initial target range -- typically major repositories or endpoints grouped by business unit. Don't pick something too broad or you might end up with too many results to do anything with. Also, you'll need some sort of access to the server -- either by installing an agent or through access to a file share. Once you get your first results, tune your policy as needed and start expanding your scope to scan more systems.
• Network: Again, a DLP tool is your friend here, although unlike with content discovery you have more options to leverage other tools for some sort of basic analysis. They won't be nearly as effective, and I really suggest using the right tool for the job. Put your network tool in monitoring mode and build a policy to generate alerts using the same data definition we talked about when scanning storage. You might focus on just a few key channels to start -- such as email, web, and FTP; with a narrow IP range/subnet if you are in a larger organization. This will give you a good idea of how your data is being used, identify some bad business process (like unencrypted FTP to a partner), and which users or departments are the worst abusers. Based on your initial results you'll tune your policy as needed. Right now our goal is to figure out where we have problems -- we will get to fixing them in a different phase.
• Applications & Databases: Your goal is to determine which applications and databases have sensitive data, and you have a few different approaches to choose from. This is the part of the process where a manual effort can be somewhat effective, although it's not as comprehensive as using automated tools. Simply reach out to different business units, especially the application support and database management teams, to create an inventory. Don't ask them which systems have sensitive data, ask them for an inventory of all systems. The odds are very high your data is stored in places you don't expect, so to check these systems perform a flat file dump and scan the output with a pattern matching tool. If you have the budget, I suggest using a database discovery tool -- preferably one with built in content discovery (there aren't many on the market, as we'll mention in the Tools section). Depending on the tool you use, it will either sniff the network for database connections and then identify those systems, or scan based on IP ranges. If the tool includes content discovery, you'll usually give it some level of administrative access to scan the internal database structures.

I just presented a lot of options, but remember we are taking the pragmatic approach. I don't expect you to try all this at once -- pick one area, with a narrow scope, knowing you will expand later. Focus on wherever you think you might have the greatest initial impact, or where you have known problems. I'm not an idealist -- some of this is hard work and takes time, but it isn't an endless process and you will have a positive impact.

We aren't necessarily done once we figure out where the data is -- for approved repositories, I really recommend you also re-check their security. Run at least a basic vulnerability scan, and for bigger repositories I recommend a focused penetration test. (Of course, if you already know it's insecure you probably don't need to beat the dead horse with another check). Later, in the Secure phase, we'll need to lock down the approved repositories so it's important to know which security holes to plug.

Discover: Technologies

Unlike the Define phase, here we have a plethora of options. I'll break this into two parts: recommended tools that are best for the job, and ancillary tools in case you don't have a budget for anything new. Since we're focused on the process in this series, I'll skip definitions and descriptions of the technologies, most of which you can find in our Research Library

Recommended Tools

1. Data Loss Prevention (DLP): This is the best tool for storage, network, and endpoint discovery. Nothing else is nearly as effective.
2. Database Discovery: While there are only a few tools on the market, they are extremely helpful for finding all the unexpected databases that tend to be floating around most organizations. Some offer content discovery, but it's usually limited to regular expressions/keywords (which is often totally fine for looking within a database).
3. Database Activity Monitoring (DAM): A couple of the tools include content discovery (some also include database discovery). I only recommend DAM in the discover phase if you also intend on using it later for database monitoring -- otherwise it's not the right investment.

Ancillary Tools

1. IDS/IPS/Deep Packet Inspection: There are a bunch of different deep packet inspection network tools -- including UTM, Web Application Firewalls, and web gateways -- that now include basic regular expression pattern matching for "poor man's" DLP functionality. They only help with data that fits a pattern, they don't include any workflow, and they usually have a ton of false positives. If the tool can't crack open file attachments/transfers it probably won't be very helpful.
2. Electronic Discovery, Search, and Data Classification: Most of these tools perform some level of pattern matching or indexing that can help with discovery. They tend to have much higher false positive rates than DLP (and usually cost more if you're buying new), but if you already have one and budgets are tight they can help.
3. Email Security Gateways: Most of the email security gateways on the market can scan for content, but they are obviously limited to only email, and aren't necessarily well suited to the discovery process.
4. FOSS Discovery Tools: There are a couple of free/open source content discovery tools, mostly projects from higher education institutions that built their own tools to weed out improper use of Social Security numbers due to a regulatory change a few years back.

Discover: Case Study

Frank from Billy Bob's Bait Shop and Sushi Outlet decides to use a DLP tool to help figure out where any unencrypted credit card numbers might be stored. He decides to go with a full suite DLP tool since he knows he needs to scan his network, storage, servers in the retail outlets, and employee systems.

Before turning on the tool, he contacts Legal and HR to set up a process in case they find any employees illegally using these numbers, as opposed to the accidental or business-process leaks he also expects to manage. Although his directory servers are a little messy due to all the short-term employees endemic to retail operations, he's confident his core Active Directory server is relatively up to date, especially where systems/servers are concerned.

Since he's using a DLP tool, he develops a three-tier policy to base his discovery scans on:

1. Using the one database with stored unencrypted numbers, he creates a database fingerprinting policy to alert on exact matches from that database (his DLP tool uses hashes, not the original values, so it isn't creating a new security exposure). These are critical alerts.
2. His next policy uses database fingerprints of all customer names from the customer database, combined with a regular expression for generic credit card numbers. If a customer name appears with something that matches a credit card number (based on the regex pattern) it generates a medium alert.
3. His lowest priority policy uses the default "PCI" category built into his DLP tool, which is predominantly basic pattern matching.

He breaks his project down into three phases, to run during overlapping periods:

1. Using those three policies, he turns on network monitoring for email, web, and FTP.
2. He begins scanning his storage repositories, starting in the data center. Once he finishes those, he will expand the scans into systems in the retail outlets. He expects his data center scan to go relatively quickly, but is planning on 6-12 months to cover the retail outlets.
3. He is testing endpoint discovery in the lab, but since their workstation management is a bit messy he isn't planning on trying to install agents and beginning scans until the second year of the project.

It took Frank about two months to coordinate with other business/IT units before starting the project. Installing DLP on the network only took a few hours because everything ran through one main gateway, and he wasn't worried about installing any proxy/blocking technology.

Frank immediately saw network results, and found one serious business process problem where unencrypted numbers were included in files being FTPed to a business partner. The rest of his incidents involved individual accidents, and for the most part they weren't losing credit card numbers over the monitored channels.

The content discovery portion took a bit longer since there wasn't a consistent administrative account he could use to access and scan all the servers. Even though they are a relatively small operation, it took about 2 months of full time scanning to get through the data center due to all the manual coordination involved. They found a large number of old spreadsheets with credit card numbers in various directories, and a few in flat files -- especially database dumps from development.

The retail outlets actually took less time than he expected. Most of the servers, except at the largest regional locations, were remotely managed and well inventoried. He found that 20% of them were running on an older credit card transaction system that stored unencrypted credit card numbers.

Remember, this is a 1,000 person organization... if you work someplace with five or ten times the employees and infrastructure, your process will take longer. Don't assume it will take five or ten times longer, though -- it all depends on scope, infrastructure, and a variety of other factors.

–Rich

Database Activity Monitoring & Event Collection Options

By Adrian Lane

'During several recent briefings, chats with customers, and discussions with existing clients, the topic of data collections methods for Database Activity Monitoring has come up. While Rich provided a good overview for the general buyer of DAM products his white paper, he did not go into great depth. I was nonetheless surprised that some people I was discussing the pros and cons of various platforms with, were unaware of the breadth of data collection options available. More shocking was a technical briefing with a vendor in the DAM space who did not appear to be aware of the limitations of their own technology choices ... or at least they would not admit to it. Regardless, I thought it might be beneficial to examine the available options in a little greater detail, and talk about some of the pros and cons here.

Database Audit Logs

Summary: Database Audit Logs are, much like they sound, a log of database events that have already happened. The stream of data is typically sent to one or more files created by the database platform, and may reside at the operating system level or may be contained within the database itself. These audit logs contain a mixture of system resource recordings, transactional events, user events, system events, and other data definitions that are not available from other sources. The audit logs are a superset of activity. Logging can be implemented through an agent, or can be queried from the database using normal communication protocols.

Strengths: Best source for accurate data, and the best at ascertaining the state of both data and the database. Breadth of information captured is by far the most complete: all statements are captured, along with trigger and stored procedure execution, batch jobs, system events, and other resource based data. Logs can capture many system events and DML statements that are not always visible through other collection methods. This should be considered one of the two essential methods of data collection for any DAM solution.

Weaknesses: On some platforms the bind variables are not available, meaning that some of the query parameters are not stored with the original query, limiting the value of statement collection. This can be overcome by cross-referencing the transaction logs or, in some cases, the system tables for this information, but at a cost. Select statements are not available, and from a security standpoint, this is a major problem. Performance of the logging function itself can be prohibitive. Older versions of all the database platforms that offered native auditing did so at a very high cost in disk and CPU utilization- upwards of 50% on some platforms. While this has been mitigated to a more manageable percentage, if not properly set up, or if too much information is requested from high transaction rate machines, overhead can still creep over 15% unless carefully deployed. Not all system events are available.

Network Monitoring

Summary: This type of monitoring offers a way to collect SQL statements sent to the database. By monitoring the subnet, network mirror ports or TAPS, statements intended for a database platform can be 'sniffed' directly from the network. This method will capture the original statement, the parameters, and the returned status code, as well as any data that was returned as part of the query operation. Typically an appliance-based solution.

Strengths: No performance impact to the database host, combined with the ability to collecting SQL statements. On legacy hardware, or where service level agreements prohibit any additional load being placed upon the database server, this is an excellent option. Simple and efficient method of collecting failed login activity. Solid, albeit niche applicability.

Weaknesses: Misses console activity, specifically privileged user activity, against the database. As this is almost always a security and compliance requirement, this is a fundamental failing of this data collection method. Sniffers are typically blind to encrypted sessions, although this is still a seldom used feature within most enterprises, and not typically a limiting factor. Misses scheduled jobs that originate in the database. To save disk space, most do not collect the returned data, and some products do a poor job of matching failed status codes to triggering SQL statements. "You don't know what you don't know", meaning that in cases where network traffic is missed, mis-read or dropped, there is no record of the activity. This contrasts with native database auditing where some of the information may be missing, but the activity itself will always be recorded.

OS / Protocol Stack Monitoring

Summary: This is available via agent software that captures statements sent to the databases, and the corresponding responses. The agents are deployed either in the network protocol stack, or embedded into the operating system to capture communications to and from the database. They see an external SQL query sent to the database, along with the associated parameters. These implementations tend to be reliable, and low-overhead, with good visibility into database activity. This should be considered a basic requirement for any DAM solution.

Strengths: This is a low-impact way of capturing SQL statements and parameters sent to the database. What's more, depending upon how they are implemented, agents may also see all console activity, thus addressing the primary weakness of network monitoring and a typical compliance requirement. They tend to, but do not always, see encrypted sessions as they are 'above' the encryption layer.

Weaknesses: In rare cases, activity that occurs through management or OS interfaces is not collected, as the port and/or communication protocol varies and may not be monitored or understood by the agent.

System Tables

Summary: All database platforms store their configuration and state information within database structures. These structures are rich in information about who is using the database, permissions, resource usage, and other metadata. This monitoring can be implemented as an agent, or the information can be collected by a remote query.

Strengths: For assessment, and for cross referencing status and user information in conjunction with other forms of monitoring.

Weaknesses: Lacks much of the transactional information typically needed. Full query data not available. The information tends to be volatile, and offers little in the way of transactional understanding, or the specific operations that are being performed against the database. Not effective for monitoring directly, but rather useful in a supporting role.

Stored Procedures & Triggers

Summary: This is the original method for database monitoring. Using the database's native stored procedures and triggers to capture activity and even enforce policies.

Strengths: Non-transactional event monitoring and policy enforcement. Even today, triggers for some types of policy enforcement can be implemented at very low cost to database performance, and offer preventative controls for security and compliance. For example, triggers that make rudimentary checks during the login process to enforce policies about which applications and users can access the database, at which time of day, can be highly effective. And as login events are generally infrequent, the overhead is inconsequential.

Weaknesses: Triggers, especially those that attempt to alter transactional processes, are a huge performance cost if in line with transaction processing. Stored procedure and trigger execution, in line with routine business processing, not only increase latency and processing overhead, but can destabilize applications that use the database as well. The more policies are enforced, the worse performance gets. This method of data collection, for use with general monitoring, has been all but abandoned.

Database Transaction Logs

Summary: Database transaction logs are often confused with audit logs, but they are very different things used for different reasons. The transaction logs, sometimes called 'redo' logs, are intended to be used by the database to ensure transactional consistency and data accuracy in the event of a hardware or power failure. For example, on the Oracle database platform, the transaction logs records the statement first, and when instructed by a 'commit' or similar statement, writes the intended alterations into the database. Once this operation has been completed successfully, the completed operation is recorded in the audit log.

Should something happen before this data is fully committed to the database, the transaction log contains sufficient information to roll the database backward and/or forward to a consistent state. For this reason, the transaction log records database state before and after the statement was executed. And due to the nature of their role in database operation, these log files are highly volatile. Monitoring is typically accomplished by a software agent, and requires that the data be offloaded to an external processor for policy enforcement, consolidation and reporting.

Strengths: Before and after values are highly desirable, especially in terms of compliance.

Weaknesses: The format of these files is not always published and not guaranteed. The burden of reading them accurately and consistently is up to the vendor, which is why this method of data collection is usually only available on Oracle and SQL Server. Transaction logs can generate an incredible quantity of data, which needs to be filtered by policies to be managable. Despite being designed to ensure consistency of the database, transaction logs are not the best way to understand the state of the database. For example, if a user session is terminated unexpectedly, the data is rolled back, meaning previously collected statements are now invalid and do not represent true database state. Also, on some platforms, there are offline and online copies, and which copies are read impacts the quality and completeness of the analysis.

Memory Scanning

Summary: Memory scanners are an agent based piece of software that reads the active memory structures of the database engine. On some pre-determined interval, the memory scanning agent examines all statements that have been sent to the database

Strengths: Memory scanning is good for collecting SQL statements from the database. It can collect the original SQL statements as well as all of the variables associated with the statement. They can also understand complex queries and, in some cases, resource usage associated with the query. In some instantiations, they can also examine those statements, comparing the activity with security policy, and send and alert. This can be desirable when near-real time notification is needed, and the delay introduced by network latency when sending the collected information to an appliance or external application is not appropriate. Memory scanning is also highly advantageous on older database platforms where the native auditing introduces a harsh performance penalty, providing much of the same data at a much lower overall cost in resources.

Weaknesses: The collection of statements is performed on the periodic scan of memory. The agent 'wakes-up' according to a timer, and typical timer intervals are 5-500 milliseconds. The shorter the interval the more CPU intensive. As the memory structure is conceptually 'round', the database will overwrite older statements that may still reside in memory but have been completed. This means that machines under heavy load could overwrite statements before the memory scan commences, and miss statements. The faster the execution of the statement, the more likely this is to be the case.

Memory scanning can also be somewhat fragile; if the vendor changes the memory structures when updating the version of the database, the scanner is often breaks. In this case it might miss statements, or it may find garbage at the memory location that it expects to find a SQL statement.

Vendor APIs

Summary: Most of the database vendors have unpublished codes and interfaces that turn on various functions and make data available. In the past, these options were intended for debugging purposes, and performance was poor enough that they could not be used in production database environments. As compliance and audit become a big driver in the database security and DAM space, the database vendors are making these features 'production' options. The audit data is more complete, the performance is better, and the collection and storage of the data is more efficient. Today, these data streams look a lot like enhanced auditing capabilities, and can be tuned to provide a filtered subset while both offering better performance and lower storage requirements. There are vendors who offer this today, and some who have in the past, but this not typically available, and not for all database platforms. Still, many of the options remain unpublished, but I expect to see more of these made public over time and used by DAM and Systems Management vendors.

Strengths: The data streams tend to be complete, and the data collected is the most accurate source of information on database transactions and the state of the database.

Weaknesses: Not fully public, not fully documented, or in some cases, only available to select development partners.

I may have left one or two out, but these are the important ones to consider. Now, what you do with this data is another long discussion. How you process it, how fast you process it, how you check for security and compliance policies, how it is store and how alerts are generated means there is a lot more ways to differentiate vendors that simply the data that they make available to you. Those discussion are for another time.

–Adrian Lane

Will Database Security Vendors Disappear?

By Adrian Lane

Rich and I got into a conversation Friday about database security, and the fate of vendors in this subsegment, in light of recent financial developments. Is it possible that this entire database security sub-market could vanish? Somewhat startled by the thought, we started going down the list of names, guessing who would be acquired, who was profitable, and who will probably not make it through the current economic downturn without additional investment- it seems plausible that the majority of today's companies may disappear.

It's not just that the companies' revenue numbers are slowing with orders being pushed out, but the safety blanket of ready capital is gone, and the vendors must survive a profitability 'sanity check' for the duration of the capital market slowdown. And that becomes even harder with other factors at play, specifically:

Trust. The days of established companies trusting the viability of small security startups are gone. Most enterprises are asking startups for audited financials to demonstrate their viability, because they want to know their vendors will be around for a year or two. Most start-ups' quarterly numbers hinge on landing enterprise clients, with focused sale and development efforts to land larger clients. Startup firms don't keep 24 months of cash lying around as it is considered wasteful in the eyes of the venture firms that back them, and they need to use their money to execute on the business plan. As most startups have financials that make public company CFOs gasp for breath, this is not a happy development for their sales teams or their VCs alike.

Breadth of function. Enterprises are looking to solve business problems, and those business problems are not defined as database security issues. Enterprises customers have trended towards purchase of suites that provide breadth of functions, which can be mixed and matched as needed for security and compliance. The individual functions may not be best of breed, but the customer tends to get pieces that are good enough, and at a better price. Database security offers a lot of value, but if the market driver is compliance, most of vendors offer too small a piece to assure compliance themselves.

Too many choices. I do this every day, and have been for almost 5 years. It is difficult to keep up with all the vendors- much less the changes to their offerings and how they work- and get an idea of how customers perceive these products. Someone who is looking at securing their databases, or seeking alternative IT controls, will be bombarded with claims and offerings from a myriad of vendors offering slightly different ways of solving the same security problems. For example, since 2004 (or their more recent inception) I have been tracking these companies on a regular basis:

Application Security Inc. Lumigent Imperva Guardium Tizor Secu o Sentrigo NGS Embarcadero (Ambeo) Symantec Quest IPLocks

And to a much lesser extent:

Phulaxis Idera DBi (Database Brothers) Nitro Security (RippleTech) SoftTree Technologies Chakra (Korea) Performance Insight (Japan)

For DB security product vendors, there are just too many for a $70-80M market subsegment, with too large a percentage of the revenue siphoned off by ancillary technologies.

Granted, this is just my list, which I used to track for new development; and granted, some of these firms do not make the majority of their revenue through sales of database security products. But keep in mind there are a dozen or so IDS/SIM vendors that have dabbled in database security, as well as the database vendors' log analysis products such as Oracle's Audit Vault and IBM's AME, further diluting the pool. There have been services companies and policy management companies who all have claimed to secure the database to one extent or another. Log file analytics, activity monitoring, assessment, penetration tests, transactional monitoring, encryption, access control, and various other nifty offerings are popping up all the time. In fact we have seen dozens of companies who jump into the space as an opportunistic sortie, and leave quickly once they realize revenue and growth are short of expectations. But when you boil it down, there are too many vendors with too little differentiation, lacking implicit recognition by customers that they solve compliance issues.

Database security has never been its own market. On the positive side it has been a growing segment since 2002, and has kept pace almost dollar for dollar with the DLP market, just lagging about a year behind. But the evolutionary cycle coincides with a very nasty economic downturn , which will be long enough that venture investment will probably not be available to bail out those who cannot maintain profitability. Those who earn most of their revenue from other products or services may be immune, but DB security vendors who are not yet profitable are candidates for acquisition under semi-controlled circumstances, fire sales, or bankruptcy, depending upon how and when they act.

Rich will give his take tomorrow, but although both of us believe strongly in the value of these products, we are concerned that the combination of market forces and economic conditions will really hurt the entire segment.

–Adrian Lane

Behavioral Monitoring

By Adrian Lane

A number of months ago when Rich released his paper on Database Activity Monitoring, one of the sections was on Alerting. Basically this is the analysis phase, where the collected data stream is analyzed in context of the policies that are to be enforced, and the generation of an alert when a policy is violated. In that section he mentioned the common types of analysis, and one other that is not typically available but makes a valuable addition: Heuristics. I feel this is an important tool for policy enforcement- not just for DAM, but also for DLP, SIM, and other security platforms- so I wanted to elaborate on this topic.

When you look at DAM, the functional components are pretty simple: Collect data from one or more sources, analyze data in relation to a policy set, and alert when a policy has been violated. Sometimes data is collected from the network, sometimes from audit logs, and sometimes directly from the database's in-memory data structures. But regardless of the source, the key pieces of information about who did what are culled from the source, and mapped to the policies, with alerts via email, log file entries, and/or SNMP traps (alerts). All pretty straightforward.

So what are heuristics, or 'behavioral monitoring'?

Many policies are intended to detect abnormal activity. But in order to quantify what is abnormal, you first have to understand what is normal. And for the purposes of alerting, just how abnormal does something have to be before it warrants attention? As a simplified example, think about it this way; you could watch all cars passing down a road and write down the speed of the cars as they pass by. At the end of the day, you could take the average vehicle speed and reset the speed limit to that average; that would be a form of behavioral benchmarking. If we then started issuing tickets to passing motorists 10% over or under that average: a behavior-based policy.

This is how behavioral monitoring helps with Database Activity Monitoring.

Typical policy enforcement in DAM relies on straight comparisons; for example, if user X is performing Y operation, and location is not Z, then generate an alert. Behavioral monitoring builds a profile of activity first, and then compares events not only to the policy, but also to previous events. It is this historical profile that shows what is going on within the database, or what normal network activity against the database looks like, to set the baseline. This can be something as simple as failed login attempts over a 2-hour time period, so we could keep a tally of failed login attempts and then alert if the number is greater than three. But in a more interesting example, we might record the number of rows selected by a by a specific user on a daily basis for a period of a month, as well as an average number of rows selected by all users over the same of a month. In this case we can create a policy to alert if if a single user account selects more that 40% above the group norm, or 100% more than that user's average selection.

Building this profile comes at some expense in terms of processor overhead and storage, and this grows with the number of different behaviors traits to keep track of. However, behavior polices have an advantage in that they help us learn what is normal and what is not. Another advantage: as building the profile is dynamic and ongoing, thus the policy itself requires less maintenance, as it automatically self-adjusts over time as usage of the database evolves. The triggers adapt to changes without alteration of the policy. As with platforms like IDS, email, and web security, maintenance of policies and review of false positives forms the bulk of the administration time required to keep a product operational and useful. Implemented properly, behavior-based monitoring should both cut down on false positives and ease policy maintenance.

This approach makes more sense, and provides greater value, when applied to application-level activity and analysis. Certain transaction types create specific behaviors, both per-transaction and across a day's activity. For example, to detect call center employee misuse of customer databases, where the users have permission to review and update records, automatically constructed user profiles are quite effective for distinguishing legitimate from aberrant activity- just make sure you don't baseline misbehavior as legitimate! You may be able to take advantage of behavioral monitoring to augment Who/What/When/Where policies already in place. There are a number of different products which offer this technology, with varying degrees of effectiveness. And for the more technically inclined, there are many good references: public white papers, university theses, patents, and patent submissions. If you are interested send me email, and I will provide specific references.

–Adrian Lane

NitroSecurity’s Acquisition of RippleTech

By Adrian Lane

'I was reading through the NitroSecurity press release last week, thinking about the implications of their RippleTech purchase. This is an interesting move and not one of the Database Activity Monitoring acquisitions I was predicting. So what do we have here? IPS, DAM, SIM, and log management under one umbrella. Some real time solutions, some forensic solutions. They are certainly casting a broad net of offerings for compliance and security.

Will the unified product provide greater customer value? Difficult to say at this point. Conceptually I like the combination of network and agent based data collectors working together, I like what is possible with integrated IPS and DAM, and I am personally rather fond of offering real-time monitoring alongside forensic analysis audits. And those who know me are aware I tend to bash IPS as lacking enough application 'context' to make meaningful inspections of business transactions. A combined solution may help rectify this deficiency. Still, there is probably considerable distance between reality and the ideal. Rich and I were talking about this the other day, and I think he captured the essence very succinctly: "DAM isn't necessarily a good match to integrate into intrusion prevention systems- they meet different business requirements, they are usually sold to a different buying center, and it's not a problem you can solve on the network alone."

I do not know a lot about NitroSecurity and I have not really been paying them much attention as they have been outside the scope of firms I typically follow. I know that they offer an intrusion prevention appliance, and that they have marketed it for compliance, security and systems management. They also have a SIM/SEM product as well, which should have some overlapping capabilities with RippleTech's log management solution.

RippleTech I have been paying attention to since the Incache LLC acquisition back in 2006. I had seen Incache's DBProbe and later DBProbeSec, but I did not perceive much value to the consumer over and above the raw data acquisition and generic reports for the purpose of database security. It really seem to have evolved little from its roots as a performance monitoring tool and was missing much in the way of policies, reporting and workflow integration needed for security and compliance.

I was interested in seeing which technology RippleTech chose to grow- the network sniffer or the agent- for several reasons. First, we were watching a major change in the Database Activity Monitoring (DAM) space at that time from security to compliance as the primary sales driver. Second, the pure network solutions missed some of the critical need for console based activity and controls, and we saw most of the pure network vendors move to a hybrid model for data collection. I guessed that the agent would become their primary data collector as it fit well with a SEM architecture and addressed the console activity issue. It appears that I guessed wrong, as RippleTech seems to offer primarily a network collector with Informant, their database activity monitoring product. I am unsure if LogCaster actually collects database audit logs, but if memory serves it does not. Someone in the know, please correct me if I am wrong on this one. Regardless, if I read the thrust of this press release correctly, NitroSecurity bought RippleTech primarily for the DAM offering.

Getting back to Rich's point, it appears that some good pieces are in place. It will come down to how they stitch all of these together, and what features are offered to which buyers. If they remain loosely coupled data collectors with basic reporting, then this is security mish-mash. If all of the real time database analystics are coming from network data, they will miss many of the market requirements. Still, this could be very interesting depending upon where they are heading, so NitroSecurity is clearly on my radar from this point forward.

–Adrian Lane