The payment card industry data security standard (PCI DSS) calls for all financial institutions and merchants to protect their clients’ sensitive data, which typically includes the use of strong cryptography as dictated by PCI DSS requirement 3. Most organisations empty this burden on the IT department or IT management teams and hope all their compliance is covered. However, in most cases when there is a data breach, the burden lies on the shoulders of the C-level management, who are left to answer to 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 that management need to be weary 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 the business 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. What these frameworks have in common is that the organisation should establish a risk management process that can constantly address known and emerging risk 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.
Identifying risks that can affect PCI DSS compliance is the first step.
Risk identification will be the part that labels out all known risk and maintaining a risk register so that all identified risks are recorded and described. Even the use of specialised cryptographic equipment like HSM devices (hardware security module) in the key management process, brings about 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.
At this stage, all the identified risks are analysed for the likelihood of occurring. A mixture of qualitative and quantitative techniques are 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 complexity of the technologies involved. 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 and traffic reaching the devices will have to pass a series of checks and rules. The result of mathematical calculations - to estimate the annual rate of occurrence, exposure factor and annualised loss expectancy - can give insight to decisions on acquiring an HSM and which set up to use.
IT governance is an integral part of the business, which seeks to create a linkage between the overall business goals and IT related goals and to keep them in sync, so that IT supports the ultimate organisational vision and goals. Most, if not all, organisations seek to gain benefit from IT related investments and gain competitive edge by driving costs down and increasing profits.
If an organisation is considering investing in a cloud HSM, they must analyse 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-cloudHSM 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 the 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 organisations that need to safeguard client information from exposure using HSM in the cloud is likely different from the treatment taken by organisations 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 are 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 organisations to use on-premise solutions. In cases where HSM devices are hosted on premises, risk sharing methods like insurance often help in maintaining an acceptable level of risk.
On-premise solutions enable better implementation of controls and to strictly manage the tender processes so that hardware will only be acquired from certified manufacturers that meet a specific criteria, for example compliance with FIPS 140-2 security level 3 and 4.
There are sectors like the financial services industry, where organisations, 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 important steps in the risk management scheme. For most advanced organisations 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 organisations tend to cut corners and assume that a breach will only happen to others and not themselves. Tight maintenance schedules have to be adhered to and appropriate corrective actions taken for all non compliance configurations. Industry standard recommendations have to be implemented.
In my experience, most organisations cut corners and focus only on the balance sheet and forget that following procedure and inspecting if policy is being adhered to, is the most important part of IT management. In the worst case scenario, this can be the deciding factor in whether the organisation 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