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.
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.
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.
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.
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.
Speak with base2Services.This is a text fix
Find out how DevOps as a Service can help you achieve and maintain PCI compliance.
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.
| 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:
|
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:
|
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:
|
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:
|
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:
|
|
| 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:
|
|
| 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:
|
|
| 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) | |