Information Centric Security

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. 

Network Security Podcast

Martin Mckeay and Rich Mogull were kind enough to invite me to their network security podcast.  We had a nice discussion on Privacy, Information Centric Security and a few other topics.  You can check it out here. 

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. 

RIAA and Music Piracy

 

I ran across this article on RIAA this morning attempting to police piracy. Once again I am left shaking my head at the stupidity of this entire piracy circus.

Most industries have competition, which forces down prices and promotes innovation. The music industry clearly has no such drivers, and innovation is someone we absolutely do not see. If organizations like RIAA put half as much time into considering a business model that works with the Internet rather than trying to punish the people interested in their product they would be growing rather than being in decline.

And while I am on the topic, this cartoon video completely captures my feeling on the subject. Yes, RIAA, you need to heed this advice.

What does this have to do with security? Plenty.

I wonder if RIAA employees get spam? Have you seen how many ways they are to spell (or mis-spell) Viagra? How many ways and how easily I can convey the meaning without actually saying it? 'Massive Pole', 'Make Her Happy', 'Top Rated Enlarger', '4 free pills' and 'Vi-Ag-Rah' got through one spam filter just in the last four hours.  So if RIAA is looking for common file names of songs, it will only take a matter of minutes until all this content is relabeled and reformatted and become invisible to ‘Media Sentry’. This is a joke. I can only assume that this is a PR exercised to waste money and further blame the consumer for the music industry’s lack of commercial success.  It will not stop piracy. It will not detect most piracy.

Why would I want to buy CD full of schlock if I all want is the one song? In this day and age where bands are seldom the organic garage band that creates something special and unique, but rather a ‘package’ of faces and sounds out of mind of recording executives, one good song is all we get. So why am I going to pay 8, 12, 20 or more dollars for garbage? And on top of that I have to deal with what I call ‘the packaging penalty’, or trying to get the CD or DVD out of its packaging without damaging the cover art or media. It’s just easier for me to record it off the radio. Or as most people do, pull a copy from the Internet and create a low-rez copy that they will listen to a couple times and delete.

A friend of mine has been going through a process of acquiring a complete catalog of a couple of female jazz singers that we both like. You would think that this is a simple process of ordering the recordings on CDs, DVD, SACD, .WAV or whatever medium is your preference. Not so fast. It turns out that not all of the distributions are created equally. We have found some cases where the media itself varies greatly in recording quality, but even more troubling is the song lists are different!  The DVD-A may contain three unique songs, the DVD a song and a video, and the SACD a different song appended yet again. We have even found cases where the CDs sold to some of the big box retailers differ from chain to chain.

Sure, they would like me to buy the same copy of music on the same medium as many times as I could afford to, and even better, buy it on every medium they can think of creating just so I can get the last song or two. This model does not work for the consumer and demonstrates how some companies have lost perspective of their value. Rather than looking to provide a product people want to buy, they are looking at news ways to mine value from intellectual property. Two very different concepts.

The last point I wanted to make is the use of the word ‘customers’, as everyone I have ever met who rips albums is also a collector. They buy when they can, and the rip when it makes economic sense to do so. I do not know anyone who is so cash-poor that they are unable to purchase songs that they really want. They are in fact customers, but they are not simply going to throw money away. As is a recurring theme in many of Bruce Schneier’s articles, economy is often a much larger factor in security than technology.

The recording industry has created a disposable medium and disposable content. They have now trained their customers to treat it as throw away background music, with the concepts of High Fidelity and cover art becoming all but extinct. Yes, I am saying that piracy is to a very large extent a byproduct of recording industry business practices. If they want to see increased revenue, they need to price, package and distribute it such that it is easier to buy than copy, or provide a higher perceived value for the packaged product. If they continue to punish customers, the recording industry will quite literally dis-intermediate itself and will succumb to a more efficient and more cost effective delivery of music.   

 

Data Security: Threats and Objectives.

