A Security Operations Centre (SOC) and Security Information and Event Management (SIEM) platform can be incredibly powerful security capabilities if done right.

They can also become incredibly expensive mistakes.

I regularly hear stories of SOC analysts arriving for their morning shift to find hundreds of alerts waiting for them. The analysts then spend their day working through a queue of low-quality alerts, many of which turn out to be false positives or have little security value.

If this is happening consistently, something is systematically wrong.

The goal of a SOC isn’t to generate as many alerts as possible. It is to identify meaningful security events early, give analysts the information they need to investigate them, and enable the organisation to respond before an incident becomes a major problem.

Here are 13 practical tips for getting more out of your SOC and SIEM.

1. Tune your detections constantly

Detection maintenance shouldn’t be an occasional housekeeping exercise. It should be a constant SOC activity.

If analysts are repeatedly seeing the same false positive, tune it.

If a detection isn’t providing enough context to investigate an event, improve it.

If a detection hasn’t fired for months, ask whether that is because nothing has happened — or because the detection doesn’t work.

Every detection should be regularly questioned:

Is it generating useful alerts?
Can false positives be reduced?
Does it detect what we intended it to detect?
Is the data still available?
Has the underlying data schema changed?
Are there important scenarios that it doesn’t cover?
Can an analyst actually triage the resulting alert?

A detection is not something you create once and forget about. I once was brought in to review an Organisations SIEM and found only 2 of their 122 detections to actually be functioning as intended. None were creating errors so no one was aware that their SIEM was providing no value at all.

Detection engineering is maintenance.

2. Tune detections as close to the source as possible

If a detection or alert can be tuned at the source, do it there rather than unnecessarily pushing that tuning into the SIEM.

For example, if an EDR platform is generating alerts and the EDR allows you to suppress or refine certain activity, consider doing the tuning within the EDR.

There is a simple reason for this.

If you eventually replace your SIEM, you don’t want to discover that years of source-specific tuning has been embedded into hundreds of SIEM rules and now needs to be recreated from scratch.

The principle is:

Tune the data as close to its source as practical, and use the SIEM to correlate and detect across sources.

This also has the potential to reduce unnecessary ingestion and processing further down the pipeline.

3. Don’t try to make every detection perfect

One of the biggest traps in detection engineering is trying to create the perfect detection.

The first 20% of the work might produce a good, useful detection.

The remaining 80% can be spent trying to account for every possible variation, edge case and theoretical scenario.

The result is often a huge, complicated query that attempts to detect everything in a single rule.

Unfortunately, complexity can become the enemy of detection.

The more complicated the logic becomes, the harder it is for an analyst to understand why an alert fired. It can also become harder to maintain and easier to accidentally introduce gaps.

A simple detection that reliably identifies an important behaviour is often more valuable than an extremely complicated detection attempting to cover every possible scenario.

Start simple.

Improve it as you learn.

4. Don’t collect data you aren’t going to use

One of the first questions I ask when looking at a SIEM environment is:

“What detections use this data?”

If the answer is “none”, why are you collecting it?

There are legitimate reasons to retain data for investigation, compliance, threat hunting or forensic purposes. But continuously ingesting large volumes of security telemetry without a defined purpose can become expensive very quickly.

More importantly, it can create the illusion of coverage.

You can have terabytes of logs sitting in your SIEM and still have no detection capability for the threats represented by those logs.

Every important data source should have a purpose.

Ideally, you should be able to explain:

Data source → Detection use cases → Security outcomes

If you can’t, it is worth asking whether the data is providing sufficient value to justify its cost.

5. Test your detections by attacking yourself

Don’t assume your detections work because the SIEM says the rules are enabled.

Test them.

For example, in an appropriately authorised test environment, use a penetration-testing or adversary-emulation approach to perform behaviours such as credential theft or directory replication abuse and see what happens. But favour purple teaming over red teaming to understand what is happening and improve your detections.

A well-developed detection capability may generate multiple useful signals from a single attack chain.

If you perform an authorised test and absolutely nothing fires, that’s extremely valuable information.

You have just discovered that your assumptions about your detection capability were wrong.

Finding that out during a controlled test is far better than finding it out during a real incident.

Obviously, offensive testing should only be performed with appropriate authorisation, scope and safeguards. Once again start simple, if your detections dont detect simple tests then why are you attempting more complicated scenarios.

6. Every detection needs an SOP

A detection isn’t finished when the query works.

It is finished when the SOC analyst knows what to do when it fires.

Every detection should have an associated Standard Operating Procedure (SOP) or playbook explaining how the alert should be triaged.

At a minimum, this should cover:

What the detection is looking for
Why the activity is suspicious
What the analyst should check first
What additional data sources should be consulted
What constitutes a false positive
What evidence should be collected
When the alert should be escalated
What containment or response actions may be appropriate

Imagine creating an excellent detection and then giving it to a junior analyst with no explanation of what the alert means.

You haven’t created an operational capability.

You’ve created a query.

Detection + documentation = operational detection capability.

7. Keep detections simple

Not everything belongs in a SIEM detection.

A classic mistake is trying to detect something like SQL injection directly from a SQL database log.

The database is already processing SQL commands. SQL commands are expected there.

You will either end up with an enormous number of false positives or create such a narrow detection that it catches very little.

Instead, think about where the suspicious behaviour becomes observable.

For example, a web access log may contain indicators of someone attempting SQL injection against an application. SQL commands may be normal inside the database, but SQL injection attempts in HTTP requests may be highly unusual.

The question isn’t:

“Can I write a detection for this?”

The better question is:

“Where can I observe this behaviour in a way that distinguishes malicious activity from normal activity?”

8. Build detection use cases when you onboard data

When a new data source is onboarded, don’t simply connect it to the SIEM and wait for someone to figure out what to do with it.

Build detection use cases around it.

A useful approach is to start with:

Your organisation’s risk assessment
Known threats to the technology
Relevant attack techniques
The OWASP Top 10 where applicable
Your existing incident history
Threat scenarios identified by your security team

But again, keep it practical.

Don’t spend weeks developing an incredibly complicated detection for a scenario you cannot reliably observe.

If your detection doesnt fire when someone is running Burp Suite against your application at full throttle, then you have gone wrong along the way.

Understand what the data can actually tell you.

9. Prioritise detections on the left-hand side of MITRE ATT&CK

The MITRE ATT&CK framework is extremely useful for thinking about detection coverage.

But not all detections are equal from a defensive perspective.

Generally, you want to detect malicious activity as early in the attack chain as possible.

Detecting reconnaissance, initial access, execution, persistence, privilege escalation and lateral movement gives you opportunities to disrupt an attacker before they achieve their objective.

If your first useful detection occurs at exfiltration or impact, you’ve potentially waited until the horse has already bolted.

This doesn’t mean you shouldn’t detect exfiltration or impact.

You absolutely should.

But organisations should be wary of having a detection strategy heavily weighted towards the end of the attack lifecycle.

The objective is not simply to detect that an attack happened.

The objective is to detect it early enough to do something about it.

10. Don’t switch on every SIEM detection out of the box

One of the first things I see organisations do when deploying a SIEM is enabling large numbers of vendor-provided detections in the SIEMs ‘library’

This feels productive and looks good on a managers report.

But it always provides a bad outcome.

Every detection that is enabled should be tested.

Vendor detections are often written against expected schemas and data structures. Your environment may not have the same fields, data quality or configuration assumed by the detection.

Worse, some SIEM platforms won’t necessarily tell you that a detection references fields that don’t exist in your actual data.

The detection may simply never fire. You may need to ingest a feed for several months before being able to test if the data or schema in a library detection is correct.

That creates a particularly dangerous situation:

The dashboard says the detection is enabled, so everyone assumes there is coverage.

There isn’t.

Start with a smaller number of high-value detections. Validate them. Test them. Document them.

Then expand.

11. Don’t be afraid to throw it all away and start again

Sometimes the best thing you can do with a broken detection environment is to stop trying to fix it.

I’ve seen situations where organisations have accumulated years of detections, exclusions, exceptions, undocumented changes and abandoned rules.

Trying to repair everything individually can become an enormous project.

Sometimes it is better to step back and ask:

“If we were starting this SIEM today, what would we actually build?”

Starting again doesn’t necessarily mean deleting everything.

It means being prepared to challenge the assumption that every existing detection has value.

Keep what works.

Retire what doesn’t.

Rebuild the important things properly.

A clean, smaller detection library with known coverage can be considerably more valuable than hundreds of poorly understood rules.

12. Run regular purple-team tests

Never assume that your detections work.

Test them.

Purple teaming is particularly valuable because it brings the offensive and defensive sides together.

A test can answer questions such as:

Did the activity generate telemetry?
Did the telemetry reach the SIEM?
Did the detection process the telemetry correctly?
Did an alert fire?
Was the alert useful?
Did the analyst know what to do with it?
Was the attack detected early enough?

And here’s an important point:

A failed purple-team test is still a successful test.

If you expected an attack technique to generate an alert and it didn’t, you’ve just obtained an accurate picture of your current detection capability.

That’s valuable.

It gives you something concrete to fix.

The dangerous outcome is not a failed test.

The dangerous outcome is believing you have coverage when you don’t.

13. SOC analysts should own SOC detections

This is perhaps the most controversial point on the list.

Detections intended for SOC analysts to triage should be created with significant input from — and ideally ownership by — the SOC analysts who will actually use them.

Threat hunters and security engineers have an important role to play in detection engineering. They bring valuable technical and threat knowledge.

But there is a difference between:

“Can we detect this?”

and

“Can a SOC analyst effectively investigate this alert at 3:00am?”

and

“Will this detection create too many false positives for SOC analysts triaging them?”

and

“I can create a detection for a extremely unique threat hunting use case but are there far simpler detections which provide better value?”

The person building the detection needs to understand what happens after it fires.

Will the analyst know why it fired?

Is there enough context?

Can they determine whether it is malicious?

Can they investigate it within the expected time?

Does it contain the information required to make a decision?

If the answer is no, it isn’t a good SOC detection — regardless of how technically impressive the query is.

The SOC should have a strong voice in deciding what becomes an operational alert.

The real measure of a SOC

A SOC should not be judged by the number of detections it has.

Nor should it be judged by the number of alerts it generates.

The better questions are:

Can we detect the threats that matter to our organisation?

Can we detect them early enough to respond?

Can our analysts quickly determine whether an alert represents a real threat?

Do we regularly test that our assumptions are correct?

Do we know where our detection gaps are?

And perhaps most importantly:

Are we confident that the alerts reaching our analysts are worth their time and are we constantly improving?

A SIEM is ultimately just a platform.

You can spend millions collecting security telemetry, building dashboards and enabling thousands of detections and still have a poor security monitoring capability.

A smaller number of well-designed, well-tested and well-documented detections can provide far more value.

The objective isn’t more alerts.

The objective is better detection.