Due to lack of education and awareness around payment security, employees usually leave security holes in their developed applications by not following best security practices to code, picking up weak passwords, and sharing company information on public and social platforms. PCI-DSS 3.0 has incorporated requirements such as 8.4 that focus on personnel trainings, guidance around payment security, guidance for selecting and protecting authentication credentials, instructions to change passwords in case of any suspicion detected, etc.

The PCI-DSS council has gone a step ahead and also focuses on major sales points where card data is processed ie. POS terminal and brings these terminals under scope, as attacks on POS devices like cloning, addition of card skimmers, etc. are on a high. Requirement 9.9 which is to “Protect devices that capture card data via direct physical interaction with the card from tampering and substitution” is added to address the POS threat challenge. This requirement will now make organizations maintain an up-to date list of devices deployed at various sites. This list will contain information about POS devices such as:

• Unique serial number of the device
• Make and model of device
• Location details at which it is deployed.

This requirement also focuses on providing training for end-personnel to be aware about the attempted tampering or replacement of authentic POS devices. Organizations need to conduct periodic reviews of devices to check for any evidence of substitution or tampering.

Third party security challenges

As per the security investigation report, 63 percent of security deficiencies that can result in breach or loss of cardholder data falls in the 3rd party IT landscape, whose business function is to process, transmit and store cardholder data received either from merchant or service providers. To handle crises whenever there is a breach resulting in cardholder data loss and no one to take ownership of that, PCI has added requirements 12.8, 12.9 to made it clear that both the engaging parties need to seal the deal with a written agreement, which should state a clear responsibility matrix. This requirement also requires the organization to do a proper due-diligence of the IT landscape, process, services offered, and security controls in place before entering into a formal agreement.

Along with the above stated requirement, PCI has also stated an additional requirement for service providers with requirement number 8.5.1 to maintain unique credentials for each customer when accessing their premises remotely for services like support of POS systems. This requirement will prevent the compromise of multiple customers’ account profiles in case the service provider used the same credentials for all the service providers and that in turn is compromised. Also service providers must set up strong credentials to access customer premises and should adopt best practice policies like a password change policy, etc.

Anti-malware solutions

The earlier PCI-DSS 2.0 standard specifies that there should be an antivirus solution deployed to protect the CDE environment from viruses, malware, etc. and that it should be completely updated with the latest patches and signatures, but the requirement did not specify about the access control settings over the AV software, such as access control over the AV manager, meaning who can only disable the AV solution and who can view its logs and edit the configuration changes. However in PCI-DSS 3.0, requirement 5.3 now requires organizations to deploy tighter policy based controls around antivirus solution that will require authorization to access and alter the configuration settings of the AV solution.

To keep controls deployment and maintenance costs in check, merchants generally come up with a classification of important endpoints that will be covered under security controls deployment like antivirus. Though asset classifications is a good practice, merchants do not generally update these lists with the ever-changing threat landscape. Keeping this in check, PCI-DSS has added a new requirement 5.1.2 which requires merchants to identify and evaluate evolving threats against systems which are not commonly affected by malicious software like mainframes, so as to develop a tighter antivirus security around all the systems in the CDE environment. Merchants can take guidance from vendors to understand the changing threat landscape and to evaluate whether their unprotected systems come under newly discovered vulnerabilities.

Penetration testing

One of the key drivers and significant changes in PCI-DSS 3.0 is addition of the requirement for merchants to conduct penetration testing on their cardholder environment. SSC has laid emphasis on the point that merchants/service providers must adopt an industry wide accepted penetration testing like NIST SP 800-15. PCI requirements also need to conduct penetration tests not only at the application level but also at the network level against devices that are deployed at the perimeter (say for segregation) or deployed inside CDE environment. PCI requirement 13.4 would require providers to conduct:

