Townsend Security Data Privacy Blog

PCI Cloud Computing Guidelines Bombshell - Where to Now?

Posted by Patrick Townsend on Dec 4, 2018 9:31:26 AM

PCI LogoIn April of this year the Payment Card Industry Security Standards Council (PCI SSC) released a new document on cloud guidance called “Information Supplement: PCI SSC Cloud Computing Guidelines”. It was an update of the first version of the guidance issued in 2013. While this is not a set of mandatory rules, it is a core guidance document and recommendations in PCI guidance documents often end up as requirements under the PCI Data Security Standard (PCI-DSS) and PCI Payment Application Data Security Standard (PCI PA-DSS). So it is worth understanding the guidance and it is wise to align your IT and business processes with the guidance. It is better to get things right at the beginning rather than have to rip-and-tear to fix things later.

Encryption Key Management Industry Perspectives and Trends eBook There is another reason to pay attention to the PCI cloud guidance: The PCI standards often set the expectations for security best practices in other regulations, and reflect evolving industry standards such as those developed by the National Institute of Standards and Technology (NIST). Even if you are not processing credit card payments, you should be paying attention to this guidance.

When it comes to encryption key management in the cloud, there is a bombshell in this document (essentially describing services such as Amazon KMS and Microsoft Key Vault). What does the new PCI guidance say about encryption and key management? Let’s parse it out and see where it goes.

Take a look at appendix E.10 “Data Encryption and Cryptographic Key Management”.

Appendix E.10 starts by describing the shared, multi-tenant architecture of cloud services (pretty much states the obvious). And then makes this statement:

“If a Customer shares encryption keys with the Provider, or engages the Provider as a key custodian, details of Provider access permissions and processes will also need to be reviewed and verified.

This consideration is particularly critical if cryptographic keys are stored or hosted by a third-party Provider that also hosts the encrypted data. If Provider personnel have access to a Customer’s keys and the Customer’s encrypted data, the Customer may have unintentionally granted the Provider ability to decrypt its sensitive data.”

In fact, all cloud service providers such as Amazon (AWS), Microsoft (Azure), and Google (GCP) have access to both your data and your encryption keys if you are using their key management services. This includes AWS Key Management Service (KMS), Azure’s Key Vault, and Google’s Customer Customer-Managed Encryption Keys (CMEK). Perhaps unknowingly, you HAVE granted your cloud provider the ability to decrypt your sensitive data.

Here is how the PCI SSC sees the risk:

“Any data that is decrypted in the cloud may be inadvertently captured in clear text in process memory or VMs via cloud maintenance functions (such as snapshots, backups, monitoring tools, etc.). To avoid this risk, Customers may choose to keep all encryption/decryption operations and key management on their own premises, and use a public cloud only for storage of the encrypted data.

Applicable controls must be applied to the encryption, decryption, and key management processes to ensure that data can only be retrieved (decrypted) by those who are authorized with a defined business need.”

Wow, that’s a pretty strong statement about not allowing your cloud provider have access to your encryption keys and sensitive data. It is hard to imagine a scenario where the cloud service provider has a “defined business need” to access your sensitive data.

Pointing back to the perceived risks of the cloud provider, here is the key point in the PCI cloud guidance:

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.

Wow, there you have it. Don’t use the cloud service providers key management service because there is too much risk. This recommendation affects a very large number of users in the cloud.

Where do we go from here?

Fortunately, there are solutions available now to solve this problem (we have one). Let’s outline some options. There will be pluses and minuses for each one. But the good news is that there are multiple solutions to this issue.

1. Deploy your own dedicated key manager in your own on-premise data center

It is fairly easy to deploy an encryption key manager in your own data center and enable its use by cloud applications. Most enterprise key managers use a secure TLS-encrypted session to interoperate with the key manager. Once you enable an outbound TCP port to your key manager, you can easily use the on-premise key manager. Note that this could be a hardware security module (HSM) or a virtual key management appliance running in VMware.

Remember that you probably do not have to retrieve the encryption key from the key server to your cloud application - most key managers support on-board encryption and decryption services. This alleviates the risk of an exposure of the encryption key in cloud memory. Performance will be the important factor to weigh in this regard. While the key manager may be quite efficient in the encryption or decryption operation, the communications lag times may mitigate against this approach.

2. Deploy your own dedicated key manager in a hosted platform

If your organization does not have on-premise infrastructure for a key manager, don’t despair. It is really straightforward to deploy a key manager in a hosted environment. A hosting provider can provide a home for a hardware security module, or for a software appliance. Establishing the firewall rules may take a bit more work, but this is an approach that has worked well for our customers.

3. Deploy your own dedicated key manager in a different cloud

One creative option to separate the encryption keys from the protected data is to deploy the key manager in a different cloud platform. You could, for example, deploy your application data in Amazon Web Services, and deploy the key manager in Microsoft Azure. This helps mitigate the risk of one cloud service provider having access to both your encryption keys and your protected data - one of the key concerns expressed in the PCI guidance.

Note that this solution will probably require that you work with the firewall rules in both cloud provider platforms. The good news is that this is not complicated - we have customers doing this today.

4. Deploy your own dedicated key manager in a separate cloud instance

Lastly, it is possible to deploy a dedicated key management solution in the same cloud as your protected data, but completely avoid the use of the cloud provider’s encryption key management infrastructure. The key server runs in its own virtual machine or EC2 instance and encryption key management is exclusively dedicated to you. If you take this approach, but sure that your key management vendor is not using the cloud providers encryption key management infrastructure! Encryption keys and key management should only be accessible to you and not to your vendor or cloud provider.

I know that some cloud customers are reluctant to take this approach due to concerns about the ability of the cloud provider to access all of the customer applications and data on their platform, including a key management system running in the cloud. Personally I think the risk is minimal, but if you have that concern see the previous alternatives.

In summary, it would be prudent to avoid the use of cloud service provider key management services such as AWS KMS, Azure Key Vault, and Google Customer-Managed Encryption Keys (CMEK). These services will put you at odds with the PCI cloud security recommendations, and likely put you in variance with future regulations. Not a good place to be.

