When it comes to the cyber security specific elements there is a whole construct to define. Who, what, where, when, why and how. The hygiene gives you the foundations; a sure footing for the organisation from which to build a capability.
That starts for me with the core mission, vision and values for your capability. What is it you want to be and why. Pardon me for getting a bit fluffy and Corporate Communications, but I really do believe it is important to set out core principles for any capability. Believe it or not your adversaries will have a mission. It may, or may not be documented, but they will have a mission. So should you!
The mission statement is a succinct definition of what it is your cyber security capability is there for and supporting that is your vision that provides more depth to the mission; A bit more of the how to support the what.
Under that should be your values. These set out the core expectations for your capability and your team. These are the principles that you will work to and should be defined in a way that brings an affinity from the team. The team must buy in to the mission, vision and values.
You need to define from the outset what the scope of your capability will be. Without a clearly defined scope you cannot be sure of what you are building. This helps define the boundaries of what you want the capability to cover and importantly what it will not do.
The objectives detail at a high level what it is you want to achieve for the organisation. This should be a more detailed build on the Mission and Vision, giving more depth to those statements, breaking them down into their fundamental elements. This forms the core of the what element of your cyber security capability.
The design principles draw out the blueprint to which you will build to and should map closely to your Scope, Objectives and of course will feed in to your requirements. You should detail elements of the build standard, for example retention models, storage principles, staffing principles (in-sourced, out-sourced, hybrid etc.), phasing etc. These are the elements that bring consistency to the build process.
The capabilities define the next level down of what the capability will actually do. You have a Scope and Objectives and the capability again draws out the how you will achieve the what of the objectives. It’s still pretty high level, but iteratively you are starting to define the actual construct of this capability in its entirety.
Taking the scope, objectives, design principles and capabilities outlined above you can now get into the meat of your requirements. The requirements is where you really start adding depth of what it is you want in order to achieve the overall objectives. This is where you define the functional and non-functional elements to actually build your cyber security capability. What is it that you need in terms of people, process and technology, as well as locational aspects, resilience, support arrangements, data sets, analytical components, skills etc.? In simple terms what is the need for this design in order for it to perform what you want it to. This is what you will use in order to design the development of this capability.
Think about those high level requirements.
- Data feeds – both internal and external sources of useful data / logs and their respective value. Which data sets do you want?
- Data acquisition – How are you going to get the data and in what timescales (e.g. real-time?), what format?
- Data processing – correlation, indexing of raw unstructured data. You’ll probably be taking lots of data from different and disparate sources and you need to make sense of them in a structured way to make analysis easier.
- Data storage and retention – How long do you want to store your data for? Bear in mind some data is very large, and different data sets have different value over time. Think about how long you will want to keep each log type for. Are you going to have different regimes for near and long term storage? Equally different storage for the results of investigations, adversary knowledge and campaign information?
- Data integrity and security – how open do you want access to your data to be? This could differ depending on which data it is. Raw data might be more open, whereas the results of worked data, and incident analysis might be more sensitive and be treated as such. Equally do you have any requirements to store data in a ‘forensically sound’ manner?
- Detective and preventative controls – what have you identified as being required to improve your cyber hygiene? This will be a mix of people, process and technological advances and should be factored in from the outset.
- Analysis – this covers many aspects, so best to break it out into subsets. There is obviously core SIEM type analysis at a high level, but you’ll also need to consider more in depth analysis such as forensics and offline malware analysis.
- Alerting and prioritisation – You cannot treat every event as critical so you will need a way of prioritising events from the outset. Consider business criticality of the exploit target, whether system or person. You will need the ability to alter these priorities as your analysis history grows and you learn more about the risk exposure of systems and personnel and the sophistication of your adversaries. The more persistent and sophisticated the adversary, the higher the priority.
- Tooling – What additional tools have you identified for the analysts toolbox? Do you know them even thematically?
- Availability – Both for data streams and core analytics platforms. How critical are they to your mission? Consider also Disaster Recovery (DR) & Business Continuity (BC) requirements. How resilient do you need this to be at a component and overall capability level?
- Personnel – What people do you need and for what purposes; how does this differ from what you already have at your disposal? What training and up-skilling requirements will you have?
- Environments – What will you need in terms of Dev., Test, Clone etc. and for what purposes?
- Knowledge management – You will need a form of knowledge management / knowledge base to store known components of previous analytical efforts. This is vital is being able to draw out elements of each attack and then finding relationships between them. Otherwise you will continue to treat each event and attack in isolation. This could include an indicator database for storing and referencing ‘Indicators of Compromise’ (IoCs) etc.
- Ticketing – You’ll need a form of ticketing system to work your events and incidents. If this forms part of a wider ‘helpdesk’ ticketing system do you need to restrict visibility and access of your security events and incidents?
- Location and physical security – Where will your capability be housed and what requirements do you have for physical protection and segregation?
- Reporting – To whom and what are you going to be reporting? This could well be varied depending on the depth of your stakeholders.
- Collaboration and partnering – Is there a need to collaborate, either with internal teams or external partners? What requirements do you have in this space?
These are just some top level requirements to consider as part of your requirements gathering. Some of which you may already do, but you need to bring it together and consider how you might need to couple elements to get the most out of them. One thing I would call out here is that you should focus at a high level on what your end state is. You should be looking to build towards your target capability. You are bound to build iteratively, but any interim phase will still be putting the building blocks for your target build.
It helps greatly to represent how your cyber security capability will operate. It breaks down the overall construct into functional elements which should couple together to define the whole. I prefer this as a visual representation of your capability in terms of what it is looking to achieve and how the elements couple together to display that.
There are many ways to build this, and one I really like is using it to display the as-is position and then the to-be. This can be a very useful piece in building backing for your case as business leader can visualise what it is you are seeking their support for.
When it comes to your cyber security capability you need to define and document the thematic construct. What it will do at a high level and how these elements fit together. You can break these down into core elements. They are not the team construct, or who does what, but form an overall picture of what the capability in its entirety will cover. From this construct you can determine which areas are stronger or weaker than others at present and the maturity path for the whole. For example identifying where you need to mature in one area in order, or prior, to build another.
Below is a simple example construct bringing out the thematic elements you should cover off in your capability design. It is by no means exhaustive, but should give you a starter for ten.
Break down the components of your capability to understand the next level of detail of what you will be doing across the cyber security team. This gives you a good mapping of your overall structure, which can then be used to revisit your Scope, Objectives and Requirements to ensure you have not strayed from your core principles, but also ensure you have everything that you need in order to design and build this capability.
You do not by any means need to follow this construct, but I would recommend logically grouping functions of your capability to better understand the overheads and synergies. You will need management and leadership, alongside operational management and tasking. You will need to manage data assets, feeds, storage, security etc. There will be a core SOC type capability; this is the heavy lifting aspect of your capability and sits right at the centre; the bread and butter of cyber security if you will. You will need to undertake protective actions and therefore change management and feedback loops as well as reporting at various levels. You will need to maintain and develop strategies, both at the top level and sub-strategies for different aspects of your future planning. You will need a risk function, building and conveying a rich picture of your organisational risks in cyber space. Advanced analytics should be a quorum within your whole capability as well as a continual drive for improvement, development and engineering. You should be iterating rules, tuning controls and looking for future enhancements on a continual basis, built from your analysis and understanding, and of course you will need an incident response capability.
These do not need to be separate entities and may well be blended when you look at the organisational construct, but I find it best to separate them out from a capability viewpoint.
Underpinning your capability construct is the processes, at various levels, and procedures that define how these capability elements will be carried out. You can take these all the way down to desk level instructions for particular items, though this is an iterative construct as you get to each level of process. The processes lead into work instructions, or procedures, that the team members will follow. My favoured way of doing this is through the team members themselves. They know their job better than anyone and should be best placed to define how their work should be done.
You can take processes to whatever level you want and get really detailed about it, but bear in mind that the more detailed your processes and procedures are the more likely you are to have to change them as you evolve.
I’m not one for having death by process, but equally I’m not into flying by the seat of my pants every day. You need to find the right balance for you and your team in terms of depth of process and procedures. Where depth can help is in bringing through new members, who will have clear instructions as to what they need to do, until of course they come across something that does not match the crib sheet.
Overall these elements, Mission through to procedures, gives you the detail of what it is you are trying to build and why, and of course how it will actually work. This will all fit in with your strategy and business case, albeit you will not have all of the depth at the business case submission, but will have the high level aspects of the above included. Your strategy should get nowhere near process and procedural levels, but should include, thematically, a narrative that supports the mission and value, and vice versa.
Build in the structure of your team, how it hangs together and for what purposes. You’ll need to build in compliance and investigation, research and intelligence, development and engineering, vulnerability and penetration testing, incident response planning and co-ordination, collaboration and partnering, reporting in various forms. There is no right way to put the team together as it is what works within your organisational construct and parameters, but ensure you cover off these bases elements, and build in flexibility to ensure you can meet demand in any facet. You should also consider moving analysts around so that they get experience of the bigger picture and an understanding of the whole team ethos and mission in action.
You will need a strong leadership team, able to make instinctive decisions where appropriate, but feeding from the investigation artefacts developed across the team. They will also need the wherewithal and experience to represent the cyber security team in many differing aspects, be it internal management, board level discussions or through partnerships and collaboration. It serves no good to have a fantastic capability that loses all credibility through poor external representation.
When you look at your team structure, or organisational construct, it is a good idea to pinpoint your priority recruitments. Which areas do you need to fill first? If you are starting from scratch you should prioritise your leadership and traditional SOC roles. In the early days you will be heavily focused on the SOC elements as your visibility grows and you work the inevitable volume spike of events. It is a common occurrence that early on you will have a significant spike of events to investigate. Over time, through knowledge build and tuning this volume should plateau and you may have the opportunity to re-provision some of your resource into other facets of your overall capability.
Although the SOC aspects will be your prime initial focus you should also start to build the other aspects of your capability. Think about the introduction and gradual build of your intelligence, research and engineering cadres. I’m a big fan of having control and think you should look to develop your engineering arm from the outset as you will want to be tuning rules and implementing defensive actions from the start. This will help in smoothing that initial volume of events.
If you build it they will come! To undertake all of the above you need to right environment and infrastructure. Think about what you are asking your cyber security capability to do and why. What they have access to and how sensitive it is. The environment they work in needs to be fit for their needs, including if your capability spans geographic regions. Communication and collaboration is key and needs to be factored in, alongside growth (back to the strategy and business case again). Think about the physical environment and how it should be protected, accessed, if it is overlooked, separate office etc.
From an infrastructure perspective of course you’ll need a plethora of security controls, all with the ability to send data and also receive data to implement courses of action. You’ll need that hub SIEM type functionality at the centre. You’ll also need analytical toolsets, storage (lots of storage), a knowledge base, wiki, ticketing system, forensics and malware tooling, sensors (custom and COTS), the list could go on and on and will as you develop a greater understanding of your gaps in visibility and capability. Some solutions to this will not exist, so you’re going to have to build them yourselves, or even if COTS customise them greatly (see skills). There is a huge amount of data analysis to be done here and you should identify opportunities for automation to reduce load from your analysts and ensure they are focussed and active on the human aspects of analysis. This isn’t about reducing your headcount, but enabling them to be of greatest value by removing unnecessary overheads where possible.
You will also need the right logical environments to undertake this work in. Live of course as that’s where the action is, Dev., Clone, Sandbox etc. and the ability to transfer things between them in a safe and secure manner. This all needs to be factored in to that overriding journey to cyber security maturity.
Combined with this you will need to bring in the right data sources for correlation and analysis. Some of these will be very heavy and have differing levels of value. You should identify the highest value sources and bring them into centre pragmatically. Things like DNS, authentication and login, security appliances, DHCP, web proxy, email etc. have strong value and should be high on your list of data feeds. You should develop an ongoing programme of data feeds into centre.
From a business case perspective you need to build these in, recognising that you will have an operational run budget, but also Dev. and build budgets to consider.