• Annual penetration tests on the external network and when there is any significant change in infrastructure or applications deployed in CDE environment.
• Annual penetration tests on the internal network and when there is any significant change in infrastructure or applications deployed in CDE environment.
• Annual penetration tests on the boundary defense of CDE environment or around the segmentation controls that are used to isolate the CDE environment to check their effectiveness.
• Adopt the cyclic process of Test (Conduct Penetration testing (PT)) > Remediate (Fix Vulnerabilities) > Re-Test (Conduct PT again) until all the vulnerabilities found are fixed.
• Requires merchants/service providers to retain the Penetration testing results and remediation activities as per the adopted industry driven approach.

Inventory list

PCI has made it mandatory for retailers to maintain an inventory list of all the in-scope devices for CDE environment. With addition of requirement 2.4 which states, “Maintain an inventory of systems components that in scope of PCI DSS”, PCI made sure that retailers keep updating their inventory list with the already in action system components or to any newly added one. To avoid any confusion, PCI has also mentioned in some drilled down requirements what all needs to be put in the inventory list, such as:

• Requirement no 11.1.1 states that “maintain an inventory of authorized wireless access points including a documented business justification ” will require retailers to maintain an inventory list for all access points with a proper business justification.
• Requirement no 9.7.1 states that to “Properly maintain inventory logs of all media and conduct media inventories at least annually” will require retailers to maintain an inventory list of all the media so that stolen or missing media should not go unnoticed.
• Requirement no 12.3.4 requires retailers to maintain an inventory of all physical devices with proper labeling to mark any unapproved installations.

However, the above stated requirement to maintain an inventory list will be very difficult for organizations to maintain until they fully practice the requirement no 1.1.3 which requires organizations to maintain an updated data flow diagram (DFD) to showcase all the controls that are in CDE environment. With an updated DFD, organizations will be able to classify what is in-scope and out of scope for their CDE environment.

Business as Usual (BaU)

One of the major themes of PCI-DSS 3.0 is to make it as a Business as Usual (BAU) Practice rather than compliance. As PCI-DSS covers a majority of mid-sized business that either do not have a large IT department or they have very few information security groups which can work to keep their business PCI-DSS-ready for audits and to incorporate any last minute hiccups. Making PCI-DSS as a BAU will require organizations to keep their PCI-DSS checklist updated regularly with any change in their CDE environment. Merchants should keep a check and document all the changes done in their cardholder data environment (CDE). These includes:

• Regular monitoring of security controls like firewall, AV solutions, access controls, IDS/IPS, Security Incident and Event Management (SIEM), etc. in CDE environment to ensure that they are correct, updated and their functioning is secure.
• Reviewing the security posture of the CDE environment with addition of new systems and devices, changes in configurations of security controls, organizational structure changes, etc.
• Reviewing latest best practices, support issued by vendors for the security devices that are placed in CDE environment to make sure that the cardholder data is secured from evolving threats.

Conclusion

PCI-DSS 3.0 has incorporated some good new requirements as per the changing threat landscape, included the end user to understand about payment security, and clarified some statements for proper understanding of merchants and 3rd party service providers. Some of the changed requirements that are incorporated in PCI DSS 3.0 are termed as best practice for some time now, after which they will become mandatory for every organization to implement. PCI DSS 3.0 will surely make merchants, service providers or any entity that is processing, storing and transmitting cardholder data and is under PCI scope to revisit and enhance their existing strategy for protecting cardholder information.

References

https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf

Author Bio:
Lohit Mehta is a Security Researcher for the InfoSec Institute. He has experience working with RFPs/RFIs; Security HLD and LLD design; Network Security elements like Firewall, IDS/IPS, DLP, Reverse proxy, WAF; in Public Key Infrastructure(PKI); in Application Security testing for OWASP Top 10; in Compliance’s like PCI-DSS 2.0,3.0 , ISO 27k1, HIPPA; with Cloud Service Provider’s such as AWS; in Security Incident and Event Management(SIEM) with tools like Splunk; in Vulnerability Testing.

The post PCI DSS: What You Need to Know appeared first on Porticor Cloud Security.