PCI DSS, Prism and backdoors

Within days of PRISM being exposed questions were being asked about the effect of possible backdoors into operating systems and the effect this would have on PCI Compliance. There have been some very good points made and some excellent answers given in a number of the forums around PCI compliance.

Having spent effectively the last week within minimal time to follow the news as I have been delivering an in-house week long information security training course in a hotel I am trying to catch-up with the developments.

It does seem that little is known about how PRISM actually works, other than it is a security programme for monitor communications that in the USA is covered by their Foreign Intelligence Surveillance Court making the collection of the data lawful within the USA. The PRISM programme appears to revolve around access to data at nine internet service providers (ISP), who have all said access requests covered by legal requests is given, however the ISP's also say there is no direct access to their data given. Other than the articles in the press where the term ‘backdoor’ is being bandied about there is no definitive proof an actual backdoor into operating systems was being used.

A concern of those who have been discussing PRISM and its potential backdoors into operating systems are about the ‘backdoor’ itself being compromised and being used by people other than those it was intended for.

Within the PCI DSS requirements, the controls on Account data (Cardholder Data and Sensitive Authentication Data) are such that if there is a legitimate legal request for access to account data it can be granted. Any law enforcement agency can request access to account data using due legal process within a judicial area that has jurisdiction over the account data.

The organisations that have to comply with the PCI DSS need to be concerned about unauthorised access to account data and hence the concern over a built in backdoor in an operating system to allow law enforcement access. This concern of backdoors is not new and is not limited to the recently publicised used of PRISM by USA. There have been recorded attempts at getting backdoors into the Linux kernel over the years by compromising the repositories of the kernel, along with rumours of back doors in the Microsoft Operating Systems.

The requirements of the PCI DSS are grouped into six areas

1. Building and maintain a secure network
2. Protect Cardholder Data
3. Maintain a vulnerability management program
4. Implement strong access control measures
5. Regularly monitor and test networks
6. Maintain an information security policy

PCI DSS compliant organisations have to implement controls that would prevent a breach. An unknown backdoor would be considered a zero-day vulnerability. Requirement 6.2 of the PCI DSS requires that a vulnerability management process to be in place to identify and assign a risk rating to vulnerabilities. If you are responsible for PCI DSS compliance you will need to consider the risk of the potential of an unknown backdoor being in the operating system of your servers.

If we consider what a backdoor is in terms of an operating system it provides remote access that bypasses the access controls implemented to ensure only properly authenticated and authorised subjects have access to the resources within that system.

That leaves us with two points to consider

• Remote access requires a connection through our perimeter around the cardholder data environment (CDE)
• Cardholder data should be protected whilst stored

The two main requirements of the PCI DSS that cover these points are

• Requirement 1: Install and maintain a firewall configuration to protect cardholder data
• Requirement 3: Protect stored cardholder data

Control of remote access

The requirements for controls on remote access are under subsections 1.2 which is “Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment” and sub-section 1.3 which is “Prohibit direct public access between the Internet and any system component in the cardholder data environment”. For a backdoor to be used and attacker would have to penetrate through the network protection or use a tunnel that can pass through proxies and use allowed protocols.

In order to protect the CDE the PCI DSS recommends vulnerability testing and penetration testing as covered by the requirements 11.2 run internal and external network vulnerability scans at least quarterly and after any significant change in the network and 11.3 external and internal penetration testing at least once a year and after any significant infrastructure or application upgrade or modification covering both network and application. This testing is only as good as the vulnerabilities and exploits that are known. The required level of testing by the PCI DSS should considerably reduce the possibility of an attacker gaining access to a server in order to access a built in backdoor.

A network built it the requirements of the PCI DSS requirement 1 should also reduce the possibility of a tunnel existing that can be used with the backdoor to give access to account data.

Protecting stored account data

The PCI DSS has a requirement (req. 3) that stored cardholder data is protected through the use of strong cryptography and cryptography key management. A backdoor to the operating system may not be sufficient to gain access to applications using strong authentication and authorisation through additional third party applications. The PCI DSS requires not tying encryption accounts to the native operating systems access control mechanism. The architecture of any account data processing, storing or transmission application should be designed in such a way to limit access to cryptographic keys used to encrypt account data and give independence of the application from the native operating systems, this would reduce the effectiveness of any vulnerability within the operating system.

Conclusion

The layered approach that is built into the PCI DSS does give strong protection to account data providing the requirements have been implemented fully and correctly.

If you are PCI DSS compliant and are following the requirements of the standard fully you would be reducing the risk considerable. Compliance with the PCI DSS does not guarantee security, however it is a minimal level of security that any prudent or diligent organisation should be doing to protect account data.
In conclusion there is a potential risk to account data from a possible backdoor built into operating systems being used by the PRISM program being discovered and used for nefarious purposes, however the PCI DSS requires organisations to consider the possibility of unknown vulnerabilities, such as a zero-day backdoor, and to have in place controls to minimise the risk, although there will also be a residual risk. Your risk assessment should establish the likelihood of this type of vulnerability occurring and whether your countermeasures have reduced the risk to an acceptable level for the organisation, if you are doing self-assessment, or to the level acceptable by a QSA if you having to complete a RoC. By implementing the controls in the PCI DSS and being compliant you are showing due diligence in trying to protect account data.