As a security analyst,
a lot of times we concentrate on the technical nature of our jobs.
We look at the side of understanding that we are technically proficient
and that we're being paid well for the fact
that we now understand how to use the tools.
We understand logging, we understand operating systems, we understand networks,
we understand a plethora of technology.
The problem is is that our job
isn't just the technical world, especially as a true security analyst. We
need to understand the business side of it.
The business side is often involves reporting,
it does no good to be able to go through and
be a technical whiz kid and be able to identify specific problems
in different aspects if you can't communicate properly to those that
need to know about what we found or what we're doing.
It's great to be able to talk jargon with other
soc analysts and go oh I went and I utilized the
SIM and I I identified this malware and I utilized
this logging algorithm and I I created my own script.
That's great. That's fantastic. You're, you're great at what you do.
But how does that translate into somebody that has absolutely no
idea what you're talking about when you start talking tech speak.
And this is where vulnerability management reporting really comes into play.
We need to be able to put all
those technical words and all those technical definitions
into a format that is able to be
read by somebody that isn't necessarily technical granted,
we're not gonna be able to dumb it down to
a point where we have to spell everything out.
But we need to provide a report that's able for our stakeholders to be able to
read it with some level of technical inefficiency, meaning that yeah,
they understand part of the jargon, but they're not experts like you are,
the jobs are separated, they're different and you need to understand that.
So when we go through and we start reporting, we need to provide assessment results.
A lot of times those results are prioritized or
provided to us via the tool that we're utilizing,
whether it's Splunk or another SIM system.
But the fact is those reports are not always flawless.
And so a lot of times we'll go
through and we'll identify specific assessments that have occurred
and we need to highlight these problems because you
as a soc analyst or a security analyst,
your job is to understand what that means,
but somebody that's in management may not.
And
so we need to be able to highlight the real issues
that are going through and that's part of your job,
we need to be able to risk prioritization.
Meaning we need to say, yeah, the CV SS score on this is like a
7.8 but this one down here,
which is maybe a 7.3 is actually more critical to our organization.
And here's why that risk prioritization is important for the aspect of business.
And we need to communicate
to our leadership or to our stakeholders
why we're utilizing this type of prioritization
rather than what was spit out by this machine.
We also need to look at compliance status.
A lot of times when we go through these reports,
there may be a compliance issue that we need to be aware of,
that our management needs to be aware of and they don't necessarily have
the track record or the understanding that we do from an analyst side.
So if you've got a compliance issue, that may have a very low risk score,
but it will cost the company hundreds of thousands if
not millions of dollars because we're not falling within compliance.
We need to work on that first and we need to be able to dictate to our uh leadership.
Why we're going towards that first?
There's also trends a while back,
there was a ransomware trend that was going around.
We need to be able to say uh yeah, normally we would go after this malware first,
but we have indicators of ransomware, which is trending right now.
Maybe we should look at this first because we don't want to have
that process. We also need to be able to dictate
the different remediation processes that we're currently undergoing.
If I've been working on a remediation process for
two or three days and it's almost done,
then I need to provide that update to our managers.
So they understand
where we are in that process.
Uh I've had managers in the past where they're like, OK, well, you know,
you've been working on this for three weeks.
No, I brought this up to you, you know, two days ago.
Uh, it had a different problem three weeks ago.
A lot of times you'll find that managers look at different aspects too,
that we do.
They see the piece of equipment but they don't
really understand what we're doing with that equipment.
Uh,
sometimes because they don't bother to read it
sometimes because it looks very similar when,
in fact, it's very different and it's our job as the security experts,
as the technical experts to be able to,
uh,
to explain to them why we're going through the
different process or how this remediation process is undergoing.
It's not uncommon also to have a main remediation,
the
main problem that we've been working on and we solved part of it,
but we didn't solve the whole thing with those compensating
controls or with that mitigation process and it takes more
than just a week to go through it and they
just keep seeing the same thing popping up the reports.
They need to understand why.
And so we need to keep a careful mind of that set of that as well by recommendations.
Uh We don't usually have the capability or the authority to say
we're going to work on this because of Xy and Z.
What
we need to be able to do is
recommend a remediation process or mitigation process or some
type of process of what we're going to attempt to do and why we're going that route.
This is all part of that
vulnerability management reporting uh aspect where
the recommendations is just as important.
A lot of times as the remediation process or even the assessment tools
in order to explain, hey, my recommendations are we do this
because it costs less money or because it does this or it's only
gonna take me like three hours repair time rather than this big issues,
which is going to cost me, you know, four weeks of time of four people.
I can knock out, you know, 30 issues right off the bat within a day.
So let's work on those 30 issues today and we'll start on the big issue tomorrow.
Uh And that's part of that recommendation process that
we often undergo as part of our jobs.
When we go through this process through vulnerability management,
we need to be able to identify specifically which stakeholders belong to.
What
uh oftentimes we'll see stakeholders as a person or a department.
And we'll say, oh, well,
the stakeholder for my organization is the C
Suite or it's my director or it's this person
uh specifically related to this technology.
And that's, yeah, those are all stakeholders.
But what about the other stakeholders if I'm working on
a financial system or part of the financial enterprise,
meaning
uh the enterprise environment or the set
that is specific towards accounting or hr
they're stakeholders in our technology.
We just don't go around unplugging stuff or changing
their enterprise environment without letting them know they're stakeholders
and we need to identify those stakeholders as such
so that they're aware of what we're doing.
Nothing
more from a business aspect
of having that department head or have a department as a whole
working on a major project only to have it or cybersecurity come in
and blast everything out because they didn't let financial
know or that department know what's going on.
This is a major issue.
So we need to identify those stakeholders and keep them in
the communication loop before we start messing with their specific technologies.
Because there could be some underlying issues underlying projects that are on go
that we don't know about
and doing a normal day to day basis and just unplug it
whenever we feel like could really hamper their ability to proceed,
which is going to create some friction between our departments
and cybersecurity.
We often have friction with other departments whether we need to or not.
It's just part of our job.
Let's kind of minimize those friction points as much as possible
by identifying those stakeholders and
then communicating with those stakeholders,
what we're trying to do.
We also need to identify vulnerabilities.
It goes without saying that vulnerability
reporting management also includes vulnerabilities,
but you'd be surprised how many times a scan goes out or an assessment
goes out and we provide this detailed list of everything that's going on.
Somebody picks it up, they're looking at it and they're overwhelmed.
They have no idea what the world's going on along with our recommendations.
Path, we often need to identify specific flaws or weaknesses within our system.
We often perform a scan, the scan identifies vulnerabilities,
but they don't necessarily identify specific flaws as
an internal working expert in your field.
You should be able to identify specific flaws or weaknesses
in the system that a report doesn't normally cart out.
That means maybe I have a firewall or a web server that is, you know,
beyond its power curve, it's getting ready
to hit its end of life cycle where Microsoft
or another organization isn't going to support it anymore.
That's a weakness that's getting ready to evolve.
So we need to be able to go through and say, yeah,
we have this piece of equipment that's hitting into life in the next three months.
We need to plan to replace that equipment. I need budget for it.
A lot of times, three months is not enough time,
especially in enterprise environment, they need a year.
So you'll see Microsoft come out and say
this operating system is no longer going to be supported at this time.
They usually give us a year to 18 months.
We need to communicate that to management to say, yeah,
I've got three servers that are no longer being supported by Microsoft in 12 months,
we need to plan to replace those or upgrade
those or do something with them because we don't
want unsupported servers on our enterprise environment that's going
to lead to further problems in the future.
So understanding those flaws or weakness is important,
but it doesn't just include end of life items.
It also includes something like
um
uh inadequate configurations or design flaws or even human errors.
All of those can interact with vulnerabilities.
There was a piece of equipment when I worked for
a different company where by itself it was fine.
But as soon as you added this third party vendor into it,
it created a vulnerability within the system
that they knew about, but nobody ever fixed.
That's a weakness that wasn't being properly reported.
So we need to identify that we need and then
put it part of our vulnerability management reporting process.
We need to identify specific technical and
non technical aspects within our environment.
If I've got a $3 billion security infrastructure
and cybersecurity is well funded which never happens,
but let's pretend it does.
Right.
And we've got every tool we could ever ask for and we have all these,
these security measures and we are just rocking and rolling.
Uh That doesn't mean that our system is 100% safe. None.
There never underestimate the stupidity of nontechnical personnel.
People are out there and there's a lot of stupid people out there as I'm sure,
you know,
it only takes one person to click on a link or do something
stupid in your system to make that billion dollar system come tumbling down.
We need to be able to identify specific codes or specific problems,
both technical and non
technical,
whether it's people or whether it's a policy or procedure
that could affect our enterprise environment as a whole.
Uh Sometimes that's IP addressing, sometimes it's segmentation,
maybe it's just a policy that doesn't make sense because it was written
a decade ago and never been updated.
We need to be able to identify both technical and non
technical problems within the individual
clients or the individual enterprise environment
and persuade or I should say comment on those as we're going through now,
a lot of times it would be under vulnerabilities,
providing specific weaknesses or flaws in our system.
But
how do you identify a nontechnical problem as being a flaw
weakness or vulnerability that would need to be an affected host?
And that's where that's part of the report comes into play.
We also need to identify specific risk scores.
We talked about risk management before,
but risk scores kind of point out a specific measure
as we're going through the entire vulnerability management reporting process.
Uh We really need to be able to go through and identify
different CV SS scores or different scores that qual sis or open
boss or any of these scans provide us and go, yeah,
the critical vulnerabilities and exposure score is this
sometimes those scores work in our favor and we're able to convince management, oh,
it's got a 9.1 CBE.
This is something we need to take care of immediately
because it's gonna provide all kinds of problems with it.
At
the same time, our expertise needs to come into play and go well.
Yeah, I know it's only a 5.6 CBE.
But for our specific system,
this is in the coming into play and it's actually more critical for our inter
environment
than this 9.1. Now. Does that occur often?
No, it occurs very rarely, but it does happen.
And you as a cybersecurity expert need to be
able to dictate those different aspects of it.
We need to be able to dissect that CV score too
because don't expect management just to come in and go.
Oh It's a CV E 9.1. And you want to fix this by 0.6 it's gonna throw
of shade on you and you're going to have to
explain to them in a professional and technical manner.
Why you want to go after this 5.6?
At the same point,
we need to be able to identify why the scores are 9.1 and compare and contrast.
And this is important when it comes into the CV scores
where you need to be able to actually read them inside
your environment to make a compelling argument to your management of
why you want to do what you want to do.
Uh CBE scores provide us a great baseline
but we want to get out of that phase of just saying, oh,
it's ac be score 9.1 and living and breathing by that CV E
score because sometimes it just doesn't make sense to go through that process.
Uh It's really, really important. I cannot express this enough.
You must understand how CV E score works
in order to accurately identify the vulnerability of reporting
management system that you want to utilize for your organization
don't fall into that trap where
the score is this and I'm just gonna do highest or lowest.
That is a mistake waiting to happen.
Mitigation is the process of understanding those CBE scores and
those vulnerabilities and those flaws that come into your system.
But being able to mitigate it, I may have a 9.1 CBE score.
Uh And I've thrown some defense in depth, I saw some mitigating factors in there.
But even though the scan is coming back and saying it's still a 9.1 with the
mitigation factors I have put in place it's more closely related to probably a 3.2.
Uh Does it actually happen like that? Absolutely not. Right.
But we do those internal processes in our mind as we go for
the CV E score is still there. We're still utilizing it.
But how can we mitigate that impact? Right.
Because if you remember mitigation or excuse me, um
impact
times likelihood,
right?
So if I can mitigate those impacts,
I'm actually derailing that score down to a lower level.
So I really want to go into play and
provide as much mitigation to my system as possible.
This could include patching. It can include uh configurations, it can
include software updates.
Uh There's a whole host of different things that I could
do including defense in depth that would mitigate those issues.
Uh I would read through the five steps of risk management plan.
It's a great summary of what's going on.
You can find it at the link provided in the slide.
When we look at mitigation factors or we look at flaws
or vulnerabilities or even uh uh misconfigurations in our system,
we often need to look at recurrent.
How often is the same issue popping up within our system
when we go through recurrence,
we have literally three items that we could do just like risk,
we can either accept it going.
Yes, I understand that this vulnerability is there.
I need to understand the flaw that's taking place and I accept that level of impact
that's going to occur on my system and it's going to occur this many times.
Uh I can mitigate the factor.
We just talked about mitigation and how we want to go through that process
or I can fully remediate the issue ie get rid of it altogether.
Recurrence really comes into play of the likelihood
of this happening repeatedly throughout our system.
Uh I could tell you that we had a known bad piece of hardware in a,
in a company I worked for in the past and
within that, we would expect to see the issue arise at least once every other week.
Uh It was a two hour drive to the specific equipment, which means every
week I was driving two hours there to fix the issue and then two hours back,
here's the worst part,
the fix for it that the manufacturer came out was literally just power cycling.
So every week, I would have to drive and take up four hours of my time,
two hours there, two hours back, just power cycle equipment.
So it worked for another week.
It was atrocious, it. It was not good for the company.
It was a waste of my time and it was a waste of company resources, but it happens.
Uh So how can we fix or remediate that issue sooner rather than later?
Um the worst part is, is that same flaw,
that same vulnerability within the system that
required that our cycle also meant that we
other sites that we're doing the same thing that's costing your company money.
In those cases, you really have to get with the vendor
and go through the process of going I need to fix and I need one now,
like not two days now and kind of put some heat
on that vendor that really goes through the management cycle,
especially if you're a security analyst to have
them push on that vendor uh and work with
other companies that have the same equipment to get
the vendor to actually push through whenever possible.
Uh So recurrence again, something that we need to be aware of as it goes through.
How often does that vulnerability pop up or that flaw or that issue that I'm seeing
uh finally prioritization.
We talked about prioritization a little bit before this is a nice
little risk comparison for prioritization uh on a five desk chart,
right?
We're looking at severity times occurrence,
how critical is the issue versus how often it actually occurs.
Uh If we see this and we've talked about this before where
I've got a flaw of vulnerability or a misconfiguration in my system,
uh and the impact the system or the severity of that system taking advantage of
uh comes into play, right? So let's let's kind of digress here, right?
If I've got something like telnet
that I'm utilizing. Well, that's a pretty high occurrence, right?
Because it's always open. So the occurrence rate would be frequent,
right?
However, is it a critical or major issue? I would fall ft
or excuse me, telnet
being
a
transmission of plain text information within my system as being very major,
uh it could even be critical and then we just align the two, right?
So we take the top at a four for major drop it
down to frequent and we have a critical score of 20.
That means that we should probably expect that issue rather
sooner rather than later when it comes to prioritization.
What about a flaw say in our system where the vulnerability provides remote access,
that would be a critical issue because it provides remote access into our system.
But you have to be a technical whiz kid in order to do it,
you have to pin the other certain vulnerabilities together,
reinforce specific vulnerabilities and provide them
together and push them together.
And it takes a computer science major,
somebody that really knows what they're doing, likelihood would be improbable.
And so it would drop down to a five
on that critical score which is a medium prioritization.
Uh It's just a different aspect of doing it much like risk matrix,
same basic concept.