This security plus exam is filled with scenario questions and there are plenty of scenario questions
that talk about vulnerability impact now in lots of episodes.
We've covered all types of vulnerabilities and their impacts but there's a few that I want to hit a
little bit harder.
So really what I'm doing is I'm grabbing directly from the security plus objectives some of the vulnerability
impact scenarios that you're probably going to be seen.
So we're just going to put them up on the screen here.
And I'm going to come up with scenarios that you should be considering for the exam.
You ready.
Let's get started.
Race conditions a race condition simply means that something is running out of control.
We can have ports on switches that run out of control.
We can have applications that are running out of control whatever is running out of control.
We are denied the use and facility of that also in a race condition certain types of resources like
memory or storage can be eaten up very very quickly.
So when we see a race condition scenario the impact of that vulnerability is going to be at the very
minimum we are denied of the usage of whatever that device or software is and equally it can begin to
impact the stuff around it.
Other programs if it's a physical device it can start affecting other switches maybe and it's something
that we need to turn off and isolate as quickly as possible.
Embedded systems and embedded system is simply an immutable system that never changes.
That can still be it's still a full system it's going to have storage in ACP you add an operating system
and input output.
The problem with embedded systems more than anything else is because they're immutable.
We tend to forget about them a lot and we don't remember that they can have situations where they can
be patched so I guess not totally immutable but they are set aside and far away.
They need patches they need anti-malware.
They need firewalls they need everything that we would use with a regular system but because they tend
to be tucked away and forgotten sometimes we forget that the danger with embedded systems more than
anything else is we forget to take care of them the same way that we would take care of any regular
device.
Lack of vendor support.
OK.
There's lots of vendors out there selling lots of kinds of different stuff and lack of vendor support
is a big issue primarily with hardware.
There's some software situations too.
If a vendor is no longer supporting whatever it might be there's one of two reasons.
Either a the device or software has become obsolescent and the vendor is trying to move on.
Or number two the vendor is completely out of business.
In either case the biggest downside the biggest vulnerability is that we can no longer patch these devices
we can no longer keep them updated.
In some cases we can no longer get parts.
If that is the particular case.
So the impact there is that the device becomes open to potential problems.
And in that case usually the right answer is as we throw that stuff away and we go ahead and get something
new that has proper vendor support mis configured or weak configuration.
Now to me these are two very different things so first of all we configuration probably the ultimate
configuration is a default configuration.
So every piece of hardware and software out there have big list entire web sites that tell us what the
default usernames and passwords are for just about everything in there.
So it's really important for us to provide the best possible configurations we can change and usernames
and passwords but we configuration can also mean things like if I have four or five different types
of wireless encryption.
There's still plenty of wireless access points out there that still use WEP and I did a recent personal
study here in the Houston area discovered something like eight percent of all wireless networks out
there still run WEP that could be easily reconfigured to a stronger configuration.
The downside is as you create some form of exposure to some type of threat actor who will take advantage
of that configuration.
Now misconfiguration to me is a different animal altogether.
When we say misconfiguration that means we do have a configuration but we have done something incorrect.
So most the time when I'm thinking of this configuration is that we haven't turned on a service that
we might be wanting to take advantage of we didn't turn on a statelets firewall for example or it could
also mean something like we failed to turn off default services.
My home router has a wonderful S-sh server built into it but I don't want anybody using that.
It would certainly be in my opinion a misconfiguration to have that turned on.
So any time we do a misconfiguration we're exposing that device of that piece of software to potential
threats that shouldn't be there in the first place.
Improperly configured accounts.
OK so an improperly configured account basically means that we have a user or a system account that
isn't being provided the rights and privileges and permissions that it needs from the permission standpoint
it's either going to mean you're going to expose a particular account to far more than it should have
and the impacts there could be a regular user deleting a hard drive or something like that to the opposite
where they don't have enough permissions and then those types of situations they're unable to do their
job.
Also keep in mind that we it's not just permissions it's also rights.
For example if we were to accidentally turn off people's rights to access a system remotely we might
be preventing them from being able to do their jobs so in either case the impact is going to be the
potential that they can do something far more naughty than they should be able to or on the other side
of it.
They're not going to be able to do their job the way they need to do it.
Voltaren business processes so of alterable business process to me.
Every business process has some degree of vulnerability.
You know we always have a meteorite hit the building and those processes disappear.
But what we're talking about are unconsidered business processes that leave us open to potential impacts
from those vulnerabilities.
So one might consider something like storing non-essential information.
So for every customer for our sneakers we store not only their shoe size and their address and their
phone number but we're also getting all kinds of information about their birthday and things like that
in their Facebook account and things like that that don't really affect our business directly.
Anytime we're storing personal identifiable information and that could possibly be exposed the impact
could be massive in terms of the things that could go against us in terms of money and reputation to
say nothing of legal OK memory buffer vulnerabilities Well any time we use memory we have lots of vulnerabilities
in there.
But the list basically they say resource exhaustion memory leak Integer Overflow buffer overflow pointer
difference and DML injection.
And to me there's really three different groups in here.
First of all resource exhaustion or a memory leak in that particular case what we're talking about is
you're running out of memory.
In that case you've got two choices.
Number one you get more of that resource or add more RAM or never to use stop the thing that is doing
this.
So for example a memory leak is because we have an application that isn't written properly that it has
some type of problem.
This talks about a recode or a patch and you're going to have to go through and dig it up.
Memory leaks are one of the most notorious problems that we can get.
The bottom line is that if you run out of memory on a system even with virtual memory that the system
is going to lockup you will be deprived of that service completely.
Now a little bit different than that is integer overflow or a buffer overflow overflows will not necessarily
turn the system off.
But what they can do is they can make the system do weird things that it wasn't anticipating their famous
buffer overflows on a particular type of server where if you forced a buffer overflow you basically
got yourself to a terminal prompt.
So we're really putting ourselves in a lot of danger with these types of things simply because it could
allow a bad actor to take higher control of the system that we anticipated.
Now pointer dereferences and deal l injections to me those kind of fit into a different world.
In this particular case the system still up and running fine but we're sneaking behind a back door to
do potential naughty things.
So there's not a big clue with a pointer dereference or a deal o injection that something bad happened
with an integer overflow or a buffer overflow usually the service itself is turned off.
Suddenly the web server stops working or something like that these other two can be more nefarious.
The bottom line is that we have to have good firewalling.
We're going to have to have good code that is robust against these types of problems primarily input
validation and we're going to be watching these systems very very closely and specially if we're using
third party libraries for anything that tends to be are those types of problems come from System sprawl
or undocumented assets.
Wow I can't even begin to start to talk about the impact of the vulnerabilities of something like that.
Let's start with the easy stuff.
Number one it's not under my control as an administrator is it being patched is it being is it being
properly controlled is it being plugged into the right place.
It what are we using it for what are the user accounts being used for on that.
So at the very least sprawling systems that are undocumented because system sprawl and undocumented
assets tend to go hand in hand meaning that there is stuff that's outside the umbrella of administration
that unless the person who's decided to take care of it is just as good as I am we can be left open
to any type of vulnerability that you'd see with any individual host or application or VM or whatever
this sprawled device is.
And it could cause disastrous results.