Zip compression is very commonly used to send files via email. Not only does zip compression make our email attachments smaller, but the most popular zip compression programs now support 256-bit AES encryption of the contents.  The ability to encrypt Zip files with AES provides a much better level of security than older zip protection methods. In the new release of Alliance FTP File Manager for IBM i we fully support Zip encryption to the WinZip standard. This means that you can create and protect Zip files on your IBM i platform, and then use a variety of delivery methods to get the Zip files in the hands of your customers, vendors, and employees. This will immediately give IBM i customers a new tool to meet compliance regulations.

The new Zip support provides rich capabilities to IBM i users. You can create encrypted or un-encrypted zip archives, include sub-directories, and use wild cards to select files.  When uncompressing and decrypting you can specify any directory as the target for the files. This capability integrates with our automation facilities for processing received files. Lastly, we provide a Windows command line Zip application to help our customers who don’t already have a Zip application.  I’m confident that this new capability will help our customers achieve a better level of security.

The other new security technology in FTP Manager for IBM i is our encrypted PDF support. In this first implementation, our customers will be able to create encrypted PDFs with their own content, and then use the automation facilities to distribute the PDFs via email, FTP, and other distribution methods. Encrypted PDF support includes the ability to set fonts and colors, embed watermark and graphic images, set headers and footers, and create tables and lists. The resulting encrypted PDF file is compatible with any PDF reader that supports the AES encryption standard for PDF. We’ve tested with a wide variety of PDF readers on PCs, Apple Macs, Blackberry, Linux desktops, and so forth. This will give our customers an additional tool to secure their sensitive data.

These new technologies for the IBM i customer will increase their abilities to meet compliance regulations and secure sensitive data. I hope you get the idea that we are dedicated to helping you protect your sensitive data and corporate assets. You are going to see a lot more of these types of new capabilities as we go forward.

Patrick

How fast are regulations changing? Really fast. The Payment Card Industry Security Standards Council will update the PCI Data Security Standard (PCI DSS) this year, and will be on a three year cycle of updates. Merchants accepting credit cards will have about 18 months to implement the changes. State privacy laws are undergoing frequent changes, most of which make the rules more stringent. Minnesota, Nevada, and Washington State have made recent changes. The HITECH Act of 2009 and related guidance further tightens the rules around protecting patient data, and further guidance is expected this year. Last, but not least, the federal government is moving new legislation through Congress to enact a national privacy law.

These changes are coming fast, and they have one thing in common: data protection requirements are getting stronger, not weaker.  Companies and organizations should be paying attention to their data protection strategies now in order to avoid expensive rip-and-tear operations in the future.

One other tendency of the evolving regulations is this: A clear reference to standards for data protection. All of the mentioned standards now make reference to widely accepts standards, usually those of the National Institute of Standards and Technology (NIST) which publishes standards and testing protocols for encryption and key management. Over the last two years PCI (and related guidance from Visa), the HITECH Act, state privacy laws, and other regulations have specifically referenced NIST for data encryption and key management standards.

Companies and organizations acquiring data protection technologies should look carefully at how solutions match up to the standards. And a word of warning here: There is still a lot of snake oil in the data protection industry. Be sure that your data protection vendor can prove that their solutions actually meet the NIST standards. This is actually not hard to independently verify – NIST publishes on-line lists of vendors who certify their solutions to the standard.

Encryption is a well defined technology to protect data through the use of an encryption algorithm and secret key. When combined with proper key management, encryption provides a well accepted method of protecting sensitive data. There is a long history of work by professional cryptographers and NIST on defining how good encryption and key management should work, and you can easily determine which vendors meet the standard through the certification process.

