Today we announced that Gartner, Inc. profiled Venafi in their recently released Cool Vendors in Data and Infrastructure Protection, 2010 report by Eric Ouellet, et al (Gartner RAS Core Research Note G00174959). This is where the perennially impartial Gartner would like me to state that “this does not constitute an endorsement”. But let’s be honest, when the biggest, brightest and most opinionated kid on the playground says you’re cool…you’re pretty much cool.

The write-up, which is primarily focused on the fact that Venafi provides a software platform to manage encryption centrally in the enterprise, including managing x.509 certificates (e.g. SSL certificates), has three sections, “Why Cool,” “Challenges,” and “Who Should Care”. If you’re interested in reading the research, Venafi is providing complimentary access to it for the next few months (a $495 value).

Click here for the full report.

One of the first issues I tackled after joining Venafi was to align our technology with a well-known category. In late 2005, however, there really wasn’t a category that made sense for us. So after a detailed analysis of what our product did technically, we decided the functions we provided for encryption assets were essentially much the same as what a number of other companies do for other technology assets. We had a software platform that provided asset management, change & configuration management and infrastructure automation functionality for systems that utilized encryption. Most of the vendors who IT Operations people think of when they think of these categories of software are IT Automation or Systems Management vendors.

With that perspective, we decided to attach ourselves to the Systems Management category with a security spin. Thus the term Systems Management for Encryption was born.

Recently, I was talking with our new VP of Sales, Rick McCord, who came to Venafi from LANDesk and before that spent several years with Altiris/Symantec (two of the strongest players in the Systems Management world). Rick asked me why the Systems Management vendors couldn’t simply add a new class of assets, certificates and keys, and begin competing with us. His question makes a lot of sense. After all these vendors have mature software platforms that touch the enterprise from top to bottom managing all kinds of assets. Certainly they could manage encryption assets, however the challenge they would have to solve is that encryption assets need a different kind of care and feeding than most of the other assets in the enterprise, because they are security assets.

To explain the depth of this challenge, I shared the analogy of what it would take for a shipping company to get into the cash transportation business (that’s the armored truck business). There’s a reason you don’t mail cash, and in simple terms it’s because the shipping/mail system isn’t setup to handle that kind of secure shipments.

Imagine if FedEx wanted to start a service to compete with Brinks or Loomis. Nearly every aspect of their operation would have to be reconsidered. They would need different trucks, people, facilities, processes, tracking technologies and more. They would need to work with customers and industry experts to learn the specific idiosyncrasies of cash transportation. In the end, it would require a significant investment.

The same issues arise when you walk into a large bank and start talking about managing their most secure assets: their encryption keys. Venafi has spent years learning (sometimes the hard way) how to manage these assets, and building that functionality into our products.

Of course, we’re not delusional, we know this is just software and there are lots of folks out there who know how to write software. Others will compete. We see the market opportunity, and I expect sooner, rather than later the Systems Management vendors will see it too. In the meantime, however, Venafi is the best armored truck service available.

At its core the PCI Data Security Standard (PCI DSS) is nothing more than a series of guidelines that constitute security best practices. Companies that institute programs to better protect cardholder data can also leverage and extend these efforts throughout their business, ensuring that other sensitive customer, employee and partner data is better protected.

Section two of the PCI DSS standard (requirements three and four of the so-called “digital dozen”) mandates that cardholder data be encrypted when stored or transmitted over open networks. PCI DSS requirement 3.5 and 3.6 mandate that all “cryptographic keys used for encryption of cardholder data against both disclosure and misuse” and that companies must “fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data.”

Earlier this year, Gartner analyst Avivah Litan reported that PCI DSS has been a key driver in security-related spend in recent months (see: “PCI Compliance Remains Challenging and Expensive”). Companies who don’t demonstrate compliance or who experience a breach are paying big dollars as a result.

Yet despite PCI DSS, increased security spend and growing encryption deployments, one questions whether enterprise data is really any more secure? Big company names continue to appear in the headlines because of major breaches, which begs the question, do companies that deal with credit card and other sensitive data actually follow best-practices or even the PCI requirements when it comes to managing their encryption?

