Advantio took part at the PCI SSC European Community Meeting held 29-31 October 2013 in Nice, France.  It has been a great opportunity for all of us to understand the future perspectives of the PCI Security Standards Council and to receive a complete overview of the latest version of PCI DSS and PA DSS 3.0.

PCI_DSS_3.0_whats_new

If you would like further information or to discuss any of the points raised here, please do not hesitate to contact our QSAs at mail@advantio.com or use the contact us form

PCI DSS 3.0: So what has changed and what can I expect?

The excitement is building around the release of PCI DSS v3.0. Therefore, it is a good opportunity to provide an evaluation of the material that has been presented by the Payment Card Industry Security Standard Council (PCI SSC) and the impact this is likely to have on you and your organisation.

Back in August 2013, Advantio joined a webinar held by the PCI Council and its General Manager, Bob Russo, where the proposed changes were introduced a high level. Of particular note was the focus upon the current lack of education and awareness of the intention of PCI DSS as well as focus upon the evolution of the PCI DSS in response to the increased usage of mobile and cloud-based technologies. Other key topics included a subject close to Advantio’s heart; the importance of a formal and well-designed penetration testing methodology and threat modelling for the software development lifecycle.Subsequent to the webinar, the PCI SSC published a document highlighting changes between v3.0 and the current version of the PCI DSS v2.0 (available here).

So what impact will the changes have upon me and my organisation?

NETWORK DIAGRAMS

As a Qualified Security Assessor (QSA), it is not unusual to be presented with a large number of diagrams, none of them depicting the flow of cardholder data; some depicting only the core network switching and routing infrastructure through to the most detailed depicting each configuration item within the organisation. The change within version 3.0 provides clarity to the requirement, requiring the organisation to maintain a diagram that shows the cardholder data flow; it should be possible to identify the entry / exit points, acceptance channels and so on. Following creation of the diagram, maintaining the diagram should not represent a heavy administrative burden for an organisation.

Advantio Top Tip: Advantio normally suggests the inclusion of a key or colour scheme to identify data paths where encryption or clear-text transmission is used.

MAINTAINING AN INVENTORY

Version 3.0 will require the entity to maintain an inventory of systems and system components within the scope of PCI DSS compliance. Larger and more mature organisations will already maintain a Configuration Management Database (CMBD), which is used to assess the impact of a proposed change and therefore the change to the requirements will have little or no impact upon these organisations. The change to the requirement will also have little impact upon less mature organisations that may not maintain a CMDB though do correctly invest time and effort in performing their annual risk assessment (Requirement 12.1.2). These organisations will already have identified the in-scope assets as understanding the threats and vulnerabilities to these assets is key to the success of the risk assessment. Therefore, the change will only impact less mature organisation that are not already familiar with PCI DSS.

Advantio Top Tip: Advantio stresses the importance of maintaining an inventory and typically requests a copy of the inventory on the first day of an engagement with an organisation. Maintaining an inventory should not have an impact upon day-to-day operations if incorporated into existing processes and procedures, such as any release and deployment procedures.

MALWARE AND COMMONLY AFFECTED SYSTEMS 

Requirement 5 currently requires that anti-virus software must be used on all systems commonly affected by malware. This has perhaps unfairly drawn attention to Microsoft based systems and the plethora of anti-virus software vendors and away from the Mac OS, Linux and UNIX Operating Systems. For a long time, there have been rootkits and Trojans that affect Mac OS, Linux and UNIX Operating Systems. And malicious software threats are constantly evolving. Therefore, it makes sense, following the path of the Version 2.0 revision to Requirement 6.2, highlighting the need for continuous education and research, ensuring that organisations understand the threats and vulnerabilities, and appropriately protect against them.

MAINTAIN A LIST OF COMMON CODING VULNERABILITIES

Rather than being reliant upon the PCI DSS to track the common coding vulnerabilities, which is only updated every three (3) years, organisations will be required to maintain their own lists and incorporate the common vulnerabilities within their secure coding practices. This change should positively impact upon organisations, ensuring that they maintain an awareness of current coding vulnerabilities.

