Information Centric Security

What's My Motivation?

(Cross post from Securosis ... which I will do from time to time when a post has relevance to InfoCentric security) -Adrian

Or more appropriately, "Why are we talking about ADMP?" In his first post on the future of application and database security, Rich talked about Forces and Assumptions heading us down an evolutionary path towards ADMP. I want to offer a slightly different take on my motivation, or belief, in this strategy.

 

One of the beautiful things about modern application development is our ability to cobble together small, simple pieces of code into a larger whole in order to accomplish some task. Not only do I get to leverage existing code, but I get to bundle it together in such a way that I alter the behavior depending upon my needs. With simple additions, extensions and interfaces, I can make a body of code behave very differently depending upon how I organize and deploy the pieces. Further, I can bundle different application platforms together in a seamless manner to offer extraordinary services without a great deal of re-engineering.

 

A loose confederation of applications cooperating together to solve business problems is the typical implementation strategy today, and I think that the security challenge needs to account for the model rather than the specific components within the model. Today, we secure components. We need to be able to 'link up' security in the same way that we do the application platforms (I would normally go off on an Information Centric Security rant here, but that is pure evangelism, and a topic for another day).

 

I have spent the last four years with a security vendor that provided assessment, monitoring, and auditing of databases and databases specifically.

Do enough research into security problems, customer needs, and general market trends; and you start to understand the limitations of securing just a single application in the chain of events. For example, I found that database security issues detected as part of an assessment scan may have specific relevance to the effectiveness of database monitoring. I believe Web Application security providers witness the same phenomenon with SQL Injection as they may lack some context for the attack, or at least the more subtle subversions of the system or exploitation of logic flaws in the database or database application. A specific configuration might be necessary for business continuity and processing, but could open an acknowledged security weakness that I would like to address with another tool, such as database monitoring.

 

That said, where I am going with this line of thought is not just the need for detective and preventative controls on a single application like a web server or database server, but rather the Inter-application benefit of a more unified security model. There were many cases where I wanted to share some aspect of the database setup with the application or access control system that could make for a more compelling security offering (or visa-versa, for that matter).

 

It is hard to understand context when looking at security from a single point outside an application, or from the perspective of a single application component. I have said many times that the information we have at any single processing node is limited. Yes, my bias towards application level data collection vs. network level data collection is well documented, but I am advocating collection of data from multiple sources. A combination of monitoring of multiple information sources, coupled with a broad security and compliance policy set, would be very advantageous. I do not believe this is simply a case of (monitoring) more is better, but of solving specific problems where it is most efficient to do so. There are certain attacks that are easier to address at the web application level, and others best dealt with in the database, while others should be intercepted at the network level. But the sharing of policies, policy enforcement, and suspect behaviors, can be both more effective and more efficient.

 

Application and Database Monitoring and Protection is a concept that I have been considering/researching/working towards for several years now. With my previous employer, this was a direction I wanted to take the product line, as well as some of the partner relationships to make this happen across multiple security products. When Rich branded the concept with the "ADMP" moniker it just clicked with me for the reasons stated above, and I am glad he posted more on the subject last week. But I wanted to put a little more focus on the motivation for what he is describing and why it is important. This is one of the topics we will both be writing about more often in the weeks and months ahead.

DEMIDS and Database Misuse Detection

DEMIDS is an early paper on how to detect misuse of a database (warning: PDF loads slowly).  As an overview, the paper describes a system where misuse is ‘detected’ by the use of a distance function.  It attributes a set of tables or database functions as the normal domain of a user, and everything that the user accesses outside of that specified domain has some distance factor associated with it.  Tables in other schema’s are viewed as being a certain distance outside of that domain, and tables in different database further still.  The further away a resource is, the more likely there is misuse.  It is a basic assumption that the users are sufficiently privileged to perform the access.  And it is inherent with the methodology described that the system is closely coupled to the database itself, and it performs the work of detection locally. 

