DOWNLOAD WHITE PAPER Download the white paper "Meet the Challenges of PCI Compliance" and learn more about ensuring the data you are protecting meets PCI compliance. Click Here to Download Now

Customers moving to a hosting provider or cloud provider are often confused about PCI DSS compliance regulations, and what their responsibilities are in that environment. Some companies feel that they can avoid compliance concerns by moving to a cloud service. Some feel that they are no longer under compliance regulations at all in that environment. I heard this comment just this week:

“I don’t need to worry about compliance because my hosting provider says they are PCI compliant.”

This is dangerously wrong.  Let’s sort this out.

First, hosting providers who say they are PCI compliant are usually talking about their own systems, not about yours. Their credit card payment application is PCI compliant, they run the required vulnerability assessments on their payment processing applications, they collect system logs, and so forth. All of these things are required by the hosting or cloud provider for their own systems to be PCI compliant. They aren’t talking about your applications and data.

This does not make you automatically PCI compliant when you use their platforms or applications. You still bear the responsibility for meeting PCI compliance in your applications. Regardless of the hosting or cloud implementation (Infrastructure-as-a-Service, Platform-as-a-Service, Software-as-a-Service, or a hybrid approach), you are always responsible for PCI compliance of your data.

What does the PCI Security Standards Council (PCI SSC) say about cloud environment?

The hosted entity (you) should be fully aware of any and all aspects of the cloud service, including specific system components and security controls, which are not covered by the provider and are therefore the entity’s responsibility to manage and assess.

And,

These challenges may make it impossible for some cloud-based services to operate in a PCI DSS compliant manner. Consequently, the burden for providing proof of PCI DSS compliance for a cloud-based service falls heavily on the cloud provider, and such proof should be accepted (by you) only based on rigorous evidence of adequate controls.

As with all hosted services in scope for PCI DSS, the hosted entity (you) should request sufficient assurance from their cloud provider that the scope of the provider’s PCI DSS review is sufficient, and that all controls relevant to the hosted entity’s environment have been assessed and determined to be PCI DSS compliant.

Simply put, you are responsible for understanding which parts of PCI compliance a cloud vendor can help you with, and which parts they can’t.

There is no cloud implementation that relieves you of the responsibility of protecting your data. See section 4.3 in this PCI guidance.

What does this mean from a practical point of view?

This means that you must meet all of the PCI DSS requirements for your cloud implementation. You may be able to take advantage of some PCI compliant services provided by the hosting or cloud vendor, but you must have the cloud vendor provide you with guidance, documentation, and certification.  You are not off the hook for responsibility in these areas.

Please note the chart on page 23 of the PCI cloud guidance. There is no hosting or cloud implementation that covers your data. You are always responsible for protecting your customer’s cardholder data. This means complying with PCI DSS Section 3 requirements to encrypt the data and protect the encryption keys.

There is no magic bullet. You have to do this work.

Living through a data breach is no fun, and I would not wish this experience on anyone. In hosted and cloud environments, ignorance is not bliss.

Stay safe.  For more information, download our whitepaper Meet the Challenges of PCI Compliance and learn more about protecting sensitive data to meet PCI compliance requirements.

Patrick

Section 10 of PCI DSS requirements v2.0 states the need to track user activities, to be able to detect, prevent or minimize the impact of a data compromise.  Because of the mere fact that most every application under the sun produces a log entry for when something goes amiss, you can also use that same log file as a security tool.  It can provide a means of tracking and analysis when a possible data breach may be occurring as well as add crucial detail for investigative purposes.  Now a smart criminal knows to cover their tracks at the scene of a crime, and they can do this simply by wiping out any log data that may exist.  However if you’re capturing these logs in real time and sending them to a third party server, even the most savvy of crooks will be caught red handed.

Our Alliance LogAgent solution helps accomplish that, as well as satisfying parts of section 10 of PCI DSS by being able to capture logs from your IBM i’s audit journal, formatting them and sending them off to a waiting log collection server.  We monitor for log entries out of numerous places on the iSeries allowing the user the a level of granularity to choose what log messages to capture and kick over the wall to the waiting log server.  It's always a good idea to work hand-in-hand with your PCI auditor to make sure you're collecting all the appropriate events on your system to meet their requirements.

For instance, you'll want to make sure you're collecting AF (Authority Failure Events) events which come from the System Value QAUDLVL.  This particular event is triggered by all access failures, such as sign-ons authorization, and job submissions. It also includes incorrect password and user ID attempts from a device.  These details can play a crucial role in tracking down details around a possible breach into your system.  

