Townsend Security Data Privacy Blog

Don’t Forget About FIPS 140-2 and Other Fundamental Key Management Features

Posted by Luke Probasco on Jan 28, 2019 1:04:00 PM

Over the last several years, encryption key management has attained “essential infrastructure” status. When done properly, key management can protect encrypted data - and in the event of a data breach, can even provide a company with an exemption for a breach notification.

Don't Forget FIPS 140-2 and Other Fundamentals I recently sat down with Patrick Townsend, Founder and CEO of Townsend Security to talk about encryption key management and the importance of standards, what to look for in a key manager, and fundamental features of an enterprise grade key manager. While Townsend Security isn’t alone in the key management game, there are a few telltale signs that differentiate a key manager that meets industry standards and one that will leave you with a breach notification on your hands. Let’s jump in.

Hi Patrick. Townsend Security has been in the key management game for close to 10 years now. Back when Alliance Key Manager was brought to market, people weren’t really sure what key management was. Now it is considered essential infrastructure.

Yes, it sure is. Things have changed so dramatically over the last few years. Encrypting sensitive data is now a requirement for businesses who need to meet data privacy compliance regulations. And it is also achieving visibility at the executive level as a part of a GRC (governance, risk, compliance) plan. The landscape really has changed a great deal, and I think organizations are stepping up and doing a better job.

We are also seeing databases implementing encryption directly into the database engine. MongoDB Enterprise is an excellent example of this by incorporating AES encryption into the WiredTiger storage engine and providing KMIP for good key management. Microsoft SQL Server Enterprise has also built the encryption engine right into the database with transparent data encryption (TDE) and provides extensible key management (EKM) for vendors like us to plug in to and allow users to properly manage encryption keys.

Let’s spend a minute on compliance. What regulations require key management?

It is true that there are a lot of compliance regulations and most of us fall under multiple. Certainly, GDPR and the new Australian law have come on board and are affecting the way companies all over the world, even outside of the EU, who are now taking steps to protect that data. Almost all regulations require the protection of data, which encryption can help with. Regarding encryption, from a best practices point of view, if you don’t have proper key management, you don’t have encryption.

PCI DSS and the payment industry has now been with us for a decade and that also drives the protection of a lot of sensitive data. While PCI DSS is a private regulation between merchants who accept credit cards and the industry, it is a strong regulation with strong penalties. Because of the longevity and focus on security, PCI DSS often informs other regulations and corporate governance boards.

While we live in a very complex set of compliance requirements, there are fortunately some similarities. When we set out to protect sensitive data, and do it right, which I am sure you know by now means based on standards and security best practices, we find business meeting a broad set of regulations.

As I mentioned earlier, key management is considered essential infrastructure. Back when Townsend Security first entered the market, there were just a few options for the enterprise to choose from. Today, options have dramatically increased. With that said, there are a few ways to distinguish a key manager that meets industry standards and one that will leave you with a breach notification on your hands.

There are a few key quality indicators when assessing key management systems. First off, a key management server must be validated to FIPS 140-2. That is the US and Canadian standard for cryptographic modules and it is just a fundamental indicator of the seriousness of a company and its ability to build good key management solutions. Unfortunately, there are claims of FIPS 140-2 compliance by vendors who have systems which have actually not completed a validation. It’s always a good idea to ask your key management vendor what their certificate number is so that you can look it up yourself on the NIST website. Additionally, key management vendors should be able meet KMIP requirements by demonstrating interoperability. These sorts of validations and certifications show that a key management vendor is stepping up to the technical requirements that customers expect.

Finally, there are individual specific validations to regulations. Our key manager, for example, has been through a PCI DSS validation with a QSA auditor and with VMware. You want to avoid solutions that are simply “key storage” which haven’t been validated and there has not been external review and validation of the cryptographic approach. It is incredibly easy to get encryption and key management wrong from a technical point of view.

Third-party attestations and validations are critically important. You are putting your digital assets, not to mention your company’s reputation, at risk when you use a poor quality key management server (KMS). Fortunately, today there are very affordable solutions available everywhere from a traditional hardware security module, to VMware, to the cloud. 10 years ago, key management servers where terribly expensive.

Yeah, I have been seeing key managers hitting the market that range from open source to cloud service provider (CSP) provided. Some key managers will even claim FIPS compliance when a simple check with NIST shows them nowhere to be found. You also get providers who claim FIPS compliance because they are using a module that has been through a validation, which as I am sure you can tell us more about, doesn’t make your solution compliant.

