Assessment

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

ADMP: A Policy Driven Example

By Adrian Lane

A friend of mine and I were working on a project recently to feed the results of a vulnerability assessment or discovery scans into a behavioral monitoring tool. He was working on a series of policies that would scan database tables for specific metadata signatures and content signatures that had a high probability of being personally identifiable information. The goal was to scan databases for content types, and send back a list of objects that looked important or had a high probability of being sensitive information.

I was working on a generalized policy format for the assessment. My goal was not only to include the text and report information on what the policy had found and possible remediation steps, but more importantly, a set of instructions that could be sent out as a result of the policy scan. Not for a workflow system, but rather instruction on how another security application should react if a policy scan found sensitive data.

As an example, let's say we wrote a query to scan databases for social security numbers. If we ran the policy and found a 9 digit field, verifying the contents were all numbers, or an 11 character field with numbers and dashes, we would characterize that as a high probability that we had discovered a social security number. And when you have a few sizable SAP installations around, with some 40K tables, casual checking does not cut it. As I have found a tendency for QA people to push production data into test servers, this has been a handy tool for basic security and detection of rogue data and database installations.

The part I was working on was the reactive portion. Rather than just generating the report/trouble ticket for someone in IT or Security to review the database column to determine if it was in fact sensitive information, I would automatically instruct the DAM tools to instantiate a policy that records all activity against that column. Obviously issues about previously scanned and accepted tables, "white lists", and such needed to be worked out. Still, the prototype was basically working, and I wanted to begin addressing a long-standing critisicm of DAM- that knowing what to monitor can take quite a bit of research and development, or a lot of money in professional services.

This is one of the reasons why I have a vision of ADMP being a top-down policy-driven aggregation of exsting security solutions. Where I am driving with this is that I should be able to manage a number of security applications through policies. Say I write a PCI-DSS policy regarding the security of credit card numbers. That generic policy would have specific components that are enforced at different locations within the organization. The policy could propagate a subset of instructions down to the assessment tool to check for the security settings around credit card information and access control settings. It could simultaneously seed the discovery application so that it is checking for credit card numbers in unregistered locations. It could simultaneously instruct DAM applications to automatically track the use of these database fields. I instruct the WAF to block anything that references triggering objects directly. And so on. The enforcement of the rules is performed by the application best suited for it, and at the location that is most suitable for responding.

I have hinted at this in the past, but never really discussed fully what I meant. The policy becomes the link. Use the business policy to wrap specific actions in a specific set of actionable rules for disparate applications. The policy represents the business driver, and it is mapped down to specific applications or components to enforce individual rules that constitute the policy. A simple policy management interface can now control and maintain corporate standards, and individual stakeholders can have a say in the implementation and realization of those policies "behind the scenes", if you will. Add or subtract security widgets as you wish, and add a rule onto the policy to direct said widgets how to behave.

My examples are solely around the interaction between the assessment/discovery phase, and the database activity monitoring software. However, much more is possible if you link WAF, web app assessment, DLP, DAM, and other products into the fold. Clearly there are a lot of people thinking along these lines, if not exactly this scenario, and many are reaching to the database to help secure it. We are seeing SIM/SEM products do more with databases, albeit usually with logs. The database vendors are moving into the security space as well and are beginning to leverage content inspection and multi-application support. We are seeing the DLP vendors do more with databases, as evidenced by the recent Symantec press release, which I think is a very cool addition to their functionality. The DLP providers tend to be truly content aware. We are even seeing the UTM vendors reach for the database, but the jury is still out on how well this will be leveraged. I don't think it is a stretch to say we will be seeing more and more of these services linked together. Who adopts a policy driven model will be interesting to see, but I have heard of a couple firms that approach the problem this way.

You can probably tell I like the policy angle as the glue for security applications. It does not require too much change to any given product. Mostly an API and some form of trust validation for the cooperating applications. I started to research the policy formats like OVAL, AVDL, and others to see if I could leverage them as a communication medium. There has been a lot of work done in this area by the assessment vendors, but while they were based on XML and probably inherently extensible, I did not see anything I was confident in, and was thinking I would have to define a different template to take advatage of this model.

Food for thought, anyway.

–Adrian Lane

ADMP and Assessment

By Adrian Lane

Application and Database Monitoring and Protection. ADMP for short.

