Your corporate network is like a pandora’s box with a lot of goodies on the inside… stuff that any self-respecting hacker (um, business person) would be happy to exploit and monetize.
So the question is, what options do you have to stop or thwart progress as that attacker tries to gain access, sneak around and slowly but surely gain ground on your crown jewels? On the theme of “resilience” and focusing on privileged access security, what are some of the ways your infrastructure can be more flexible, adaptable and resistant to attacks?
Redefining “Attack Surface”
I like to think of this problem in terms of “attack surface.” In my mind, that’s kind of like the total set of doors you leave exposed, ajar or wide open. Doors that an attacker can compromise to get access to important data or as an intermediate hop to another server en-route to that bounty.
HOWEVER — I want to challenge the popular interpretation, which is to take the word “surface” literally. If you google “attack surface” and “security,” you’ll find a bunch of blogs, products and articles that don’t really get it. They take “surface” to mean perimeter, with the figurative doors on the outside, on the boundary. Where people log in. So they focus exclusively on authentication, how to prevent attackers from getting privileged account passwords and logging in illegitimately. Their solution? A password vault.
While there’s certainly a lot of breach activity at this surface level, there’s a lot more going on below the surface… after login. Our attack surface is in fact way bigger and deeper.
Vaulting Should Be a (smaller) Part of Your Security Focus and Investment
OK, so what does this mean in the context of privileged access security? Focusing purely on vaulting passwords used to log in means we miss a big (way bigger, in fact) part of the picture. We focus on what’s obvious and, frankly, what’s easy to solve. We fixate on the external threat: those visible surface doors that can be breached if an attacker gets the password to the superuser account (“root” or “administrator”). We postulate that admins, being human and fallible, can’t be trusted with these passwords anymore. So, we decide to vault them away and only hand them out if legitimately needed. Since the admins no longer know the password, that attack vector is gone. Right? Most organizations rely on this method for 90% of privileged access scenarios.
What this is NOT doing for us, though, is reducing the broader attack surface… below the surface… on the inside. What’s overlooked is consolidating identities, true least-privilege access, along with a healthy wrapper of multi-factor authentication (MFA).
Begin with identity consolidation — by minimizing the number of privileged accounts being shared. Most organizations can actually disable or delete up to 90% of these accounts. Your attack surface is then dramatically reduced vs. keeping them enabled and vaulted (read: available to exploit). But it’s not just malicious bad guys. Many customers I talk to also complain that their admins camp out all day logged in with full privilege. While not malicious, there are many, many “mistakes” that have resulted in very expensive consequences.
Do some napkin math and guesstimate what that might mean for you. One Centrify customer disabled 97 privileged accounts out of 129, across 43 servers — a 75% reduction. Even “root” was a candidate. Forrester Inc. advised that 80% of breaches involved privileged credentials. Operating systems including Ubuntu and Mac OS are shipping with the root account disabled by default. Red Hat and CentOS include documentation on how to disable root. AWS automatically creates “ec2-user” admin accounts on most *NIX instances with no password for “root.” Microsoft Technet recommends disabling the BUILTIN/administrator account.
Back to the napkin. If like our example customer, you could disable 75% of privileged accounts then it’s not unreasonable to speculate Forrester’s number reducing to around 20%. Very significant indeed.
So, after you have reduced your organization’s risk of being breached by reducing the number of privileged accounts — yes, you should absolutely vault the remainder; those account passwords that strictly can’t be disabled. Emergency access only, with password checkout going through an audited request/approval workflow process and subsequent access strictly time-bound for the minimum time necessary to complete the task at hand.
So, how are admins supposed to do their job? Frankly, a lot more securely by using least-privilege access!
We have all admins login with a unique, personal account that has only the necessary privileges to do their jobs (vs. “root,” “administrator,” “oracle,” “sa,” etc.). When they legitimately need extra privilege to perform a task, pre-assigned roles enable admins to elevate their privileges. In this model, instead of the entire login session running with full privileges, we only allow individual processes to be elevated, thus decreasing your attack surface and exposure to exploits.
To further reduce the attack surface, we can include a request/approval workflow to request access to said roles. For even more, a second factor can be requested when logging in or as a step-up if already logged in…
Even with all this, there are still risks. Introducing MFA for BOTH login and privilege elevation (where appropriate, ideally based on context) brings additional levels of assurance that the user is who they claim to be.
Summary of Benefits
The reasons our customers implement this best-practice approach are multi-faceted. Certainly, it’s more secure to disable the majority of privileged accounts and for admins to be in a least-privilege state the majority of the time. Centrify’s elevation method is very analogous to how admins use “sudo” to elevate, so it’s not something new to learn; there’s no productivity impact. Also, with the huge growth in breaches and liability, I find administrators are actually more content to not use a privileged account 24×7 and to have all their activities forensically audited/recorded so they can better account for their actions when something goes wrong. Finally, from an auditing and compliance perspective, this model ensures full accountability. I.e., Tony logs in as “tony” and all his “dzdo” (Linux/Unix) or “Run With Privilege” (Windows) elevation activities are logged (and optionally recorded) as “tony” vs. anonymously.
Building resilience in infrastructure requires a combination of approaches. A vault serves a legitimate purpose in helping to prevent a cyberattack, however, its impact on reducing the attack surface is minimal on its own. It must be combined with identity consolidation, least-privilege access control, MFA and access request/approval. This combination will give you the best-practice means to mitigate risk, shrink that attack surface, and protect your corporate assets from cyberattack.
Learn how to reduce the risk of data breaches here.