Townsend Security Data Privacy Blog

Patrick Botz, founder of Botz and Associates and former Lead Security Architect at IBM, recently published a White Paper in conjunction with Townsend Security discussing dual control, split knowledge, and separation of duties--three critical controls needed to protect encryption keys and encrypted data on the IBM i platform. These controls are considered “best practices” in the IT industry, and it is common knowledge amongst security professionals that without these controls in place, any organization could be at risk for a major data breach.

Just like financial controls that are put in place to prevent fraud in a business, these concepts are used in IT security to prevent data loss. As data breaches are reported in the news almost every day, we can easily see the consequences of data loss: public scrutiny, hefty fines, lost business, and litigation are just a few of the ramifications. Implementing these controls reduces the potential for fraud or malfeasance caused by the mishandling of data or a data loss event due to hackers, employee mistakes, or stolen or lost hardware.

In this white paper Patrick Botz outlines the importance of these three controls and explains why they must be used to protect data stored in IBM i databases. Botz discusses on-board master key capabilities provided by the IBM Cryptographic Services APIs on an IBM i, the limitations of the IBM i Master Key Facility, and why organizations should use third-party key management to protect their sensitive data.

The top 3 critical best practices are:

Separation of Duties - This is widely known control set in place to prevent fraud and other mishandling of information. Separation of duties means that different people control different procedures so that no one person controls multiple procedures. When it comes to encryption key management, the person the person who manages encryption keys should not be the same person who has access to the encrypted data.

Dual Control - Dual control means that at least two or more people control a single process. In encryption key management, this means at least two people should be needed to authenticate the access of an encryption key, so that no one single person has access to an encryption key

Split Knowledge - Split knowledge prevents any one person from knowing the complete value of an encryption key or passcode. Two or more people should know parts of the value, and all must be present to create or re-create the encryption key or passcode. While split knowledge is not needed to create data encryption keys on the IBM i, it is needed for the generation of master keys which are needed to protect data encryption keys. Any encryption keys that are accessed or handled in the clear in any way should be protected using split knowledge.

The three core controls should always be used when storing or transferring encrypted sensitive data. A certified, hardened security module (HSM) designed to secure data encryption keys and key, or master, encryption keys should implement these controls into the administration of the key manager. NIST FIPS 140-2 validation is an important certification to look for in an encryption key manager. This certification ensures that your key manager has been tested against government standards and will stand up to scrutiny in the event of a breach.

Automatic Encryption on V7R1
With the release of IBM i V7R1, users can now encrypt data automatically with no application changes. This is great news for IBM i users since encryption has been a difficult task in the past, needing specialized encryption solutions for earlier versions of IBM i. Protecting your encryption keys in a an external key management HSM is the critical next step to protecting your encrypted data.

To learn more about encryption key management for the IBM i download the full White Paper “Encryption Key Management for IBM i - Sources of Audit Failures,” by IBM i security experts Patrick Botz and Patrick Townsend.

What Standards for PCI Encryption You Need To Know and Why They Matter

Payment Card Industry - Data Security Standards (PCI-DSS) require you to encrypt credit card account numbers stored in your database and ensure data stays secure when transferred outside your company.

In order to understand these PCI encryption requirements, we first should know the source of industry best practices for encryption 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 following concepts in PCI DSS 2.0 Section 3.  Next, it is important to understand the security best practices concepts of Dual Control, Separation of Duties, and Split Knowledge. I’ll simplify them here from the point of view of encryption key management:

1. Dual Control means that no one person alone 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.
    
2. Separation of Duties means that different people should control different aspects of your data protection 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.
    
3. 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.

In order to meet standards for PCI encryption, you need to make sure you protect these three things properly:

1. Protect your data at rest with AES Encryption
   Advanced Encryption Standard (AES) has been adopted as a format standard (FIPS -197) by the US government and many state and local agencies when it comes to encrypting data in a database. AES is the recommended encryption method for PCI-DSS, HIPAA/HITECH, GLBA/FFIEC and individual state privacy regulations. Encryption methods approved and certified by the National Institute of Standards and Technology (NIST) provide assurance that your data is secured to the highest standards.  
    
