Security operations centre (SOC) buyers guide

Security operations centre (SOC) buyers guide
This guidance is for organizations that are considering procuring a Security Operations Centre (SOC) from a third party. It is equally applicable for those seeking to establish their own in-house SOC. It summarise's the core functions of a SOC, and includes the different deployment options available, the SOC lifecycle, and other high-level considerations.

What does a SOC do?
The key aims of a SOC are:

to detect and respond to threats, keeping the information held on systems and networks secure
to increase resilience by learning about the changing threat landscape (both malicious and non-malicious, internal and external)
to identify and address negligent or criminal behaviours
to derive business intelligence about user behaviors in order to shape and prioritize the development of technologies

Why might you need a SOC?
Some examples of why you might need a SOC include:

you are running an online service for the public
you host a number of sensitive databases which are accessed by staff on your premises, by remote staff, or by customers or partners
you have several different office locations and a unified security function delivers cost savings
you share large quantities of sensitive data with other organisations
you require a single point of visibility for all your threats

What type of SOC is best for you?
SOCs come in a variety of flavours and can cover the entire incident management process. This can include:

integration, management and review of traffic feeds
protective monitoring
initial triage and analysis
vulnerability management
alerting and response
incident management
root cause analysis
patching & remediation
correlation management, Security Information and Event Management (SIEM) tuning
continuous improvement
key management
The functions that your organisation require will depend on a number of factors, including but not limited to:

your budget
whether or not you choose a third party supplier
your willingness to share your information feeds with a commercial supplier
your own willingness/capability to perform forensic investigations
how you manage business continuity
whether you need an on-premise or an off-premise service (or a hybrid of the two)
if you outsource your SOC, it will likely be multi-tenanted. This means that any threat intelligence generated from your data feeds will be used to improve the service delivered to other customers. Consider the sensitivity of your data, your requirements and whether you'd be comfortable with a multi-tenanting arrangement (noting the higher costs of a dedicated service and the potential benefits to you derived from being a co-tenant).
how well you know the range of threats posed to your organisation
whether your requirements are unique - a generic service may suffice if your requirements are typical of other organisations

Top tips before you start
When defining your SOC requirements, we recommend you consider the following:

Logs are not an end in themselves. It’s tempting to think they are, but it’s the way they are correlated that provides the power of a SOC. Logs must be collected, aggregated, analysed, stored and minimised. Most importantly, they must be available to your SOC at all times.
SIEM is not a panacea. Be wary of any supplier that tells you that security information and event management (SIEM) is a panacea for all your analytic needs. Good SOC analysts don’t develop anything in the SIEM until they've proved an idea using scripts and logs first. A good supplier will have a content development checklist and a standard process for proposing, justifying and implementing rulesets in your SIEM.
Don’t assume your business wants to hear what the SOC finds. Your SOC has detected something; who will care and what you do next? Work back from the end of the incident and verify you can achieve each stage before levying a requirement upon your SOC. Ensure the action you wish to take is legal and covered by internal policy.
Review regularly which SIEM content is providing benefit, and use stats to justify its existence. Your SOC is an invaluable source of business intelligence and management information.
Establish the basics. Don't bother with advanced concepts until you're confident you have the basics covered. Expensive and complex SIEM tools are all the rage, often the temptation is to jump from zero to 'behavioural analytics' using an expensive SIEM that nobody understands properly. Well trained and quality staff are crucial.

A secure SOC protects itself
An SOC exists to help manage your risks more effectively, which means the SOC itself must be protected adequately. A SOC must have mechanisms, processes and procedures to ensure that it can protect itself against threats comparative to those being faced by its customers. This includes protecting the service itself, and also the data within it.

The SOC provider must be able to demonstrate that they understand the architecture of their monitoring system. A supplier ought to be able to provide documentation to include:

an overview of the system elements, such as perimeter, host and network, and specific application-based agents
clearly annotated network diagrams, which demonstrate a comprehensive understanding of how the SOC architecture is designed and managed
related technical documentation which demonstrates how architectural components are used to actively monitor the environment
mechanisms for managing the control of privileged user access
the monitoring and control of privileged user access, demonstrating an understanding of who has access and their activity
which parts of the architecture allow for automation, and which parts require analysts
descriptions of what the sensors within the monitoring service actually do

Feeding your SOC
Where will your information feeds come from? What inputs will you feed into your SOC? It depends on the kind of services you are running, but it might include:

data from the organisation's vulnerability management
records of high-value database commands
requests made to your web servers
records of high-value privileged administrator commands
outputs from web content filters
logs from the mail gateway
logs of DNS requests made by your internal systems and servers
logs from your federated authentication system
if you use cloud, you may need to incorporate any alerting provided by the cloud service into your SOC, e.g. breaches of Data Loss Prevention policy
A fuller picture of the logs and other outputs which can feed your SOC are shown below. Discuss with your supplier how you will determine which inputs are required to deliver the best service to your business.

AWS Partner Network
PCI DSS Compliant
PCI DSS Certification
NASSCOM Emerge 50 Awards