It is really important to understand your starting point before deciding what your future holds and how to get there. You will, or certainly should, already be doing several aspects of InfoSec and it is vital that you develop a view as to what your focus is on and how well you are doing. You will need to understand the current risk posture across the organisation and how this is reflected in the security function. For example what kind of budget is afforded to securing the organisation and what credibility does security hold. Where you have that budget what is it used for and how are those investments identified? Does security have a seat at the top table, or is it several layers down?
How do you currently approach risk management? Is it a thorough investment in truly understanding risk with continual measurement thereof, or is it more lip service to overarching risk with little application of the management aspect of risk?
Understanding you current technology stack and architectures is really important, as well as what controls infrastructure you have in place and how it is utilised, alongside what it is telling you. Do you have a good asset understanding, a Configuration Management Database (CMDB – for those that don’t know this is a repository of asset information, including dependencies between assets; it gives you an understanding of how critical assets are composed), up to date documentation? Can you put your hand on the configuration of the enterprise? How well is it managed and kept up to date? How do you assess the importance of particular patches and how long does it take between release and deployment? Also, who manages the enterprise, or which aspects of it? Who are the key players for each aspect?
What is the breadth and depth of your ecosystem? What do they provide and what access do they have? How is this governed and what supplier assurance activities are undertaken? What are the results of these assurance activities?
What policies are in place, how well are they understood by users, how often are they breached and policed? Frankly are they fit for purpose and I would add, do you understand them yourself?
What processes are currently in play, especially regarding incident management, access control, provisioning and change, SyOps etc.? How many incidents do you currently have and how do they breakdown in terms of cause and vector? How easy are they to investigate and resolve? Were you able to detect them yourselves? What were the impacts of those incidents and were lessons learned undertaken and implemented?
What is the make-up of the existing security team? How are they split and how do they perform? It’s useful to engage the security guys on the ground to understand what they think of their role and effectiveness. What skills and resources do they have at their disposal and how well do they use them? Do they have an improvement plan?
What controls do you have for both detection and prevention of threats? How are they performing? Mind, do you assess their adequacy at present, or just trust that they work? What assessments are done across the estate, if any, and what happens with the results of them? Have there been any audits of the security function, or key IT areas? If so what were the results and were the recommendations, or gaps, actively work on.
There are lots of questions to ask and find answers to here. It is not a tick box exercise and really needs effort putting into it to ensure it is a robust and thorough assessment of the current health and practices across your organisation, from an IT and security perspective. I find it best to apply a common framework to this work, for example ISO27001. It does require due diligence and making it up on the fly doesn’t cut it. You may choose another framework, but it is best to have a standard and structured ‘list of questions’.
Another concept to consider is what your most valuable assets are in terms of criticality to your business mission. This is fairly common sense to identify the most valuable resources and ensure they are adequately protected, but protected from what? It is common practice to identify key assets, establish the risks to those assets and implement appropriate mitigations for those risks that are deemed above tolerance. This is, or certainly should be a standard flow within any organisation, though often focusses on theoretical risks, and post ‘go live’ rarely gets looked at again.
A new approach has been developed by the good people at Mitre. The approach is built for Mission Assurance (MA), and from the context of this the subdomain of Mission Assurance Engineering (MAE). Mission Assurance is the ability of operators to achieve their mission, continue critical processes, and protect people and assets in the face of internal and external attack. Mission Assurance Engineering (MAE) offers a common, repeatable risk management process that is part of building secure and resilient systems.
The premise of MAE is to identify your Crown Jewels in terms of mission critical objectives, operational tasks and their dependencies with information assets, or cyber assets in the solution or wider estate. From this you can determine the impact of failure of one asset to the overall mission of the organisation. How that asset can affect higher level tasks, objectives and the overall ability for the business or function to operate effectively.
What often gets missed in classic risk assessments is the dependencies between assets. For example if Asset A fails what is the knock on effect to Asset B, where Asset B is a mission critical asset. When you understand dependencies between assets you can start to predict the effect of a successful cyber-attack on a particular asset and how it will affect the business operation.
Remember here that it is not just the core asset(s) that houses the crown jewels that is mission critical. Supporting assets that have access, or provide flows to the core asset are also critical, or can have a critical impact to business operation. This can also include files, services and key system accounts. You may also have assets that are time critical, certainly where you have specific business events or peaks. These need to be factored in also. It should be noted that the more complex your business goals and supporting systems the more difficult this can be, but still well worth the effort.
From there you need to understand how susceptible those assets are to threat, internal and external and therefore the risk to those assets. This process is called a Threat Susceptibility Assessment (TSA). Cyber threat susceptibility analysis (TSA) is an MAE activity that quantitatively assesses a system’s [in]ability to resist cyber-attack over a range of adversary Tactics, Techniques, and Procedures (TTPs).
Consider any threat actor’s exploit target; they are either targeting a security configuration (CCE) induced vulnerability (e.g. didn’t harden the system), a known vulnerability (CVE), or they found a new (0-day) vulnerability in a software weakness (CWE), and the attack pattern (CAPEC) used is the steps to exploit said vulnerability.
You need to understand what weaknesses your core and supporting assets have and what methods are in play for exploiting those weaknesses. A simple and effective way of understanding this is to take the configuration of the assets, establishing what vulnerabilities exist for the configuration components (e.g. software stack elements, versions, patch status etc.) and how they could be exploited. Resources like Common Attach Pattern Enumeration and Classification (CAPEC) gives you a compilation of attack patterns that describe common methods for exploitation. They are derived from real-world scenarios and effectively portray the Tactics, Techniques and Procedures (TTPs) of real adversaries.
There are a lot of attack patterns to go through, though you should be able to discount several due to the nature of your software stack. For example if you have no SQL instance it would be rather futile in assessing susceptibility to SQL injection attacks. When you establish the relevant attack patterns to your assets you need to score them to understand likelihood of success, impact, restoration costs etc. The higher the value of the asset the more weighted the scoring should be.
This should give you a matrix from which you can easily identify the highest risked assets, and to which attack patterns. This gives you an idea of which assets need swiftest focus. This focus needs to be on countermeasures to reduce the susceptibility of an asset to attacks. These countermeasures can include processes, procedures, technological controls etc. and are designed to counter the threat or vulnerability by eliminating or preventing it, or by reducing the harm or impact it could cause. Of course prevention is never going to be 100% infallible, and so detective controls are equally as valid, though reporting, alerting and priority needs to be aligned to the criticality of the asset in question. Recovery is something that should also be factored in to any potential susceptibility and resultant impact.
You can approach this aspect in a few ways. You can look vertically at the assets deemed most at risk, horizontally at the attack patterns with the widest breadth of susceptibility or a combination of both. Where identifying countermeasures it is useful to look in the round in terms of what assets they will serve to protect and which attack patterns they mitigate against. Where you can have numerous hits across both, these should be high on your priority list as they have the greatest impact in terms of reducing risk to your organisation and a demonstrable story.
Where a counter-measure or mitigation is deemed required you will have a strong basis from which to implement it. Following this process you can describe why it is required, what the asset is susceptible to and the likely impact should the susceptibility be realised.
There are some great resources out there to help understand this concept more fully and I would recommend the following from Mitre as a minimum read:
Note: Mitre is a Federally Funded Research and Development Centre sponsored by the U.S. Government
Taking the results of where you are now you can start to plan for where you want to be tomorrow. You should be able to identify your gaps pretty easily from undertaking the above assessment and now you need to coherently define how you address those gaps and weaknesses in your current regime.
For me this starts with your basic cyber hygiene (I’ll cover that in more depth later) and the old adage of ‘low hanging fruit’. This is especially worthwhile where you can address a gap or weakness quickly and demonstrate value to the organisation. Successes like this help you build greater credibility and gather momentum for your longer term plans. The work you have undertaken already gives you a strong starting point in describing the rationale behind the need for action.
This planning aspect is where you need to determine the order and magnitude of the differing enhancements to your security regime and correlate this across your existing risk view. You need to start formulating a programme of work and an outline vision for your cyber security capability. Depending on the breadth of your gaps you should be able to roughly estimate the length of your programme to meet your initial vision, and as such what type of support for your programme you will need to engender.
The planning stage is the prequel to the development of your security strategy, which really starts to pinpoint the high level activities you will be focussing on.
Without a coherent and well thought through strategy that is built upon the wider business vision, then you will effectively be undertaking Elastoplast security. The focus will be on perceived risks, rather than actually measured and applicable risks without a compelling build structure to enhance the defensive capabilities for the organisation in its entirety.
The strategy needs to be founded on a realistic view of the organisation’s capability, coupled with the vision for where security can support and allow the business to achieve its overall plan. When I say a realistic view of the current capability this needs to be a full and frank look in the mirror. This is not a tick box exercise to pass an audit check, as it will serve you no good in the long run. There is no point whatsoever in pretending you are better than you actually are. The purpose of this is to allow you to determine how to build you capability, ensure you have the right foundations in place and then identify the elements that will increase your maturity. For example there is no point identifying a security investment if you are simply not patching your systems adequately.
Research is key in identifying where it is you want to get to in terms of maturity and capability. Learn from those that do aspects really well and understand the journey they took to reach that level of maturity. You need to factor this across the whole sphere, not just a single component. You will find that the best make sure their basics, cyber hygiene if you will, are absolutely nailed! Also understand that this is not something that happens overnight, nor can you just throw money at a problem, especially if your growth path has not been properly defined.
It is all well and good saying the strategy should be coherent, but it’s worth a short spell just explaining some of the key components in building that strategy.
The prime focus of the strategy and cyber security capability build should be to improve preparedness, response and recovery measures in the event of a cyber-attack, including building greater situational awareness, contingency plans and a systematic approach to both risk management and governance frameworks. The strategy needs to include the definition of organisational structures that develop, build and test the preparedness activities and overarching frameworks.
In order to achieve the above, the strategy should review existing capabilities, policies, personnel etc. and draw out the advancement of appropriate policy, procedural, technological and organisational aspects. It should show an understanding of the existing organisation’s estate and practices and highlight where these are not appropriate to meet and mitigate the current and future risks. It should consider the range of threats, current capabilities to mitigate those threats and appropriateness to the business criticality of the area that the risk relates to. This gives you a good basis to define where improvements are required. As part of this risk view it should consider emergence and evolution of threats in this space.
Focus on existing business risk alongside technological or organisational constructs across the enterprise, coupled with any regulatory or legal compliance requirements should be a key factor in defining the strategy. This needs to be coupled with the view on emerging threats and risks and of course the defining elements of the business vision and supporting technology and business strategies. It should recognise constraints, for example outsourced technology partners, supply chain delivery etc. and ensure these are built in to any planning.
The strategy should pinpoint the build process from current measurements of capability to the desired future state, including goals and benefits therein. From this it should deliver the thematic roadmap for delivering the future capability with a clear statement on the scope and objectives of the strategy. It should also recognise and describe that due to the evolution and development of cyber space, emergence of new threats and risks, adoption of new technology and collaboration mechanisms the strategy will be a living document.
Each theme across the strategy should display the as-is and to-be, or current and future states that the strategy seeks to build and a high level view on the supporting aspects for those themes. This includes what those aspects are, how they relate to the overall theme and what the strategy is seeking to do and the wider benefit of those actions.
Within the strategy should be a plan for delivering significant cyber hygiene advances to create and maintain the foundations for the cyber security capability. It should also define a plan for putting in place the building blocks to drive the cyber security capability forwards and a plan for continual maturity development and the importance of continual improvement and evolution.
The strategy should focus on defining and delivering an outcome that both protects the organisation of today and tomorrow and enables the organisation to meet its business vision. Although obviously a security focussed document, the strategy needs to be written in a clear business language. It should demonstrate and understanding of the business drivers and describe how action against the strategy will support those drivers and build speed and agility into the business development. It should define the need for action and the driving forces behind such action, without being wholly prescriptive in how the action will be achieved. It should also display how those actions will be measured to show realisation of the benefits from action.
An often overlooked factor is where the cyber security capability sits within the organisation. Who owns it and is responsible for both its delivery and run. Think carefully about where this should sit, and equally if this is already constrained in terms of existing reporting lines and responsibility. Cyber security is a board level issue and needs to have visibility at that layer of the organisation. An over-bureaucratic reporting chain will not serve the organisation well in understanding the cyber risk.
One thing I would recommend here is including a glossary of terms. There will be numerous occasions within the strategy where cyber security or InfoSec terms are used. It’s almost unavoidable, unless you want to explain each of those terms in train, and as such a simple glossary that translates those terms into a simple language definition can be very valuable.
Remember that the strategy will be a living document and as such will need regular review and iteration to ensure it remains pertinent and fit for the business need.
You will need investment. Even if you are just tweaking processes you will need an investment of time and resource. Your business case should be built from you strategy and written in a way that exposes how inaction will jeopardise the business vision, but that action will enable that vision to be secured. The language and tone needs to be at a business risk level and display that your planning has been thorough and consistent, whilst always reiterating that support of the business strategy.
The business case should display the detail of where your cyber security capability currently lies and how you propose to deliver the maturity required to support your business of the future. If your business has a 2020 vision (a 5 year, or 10 year vision for the future of the organisation) so should you and this should jump out of the business case. Your case needs to draw out the elements of people, process and technological investment and how when coupled together they will bring a robustness to the business’ risk posture. Your business will want to take risks and you must demonstrate how you can allow them to take pragmatic and informed risks due to the fact that you will provide them a thorough understanding of the risks they currently face, and will face.
You should be open and honest that investment in cyber security is not a short term goal. It is an ongoing investment, but that with increased maturity comes a more evolutionary flow rather than revolutionary change. The journey simply never ends, but a more mature organisation will have much more control, much greater insight, a lower overhead in terms of heavy investment and the ability to build coherent business cases built upon the intelligence produced from within the cyber security capability. This intelligence is used to demonstrate the value to the business of such investment.
The business case should detail all of the aspects of your cyber security capability plan for both short and long term advancement. It should be realistic on cost and value to the organisation, including setting expectations on benefits realisation / return on investment, and especially regarding time and materials to build the capability.
The business case should clearly differentiate between the available and proposed options, including the Do Nothing option, and why one option is preferred over others. This may be a highly complex and technical rationale, but must be defined in a clearly understandable language that business leaders will get. At the end of the day you need business leader support and if they don’t understand it they are less likely to support it. It should clearly detail the planning that was undertaken, how it maps to the overarching strategy and how the building blocks and actions from that strategy will be implemented.
Your business case needs a lot of time and effort invested in it. It is what will get your capability build off the ground. It cannot be a ten minute hash job. In times of austerity and where business focus is on financial growth you will have quite a task in building adoption and support of a costly and long journey. Put the effort in!