Townsend Security Data Privacy Blog

Two Factor Authentication (2FA) and a look at the compliance regulations that require identity verification for remote access.

The use of two factor authentication provides an added layer of security beyond just a username and password. Because passwords can be guessed, stolen, hacked, or given away, they are a weak layer of security if used alone. Since frequent access happens from outside of the network, remote login is considered high-risk and requires additional steps to confirm user identity. Protecting access with two factor authentication adds identity assurance and significantly reduces risk of unauthorized access in the retail, healthcare, and financial industries.

Payment Card Industry Data Security Standards (PCI DSS)

The PCI Security Standards Council has stated that they will continue to change and evolve compliance regulations over time as attacks change. In PCI DSS section 8.3 the requirement states that organizations must “incorporate two factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties.”  The objective of this requirement is to ensure that merchants implement strong access control measures so that authorized individuals with network and computer access can be identified, monitored, and traced.

Requirement 8: Assign a unique ID to each person with computer access. Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.

Note: These requirements are applicable for all accounts, including point-of-sale accounts, with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data.

Requirement 8.3: Incorporate two factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties.

Note: Two factor authentication requires that two of the three authentication methods (something you know - something you have - something you are) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two factor authentication.

Health Insurance Portability and Accountability Act (HIPAA) and the Health Information Technology for Economic and Clinical Health (HITECH) Act

HIPAA was an act signed in 1996 by President Bill Clinton, meant to improve the efficiency of the healthcare system by encouraging the use of Electronic Data Interchange (EDI) when accessing Protected Health Information (PHI). Covered entities must develop and implement policies and procedures for authorizing PHI access in accordance with the HIPAA Security Rule Administrative Safeguards 164.308(a)(4) [Information Access Management: Access Authorization] and Technical Safeguards 164.312(d) [Person or Entity Authentication] and the HIPAA Privacy Rule at §164.508 [Uses and disclosures for which an authorization is required].

The HIPAA Security Rule requirements have most recently been expanded via the HITECH Act, which establishes mandatory federal security breach reporting requirements with expanded criminal and civil penalties for non-compliance. To remain HIPAA compliant and avoid fines for HITECH Act non-compliance, strict control over access to patient records must be demonstrated.

HIPAA/HITECH requirements regarding the transmission of health-related information include adequate encryption [164.312(e)(2)(ii) when appropriate, and 164.312(a)(2)(iv)], authentication [164.312(d)] or unique user identification [164.312(a)(2)(i)] of communication partners. By selecting Two Factor Authentication (2FA), users would be required to combine something they know, something they have, or something they are; thereby providing more secure access to PHI files. Protected Health Information can be account numbers, medical record numbers and geographic indicators among other private consumer information. It is important that only those health care workforce members who have been trained and have proper authorization are granted access to PHI.

Gramm-Leach-Bliley Act (GLBA) & Federal Financial Institutions Examination Council (FFIEC)

The Federal Financial Institutions Examination Council (FFIEC) is charged with providing specific guidelines for evaluating financial institutions for GLBA (Gramm-Leach-Bliley Act) regulations compliance. The FFIEC also provides guidance around the use of two factor authentication to strengthen systems in the financial industry and strengthen banking websites against financial fraud with the document, “Authentication in an Internet Banking Environment” (v.3). For banks offering internet-based financial services, the guidance document describes enhanced authentication methods that regulators expect banks to use when authenticating the identity of customers using online products and services, as follows:

• Financial institutions offering internet-based products and services to their customers should use effective methods to authenticate the identity of customers using those products and services. Furthermore, the FFIEC considers single-factor authentication (as the only control mechanism) to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties.
• The implementation of appropriate authentication methodologies should start with an assessment of the risk posed by the institutions’ Internet banking systems. The authentication techniques employed by the financial institution should be appropriate to the risks associated with those products and services.
• Account fraud and identity theft are frequently the result of single-factor (e.g. ID/password) authentication exploitation.
• Where risk assessments indicate that the use of single factor authentication is inadequate, financial institutions should implement multi-factor authentication, layered security, or other controls reasonably calculated to mitigate those risks.

