Most breaches are not stopped at the door. They are found, or missed, afterwards. The difference between an incident that is contained in hours and one that runs for months is rarely a single product. It is whether the organization can see what is happening, understand what it is looking at, and act on it quickly.
That capability rests on three decisions that are often made separately and sometimes by different teams: the SIEM that collects and analyses the data, the threat intelligence that gives alerts meaning, and the SOC operation that investigates and responds. Choose well and each multiplies the others. Choose badly and the weakest one caps what the whole system can achieve.
Why detection speed is the value
Time is the variable that connects detection to cost. The longer an attacker is inside, the more systems they reach, the more data they can take, and the harder it is to scope and recover. Industry research on breach costs, including IBM's annual study, has consistently found that breaches identified and contained faster cost materially less than those that run on.
Regulation reinforces the point. Under NIS2, in-scope entities must provide an early warning within 24 hours of becoming aware of a significant incident, and GDPR requires notification of a personal data breach to the supervisory authority within 72 hours where required. You cannot meet those clocks if you cannot tell quickly that something has happened and what it affects.
So the value of a good detection stack is not a feature list. It is shorter dwell time, a smaller blast radius, evidence you can rely on, and the ability to answer a regulator, an insurer or a board with facts.
Choosing the SIEM
A SIEM is only as good as the data it receives and the detections written on top of it. Product comparisons tend to focus on dashboards. The questions that decide outcomes are different.
- Coverage and onboarding effort. Which of your sources matter most (identity, endpoints, cloud, email, network, critical applications), and how hard is it to onboard each? A source that is difficult to ingest is a source you will not monitor.
- Detection content and flexibility. Does it ship with maintained detections mapped to MITRE ATT&CK, and can your team write, test and version its own? Detection that cannot adapt to your environment becomes noise.
- Cost model. Pricing by ingestion volume, events per second or workload shapes behaviour. If a model punishes logging, teams will quietly log less and create blind spots. Model your real volumes before you sign.
- Integration. Native connections to your EDR, identity provider, cloud platforms and ticketing, and the ability to automate response through a SOAR capability, decide how much work is manual.
- Retention, residency and compliance. Where is the data stored and processed, for how long, and under what terms? For EU organizations this is a GDPR and sometimes a sovereignty question.
- Operability. A powerful platform that your team cannot run is worse than a simpler one they can. Be honest about your skills, and about whether a cloud-native service or a self-managed one fits.
Commercial and open-source options, from cloud-native services to platforms such as Splunk, Microsoft Sentinel, Elastic and Wazuh, can all work well in the right context. The right choice follows from your data, skills and budget, not from a market ranking.
Choosing the threat intelligence
Threat intelligence is often bought as a feed and then forgotten. Its value comes from relevance and from being wired into how you detect and decide. It helps to separate the types:
- Strategic: who targets organizations like yours and why, for leadership and planning.
- Operational: campaigns and attacker behaviour, to guide detection and hunting.
- Tactical: tools, techniques and procedures, the basis for writing detections that survive an attacker changing their infrastructure.
- Technical: indicators such as addresses, domains and file hashes, useful but short-lived.
When evaluating a source, ask:
- Is it relevant to your sector, geography and technology stack, or is it generic?
- Is it timely, and does it carry confidence levels, context and provenance, or just a list of indicators?
- Can you act on it? Look for machine-readable formats such as STIX and TAXII and direct integration with your SIEM and EDR.
- What is the false-positive rate, and how are old indicators retired?
- Does it cover the sources you need? Government and national CERT channels, sector sharing groups such as ISACs, open resources such as MISP communities and the CISA Known Exploited Vulnerabilities catalogue are valuable and often free, and commercial providers add depth and speed.
More feeds are not better. A handful of relevant, well-integrated sources will outperform a pile of unfiltered lists that nobody has time to triage. Use intelligence to enrich alerts, to prioritize vulnerabilities that are being exploited, to design detections for the techniques your adversaries use, and to give hunters a hypothesis to test.
Choosing the SOC operation
The SOC is where data and intelligence become decisions. The key choice is the operating model, and the honest answer is rarely all or nothing.
- In-house. Maximum context and control, but 24/7 coverage needs a surprising number of people, and retention of skilled analysts is difficult.
- Managed detection and response or a managed SOC. Faster to stand up and covers out-of-hours, but depends on the provider's understanding of your business, clear service levels and a defined hand-off for response actions.
- Hybrid. A small internal team owns detection engineering, escalation and business context, while a partner provides round-the-clock monitoring and first-line triage. For many organizations this is the practical middle.
Whichever model you choose, check the things that determine results: documented playbooks, a clear escalation path to IT and the business, authority to take containment actions, a detection engineering process that tunes and tests rules, regular threat hunting, and rehearsed incident response. I cover the small-team case in Building a SOC with a two-person team, and the wider organizational side in A cyber breach triggers more than an IT response.
Why the three must fit together
Each component can be excellent and the whole can still fail, because the failures usually happen at the seams:
- A capable SIEM with poor log coverage detects only what it is shown.
- A premium intelligence subscription that is not integrated gives analysts one more portal and no faster decisions.
- A skilled SOC working on noisy data and thin context burns out and starts to ignore alerts.
- A managed service that cannot see your environment or act on your behalf can only forward alerts.
The test of a good design is the end-to-end path. An attacker technique that matters to you should be visible in the data, matched by a detection, enriched with relevant context, investigated by a trained analyst and answered with an action. If any link is missing, you have found your next priority.
How to decide
- Start from your threat model. List the attacker behaviours most likely to hurt you and the assets they would target. These become the use cases everything is judged against.
- Write requirements from those use cases, not from vendor brochures: data sources, detections, integrations, retention, response actions and service levels.
- Prove it on your own data. Run a proof of concept with your real logs and a few realistic scenarios, and measure what is detected and how fast.
- Cost the whole thing: licences, ingestion growth, engineering time, analyst time and managed service fees. Include the cost of switching later and how portable your detections and data are.
- Decide the success measures in advance, and review them after go-live.
What to measure afterwards
- Log-source coverage across your critical assets.
- Detection coverage against the ATT&CK techniques that matter to you, and how many of those detections have been tested.
- Mean time to detect, to acknowledge and to contain, and the dwell time of real incidents.
- Alert quality: false-positive rate, and the share of alerts that are investigated.
- Intelligence usefulness: how often it changed a decision or produced a detection.
- Results of purple-team exercises and incident drills.
Proactive security is not a promise that attacks will not get in. It is the ability to notice early, understand clearly and respond decisively. Selecting the right SIEM, the right intelligence and the right SOC operation, and making them work as one system, is what turns that ability into something you can measure and defend to a board.
If you would like help evaluating a SIEM, designing a threat intelligence approach, or choosing a SOC operating model, get in touch through the consultation form.