by Kim Borg

In stark contrast to many other security technologies, encryption has matured from being solely a security operations-level issue into being a grown-up business-level issue that can impact an entire organization. That and the emergence of a so-called ‘Encryption Maturity Curve’ are just some of the findings unearthed in the 2012 Global Encryption Trends Study, a report based on independent research by the Ponemon Institute and sponsored by Thales e-Security.

This year marks the eighth year that Thales has been conducting the study, which also reveals that the ever-evolving role of encryption – which emphasizes the importance of a sound key management strategy – equates to an improved security posture for today’s organizations.

I recently spoke with Richard Moulds, vice president strategy at Thales e-Security, about some of the more surprising trends the study uncovers. For example: The number one perceived threat surrounding data protection has nothing to do with malicious insiders or hackers. Who knew?

Kim Borg: It seems that encryption is edging its way beyond the security operations level to the business level. Does this mean that organizations need to be even more preemptive when it comes to their encryption solution needs?

Richard Moulds: The word “preemptive” is the key point, really. Encryption itself is fundamentally preemptive because what you’re essentially saying is that you’re going to make data worthless, almost on the assumption that somebody is going to get to it – whether they’re going to get it by mistake, because you’ve left a laptop on a bus, a memory stick has gone missing or a backup tape has fallen off the truck. So, whether it’s exposed by mistake or whether it’s been exposed by attack, encryption is, by definition, a preemptive approach that essentially says that data is protected by default, whether or not it needs to be. That requires a certain amount of foresight.

I think what’s brought encryption into the mainstream over the last 10 years is really data breach disclosure mandates, which require that personal data be kept confidential. Data breach disclosure law started in California and now has pretty much swept across the U.S. It essentially says that if you lose data that is relevant to people, then you have obligations to announce the fact that you’ve lost it. As a result, the newspapers are full of stories of passwords being stolen; this is not necessarily because there are more attacks, it’s just that these days, you can’t brush these kinds of breaches under the carpet.

Clearly, data breach disclosure law has become a huge issue, which I think has elevated encryption beyond being an issue with which just the security IT folks are concerned. Legal departments and general management care about the negative impact of data breach disclosure laws – but since encryption is often a way to avoid making a disclosure, after all the loss of useless scrambled data is less concerning, encryption has grabbed the attention of the business domain.

The other thing that’s pushed encryption into the business domain is this issue of compliance scope. When you think of security mandates, such as PCI Data Security Standard [PCI DSS], which applies to anybody who touches a credit card number, which, by the way, is more than just merchants, large chunks of the IT infrastructure for many organizations are impacted. The compliance net can be very wide, involving marketing companies, service providers and even lawyers, where credit card numbers can be buried in evidence that’s provided in the context of legal cases.

The point is that, although many of these standards require encryption to be used in certain situations, they don’t necessarily require data to be encrypted everywhere. However, where data is left unencrypted, those systems, quite rightly fall under special scrutiny because an attack gives direct access to unprotected data. By taking a more proactive approach and going beyond the basic compliance requirements for encryption can dramatically reduce your compliance footprint. If you can encrypt data before it goes into the database, for example, or before you pass it to a cloud service or before you hand it off to a business partner, then those services or bits of infrastructure or partners can be taken out of scope from a compliance point of view.

Trying to make your entire organization compliant from a data privacy point of view is a difficult task. So, the more you can descope your compliance obligations, the better and that’s where I think encryption can play a big role. So I think both the descoping issue and the public disclosure mandate have forced encryption into the business domain.

Although [the Encryption Trends Study] shows that IT operations are still the dominant owner of the strategy, when you look at the trends of the last eight years it’s very clear, that when you ask who drives strategy for the enterprise – business or IT owners – the lines are actually converging and the balance of influence over encryption strategy is shifting towards the business leaders.

We did the survey across seven different countries and what’s interesting is that the shift toward the business focus is actually much stronger in the U.S. than it is elsewhere, so that sort of raises some interesting questions. For example, is the U.S. a predictor of what will be the case for the rest of the world in some years’ time or is somehow the U.S. different?

I think in this case it really is about compliance descoping and data breach disclosure laws, both of which are currently much more prescient in the U.S.

KB: So, how big a role do compliance mandates play – especially in the U.S. – when organizations across various vertical industries are trying to determine the best encryption deployment for their needs?

Also, according to the study, aren’t organizations more inclined to adopt an enterprise encryption plan or strategy rather than relying on ad hoc requirements or informal policies?

RM: I think the role of compliance in defining deployment strategy is often overstated, vendors across the security industry use compliance as a panacea to drive demand for their particular security solutions. If we look are PCI DSS, which I think is probably the most prescriptive mainstream security standard that’s out there – in other words, nothing is really as specific or as tightly audited – the actual references to particular types of technology remain relatively sparse.