Tokenization is a new technology and lacks the history and standards of encryption, but which incorporates encryption technologies. Tokenization works by substituting a surrogate value (or “token”) for the original data. By itself the token does not tell you anything about the original value which might be a credit card number, patient ID, and so forth. But tokenization requires that you use good encryption practices to protect the sensitive data in the token database. This means you have to use a tokenization solution that meets the same stringent standards for encryption and key management. When acquiring a tokenization solution, you will want to use the same diligence about encryption and key management that you would use for a pure encryption solution – that is, the solution should be built to standards and the vendor should be able to prove it through the NIST certification process.

Remember, a tokenization solution will be IN SCOPE for a PCI audit!

Tokenization standards are still evolving. Bob Russo of the PCI Security Standards Council indicated that the council will be taking up work on this in 2010. Visa just released a best practices guide for tokenization (you can get it here), and you can probably expect the eventual standards to incorporate much of this guidance. Additionally, the X9 organization is also working on standards for tokenization.

In regards to tokenization standards, stay tuned ! Much more is coming our way.

Encryption, tokenization, and key management – this is the trifecta for protecting data at rest. I’ll have more comments in the future about tokenization as we analyze the best practice guidance from Visa and help you connect the dots with our encryption, tokenization, and key management solutions.
Patrick

Encryption is well known technology, has clear standards, and has been in use for data protection for a long time. Most of the compliance regulations (PCI, HIPAA/HITECH, state privacy regulations, etc.) make clear reference to encryption and widely accepted standards. So it is a no-brainer to use encryption. When done correctly, it is going to meet compliance regulations and your security goals.

But encryption has a nasty side-effect. When you encrypt fields in your database that are indexes or keys, you disrupt the indexing capability of the field and you introduce unacceptable performance burdens on your system. Encrypting an index or key field often means re-engineering the application and this is costly and time consuming.

Enter the new kid on the block – Tokenization.

When you tokenize data you replace the sensitive data with a surrogate, or token, value. The token itself is not sensitive data, but it maintains the characteristics of the original sensitive data. It walks like a duck, it quacks like a duck, but from a compliance point of view, it is NOT a duck. Tokenizing data lets you maintain those precious index and key relationships in your databases, and minimizes the number of changes you have to do to your applications.

So, why not use tokenization for everything? Is this the magic bullet we’ve been searching for?

Hold on there, Cowboy. There are some things you should think about.

Tokenization solutions typically work by creating a separate database to store the token and the relationship to the original sensitive data. This means that every time you need to register a new token, retrieve the attributes of the token, or recover the sensitive data, you have to make a request to the tokenization solution to do this work for you. Got 10 million records in your database? This is going to have a major impact on performance. Applications that need high performance may not be the best for a tokenization approach – you might really want to use encryption in this environment.

Then there is the question of compliance. Tokenization is new technology. At this point there are no standards for tokenization solutions, and no reference to tokenization in the published regulations. So, are you really compliant if you tokenize sensitive data? I think so, but you should be aware that this is an unsettled question.

When you tokenize data, you are creating a separate repository of information about the original sensitive data. In most cases you will probably be using a solution from a vendor. Since the tokenization solution contains sensitive data, it will itself be in scope for compliance. Has the vendor used encryption, key management, and secure communications that meet compliance regulations? How do you know? If you are going to deploy a tokenization solution you will want to see NIST certification of the solution’s encryption and key management so that you are not just relying on the claims of the vendor.

Most Enterprise customers will probably find uses for both encryption and tokenization. Encryption is great for those high-performance production applications. Tokenization is great for maintaining database relationships, and reducing risks in the development, test, QA and business intelligence databases. Both can help you protect your companies’ sensitive data!

Patrick

This question usually comes up in the context of an application that is NOT storing encryption keys separately from protected data. For example, Microsoft’s TDE provides a mechanism for database encryption which can be implemented with all data-encrypting keys and key-encrypting keys on the same server.  Of course, Microsoft’s EKM facility lets you define an external key management device, but it is not the default configuration, and not the easy route to encryption. Oracle’s TDE facility is very similar. And IBM’s System I (AS/400) platform has the same types of issues.