That’s right. Unfortunately, there is still a fair amount of snake oil in the industry. People claim FIPS 140-2 compliance, but haven’t fully been through the process. As you mentioned, claiming one component as being FIPS 140-2 compliant does not make your entire solution compliant. I like to say, “I drive a Toyota. If I put a Jaguar hood ornament on my car, it doesn't turn my car into a Jaguar. It is still a Toyota!” There is a lot of language used by some solution providers that just isn’t accurate and should be verified before choosing a solution.

You also talked about governance. Let’s take a look at the recent Marriott/Starwood breach. There was an interesting statement where they said “we can’t be absolutely sure that the encryption keys weren’t lost.” If you are using enterprise level key management systems, you have monitoring and audit trails that will show if keys have been retrieved. By them not knowing, it is easy to surmise that they weren’t adequately protecting our information. This was a failure of governance in regards to critical security infrastructure. We might not be talking about the breach right now had they had industry standard key management in place.

Changing gears a little, we have in the past seen cloud vendors offer key management systems in their shared environments. Multi tenant key management presents a concern for enterprises. Just last week I had a conversation with a security professional from a global enterprise who said, “for us, trust is paramount to our brand. We will never allow encryption keys to be stored and accessed by a cloud vendor.” I thought it was a very interesting statement and completely lines up with other enterprises that I speak with.

There is also a bit of confusion on the term KMS. For example, VMware defines KMS as a Key Management Server. Amazon, on the other hand, defines their KMS as a “Key Management Service.”

Well, there is a bit of confusion on this isn’t there? A true enterprise key management system (KMS), is responsible for the entire lifecycle of an encryption key - from generation where admins create provably strong keys, to storage, to provisioning applications and users who need the keys, all the way through to the archival and destruction of the keys. Key management systems manage all of those phases according to industry standards.  

A key management service can better be defined as storage service and offers a mix of capabilities. Some are services that are shared, multi-tenant environments. CSP key managers often work this way (think AWS KMS, Azure Key Vault). Many services don’t give you full access or control over a key’s complete lifecycle. Some services allow you to bring your own key, but then bring that into their own infrastructure, where you then share administrative access and control.

It is very important to know that if you are truly trying to do security the right way, you need a key management system that is built to industry standards and validated to industry standards. One last point, it is possible to do key management correctly in the cloud. There are third-party key management offerings that can be found in the marketplace that meet all the standards that we have been talking about, and are dedicated to you and only you. Our Alliance Key Manager is one, for example.

A feature that we are very proud of with our key manager is that it runs the same software in the Cloud, VMware, or as a traditional hardware security module (HSM). We have customers setting up hybrid cloud/on-prem deployments or even cross-cloud. The way we license our key managers works really well for the modern enterprise which needs a predictable, low TCO. With Alliance Key Manager, there are never added fees for additional databases or applications.

To hear this conversation in its entirety, download our podcast Don’t Forget About FIPS 140-2 and Other Fundamental Key Management Features and hear Patrick Townsend further what enterprises should look for in a key manager, the importance of standards, and other fundamental features of an enterprise grade key manager.

Don't Forget FIPS 140-2 and Other Fundamental Encryption Key Management Features

Topics: Encryption Key Management, FIPS-140

Why Encrypt Data in Your Drupal Websites?

Posted by Liz Townsend on Oct 3, 2014 10:44:00 AM

The internet has become a portal for the transmission and storage of sensitive data. Most websites today gather information from potential or current customers, clients, and users. From credit card numbers to email addresses and passwords, few websites exist today that don’t collect some sort of personal data. Therefore, website developers are becoming more and more interested in learning how to build websites that can easily encrypt sensitive data that their client’s website may be collecting. Drupal Developer Program

Encryption isn’t as widely used at the application and module level in websites as it probably should be. Protecting sensitive data using strong encryption from the moment a website accepts a customer’s information, and throughout transmission and storage of that data is the only method to ensure that data is never compromised. This is critical for websites using commerce modules or forms that collect a person’s health information, financial information, or other personally identifiable information (PII); and for businesses who wish to avoid a data breach.

As Drupal grows and more Drupal developers are beginning to interact with larger clients, the need to provide strong security to those businesses grows as well. The need for encryption will continue to grow as potential clients ask Drupal developers for standards-based security solutions that will help them meet compliance regulations and mitigate risk.

  • Government websites, for example, will need to pass FISMA regulations around encryption.
  • Large retail websites will need to pass Payment Card Industry Data Security Standards (PCI DSS).
  • Colleges and Universities have multiple compliance requirements, as well as FERPA, to adhere with.

