Security / AWS / Compliance

PCI DSS Compliance on AWS - Get 71 requirements covered out-of-the-box

Jared Brook

13 Minute Read

If your business handles credit card transactions and is running, or planning to run, on AWS, then you are likely aware of the various data security standards your company must adhere to. The Payment Card Industry (PCI) data security standard, the Information Security Management (ISO) standards, and the General Data Protection Regulation (GDPR) each increase the controls around cardholder data to reduce instances of fraud.

With data breaches occurring at an alarming frequency, PCI, ISO and GDPR standards can no longer be ignored. Customers are increasingly familiar with the threats to their security and thus demanding compliance to these standards.

Thankfully, base2Services and Amazon Web Services (AWS) cover 71 of the 296 PCI requirements out-of-the-box.

The remaining requirements are dependent on your application, processes, and documented procedures.

pci_compliance_banner

Compliance is a day zero concern

In almost all cases, a compliant PCI environment should be built from the ground up. The infrastructure needs to be compliant and the application needs to be changed to comply. Instead of attempting to retrofit PCI compliance into your existing AWS stack, we always recommend that you build again and migrate. Building the compliance and security from the ground up is both the easiest and the safest way to ensure that your audit project succeeds and your customers are protected.

base2Services has developed a baseline that meets 71 of these requirements out-of-the-box – saving you a considerable amount of time and significant headaches. We have experience in communicating with Auditors and are able to justify any scenario that may be raised. Our hands-on approach ensures that your team gets moving faster to deliver PCI compliance for your customers.

Continuous PCI DSS compliance

In order to maintain PCI compliance, make sure you implement the right build pipelines, in an AWS environment, make sure you can bake AMI’s or containers that are propagated from dev right through to production. This is a key component to successfully ensuring that what you are developing and testing on, is exactly what goes into production. Don’t leave builds to chance – the exposure to a data breach increases dramatically.


How to get started with PCI DSS compliance on AWS

STEP 1

Establish a crack team, led by a Project Manager.

Yes, it is fundamentally important that a Project Manager exists in this situation. They are able to manage the checklist, the auditor, and ensure that the requisite tasks are getting completed to pass your audit.

STEP 2

Find an Auditor that you are comfortable working with.

Don’t let price get in the way. A good auditor is one that understands your business needs, is technically minded and pragmatic – without being simply checklist obsessed.

STEP 3

Speak with base2Services.This is a text fix

Find out how DevOps as a Service can help you achieve and maintain PCI compliance.

 

Save time

The following items from the PCI checklist are already handled by both AWS and base2Services. Avoid the battle of building and managing these items. Focus on the application and promoting your compliance to your customers.

71 PCI Requirements out-of-the-box

Section PCI DSS Requirements v3.2.1 Covered by base2Services & AWS
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
1.1.1 A formal process for approving and testing all network connections and changes to the firewall and router configurations AWS uses Security Groups and Access Control Lists instead of routers and firewalls. base2Services provides a process to manage these in a compliant way
1.1.4 Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone AWS provides this as native capability through the use of Virtual Private Clouds (VPCs)
1.2.2 Secure and synchronize router configuration files Not applicable in an AWS environment
1.2.3 Install perimeter firewalls between all wireless networks and the cardholder data environment, and configure these firewalls to deny or, if traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment AWS provides methods for locking this down
1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ AWS limits through ACLs
1.3.3 Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network. (For example, block traffic originating from the Internet with an internal source address) AWS provides these functions
1.3.7 Do not disclose private IP addresses and routing information to unauthorized parties. Note: Methods to obscure IP addressing may include, but are not limited to:
  • Network Address Translation (NAT)
  • Placing servers containing cardholder data behind proxy servers/firewalls,
  • Removal or filtering of route advertisements for private networks that employ registered addressing,
  • Internal use of RFC1918 address space instead of registered addresses
AWS provides NAT on its routers
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network. This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, payment applications, Simple Network Management Protocol (SNMP) community strings, etc.) AWS has this by default
2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards. Sources of industry-accepted system hardening standards may include, but are not limited to:
  • Center for Internet Security (CIS)
  • International Organization for Standardization (ISO)
  • SysAdmin Audit Network Security (SANS) Institute
  • National Institute of Standards Technology (NIST).
base2Services' baseline Jenkins CI pipelines continuously scan for security vulnerabilities
2.2.2 Enable only necessary services, protocols, daemons, etc., as required for the function of the system. base2services' baseline configuration continuously checks for exposed services and protocols (for AWS)
2.2.4 Configure system security parameters to prevent misuse. base2services' baseline SOEs removes any unnecessary services, scripts, etc
2.2.5 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.
2.3 Encrypt all non-console administrative access using strong cryptography. Note: Where SSL/early TLS is used, the requirements in Appendix A2 must be completed. MFA activation is required to connect to AWS. Phones need to have lock screen active
2.6 Shared hosting providers must protect each entity’s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A1: Additional PCI DSS Requirements for Shared Hosting Providers. AWS provided
Requirement 3: Protect stored cardholder data
3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all cardholder data (CHD) storage:
  • Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements
  • Specific retention requirements for cardholder data
  • Processes for secure deletion of data when no longer needed
  • A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention
base2Services' Shelvery backups allow for configuration of data retention policies - need to check your current policy and ensure it is current and up to date and includes the elements necessary
3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts. Note: This requirement applies in addition to all other PCI DSS encryption and key-management requirements Requirement is met on AWS and enforced by base2services’ CI pipelines. It is recommended that disk level encryption be implemented for Dev machines
Requirement 6: Develop and maintain secure systems and applications
6.4.2 Separation of duties between development/test and production environments You need separate Admins for Prod versus other environments. base2Services' baseline introduces IAMElmer to manage temporary keys and AWS console access
6.5 Address common coding vulnerabilities in software-development processes as follows:
  • Train developers at least annually in up-to-date secure coding techniques, including how to avoid common coding vulnerabilities
  • Develop applications based on secure coding guidelines
Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements
Ensure developers are trained on secure coding practices. Combined with independent code reviews and the use of the AWS WAF, this will provide sufficient controls
6.5.1 Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws. Ensure developers are trained on secure coding practices. Combined with independent code reviews and the use of the WAF, this will provide sufficient controls.
6.5.2 Buffer overflows
6.5.3 Insecure cryptographic storage
6.5.4 Insecure communications
6.5.5 Improper error handling
6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1).
6.5.7 Cross-site scripting (XSS) Ensure developers are trained on secure coding practices. Combined with independent code reviews and the use of the WAF, this will provide sufficient controls.
6.5.8 Improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions).
6.5.9 Cross-site request forgery (CSRF)
6.5.10 Broken authentication and session management
Requirement 7: Restrict access to cardholder data by business need to know
7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities. base2Services’ baseline IAMElmer will manage temporary access. However, limit the number of administrators of the AWS account and number of Users who can act as Admins on the Production environment
7.1.3 Assign access based on individual personnel’s job classification and function Setup IAM Roles in AWS and establish a process for assigning this role. Use IAMElmer to issue temporary access
7.2.1 Coverage of all system components AWS establishes a 'deny all' setting by default, requiring explicit authorisation to access components
7.2.2 Assignment of privileges to individuals based on job classification and function.
7.2.3 Default “deny-all” setting.
Requirement 8: Identify and authenticate access to system components
8.1.6 Limit repeated access attempts by locking out the user ID after not more than six attempts. AWS needs to be configured to meet these requirements
8.1.7 Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.
8.1.8 If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.
8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users:
  • Something you know, such as a password or passphrase
  • Something you have, such as a token device or smart card
  • Something you are, such as a biometric.
8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components. Settings configured as part of base2Services' baseline
8.2.3 Passwords/passphrases must meet the following:
  • Require a minimum length of at least seven characters.
  • Contain both numeric and alphabetic characters.
Alternatively, the passwords/passphrases must have complexity and strength at least equivalent to the parameters specified above.
8.2.4 Change user passwords/passphrases at least once every 90 days.
8.2.5 Do not allow an individual to submit a new password/passphrase that is the same as any of the last four passwords/passphrases he or she has used.
8.2.6 Set passwords/passphrases for first-time use and upon reset to a unique value for each user, and change immediately after the first use.
8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access. Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement. Implement MFA for all AWS accounts
8.3.2 Incorporate multi-factor authentication for all remote network access (both user and administrator, and including third party access for support or maintenance) originating from outside the entity's network.
Requirement 9: Restrict physical access to cardholder data
9.1.1 Use either video cameras or access control mechanisms (or both) to monitor individual physical access to sensitive areas. Review collected data and correlate with other entries. Store for at least three months, unless otherwise restricted by law. Note: “Sensitive areas” refers to any data center, server room or any area that houses systems that store, process, or transmit cardholder data. This excludes public-facing areas where only point-of-sale terminals are present, such as the cashier areas in a retail store. AWS provided
9.1.2 Implement physical and/or logical controls to restrict access to publicly accessible network jacks. For example, network jacks located in public areas and areas accessible to visitors could be disabled and only enabled when network access is explicitly authorized. Alternatively, processes could be implemented to ensure that visitors are escorted at all times in areas with active network jacks.
9.4.1 Visitors are authorized before entering, and escorted at all times within, areas where cardholder data is processed or maintained.
Requirement 10: Track and monitor all access to network resources and cardholder data
10.1 Implement audit trails to link all access to system components to each individual user. base2Services' baseline configured. Create logs for each individual user. For PCI compliance, accounts/areas within scope of logging are: AWS Admins, AWS Account (if separate), Production Environment, Log Data (including S3 bucket if used as storage), Antivirus
10.2.2 All actions taken by any individual with root or administrative privileges Settings configured as part of base2Services' baseline
10.2.3 Access to all audit trails
10.2.4 Invalid logical access attempts
10.2.5 Use of and changes to identification and authentication mechanisms—including but not limited to creation of new accounts and elevation of privileges—and all changes, additions, or deletions to accounts with root or administrative privileges
10.2.6 Initialization, stopping, or pausing of the audit logs
10.2.7 Creation and deletion of system-level objects
10.3.1 User identification
10.3.2 Type of event
10.3.3 Date and time
10.3.4 Success or failure indication
10.3.5 Origination of event
10.3.6 Identity or name of affected data, system component, or resource
10.4 Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time. Note: One example of time synchronization technology is Network Time Protocol (NTP) AWS manages NTP by default
10.4.1 Critical systems have the correct and consistent time
10.4.2 Time data is protected
10.4.3 Time settings are received from industry-accepted time sources
10.5.1 Limit viewing of audit trails to those with a job-related need Settings configured as part of base2Services' baseline
10.5.2 Protect audit trail files from unauthorized modifications
10.5.3 Promptly back up audit trail files to a centralized log server or media that is difficult to alter
10.5.4 Write logs for external-facing technologies onto a secure, centralized, internal log server or media device
10.6.1 Review the following at least daily:
  • All security events
  • Logs of all system components that store, process, or transmit CHD and/or SAD
  • Logs of all critical system components
  • Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.)
10.6.2 Review logs of all other system components periodically based on the organization’s policies and risk management strategy, as determined by the organization’s annual risk assessment
10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from backup)


More Blog Posts