2. Protect your data in motion with PGP Encryption
   PGP encryption is the standard when it comes to encrypting files that need to be transferred.  Pretty Good Privacy (PGP) is the standard for encrypted file exchange among the world’s largest retail, finance, medical, industrial, and services companies.  Also know that when encrypting a file with PGP, you may be using AES encryption.  Transmit sensitive files over the internet using trusted encryption technologies. (AES, SSH, SSL, and PGP). Encryption solutions work together to ensure that all your sensitive data is secure even after the transmission is complete.  AES will protect data at rest within your organization and PGP keeps it secure when it is sent outside your company.
    
3. Protect your encryption keys and your data by keeping them apart!
   Leaving your encrypted data and keys in the same place is like leaving the key to your house under your welcome mat.  Security best practices require that you store encryption keys separately from your encrypted data and managed with an encryption key manager. It is also important to note that. In regards to the cloud, PCI SSC recently offered this guidance:
   In a public cloud environment, one Customer’s data is typically stored with data belonging to multiple other Customers. This makes a public cloud an attractive target for attackers, as the potential gain may be greater than that to be attained from attacking a number of organizations individually. Strong data-level encryption should be enforced on all sensitive or potentially sensitive data stored in a public cloud. Because compromise of a Provider could result in unauthorized access to multiple data stores, it is recommended that cryptographic keys used to encrypt/decrypt sensitive data be stored and managed independently from the cloud service where the data is located.

The most important part of a data encryption strategy is the protection of the encryption keys you use. Encryption keys safeguard your encrypted data and represent the keys to the kingdom. If someone has access to your keys, they have access to your encrypted data.

 

Download the whitepaper Meet the Challenges of PCI Compliance and learn more about protecting sensitive data to meet PCI compliance requirements.

         

 

At Townsend Security, we ensure our customers data is secured to the highest level for compliance. Our AES encryption solutions are NIST validated and our encryption key management solutions are FIPS 140-2 certified.  Our HSM appliances integrate seamlessly with Windows, Linux, UNIX, IBM Power Systems and Microsoft SQL Server 2008/2012 (enterprise edition) and can also work with earlier/non-enterprise editions of SQL Server.

As always, if you have comments or questions about PCI encryption, please list them here

In part one of Meeting PCI-DSS Requirements for Encryption Key Management I discussed Separation of Duties and Dual Control, two critical components necessary towards meeting Section 3 of PCI DSS for encryption key management compliance.  Equally important to meeting section 3 are the notions of Split Knowledge, Audit Trail Logging and Strong Key Usage and Protection.

Section 3.6.1 of PCI DSS v2.0 states that your encryption solution must generate strong keys as defined by PCI DSS and PA-DSS using "strong cryptography."  On our Alliance Key Manager (AKM) all data encryption keys, key encryption keys, and authentication keys are generated using a NIST approved and certified cryptographically secure random number generator.  This meets NIST requirements for strong encryption key creation and establishment.  Furthermore in regards to Key Encryption Keys and Authentication Keys that protect your data encryption key database, the former keys are protected by a 2048-bit RSA key.  Since AKM is FIPS 140-2 certified and meets NIST requirements, you're covered on how keys are stored in a protected format, detection of key corruption, and the separation of data encryption keys from your key encryption keys.

Split Knowledge can also play a crucial role in protecting your data encryption keys.  Parts of the security standard state that you shouldn’t export a key in the clear from the AKM database and that the key needs to be protected.  For this to occur, you'd first have to have your Admin latch up to the key server utilizing a secure TLS connection with the proper credentials and authenticate to the server.  Once the connection is established, the admin is free to export or import symmetric keys, however upon export they will be required to protect the symmetric key with a RSA key. No manual establishment of keys in the clear is supported. By default this is out of the box functionality; we ensure this requirement by setting a configuration option for PCI-DSS mode.

Finally, there is the important item of collecting your system logs and transmitting them over your network to a waiting log collection server.  This waiting log server would ideally be running a SIEM product that monitors and analyzes log messages looking for malicious activity or critical errors. Specifically, AKM writes logs to four different log files; audit, error, backup, and trace logging, when enabled.  The key manager comes with Syslog-ng built in and ready to be configured.  You simply select your sources and define your destination of the collection server to begin transmission of your log files.  You can configure your SIEM product to send out alerts when certain events or errors occur that you want to be on the lookout for.

Want to learn more?  You can view a pre-recorded webinar titled "Encryption Key Management Simplified" and learn how encryption key management can be easy, why encryption key management is important, and what the barriers are to good encryption key management.