How confirmed attacker signals change SOC operations for MSSPs

Active Campaign Detected Across the Sensor Fleet

Published:

25 September 2024

By:

Xavier Bellekens

Summary

Managed security service providers carry the same detection problems as any SOC, multiplied across every client they look after. Analysts spend much of their day working through alerts that turn out to be harmless, while the threats that matter take longer to find.

This post looks at how signals based on confirmed attacker behaviour change that picture. When an alert only fires because an attacker has interacted with a sensor, the SOC has far less noise to work through and far more context on each incident.

The challenges MSSPs face

The challenges MSSPs describe to us have changed little in recent years, although the pressure behind them has grown. The ones we hear most often are:

  • Alert volume. Endpoints, networks, cloud services and applications produce more data than any team can review by hand.
  • False positives. Harmless activity is flagged as a threat, and each alert still has to be investigated before it can be closed.
  • Skills shortage. Demand for experienced analysts is higher than supply, so existing teams absorb the extra work.
  • A wider attack surface. Remote working, cloud services and connected devices give attackers more places to start.
  • Slow detection. Many controls only respond once a breach is under way, which gives an attacker time to move and to steal data.
  • Client reporting. Clients expect clear evidence of what was found and what was done about it.

Most of these share a root cause in the way traditional detection works. Rules and signatures try to predict what an attack will look like, and those predictions produce many alerts with little certainty behind them.

How confirmed attacker signals work

Lupovis takes a different starting point, which is to record what attackers do. Our global network of more than 1,000 sensors captures over 150 million attacker signals every day across cloud, network and edge environments. Inside a client environment, internal sensors sit alongside production systems and have no legitimate business use.

Lupovis sensor network figures showing more than 1,000 sensors and over 150 million attacker signals a day
Source: Lupovis

Because no member of staff or service has a reason to touch an internal sensor, any interaction with one is a confirmed event worth investigating. That one property changes several parts of SOC work.

Four step diagram showing how an interaction with an internal sensor becomes a confirmed alert in the SOC

What changes in the SOC

Detection

An alert is only raised when an attacker interacts with a sensor, so there is no backlog of false positives and no detection rules to maintain. Analysts can treat each alert as a real incident from the first minute.

Context

Each interaction records what the attacker did, including the techniques, tools and infrastructure involved. The analyst receives that context with the alert, which shortens triage and gives the incident response team a clear starting point.

Timing

Sensors are often touched during reconnaissance and lateral movement, which is earlier than most controls would raise an alarm. The SOC gains time to contain the activity before it reaches production systems.

Threat intelligence

Signals from the wider sensor network show which vulnerabilities and techniques attackers are using across the internet at that moment. An MSSP can use this to prioritise patching advice and to tune controls for each client's sector.

Comparison of rule based detection and confirmed attacker signals across five areas
Source: Lupovis

Why it matters for MSSPs

For an MSSP, the benefit shows up in the measures clients judge the service on. Fewer false positives mean analysts close genuine incidents faster, and earlier detection reduces the damage an attacker can do. Reports to clients can also point to confirmed attacker activity, which is easier to explain than a count of alerts reviewed.

The same change eases the staffing problem, because a team that is no longer buried in low value alerts has time for threat hunting and for improving each client's defences. That lets an MSSP take on more clients without growing the team at the same rate.

How to get started

MSSPs that want to test this approach can start small by deploying internal sensors for one client. Comparing the alerts they raise with the existing alert queue over a month will show the difference in volume and quality.

Lupovis works alongside existing SIEM, SOAR and ticketing tools, so confirmed alerts arrive in the workflow analysts already use. Coverage can be external, internal or both, and it can be self managed or fully managed by Lupovis. MSSPs including Orange Cyberdefense already use Lupovis as part of their service.

References

  • Lupovis SOC Efficiency use case
  • Lupovis Threat Hunting use case
  • Lupovis research: The internet changes shape before the advisory

Explore our other blogs