CONSIDERATION FOR OTHER AUTHENTICATION MECHANISMS

This year saw many, including Heather Adkins, Google's Manager of Information Security, heralding the death of passwords. In PCI DSS version 2.0, Requirement 8 has a heavy focus upon passwords, ensuring that they are sufficiently strong, changed regularly, etc. PCI DSS version 3.0 will see these requirements change to incorporate consideration for other authentication mechanisms, such as physical security tokens, smart cards and certificates. This will be a great benefit to those that have already begun to move away from passwords, removing any of the existing ambiguity how to satisfy the requirements.

PROTECTION OF POS TERMINALS

One of the most interesting changes in version 3.0 will be the inclusion of specific requirements relating to the physical security of the payment terminals, ensuring that they are sufficiently protected from tampering and/or substitution. PCI DSS has always been a compromise driven standard. The inclusion of specific requirements relation to POS terminals is directly linked to the increased number skimming attacks on POS devices. Other standards published by the PCI SSC already provide coverage for the physical security of ATMs and unattended POS terminals. Dependent on the specific processing scenarios, such as processing model, number of POS devices and locations, this requirement may introduce a new overhead on retailers and their PCI DSS compliance assessment.

PENETRATION TESTING: TESTING METHODOLOGY AND VERIFICATION OF SEGMENTATION

PCI DSS version 3.0 will introduce a requirement for a penetration testing methodology to be implemented as well as performing penetration tests to verify that the controls used to segment the environment are operational and effective. Unlike Approved Scanning Vendors (ASV), who are assessed by and registered with the PCI SSC, there is no central registry, vetting or control of penetration testers.

At Advantio, we have always believed in the importance of making a customer aware of our methodology and the ‘secrets’ behind our ethical hacking exercises, tuning the process to satisfy the need of the PCI DSS standard. However, currently with other organisations what you get for your money is not always clear.

Where organisations obtain there penetration testing services elsewhere, the addition of the requirement for a penetration testing methodology within version 3.0 and explicit inclusion of testing to verify the controls used to segment the environment will provide organisations with a greater level of assurance that their controls are effective. 

SERVICE PROVIDERS: CLEAR DIVISION OF RESPONSIBILITIES

This was the focus of a Special Interest Group (SIG), requiring organisations to maintain a list of the responsibilities fulfilled by their service providers. The level of detail required or how the requirement is to be addressed is unclear. However, it is commonplace to finding that organisations do not understand the services that their service provider provides to them.

For example, your firewall management company will implement the firewall changes that you request, however testing that the changes were effective and do not adverse affect the security of your environment requires business knowledge. Therefore, testing following a firewall change is not typically something that the firewall management company will be able to do for you.

Identifying and clearly defining responsibilities will be increasingly important as organisation increase their reliance upon third party service providers, such as hosting providers, Payment Service Providers (PSPs), IT support companies and cloud-based storage providers.

TRAINING AND DOCUMENTATION

PCI DSS Requirement 12.1 in version 2.0 stands out as a ‘catch all’; you had best make sure that everything you need to have documented has been. The existing requirement will be removed, with a move to the basic tenet of successful IT, the incorporation and alignment of people, process and technology.

Each requirement will consider the people, process and technology elements. Individuals must be aware of their responsibilities. Appropriate technologies and controls must be in place. And appropriate documentation, including policies, procedures and standards, must be available to support each requirement. For some organisations this may necessitate the creation of additional documentation.

If you would like further information or to discuss any of the points raised above, please do not hesitate to contact our QSAs at mail@ntt.ie or use the contact us form.

Marco Borza

Written by Marco Borza

I am the Founder of Advantio.
Technology has been my passion since I was a kid; when I first heard the handshake of an old 300bps modem I realised security would be key in an interconnected world. Since then it has become my passion and primary focus.
The reason why I've started my own business is to make IT Security simple.

Certifications: CISSP / CCSA (Checkpoint) / ITIL Foundations / ACSA (ArcSight)/ Linux+/ PCI-QSA / PA-QSA