Assessment. In the last post I mentioned that I believe that Rich Mogull’s number for the size of the Database Activity Monitoring market is about right; about $70M. Over the last two years, the Request For Information & Request For Procedure documents I have reviewed for database security, Assessment forms a full 60% of the overall requirements. The majority of the requirements. My sampling size is about 40 such documents, so I believe this is a large enough number to be meaningful. DAM, encryption, audit and the other items are in the remaining 40%. More still, Monitoring provides critical value on a select number of critical servers, but assessment provides value across all of databases in an organization.
Yet if DAM is at $70M, and Assessment is still in the $15-20M range, do you sense an issue here? I do not think that this is an issue of pricing, but a mismatch in vendor offerings & customer requirements. It is also an issue of perception as many companies thought that their assessment vendor was already providing database assessment. To a degree, they were, but the level of detail that is provided is insufficient. Is this a limiting factor for success in the eyes of the customer? You betcha! If the solution does not meet the requirements as the customer perceives them, then the adoption rate will be lower.
Policies. I am at odds with many people on this one, but I have discussed this with many vendors and a few customers, so I still maintain this is the direction we are going to be heading: Policies as a security and compliance consolidator.
What do I mean? I mean that whatever security widget you sell today becomes a component in a larger framework. The data it collects, the data it filters, the data it stores, how long, and what gets sent off to other applications will all be specified by a policy somewhere. That policy will govern several security and reporting applications, and those policies will be geared toward meeting the business requirements in terms of function, compliance, regulatory requirements, service levels and just about every other operational vector within IT.
Why do I say that? Because businesses have specific policies that they need fulfilled. The people who know about these requirements and manage these requirements are not domain experts. They do not know and do not want to know about firewall rules, do not want to know how SAP connects to a database, they just want to know their policy has been implemented.
Let’s take this from the other direction. Security challenges are complex. I typically find that most customers have not performed a threat analysis or a risk analysis, and they are not even sure where to start. The scope of the problem set is daunting. So it is based upon this that the simpler, less complex concepts of a policy, and let the domain experts decide behind the scene how the policy is enforced. I see this at larger companies all of the time when they create specifications on how a network is to be secured, how a database is to be secured, how an application is to be secured. But the blending of technical implementation and business policy has little integration, and I am claiming that these policies and their associated implementation creates a fine bridge between the technical and business stakeholders.
Virtualization. I cannot think of any single thing that will affect database security offerings more in the next couple of years than virtualization. One simple point I want to make. The first is your network will probably be virtualized along with your servers. Your selection of a DAM technology – or any external technology for that matter – may stop working in a virtual environment if there is no wire or no mirror port to hook into. And it certainly will have an impact to discovery and assessment methodologies.
Dashboards. I hear about Dashboards a lot. A lot. I think whenever someone does not really know what the next trend in XYZ technology or security widget, that a Dashboard is the next thing that the customer needs to truly realize their value potential.
I have been hearing this in the database security realm as of late, and please, just stop it! Look closely at the requirements for various regulatory (e.g. Sox) and compliance (e.g. PCI) challenges. Look at the frameworks that are out there like Cobit, COSO, SCAP or whatever guide you choose. Discovery and preventative controls are put into place, and detective controls to augment enforcement. Separation of duties requires that the roles be separate and distinct. Different policies, collecting different data, filtered and reported in a different way for each stake holder. What is more, I may not want all of the collected data stored in a single location as that in and of itself may be a problem. Access control resolves that you say? Different views enforce roles? Groups and roles can handle this? Ha! Make no mistake, reports are one of the principle values provided to the stake holders of data and application security, audit and compliance. But the whole point in providing separation of duties means that there is not a central view and probably not a central repository of all activity as that defeats the purpose. Generic ‘hub’ or ‘vault’ models that serve all audiences are probably not the right method.
Comments