A Security Operations Centre (SOC) "is a team, primarily composed of cybersecurity specialists, organized to prevent, detect, analyze, respond to, and report on cybersecurity incidents."
– Definition by CNSS (Committee on the National Security Systems)

Within the relatively young field of cyber security, there are the even younger subfields of security operations, detection engineering and cyber intelligence. For years, the Great IT Security Rebranding has focused on standards for maturing cyber security controls- NIST CSF, ISO 27000 suite -which seems to have left a blindspot of experience surrounding SecOps.

Largely, this is because measuring cyber risk in SecOps is complex. It deals with the day-to-day of security- the myriad digital events. It involves the intersection of dozens of fields and skills: incident response, threat hunting, forensics, detection engineering, malware analysis, scripting, data science, risk analysis, statistics, networking, vulnerability management, to name a few. And it must always fight to develop new detection methods for emerging attack methods.

However, having worked as an analyst in the SOC-as-a-Service functions at two managed service providers, I have observed that many of the structural problems faced by SOCs are due to poor planning at the start of the journey. Perhaps the responsibilities of security monitoring started out small, and so it was handled by the IT department. Or perhaps a SOC had to be created quickly to meet client demand or regulatory requirements by individuals with minimal experience. I know analysts in organisations in both of these situations, and it is incredibly difficult both technically and bureaucratically to move the status quo once you have a ‘good enough’ system in place.

All the theory needed to create a SOC is excellently documented in MITRE’s ’11 Strategies of a World-Class Cybersecurity Operations Center’– essentially the SOC textbook. It is a masterpiece, and I am eternally grateful to the authors.

However, frankly, not everyone has time to read a dense, 450-page document when they’ve been tasked with getting a SOC on its feet as soon as possible. Moreover, I have always found a combination of theory and practice the best way of learning myself.

So, the purpose of this blog is to create a concise, practical guide to deploying a well-planned SOC that will avoid as many of the common pitfalls as possible, using Azure Sentinel as the SIEM (Security Incident & Event Manager) and a stack of mostly Microsoft technologies. Along the way, I will provide screenshots where appropriate from my home lab, and will cite industry best practices and standards. While I will discuss the people, process and technology factors involved, I will focus on technical side, as that is my area of expertise.

I hope that the reader may find this helpful in their SecOps journey.

All the best,

Polus