For the last three years I’ve been dedicated to solving authentication problems. Mainly for large groups of external consumers who log into banking, retail, or social media accounts and services, and mostly using mobile multifactor authentication or device-based fingerprinting. Always, though, I’ve kept an eye on the balance between strong security and outstanding user experience. And never in a system relying on user names and passwords.
Why no user names and passwords? Because of the “mountain problem.” There has been a veritable mountain of user names and passwords that has been stolen in the last 5 years and is now available for sale on the dark web. With something like 4 billion records exfiltrated through the exploits we’ve heard so much about in the last few years – Equifax, Anthem, Yahoo, Twitter to name a few – it’s almost a guarantee that a user name and password for one of my confidential accounts is available for sale on the dark web. Or, at the very least, that the personal information that allows someone to spoof some knowledge-based authentication process and generate a new username and password pair is available.
"the mountain grows every day"
This mountain of confidential information grows every day, and spurs advances in biometric authentication, MFA, risk-based authentication and real-time authorization. It’s important and necessary work.
But for the last few weeks I’ve been looking at this problem from a different perspective. As Venafi’s new director of product marketing, I’m looking at not just the visible, growing attack surface of the mountain, but what’s beneath it.
It’s no longer the mountain problem I’m worried about. It’s the iceberg problem.
The Iceberg Problem
Imagine that all those stolen credentials and records are the tip of an “identity iceberg”, or what we can see with our own eyes from the deck of the ship. The top side is built on human identities and it’s getting taller and taller with each breach. We can see it growing every time we dip into “Password Paradise” or our favorite TOR-directed online credential shop and read the ads for “account takeover made easy”.
Now imagine Poseidon wades into view and grabs that iceberg and lifts it (with two hands as it clears the water, because it’s so heavy now) and flips it over so you can see what the underside looks like. This is the machine identities side of the iceberg. And this new attack surface is three or four times bigger than what we can see above the water line, but obfuscated and often hidden and always hard to control. Poseidon can hardly lift it now because the underside is so immense.
We know all about human identity issues. The cybersecurity market spends over $8 billion a year on ways to enable authentication and access for human identities. But beneath this are the machine-to-machine connections that make everything run, either in corporate networks or across the internet at large. What we have is a long and complex chain of machine communications: servers talk to other servers that talk to gateways; databases talk to applications and IoT sensors and edge devices; load balancers talk to everything and try to keep the whole orchestrated mess running.
Trends towards virtualization and containerization compound the problem. Research firm Securosis wrote on the exponential growth in critical machine identities in a recent report titled “Understanding and Selecting a Secrets Management Platform”:
Virtual Machines: Servers, Containers, Instances
is especially problematic where ‘machines’ are not something sitting in a rack at a co-location facility, but instead an ephemeral instance of a machine — or perhaps thousands of instances running simultaneously, potentially being created and destroyed by the dozen due to the transitory vagaries of demand. How can we track which server, virtual machine, or container is which, or what set of permissions to provide each? And the scope of the problem broadens as we extend automation and orchestration across teams. Development teams need to share data, configurations, and access keys across and between teams to cooperate on application development and testing.
Automated build servers need access to source code control, API gateways, and user roles to accomplish their tasks. Servers need access to encrypted disks, applications need to access databases, and containers must be provisioned with privileges as they start up. Automated services cannot wait around for users to type in passwords or provide credentials! So we need new agile and automated techniques to provision data, identity, and access rights.”
These machine-to-machine authentications are handled by a handful of known and trusted technologies:
- Digital certificates based on SSL and TLS protocols that authenticate and encrypt connections between end users and sites, services or applications
- SSH protocols that exchange secure keys (or exchange machine passwords that generate keys) to secure privileged access by administrators
- Code signing certificates that bind program code to digital keys to ensure integrity
(If this is all new to you and you’d like a primer, download the free e-book Machine Identity Protection for Dummies. I did.)
The “iceberg problem” is not that there aren’t trusted, reliable methods to secure these connections, or that these methods that are being improved year by year. It’s the sheer volume of connections.
More Machine Identities than Human Identities
In 2015, there were about the same number of connected devices as there were people, about 8 billion of each. By 2020 the number of devices is forecast to more than double to 20 billion, while the number of people (and therefore “top-of-the-iceberg” identities) only grows by about 10%.
At the same time, applications that also require these trusted connections will double as well – from almost 50 billion in 2015 to over a 100 billion in 2020.
The bottom of the iceberg (the part that sunk the Titanic, mind you) is getting much larger much faster than the part of the iceberg we can see above the waterline. And if those connections are compromised, it’s not one or two accounts that are affected, but potentially all accounts.
How to Manage All Machine Identities
So these connections need to be assessed by trusted protocols and methods. We need management and oversight of the nearly invisible, hard-to-examine underside of the iceberg in order to avoid potentially catastrophic errors.
- Is the certificate valid and active, or expired?
- Is the certificate a clever forgery?
- Is it configured for proper encryption?
- Does it use weak or deprecated signing algorithms?
- Does it have the right organizational information and provenance?
- Can we account for all our certificates, or are there rogue and unknown certificates connecting critical systems?
- If we had to replace them (read Comodo certificate hack – it gets worse) could we find them?
That’s the kind of assurance Venafi provides
This is an exciting new world for me. It’s similar to the work I did in human identities and authentication, but the problem is embedded in our digital lives and growing exponentially larger every day. There’s a huge opportunity here to make life safer and better for everyone by solving it.