In Rich's previous post, under "Enter ADMP", he discussed coordination of security applications to help address security issues. They may gather data in different ways, from different segments within the IT infrastructure, and cooperate with other applications based upon the information they have gathered or gleaned from analysis. What is being described is not shoving every service into an appliance for one stop shopping; that is decidedly not what we are getting at. Conceptually it is far closer to DLP 'suites' that offer endpoint and network security, with consolidated policy management.

Rich has been driving this discussion for some time, but the concept is not yet fully evolved. We are both advocates and see this as a natural evolution to application security products. Oddly, Rich and I very seldom discuss the details prior to posting, and this topic is no exception. I wanted to discuss a couple items I believe should be included under the ADMP umbrella, namely Assessment and Discovery. Assessment and Discovery can automatically seed monitoring products with what to monitor, and cooperate with their policy set.

Thus far the focus through a majority of our posts has been monitoring and protection, as in active protection, for ADMP. It reflects a primary area of interest for us as well as what we perceive as the core value for customers. The cooperation between monitored points within the infrastructure, both for collected data and the resulting data analysis, represents a step forward and can increase the effectiveness of each monitoring point. Vendors such as Imperva are taking steps into this type of strategy, specifically for tracking how a user's web activity maps to the back end infrastructure. I imagine they will come up with more creative uses for this deployment topology in the future.

Here I am driving at the cooperation between preventative (assessment and discovery in this context) and detective (monitoring) controls. Or more precisely, how monitoring and various types of assessment and discovery can cooperate to make the entire offering more efficient and effective. And when I talk about assessment, I am not talking about a network port scan to guess what applications and versions are running- but rather active interrogation and/or inspection of the application. And for discovery, not just the location of servers and applications, but a more thorough investigation of content, configuration and functions.

Over the last four years I have advocated discovery, assessment and then monitoring, in that order. Discover what assets I have, assess what my known weaknesses are, and then fix what I can. I would then turn on monitoring for generic threats I that concern me, but also tune my monitoring polices to accommodate weaknesses in my configuration. My assumption is that there will always be vulnerabilities which monitoring will assist with controlling. But with application platforms- particularly databases- most firms are not and cannot be fully compliant with best practices and still offer the business processing functions the database is intended for. Typically weaknesses in security that are going to remain part of the daily operation of the applications and databases require some specific setting or module that is just not that secure.

I know that there are some who disagree with this; Bruce Schneier has advocated for a long time that "Monitor First" is the correct approach. My feeling is that IT is a little different, and (adapting his analogy) I may not know where all of the valuables are stored, and I may not know what the type of alarm is needed to protect the safe. I can discover a lot from monitoring, and it allows me to witness both behavior and method during an attack, and use that to my advantage in the future. Assessment can provide tremendous value in terms of knowing what and how to protect, and it can do so prior to an attack. Most assessment and discovery tools are run periodically; while they may not be continuous, nor designed to find threats in real time, they are still not a "set and forget" part of security. They are best run periodically to account for the fluid nature of IT systems.

I would add assessment of web applications, databases, and traditional enterprise application into this equation. Some of the web application assessment vendors have announced their ability to cooperate with WAF solutions, as WhiteHat Security has done with F5. Augmenting monitoring/WAF is a very good idea IMO, both in terms of coping with the limitations inherent to assessment of live web applications without causing disaster, but also the impossibility of getting complete coverage of all possible generated content. Being able to shield known limitations of the application, due either to design or patching delay, is a good example of the value here.

In the same way, many back-end application platforms provide functionality that is relied upon for business processing that is less than secure. These might be things like database links or insecure network 'listener' configurations, which cannot be immediately resolved, either due to business continuity or timing constraints. An assessment platform (or even a policy management tool, but more on that later) or a rummage through database tables looking for personaly identifiable information, which is then fed to a database monitoring solution, can help deal with such difficult situations. Interrogation of the database reveals the weakness or sensitive information, and the result set is fed to the monitoring tool to check for inappropriate use of the feature or access to the data. I have covered many of these business drivers in a previous post on Database Vulnerability Assessment. And it is very much for these drivers like PCI that I believe the coupling of assessment with monitoring and auditing is so powerful- the applications help compensate for each another, enabling each to do what it is best at, passing off coverage of areas where they are less effective.

Next up, I want to talk about policy formats, the ability to construct policies that apply to multiple platforms, and how to include result handling.

–Adrian Lane