I think most IT security folks would regard PCI DSS as being a fairly reasonable framework for protecting sensitive data and it’s based on well-established technology. It’s not particularly revolutionary many companies already have most of the measures in place and, of course, it only applies to credit card numbers. So, I think to say people are deploying encryption and a host of other security technologies purely because of compliance is a bit of a cop out but it can often be an important catalyst for change.

So, while the specifics about technology choices or deployment approaches have been a little bit overstated in the context of compliance, I do think that one of the things the compliance issue do is to help people secure IT budgets. In essence: get security on the agenda.

KB: It seems fairly apparent that legal and financial industries, for example, would have much more concrete encryption plans – by virtue of the sectors in which they play – than would other vertical industries. Is this the case? Are certain industries more “encryption-happy” than others?

RM: There’s a correlation between being, as you say, “encryption-happy” and the degree to which an industry or company has got its head around data classification. Those people who jump in and say: “Wouldn’t it be great if we encrypted all of our stuff?” are being a little naïve – it’s really not necessary. Companies need to classify the data they care about, or that they have been told they should care about by a regulator, discover where it is on the network – which, in itself, can yield some interesting surprises – and then figure out how best to protect it. That’s the logical process companies should follow, but obviously companies in sectors like defense, government and banking have for years had a very good idea about what data they care about and about what data they care less about.

So, the first question I ask when somebody asks for encryption advice is: “To what degree have you classified the data in your business?”

If I get sort of a vague response, then it tells me how far along that business is on the sophistication curve. Alternatively, if they come back with: “We care about health care records” or “We care about salary information” or “We care about social security information” or “We care about credit card numbers” or “We care about national secrets,” then they’re probably going to be much more experienced in the ways of using encryption.

I think the industries that are waking up to encryption now include the hospitality sectors – these sectors are really being attacked from a data breach perspective and yet they have had a relatively unsophisticated approach to data protection in the past.

KB: Let’s explore what Thales has designated as the ‘Encryption Maturity Curve,’ which essentially charts a trend toward increasingly sophisticated deployments of encryption – that is, moving beyond traditional laptop and network encryption to encryption of data in applications.

RM: If people are embarking on the journey of using encryption, they tend to embark on it from the perspective of, initially, protecting data in motion, data flowing over public networks. And then they tend to move on to more sophisticated uses of encryption later.

This again ties into the compliance issue. If you look at what PCI DSS actually mandates, it says if you’re putting any credit card numbers over a public network, then that data has to be encrypted – no question about it. It then says that if you’re storing credit card numbers, then you have to make sure that information is unreadable while it is stored - it gives you four or five different ways of making it unreadable – one of which is encryption.

So, there’s sort of a pain versus gain equation for those security technologies – how much do they actually protect you against what sort of threats and how much of a pain are they to actually deploy?

Deploying network-level encryption is the easiest – you can basically put a box at both ends of the connection. While network encryption is very easy to deploy, it only really guards against eavesdropping on the network. That’s basically a default approach. Nobody in their right minds would send sensitive data over the Internet without using encryption.

As you move up the maturity curve you next get to the notion of protecting data, not just in motion, but also at rest, while it is stored. An obvious situation where data at rest is lost is when stored data leaves the building somehow. It might leave the building on a memory stick, a laptop, or a backup tape. Most companies that know something about protecting data will not allow sensitive data to leave their building without being encrypted.

Of course, mistakes can always happen and employees can take memory sticks home in their bag. Again, encryption used at this level can be very transparent – encrypting a backup tape and then decrypting it if you ever need to recover that data is transparent to all of your business applications – nobody in your enterprise would even know that you’re doing it – so it’s relatively easy, but, of course, it only guards against the media being stolen.

It doesn’t guard against any sort of malicious insider, it doesn’t guard against any persistent threats and it doesn’t guard against any mistaken use by an internal user.

Then you move into the next level, which I think of as being the database, where you’ve moved beyond the realm of data just sitting around in repositories; you’re now looking at situations where data is live.

So, in terms of adding encryption to a database, it’s quite possibly more painful to deploy – it might disrupt some of your applications, it might disrupt the ability to search on data or to sort data. But the increased pain is going to give you increased coverage – for example, it might protect against certain internal attacks. In fact, database encryption was one of the strongest growth areas this year in the Ponemon study compared to previous years.

Then, you go up the maturity curve a step further and you start to think about building encryption into applications themselves. For example, as soon as a credit card number is captured on an Internet website, it’s encrypted and it stays encrypted from that point forward.

Of course, now you’ve got so much broader data protection coverage – your databases, file systems, networks, backup systems – might only ever be exposed to encrypted data because the data was encrypted from the moment it was captured. But that’s a fairly high price to pay in some cases because you’re now changing applications to support encryption.

Finally, you can go the whole hog and do what is called point-to-point encryption, which is where you literally encrypt the data the second you get it, wherever you get it – whether it’s in your email system, or at a Point of Sale device in a store – and it’s encrypted its whole life. If it ever needs to be decrypted then keys need to be requested and they may or may not be granted, which can be very disruptive to the organization. So, in essence, the earlier you encrypt information, the more repercussions you have on your business, but if you can do it right, the protection that it delivers will be much broader.

