As machine identities become more prevalent and the dangers of their misuse become more publicized, auditors are beginning to pay closer attention to what organizations are doing to protect their keys and certificates. This increased scrutiny from auditors is prompting many organizations to re-evaluate their machine identity management strategies.
Compliance of all types is essentially becoming the impetus for organizations to focus on machine identity problems that may have been overlooked before. Large organizations have got so many things that they're dealing with, like every organization, and priorities will change from one week to the next pretty much based on who within high-level management is shouting them out at the time, or whatever itch is the most painful at the time. But with the spectre of audit findings looming over their heads, the awareness about the importance of machine identities and the need to protect them is increasing—from the highest levels of management on down.
I think regulations such as the Payment Card Industry’s Data Security Standard (PCI DSS) and frameworks like NIST’s SP1800 series have been very good at raising awareness of machine identities. While PCI pertains only to those organizations who are handling payment card data or personally identifiable information, NIST guidelines are applicable for anybody running a network that people are connecting into—and that bad people are trying to get into.
Compliance with the different PCI standards is enforced by penalties and the threat of not being allowed to connect to payment networks. Both of those are strong motivators for compliance. While encryption and its corresponding machine identities are treated very loosely in PCI, they are included and must be addressed. NIST publications—whether they be guidelines or specifications—are more of a game plan for how to do things well and, on the way, avoid penalties from regulations such as GDPR.
Learn how machine identity management helps you address NIST guidelines for TLS management. Contact us.
goes back 12 years or so to when I first started working with hardware security modules (HSMs). Some of the stuff that NIST addresses is quite high-level, almost abstract. There are different ways in which you can apply NIST recommendations to mean different things, to be less or more secure. Again, it's one of those things where they have come up with sensible suggestions, guidelines, good concepts, but they can't be too prescriptive.
What NIST doesn’t aim to do is define an architecture that every network must have, or every HSM must take. But they can say things like, "Well, you must know where your private keys are. You must be able to find out which private key gains you access to which systems. If you've got a private key, what things does it give you access to? Or if you've got something that you can gain access to, what private keys can gain access to it?"
But the best strategy is to avoid audit findings before they happen. Proactively evaluating your own environments for potential security issues that may trigger audit flags not only streamlines audits, it improves your overall security posture.
One large organization I’m working with has mandated a proactive evaluation of all controls through what effectively becomes an organization-wide compliance audit. So they are having to do essentially discovery and audit reporting for compliance to prove that they know about everything they’re doing with machine identities, and everything is compliant. In part, increasing chances of machine identity audit findings have motivated them to conduct their own internal audit as a preemptive strike.
We can help organizations scope their entire machine identity landscape, assess the overall (and individual) cryptographic strength, and continuously monitor the health and safety of all machine identities. Robust reporting also provides an audit trail in cases where that may be necessary.