Let’s have a closer look. In the same report, Gartner recommends that companies encrypt data in transit—even when the data is being transmitted over internal, private networks. This goes beyond what PCI DSS requires, yet is certainly a best practice. The report also calls out the importance of properly protecting “decryption keys”, which for data in transit means “private keys”. This implies an inherent security risk in poorly managed private keys used to secure network traffic. Gartner states:

“The PCI standard does not require the encryption of data that flows over private enterprise networks; however, Gartner recommends that card-accepting enterprises consider this measure because it renders the data useless if it’s stolen (unless, of course, the thief has access to the decryption key).”

What are typical organizations currently doing to manage and secure their private keys? This becomes an especially important question given that the majority of data breaches have been executed from inside organizations. Let’s take a closer look. When SSL is used to encrypt data in transit, the certificate is used to authenticate the client to the server and then the public key contained in the certificate is used to encrypt a symmetric key that is used to encrypt the ensuing two-way communication. Thus, if you can gain access to the “decryption key”, which in this case is the private key that resides on the server, you can access the symmetric key and decrypt the data. All of this of course could be done asynchronously if the network stream was captured. Thus, if the wrong person has access to or obtains of copy of that key, then the data is at risk.

Sound far-fetched? Check out the attack vector Wired reported that the infamous TJX hackers exploited:

“In the spring of 2005, associates of TJX hacker Albert Gonzales hacked into the point-of-sale system of a Marshall’s clothing store in Minnesota. The hackers pointed an antenna at the store to grab data as it streamed over the store’s vulnerable Wi-Fi network, then used the data to gain access to the central transaction database of TJX, Marshall’s parent company.

Similarly, in mid-2007, Gonzalez’s gang gained access to point-of-sale servers at Dave & Buster’s restaurants and installed packet sniffers to siphon card data as it was transmitted to corporate computers and others for authorization.”

The need to protect these keys with good key management and access control systems from bad guys (the “thief” referenced in the Gartner quote above) becomes very interesting in the context of Gartner’s other finding:

“The Gartner survey found that retailers are mostly concerned about unauthorized access to their systems by insiders, not outsiders…. Insiders typically cause the most damage because they know where to find sensitive corporate personal, financial account and other information.”

And

“As you secure your enterprise systems, remember that insiders with privileged and knowledgeable access can cause significantly more damage than an outside hacker acting alone.”

In most organizations, these private keys are not being protected—from either external or internal threats. In fact, despite best practices and specific key management requirements in the PCI DSS standard, keys are seldom rotated and are frequently protected with the same password across hundreds of keystores.

Who’s managing the private keys to your kingdom?

In the latest installment of our “Simon the IT Dummy” video series, Simon Christopher encounters copies of PFX files on a compact flash card that had been left behind by a fired co-worker (PFX files are encrypted security files that contain private keys). The device also had several spreadsheets on it, which (based on the file names that are legible in the 720p version of the video on YouTube) almost certainly contain regulated data. Simon instantly recognizes  that this was a data breach, as this type of data would never be stored or transported on a digital camera memory card for any official purpose.

As always with the Simon videos, this scenario is admittedly a little over the top, but let’s back up a few steps and talk about why private key security would be an issue. In a public key cryptography scheme, two asymmetric cryptographic keys are used – a public key and a private key. The public keys are used for encryption and are distributed freely to parties who need to send encrypted data. The private keys are used by the receiving party for decryption and therefore must be stored securely to ensure against unauthorized decryption and data access.

I once heard someone describe this scheme using the analogy of a public mailbox on a street corner. Letters can be put into the mailbox by anybody, and they are kept secure and private inside the mailbox. Only the mail carrier has the key to unlock the box and access the letters. Of course, this analogy has its imperfections, but I find it helpful in illustrating the role of the private keys in a PKI scheme, and there are a surprising number of parallels to our encryption world.