Helping clients meet compliance regulations will also require, in some cases, the need for encryption key management. Historically, developers only had three choices for encryption key storage: they could store the key in a file protected on the server, in the Drupal database, or in Drupal’s settings file. None of these options are secure, and would not meet several compliance regulations and general security best practices.

Encryption key management is more than a “key storage” solution. An encryption key manager protects encryption keys on a separate server (located in the cloud or as a physical Hardware Security Module (HSM) or in a (VMware) virtual environment) that implements control layers such as dual control and separation of duties. An encryption key manager manages encryption key creation, deletion, lifecycle, rollover, and archival. Key managers that are FIPS 140-2 compliant have undergone NIST validation and are based on industry standards. Choosing an encryption and key management solution based on standards will ensure your solution will stand up to scrutiny in the event of a breach.

If you are a Drupal developer, you can now join the Townsend Security Drupal Developer Program, work with our encryption and key management technology free of charge, and learn how to secure sensitive data in Drupal for your clients concerned with security.

Using Key Connection for Drupal, the first encryption & encryption key management module, Drupal developers can now build NIST compliant AES encryption and FIPS 140-2 compliant encryption key management into their Drupal websites.  

Just click below to sign up:

Developer Program Encryption  

Topics: Encryption, NIST, Developer Program, Encryption Key Management, FIPS-140, Drupal

Dreamforce to You: Protecting Sensitive Information

Posted by Luke Probasco on Jan 17, 2012 8:04:00 AM
Dreamforce to YouAs the social revolution moves into the business world, protecting your data is more important than ever.  This was a key takeaway for attendees of the recent “Dreamforce to You” event in Seattle, WA, hosted by Salesforce.

Similar, yet smaller in scale to the Dreamforce conference held annually in San Francisco, this event brought together sales and marketing professionals who use Salesforce.com (a cloud-based Customer Relationship Manager) to see what is new with the CRM, how it can help you do your job better, as well as allow attendees to network with peers.  Additionally, Peter Coffee, an IT visionary who acts as the VP and Head of Platform Research at Salesforce.com, delivered an inspirational keynote titled “Toward the Social Enterprise: Trust; Vision; Revolution”.

The focus of both Dreamforce and “Dreamforce to You” is that by and large  business is embracing the social revolution.  Whether you are Bank of America and helping your customers find the nearest ATM or are collaborating with co-workers internally using social tools, businesses are migrating to the social world.  During the keynote, Peter Coffee presented a slide titled “Social is a model, not an app.”  By being social, businesses are able to work more efficiently and reach more customers in ways that were never thought possible.  “Salesforce is not just using social tools but instead is driven and formed by the social network.”

As Peter Coffee continued to discuss cloud computing, the future of IT platforms, and how businesses are “going social”, he conveyed a key concept – companies need to protect their sensitive information.  

Insist on NISTWe couldn’t agree more.  As a security company, this is something we have been saying since the beginning.  We have offered NIST-validated AES encryption for all the major enterprise platforms for over ten years, been securing managed file transfers with PGP encryption, and recently stepped up our game with a FIPS 140-2 compliant encryption key management HSM.  Simply put, we are helping organizations protect their sensitive information and meet compliance regulations with certified encryption solutions.

Occasionally we hear “I don’t need encryption, nothing can get inside my network” (De-Perimeterization concept). The truth is, no matter how many of the latest and greatest network security devices you implement, there is still nothing as fail-safe as properly encrypting your data.  As keynote speaker Peter Coffee would say about investing in the wrong technology, “doing it better is still doing the wrong thing.”

For more information on data privacy, download our podcast Data Privacy for the Non-Technical Person.  Patrick Townsend, our Founder & CTO, discusses what PII (personally identifiable information) is, what the most effective methods for protecting PII, as well as the first steps your company should take towards establishing a data privacy strategy.

Click me

Topics: NIST, De-Perimeterization, Data Privacy, Trade Shows, FIPS-140, AES Encryption

FIPS-140 Certified Encryption and the "Aha" Moment

Posted by Patrick Townsend on Jun 16, 2011 8:28:00 AM

