Research

Updated June 4th to reflect terminology change. This is the Re-Introduction to our Database Encryption series. Why are we re-introducing this series? I’m glad you asked. The more we worked on the separation of duties and key management sections, the more dissatisfied we became. Rich and I got some really good feedback from vendors and end users, and we felt we were missing the mark with this series. And not just because the stuff I drafted when I was sick completely lacked clarity of thought, but there are three specific reasons we were unhappy. The advice we were giving was not particularly pragmatic, the terminology we thought worked didn’t, and we were doing a poor job of aligning end-user goals with available options. So yeah, this is an apology to our audience as the series was not up to our expectations and we failed to achieve some of our own Totally Transparent Research concepts. But we’re ‘fessing up to the problem and starting from scratch. So we want to fix these things in two ways. First we want to change some of the terminology we have been using to describe database encryption. Using ‘media encryption’ and ‘separation of duties’ is confusing the issues, and we want to differentiate between the threat we are trying to protect against vs. what is being encrypted. And as we are talking to IT, developers, DBAs, and other audiences, we wanted to reduce confusion as much as possible. Second, we will create a simple guide for people to select a database encryption strategy that addresses their goals. Basically we are going to outline a decision tree of user requirements and map those to the available database encryption choices. Rich and I think that will aid end users to both clarify their goals and determine the correct implementation strategy. In our original introduction we provided a clear idea of where we wanted to go with this series, but we did adopt our own terminology in order to better encapsulate the database encryption options vendors provide. We chose “Encryption for Separation of Duties” and “Encryption for Media Protection”. This is a bit of an oversimplification, and mapped to the threat rather than to the feature. Plus, if you asked your RDBMS vendor for ‘media encryption’, they would not know what they heck you were talking about. We are going to change the terminology back to the following: Database Transparent/External Encryption: Encryption of the entire database. This is provided by native encryption functions within the database. The goal is to prevent exposure of information due to loss of the physical media. This can also be done through drive or OS/file system encryption, although they lack some of the protections of native database encryption. The encryption is invisible to the application and does not require alterations to the code or schema. Data User Encryption: Encrypting specific columns, tables, or even data elements in the database. The classic example is credit card numbers. The goal is to provide protection against inadvertent disclosure, or to enforce separation of duties. How this is accomplished will depend upon how key management is utilized and (internal/external) encryption services, and will affect the way the application uses the database, but provides more granular access control. While we’re confident we’ve described the two options accurately, we’re not convinced the specific terms “database encryption” and “data encryption” are necessarily the best, so please suggest any better options. Blanket encryption of all database content for media protection is much easier than encrypting specific columns & tables for separation of duties, but it doesn’t offer the same security benefits. Knowing which to choose will depend upon three things: What do you want to protect? What do you want to protect it from? What application changes and management tasks will you tolerate? Thus, the first thing we need to decide when looking at database encryption is what are we trying to protect and why. If we’re just going after the ‘PCI checkbox’ or are worried about losing data from swapping out hard drives, someone stealing the files off the server, or misplacing backup tapes, then database encryption (for media protection) is our answer. If the goal is to protect data in the event of compromised accounts, rogue DBAs, or inadvertent disclosure; then things get a lot more complicated. We will go into the details of ‘why’ and ‘how’ in a future post, as well as the issues of application alterations, after we have introduced the decision tree overview. If you have any comments, good, bad, or indifferent, please share. As always, we want the discussion to be as open as possible. Share:

OK, I have to call Bull$%} on this: Anti-piracy pup sniffs out 35,000 illegal DVDs. A piracy fighting dog. Really. From Yahoo! News: The black Labrador helped enforcement officials who carried out raids last week in southern Johor state which neighbours Singapore, the Motion Picture Association (MPA) said in a statement. Paddy was given to Malaysia by the MPA to help close down piracy syndicates who churn out vast quantities of illegal DVDs. The dog is specially trained to detect chemicals in the discs. So the dog can detect chemicals used in DVDs. Call me a cynic, but I suspect that ‘Paddy’ cannot tell the difference between Best Buy, an adult video store, and an underground DVD warehouse. So unless someone has figured out how to install laser diodes and detection software onto a Labrador, it’s not happening. Of course, when they do, the pirates will be forced to escalate the confrontation with the unstoppable “Fuzzy, bouncy, piracy tennis ball of mayhem”. Seriously, this is an illustration of the huge difference between marketing security and actual security. It looks to me like someone is trying to create the MPA version of Sexual Harassment Panda, and it’s just wrong! Share:

I ran across a lot of little tidbits in the world of database security this week, so I figured I would share this for the Friday Summary: Idera has been making a lot of noise this week with seemingly two dozen TechTarget ‘KnowledgeAlerts’ hitting my inbox. Yes, they are still around, but it’s hard to consider them a database security vendor. Customers mostly know them as a DB tools vendor; but they do additionally offer backup encryption, a form of activity monitoring, and what I call “permission mapping” solutions. Not a comprehensive security suite, but handy tools. They really only support the SQL Server platform, but they do in fact offer security products, so bad on me for thinking they were dead and buried. I may not hear about them very often, but the one or two customers I hear from seem to be happy, and that’s what counts. And it’s a challenge to put security tools into the hands of DBA’s and non-security personnel and make them happy. And speaking of “I thought they were dead”, NGS Software entered into a partnership with Secerno recently. NGS has always incredibly database security savvy but product-deficient, focusing more on their professional services capabilities rather than product development. It shows. Secerno is a small DAM firm with a novel approach to detecting anomalous queries. I would like to see them able to compete on an even footing to demonstrate what they can do, as they need more proof points and customer successes to prove how this technology performs in the real world. To do that they are going to need to offer the assessment capability or they will get relegated to the sidelines as a ‘feature’ and not a database security solution. Secerno is too small and probably does not want to sink the time and money required to develop a meaningful body of assessment policies, so being able to leverage the NGS team and their products will help with preventative security measures. Ideally Secerno will put an updated face on the ‘Squirrel’, and leverage the expanded body of policies, but better to have the capability for now and improve later. I have said it before and I will say it again: any customer needs to have assessment to baseline database configurations, and monitoring to enforce policy and detect threats. The compliance buyers demand it, and that’s your buying center in this market. I am eager to see what this UK tag team can do. LogLogic announced their database security intentions a little while back, but shipped their Database Security Manager this week. This is not a scruffy startup entering the database security arena, but a successful and polished firm with an established customer base. Granted, we have seen similar attempts botched, but this is the addition of a more complimentary technology with a much better understanding of the customer buying requirements. LogLogic is touting the ability to perform privileged user monitoring, and that this is fully integrated with their existing audit log collection and analysis. But everyone they will be competing with will have something similar, so that’s not very interesting. What is significant to me is a log management vendor providing the near-real-time monitoring and event blocking capabilities that need to be present to take a security product seriously. Additionally, it is done in a way that will address console and privileged users, which is necessary for compliance. The speed of the integration implies that the product architecture is conducive to both, and if you have ever tried implementing a solution of this type you understand that it is difficult because the two functions offer diametrically opposed technical challenges in data storage and processing. Keep in mind that they just acquired Exaprotect to accomplish similar goals for SEM, so I expect we will see that integration happen soon as well. Now let’s see if their customers find it compelling. Thanks to one of our readers for the heads-up on this one: The Netezza Corporation Investor relations transcript. Interesting details coming out of their end-of-quarter investor call. Turns out that the $3M acquisition price I quoted was slightly off, and the real total was slightly higher at $3.1 million. Given Netezza’s nominal head-count increase since January 1, 2009 (9 people), it looks as if they kept just a handful of the Tizor staff. What shocked me is that they are being credited with 23 customers – less than half the number of customers I thought they had. I am not sure what their average deal size was, but I am willing to bet it was sub-$200k, so revenues must have been very small. This deal was better for their investors than I realized. Lumigent continues to thrive as the contra-database-security platform. While I find most things GRC to be little more than marketing doublespeak, Lumigent has done a good job at locating and mining their ‘AppGRC’ niche. It’s not my intention to marginalize what they provide because there is customer need, there has been for some time, and the platform is suitable for the task. It is interesting that none of their (former?) competitors had success with that marketing angle and reverted to security and compliance messages, but Lumigent is making it work. The segment needs to move up from generic database security to business policy analysis and enforcement, but the ‘what’ and how to get there are not always clear. I confess I think it funny that for most of their articles such as this one, I could substitute “database security” for ‘AppGRC’ and they would still work. Does the need to move beyond reliance on DBA scripts to a more comprehensive assessment and audit platform with separation of duties sound like DB security? You bet it does. It goes to show that messaging & positioning is an art form. So bravo on the re-branding, appropriate new partnerships and intense focus they have on GRC buyers in the back-office application space. And now for the week in review: Webcasts, Podcasts,