My advice? Get encryption key management right from the beginning. If you are using a cloud provider’s KMS, start your migration now. You have readily-available choices that are affordable. Get started now!

Our Alliance Key Manager is validated to PCI-DSS and available in cloud, VMware, and HSM platforms. You can do this! Get started here.

Patrick

New Call-to-action

Topics: PCI Encryption, PCI DSS, Encryption Key Management

Top 3 Areas of Weakness when Undergoing a PCI Audit for the First Time

Posted by Sophia Khan - CyberGuard Compliance on Apr 17, 2018 8:21:00 AM

Guest blog by Sophia Khan of CyberGuard Compliance


CyberGuard-Word-CloudWith all of the security breaches you hear of in the news and the occurrence of these incidents becoming more widespread, how can you be sure your customer’s credit card information remains secure? This is the purpose of PCI DSS (Payment Card Industry Data Security Standards) as it pertains to all merchants who accept credit cards, irrespective of their annual revenue and credit card transaction volume. Even with this mandatory requirement, a vast majority of organizations are still struggling to maintain PCI compliance, and the process is costing companies a great deal in consulting fees to address the root cause of PCI audit failures. By being proactive in assessing the areas of weakness when undergoing a PCI Audit, especially for the first time, companies can avoid the frustrations of a failed audit and be well on their way to continued PCI compliance.

FIRST TIME PCI AUDIT AREAS OF WEAKNESS:

 

1) Encryption Key Management

Several sections of PCI DSS address cryptography and key management with respect to the protection of cardholder data. When a company is unfamiliar with the ever-evolving encryption standards and requirements, this can provide additional challenges in maintaining PCI compliance. PCI DSS does not specify which cryptographic standards should be utilized, however most companies do implement Advanced Encryption Standard (AES) and Triple Data Encryption Standard (TDES), which are widely accepted for the encryption of sensitive data. These are the standards approved by the National Institute of Standards and Technology (NIST).

The list of requirements includes the protection of cryptographic keys utilized for the use of encryption of cardholder data by limiting access to the fewest number of custodians necessary, and the secure storage of keys in as few locations as possible. Additionally, cryptographic keys generated need to be strong with secure key distribution and storage, with periodic key changes being mandatory. For example, if a vendor hosts your encryption keys, then they along with hackers can most likely access it. Therefore, it is essential for maximum security to exclusively host your own encryption keys.

The solution to the complex issue of encryption key management, is the utilization of encryption and tokenization tools which will protect sensitive information with NIST-validated AES database encryption. There are five fundamentals of encryption key management:

  1. Key storage
  2. Key policy management
  3. Key authentication
  4. Key authorization
  5. Key transmission

By implementing a strong key management application, secure data can be protected and there will be prevention of third-parties from accessing unencrypted content.  

2) Two-Factor Authentication

Passwords are typically the first and final line of defense in protecting user accounts. They are also the easiest for hackers to crack and on their own can compromise the security of sensitive information. Two-factor authentication, also known as multi-factor authentication, significantly reduces the risk of system intrusion, as you are required to utilize both a password as well as an additional measure such as a security code sent to a mobile device. PCI security standards require at least two of three authentication methods described in the requirement to be utilized.

  • Something you know: This utilizes knowledge of something such as a password, PIN, or phrase.
  • Something you have: This may involve an RSA token device, smartcard, key fob, or cellular device with mobile authentication.
  • Something you are: This involves biometric measures such as a fingerprint or retina scan, facial or voice recognition, or other unique physical identification.

By utilizing two-factor authentication, companies can reduce the security threat of possible intrusion with added authentication mechanism beyond a simple password.

3) System Logging

Section 10 of the PCI DSS indicates organizations must track and monitor all access to network resources and cardholder data. This is one of the most important PCI compliance requirements as it related to network security and access. The requirement has many subsections outlining what needs to be fulfilled in order to maintain compliance in this section.

The following must be logged and maintained:

  • There must be a system for logging access to all system components and every individual user.
  • Audit trails for each of the following must be established:
    • Individual users with cardholder data;
    • All actions performed by users with administrative privileges;
    • All invalid access attempts;
    • Tracking of audit log clearings;
    • Secure assessment trail logs and access restriction to those with a job-related need.

System logging capabilities and the function to track user activities are imperative in detecting, preventing, and diminishing the potential impact of a data security breach. In the absence of system activity logs, it would be near impossible to detect the cause of a compromise and correct it. By maintaining knowledge of who had access to the system what they used the data for, a company can be proactive in the event cardholder data goes missing or there is suspicion of any foul play.

In recent times, many organizations have fallen into the ‘check the box’ category, where PCI compliance is simply a mandatory prerequisite they try and get through for the sake of fulfilling a minimum requirement. By practicing good cybersecurity hygiene on a consistent basis, and being cognizant of the potential areas of weakness, your Company can ensure cyber-risk management is a continued priority as you minimize operational risks. This will also allow your firm to stay ahead of the curve as technology evolves when the standard updates with time.

Visit CyberGuard Compliance’s website to learn more about their services relating to PCI audits.

About CyberGuard Compliance
CyberGuard Compliance is based in the United States, but serves clients around the globe. The firm’s leadership team has over 150 years of combined business management, operations and related information technology (IT) experience. CyberGuard Compliance has performed over 1,000 SOC audits, and unlike most traditional CPA firms which focus on financial statement auditing and tax compliance, CyberGuard Compliance focuses on cybersecurity and compliance related engagements. These engagements include, but are not limited to, SOC 1 Audits, SOC 2 Audits, SOC 3 Audits, SOC Readiness Assessments, ISO 27001 Assessments, PCI Compliance, HIPAA Compliance, HITRUST Compliance, Vulnerability Assessments, and Penetration Testing. For more information, please visit https://www.cgcompliance.com.

Topics: Compliance, PCI DSS

Privately Held Companies Think They Don’t Need to Worry About Security and Compliance

Posted by Patrick Townsend on Sep 13, 2016 9:37:33 AM

