Given the quantity and variety of hardware security modules (HSMs) used by financial services for the support of cryptographic service provision, it can be difficult to determine the working condition, productivity, performance, health, and usage of each HSM. This is a core problem of management and monitoring. It is very costly and time consuming for project architects to design systems that utilise HSMs, having to build crypto infrastructure from scratch in every new project and integrate against HSM APIs.
As in many banks, the development staff do not have mining all the necessary experience of working with different HSMs, even when supported by well-trained security professionals. Avoiding design mistakes, implementation delays and conflicts with internal auditors, shortens the project time and saves resources. A major problem that banks face is maintaining proper management of encrypted data – ensuring that sensitive data remains encrypted in storage as well as transit, while complying with internal audit and scheme standards such as PCI DSS. Encryption of the data is the easy part, but ensuring that the data can be migrated from encryption under an older key to a new one, or upgraded to a stronger encryption algorithm can be very challenging – especially without causing significant downtime to the system whilst the data is translated. Sometimes simply keeping track of which data records are encrypted with which keys can be a challenge.
Banks make extensive use of hardware cryptography – encryption using keys stored in HSMs, which are costly and specialised devices. But due to the paramount requirement for availability and resilience in banking systems, ever more devices are required to ensure resilient systems capable of supporting peak loads, despite the high performance of modern HSMs. Where one or two HSMs in theory might suffice, difficulties in configuration and secure sharing of the devices mean that a large service application might need three times as many HSMs to support it, once the different development, testing, and disaster recovery instances are taken into account. HSMs are under-utilised because of these problems of accommodating multiple applications on the same HSM, and in getting the necessary reliability guarantees… some HSMs have less than 25% utilisation.
Even with efficiency and utilisation savings on HSMs, the sheer breadth of applications supported by a large bank means that a wide variety of underlying HSMs will be required: Specialist applications such as payment authorisation require specialist HSMs. At an operations level these banks needs a unified view of its HSM estate, showing health and performance, in order to maintain the infrastructure at peak efficiency. The more detailed the data available, the easier it is to identify and remove bottlenecks. Such a monitoring and control system should permit mixing of different types of HSMs (with different programming APIs) and from different manufacturers. The system must allow for hot-swapping of devices and support scaling of the system to support even very high performance requirements.
It is not sufficient simply to operate a secure system; banks have a requirement to prove that they are doing so. Like any bank they are subjected to regular audits from a variety of bodies including national and international card schemes. Demonstrating compliance with regulations can be very time consuming and burdensome, even in simple projects and regular business routines. The particular security settings used may be buried deep in design and specification documents, which incur time and manpower to locate, so it may be even harder to demonstrate to an auditor that the system is actually operating as the design claims it should. Banks therefore have a requirement at the cryptographic level to demonstrate both a coherent security policy, and the enforcement of that policy.
However as cryptography becomes ever more present for data security in most applications, developers who are not security specialists are required to become involved in protecting the data handled by their application. Rather than incurring the cost of hiring extra specialists, or risking delays to projects, most banks would far prefer to make security and encryption services accessible to non-specialists in a safe manner. A solution is desired which keeps their software procurement process lean and fast. Solutions offering failover and recovery of HSMs, or an API supporting simplified crypto operations are available, but a plethora of legacy and proprietary components proves very difficult to combine into one efficient solution.