Identity threats (i.e., the use of compromised credentials for malicious access to targeted resources) have become the dominant element of today’s threat landscape. Moreover, these are the threats that organizations find the hardest to protect against, with lateral movement and ransomware spread causing widespread damage on a seemingly daily basis. Yet, within most organizations there is in fact a gap in terms of who is actually accountable to prevent these attacks. And this gap is one the fundamental reasons that organizations struggle to gain the upper hand against identity threats.
In this post, we’ll discuss this gap by examining a sample use case, with the purpose of prompting all cybersecurity professionals to reflect on how present this gap is in their organization and how it can be resolved.
Identity Teams are Not Accountable for Preventing Cyberattacks
Meet Jack. Jack is an Identity and Access Management (IAM) engineer at his company. Part of Jack’s role is to implement multifactor authenticaton (MFA) protection on his users’ access. Being a consummate professional, Jack evaluates, purchases, and deploys an MFA solution on all of his company’s SaaS and web apps, well as for remote VPN access to the on-prem environment and Remote Desktop Protocol (RDP) access within it.
But because MFA for RDP entails installing an agent on each server in the environment, the decision is made not to deploy this on a specific group of older servers that support several business-critical apps. The concern here is that the additional load of the MFA agents will crash these servers, leading to unacceptable downtime. So the project is considered successful given these considerations.
Security Teams are Not Accountable for Evaluating and Deploying Identity Protection Products
Now meet Jill, who is a Security Operations Center (SOC) manager on her company’s security team. Her KPI is to prevent, detect, and respond to cyberattacks. Jill is aware that ransomware attacks which spread across the enterprise environment are a critical threat. Adversaries accomplish this spread by using compromised user credentials to log in to as many machines as possible. To prevent this, Jill’s team invests significant effort in responding to alerts and proactively hunt for anomalous user access that could indicate such a spread is taking place.
However, neither Jill nor anyone from her team have been involved in the evaluation, testing, and rollout of the MFA solution that is now in place across their enterprise’s environment. Because her focus is squarely on cyberattacks, her only reaction is being happy to hear that the MFA project was successfully completed.
The Result: Cyberattacks That Include Identity Threats Encounter Little Defense
One day ransomware hits. The adversaries realize the organization’s app servers are the best target to hold hostage. To gain control of these servers and encrypt the data on them, they attempt to log in via RDP using a compromised user’s credentials. And since there’s no MFA on these servers, the attempt is successful. Now the adversaries are in full control and can impose their ransomware demands on the organization.
Let’s leave our story and reflect on what happened here.
Lessons Learned: When No One Owns The Risk, The Risk Owns You
So what made this breach possible, despite there being dedicated and talented identity and security teams in place? The answer is in how Jack and Jill perceive the role they’ve been assigned in their organization.
For his part, Jack was not tasked with preventing ransomware spread but rather with deploying an MFA solution. From his perspective, the servers without MFA protection weren’t seen as a security risk but instead as a missing percentage in the project’s overall MFA coverage rate. And a coverage rate of 90% is significantly better than the previous rate of 0%. Best efforts were made and, while results weren’t perfect, they were definitely good enough.
Jill, on the other hand, had no part whatsoever in the MFA project. Unlike a SIEM or an EDR, MFA is not considered a security product but rather a focus of the identity team. Had Jill been involved in the MFA discussions, she might have discovered that the app servers were exposed and pushed to upgrade them so that the MFA project would not be considered complete before these servers were fully protected.
So is Jack to blame for the breach? Not really, because this was never part of his responsibility. Does that mean Jill is to blame for the partial MFA coverage? Not really, because MFA has never been part of her jurisdiction.
And this is exactly the accountability gap we’re talking about.
Could an Accountability Gap Exist in Your Environment?
This story is a good example of the state of identity protection today. How this accountability gap developed and why it is found only within identity protection (unlike endpoint or network protection) is worth a separate discussion. What’s more important is for you to ask if a similar scenario could take place in your environment.
Here are some key questions to ask yourself:
Is your SecOps teams involved in implementing identity protection controls such as MFA and PAM?
Does your CISO have a say in the design and implementation of the IAM infrastructure?
Does your identity team realize that the solutions they evaluate and deploy are actually the last line of defense against attacks that could put the entire organizations at risk?
And the most important question: Is there a single stakeholder in your organization who has both the accountability to prevent identity threats as well as the authority and knowledge to determine the security measures that should be put in place to achieve this? This is not to say that identity protection will be complete after resolving the accountability gap. Certainly, there are other challenges to overcome before getting there. But it is an essential first step to take in order to make this protection possible. Ultimately, whether the accountable person comes from the identity side or the security teams doesn’t matter. As long as there is a clear owner in your organization, the initial milestone of getting the upper hand over identity threats will be accomplished.
The post Mind the Gap! Who’s Accountable to Protect Against Identity Threats in your Organization? appeared first on Silverfort.
*** This is a Security Bloggers Network syndicated blog from Blog – Silverfort authored by Yiftach Keshet. Read the original post at: https://www.silverfort.com/blog/mind-the-gap-whos-accountable-to-protect-against-identity-threats-in-your-organization/