So what is a security administrator (developer, compliance officer, CIO, …) to do?

First, I don’t think you are going to find clear guidance on this issue from any of the current PCI, HIPAA, HITECH Act, and state privacy regulations. The best you get is “Use good key management practices” or “Use key management practices consistent with international standards”. Thin gruel if you are looking for clear guidance. As the compliance regulations change over time I suspect we’ll get better guidance, but right now there are not many strong statements about this issue.

So, what to do? Here are my thoughts:

First, some practical advice: For the last 12 to 18 months I’ve been noticing that QSA auditors have been focusing much more on key management practices. Our largest merchant customers are being required to physically separate encryption keys from the data they protect. I’ve even seen this issue come up with Level 3 merchants! If you are into reading tea leaves, you will take this as pretty clear guidance. As you know, you are only compliant when your QSA auditor says you are.

Secondly, there are really good security reasons to separate encryption keys from the data they protect:

• Dual control is an important part of any good key management practice, and almost impossible to do well without a separate of the keys from the protected data.
• When doing routine backups you must separate encryption keys from protected data, again almost impossible to do on a full server backup.
• NIST key management best practices require secure key transport at the time of use – very hard to do unless you have a separation of keys and a secure SSL/TLS channel.
• Key management best practices also call for documented key management procedures and controls. This is really hard to get right without a professional key management system.

Lastly, I’ve really benefited from Bruce Schneier’s practical view of encryption and related technologies. I’m reading his latest book on Cryptography Engineering (co-authored with Ferguson and Kohno), and he frequently points out that a data protection strategy is only as secure as the weakest link. To me, encryption key management looks like the weakest link in most data protection schemes. Moving encryption keys away from the data they protect is a minimal requirement to begin to get better security.

Don’t imagine that the bad guys are not thinking about key management. One of the largest recent data breaches was accomplished through an attack on a key management system.
My advice? If you are doing a new encryption implementation you should put a lot of attention on good key management and separation of keys from the data they protect. You will get better security, and you will be better positioned for the evolution of data security regulations. Regardless of how well you think your data encryption keys are protected, you are going to have to defend this practice to your auditor. It’s getting harder to win this argument.

If you already have a key management solution that stores keys on the same server as the protected data, start thinking about what it will take to change this strategy. I predict you will have to face this problem in the near future.

Patrick

Both long-time Customers and new acquaintances alike responded positively to the news that PTSS has received NIST (AKA fips-197) certification for our AES/400 encryption product.  In fact, at the COMMON conference we announced that we have achieved NIST certification on our database encryption solutions for V5R4, V6R1, and i7.1.  With these announcements PTSS is the only company to receive NIST certification for database encryption on the IBM i – an accomplishment not even IBM has matched. You can see the NIST fips-197 certification list here.  Look for Certificates 1338, 1339, and 1340.

Why you care about NIST
NIST certification is our customer’s assurance that we have “encryption done right”.  The certification process is complicated, arduous, and costly.  Still, it was an easy decision for PTSS to go through that process.  We believe that customers deserve assurances that their encryption software is complete, well tested, and conforms to industry standards.   NIST certification provides that assurance.

By way of example, in just this past month we have bailed out customers who purchased non-standard encryption products that leaves their data isolated and un-shareable.  Software vendors that are new to encryption can make all kinds of mistakes that cause data to be either unreadable on other systems, or subject to brute force attacks, or worst of all, unable to be decrypted and retrieved.

With a NIST certified solution you know that an independent group of cryptographers reviewed the encryption and the decryption software and ran it through a rigorous testing protocol.  You can be confident that this software is secure, scalable, and interoperable with business partners and other business units.  But most of all it is your assurance that your encryption was done right.

A first for you – Guaranteed Encryption
Here is a first for PTSS customers – we guarantee that our NIST certified encryption software meets or exceeds the encryption requirements of PCI, HIPAA, the HITECH act of 2009, and all 44 state privacy laws currently in effect.