This is an off-topic post. It has a bit to do with Compliance, but nothing to do with Security, so read no further if you are offended by such things. I am surprised that we have not been reading more about the off balance sheet ‘assets’ that was brought to light last week. In a nutshell, over $900 billion in ‘assets’, spread across the 19 largest US banks, was not part of the normal 10K/10Q, and the SEC is telling banks they need to be brought back onto the balance sheets. This is an issue is because these ‘assets’ are mostly comprised of real estate and credit card debt owed to the banks. The change could result in about $900 billion in assets being brought onto the balance sheets of the 19 largest U.S. banks, according to federal regulators. The information was provided by Citigroup Inc., JPMorgan Chase & Co. and 17 other institutions during the government’s recent “stress tests,” which were designed to determine which banks would need more capital if the economy worsened. … In general, companies transfer assets from balance sheets to special purpose entities to insulate themselves from risk or to finance a large project. Given the accelerating rate at which credit card debt is going bad, and the fact that real estate values in states like Arizona have dropped as much as 70% since 2006, it’s likely we are looking at the majority of these ‘assets’ simply vanishing. Across the board, 12% of all homeowners are behind in payments or in foreclosure, and the remaining assets are worth far less than they were originally. It was ironic that I ran across an article about the need to repeal the Sarbanes-Oxley Act of 2002 on the very morning I saw this news item. There has been a methodical drumbeat for several years now about the need to repeal SOX, saying it makes it harder to fill out company boards of directors, going so far as to claim the reversal could help stimulate the economy. Of course corporate executives never liked SOX as there were additional costs associated with keeping accurate records, and it’s hard to balance the perception of financial performance with the potential for jail time as a consequence of rule violations. The scandals at Worldcom, Enron, Tyco, and others prompted this regulation to ensure the have accuracy and completeness in financial reporting which might enable us to avoid another similar fiasco. But we find ourselves in the same place we did in 2001, where many companies are in worse financial shape than was readily apparent – many of the same firms requesting more money from the government (taxpayer) to stay afloat. Section 302 was specifically about controls and procedures to ensure that financial statements are accurate, and it looks to me like moving hundreds of billions of dollars in high risk real estate & credit card loans “off balance sheet” would violate the spirit of the act. I would have thought that given the current economic situation, and with the motivating events for Sarbanes-Oxley still in recent memory, there would be greater outcry, but maybe people are just worried about keeping the roofs over their heads. But the call will come for additional regulation and controls over financial systems as more banks fail. Clearly there needs to be refinement and augmentation to the PCAOB guidelines on several accounting practices, but to what degree will not be determined for a long time. Will this mean new business for vendors who collect data and enforce policies in and around SOX? Nope. Instead it will underscore the core value that they cannot provide. Security and Compliance vendors who offer help with SOX policy enforcement cannot analyze a balance sheet. While there were a couple notable examples where internal auditors monitored accounting and database systems to show fraud, this is not a skill you can bottle up for sale. Collection of the raw data and simple policy enforcement can be provided, but there is no way any product vendors could have assisted in detecting the shuffling of balance sheet assets. Still, I bet we will see it in someone’s marketing collateral come RSA 2010! Share:

There have been a couple of acquisitions in the last two weeks that I wanted to comment on; one by Oracle and one by McAfee. But between a minor case of food poisoning followed shortly by a major case of influenza, pretty much everything I wanted to do in the last 12 days, blogging notwithstanding, was halted. I am feeling better and trying to catch up on the stuff I wanted to talk about. At face value, neither of the acquisitions I want to mention are all that interesting. In the big picture, the investments do spotlight product strategy, so I want to comment on that. But before I do, I wanted to make some comments about how I go about assessing the value of an acquisition. I always try to understand the basic value proposition to the acquiring company, as well as other contributing factors. There are always a set of reasons why company A acquires company B, but understanding these reasons is much harder than you might expect. The goals of the buyers and the seller are not always clear. The market strategy and self-perception of each firm come into play when considering what they buy, why they bought it, and how much they were willing to pay. The most common motivators are as follows: Strategic: You want to get into a new market and it is either cheaper or faster to acquire a company that is already in that segment rather than organically develop and sell your own product. Basically this is paving the road for a strategic vision. Buying the major pieces to get into a new market or new growth opportunities in existing markets. No surprises here. Tactical: Filling in competitive gaps. A tactical effort to fill in a piece of the puzzle that your existing customers really need, or complete a product portfolio to address competitive deficiencies within your product. For example, having network DLP was fine up until a point, and then endpoint became a de facto requirement. We saw this with email security vendors who had killer email security platforms, but were still getting hammered in the market for not having complete web security offerings as well. Neither is surprising, but there are many more than these basic two reasons. And this is where things can get weird. Other motivating factors that make the deal go forward may not always be entirely clear. A couple that come to mind: Accretive Acquisition: Buying a solid company to foster your revenue growth curve. Clear value from the buyer’s perspective, but not so clear why profitable companies are willing to sell themselves for 2-4 times revenue when investor hopes, dreams, and aspirations are often much more than that. You have to view this from the seller’s side to make sense of it. There are many small, profitable companies out there in the $15-35M range, with no hope of going public because their market is too small and their revenue growth curve is too shallow. But the investors are pushing for an IPO that will take years, or possibly never happen. So what is your exit strategy? Which firms decide they want the early exit vs. betting their fortunes on a brighter future? You would think that in difficult economic times it is often based upon the stability of their revenue in the next couple of quarters. More often it comes down to which crazy CEOs still swear their firm is at the cusp of greatness for a multi-billion-dollar-a-year market and can convince their boards, vs. pragmatists who are ready to move on. I am already aware of a number of mid-sized companies and investment firms trying to tell “the wheat from the chaff” and target viable candidates, and a handful of pragmatic CEOs willing to look for their next challenge. Look for a lot more of these acquisitions in the next 12 months. Leveraged/Platform Enabler: Not quite strategic, not quite tactical, but a product or feature that multiple products can leverage. For example a web application server, a policy management engine, or a reporting engine may not be a core product offering, but could provide a depth of service that makes all your other products perform better. And better still, where a small firm could not achieve profitability, a large company might realize value across their larger customer base/product suite far in excess of the acquisition price. Good Tech, Bad Company: These firms are pretty easy to spot in this economy. The technology is good and the market is viable, but the company that produces the technology sucks. Wrong sales model, bad positioning, bad leadership decisions, or whatever – they simply cannot execute. I also call this “bargain bin”’ shopping because this is one of the ways mid-sized and larger firms can get cutting edge technology at firesale prices, and cash shortfalls force vendors to sell quickly! Still, it’s not always easy to distinguish the “over-sold bad tech” or “overfunded and poorly managed bad technology” firms from the “good tech, bad management” gems you are after. We have seen a few of these in the last 12 months, and we will see more in the coming 12 months as investors balk and lose confidence. The Hedge: This is where you want into a billion dollar market, but you cannot afford to buy one of the leaders, or your competitors have already bought all of them. What do you do? You practice the art of fighting without fighting: You buy any other player that is a long way from being the front-runner and market that solution like crazy! Sure, you’re not the leader in the category, but it’s good enough not to lose sales, and you paid a fraction of the price. It may even give you time to build a suitable product if you want to, but more often than not, you ride the positive perception train till it runs off the rails. Sellers know this game as well, and you will often see firms