As I mentioned, Alliance LogAgent sends these events to a listening collection server or SIEM solution.  We work with any SIEM product that is actively listening and waiting for logs to arrive and can accept messages in the RFC 3164 or Common Event format.  There are a number of SIEM products available on the market and they help parse the influx of log messages as they arrive, as well as send out notification and alert emails when something suspicious is detected.

Currently, the PCI guidelines don't include transmitting logs over a secure SSL/TLS session (it’s a very, very good idea).  However, looking ahead to when this becomes a requirement, you can rest assure that you’re already running software that can meet those needs.  LogAgent is already setup to handle secure SSL/TLS transmissions and is one of the reasons it stands apart from the competition.  The only change you'll have to make in the configuration of the product when switching over from UDP/TCP to SSL will be to provide an SSL application ID.  This is an ID that is associated with a digital certificate that you can create with IBM's Digital Certificate Manager (DCM).   Having this secure session in place will ensure that your log message data won't be intercepted on its journey to the collection server.

Download a free 30-day evaluation of Alliance LogAgent Suite and meet Section 10 of PCI DSS.  In under an hour, you can start collecting all system logs on your IBM i (AS/400) and converting them to syslog or CEF format for any SIEM or log collection server.

The recent 2011 PCI Compliance Report released by Verizon concludes that many companies are losing ground on PCI DSS compliance and 44% of all breaches take over a year to be discovered. These findings are disturbing. eWeek.com wrote an excellent summary of the report.

Here is one snippet from the article:

"About 42 percent of organizations had trouble encrypting data in the database or implementing a proper key management strategy to keep the information safe."

We know that data protection is the hardest part of PCI DSS compliance. Many studies show that organizations struggle with encryption and key management. But are they really losing ground after they get their data in place?

I talk to a lot of customer about PCI DSS compliance, and I have a different take on this.

The recent audit and training changes that affect Level 2 Merchants may be showing up in this statistic. Prior to 2011, Level 2 Merchants completed an annual Self Assessment Questionnaire (SAQ). Starting in 2011 Level 2 Merchants must either undergo an on-site audit by a QSA auditor, or send a member of their IT team for ISA training by the PCI council. A lot of companies are opting for the second option and are getting their internal staff through the ISA training process.

I think that a lot of these newly trained IT professionals are coming back home and understanding encryption and key management requirements a lot better. It was easy to put the check marks in the box when doing the SAQ questionnaire. Now there is a lot more thought about what good encryption and key management means. I think that is driving a lot of the change, especially in the area of key management.

Did these companies lose ground? No, they weren’t in compliance before, and they are just coming into compliance now.

Customers tell me that meeting the PCI DSS requirements for key management is their biggest area of remediation. They’ve been storing encryption keys in a file, or somewhere on the hard drive, or on a USB storage device, or on another server where they are not properly protected. None of these techniques can meet PCI DSS requirements for Dual Control, Separation of Duties, and Split Knowledge. Really, any storage of data encryption keys on the same server as protected data is going to be a compliance problem. Newly trained IT staff now understand this and are taking action to fix the problem.

So, did they fall out of compliance? No, they weren’t in compliance before and now they are moving towards better security. And that is a good thing.

I don’t mean to minimize the effort that it takes to stay in compliance with PCI DSS. It’s a lot of work and it takes on-going attention. And security and IT departments are under the same budgetary pressures that all of us feel. They are trying to make do with fewer people and smaller budgets. 

But perhaps the news is not as bad as we think. If you haven’t taken a look at your key management strategy lately, now is the time to do it.