We know that the driving factor behind encryption for many of you is compliance with regulations.  We also know that the worst case scenario for an IT team would be having to redo an encryption project because the tools you used were not up to the job.  While some encryption vendors use strange modes and non-standard encryption practices, we’re so confident that our NIST certified encryption will meet these regulation requirements that we pledge that if they ever are found to be lacking we will bring them back up to standard at no additional cost to you.

We believe you have a right to encryption done right, and with this guarantee we’re standing behind that belief.

John Earl, President & CEO

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.

When 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 Patrick Townsend Security Solutions 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 Patrick Townsend Security Solutions 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?

Well, 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.  Many of our Enterprise customers won’t buy a $75 secure USB device without FIPS-140 certification. 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.

Bruce Schneier, the Godfather of encryption, has written about this topic on a number of occasions. I recommend that you read his comments (archived here).  You can also read about encryption “snake oil” here. The article is old, but still relevant today.  How can you know if a product has really been NIST certified? That’s easy. Ignore any vendor claims about this and go directly to the source. AES encryption validations are published on the NIST website (you will find our AES certifications in this list), and FIPS-140 certifications here and FIPS-140 In Process here (you will find our Alliance Key Manager in this list).

Patrick

For most organizations, the entire impetus to encrypt is closely tied to the need to be compliant with one regulation or another.  There is the PCI regulation, the HITECH act of 2009, HIPAA, Sarbanes-Oxley, and a whole host of state privacy laws.  If you are going through the due diligence of database encryption, you sure as heck want to get it right the first time.

A big part of getting it right is using the right encryption tool.  There are plenty of tools on the market that claim to do encryption, and you probably know a clever programmer or two who thinks he can come up with a nifty little data scrambling algorithm that no-one has ever seen before. But encryption — real encryption — demands that we reach for a higher standard.

The U.S. Department of Commerce publishes the definitive encryption standard on its National Institute of Standard and Technology website and to date, hundreds of cryptographic providers have achieved this high standard.  As of this writing, NIST has certified over 1,300 AES encryption implementations.

A Fundamental Truth
Cryptographers do not suffer fools lightly.  Their science is mathematically based and their algorithms are well known and well vetted.  A fundamental truth of cryptography is that real encryption cannot rely on keeping the algorithm secret.  Instead the secret that protects the data is the encryption key, and only the encryption key. Anyone who says different may find themselves on the receiving end of an extra-long mathematical dissertation on the mathematical correctness of accepted encryption algorithms.

When you stop to think about it, this makes perfect sense.  If the world used a secret algorithm to encrypt data, if that algorithm were ever to be discovered then all the world’s data would be at risk.  But if the key is the one-and-only secret that unlocks the data, then a compromised key only puts the data at risk that was encrypted with that particular key. All the other data that has been encrypted with other keys is still safe.  This demonstrates both the wisdom of strong (and open) algorithms, but also the essential importance of strong key protection.

Another benefit of open algorithms is that they are peer reviewed and extremely well vetted.  The AES standard that is the de-facto standard for encrypting data at rest is well known in cryptography and mathematical circles and is recognized the world over as the most effective method for encrypting business data.  Its modes of encryption are well known and proven. And there is a strong body of knowledge about how to correctly implement the AES standard.  From the perspective of a cryptographic (encryption) provider, encryption libraries are not easy to write, but they are known to be solid when implemented according to accepted standards.

Homegrown Encryption
Unfortunately, some software providers seemed to have taken a different road. AES encryption must have seemed too difficult, or too cumbersome, so instead they found loopholes and/or shortcuts to simplify their implementation.  Some software providers use untested software, or unique and un-vetted methods of encryption.  These data scrambling methods aren’t (and never could be) NIST or FIPS certified, but if their customers never ask about certification or independent validation, those providers are not likely to raise the topic.