The FFIEC is a government agency which works with many other government agencies to unify how financial institutions should be supervised. The guideline documents recommend banks treat the FFIEC as baseline compliance for safe online authentication and transaction verification. Since all single factor authentication techniques can be easily compromised, financial institutions should not rely solely on any single control for authorizing high risk transactions, but rather institute a system of layered security with multi-factor authentication.

Although there are varying levels of enforcement, guidelines vs. laws vs. fines, it is clear that two factor authentication plays a critical security role in both compliance and following best practices. This trend will only grow within various industries and throughout the overall data security environment.

Townsend Security offers Easy to Deploy, Cost Effective Two Factor Authentication Solution for the IBM i Platform

Alliance Two Factor Authentication brings mobile SMS and voice verification to the IBM i platform. The solution was built to solve large scale problems in a cost-effective manner and appropriately addresses the concerns raised in the various guidelines and standards listed above. Remote access to networks containing critical payment, patient information, or financial records can be protected with the Alliance 2FA solution using your mobile phone to receive authentication codes.

For more information, request our 2FA Resource Kit! 

Every few years since its inception in 2006 the Payment Card Industry Security Standards Council (PCI SSC) has revised and updated the the Payment Card Industry Data Security Standards (PCI DSS) and Payment Application Data Security Standards (PA DSS) to improve security for the payment card industry worldwide. These revisions, clarifications, and new points of guidance are based on considerations and recommendations by experts in the field of data security as well as over 700 organizations that process cardholder data. At the end of their review period, the PCI SSC concluded that revisions needed to be made based on these problematic themes in the payment card industry:

• Lack of education and awareness of how to implement and maintain PCI standards - a major problem since the improper implementation of PCI standards leads to data loss and breaches
• Weak passwords and authentication
• Lack of consistency of responsibility when implementing necessary third party security features
• Slow detection of threats
• Inconsistency of PCI assessments¹

Since the release of v3.0 in November 2013, many organizations affected by PCI DSS and PA DSS are asking: Are there new revisions regarding encryption and key management in v3.0, and what do I need to do in order to meet new recommendations, regulations, and best practices? Luckily, much of version 3.0 hasn’t changed from 2.0. However, many important clarifications have been made. In section 3 of PCI DSS (the section pertaining to encryption and management of encryption keys), version 3.0 makes clarifications regarding these aspects of encryption and key management²:

• Stricter controls around the protection and deletion of authentication data
• Key management procedures must be both implemented and documented
• The requirement of PAN masking
• The critical use of dual control and split knowledge
• The mandate that logical access for disk encryption must be managed separately and independently of the native operating system authentication and access control mechanisms, and that decryption keys must not be associated with user accounts.

Version 3.0 has also split requirement 3.5.2 into two separate requirements to emphasize the importance of both storing encryption keys in a secure location (3.5.2) as well as in the fewest possible locations (3.5.3)²

Based on the themes they found and the revisions made, it is clear that the PCI SSC is moving toward making their regulations stricter. What’s even more interesting is that in this last review, more than half of the recommendations were taken from experts and organizations outside of the United States. This is likely because the United States is farther behind other countries such as the European Union in terms of credit card data security, and since the PCI SSC sets worldwide regulations, they must set standards that meet the highest expectations.

We recommend all organizations worldwide look to the highest standards and follow best practices and recommendations (whether they are required or not) since these evolving requirements are based on current conditions and threats in the data security world and indicate future hardened regulations.

To learn more about encryption key management best practices download NIST Special Publication 800-57 “Recommendations for Key Management: Parts 1, 2 & 3” 

¹ PA-DSS & PCI DSS change highlights

² PCI DSS 3.0 summary of changes

Make sure you don't turn a blind eye to data security!

The basic concept of converting sensitive data into a form that could not be easily understood if it was to be seen by the wrong audience goes back as far as 500 BC (Atbash Cipher), some would even argue that in 1900 BC a simple hieroglyphic substitution was the first form of cryptography. While technology has made great advancements in recent years, it has also created an even greater need for privacy of sensitive information. Whether you are the Chief Security Officer, IT personnel, or database administrator; you should know how your company is handling sensitive data. In fact, security is the responsibility of every business owner and employee. Not using secure passwords can lead to a data breach just as not following key management best practices can provide access to people with malicious intent. When awareness around data security reaches every department and individual, then the company can not only meet compliance regulations, but can benefit from effective data security. Compliance regulations require (or strongly recommend) all industries following best practices for encryption and key management . Do you know which of these apply to you and your company? For example, if you take credit cards for any reason, you fall under Payment Card Industry - Data Security Standards (PCI-DSS). Other common regulations are:

• HIPAA/HITECH ACT requires security of Protected Health Information (PHI) in the medical sector.
• GLBA/FFIEC sets regulations for banks, credit unions, credit reporting agencies, and anyone in the financial industry.
• FISMA is for Federal US Government Agencies.
• The Federal Trade Commission (FTC) also gets involved with anyone who issues a privacy statement.
• More than 45 states also have their own privacy rules, in addition to the ones listed above, that strongly recommend encryption of any personally identifiable information (PII).

So, beyond compliance with regulations, why should you care about encryption… First of all, your customers, clients, and suppliers all expect you to protect their sensitive data. Effective encryption and key management can provide your company with a number of other benefits as well. Here are just a few basic benefits of effective encryption key management:

• Peace of Mind - While hackers and identity thieves are getting smarter and regulations are getting more complex, data protection technology is also improving at a rapid rate. Encryption and key management options are now available in virtual machines and cloud environments as well as hardware security modules(HSMs). How well would you sleep at night if you kept your house key under your welcome mat?
• Reputation - Whether information is lost due to a hacker or a hurricane, if a company loses all of it’s important data, the whole business could be ruined. However if sensitive data is lost because mechanisms for protecting it are not in place, then an organization has even bigger problems. The most effective way to secure data and ensure the integrity of a company is to deploy encryption and properly manage the encryption keys.
• Credibility - Beyond audit requirements, organizations need to consider the security of their customers Personally Identifiable Information (PII). Being able to protect your clients with strong key management practices can add a level of trust and confidence that will help grow your business.

Mobility is also great benefit! As more people move their data to the cloud or virtualized environments the need for encryption increases, and the importance of key management becomes even more evident. In order to maintain control over your data, and the privacy of your customers, information must not only be encrypted but kept secure while in motion, in use, or at rest. By properly managing your encryption keys, you are still in control of your data no matter who is sharing your infrastructure.

In this complimentary eBook, "Turning a Blind Eye to Data Security”, authors Kevin Beaver, CISSP; Patrick Townsend, and Todd Ostrander will teach you about:

• Tools and resources to begin the discussion about data security in your company
• 5 Common misconceptions about data security
• 6 Questions to ask your CIO

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.

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 2013 merchants should ask: Will we pass our PCI audit this year using the same technology and standards we used last year? The answer is possibly not.

Businesses that accept credit cards have to meet PCI-DSS compliance requirements and encrypt credit card numbers using industry standard encryption and good encryption key management practices. They are often shocked and surprised when, after passing a compliance audit for a number years, they suddenly fail an audit around encryption key management practices. Audit failure due to poor encryption key management has begun to happen more frequently within the past year.

Let’s take a look at one scenario of a customer we helped this year.

A large retailer with a Level 1 merchant designation processes tens of thousands of credit card transactions every year. Card transactions originate through point-of-sale (POS) terminals in stores, through web-based eCommerce applications, and telephone orders. A pretty typical retail operation in many ways. This Level 1 merchant had passed on-site QSA audits for several years. Suddenly, this year they failed their PCI-DSS audit.

Why did this happen? Because the encryption key used to protect credit card numbers was stored on the same server as the protected data.

In the last year or so, failing PCI-DSS audit due to poor encryption key management is actually far more common than you might think. In this case a new QSA auditor was assigned to the merchant, and the auditor was quite knowledgeable about security practices in general, and key management in particular. The previous auditor had granted the merchant “compensating controls” for their encryption key management strategy - but the new auditor found that the compensating controls were inadequate for proper encryption key protection. Thus the audit failure and the need to remediate encryption key management.

Here are a few thoughts that might be helpful to merchants reviewing their encryption key management practices:

• PCI DSS standards are not set in stone. The PCI Security Standards Council has been very transparent in letting merchants know that the standards can and will evolve as security threats evolve. What you are doing today may not be adequate to protect your systems tomorrow.
• QSA auditors vary in their assessment of risk and requirements to meet the standards. And as the security threat environment changes, they can revise their assessment practices and requirements for merchants. Compensating controls that might have been appropriate in the past, may no longer be appropriate.
• In the early years of PCI audits, the focus may have been more on basic compliance with high priority security tasks given priority. As time has gone by, attention is now more focused on tightening up critical components like encryption key management. Weak encryption key management practices and compensating controls are falling by the wayside.
• QSA auditors are a lot more educated on the issues of Dual Control and Separation of Duties for encryption key management systems. It is almost impossible to implement a encryption key management system on the same platform as protected data, and meet these security requirements. Protecting encryption keys with purpose-built key management hardware security modules (HSM) is now a typical requirement for PCI DSS compliance.

So what can a merchant do if they want to make sure they will pas their PCI-DSS audit this year?

• Review your encryption key management implementation now. If your implementation does not meet security best practices for encryption key management, start planning on what you will do to remediate the problem.
• Ask yourself: Were we operating under compensating controls for encryption key management? It would be wise to assume these won’t be renewed at some point in the future.
• Ask yourself: Are we storing our encryption keys on the same server as the credit card number? Start planning now on how you will respond in the event of an audit failure.

Good encryption key management is no longer a time-consuming, expensive proposition. Our Level 1 merchant was able to remediate the problem in under 30 days with their own IT team and without the need for on-site consultants from Townsend Security. To learn more about encryption key management and meeting PCI-DSS, download our White Paper, Encryption Key Management for PCI-DSS.

At Townsend Security, many of our customers are in the retail industry (a pretty big number of them, actually), which means that every day we’re working with these businesses to help them assess their data security posture so that they can meet compliance requirements for PCI-DSS. Often times a company will come directly to us for fear they may be about to go through a PCI audit, needing an immediate solution. These companies already know that they’re in trouble, and by the time they find us they’ve had to figure out their current security status and the PCI Compliance Level that they fall under.

[Learn More: PCI DSS 5 Take-Aways to Take Away the Pain!]

However, many merchants who are failing PCI audits are discovering this information about themselves too late. In fact, many businesses go a long time believing that they do NOT need to meet PCI DSS compliance for a variety of reasons. We hear things like: "Our business is too small, We’ll never get audited," or, perhaps worst of all, "Our data is secured using a firewall and passwords" (we actually heard this from a well-known restaurant chain, who two months later, suffered a data breach).

Here’s the truth: ALL merchants handling cardholder data (regardless of size) must comply with PCI DSS. The first questions a merchant needs to ask itself are these: What Merchant Level am I, Am I meeting compliance for my Merchant Level, and Would I pass a PCI audit?

Currently, PCI DSS is a national standard for payment card security, and although there is not a national standard for merchant levels, compliance rules are the same for all credit card companies. Merchant level definitions for all credit card companies are straightforward, and are centered around annual number of transactions. Here are VISA’s definitions, for example:

1 - Compromised entities may be escalated at regional discretion

2 – Merchant meeting Level 1 criteria in any Visa country/region that operates in more than one country/region is considered a global Level 1 merchant. Exception may apply to global merchants if no common infrastructure and if Visa data is not aggregated across borders; in such cases merchant validates according to regional levels.

[Mastercard’s Merchant Level descriptions can be reviewed here.]

If you’re a level 3 or 4 merchant, you will not have to go through a yearly PCI audit, instead you will fill out a yearly questionnaire regarding your security practices. The ONLY time a level 3 or 4 merchant gets audited is in the event of a data breach, or if they are found to be out of compliance with PCI DSS

However, level 3 and 4 merchants should never use this as an excuse to have weak security. Smaller businesses need to be aware that they are at a higher risk of a data breach simply because data security feels like less of a concern. It is now becoming increasingly more obvious that smaller businesses are being targeted by hackers more often than larger businesses because hackers know that they are in general more vulnerable. In the event of a data breach small and medium sized businesses may never recover from the financial penalties brought on by a data breach.

So how do you protect the cardholder data that you’re storing, processing, and or transferring to be PCI DSS compliant? It’s easy in these 5 steps....

