4 pitfalls to avoid when building a CSOC
Setting up a new Cyber Security Operations Center (CSOC) within your organisation is a big step in increasing your incident monitoring and response efficiency, providing you can avoid the following mistakes:
1. Putting technology before people and processes
We’ve all been there: new technology is released that is promising you and your CSOC team the world: better detection rates, less false positives, more visibility, better intelligence, etc… You’ve seen the demos, did the Proof of Concepts and you feel convinced and ready to buy…
But first also consider the operational cost of running and maintaining the new solution.
Don’t get me wrong: technologies like SIEM, Breach Detection, Advanced Endpoint Protection and Live Forensics can help your organisation quickly and efficiently detect, block, analyse and remediate attacks, but they also require:
Sufficient CSOC personnel with the correct skill-set and free time to use the solution, interpret the results and update the rule-sets, filters and Indicators of Compromise.
Sufficient CSOC and IT personnel to handle the extra events generated by new technology.
Sufficiently documented CSOC processes regarding incident detection, management and response.
Without these key resources, your new investment will not provide you with the expected results.
2. Doing too many things at once
Most organisations have a limited budget and limited resources assigned to CSOC activities. Most CSOCs perform some form of incident monitoring, analysis and remediation tasks. Other tasks like manual intelligence gathering and advanced malware analysis can also be helpful to detect and respond to very advanced attacks, but these require a lot of resources or require people with a very specific (read: expensive) skillset. It might not be realistic to incorporate these tasks in your CSOC’s daily activities, without sacrificing some of the more “basic” capacities.
However, most of these “advanced capacities” can be outsourced or automated in one way or another, eliminating the need for specific CSOC personnel to execute this task. For intelligence gathering, there are free and commercial threat intelligence feeds you can hook up to your SIEM. For automated malware analysis there are free sandboxing solutions like malwr.org and Cuckoo. For manual in-depth malware analysis, it might make more sense to hire an external malware analysis resource when you need it.
What your CSOC does internally and what will be outsourced or automated will depend on the budget, the maturity level of your organisation and the skill set of your CSOC staff.
3. Starting without corporate buy-in
Your CSOC needs executive support to be able to do its job properly. Endless discussion can arise about what the CSOC is or isn’t authorised to do, especially when a major incident occurs. A good example is whether or not it is allowed to disconnect an infected machine from the corporate network.
You can prevent this from happening by creating a CSOC charter, which is basically a policy stating what tasks the CSOC is authorised to do and the resources and efforts that are expected from the other departments. This document should be formally approved by the top-level executives.
4. Lacking a playbook
All tasks within the security incident handling process should be formally documented beforehand. Don’t fall in the trap of starting to document only when an incident arrives!
There have to be step-by-step guides on how to perform incident response tasks for your team, for example how to detect C&C connections using a SIEM or how to perform a reinstallation of an infected workstation. A good format to use for this type of documentation is the incident response playbook.