Fore more information, download our podcast "Key Management Best Practices: What New PCI Regulations Say" and learn about encryption key management best practices, as well as what PCI has to say about integrated key management (why it isn't a good thing), dual control, separation of duties, and split knowledge.

 

Patrick

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

I recently returned from 5th Annual PCI Security Standards Council vendor expo in Scottsdale, AZ.  And rather than returning with a sunburn - after all it was 106 degrees there - I returned with a much better appreciation of what companies are doing to help protect cardholder data.  Every major company that accepts credit cards was at this event.  As a consumer at many of these companies, it made me feel good to know that they take this job seriously and are doing everything they can to keep my information and all of their customers’ information secure.

This was my first time at the event and I enjoyed meeting new people and learned a lot of interesting things. I met with QSA audtiors, customers, potential customers  and vendors.   When asked who Townsend Security was,  I recited my elevator pitch and said “we provide certified encryption and key management solutions to help mid-market customers meet compliance requirements.”  That message was well received, however, as the expo continued, I discovered that people “get” encryption and were more interested in discussing encryption key management.  Many knew key management was something they needed to do and for those that said they were doing something, they wanted to know how they could automate the process.

I spoke with one QSA auditor and asked his opinion on why so many people might be inquiring on this topic and his response, “I have yet to see key management done correctly.” And for companies working on staying compliant,  I think one lady’s response about key management at her organization may sum it up best -- a long pause, accompanied with a rolling of her eyes and a heavy sign saying “it’s not good.”

We know encryption key management isn’t easy, but it is necessary for compliance and to be honest, it is really a best practice for protecting data.  If you are going to go through all the work of encrypting data, then you really should make sure the keys safeguarding the data are also secure.  I talked a lot about our encryption key management solution, Alliance Key Manager (Enterprise and SQL Server editions), at the Expo and thought it would be worth recapping some of the discussion for those who couldn’t be there and are facing encryption key management requirements of PCI DSS.

1) Manage and store encryption keys on a certified appliance.  Our encryption key management solution ensures encryption keys are stored away from the encrypted data, it allows you to satisfy PCI requirements for dual control and separation of duties.  QSA auditors will look to make sure the same person who has access to encrypted data doesn’t have access to encryption keys (dual control).   It is important to restrict access to certain keys by certain users or groups (separation of duties).  You don’t want the same person who has access to encrypted data to have have access to keys that unlock that data.

2) Rotate encryption keys. PCI DSS states that you need to periodically rotate the encryption key. This can be a very time consuming task if done manually and may even be overlooked because it can be a very complex project, depending upon your encryption code. Our encryption key management solution allows you to schedule regular key rotations and enforce your internal security policies while meeting PCI requirements.

3) Log all encryption key activity.  Alliance Key Manager has built in logging, which allows administrators to track all key retrieval, management, and system activity. Reports can be sent automatically to central log management, alerting facilities, or SIEM products for a timely and permanent record of activity.

4) Certification.  Our encryption key management solution is FIPS 140-2 Level 1 certified, ensuring you are effectively managing keys to industry standards.   

5) Don’t let cost be a barrier to meeting compliance requirements. If you have looked at key management solutions, you know they can be costly.  Alliance Key Manager (enterprise and SQL Server editions) are priced with the mid-market customer in mind. I think this was the fact that resonated with people I spoke with the most.  They were happy to hear about a solution that is easy to implement, as well as cost-effective.

We handed out this useful PCI DSS and Key Management matrix at the conference, several people found it useful. Download your copy to learn more about key management requirements. And if your company knows you need an encryption key management solution, give us a call. We are happy to spend a 15-minute technical overview with you and your team to find out how we can help you.

A little over a year ago Mastercard sent a shot over the bow of Level 2 Merchants when they informed them that they would have to undergo a PCI DSS audit by a qualified QSA auditor, or send internal IT staff to ISA training given by the PCI Security Standards Council. Level 2 merchants had been completing a Self-Assessment Questionnaire (SAQ) each year, and this represented a big step-up in the requirements.

Merchants scrambled to prepare for this new requirement which was due to take effect on June 30, 2011. A number of Level 2 merchants signed up early for the ISA training, and several training sessions were held in the US and Europe. Annual training and certification seemed more attractive than an on-site QSA audit to many merchants, probably because of the cost associated with an on-site audit. But I am guessing that the demand for ISA training out-stripped the availability of classes.

Mastercard just announced a postponement of the SDP ISA requirement:

“In June, 2011, MasterCard announced revisions to the SDP Program mandate by postponing the implementation date of the Level 1 and Level 2 merchant internal audit staff training and certification requirements until 30 June 2012. MasterCard has postponed the implementation date of the Level 1 and Level 2 merchant internal audit staff training and certification requirements to accommodate for the PCI SSC’s global rollout of the ISA Program and to provide Level 1 and Level 2 merchants in all regions with the opportunity to attend the ISA Program and pass the associated accreditation examination.”

The full announcement is here.