Normally, when a company buys software that does not work, the IT staff gets in trouble, they try to get your money back, purchase different software or some other type of corrective action. When a state or local government buys software that does not work, what do they do? Attempt to alter human behavior of course! Taking a page from the TSA playbook, the department of motor vehicles in four states adopt a ‘No Smiles’ policy when taking photos. Why? Because their facial recognition software don’t work none too good: “Neutral facial expressions” are required at departments of motor vehicles (DMVs) in Arkansas, Indiana, Nevada and Virginia. That means you can’t smile, or smile very much. Other states may follow … The serious poses are urged by DMVs that have installed high-tech software that compares a new license photo with others that have already been shot. When a new photo seems to match an existing one, the software sends alarms that someone may be trying to assume another driver’s identity.” Great idea! Hassle people getting their drivers licenses by telling them they cannot smile because a piece of software the DMV bought sucks so bad at facial recognition it cannot tell one person from another. I know those pimply face teenagers can be awfully tricky, but really, did they need to spend the money to catch a couple dozen kids a year? Did someone get embarrassed because they issued a kid a drivers license with the name “McLovin”? Was the DHS grant money burning a hole in their pockets? Seriously, fess up that you bought busted software and move on. There are database cross reference checks that should be able to easily spot identity re-use. Besides, kids will figure out how to trick the software far more easily than someone with half a brain. Admitting failure is the first step to recovery. Share:

I got acquainted with something new this week: Women’s fashion and knock-offs. And before you get the wrong idea, it’s close to my wife’s birthday and she found a designer dress she really wanted. These things are freakishly expensive for a piece of fabric, but if that is what she wants, that is what she will have. I have been too busy to leave the house, so I found what she wanted on eBay at a reasonable price, made a bid and won the item. When we received our purchase, there was something really weird … the tag said the dress was “100% Silk”. But the dress, whatever it was made out of, was certainly not silk, rather some form of Rayon. And when we went to the manufacturer’s web site, we learned that the dress is not supposed to be made from silk. I began a stitch by stitch examination of the dress and there were a dozen tell-tales that the dress was not legitimate. A couple Internet searches confirmed what we suspected. We took the dress to a professional appraiser who knew it was a fake before she got within three feet of it. We contacted the seller who assured us the item is legitimate, and all of her other customers were satisfied so she MUST be legitimate, but she would happily accept the item and return our money. The seller knows they are selling a fake. What surprised me was (and that is probably because I am a dumb-ass newbie in ‘fashion’) the buyer typically knows they are buying a fake. I started talking to some friends of my wife’s, and then other people I know who make a living off eBay, and this is a huge market. Let’s say a buyer pays $50.00 for a bad knock-off, and a good forgery costs $200. The genuine article costs 10x that, or even 20x that. The market drives its own form of efficiency and makes goods available at the lowest price possible. The buyers know they cannot ever afford the originals, so they buy the best forgeries they can afford. The sellers are lying when they say the items are ‘Genuine’, but most product marketing claims are lies, or charitably put, exaggerations. If both parties know they are transacting for a knock-off, there is no fraud, just happy buyers and sellers. To make a long story short, I was staggered that there is huge in-the-open trade going on. Now that I know what to look for, perhaps half of the listings on eBay for items of this type were fake. Maybe more. I am not saying that this is eBay’s fault and that they should do something about it: that would be like trying to stop stolen merchandise being sold at a flea market, or trying to stop fights at a Raiders game. Centuries of human history have shown you cannot stop it altogether, you can only hope to minimize it. Still, when eBay changed their policy regarding alleged counterfeit items, it’s not a surprise. It is a losing battle, and if they are even somewhat successful, the loss of revenue to eBay will be significant. I admit I was indignant when I realized I bought a fake, and I started this post trying to make the argument that the companies producing the originals are being damaged. The more I look at the information available, the less I think I can make that case. Plus, now that I got my money back, I am totally fine with it. If .0001% of the population can afford a dress that costs as much as a car, is the manufacturer really losing sales to $50 fakes? I do not see evidence to support this. When Rich and I were writing the paper on The Business Justification for Data Security, one of the issues that kept popping up was some types of ‘theft’ of intellectual property do not create a direct calculable damage, and in some cases created a positive effect equal to or greater than the cost of the ‘loss’. So what is the real damage? How do you quantify it? Do the copies de-value the original and lower the brand image, or is the increased exposure better for brand awareness and desirability? The phenomenon of online music suggests the latter. Is there a way to quantify it? Once I knew what to look for, it was obvious to me that half the merchandise was fake, and the original manufacturers MUST be aware of this going on. You cannot claim each is a lost sale, because people who buy a $50 knock-off cannot afford a $10,000 genuine article. But there appears to be a robust business in fakes, and it seem to drive up interest in the genuine article, not lessen it. Consumerism is weird that way. Share:

Securosis is a funny company. We have a very different work objectives and time requirements compared to, say, a software company. And the work we do as analysts is way different than an IT admin or security job. We don’t punch the clock, and we don’t have bosses or corporate politics to worry about. We don’t have a ‘commute’ per se, either, so all of the changes since I left my last company and joined have been for the better and do not take long to adapt to. Another oddity I recently learned was that our vacations days are allocated in a very unusual way: it turns out that our holiday calendar is completely variable. Yes, it is based upon important external events, but only of quasi-religious significance. Last week I learned that all Star Trek premier days are holidays, with a day off to ‘clear your mind’ and be ready to enjoy yourself. This week I learned we get 1/2 days off the afternoon of a Jimmy Buffet concert, and most of the day off following a Jimmy Buffet concert. You see the wisdom in this policy the morning after the show. Last night Rich, I, and his extended family went to Cricket Pavilion for Buffett’s only Phoenix show. I won’t say how many of us actually packed into that tiny motor home for the trip down in case someone from the rental company reads the blog, but let’s say that on a hot summer afternoon it was a very cozy trip. And with something like 24 beers on ice per person, we were well prepared. This was my first Buffett concert and I really enjoyed it! We ended up going in late, so we were a long way from the stage, but that did not stop anyone from having a good time. I will be marking next year’s holiday calendar when I learn his next local tour dates. As this is a Securosis holiday, today’s summary will be a short one. And now for the week in review: Webcasts, Podcasts, Outside Writing, and Conferences Martin and Rich hit a major milestone with the 150th Network Security Podcast, which also hit the 500,000 download mark! Congratulations guys! Favorite Securosis Posts Rich: Adrian’s post on Open Invitation to the University of California at Berkeley IT Dept. Adrian: Rich’s post on The Data Breach Triangle. Data security is not always about preventing the attack. Favorite Outside Posts Adrian: Even though it came out last week, I just ran across Glenn Fleishman’s post on securing home networks. Rich: The PaulDotCom post on SQL Injection with sqlmap. Top News and Posts The cost of patching. Adobe Reader JavaScript Vulnerability at CERT. DoD Official Charged With Handing Over Classified Data To China. Security updates by Apple. Nearly half of IT security budgets deemed insufficient. Only half? Really? Did you see that Obama spoke at the ASU graduation ceremony? Did you see that the opening act was Alice Cooper? Rock on! Blog Comment of the Week This week’s best comment was from Martin McKeay in response to The Data Breach Triangle: Perhaps ‘access’ would be a better term to use than ‘exploit’. A malicious outsider needs an exploit to access the data, whereas a malicious insider usually has access to the data to begin with. You need the loot, a way to get the loot and a way to escape with the loot when you’ve got it. Is there any such thing as a ‘crime triangle’? I’m going to have to give this a bit more thought; I believe you have the right idea, but I think this somehow defines the data breach elements too narrowly. I haven’t figured out exactly what leads me in that direction yet, but it will come to me. Share:

You probably heard the news last week that hackers have infiltrated restricted computer databases at Cal Berkeley. 160,000 current and former students and alumni personal information “may” have been stolen. The University says social security numbers, health insurance information and non-treatment medical records dating back to 1999 were stolen. Within that data set was 97,000 Social Security Numbers, from both Berkeley and Mills College students who were eligible for medical treatment. I am going to make an educated guess that this was a database either for or located at Cowell Hospital, but there are [very few other details available. Not unusual in data breach cases, but annoyingly understandable and the reason I do not post comments on most data breaches. This one is different. This is an offer to help UC Berkeley with their data security challenge. As a security professional and Berkeley alumnus, I want to offer my services to assist with security and product strategy to ensure this does not happen again. Free of charge. I am willing to help. This is a service Securosis provides: free strategic consultation services to end users. Within reason, of course, but we do. So I am extending an open offer of assistance to the University. In 2008, when I was still with my previous employer, we had a couple meetings with IT staff members at UC Berkeley for some of the security challenges and to see if our products were of interest to them. As most initial conversations go, we covered as much background about the environment and goals as we could. While the people we were speaking with were smart and highly educated, the questions they asked and the order of their priorities suggested that they were naive about security. I do not want to provide too many details on this out of respect for confidentiality, but the types of products they were reviewing I would have assumed were already in place, and policies and procedures would have been more evolved. I can even hear Adam Dodge in the back of my head saying “Well … education is a lot different than the private sector”. He’s right, and I get that, but for an organization that has already had a data breach through a lost laptop in March 2005, I expected that they would have gotten ahead of the curve. The liability here goes all the way up to the UC Regents, and this is a problem that needs to be addressed. My goal is not to insult the IT staff at UC Berkeley. Just look at the Privacy Rights web site, or the Open Security Foundation, and you will see that they are no better and no worse than any other university in the country. What pisses me off is that my alma mater, one of the best computer schools in the world, is below average in their data security! Come on!!! This is Berkeley we are talking about. UCLA, OK, I could understand that. But Berkeley? They should be leading the nation in IT security, not the new poster child for University data breaches. Berkeley has among its student body some of the smartest people in computer science, who gather there from all over the world to learn. When I was there if you wanted to know about inner details of the UNIX kernel, say at 2:30 in the morning, there was someone in the lab who could answer your question. Want to know the smallest of details on network architecture? The ‘finger’ daemon could point you to the guys who had all the answers. You might need to pull them away from Larn for a couple minutes, but they knew scary levels of detail on every piece of software and hardware on the campus. It is no different today, and they are clearly not leveraging the talent they have effectively. So go ahead. Ask for help. The university needs assistance in strategy and product suitability analysis, Securosis can help, and we will do it for free. Now I am going to have the Cal fight song in my head for the rest of the day. Share:

This is the next installment in what is now officially the longest running blog series in Securosis history: Database Encryption. In case you have forgotten, Rich provided the Introduction and the first section on Media Protection, and I covered the threat analysis portion to help you determine which threats to consider when developing a database encryption strategy. You may want to peek back at those posts as a refresher if this is a subject that interests you, as we like to use our own terminology. It’s for clarity, not because we’re arrogant. Really! For what we are calling “database media protection” as described in Part 1, we covered the automatic encryption of the data files or database objects through native encryption built into the database engine. Most of the major relational database platforms provide this option, which can be “seamlessly” deployed without modification to applications and infrastructure that use the database. This is a very effective way to prevent recovery of data stored on lost or stolen media. And it is handy when you have renegade IT personnel who hate managing separate encryption solutions. Simple. Effective. Invisible. And only a moderate performance penalty. What more could you want? If you have to meet compliance requirements, probably a lot more. You need to secure credit card data within the database to comply with the PCI Data Security Standard. You are unable to catalog all of the applications that use sensitive data stored in your database, so you want to stop data leakage at the source. Your DBAs want to be ‘helpful’, but their ad-hoc adjustments break the accounting system. Your quality assurance team exports production data into unsecured test systems. Medical records need to be kept private. While database media protection is effective in addressing problems with data at rest, it does not help enforce proper data usage. Requirements to prevent misuse by credentialed users or compromised user accounts, or enforce separation of duties, are outside the scope of basic database encryption. For these reasons and many others, you decide that you need to protect the data within the database through more granular forms of database encryption; table, column, or row level security. This is where the fun starts! Encrypting for separation of duties is far more complex than encrypting for media protection; it involves protecting data from legitimate database users, requiring more changes to the database itself. It’s still native database encryption, but this simple conceptual change creates exceptional implementation issues. It will be harder to configure, your performance will suffer, and you will break your applications along the way. Following our earlier analogy, this is where we transition from hanging picture hooks to a full home remodeling project. In this section we will examine how to employ granular encryption to support separation of duties within the database itself, and the problems this addresses. Then we will delve into the problems you will to run into and what you need to consider before taking the plunge. Before we jump in, note that each of these options are commonly referred to as a ‘Level’ of encryption; this does not mean they offer more or less security, but rather identifies where encryption is applied within the database storage hierarchy (element, row, column, table, tablespace, database, etc). There are three major encryption options that support separation of duties within the database. Not every database vendor supports all of these options, but generally at least two of the three, and that is enough to accomplish the goals above. The common options are: Column Level Encryption: As the name suggests, column level encryption applies to all data in a single, specific column in a table. This column is encrypted using a single key that supports one or more database users. Subsequent queries to examine or modify encrypted columns must possess the correct database privileges, but additionally must provide credentials to access the encryption/decryption key. This could be as simple as passing a different user ID and password to the key manager, or as sophisticated as a full cryptographic certificate exchange, depending upon the implementation. By instructing the database to encrypt all data stored in a column, you focus on specific data that needs to be protected. Column level encryption is the popular choice for compliance with PCI-DSS by restricting access to a very small group. The downside is that the column is encrypted as a whole, so every select requires the entire column to be deencrypted, and every modification requires the entire column to be re-encrypted and certified. This is the most commonly available option in relational database platforms, but has the poorest performance. Table / Tablespace Encryption: Table level encryption is where the entire contents of a table or group of tables are encrypted as one element. Much like full database encryption, this method protects all the data within the table, and is a good option when all more than one column in the table contains sensitive information. While it does not offer fine-grained access control to specific data elements, it more efficient option than column encryption when multiple columns contain sensitive data, and requires fewer application and query modification. Examples of when to use this technique include personally identifiable information grouped together – like medical records or financial transactions – and this is an appropriate approach for HIPAA compliance. Performance is manageable, and is best when the sensitive tables can be fully segregated into their own tablespace or database. Field/Cell/Row Level Encryption, Label Security: Row level encryption is where a single row in a table is encrypted, and field or cell level encryption is where individual data elements within a database table are encrypted. They offer very fined control over data access, but can be a management and performance nightmare. Depending upon the implementation, there might be one key used for all elements or a key for each row. The performance penalty is a sharp limitation, especially when selecting or modifying multiple rows. More commonly, separation of duties is supported by label security.