First, these keys clearly must be safe-guarded. They are the proverbial keys to the kingdom – whoever has access to the keys can access the data.

Next, I suspect just like in PKI implementations, the same lock is often used on a number of different mailboxes, and multiple copies of the same key are distributed to mail carriers to simplify the process of distributing and managing who gets keys and who can open the mailboxes. From a management standpoint, it would be simplest if there was just one key and lock pair. Then each mail carrier could be issued a key that would open any box they needed to access. Later, if routes or responsibilities changed, nobody would have to sort through and decide which keys to revoke and which to issue. Mail carriers would always have the key they need to do their job. Of course the security challenges to such an approach are obvious, and therefore such a practice would never be allowed in the IT world. Or would it?

Unfortunately, what happens in the IT world is often very much like the process described above. Administrators who setup hundreds and even thousands of systems regularly share keystore passwords (keystores are generally software stores where cryptographic keys are stored). In fact, within IT groups (UNIX sys admin, etc.) keystore, SSH and other system passwords are often shared across a number of systems, devices and applications. In an interesting parallel with the mailbox system, most software-based keystores don’t have the concept of a user account, so any entity that presents the right password is in, and there is no way to tell whether it was a good guy or a bad guy. The mailbox works the same way – anyone with a key is in. You don’t have to be a mail carrier – you just have to get his key (but that’s a topic for another blog).

Finally, there is a big difference between what you need (access, expertise, keys, etc.) to exploit bad private key security and what you need to exploit the mailbox system. In order to exploit either system, you need a key. Once you get the key, however, then you need a mailbox or some data. Getting a mailbox, especially one located in a public place is kind of difficult. But in the IT world, data can be discretely collected and removed from an organization fairly easily—especially if it’s encrypted when it goes out. Perhaps nobody will remove data on a compact flash card, but it’s probably not as far-fetched as it seems.

Now if only there was a software company that could help manage this stuff…

The Payment Card Industry Data Security Standard (PCI DSS) and similar regulations mandate numerous controls around protecting sensitive data, including the management of and access to cryptographic keys. You might be surprised to learn how typical organizations secure and manage these keys—the private keys required to encrypt data in transit. Are these keys properly protected against loss, misuse and theft?

A new on-demand webinar entitled: “The Key Dilemma - Linking Compliance & Encryption Management” addresses these questions. Click here to view the recording and learn how to better protect your data and achieve compliance.

We just uploaded the latest video in the new wave of content in the Simon the IT Dummy saga—our new Don’t Be A Dummy Series. These videos are a little different than the original episodic content we used to introduce Simon (don’t worry, we have more episodic content coming).

The back story behind these is that the Computer Science department at SubPar Community College (a school near NonCorp headquarters where Simon works) asked a few film students to shoot some videos to help their students better understand practical corporate IT life. These film students unwittingly ended up taking advice from the misfits at NonCorp and, well, let’s just say the advice they got isn’t going to do the Computer Science students much good.

We chose Brian Messman’s insights into the mind of an auditor to kick this series off because auditors play such a key role in what we do. Much of the encryption deployed throughout the world’s IT infrastructures is there in response to external mandates or internal policies to encrypt, and systems are audited regularly to ensure they are encrypting critical data.

In Brian Messman’s unique worldview anything that gets you through an audit without too many scars on your back is fair game. In the real world, of course, most auditors are the epitome of moral characters. But an audit can be a major distraction, which is why most IT practitioners want to get auditors out the door as quickly and with as few resulting to-do’s as possible.

Check out Simon’s new home on the web: www.DontBeADummy.org

* At least we hope auditors are only corrupt in Simon’s world.

Last Friday, I wrote a post about the terminology we use in our industry to explain what we do. On Monday, still in the semantics mindset, it occurred to me that although many of our most frequently used industry terms are quite helpful, some are actually very unhelpful.

Before I give the impression I’m throwing my chosen profession under the bus, I want to say that I believe there is a general desire in high tech to use terms that are easily understood, if not self-explanatory. To that end, I think terms like “two-factor authentication”, “one-time password” and “single sign-on” are good at describing what they are and places boundaries on their scope. On the other hand, there are a number of terms that are not particularly helpful at explaining what they mean, and in fact result in placing almost no boundaries on what they encompass.