In my role at Townsend Security I engage with companies both large and small and have many conversations about data breaches and security. One pattern that I see a great deal is the belief by privately held companies that they are not subject to compliance regulations, are not a target by cybercriminals, and don’t have much to worry about. The feeling seems to be “Gee, we are not publicly traded so we don’t have to do all that security stuff. It’s hard and expensive and it doesn’t really apply to us. Besides, we are too small for hackers to bother with.” I’m sure I’ve heard exactly these comments a number of times.

For the sake of these small businesses who represent the real backbone of our economy, we need to dispel these myths. Let’s look at a few of them:

We Don’t Need to Meet PCI Compliance
Download Whitepaper on PCI Data Security Anyone who takes credit or debit cards in their business must comply with the PCI Data Security Standard (PCI-DSS). When you signed your merchant agreement you agreed to be bound by the data security standards for payment cards. This is not a government regulation - this is an agreement between you and your payment provider and they all require this compliance. It doesn’t matter if you are small or large, privately held or publicly traded on the NYSE. You have to meet PCI compliance for security. Failure to comply with PCI-DSS standards can put you a jeopardy for loss of the ability to accept credit card payments. This can be devastating for any company.

I Only Store a Small Number of Credit Cards, PCI Doesn’t Apply to Me
This is an incorrect understanding of the PCI Data Security Standard. Processing a small number of payment transactions, or a low dollar amount, may put in you a lower category for PCI compliance, but the PCI-DSS still applies to you. In the event of a data breach you may find that you have new on-site PCI audit requirements, additional liabilities, and you may have to pay a higher rate to authorize payment transactions. These effects can really hurt your business. Rest assured that if you take credit card payments the PCI-DSS requirements apply to you.

We Don’t Need to Meet HIPAA Compliance and Reporting
If you are a medical organization defined as a Covered Entity under HIPAA regulations you need to meet HIPAA data security requirements. This includes both privately held as well as publicly traded organizations. There is no exclusion for privately held organizations whether you are a country doctor with a small practice or a large HMO or hospital chain. A quick review of the compliance actions by OCR shows that privately held organizations are just as likely to be fined as larger organizations. And penalties often do not stop at monetary fines, there are often requirements for years of on-site security audits and assessments that are very costly.

We are Not Big Enough to be a Target
Many executives and members of the IT organization at privately held companies believe that they are not a target of hackers and cybercriminals simply because they are privately held and small. This falls into the category of wishful thinking. In fact, as the FBI reports, smaller private companies are increasingly the focus of cybercriminals and are experiencing significant financial losses. Here is what John Iannarelli, and FBI consultant, says:

"Time and again I have heard small business owners say they have nothing to worry about because they are too small to interest cybercriminals. Instead, small businesses are exactly who the criminals are targeting for two primary reasons. In the criminal's mind, why go after large companies directly, when easier access can be attained through small business vendor relationships. Secondly, since small businesses have less financial and IT resources, criminals know they are less 'compromise ready' and tend to be less resilient."

We Don’t have to Report a Data Breach
Many smaller privately held companies are under the mistaken impression that compliance laws do not require them to report a data breach. This is incorrect - state and federal laws that require data breach notification require small businesses and privately held companies to report data breaches. Being small or privately held does not exclude you from data breach notification.

Compliance Regulations Don’t Apply to Us
It is true that if you are a private company the Sarbanes-Oxley compliance regulations certainly do not apply to you, those regulations only apply to publicly traded companies. And the Federal Information Security Management Act (FISMA) does not apply to you because it only applies to US government federal agencies. You are, however, covered by state privacy law, PCI Data Security Standards (if you accept credit or debit cards), HIPAA if you are a Covered Entity in the medical segment or if you process patient data for a Covered Entity, and the Federal Trade Commission (FTC).

We are Not Under FTC Rules About Data Privacy
The Federal Trade Commission has a broad charter to protect consumers and this includes enforcement for consumer privacy. From large companies like Google, Facebook and Twitter to small companies like an auto dealership, the FTC has taken enforcement actions that include private companies. The enforcement actions can include fines, mandatory audits that last for many years, and other penalties. Private companies do fall under FTC jurisdiction. You can read more about the FTC and data privacy here.

In summary, smaller privately held companies are the target of cybercriminals, are less prepared to deal with an attack, and have fewer resources to recover from an attack. No competent executive in a privately held company would forgo general liability insurance for their business, but are much more likely to suffer a loss from a cyber attack. It is not good business sense to ignore real threats.

Some last thoughts from the FBI:

The criminal then either creates another account or directly initiates a funds transfer masquerading as the legitimate user. The stolen funds are often then transferred overseas. Victims of this type of scheme have included small and medium-sized business, local governments, school districts, and health care service providers.

The potential economic consequences are severe. The sting of a cyber crime is not felt equally across the board. A small company may not be able to survive even one significant cyber attack.

From a Washington Post interview with the FBI:

Federal agents notified more than 3,000 U.S. companies last year that their computer systems had been hacked, White House officials have told industry executives, marking the first time the government has revealed how often it tipped off the private sector to cyberintrusions.

The alerts went to firms large and small, from local banks to major defense contractors to national retailers such as Target, which suffered a breach last fall that led to the theft of tens of millions of Americans’ credit card and personal data, according to government and industry officials.

“Three thousand companies is astounding,” said James A. Lewis, a senior fellow and cyberpolicy expert at the Center for Strategic and International Studies. “The problem is as big or bigger than we thought.”

Others notified by the Secret Service last year included a major U.S. media organization, a large U.S. bank, a major software provider, and numerous small and medium-size retailers, restaurants and hotels, officials said.

“Within hours of us coming up with information that we can provide, we would go to a victim,’’ said Edward Lowery, Secret Service special agent in charge of the criminal investigative division. “The reaction would be just like when you’re told you’re the victim of any crime. There’s disbelief, there’s anger, all those stages, because there’s a lot at stake here.”

Yes, Indeed. There is a lot at stake.

download the Whitepaper: Meet the Challenges of PCI Compliance

Topics: Compliance, PCI DSS

