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 ones 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 a more readily
easy to identify list per se.
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 exploits, 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 problem 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
value.
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?
For 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, i.e. 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 or 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 is 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 tasks.
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 going to 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 a deadline.
We don't want that deadline to be so far out there that it's never going to 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 our 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 that it's interfacing
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 invaluable input of hey, this is the normal
route 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 going to 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 hire everybody.
I won't have any vulnerabilities, but let's be realistic.
That'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 instance, phishing.
Usually phishing emails are a common problem within any enterprise environment.
So having awareness training every once in a while to say, hey, don't click on 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, two 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 forth.
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 a $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 VPN.
You need to provide a secure workspace to where other people cannot 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, an MOU is a agreement between two parties to understand a specific goal or a specific objective
within those two parties 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 needed 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 in.
For instance, in one case, we had a windows machine that didn't have Excel because we were still help
desk and we still had that memorandum of 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, memorandum of understanding, we were required to go out there and excel 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.
An MOU 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, time bound, 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 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 KPI 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 in the day.
Plus there's bathroom breaks.
There's lunch breaks.
There's just a human concept of, yeah, I worked a 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 to having a KPI.
And my instance, we measured tickets closed.
How many tickets did I close with an actionable item that was not reopened within the next 24 hours?
Meaning if I went out and I fixed a 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 can 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, uh, availability on your
internet activity for your organization within an SLO or a 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 own company.
Finally, we have an SLA or service level indicator.
This is the real number of the performance of how we did.
Now SLAs, SLOs and Slis, they're usually done on a monthly, quarterly or annual basis.
And so we may look at a monthly basis and say, oh well our SLA was 99.9.
Our SLO is 99.2.
For our internal objectives.
And our SLI was 99.13.
We met our SLA but we failed on our SLO.
Are we in trouble?
No, this was 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 SLA slow and SLA.