That’s what I mean by Maturity Curve and of course it gets back to data classification, which, again, means that you don’t need to go to all those relatively painful measures for all classes of data. Only very specific types of data, such as credit card numbers, need to be protected at point of capture.

Think of a pyramid, where the base of the pyramid might be network encryption or storage encryption, which applies to virtually everything in the organization. At the top of the pyramid might be very selective encryption in very specific applications for very precise types of data.

KB: Based on the study, what are the top two data protection priorities for today’s organizations?

RM: Again, it comes down to the data you’re trying to protect. The sort of data protection policies you might have at your fast food outlet might be very different from the policies you have in a cloud service you’re using or in a data center that’s entirely under your control in a secure bunker somewhere.

There’s a chart in the Ponemon study that looks at perceptions around threats. The perceived wisdom is that malicious insiders or hackers is where the issue lies but they actually came out fourth and fifth in order of perceived threats.

The greatest perceived threat – by 30 percent or so – is employee mistakes, just people doing the wrong thing by error because they weren’t trained or they forgot or the process changed and nobody told them.

The second greatest perceived threat, which is actually brand new this year – they’ve only just started tracking it – is disclosure to law enforcement or forensic activities. Sometimes known as e-discovery, these issues occur when somebody comes along and says: “I need to see the data for a particular account” and that data is consciously disclosed – maybe it’s the FBI, maybe it’s a lawyer – and suddenly that data is outside of your control.

This is particularly so with the cloud, where everybody is concerned about data disclosure because you’re using a shared infrastructure, When you’re sharing infrastructure – as you are in the cloud, you don’t know who your co-tenants are, and if the cloud provider gets subpoenaed to deliver data that relates to somebody else that happens to be living on the same disk drive that you happen to be living on, then your data gets disclosed as well.

One of the new drivers for encryption involves trying to get around this issue of e-discovery loss by making sure that even if my data is handed over to the FBI because somebody else did something bad, at least I know it’s useless without the key, at least I would have some control over it.

As I mentioned before, the fourth greatest perceived threat is hacking and the fifth one is malicious insiders, so if you look at the percentages and add it all up, the first three greatest perceived threats are basically all mistake-oriented and overshadow the more commonly cited attack oriented threat by a factor of more than two to one.

KB: Granted, there can be an element of paranoia, but, according to the study, what would you classify as some of the least important features of encryption technology solutions that people seem to get hung up on?

RM: It’s interesting, because encryption is still a relatively immature technology for most verticals and there can be real challenges and pitfalls to deploying it.

Ten years ago, there was a wave of vendors creating their own encryption algorithms and I think that raised some concerns in the user community – you know: “How am I supposed to assess the quality of these proprietary algorithms, how can I as a consumer possibly determine the validity of some vendors’ claims about their special algorithms?” The reality is that there are very few vendors and organizations these days that are promoting proprietary encryption solutions.

I think we’re now at the point where the industry has recognized that there are standards-based encryption schemes that have been well proven, that people have literally been trying to break them for decades and have failed – and the merits of trying to launch your own proprietary system these days are so low, so I think that’s a concern that’s probably overblown these days.

Encryption is perceived as being slow and complicated and it’s certainly true that encryption can have a performance impact on organizations, so again it gets back to this issue of classification. For example, you might deploy encryption at the storage layer and it might have no effect, whereas you might deploy encryption within an application and it might have a significant effect.

I think the issue is a lot less severe than it was 10 years ago. These days, the availability of native embedded encryption technology within databases and storage systems today has far less impact on performance than retrofitting encryption would have had in the past.

The issue that does quite rightly occupy peoples’ minds is that of key management. The old adage is that it doesn’t matter how much you spent on your front door lock if you leave the key under the mat you will have got very little benefit. The same is true for encryption. You can spend an awful lot of effort encrypting data, but if the keys can be found or the keys can be lost easily, then there’s no point.

That’s the Achilles Heel of encryption – the fragility of the key management system. Ten years ago, I think if you had asked people: “What’s the hardest: encryption or key management”, they would have said “encryption.”

These days, encryption is almost perceived to be a commodity, a part of the system you buy, while key management is perceived to be the challenge. Companies can easily end up with tens of millions of keys that are scattered across their enterprise and that need to be both protected and available. If you encrypt a database or a file system or a backup tape and somehow that key gets lost, that data is essentially destroyed.

When you think about key management and the operational and security needs of the business, it gets even more interesting when you think about the cloud, because in that sense you’ve got encryption happening in a different place.

Encryption is happening in the cloud somewhere and the key’s going to be managed in the enterprise, so you’ve got a real abstraction between key management issues and the task of doing encryption. This is becoming the year of key management, if you like.

Download the complete Thales 2012 Global Encryption Trends Study here.

Kim Borg is the Editor-in-Chief at Computer Technology Review. She can be reached at kim_borg@wwpi.com.