Managed SOC Market Do's and Don'ts

A few things to consider when approaching the Managed SOC market, firstly it’s a fast-growing market so whatever you do needs to be a differentiator from the rest of the field, probably best answered in part by some Do’s and Dont’s which I can list below:


  • Do scope out the local market, who are the current players, what do they offer, what’s their USP (Unique Selling Point)

  • If you currently operate as an MSP, talk to your existing customers and have a deep discovery session with them around their organisation’s profile, what are their perceived risks and threats, what are their pain points in security monitoring currently (I.E. detection capability, staffing, experience, funding)

  • Do build a list of security threat use cases using the following workflow: Identify risk - create use case - identify required data sources (and validate they can send the required information in the logs) - method of detection - remediation plan

  • Do think long and hard about what your core SOC tool (the SIEM) is going to be, in conjunction with the identified use cases from the step above, which vendor platform will meet those needs (Hint: A SIEM that uses basic correlation won’t cut it). You will need a combination of static correlation rules, machine learning and behaviour analytics

  • Do take considerable time looking at how the SIEM vendor charges for their solution, I’m going to go out on a limb here and say that vendors who charge by ingestion are going out of fashion due to unpredictable costs which result in customers having to reduce log source scope due to costs, far better to have a per user priced vendor, but do be aware of buying a solution that is constrained by sizing, e.g. can only handle X EPS (Events per Second) or X GB or TB per day unless it is fully scalable and cost effective to do so. NOTE: Be very wary of vendors who will deliberately undersize just to gain business!

  • Do plan for Automation - I’m not just talking about post-detection and alert automation (E.G. SOAR), you should be looking at a SIEM that performs automation of the events that triggered the alert, there’s no value in having an alert trigger if the analysts have to then go and piece together all of the activity that led up to the alert

  • Do consider how you will handle multiple tenants (customers). Not all SIEM’s are capable of multi-tenancy and in fact, make sure you understand what multi-tenancy really means, there are many options including; single platform - multi tenant - SPOG (Single Pain of Glass) dashboard/view, single platform per tenant - SPOG, single platform per tenant - discrete dashboard per tenant, and probably a few iterations of these.

  • Do think about what the SIEM platform will be - Physical appliance, virtual appliance or cloud based. Both physical and virtual appliance based bring challenges and costs associated with physical data centre racking or VM hosting, these are harder to scale and some vendor solutions need dozens, if not hundreds of appliances. Cloud hosted solutions are the way forward, the management costs such as hosting, upgrading etc. are encompassed in the solution cost by the vendor, native cloud solutions can scale automagically as you or your customers grow or see burst activity due to incidents etc.

  • Do ensure you have robust People, Process and Technology within your SOC, the right people doing the right job, with the right tools following clearly defined and most importantly, repeatable processes!


  • Don’t think you can offer a Managed SOC service where you simply ingest all of your customers data sources and expect to find stuff. This is absolutely 100% the wrong approach and you will fail. You should use a use case driven approach as mentioned in the Do section. Those use cases should be repeatable across all your customers, about 80-90% of all use cases apply to all customers, the remainder is for bespoke customer specific use cases

  • Don’t skimp on resourcing, there are many roles you need to have to run a successful MSSP SOC, from Tier 1, 2 and 3 analysts through to threat hunters, content engineers. You may not need them all at once, build out as you grow but make sure you have enough physical people to perform all the roles required from day one

  • Don’t overload your staff! In conjunction with a fully optimised SIEM solution and the correct number of staff you should be generating no more than 10 incidents per analyst per day/per shift. That figure even then only allows 40 minutes per incident for investigation, triage and mitigation. Alert fatigue is the number one reason why SOC’s have such high staff turnover

  • Don’t expect your analysts to come to the same conclusion when faced with the same alert! Use clearly defined processes and playbooks to ensure you achieve the same repeatable outcome each time

  • Don’t build your MSSP SOC on top of your parent organisations infrastructure. An MSSP SOC should be on it’s own network and infrastructure

  • Don’t build your MSSP SOC in the corner of an office! It should be a dedicated facility with proper segregation and access controls. A dedicated SOC should have a main SOC room preferably with decent wall mounted video screens showing primary SIEM information, one screen with a news channel feed, decent lighting with limited inward visibility from external windows. You should also have a dedicated war room, an isolated malware analysis lab (if that’s a service you offer) and if you can accomodate it, a limited viewing area for prospective customers (just be mindful of what can be viewed from that position)

I’ve been lucky enough to work for and with MSSP SOC’s from small state based providers through to huge global American based telecoms giants, from Australia, throughout Asia and the UK and USA too.



Please post your comments, ideas and suggestions below.