I was on a rant today because I was having a discussion about Information Centric Security, and someone has said that the implementation I was proposing promoted viruses and malicious code. The assertion is the packetized implementation of ICS I endorsed hid the contents from the user who received it, and therefore all sorts of malware could be hidden within the packets and ‘jump out’ at unsuspecting users. That is a great point, I do concede; completely wrong in two assumptions, but a good point that enforces my point for the need of two-way (or more) trust establishment. It also underlines the issue of what we should and should not do with the data we receive. The data we receive, who sent it and what their intentions were are assumed, and assumed to be good intentioned. Information Centric Security is meant to help assess not only Identity and proper use, but also help address the grotesque lack of trust establishment. We are far too trusting of other people, web sites, downloads, and in general, any free stuff that comes our way. And after spending the last few days with an infected DNS server, I don't even trust our infrastructure. Data needs to protect itself, and the users need  to protect themselves.

I have been making several assertions in recent posts that an Information Centric Security inherently addresses several problems we typically face with today’s security products simply by the nature of this security model. I realize I should back these statements up with some specific examples to further elucidate what the heck it is I am talking about. So this is this the first of several posts on that subject.  I want to start with an outline of some of the typical attacks and the associated objectives of the attackers to provide an overview of the ‘threatscape’. I will talk about how to apply the Information Centric model to one or two common tasks, and then talk about what value an ICS model provides in those contexts. I will also make mention to some of the things that ICS does not help with or problems that it does not solve.

So what are we trying to do? Secure data. That begs the question ‘secure it from what’, which becomes a much longer and more difficult discussion, but I will attempt to tackle some of the major points here. This is an overview list of the types of threats that I will be considering as this will help frame the attacks to be considered.  I have broken objectives and attacks into two separate lists I broke this into two lists to better illustrate a many to many relationship of attacks and threats, as well as the complexity of information security challenges.

So what are some of the hacker’s objectives when it comes to data security?

Theft of data.

Alteration of data.

Pretty much, that is it. I am making the assumption that if data can be viewed, it can be copied. We have been working hard for the last two decades to make data available, and pretty much every medium I can convey data on has a way for me to siphon it off. And I also assume that these two goals can be accomplished by subversion of the processing infrastructure or machine for the purpose of:

Alter an event or processing

Altering the functionality of a machine

Theft of activity

Use infrastructure to attack another machine

This is not an exhaustive list, but the major ones that popped into my mind. Feel free to add more and I will attempt to discuss in future posts.  I will note that there are many other objectives for hackers, for example denial of service attacks, but my intention is to limit this discussion to data security and not general infrastructure security challenges.  For Information Centric Security, these first two items are the challenges we are trying to address. Each of the above objectives they can accomplished in a number of different ways. Given these objectives, how might a hacker go about it?

Insider attacks: Use of the approved platforms, applications and credentials to either steal or alter data.

Network attacks or theft of data in motion: Network monitoring or ‘sniffing’, ‘man in the middle’ attacks and the like.

Data at Rest: gaining access to a file server, console or backup media and other forms of direct access to data at rest.

Quasi Data at Rest:  Databases. These repositories have a unique set of challenges given the myriad of ways to execute functions on data, and typically require some degree of inspection of the data to perform reporting and analysis functions.  And there are a myriad of attacks such as bypassed credential checks, SQL Injection, Buffer Overflows, exercising external code inks, data leakage and more. 

Data in process:  Applications. As with databases, web applications and large footprint enterprise applications like SAP offer a myriad of exploits.

Platform: Use of remote sessions, viruses or other code that provides a gateway onto the system, OS or application that houses/processes the data.

Physical attacks: This could run the gamut from looking over someone’s shoulder, Tempest attacks (quasi-physical), stealing a computer  to holding a gun to someone’s head. I am going to ignore this as section to discuss as a) it is somewhat outside the topic of computer security and is more of a traditional security problem, and  as well as b) this typically devolves into an insider attack.

My intention is not to create a definitive list, but rather cover the bulk of objectives and threats, and discuss how Information Centricity addresses some of the problems. This is a long enough list that it is going to take some time to address.  In the next post, I am going to discuss two examples of how someone might choose to implement ICS, and then follow that up with a discussion of how ICS deals with some of the threats brought up in this post.