Congratulations! All your sensitive PII data is encrypted. (Probably. You’re never quite sure what the DevOps team is up to).
Your on-prem and cloud-based SANs are encrypted (even that one you discovered in a far-flung office), all your various databases are encrypted (at least the high-profile ones – there’s just too many to encrypt them all, surely no-one does that?), your S3 buckets are encrypted, you’ve set up BYOK for your SaaS applications, your VMs are encrypted, and you’ve even got some home-grown applications doing their own encryption (must get around to checking which algorithms they’re using). There’s also an HSM being used for the company PKI (it’s black magic to you; the guy running it has been here for 25 years – what will you do when he retires?). The DevOps team must be encrypting their stuff, too, presumably.
Yep, you can show the auditor that you have fifty-something encryption solutions (that’s good, right?). You can even point them towards the teams that manage most of them. Not quite sure about that new company you acquired recently, though. Or who owns security in the DevOps team.
Anyway, give yourself a pat on the back. The GDPR compliance box has been ticked. That costly data breach has been averted. Now you can focus on deploying that new fancy widget the boss has been asking for.
The CISO is asking questions. Do you know how many encryption keys you have? Do you know what they’re all used for? Do you know who has access to them? Do you know if they are being rotated regularly? Do you have audit logs showing their usage? If you can’t prevent the keys from being compromised, then what’s the point of encrypting anything in the first place? Phew, that’s going to be a lot of work. And you’ll have to talk to the DevOps team …
She doesn’t just want PII data encrypted, she wants sensitive company information like email, financial records, M&A docs, meeting notes, and strategy papers encrypted too – at the application level, if possible. And extend it to other companies in the Group. And you shouldn’t rely on storing encryption keys on servers anymore, they need to be protected in a secure external key store. And you shouldn’t let cloud service providers have access to the encryption keys for your data. And just what is the DevOps team doing to ensure their keys and other secrets aren’t hard-coded or left in unencrypted locations on Internet-facing servers …?
If only you could manage all your encryption keys centrally. Then you would have instant visibility of all your keys and what they are used for. You could control who has access to them, and which keys require a quorum approval to use. You could set up crypto policies to enforce which algorithms and key lengths are permitted. You could set up automated key rotation policies. Of course, it would need to support PKCS#11, JCE, CAPI/CNG, KMIP, and BYOK to integrate with all your applications. Also, a REST API so the DevOps team can manage their own keys, secrets and certificates for whatever it is that they do.
Of course, it would need to be very secure, also highly available, and capable of scaling seamlessly as you grow. It must support both on-prem and cloud keys – no, make that multi-cloud. And integrate with your SSO and SIEM tools. And if you could manage the keys in that old HSM too, even better – you’re committed to a support contract, but once that expires it would be great if the key management system could take over that function.
Fortunately, you’ve just discovered that Fortanix Self-Defending Key Management Service can do all of this, and more! At a flat, predictable price to make budgeting easy. In fact, it’s going to save so much work, you’re going to save money. And it will provide much better protection against that costly data breach. Perhaps even the DevOps team – I mean the DevSecOps team – will be happy.
Get our blog updates in your inbox: