In this instalment we’ll be looking at structure. Something that’s very important if we’re to approach security holistically, systematically, consistently, and repeatably… and yet, something few security programmes seem to have.  

Generic frameworks can be good, but they’re not bespoke to your business 

Firstly, I want to touch on the fact that there are many frameworks used by information security teams/departments out there. We named ISO 27001 and NIST in the previous instalment of this series, for example. 

While many of the concepts within those frameworks are useful, it’s important to realise that they are neither strategies nor programmes. Why? Because they are simply not about your business, not beyond its most generic IT parts anyway. They do not define how we achieve the specific outcomes that serve your business. 

The other problem I have with them is how they are implemented. If one requires something like authentication, for example, then I often see people implement some authentication, somewhere. It’s often not done in a way that’s measured to the business process it’s authenticating, and rarely done holistically.  

We miss places, systems, and processes, but then tick the box because we have some authentication, again, somewhere. 

Worse still, traditional approaches often see resource taken away from helping the business be more secure, for the sake of servicing compliance in ways that have questionable benefit. 

Risk ratings in spreadsheets can be tweaked to show progress, and evidence to the auditor can be selectively collected to pass the audit. I dare anyone that has participated in this to tell me they feel their organisation is more secure than if they’d actually put that effort towards securing things. 

So, I repeat: our security programme should reflect our business, it should implement our strategy which is, again, all about our business. 

Doing it this way not only makes it a lot more effective from a risk perspective, but it also provides better fit, less resistance, and the occasional cost and business benefit too. Things typically missing in most third-party compliance standards.  

My approach to structuring security frameworks 

The first thing I do is to draw a box. Think of it as a container in which we put the elements needed to establish and run a successful programme.  

The purpose of this is simple: to put everything in one place. Everything lives within this first “outer” box in one way or another.  

Note that this will include any relevant components, not just of our security function but many relevant items belonging to other departments as well. We will define those together with the relevant teams, helping shape them to be as secure as possible while respecting the business need, then keep them (or a link to them) in the box.  

These “components” are procedures, standards, policies, processes, etc. We relate to them as documents. We have to be very careful to not think that they are just documents though. They are not. They are actions, operations, and rules. But they do have to be documented, and that means documents.  

So, our framework is a collection of documents. Making sure those documents get actioned properly is a big part of the framework’s purpose. 

Within that outer box I then create a number of other horizontal boxes, which I place one below the other like a stack so that my outer box ends up becoming a bit of a tall rectangle over time. These boxes are the “domains” that make up the different areas of consideration I’ve found to be necessary to have a successful security programme. 

What these boxes represent and what they contain has evolved over time and will continue to do so. They can also vary by business type. 

I used to call them layers because of how they presented on paper in the diagrams of the framework, but this is a bit of a misnomer as there’s no dependency or hierarchy between them, as such. They’re effectively groupings; sometimes in concept, sometimes just for ease of management. 

Anyway, although it’s an imperfect term, let’s stick with “domains” for these.  

As a working example, here’s how I’d now structure the domains in a framework for a SaaS B2B services company, like the one I worked for in my last CISO role.  

After a lot of thought, an understanding of the challenges and needs of the business, and a strategy to deliver it, I might eventually settle on these 11 domains (boxes) within my big box to group the entirety of my programme: 

• Executive
• Programme Definition
• Interdepartmental Integration
• IT Operations
• SaaS & Business Applications
• Product and Engineering
• Human Factors
• SecOps
• Compliance
• Commercial
• Business Stubs 

I want to repeat that this structure is entirely arbitrary and that you should feel free to deviate. 

In fact, I strongly recommend you do. The example here includes consideration for the specific sector, culture, maturity, and other factors of the organisation. The approach for a different organisation (like yours) should look at least a little different. 

Now let’s look at what these domains mean.

• Executive: This always includes an Executive Charter that defines hard rules for the scope, responsibility, and authority of the security function, to be signed by the senior management team (the perfect place to pitch the security as quality concept and its many business advantages). 

This is critical. You need a business-aligned security strategy, and you need real executive support. Many organisations have neither. 

• Programme Management: An overview of the whole programme, inventory of its components, continuous improvement process, and how the activities will be scheduled and tracked. 

• Interdepartmental Integration: Define how we work together with various relevant but non-technical departments such as HR, Legal, Sales and more to support our security strategy. 

• 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. 

• SaaS & Business Applications: 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. 

• 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. 

• Human Factors: This is where we drive cultural change (which is not the same as user awareness) in conjunction with HR, connect with stakeholders and the general workforce, and work on process engineering to reduce elements of human error in business and IT processes. 

• SecOps: This is where the stuff most people associate with security goes. SOC operations, EDR, NDR, anti-phishing, vulnerability management, incident notification/response, threat intelligence, forensics, etc. 

• Compliance: I do not build my security according to any third-party compliance standard. I feel doing so 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. In other words: the framework’s contents are what I aim to comply to.  
   
  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 mappings happen. 

• 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?) 

• Business Stubs: A place to store other departments’ business processes (or links thereto) that could have impacts to, or should be taken into consideration in, our activities in any the domains listed above. 
   
  Examples could be the HR onboarding process, Sales negotiation process, Legal review and acceptance of service agreements and commitments, etc. 

Join us for the next instalments of this series where we’ll cover a bit more about the thinking behind each of these domains, starting with the Executive Domain.