So we are seeing a raft of uncertified, and un-vetted cipher methods introduced in the market place.  Some, like OMAC, CS, and CWC have languished on the NIST list of “Proposed Modes” for years, while others like CUSP have never even been submitted as a proposed standard.  And while it is possible that one or more of these upstart modes could be better than one of the current, standard modes, there is no way to know this because these new modes have not been properly tested and crypto-analyzed.  Without testing and peer review, each of these modes is just another premature idea that is statistically more likely to be a bad encryption method than a good one.

Show Me the Cert!
Many software vendors are beginning to recognize the value of certifications.  Some claim certifications they don’t actually have (HINT: PCI does not certify encryption software) and some will use confusing language to infer they have achieved levels of certification they haven’t.  Recently I visited a website that claimed (I’m paraphrasing):

Our stuff uses FIPS 140-2 certified algorithms to ensure the highest level of data security.

The NIST AES website displays no record of this company ever having received a certification for any encryption software.  Clearly they recognize the value of certification, but have not yet knuckled down to do the hard work to make it so.  And if you don’t check their supposed “facts,” it’s likely that you’ll soon regret it.

My advice?  When someone claims to be certified for any type of encryption, ask a simple question: “Can you show me the cert?”  It ought to be available on the web, or in paper form that they can show to you so that you know this software has passed an independent evaluation.  If they have a cert, then you can dig down deeper and find out whether the software will fit your needs.  But if they are claiming a certification that they cannot prove, my advice is to keep your hand on your wallet and then run.

The alliance has attracted top tier talent in the security and audit communities, and has published guidance on issues that should concern anyone considering deploying Cloud solutions.

The guide covers three basic models of cloud deployment – IaaS (Infrastructure as a service), PaaS (Platform as a Service), and SaaS (Software as a Service). It goes on to discuss the necessary differences to approaching security in the Cloud. It’s a nicely done, high-level guide to security in the cloud.

Section 11 in the guide is on encryption and key management, which is the focus of our company and products. Their recommendations on encryption are spot-on. Because of co-tenancy and shared resource management on cloud platforms, security professionals recognize that there is an elevated risk of loss. Cloud users need to take extra steps to protect sensitive information. Encrypt data in motion, even between different applications and environments on the same cloud; Encrypt data at rest and in archival storage; Encrypt data on backup media and insure that you have access to the encryption keys in a non-cloud environment.

The recommendations on key management are also very interesting. The alliance has recognized that weak key management is much more of a problem in Cloud environments. Here is a sample and summary of some of their recommendations (you can get the full report at their web site):

• Key stores must themselves be protected in storage, transit, and backup. Encryption keys should never be stored in the clear, and keys should never be stored on the platform where they are used.

• Access to keys should be controlled, and the users of encryption keys should not be the ones storing and managing the keys. This means you should never use native operating system account management as the access control mechanism for key management.

• Secure backup and recovery of key management systems is more important. There are special requirements for backing up key management systems.

• Segregate key management from the cloud provider to avoid conflicts in the event of legal disclosure requirements. This will be a real challenge for companies that use Clouds for substantially all of their operations.

• Insure that encryption adheres to industry and government standards. Of course, the only way to insure adherence to standards is to insist on NIST certification of encryption and key management solutions. For example, FIPS-140 certification should be a requirement for a key management solution.

These are just some of the recommendations in this important guidance. If you are considering the Cloud as a home for you applications and systems, this guide is definitely for you.

We announced the release of our Alliance Key Manager product for direct sales this month at RSA. This follows a year of success with the product in our partner channel. We’ve been developing data security solutions for the cloud for some time, and you will definitely be hearing more from us on this topic  in the weeks ahead.

Patrick

This week I spent time at SHARE, the IBM Mainframe user group and expo, in Seattle. Seattle is close to home and it was great meeting local Mainframe users again.  We’ve been going to SHARE off and on, over the years, and now plan on being there more consistently. We are celebrating 5 years of IBM Mainframe support in our encryption products, and our release of Alliance Key Manager brings one more solution to the Mainframe. Here are some thoughts about SHARE and some of the discussions I had with members.

