Welcome everyone.
I am with Richard Chapman, with Cyber Now Labs, a SOC manager.
Richard, what does a Cyber Now lab?
SOC manager do?
My main focus is to work with the analysts to help them understand security events.
Basically investigate those security events and really kind of help keep the network safe and secure,
which is what most security operations center analysts do around the globe.
Great.
So Cyber Now Labs teaches students cyber security and in a real SOC environment, is that correct?
Can you kind of expand on that and what you teach your students, what tools they would be utilizing?
Yeah, absolutely.
So first and foremost, it's always good to have real, at least as real a situation as you possibly
can when you're learning how to be a security operations center analyst.
And what we've done is we've basically created a real network with real security tools, enterprise
grade tools that you would see in any SoC around the world.
And our analysts get to investigate real security events.
So they're investigating real attacks on our network, and it gives them the real experience that you
need to be able to say, I know how to work through a security event investigation, do incident response
on that, make good recommendations on what needs to be done to help either get that threat actor out
or block that activity from being successful in the future.
So is it fair to say then, that within your SOC environment that you guys start literally from the
foundation of an event occurring all the way to finishing the event and the paperwork inside, can you
kind of walk us through that process?
Yeah, absolutely.
Um, the incident response process starts with preparation, and that means having everything in place
to be able to detect these, these activities.
So our tools are designed to look at activities that are happening in and around our network.
And they generally have rules that they get broken which create alerts, detections, notables based
on the tool.
And our analysts are investigating those activities so they get to see them start out.
Then they understand exactly why it triggered and then they investigate those events to be able to determine
is this actually malicious behavior, or is it a false positive where you've got something triggering
that shouldn't necessarily be triggering?
And if it does, then what can we do to help minimize that in the future as well?
So it is basically from a ground up kind of perspective, um, here's a SoC environment, here's the
tools.
But let's start with the investigation from the very beginning.
Work all the way through it to even being able to, you know, make recommendations on what needs to
be done to help secure the environment.
Now, I know from my own personal experience that once you get involved into the education portion of
it, a lot of times you kind of fall behind on the trends and what's going on in real life.
How does how does your SOC differ from that aspect?
Because I know that you've got a live action SoC.
How do you keep up to date with all the newest security threats that are coming up to bear?
Well, there's there's a lot to to do to actually stay on top of things.
We are a smaller SoC so we don't get to see the advanced persistent threats.
Um, so we're not getting to see maybe as many of those emerging threats as a larger environment like
a well-known enterprise might see on a daily basis.
So what we generally try to do is we try to make sure that we're recommending to our analysts to read
cyber security news, you know, envelop themselves in the threat intelligence that is available out
there in the world.
We also recommend a bunch of different sources for them to read daily so that they see that activity.
And then we also do have some virtual environments where, believe it or not, we actually can create
some of those activities for them.
Now that's a little bit different than a simulated environment that, you know, a lot of I guess you
could say other opportunities to learn how to be a cybersecurity analyst might provide because those
generally are static.
It's not it's not new.
It's not recreated.
It's not regenerated.
It's kind of the same thing every single time.
Whereas we can go in and download a brand new piece of malware that just became available, executed
in an environment, and actually let our analysts see what it does.
So we've got many different angles, I guess that you could say we approach it from so that our analysts
are getting the most up to date knowledge.
They're they're able to learn as best they possibly can and basically come out of our program being
a solid cybersecurity analyst, that's kind of gone through almost like a trade school type mentality.
So you're going through and you're teaching your students stock, but you're also operating on a stock
in real time with real threats simultaneously going on.
So students get their hands dirty right at the get go.
Uh, can you kind of explain how prioritization or triage works in your SOC Environment.
Absolutely.
So first off, we do teach many different types of tools.
And one of the tools that we utilize is called a Siem tool.
It's basically an event manager.
And what it's doing is it's looking at the different alerts that are happening around our environment,
and it gives our analysts a single pane of glass.
So that means they can monitor that dashboard.
And when a new offense or a new notable pops up on the dashboard, they can begin investigating that.
Now that could be an email alert.
It could be an endpoint detection alert.
It could be some sort of brute force attack by a, you know, a device somewhere out there in the internet
trying to see if it can brute force its way into one of our systems.
So it gives them one spot that they can focus on and monitor.
And those alerts are ranked, and generally they have some sort of threat scale to them, you know,
a 0 to 10 high severity versus an informational severity.
And those informational alerts might not be the main focus, whereas a critical alert might be one they
really want to focus on because it's a potential critical issue that they need to jump on quickly.
But we also do teach our analysts how to think.
So just because it says critical doesn't mean it necessarily is.
That could be an issue with the way that everything is tuned in the rules.
So we obviously approach that from the realistic perspective as well too.
We've had many situations where a rule was created and right off the bat it was wrong.
So it was generating a lot of false positives.
So they have to be able to think through that process just like any analyst would in an environment.
Let me shift gears a little bit here.
So we talked about, uh, the triage effect and a lot of the tools which we're going to get into depth.
And I'm going to ask you to show off some of those tools in a few minutes.
But how can you kind of discuss how an incident occurs from start to finish?
Right.
We talked about how their data goes, but but how would you handle an incident from start to finish
from the ticketing perspective of and communication.
I think the first step for an analyst is to be able to understand what they're seeing in the alert.
So if, for instance, if they're looking at one of our Siem tools and they're looking at an offense,
it's going to give them artifacts that are associated with that offense.
It's going to give them the date, the time, how many events.
There were different pieces of information that allow the analyst to start to put together the picture
of what happened.
So that's kind of the first part of it, basically identifying that activity and really understanding
it, detecting it and then identifying it.
Then that analyst is going to start to really investigate and analyze what they're seeing, and they're
going to start to utilize open source intelligence, their understanding of network protocols, their
understanding of the systems that we have in our environment, their understanding of the device that's
actually carrying out the activity.
If it's an external device, they're going to start to paint the picture as to what's going on at that
point.
Then they're going to look and see.
Was any of that action allowed, was it successful or was it blocked.
And at that point it gives them the opportunity to then make a declaration.
Is this a true positive attack that we need to take action on now?
Was it a true positive attack from a malicious actor that was blocked effectively by the security tools?
That's a good thing?
Or is it a false positive like I mentioned earlier where the rule triggered, but it might not necessarily
should have triggered once they make a clear declaration, a lot of times it's going to be ticketing
next.
So that means taking the steps to grab all of those artifacts right there.
Ticket painting the picture of what happened, really kind of telling the story on this day and this
time, this IP, uh, triggered a detection in our environment by carrying out this activity on this
internal device.
Right.
Um, it's it's kind of telling the story, so to speak.
And depending on what needs to be done, the analyst is going to be able to make recommendations.
They're going to say, this is what needs to be done.
We need to block this URL.
We need to block this IP or add this IP to a watch list.
Or maybe this user needs to have their password reset.
So maybe they're going to send a ticket over to the help desk to accomplish that.
So it's really kind of stepping through from again the very beginning when you're just getting details
to understanding it, investigating it, making the declaration and then being able to write an effective
ticket for whoever needs to see it, whether it's somebody in the business arm of the of the company,
or whether it's the next tier analyst who's going to dig in deeper and really, really get to the fine
granular details that maybe a lower level analyst might not be able to understand in their early stages
of being a SOC analyst.
So for me personally, I often get asked by brand new people just trying to get into cybersecurity.
Maybe they already have security flaws, but they're trying to get in their first step of cybersecurity.
And I often get asked, oh, I just want to work in the basement with the hoodie on and the sunglasses.
I mean, obviously it's not that bad, right?
But but I get this mentioned that a lot of people have this misnomer, at least in my eyes, of thinking
that I'm going to get into cybersecurity and I get to work alone in the basement, and I don't have
to deal with anybody.
How true or false is that narrative?
Well, I will say, in today's post-Covid world, working alone at home in a dark office can be it can
be a real situation.
Um, but there, even with that being said, there's a lot of collaboration.
Uh, yes.
There are times where you're going to do independent investigations, independent work.
But, you know, collaboration is key in a SOC.
We know analyst knows everything.
And to be able to pull in an extra set of eyes, or maybe even a team of extra analysts who have got
a lot more years of experience put together than you do by yourself.
It can be the difference between identifying a real threat and maybe missing that threat.
So individualized work does happen, but collaboration is absolutely key.
You have to be able to effectively communicate with your team to be able to even, like I mentioned
earlier, paint that picture.
Tell your team what you're seeing, what you've been able to identify.
Um, maybe where some of your hangups are, what your thoughts are, and, and, and allow them to learn
from what you've already done so they don't have to redo the investigation.
They can pick up right where you left off and provide additional guidance and or knowledge and direction.
So it sounds like teamwork is really one of the the core fundamentals of being an a SoC.
I know for me personally, especially very early on when I was getting first into it and first into
telecom, that I kept on getting pressured by my own superiors to say it is not a solo sport, it is
very much a team sport and you can't know everything all the time.
Would you agree with that sentiment that not only is collaboration and communication important, but
being able to stand up and say I don't know, let me ask somebody and let me get the right answer.
Can you kind of go into depth, maybe with a scenario or something, what your own experience tells
about that?
Yeah, I will tell you 100%.
I agree with that statement.
Um, I've had situations like that myself where I'm working with, uh, analysts in a SoC shift, and
one of them will escalate something to me, and I'm like, I've never seen this before, so you have
to start digging in and really trying to understand exactly what's going on.
And I always start off with telling my analysts, it's very important to understand who's involved,
the who, the what, the when, the where, the why.
Right.
The more of that that you can put together, the better you're going to understand the possibilities.
Um, but yeah, there are absolutely situations where you're like, I don't understand why this is showing
up this way or why this is what it is, or I've never seen this process before.
Let's go figure out what this process is.
And, you know, we try to to make our analysts self-sufficient.
So we absolutely try to help them be resourceful so that they will take as many steps as possible individually,
on their own, as an analyst first.
I mean, you have to be able to do that to a certain degree, right?
But you do reach a point where you go, I need help.
I don't know what this is.
I cannot make heads or tails of this.
I think it's this, but it looks like this.
I can't find any information on that.
Whatever the case may be, there are times where you hit a point where your knowledge is exhausted and
your research is even not presenting additional opportunities to learn what could be going on.
So you have to be able to ask for help at that point.
It's a valuable, uh, valuable tool that I think that analysts have to have.
Awesome.
So we talked a little bit about incident response.
We talked a little bit about teamwork and collaboration.
I'm going to totally shift gears on you again and ask about compliance, because I know from from my
own personal perspective and the many, many years that I worked in it, compliance is a big issue.
How does a sock help meet those compliance requirements that we see?
First off, I would agree that compliance is not only important, it's becoming more important on a
daily basis.
I actually was reading an article this morning about a very well-known tech company who is actually
going to start holding their executives responsible for major incidents that that happen.
In other words, it's going to put pressure on executives to ensure that their security teams are following
best practices.
They're utilizing frameworks like the NIST framework to be able to ensure that they have the best possible
security in place to do everything possible to keep from breaches happening.
So I think there's going to be a much larger level of accountability as we move forward.
As a SOC analyst, it's it's obviously our job to do the investigations and to report on our findings.
So the better we can do at that.
And the more that we can actually provide those details to the tier twos, to the SOC managers, to
the CSOs.
That's going to allow them to make better decisions and implement better, better security measures
across the across the, you know, across the network.
Right.
So I think we play a key role in that.
We are that initial line of defense.
We're looking at things from the beginning and everything kind of gets passed up to the the next level,
and it gets processed all the way up to the highest levels.
Who are running the whole operation, and they need the best information possible, and they need to
be able to compare what they're doing and what they're seeing to those frameworks, to be able to keep
the environment as safe and the data as safe as possible.
Richard, thank you so much for your time today and the next episode.
You're actually going to show us some tools related specifically to a SoC environment and dive into
those complexities.
So thank you so much for your time Thank you for having me.
Pleasure.