I had the great honor of presenting at a CIO/CISO summit yesterday; the topic I was assigned was “Protecting Privilege”, so of course I used the opportunity to present on something that I’m actually passionate about: zero trust. Along the way, I think I probably irritated a great many vendors in the room with my assertion that products have never single-handled solved a single security problem, but the presentation was so well received that I decided to convert it into a post. The focus was what are we doing about protecting privileged accounts, what is (and isn’t) working, and what we *should* be doing. I believe we are at an inflection point as an industry, and the collision of mobility, the consumerization/”appification” of how we work, and regulatory regimes are shifting the ground under our feet. We must stop doing things the way we have and think about an entirely different strategy.
First off, we all have known for a very long time that we must treat privileged IT accounts differently. We assign “admin” accounts to our IT people, to be used only for administrative tasks, and never for things like email or web browsing. We dictate a more stringent process for authorization, including things like more frequent cycling of passphrases, requiring multifactor authentication, and longer/stronger passphrases. We even monitor usage of those accounts. I think it’s pretty clear we get the concept of privilege as an industry…but are we applying the concept appropriately to effectively manage risk for our companies?
Think about it this way: when was the last time you had administrative credentials get stolen? Don’t get me wrong, they are definitely a sought-after prize. And if you have implemented a Privileged Access Management platform, that is an excellent idea and serves to further automate, track, and standardize the use of traditional privileged accounts (both those tied to individuals, and those that serve as privileged service accounts). But we have raised the bar enough that attackers typically go after easier targets. And it turns out that those targets are also more lucrative. I’m speaking, of course, about Layer 8 of the OSI model: the carbon layer. Social engineering can get around almost any protective technology you can deploy.
The Verizon Data Breach Investigative Report for 2018 cites that Phishing and Credential Theft as the #1 and #3 vectors in the top 20 of compromises (#2 is PoS RAM scrapers). Depressingly, this is exactly the same if you look over the past few years of reports. We have not, as an industry, effectively extended our understanding of privilege past privileged IT resources. There are a few reasons for this; one, I think, is that IT Security teams too often are not well integrated into their businesses to understand *business* risk past the ends of their own noses. To wit: wouldn’t having the comptroller’s email compromised and used to authorize illicit wire transfers make for a pretty bad day for your company?
OK, so we enlarge our definition of “privilege” to cover VIPs such as Legal, HR, Finance, top executives, etc. You implement controls to monitor and strengthen authentication for those individuals. That’s better, for sure, and many organizations do this already. But then someone not in that group gets compromised, and the attackers pivot and escalate privileges and we are off to the races again. Examples abound of businesses that were brought down by non-privileged compromise, or even third-party vendors—almost entirely outside of your realm of control—used as attack vectors to compromise your network.
No, the concept of privilege, while important in certain cases, does not get us where we want to be. You don’t need a privileged account compromised to do great damage to your business, which means from a risk-based approach, you should be protecting *all* your accounts. Multi-factor authentication helps a lot here, but it is not a silver bullet either; no business is going to make its general user base provide a second factor every single time they perform a task. Productivity would be massively impacted, users would reach for their torches and pitchforks, and security would once again be an obstacle to business. We have to do better than this.
It turns out, we can. Think for a moment about how your network is constructed, how your employees work, and how data flows in and out of your organization. Think also about what happens when a person authenticates. What does it mean to you, and to your organization, when a person successfully authenticates? Authentication is a claim that a person is who they say they are, typically without the presence of another person who can confirm their identity; the person provides evidence to support their claim, such as a password (something they know), a token (something they have), or even biometrics (something they are). No surprises here. But for most of our organizations, at that point, that person has full access to all the resources they are entitled to. And herein lies the problem.
How many of you have true road warriors, individuals who are not connected to your WAN or LAN in any sense for weeks at a time? With the ubiquity of SaaS, we have enabled our users to access productivity applications from anywhere, from any device, at any time. They don’t have to VPN into our networks much at all anymore, for most applications at least. When they do, it is a jarring experience, markedly clunky in comparison to just opening a mail client or a cloud storage app and instantly getting what is needed. So these folks are on the road, operating often in very hostile environments. When they do plug back in (either physically, wirelessly, or via VPN), they are often carrying with them some malware. Your SIEM barks and your incident response team goes into triage and contain mode. You have a compromised endpoint on your network, and it has full access to whatever that user account has access to, simply because that person actually was who they claimed to be.
It is a common realization that the perimeter of our networks is no longer a thing that exists. With the increase in mobility and the ubiquity of access to data via *aaS models, we have to start thinking about “perimeters” around where data actually is. It follows our users. Our users have each become microperimeters. The idea of grouping assets and wrapping protecting controls around them to manage risk is right out the window; we actually increase our risk with that approach, for the examples mentioned above, and for many other reasons.
WE ARE DOING IT WRONG, and we aren’t thinking broadly enough about effective risk management.
The concept of zero trust turns the prevailing model of perimeter-based risk management on its head. It recognizes that just being who you claim to be isn’t enough to grant unfettered access to resources. It inserts an incredibly important concept into our notion of authorized entitlements: context.
I’ll be adding another post soon about zero trust, the importance of context, what this model means, and how we can start to move towards it. For now, I'll say this about context: Sometimes, goats are in trees, and that's ok. Figuring out when it is ok is the real trick.
