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

The way organizations are managing encryption keys is falling under more scrutiny by Payment Card Industry (PCI) Qualified Security Assessor (QSA) auditors.  Companies must demonstrate they are enforcing dual control and separation of duties in order to protect sensitive data. 

Here are the answers to three of our most frequently asked questions about encryption key management on the IBM i:

Is it still effective to use an integrated key management solution that stores encryption keys in the same partition as the encrypted data?  
The short and simple answer is No. There are many reasons why storing an encryption key on the same server that contains protected data is not advisable. This is not just an IBM i issue - it spans all of the current major operating systems. Let's explore this a bit more in the following sections.

How do IBM i users manage encryption keys according to PCI requirements with an encryption key manager?
Payment Card Industry - Data Security Standards (PCI DSS) requirement states the following requirements for encryption key management:

• Dual Control means that at least two people should be required to authenticate before performing critical key management tasks.

• Separation of Duties means that the individuals managing encryption keys should not have access to protected data such as credit cards, and those that have access to protected data should not have the authority to manage encryption keys.

How are the “dual control” and “separation of duties” requirements achieved on IBM i?
On the IBM i you simply can't achieve these PCI requirements if you store the encryption key in the same partition as the protected data.  

The QSECOFR user profile (and any user profile with *ALLOBJ authority) will always have complete access to every asset on the system.  An *ALLOBJ  user can circumvent controls by changing another user's password, replacing master keys and key encryption keys, changing and/or 
deleting system logs, managing validation lists, and directly accessing database files that contain encrypted data.  

From the perspective of PCI, an integrated key management system puts too much control into the hands of any one single individual.
The only way to comply with PCI requirements for key management is to store the encryption keys off of the IBM i.  Take users with *ALLOBJ authority out of the picture completely.  When you use a separate appliance to manage encryption keys you can grant a user access to the protected data on the IBM i and deny that same user access to the key manager.  Now you have enforced separation of duties.  And with the right key management appliance you can require TWO users to authenticate before keys can be managed, and have dual control of encryption keys.

Now it’s time to ask yourself a few questions!

• Is your organization encrypting data on IBM i?  

• If so, how are you managing the encryption keys?

• If you store the keys on a separate partition, have you had a recent PCI audit?  

• What did your auditor say?

If you aren’t sure of the answers, or if this still seems foreign to you, take a few minutes to download our eBook "Encryption Key Management Simplified”.

Whether you are an IT administrator or a business executive, this resource will help you learn the fundamentals of:

• What is encryption key management

• Key management best practices

• How to meet compliance regulations (PCI-DSS, HIPAA/HITECH, GLBA/FFIEC, etc.) with encryption key management

• How encryption key management works on every platform including Microsoft SQL Server '08/'12, Oracle, and IBM i

  As always, we welcome your comments and suggestions!  Let us know what you think of the eBook! 

With the emergence of data security standards, encryption and key management have become a necessity for most companies storing or transferring sensitive data such as credit card numbers, patient data, social security numbers, and other personally identifiable information (PII). 

Transparent Data Encryption (TDE) on Microsoft SQL Server 2008, 2008 R2, and 2012, allows automatic encryption on these editions of SQL Server without application changes. With newly available SQL Server encryption capabilities, encryption key management--a critical step to securing your data--is done easily on SQL Server with extensible key management (EKM). EKM allows customers to choose a third-party encryption key management hardware security module (HSM) and integrate that HSM easily into their SQL database.

Without an encryption key management HSM, SQL Server users are essentially leaving the keys to their data underneath their welcome mat!

Three things to remember for following security best practices:

# 3 – SQL Server Encryption isn’t as imposing as it sounds…

• Compliance regulations drive the need for encryption and require that you protect the encryption keys apart from the encrypted data storage.  
• An encryption algorithm is simply a mathematical formula that protects data. The critical element is the way the “Key” to that formula (the encryption key) is managed. 
• HSMs like Alliance Key Manager create, manage, and protect encryption keys through the entire lifecycle and deliver them securely when they are needed.
• Alliance Key Manager is a quick, efficient, and compliant solution that is easy to implement with our “Key Connection for SQL Server” EKM provider software. Based on FIPS (Federal Information Processing Standard) 140-2 certified technology, it is easy to implement, deploy, and configure with “out of the box” integration with SQL Server.
• Townsend Security is Microsoft Silver partner and Alliance Key Manager works with all versions of Microsoft SQL Server including SQL Server 2005. Additionally, Alliance Key Manager allows you to protect sensitive data stored in Microsoft SharePoint and Microsoft Azure.

#2 - You are required to protect data by government and industry created regulations…

• PCI-DSS (Payment Card Industry – Data Security Standard) for merchants
• HIPAA/HITECH  (Health Insurance Portability and Accountability Act)/(Health Information Technology for Economic and Clinical Health) for medical providers
• GLBA/FFIEC (Gramm-Leach-Bliley Act)/(Federal Financial Institutions Examination Council) for the financial industry
• FISMA (Federal Information Security Management Act) for US Government agencies

#1 - Customers expect their data to be protected!

• PCI-DSS is required for anyone who takes credit cards.
• While expectations for data protection in the medical and financial industries are wide-spread, and easily understood, compliance regulations affect business and organizations of all sizes. 
• Beyond the expectations for privacy, and the laws that require it, the consequences of a data breach or data loss can be substantial. 
• Small to mid-sized companies can be an easy target for data thieves, resulting in costly losses to their business and reputation.

We have resources to share with you about SQL Server Encryption and how to best secure your data.  Please click the button below to access these informative downloads! 
 

 