I believe that this announcement is a good faith action on the part of Mastercard to help merchants meet the requirement. We saw a similar action on the part of the State of Massachusetts when they delayed the implementation of their mandatory encryption requirements for consumer privacy. These requirements were eventually placed into effect and are now law. Level 2 merchants should not interpret this as a reprieve from having to meet these requirements. If you aren’t scheduled for ISA training, get registered now and don’t put it off!  You are going to need to meet these requirements and the sooner you get the training done the better off you are going to be.

By the way, I’ve heard great reports on the training! It is practical and effective, and Level 2 merchants are reporting a lot of benefits from the training.

Be sure to follow us on Facebook, Twitter, and LinkedIn to stay up to date on the latest technology and news about data protection.

Patrick

 

   

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

We are now past the half-way mark between PCI DSS version 1.2 and PCI DSS version 2. During this year of 2011 merchants have the option of qualifying under either version of the data security standard. Starting on January 1 of 2012, the only option will be to meet the version 2 standard. So, what trends have we observed?

Level 1 merchants are doing pretty well meeting the data security requirements because they’ve been through several cycles of on-site QSA audits. With the basic security controls in place, they are focusing on implementing better real-time monitoring and learning to react quickly to new threats. We still see breaches among large retailers because the bad guys are getting better, but the larger merchants have really stepped up their game.

The picture is not so bright with Level 2 and Level 3 merchants. Level 2 merchants now have to undergo an on-site QSA audit, or do annual training with a PCI SSC certified trainer. This is having a big impact on a lot of these merchants whose security controls were not up to par. They are having to deploy better monitoring systems, and meet industry best practices for encryption and key management. And key management is turning out to be a problem area from many of these mid-tier merchants.

What are the key management problems that I am hearing about? Here are some examples:

• A retailer with an eCommerce web site running on a Windows platform is encrypting data in a SQL Server database, but the key is stored on another server in the clear. A QSA auditor required that the merchant deploy better key management practices.
• A large manufacturer runs a user group and collects membership fees from a web site which are then processed on an IBM System i (AS/400) platform. The encryption keys were stored in encrypted format on the same server. A QSA auditor at their payment processor required that they institute better key management practices by storing the keys in an HSM on a physically separate server.
• A division of a large home improvement retail chain accepted customer orders from a web site, and processed the authorization transactions on a Linux server. The encryption keys were stored on a removable storage device. The payment processor rejected their self-assessment questionnaire on the basis of key management practices. The division migrated to the corporate key management solution to mitigate the issue.
• A software vendor who provides web hotel reservation portals uses both a Windows application and a Linux application to process reservation requests and payments. PCI standards require that credit card numbers be encrypted as data moves through both server environments. This software developer had good advice and chose a defensible key management strategy from the start.

I think you get the idea. Starting with a good key management solution is going to save you some grief later. We helped each of these companies meet PCI DSS compliance for key management, and in most cases it really didn’t take that much time or effort. But better to get it right from the start!

To learn more, download our white paper on encryption key management requirements for PCI.

Companies of all sizes feel the increasing pressure to protect sensitive customer information to meet PCI-DSS Standards.  Here are five ways to help ensure your database meets PCI requirements: 

1) Use certified encryption solutions to protect cardholder data

A standards-based encryption solution safeguards information stored on databases. Encryption methods approved by the National Institute of Standards and Technology (NIST) provide assurance that your data is secured to the highest standards.  

2) Encrypt cardholder data that is sent across open, public networks
Transmit sensitive files over the internet using trusted encryption technologies. (AES, SSH, SSL, and PGP).

3) Store encryption keys from your encrypted data on a certified encryption key management appliance
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.

4) Enforce dual controls and separation of duties for encrypted data and encryption keys
Make sure people who have access to your encrypted data are restricted from accessing the encryption keys and vice versa. If someone can access your encrypted data and access the keys, your data is compromised.  You shouldn’t lock your door and leave the key under the mat for easy access to your home, the same precautions should be taken with your sensitive data.

5) Use tokenization to take servers out of the scope of compliance
Tokenization replaces sensitive data with a token. The token maintains the original data characteristics but holds no value, reducing the risk associated sensitive data loss. When you store tokens on a separate token server it eliminates the need to store the original data in an encrypted format, and may take the server out of scope for compliance.

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

 

Smart phone payment systems have exploded over the last few months offering the specter of turning every street vendor into a walking, talking, credit-card accepting, free-spirited merchant. In some cases smart phone payment vendors are giving away free card readers just by signing up. Some people saw this as the welcome exuberance of democratic capitalism with innovation driving new opportunities. Others saw this as the apocalypse for credit card security.  Is there some middle ground here?

