A SOC is cooking - with a sprinkle of Machine Learning and SRE

This week sees the start of an exciting new chapter in our ever-maturing InfoSec story, with our Group Security team forming a new Security Operations Centre (SOC).

It has been founded using key staff from our existing Network Information Security (NIS) and AppSec analyst capabilities and I believe we are taking an interesting approach to the its creation that sees us using our ASV (Surecloud) as our first internal SOC client:

The rationale is simple - Surecloud's consultants are tasked with poking and probing our applications, network and supporting infrastructure (all BAU as part of our PCI-DSS routines), and our SOC is challenged to be able to report back to the testers what it is they did.

To achieve this the new SOC team has been empowered (provided time, creative freedom, engineering resource access and budget) to architect whichever technical solution(s) they require to be gain the required insight, and so a Red/Blue team dynamic is born between 'them' and the 'outside'; a relationship that through regular iteration, investment and evolution will result in continual improvement and maturation into the best SOC capability our Group of brands will require.

Sounds easy but of course there are many key steps required to enable such insight, intelligence, alerting and reporting, and we are only at the start of this journey.

Whilst we have mature SIEM and other InfoSec solutions in place that are backed by external SOC centres, we felt that an in-house SOC capability be an important new string to our Security bow. Having internal SOC staff able to directly converse and share their dashboards with our technicians, engineers and product owners at a level that is both application-aware and 'trusted' breaks through the restriction a 3rd party SOC may be held back by as a result of distance. An internal SOC also offers faster remediation where human effort for remediation is required. However, our aim is for human intervention to be minimal and for automation to run the ship...which brings me on to the flip side of this coin...

Machine Learning (ML)

Our SOC - whilst modest in headcount - will initially be supported by a mature L1 NOC, brand teams of on-call Engineers, Operations Technicians and Incident Response procedures driven by Service Delivery Management.

Whilst not quite operating within the aspirational Google 'Site Reliability Engineering' (SRE) model of engineering, all of these supporting functions do a great job of keeping our brand's services available and responsive for our customers.

However - and paying attention to SRE's teachings - we wish to maintain a lean SOC team that is reliant on automation, and it is here that we believe ML will play a key role that can ensure we are able to remain lean but also be highly effective.

As you may imagine, a Group of our size generates an array of data that is rich food for a SOC that aims to be supported by a ML capability. The sheer data volumes dictate that signature-based and algorithmic detection won't offer sufficient protection and SOC insight. A SOC built upon the guiding principles of SRE and supported by ML (yes, I know I'm a keen user of acronyms) will ensure that SOC investment remain appropriate and service level objectives be met. Happy Tech. Happy Business. Happy Board.

So there's our vision - SOC aggregation of Group data with intelligence resulting from machine learning, fed into SRE-backed remediation practices.

Here's to making it a working practice.