Given the quantity & variety of hardware security modules (HSMs) used by financial services for the support of cryptographic service provision, it can be difficult to pick the working condition, productivity, performance, health, & usage of each HSM. This is a core issue of management & monitoring. It is dear & time consuming for project architects to design systems that utilize HSMs, having to build crypto infrastructure from scratch in every new project & integrate against HSM APIs.
As in lots of banks, the development staff does not have all the necessary experience of working with different HSMs, even when supported by well-trained security professionals. Avoiding design mistakes, implementation delays & conflicts with internal auditors, shortens the project time & saves resources. A major issue that banks face is maintaining proper management of encrypted knowledge - ensuring that sensitive knowledge remains encrypted in storage as well as transit, while complying with internal audit & method standards such as PCI DSS. Encryption of the knowledge is the simple part, but ensuring that the knowledge can be migrated from encryption under an older key to a used or upgraded to a stronger encryption algorithm can be challenging - without causing significant downtime to the method whilst the knowledge is translated. Sometimes fundamentally keeping track of which knowledge 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 pricey & specialized devices. But due to the paramount requirement for availability & resilience in banking systems, ever more devices are necessary to make positive resilient systems able to supporting peak lots, despite the high performance of modern HSMs. Where or HSMs in theory might suffice, difficulties in configuration & secure sharing of the devices mean that a large service application might require times as lots of HSMs to support it, times the different development, testing, & catastrophe recovery instances are taken in to account. HSMs are under-utilized because of these issues of accommodating multiple applications on the same HSM, & in getting the necessary reliability guarantees... some HSMs have less than 25% utilization.
Even with efficiency & utilization savings on HSMs, the sheer breadth of applications supported by an immense bank means that a wide choice of underlying HSMs will be necessary: Specialist applications such as payment authorization need specialist HSMs. At an operations level these banks needs a unified view of its HSM estate, showing health & performance, in order to maintain the infrastructure at peak efficiency. The more detailed the knowledge obtainable, the simpler it is to identify & remove bottlenecks. Such a monitoring & control method ought to permit mixing of different types of HSMs (with different programming APIs) & from different manufacturers. The method must permit for hot-swapping of devices & support scaling of the method to support even high performance requirements.
It is not sufficient fundamentally to operate a secure system; banks have a requirement to show that they are doing so. Like any bank they are subjected to regular audits from a variety of bodies including national & international card schemes. Demonstrating compliance with regulations can be time consuming & burdensome, even in simple projects & regular business routines. The particular security settings used may be buried deep in design & specification documents, which incur time & manpower to locate, so it may be even harder to demonstrate to an auditor that the method is actually operating as the design claims it ought to. Banks therefore have a requirement at the cryptographic level to demonstrate both a coherent security policy owner, & the enforcement of that policy owner.
However as cryptography becomes ever more present for knowledge security in most applications, developers who are not security specialists are necessary to become involved in defending the knowledge handled by their application. Than incurring the cost of hiring additional specialists, or risking delays to projects, most banks would far prefer to make security & encryption services obtainable to non-specialists in a safe manner. A solution is desired which keeps their program procurement method lean & fast. Solutions offering failover & recovery of HSMs, or an API supporting simplified crypto operations are obtainable, but a plethora of legacy & proprietary parts proves hard to combine in to efficient solution.
One method of solving these issues would be in the form of a cluster of high performance servers which sit between the banking applications and the HSMs. This may provide a centralized system featuring key management and comprehensive compliance tools arranged around it in a secure, cloud-like environment. Allowing the project designers to do what they do best - write application software, which accesses a complete and compliant security service, as and when required. Introducing the notion of a portal for HSMs as an underlying software service around which a security business service can be offered. As a standards based, and business platform independent solution, interfaces to authentication, key management, monitoring and logging systems should allow easy integration of third-party components with the system. A cryptographic service of this nature could allow HSMs to be shared across a wide variety of applications thereby reducing the overall HSM estate by more than 50% and saving banks millions per year in maintenance costs alone.
0 komentar:
Posting Komentar