The Basics
- Identity providers, which are services that manage and verify a person or system’s credentials to confirm they are who they claim to be, now control access to most of today’s businesses or organizations, making each single login a high-value target.
- True identity defense today requires seven independent layers that if individually compromised don’t compromise another layer, or failure of the whole.
- The seven layers Identity Defense-in-Depth comprises are credentials, access decisions, privilege, sessions, application accounts, external trust, and detection.
- This article will teach you how to evaluate your organization’s identity controls, test what happens when one fails, and implement practical fixes (none of which include buying more security products).
______________________________________________________________________________________________
Why A Firewall is no Longer Enough
The firewall used to be the main boundary between the internet and the business or organization using it. Users, applications, and data were inside the user’s network, and most outside access had to pass through a small number of controlled entry points.
That’s not how most organizations operate today.
Now, employees work from anywhere, vendors connect directly to cloud applications, and automated systems exchange information without ever touching the corporate network.
The firewall still matters, but it is no longer the control making most decisions about which people and devices are allowed access.
That role has shifted to the identity provider.
What is an Identity Provider?
An identity provider is a service that acts as a kind of gatekeeper. It manages and verifies a person or system’s credentials like usernames, passwords, or other authentication details to ensure that only the right people or devices can access certain systems, apps, or data.
While an identity provider streamlines access by managing and verifying credentials, it also serves as a critical point of vulnerability: One approved login can provide access to email, financial systems, customer data, cloud infrastructure, and sensitive files. That means that if an attacker takes over that login or steals the approved session, the activity may look legitimate even while the attacker is sending fraudulent messages, accessing data, or changing the environment.
Although the landscape has shifted, this does not make network, endpoint, or application security less important. It simply means those controls can no longer rely on the network boundary, i.e., the firewall, to establish trust. In modern environments, access decisions are frequently based on a combination of identity, device, application, session, and risk information gathered from multiple systems. As a result, being “inside” the corporate network is no longer sufficient to establish trust, nor is being “outside” necessarily grounds for denial of access.
Each of those controls needs to work under the assumption that something around it has already gone wrong. For instance, the password may already be known. The device may not be trustworthy. A vendor or connected application may already be compromised. The next layer still needs to block the request, limit what the account can reach, flag the activity, or give the response team a way to shut it down.
Adversary-in-the-middle Attacks
Complicating matters of access for organizations today is the reality that attackers do not always need to break in. One common method threat actors use: They place a fake service between the user and the real sign-in page. The user sees the normal login screen, enters a password, and approves MFA. The attacker relays the entire process to the real service and captures the session after the service approves the login . This is commonly called an adversary-in-the-middle attack.
An adversary-in-the-middle attack doesn’t require the attacker to exploit the firewall or install malware. They simply log in with a session the identity provider had already approved. From there, they may read email and files, send messages from a trusted account, create forwarding rules, add another authentication method, or approve an application that keeps access even after the password is changed. This is why a password reset by itself may not contain an identity compromise. If the attacker has already established persistence through active sessions, additional authentication methods, mailbox rules, or application consent, they may retain access even after the password has been changed.
Identity Defense-in-Depth: Seven Layers, With no Single Point of Failure
Defense-in-Depth is a proactive cybersecurity strategy that uses multiple independent and overlapping layers of protection so that a failure in one or more layers doesn’t compromise the whole. Individual layers do not necessarily stop an attacker in a clean sequence. In most incidents, one or more of them may fail, but the remaining layers can still contain the damage.
The seven core layers — and best practices — of a Defense-in-Depth strategy include:
- Credentials: Assume the password is known. Use phishing-resistant authentication, protect password and MFA recovery, remove older sign-in methods, and stop sharing accounts. A password should not be enough to get into the business.
- Access decisions: Assume the login is valid. A correct password and an approved MFA prompt should not automatically open every application. Device health, location, user risk, and the sensitivity of the system should still affect the decision.
- Privilege: Assume a regular user account is compromised. Administrative access should be separate from day-to-day work, granted only when needed, and removed when the work is done. One compromised account should not provide control over the entire environment.
- Sessions: Assume MFA has already succeeded. Authentication happens once, but access may continue for hours or days. Sessions need to be reevaluated when risk changes, and the security team needs a reliable way to end them quickly.
- Application and automated accounts: Assume a secret has leaked. Applications, scripts, and automated processes often have significant access without a person signing in. Every account should have an owner, a documented purpose, limited permissions, credentials that expire or rotate, and a plan for removal when it is no longer needed.
- External trust: Assume the connected organization or application is compromised. Vendors, guests, and connected applications extend access beyond the systems the organization directly controls. Those connections need an owner, a defined scope, a review date, and a tested way to remove access.
- Detection and response: Assume the preventive controls missed it. Monitoring needs to cover more than failed logins. New authentication methods, application approvals, administrative rights, forwarding rules, and changes to trusted connections can all show that an attacker is already inside. The response plan needs to end active sessions, remove the attacker’s changes, preserve the evidence, and confirm that access is gone.
How to Begin Implementing Defense-in-Depth in Your Organization
Identity problems do not stay inside IT, so start with the systems that matter most. A compromised account can affect payments, customer communications, regulated data, operations, and the organization’s ability to recover. Pick a business system the organization cannot afford to lose or misuse, then work through the following three questions with the business owner or organization leadership and technical lead:
- What can the account reach? Include systems, data, business processes, other accounts, and any financial authority tied to it.
- What still works if one control fails? Identify the control that would block the request, reduce the account’s access, generate an alert, or end the session.
- When was that tested? Document what happened, who owns any gap, and when it will be fixed.
Be wary of responses like “MFA is enabled” or “We have ‘a policy’” Responses like these don’t answer the critical three questions above. Your organization should know how long it takes to recognize a compromised account, shut down its sessions across connected systems, remove any access the attacker added, and confirm that the account is clean. And that process must be assessed with the people who own the system; not left in a document that has never been used.
Once foundational defense-in-depth controls are in place, a few key metrics will show whether security is improving: how many privileged users have phishing-resistant authentication, how many permanent administrator accounts remain, how long it takes to end all access for a compromised user, how many application accounts have an owner and expiration date, and whether vendor, guest, application, and privileged access reviews are being completed. These measures will prove to be far more useful than a count of security products.
Your Takeaway: Identity Defense is Bigger Than One Product
Buying another firewall or identity product will only burn cash and, worse yet, may not even fix the inherent issue. Your organization needs clear ownership, limited access, controls that do not all fail together, and a response process that has been evaluated.
Treat each login as an access decision, keep administrative access temporary, make sure sessions can be ended quickly, and review the outside organizations and applications that are trusted to connect.
Rehmann can help identify the identity paths that create the most risk, test the controls around them, and build a practical plan to close the gaps. Contact us here.