Research

Few terms strike as much dread in the hearts of security professionals as key management. Those two simple words evoke painful memories of massive PKI failures, with millions spent to send encrypted email to the person in the adjacent cube. Or perhaps it recalls the head-splitting migraine you got when assigned to reconcile incompatible proprietary implementations of a single encryption standard. Or memories of half-baked product implementations that worked fine on in isolation on a single system, but were effectively impossible to manage at scale. And by scale, I mean “more than one”. Over the years key management has mostly been a difficult and complex process. This has been aggravated by the recent resurgence in encryption – driven by regulatory compliance, cloud computing, mobility, and fundamental security needs. Fortunately, encryption today is not the encryption of yesteryear. New techniques and tools remove much of the historical pain of key management – while also supporting new and innovative uses. We also see a change in how organizations approach key management – a move toward practical and lightweight solutions. In this series we will explore the latest approaches for pragmatic key management. We will start with the fundamentals of crypto systems rather than encryption algorithms, what they mean for enterprise deployment, and how to select a strategy that suits your particular project requirements. The historic pain of key management Technically there is no reason key management needs to be as hard as it has been. A key is little more than a blob of text to store and exchange as needed. The problem is that everyone implements their own methods of storing, using, and exchanging keys. No two systems worked exactly alike, and many encryption implementations and products didn’t include the features needed to use encryption in the real world – and still don’t. Many products with encryption features supported only their own proprietary key management – which often failed to meet enterprise requirements in areas such as rotation, backup, separation of duties, and reporting. Encryption is featured in many different types of products but developers who plug an encryption library into an existing tool have (historically) rarely had enough experience in key management to produce refined, easy to use, and effective systems. On the other hand, some security professionals remember early failed PKI deployments that costs millions and provided little value. This was at the opposite end of the spectrum – key management deployed for its own sake, without thought given to how the keys and certificates would be used. Why key management isn’t as hard as you think it is As with most technologies, key management has advanced significantly since those days. Current tools and strategies offer a spectrum of possibilities, all far better standardized and with much more robust management capabilities. We no longer have to deploy key management with an all-or-nothing approach, either relying completely on local management or on an enterprise-wide deployment. Increased standardization (powered in large part by KMIP, the Key Management Interoperability Protocol) and improved, enterprise-class key management tools make it much easier to fit deployments to requirements. Products that implement encryption now tend to include better management features, with increased support for external key management systems when those features are insufficient. We now have smoother migration paths which support a much broader range of scenarios. I am not saying life is now perfect. There are plenty of products that still rely on poorly implemented key management and don’t support KMIP or other ways of integrating with external key managers, but fortunately they are slowly dying off or being fixed due to constant customer pressure. Additionally, dedicated key managers often support a range of non-standards-based integration options for those laggards. It isn’t always great, but it is much easier to mange keys now than even a few years ago. The new business drivers for encryption and key management These advances are driven by increasing customer use of, and demand for, encryption. We can trace this back to 3 primary drivers: Expanding and sustained regulatory demand for encryption. Encryption has always been hinted at by a variety of regulations, but it is now mandated in industry compliance standards (most notably the Payment Card Industry Data Security Standard – PCI-DSS) and certain government regulations. Even when it isn’t mandated, most breach disclosure laws reduce or eliminate the need to publicly report loss of client information if the lost data was encrypted. Increasing use of cloud computing and external service providers. Customers of cloud and other hosting providers want to protect their data when they give up physical control of it. While the provider often has better security than the customer, this doesn’t reduce our visceral response to someone else handling our sensitive information. The increase in public data exposures. While we can’t precisely quantify the growth of actual data loss, it is certainly far more public than it has ever been before. Executives who previously ignored data security concerns are now asking security managers how to stay out of the headlines. More enforcement of more regulations, increasing use of outsiders to manage our data, and increasing awareness of data loss problems, are all combining to produce the greatest growth the encryption market has seen in a long time. Key management isn’t just about encryption (but that is our focus today) Before we delve into how to manage keys, it is important to remember that cryptographic keys are used for more than just encryption, and that there are many different kinds of encryption. Our focus in this series is on data encryption – not digital signing, authentication, identity verification, or other crypto operations. We will not spend much time on digital certificates, certificate authorities, or other signature-based operations. Instead we will focus on data encryption, which is only one area of cryptography. Much of what we see is as much a philosophical change as improvement in particular tools or techniques. I have long been bothered people’s tendency to either indulge in encryption idealism at one end, and or dive

We are pleased to announce the availability of a new research paper, Understanding and Selecting Database Security Platforms. And this paper covers most of the facets for database security today. We started to refresh our original Database Activity Monitoring paper in October 2011, but stopped short when our research showed that platform evolution has stopped converging – and has instead diverged again to embrace independent visions of database security, and splintering customer requirements. We decided our original DAM research was becoming obsolete. Use cases have evolved and vendors have added dozens of new capabilities – they have covered the majority of database security requirements, and expanded out into other areas. These changes are so significant that we needed to seriously revisit our use cases and market drivers, and delve into the different ways preventative and detective data security technologies have been bundled with DAM to create far more comprehensive solutions. We have worked hard to fairly represent the different visions of how database security fits within enterprise IT, and to show the different value propositions offered by these variations. These fundamental changes have altered the technical makeup of products so much that we needed new vocabulary to describe these products. The new paper is called “Understanding and Selecting Database Security Platforms” (DSP) to reflect these major product and market changes. We want to thank our sponsors for the Database Security Platform paper: Application Security Inc, GreenSQL, Imperva, and McAfee. Without sponsors we would not be able to provide our research for free, so we appreciate deeply that several vendors chose to participate in this effort and endorse our research positions. You can download the DSP paper. Share:

As you might have noticed, there was no Incite last week. Turns out the Boss and I were in Barcelona to celebrate 15 years of wedded bliss. We usually run about 6 months late on everything, so the timing was perfect. We had 3 days to ourselves and then two other couples from ATL joined us for the rest of the week. We got to indulge our appreciation for art – hitting the Dali, Miro, and Picasso museums. We also saw some Gaudi structures that are just mind-boggling. Then we joked about how Americans are not patient enough to ever build anything like the Sagrada Familia. Even though we were halfway around the world, we weren’t disconnected. Unless we wanted to be. I rented a MiFi, so when we checked in (mostly with the kids) we just fired up the MiFi, and Skype or FaceTime back home. Not cheap, but cheaper than paying for expensive WiFi and cellular roaming. And it was exceedingly cool to be walking around the Passion Facade of the Sagrada Familia, showing the kids the sculptures via FaceTime, connected via a MiFi on a broadband cellular network in a different country. We took it slow and enjoyed exploring the city, tooling around the markets, and feasting on natural Catalan cooking – not the mixture of additives, preservatives, and otherwise engineered nutrition we call food in the US. And we did more walking in a day than we normally do in a week. We also relaxed. It’s been a pretty intense year so far, and this was our first opportunity to take a breath and enjoy the progress we have made. But real life has a way of intruding on even the most idyllic situations. As we were enjoying a late lunch at a cafe off Las Robles, our friends mentioned how it’s been a little while since they were online. We had already had the discussion about weak passwords on their webmail accounts as we enjoyed cervezas Park Gueell the day before. Their name and a single digit number may be easy to remember, but it’s not really a good password. When my friend then told me how he checked email from a public computer in London, I braced for what I knew was likely to come next. So I started interrogating him as to what he uses that email address for. Bank accounts? Brokerage sites? Utilities? Airlines? Commerce sites? No, no, and no. OK, I can breathe now. Then I proceeded to talk about how losing control of your email can result in a bad day. I thought we were in the clear. Then my buddy’s wife piped in, “Well, I checked my bank account from that computer also, what that bad?” Ugh. Well, yes, that was bad. Quite bad indeed. Then I walked them through how a public computer usually has some kind of key logger and accessing a sensitive account from that device isn’t something you want to do. Ever. She turned ashen and started to panic. To avoid borking the rest of my holiday, I had her log into her account via the bank’s iOS app and scrutinize the transactions. Nothing out of the ordinary, so we all breathed a sigh of relief. She couldn’t reset the password from that app and none of us had a laptop with us. But she promised to change the password immediately when she got back to the US. It was a great reminder of the low-hanging fruit out there for attackers. It’s probably not you, but it’s likely to be plenty of folks you know. Which means things aren’t going to get better anytime soon, though you already knew that. –Mike Photo credits: “Low-hanging fruit explained” originally uploaded by Adam Fagen Heavy Research We’re back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, with all our content in its unabridged glory. And you can get all our research papers too. Understanding and Selecting Data Masking How It Works Defining Data Masking Introduction Evolving Endpoint Malware Detection Control Lost Incite 4 U Bear hunting for security professionals: Fascinating post by Chris Nickerson about Running from your Information Security Program. How else could you integrate bear hunting in Russia (yes, real bears), running, and security? He talks about how these Russian dudes take down bears with nothing more than a stick and a knife. Probably not how you’d plan to do it, right? Chris’ points are well taken, especially challenging the adage about not needing to be totally secure – just more secure than the other guys. That’s what I love about pen testers – they question everything, challenge assumptions, and spend a great deal of their lives proving those assumptions wrong. The answer? Plan for the inevitable attacks and make sure you can respond. Yes, it’s something lots of folks (including us) have been talking about for a long time. Though I do enjoy highlighting new and interesting ways to tell important stories. – MR Job security: Say you’re the CISO of a retail chain. Do you think you’d be fired if 10% of your transactions were hacked and resulted in fraud? Maybe you should consider working for the IRS, because apparently gigantic fraud rates not only don’t get you fired there – you get sympathetic press. I bet the guys at Global Payments and Heartland are jealous! And someone at the IRS actually thought that anonymous Internet tax filings, with subsequent anonymous distribution of refunds, was a great idea. I’m willing to bet that not only is whoever created the program is still working at the IRS (where else?), but they will keep the program as is. There are occasions where it’s better to ditch fundamentally flawed processes – and losing millions, if not hundreds of millions, of dollars is a good indicator that your process still has a few glitches – and start over. Most