Why an identity-centric approach to Tools Rationalization is the place to start

It’s no surprise that attacks targeting end users aren’t slowing down. According to the 2024 Verizon DBIR, a staggering 68% of all breaches involve the notorious human element, which was roughly the same as 2023. On the contrary, less than 1% of cyber exposures stem from CVEs according to new research by Cyentia institute. Since humans continue to be the weakest link, it’s time we prioritize preventative controls to best address the way in which they (the users) are being attacked.

At Reach, we’ve identified that almost all identity-centric attacks delivered to an organization’s workforce are preventable using the tooling in place. Examples of attacks that target the end user include:

• URL-based Phishing (corporate and consumer)
• Ransomware
• Malware (executable attachments)
• Business email compromise
• Keyloggers

Gartner predicts that by 2025, half of all cyber incidents will occur because of a “lack of talent” or human error. Organizations assume they are covered when it comes to protecting their knowledge workers, but oftentimes there are cracks.

Limiting the blast radius is feasible. It’s a big data problem, often involving big data readily available to security operators.

To address identity-centric attacks it’s important to start with both:

1. An inventory of the minority of the workforce that represents a majority of the overall risk
2. The ways in which your products that have some concept of an identity - typically Email Security, Network Security, Endpoint Detection and Response (EDR), and Identity and Access Management (IAM) products – can interoperate as a cohesive unit

This two-pronged approach enables organizations to achieve defense in depth while pinpointing where risk hotspots live.

Before we dive into it, we want to make an important distinction. We’re not here to tell you we can identify the “8% of the population that accounts for 80% of the risk”, even though we do. We’re here to tell you that we’ll tailor your security estate to best protect these users and ensure the best defenses possible are in place for them at any given moment in time.

Part 1: Establishing a backbone to inform “where” and “how”

To start, some products claim to “fight AI employee risk” by identifying risk hotspots and giving you a list. We’re again here to tell you (scream to you) that simply identifying employee risk hotspots is not enough! It is, however, an important first step. There are important considerations to weigh when it comes to normalizing these data points, as the accuracy becomes incredibly important once we get to tailoring security. For example:

• Are mailing lists collapsed to individual identities? (Hint: you can’t deploy an EDR rule to a shared mailbox)
• Are ex-employees from stale AD records still showing up?
• Are proxy addresses, whose identity your email security provider doesn’t understand, taking up more weight than real users?

Understanding where risk lives within the workforce continuously is an imperative first step.

Part 2: Determining the optimal set of configuration combinations based on your risk profile

Security product forensics reveal how to leverage your licensed capabilities. These data points can then be overlayed with what you have deployed, what it’s capable of, and how you’re using it.

For instance, if a phishing campaign uses URLs that bypass DNS security checks and redirect users to a web page hosted on a public IP address, forensics from your email security product can identify:

• Where within the workforce these URLs were delivered
• Which users clicked the URLs
• The attributes of the phishing page

This data helps create a "most phished" group, focusing on high-risk areas.

Part 3: Mapping and deploying available controls from the holistic security estate to combat identity-centric attack chains

Layer in compensating controls from your Network, EDR, and IAM products to address identity-centric attack chains.

To start, we’ll utilize your Endpoint product’s browser capabilities to create a custom rule that both:

1. Alerts you when a user browses to a public IP address (and bypasses DNS checks)
2. Alerts you when a user submits credentials on a suspected phishing page hosted on a public IP address

We'll then conduct a similar exercise on the firewall, creating and implementing custom App IDs to apply content filtering (blocking, in this case) when users browse to a public IP address.

To ensure a layered defense in the event of credential compromise, we'll then add compensating controls using your IAM product to limit the blast radius if the attack is carried out successfully. We'll want to ensure all contextual and risk-based authentication attributes are layered into sign-on policies as the likelihood of anomalous login (e.g. logins originating from non-sanctioned cloud providers, new regions, risk levels assigned by vendor) are high. Examples below utilize capabilities you may be paying for in Okta's Adaptive MFA and SSO modules.

From start to finish, this is clearly a staggering amount of work to do manually, which is why Reach exists.

Layering defenses from an identity-centric point of view

You may hear terms like "tools rationalization" or "maximizing tool effectiveness," but their meanings can vary. Are you following a vendor best practice checklist, mapping CVEs to specific configurations, or tracking workforce risk and ensuring your licensed capabilities address this risk? Whichever path you choose, understanding the value of each approach is crucial.

More About Reach Security

Reach is the first AI purpose-built to reprogram your security infrastructure based on who you are and how you're being attacked. Organizations of all sizes trust Reach to make mission-critical decisions because it doesn't hallucinate and it doesn't make mistakes. It's a different kind of AI. To learn more, visit reach.security/try-reach.