How to Reduce Cryptography-Risks related to PCI DSS

The payment card industry data security standard (PCI DSS) calls for all financial institutions and merchants to protect their client's sensitive data, typically including strong cryptography as dictated by PCI DSS requirement 3. Most organizations empty this burden on the IT department or IT management teams and hope that all compliance requirements are met. However, in most cases when a data breach occurs, the burden lies on the shoulders of the C-level management, who are left to answer the difficult questions.

To curb this problem, top management must play an active role in managing the risks involved in cryptography and its related subjects in the achievement of PCI DSS compliance. The first and foremost risk management needs to be wary of is the risk of non-compliance, which in some cases will lead to the business losing a critical trading license and can translate to closing operations.

Businesses are encouraged to implement a risk framework that manages all the challenges faced in a PCI DSS environment. Frameworks like ISO 3100, Risk IT from ISACA, or NIST special publication 800-37, to mention just a few, can assist in achieving a well-balanced risk management program. These frameworks have in common that the organization should establish a risk management process that can constantly address known and emerging risks appropriately and in a timely manner.

The following steps are critical in the management of risk involved in the cryptographic sphere, which is one of the areas responsible for enforcing the maintenance of privacy and protecting cardholder data.

Risk Identification

 The first step is to identify risks that can affect PCI DSS compliance. Risk identification will be the part that labels all known risks and maintains a risk register so that all identified risks are recorded and described. Even the use of specialized cryptographic equipment like HSM devices (hardware security module) in the key management process brings risks and vulnerabilities. Consider one advantage of HSMs is that they create a root of trust and that this can also create a risk - if the HSM is compromised, the whole system is vulnerable. It is highly unlikely for the HSM devices to be physically and logically compromised, but there are cases where it has occurred, for example, the DigiNotar attack in 2011. This led to the ultimate closure of the Certificate Authority. 

In this case, DigiNotar had implemented all their HSM configurations as per the recommendations of PKCS #11. According to the forensic analysis conducted, the most critical factor that led to the attack was poor security design and policies. DigiNotar was running out-of-date software, which is the most critical factor in all logical attacks.

Risk analysis

All the identified risks are analyzed at this stage for the likelihood of occurring. A mixture of qualitative and quantitative techniques is employed to reach a decision on the risk treatment methods. In the case of cryptographic modules (HSMs), the inherent risk brought about by the HSM devices is the technology's complexity. The more complex configurations get, the higher the risk of human error. Which can render the secrecy of the master keys susceptible to attack. In a Certificate Authority setup, the HSM devices will be hidden behind a series of firewalls in different network security zones. Traffic reaching the devices will have to pass a series of checks and rules. The outcome of mathematical calculations - to estimate the annual rate of occurrence, exposure factor, and annualized loss expectancy - can give insight into decisions on acquiring an HSM and which setup to use.

IT governance is an integral part of the business, which aims to align the overall business goals and IT-related goals and keep them in sync so that IT supports the ultimate organizational vision and goals. Most, if not all, organizations seek to gain benefits from IT-related investments and gain a competitive edge by reducing costs and increasing profits.

In the banking industry, the need for privacy has seen costs rise due to the requirements by governments and regulatory institutions to safeguard personally identifiable data. 

If an organization is considering investing in a cloud HSM, it must analyze the risk of the HSM being compromised due to known vulnerabilities in the physical devices that they use. For example, a specific HSM used by Amazon for its AWS-cloud HSM once had a vulnerability that allowed the extraction of secret keys. This has since been patched, but the point is this information is crucial for risk analysis which can aid in security designs for cloud clients.

Treatment of risk

Treatment is affected by the types and nature of risks involved and is ultimately affected by the business model. The treatment methods used in organizations that need to safeguard client information from exposure using HSM in the cloud are likely different from the treatment taken by organizations using these devices on premises. In the cloud, the physical devices are with the service provider and, that being the case, the control of the devices is not in the hands of the client - as a result, should any compromise occur, the provider might be liable for the losses incurred.

However, it is advisable for organizations to use on-premise solutions. In situations where HSM devices are hosted on-premises, risk-sharing methods such as insurance are frequently used to maintain an acceptable risk level.

On-premise solutions enable better implementation of controls and strictly manage the tender processes so that hardware will only be acquired from certified manufacturers that meet specific criteria, for example, compliance with FIPS 140-2 security levels 3 and 4. 

There are sectors like the financial services industry, where organizations, such as issuing banks, are cautious about cryptography in the cloud and still prefer their HSMs physically on-premise, to ensure full control and to demonstrate compliance with PCI DSS requirements.

Monitor and review Risks

This is one of the most crucial steps in the risk management scheme. For most advanced organizations with a well-defined maturity level, a miss on the monitoring element can have catastrophic results. Emerging risks must be closely monitored in terms of changes in the regulatory environment. Most advanced organizations tend to cut corners and assume that a breach will only happen to others, not themselves. Tight maintenance schedules have to be adhered to, and appropriate corrective actions taken for all non-compliance configurations. Implementation of industry-standard recommendations is required.

In my experience, the majority of organizations cut corners and only focus on the balance sheet, forgetting that the most important aspect of IT management is following procedure and inspecting policy compliance. In the worst-case scenario, this can be the deciding factor in whether the organization continues to exist or not.

References and Further Reading

• Selected articles on Key Management (2012-today), by Ashiq JA, Guillaume Forget, James H. Reinholm, Matt Landrock, Peter Landrock, Steve Marshall, Torben Pedersen, and more 
• Selected articles on HSMs (2012-today), by Asim Mehmood, Guillaume Forget, Matt Landrock, Peter Landrock, Rob Stubbs, Steve Marshall, Torben Pedersen, and more 
• FIPS PUB 140-2 - SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES (2002), National Institute of Standards and Technology 

Image: "Acarien", courtesy of Jean-Raphaël Guillaumin, (CC BY-SA 2.0)