We won’t see much for a while yet, but when we do, it will likely begin with Oracle selling pre-tuned versions of Secerno for Oracle Applications. After a while we will see a couple new analysis options, and shortly thereafter we will be told this is not WAF, it’s better than WAF. How could these other vendors possibly know the applications as well as Oracle? How could they possibly protect them as accurately or efficiently? These WAF vendors don’t have access to the Oracle applications code, so how could they possibly deliver something as effective? We are not trying to be negative here, but we all know how Oracle markets, especially in security:
OK, so we went negative. Send your hate mail to Rich. I’ll field the hate mail from the technologists out there who are screaming mad, knowing that there is a big difference between WAF policies and traffic analysis and what Secerno does. Yes and no, but it’s irrelevant from a marketing standpoint. For those who remember Dell’s “Dude” commercials from the early 2000s, they made buying a computer easy and approachable. Oracle will do the same thing with security, making the choice simple to understand, and covering all their Oracle assets. They’d be crazy not to. Market this as a full-featured WAF, blocking malicious threats with “zero false positives”, for everything from Siebel to 11G. True or not, that’s a powerful story, and it comes from the vendor who sold you half the stuff in your data center. It will win the hearts of the security “Check the box” crowd in the short term, and may win the minds of security professionals in the long term.
I believed Microsoft wanted SQL Server to leverage BitLocker and the associated Encrypted File System (EFS). It seemed to me that their strategy was going to be similar to what IBM does with Vormetic: leveraging a generic file system encryption system to secure both database and generic files on disk. They have lots invested in the OS, so why not? Looking at SQL Server 2008, that really does not seem to be the focus -- instead Transparent Database Encryption, performed at the block level, is the preferred method for database encryption. Block level encryption is pretty fast, and as it is applied to all the data files, you cannot accidently miss one and leave data exposed. This option seems more appropriate for compliance, as you are moving key management and encryption policy decisions out of IT and into the database. In practice this may be academic, but it's easier and offers less room for mistakes. All told, that can be the difference in making an auditor happy.
If you look at the SQL Server portfolio of encryption options, they offer the API level 'cell encryption', block level TDE, and BitLocker OS level encryption. Coupled with the DPAPI key manager, this means Microsoft's approach is closer to Oracle's, with their corresponding dbms_crypto API, block level Tablespace Transparent Encryption (TTE or TDE depending on your reference), wallet key manager, and column level TDE that provides intra-block protection. It's not surprising that IBM focuses more on storage, Microsoft more on the OS, and Oracle on the application layer, but Oracle and Microsoft now have more similarities than differences.
I have been known to lock myself in a server lab for a week or more, testing a product every which way, until I am confident I know how a product works. Blue fingered and frozen, I emerge with knowledge of how a product stands up to its competition and how it solves customer problems. I did this with Oracle 10G encryption a few years ago, and came away with the impression that is was very easy to use, with more than acceptable performance, but storing the keys in the database remains an issue. I seem to remember the keys being stored raw in the systems tables. What shocked me is that I learned that the external key server (what Oracle calls a 'wallet'), is mandatory, not optional. This means that all the keys stored in the database are encrypted by the master key stored in the wallet. I have absolutely no recollection of that being the case, and while I vividly remember setting up keys, I have no memory of installing, configuring or using a wallet. Maybe I had a beta version -- who knows? But I was so shocked by this I asked Rich if he knew about it and he said 'no'. So if both of us can totally misunderstand this requirement, it's a fair bet others have as well.
The wallet as a required external key management service is important, as it encrypt the keys used to encrypt / decrypt data within the database. Encryption by a master key external to the database makes it virtually impossible for the DBA to get the keys, as they are not sitting around in cleartext on disk. Accessing the master key is a process between the database and the wallet, where the database must securely authenticate itself before it can be provided the master key it needs to decrypt data encryption keys. The master key is in turn secured in the wallet through RSA's PKCS #5 v2.0 secure password methodology, so the master key never resides in the clear on disk either. You need to make sure the wallet is properly secured and backed up, but these minor management tasks pale in comparison to the extra key security provided. I am happy to be wrong as this is a really solid security choice on their part.
Written by alane | Filed under Data Security, Database | 5 comments
While doing research on business justifications for several projects Rich and I are working on, I ran across the Aberdeen Group research paper on the Imperva Blog. Aberdeen talks about business justification for database security spending, and you can download a copy for free. It?s worth a read, but needs to be kept in perspective.
?Don?t you know about the new fashion honey? All you need are looks and a whole lotta money.?
?Best-in-Class companies 2.4 times more likely to have DB encryption ? Best-in-Class companies are more likely to employ data masking, monitoring, patch management and encryption than Laggards.? Hmmm, people who do more and spend more are leaders in security and compliance. Shocker! And this is a great quote: ?? current study indicates that the majority of their data is maintained in their structured, back end systems.? As opposed to what? Unstructured front end systems? Perhaps I am being a bit unfair here, but valuable data is not stored on the perimeter. If the data has value, it is typically stored in a structured repository because that makes it easier for a wider group to query, for various purposes. I guess people steal data that has no value as well, but who cares?
?Well, duh.?
Saying it without saying it I guess, the Imperva comments are spot on. You can do more for less. The statistics show what we have been talking about for data security, specifically database security, for a long time. I have witnessed many large enterprises realize reduced compliance and security costs by changes in education, changes in process, and implementation of software and tools that automate their work. But these reductions came after a significant investment. How long it takes to pay off in terms of reduced manpower, costs, and efficiencies in productivity varies widely. And yes, you can screw it up. False starts are not uncommon. Success is not a given. Wrong tool, wrong process, lack of training, whatever. Lots of expense, Best-in-Class, poor results.
?But mom, everyone?s doing it!?
The paper provides some business justification for DB security, but raises as many questions as it answers. ?Top Pressures Driving Investments? is baffling; if ?Security-related incidents? is its own category, what does ?Protect the organization mean?? Legal? Barbed wire and Rent-a-Cops? And how can 41% of the ?Best-in-Class? respondents be in three requirement areas. Is everything a top priority? If so, something is seriously wrong. ?Best-in-Class companies are two-times more likely than Laggards to collect, normalize, and correlate security and compliance information related to protecting the database?. I read that as saying SIEM is kinda good for compliance and security stuff around the database, at least most of the time. According to my informal poll, this is 76.4% likely to confuse 100% of the people 50% of the time.
?Does this make me look Phat??
If you quote these statistics to justify acquisition and deployment of database security, that?s great. If you choose to implement a bunch of systems so that you are judged ?best in class?, that?s your decision. But if I do, call me on it. There is just not enough concrete information here for me to be comfortable with creating an effective strategy, and no way to cobble together enough data to really know what separates the effective strategies from the bad ones. Seriously, my intention here is not to trash the paper, because it contains some good general information on the database security market and some business justification. You are not going to find anyone on this planet who promotes database security measures more than I do. But it is the antithesis of what I want to do and how I want to provide value. Jeez, I feel like I am scolding a puppy for peeing on the rug. It?s so cute, but at the same time, it?s just not appropriate.
?I call Bu&@% on that!?
I have been in and around security for a long time, but the analyst role is new to me. Balancing the trifecta of raising general awareness, providing specific pragmatic advice, and laying out the justification as to why you do it, is really tough. This blog?s readership comes from many different backgrounds, which further compounds the difficulty in addressing an audience; some posts are going to be overtly technical, while others are for general users. Sure, I want to raise awareness of available options, but providing clear, pragmatic advice on how to proceed with security and compliance programs is the focus. If Rich or I say ?implement these 20 tools and you will be fine? that is neither accurate nor helpful. If we recommend a tool, ask us why, ask us how, because people and process are at least as important as the technology being harnessed. If you do not feel we are giving the proper weight to various options, tell us. Post a comment on the blog. We are confident enough in our experience and abilities to offer direct advice, but not so arrogant as to think we know everything. One reason Rich and I are hammering on the whole Open Research angle is so that you know where our opinions come from and who we are, but also to ensure readers have the ability to question our research and add value to it.
Now, here are the basics steps:
Consider this an education exercise to provide base understanding of what needs to be addressed and how best to proceed. At this point you should be ready to a) you can document what exactly your ‘corporate configuration policies’ are and b) develop a tiered plan of action to tackle databases in descending order of priority. Keep in mind that these are just a fraction of the preventative security controls you might employ, and does not address active security measures or forensic analysis
In other words: a good product with advantages and disadvantages, just like anything else. More security than compliance, but like many DAM tools it offers some of both. Ignore the hype, figure out your needs, and evaluate to figure out which tool fits best. You aren’t a bad person if you don’t buy Oracle, no matter what your sales rep tells your CIO.
And seriously – watch out for the deal bundling. If you haven’t learned anything from us about database security by now, hopefully you at least realize that DBAs and security don’t always talk as much as they should (the same goes for Guardium/IBM). If you need to be involved in any database security, start talking to the DBAs now, before it’s too late.
Transparent/External Encryption for protecting database data uses the following techniques & technologies:
Which option to choose depends on your performance requirements, threat model, exiting architecture, and security requirements. Unless you have a high-performance system that exceeds the capabilities of file/folder encryption, we recommend you look there first. If you are managing heterogeneous databases, you will likely look at a third party product over native encryption. In both cases, it’s very important to use external key management and not allow access by any local accounts. We will outline selection criteria and use cases to support the decision process in a future post.
Transparent/External Encryption for protecting database data uses the following techniques & technologies: