Battling the 'Assumed Breach' Model with Identity Security

In security, there is a saying that it’s best to ‘assume there has already been a breach’. This is an open-ended statement that makes assumptions about our understanding of information security. It should lead to a broader conversation but often doesn’t. This article aims to look at this statement through the lens of identity to reduce risk.

When we assume there is a breach, it means that we need to operate as if a malicious actor is already within our network. This challenges the way we have traditionally designed our networks, where there is a higher level of trust granted to traffic internal to the network versus external (e.g., internet-based traffic).

Here are some scenarios that come to mind that demonstrate “trusted traffic”:

• A website containing sensitive information is freely accessible for anyone on the internal network (either VPN or directly connected).

• Network shares allow unauthenticated access to read and share files.

• Weaker authentication (e.g., password-only) to apps where internet-based traffic would use multi-factor authentication.

• Staff devices connect directly to servers (e.g., RDP/SSH) from the internal network without going via any sort of proxy layer.

The idea behind an ‘assumed breach’ model effectively saves time when trying to identify the real risks within your network. With mechanisms such as phishing, credential theft, or having a malicious insider, it’s only a matter of time before a foothold is established inside your network, it’s an unfortunate reality.

Of course, we can add friction to these mechanisms to make them harder to exploit. We can improve phishing awareness and filtering, enforce stronger password complexity, and detect stolen credentials. However, these are largely human problems and they are almost impossible to solve completely. Humans are always the weakest link in a security strategy.

So what we do is assume that the thin outermost layer has been compromised already. Someone is on your network and there’s nothing you can do about it. But with some additional, more fortified layers, we can still have a strong security stance, regardless.

By skipping the initial penetration steps and dropping an ‘attacker’ inside your network, we can start focusing on more refined defense techniques. How do we prevent access to infrastructure, privilege escalation, lateral movement, and if an attacker locates sensitive data, how can we stop or limit that data from being exfiltrated out of your network?

Using MFA Differently

Using Multi-Factor Authentication in the enterprise is typically used for either external access or for high-risk applications. Using MFA sparingly prevents a torrent of abuse from end-users trying to get their work done. However, not all MFA is created equal. Authentication systems can be configured to trust device or browser sessions for longer periods of time. So you can mitigate the annoyance of pestering users for additional login factors by only asking for it periodically, with low-risk systems accepting an MFA token for several days or even weeks, whilst challenging for MFA frequently for high-risk apps.

Alternatively, consider the ‘second factor’ options available to you. We can use push notifications to mobile devices, code matching, FIDO tokens and various other techniques to improve the user experience for users. The use of passkeys could also play a role in strengthening the authentication process, however this technology is still new and hasn't yet achieved widespread adoption levels.

The Value of PAM

The use of Privileged Access Management (PAM) solutions goes a long way in defending against an assumed breach model. When users cannot use their corporate passwords to log in to servers or administrative panels, it protects against traditional phishing and credential stuffing campaigns because these credentials won’t work on infrastructure (e.g. SSH, RDP). Even if an attacker knows a Sysadmin’s personal account password, accessing PAM systems generally require MFA, and ‘checking out’ privileged accounts can require controls such as approvals, and a valid incident or change ticket to be presented.

The privileged account credentials managed by the PAM solution can also be rotated after each use, so if an administrator stores the checked out credentials somewhere, they provide no value in the future.

There’s a consideration around directory-style attacks in the assumed breach model. Using Active Directory as an authentication source for applications is a common practice. Can your system detect if I iterated through all the accounts in the directory, patiently testing small batches of known-weak passwords? Not enough attempts to lock users out, but enough to potentially get a few hits? Or what if I was going for a scorched earth approach and wanted to impact the entire organization? Could I purposefully lock out every account I could find?

These sorts of activities should be monitored so alerts can be triggered when this behavior is detected. Following this, proper security processes need to be implemented to ensure that actions are taken to neutralize threats. This means ensuring that teams take ownership of threats.

When adopting an assumed breach mentality to defend your identity landscape, we remove the blanket that firewalls have provided us in the past. Depending on the size of your organization, you may already have insider threats active in your environment. So it’s up to us to prevent unauthorized access, protect against escalation and lateral movement, and to be able to detect when systems (and end-user devices) are being attacked.

So next time you’re planning a solution, consider the scenario where a bad actor is already inside your network. Be mindful of easing the defenses just because traffic is assumed to be internal only. In a network of thousands of laptops, many connected from home, it only takes one compromised device to sneak in.