Introducing a PCI DSS compliant Key Management System to a Bank

The whole payment card industry relies on all players to have strong protection for card holder information and any weak link may destabilize the whole system. As a result, all non-compliant players can introduce unwanted vulnerabilities to the entire system.

Ease of overview and management of cryptographic keys

A proper key management system will ensure that there is ease of administration activities for the keys and there is assured continuity of business in the event that the main administrator for the keys retires or is dismissed from active duty.

In the event of an interruption, there must be a level of assurance that critical operations will continue because there will be back ups.

In a banking institution, there are many keys to be managed, and knowing which key does what may become difficult in the maze of keys. A proper inventory of keys has to be established and proper labeling of keys should be maintained. It is advised to engage in scoping activities that seek to clarify the boundaries of all hardware and logical devices or software that is involved in the processing of CHD so encryption plans can revolve around these technologies.

The ultimate responsibilities of the overall security of the organisation will be in the hands of the board of directors. Top management involvement in the key management schemes should be noticeable through security policies that create conditions to foster the development and maintenance of keys.

Key management is usually done in line with the organisational goals and objectives. Policies should be developed specifically for key management, and clarity has to prevail in terms of responsibilities of the different parties involved with the management of the keys from the beginning to the end of the key’s useful life. It is wise for an organisation to hand over the responsibilities of key management to the security department (in most larger organizations, there is a separate IT security department, which is in charge of handling all IT security related issues).

However, organisational architecture differs, and some may hand it over to a different department. The security department should be solely responsible for enforcing all security measures needed to protect the keys and their life cycle.

A banking institution should use strong encryption methods and refrain from weak ones like MD5 for hashing and SSL for tunneling, which can be replaced by TLS. NIST has published procedures on key management in special publication 800-57 which explains the different states and phases a key will be in from its inception into the systems, up to its decommissioning. The four distinct phases are pre-operational, operational, post operational and destroyed.

Pre-operational: All processes for registering a client and key establishment and registration.

Operational: After the key has been generated, its availability for cryptographic purposes provides a crucial service for the bank to achieve its set objectives. All the processes to deploy a key, maintaining including backing up and securely storing it are all handled in this phase.

Post operational: This will provide a standard way to deal with compromised, expired keys, key change and key derivation archival and key recovery.

Destroyed: At this phase caution has to be exercised to make sure that a banking institution is sure of which keys it need to destroy. Metadata may be kept but the risk of that metadata being captured by rogue elements is high, such that is is advisable to destroy even the metadata. 

Key life cycle

During the different operational stages of the life cycle a banking institution has to understand the different processes that take place.

During key creation, plans are made to strictly secure the key, and the use of strong encryption is advised. In asymmetric encryption, the primary focus for a bank would be to secure the private key and making sure that the physical or logical area containing this key is strictly restricted and access will only be granted on a need-to-know basis. The algorithm used for the key generation may not be protected but the key itself needs strict protection.

The backing-up of keys will follow and constant consultation with the backup and recovery team have to be made to clarify the importance of the use of external media and encrypting the backup.

Deploying the key will call for strong encryption methods and more recommended latest tunneling forms like TLS. Clear lines of authority have to be established and compensating controls should be in place where segregation of duties is not possible. Proper workflow documentation should be maintained so that in the event of an audit it is clearly established what has been going on. When the key has been deployed and activated, constant monitoring should take place with the sole aim of minimizing downtime. Critical systems that rely on the key management system (KMS) may experience downtime in the event of keys not being available. As such, monitoring may unearth critical unforeseen events and remedial action can be promptly taken to avert problems.

Rotation will entail activating a new key. It has to be noted, however, that caution has to be taken when dealing with old keys. They should not be removed from production before affirmation that there is no data encrypted with them. If they are removed haphazardly, unexpected downtime may cripple the business application and losses may be incurred. When a key reaches the end of its useful life it will reach the expiration stage or retirement which is dependent on a bank’s crypto-period. It is advisable (and in some circumstances, required) to set an annual crypto-period. Old keys at this stage are deactivated from the production environment.

The following stage of archival is not the same as deleting. Its equivalent to backup. It involves safely keeping all retired keys in a library with secure restrictions and period for which the key will be kept will depend on the bank’s data retention policy. Once the data that was encrypted with that key is no longer available then the keys can be destroyed.

The final stage of destruction summons the end of life of the key. This stage is usually sensitive since proper procedures to delete and erase the key from the KMS should be followed. Extreme caution has to be practiced in terms of objectively proving that the key will never be needed. In all these stages and processes, documentation has to be done at each stage which is clear and precise on what is taking place.

Conclusion

For banking institutions, compliance with PCI DSS key management should be a top priority for its security and compliance departments. It has to be noted that compliance is an ongoing process and monitoring of systems should be proactive. Any change in the environment has to be carefully planned for and risks calculated in terms of non compliance. The greatest point to note is that compliance with PCI DSS does not necessarily guarantee that a banking institution’s systems are fully secured. More measures to secure the whole infrastructure should be employed and investments should be made for constant research towards security and current trends.  

References

• NIST SP800-57 Part 1 Revision 4: A Recommendation for Key Management (2016) by Elaine Barker

• Selected articles on Key Management (2012-today) by Ashiq JA, Dawn M. Turner, Guillaume Forget, James H. Reinholm, Peter Landrock, Peter Smirnoff, Rob Stubbs, Stefan Hansen and more

• CKMS Product Sheet (2016), by Cryptomathic

• Payment Card Industry (PCI) Data Security Standard -
  Requirements and Security Assessment Procedures
  Version 3.2.1 (May 2018), by the PCI Security Standards Council
• The Falcon's View -Mental meanderings of an infosec obsessive (retrieved 5/2018), by Ben Tomhave

 Photo: Finance District, by courtesy of Joan Campderrós-i-Canas (CC by 2.0)