IBM i, PCI DSS 3.2, and Multi-Factor Authentication

Posted by Luke Probasco on Aug 16, 2016 10:48:05 AM

With the recent update to the Payment Card Industry Data Security Standard (PCI DSS) regarding multi-factor authentication (also known as Two Factor Authentication or 2FA), IBM i administrators are finding themselves faced with the requirement of deploying an authentication solution within their cardholder data environments (CDE). Prior to version 3.2 of PCI DSS, remote users were required to use two factor authentication for access to all systems processing, transmitting, or storing credit card data. With version 3.2 this is now extended to include ALL local users performing administrative functions in the CDE.

Here is an excerpt from section 8.3: (emphasis added)

8.3 Secure all individual non-console administrative access and all remote access to the cardholder data environment (CDE) using multi-factor authentication.

IBM i, PCI DSS, & Multi-Factor Authentication I recently was able to sit down with Patrick Townsend, Founder & CEO of Townsend Security, and talk with him about PCI DSS 3.2, what it means for IBM i users, and what IBM i users can do to meet the latest version of PCI DSS.

Thanks for taking some time to sit down with me, Patrick. Can you recap the new PCI-DSS version 3.2 multi-factor authentication requirement? This new requirement seems to be generating a lot of concern.

Well, I think the biggest change in PCI DSS 3.2 is the requirement for multi-factor authentication for all administrators in the cardholder data environment (CDE).  Prior to 3.2, remote users like contractors and third party administrators, had to use multi-factor authentication to login to the network.  This update extends the requirement of multi-factor authentication for ALL local, non-console users.  We are seeing businesses deploy multi-factor authentication at the following levels:

  •      Network Level - When you first access the network
  •      System Level – When you access a server or any system with the CDE
  •      Application Level – Within your payment application

The requirement for expanded multi-factor authentication is a big change and is going to be disruptive for many merchants and processors to implement.

Yeah, sounds like this is going to be a big challenge.  What does this mean for your IBM i customers?

There are definitely some aspects of this PCI-DSS update that will be a bigger challenge on the IBM i compared to Windows or Linux.  First, we tend to run more applications on the IBM i.  In a Windows or Linux environment you might have one application per server.  On the IBM i platform, it is not uncommon to run dozens of applications.  What this means is, you have more users who have administrative privileges to authenticate – on average there can be 60 or more who can sometimes be a challenge to identify!  When merchants and processors look at their IBM i platforms, they will be surprised at the number of administrators they will discover.

Additionally, the IBM i typically has many network services exposed (FTP, ODBC, Operations Navigator, etc).  The challenge of identifying all the entry points is greater for an IBM i customer.

You say it is harder to identify an administrative user, why is that?

On the IBM i platform, there are some really easy and some really difficult administrative users to identify.  For example, it is really easy to find users with QSECOFR (similar to a Windows Administrator or Linux Root User) privileges.  But it starts to get a little more difficult when you need to identify users, for example, who have all object (*ALLOBJ) authority.  These users have almost the equivalent authority of QSECOFR.  Finding, identifying, and properly inventorying users as administrators can be a challenge.

Additionally, with a user profile, there is the notion of a group profile.  It is possible for a standard user, who may not be an administrator, to have an administrative group profile.  To make it even more complex, there are supplemental groups that can also adopt elevated authority.  Just pause for a minute and think of the complex nature of user profiles and how people implement them on the IBM i platform.  And don’t forget, you may have users on your system who are not highly privileged directly through their user profile, but may be performing administrative tasks related to the CDE.  Identifying everyone with administrative access is a big challenge.

Townsend Security has a multi-factor authentication solution for the IBM i.  How are you helping customers deal with identifying administrators?

From the beginning, we realized this would be a problem and we have taken some additional steps, specifically related to PCI DSS 3.2 to help IBM i customers identify administrators.  We made it possible to build a list of all users who have administrative access and then require them to use multi-factor authentication when logging on.  We have done a lot to help the IBM i security administrator identify highly privileged users and enroll them into a two factor authentication solution, and then periodically monitor/update/audit the list.

What are some of the other multi-factor authentication challenges that IBM i customers face?

Some of them are pretty obvious.  If you don’t have a multi-factor authentication solution in place, there is the effort of evaluating and deploying something on the IBM i server.  You’ll find users who may already have a multi-factor authentication solution in place for their Windows or Linux environments, but haven’t extended it to their IBM i.  Even if they aren’t processing credit card numbers on the IBM i, if it is in the CDE, it still falls within the scope of PCI DSS.

Aside from deploying a solution, there is going to be administrative work involved.  For example, managing the new software, developing new procedures, and putting governance around multi-factor authentication.  Further, if you adopt a hardware-based solution with key FOBs, you have to have processes in place to distribute and replace them, as well as manage the back-end hardware.  It has been really great seeing organizations move to mobile-based authentication solutions based on SMS text messages where there isn’t any hardware of FOBs to manage.  Townsend Security’s Alliance Two Factor Authentication went that route.

Let’s get back to PCI DSS.  As they have done in the past, they announced the updated requirements, but businesses still have a period of time to get compliant.  When does PCI DSS 3.2 actually go into effect?

The PCI SSC always gives merchants and processors time to implement new requirements.  The actual deadline to meet compliance is February 1, 2018.  However, what we are finding is that most merchants are moving rapidly to adopt the requirements now.  When an organization has an upcoming audit or Self Assessment Questionnaire (SAQ) scheduled, they generally will want to meet the compliance requirements for PCI DSS 3.2.  It never is a good idea to wait until the last minute to try and deploy new technology in order to meet compliance.

You mentioned earlier that you have a multi-factor authentication solution.  Tell me a little bit about it.

