It seems that we’re in a popular industry right now. nCipher, a major competitor originating from my homeland, out here in the cold and wet United Kingdom, has gone and picked up another rival, NeoScale, for what an old boss of mine would have referred to as ‘two bob and a conker’, i.e. next to nothing. This is a great move for nCipher, and as competitors we would be right to stay on our toes.

However, whether it is enough to challenge the lead that we seem to be getting in the KM market here, it’s hard to say. With my PM hat on I would say that buying up old technology is never a great way to get a hold in a marketplace, it takes a huge development effort to integrate things properly, and although you inherit customers, you inherit problems, support and maintenance issues. It can leave you further behind than you were when you tried to catch up in the first place. Personally, I’d rather be there from the beginning and do the hard slog of writing it yourself. Like Ingrian has.

I’ve worked with Ingrian for 7 years now, since they first moved into the UK, and before I was working directly FOR Ingrian, I worked for a reseller who brought them into the UK. In 2000, when the offering was little more than a fairly basic SSL accelerator, Ingrian used nCipher cards. We (the reseller) had sold so many nCipher cards that Ingrian wanted our help with their devices.

But, whilst nCipher continued down that route for many years, Ingrian moved, quickly and cleverly, into a market which started off as encryption, and mutated into Key Management, always addressing the needs of the customer as they arose with imaginative and relevant technology. To be honest, they were probably too early for the UK market, I changed jobs a couple of times, including working for another competitor, which also failed to make an impact on the UK market. More recently I worked in distribution, and then for a partner in Spain, but seeing the market heat up brought me back to the cold and wet for another go. This is already a red hot quarter for us over here (in terms of sales, not weather of course), and promises to be a record breaking one for us across the globe. PM is looking busy and there’s talk of new features almost every day.

I’ve seen some very interesting discussions amongst the SEs as recently as today about where we see the product heading in the future, and there’s no shortage of ideas. Security is very exciting at this level, especially to be able to feel as though you are part of something which is making such an impact and a difference to networks all over the world.

Great news from the marketing department tonight (OK, this morning if you’re in Redwood, but it’s dark here in the UK). Ingrian has shipped its 1500th appliance this week, proving that not only is this a mature product, but one which people are using in their droves.

I’ve been part of the push at Ingrian in EMEA for some time, in various guises. I worked for a reseller who brought Ingrian over to the UK 6 years ago, and we didn’t fare very well to tell the truth. More recently I worked for a distributor who carried Ingrian stock, and trained up on it again, started doing some more business with the guys over here, and eventually ended up working here - as I knew I probably would.

I’ve watched this market go from SSL with a bit of encryption, to database encryption and APIs and now to key management. Ingrian has worked it very smartly, but mainly because they’ve always been at the forefront of technology development. I speak to roughly one old SSL customer a month, and every time I hear them say “Wow, I remember how great that stuff was, if your KM is anything like as good, we’ll have some.”

Seems that it is.

There, I’ve said it. It’s been preying on my mind to tell the truth.

The more I visit customers and take their questions, the more I find myself saying ‘why don’t you try it out?’ To be perfectly honest, encrypting data is child’s play, literally. I’ve played with codes and ciphers since I was in short pants, and although the ones I play with (I mean “work” of course) are slightly more advanced these days, the principles behind them are not. So, instead of making them up myself, I use someone else’s codes, Rijndael mostly, with randomised initialisation vectors on columns in CBC mode with PKCS5 padding. Still, all I’m doing is making sure someone else can’t see my data.

All the words and maths seem to put people off, but there’s really nothing to it. When it comes to application encryption there are a million questions about keys, what can I use here when my legacy application uses XXX keys, how long can I make it, can I export it, etc. When it comes to databases there are a million questions about the security of the databases themselves. It’s quite simple, we’re stopping data from being seen by the people who shouldn’t see it. Nothing hard about that.

But what about those keys, and those people? Forget about how complex the keys are to compute for a second, forget about how to ensure your user is the person you think he is, just take it as a given that these things exist in todays networks. There is still another issue. People need keys, some people need more than one key, some need none. Some keys need to be expired, some need to be rotated. All of this needs logging, and in a sensible way, not all in a jumble.

So, we’ve got it covered, but surely that takes a lot of doing? It must take a performance hit, right? I was on a site earlier this week with a pretty poor network setup. I will not name and shame, ever, so don’t ask. 10Mbps/Half Duplex, 7 hops between Ingrian device and database. It was taking half an hour to set up each column encryption. I was pretty unhappy. I left site with a reseller promising to help set it up properly and make sure the customer saw how good we really are.

