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 know 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 wiz 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
SEM, and I identified this malware and I utilized this logging algorithm and 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 over to 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 going 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 Cem 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 identified 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.
When are you able to risk prioritization.
Meaning we need to say, yeah, the Cvss 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 leadership why we're going
towards that first.
There's also trends.
While back, there was a ransomware trend that was going around.
We need to be able to say, 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 to go through 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 2 or 3 days and it's almost done, then I need to
provide that update to our managers so that they understand where we are in that process.
I've had managers in the past where they're like, okay, well, you know, you've been working on this
for three weeks.
No, I brought this up to you.
You know, two days ago it had a different problem three weeks ago.
A lot of times you'll find that managers look at different aspects differently than we do.
They see the piece of equipment, but they don't really understand what we're doing with that equipment
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 process or a main problem that we've been working
on, and we solve 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 side of that as well.
Finally, recommendations.
Uh, we don't usually have the capability or the authority to say we're going to work on this because
of X, Y, 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 Vulnerability management reporting 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 going
to take me like three hours of 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.
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
from 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 the enterprise environment
or the segment that is specific towards accounting or HR, their stakeholders and our technology.
We just don't go around unplugging stuff or changing the enterprise environment without letting them
know their stakeholders.
And we need to identify those stakeholders as such so that they're aware of what we're doing.
Nothing sucks more from a business aspect of having that department head, or have the 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 ongoing that we don't know about.
And doing a normal day to day basis and just unplugging 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 mean 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 in the world is going on.
Along with our recommendations path, we often need to identify specific flaws or weaknesses.
When 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
within the system that a report doesn't normally turn 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
end of 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 weaknesses 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 weakness 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.
Number.
Never underestimate the stupidity of non-technical 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 hosts 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.
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 there would be under vulnerabilities providing specific weaknesses or flaws in
our system.
But how do you identify a non-technical problem as being a flaw or weakness, or a vulnerability that
would need to be an affected host?
And that's really 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, we really need to be
able to go through and identify different Cvss scores or different scores that Quarless or Openvas 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
CVE.
This is something we need to take care of immediately, because it's going to 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
CVE, but for our specific system, this isn't coming into play, and it's actually more critical for
our enterprise 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 CVV score too, because don't expect management just to come in and go,
oh, it's a CV 9.1 and you want to fix this 5.6 it's going to throw some 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 score is a 9.1 and compare and contrast.
And this is important when it comes into these 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.
CV scores provide us a great baseline, but we want to get out of that phase of just saying, oh, it's
a CV score of 9.1 and living and breathing by that CV score, because sometimes it just doesn't make
sense to go through that process.
It's really, really important.
I cannot express this enough.
You must understand how CV score works in order to accurately identify the vulnerability of your 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 going to do highest and 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, and I've thrown some defense in depth.
I've solved 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.
Does it actually happen like that?
Absolutely not.
Right.
But we do those internal processes in our mind as we go forward.
The CBE 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 could include software updates.
There's a whole host of different things that I could do, including defense in depth that would mitigate
those issues.
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 on the slide.
When we look at mitigation factors and we look at flaws or vulnerabilities or even, uh misconfigurations
within our system, we often need to look at recurrence.
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.
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, i.e. get rid of it altogether.
Recurrence really comes into play of the likelihood of this happening repeatedly throughout our system.
I can tell you that we had a known bad piece of hardware 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.
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 and two hours
back just to power cycle the equipment.
So it worked for another week.
It was atrocious.
It sucked.
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.
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 power cycle also meant that we had other sites that were doing the same thing that's costing your
company money.
And 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 and work with other companies that have the same equipment to get the vendor to actually
push through whenever possible.
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?
Finally, prioritization.
We've talked about prioritization a little bit before.
This is a nice little risk comparison for prioritization on a five disc chart.
Right.
We're looking at severity times occurrence.
How critical is the issue versus how often it actually occurs.
If we see this and we've talked about this before, where I've got a flaw, a vulnerability or a misconfiguration
in my system and the impact that system or the severity of that system taking advantage of 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 uh, 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 or excuse me, telnet being, uh, transmission of plaintext 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 for 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 wiz kid in order to do it.
You have to pin together certain vulnerabilities, together 3 or 4 specific vulnerabilities and provide
them together and mush 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 the critical score, which is a medium prioritization.
Uh, it's just a different aspect of doing it, much like risk matrix same basic concept.