Information Centric Security

Adrian Lane joins Securosis!

Believe it or not, I'm going to work with Rich Mogull at Securosis. Worst yet, I'm excited about it!

On the outside looking in, Rich and I have dissimilar backgrounds. I have been working in product development and IT over the last ten years, and Rich has been an analyst and market strategist. But during the four years I have known Rich, we have shown an uncanny similarity in our views on data security across the board. We are both tech guys at our core, and have arrived at the same ideas and conclusions about security and what it will look like in the years to come.

As our backgrounds are both diverse and complimentary, my joining Securosis will facilitate taking on additional clients and slowly expand the types of services provided. I will contribute to strategy, evaluations, architecture and end-user guidance, as well as projects that involve more ‘hands-on’ assistance. I will also be making contributions to the Blog on a regular basis as well. 

Anyway, I am really looking forward to working with Rich on a daily basis. And yes, before Amrit Williams has a chance to ask, I am a card carrying NAHMLA (North American Hoff-Mogull Love Association) member. We may even sell Polo Shirts on the web site.

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.

ICS Example No. 2

A few posts back I provided one of the simplest examples I could come up with for Information Centric Security.  To recap, consider having a PGP plug-in to an email tool like Outlook or Eudora.  The outbound email you send is encrypted with the receiver’s public key, and signed by your private key to ensure authenticity.  Conversely inbound email is encrypted with your public key, digitally signed by the sender.  Consider some of the advantages of this that a) your email is stored locally in a safe form, b) your email is reasonably safe in transit, c) you can verify the email came from the person on the ‘From’ line.  There are certainly secondary advantages in filtering spam, not having to worry about lost backups, in transit alteration, and can still communicate with other non-secured persons and applications at the users discretion just as you do today. 

 I also wanted to discuss a slightly more complex example to illustrate how Information Centric Security can solve other problems. 

Let’s say I am on my laptop at some coffee shop, using their 'secure' wireless hackspot.  I want to buy a book, so I go to Amazon, or some such site.  And they want to make this easy for me, the customer, to very quickly make my purchases with as little effort as possible.  A very easy process as I simply select a book after browsing the site, choose my shipping and click ‘Give us $$$ right now’ button.  They store my credit card whether I want them to or not, so no need for me to enter that data again after my first purchase.  I assume that I am directly connected to the merchant and that the ‘HTTPS’ and little lock symbol means something.  The vendor is a big, trustworthy company and does this type of thing all the time so I assume they must secure all of these credit card numbers, right?  And from the Identity perspective, the vendor is pretty sure I am me.  No password required, because the cookie on my machine told them I was me and cookies don’t lie.

What don’t I like about this?  I don’t like the merchant storing my credit card number.  There really is no good reason for them to have it to clear payment, and so it invites liability to store it.   I don’t like that there is no password required.  Even if they did want a password, given I am using my laptop at the hackspot, every piece of personal data passed across that link can be accessed in an man-in-the-middle attack.    

Let’s take a quick look at this from a packetized or object data model.  Let’s assume that the process is the same … I go to my WiFi spot, select a book, click checkout, and authorize the payment.  But this time there will be a couple small differences.  The first is that I am using a small tool kit that can encrypt or provide a digital signature (or both) to certain objects on my machine, and while I would not necessarily have it as a browser plug-in, but for simplicity, let’s say that is what it is.  In this case, when I get my book order confirmation, I am going to be sent an electronic purchase order from the merchant.  It will contain a short description of the purchase, a purchase Id, merchant Id, and amount, a timestamp and a customer Id.  I will pull my credit card from the secure tool kit, append that credit card number which has  been encrypted with the public key of the credit card processor, and digitally sign the entire PO.  I then return the entire blob back to the merchant.

The merchant will pass a copy of this back to the payment processor who will decrypt the credit card number, and verify the number belongs to the user who signed the PO.  They can then send some form of acknowledgment back to the vendor to verify the user was the owner of the credit card, and that the payment has been approved.  Merchant sends me back an order confirmation and the process is complete.  A remediation or dispute resolution is a simple process for the merchant that does not require a credit card number stored in the clear.

