IAM professionals and infosec leaders often use analyst planning guides as a blueprint for both investment and implementation. However, this has proved to be a challenge for machine identity architects because there was no resource for them to consult. Until now. This year’s Gartner 2021 Planning Guide for Identity and Access Management highlights some previously existing trends, but also introduces whole new categories of risk that require strategic planning.
In particular, I’d like to explore a whole new focus area that has surfaced:
“Keys, Secrets, Things, Agents, Containers Will Drive Broader IAM Scope”
Basically, this focus breaks down into two distinct and fundamentally different needs. You’ve got to “Treat non-human entities as first-class citizens.” But, in the process you also have to “Manage keys, secrets for machine identities.”
This new consideration is, in part, a recognition that the IAM security landscape has permanently shifted. Machine identities, in the form of TLS certificates, SSH keys, API keys, code signing certificates and JSON tokens and more now vastly outnumber the human identities on our networks. With mesh architectures and micro-segmentation, hundreds or thousands of dynamic machine identities now replace single, monolithic objects and their more static, long-term identities.
To break this new concept down into useful, implementable chunks, I’d like to give you my perspective on the high-level 7-step checklist that Gartner provides for practitioners to study and for managers to begin planning their budgets around.
CIO Study: Outages Escalating with Massive Growth in Machine Identities
1. Define types of machine identities
It’s almost a certainty that your organization is using SSL/TLS certificates to secure web sites and services. Probably many more than you think. On average, a new Venafi customer discovers over 57,000 keys and certificates they didn’t know they had, according to independent research company TechValidate.
But that’s only one type of identity. Do your system admins use SSH keys to provide access to back-end systems? How about your developers? Are API keys being used, or endpoint certificates for people and small devices? Are code-signing certificates leading to unseen, unaccounted for, and possible unsecured key sprawl?
2. Define high-level policies for machine identities
Once you know what kind of keys you’re using, you need to create a policy for them. In fact, the US National Institute for Standards and Technology (NIST) introduced a new special publication last year that went into a deep dive on what a TLS policy should contain: Which certificate authorities (CAs) are allowed to issue for your organization? How long should certs last? What are the secure configurations for each certificate, and how is it tracked to organizational structure, purpose and risk? Get a summary of NIST 1800-16, “Securing Web Transactions: TLS Server Certificate Management” here.
But that’s just for your SSL/TLS certificates. Does your policy for SSHH keys allow port forwarding? Does it establish a need for source control? And so on, the myriad types of machine identity your organization relies on.
3. Define target architectures for machine identities
If you’re like most organizations in a world experiencing rapid transformation, you’ve likely got a plethora of different computing environments. You’ve still got traditional infrastructure, but you’ve also got private cloud, public cloud, hybrid, containers and more.
This requirement asks for a precise inventory of the environments machine identities will be working in, along with an outlook for the emerging architectures of the future. Is the organization pursuing mesh architectures? If so, will there be requirements for many:many mTLS (mutual TLS) connections?
4. Evaluate existing technologies that manage machine identities, keys, secrets and certificates
For the last ten years the need for more and more certificates and keys has driven many companies to develop their own home-grown solutions for key and certificate management. These worked fine, given the scales of the early 2000s. But now machine identities are exploding in number, and doing so exponentially, year over year.
If it takes a person two hours to issues and install a certificate, these automated systems might be able to do it in 30 minutes. This sounds acceptable, and in many cases even reasonable … until the number of machine identities quadruples, and then quadruples again, in the same year.
5. Do a gap analysis
You know what you have, and you know what you need. Do the detailed gap analysis that lays out—objectively and even harshly—how your machine identity management capabilities differ from those defined by Gartner and other analysts.
6. Define new solutions and best practices
This is a call to get away from “set and forget” PKI. Organizations need to rethink and reimagine what solutions will look like in the very near future. Will you need to inject certificates into CI/CD pipelines automatically, using defined API calls? Will you need to audit against on-prem, cloud , and remote machine identity configurations?
Start with a resource like Venafi’s Machine Identity Management Blueprint to get you started on this cross-functional project.
7. Lay out, and spend time communicating, a roadmap
How are you going to get there? In all likelihood the distance between where you are today (as defined by your own analysis) and where you need to be (as defined by any number of the assets linked to this post). Then, how are you going to get there? Through what milestones? Through what gates and with what kind of collaboration between team?
The IAM landscape is changing. For practitioners and strategists alike, one of the largest, fastest and most tectonic of these changes is the arrival of the Machine Identity Management category – at scale and with high a need for surprisingly high assurance. It’s time to get started.
Get a 30 Day Free Trial of TLS Protect Cloud, Automated Certificate Management.
Related posts