Just a quick side note, if you’re struggling with any acronyms or understanding of phrases, my Jargon Buster should help, but if not please do reach out to me.
As a follow on from the post around the purpose of a SOC, here, I want to discuss a bit more around the react and respond approach within a SOC and some recommendations of improvement in order to become more proactive and preventative. I feel that a SOC should be driving towards this approach in order to stay ahead of the game and show their worth and qualities.
I am taking a very high level approach to this and aiming to cover all angles. Your SOC may have some of this already, you may have things that are not on the list, or you might not even be in a SOC!
Each SOC will have some operational element of reacting and responding, just different parameters exist. This is shown in the different types of SOC out there. There are numerous variations but I’ve collated what I feel are the main types.
The main types of SOC Available:
Virtual SOC
A virtual SOC (VSOC) is where team-members are available/activated in case of an alert or critical incident. These are not permanent SOC staff so constant eyes-on are not present.
Dedicated SOC
An in-house, dedicated team of SOC staff. This is typically an internal SOC to an organisation. A dedicated SOC would normally be 24/7 as well to ensure an eyes-on approach is adhered to.
SOC and NOC
This is a hybrid between SOC and NOC. Though it can be rare and unheard of, it is out there. NOC activities usually cover system performance via proactive monitoring, data protection and replication/backups, security profiling including patching and more.
Next-gen SOC
A next-gen SOC would typically take over the traditional function of a SOC. The extra features can include more dedicated incident response, forensics, threat intelligence and so on. Having said this, there is still a need for the actual SOC monitoring so this does still happen.
Outsourced SOC (MSSP)
This is where an outsourced managed services provider provides a SOC service for others to purchase. The role of this SOC is to then look after other organisations’ security monitoring and response from a react and respond perspective. This is sometimes a more feasible option as an MSSP takes on the responsibilities that an organisation can’t handle, such as the need for 24/7, wages, tools etc.
Reacting and Responding
When we refer to react and respond, it typically comes down to the continuous monitoring aspect of the SOC. What I mean by this is your technology is in place, your alarms are firing and your analyst(s) are reacting and responding to said alarms.
Reaction covers meeting the SLA’s and then triaging the alarm to determine its severity and if it is in fact malicious/suspicious or not.
The response side of this comes from taking appropriate actions. This could be blocking an IoC, engaging a client or stakeholder, isolating a machine from the network and so on.
These 2 functions are the primary aspects of an operational SOC and it is present in each and every SOC, but in different forms – such as different SLA’s, processes, availability; but when you look to the core of it – these 2 feature always.
Proactive and Preventative
Being proactive and preventative will not replace the need for reacting and responding, it’s a given as a SOC requires it for it’s purpose and function, however it is a necessary add on that should be utilised a lot more than it is now.
Where your traditional SOC encompasses the reactive and responsive actions, I feel this is what keeps the SOC held back and just doing their normal job and remaining neutral. But adding value to that service is what clients and organisations want to see. They want to be getting more for their money whilst ensuring it’s the right option for them, so why not improve the SOC and yourself by being one step ahead in the game.
Put your mind into that of a hacker and incorporate an element of threat hunting and threat intelligence and try to beat the hacker to your network by preventative and protective measures. Network with others and follow relevant sources who post about this stuff so you can cross reference it in your network and clients networks if applicable. Setting up RSS feeds is a good start point for this to get feeds into your inbox to whilst you can scan for relevant information. You can then start to expand this as you grow as an individual or SOC.
Recommendations
I want to discuss some floating ideas of how reacting and responding can be improved. As it’s a broad area, I want to target the not so prominent points.
Improve visibility
I think this is one of the biggest aspects in order to improve. Don’t allow analysts to become tunnel-visioned into a toolset and or inbox. Allow them visibility of what’s going on, to be proficient in the toolsets, to possess autonomy. From this, it is equally important not to overload. Some MSSP’s have upwards of 10 SIEMs, 4 inboxes and so on and it is just overloaded to the extent that you cannot do anything else due to the strict requirements set by these things.
React & Respond vs Proactive & Preventative
Without removing the reactive and responsive side to things, try to drift from being fully operational in this area so you can allow the growth in to a proactive and preventative approach. Having the ability to be one step ahead is critical in cyber because you may be able to stop something before it even happens. This adds value to the analyst, their role, and also the organisation you’re supporting.
Orchestration and Automation
Similarly to the above point but to work on fine tuning and spotting patterns and trends so you can begin to filter these out. By doing this you are allowing more time to do proactive and preventative as opposed to constantly reacting and responding to the known false positives. Another quick win on this is your SIEM saves space! Every cloud.
Analyst and SOC Goals & Achievements
A couple of pointers in this section.
Firstly, implement personal development plans and project tasks for analysts to work on. These projects would typically benefit the SOC as a whole as you’re working on something in particular. This could be setting time aside to implement orchestration rules, looking in to implementing a solution to target an issue, and so on.
Following on from this, I feel that it is extremely important to have stats and metrics. Without these, how are you going to baseline/benchmark and improve? So, improve the times on react and respond actions by implementing SLA’s to activities and measure against this (create a swanky little dashboard that captures this), implement automation and orchestration for accuracy and to show your work, set expectations across analysts too. Setting these expectations and goals allows the SOC to showcase their work, their efficiency and impact to the service and it can be used in prospecting new clients. But most importantly, you see both the positives and negatives and it gives you plenty to work on in order to improve.
Lastly, I think it is important to aim to improve monthly from the metrics mentioned above so you can showcase these improvements to the business, new clients, and even your analysts; whether it be in 1-2-1’s or SOC meetings.
Cyber War-gaming
War-gaming is a good way to test processes and responses to particular scenarios. Both analyst and client/organisations benefit from this because it is an ethical approach to identifying any holes in your posture.
Types of activities could include DDoS response, Major Incident response, phishing incidents and containment, Ransomware Incident Response.
You’ll notice they’re pretty much all response right? This will not leave a SOC. The point I’ve tried to make around proactive and preventative is to put measures in place for this kind of activity. For example, but not limited to:
– Firewall/IDS/IPS thresholds or even re-routing/blackhole for packets to stop a DDoS attack
– Stakeholders and process/runbook documentation for Major Incidents – What defines a major incident for this client/organisation?
– Email and spam filtering, whaling configuration, any IoC indexing, thresholds etc.
– Network segregation, tools in place for containment, knowledge or processes for containing the threat, DLP solutions including backups.
It’s the extra steps you take which can really define your security posture so you’re in a comfortable position in the event of a cyber attack.
Communication
Perhaps the most important and overlooked aspect.
The SOC team must communicate with the wider audience, the organisation/clients it is looking after. I always make a point to speak with people outside of the SOC and help where I can, ask for their help, get opinions and thoughts because you can start to use this in your work and proactive approaches. You also get the word out there about your role and what you do and how you’re the “eyes watching them and what they do”.
The cliche is that SOC operates in a silo and that we don’t like to communicate much but it should be the complete opposite. Security is paramount if we want to ensure the safety of our own staff and clients and by changing the perception of how this department is seen is key. One of the other problems is that most don’t actually know what the security team does, so more reason to raise awareness and give tips on how to remain safe.
This topic really is a rabbit hole and I could get lost talking about it for a while so, I’m going to be leaving this as is present.
As always, all feedback is welcomed and I hope to hear from you. If you have any questions or concerns, please do reach out to me.
Dan.
Steel Cyber Security 