Sure. Alliance Two Factor Authentication is a mature, cost-effective solution that delivers PINs to your mobile device (or voice phone), rather than through an expensive key FOB system. IBM i customers can significantly improve the security of their IBM i systems through implementation of proven two factor authentication.  Our solution is based on a non-hardware, non-disruptive approach.  Additionally, we audit every successful or failed authentication attempt and log it in the security audit journal (QAUDJRN).  One thing that IBM i customers might also be interested in, is in some cases, we can even extend their existing multi-factor authentication solution to the IBM i with Alliance Two Factor Authentication.  Then they can benefit from the auditing and services that we supply for the IBM i platform.  Our goal was to create a solution that was very cost-effective, rapid to deploy, meets compliance regulations, and doesn’t tip over the IT budget.

Download a podcast of my complete conversation here and learn more about what PCI DSS 3.2 means for IBM i administrators, how to identify administrative users, challenges IBM I customers are facing, and how Townsend Security is helping organizations meet PCI DSS 3.2.

Podcast: IBM i, PCI DSS, and Multi-Factor Authentication

 

Topics: 2FA, IBM i, PCI DSS

Data Protection in the Cloud & PCI DSS - Logs and Log Monitoring (Part 3)

Posted by Patrick Townsend on Mar 18, 2015 9:16:00 AM

This is the third part in our series looking at recent announcements by Amazon, Microsoft and other cloud service providers regarding new encryption and key management services. Let’s talk about log collection and active monitoring as a security best practice, and as a requirement to meet PCI DSS security requirements. Since the PCI DSS guidelines implement common security best practices, they are a good starting point for evaluating the security of any application and platform that processes sensitive data. Following the practice of the first part of this series we will use the PCI document “PCI DSS Cloud Computing Guidelines, Version 2.0” as our reference point, and add in some other sources of security best practices. Even if you don’t have to meet PCI data security requirements, this should be helpful when evaluating your security posture in the cloud.

Download Whitepaper on PCI Data Security

Collecting system logs and actively monitoring them is a core component of every cyber security recommendation. Cybercriminals often gain access to IT systems and go undetected for weeks or months. This gives them the ability to work on compromising systems and stealing data over time. Active monitoring is important in the attempt to detect and thwart this compromise.

Here is what PCI says about active monitoring in Section 10 of the PCI DSS (emphasis added):

Review logs and security events for all system components to identify anomalies or suspicious activity.

Many breaches occur over days or months before being detected. Checking logs daily minimizes the amount of time and exposure of a potential breach. Regular log reviews by personnel or automated means can identify and proactively address unauthorized access to the cardholder data environment. The log review process does not have to be manual. The use of log harvesting, parsing, and alerting tools can help facilitate the process by identifying log events that need to be reviewed.

In recognition of the importance of ongoing, active monitoring the National Institute of Standards and Technology (NIST) provides this guidance in their Special Publication 800-137 “Information Security Continuous Monitoring (ISCM)” guidance:

The Risk Management Framework (RMF) developed by NIST, describes a disciplined and structured process that integrates information security and risk management activities into the system development life cycle. Ongoing monitoring is a critical part of that risk management process. In addition, an organization’s overall security architecture and accompanying security program are monitored to ensure that organization-wide operations remain within an acceptable level of risk, despite any changes that occur. Timely, relevant, and accurate information is vital, particularly when resources are limited and agencies must prioritize their efforts.

And active monitoring is a component of the SANS Top 20 security recommendations:

Collect, manage, and analyze audit logs of events that could help detect, understand, or recover from an attack.

Deficiencies in security logging and analysis allow attackers to hide their location, malicious software, and activities on victim machines. Even if the victims know that their systems have been compromised, without protected and complete logging records they are blind to the details of the attack and to subsequent actions taken by the attackers. Without solid audit logs, an attack may go unnoticed indefinitely and the particular damages done may be irreversible.

Because of poor or nonexistent log analysis processes, attackers sometimes control victim machines for months or years without anyone in the target organization knowing, even though the evidence of the attack has been recorded in unexamined log files.

Deploy a SIEM (Security Incident and Event Management) or log analytic tools for log aggregation and consolidation from multiple machines and for log correlation and analysis.

This is why actively collecting and monitoring system and application logs is critical for your security strategy.

Implementing this critical security control in a cloud environment presents some special challenges. Here is what the PCI cloud guidance says:

Additionally, the ability to maintain an accurate and complete audit trail may require logs from all levels of the infrastructure, requiring involvement from both the CSP and the client. For example, the CSP could manage system-level, operating-system, and hypervisor logs, while the client configures logging for their own VMs and applications. In this scenario, the ability to associate various log files into meaningful events would require correlation of client-controlled logs and those controlled by the CSP.

It is not enough to collect logs from a few selected points in your cloud application environment. You need to collect all of the logs from all of the components that you deploy and use in your cloud application. This is because the effectiveness of active monitoring depends on the correlation of events across your entire application, database, and network and this includes the cloud providers systems and infrastructure. Here is what ISACA says about security event correlation:

Correlation of event data is critical to uncover security breaches because security incidents are made up of a series of events that occur at various touch points throughout a network--a many-to-one process. Unlike network management, which typically is exception-based or a one-to-one process, security management is far more complex. An attack typically touches a network at multiple points and leaves marks or breadcrumbs at each. By finding and following that breadcrumb trail, a security analyst can detect and hopefully prevent the attack.

Your encryption key management system is one of those critical system components that must be monitored and whose events should be aggregated into a unified view. Key management logs would include encryption key establishment and configuration, encryption key access and use, and operating system logs of every component of the key management service. You should be able to collect and monitor logs from all parts of your applications and cloud platform.

Unfortunately, current key management services from cloud providers only provide a very limited level of access to critical component logs. You might have access to a limited audit trail of your own access to encryption keys, but no access to the key service system logs, HSM access logs, HSM audit logs, or HSM operating system logs. Without access to the logs in these components it is not possible for you to implement an effective log collection and active monitoring strategy. You are working in the dark, and without full access to all logs on all components of your cloud key management service you can’t comply with security best practices for log collection, correlation, and active monitoring.

Since key management systems are always in scope for PCI audit and are extensions of your application environment it is difficult to see how these new cloud key management services can meet PCI DSS requirements for log collection and monitoring as currently implemented.

