A SOC in six months, and how not to build an expensive dashboard

Organisations across Pakistan have been told to have operational security operations centres inside six months. It is a reasonable instruction. The national CERT has reported a rising volume of incidents, and a country cannot defend what nobody is watching.

It is also the kind of instruction that produces a great deal of waste, because six months is long enough to spend a budget and short enough to skip the thinking. The predictable outcome is a room with screens in it, a tool that ingests everything, and an alert queue nobody works because it produces four hundred items a day and always has.

That is not a SOC. It is a very expensive way of finding out about a breach at the same time you would have found out anyway.

What a SOC actually is

A SOC is not a room, a tool or a headcount. It is a promise that something unusual will be noticed and acted on within a defined time, by somebody whose job that is.

Everything else follows from that promise. If nobody is looking between six in the evening and nine in the morning, you do not have twenty four hour monitoring no matter what the procurement document says. If alerts are generated and never triaged, you do not have detection. If a real detection has no defined response, you have a notification service.

Test any proposed design against the promise. Most fail on the first question.

The order of work that survives a deadline

Under time pressure the temptation is to run everything in parallel. Resist it, because the dependencies are real and working out of order wastes the most time.

Know what you are defending. You cannot write a detection for a system you do not know exists, and you cannot prioritise an alert about an asset with no owner. This is the same inventory problem that sits underneath every control framework, including PISF, which is convenient, because the work counts twice.

Get the right logs, not all the logs. The instinct is to collect everything and decide later. It is the most expensive mistake available, because volume drives licensing, licensing drives the budget, and the budget then has nothing left for the people who make any of it useful.

Start with identity, because almost every intrusion touches authentication. Then endpoint, because that is where execution happens. Then your perimeter and your externally facing services. Then cloud control plane activity, which is where a quiet attacker does the damage that matters. That order covers the overwhelming majority of real intrusion paths, and you can add breadth later once you know what you are missing.

Write a small number of detections that map to real behaviour. A handful of good detections beats a thousand imported rules. Map them to MITRE ATT&CK so you can say which techniques you cover and, more usefully, which you do not.

Define the response before you need it. For each detection, somebody should be able to say what happens when it fires, who does it, and what authority they have at three in the morning. A detection without a response is a source of stress rather than safety.

Then buy the tooling. Doing this last feels wrong and is correct. By this point you know your data volume, your retention need and your use cases, which means you are specifying a purchase rather than being sold one.

If you cannot name the person who will act on an alert at three in the morning, you have not built a SOC. You have built a dashboard.

The staffing problem nobody wants to say out loud

Twenty four hour coverage with your own staff needs something in the region of eight to twelve analysts once you account for shifts, leave, training and attrition. For most organisations outside the largest banks and telecoms, that is not affordable, and pretending otherwise produces a rota that burns out its people in a year.

There are honest alternatives. Run extended hours rather than claiming continuous cover, and be truthful in your documentation about when you are watching. Share a capability across a group. Use a managed provider for the overnight window and keep the investigation and decision making in house, which keeps context where it belongs.

What does not work is a nominal twenty four hour SOC staffed by three people who are also doing other jobs. That design fails quietly, and it fails at the exact moment it is needed, because the incident will start on a Thursday night.

What to measure

Ignore alert counts. A high alert volume is usually evidence of a tuning problem.

Watch how long it takes to notice something, how long from noticing to containing it, what proportion of alerts turn out to be real, and how much of your environment is actually feeding in. That last number is the one that quietly decays as new systems get built and nobody adds them to the pipeline.

Run the numbers monthly and show them to somebody outside the team, because a measure only reported internally tends to become optimistic.

Prove it works before you say it works

A SOC that has never been tested is a hypothesis.

The cheapest test is a tabletop exercise, which will find your process gaps in ninety minutes. The more useful test is a purple team engagement, where somebody executes known techniques in your environment and you find out honestly which of them you saw. Nearly everyone discovers that coverage they believed in was not there, and it is far better to discover that on a Tuesday by arrangement.

Our VAPT and red team practice runs those exercises with the detection team in the room rather than against them, which is the version that improves anything.

Where we fit

We design and stand up security operations capability through SOC design and monitoring, including the unglamorous parts, which are log source prioritisation, detection engineering and the response runbooks that decide whether an alert becomes an action. SOC Command covers the operating side for organisations who want the capability without building the rota themselves.

Threat Intelligence Mapper exists because most threat reporting arrives as narrative and a SOC needs it as a check. It ends its output at the one detection worth validating this week rather than at a warning.

And because the monitoring obligation now sits inside the national framework, the evidence matters as much as the capability. CyberNexus holds that side, so the fact that your detection coverage was reviewed, and by whom, survives the person who reviewed it.

Start here

Pick your five most important systems. Not fifty. Five.

Confirm their logs actually arrive, confirm somebody would see an alert from them today, and confirm somebody knows what to do about it. Most organisations fail one of those three on at least one of the five, and finding out which costs an afternoon rather than a budget cycle.

Common questions

How long does it take to build a SOC

A focused capability covering your most important systems is achievable in months. Genuine continuous coverage across a large estate takes longer and depends far more on staffing than on technology. The honest approach under a deadline is to narrow scope and be accurate about what is covered.

What logs should a SOC collect first

Identity and authentication, then endpoint, then internet facing services and perimeter, then cloud control plane activity. Collecting everything from day one drives cost up without improving detection, because volume is not coverage.

Do we need a SIEM to have a SOC

You need somewhere to centralise and query logs, and somewhere to track alerts through to a decision. A SIEM is the usual answer at scale, but buying one before you know your data volume and use cases means specifying the problem after paying for the solution.

Can a small organisation run its own SOC

Continuous in house coverage is difficult below roughly eight to twelve analysts once shifts, leave and attrition are accounted for. Smaller organisations usually do better with extended hours in house, a shared capability, or a managed overnight window with investigation kept internal.

How do we prove our SOC works

Exercise it. A tabletop finds process gaps quickly. A purple team engagement finds detection gaps honestly, because somebody runs known techniques and you compare what happened with what you saw. Both produce evidence an auditor will accept.