June 26, 2025 • 41 mins
Inside the War Room – What a Modern SOC Really Looks Like
Think your SOC is ready? Think again.
In this episode, our host Jordy Decock sits down with Sander Bougrine (SOC Operations Lead) and Jani Vleurinck (Detection Engineering Lead) from The Collective, for an unfiltered look inside the engine room of modern cybersecurity: the Security Operations Center.
🔍 Get behind the scenes of real-world MDR challenges ⚙️ Learn how top-tier teams handle detection, escalation, and response 🚨 Hear how they’re adapting to the latest threats—and what you might be missing
Whether you're running a SOC, building one, or just trying to keep up with the chaos—this one’s for you.
👉 Tune in now and let us know: what’s the biggest challenge your SOC is facing today?
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Jordy Decock (00:00):
You've seen the headlines.
Data breaches, ransomware, insider threats.
But you haven't seen this.
The war room where it all unfolds.
Today, we pull back the curtain.
Welcome to The Collective podcast.
The podcast where we delve into the ever evolving world of corporate security to help businesses stay ahead of the curve.
Whether you're a small startup or a global enterprise.
(00:23):
I'm your host, Jordy Decock, working for The Collective , where we pride ourselves on a hands on approach, working closely with our clients to cut through the noise and deliver the solutions they actually need.
No unnecessary fluff, no overselling.
Each episode, I'll be joined by experts, practitioners and thought leaders diving into today's most pressing security challenges.
(00:44):
We're here to provide insights, strategies and actionable advice to keep your organization safe and secure in a digital first world.
Joining me today are Sander Bougrine, SOC operations lead, and Jani Vleurinck, SOC Detection Engineering Lead, both working at the Collective.
Together we'll dive into the modern SOC and explore the hot topics and actual struggles of a managed detection and response service provider.
(01:10):
Get ready for practical insights, best practices and strategies to strengthen your security status one episode at a time.
Welcome on the podcast.
Sander and Jani.
Let us begin by opening the curtain of what a SOC does and dive a bit deeper into SOC as a service.
Can you give us a global overview of the tasks a SOC deliver?
Jani Vleurinck (01:32):
Of course.
As a soc, we mainly detect and respond, which means that we will attempt to detect whatever threats a company may face, whether they're being attacked by outsiders.
And if there is an attack, we will respond to that attack by attempting to evict those attackers.
Jordy Decock (01:50):
Okay, can you also elaborate on how we evict those threats?
Sander Bougrine (01:55):
Yeah, sure.
So some things we're doing are, for example, when we see that a user has done a sign in from a location which isn't expected, we have the possibility to, for example, initiate a session revocation, which means that the user is thrown out of his session and needs to re authenticate again before continuing his behavior.
Jordy Decock (02:20):
What is a way to evict those users?
Sander Bougrine (02:23):
When we are looking at device, for example, we have the possibility when we are seeing strange behavior like for example, some malware which is running on the device or some processes which are running which we can immediately explain.
We have there the possibility to isolate a device which means that it's cut from the Internet so it's put into.
Jordy Decock (02:45):
A separate Internet environment.
How should I envision that?
Jani Vleurinck (02:50):
Actually, no, they just won't communicate with anything else.
So it won't communicate with anything else on the local network and it won't communicate with anything on the Internet.
That way we make sure that lateral movement is not possible.
Jordy Decock (03:03):
Okay, so for the end user who is behind the device, for example, I'm the hacker, I'm behind the laptop, he still thinks he's inside the environment, but he can't communicate with anything else.
Am I seeing that?
Correct?
Sander Bougrine (03:18):
But let's for example state that the attacker has a connection to the device over the Internet, which means he has its term called C2, is creating C2 activity, creating a beacon from his device to the device of the victim.
But that connection is going over to Internet.
When we are isolating the device, the network connection is blocked, which means that the session he had to the device is cut.
Jordy Decock (03:44):
Okay, yeah.
Jani Vleurinck (03:45):
When it comes to eviction, I don't think we need a lot else.
But other than that, we also obviously have the capability to remove files from devices via the Live Response functionality that our EDR Microsoft Defender for Endpoint provides us.
Jordy Decock (04:00):
What are things that I should envision with that?
Jani Vleurinck (04:03):
So it's mainly about removing certain files that may or may not be malware persistency methods like registry keys, like startup folder, that kind of stuff.
Jordy Decock (04:14):
So you can straight up delete any item that is in somebody's folder that is correct.
Jani Vleurinck (04:19):
With Live Response, we pretty much have a session to any device that is onboarded with an EDR agent which grants a system privileges shell.
Jordy Decock (04:28):
Okay, yeah, Most people know the term soc, but not the difference between an in house SOC or SOC as a service.
At The Collective we offer the SOC as a service to our customers.
Can we maybe elaborate a bit on that?
What is a SOC as a service and what are the differences between a company having an in house SOC and a going for SOC as a service?
Sander Bougrine (04:47):
I think the main difference between an in house SOC and a SOC as a service is that an in house SOC is doing SOC services, blue teaming activities within their own company.
Where we have SOC as a service, which is radar managed service, where we provide a service to other companies, where we deliver security for them.
Jordy Decock (05:06):
Yeah.
Jani Vleurinck (05:07):
So that also means that when we are an external party that provides a SOC or SOC as a service, we get to see a lot of different environments.
For example, blue team that works for a certain company that is only in house will only ever see their own environment with their own processes from within their company.
For us, as a SOC as a service, it's a lot different.
(05:28):
We see companies with all kinds of Threat landscapes.
We see companies from all kinds of branches, like pharma, like banking, you name it, we see it all.
Which is actually a very unique standpoint to be in.
Jordy Decock (05:41):
When you see all of those environments, do you see a lot of comparisons?
I mean, is something happening in a pharma environment completely the same happening in a banking environment or do you see a lot of differences?
Sander Bougrine (05:53):
Yeah, we have, for example, seen attacks within specific branches.
For example, we have several banking systems where we had an attack specific scoped on what they are doing.
When we see those activity and we know, okay, what we are dealing with, what are the entities which were detected during the attack, we have the possibility to gather them and also see that we can scope them to other organizations as well.
(06:17):
Which means that, okay, we had them in one organization, let's see now that other organization which are working the same brands as well, are also defended against this same threat.
Jani Vleurinck (06:28):
It's not just threat hunting that helps us with this, it also helps a lot with detection engineering, which is my expertise, where if we see a certain threat one of our customers, it doesn't even need to be for other customers in the same branch.
We can just create a detection on that new threat we have observed.
Jordy Decock (06:44):
Okay, maybe I'm not bringing the right reasons right now, but I also remember a lot talking about phishing emails.
I believe that's a really good example.
Sander Bougrine (06:53):
Yeah, we have for example, like attack groups which are mainly focused on just sending phishing mails as lot as possible to lots of different organizations.
So there are strengths within a socket services that when we see the fish are sending a mail and we have captured them within a case and also collecting the eviction efforts, we have the possibility to also provide them within other organization as well.
(07:18):
Which means, for example, Organization X has received a phishing mail.
We investigated it, concluded okay, it was a phishing mail.
We had the possibility to say okay for the other organization even before they received a mail from this phishing attacker.
We had the possibility to say, okay, if a meal is received from that phisher, just block it.
(07:38):
Because we know based on what we saw within the other organization as well, that it's a phishing mill.
Jani Vleurinck (07:44):
Unfortunately, unfortunately, phishing still seems to be the major cause of accounts being breached.
It's fighting an uphill battle as a defender, really.
But we do believe that the fact that we can extend that information that we gain from one customer's phishing email to the rest of the customers really pays dividends when we are looking towards staying resilient of these Phishing attacks.
Sander Bougrine (08:06):
Yeah.
And that is also why it's important to not only collect eviction efforts.
Like for example, we have seen sender X which is sending phishing mails.
Okay, we are blocked going to block the sender, but next time he's smart and he's using a new sender entity, receiving phishing mails and then resolving them by saying, okay, it's phishing mail and blocking the sender is a good thing.
(08:28):
But it's formally aftermath.
So we're going to do aftermath.
Once the phishing mail is already gathered within the organization.
We don't only going to just investigate phishing mails and see, okay, is it a phishing mail or not?
Because then there are a lot of phishing mails.
Then we are just doing day to day operations, just only focusing on fishing meals.
(08:49):
An important thing there is to also create detection rules which are smart and not only looking, okay, has sender X send a mill is going to be fish.
We're also going to create detections with detection rules where we have seen certain things that are scoped on phishing.
For example, a specific attachment which is given within the phishing mail.
For example, a couple of months ago we had a lot of QR code phishing.
(09:12):
It's also important to create behavior based rules on that as well.
Jordy Decock (09:16):
Okay, you mentioned phishing as part of the campaigns that you guys have to handle.
Are there any other things we might see?
A lot.
I hear a lot about phishing.
I hear a lot about malicious malware.
Jani Vleurinck (09:27):
Yeah.
So right now one of the most popular ways of breaching an endpoint appears to be what we call click fix malware.
Pretty much what it does is it is going to tell a user who lands on a certain page, hey, I'm a captcha.
If you want to go past this captcha, you will have to press Windows R button, Control V and enter.
(09:48):
So in the background what this website does is it transfers a malicious command to your clipboard and as you press Windows R, you open the run functionality of Windows and Control V pastes it into the run functionality and then you execute it using Enter, which sets in motion a whole chain of malicious commands.
Jordy Decock (10:10):
I think one of the first things a lot of listeners might have right now is like, why would somebody fall for that?
But it's not the usual typical IT guy who knows the stuff that is falling for that, but it's the people who are falling for this who are not as technical as we are.
So I feel that's a really important step to Take in consideration that these malicious actors aren't focusing on the IT people, they're focusing on the rest of the organization to get to the IT people.
Jani Vleurinck (10:39):
Oh yeah, definitely.
They are going to go for the, let's say, I don't want to say this, but low hanging fruit I should say.
And from there they will oftentimes try to escalate privileges or move laterally, which is what we would say in the MITRE terms of it.
And yeah, these people are the most vulnerable within the organization.
(10:59):
But at the same time that doesn't mean that the IT people can't be targets too.
There are certain vulnerabilities and phishing campaigns that we've seen, for example, with malicious RDP files, with malicious Visual Studio files which target IT people.
Sander Bougrine (11:15):
Yeah, and this is an interesting thing because why they are attacking IT people is because they have a lot of high privileges and more privileges the attacker has, the more important it's going to be to travel within the environment.
Jani Vleurinck (11:28):
Yeah, because that way they don't have to do privilege escalation, they can just do lateral movement because they already have most of the privileges they need and.
Jordy Decock (11:35):
Is the fastest way to deal damage.
Jani Vleurinck (11:37):
That's correct.
Sander Bougrine (11:37):
Again, also, I think if we're talking about the catcher, also an important thing to note is that okay, we can detect certain things, but it's also important to do something with them.
Not only say, okay, we have detected them, we have done as lots of mitigation as we could, but also provide next steps, not wait till the next incident, but also go to the customer and say, hey customer, we've seen this specific traffic, we know that it's going on within the threat landscape, but let's do something with it.
(12:07):
For example, let's see that we can see.
Okay, if we're talking about regular users, do they need to have elevated privileges within a shell?
For example, Couldn't we restrict that so that once the user is falling in the captcha, the damage is restricted?
Jani Vleurinck (12:23):
Yeah, and on that note as well, it's not just about telling the customer that they can fix some stuff on there and we can also do some stuff we can, for example, user automated isolation, which means that as soon as one of those malicious cmdlets that are being executed by the Clickfix malware is detected, then the device will automatically get isolated, which were talking about earlier.
(12:45):
Which means that the attacker cannot make an inbound connection to take control over the computer.
And if it's a malware that works autonomously, it can't go and do electron movement around the network because the device will not communicate with the rest of the network anymore.
Jordy Decock (12:59):
Okay, we've talked a lot about how attackers can reach our employees or our network.
Maybe we should take a step back now and focus a little bit on the SOC itself.
At the Collective, we have our own SOC Security Operations center.
Which programs or which suite are we using at the Collective?
Maybe you should also explain why we as a collective especially choose this suite to use in our soc.
Jani Vleurinck (13:23):
So first of all, we work fully on the Microsoft stack.
So that means all the Defender flavors, Microsoft Sentinel and anything that Azure has to offer in terms of logging.
The reason why we do this is because all of the products, they just work with each other seamlessly.
Sander Bougrine (13:40):
Yeah, it's like an all in one solution.
You have the different types within an attack and the biggest, a big opportunity.
Microsoft is that they covering a lot.
If we're talking for example about Mitra.
Jordy Decock (13:52):
The attack, the attack framework.
Sander Bougrine (13:55):
If we're talking like for example about an attack where a user has fallen into a phishing mill, which is leading to initial access, which means that the attacker has access to the account.
Microsoft discovering a lot of things within there.
For example, we have visibility within the mail, but we also have visibility in the sign in logs which were generated because they are all collected within one centralized system.
Jordy Decock (14:17):
As a part of that, the thing we just discussed earlier, like you can go through Microsoft Endpoint live inside the user's laptop and we'll just reach the phishing email out.
Jani Vleurinck (14:29):
That is correct.
At the same time, you would be able to do the same with other EDRs, but it wouldn't work as seamlessly.
And setting it all up isn't as easy as it is with just an entire Microsoft stack.
Sander Bougrine (14:40):
Yeah, and I think another important note to make is that a lot of people are saying, okay, they are working with Microsoft solutions, so they are only focused on Microsoft.
But that's not true within our Microsoft solution.
Formally, if we're talking about for example our centralized SIEM system, Sentinel or Defender is there, we have the possibility to ingest other solutions as well.
(15:04):
If we are talking, for example an organization which is Google Cloud platform, for example, we have the possibilities and opportunities to ingest that locks as well.
And also see, okay, can we do important detections within that environment as well and not only focused on the Microsoft environment.
Jani Vleurinck (15:23):
And that's the thing I would like to come back on that.
Sandor said earlier that Microsoft already does a lot of detections, but we are also a force to be reckoned with when we are looking at creating our own detections.
So let's say by default, Defender XDR has an extensive suite of detections that will cover a large part of the MITRE matrix.
(15:45):
The bad part about this is that attackers will also know how to evade these detections.
Which means that creates an opportunity for us to create detections on top of the stack so that the attackers don't know what we have in store for them.
Sander Bougrine (16:01):
Yeah, and they're also SOC as a service is also a big opportunity.
Within that as well we have company which is working with certain solution and another company, for example, which is using another solution.
For example, let's focus on firewall.
A lot of companies are using firewalls to have insights into their traffic which is going for example, on their on prem environment.
(16:22):
That isn't a problem for us because we have the opportunities to ingest logs from both of these solutions.
So it doesn't really matter if we have a customer which is using certain integrations and another customer which is using other integrations.
If within our centralized team we have the possibility to ingest locks from other sources as well.
Jordy Decock (16:44):
Okay, so is there any like we're talking about Microsoft, the entire suite for.
As far as I know, there is not any other suite in the environment that even comes close to this complete solution.
Jani Vleurinck (16:59):
There is not a full suite, as far as I know that does it.
But there are individual components that you can make work together.
One of the most popular SIEM products out there is Splunk and it pretty much works the same way as you would expect Sentinel to do.
You can just ingest all of the logs from other products.
Sander Bougrine (17:18):
I think another important thing to also note is that if we are talking for example, like other SIEM integration, SIEM solutions that has the opportunity as well to ingest different sources.
I think also a main focus which is within the Defender suite is that Defender is also building integration rules that go with the solution as well.
(17:38):
We have for example within Sentinel, the content hub where there is already created some integration solutions which go with standard building detection rules.
So you don't have to create them your own or you just can start with them and then see, okay, what are they generating, how is the data ingested and then scope them more or update them by creating other detection rules as well.
Jordy Decock (18:06):
Okay, the reason there is a sock also on the market such as the collective delivers versus an in house soc.
Is there a big reason why companies aren't all getting their own in house soc?
Sander Bougrine (18:21):
I think the main focus Is how big is the organization?
Are we talking about a big organization which has the capability and the funds to have an in house society?
Then it might be interesting to have an in house soc, because then you can scope your SOC as much as possible on your specific organization.
(18:41):
But if we're talking about, let's say, for example, less bigger organizations organization where their focus isn't necessarily on security, it's interesting to have a SOC as a service because then you can outsource those activities.
You don't need your own people or your own resources to provide a soc.
Jordy Decock (19:02):
Yeah, I think one of the things we see a lot then from my part or from my side of the job is that companies have a two man team or a one man security team.
And when we speak about threat protection or anything else, considering Microsoft Defender, they have tried to set it up, but they don't have the time to take action on the locks they receive.
Jani Vleurinck (19:27):
And not just that.
So when you have your run of the mill SOC analyst, they will be able to analyze and take action on those alerts a lot faster than the internal security teams can.
The internal security teams oftentimes are not schooled in operational security.
They know how to harden an environment.
(19:47):
They know their environment inside out.
But how to interpret the raw logs that come from such alerts is a whole job entirely different.
Sander Bougrine (19:56):
I think another important thing is also quality.
When we have less bigger companies, they don't have the funds to have a SOC which has the quality to do it in a good way.
You can provide sock, which means, okay, we're ingesting a lot of locks, but There are certain SOCs which are ingesting as much as possible, but don't provide necessary detections or context within those locks.
(20:21):
I think quality there is an important thing to also do something with the logs that are provided within the SIEM solution.
Jani Vleurinck (20:27):
Our philosophy on it is mainly that whenever we ingest a new log source, we are going to do an in depth investigation on what that log source can tell us and what kind of new threats we can detect with it.
That makes sure that if the customer does spend money on ingesting those logs as Sentinel is often pay as you go.
So the more you ingest, the more you will pay that they will actually get some value out of that.
(20:50):
They will know that their threat landscape is covered more by ingesting those logs and paying that price.
Jordy Decock (20:55):
But there should be a good look at which logs are we ingesting, because I can imagine there are a lot of logs that aren't going to give you or deliver you a lot of value.
Jani Vleurinck (21:07):
That's correct.
In that sense, we do have a couple of options there.
So, for example, let's say raw network traffic logs.
Those are oftentimes not as interesting for us to ingest to make true like alerts on, but at the same time it is good for us to have as an enriching factor in our investigations.
(21:27):
Now Microsoft offers something which is called auxiliary logs, which costs less to ingest, but you will have to pay each time you query them.
But the amounts of time you need to query them is significantly lower than the standard logs that you ingest.
So it helps us in some cases where we have an alert where we need, for example, network traffic info that we can use that to, let's say, see if something is a true positive or false positive.
Sander Bougrine (21:54):
Yeah.
And also when talking about ingesting locks, which is a pay as you go service, it's also important to do analysis on.
Okay, we have specific locks on the firewall, but this could be dozens of logs based on the activity that is going on within the organization.
If we are just going to ingest row all of those logs, it's going to be a high cost.
(22:18):
It's also important to do analysis on, okay, what are the bare minimum logs that we need and what are important logs for us as SOC to do detection on?
Jordy Decock (22:28):
Okay, both of you actually work at the SOC of the collective.
I do believe a lot of customers know the term sock are familiar with that, but don't realize how the structure of a sock is set up.
Maybe we can enlighten a little bit like what are your jobs?
What are the other jobs that a sock has and how do we split it up?
(22:52):
How does a in house SOC take on the matter?
How does a sock us work?
Are there a lot of differences there?
Jani Vleurinck (22:58):
I'll start off with my own main job within the SoC, which is a detection engineering lead.
As a detection engineering lead, I pretty much write the queries and I also look at the queries that were already made that will generate alerts.
So whenever there is a new upcoming threat, I will analyze it, maybe try the new exploits on my own and see what kind of logs it generates.
(23:24):
Once I have those logs and I know what that kind of attack looks like in the logs, I will create a query that will look for those logs and that query will then generate alerts when something like that is found.
The other flip side is that I will also have to maintain the rules that I have written.
So when you are an external SOC like we are, you have a lot of companies under your wing and that means that there are a lot of angles for false positive.
(23:50):
These rules will need to be maintained to make sure that your actual analysts are not overwhelmed by the alerts.
So that means that a significant part of the detection engineer's time goes into maintaining those queries to make sure that they throw as little as possible false positives.
Sander Bougrine (24:06):
And I think another big important thing to note within the detection engineering stack as well is that the difference between now and SOC is there.
You have detection engineers which are mainly focusing on the core business of that organization and they can scope their detection rules as much as possible.
But within a SOC as a service, what we are doing, we need to be assured that once we have deployed the detection rule, once a new organization is onboarded, the detection rule is also going to work on that organization as well.
(24:36):
Which means we're not only focusing on specific entities or eviction efforts, but also focusing on, okay, what is the specific behavior that we want to detect with this type of.
Jani Vleurinck (24:47):
And that brings us to what you do in the society.
Sander Bougrine (24:49):
Yeah, so my job as an operations is two sided.
One is on the inside, where I look at the incidents that are coming in from different organization and also see, okay, are they managed correctly?
Is the investigation done correctly?
And also once the investigation is done, are we assured that next time the same activity is happening, that we are protected against them?
(25:11):
Another site which go hands to hand with that is communicating with customer.
For example, if we have seen an incident, it's important to not only just detect them and then say, okay, I've seen them, let's wait to the next one.
But also communicate to the customer, okay, we have seen that specific behavior, but let's check what we can do to be assured that next time we're seeing the same thing.
(25:32):
We are protected against it.
Jordy Decock (25:34):
Is that the only role that communicates with the customer?
Sander Bougrine (25:37):
It's not the only role.
I think a big importance within our service as well is that all of our SOC analysts can communicate with the customer.
And that's something we've decided because it's important that the analyst which has done the investigation has the most insights within it and the deepest dive within.
Okay, what was the activity that we saw?
(25:57):
If I need to collaborate on that as well, we're losing time.
And that time can be used to do mitigation or cok.
We've seen that, but how can we create important improvements?
For example?
So we decided that even SOC analyst has picked up an incident, he's not only going to do the investigation, but once communication needs to be done or extra input needs to be provided, he has the ability to also check that with the customer as well.
Jani Vleurinck (26:27):
And it's important that everyone on the team learns how to communicate with the customers because for example, just a normal analyst, someone who is doing the alerts, they also have to make the customer aware of what is happening.
Which we use teams to communicate with our customers in specialized chats where we will tell them the latest update on stuff.
(26:49):
And that brings me into the next role that we can talk about, which is the automation engineer.
We have an automation engineer who makes all of the playbooks, which is what we use in sentinel terms to automate certain tasks.
So let's say for example, Jodi, your computer chose a priority one incident.
Oh no, there's malware on your computer.
(27:10):
What do you think happens now?
Jordy Decock (27:12):
There is an alert signaled.
Jani Vleurinck (27:15):
That's correct.
What does this alert do on its own?
What would be the best case scenario?
Jordy Decock (27:20):
The alert on its own.
It's giving you a heads up on what is happening.
But I suppose that's not what I'm gonna get as a.
Jani Vleurinck (27:28):
Well, we do, we do get alarms on our phone.
We get woken up, we stumble out of bed.
We stumble out of bed all groggily.
Yeah.
We stumble out of battle groggily and then we open our computer and what.
Jordy Decock (27:40):
We see, it happened like four times today.
Jani Vleurinck (27:42):
Yeah, exactly.
And what we see is Jody's device has already been isolated because our automations have told us that's a priority one incident.
Jody's device needs to be immediately shut off from the network.
And that's the kind of work that our automation engineer does.
He makes the automations that actually talk to Microsoft servers and tells them like, hey, this device needs to be isolated immediately.
Sander Bougrine (28:05):
That's a big thing because then we're not only doing eviction efforts once we know what the attack means, which means that we could already lose a couple of minutes, maybe a couple of hours, who knows?
And the attacker may gain more privileges.
But if we are taking already mitigation actions once we are receiving those incidents, which can be assured that mostly there is something going on, that the eviction efforts has already been taken, we can do our investigation being assured that okay, the attack that was going on is already being killed by for example, the device isolation.
Jordy Decock (28:40):
Okay.
But not every critical incident is the same for every company, I suppose.
Sander Bougrine (28:46):
Yeah.
And that's also why it's important to note that we are formally working on behaviorals based on experience on the incidents that we have already investigated.
We have created a list with specific behavior that we know.
Okay.
Once we are seeing this, we can be assured that mostly something is going on.
(29:07):
If we are seeing this specific behavior, the automatic rules are immediately coming in and blocking potential threats.
Jani Vleurinck (29:14):
And also our detection engineer is in contact with the customers to tune the automations a bit to their liking.
So for example, we have one customer that told us like, yeah, I actually want all alerts from this source to be a priority one alert.
Could you also automatically isolate all events that throw such an alert?
And this is the kind of thing that our detection engineer also needs to talk with customers for because he needs to be able to tailor the automation rules to their specific needs.
Jordy Decock (29:44):
He needs to understand the business.
Jani Vleurinck (29:46):
That's correct.
Jordy Decock (29:46):
Okay.
Sander Bougrine (29:47):
And then when talking about that, I think we're going to our next important thing, which is cti, which also scoped on how the priority has to be specifically being scoped on a specific role.
We are collecting as lots as information during our investigation, which we are collecting in a centralized way within our organization.
(30:08):
For example, we have a MISP instance, which means this is a cooperative communication within the Benelux where we are sharing specific IOCs, which means entities which were seen within specific attacks.
We are distributing them with each other.
And within those misp, we can sync all the indicators to all of the organizations we're managing, which means that we have company X which is protected against a new threat landscape, but also be assured that company another company is also protected against.
Jani Vleurinck (30:38):
And these indicators can be a whole range of things.
They can be IP addresses, they can be domains, full URLs, file hashes, that kind of thing.
So if any of these indicators are then seen one of our customers environment, after we have synced those indicators to our customer's environment, they will a automatically get blocked and b raise an alert on our SOC so that we can investigate where did it come from and do we know if there is anything else that is connected to this attack still on the environment.
Jordy Decock (31:06):
Okay, so for example, one of the things that I'm understanding out of this is we have seen a hacker with his IP address in a different environment.
We engage the same IP address in one of our other environments that we're currently having on our soc.
We already know this is bad news and we will automatically isolate the device.
Sander Bougrine (31:25):
He gets to and not even if we only saw it within our organizations.
Like I said, we have the MISP instance which is a centralized ways by sharing specific eviction efforts which is seen as well as within other big organization within the Benelux.
So if they were seen within one of those organizations where we have a trust that okay, if we are seeing the same ioc, we know that it was seen within an attack within the other organization as well.
(31:55):
We can also be protected in that way as well.
For example, we are working with a private bank, a bank which is responsible for a lot of traffic within Europe.
They also have another community which is specific to the banking sector.
And that's also a big strange is we have those insights so we can implement that as well and be assured that if something is seen within any of the banking systems where a specific threat actor is seen which is specifically attacking those banks, we can collect that eviction efforts as well and also be assured that our partner which is also working in the bank sector is protected as well.
Jordy Decock (32:35):
Maybe adjacent to that.
What I experience from the business side, I feel a big pushback from the business side sometimes that they look at the size of soc, how big is it, how much employees do they have?
They think the more employees SOC has, the safer my company will be.
Jani Vleurinck (32:53):
And that's not entirely true.
I think that is widely outdated model.
The more modern SOCs, they work a lot with automations, they work a lot with scoping their detection rules to better.
So in the past the need for a larger SOC was mainly created because people were creating rules that were not very scoped on malicious behavior, but rather on oh, we saw this thing once in an attack which may or may not be related to the accuracy actual attack.
(33:24):
So it must be malicious.
Then they make a rule for that and that keeps going off and off.
It keeps creating false positives because it was not a correctly scoped rule in the first place.
Sander Bougrine (33:36):
And that's an important thing.
It's not human analyzing that is defining how much capacity you need.
But it's indeed how we are implementing our detection rules, how we are scoping a specific behavior.
Like I said, we could have specific behavior and say, okay, we have seen them, wait till the next one and next time we're going to say again, okay, we see it, we know it.
(33:59):
Yeah, just close it.
That's not efficient.
And that's also defining if we are going to need one analyst which is mainly focusing only on that or we are going to create specific detection rules as well as creating maybe specific automation rules.
Automation rules are more mainly focused on okay, we've seen specific behavior.
(34:19):
It's a bit odd, but okay, the customer has confirmed that he's using that specific application or that specific behavior is known to them, then we are also going to implement those automation rules as well.
Which means that next time an incident is received indicating that this activity is happening, it's not again analyzed by one of our SOC analysts, but we have an automation rule in place which is just saying, okay, we've seen the specific behavior, we know that going on is a bit off, but the customer has confirmed that this activity might be happening.
(34:52):
So just close rule.
It's good for documentation, for reporting, but we know that it's happening, so it's not useful for us to investigate it.
Jordy Decock (35:03):
Again, I think one of the big things that is a philosophy we also encounter or that we try to employ is that the more users there are doesn't mean that there should be more alerts.
Sander Bougrine (35:18):
No, Exactly.
We have for example organization which has 20 customers, but are creating like for example, 10 incidents within a day.
And then we have a customer which has 10,000 users which is generating only one incident a day.
It doesn't mean that the more users there are, the more incidents they're going to be.
It's also based on okay, how is the organization configured, but as well as how interesting is it for the attacker to use that organization as a victim.
Jani Vleurinck (35:47):
Well, to be honest, spray and pray attacks you are always going to encounter.
But the effectiveness of these spray and pray attacks will wildly differ across multiple organizations.
Let's say Organization a has about 50 employees, but they are not exactly hardened to attacks.
Meanwhile, the other one, Organization B, has about 900 employees, but they are very hardened.
(36:12):
It is completely possible that Organization A, although that they have a lot less employees, will cause a lot more load on a SOC than Organization B will, because Organization B already has restrictive controls in place that make sure that the attacks don't land in the first place.
Jordy Decock (36:30):
Also, I think the longer they are on the SoC, the more we have a vision on which are false positives what is actually happening inside the environment.
So that also helps of course, with downgrading the load on a sock.
Maybe just one more point on that is what are key takeaways listeners could take away after this podcast?
Jani Vleurinck (36:51):
Everyone can use a soc.
Any organization, no matter how large or small, in my opinion, can use a SoC.
It doesn't have to be much, but if you want to be well protected, you might as well get a SOC that does their own detection engineering, that does their own automations, and that actually looks into new threats and will actually make sure that they have means against those threats.
Sander Bougrine (37:17):
As SOC is not only investigating a lot of locks, incidents, alerts, but also checking, okay, what is important for that organization, but also see how can we improve that organization.
How can we see that the organization is defended against day to day landscape.
Jordy Decock (37:34):
Because not a single company is safe anymore.
I think we did have two examples of that already, didn't we, during the sock onboarding that suddenly get breached and they are really happy that were there.
Sander Bougrine (37:48):
Yeah.
And I think that's an important thing to mention.
Indeed it's not because you have a SOC that you don't can be breached.
It's important to know that we are evolving, but trend landscape is also evolving, but there it's important to not only do detection, but also response.
How can we be assured that if we see something new, okay, it could be that we don't immediately know what's happening, but how can we be assured that we be protected as soon as possible?
Jani Vleurinck (38:21):
And a SOC will be able to make you see these improvements a lot more easily.
So it doesn't mean that you can only use a SOC to defend you against attacks that are happening actively.
A SOC can also give you these insights because they have seen these things, especially SOC as a service have seen these things over and over again on other organizations.
(38:43):
And they can also proactively inform you that, hey, this is something we've seen on another organization that we are partnered with.
You might want to fix.
Jordy Decock (38:51):
This isn't one of the values a SOC brings.
Hey, even if you get breached, we will handle the breach really fast.
We can isolate a malicious actor.
Jani Vleurinck (39:02):
Yeah, so a lot of actors who get onto an environment will lay dormant for some time because they need to do stuff like privilege escalation, like virtual movement to do the real damage.
So anchor your systems, exfiltrate data that normal users do not actually have access to, for which they would need the privilege escalation.
(39:23):
And during these steps, the SOC can detect them.
Jordy Decock (39:27):
So that's a great example of why organizations who are currently, for example, in a SOC onboarding suddenly get breached because the other side sees movement and they realize, oh damn, we need to react really fast, otherwise our window is gone.
Sander Bougrine (39:43):
Indeed.
And that's also defining what a good attacker is.
A good attacker will also always be stealthy, which means he gain initial access, but is not immediately using it.
He's just creating connection between his device and the environment of the customer.
But then it will be quiet for time, which we also saw within the attack of the customer.
(40:06):
The customer was already been breached from couple of months which we saw based on the firewall logs, but the attacker decided to be quiet and then immediately do a total destruction out of the nowhere.
So that also means it's important to not only do detection, but also be assured that your infrastructure that you are using within your organization is being up to date and also have the visibility in the logs that are going over those infrastructure.
(40:35):
For example, if this customer was onboarded and we had visibility within the firewall logs, we will be alerted a couple of months before the total distraction that something was not right.
Jordy Decock (40:46):
Well, there are no other key takeaways and I think we can say that this was the episode about our SOC service for sharing your valuable insights.
And of course, thank you all for tuning in.
We hope you found today's discussion helpful.
If you did, don't forget to subscribe and share this with your colleagues, helping us reach more people who are just as passionate about building a safer digital world.
(41:10):
We'll be back next time with another important topic in corporate security.
Until then, stay vigilant, stay secure, and let's keep working together to shape a safer future.
You've seen the headlines.
Data breaches, ransomware, insider threats.
But you haven't seen this.
The war room where it all unfolds.
Today, we pull back the curtain.
Welcome to The Collective podcast.
The podcast where we delve into the ever evolving world of corporate security to help businesses stay ahead of the curve.
Whether you're a small startup or a global enterprise.
(00:23):
I'm your host, Jordy Decock, working for The Collective , where we pride ourselves on a hands on approach, working closely with our clients to cut through the noise and deliver the solutions they actually need.
No unnecessary fluff, no overselling.
Each episode, I'll be joined by experts, practitioners and thought leaders diving into today's most pressing security challenges.
(00:44):
We're here to provide insights, strategies and actionable advice to keep your organization safe and secure in a digital first world.
Joining me today are Sander Bougrine, SOC operations lead, and Jani Vleurinck, SOC Detection Engineering Lead, both working at the Collective.
Together we'll dive into the modern SOC and explore the hot topics and actual struggles of a managed detection and response service provider.
(01:10):
Get ready for practical insights, best practices and strategies to strengthen your security status one episode at a time.
Welcome on the podcast.
Sander and Jani.
Let us begin by opening the curtain of what a SOC does and dive a bit deeper into SOC as a service.
Can you give us a global overview of the tasks a SOC deliver?
Jani Vleurinck (01:32):
Of course.
As a soc, we mainly detect and respond, which means that we will attempt to detect whatever threats a company may face, whether they're being attacked by outsiders.
And if there is an attack, we will respond to that attack by attempting to evict those attackers.
Jordy Decock (01:50):
Okay, can you also elaborate on how we evict those threats?
Sander Bougrine (01:55):
Yeah, sure.
So some things we're doing are, for example, when we see that a user has done a sign in from a location which isn't expected, we have the possibility to, for example, initiate a session revocation, which means that the user is thrown out of his session and needs to re authenticate again before continuing his behavior.
Jordy Decock (02:20):
What is a way to evict those users?
Sander Bougrine (02:23):
When we are looking at device, for example, we have the possibility when we are seeing strange behavior like for example, some malware which is running on the device or some processes which are running which we can immediately explain.
We have there the possibility to isolate a device which means that it's cut from the Internet so it's put into.
Jordy Decock (02:45):
A separate Internet environment.
How should I envision that?
Jani Vleurinck (02:50):
Actually, no, they just won't communicate with anything else.
So it won't communicate with anything else on the local network and it won't communicate with anything on the Internet.
That way we make sure that lateral movement is not possible.
Jordy Decock (03:03):
Okay, so for the end user who is behind the device, for example, I'm the hacker, I'm behind the laptop, he still thinks he's inside the environment, but he can't communicate with anything else.
Am I seeing that?
Correct?
Sander Bougrine (03:18):
But let's for example state that the attacker has a connection to the device over the Internet, which means he has its term called C2, is creating C2 activity, creating a beacon from his device to the device of the victim.
But that connection is going over to Internet.
When we are isolating the device, the network connection is blocked, which means that the session he had to the device is cut.
Jordy Decock (03:44):
Okay, yeah.
Jani Vleurinck (03:45):
When it comes to eviction, I don't think we need a lot else.
But other than that, we also obviously have the capability to remove files from devices via the Live Response functionality that our EDR Microsoft Defender for Endpoint provides us.
Jordy Decock (04:00):
What are things that I should envision with that?
Jani Vleurinck (04:03):
So it's mainly about removing certain files that may or may not be malware persistency methods like registry keys, like startup folder, that kind of stuff.
Jordy Decock (04:14):
So you can straight up delete any item that is in somebody's folder that is correct.
Jani Vleurinck (04:19):
With Live Response, we pretty much have a session to any device that is onboarded with an EDR agent which grants a system privileges shell.
Jordy Decock (04:28):
Okay, yeah, Most people know the term soc, but not the difference between an in house SOC or SOC as a service.
At The Collective we offer the SOC as a service to our customers.
Can we maybe elaborate a bit on that?
What is a SOC as a service and what are the differences between a company having an in house SOC and a going for SOC as a service?
Sander Bougrine (04:47):
I think the main difference between an in house SOC and a SOC as a service is that an in house SOC is doing SOC services, blue teaming activities within their own company.
Where we have SOC as a service, which is radar managed service, where we provide a service to other companies, where we deliver security for them.
Jordy Decock (05:06):
Yeah.
Jani Vleurinck (05:07):
So that also means that when we are an external party that provides a SOC or SOC as a service, we get to see a lot of different environments.
For example, blue team that works for a certain company that is only in house will only ever see their own environment with their own processes from within their company.
For us, as a SOC as a service, it's a lot different.
(05:28):
We see companies with all kinds of Threat landscapes.
We see companies from all kinds of branches, like pharma, like banking, you name it, we see it all.
Which is actually a very unique standpoint to be in.
Jordy Decock (05:41):
When you see all of those environments, do you see a lot of comparisons?
I mean, is something happening in a pharma environment completely the same happening in a banking environment or do you see a lot of differences?
Sander Bougrine (05:53):
Yeah, we have, for example, seen attacks within specific branches.
For example, we have several banking systems where we had an attack specific scoped on what they are doing.
When we see those activity and we know, okay, what we are dealing with, what are the entities which were detected during the attack, we have the possibility to gather them and also see that we can scope them to other organizations as well.
(06:17):
Which means that, okay, we had them in one organization, let's see now that other organization which are working the same brands as well, are also defended against this same threat.
Jani Vleurinck (06:28):
It's not just threat hunting that helps us with this, it also helps a lot with detection engineering, which is my expertise, where if we see a certain threat one of our customers, it doesn't even need to be for other customers in the same branch.
We can just create a detection on that new threat we have observed.
Jordy Decock (06:44):
Okay, maybe I'm not bringing the right reasons right now, but I also remember a lot talking about phishing emails.
I believe that's a really good example.
Sander Bougrine (06:53):
Yeah, we have for example, like attack groups which are mainly focused on just sending phishing mails as lot as possible to lots of different organizations.
So there are strengths within a socket services that when we see the fish are sending a mail and we have captured them within a case and also collecting the eviction efforts, we have the possibility to also provide them within other organization as well.
(07:18):
Which means, for example, Organization X has received a phishing mail.
We investigated it, concluded okay, it was a phishing mail.
We had the possibility to say okay for the other organization even before they received a mail from this phishing attacker.
We had the possibility to say, okay, if a meal is received from that phisher, just block it.
(07:38):
Because we know based on what we saw within the other organization as well, that it's a phishing mill.
Jani Vleurinck (07:44):
Unfortunately, unfortunately, phishing still seems to be the major cause of accounts being breached.
It's fighting an uphill battle as a defender, really.
But we do believe that the fact that we can extend that information that we gain from one customer's phishing email to the rest of the customers really pays dividends when we are looking towards staying resilient of these Phishing attacks.
Sander Bougrine (08:06):
Yeah.
And that is also why it's important to not only collect eviction efforts.
Like for example, we have seen sender X which is sending phishing mails.
Okay, we are blocked going to block the sender, but next time he's smart and he's using a new sender entity, receiving phishing mails and then resolving them by saying, okay, it's phishing mail and blocking the sender is a good thing.
(08:28):
But it's formally aftermath.
So we're going to do aftermath.
Once the phishing mail is already gathered within the organization.
We don't only going to just investigate phishing mails and see, okay, is it a phishing mail or not?
Because then there are a lot of phishing mails.
Then we are just doing day to day operations, just only focusing on fishing meals.
(08:49):
An important thing there is to also create detection rules which are smart and not only looking, okay, has sender X send a mill is going to be fish.
We're also going to create detections with detection rules where we have seen certain things that are scoped on phishing.
For example, a specific attachment which is given within the phishing mail.
For example, a couple of months ago we had a lot of QR code phishing.
(09:12):
It's also important to create behavior based rules on that as well.
Jordy Decock (09:16):
Okay, you mentioned phishing as part of the campaigns that you guys have to handle.
Are there any other things we might see?
A lot.
I hear a lot about phishing.
I hear a lot about malicious malware.
Jani Vleurinck (09:27):
Yeah.
So right now one of the most popular ways of breaching an endpoint appears to be what we call click fix malware.
Pretty much what it does is it is going to tell a user who lands on a certain page, hey, I'm a captcha.
If you want to go past this captcha, you will have to press Windows R button, Control V and enter.
(09:48):
So in the background what this website does is it transfers a malicious command to your clipboard and as you press Windows R, you open the run functionality of Windows and Control V pastes it into the run functionality and then you execute it using Enter, which sets in motion a whole chain of malicious commands.
Jordy Decock (10:10):
I think one of the first things a lot of listeners might have right now is like, why would somebody fall for that?
But it's not the usual typical IT guy who knows the stuff that is falling for that, but it's the people who are falling for this who are not as technical as we are.
So I feel that's a really important step to Take in consideration that these malicious actors aren't focusing on the IT people, they're focusing on the rest of the organization to get to the IT people.
Jani Vleurinck (10:39):
Oh yeah, definitely.
They are going to go for the, let's say, I don't want to say this, but low hanging fruit I should say.
And from there they will oftentimes try to escalate privileges or move laterally, which is what we would say in the MITRE terms of it.
And yeah, these people are the most vulnerable within the organization.
(10:59):
But at the same time that doesn't mean that the IT people can't be targets too.
There are certain vulnerabilities and phishing campaigns that we've seen, for example, with malicious RDP files, with malicious Visual Studio files which target IT people.
Sander Bougrine (11:15):
Yeah, and this is an interesting thing because why they are attacking IT people is because they have a lot of high privileges and more privileges the attacker has, the more important it's going to be to travel within the environment.
Jani Vleurinck (11:28):
Yeah, because that way they don't have to do privilege escalation, they can just do lateral movement because they already have most of the privileges they need and.
Jordy Decock (11:35):
Is the fastest way to deal damage.
Jani Vleurinck (11:37):
That's correct.
Sander Bougrine (11:37):
Again, also, I think if we're talking about the catcher, also an important thing to note is that okay, we can detect certain things, but it's also important to do something with them.
Not only say, okay, we have detected them, we have done as lots of mitigation as we could, but also provide next steps, not wait till the next incident, but also go to the customer and say, hey customer, we've seen this specific traffic, we know that it's going on within the threat landscape, but let's do something with it.
(12:07):
For example, let's see that we can see.
Okay, if we're talking about regular users, do they need to have elevated privileges within a shell?
For example, Couldn't we restrict that so that once the user is falling in the captcha, the damage is restricted?
Jani Vleurinck (12:23):
Yeah, and on that note as well, it's not just about telling the customer that they can fix some stuff on there and we can also do some stuff we can, for example, user automated isolation, which means that as soon as one of those malicious cmdlets that are being executed by the Clickfix malware is detected, then the device will automatically get isolated, which were talking about earlier.
(12:45):
Which means that the attacker cannot make an inbound connection to take control over the computer.
And if it's a malware that works autonomously, it can't go and do electron movement around the network because the device will not communicate with the rest of the network anymore.
Jordy Decock (12:59):
Okay, we've talked a lot about how attackers can reach our employees or our network.
Maybe we should take a step back now and focus a little bit on the SOC itself.
At the Collective, we have our own SOC Security Operations center.
Which programs or which suite are we using at the Collective?
Maybe you should also explain why we as a collective especially choose this suite to use in our soc.
Jani Vleurinck (13:23):
So first of all, we work fully on the Microsoft stack.
So that means all the Defender flavors, Microsoft Sentinel and anything that Azure has to offer in terms of logging.
The reason why we do this is because all of the products, they just work with each other seamlessly.
Sander Bougrine (13:40):
Yeah, it's like an all in one solution.
You have the different types within an attack and the biggest, a big opportunity.
Microsoft is that they covering a lot.
If we're talking for example about Mitra.
Jordy Decock (13:52):
The attack, the attack framework.
Sander Bougrine (13:55):
If we're talking like for example about an attack where a user has fallen into a phishing mill, which is leading to initial access, which means that the attacker has access to the account.
Microsoft discovering a lot of things within there.
For example, we have visibility within the mail, but we also have visibility in the sign in logs which were generated because they are all collected within one centralized system.
Jordy Decock (14:17):
As a part of that, the thing we just discussed earlier, like you can go through Microsoft Endpoint live inside the user's laptop and we'll just reach the phishing email out.
Jani Vleurinck (14:29):
That is correct.
At the same time, you would be able to do the same with other EDRs, but it wouldn't work as seamlessly.
And setting it all up isn't as easy as it is with just an entire Microsoft stack.
Sander Bougrine (14:40):
Yeah, and I think another important note to make is that a lot of people are saying, okay, they are working with Microsoft solutions, so they are only focused on Microsoft.
But that's not true within our Microsoft solution.
Formally, if we're talking about for example our centralized SIEM system, Sentinel or Defender is there, we have the possibility to ingest other solutions as well.
(15:04):
If we are talking, for example an organization which is Google Cloud platform, for example, we have the possibilities and opportunities to ingest that locks as well.
And also see, okay, can we do important detections within that environment as well and not only focused on the Microsoft environment.
Jani Vleurinck (15:23):
And that's the thing I would like to come back on that.
Sandor said earlier that Microsoft already does a lot of detections, but we are also a force to be reckoned with when we are looking at creating our own detections.
So let's say by default, Defender XDR has an extensive suite of detections that will cover a large part of the MITRE matrix.
(15:45):
The bad part about this is that attackers will also know how to evade these detections.
Which means that creates an opportunity for us to create detections on top of the stack so that the attackers don't know what we have in store for them.
Sander Bougrine (16:01):
Yeah, and they're also SOC as a service is also a big opportunity.
Within that as well we have company which is working with certain solution and another company, for example, which is using another solution.
For example, let's focus on firewall.
A lot of companies are using firewalls to have insights into their traffic which is going for example, on their on prem environment.
(16:22):
That isn't a problem for us because we have the opportunities to ingest logs from both of these solutions.
So it doesn't really matter if we have a customer which is using certain integrations and another customer which is using other integrations.
If within our centralized team we have the possibility to ingest locks from other sources as well.
Jordy Decock (16:44):
Okay, so is there any like we're talking about Microsoft, the entire suite for.
As far as I know, there is not any other suite in the environment that even comes close to this complete solution.
Jani Vleurinck (16:59):
There is not a full suite, as far as I know that does it.
But there are individual components that you can make work together.
One of the most popular SIEM products out there is Splunk and it pretty much works the same way as you would expect Sentinel to do.
You can just ingest all of the logs from other products.
Sander Bougrine (17:18):
I think another important thing to also note is that if we are talking for example, like other SIEM integration, SIEM solutions that has the opportunity as well to ingest different sources.
I think also a main focus which is within the Defender suite is that Defender is also building integration rules that go with the solution as well.
(17:38):
We have for example within Sentinel, the content hub where there is already created some integration solutions which go with standard building detection rules.
So you don't have to create them your own or you just can start with them and then see, okay, what are they generating, how is the data ingested and then scope them more or update them by creating other detection rules as well.
Jordy Decock (18:06):
Okay, the reason there is a sock also on the market such as the collective delivers versus an in house soc.
Is there a big reason why companies aren't all getting their own in house soc?
Sander Bougrine (18:21):
I think the main focus Is how big is the organization?
Are we talking about a big organization which has the capability and the funds to have an in house society?
Then it might be interesting to have an in house soc, because then you can scope your SOC as much as possible on your specific organization.
(18:41):
But if we're talking about, let's say, for example, less bigger organizations organization where their focus isn't necessarily on security, it's interesting to have a SOC as a service because then you can outsource those activities.
You don't need your own people or your own resources to provide a soc.
Jordy Decock (19:02):
Yeah, I think one of the things we see a lot then from my part or from my side of the job is that companies have a two man team or a one man security team.
And when we speak about threat protection or anything else, considering Microsoft Defender, they have tried to set it up, but they don't have the time to take action on the locks they receive.
Jani Vleurinck (19:27):
And not just that.
So when you have your run of the mill SOC analyst, they will be able to analyze and take action on those alerts a lot faster than the internal security teams can.
The internal security teams oftentimes are not schooled in operational security.
They know how to harden an environment.
(19:47):
They know their environment inside out.
But how to interpret the raw logs that come from such alerts is a whole job entirely different.
Sander Bougrine (19:56):
I think another important thing is also quality.
When we have less bigger companies, they don't have the funds to have a SOC which has the quality to do it in a good way.
You can provide sock, which means, okay, we're ingesting a lot of locks, but There are certain SOCs which are ingesting as much as possible, but don't provide necessary detections or context within those locks.
(20:21):
I think quality there is an important thing to also do something with the logs that are provided within the SIEM solution.
Jani Vleurinck (20:27):
Our philosophy on it is mainly that whenever we ingest a new log source, we are going to do an in depth investigation on what that log source can tell us and what kind of new threats we can detect with it.
That makes sure that if the customer does spend money on ingesting those logs as Sentinel is often pay as you go.
So the more you ingest, the more you will pay that they will actually get some value out of that.
(20:50):
They will know that their threat landscape is covered more by ingesting those logs and paying that price.
Jordy Decock (20:55):
But there should be a good look at which logs are we ingesting, because I can imagine there are a lot of logs that aren't going to give you or deliver you a lot of value.
Jani Vleurinck (21:07):
That's correct.
In that sense, we do have a couple of options there.
So, for example, let's say raw network traffic logs.
Those are oftentimes not as interesting for us to ingest to make true like alerts on, but at the same time it is good for us to have as an enriching factor in our investigations.
(21:27):
Now Microsoft offers something which is called auxiliary logs, which costs less to ingest, but you will have to pay each time you query them.
But the amounts of time you need to query them is significantly lower than the standard logs that you ingest.
So it helps us in some cases where we have an alert where we need, for example, network traffic info that we can use that to, let's say, see if something is a true positive or false positive.
Sander Bougrine (21:54):
Yeah.
And also when talking about ingesting locks, which is a pay as you go service, it's also important to do analysis on.
Okay, we have specific locks on the firewall, but this could be dozens of logs based on the activity that is going on within the organization.
If we are just going to ingest row all of those logs, it's going to be a high cost.
(22:18):
It's also important to do analysis on, okay, what are the bare minimum logs that we need and what are important logs for us as SOC to do detection on?
Jordy Decock (22:28):
Okay, both of you actually work at the SOC of the collective.
I do believe a lot of customers know the term sock are familiar with that, but don't realize how the structure of a sock is set up.
Maybe we can enlighten a little bit like what are your jobs?
What are the other jobs that a sock has and how do we split it up?
(22:52):
How does a in house SOC take on the matter?
How does a sock us work?
Are there a lot of differences there?
Jani Vleurinck (22:58):
I'll start off with my own main job within the SoC, which is a detection engineering lead.
As a detection engineering lead, I pretty much write the queries and I also look at the queries that were already made that will generate alerts.
So whenever there is a new upcoming threat, I will analyze it, maybe try the new exploits on my own and see what kind of logs it generates.
(23:24):
Once I have those logs and I know what that kind of attack looks like in the logs, I will create a query that will look for those logs and that query will then generate alerts when something like that is found.
The other flip side is that I will also have to maintain the rules that I have written.
So when you are an external SOC like we are, you have a lot of companies under your wing and that means that there are a lot of angles for false positive.
(23:50):
These rules will need to be maintained to make sure that your actual analysts are not overwhelmed by the alerts.
So that means that a significant part of the detection engineer's time goes into maintaining those queries to make sure that they throw as little as possible false positives.
Sander Bougrine (24:06):
And I think another big important thing to note within the detection engineering stack as well is that the difference between now and SOC is there.
You have detection engineers which are mainly focusing on the core business of that organization and they can scope their detection rules as much as possible.
But within a SOC as a service, what we are doing, we need to be assured that once we have deployed the detection rule, once a new organization is onboarded, the detection rule is also going to work on that organization as well.
(24:36):
Which means we're not only focusing on specific entities or eviction efforts, but also focusing on, okay, what is the specific behavior that we want to detect with this type of.
Jani Vleurinck (24:47):
And that brings us to what you do in the society.
Sander Bougrine (24:49):
Yeah, so my job as an operations is two sided.
One is on the inside, where I look at the incidents that are coming in from different organization and also see, okay, are they managed correctly?
Is the investigation done correctly?
And also once the investigation is done, are we assured that next time the same activity is happening, that we are protected against them?
(25:11):
Another site which go hands to hand with that is communicating with customer.
For example, if we have seen an incident, it's important to not only just detect them and then say, okay, I've seen them, let's wait to the next one.
But also communicate to the customer, okay, we have seen that specific behavior, but let's check what we can do to be assured that next time we're seeing the same thing.
(25:32):
We are protected against it.
Jordy Decock (25:34):
Is that the only role that communicates with the customer?
Sander Bougrine (25:37):
It's not the only role.
I think a big importance within our service as well is that all of our SOC analysts can communicate with the customer.
And that's something we've decided because it's important that the analyst which has done the investigation has the most insights within it and the deepest dive within.
Okay, what was the activity that we saw?
(25:57):
If I need to collaborate on that as well, we're losing time.
And that time can be used to do mitigation or cok.
We've seen that, but how can we create important improvements?
For example?
So we decided that even SOC analyst has picked up an incident, he's not only going to do the investigation, but once communication needs to be done or extra input needs to be provided, he has the ability to also check that with the customer as well.
Jani Vleurinck (26:27):
And it's important that everyone on the team learns how to communicate with the customers because for example, just a normal analyst, someone who is doing the alerts, they also have to make the customer aware of what is happening.
Which we use teams to communicate with our customers in specialized chats where we will tell them the latest update on stuff.
(26:49):
And that brings me into the next role that we can talk about, which is the automation engineer.
We have an automation engineer who makes all of the playbooks, which is what we use in sentinel terms to automate certain tasks.
So let's say for example, Jodi, your computer chose a priority one incident.
Oh no, there's malware on your computer.
(27:10):
What do you think happens now?
Jordy Decock (27:12):
There is an alert signaled.
Jani Vleurinck (27:15):
That's correct.
What does this alert do on its own?
What would be the best case scenario?
Jordy Decock (27:20):
The alert on its own.
It's giving you a heads up on what is happening.
But I suppose that's not what I'm gonna get as a.
Jani Vleurinck (27:28):
Well, we do, we do get alarms on our phone.
We get woken up, we stumble out of bed.
We stumble out of bed all groggily.
Yeah.
We stumble out of battle groggily and then we open our computer and what.
Jordy Decock (27:40):
We see, it happened like four times today.
Jani Vleurinck (27:42):
Yeah, exactly.
And what we see is Jody's device has already been isolated because our automations have told us that's a priority one incident.
Jody's device needs to be immediately shut off from the network.
And that's the kind of work that our automation engineer does.
He makes the automations that actually talk to Microsoft servers and tells them like, hey, this device needs to be isolated immediately.
Sander Bougrine (28:05):
That's a big thing because then we're not only doing eviction efforts once we know what the attack means, which means that we could already lose a couple of minutes, maybe a couple of hours, who knows?
And the attacker may gain more privileges.
But if we are taking already mitigation actions once we are receiving those incidents, which can be assured that mostly there is something going on, that the eviction efforts has already been taken, we can do our investigation being assured that okay, the attack that was going on is already being killed by for example, the device isolation.
Jordy Decock (28:40):
Okay.
But not every critical incident is the same for every company, I suppose.
Sander Bougrine (28:46):
Yeah.
And that's also why it's important to note that we are formally working on behaviorals based on experience on the incidents that we have already investigated.
We have created a list with specific behavior that we know.
Okay.
Once we are seeing this, we can be assured that mostly something is going on.
(29:07):
If we are seeing this specific behavior, the automatic rules are immediately coming in and blocking potential threats.
Jani Vleurinck (29:14):
And also our detection engineer is in contact with the customers to tune the automations a bit to their liking.
So for example, we have one customer that told us like, yeah, I actually want all alerts from this source to be a priority one alert.
Could you also automatically isolate all events that throw such an alert?
And this is the kind of thing that our detection engineer also needs to talk with customers for because he needs to be able to tailor the automation rules to their specific needs.
Jordy Decock (29:44):
He needs to understand the business.
Jani Vleurinck (29:46):
That's correct.
Jordy Decock (29:46):
Okay.
Sander Bougrine (29:47):
And then when talking about that, I think we're going to our next important thing, which is cti, which also scoped on how the priority has to be specifically being scoped on a specific role.
We are collecting as lots as information during our investigation, which we are collecting in a centralized way within our organization.
(30:08):
For example, we have a MISP instance, which means this is a cooperative communication within the Benelux where we are sharing specific IOCs, which means entities which were seen within specific attacks.
We are distributing them with each other.
And within those misp, we can sync all the indicators to all of the organizations we're managing, which means that we have company X which is protected against a new threat landscape, but also be assured that company another company is also protected against.
Jani Vleurinck (30:38):
And these indicators can be a whole range of things.
They can be IP addresses, they can be domains, full URLs, file hashes, that kind of thing.
So if any of these indicators are then seen one of our customers environment, after we have synced those indicators to our customer's environment, they will a automatically get blocked and b raise an alert on our SOC so that we can investigate where did it come from and do we know if there is anything else that is connected to this attack still on the environment.
Jordy Decock (31:06):
Okay, so for example, one of the things that I'm understanding out of this is we have seen a hacker with his IP address in a different environment.
We engage the same IP address in one of our other environments that we're currently having on our soc.
We already know this is bad news and we will automatically isolate the device.
Sander Bougrine (31:25):
He gets to and not even if we only saw it within our organizations.
Like I said, we have the MISP instance which is a centralized ways by sharing specific eviction efforts which is seen as well as within other big organization within the Benelux.
So if they were seen within one of those organizations where we have a trust that okay, if we are seeing the same ioc, we know that it was seen within an attack within the other organization as well.
(31:55):
We can also be protected in that way as well.
For example, we are working with a private bank, a bank which is responsible for a lot of traffic within Europe.
They also have another community which is specific to the banking sector.
And that's also a big strange is we have those insights so we can implement that as well and be assured that if something is seen within any of the banking systems where a specific threat actor is seen which is specifically attacking those banks, we can collect that eviction efforts as well and also be assured that our partner which is also working in the bank sector is protected as well.
Jordy Decock (32:35):
Maybe adjacent to that.
What I experience from the business side, I feel a big pushback from the business side sometimes that they look at the size of soc, how big is it, how much employees do they have?
They think the more employees SOC has, the safer my company will be.
Jani Vleurinck (32:53):
And that's not entirely true.
I think that is widely outdated model.
The more modern SOCs, they work a lot with automations, they work a lot with scoping their detection rules to better.
So in the past the need for a larger SOC was mainly created because people were creating rules that were not very scoped on malicious behavior, but rather on oh, we saw this thing once in an attack which may or may not be related to the accuracy actual attack.
(33:24):
So it must be malicious.
Then they make a rule for that and that keeps going off and off.
It keeps creating false positives because it was not a correctly scoped rule in the first place.
Sander Bougrine (33:36):
And that's an important thing.
It's not human analyzing that is defining how much capacity you need.
But it's indeed how we are implementing our detection rules, how we are scoping a specific behavior.
Like I said, we could have specific behavior and say, okay, we have seen them, wait till the next one and next time we're going to say again, okay, we see it, we know it.
(33:59):
Yeah, just close it.
That's not efficient.
And that's also defining if we are going to need one analyst which is mainly focusing only on that or we are going to create specific detection rules as well as creating maybe specific automation rules.
Automation rules are more mainly focused on okay, we've seen specific behavior.
(34:19):
It's a bit odd, but okay, the customer has confirmed that he's using that specific application or that specific behavior is known to them, then we are also going to implement those automation rules as well.
Which means that next time an incident is received indicating that this activity is happening, it's not again analyzed by one of our SOC analysts, but we have an automation rule in place which is just saying, okay, we've seen the specific behavior, we know that going on is a bit off, but the customer has confirmed that this activity might be happening.
(34:52):
So just close rule.
It's good for documentation, for reporting, but we know that it's happening, so it's not useful for us to investigate it.
Jordy Decock (35:03):
Again, I think one of the big things that is a philosophy we also encounter or that we try to employ is that the more users there are doesn't mean that there should be more alerts.
Sander Bougrine (35:18):
No, Exactly.
We have for example organization which has 20 customers, but are creating like for example, 10 incidents within a day.
And then we have a customer which has 10,000 users which is generating only one incident a day.
It doesn't mean that the more users there are, the more incidents they're going to be.
It's also based on okay, how is the organization configured, but as well as how interesting is it for the attacker to use that organization as a victim.
Jani Vleurinck (35:47):
Well, to be honest, spray and pray attacks you are always going to encounter.
But the effectiveness of these spray and pray attacks will wildly differ across multiple organizations.
Let's say Organization a has about 50 employees, but they are not exactly hardened to attacks.
Meanwhile, the other one, Organization B, has about 900 employees, but they are very hardened.
(36:12):
It is completely possible that Organization A, although that they have a lot less employees, will cause a lot more load on a SOC than Organization B will, because Organization B already has restrictive controls in place that make sure that the attacks don't land in the first place.
Jordy Decock (36:30):
Also, I think the longer they are on the SoC, the more we have a vision on which are false positives what is actually happening inside the environment.
So that also helps of course, with downgrading the load on a sock.
Maybe just one more point on that is what are key takeaways listeners could take away after this podcast?
Jani Vleurinck (36:51):
Everyone can use a soc.
Any organization, no matter how large or small, in my opinion, can use a SoC.
It doesn't have to be much, but if you want to be well protected, you might as well get a SOC that does their own detection engineering, that does their own automations, and that actually looks into new threats and will actually make sure that they have means against those threats.
Sander Bougrine (37:17):
As SOC is not only investigating a lot of locks, incidents, alerts, but also checking, okay, what is important for that organization, but also see how can we improve that organization.
How can we see that the organization is defended against day to day landscape.
Jordy Decock (37:34):
Because not a single company is safe anymore.
I think we did have two examples of that already, didn't we, during the sock onboarding that suddenly get breached and they are really happy that were there.
Sander Bougrine (37:48):
Yeah.
And I think that's an important thing to mention.
Indeed it's not because you have a SOC that you don't can be breached.
It's important to know that we are evolving, but trend landscape is also evolving, but there it's important to not only do detection, but also response.
How can we be assured that if we see something new, okay, it could be that we don't immediately know what's happening, but how can we be assured that we be protected as soon as possible?
Jani Vleurinck (38:21):
And a SOC will be able to make you see these improvements a lot more easily.
So it doesn't mean that you can only use a SOC to defend you against attacks that are happening actively.
A SOC can also give you these insights because they have seen these things, especially SOC as a service have seen these things over and over again on other organizations.
(38:43):
And they can also proactively inform you that, hey, this is something we've seen on another organization that we are partnered with.
You might want to fix.
Jordy Decock (38:51):
This isn't one of the values a SOC brings.
Hey, even if you get breached, we will handle the breach really fast.
We can isolate a malicious actor.
Jani Vleurinck (39:02):
Yeah, so a lot of actors who get onto an environment will lay dormant for some time because they need to do stuff like privilege escalation, like virtual movement to do the real damage.
So anchor your systems, exfiltrate data that normal users do not actually have access to, for which they would need the privilege escalation.
(39:23):
And during these steps, the SOC can detect them.
Jordy Decock (39:27):
So that's a great example of why organizations who are currently, for example, in a SOC onboarding suddenly get breached because the other side sees movement and they realize, oh damn, we need to react really fast, otherwise our window is gone.
Sander Bougrine (39:43):
Indeed.
And that's also defining what a good attacker is.
A good attacker will also always be stealthy, which means he gain initial access, but is not immediately using it.
He's just creating connection between his device and the environment of the customer.
But then it will be quiet for time, which we also saw within the attack of the customer.
(40:06):
The customer was already been breached from couple of months which we saw based on the firewall logs, but the attacker decided to be quiet and then immediately do a total destruction out of the nowhere.
So that also means it's important to not only do detection, but also be assured that your infrastructure that you are using within your organization is being up to date and also have the visibility in the logs that are going over those infrastructure.
(40:35):
For example, if this customer was onboarded and we had visibility within the firewall logs, we will be alerted a couple of months before the total distraction that something was not right.
Jordy Decock (40:46):
Well, there are no other key takeaways and I think we can say that this was the episode about our SOC service for sharing your valuable insights.
And of course, thank you all for tuning in.
We hope you found today's discussion helpful.
If you did, don't forget to subscribe and share this with your colleagues, helping us reach more people who are just as passionate about building a safer digital world.
(41:10):
We'll be back next time with another important topic in corporate security.
Until then, stay vigilant, stay secure, and let's keep working together to shape a safer future.
Popular Podcasts
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by audiochuck Media Company.
Cardiac Cowboys
The heart was always off-limits to surgeons. Cutting into it spelled instant death for the patient. That is, until a ragtag group of doctors scattered across the Midwest and Texas decided to throw out the rule book. Working in makeshift laboratories and home garages, using medical devices made from scavenged machine parts and beer tubes, these men and women invented the field of open heart surgery. Odds are, someone you know is alive because of them. So why has history left them behind? Presented by Chris Pine, CARDIAC COWBOYS tells the gripping true story behind the birth of heart surgery, and the young, Greatest Generation doctors who made it happen. For years, they competed and feuded, racing to be the first, the best, and the most prolific. Some appeared on the cover of Time Magazine, operated on kings and advised presidents. Others ended up disgraced, penniless, and convicted of felonies. Together, they ignited a revolution in medicine, and changed the world.