PCI compliance is getting a lot more attention among Mainframe users. As is the case with almost everyone, encryption and key management are perceived to be the hardest parts of PCI compliance to tackle. I had lots of discussions about best practices for key management and encryption. There are a lot of legacy CICS Cobol applications out there, with a mix of DB2 and IDMS databases.  Our new Alliance Key Manager includes a ready-to-use z/OS library and callable applications to retrieve keys from Alliance Key Manager. Everyone wanted to know the architecture of the interface, and it’s pretty simple. Since AKM’s interface is a wire protocol, we use IBM’s System SSL interface to do secure and authenticated communications with the key server. Customers can use RACF certificate management, which is a big deal for the Mainframe security professionals. It was good to get positive feedback on the approach that we are taking.

It was a lot of fun answering the question “How much is this going to cost?”  “Free” was not on anyone’s list of expected answers. Jaws dropped as the thought took some time to sink in. I got the impression that Mainframe users don’t hear that very often from their vendors. But the pricing model for Alliance Key Manager does not include client-side software charges. All-in-all that might have been the most fun part of the conference for me.

Tokenization was also a big hit for the Mainframe users. Alliance Tokenization can plug in right next to their Mainframes and scale up to mainframe class processing. Tokenization is a great solution for Mainframe customers who want to avoid the database impacts that encryption can cause. There was also an embrace of the idea that you could create a vault of this information on a separate platform, and use NIST-certified encryption and key management to protect the data.

If there is one thing that Mainframe security architects get, it is the importance of NIST certification.  Large Enterprises with in-house CSOs and CISOs have been monitoring the evolution of compliance regulations for some time. They know that regulatory framework is bending heavily towards NIST certification as a strong recommendation, and as a requirement for federal agencies.  Many large Mainframe users now require NIST certification for any product implementing cryptography.

It’s amazing how well the Mainframe is doing with Linux workloads. You can run SUSE and Red Hat Linux on partitions on the Mainframe, and there are a number of companies running hundreds of Linux instances. IBM released a much more powerful IFS processor for Linux environments, and native IBM VM utilities can be used to easily manage the Linux instances through one interface.  An IBM’er told me that 16 percent of new z10 new installs are Linux driven, and one third of new Websphere installations are on Linux on the Mainframe. This segment is hopping.

We introduced PGP Command Line 9 on Mainframe USS a year ago, and just released that native z/OS Batch version this year. This is getting good reviews from customers. Customers like the big library of sample JCL that we now provide, and they like the implementation of key management and configuration in PDS. This makes it much easier to put everything under RACF (or ACF/2, Top Secret) control.

I’m proud of the fact that we support all of our encryption solutions in-house. One reason Enterprise customers are wary of open source solutions is that they are afraid they won’t be able to get timely support if there is a problem. It’s a reasonable concern. I remember once trying to chase down an open source developer and discovered that he’d gone off to a heavy metal concert in Eastern Europe, return date unknown. Arrrghhhh.  That won’t happen to our customers – we support everything we sell right down to the last line of code.

Patrick

In today’s data protection marketplace, the sheer number of solutions available makes it difficult to know who to trust. But when it comes to protecting your Enterprise’s sensitive data, the issue of trust becomes critical. To clear up some of the confusion, customers who need to comply with PCI DSS security requirements should pay close attention to the NIST (National Institute of Standards in Technology) publication 800-57, which lays out the standards for strong encryption and key management. While the PCI Security Standards Council does not yet require strict adherence to the NIST standard, it is clear they are driving in this direction. NIST certification ensures that your encryption solution follows certain guidelines for encryption, decryption, key management, and logging. It’s no accident that all of the encryption solutions offered by Patrick Townsend Security Solutions adhere to this standard.