I believe that every individual or company that attempts to bring encryption products to market experiences an “Aha” moment. This is the moment when you realize how very difficult it is to get encryption right, and how many ways there are to get it wrong.

It’s not just that encryption is complicated (it is; to a non-mathematician the algorithms can be mind-boggling). It’s that there are so many aspects to doing an encryption implementation correctly that the likelihood of errors is high even for the best-intentioned and most knowledgeable developers. This “Aha” moment can be dramatic. It happens when you see all of your limitations clearly and you know that you are facing a crucial challenge.

However, what a person or company does after this “aha” moment says everything about their character and the quality of the products they bring to market.

NIST EncryptionWhen I had this “Aha” moment years ago, I realized that our company had to radically change how we approached the development of our encryption and key management products. I knew that we had to step up to much higher standards, and change how we looked at our own products. But where does one go to figure out how to do encryption right? Fortunately, our company had several good enterprise customers who helped point the way. Enterprise security architects directed us to the National Institute of Standards and Technology (NIST) web site and the FIPS-140 certification process. The NIST and FIPS-140 certification outline the proper standards and best practices for encryption, decryption, key management, and logging.  So began the complete transformation in how we bring Townsend Security encryption products to market.

It wasn’t long, however, before the “Aha” moment was followed by an “Oh no” moment.

It quickly became clear that there was a large body of published guidance on the standards and best practices for encryption and key management. This stuff would fill a small library. And it was intense reading. This was not “Dick and Jane” beginning level stuff. It assumed that you started at a pretty advanced point in your knowledge of encryption and cryptographic module implementation. Not only are there published standards, but there are well-defined test and certification protocols.  And these tests were not going to be easy to pass. These tests are only conducted by a small number of certified labs (See NVLAP), the tests are detailed, complex, and designed to detect even the most minute errors that could cause encryption algorithms to fail.  Certification also means that you must undergo a stringent review of the encryption source code and your development practices.

This was the “Oh no” moment. This process was going to hurt.  It was going to be expensive, time consuming, and mentally taxing. And (at least initially) it was going to slow down our release schedule and increase our time to market.  There was also the concern that some competitors would rush to market faster with whiz-bang features that impressed customers in the demonstration process, but were of less importance to encrypting data.

This was going to be a huge undertaking.  I huddled with our development team. I huddled with our sales and marketing team. I took a long walk.

It was clear to me that this was a decision that would define who Townsend Security would be as a company, and it would illuminate how we really feel about taking care of our customers.  Were we really committed to doing security right and providing complete solutions to our customers?  Or were we willing to scrape along the bottom with inferior products that could be sold to less sophisticated customers?

FIPS certifiedWell, you already know how this came out. In the end I could come to no other conclusion.  We would either do the right thing, or get out of the security market altogether. We’re still in, so you know that we made that commitment and investment in NIST certification of our correctly implemented encryption solutions. We did learn a lot about encryption development processes and best practices. And I must say our products are so much better for it.

As you know, we made a substantial investment in the certification effort (we still do), and we do have some competitors, especially in the IBM System i (AS/400) marketplace, who claim to have jumped ahead of us.  But I know how dramatically our certification efforts improve our products, and I know how much better off our customers are because of it. Customers who have a NIST certified solution will be protected from harsh regulations, those who put their trust in non-certified solutions will find themselves at the mercy of ever evolving regulating standards.  As these compliance regulations evolve and incorporate standards and independent assessment in their guidelines, our customers will benefit from our efforts. And as the attacks on our protected data get ever more sophisticated, we will see poorly crafted encryption and key management products easily broken with heartbreaking losses for the companies involved.

So, I am a converted believer in the independent certification process.  No one believes that independent NIST certification is a guarantee of perfect security. But no one who has been paying attention believes anymore that a security product should be trusted without it.  We believe the encryption and key management you trust to protect your entire Enterprise database should be equally (if not more stringently) proven and validated.  Click here download a free 30-day evaluation of our NIST-certified AES encryption - available for all Enterprise platforms (Windows, UNIX, Linux, IBM i, IBM z).

Patrick

Click me

Topics: Encryption, NIST, FIPS-140

AES Encryption Performance

Posted by Luke Probasco on Apr 12, 2011 8:48:00 AM

AES Encryption Performance: Avoid the High Cost of Poorly Performing Encryption Solutions

