Building a SOC in 2024

I always loved to hear about Allie Mellen from Forrester when she presents her insights on some security operation topics. Last week, I could not succeed in watching the Linkedin live event about Building a SOC in 2024 but I could catch up with the Youtube replay of Cloud Security Podcast few days after.

In this podcast episode, I found some points of view so inspiring that I decided to write an article about it, but from a #SOCplatform vendor perspective. The topics below are some ideas that were discussed and that were the most interesting for me but I strongly invite the reader to watch the podcast to get the real statements from Allie.

1 - XDR is valuating EDR telemetry but not only

Allie presents the difference of scope of application between EDR and XDR and explains XDR covers a larger scope but still leverages EDR telemetry.

That's very true, in Sekoia.io we can detect threats with the ingestion of many datasources, but one brings a huge value, it's the endpoint telemetry. Combined with events from other datasources, it brings a good visibility on what's going on, and allow to detect huge threats or low hanging fruits alerts.

To give you an idea, over around 1000 prebuilt detection rules, about 50% will be leveraging endpoint telemetry and the MITRE ATT&CK matrix coverage is pretty good just with this kind of datasource

2 - AI can be used better

Allie says that the use of AI as a marketed term is used much less than one year ago because marketing over-promised and products under-deliver.

Indeed, #GenAI is not good everywhere, but for some specific use cases, it rocks.

Summarizing reports is great and efficient for GenAI, it's a perfect field of application.

But an other aspect is mentioned by Allie as well, leveraging AI to understand alert content better such as command lines. The capability to give more explanability on alerts is very interesting for GenAI and indeed, this feature can bring the analyst to understand better what he has to deal with

Instead of having a AI tool ready to serve any chatbot question, Allie insists on having AI being integrated into the analyst workflow for the different tasks he has to work on

The integration of AI into the analyst workflow is much valuable than generic question bar where an analyst does not know where to start. In Sekoia.io we follow this approach where AI is leveraged on some precise tasks.

3 - SOC jobs evolution

Some CISOs says security analyst have the worst job, and the security vendors should improve the analyst experience to make the job more meaningful

I can't agree more! A product should focus first on the user using the product. This is obvious but we sometimes hear weird feedbacks about products not thinking about practical SOC use cases.

AI won't replace SOC teams to automated response

In our approach, different AI assistants are very specialized on single tasks only with one simple goal: optimize the time of the analyst to do faster or understand better but one thing is clear: they stay in control.

We need to tear down the Tier-1, Tier-2, Tier-3 model

Allie states that this legacy approach does not help younger analysts to progress easily in their career path. The entry level has also to sustain the most repetitive part of SOC activities leading to burn out or disinterest in the field. This cannot be accepted regarding the superior interest we have to keep enough defenders to protect our companies, our economies, our democraties!

Whether companies to use this Tier approach or a more flattened approach based on collaboration, in Sekoia.io, you will find pre-built roles and fine-grained permissions to create your own. This will allow to create the roles that really fits with your organization based on a RBAC approach.

Detection engineering should be a main goal for SOC teams

As a continuation of Tier abandon, Allie believes that all team members should be involved into the complete alert process. She explains that detection engineering should be a collaborative objective for SOC teams for various reasons

• It helps junior team members to learn faster when practicing co-development on detection rules with senior members. It will bring both the threat understanding and the business understanding
• Improving detection is a central part of the SOC activities. All improvements around it (both skills and technical stuff) will overall improve the performance of this process.

In Sekoia.io, we want detection rules to be thought as a atomic gears that can be tuned by the analysts and foster collaboration. We use #Sigma correlation language, which is the prefered language of the security community. It enables using community rules, asking for help and sharing your own pack of rules.

Each rule can be selected, analyzed and tuned so that it perfectly fits within the customer environment

An alert filter is a SIGMA surcharging filter that can allow to tune generic rules with business specificities.

Using APIs, customers can also integrate their detection engineering into a CI/CD pipeline and have their home made detection rules be the result of their "detection as code" where staff can collaborate upon, junior members can propose new rules and senior members can validate them. This way, you get flexibility, versioning and staff training. And if the customer operates a test tenant, he can also use it as a staging environment to check the upcoming rules.

We made a dedicated blog post on this topic.

4 - SOC building

Companies with Incident Response process in place statistically have less security breaches and the evaluated cost of breaches is $250k less than companies that do not have such process in place.