Download our white paper "Meeting the Challenges of PCI Compliance" to learn what an auditor is going to look for, how you can ensure your data is secure, and why auditors are looking specifically at encryption key management.

At Townsend Security we get all kinds of questions about PCI Compliance. A question we get asked frequently by healthcare professionals is:

As a medical healthcare provider, we accept payments via check or credit card through Point of Sale devices implemented by a third-party vendor. Are we responsible to comply with PCI DSS requirements?

Many people assume that if they use a third-party vendor, the vendor must be the one to comply with PCI DSS. Our CEO Patrick Townsend, has a different take on this subject. I asked Patrick if he could answer some of the common questions asked by healthcare providers concerned about PCI DSS compliance requirements.

Are we (healthcare providers) responsible for complying with PCI DSS?

Yes, every Merchant is responsible for PCI DSS compliance even if using an outsourced service. However, this type of arrangement can greatly reduce the amount of work that the Merchant has to do. Usually you will only need to complete and sign a Self Assessment Questionnaire (SAQ). You would get this from your outsourced authorization provider.

Okay, but if we do need to be concerned with PCI compliance, how is the PCI DSS processed managed?  Does the IT team tackle this? Our compliance team?

Typically the IT department takes the lead on coordinating any work that has to be done for PCI DSS. This might include things such as a vulnerability scan by an approved scan provider and similar types of tasks. An officer or director then reviews and signs the SAQ and letter. In medical organizations the Compliance Officer is typically more involved with various medical industry compliance requirements related to HIPAA and so forth and usually not involved with PCI DSS. But it never hurts to ask.

What about banks that process our clients’ credit card information?  What kind of reporting should we be getting from our bank confirming that they are compliant or following PCI DSS compliance?

Banks are under a different type of compliance requirement for PCI. You should just ask them for a letter assuring you that they meet all PCI data security requirements as an authorization provider.

Sometimes PCI compliance can be confusing. Hopefully, thanks to Patrick, you may now have a better understanding of PCI compliance and how you can outsource credit card information while remaining PCI DSS compliant. If you have questions about PCI compliance, send me an email at kristie.edwards@townsendsecurity.

If you want to learn more about PCI compliance and how Townsend Security can assist with the process, listen to Patrick speak about current best practices and encryption key management in the webinar, “Key Management Best Practices: What New PCI Regulations Say.”

If you're struggling to understand encryption key management, trust me, you're not alone. If you are just beginning your research, here is the first step to lead you in the direction of a comprehensive key management plan that meets all data security compliance regulations.

Let’s start with the basics:

1. You must manage your encryption keys separate from your encrypted data.

Storing your encryption keys on the same device as your encrypted data is like taping your house key to the front of your door. It’s just a bad idea! Plain and simple. Whether you’re a DBA, IT Admin, or Auditor, PCI DSS section 3 addresses encryption keys and states that keys should be managed with Dual Control and Separation of Duties. This means the keys must be stored on a separate system designed to manage the keys.

2. Manage your keys using split knowledge, separation of duties, and dual control.

This means using multiple people to manage parts of the keys so that no one person has entire control of the keys. PCI DSS section 3 also speaks directly to this protocol. Without separation of duties and dual control, storing your keys on a separate device isn’t much better than “hiding” your key under the welcome mat.

The other day I spoke with a prospect in the healthcare industry who believed the tools he had in place for key management were sufficient, until he found out they were not.  This prospect was using Software as a Service (SaaS) to manage their encryption keys. While using SaaS is a great replacement for some aspects of our work lives, it will not work for key management if you’re managing your keys on same server as you store your encrypted data.

In the healthcare industry, the HIPAA HITECH act states simply, “… covered entities and business associates should keep encryption keys on a separate device from the data that they encrypt or decrypt”.

There are some people out there still storing their keys on their database server, thinking that they are meeting compliance regulations. What they don’t realize is that they are not PCI DSS compliant and will likely fail a security audit if they are audited. My last word is this: When it comes to regulations like PCI, HIPAA/HITECH, or state privacy laws, you must physically separate encryption keys from the data they protect.

If you want to learn more about key management and PCI compliance, listen to Patrick speak about current best practices and encryption key management in the webinar, “Key Management Best Practices: What New PCI Regulations Say.”

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.

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.