AES EncryptionAES encryption has become the de facto standard for protecting data at rest in databases and unstructured data such as flat files, messages, EDI, and XML documents.  As enterprises deploy data security solutions to meet compliance requirements, they are frequently surprised by the performance impacts of encryption. Inadequate attention to encryption performance can lead to increased costs, delayed or failed projects, compliance failure, reduced flexibility to meet competitive challenges, and exposure to legal liability.

Whether you're evaluating an encryption solution or already encrypting data, these tips about encryption and performance will help ensure you have the right solution in place. 

Encryption - A Resource Hungry Application

By its very nature, encryption and decryption are resource intensive processes. Encrypting a simple credit card number requires many thousands of computer instructions. These instructions merge the input data with an encryption key using a large number of computer instructions to produce the secured data (called the “cipher text”). Because of the large number of computer instructions, an enterprise customer will experience increased utilization of computer resources and a need to consider adding additional capacity.

Ask for performance metrics

Armed with the knowledge that encryption performance is important, you can take action to avoid potential problems. Before acquiring an encryption solution, ask your data security vendor to provide performance metrics for their solution. How long does it take to encrypt one million credit card numbers? Can they provide you with source code and demonstrate this performance on your server?

The Hidden Costs of Encryption

Poorly performing encryption solutions can come with steep price tags as you secure more data in more places. You may have to add additional memory and increase the number of processors to handle the demands of encryption. As you upgrade your server hardware, the operating system vendor and application software vendors may increase the license fees they charge for their software. These cost increases may ripple through your backup and high availability systems. On top of increased hardware and software, your human resource costs also increase as you deploy larger and more powerful servers.

Are Network Encryption Devices a Good Idea?

Some security vendors provide encryption solutions on an external server as an encryption appliance. Each time your application needs to encrypt or decrypt data, a connection to the server is created and the data is transferred to the server for the encryption operation. Be sure to understand the maximum encryption rate of these types of appliances when doing a large number of operations. if it takes 5 milliseconds to transfer data to a server for encryption,
and 5 milliseconds to return the encrypted data, that 10 milliseconds can represent a performance problem.

Test Drive - not all AES encryption solutions are the same

Townsend Security's proven AES encryption solution encrypts data 94x times faster than the competition.   Request a free 30-day trial of our popular Alliance AES Encryption and see for yourself.

But don't just take our word for it, read what Staples has to say about their experience with our AES encpryption solution.

Case Study

AES PerformanceA large multi-brand retailer, that sells its products online and in traditional retail outlets needed to meet PCI Data Security Standards for protecting customer credit card information. After evaluating several different vendors for performance they decided on AES Encryption from Townsend Security.  They deployed the Alliance AES/400 Encryption solution to protect sensitive data in DB2 database files and in a variety of unstructured data files and were able to achieve PCI compliance in record time.

Townsend Security Can Help

The best way to secure sensitive information is with strong encryption and key management. Townsend Security provides NIST validated encryption and logging solutions for the enterprise. Our encryption, key management, tokenization, and logging solutions protect sensitive data from loss, whether it is at rest or in motion.  With NIST validated and FIPS 140-2 compliant certified solutions, Townsend Security meets or exceeds the standards in PCI, HIPAA/HITECH, and state privacy laws.  Click here to download a free 30-day trial of our popular Alliance AES Encryption.

Topics: NIST, Alliance AES/400, Encryption Key Management, Case Study, Performance, FIPS-140, AES Encryption

Non-Standard Encryption – Now That Bites

Posted by Patrick Townsend on Feb 11, 2011 1:33:00 PM

CUSP EncryptionIn our encryption practice we often help customers integrate the exchange of encrypted data between different applications within the organization, and between their own applications and a vendor’s or customer’s application. It is truly amazing to me how often we encounter non-standard encryption that makes this integration very difficult. The problem is not the lack of standards for encryption. Most compliance regulations provide clear guidance and references to encryption standards. Here is what the PCI Data Security Standard (PCI DSS) Navigation Guide says about encryption (my emphasis):

The intent of strong cryptography (see definition and key lengths in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms) is that the encryption be based on an industry-tested and accepted algorithm (not a proprietary or "home-grown" algorithm).

Strong Encryption:
Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher). See NIST Special Publication 800-57 for more information.

The problem seems to be a general lack of knowledge about encryption. And this applies to some vendors of encryption solutions. Here are a couple of examples:

One of our customers was having trouble decrypting a field with our software that was encrypted on a Windows server with “256-bit AES using CBC mode”. That seemed to be a pretty straight-forward task. Yet we couldn’t get the data decrypted properly. The output just looked like garbage. We spent a fair about of time with the customer verifying that they had the right decryption key, that the initialization vectors for the decryption were specified correctly, and that our software was being used correctly. But nothing was working. We then asked the third party software vendor to share their AES source code with us.  In this case the vendor was very accommodating and let us review their source code implementation of AES encryption.

Voila! The source code showed that the implementation was using a 256-bit block size for the encryption algorithm. The AES standard (FIPS-197) requires the use of 128-bit block sizes. The use of the larger block size meant that this was not even AES encryption according to the industry standard. The vendor fixed their implementation and the project was successful. But our customer spent a lot of time and money resolving the problem.

Another example of getting into trouble occurred with a customer who deployed an AES encryption solution that used the CUSP mode of encryption. This rang alarm bells right away.  We knew that CUSP was not one of the NIST approved modes of encryption, and we had never encountered it before. We quickly learned that CUSP stood for “Cryptographic Unit Service Provider” and was implemented by IBM in a couple of their server products. This customer had a couple of problems. CUSP mode was not a standard mode of encryption, and data encrypted with CUSP was not going to be decrypted by any of the standard open source or commercial products in the market. So this customer was locked into an incompatible encryption strategy.

The second problem is that the CUSP mode of encryption is a proprietary protocol.  The PCI DSS clearly states that strong encryption must be based on industry standards and not proprietary protocols (see above).  As I interpret the PCI DDS requirements for encryption, a customer using CUSP mode would be out of compliance. That’s going to hurt the next time a QSA takes a hard look at your encryption implementation.  We recently published a white paper on the weaknesses of the CUSP mode of encryption.  Click here to download it.

One way to insure that your AES encryption software is compliant is to look for a NIST certification. A NIST AES Validation certificate, or a NIST FIPS-140 certificate, is pretty good assurance of compliance. The FIPS-140 certification process requires AES Validation, so that certification is incorporated by reference. That’s why either certification will give you the assurance that AES encryption is being done according to the standard. Lacking certification, you are relying on the promises of a vendor or developer who may be ignorant, or have a motivation to be less than forthcoming. Not a good situation to find yourself in.

Both of these customers spent a fair amount of money fixing the problem.  An entirely avoidable expense.

Patrick

Topics: Encryption, NIST, CUSP, PCI DSS, AES, PCI, FIPS-140

Encryption Key Management: Top IT Initiative

Posted by John Earl on Feb 11, 2011 1:13:00 PM

encryption key managementI just returned from a trip to Europe and Encryption Key Management was a very hot topic.  This is a topic I very much like to speak about, given our recent release of Alliance Key Manager.  It still surprises me how many conversations I had with technology companies who understood the need to have a proper key manager either embedded within or integrated from the outside of their program or appliance.  There are, I think, a couple of reasons for this phenomena.  

First, many organizations are taking the step to encrypt sensitive data that used to be stored in the clear.  Protecting data is an important IT initiative these days, and one of the absolute best ways to protect data is to encrypt that data.  But as IT teams take on their encryption initiatives, somewhere in the middle of their first encryption project an important realization dawns upon them: After you encrypt the data, the data is only safe if you protect the encryption key.  At this point some organizations will put a temporary fix in place and "hide" the keys as best they can on the same server as the data, but they know this is wholly unsuitable and that a more secure and more permanent solution must be found.

The second reason that I think key management has become such a hot topic on this trip is because of the increased number of compliance regulations around encryption key management.  In October of 2010 the PCI-DSS 2.0 standard was released and in it is call for organizations that store credit card information to use a certified key management solution that is separated from the data, includes robust auditing capability, and supports separation of duties and dual control (more on those topics perhaps in another blog post).

From my perspective then, we appear to have just the right solution at just the right time.  Having recently received our FIPS-140-2 certification for Alliance Key Manager in the U.S. Mail, we're in a celebratory mood here at Townsend Security and it is good to hear all our friends in Europe endorse the time and effort our team has put into this fabulous offering.

John Earl

Topics: Alliance Key Manager, Separation of Duties, PCI DSS, Encryption Key Management, FIPS-140, Dual Control

PCI DSS 2.0 and Encryption Key Management

Posted by Patrick Townsend on Feb 11, 2011 11:46:00 AM

2014 UPDATE:
No Significant Changes around Key Management in PCI DSS v3.0

PCI DSS 2.0 encryption

