Building a SOC from a green field

My institution had no security operations program when I got there. I arrived at a stack with no log pipeline and no written playbook for the events that keep you up at night. My title was the org’s first dedicated information security analyst, a name that described the job only loosely. The work I was doing had no title at all, so I called myself the founding security engineer, and that is what I became.

A green field means no prior incidents to learn from and no institutional memory of how a bad morning goes. You are deciding everything from scratch, including what “done” looks like for a program that does not yet exist.

Start with the asset inventory

I reached for the tooling first, because that is the tempting move. A log pipeline and a dashboard give you the feeling that you are running a security operation, and that feeling is seductive when you have nothing else. The order was wrong. The first deliverable was an asset inventory, and it was unglamorous: which servers exist, what they run, who owns them, and which sit behind the mail gateway.

A SOC that cannot name its own assets cannot separate a real event from noise. An alert fires, and the first question is which host this is and how much it matters. Without the inventory, that question has no answer. I would redo the first month as an inventory month, and I would keep the inventory as a living document rather than a one-time artifact.

You cannot detect what you did not log

The second step was choosing which logs mattered and getting them flowing. A green field has no capacity to chase every source at once, so I picked the ones an attacker touches first and the ones the institution needed. Authentication events, egress, and the mail gateway’s traffic.

Those three gave me enough signal to build the first handful of detections without drowning. I wrote each detection as a plain statement: if account X signs in from Y after being in Z, raise a ticket. I could test it, and I could explain it to the leadership layer in one line. The temptation is to collect everything so you are not missing anything, and the cost is a firehose that no single person can watch. I added sources on demand, the moment a real investigation showed me I needed one.

Borrow the frameworks, then make them yours

A green field has no in-house methodology, so you borrow. I used NIST CSF 2.0 as the spine, because its six functions, Govern, Identify, Protect, Detect, Respond, and Recover, map to the questions I had to answer¹. For incident handling I used NIST SP 800-61, the third revision, which NIST released in April 2025 and framed as a CSF 2.0 community profile². That revision folds incident response into the Detect, Respond, and Recover functions instead of treating it as a standalone lifecycle.

The frameworks give you the shapes of the decisions you must make and a vocabulary for reporting up, but they do not tell you which of your servers a breach would hurt most. Only your own inventory and your own threat model answer that. I used the frameworks as the outline and filled in the specifics from the inventory and the threat model.

One person, several hats

In a mature program, triage, detection engineering, and reporting are separate desks. In a green field, they are one person, which is me on the worst days. I triage the queue, I write the next detection, and I put together the report that goes to the teams who own the systems and to leadership.

At this stage the concentration shortens the loop. I find the thing, I build the detection that would have caught it earlier, and I write down what it meant while it is still fresh. The cost is that the loop only runs when I am sitting down. That makes a SOC at this stage more brittle than the ones with a rotation behind it.

ATT&CK as a shared vocabulary

Building detections from nothing, you need a way to name what you are hunting and to say, with some precision, where the gaps are. MITRE ATT&CK is a knowledge base of adversary tactics and techniques based on real-world observations³. The enterprise matrix currently lists fifteen tactics, from reconnaissance and resource development at the front through exfiltration and impact at the back, and each tactic breaks into named techniques⁴.

I used it as the index for coverage. I tagged each detection to the technique it hunts, and each tag left a gap visible in the matrix. I could point at a specific technique, say that it is not covered yet, and rank it against the others by how likely it is in my environment. That tag is a shared vocabulary: when I say we are missing coverage for credential dumping, the systems team and leadership know exactly which cell of the matrix I mean.

The relay is the output

My job is to research and assess, then hand findings and priorities to the teams that own the systems and to leadership. The green field put me deeper into the machinery than the job title suggests. When our patching broke, I fixed it, and I built the vulnerability management program that assists with the patching effort. Deployment is automated, so on a normal day I am not the one pushing OS updates. The SOC’s output is the relay: a clear, ranked set of what I found, what it means, and what I need done next.

The relay is where a green field SOC earns its keep, or a leader skims it past. I keep the leadership-facing version to the finding, the risk, and the one decision I need from them. The program is only as good as that last hand-off, the moment I hand a ranked list to the systems team and they start moving on it.

A green field does not end. The inventory grows, new techniques show up, and the relay has to carry more, but the order of work stays the same.