Welcome to this series on building security programmes. It will help you with your organisation’s security, and also demonstrate CDW’s commitment to help customers approach security holistically and effectively, with their unique business requirements and context in mind.  

Let’s get started!   

One of the issues I’ve faced as a CISO, auditor, and now trying to help CDW customers reach better security outcomes, is a lack of effective security programmes. 

In many security functions, the programmes tend to be based around acquiring, implementing, and operating risk management capability; mostly in terms of tools and services. 

The issues with simply acquiring more security tools 

My first observation here is that the maturity of these programmes is often quite low. When asking for documentation around the process, operations, configuration, scheduling, maintenance, and other aspects of what’s been acquired and put into service, I’m often left empty-handed. 

The second, and perhaps more important issue is that, while more mature processes would help the effectiveness of the tools in their application, the business would likely still not benefit from effective overall protection. The reason for this is that, to be effective at protecting a business, a security programme must deliver a security strategy that aligns to the business.  

Instead, most of the strategies we see are often little more than shopping lists of solutions with only a vague connection to the business’ goals. 

Imagine you were newly hired as CEO of a troubled company and you’re trying to ascertain the lay of the land; what’s working, what isn’t, and which people to trust. 

You ask your Chief Marketing Officer what their marketing strategy for the business is. Their answer is that they are ‘going to buy the latest and greatest marketing tools’.  

You’d seriously start to question them. 

No marketing function can be successful without understanding the market, the product, the customer, the costs, the inputs, the sales cycle, the points of resistance, and much more. 

And the third and final issue I see with most programmes is that they are heavily focused on security operations that are meant to mitigate the vulnerabilities in the business.  

That probably sounds like a good thing, until you realise that it’s done at the expense of driving change that would reduce the creation of issues in the first place.  

‘What good looks like’ 

Defining ‘what good looks like’, so your business doesn’t have security issues in the first place is, in my opinion, the most important purpose of a security programme if it’s to make things better for the business over time.  

It should, of course, also define how to run security operations to mitigate remaining risk (and how to do so in the most cost-effective way possible), but if your programme does not drive more fundamental change by defining ‘what good looks like’, so that your business and IT processes don’t introduce vulnerabilities in the first place, your organisation will never actually become more secure. 

In this series, in the hopes of helping our customers and the world at large (not to mention showcasing some CDW insights!), I will elaborate on how I’ve built security programmes to address the three issues we’ve just covered. I'll cover:

• How to ensure operations are well-defined and mature. 
• How to ensure the programme is not siloed as merely an IT function. 
• How to define ‘what good looks like’ throughout the entirety of the business, so that its processes leave us with fewer and fewer issues to risk-manage over time. 

One thing you’ll notice about the example framework in this series is that, beyond ensuring we have a defined strategy, securing management support, and ensuring the needed organisational structure is in place, a lot of it is based on systematically going through applications, systems, IT and business processes, and so forth.  

“Doing security” (as in, operational security activities and 'cyber' technologies) plays only a very small role. 

It's easy to get tightly focused on each individual area as we work through things, but please remember that we should always have the business and the quality of its business and IT outputs in the back of our minds. 

That, more than anything, should define what is needed in our programme and with what level of granularity. 

As we like to say:  

Do less “cybersecurity”, do more business securely. 

Join us for our next instalment, where I’ll elaborate on my definition of security programmes vs frameworks for the purpose of this series.