Let's face it.
When you first run your first vulnerability scan
against any new system or enterprise environment,
you may see hundreds, if not thousands of different vulnerabilities,
flaws or misconfigurations that pop up.
How do we identify which one should we work first?
Versus which one we should work last. How is that system all made up?
We need to prioritize the different vulnerabilities,
flaws and misconfigurations and are more readily easily to identify list.
This means we need to identify the severity.
When we look at severity,
we're looking at the impact the system has on our environment.
This means is the system.
If it was exploited or if that vulnerability was exploited,
how much damage would it do to our enterprise as a whole?
If I've got a malware that exploit that is being used
to exploit a vulnerability and it takes down an entire server,
that's a problem.
However, it may not be a critical.
When we talk about criticality,
we're talking about an individual component within our system.
So I could have a high severity but a low criticality.
Meaning that if I have 15 servers and one drops off the air,
is it really that big of an issue on the enterprise environment as a whole,
probably not as we normally keep our servers at 50% capacity,
losing one server while yes,
it is a problem doesn't necessarily mean that it has a high criticality.
However, at the same token, if I have one router and that one router goes down,
the criticality could be enormous.
It is a major problem because my entire network is shut down.
So when we look at severity,
we're looking at the overall impact of the environment
where criticality is the critical component within my system.
Finally, we need to look at resource availability. And
do I have enough resources to accomplish what I'm trying to do
prioritization?
Again,
if I have 15 servers and one drops off the air
and I have enough resources to bring that server back online,
is the resource availability high or is it low?
If I've got only one router and one repair mechanism,
ie one replacement and it drops off the air, that's not only a high criticality,
a high severity,
but I also have low resource availability because there's only one of them
and only one replacement.
When we talk about resource availability,
we're really referring to how much stock do I have
available across my entire network to fix the issue.
If something were to happen to it.
Overall, we need to look at different action plans,
action plans dictate how we define or how we do something within our network.
Normally an action plan goes into say, oh, I want to employ this software.
I want to do this in my network first. We need to come up with different objectives.
What is the objective we need to define
accurately and completely what we're trying to accomplish
it? Know
no good to anybody. If you say, oh, I want to make the network better.
That is not an objective,
that is a value or a plan of action that we're trying to strive for.
That's a guideline.
An objective would be I want to make our network better by
replacing all the routers with this newer router that has higher efficiency,
better validation, better authentication
and better streamlined services.
That would be an objective replacement of routers to make the network better.
We've defined our objective. Finally, we want to do task.
We want to break down the objectives into high level task. How are we going to do this?
Well, I need my asset department or my supply chain management to order the routers.
I need to dictate to my operations department that they need to replace
the routers during the maintenance window between this date and this date,
I've identified different tasks.
I need to assign the teams responsible for each one of those tasks.
Usually this is done at the same time, the tasks are identified but not always.
For instance, when I said, hey,
I want to replace the routers with new ones I'm going to
dedicate the operations team to do so that's assigning the responsible party.
But if I just said, I want to replace the routers during the maintenance window,
I'm really kind of leaving a lot up to interpretation.
Maybe the hr department feels like they're qualified to replace routers.
You just don't know,
you need to assign the proper team to assume the proper responsibility.
We need to schedule deadlines.
If I just said, hey, let's replace the routers with the operations team.
The operations team may come back and say, well, we're down on manpower.
It's gonna be seven months before I can get to it. It's not a big deal.
It's just replacing routers.
Their schedule may be different than yours.
You need to be able to say I want the routers replaced at a certain time.
We don't want to say specifics like October 14th at 239 in the morning.
We want to kind of give a window that they can operate on,
but we definitely want to give its deadline.
We don't want that deadline to be so far out there that it's never gonna get done.
It's going to be forgotten.
So most of the time we want our deadlines to be 30 no more than 60 days out if possible.
We want to plan resource allocation if I'm replacing routers.
What does that entail? Do we need to replace Ethernet cables while we're at it?
What about the connectors? How about power?
What about resource allocation to make that happen?
Resources include more than just supplies and assets. What about the manpower?
I can have the it team replace the router. But what if I have a bigger network imposed?
Do I need to get with the hierarchy or the
class two technical support to make sure it's facing correctly?
I need to plan my resource allocation properly so
that everything is coinciding at the same time.
Finally, I want to execute the change.
I once I've executed it and the router has been replaced, I want to monitor it.
Am I still getting the same amount of traffic that I got before?
Am I seeing an increase in the throughput? Is it doing what I wanted it to do?
We often take baselines and those baselines provide us some valuable input of, hey,
this is the normal
in
which the router was operating at. It's doing three terabytes per hour.
That's a respectable speed for this router.
We've replaced it with this new router and it's
supposed to go up to five terabytes in speed.
Is it hitting that mark? Did it not hit that mark?
Are we still seeing three terabytes?
Maybe we're seeing one Terabyte if we're only seeing one and we normally see three,
that's a major problem.
We need to continually monitor that new device
and make sure it's handling effectively and efficiently.
The way that we decided to go,
we need to do awareness training and education.
Did you know that?
93% I'm gonna say that again,
93% of all vulnerabilities within a system or all
exploits caused through vulnerabilities come from human beings.
That's right. Your everyday worker is causing those problems in our network.
Now, I know most of you are like, oh man, let's just fire everybody.
I won't have any vulnerabilities, but let's be realistic.
It's not really something we can do.
So we have to provide training, awareness and education.
This training and awareness and education hopefully brings down that
93% in your organization down to a respectable level.
We can do that through awareness training,
awareness training means that we're going to go through and we're going to identify
different points within our network that are having issues for instant phishing.
Usually phishing emails are a common problem with any enterprise environment.
So having awareness training every once in a while to say, hey,
don't click on an email phishing links that you don't know Excel documents that
you didn't request isn't something you should
be clicking on from an outside source.
We should have password security. Why does your password
need to be this long? What's the purpose?
We can often create policies to our users and say, oh well,
your password needs to be 24 characters in length.
It needs to be in a statement format.
It needs to have two numbers, two letters,
two uppercase to lowercase with at least three special characters
and expect our users to follow it. But you're going to hear a lot of grumbling
often. What we need to do is tell our users why we're doing something.
We're doing a password security model because the old one didn't work properly.
And since it didn't work properly,
you're having to change your password every 30 days.
And because you're having to change your password every 30 days,
you're forgetting your password.
If we provide context to our policies,
you'll get a lot more feedback from your workers
and they'll see the need and the
reliability of the policy that you're putting forward
if that doesn't work. We just technically do it and make it do them anyway.
But let's be honest,
it's sometimes better to know the why we don't want to treat our employees
like three year old kids because I said so is not an appropriate answer.
When an employee asks you,
why do I need to change my password or why do I need to follow these password policies?
We need to do social engineering awareness.
We need to make our users aware of the fact that, hey,
Facebook is a problem getting instant messages on your telephone saying to click
this link because you could reward yourself
with $100 gift certificate from Subway.
Not an appropriate text message to be clicking on.
We need to have remote work policies and understand that, hey,
when you're going through remote work.
This is the avenue you need to take. You need to use a VP,
you need to provide a secure workspace to where other people can see your screen,
which means don't remote work at Starbucks.
We need to have an incident response plan and understand that our incident
response could alleviate some issues but also
cause some responses that our workers not
be may not be aware of all of this comes into that training and
awareness and education that we vastly need
to do within our enterprise environment.
Often we'll see a memorandum of understanding now
what mou is an agreement between two parties to
understand a specific goal or specific objective within
those two parties uh that's relevant to them.
What do I mean by that?
I saw an mou one time that identified my department was to work with another
department at the time I worked with operations
and the other department was finance and they
access to different technologies within their environment
by having that mou in place,
we were required to facilitate and to support them in their
technical uses for equipment that they might not otherwise have expertise.
For instance,
in one case,
we had a Windows machine that didn't have Excel because
we were still help desk and we still have that memory
understanding. We had to go out there and actually install Excel on their computer.
Now you would think to yourself, oh my gosh, Excel. It's not that difficult to do.
But via the
memorandum of understanding, we were required to go out there and
install these programs on their machines.
Now, I use Excel as kind of a low end documentation.
But let's think about it from a different perspective. If I have two organizations
and both organizations want to work together on a project,
then having that memorandum of understanding that
dictates how we're going to work together,
how many hours we're going to do?
What the scope is,
what our compliance considerations should be used and what
system resources that they could use within our interoperability.
It all makes sense and
is an important aspect within cybersecurity and
within our industry because it really dictates
how we're going to work with other parties outside of our own department.
Metrics and key performance indicators or KPIS are specific
timebound relevant, attainable and measurable quantifiable objectives.
Now, I know I threw a lot of words at you,
but I want you to understand how important this is KPIS are often used by
managers and by business employers to understand how
we're doing within our own work environment.
It wasn't uncommon when I was working in telecommunications,
for Kpis to be used for everything and I do mean everything.
How many tickets am I getting through a day if I repaired this specific item?
How long did it take me to repair that item?
How many of those items did I replace in a week? How many critical tickets did I work?
Versus how many major tickets? How many uh minor tickets? How can I improve myself?
How could I understand a specific relevant manner when we're looking at Kpis?
It's a measurable goal that is attainable and attainable is
the big portion you can make a KP I,
that is extraordinary.
Right. You could say, oh, I want my workers to work at least 100 tickets per day.
Right.
And each ticket takes 3 to 5 minutes to work.
That's not possible. There's only so many minutes of the day.
Plus there's bathroom breaks, there's lunch breaks,
there's just a human concept of, yeah,
I worked the ticket but I still have to fill out the ticket properly.
It needs to be attainable. Finally, it needs to be measurable.
If you can't measure success, then there's no reason having a KP I,
in my instance, we measured tickets closed.
How many tickets did I close with an action item
that was not reopened within the next 24 hours?
Meaning if I went out and I fixed the problem was
another ticket open for the exact same item within 24 hours.
If it was, that ticket did not count, it was not measured.
So we need to identify the scope and specific instances in which our KPIS
interact.
We have something called sla service level agreement.
A service level agreement is an agreement between two
organizations that specifically state what you're going to provide
for instance,
if I'm a telecommunications company and you're getting internet from me,
you
state within our contractual agreement that I want a 99.9 uptime with my internet.
That is a service level agreement that I'm signing off on.
I'm stating as the telecommunications company that you will have a 99.9
availability on your internet activity for your organization
within an slo or service level objective.
We are providing an objective that says, yes,
my company promised 99.9 but maybe inside of our organization, we're saying,
you know what, let's go for 99.2%.
Our goal as an organization is to provide 99.2%
uptime or availability to that internet to this company.
Now, that's a service level objective within the owned company.
Finally, we have a SL
or service level indicator. This is the real number of the performance of how we did.
Now, Slas
Slos and
SLS, they're usually gone on a monthly, quarterly or annual basis.
And so we may look at a monthly basis and say, oh, well, our sl was 99.9. Our sl
is 99.2
for internal uh objectives. And our sl I was 99.13.
We met our SL A but we failed on our slo. Are we in trouble?
No, as far as the company organization is concerned,
the outside organization is happy they met their 99% uptime
but we have some work to do on our slo for internal objectives. This is Slaslo and SL I.