The new PCI Data Security Standards (PCI DSS v2.0) are here and I’ve gotten a lot of questions about the changes related to encryption key management. Because we work with a lot of companies going through PCI compliance audits and reviews, the new standards just confirm the trends we’ve seen over the last few months on how QSA auditors and security professionals view encryption key management, and what they see as the minimum requirements for managing keys.  The clear trend is to require that encryption keys be stored separately from the data they protect, and to make sure that the people who manage encryption keys are not the people who manage the protected data. Let’s look at why this is happening.

PCI DSS Encryption Key Management Compliance While most of the largest merchants in the Level 1 category are already using professional key management solutions to protect encryption keys, the trend over the last 12 months is to require smaller merchants in the Level 2 and Level 3 categories to also use better key management practices, too. So, what are the parts of PCI DSS that are driving this change?  It all has to do with industry best practices for encryption key management, and the concepts of Dual Control, Separation of Duties, and Split Knowledge. These best practices and concepts work together to form the basis for determining if your approach to key management will pass muster.

First, what is the source of industry best practices for key management? Here in the US, the National Institute for Standards and Technology (NIST) is the most common source for guidance on best practices. The NIST special publication SP-800-57 provides specific pointers on how best practices for both procedurally managing encryption keys, and what to look for in key management systems. In these documents you will find the genesis of most standards regarding encryption key management, including the concepts in PCI DSS 2.0 Section 3.

Next, it is important to understand Dual Control, Separation of Duties, and Split Knowledge. These are all clearly defined in the PCI DSS standard and in the accompanying PCI DSS glossary. I’ve extracted the exact definitions below, but I’ll recap them here from the point of view of key management.

Dual Control means that no one person should be able to manage your encryption keys. Creating, distributing, and defining access controls should require at least two individuals working together to accomplish the task.

Separation of Duties means that different people should control different aspects of your key management strategy. This is the old adage “don’t put your eggs in one basket”. The person who creates and manages the keys should not have access to the data they protect. And, the person with access to protected data, should not be able to manage encryption keys.

Split Knowledge applies to the manual generation of encryption keys, or at any point where encryption keys are available in the clear. More than one person should be required to constitute or re-constitute a key in this situation.

What are the practical implications of these best practices and core concepts?  One of the practical implications follows from a common fact of system administration. On all major operating systems such as Linux, Windows, and IBM System I (AS/400) there is one individual who has the authority to manage all processes and files on the system. This is the Administrator on Windows, the root user on Linux and UNIX, and the security officer on the IBM System i platform. In fact, there are usually multiple people who have this level of authority. In one study by PowerTech, the average IBM System i customer had 26 users with this level of authority!

That’s why storing encryption keys on the same system where the protected data resides violates all of the core principles of data protection, and that’s why we are seeing auditors and payment networks reject this approach. If you haven’t faced this issue yet, your day is probably coming. Now is the time to start planning on how to deal with the problem.

Over two years ago we saw this trend developing and took action to help merchants be prepared for proper key management. We created the Alliance Key Manager solution and released it to our partner channel in 2009. This year we released it for direct sale, and last week we received our FIPS-140-2 certification from NIST. Over 1,000 customers are now using AKM to protect their encryption keys with a solution that provably meets industry standards.  Our encryption products have been updated to use this new key management solution, and we are moving customers forward to compliance. It’s been a long, hard slog to NIST FIPS-140 certification, but I think our customers will benefit from the effort.

I hope this has been helpful in clarifying key management best practices. For more information on PCI and key management, download our podcast titled "Key Management Best Practices: What New PCI Regulations Say." Please let us know if you have any questions.

Click me

---

From the PCI DSS version 2.0 Glossary:

Dual control
“Process of using two or more separate entities (usually persons) operating in concert to protect sensitive functions or information. Both entities are equally responsible for the physical protection of materials involved in vulnerable transactions. No single person is permitted to access or use the materials (for example, the cryptographic key). For manual key generation, conveyance, loading, storage, and retrieval, dual control requires dividing knowledge of the key among the entities. (See also Split Knowledge).”


Separation of Duties
“Practice of dividing steps in a function among different individuals, so as to keep a single individual from being able to subvert the process.”

Split knowledge
“Condition in which two or more entities separately have key components that individually convey no knowledge of the resultant cryptographic key.”

Source documents are available online at www.pcisecuritystandards.org

Topics: Compliance, Encryption, Key Management, PCI DSS, PCI, FIPS-140