Saryu Nayyar | Forbes.com »
While many stand-alone security tools deliver some kind of threat assessment, whether in the form of color codes or numerical value, they often don’t provide any context. This can lead to confusion as SecOps (security operations) personnel try to piece together what is happening from a series of unrelated data points. A unified risk score, on the other hand, delivers context and avoids this sort of confusion. Let’s take a look at what’s needed to achieve and integrate risk scoring within a security program.
In a typical organization, the security stack includes numerous data sources, such as firewalls, access controls, endpoint protection, antivirus and anti-malware systems and email protection. It can even include physical card access and point of sale systems.
Aggregating data feeds from these various sources in a centralized data lake is the first step toward implementing risk scoring. By bringing all the information together in one place where it can be normalized, correlated and contextualized, the analysis becomes much more effective and efficient.
Next, several elements must be used to derive a risk score.
The first is access, which is a fundamental part of risk scoring. This entails who users or entities are, where they log in from and when, who they interact with both as people and as resources, their peer groups, and what permissions and privileges they have. Entities can be people or systems and sometimes even assets.
The second element is behavior, which covers what users and entities are doing and why and how it compares to their peers. An example might be a user from the HR department reaching out to look at assets in the engineering department’s project shares. It might be benign, but it’s an outlier that potentially raises the risk score of both the user and asset in question. How much it raises the risk score would depend on multiple factors, including whether the HR user has done this before or if there has been a recent flurry of communication between engineering and HR, possibly prompted by an investigation.
Users and entities are the next element. These are basically servers, workstations, laptops and any other network-connected devices, all of which exhibit some characteristic behaviors that can be used to identify them. For example, what roles they serve, what entitlements they have and what access is granted to them are all identifiable characteristics. How they interact with other entities and systems on a daily basis provides the baseline to pinpoint anomalous behavior.
Meanwhile, other resources (databases, individual files, records, etc.) get their own risk profiles. These, in turn, are tied to the risk scores of users and entities. Any of these elements could influence the overall risk score. Ultimately, an asset at risk can be as important as a user engaging in risky behavior. This is what makes risk the priority for analysts to see first, so they can investigate the events that led to that elevated score.
Once a risk-scoring infrastructure is in place, it can provide the intelligence needed to support incident detection and response, forensics, and threat hunting.
For example, risk scores can flow organically into a security orchestration automation and response (SOAR) platform. The SOAR system can leverage contextual risk assessments for each entity and asset, rather than event-level inputs. Advanced automation provided by SOAR is central to improving the efficiency and effectiveness of the SecOps teams. By letting the SOAR system handle routine functions, security analysts can focus their attention on threats that require human investigation.
Risk scoring also provides a valuable advantage for forensic investigations, giving analysts a reliable starting point for digging into the details of what happened. The events associated with a risk score identify which machines need to be torn down and what analysts should be looking for as they clear the environment. While there’s still plenty of manual investigation to be performed beyond the intelligence provided by risk scores, they give analysts a big head start.
Finally, for threat hunters who are charged with discovering latent threats lurking in the environment, risk scores again provide a valuable starting point. For example, after a user is identified as high-risk, an investigation discovers a malware infection. Once SecOps remediates the problem, threat hunters know the source of the incident and how to root out its possible spread to other assets.
It’s clear that risk scoring enriches threat detection and prevention, incident response and forensics through automation. It can also be effective when used as a starting point for forensics and threat hunting. That’s why organizations should invert the current approach of using security events for front-line monitoring and instead prioritize their defense on unified risk scores.