Below is some of the language from the PCI Data Security Standard that advises customers to pay attention to the Strong Encryption and Key Management standards published by NIST: (emphasis added in bold)

PCI Data Security Standards

3.4 Strong cryptography with associated key management processes and procedures: 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 (Editor’s Note: Not a proprietary or “home-grown” algorithm).

3.6.a Verify the existence of key-management procedures for keys used for encryption of cardholder data. (Editor’s Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov).

3.6.1 Generation of strong cryptographic keys: The encryption solution must generate strong keys, as defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms under “strong cryptography.”

What is “Strong Cryptography”?

Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. See NIST Special Publication 800-57 for more information.

Customers attempting to achieve PCI-DSS compliance should inquire as to the NIST Certification status of any solution they are considering (Editor’s Note: You can check the NIST website for yourself).

NIST certification is time and resource intensive and is not easy to achieve. Frankly some products could never achieve that status without a significant redesign. There are a number of examples of software products that have attempted to achieve NIST certification for two and three years without success.

If you are considering an encryption product for PCI-DSS compliance, ask your vendor what their plans are for NIST certification, and what the results of previous attempts have been.

NIST certification is the only protection many customers have against inferior, or erroneous encryption methods. As standards for PCI, HIPAA, and other compliance measures become more demanding over the years, NIST certified products are your shield against shifting compliance requirements that may invalidate the encryption methodologies of a given software provider.

What does Visa say?

Visa International is pushing the PCI-DSS council to be more rigorous in its data standard. Below are excerpts from a Visa Best Practices document that demonstrates VISA’s commitment to ANSI and NIST Standards with respect to encryption.

The implementation of any data field encryption solution must be done in a strong and secure way to prevent the compromise of card data. With industry standards still in the development phase, that goal can be particularly challenging. In an effort to enhance overall data security in the payment industry and to further the development of data field encryption, Visa has developed best practices to assist merchants in evaluating the new encryption solutions emerging in the marketplace.

All cardholder data and sensitive authentication data shall be encrypted using only ANSI X9 or ISO approved encryption algorithms (e.g. AES). (Editors Note: ANSI embraces this NIST Standard for encryption and key management).

All keys and key components shall be generated using an approved random or pseudo-random process such as NIST SP 800-22. (Editors Note: AKM is certified to these standards).

Any methods used to produce encrypted text of the same length and data type as the original cleartext shall be evaluated by at least one independent security evaluation organization and subjected to a peer review; such methods shall also be implemented following all guidelines of said evaluation and peer review including any recommendations for associated key management. (Our Alliance AES Encryption and Alliance Key Manager solutions have been reviewed by Atsec, a NIST-certified NVLP laboratory).

Devices used to perform cryptographic operations should undergo independent assessment to ensure that the hardware and software they are using is resilient to attack. (Our Alliance Key Manager appliance has been assessed by an independent auditing company Atsec).

In conclusion:

Customers who buy encryption software should keep these points in mind:
1. The PCI-DSS Standard is driving toward the NIST Standard.
2. VISA International is already calling for standards-based encryption.
3. Auditors are increasingly asking for customers to prove their encryption solutions are complete.
4. All PTSS products have been developed to the NIST Standards.
5. PTSS has the only NIST certified encryption solution for data at rest on the IBM i (AS/400 or i Series) platform.
6. All PTSS encryption solutions were developed and are supported in house by their authors. We do not have to reach out to the open source community for technical support.

We are determined that no one should get stuck with an inferior solution simply because they do not know there is a difference, or because they do not think the difference is important. Anyone who is faced with PCI-DSS compliance will want to avoid duplicating effort and expense by embracing the right encryption tools the first time. The right encryption tools are those that have been independently certified as meeting the ANSI and NIST Standards that are increasingly being referenced by PCI, Visa, HIPAA, and other data protection regulations.

If you would like more information about NIST certification or our encryption and key management solutions, please contact me directly.

John T. Earl
john.earl@patownsend.com