Does this mean you can’t implement security best practices for key management in the cloud? I don’t think so. There are multiple vendors, including us (see below), who offer cloud key management solutions that provide full access to key management, configuration, key usage, application, and operating system logs.  You can deploy a key management service that fully supports security best practices for log collection and monitoring.

In part 4 of this series we’ll look at the topic of key custody and multi-tenancy and how it affects the security of your key management solution in the cloud.

Patrick


Resources

Alliance Key Manager for AWS

Alliance Key Manager for Azure

Alliance Key Manager for VMware and vCloud

Alliance Key Manager for Drupal

 

download the Whitepaper: Meet the Challenges of PCI Compliance

Topics: PCI DSS, Amazon Web Services (AWS), logging, cloud, Microsoft Azure

Data Protection in the Cloud & PCI DSS - Segmentation (Part 2)

Posted by Patrick Townsend on Mar 9, 2015 2:53:00 PM

This is the second part in our series looking at recent announcements by Amazon, Microsoft and others regarding new encryption and key management services. Let’s talk about the concept of segmentation as a security best practice, and as a strong recommendation by PCI DSS security standards. Since the PCI DSS guidelines implement common security best practices they are a good jumping off point for evaluating the security of any application and platform. Following the practice of the first part of this series we will use the PCI document “PCI DSS Cloud Computing Guidelines, Version 2.0” as our reference point. Even if you don’t have to meet PCI data security requirements, this should be helpful when evaluating your security posture in the cloud.

Download Whitepaper on PCI Data Security

Segmentation as a security concept is very simple and very fundamental. Better security can be achieved by not mixing trusted and untrusted applications, data, and networks. This concept of trusted and untrusted applications extends to the value of the data assets – when applications process highly sensitive and valuable data assets they need to be separated into trusted and secure environments. We expend more effort and resources to protect what is valuable from criminals. Conversely, when there are no valuable data assets in an environment there is no need to take the same level of effort to secure them.

This is the core reason that PCI DSS recommends segmentation of applications that process payments from non-payment applications. Here is what PCI says about non-cloud applications:

Outside of a cloud environment, individual client environments would normally be physically, organizationally, and administratively separate from each other.

So, how do the PCI DSS security requirements relate to cloud platforms? Here is what PCI says (emphasis added):

Segmentation on a cloud-computing infrastructure must provide an equivalent level of isolation as that achievable through physical network separation. Mechanisms to ensure appropriate isolation may be required at the network, operating system, and application layers; and most importantly, there should be guaranteed isolation of data that is stored.

Proper segmentation is difficult to achieve even when you have complete control over all aspects of your environment. When you add the inherently shared and multi-tenant architecture of cloud platforms this becomes a high hurdle to get over. Here is what PCI says about this challenge:

Client environments must be isolated from each other such that they can be considered separately managed entities with no connectivity between them. Any systems or components shared by the client environments, including the hypervisor and underlying systems, must not provide an access path between environments. Any shared infrastructure used to house an in-scope client environment would be in scope for that client’s PCI DSS assessment.

This brings us exactly to the concern about new cloud key management services in Azure and AWS. These new services are inherently multi-tenant in both the key management services down to the hardware security modules (HSMs) that provide the ultimate security for encryption keys. You have no idea who you are sharing the service with.

The PCI guidance tells us what this segmentation looks like in a cloud environment:

A segmented cloud environment exists when the CSP enforces isolation between client environments. Examples of how segmentation may be provided in shared cloud environments include, but are not limited to: 

  • Traditional Application Service Provider (ASP) model, where physically separate servers are provided for each client’s cardholder data environment.
  • Virtualized servers that are individually dedicated to a particular client, including any virtualized disks such as SAN, NAS or virtual database servers.
  • Environments where clients run their applications in separate logical partitions using separate database management system images and do not share disk storage or other resources.

There is no cloud service provider implementation of key management services that meet these basic requirements.

The PCI DSS guidance takes a pretty strong view about inadequate segmentation in cloud environments:

If adequate segmentation is not in place or cannot be verified, the entire cloud environment would be in-scope for any one client’s assessment. Examples of “non-segmented” cloud environments include but are not limited to:

  • Environments where organizations use the same application image on the same server and are only separated by the access control system of the operating system or the application.
  • Environments where organizations use different images of an application on the same server and are only separated by the access control system of the operating system or the application.
  • Environments where organizations’ data is stored in the same instance of the database management system’s data store.

Since key management systems are always in scope for PCI audit and are extensions of your application environment and depend entirely on the access control system of the cloud provider, it is difficult to see how these new cloud key management services can meet PCI DSS requirements as currently implemented.

Here’s the last comment by PCI on segmentation in cloud environments:

Without adequate segmentation, all clients of the shared infrastructure, as well as the CSP, would need to be verified as being PCI DSS compliant in order for any one client to be assured of the compliance of the environment. This will likely make compliance validation unachievable for the CSP or any of their clients.

Does this mean you can’t implement security best practices for key management in the cloud? I don’t think so. There are multiple vendors including us (see below) who offer cloud key management solutions that we believe can be effectively isolated and segmented on cloud platforms, or even hosted outside of the cloud.

In our part 3 of this series we’ll look at the topic of logging and active monitoring and how it affects the security of your key management solution in the cloud.

Patrick


Resources

Alliance Key Manager for AWS

Alliance Key Manager for Azure

Alliance Key Manager for VMware and vCloud

Alliance Key Manager for Drupal

Alliance Key Manager for IBM Power Systems

Alliance Key Manager Cloud HSM

download the Whitepaper: Meet the Challenges of PCI Compliance

 

Topics: PCI DSS, Encryption Key Management, cloud

PCI Compliance and the Assessment Process

Posted by Michelle Larson on Dec 4, 2014 1:30:00 PM

Understanding PCI Merchant Levels and how an assessment can help your business

If your business takes credit cards for payment, then you are subject to the Payment Card Industry – Data Security Standards (PCI-DSS).

Companies of all sizes must comply with PCI DSS to ensure that their customers' data is protected during the processing and transmission of credit or debit card transactions and securely stored within any internal databases. PCI categorizes businesses into different classification levels based on the number of transactions and dollar amounts they processes each year.