As always, we welcome your comments and questions!

DOWNLOAD WHITE PAPER Download our Encryption Key Management and PCI DSS 2.0 Compliance Matrix white paper and learn more about ensuring the data you are protecting meets PCI compliance. Click Here to Download Now

There are are a few major components of PCI-DSS that need to be addressed when implementing an external key manager into your data encryption equation.  Separation of duties for starters, simply states that those who have access to the sensitive data, such as card holder details or credit card numbers cannot also have access to the encryption keys that protect them.  Conversely, the same can be said for the individuals that are responsible for managing data encryption keys -- they should not have access to the sensitive data for which the keys they are creating are used to protect.  Quite simply, separation of duties is the concept of dividing critical data protection processes between different individuals. This helps reduce the opportunity and likelihood of fraud when processing sensitive data.

I often talk with companies who've until recently considered encryption key management as an afterthought to their security infrastructure.  Often times they would store encryption keys on USB sticks or locally, alongside the encrypted data.  This approach allows individuals within the organization access to both the keys and data, directly conflicting separation of duties.  Utilizing an external encryption key manager to house your encryption keys, as well as implementing a policy where your security team are the only ones managing those keys and your DBA's and users are the only individuals accessing the data, will help move you in the direction of PCI compliance.

But of course there are other pieces to PCI that one should be aware of when it comes to proper encryption key management.  While separation of duties is good practice, there is an additional level of security that can be implemented on the encryption key management side called dual control.  Dual control is a process that requires the involvement of two or more individuals to complete a specified task, such as creating a key, changing its attributes, revoking status, or destroying an encryption from use forever.  Think of dual control as the act of requiring two individuals with two different keys to unlock the launch codes for a nuclear missile.  You certainly wouldn’t want all that responsibility resting on the shoulders of just one person with no oversight in place.  The same can be said for the management of your encryption keys.

To implement dual control on Alliance Key Manager (AKM), our encryption key management HSM, you'd first active it in the AKM configuration file of the hardware appliance.  Then the two Security Admins responsible for key management would install our Java based admin console into their work environments and configure them to communicate with the key manager over a secure TLS connection.  Once this is established, the first Security Admin would authenticate to the key server and set an 'Authorized Administrator' time period.  This allows the the first Admin to specify a window of time (in minutes) where the other Admin can log onto the key manager and perform their duties.  Taking this approach to key creation and management adds that additional layer of security to your encryption key environment.

In Part II of 'Meeting PCI-DSS Requirements for Key Management'  I will discuss the importance of capturing your audit logs and transporting them to a collection server off the key manager device as well as dig into the concept of split knowledge and how AKM meets that requirement. Until then, download our white paper on encryption key management requirements for PCI.

I just listened to a discussion of database security hosted by Oracle that was very well done. At one point the discussion turned to current threats and how the Enterprise has lost the ability to use perimeter protection for sensitive data. This has been a topic of much discussion in the security area for the last few months. Perimeter protection is based on the use of Firewall and similar technologies to keep the bad guys out, but this approach is failing with the advance of more sophisticated attacks, the use of social media by large organizations, the advance of mobile technologies, insider threats, and the migration of applications to cloud platforms. The trend is called “de-perimeterization” and represents a bit of a challenge to organizations that need to protect sensitive data.

Vipin Samir and Nishant Kaushik did a great job of describing the how the process of de-perimeterization has forced companies to fall back on user access controls to protect data. But user access controls are notoriously weak.  Weak passwords and sophisticated password cracking routines make it almost impossible to properly secure a database. So what is a security administrator to do?

Here are the suggestions from the panel that are a part of a defense-in-depth strategy:

Use Encryption to Protect Data:
Companies should use encryption at the database level or column level to protect data. This will secure data at rest on backup tapes and on disk in the event a drive is replaced. Encryption is an important part of the data protection strategy, but it needs to be combined with other techniques.

Use Good Key Management:
Protecting encryption keys is the most important part of the encryption strategy. Good key management techniques are needed, and the keys must be separated from the data they protect. Without this separation from protected data it is impossible to implement separation of duties and dual control – important parts of the key management strategy. See our Alliance Key Manager solution for more information about securing encryption keys.

Separation of Duties:
Because the threat from insiders is rising, it is important that the management of encryption keys be separate from the management of databases. Database administrators responsible for our relational databases should not have access to encryption key management, and security administrators should not manage databases. This is a core principal in data security regulations such as PCI DSS, but is often overlooked.

Context Sensitive Controls and Monitoring:
The last important step is to be sure that data access controls are sensitive to the data and its context. Bill in shipping has access to the order database, but should he really be decrypting the credit card number? Does your encryption solution detect and block this type of event? How will you monitor this security event? Or, Sally is authorized to view HR data from the accounting application, but should she really be using FTP to transfer this data? Normal encryption functions would not provide adequate protection from these types of data access. Context sensitive controls are needed to augment encryption.

When we started planning for automatic encryption in our Alliance AES/400 product two years ago, we took care to implement context sensitive controls right in the decryption APIs. That is now available in V7R1 of the IBM i operating system. We avoided the error of basing these controls on user account authorities and native OS security. Just because the operating system says you have read access rights to a database table, doesn’t mean you should be decrypting the social security number or using FTP to transfer the file. I’m happy with our implementation that is based on explicit authorization by a security administrator, and application white lists.

You can get more information and request an evaluation version of our Alliance AES/400 solution here.

You can find the Oracle presentation here. Look for “How secure is your Enterprise Application Data?”

Patrick

I 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