Last November the PCI Security Council took the unprecedented step of suspending all Payment Application Data Security Standard (PA-DSS) certifications of smart phone payment applications, and refused to accept new applications based on that platform. That sent a signal to all established merchants that the council had serious concerns and would be issuing new guidance. Established vendors of payment solutions were left in limbo, and new startups who wanted into this field found themselves stalled. Nerve wracking to say the least.

Today the PCI Security Council removed some of the uncertainty about smart phone payment systems by issuing some preliminary guidance.  You can read the press release here.

In the press release you can find initial guidance on what smart phone applications might qualify for PA-DSS certification, and which applications will likely be excluded from the process.  You can find that guidance here.

This guidance is bleak for almost all of the smart phone applications currently in the market.  In regards to applications that will NOT be considered for certification, this item stands out:

 

13. Does the application operate on any consumer electronic handheld device (e.g., smart phone, tablet or PDA) that is not solely dedicated to payment acceptance for transaction processing?

 

Does this mean that a merchant can’t use a smart phone application for payment processing? Nope, the council addresses that, too. If you want to accept payments using smart phone technology, you must include the smart phone application as a part of your normal PCI DSS review process. So, as a merchant, that is your path to PCI compliance. But I don’t think it is time to pop the cork quite yet.

A normal PCI DSS review looks at all of the systems that process credit card information, and the systems they connect to. A payment application that has connectivity to another system generally puts that system into scope for PCI compliance. Your average smart phone connects to hundreds of millions (billions?) of servers on the Internet. That’s a scope of compliance from your worst nightmare.  So I don’t think we will see a rush by merchants to include smart phones in their PCI DSS plans.

Where is all of this going?

I think some smart phone vendors will move towards dedicated devices for payments. Some vendors of WiFi payment systems may incorporation solutions based on the less expensive smart phone platform. We might also see the emergence of alternative payment technologies that don’t directly involve credit card swipes (think something like PayPal?). Things look bad for those smart phone payment applications that got into the market early. If you are the Balloon Man working the local flea markets, don’t throw away that donation hat just yet.

For more data privacy news and tips, follow us on Facebook, Twitter, and LinkedIn.

    
   

5 Commonly Asked Questions About Data Privacy

The job to protect sensitive data often falls in the hands of IT security administrators and their teams because of their technical expertise. We feel data protection is everyone's responsibility because every employee has an invested interest in maintaining their organization's good reputation with customers and partners.

We have compiled questions from discussions over the years with  customers and prospects to help people understand the basics of data privacy and why responsibility of maintaining data integrity goes beyond the IT department.  In addition to this list, we have produced a podcast with more information - download it here.

1. What constitutes personal information that we have to protect and how do businesses protect this information?

The first things people think of are credit card or social security numbers.  However, other pieces of information are equally as important.  Think about the things your bank asks you when you call them to talk about your account. Can you verify your phone number? The last four digits of your social security number? Your birthdate? Maiden name? These pieces of information can be used to commit fraud. 

The banks are using that information to identify you. And the fraudsters will use that information to impersonate you. The technical term for this kind of information is Personally Identifiable Information, or PII.

Businesses can protect data with a few different techniques involving third-party software solutions and implementing internal policies around who has access to data.

Vendor solutions can provide the ability to control who has access to data inside the company and prevent potential hackers from gaining access to your network.   Companies can also use vendor solutions to encrypt their data. Encryption is a process that takes sensitive information and runs it through a scrambling process. Once encrypted, your data can only be deciphered with a special key.  The data is useless to the person that attempts to steal it, unless they they have the key.

2. We’ve been hearing a lot about encryption and key management. How do they relate to each other?

They go together, they are complementary technologies. In addition to the raw credit card number, another very important input to the encryption is the secret key.  Without the key, no one can read the encrypted data. Many people think that an encryption algorithm itself is a secret mechanism, but that’s not the case. Encryption is well understood, there are standards for it and they’re readily available.  The secret that prevents malicious users from stealing data is the encryption key.

At home, the key to your front door is what protects you. Companies that use encryption have to create a key that is unique and strong, and then protect it to ensure it doesn’t get into the wild. Anyone who has the key can get the data. In the real world of protecting data with encryption, the encryption key is what users are taking care to protect.

3. What happens when the encryption is not done correctly?