Download Whitepaper on PCI Data Security

Level 1 – All merchants processing more than 6 million card transactions annually

Level 2 – All merchants processing between 1 million and 6 million card transactions annually

Level 3 – All merchants processing between 20,000 and 1 million card-not-present only transactions annually

Level 4 – All other merchants

Level 1 companies are most likely well versed in the annual PCI audit process as they have a certified onsite audit annually with a Qualified Security Assessor (QSA). Level 2, 3, 4 merchants are not required to hire an onsite QSA, but can have a certified Internal Security Assessor (ISA) do the PCI self assessment annually. However, a small business preparing a self-assessment to participate in their first PCI review may find it a little daunting. If you're feeling that the PCI assessment process is overwhelming and complicated, understanding this process may be the first step toward putting your mind at ease. If you are a Level 1 merchant, the PCI assessment is a process carried out by a QSA to establish whether or not a business is compliant with security standards relating to the processing of transactions made via a credit or debit card (payment card). PCI compliance assesses your business point of sale system, payment applications, and all interconnecting systems with these goals in mind: (1) to examine your system, (2) to identify vulnerabilities, and (3) to prevent data from being compromised.

It’s not a matter of “IF”, but “WHEN”

If you have already suffered a data breach, working closely to review your assessment and put data security best practices into place will provide you with a roadmap to help avoid future losses. If you have not yet been breached, undergoing an assessment and reviewing your risk tolerance can still be stressful. Understanding the process may alleviate some of that stress and help you to maximize your use of the information in the PCI DSS assessment report

How can a PCI audit help my business?

PCI compliance auditing helps businesses to ensure they are providing the most secure environment for their customers to process payments and ensures that transactions are less likely to result in a compromise in the customers' data.

Ensuring that you meet PCI compliance and have a solid infrastructure for managing data security will increase customer confidence in your business and ensure that you're not exposed to security breaches that could have been avoided. 

To learn more about meeting PCI compliance requirements, download the whitepaper Meet the Challenges of PCI Compliance and find the answers to the following questions (and more):

  • What will my auditor look for?

  • How can I ensure my customers' data is secure?
  • What is the difference between tokenization and encryption?
  • What is encryption key management and why are auditors looking at this?

  download the Whitepaper: Meet the Challenges of PCI Compliance

 


Topics: Compliance, Data Security, PCI DSS, Best Practices, Encryption Key Management, White Paper

How To Meet PCI DSS Compliance With VMware

Posted by Michelle Larson on Sep 25, 2014 3:12:00 PM

VMware and PCI DSS Compliance: Taking the right steps in a virtualized environment

VMware encryption key management

As of vSphere 6.5, AES encryption has been added to VMware. With VMWare encryption, complying with PCI DSS, requirement 3 is even easier. And executives are taking note as they look to conserve resources by moving their organizations databases and IT environments to virtualized platforms and to the cloud.

Security best practices and compliance regulations call for sensitive data to be protected with encryption and that data-encrypting keys (DEK) be physically or logically separated from the sensitive data and protected with strong key-encrypting keys (KEK). Depending on what type of information is being stored and what industry guidance your project/company falls under, compliance regulations in addition to PCI DSS may apply.

VMware PCI DSS ComplianceThe Payment Card Industry Data Security Standard (PCI DSS) is one of the most rigorous and specific set of standards established to date and is used by many organizations as a standard to secure their systems. PCI DSS applies to all organizations that store, process, or transmit cardholder data, regardless of volume. This includes merchants, service providers, payment gateways, data centers, and outsourced service providers.

Here is a high level look at all twelve items that must be met in order to be compliant, with three new requirements in PCI DSS 3.0 (**) that warrant mentioning as being most relevant to the use of VMware and cloud technologies in a PCI-regulated infrastructure:

Build and Maintain a Secure Network and Systems
Requirement 1: Install and maintain a firewall configuration to protect cardholder data


(3.0) **Req. 1.1.3: "[Maintain a] current diagram that shows all cardholder data flows across systems and networks."

Requirement 2: Do Not use vendor-supplied defaults for system passwords and other security parameters

(3.0)** Req. 2.4: "Maintain an inventory of system components that are in scope for PCI DSS."

Protect Cardholder Data

Requirement 3: Protect stored cardholder data*


* Requirement 3 specifically addresses the need for encryption and key management, stating:

“Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.”

Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs


Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know


Requirement 8: Identify and authenticate access to system components


Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data


Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that address information security for all personnel

(3.0) ** Req. 12.8.5: "Maintain information about which PCI DSS requirements are managed by each service provider and which are managed by the entity."

It can seem overwhelming at first, but the PCI Security Standards Council (PCI SSC) website contains this documentation along with a number of additional resources to assist organizations with their PCI DSS assessments and validations. Within the latest documentation by the PCI Security Standards Council (v3.0 released November 2013) specific testing procedures and guidance is given for Requirement 3 on pages 34-43.

Fortunately, there are also standards and published guidance on running payment applications in a virtualized environment:

Payment Card Industry Data Security Standard: Virtualization Guidelines and Cloud Computing Guidelines

NIST SP 800-144: Guidelines on Security and Privacy in Cloud Computing

Cloud Security Alliance: Security Guidance for Critical Areas of Focus in Cloud Computing

While virtual technology is not limited to VMware, it is one of the most commonly used and supported architectures by many cloud service providers. In addition to the PCI compliance and cloud guidelines above, VMware worked with CoalFire, a QSA auditing firm, to create guidance on how to specifically deploy payment applications in a VMware environment. You can access the CoalFire document  here.

As platform virtualization becomes a more popular solution, executives need to remain vigilant with their data security and meeting compliance requirements. We can help make the transition to VMware easy with our Alliance Key Manager for VMware solution, which meets the PCI recommendations when deployed properly in a VMware environment. We are committed to helping businesses protect sensitive data with industry standard NIST compliant AES encryption and FIPS 140-2 compliant encryption key management solutions.


To learn more about enterprise key management for VMware and vCloud, download our podcast "Virtualized Encryption Key Management".