While we have seen many papers on Intrusion Detection and Prevention for the general case, this was one of the first papers that I had seen written specifically for database misuse detection.  I mean two things by this, insiders vs outsiders, and using database internals as opposed to external information.  And as such, almost every patent application in the area of heuristic or dynamic database monitoring has to account for this work.   Database misuse detection through Heuristics is a somewhat tough problem to crack.  It’s not that we do not have the technology and the ability to detect the problems, we do. 

By looking at data and meta-data, examining objects and distance, by looking at users and time, by looking at history and present activity, by looking at location and function, and any combination thereof, we can actually do a really good job at detection.  The problems are two-fold, in that the way we use databases has actually changed considerably over the last 5 years, and that every company uses databases in slightly different ways.  That means that both user activity changes and the business rules change. It means that deployment of a good heuristic system is more expensive as the threat model is more complex, but also that a behavior based algorithm that can adapt to environmental changes require less tweaking and have a longer shelf life than.  Technically speaking, DEMIDS is a behavior based detection algorithm.

I have probably spent more time studying this paper than its author spent writing it at this point.  I have spent months with various patent attorney’s attempting to explain the distance function and how this differs from other patents, applications and prior art.  And months more educating patent examiners what this really means and how it differs from other claims.  That is because they read this paper and they think they know what it is doing and what is being described.  Pre-conceived notions are a powerful thing.  And my protestations to the contrary are met with skepticism.  Then I force them to work through the equations … a mathematical proof if you will … and they get random garbage rather than the numbers they were expecting.  When I explain again how the distance calculation actually works and produce an expected numbers, they can barely believe it.  Believe it.  What is going on here is subtle and clever, albeit not particularly useful in today’s world.  Still, anyone out there who is considering database misuse detection algorithms, this paper needs to be in your repertoire.  Any patent work you do in this area, the examiners will send this work back to you as prior at and ask you to explain how you are novel.  

 

I bring this up to illustrate the change in database usage has evolved considerably since 2000, as has our mindset on database security.  It is a testament to how far we have come in this industry as a whole; how databases are used, the volume of information moving through them, the number of users and roles, and how we distribute and share data.   When this paper was written the concept was well ahead of its time, but still has been eclipsed because of the vast amount of research and development into this field of expertise.  Typical uses of the database, like anonymous connection pools or mirroring are not appropriately accounted for.  Still, it is really worth a read to understand some of the early approaches to the problem of detecting authorized (re: insider) database misuse if this is a subject that interests you.

More comments on database security

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.

Database Security Market.

Howdy!  Hola! Good Morning!  I had a good holiday.  Feeling good.  Five days off, at home, with wonderful weather will do that.  Plus there are a lot of changes in my life and a bunch of new professional opportunities that are really quite exciting.  So I am feeling better than good.  Unchained!  Even a little sassy.  Anyway, let’s get right into this post, shall we?

For those of you who know me, you know that I have been in data and database security for over 12 years now.  As CTO with various firms that develop security software, as a consulting security practitioner, and as a CIO.  And lately I have been doing a lot of research.  Too much.  Market trends, acquisitions, obscure executive quotes, public company PowerPoint presentations, how marketing organizations spin their value, PR and how they create image, blogs, face to face meetings, product analysis, analyst reviews and just about everything I can get my hands on.  

Lately a couple of things have happened.  First, a lot of research has illuminated a couple indicators within the database security industry.  Second, I have discovered some hard evidence to support a couple of quiet predictions that I have had for a while.  Finally, I find myself unburdened of several responsibilities so I can talk more freely about all of the above.  This has all lead me to a new series of posts on this blog that I will be making on the database security industry at large.  In this post, acquisitions and market sizing.

I am making the prediction that by year’s end, three of the top four database security companies will be acquired.   In fact, I will bet that 5 will be gone within an 18 month window of time.  There are a dozen firms or more for those of you who do not watch this segment on a daily basis.  And they will be gobbled up by larger firms.  Yes, some have been predicting this for 2 years.  This is the first time that I have made this statement because the market is no longer nascent, and there is genuine customer demand.  A lot of research and a lot of conversations, and I am convinced this we will no longer be waiting as these mergers & acquisitions will happen.  It does not require a huge leap of faith when you realize that there are about a baker’s dozen established firms in the areas of security, systems management and database management that have been circling and investigating the market space for a year or so.  But the music is about to stop in this game of musical chairs, and several key players who could genuinely use database security in their portfolio will be left out of the mix.  Yes, giant systems management & security vendor, I am talking about you.  Plus a few others who will wait until they feel the market size justified the investment, only to find that they waited too long. 