In this scenario the merchant can verify that I am me because of the digital signature, but I did not have to pass a password across the Internet.  It keeps the merchant from trying to keep credit card numbers lying around, which is an advantage to everyone.  It protects the merchant as it lessens the likelihood of replay attacks, forgeries, and the passwords or credit card numbers from being intercepted by a man-in-the-middle.  It protects the user from the same issues.  And as the toolkit can be used to store personal information on the laptop encrypted, reduces the possibility of the information being obtained during a physical theft.

As much of this can be automated by a local application, the user does not need to worry about all of the ugly details or be a cryptographic expert.  This is almost zero change to the shopping experience, a small addition of code to the user and merchant sides, and a moderate change to the underlying payment clearing process.  But it is my contention that this offers greater user & merchant security.  But best of all, this could do away with the entire PCI Industry as we know it, reducing costs for the merchant and fraud for the merchant banks! 

A perfect solution?  Not even close.  It opens up new attack vectors in key management and public key distribution, but these are more complicated, and more expensive, attacks.  And I still have the problem that if someone gets my laptop, they can order whatever they like without my assistance.  If they get a hold of the laptop, the only thing that keeps a thief from pretending to be me is a password.  If they can now guess the password(s), and I am not using some form of n-factor authentication, it’s game over.  But that is no different than what we have today.  With this packetized data model, information is stored on the disk like keys, credit card numbers and other valuable data is encrypted and not accessible without passing access control requirements.  And the vendor may have my credit card number, but that number is secured so that only the bank & I know what it is.  

 Thoughts?  Questions?  Character Assassinations?  Feel free to chime in.

Miscellaneous Ramblings on ICS

I was having lunch the other day, discussing Information Centric Security, with someone I had never met before.  It was an amazing conversation, and it struck me as ironic that two people who have each spent the last dozen years at different companies working with different technologies have come to so many similar conclusions.  Both in the deficiencies in how we use the security tools we have today, or more correctly, the mis-application of those technologies.  We both had nearly identical concepts about how to move security forward, and how it will take a fundamental shift in the mentality and approach of the security practitioners to achieve these goals.  Our consensus was that it is not so much a technology issue, but will require a fundamental shift in perspective to advance IT security from where we are today.  There is more than enough technology available.  Our technology tool kit is full of cool stuff.  Technology is not the limiting factor.  How we approach solving problems is.  I called it an ‘Approach’, he called it a ‘Mind Hack’.  Whatever.  It is these types of meetings that keep me in this profession and get me excited about my work.

It is also interesting to see how biases and beliefs manifest themselves into different implementation strategies.  Forgive the crude analogy, but while we both fervently believe in Information Centric Security as a model, we worship at slightly different altars of implementation.  Some of us view the solution as a virtualized application space, which I believe is manifest of a business processing security perspective.  Others view the solution as a packetized encapsulation of data objects, which I believe originates from a perspective of personal data protection.  The former has a distinct advantage in the area of misuse detection and data policy management, the later has a decided advantage in privacy and application dependencies.  There will be other proposals, which will all have a common thread that data will have a playground in which it is used, accessed and stored.  The differences are where you draw your ‘line in the sand’, or the protective boundary around the data. Personally, the more the better as it shows the flexibility of the concept, but it can make it more difficult to get your head around.

To take this one step further, much of the security we have today is designed to protect the infrastructure.  It is external to business processing and in many cases is deployed as an ad-on at the network level.  ICS by contrast is systemic.  ICS places security directly on the asset of value, not the infrastructure.   ICS and Firewalls or IDS are not mutually exclusive, but take the opposite approach. 

Anyway, it is great to get a chance to sit down with someone who has been thinking about this for many years and hammer out some ideas and where to go with this. We are going to reach a critical mass on this in short order.

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.