The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard merchants and service providers must comply with if they store, process, or transmit cardholder data. PCI DSS includes over 400 information security requirements, including requirements that apply to cloud infrastructure such as Amazon Web Services (AWS).

Organizations that use AWS to store and process credit card data must ensure their cloud infrastructure is compliant. But maintaining AWS PCI-compliance is not as simple as uploading sensitive data to a cloud service that has been audited and declared PCI compliant. As Amazon puts it, “It is the customer’s responsibility to maintain their PCI DSS cardholder data environment (CDE) and scope, and be able to demonstrate compliance of all controls.”

In this article, we examine what AWS PCI compliance means and how companies store and process data on AWS while maintaining PCI DSS compliance.

Which Data is Covered by PCI DSS?

Cardholder data is any personally identifiable information associated with a credit cardholder or their account. It includes:

  • The Primary Account Number (PAN)
  • Cardholder names
  • Expiration dates
  • Service codes

PCI DSS also addresses the storage, processing, and transmission of sensitive authentication data, including magnetic stripe data, CVC numbers and equivalent data, and personal identification numbers (PINs). Organizations storing and processing this data must ensure that the relevant infrastructure and systems are compliant.

Is AWS PCI-Compliant?

AWS is a PCI DSS Level 1 compliant service provider. Level 1 is the most stringent of the four levels of PCI compliance, and it implies that AWS has been certified compliant following an audit by a Qualified Security Assessor (QSA).

Which AWS Services Are PCI Compliant?

The majority of Amazon’s cloud services are PCI-compliant. Compliant services include Amazon Simple Storage Service (S3), Amazon Elastic Compute Cloud (EC2), Amazon Elastic Block Store (EBS), and around 150 other cloud services and programs. You can see a complete list of PCI compliant AWS services at AWS Services in Scope by Compliance Program.

AWS PCI Compliance and the Shared Responsibility Model

AWS operates a shared responsibility security model meaning responsibility for securing cardholder data is shared between the platform and the user. AWS implements secure and compliant systems which reduce the users’ operational burden. But it doesn’t absolve them of the responsibility to use AWS services in a secure and compliant manner.

Amazon is always responsible for securing the underlying hardware, but the user may be responsible for the service’s configuration and any software they run on it. The division of responsibility depends on the cloud service. On EC2, the user is responsible for securing the operating system and services they run on virtual servers. On S3, they are responsible for the aspects of the service that are user configurable.

To consider one common AWS security failing, Amazon S3 is a secure and PCI-compliant object storage service. If S3 is correctly configured and used as part of a compliant system, an AWS user could store cardholder data on S3 and maintain PCI compliance.

However, S3 can be configured insecurely. This could occur by setting a permission policy that allows public access to the data stored in a bucket. In that case, the service is PCI compliant, but the user’s implementation is not, and nor is any system that uses that implementation.

As Amazon’s compliance guidelines make clear, “AWS Services listed as PCI DSS compliant means that they can be configured by customers to meet their PCI DSS requirements. It does not mean that any use of that service is automatically compliant.” Additionally, the PCI DSS’s scope goes beyond infrastructure to processes and people—compliant infrastructure can’t make a system compliant unless all other appropriate controls are also implemented.

Ultimately, PCI DSS compliance is always the responsibility of the user. Amazon makes compliance easier, but if cardholder data is exposed or misused, it is the user who faces penalties and perhaps the revocation of their ability to process credit card payments.

How to Achieve PCI Compliance on AWS

Achieving PCI compliance on AWS is a complex topic: it depends on the size and scope of a business’s cardholder data environment; the cloud infrastructure, services, and software in use; and the processes the company supports with AWS services.

To implement a PCI-compliant cardholder data environment, AWS users must ensure that all infrastructure connected to the data environment complies with the relevant PCI DSS requirements. We cannot cover all applicable requirements here, so let’s look at three examples of how AWS helps businesses comply.

PCI DSS Firewall Controls

PCI DSS Requirement 1.1.4 requires businesses to implement a firewall at each internet connection and between any demilitarized zone and the internal network zone. Amazon provides two main PCI compliant firewall options: Security Groups and Network Access Control Lists (NACL).

Firewalls are a clear example of how the division of responsibility between AWS and the user works. AWS provides firewall services that help users comply with PCI DSS requirements, but the user must configure and manage the firewalls in a compliant manner. AWS also provides the AWS Firewall Manager to centralize and simplify firewall management for AWS environments.

Strong Encryption of Data at Rest and in Motion

PCI DSS Requirements 3 and 4 address cardholder data protection, including encryption at rest and in transit. Relevant requirements include:

  • Render PAN unreadable anywhere is stored.
  • Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open networks.