Second, the market size of database security is about to double.   Rich Mogull posted a comment last week on the Database Activity Monitoring size at $70M for 2007, plus or minus $20M.  I believe his number is accurate, but does not include assessment, which is half again as large, so I think 70 is a safe number. I am predicting $130M by the end of 2009.  I will leave auditing out of the picture for now as predicting its size, impact and customer demand is more black art than science.  As these components are not always tracked as a single offering as they should be, rather as fragments, the market size has the illusion of being smaller than it is.  Regardless, with the onset of the acquisitions, this market will quickly eclipse DLP.   

I do not believe I am not shimmying out on a slender branch here as growth of this segment should not be a big mystery.  The current group of players are small firms with small sales teams and limited reseller relations.  These products are about to be sold by an order of magnitude larger global sales forces, and quadrupling the number of customers who see these products.  The acquiring firms will lend additional credibility to the technology, bundle it with existing products that (hopefully) create a more compelling solution, and the professional services that are often a required step in their deployment.  And let’s face it, database monitoring, auditing, prevention and assessment are not considered a necessity by most enterprises today.  But that is changing rapidly as companies realize that AV, Access Control & IDS try to keep outsiders out, rather than being geared to protect sensitive information.  And where is a lot of the sensitive information stored that needs to be protected?  Today’s players have proven the value of these solutions, and now the larger companies will step in and make the market.

In future posts I will discuss and analyze these as they happen.  I will make comments on the business value proposition, the fit of the technology within the acquiring company’s existing product offerings, and provide analysis of strategic vision.  Later.  Next up will be product directions, roadmaps and synergies. 

Stored Procedures and SQL Injection

There is a nice post by Michael Howard on a couple simple steps to help mitigate SQL Injection attacks over on the Security Development Lifecycle blog this morning.  Simple steps that are effective by reducing the avenues of attack or reducing the assumptions of trust between the application and the database. However wanted to add a couple of comments onto this subject that I believe add some value to the suggestions he made. Specifically:

-Don't allow create/modify procedure permissions

-Use a dedicated, non-admin database user account

-Don't use external stored procedures

The first comment I wanted to make is on “Use SQL Execute Only Permissions” and “Use Stored Procedures”. This is absolutely correct. Not only is there typically a performance benefit, there is some built in parameter screening in the RDBMS that checks consistency and type.  The use of stored procedures is to combat injection of ad-hoc SQL statements. And the additional suggestion of using ‘execute only’ permissions on procedures is because I want to make sure that the stored procedures that I have cannot be replaced or altered by the SQL Injection attack. I do not want an attacker using SQL Injection to read my existing code, but this is a secondary consideration. The attacks I see could usually care less what logic you have, but really want to introduce their own functionality, either by introducing an ad-hoc query or by introducing a stored procedure. Use of stored procedures mitigates the first issue, and ‘execute only’ stops the alteration of the code. I am adding that you want to periodically check that the database user does not have create procedures permissions in their role in addition to the existing stored procedures being execute only. This combats the ‘Injection’ of new stored procedures to launch additional attacks.

