All articles

Building Effective Security Programmes: Part 11 – The Secops Domain

Author:

Greg Van Der Gaast

Security

•  Apr 15, 2024

Welcome back to our series on building security programmes. A series we hope helps not only you better secure your organisation, but also highlights CDW’s commitment to help customers approach security holistically and effectively with their unique business context in mind.  

Today, a quick look at Security Operations. 

This domain is likely the simplest one to understand for most of the security practitioners because it’s essentially what most people consider “cyber security.” 

It’s also the reason I won’t talk too much about it. Most practitioners out there know this stuff, so I want to talk more about making sure it’s captured and integrated into our framework. 

This serves a few purposes. 

It makes sure that the individual processes and roles around them are defined, documented, and managed, to ensure that they are considered holistically with all the other actions in our framework when we think about our overall risks. 

It also allows us to ensure that any insights of strategic value that may come out of these operational activities are captured and considered by the overall strategy. 

As a CISO, my view is that in any larger organisation’s SecOps is best delegated to a Head of Security Operations. The roles, in my opinion, have very different profiles with one having a strategic C-level focus and the other more on process and technology. But it’s my job to make sure these things are captured in the programme. 

Managing the programme and its contents is something you may also consider delegating. I have a programme, quality, and compliance manager who oversaw this in my last CISO role. 

Right, the SecOps Domain. This domain is where I define how we implement, configure, run, and maintain security technologies like our general SOC setup, SOAR, SIEM, EDR, NDR, Vulnerability Management, Application Security Testing, Penetration Testing, and any other non-strategic operational security activity. 

That said, security operation leads should be mentored in providing as much strategic feedback as possible, and our business insights are critical to know where to prioritise operational resource. 

How we manage the outputs of these tools is critical to informing our strategy and getting results from it. 

For example, if our SOC is seeing high frequencies of certain elements being exploited, we should not just combat those attacks but also investigate the reasons behind the presence of those vulnerable elements so that they can be tackled, and their remediation planned as strategic activities.  

Conversely, our business knowledge should tell us which systems, users, or processes have the highest potential business impacts and our operational security focus, or at least awareness, should have some degree of concentration there.  

This is one area of security that’s well-serviced in terms of knowledge, and as such, there is plenty of knowledge out there on how to best run security operations and associated technologies.  

However, do remember to always keep the strategic aspects in mind to maximise their business value in addressing root causes and prioritising resource. 

As always, if we can help you with any of these technologies, or the insights to get more strategic value out of them, don’t hesitate to get in touch. 

Join us next time for a look at how our framework addresses compliance. 

Contributors
Share
Subscribe to email updates