Businesses must encrypt cardholder data in transit and at rest with strong, modern cryptographic technology. AWS makes this relatively straightforward. Most storage services offer encryption at rest, including databases, storage services, and caching services.

Data is automatically encrypted as it is moved within a secure AWS network. Still, users must ensure that they implement suitable cryptographic protection when data is transmitted to third-party clients and services.

Secure Key Management

PCI DSS Requirement 3.5 and Requirement 3.6 include several key management sub-requirements such as:

  • Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse.
  • Restrict access to cryptographic keys to the fewest custodians necessary.
  • Generate strong cryptographic keys and implement processes to store and distribute them securely.

To help businesses comply with these requirements, AWS provides the AWS Key Management Service (AWS KMS). AWS KMS is a key management service that can generate and control secure keys. It integrates with many other AWS services that encrypt data, making it easier to comply with PCI DSS encryption and key management requirements.

Verifying AWS PCI Compliance with A PCI DSS Audit

As we’ve seen, AWS is a PCI-compliant cloud platform. AWS services help businesses build PCI compliant systems to store and process credit card data. Achieving PCI compliance is much less complex on AWS than on self-managed colocated servers.

However, less complex isn’t the same as simple. Businesses often face challenges configuring, managing, and integrating AWS cloud services in a way that maintains compliance. Non-compliant organizations risk fines and penalties, termination of the ability to accept cards as payment, loss of business, and legal costs.

As a licensed CPA and QSA firm, KirkpatrickPrice’s PCI audits will help your business demonstrate PCI compliance and reduce the risk of non-compliance. In addition to PCI audits, we also offer cloud security audits, penetration testing, risk assessments, and other services that help businesses to achieve PCI compliance on AWS.

Contact KirkpatrickPrice today to learn more about how a PCI audit could benefit your business.

Are you considering going through an information security audit for the first time? Are you contemplating a requirement for all of your vendors to undergo information security audits? Are you looking for an auditing firm who can help your organization utilize the benefits of auditing? Do you need help explaining the value of information security audits to executive management? Are you trying to cultivate a culture of compliance within your organization? We’re here to help.

What are the Advantages to Auditing?

Many people are intimidated by the requirements, price, and efforts of auditing, but we believe the benefits outweigh the cost. Yes, undergoing information security audits is a challenging and time-consuming process for most organizations, but our Information Security Specialists aim to educate clients on the value that attestations and compliance can bring to their business, which range from competitive advantages to reputational improvement. When your organization has completed an information security audit and gained compliance, the challenges you faced will be worth it.

However, getting executives on board with undergoing information security audits can be challenging, because many organizations are fearful of the process. We see many organizations get stuck in the checkbox mentality, where they view auditing as an item to be checked off a list rather than understanding the purpose and benefits. At KirkpatrickPrice, we want to be your audit partner, not just an item to check off on a list. We want to walk through this audit lifecycle with you, enhancing your business by placing security and compliance at the forefront of the current threat landscape.

Are you ready to get started on securing your business? Do you want to ensure your security posture is as strong as possible? Do you want to see how your mindset toward auditing can change over a three-year period? KirkpatrickPrice offers a wide variety of information security testing and auditing services. To learn more, contact a KirkpatrickPrice information security specialist today.

This exclusive video series, PCI Demystified, was developed to assist your organization in understanding what Payment Card Industry Data Security Standard (PCI DSS) is, who it applies to, what the specific requirements are, and what your organization needs to do to become compliant.

The 12 PCI DSS Requirements

The PCI DSS was jointly developed by the payment card brands to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. Its purpose is to ensure that all of the data that lives within the Cardholder Data Environment (CDE) is protected and secured from theft or unauthorized use. If you are a merchant, service provider, or subservice provider who stores, processes, or transmits cardholder data, you are subject to comply with the PCI DSS.

The current version, PCI DSS 3.2, has approximately 394 controls, 6 control objectives, and 12 major subject areas. The 12 requirements are:

PCI Requirement 1

“Install and maintain a firewall configuration to protect cardholder data.” Your organization should focus on securing and hardening your network and securing the inbound and outbound traffic.

PCI Requirement 2

“Do not use vendor-supplied passwords and other security parameters.” Most organizations tend to focus on hardening their operating systems, but this requirement is intended for all assets within the environment.

PCI Requirement 3

“Protect stored cardholder data.” This requirement focuses on securing cardholder data at rest; this is the encryption and the storage of sensitive information.

PCI Requirement 4

“Encrypt transmission of cardholder data across open, public networks.” If you transmit cardholder data over open or public networks, that data must be securely and appropriately protected.

PCI Requirement 5

“Protect all systems against malware and regularly update anti-virus software or programs.” Do not focus on only anti-malware or only anti-virus; this requirement deals with both.

