What is the PCI DSS?
The intent of the PCI DSS standard is to protect cardholder data and, through this, to protect the cardholder, the issuing bank, payment brands and the other entities in the payment card ecosphere.
The protection is provided by a set of mandatory controls that are organised into six objectives comprising 12 main requirements.
In version 3 of the PCI DSS, there are 244 controls in the 12 main requirement sections. In addition to this, there are 399 testing procedures that need to be met to gain certification to the Standard. During an audit the assessor will attempt to ensure that the testing procedures have been met, thereby proving that the organisation is compliant.
|Requirement section||Number of Requirements||Number of testing procedures|
In our experience, it is meeting these testing procedures that causes problems for organisations trying to demonstrate compliance to the Standard. Lacking evidence that the controls are in place is a common cause of failure to achieve compliance.
Organisations need to follow the old maxim about documentation: document what you do and do what you document.
We find during gap analysis exercises that organisations follow good practices, but these are not documented. Those on the front line know how to do their job; they have the knowhow to secure information and systems, but they also need to know why it needs to be done. Human nature is such that if we don’t understand the need to do extra work, we won’t go that extra mile. Furthermore, technical people are often poor at documentation, but they are the ones with the knowledge to create accurate and sensible documentation. When working under pressure, it is often the recording of evidence that gets missed in the rush to complete jobs, and this is not caught up on later. A lack of evidence showing that work has been completed will prevent certification to the Standard.
In gaining accreditation to the PCI DSS, the enemy is not the hackers or the auditors, but the organisation’s employees. As Sun Tzu wrote, “Know your enemy and know yourself, find naught in fear for 100 battles”. In order to achieve compliance, you need to know the weaknesses in your own systems. Information security is about the people, processes and technology, and often it is the people who are the weakest link.
Being compliant is not the same as being secure. Compliance is simply conforming to official requirements, while security is the state of being secure.
The PCI Security Standard Council recognise that the Standard won’t make an organisation totally secure; the Standard is the minimum level of security that the stakeholders (payment brands) find acceptable to minimise the risk to cardholder data. It is the payment brands’ risk appetite that sets the requirements, not the risk appetite of the implementing organisation.
Implementing the PCI DSS
When an organisation decides it will become compliant, it often starts up a project to achieve this. Whatever the chosen project management methodology is, it requires the following:
- Verified support from senior management or a project sponsor to confirm the organisation’s focus and investment exists to support the compliance effort.
- Creation of a formal project charter.
- Core team that has representatives from key stakeholders within the organisation.
While implementing the Standard can be a difficult and complex process, it is also easier than maintaining adherence to the Standard. When implementing the project, the core team with the necessary skills is brought together, but when the project completes the team disbands, experts return to working within their own teams and the driving force to ensure adherence to the Standard is weakened or non-existent.
Version 3 of the standard
The PCI DSS is developed on a three-year cycle. The latest version of the Standard, v3, was released in November 2013 and became certifiable on 1 Jan 2014. The old version is due to be retired on 31 Dec 2014, giving a transition period where an organisation can either continue to certify against v2 or move to v3. The next version is due to be released in November 2016 when the cycle starts anew.
The intent of the v3 changes was to help organisations make payment security part of their business-as-usual activities, introduce more flexibility, and increase the focus on education, awareness and making security a shared responsibility.
Overall updates include specific recommendations for making PCI DSS part of everyday business processes and best practices for maintaining ongoing PCI DSS compliance; guidance from the Navigating PCI DSS Guide built into the Standard; and enhanced testing procedures to clarify the level of validation expected for each requirement.
A key point that the PCI SSC is driving forward is making compliance activities part of everyday business processes – i.e. Business as Usual (BAU), which is the normal execution of standard functional operations within an organisation. An employee’s everyday actions are normally defined by work instructions or standard operating procedures, and BAU is the standardisation of all of your processes to the point that they become second nature, and are documented in such a fashion that anyone can pick up where the previous person left off.
The PCI SSC is hoping that by building the controls into organisations’ BAU, then the biggest problem in maintaining compliance will be diminished. As previously stated, the failure to collect evidence of controls being in place during everyday operations is the most common reason that organisations fail the annual audit. By ensuring activities such as monitoring daily logs are part of work instructions, the operators responsible will ensure that events that are generated from analysis of the logs are followed up on and the appropriate actions taken, and all this is recorded in checklists and records.
A recent example of why PCI DSS controls need to be part of everyday operations was the Heartbleed vulnerability announcement. As part of requirement 6.1, organisations need to establish a process to identify security vulnerabilities – using reputable outside sources for security vulnerability information – and assign a risk ranking (for example, ‘high’, ‘medium’, or ‘low’) to newly discovered security vulnerabilities.
When the Heartbleed vulnerability was announced, organisations needed to pick up on the announcements quickly. Because of its high profile, a lot of announcements were issued, some of which were not totally accurate; the reputable sources of vulnerability data, however, were correct. Any organisation meeting the PCI DSS should have also picked up on the vulnerability warnings issued by the payment brands. Discussions I have had with organisations since then, however, show that most had failed to see the VISA security alert.
As a QSA, I would expect to see that organisations being assessed had recorded the announcement, classified it appropriately and taken appropriate actions – and recorded all of this. If systems were reconfigured, then evidence should be in the configuration management systems and the change management systems showing that senior management had signed off on the changes.
The PCI SSC has given examples of how PCI DSS should be incorporated into BAU activities, including but not limited to the following:
- Monitoring security controls to ensure that they are operating effectively and as intended.
- Ensuring that all failures in security controls are detected and responded to in a timely manner.
- Reviewing changes to the environment prior to completion of the change.
- Changes to organisational structure should result in a formal review of the impact to the PCI DSS scope and requirements.
- Periodic reviews and communications should be made to confirm that the PCI DSS requirements continue to be in place and personnel are following secure processes.
- Review hardware and software technologies at least annually to confirm that they continue to be supported by the vendor and can meet the organisation’s security requirements, including PCI DSS.
These best practices for implementing PCI DSS into business-as-usual processes are provided as recommendations and guidance only, and they do not replace or extend any PCI DSS requirement.
Employees can’t do what they have not been told about, and they will not read pages and pages of formal documentation. To ensure they follow the required controls their work instructions should only cover what is relevant to the activities undertaken. Additionally, awareness training will need to be given on a regular basis – this is a PCI DSS requirement itself. Increasing awareness and education across organisations can help drive payment security as good business practice.
Documentation needs to say how activities should be recorded – the evidence that needs to captured – along with reasons and justifications for decisions to be recorded appropriately. It must be easy to read, ensuring that the controls are transparent and part of the work flow.
Senior management should ensure compliance activities are completed. This can be achieved by using dashboards displaying monitored key performance indicators, which could include the following:
- Patch management.
- Number of vulnerabilities over time.
Requirement 12 requires organisations to maintain a policy that addresses information security for all personnel. It does not define a particular standard to be followed, but standards such as ISO27001 can help organisations create a suitable ISMS.
A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it.
When an ISMS standard such as ISO27001 is used, the requirements of the PCI DSS need to be integrated with the appropriate ISO27001 requirements to create an ISMS for the organisation that can be audited against both standards.
The PCI DSS is about protecting cardholder data. This can only be achieved if security best practices are applied on a daily basis. Although the PCI DSS is only audited annually, security can only be achieved when the controls are implemented as business as usual. To ensure adherence to the Standard (and therefore certification) organisations need to record evidence of everyday use of the controls that the Standard mandates.
The biggest issue in securing cardholder data is not the processes or technology, but the people within the organisation. A successful implementation of the Standard requires organisations to understand their greatest asset: the people who work for them. They need to ensure that their employees know how to make their everyday roles secure through relevant work instructions, but without being overloaded with formal policies and documentation.