The financial market undergoes significant changes. This article will look at how the choice of a suitable HSM and crypto strategy will support and enable a fast, targeted and enforced pursuit of the corporate goals.

In our article “Cryptography in Financial Institutions: Where Market Changes Require a Mutual Understanding by CEO and CISO – to Manage Risk AND Reduce Total Cost of Ownership”, we described the interdependence of

Changing competitive landscape
Changes driven by new regulations and standards
Consolidation on the supplier side of cryptographic systems
The ability to pursue the bank’s goal.

In this article we will dive deeper into the parameters which deserve consideration and explain why.

Reducing Total cost of Ownership

Severe competition and increasingly volatile markets push CEOs and CIOs to rethink their IT and bring costs down. On the first glance this does not look like good timing as attacks and attempted online fraud is getting more and more technically sophisticated.

But the bank can solve two problems in one by getting to more modern and safer systems.

So what can be done?

1. Upgrading and consolidating to more performant HSM infrastructures

PCI PTS HSM forces banks in its version 3 to lift their payment networks to more modern architectures. In particular they need to be key-block enabled. Old architectures and legacy HSMs need to be replaced. This will also involve an adaptation of the banking apps’ crypto interfaces.

Many old HSMs can be replaced by fewer, safer, more reliable and more performant HSM infrastructures. The amount of deployed HSMs can be cut by up to 50%.

2. Move to virtualization of HSMs

The amount of HSMs can be drastically reduced when applying virtualization and thus move to partitioned or containerized HSMs. Technically this means that one physical banking-grade HSM can manage several virtual HSMs. If you are interested in learning how this works in practice, please get in touch.

Move-to-virtualized-HSMs

3. Delegating Banking applications partially to the cloud

The public cloud is a trade off to banks. It may create open flanks if not properly addressed such as external hosting and travelling through the internet. But it also has many advantages like financial savings, flexibility and scalability or global reach.

The opening of banking APIs and the gradual replacement of old mainframe architectures by challengers like Microsoft, Oracle or SAP even migrate parts of the bank’s core management applications to the cloud.

This approach has the following risk potential:

The cloud provider is the master of all crypto that takes place in the cloud. The banks lays its security and hence its trustworthiness into the hands of a third party;
Managing all data, all applications and the cryptographic keys gives the cloud service provider access to all sensitive data
Changes in regulations, emerging security risks, changes in policies (e.g., geographical segmentation) may require rapid responsiveness and scope of manoeuvre by the bank. If the bank depends on the cloud service provider, it cannot act autonomously
the bank is pushed into a vendor lock-in (as data is tied to the one who has the key to them).

The bank loses its capacity to do end-to-end management of keys, if parts of the cryptographic keys are managed by various cloud service providers. In that case, key management of data accommodated by the local data center remains in the hands of the banks.

The silver bullet is a crypto server cloud, where keys are managed by the banks in secure, banking-grade HSMs. If the bank wants to move data from one cloud to the other, it can be easily done without any vendor lock-in.

Utimaco-Hybrid-Cloud

4. Turning the architecture less complex and more straightforward

Reducing the number of involved devices makes their management more economical and will most probably reduce the purchase price.

Another aspect will be to choose full line crypto-providers which supply out of one hand HSMs and key management and who provide readily the interfaces and key-blocks required in the variety of applications. This consequently also makes the banks faster w.r.t. Time-to-market, as interfaces are available, integration is simple (probably made as standard API) and less interlocutors are required.

5. Merging Payment and General Purpose HSMs

Let us address a holy grale. Why not bring payment and non-payment applications into the same banking-grade HSM architecture? If all compliance requirements are fulfilled, nothing speaks against it. It will definitely impact the bank’s internal structures and risks opposition as even internal human resources can be reduced.

Consequently it may require a more empathic and HR-oriented approach, than a technical. C-level managers should be aware that opinions by team members concerning the merging of these two worlds may be rather driven by fears about job loss than by technical concerns.

6. Turning the banking architecture flexible and crypto-agile

In the previous section we already addressed time-to-market. We should visit it when addressing the crypto-agility. New applications, new strategic targets or new regulations might require changes in applications as well as in crypto.

The answer to both is crypto-agility. Banks need architectures that are flexible enough to rapidly integrate new applications, built or deployed in-house, or connected via open APIs from external service providers.

In the same time crypto needs regular updates, driven by external threats, changes demanded by the regulators or the advent of post quantum computing.

Crypto-agile HSM architectures will make sure that operating costs will remain controllable. It would be fatal to save money during the purchase phase and end up in a monolithic, proprietary and non agile architecture after a short period of time.

7. Following a Dual Vendor Strategy

We keep on talking about lock-in situations. A serious infrastructure management involves risk mitigation. This implies that there are always a minimum of two vendors, providing HSM solutions. This will dilute the cost gains through centralization, but will retain independence from one monopolistic supplier. It also will reduce down-times and migration, if one of the vendors disappears due to financial or contractual problems.