PCI Requirement 6

“Develop and maintain secure systems and applications.” There’s more to this requirement than just securing applications. It’s about identifying vulnerabilities, patching your systems, change management, change controls, and secure software development.

PCI Requirement 7

“Restrict access to cardholder data by business need-to-know.” Requirement 7 goes hand-in-hand with Requirement 8; it focuses on authorization.

PCI Requirement 8

“Identify and authenticate access to system components.” Requirement 8 focuses on authentication.

PCI Requirement 9

“Restrict physical access to cardholder data.” If a hacker as physical access to your assets, they pretty much own that data.

PCI Requirement 10

“Track and monitor all access to network resources and cardholder data.” This requirement is all about logging.

PCI Requirement 11

“Regularly test security systems and processes.” Your organization must ensure that you’re testing for vulnerabilities and managing the security of your environment so that your assets are protected.

PCI Requirement 12

“Maintain a policy that address information security for all personnel.” This is the requirement that addresses the policy and procedure management and vendor management of your organization.

Learn More about the 12 PCI Requirements

Please note that this blog reflects PCI DSS v3.2.  To learn about the current version of PCI DSS, v4.0, please see the following resources:

The 12 PCI DSS Requirements Video Transcript

The PCI DSS is comprised of 12 requirements and 2 appendices that we need to have a discussion about. We start out with Requirement 1, which is focused on securing and hardening the network and the inbound and outbound traffic. Requirement 2 is primarily focused with looking to harden the systems and the applications; most organization really just tend to focus on hardening their operating systems, but Requirement 2 is really intended for all assets within the environment. Requirement 3 is focused on securing cardholder data at rest. This is the encryption and the prohibition of storage of sensitive information. Requirement 4 is focused on making sure that when you transmit cardholder data over open or public networks, that the data itself is appropriately protected. Requirement 5 deals with antimalware and deals with antivirus.

Requirement 6 has actually got quite a bit that it deals with. This requirement, when we talk about the PCI DSS, talks about securing applications, but there’s a little bit more than that. It’s identifying vulnerabilities, it’s patching your system, it’s change management, it’s change controls, it’s secure software development and all the requirements that go along with making sure the applications are maintained securely. Requirement 7 and Requirement 8 kind-of go hand-in-hand; Requirement 7 is authorization and Requirement 8 is authentication. We change things up a little bit when we get to Requirement 9. Requirement 9 is focused on the physical security of the environment. If I’m a hacker and I have physical access to your assets, I can pretty much own the data on it. We get to Requirement 10, which is all of your logging. When we get to Requirement 11, it’s focused on making sure that all of things that you’ve put in place to secure your assets are functioning appropriately. This is where we’re testing for vulnerabilities and making sure we’re managing the security of the environment. Requirement 12 is the policy and procedure management and vendor management of the organization. This is really the management aspect of the PCI DSS itself.

Most organizations, most people tend to focus on the 12 requirements themselves, however there are 2 additional appendices that might as well be requirements. The first one we have is for shared hosted services providers. If you have a question of whether you’re a shared hosted service provider, please look at Requirement 2.6 in the PCI DSS. That will clearly explain what a shared hosted service provider is and talk about what the requirements are there. Lastly, we have the last appendix which we need to be concerned with or have conversations about. This is the Designated Entities Appendix. Once again, we’ll talk about what that is when we get to that requirement.

This exclusive video series, PCI Demystified, was developed to assist your organization in understanding what the Payment Card Industry Data Security Standard (PCI DSS) is, who it applies to, what the specific requirements are, and what your organizations needs to know and do to become compliant.

Why was PCI DSS developed?

The PCI Security Standards Council is a third-party organization that was developed for the sole purpose of managing the security of cardholder data. Prior to the PCI Security Standards Council, each payment card brand managed their own security standards.

Eventually, the payment card brands realized that it was counterproductive to have five different sets of standards that their clients had to audit against, thus, the PCI Security Standards Council and the PCI Data Security Standards were created. The PCI DSS was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. The founding payment brands for the PCI Security Standards Council include Visa, Inc., MasterCard, Discover Financial, American Express, or JCB International.

Who are the participants in the PCI environment?

If you store, process, or transmit cardholder data, interact with payment card data in any way, or have the ability to impact someone else’s cardholder information or the security of that information, you are subject to comply with the PCI DSS. The PCI Security Standards Council and payment card brands are major participants in the PCI environment and are responsible for tracking and enforcing PCI DSS compliance, penalties, fees, compliance deadlines, and the monitoring and facilitating of investigations. The other entities that are impacted by the PCI DSS compliance lifecycle are acquiring banks, issuing banks, merchants, service providers, and sub-service providers.

