Security Information and Event Management (SIEM) is feeling
its age. Harkening back to a time in which businesses were prepping for the
dreaded Y2K and where the cutting edge of security technology was bound to
DMZ’s, Bastion Hosts, and network vulnerability scanning – SIEM has been along
for the ride as both defenses and attacker have advanced over the intervening
years. Nowadays though it feels less of a ride with SIEM, and more like towing
an anchor.
Despite the deepening trench gauged by the SIEM anchor
slowing down threat response, most organizations persist in throwing more money
and resources at it. I’m not sure whether it’s because of a sunk cost fallacy or the lack
of a viable technological alternative, but they continue to diligently trudge
on with their SIEM – complaining with every step. I’ve yet to encounter an
organization that feels like their SIEM is anywhere close to scratching their
security itch.
The SIEM of Today
The SIEM of today hasn’t changed much over the last couple
of decades with its foundation being the real-time collection and normalization
of events from a broad scope of security event log sources and threat alerting
tools. The primary objective of which was to manage and overcome the cacophony
of alerts generated by the hundreds, thousands, or millions of sensors and logging
devices scattered throughout an enterprise network – automatically generating
higher fidelity alerts using a variety of analytical approaches – and
displaying a more manageable volume of information via dashboards and reports.
As the variety and scope of devices providing alerts and
logs continues to increase (often exponentially) consolidated SIEM reporting
has had to focus upon statistical analytics and trend displays to keep pace
with the streaming data – increasingly focused on the overall health of the
enterprise, rather than threat detection and event risk classification.
Whilst the collection of alerts and logs are conducted in
real-time, the ability to aggregate disparate intelligence and alerts to
identify attacks and breaches has fallen to offline historical analysis via
searches and queries – giving birth to the Threat Hunter occupation in recent
years.
Along the way, SIEM has become the beating heart of Security
Operations Centers (SOC) – particularly over the last decade – and it is often
difficult for organizations to disambiguate SIEM from SOC. Not unlike Frankenstein’s
monster, additional capabilities have been grafted to today’s operationalized
SIEM’s; advanced forensics and threat hunting capabilities now dovetail in to
SIEM’s event archive databases, a new generation of automation and
orchestration tools have instantiated playbooks that process aggregated logs,
and ticketing systems track responder’s efforts to resolve and mitigate
threats.
SIEM Weakness
There is however a fundamental weakness in SIEM and it has
become increasingly apparent over the last half-decade as more advanced threat
detection tools and methodologies have evolved; facilitated by the widespread
adoption of machine learning (ML) technologies and machine intelligence (MI).
Legacy threat detection systems such as firewalls, intrusion
detection systems (IDS), network anomaly detection systems, anti-virus agents,
network vulnerability scanners, etc. have traditionally had a high propensity
towards false positive and false negative detections. Compounding this, for
many decades (and still a large cause for concern today) these technologies
have been sold and marketed on their ability to alert in volume – i.e. an IDS
that can identify and alert upon 10,000 malicious activities is too often
positioned as “better” than one that only alerts upon 8,000 (regardless of
alert fidelity). Alert aggregation and normalization is of course the bread and
butter of SIEM.
In response, a newer generation of vendors have brought
forth new detection products that improve and replace most legacy alerting
technologies – focused upon not only finally resolving the false positive and
false negative alert problem, but to move beyond alerting and into mitigation –
using ML and MI to facilitate behavioral analytics, big data analytics, deep
learning, expert system recognition, and automated response orchestration.
The growing problem is that these new threat detection and
mitigation products don’t output alerts compatible with traditional SIEM
processing architectures. Instead, they provide output such as evidence
packages, logs of what was done to automatically mitigate or remediate a
detected threat, and talk in terms of statistical risk probabilities and
confidence values – having resolved a threat to a much higher fidelity than a
SIEM could. In turn, “integration” with SIEM is difficult and all too often
meaningless for these more advanced technologies.
A compounding failure with the new ML/MI powered threat
detection and mitigation technologies lies with the fact that they are
optimized for solving a particular class of threats – for example, insider
threats, host-based malicious software, web application attacks, etc. – and
have optimized their management and reporting facilities for that category.
Without a strong SIEM integration hook there is no single pane of glass for SOC
management; rather a half-dozen panes of glass, each with their own unique scoring
equations and operational nuances.
Next Generation SIEM
If traditional SIEM has failed and is becoming more of a
bugbear than ever, and the latest generation of ML and MI-based threat
detection and mitigation systems aren’t on a trajectory to coalesce by
themselves into a manageable enterprise suite (let alone a single pane of glass),
what does the next generation (i.e. NextGen) SIEM look like?
Looking forward, next generation SIEM isn’t SIEM, it’s an
evolution of SOC – or, to license a more proscriptive turn of phrase,
“SOC-in-a-box” (and inevitably “Cloud SOC”).
The NextGen SIEM lies in the natural evolution of today’s
best hybrid-SOC solutions. The Frankenstein add-ins and bolt-ons that have
extended the life of SIEM for a decade are the very fabric of what must ascend
and replace it.
For the NextGen SIEM, SOC-in-a-box, Cloud SOC, or whatever buzzword
the professional marketers eventually pronounce – to be successful, the core
tenets of operation will necessarily include:
- Real-time threat detection, classification, escalation, and response. Alerts, log entries, threat intelligence, device telemetry, and indicators of compromise (IOC), will be treated as evidence for ML-based classification engines that automatically categorize and label their discoveries, and optimize responses to both threats and system misconfigurations in real-time.
- Automation is the beating heart of SOC-in-a-box. With no signs of data volumes falling, networks becoming less congested, or attackers slackening off, automation is the key to scaling to the businesses needs. Every aspect of SOC must be designed to be fully autonomous, self-learning, and elastic.
- The vocabulary of security will move from “alerted” to “responded”. Alerts are merely one form of telemetry that, when combined with overlapping sources of evidence, lay the foundation for action. Businesses need to know which threats have been automatically responded to, and which are awaiting a remedy or response.
- The tier-one human analyst role ceases to exist, and playbooks will be self-generated. The process of removing false positives and gathering cohobating evidence for true positive alerts can be done much more efficiently and reliably using MI. In turn, threat responses by tier-two or tier-three analysts will be learned by the system – automatically constructing and improving playbooks with each repeated response.
- Threats will be represented and managed in terms of business risk. As alerts become events, “criticality” will be influenced by age, duration, and threat level, and will sit adjacent to “confidence” scores that take in to account the reliability of sources. Device auto-classification and responder monitoring will provide the framework for determining the relative value of business assets, and consequently the foundation for risk-based prioritization and management.
- Threat hunting will transition to evidence review and preservation. Threat hunting grew from the failures of SIEM to correctly and automatically identify threats in real-time. The methodologies and analysis playbooks used by threat hunters will simply be part of what the MI-based system incorporates in real-time. Threat hunting experts will in-turn focus on preservation of evidence in cases where attribution and prosecution become probable or desirable.
- Hybrid networks become native. The business network – whether it exists in the cloud, on premise, at the edge, or in the hands of employees and customers – must be monitored, managed, and have threats responded to as a single entity. Hybrid networks are the norm and attackers will continue to test and evolve hybrid attacks to leverage any mitigation omission.
Luckily, the NextGen SIEM is closer than we think. As SOC
operations have increasingly adopted the cloud to leverage elastic compute and
storage capabilities, hard-learned lessons in automation and system reliability
from the growing DevOps movement have further defined the blueprint for
SOC-in-a-box. Meanwhile, the current generation of ML-based and MI-defined
threat detection products, combined with rapid evolution of intelligence
graphing platforms, have helped prove most of the remaining building blocks.
These are not wholly additions to SIEM, and SIEM isn’t the
skeleton of what will replace it.
The NextGen SIEM starts with the encapsulation of the best
and most advanced SOC capabilities of today, incorporates its own behavioral
and threat detection capabilities, and dynamically learns to defend the
organization – finally reporting on what it has successfully resolved or
mitigated.
-- Gunter Ollmann
No comments:
Post a Comment