Facing a Testing Time
Looking for Problems
In a previous blog I talked about the various trigger points that provide users of Payment HSMs with an opportunity to review which HSMs they use and how they acquire their HSM capability. One of those opportunities is when the HSM vendor brings out a replacement model: this is actually exercising the minds of all users of the ubiquitous payShield product at the moment because Thales has recently announced the imminent withdrawal from sale of the payShield 9000 and its replacement with the payShield 10K.
This got me thinking about the issues those users will face. Backwards compatibility should not be a problem because Thales have always been pretty good at ensuring this. But there is a problem that users will face – how to go about testing the new model. And when you start mulling over the issue of testing you realise it’s a lot wider than just being related to product updates. It applies to everyone.
What’s the big deal about testing?
Why has testing floated to the top of my negative thoughts? There are probably two main areas where it causes difficulties.
Firstly, the complexity of planning it. Technical testing will probably need to be done early on in the replacement cycle to allow time for any application and system issues to be resolved before going live. But if the organisation plans to buy and operate the HSMs, then before this testing can be started the corporate purchasing cycle will need to be completed, space will need to be found in the data centre (bearing in mind that the old HSMs will still be operational), the HSMs will need to be integrated into the corporate network and support system, and operations and security staff will need to be trained up on the new models. Documented procedures will also need to be updated (although this may not be a barrier to starting testing). Doing all this in time to get testing underway may be tough to achieve.
The second area of concern is the simple one of cost. PCI security standards mean you have to use different HSMs for testing and for live production work. You will need to retain testing capability after you have gone live to allow you to test future application changes and updated software from the HSM vendor. This presents you with additional capital cost for HSMs which will spend most of their lives doing nothing, together with the costs of having them supported by the vendor, of providing data centre and network facilities, of operating the HSMs, and ultimately of disposing of them securely.
Testing capacity on tap
For many users, accessing MYHSM’s cloud-based Payment HSM Testing Service is a more efficient and cost-effective way of providing testing capabilities. This can be used both with applications that are also in the cloud or hosted on the user’s own IT infrastructure.
The Testing Service is fast and easy to sign up to, to operate, and to disengage from. Payment applications see the same interface as with Payment HSMs on premises.
The service is paid for by a monthly fee just for the period it is needed, avoiding the planning, training, Capex and operating costs of full-time Payment HSMs on premises with only a part-time role.
An important aspect of the cost-effectiveness of the service is that the tap can be turned off when the capability isn’t needed any more.