Today I got a mail: “30,000 records in less than 10 seconds! As you can imagine, the customer is satisfied.” Of course they are. Encryption is easy.

It is interesting to be able to watch a market evolving from the other side of the Atlantic, and easy to seem wise after the event. In Europe we are currently embarking on a period of unprecedented PCI DSS activity. Jon Shaw, Ingrian’s EMEA Sales Manager, was at a PCI event in London earlier today which had initially been planned for a conference room, and ended up filling the same show room that InfoSec is held in every year because of heighened demand. I am so busy fulfilling the SE role in EMEA that we are aiming to get another ‘body’ on board in the region early next year - we have yet to find out how that will work - but needless to say my diary is full until the middle of December as of going to press mid-November, and I still have customers calling for more work.

In the US we are seeing major technologies move into the key management space, HP have now followed Sun and IBM amongst others into an area which is now booming due to the demand created in the large part by PCI and regulations such as SB1386 - the data disclosure bill.

There is still one major issue outstanding however. Now that all of these vendors have created their own solutions, customers are often worried that their key management will become part of a proprietary system. Even corporations which describe themselve as ‘a Sun shop’, ‘an HP shop’, etc. have diverse applications which do, and more pressingly WILL use keys from non-proprietary systems.

To many, this is the appeal of a smaller vendor (small compared to these players at least) such as Ingrian. We cannot yet dictate the market, although we have a mature technology which is always amongst the RFPs, if not the only one who makes it through the selection process more often than not. Maybe that’s why we have always tried to please the market, and continue to do so with connectors available for Oracle on AIX, Solaris, HP-UX, Linux, Microsoft SQL and even some weird and wonderful NCR z/OS databases to the standard PKCS#11 API connector and our own ICAPI connector for building applications in any of the mainstream programming languages (and probably a few others not so mainstream too).

With so much functionality available it would be easy to sit back and relax, be happy with a market which was already coming to us with their problems, but the problems have not ended there. Recently file encryption has become a ‘nice to have’ feature when protecting databases, so of course, we have written one. I have it installed on my W2k3 server at home and although I’m not particularly worried about someone walking off with my disks, it adds a warm fuzzy feeling which we’re aiming to pass on.

The one thing that my application development folks struggle with more than anything else is the problem around encrypting your index values in a database.  Credit Card numbers are often used as the primary key in the databases in my environment and more often than not the value is part of an index to speed up query performance.  If you encrypt the value, now you’ve encrypted part of your index…what then?  How are people getting around this.  I’ve seen the generic marketing answers.  I want to get specific and see some details.  What are people doing?

The current tools for storage encryption are going to change.  Column-level database encryption has a limited future.  Network link encryption isn’t going to be enough.

Let’s look at storage first…it’s real popular right now.  First, I think pretty much everyone agrees that encrypting disk in a co-lo or data center is protection against a forklift.  I’ve said it before, if you’re encrypting disk in your SAN anybody that can read the SAN - good or bad - has access to your data.  It’s a control to protect against physical theft only.  There are some new advances in this area that might make this a little more viable, but I think it is still a short-term option.  That is, unless you have military or other theft deterrent requirements.  Encrypting disk or tapes that move around - where the theft or loss threat is much closer to reality is a different situation.  Pretty soon every tape drive and CDL/VTL is going to be encryption capable.  Where does that leave the current vendors in the storage encryption space?

Column-level database encryption is a big band-aid, in my opinion.  It gives you some extra protection against logical attacks over SAN-type encryption.  But it still doesn’t give you a lot of protection against the insider threat.  Plus, you’re not going to deploy it on your big databases.  One poorly written query and you’re looking at full table scans against the encrypted column.  How long does it take to decrypt 180 million items in that column?  Too many gotchas for this hybrid type approach.

Encrypting “dedicated” or “private” lines, or building B2B-type VPNs is also getting more traction.  Where’s the most risk in a network connection?  At the core or at the edge?  Encrypting from router to router ignores the clear zone on either side of those routers.  And considering that the number of reported breaches across dedicated ISP links is pretty small…if not zero…I think protecting the edge is much more important.  Encrypting end-to-end is going to win out eventually.

Encryption is not the end all solution to protecting data.  All I’m saying is that the landscape is going to change.

So, I have to start this out with the obligatory “I Am Not A Lawyer” statement.

If you’re involved in the security space, you’re probably also involved in compliance.  (What?  Security and Compliance aren’t the same?  No.)  Compliance means different things to different people, but in the broad sense I think of it as the need to follow the rules that you are subject to.  You process credit cards?  That’s PCI.  You handle personal health information?  That’s HIPAA.  And now, are you a merchant in the state of Minnesota?  That’s HF 1758, the Plastic Card Security Act.   Several states have crafted bills in the aftermath of the TJX breach that allow issuing banks (that’s credit card issuing) to recover costs from merchants if there is a breach caused by a merchant.  It’s expensive to reissue a credit card.  The banks don’t want to pick up the tab for reissuing 40 million + credit cards in the near future.  They are counting on merchant breaches happening.  (I am too, by the way.  That’s a topic for another time.)

