Modern DFIR practices and processes bring a whole slew of systems, data sources, and types of expertise to bear in seeking to detect, address, and understand security incidents.
Filesystems, network traffic, activity, and extensive logging all play into the game, but at the end of the day, detection often remains more an art than a science, and the task of detection tends to remain an indirect one.
That is to say that analysts and teams must still generally infer what's happening using data that indirectly reveals that an incident has occurred and that may, with a great deal of work, imply what the impact of the incident was.
Direct Incident Data
All of this would go much more smoothly if there was a data source that could simply, directly, and authoritatively say:
There was a breach
At a specific time
Using specific account(s)
Even better if this data source could add details like:
Here is what was done interactively during that time
Here are the time(s) at which illicit activity started and stopped on each account
Assembling these things by cross-referencing multiple indirect data sources can be an infuriating process, and more to the point, it tends to happen after the fact—sometimes long after the fact.
Yes, there are solutions designed to ingest this data and surface potentially important anomalies sooner than that, but in practice we know that on average, unauthorized users tend to have access for weeks to months (sometimes even years) before a compromise is detected.
So let's add another criterion. The industry is also in need of a solution that does all of the things we just outlined above:
In real time, as the action is happening
For many organizations—particularly those whose core business isn't cybersecurity itself—a solution able to meet these requirements would be a massive security enabler.
Credential Compromise Detection
So, spoiler alert—we offer this solution at Plurilock.
True, we often speak of our technology and products in terms of authentication, but in fact a product that does continuous authentication with real-time logging is at the same time a powerful DFIR tool for rapid credential compromise detection and response.
Let's look at the technology and how it enables everything we've just talked about:
It uses behavioral biometrics
In other words, fingerprint-unique patterns in typing and pointer activity
To either confirm or reject the identity of a real person
As they attempt to use the credentials belonging to that person
In real time
When our ADAPT login product honors a login, it authenticates not just a username and password, but also the match between them and the person trying to use them. When it rejects a login attempt because the person didn’t match the credentials, it is effectively logging that these credentials have been compromised—perhaps by phishing, perhaps by other forms of credential theft.
Similarly, our DEFEND continuous authentication product confirms, moment by moment, that an active user is in fact the expected person—that the body at the console matches the credentials in use. But if at any point the expected person gives way to someone else, DEFEND proceeds to log the fact that the account is now compromised—being used by a stranger—for as long as such use continues.
ADAPT and DEFEND don't infer that an incident may have occurred; they know.
Most forms of detection fail to spot intruders because they’re looking for anomalous activity or contexts. Using Plurilock for authentication and credential compromise detection, incidents can be flagged immediately even when activity and contexts are not clearly anomalous.
Authentication vs. Detection
All of this is interesting because the best practices that we've all been hearing about for some time now—Zero Trust, Continuous Adaptive Risk and Trust Assessment (CARTA), and so on—are complicated by the fact that the first, most fundamental part of the trust equation often goes unanswered:
"Is this the wrong person for these credentials?"
Authentication is intended to address this question, but of course most of the kinds of credentials in use today can in principle be shared or used by anyone. We rely on the owner of the credentials to "protect" them from others' prying eyes, something that has proven to be nearly impossible in practice.
So users are first "authenticated" by being asked to provide a username, a password, and an OTP or hard token. Then, security teams proceed to try to "untrust" them after the fact by wading through fields full of haystacks in search of a telltale needle.
Behavioral-biometric technology resolves this messy disconnect by doing the obvious—merging authentication and detection using biometric data that's nearly impossible to steal or to reuse.
"Does the person at the console actually own this valid set of credentials? If so, they're authenticated. If not, an intrusion—and a compromised set of credentials—have been detected!"
Continuous and Enriched Data
Even better, because behavioral biometrics operates continuously in real time, behind whatever work the user is doing, this signal can reflect time frames, and be correlated with ongoing activity.
Not just an immediate signal that "these credentials are compromised," but also "they remain in use by a stranger right now, and here is what they are interactively doing."
Revisit the log data after the fact and you have "these credentials were in use by a stranger from 11:31 am through 11:52 am, on this particular console, and during this period they carried out the following interactive tasks…"
Pair the technology with a SIEM and the result is the kind of DFIR acceleration that results in near-real-time response and understanding—of a kind that brings initiatives like Zero Trust and CARTA much closer to reality.
Rethinking Traditional Models
All of this is why we tend to tell our customers to begin to think outside the box when it comes to Plurilock and their security stack.
Yes, Plurilock products provide invisible MFA at login and continuous authentication all day long during work sessions, all using behavioral biometrics.
But behavioral-biometric authentication also provides a real-time signal—with deep data enrichment and risk assessment potential—when a compromise occurs. ■