SOC Planning – Defining SOC Scope
Defining scope for the SOC is crucial for its success and to determine stakeholders for the SOC. The scope will help determine cost, associates needed to run the SOC, SOC processes and many other areas as listed below:
- Coverage – Decide which areas fall under scope of the SOC (IT, OT, IoT, Physical Security, Cloud Service Providers. Others).
- Incident Handling – Demarcation of where incident response will be handed over to other IT/OT/Physical security teams and which parts will be covered by the SOC staff. This will also help in determination of who needs access to incident management application.
- Incident Handling Support – Which part of incidents will be outsourced to third parties, if any. For example, if the SOC does not include building in-depth forensic capability, it can be outsourced to a third party for major incidents.
- Managing SOC IT Infrastructure – SOC team manages security applications including SIEM and security tools. However, IT infrastructure is needed to run these applications and tools. Decide who will manage network, storage, server Operating System for SOC IT infrastructure.
- Governance – What is the governance structure and what other teams are involved. Especially who approves processes for incident handling when people outside SOC are involved.
- Connection with Outside Parties – When outside parties like press, communication, law enforcement are engaged, who will establish relationships with these outside parties.
- Data Collection Scope – What is the scope of data collections including logs, netflows, threat intelligence, physical security and others. What is in scope and what it not included in the data collection. If Cloud environment is in the scope, what data can be collected from the Cloud Service Providers (CSP)?
- Vulnerability Management – Who manages critical vulnerabilities, from scanning to prioritization to patching.
- Threat Intelligence Gathering and Use – How threat intelligence will be gathered and utilized (internal or outsources/purchased).
- Processes – Define which processes will be part of SOC and which will be excluded. For example, is SOC responsible of education and awareness, pen testing, or patching? Depending upon organizational structure, these and other security operational processes may be part of SOC or outside of its scope.
- Single or Multi Site – Large organizations may have more than one SOC. In case of multiple SOC situation, define geographical or organizational scope for each SOC. Also define collaboration mechanism and resource sharing among multiple SOC environments.
- Compliance – What role SOC has in achieving and maintaining compliance with government and/or industry regulations.
This seems quite a lot of work but defining the scope is crucial part of a successful SOC foundation. Writing down the scope document and getting buy in from stakeholders will go a long way to avoid problems during SOC implementation and operations phases.
For a broader overview of SOC, plate take a look at What it Really Takes to Build a SOC and other references below.
Your feedback is very important to me. Please share your thoughts on my Twitter handle at @rafeeq_rehman
References
