Updated: Aug 26
This article is the second in a series of articles on the art of writing a security strategy. This article will focus on the process of defining “the HOW” of a security strategy.
The WHY/HOW/WHAT approach is based on the ideas in Simon Sinek's book Start with Why.
This article is part of a series designed to help leaders (CISO’s) and security professionals define their cybersecurity strategy and will be followed by two integrations (cybersecurity frameworks and Information security team structure) before we head into the final article - the WHAT.
Please refer to the previous article for more information on - the WHY and please note the ideas in this series of articles are mine and do not represent the view of my employer or any of my clients.
Applying the WHY and heading to the HOW
In this article, I will take you on a journey where we will explore the HOW when it comes to developing a cybersecurity strategy.
In the previous article, we explored “the WHY” when it comes to commencing the journey of putting together a security strategy. I use the term journey for a specific reason: writing a security strategy is like aiming toward a destination and progressing along a very long road.
The end destination is the vision (The WHY) that will not be reached. This is the best definition of the vision otherwise it becomes your current status and not a vision anymore.
“The vision is something ever moving and something to strive toward. You will never reach the vision because if you do it will not be a vision anymore but reality instead.”
This is just my take on one of the academic definitions of the vision, and yes, I did just quote myself.
The WHY of your security strategy is the fundamental reason why the organisation should aim for security.
You as a CISO should champion the vision (meaning of the security strategy) and the strategy should be built on the vision and developed into the security plan that will implement it.
The key message to remember when implementing security in an enterprise is:
“Security must serve the enterprise not the other way around.”
This should communicate the need, for the security practice, to serve the organisation; this means that as security professionals you should identify the top risks to key assets and ensure that the enterprise perceives them correctly and mitigates them in line with the risk appetite.
In all the risk assessments you do, it is important to remember that there are elements of education and awareness that a security professional or CISO would need to do for the board of directors and other key stakeholders.
The whole process aims to increase the overall level of security maturity of the organisation, in particular, the key stakeholders, so that the latter can make an informed decision during the process.
Adding credibility to the strategy — the reference frameworks
In the next article, we will explore some of the reference frameworks which serve the purpose to add credibility and structure to a security strategy.
To give an idea of the frameworks considered:
· ISO27001 Framework: The framework can be enriched with topics depending on your organisation.
· NIST cybersecurity framework: NIST proposes a five step approach to cybersecurity.
Please note there are many more info security reference frameworks, but for the sake of brevity, I’ve just considered the above for this article.
Five steps to achieving a cybersecurity strategy
The HOW of the security strategy can be summarised in the following five steps, which are based on experience and the above frameworks, specifically the NIST cybersecurity framework.
We will explore each of the steps in detail:
Step 1 — Baseline: Assess the current status of security
Starting the security strategy from an exact starting point is essential. The best way to achieve this clarity is to establish a baseline. An audit of the current set of assets is recommended.
Depending on the number of the assets it might be necessary to reduce the scope to only the Crown Jewels.
To define the baseline:
· Define the business benefits of a baseline, with a business case, to display the importance and secure the required budget
· Utilise a mix of internal and external audit (if the budget allows):
· Internal audit provides a partial perspective but a real-life perspective and tends to be cheaper (can scale well). The selection of internal vs external depends on the organisation.
· External audit assures third party review but tends to be more expensive. (Caveat is that third parties tend to have their agenda to sell consultancy so always take the audit report with a pinch of salt)
· Bring it all together — Match the findings to the key pain points/assets: this will provide a sense of priorities and facilitate the identification of the quick wins (high-value assets protection with least effort).
“Without a full baseline is not easy to define a plan of action.”
I am conscious that we don’t live in a perfect world, so it might not always be possible to build or have a baseline at hand.
If this is the case, here are some of the key areas that you can look at:
· The patch management process and the status of patching across the IT asset estate
· The application security maturity level and the level of security awareness of the developers.
· The level of maturity of the supply chain managers and security assessment of third parties
· The security (architecture) involvement in projects lifecycle and how soon are they engaged (shift left)
· The level of maturity of the security architecture team and how well integrated are they with the overall architecture team
· The involvement of the security team in the DevOps team and development pipeline
· The involvement of the security team in approving changes (change control process)
If you are presenting the above to the board it is important to provide business benefits, evaluate the findings with a risk assessment and provide at least three mitigation options with the recommend one.
This means the board will have a method to evaluate and accept or mitigate risk. Ultimately, a board of director is meant to is assess risks and take a money-conscious decision.
Once you or the dedicated team has identified the IT assets, the Crown Jewels and you have the output of the audit (internal, external or ad-hoc) you can proceed on pinning down additional details like:
· Define and agree on a budget; define a healthy division between buying and building (internally) the controls:
· Buy vs build of tools can reduce the implementation time but requires a good understanding of the enterprise and a careful placement of the tool. An example of a tool focused vision is: deploying a SIEM without knowing what asset to log/alert.
· Build internal controls could provide great flexibility (knowing better your own enterprise) but at the same time might burn up the resources pool: money, people and time.
· Be conscious when segmenting the implementation team in:
· Project resource (new projects tends to have high visibility as they have high value for the organisation)
· BAU resource — balance the BAU work and weight the gain to the level of risk of a problem (directly linked to the asset value)
Steps 2 and 3 — Risk assessment gap analysis and plan
Steps 2 and 3 are to define the delta between the current and the target security posture. The gap analysis is the precursor of defining the security plan (the WHAT) and what takes to achieve the target posture.
Each gap identified should be based on risk assessment.
To perform a risk assessment, one of those reference models can be used:
· ISO 27001 as part of the ISMS
· NSCS guidelines
The risk assessment of the identified gaps should:
· Risk assess the identified gaps against the impacted assets.
· Quantify the impact on the assets with quantitative (numerical) or qualitative (opinion based) analysis depending on the maturity of the risk assessment process.
· Propose mitigation and evaluate the mitigation effectiveness
· Evaluate the residual risk after applying the mitigation
· Assign the risk an owner and a timeline of resolution or risk review
Basing the analysis on the gap and the importance of the resolution for the organisation will provide the CISO with a sense of priority. The sense of priority might or might not be linked to the risk level. But the risk importance will offer a priority in the security implementation plan
Step 4 — Implementation and monitoring
The plan leads to the implementation of the security strategy and helps to allocate the budget and resource available/acquired.
The status of the implementation, which would also be described as the WHAT should be monitored to measure success in implementation.
But, be mindful that resources to implement and actuate the security strategy might inevitably spread between the project and the BAU.
Also be mindful that the implementation of the security strategy should be integrated with the operation team. The advantage of involving them from the very beginning is that the security team will keep the plan update and accept the dashboards and controls more gladly and most importantly provide useful insight from a different angle.
Step 5 — KPI and continuous monitoring
During the implementation of the security control, the process is vital in defining:
· Key Performance Indicators (KPI) — parameters to monitor that are important in defining success (e.g. number of security improvements in applications). Determining the meaning of success is essential to report on the status of the project as well as react to failures.
· Alerting and monitoring strategy — what alert should be sent and to who.
· For each control it is essential to identify what to monitor and determine the alerts.
· It is important to integrate monitoring and logging toolkits (e.g. matrix) into the project. Each project will introduce a new component and should define what to log and what to alert.
· Define the monitoring dashboard and train the SOC team to analyse them and alert based on the output of the dashboards.
Beyond the five steps
There are other key steps and vital activities that work with and as part of the security strategy. The activities should be a part of the lifecycle of the security team:
Recruitment and staff sourcing — There is no point in defining a security strategy if there is no one who can govern it and implement it. Moreover, this will be a vital process to preserve the health of a security team keeping it correctly (the stuff of dreams) staffed to the adequate level and refresh the resource with fresh intake and ideas.
Incident management and disaster recovery plan — this is another vital part of the security strategy and the most important and essential part of the organisation. The plans will keep on evolving during the life of the organisation and the changes introduced. This step is in line with NIST’s step 3 - Detection method based on the deployed controls and step 4 — Incident response based on the detection methods
Business continuity and recovery plan — This is the key activity to keep the organisation healthy. Start a line of action to define a recovery plan based on the Incident response
Establishing a security strategy is a cumbersome, but necessary journey, for an organisation.
Without a strategy, the organisation will end up firefighting but not addressing the root causes and ultimately wasting a lot of resource and energy.
In this article, we’ve started heading from the WHY (the vision) into the HOW (the methods) and preparing the road for the WHAT (the plan).
In the next article, we will explore some additional detail on the HOW: the framework and resourcing the team.
Ultimately the HOW will head into the WHAT (the plan) that will provide a step by step action plan to execute the strategy.
Without a why and a vision implementing security controls in an organisation is like trying to put out a fire with a napkin…if is a small fire you might achieve something but, most of the time, it will result in something like this.
Other Articles on Medium