There are many ways that encryption can be done incorrectly or poorly. We see that particularly around the area of encryption key management. One big mistake many people make is storing an encryption key on the same platform where the data are stored. Sometimes you hear the term integrated key management to describe this practice. Even if you lock down the database, keeping it on the same partition as your data leaves it readily accessible for potential cracking.

Other examples are using nonstandard or proprietary encryption. It’s important that a company buying encryption technology should vet their vendors carefully. NIST certified encryption is the best assurance that a solution meets your compliance requirements.

4. Are there any laws or regulations requiring businesses to protect their sensitive data?

Yes, there are quite a few, and many companies find themselves complying with multiple regulations. If you take credit cards, you fall under the Payment Card Industry standard. That’s a private regulation promoted by the credit card vendors such as Visa and Mastercard. If you’re a bank or engaged in the banking industry, you fall under Gramm-Leach-Bliley Act and FFIEC regulation for protecting data. In the health care industry, you fall under the HIPAA/HITECH acts.  FIRPA is the regulatory environment around educational institutions.

Individual states have passed data privacy regulations and defined data breaches and the penalties for them. And the federal government is moving laws through Congress to define protections for personal information. There are quite a number of regulations that define data that needs to be protected.

5. How would my organization develop a data security policy?

It’s a real challenge especially if you’re starting for the first time, it’s easy to feel overwhelmed when hearing about data breaches on a daily basis. Keep it simple to start. There are some things you can do that are very effective up front.  Rank where the vulnerabilities are. Here are just a few to help get you started:

1. Make sure you have good antivirus software on Windows and Mac.
2. Use good strong passwords. “1234” or “admin” are not good passwords!
3. Understand where your data resides and who has access to it.

Here’s another interesting thing, if you have a problem, it’s going to be your problem, not the vendor’s problem. It’s going to be your headache, your upset customers, and your financial loss. So pay attention to your encryption solution! 

Something that inhibits people from taking action is just thinking they are not subject to a data breach.  That’s a dangerous attitude. We've been saying it for years beause it's true - Data Gets Out. Encrypt it! 

Download the complete podcast here.

The new PCI Data Security Standards (PCI DSS v2.0) are here and we’ve gotten a lot of questions about the changes related to encryption key management. Because we work with a lot of companies going through PCI compliance audits and reviews, the new standards just confirm the trends we’ve seen over the last few months on how QSA auditors and security professionals view encryption key management, and what they see as the minimum requirements for managing keys. I recently sat down with Patrick Townsend, Founder & CTO of Townsend Security, to discuss the new PCI regulations in regards to encryption key management.  To hear an expanded podcast of our conversation, click here.

 

What is the source of industry best practices for key management?

 

The NIST special publication SP-800-57 provides specific pointers on best practices for both procedurally managing encryption keys, and what to look for in key management systems. In these documents you will find the genesis of most standards regarding encryption key management, including the concepts in PCI DSS 2.0 Section 3.

Also, key management solutions are certified to the FIPS-140-2 standard for cryptographic modules. So FIPS-140 is a source of best practices and standards.

 

Dual control, separation of duties, and split knowledge have been buzz topics in the key management world lately.  What do they mean?

 

Well, 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.

 

Split knowledge is defined in the PCI DSS version 2.0 glossary as a “condition in which two or more entities separately have key components that individually convey no knowledge of the resultant cryptography key.”

 

Are there any standards or best practices regarding “integrated key management?”

 

“Integrated key management” is a term of art, and not a standard.  If “integrated key management” means “we store our encryption keys on the server where the data is,” then that is a bad thing, from a compliance and security point of view. 

 

So, what are the best practices for encryption key management?

 

First you should follow the key life-cycle and be able to document it.  You should always separate the keys from the data.  If you follow the PCI guidelines, you are in excellent shape.  Finally, I would recommend only using a FIPS 140 certified key management solution.

 

What are the practical implications of these best practices and core concepts such as “dual control” and “separation of duties?”

 

One of the practical implications follows from a common fact of system administration. On all major operating systems such as Linux, Windows, and IBM System i (AS/400) there is one individual who has the authority to manage all processes and files on the system. This is the Administrator on Windows, the root user on Linux and UNIX, and the security officer on the IBM i platform. In fact, there are usually multiple people who have this level of authority. In one study by PowerTech, the average IBM System i customer had 26 users with this high level of authority! You just can’t meet PCI and other industry standards for proper key management by storing the encryption keys on the same platform as the data you are trying to protect.

 

To download an expanded podcast of our conversation, click here.