HF1758 also takes portions of the PCIDSS and makes them law.  The most specific piece of this is defining what people cannot store.  These pieces of data include magnetic stripe data, PIN information, and CVV data.  So, this is a good thing and a bad thing.  Good thing - Because merchants are not complying with PCI in large numbers, this law puts them in jeopardy of fines above and beyond non-compliance with PCI.  Merchants, so far, have not suffered much when they are the source of a breach.  Even TJX sales are up 10% since that breach announcement.  Bad thing - Government bodies are trying to legislate technology and business processes.  I don’t know about you, but I like the government to leave my internets alone.

Here’s a link to the SANS opinion on HF1758.

My team spends a lot of time working with application developers on security topics. For me, I mostly try to convince people that encrypting sensitive data is a good thing. One of my colleagues spends his days preaching the word of secure development life-cycle. Yet another spends his time deploying audit and logging solutions. There’s a lot of work to be done in this day of security compliance. My executives are always looking for the “snap-on” security solution. Can I plug a firewall here? Can I drop in an appliance there? Can I get something to automatically check code for vulnerabilities? And my favorite…Can I get a box to just encrypt my sensitive data without any changes to my business or applications? When I say, “No” I almost feel bad for people because they have been so conditioned to believe that I can buy a box or a kit or whatever to make my security “problem” go away. To be fair…this happens in all the different technology domains. It seems that vendors often feed customers the magic pill and we swallow it. For sure, there are solutions that really do just “snap-on” with very little effort. But I think those solutions probably aren’t providing much benefit.

Encryption really isn’t that different. There are solutions that get you pretty far down the road to “transparent implementation.” But what happens when your application or business process just sucks? Time and time again I run across applications where sensitive data is thrown around like so much chaff. (Insert favorite piece of data…SSN, CC#, DDA, routing numbers, health info, etc) It gets logged, tracked, indexed, and analyzed before anyone realizes that the data is everywhere. You can’t snap encryption into an environment like that. You have to follow the path and figure out where the data comes from, who sees it, and where it’s going to end up. A good crypto implementation is going to require some change - big or small. I’d rather make the changes in my apps and processes and get good security instead of going the easy route with pointless encryption to get the check-mark in the compliance box.

How much sensitive data do you have?  Where is it?  Who has access to it?  If you answered, “I don’t know” three times don’t feel ashamed.  Stand proud in your data ignorance.  I can’t imagine that there are many companies that can easily answer any of those questions.  Where I am, sensitive data is literally everywhere.  I often joke with people that it would probably be easier to pin down where the sensitive data is not.  When data is so pervasive, how do you secure it?

Discuss amongst yourselves…

Something that is commonly said, but rarely understood is “Encryption is easy; key management is hard.” I know I’ve said this many times to lots of different people. I think the most important thing to realize about encryption is that it is absolutely insecure if a key is compromised. This isn’t a breach that most people understand. My executives understand losing a tape is a breach. They sort of understand that systems can be hacked. And execs understand that an evil DBA (no offense to good DBAs) can walk out of the building with millions of credit card numbers. Some people are starting to understand that encrypting data can protect against some data breaches and attacks. If you do it right, even wicked DBAs should not be able to pull massive amounts of sensitive data from your databases in the clear.

So, encrypting data - good. Losing keys - bad. If I roll out all this encryption, I have to do something with all of the keys. If you say PKI, immediately you get a groan for a response. And most of the vendors that use symmetric algorithms have key management baked into the product. But what happens when I have four or five or six or more symmetric deployments. I will end up with four or five or six key management tools or methods. Who knows, if you’re anything like a lot of big companies you might have four or five or six PKI deployments too. I don’t know that there is much in the market today that is capable of pulling asymmetric and symmetric key management together, but finally at long last there are efforts to move towards key management standards. Not that standards are going to solve all the world’s ills, but maybe I can start using one or two key management tools or protocols instead of lots and lots of them.

Here are a some links:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ekmi

http://ieee-p1619.wetpaint.com/page/Key+Management+Subcommittee+PAR+Worksheet

I just joined the OASIS committee in hopes of getting more involved.  And it looks like the committee chair has presented ideas to the IEEE working group.  I hope that the crypto vendors get more involved and plan on supporting the standards that the committee(s) put forward.