Podcast: Virtualized Encryption Key Management
 

Topics: Alliance Key Manager, PCI DSS, Encryption Key Management, VMware, Virtualized Encryption Key Management, Podcast, PCI, Cloud Security

PCI DSS Compliance = Encryption & Key Management

Posted by Michelle Larson on Jul 1, 2014 2:13:00 PM

Many compliance regulations and security best practices require the encryption of sensitive data and the protection of encryption keys with proper key management.

Security best practices and PCI DSS compliance regulations call for sensitive data to be protected with encryption and that data-encrypting keys (DEK) be physically or logically separated from the sensitive data and protected with strong key-encrypting keys (KEK). Anyone who needs to protect sensitive data in their database, needs to know that storing the encryption keys within the same location puts data at risk for a breach.  Depending on what type of information is being stored and what industry guidance your project/company falls under, compliance regulations in addition to PCI DSS may apply.


PCI Compliance Regulations require encryption and key management

For any company that accepts credit card payments, the Payment Card Industry Data Security Standards (PCI DSS) issues 12 requirements that must be met in order to be compliant. It can seem overwhelming at first, but the PCI council that issues PCI DSS also provides detailed reference guides and instructions on each requirement.

Let’s take a brief look at all twelve items:

Build and Maintain a Secure Network and Systems

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

Requirement 2: Do Not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

Requirement 3: Protect stored cardholder data*

Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs

Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know

Requirement 8: Identify and authenticate access to system components

Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data

Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that address information security for all personnel


Within the latest documentation by the PCI Security Standards Council (v3.0 released November 2013) specific testing procedures and guidance is given for Requirement 3 on pages 34-43. The PCI Security Standards Council (PCI SSC) website (http://www.pcisecuritystandards.org) contains this documentation along with a number of additional resources to assist organizations with their PCI DSS assessments and validations.

* Requirement 3 addresses the need for encryption and key management, stating:

Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.”


The PCI Security Standards Council also issues their Cloud Computing Guidelines (https://www.pcisecuritystandards.org/pdfs/PCI_DSS_v2_Cloud_Guidelines.pdf) and additional information around virtualization of data protection solutions so you can be PCI compliant with a cloud-based solution for encryption and key management.


Other compliance requirements for protecting information go beyond cardholder data (PCI focuses on PAN or the Primary Account Number specifically) and also require that personally identifiable information (PII) such as names, birthdates, email address, zip codes, usernames, or passwords be protected properly with encryption and key management. To meet the growing need for NIST validated and FIPS 140-2 compliant solutions, the data security experts at Townsend Security provide a certified key management system (Alliance Key Manager) which provides secure key storage and retrieval options for a variety of Enterprise and open source platforms.  Now sensitive information can easily be encrypted and the encryption keys properly managed. 

For more information on encryption, download the latest eBook, The Encryption Guide:

The Encryption Guide eBook

Topics: Compliance, Encryption, eBook, PCI DSS, Encryption Key Management

Drupal CMS and PCI DSS Compliance

Posted by Michelle Larson on Apr 2, 2014 11:14:00 AM

Securing data with encryption and protecting the encryption keys with proper key management is addressed in many compliance regulations and security best practices.

Download Whitepaper on PCI Data Security For Drupal developers who need to protect sensitive data in their (or their clients) content management system (CMS), storing the encryption keys within the Drupal CMS puts that data at risk for a breach. Security best practices and PCI DSS compliance regulations call for sensitive data to be protected with encryption and that data-encrypting keys (DEK) be physically or logically separated from the sensitive data and protected with strong key-encrypting keys (KEK).  Depending on what type of information is being stored and what industry guidance your project/company falls under, compliance regulations in addition to PCI DSS may apply.

For any company that accepts credit card payments, the Payment Card Industry Data Security Standards (PCI DSS) issues 12 requirements that must be met in order to be compliant. It can seem overwhelming at first, but the PCI council that issues PCI DSS also provides detailed reference guides and instructions on each requirement. Let’s take a high level look at all twelve items:

Build and Maintain a Secure Network and Systems

Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do Not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

Requirement 3: Protect stored cardholder data*
Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know
Requirement 8: Identify and authenticate access to system components
Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that address information security for all personnel

Within the latest documentation by the PCI Security Standards Council (v3.0 released November 2013) specific testing procedures and guidance is given for Requirement 3 on pages 34-43. The PCI Security Standards Council (PCI SSC) website contains this documentation along with a number of additional resources to assist organizations with their PCI DSS assessments and validations. PCI SSC also issues Cloud Computing Guidelines and additional information around virtualization of data protection solutions so you can be PCI compliant with a cloud-based solution for encryption and key management.

Requirement 3 addresses the need for encryption and key management, stating:

PCI requirement 3:Protect stored cardholder data

“Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.”

In order to address PCI DSS Requirement 3: Protect stored cardholder data; the security experts at Townsend Security partnered with Chris Teitzel, CEO of Cellar Door Media and Drupal developer to create Key Connection for Drupal in connection with the existing Drupal Encrypt module. In order to provide secure key storage and retrieval options, Key Connection for Drupal provides a secure key management system (Alliance Key Manager) outside of the Drupal installation. Now when cardholder information is collected or stored in a database it can easily be encrypted and the encryption keys properly managed. Key Connection for Drupal allows developers and users to choose whether they need to retrieve a key and encrypt/decrypt locally or to send the data to Alliance Key Manager to perform on board encryption.

Other compliance requirements for protecting information go beyond cardholder data (PCI focuses on PAN or the Primary Account Number specifically) and also require that personally identifiable information (PII) such as names, birthdates, email address, zip codes, usernames, or passwords be protected with encryption and key management. Check back as future blogs will cover additional data privacy compliance regulations and security best practices that impact developers and users of the Drupal CMS open source platform in regards to protected health information (PHI).

For more information on PCI Compliance, download the Whitepaper: "Meet the Challenges of PCI Compliance"

download the Whitepaper: Meet the Challenges of PCI Compliance

Topics: Compliance, PCI DSS, Encryption Key Management, White Paper, Drupal