I’ve been involved in security operations for a long time. Like, longer than I’d like to admit. That said, though I’ve worked in SecOps, I’ve never worked in an actual SOC (Security OperationsCenter). Strange, eh?

Security Operations as a concept has been around a long time, but as a term it can have different meanings to different people. We often think of a SOC as the be-all and end-all definition of security operations, but in reality a SOC only covers part of the space. As you’re maturing your security program or progressing in your career, it’s useful to have a mental model of what security operations is and isn’t… or see if you want you can try Bruce’s mental model of security operations on for size.

WARNING: what follows is how I slice up this space. It may not be the same as an organization like Gartner or CISSP training material defines it, but I’ve found this breakdown to be a useful foil for my thinking.

The SecOps Life Cycle

When I think about building and operating systems, I tend to put activities and skills into three buckets:

Most situations are not this cut-and-dry. In many organizations, people may wear two or three of these hats, even if they officially only have one of the titles. That said, I still find this framework useful when thinking about the work breakdown that happens in IT and security shops around the world. Defining the system, building the system, and operating the system each take different skills, technologies, and processes to be successful. When I’ve built and run IT and security programs, I’ve generally (but not always) structured my teams around these three pillars, often with some piece of governance layered over the top. 

Upper-Case Security Operations vs lower-case security operations

I like to think of the differences between formal processes and roles with foundational concepts as the difference between upper and lower-case letters. For instance, upper-case C Compliance refers to ensuring your organization complies with formal frameworks like SOC2, ISO27001, and PCI DSS. Lower-case c compliance refers to ensuring your organization is inline with your cybersecurity risk objectives and operating the way you expect.

Similarly, capital Security Operations refers to a SOC; that entity that takes security signal in, triages it, analyzes it, responds to it, and remediates security threats. Lower-case security operations ensure that the security apparatus in your organization is meeting the business needs, operating within expected ranges, and generally keeping the bad actors out. Lower-case security operations includes upper-case Security Operations, but is a superset of all things operational in cybersecurity land.

When we more directly apply this model to people in security roles we get the easily recognizable titles of Security Architect, Security Engineer, and Security Analyst. But wait. Shouldn’t that be a Security Operator? It could be that my model is just broken, but let's dig in a bit.

Far and away the most common operations role in security is Security Analyst. With analysts we get a universe of related jobs like SOC Manager and Detection Engineer but usually not more generic jobs around security operations. 

Why not?

Let’s look at a diagram:

Upper-Case Security Operations has evolved to encompass the landscape of things that happen along the detection and response pipeline. Potential bad events are discovered somewhere in the enterprise. Information on those events then works through a pipeline that enriches the information, automates the analysis, and involves humans where applicable. Ultimately the event is either adjudicated to be a real security incident (which launches incident response) or the event is adjudicated to be benign…and the cycle starts again.

Lower-case security operations include all of that, plus operating and maintaining the security apparatus not involved in the detection and response pipeline. This includes deploying and tuning endpoint security controls, refining email security rules and ensuring the right email is getting through to users, digging through logs when people have security related issues and questions.  There’s a universe of operational activities performed in enterprises that are security-related but don’t fall under the purview of Upper-Case Security Operations.

How do you handle SecOps?

Depending on the size and structure of an organization, security operations can be wrangled in many different ways. In my experience, more often than not, security operations fall to either security engineering or IT operations staff. It is rarely handled inside the SOC as they have their hands full with managing alerts and incidents. It can be what is euphemistically called an “other duty as assigned.” There’s no official strategy on handling security operations, it’s just “handled”; the system owner, the administrator, or even a random person in the department just handles these types of issues.

In small cloud native organizations this is a particularly acute problem. Smaller orgs likely won’t have a SOC but will have an XDR or MDR that is handling their Security Operations function. All the security operations activity that’s left to do gets handled by whoever has the most security skills and/or whoever is up for the challenge. Under resourced and without proper tooling, security operations can be a drag on the organization and ultimately increase the risk enterprises have to bear.

Fixing SecOps

Pretty dire, eh? It doesn't have to be. The first step in dealing with a problem is admitting you have one. Take a look at your organization and assess the scope of the “other duties as assigned” in security operations. What’s being addressed? What isn’t? How did responsibility get assigned? Is there any oversight or reporting? What tools and processes can be implemented to help?

Ultimately getting control of your security operations likely isn’t a difficult task… it’s just one that you have to be aware that you’re solving. Many orgs don’t realize they aren’t dealing with security operations in a sane way until there’s an incident and it’s staring them in the face. Friendly advice: before you deal with Security Operations, take a minute to deal with security operations.