You Should Feel ‘Positively’ About Your Security Tools: How We’re Mitigating False Positives in Identity Security

While we’d all love to get to a place where “Why are security tools so necessary” is the top search result, security tools are undeniably noisy. Whether you’re calling it a problem with your signal-to-noise ratio or suffering from alert fatigue, a massive problem with modern security tools is the issue of false positives: detecting a harmless or beneficial activity as a threat. While technically less risky than a false negative (not detecting a malicious threat when it happens), false positives overburden security teams and add to their already heavy workflows, disrupt access needed to maintain employee productivity, and result in costs for your organization when they lead to the dismissal of a genuinely critical alert.

In the Orca Security 2022 Cloud Security Alert Fatigue Report, over half of the surveyed IT professionals spent more than 20% of their time deciding which alerts should be dealt with first. “The overload of alerts, combined with widespread inaccuracy (43% say more than 40% of their alerts are false positives), is not only contributing to turnover but also to missed critical alerts: more than half of respondents (55%) say their team missed critical alerts in the past, due to ineffective alert prioritization – often on a weekly and even daily basis.”

How do we mitigate false positives?

To illustrate one approach to addressing false positives, we’ll use the example of Crosswire’s ITDR (Identity Threat Detection and Response) tool. Through identity security context, like relying on related logs and profile attributes, we can enrich our threat detection rules and mitigate false positives.

For example, rules are aligned with the MITRE ATT&CK framework, a leading knowledge base of common tactics, techniques, and procedures used by cyber adversaries, ensuring that our system remains proactive and responsive (ex., Active Directory Credential Request, Web Credential Usage, Remote Service Session Hijacking, etc.).

To further enhance our detection capabilities, we leverage machine learning algorithms to filter out false positives and assist in the creation of detection rules. This allows us to simulate the “common sense” of a security analyst and supplement entry-level security analyst triaging.

Threats also change over time, and what was once an indicator of compromise quickly becomes innocuous (and vice versa). We are in the business of understanding the ever-changing security landscape and changing our alerts to fit that new landscape, acting as a trusted security advisor both through AI adaptations and changes to our written rules that parallel changes in attacker behavior trends.

This is also where something like company-specific context, such as how a specific company’s users behave, will come into play. To illustrate this point with a simple example, while an engineer accessing Salesforce at almost any company could be cause for suspicion and alert, this wouldn’t be the case for an engineer working at Salesforce itself, reducing a false positive alert (in addition to other contextual configuration based on your org’s security posture/staffing levels).

What happens if there is a false positive?

While Crosswire’s ITDR tool—and any tool created with the problem of false positives in mind—will substantially reduce false positives, there’s no (secure) way to eliminate them entirely; they’re a part of the process. Instead of ignoring that reality, Crosswire has instituted gradual remediation to reduce grand fallout from false positives when they happen to minimal inconvenience.

The key philosophy that Crosswire’s ITDR product follows is that the severity of the remediation should match the severity of the alert. For instance, Okta impossible travel is super noisy, and it could be an indicator of compromise or just user activity (like a VPN or actual travel). Instead of immediately instituting an intrusive (deactivate account) or costly (send an alert to a SOC) measure, Crosswire will instead sync with their HR work location and/or send a notification to ask the user to confirm the new location or additional verification before intrusive measures are taken.

To illustrate, consider an example related to the MITRE Active Directory Credential Request framework where a user requests new active directory credentials, such as a ticket or token. While another pure anomaly detection tool might flag this unilaterally as a compromise, our system takes into account contextual factors. For instance, contextual alerting would flag this as high priority (like revoking the user session) if this is then followed by anomalous Kerberos activity or indications of Pass the Ticket being used to move laterally, but lower priority (like an additional MFA push) for an account that has just switched projects or positions and now needs access to different Active Directory resources.

By tailoring our response to the severity and nature of the alert, we strike a balance between addressing false positives and maintaining a smooth user experience while safeguarding critical systems and data. The bottom line is that you need to be able to trust your security tools, and false positives harm that trust by making users feel as though their tools are only searching for random, insignificant signals because they’re the easiest to find.

To stay up to date with Crosswire and hear more about what we’re doing to make security tools you can trust, contact us for a demo here and subscribe to our blog below!