The first time I encounter a new term, I try to attach it to something I know and understand. One such term that’s gotten a lot of airtime over the past few years is “data loss [or leakage] prevention”. In fact, it’s gotten so much play that most people just refer to it as DLP (I’m sure much to the chagrin of Texas Instruments’ trademark lawyers). But where is this data “leaking” from? And what parts of your infrastructure do you use these types of products to protect? I think this is a good example of a term that is too broad to be instantly meaningful.

As a startup marketer and a former product manager, I understand the importance of having a broad vision and an expansive name for your product or industry’s category that will allow you to grow into being the critical fabric of the entire universe. On the other hand, a category name that is too broad can confuse people, and significantly increases the cost of educating the public on your space.

My current favorite overloaded term is “end-to-end encryption”. When I first heard this term, I drew on what I knew. End-to-end must mean across the entire infrastructure, everywhere data travels and everywhere it rests. So I reached out to Heartland Payment Systems, (one of the most vocal proponents of end-to-end encryption) and said; “we should talk, because we provide ‘end-to-end encryption management’, and you’re going to need that.” The response I received was, “We’re all set. We already have a vendor who does this for us.” I thought, “how can you already have “a vendor” for a problem that crosses hundreds if not thousands of vendors. Then I realized, “I must have the wrong ‘ends’.”

The payment processing industry has used this term a lot over the past 12 months, with Heartland even trademarking the term “E3”. But what does end-to-end really mean? Is the payments world definition of end-to-end encryption part of a larger world where the encrypted email guys’ end-to-end encryption also lives? Does their end-to-end encryption have anything to do with laptop encryption, database encryption, backup tape encryption and all of the other encryption that’s going on from one end of the enterprise infrastructure to the other? Wikipedia is no help – the end-to-end encryption article there talks about encrypting radio transmissions.

It occurred to me that the way the payment industry uses end-to-end encryption might make more sense if it were called point-to-point encryption, but Heartland wants us to understand that point-to-point encryption is inadequate because between the two ends are zones where data may be unencrypted. But whether your data crosses zones of decryption in transit, or stops on islands of decryption at rest, the “end” is still fuzzy. Further, this is a vertical concept with a horizontal name.

So what can we do? Not much, this train has already left the station, but we have been using more clear terminology when we train our sales people, referring to “end-to-end encryption for physical payments”, and we won’t be calling what we do “end-to-end encryption management” anytime soon.

I just finished reading Luther Martin’s clever blog post, in which he recalls people mistakenly writing about “rouge certificate authorities” rather than “rogue certificate authorities”. He recounts how few people got the joke when he peppered the conversation on a mailing list with sarcasm. He said:

I had to add a comment or two to the discussion that didn’t really relate to the security issues that were being discussed. I said that I hadn’t heard of a “rouge CA,” and asked if these were discussed in a standards document that I hadn’t “red”. see: Luther Martin, Seeing Red

That made me think of all the times we’ve had to begin conversations with statements such as, “when we say encryption, we mean technologies that employ encryption for data encryption, authentication, digital signing, and securing lines of communication.” More recently, we’ve been actively talking about the need to securely manage “Private Keys”, and it seems regardless of the technical level of the audience, we always have to clarify that we’re talking about “the cryptographic key used in RSA-based public key encryption schemes to unencrypt things”. Of course when I say that, then I end up having to define “things”… Things include the packet that contains your credit card number or the encrypted signature of an email or document, etc.

When you walk around this industry, the streets are littered with terminology by insiders that’s supposed to be meaningful to insiders, but when you sit in the marketing seat, you realize it’s not meaningful. In the late 90’s when I went from the ecommerce and hosting industry to enterprise software, I encountered the term, “web services”. My first reaction was, “okay, sure they’re talking about services hosting providers offer, like server space, DNS, database, etc.” They were really talking about SOAP, UDDI, WSDL, etc. The term “web service” is intuitive when describing those things, but only when you’re in the right context.

