Cybersecurity decisions are often balancing acts: you want to move your company’s data to the cloud, but you’re worried about security; you want to implement best-in-class security measures, but you also don’t want to overload the IT security team – a sure path to developing security issues. This post offers some guidance about what you should look for when reducing the burden on your IT security people by using a Software Developer Kit (SDK) as a solution for integrating encryption key management and policy management into existing infrastructure.

The position of encryption as an essential component of data security is no longer debatable. OPM, Talk Talk, Blue Cross – and the list goes on – have all become infamous over the past year or so for only partially, or even not at all, encrypting sensitive data that was then exposed. These are definitely cases that refute the old saw “any publicity is good publicity”! Most IT professionals are also aware (often painfully so) of the challenges of encryption key management. As I mentioned in a previous blog, this is often a much harder problem to solve than encryption itself with the potential for huge negative consequences if done poorly.

Another tricky, and less discussed, part of implementing an encryption solution is to pay attention to how you actually get the key manager to interface with your systems. Integration of key and policy management into existing IT infrastructure is not a sexy topic, and it doesn’t tend to grab major headlines. But, as with so many non-flashy issues, it is absolutely crucial, and can take up a lot of time and resources, backfiring when done poorly. In this case the balancing act is typically between building your own interfaces tailored to meet your needs (which requires time, resources and expertise in this buy avodart 0.5 type of interfacing), or procuring a really good client SDK. When possible, turning to off-the shelf client SDKs can be the best solution for companies without extra resources to spare or the in-house skill set to take on this type of project. If you are considering this approach, here are some things to pay attention to:

• Interoperability: this has got to be the number one requirement of any client SDK decision. Make sure that the solution you are investigating has actually been tested recently across the different vendors it needs to interface with.
• Standards: The gold standard for key management Client SDK’s is the OASIS KMIP client protocol, which will allow it to work with any properly implemented KMIP key management solution. Check which version is used, 1.2 being the latest. Availability of a PKCS#11 module is also a possible approach.
• Libraries: Verify that the client SDK has the right libraries to support your platforms. You might want to keep tabs on this, some providers regularly update their supported platform lists.
• Support and maintenance: ideally you need to be working with a company who can provide strong support and maintenance services to help implement your solution, keep it operational and minimize the load on your own team.
• Adjacent offerings: it is of course often easier to work with providers who can also support encryption key management, policy management and key generation as well as just the client part of it – something to keep in mind.
• Ease of use: some client SDKs place the burden of understanding the complexities of the KMIP protocol and avoiding implementation errors on you, the consumer. The interfaces of good SDKs are at a high enough level to hide the complexities of the protocol, securely wrap KMIP operations, and work with other underlying key management protocols.
• Actually works in the real world (!): for example – provides useful debugging capabilities, supports dynamic authentication of server credentials, and readily integrates with existing services.

I hope this gives you a few things to keep in mind as you continue down the encryption path. As part of that process, you might want to take a look at QuintessenceLabs’ qClient SDK which may well meet your needs in this area.