When I was a kid and we would go out to dinner, my dad would often pay using a credit card. The server would come over with an awkward, clunky device, put the credit card in it, and scan the card. By scan, I mean make an impression of the numbers on a piece of paper with a carbon receipt, which he would then sign and each party would get a copy. There were no wires, no electronic transmissions of data, and no internet connections to worry about. In those days, the storing, processing and transmitting of credit card data was very much an analog process. Along came magnetic strips, online shopping, and now, chipped cards. When the credit card industry moved into the digital space, it quickly realized the need to protect itself from digital fraud. Merchants and those responsible for handling the data needed to protect it in the same way they would protect physical currency. Then, like now, there was a lack of cybersecurity expertise; credit card handlers knew they had to protect the data, but they didn’t necessarily know how. The major credit card companies had a vested interest in helping companies protect the data, and so each developed their own security standards. While a good first step, this wasn’t so good for anyone having to navigate multiple, different standards for each credit card company. In order to standardize and ease this burden, the Payment Card Industry Security Standards Council (PCI SSC) was formed in 2004, and the various policies were aligned to the Data Security Standards – PCI DSS. Depending on the number of transactions and the amount of money processed, a merchant can become certified either by having a Qualified Security Assessor (QSA) validate that required controls are in place or by completing a Self-Assessment Questionnaire (SAQ). There have been several iterations of the PCI DSS since 2004 and version 3.2, ratified in 2016, went into full effect February 1, 2018. The standards themselves are broken down into six categories and 12 requirements:
| Control Category | Control Requirement |
Build and Maintain a Secure Network and Systems | 1. Install and maintain a firewall configuration to protect cardholder data. 2. Do not use vendor-supplied defaults for system passwords and other security parameters. |
Protect Cardholder Data | 3. Protect stored cardholder data. 4. Encrypt transmission of cardholder data across open, public networks. |
Maintain a Vulnerability Management Program | 5. Protect all systems against malware and regularly update anti-virus software or programs. 6. Develop and maintain secure systems and applications. |
Implement Strong Access Control Measures | 7. Restrict access to cardholder data by business need to know. 8. Identify and authenticate access to system components. 9. Restrict physical access to cardholder data. |
Regularly Monitor and Test Networks | 10. Track and monitor all access to network resources and cardholder data. 11. Regularly test security systems and processes. |
Maintain an Information Security Policy | 12. Maintain a policy that addresses information security for all personnel. |
What’s New with the PCI DSS 3.2 February 1st Release?
PCI DSS 3.2 has been out since April of 2016, but a few items change from recommendations to requirements on February 1st, 2018. A few of the notable highlights are:
- Change Management – Requirement 6.4.6 – Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks and documentation updated as applicable. (This seems like an obvious requirement, but it was only a best practice recommendation before 2018.)
- Access Control – Requirement 8.3.1 – Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access. (MFA was not required for non-console administrative access prior to February 1st, 2018, though remote network access for all parties was.)
- Segmentation Testing – Requirement 11.3.4.1 – Additional requirement for service providers only: If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods. (Previously segmentation testing wasn’t a requirement, though penetration testing was.)
Do you Need Help Implementing the PCI Controls?
Many of the PCI controls can be automated and implemented using commercial software solutions. Tripwire Enterprise ensures File Integrity Monitoring and Secure Configuration Management and is able to guide the user toward meeting compliance requirements. Tripwire IP360 performs vulnerability management, as well as asset discovery to monitor authorized and unauthorized systems on the network (also Critical Security Control #1!), and Tripwire Log Center manages centralized log collection and management and will alert on events of interest within the network. If you are looking for someone to help administer and manage your PCI environment, Tripwire ExpertOps is PCI-certified and can help monitor your critical infrastructure.
PCI – Keeping Your Credit Card Data Safe
PCI has come a long way since it was first implemented in 2004, but the controls and requirements have been a strong security framework for keeping data safe in the digital age. More than a compliance checkbox, the controls are leading practice for data protection and, if properly implemented and followed, increase the cybersecurity of any organization which follows them. You can learn more about Tripwire and their PCI DSS solutions here.
Insider Insights for the PCI DSS 4.0 Transition
Gain valuable insights from cybersecurity experts on transitioning to PCI DSS 4.0. Tripwire's comprehensive guide provides strategic advice, making the compliance process more streamlined and efficient. Understand the challenges and solutions for meeting PCI DSS requirements with expert guidance.