This argument can be used to convince an executive team that security operations is critical today. If you have any kind of digital jewels, you MUST have a dedicated budget line for security operations, otherwise you might face troubles in a near future.

Regarding Incident response process, I've always been a big fan of different approaches to prepare and anticipate incidents (this can be Security Operation Procedures, cheatsheets, Notebooks, Playbooks, etc depending on your preferences or available tools). What is important is to have some and get used to it.

In Sekoia.io, we use notebooks to orchestrate your incident responses and playbooks to automate specific jobs, including part of incident responses. Some are already available as templates but a company will be able to create its owns.

If you intend to build your SOC, you should start with a MSSP/MDR provider

Indeed, the step can be high and starting from scratch can be hard for your internal team, especially if this team has been recruited for that and has to learn every aspects of the company business while building the stack to bootstrap the SOC.

Using a partner is probably a smarter way to proceed. He knows the SOC business, he knows how to onboard a customer, he knows how to respond incidents, he has the staff and the skills. In other words, he will be your perfect stepping stone to get your SOC ready.

Does it mean that you should delegate your SOC entirely. AFAIC, It depends.

• I am strongly convinced that hybrid SOC is the good way to proceed for mature organizations with minimal secruity staff internally. By doing so, you will partner with you provider, you will define what is their responsability, what is yours. You will decide what is done collaboratively and what is delegated. This approach allows internal teams to step up and learn from the partner the good tactics to improve detection efficiency, to define new incident response methodologies, etc. Once again, by proceeding this way, the customer stays accountable for the SOC and can get the best of internal and external capabilities.
• For small organizations, they might not have have the staff to be able to co-manage a SOC and might prefer ot delegate it to a partner and that's fine. But once again, what is important is to keep the ownership of the contracting activities.

We have defined before about how RBAC can help to define precise roles of your SOC participants. May be a MSSP will allow some customers to just look at alerts whereas others will afford complete alert processing collaboration.

What is the most important for a MSSP is to operate its service at scale, that means efficiently on all its customers. Should you work on triage step, you want to do that on all customers to avoid spending time, should you work on hunting activities, you want to focus on the concerned customer only, but maybe some prevalence metrics will also help you. Translated into architecture design, this means multi-tenancy and how someone has the keys to do some activities in some tenants.

As a MSSP SOC analyst, if the interface allows to always decide wether to apply something for all the customers or a subpart of them, this is a tremendous way to optimize the service. That means cost optimization. That means being able to propose propose SOC services for small-to-medium organizations. And this point is crucial to have our countries protected correctly.

If you are a working as/for a MSSP provider or willing to develop your MDR capabilities, you should definitely have a look at our case study page

Bringing all the logs is a nonsense

Allie states that customers willing to have all their logs being ingested or the MSSP proposing to receive all customer logs are both wrong. This approach is not efficient.

If data does not conveys anything interesting regarding threat detection, it's useless for XDR/MDR as these approaches focus on threat.

If data does not convey anything interesting regarding fraud, policy impact, suspicious activities, it's also useless for legacy SIEM

May be the only remaining reason to push everything would be be comply with a NOT-SO-SMART mandatory regulation but one has to keep in mind that the detection pipeline is under-optimized for these kind of datasources therefore.

I like to to consider datasources as facets of observability. These facets apply to the customer assets and you need different facets to say you observe it correctly. But when you have a relevant facet, there is no reason to add a second layer of the same facet. Telemetry is very valuable, (as said before) but multiplying it is a nonsense, in terms of asset performance, of network bandwidth, and also analytics costs.

Define your metrics

Allie explains that metrics are important to measure the ROI and especially the quality of the detection.

Once again, to keep the accountability of the SOC activity, the customer must be involved to define or review these metrics, probably available in an operational dashboard and this commitment should make sense for internal SOC teams, for externalized SOC or even co-managed SOC.

Conclusion

Allie talked about so many important aspects of SOC activities and she presents it the modern way to solve it.

This was so aligned with many fundamental capabilities that we have brought into Sekoia.io in the past years that I could not miss the opportunity to detail how we make it real.

I hope you will also be aligned with what is said here. If you are a Sekoia.io user, you might be comfortable with that already, if you are not, well, maybe you should have a look, this is what our customers say on Gartner Peer Insights.

For those of you we are willing to go further, I really invite you to watch the podcast replay!