An acquiring bank is a bank or financial institution that processes card payments on behalf of a merchant. Acquirers are subject to payment brand rules and procedures regarding ensuring merchant compliance on behalf of the PCI Security Standards Council.

Issuing banks are the financial institutions that issue the payment cards on behalf of the payment card brands and who act as the middle man between the cardholder and the payment brand network.

Merchants accept the credit cards for payment and may store, process, or transmit cardholder data.

A service provider is any entity that stores, processes, or transmits cardholder data on behalf of a third-party (merchant), or otherwise have the ability to impact cardholder data security.

A sub-service provider is any entity that is acting on behalf of a merchant or service provider who has active access to their cardholder data environment.

Introduction to PCI DSS

Hi, my name is Jeff Wilder and I am the Director of PCI Services here at KirkpatrickPrice. We wanted to develop a series of videos to talk about what the PCI DSS Security Standards are, who they apply to, and then later on, talk about the specific requirements about what you actually need to do to in order to become compliant.

We want to start off the series by talking a little bit about the players within the industry. The PCI Security Standards Council is a third-party independent organization that was established about 10 years ago for the sole purpose of managing the standards themselves. Prior to the PCI Security Standards Council, each card brand managed their own standards. They realized that it wasn’t in their best interest to have five different standards and have clients having to audit against so many different standards. So, they established the Council as the sole means of managing a set of security standards that need to be applied if you interact with a Visa, MasterCard, American Express, or JCB. So in this lifecycle, we have the PCI Security Standards Council, we have the card brands themselves, and we also have what we call acquiring banks. Now these acquiring banks – if you are a merchant having merchant relationship with a bank, if you accept a credit card for payment, you have a relationship with an acquiring bank. These acquiring banks are the entities that, really, are responsible for your compliance. They are responsible for you on behalf of the Council to ensure that you are compliant on a day-to-day basis. Next in the ecosystem, we have what we call issuing banks. Now, the issuing banks have a relationship with the individuals that have credit cards. They’re the ones that actually issue the cards. Of course we have the merchants – these are the organizations that accept the credit cards for payment. Then we have service providers. Now, service providers are any entity that would store, process, or transmit cardholder data on behalf of a third-party, or otherwise have the ability to impact the security of it. If you interact with payment card data in any way, if you store, process, or transmit it, or if you have the ability to impact someone else’s cardholder information or the security of that information, you are subject to the PCI DSS standards.

In this series of videos, we’re going to be going over the requirements and talking about, not so much just what does the PCI DSS Security Standards say and the individual requirements, but what it really means. How is that going to apply into your environment? What I’m going to try to do is provide you with some guidance based off my 10 years of experience in the industry as former Council member helping to develop these standards and training for the last 2.5-3 years, prior to becoming the Director here at KirkpatrickPrice. I’m going to bring to the table all of that knowledge and information for you to use at your discretion. So, hope you enjoy the videos. Thank you.

PCI Requirement 12: Maintaining an Information Security Policy

When creating an information security policy, an organization must create a policy that addresses information security for all personnel. Let’s emphasize “all” – this policy is not just for the IT department but is for anyone that would/could be involved in some capacity with storing, processing, and transmitting cardholder data. PCI Requirement 12 helps oversee and govern an organization’s PCI DSS compliance program.

In this webinar, our panelist will discuss the 10 sub-requirements of PCI Requirement 12, which include:

Requirement 12.1 – You must keep a current set of policies accessible to all relevant personnel.

Requirement 12.2 – Risk Assessment is performed at least annually, and also performed when business objectives chance.

Requirement 12.3 – Develop usage policies for critical technologies.

Requirement 12.4 – Security policies must define responsibilities for all users.

Requirement 12.5 – Security management and activities must be formally assigned.

Requirement 12.6 – Implement a formal security awareness program.

Requirement 12.7 – Screen potential personnel prior to hire to minimize the risk of attacks from internal sources.

Requirement 12.8 – Maintain and implement policies and procedures to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data.

Requirement 12.9 – Service providers must acknowledge in writing that they are responsible for the security of cardholder data they possess or store, process, transmit on behalf of the customer, or to the extent that they could impact the security of the cardholder data environment.

Requirement 12.10 – Implement an incident response plan.

The  PCI DSS isn’t just a technical standard; it includes people, processes, and technology. Furthermore, your organization’s policies and procedures are not just pieces of paper. They are an executive-level edict that define how the business will be run. It’s not enough to have policies and procedures. You must make sure that your policies and procedures are effective and actually implemented to ensure they are functioning properly and as you designed them. If your policies aren’t functioning, then you don’t have a policy.

To learn more about PCI compliance, check out our PCI Demystified video resources or contact us today.