While perhaps not as headline grabbing as investigating a good targeted attack, this work is a key part of our philosophy and really important. Based on this and drawing on our wealth of experience we are presenting a talk at our upcoming Oasis conference, which will focus on how an organisation can develop this capability in the form of a Security Operations Centre (SOC).
The ‘SOC’ label is widely used for a whole variety of functions. So for clarity we define a SOC as a one stop shop for managing cyber security related incidents within an organisation, ensuring they are properly identified, investigated, remediated and reported.
Identify the threats
To understand the requirements of the SOC, begin by considering the threat landscape. What information held by the organisation would be of interest to attackers? Who are these attackers and what is their capability? Nation states and advanced criminal groups will have a different style of attack and business impact to that of hacktivists and script kiddies. Take into account previous compromises and those experienced by peer organisations.
Secondly, ascertain the risk appetite of the business. Some threats may be acceptable to the business and may not be worth the associated cost of defending. By taking the time to evaluate threat and risk an organisation will gain a vital insight into future attacks and be able to make informed decisions about where best to focus defensive resources.
Determine the end goal
Based on the threat landscape and risk appetite, build a picture of what capabilities the mature SOC will have. A paper from Mitre provides a comprehensive list that is a useful starting point. Prioritise this based on the requirements for your organisation and the threat landscape.
Next, map existing resources against this end goal. Identify the SOC’s level of maturity for each capability, and use this to prioritise the changes and investment that need to take place.
At this stage it is worth identifying any quick wins. Establish what skills the current team members have, and look at existing process and technology. Could the maturity of any capability be rapidly improved through little effort and cost? For example, staff training or logging and analysing new data sources.
Build the SOC – People, Process and Technology
Now that the strategy is in place, invest in people, process and technology to start building the SOC.
People – a fully functioning SOC requires access to people with a range of specialist skills, ranging from network and forensic analysts to software developers and threat intelligence researchers. For existing staff consider external training and encourage knowledge sharing internally. Hire new staff to build the team and fill missing areas of expertise. It is also worth noting that it may not be practical to fill all of these roles on a full time basis – consider outsourcing specialist work such as reverse engineering to a third party who can be called upon in the event of an incident.
Process – The SOC must run like a well-oiled machine, ready to make decisions and take appropriate actions quickly in a high pressure environment. It needs documented processes to ensure incidents are managed in the most consistent and efficient way. On the other hand, the processes must be flexible enough to be quickly adapted to take into account new technology or attack methods and it is not possible nor desirable to have a procedure defined for every eventuality.
Technology – It is easy to throw money at well-advertised out of the box tools, but these are only as effective as the person using them. A useful technology for a developing SOC may simply be a log management platform that collates various log sources in the same place, and facilitates the querying of large amounts of data (for guidance, see CPNI's paper on log management).
Measure success
Finally, how can an organisation measure the success of the SOC? It is notoriously difficult to measure the success or effectiveness of a preventative capability, which can be problematic when justifying the need for investment to the business. Statistics such as ‘number of incidents detected’ are misleading, particularly while a SOC is growing, as new technology and people will change what is considered to be an incident, and results will vary significantly depending on the threat landscape at that time.
Similarly, measures such as ‘time from incident detection to closure’ will vary depending on its severity, who is investigating the alert and the process that is followed. KPIs such as this may actually have a detrimental effect on performance, as staff should not be encouraged to close an alert or incident quickly without thorough investigation.
Perhaps the best way to measure success is to communicate with peer organisations in the same industry and/ or of a similar size, and discuss whether they are seeing similar attacks. Stay up-to-date with security news of attacks in your sector, and consider whether your organisation would have visibility of such attacks and what the investigation process would entail.
Contact and Follow-Up
Kat is a part of our Response team in Context's London office. See the Contact page for how to get in touch.