There is another angle on this story that I would like to point out. I love the introduction to this post when Michael states “If you have a Web server (doesn't matter what type), and it's hooked up to a database (doesn't matter what type) you need to go in and review your code that performs the database work”. Absolutely! They go hand in hand. But the remainder of the post goes on to discuss deterrence and security from the web application developer’s perspective. That’s not a criticism, but I want to help illustrate that SQL Injection is a database attack made through a web application. 

But database administration and database platform security is oft left out of the conversation, and it should not be, as there are other simple tips that have similar benefits to helping reduce the possibility of SQL Injection. I have made some comments to several of the OWASP & WASC members here in San Jose, and that given the symbiotic relationship between database platforms and web application, may want to include some additional database platform security discussions with the application security discussions that they have today. For example, I had commented in a previous post that the entire attack could be negated by running the database administered under a different user account than the web application administrator. That is a very simple step to address a common abuse of trust relationships to carry out an attack.  So my second suggestion is use a dedicated database user for the web application account that does not have administrative rights.

My final suggestion on the topic of stored procedures has to do with external stored procedures. Most relational databases have the option of using external links and stored procedures to reference OS level code. This is in essence a program outside the database that can either run OS level functions, and often can use database functionality as well. I do not want to go into a long discussion here about the types of attacks that can be conducted through external code, or the dozens of issues pertaining to permissions, but simply comment that in using stored procedures for web applications, resist the urge to use external stored procedures or links. They can be very dangerous, and I typically advocate checking that the user rights do not include use of these external resources.

Most web developers look at a document like this one and tend to tune out.  So thanks to Michael for posting simple and effective SQL Injection prevention/mitigation steps for web applications. 

Oracle Critical Patch Update for April 2008

Comments on database security notice.

 

I just received my notification for the April 2008 security update from Oracle. Some information can be found here, and scroll down to the ‘Oracle Database Risk Matrix’. Unlike some of my peers in the industry, I have usually been pretty happy with the patches that come from Oracle for security. What is more, they tend to release security patches on a very regular schedule, so the DBA in me appreciates this consistency both because Oracle has trained me to look for it, and subsequently can plan the deployment of the patch into my normal workflow.

What bugs me is the lack of information pertaining to the threat, or what the real issue is, when looking at the contents of the security patches. Why the lack of details? I am not too sure if this is because they have the mindset that they do not want to reveal too much information to would-be hackers, which is a laughable assumption, or if this is some legal mumbo-jumbo to reduce liability. Regardless, it’s annoying. I want to understand the threat so I can take appropriate action; for example I may not agree with Oracle’s threat assessment and desire an interim workaround prior to deploying a patch. Or I might alter my normal deployment schedule if I deem the risk too great to delay. But you cannot assess the urgency of the patch, or take appropriate action if you have no clue as to the nature of the threat, so in fact the customer has little information that is helpful.   ‘Critical Patch’ is only marginally more informative than ‘Threat Level: Orange’.

More important to this discussion: Oracle does not assign risk for your business. You do. Even if Oracle could produce a satisfactory definition for “Base Scores”, (here is a blog post that does a better job than the official Oracle documents) it is irrelevant to understanding the threat to your business. A database is not a standalone entity; rather it can have multiple audiences, applications, processes and users. If you’re going to provide a ‘Risk Matrix’, you need to include some information that is pertinent to the risk, not a list of code areas affected. Two completely different concepts that they have merged together as if they were equivalent. 

I don't think you need to jump out and install this ASAP, despite what some of the sensationalistic journalism based this patch release. The Oracle advisory states “1 of these database vulnerabilities may be remotely exploitable without authentication, i.e. may be exploited over a network without the need for a username and password.” But the ‘Risk Matrix’ lists Oracle 11.1.6 as the version affected. Even if the Oracle Base Score was considered a ‘10’, a complete system compromise, does this have an impact to you? As 11 is the only release affected, making the comments about databases being a ‘Sitting Duck’  are a little overblown IMO. I am unaware of any corporate client of ours who has gotten Oracle 11 out of the lab and into production, so the scope of this threat is minimal.

What does concern me is when areas of the code like DBMS_CDC_UTILITY and SYS.DBMS_AQ which are complex and have had vulnerabilities over time. Hackers tend to learn the nuances about specific modules and then attack them over and over again, thus why we see a chain of vulnerabilities against specific modules over time. But those modules tend to be the ones that were not designed with security in mind and why they were targeted to begin with.

I will post more once I get a chance to review the patches more thoroughly, so while I recommend you apply it when you get a chance, I do not see anything that is a huge hair on fire threat.