An identity security breach is one of the most serious attack types that an organization faces today, and sadly also some of the most common, with 84% of organizations having noted that they experienced an identity-related breach in the past two years. If a bad actor is able to gain control of a trusted identity, they can more easily move laterally and vertically throughout the organization until they reach their desired targets and can then exfiltrate data, hold computers for ransom, or other such undesirable actions. Making matters worse, is that in past IDSA research, 99% of organizations thought that identity-related breaches could have been prevented with strong access control.
Until the day comes that every organization has completely tightened up their identity and access management (IAM) programs to secure every identity throughout the organization, there will be a need to have a plan in place to deal with the inevitability of an identity security breach. Here are a few steps that organizations can take to prepare themselves for the day if, or when, they are faced with an identity that has been breached.
Step One: Establish a Plan in Case of Identity Security Breach
Of course, as with anything, the first step is to establish a plan by gathering stakeholders to determine the risks involved with identity security breaches. The plan should establish what tools are needed to alert the Security Operations Center (SOC) or security and risk management leaders that something is amiss. Typically, an event alerting system like a SIEM, UEBA, threat analytics tool, or some combination of these are needed for comprehensive alerts to be sent when something anomalous has occurred, like an identity accessing something they normally don’t, or at a strange time, or coming from a foreign IP address. Once the proper tools have been established to safeguard and identify these types of anomalies, determining a process for what happens once an alert has been triggered and how to do so quickly (ideally automatically) is needed. Then, the team involved should establish what actions need to be taken once an alert has been sent, processed, and a breach of an identity is confirmed. This should include taking the network or affected systems offline, planning for a ransomware negotiation, or other steps that administrators need to take once a breach is suspected.
Step Two: Evaluate the Identity Security Breach Alert and Determine Required Actions
On the practical side, when a security practitioner receives an alert of a potential breach, they then need to evaluate the alert and determine if action is required. If it is clear that something is awry, access for that identity should be swiftly and automatically revoked until the situation is under control, to prevent lateral movement by this identity. This action, however, cannot be taken lightly, as any time access is revoked for a user, productivity is inherently lost and lead to slower business operations. If a threat is verifiable, disabling all user accounts that belong to the compromised identity is a good step to ensure that the identity is not able to make their way into any additional systems. If done automatically, the disabling of access removes the need for a manager to grant permission, which can further slow down the process if someone is needed to manually intervene when an identity security breach is detected. Risk scores can also be used to determine when this process is automated, for instance, if a domain admin has been potentially breached, the process will need to be very quick and likely automated, but for an identity that has less far-reaching access, it could be done manually. If assigning risk scores to certain systems or identities, these decisions can be automatically routed according to policy.
Step Three: Deal with the bad actors and certify if there are unneeded permissions or access
After access has been revoked, the security team should get to work to establish what went wrong, and deal with the attacker to make sure that only authorized users remain in the network. After the attacker is dealt with, unwinding the lockout for the identity and resuming business operations is top of mind. Enabling prior access to the target systems for the now-secured identity should be a priority, however, it likely behooves an organization to certify if there are unneeded permissions or access that this identity has that can be removed without affecting future productivity. It is also critical to log all actions that were taken, both from the breached identity, and the remediation efforts, as auditors, will certainly be interested to see what went wrong, why, and how it was dealt with.
Staying vigilant against bad actors is a never-ending fight for security leaders, and the sad truth is that most organizations will face a situation where trusted identities are leveraged by bad actors to gain access to things they should not. When that time comes, having a plan in place to govern this access and ensure that there are swift actions to take, can have a massive impact in the overall damage of a breach. For more information, check out Omada IdentityPROCESS+: Identity Security Breach Management, to learn about how Omada helps customers to implement processes for dealing with identity breaches in real time.
