In this instalment I want to share with you how I structure a strategic security programme as a CISO. Both in the hopes that it can help you drive change in your own organisation(s), but also to help the practical understanding of some of the things we have discussed so far on in this series both in terms of how and why.
This will be a high-level overview at best, but something we will explore in detail in an upcoming book graciously sponsored by Hitachi Vantara.
My definition of a “strategic” or “business-level” security programme is similar to any other security or quality programme. It involves defining the ideal state of things, how we maintain that state, and capturing the necessary support and authority to do it. The real difference is the scope at which we address the problem:
Most security function and programmes focus on having the capacity to deal with all the issues the current business processes have and will produce, forever.
Conversely,I prefer to focus primarily on influencing business process throughout the whole organisation to continuously reduce the number of bad outputs(vulnerability, attack surface, obstacles to security maintenance activities like patching, etc.) they produce in the first place.
The first is building operational security capacity, the second is shaping the business so that things are inherently more secure and less and less operational security capacity is required over time.
So, what does such a programme look like? Well, it can take many shapes. I’ve evolved, sometimes radically, how I approach this over time to not just better reflect each organisation, but also to incorporate new knowledge and ideas. I hope that, should you decide to take some of the concepts and structures presented here, you also adapt and evolve them to work even better for yourself and others.
The first step is very simple: I create a framework.
I start by drawing a big square (more a vertical rectangle for me) that acts as both a box and a wireframe.
The purpose is simple: it holds everything. It’s a container that everything will live in, and that will connect them all together. This overcomes the first problem I often see in organisations: discombobulated documents and policies, rarely in homogeneous formats, scattered all over the place, and with no full inventory anywhere.
Inside this box I create layers, or domains (I’ll used “domains” going forward). And within these are a variety of documents. These documents can be standards, declarations, processes, policies, definitions, anything really. These are what define the desired states of things; of the organisation, of our own efforts and mandate, of our needed authority, and of the approaches we’ll employ to deliver on our mission.
How many domains or layers there are can vary for each organisation, and as mentioned you should tailor this to what works best for you. But as an example, the last framework I developed for a SaaS B2B services company contained the following domains:
1. Executive
2. Programme Definition
3. HR & Legal Integration
4. IT Operations
5. SaaS & BusinessApplications
6. Product and Engineering
7. Human Factors
8. SecOps
9. Compliance
10. Commercial
11. Business Stubs
1. Executive: This always includes an Executive Charter that defines hard rules for security scope, responsibility, and authority, signed by the senior management team (The perfect place to pitch the security as quality concept and its many non-IT business advantages). As well as a written Security Strategy (business-centric, so well beyond IT) that explains and justifies the approach (including the framework), team structure, timelines, etc. involved in delivering it.
This is critical. You need a business security strategy, and you need real executive support. Many organisations have neither.
2. Programme: An overview of the whole programme, inventory of its components, continuous improvement process, how the activities will be scheduled and tracked.
3. HR & Legal Integration:I need to define Acceptable Use Policies enforced by HR, I need defined roles and associated access, I need HR integration for automated/effective JML, I need to work with HR and sometimes legal on investigations. All this is defined here. I also need integration with Legal for contractual reviews, certain incidents, ensuring contractual requirements are captured in IT and security service delivery, etc.
4. IT Operations: Define how we do everything IT related, from provisioning users, asset management, patching, architecture, backups, recovery, logging, email, networking, endpoint hardening, database configuration, media handling, cloud standards, change management, etc. This one tends to be quite large and could easily be broken into several sub-domains for ease of delegation or organisation. The important part is to define, in detail, with the relevant stakeholders, how each IT activity should be done with security in mind.
5. SaaS & BusinessApplications: Define the state in which every internally hosted or SaaS business application should be in to ensure security, one at a time, working with the stakeholders to understand the business processes, data, and potential impacts.
6. Product and Engineering: If applicable, define all the practices that should go into your product development, product security features, hosting/engineering environment, internal and external-facing product security documentation, etc.
7. Human Factors: This is where we drive cultural change (which is related only minimally to user awareness) in conjunction with HR but also work on process engineering to reduce elements of human error in business and IT processes.
8. SecOps: This is where the stuff most people think is security goes. SOC operations, EDR, anti-phishing vulnerability management, incident notification/response, threat intelligence, forensics, etc.
9. Compliance: I do not build my security according to any 3rd party compliance standard. That is not only backwards in some ways but also likely to result in missed areas and ill-fitting implementations. Instead, my compliance is based on the application of the framework. I can then easily map my security processes and mechanisms to any compliance standard with minimum effort (a great business agility advantage when entering new verticals or markets). This is where those mapping shappen.
10. Commercial: Here we define how we capture contract schedules that relate to security, any customer facing services like security-status portals, how we help Sales accelerate the RFI process (including any documentation to give customers), our involvement in any contractual negotiations with an impact on security, and any marketing and branding material around how our security gives us an edge. (If we think security is important, why wouldn’t we have it be a brand value or selling point?)
11. Business Stubs: Links to all other departments’ business processes, which should be taken into consideration when creating every component of the framework in all the domains listed above.
I typically start off building out the executive domain and getting the relevant documents approved, then create the Programme Definition layer so everyone knows how to contribute to the programme. The HR & Legal pieces (as many important other processes will depend on these) come next. Building out the rest is then mostly delegated to members of my team and collaborating other departments.
Now might be a good time to mention that, for reasons I will explain shortly, out of the dozens of activities that would fall under the IT Operations domain I always ask that the back-up and recovery piece be one of the first one shandled.
Overtime, the build-out of this programme leads to close integration between departments and the involvement of those departments in security practices.
To name just a couple of examples: Access to systems can be managed automatically by HR based on role profiles and automation, systems and applications are architected and produced using templates incorporating security standards, all business processes are captured with security concerns highlighted and considered, Operational/maintenance activities like application and asset management, patching, backups, provisioning, and more become automated according to define standards, all leaving fewer gaps for potential exploitation.
The net result is greater security due to the improvement (higher quality) of the organisation’s processes, not the security department’s capability to firefight. This means every implemented change has a permanent effect rather than just being the latest avoided disaster.
And that is how we reverse the trend, lower the business’ risk over time while needing less and less operational security resource (rather than more), save the business money, not to mention find and generate other benefits elsewhere.
I’ve seen everything from significant reductions in license costs, contract renegotiations, more stable applications, lower maintenance costs, higher customer satisfaction, even reduced turnover as DevOps and Site Reliability Engineers inherited fewer frustratingly hard to maintain systems. All from trying to improve the quality of processes to help, nominally, with security.
The argument of improving the business rather than “doing security” is also one I find easier to sell to executive audiences. When department heads resist, the quality argument is a powerful one. It’s somewhat easy for departments to claim that it’s not their job to handle security when senior leadership doesn’t understand how security works. But once we’ve positioned security issues as being the result of poor quality, it’s very difficult for those department heads to argue that they aren’t responsible for the quality of their outputs.
If they insist that security isn’t their responsibility, I like to ask them who they hired to lock their front door this morning.
So that, in my opinion, is the goal of a framework, and the strategic goal of the CISO.
I have yet to see anyone propose a more sustainable approach in the sense of eliminating the source of security issues in the first place.
There is however one problem with it: You must put in the work, and it takes time. Probably years.
I feel this is one reason people go for the short-term firefighting and mitigation approaches, spending most of the effort operating detection and response functions to firefight all the issues at their feet. Don’t get me wrong, you need these technologies, but their greatest value isn’t firefighting issues, it’s giving you the end of a string to pull on to find out which business processes are responsible for the issues. We can then rectify them so that the issues stop coming, instead of spending all our time dealing with the resulting fires.
And that’s where recovery capabilities come in. I know this is a radical statement to most technical security professionals, but it allows us to, in a way, let some things burn. Or rather, risk them catching fire.
We can risk them catching fire because we know we can quickly and reliably bring them all back to life, and the time saved trying to mitigate and react to every risk or threat can be spent elsewhere fireproofing the business processes that build our systems, applications, and define our operations. Once we’ve fireproofed them, we don’t need to stand guard over them all the time, which is yet more resource we can shift.
That is what risk management and security leadership should be about: using there source we have at our disposal to deliver the highest amount of value to the organisation, and to consume as little of the organisation’s resources as we can. Not to “do security” in a way that we know is ultimately ineffective (as shown by the ever-increasing frequency of breaches).
In short, we know that if the worst comes to pass, apart from a confidentiality breach, things can be put back in order. And having this capability, as you work on building out your programme to be able to stop things happening in the first place, means you can sleep at night, and focus on the future during the day.
But even from a pure technical Risk Management perspective, this idea of “letting things burn” isn’t radical at all in my mind. In fact, if we include the speed of recovery in our Risk Management calculations (something that obviously should be done but rarely is) it affects the business impact of any particular risk.
For example, one way of decreasing the impact of all our risks could be not to even do anything about the threats or vulnerabilities, but merely have faster recovery.
And if we increase the scope of our risk calculations to include the root causes of the risks (business process) and start looking at a longer more strategic timeline, we find that fixing the causal business process is almost always what should be prioritised. Even more so when short term risk has been mitigated by strong recovery capabilities.
And that’s precisely what we’ll be looking at in our next instalment: Risk Management under the light of business risk, how recovery time factors in, and how it helps us shift our focus to solving the root issues rather than continually mitigating the risks they cause.
Next article: What We Call Security: Recovery-based Risk Management (4/7)
If you’re ready to prove the impact your cyber initiatives are having in a business context through evidence-based solutions, we’re ready show you.
Request Demo