What other terms have you encountered that have vastly different meanings based upon “your” context?

Oh yeah, and one more thing - when I referred to “Luther Martin” above, I don’t mean the contrarian US Founding Father, and I didn’t mistype the name of the founder of Lutheranism, or the American Civil Rights Leader, I was referring to the principal cryptographer at Voltage Security.

1 year
12 months
365 days
8766 hours
525948 minutes

Where do they all go?

This is a question that all individuals ask themselves at some point.  It is almost an epiphany.  How am I spending my minutes?   These minutes are so dear.  Am I wasting them on someone?  Am I wasting them on something?  Am I really taking advantage of the minutes that are mine?

Thanks to societies’ marketing geniuses these questions have already been asked and answered.  Our lives are surrounded by efficiencies to save our minutes.  For example, when was the last time you bought a head of lettuce instead of the triple washed, 7 ply bag of Cesar salad?  How many of us purchase the oil, oil filter and drain plug washer every 3 months instead of visiting the Jiffy Lube?  Be honest, are you one of the 18 million individuals who consider spending $300 on a robot vacuum?  These are successful “minute rescuers” in our daily personal lives.

But what about the workplace?

Think about your job.  Look at your task list.  See anything familiar?  Anything that is a consistent occurrence? Look at the list, any minute wasters?

This is one of the key points of Venafi Encryption Director; it saves your minutes from being wasted on the digital certificate lifecycle.  Millions of minutes.

For example, one private company identified a certificate renewal takes 120-240 minutes.  Multiply those by 1000 for the digital certificates and private keys within the organization and the cumulative minutes explode.  This company determined they waste 120,000-240,000 minutes renewing certificates every year.

The reason Jiffy Lube, bags of Cesar Salad and robot vacuums exist is because our minutes are more valuable than the cost of oil changes, prewashed salad or self cleaning floors.  Our minutes are too precious.

Similarly aren’t your minutes at work as valuable?  Venafi regains those minutes through automation software which manages the digital certificate lifecycle:

CSR creation - submittance to CA - signed new certificate - installed new certificate on new application - notification to all parties.

The entire process can be automated.  Think of getting those minutes back.  Think of the hours which can be focused on securing the architecture.  Think of the money saved for the corporation…

Think of all that prewashed salad you could eat while getting your oil changed.

Independent software reviewer Logan Harbaugh recently completed and published his findings about leading key management vendors for NetworkWorld magazine. As I indicated in an earlier blog, the “shootout”-style review takes a close look at market-leading enterprise key management vendors and their EKM products, including our own Venafi Encryption Director.

The Director-specific product review is here. The report is fair and does a good job of exposing what Director does and what it’s good at (holistic approach, best of breed and manager of managers’ solution for enterprise encryption management–from the desktop to the data center). The article also points out the solution’s low price point andhighlights the many operational and security benefits it provides—including easing audits and ensuring compliance.

As they say, the proof is in the pudding…. It also helps when independent, third-party analysts validate one’s claims.

Here are some of the highlights, taken verbatim from the report:

• “Venafi Encryption Director was the easiest of the three products to deploy.”

• “Because Venafi works in partnership with application and OS vendors, getting Encryption Director to work with any supported application is generally very straightforward.”

• “Venafi can automate the process of installing certificates on supported systems, which is a great benefit in itself. Suppose, for instance, that a decision has been made to move from 1,024-bit certificates to 4,096-bit certificates. Normally this would entail generating new certificates for each system, copying the file to the system and installing it through the application. This entire process is automated, resulting in a huge time savings to the admin. This same automation also applies to renewals of certificates, allowing the admin to regularly update certificates to lessen the possibility of compromised keys.”

• “Reporting and auditing functions work well, and are extremely useful, making security audits much easier in these days of PCI and lawsuits over data loss.”

• “With relatively low pricing that runs $75 to $275 per managed system, Venafi Encryption Director is easy to get started with and very effective.”