Often when we look at end of life or outdated components, Winter
said that those end of life components, whether it's software,
hardware or operating systems can pose a significant security
risk or vulnerability to our network as a whole.
In 2007, when Microsoft seven came out, they had about a a lifespan of about a decade
and after that decade occurred,
they stopped supporting when they stopped supporting it,
they no longer patched it.
Those vulnerabilities or new vulnerabilities
that erupted from that operating system
were no longer being supported by Microsoft and as such,
those vulnerabilities became every day anybody could access it.
It's not uncommon right now to find
vulnerabilities in Microsoft seven that are still
being utilized in a classroom as how to guides on how to act different machines
within the software cycle. We need to look at a software bill of materials.
Let's take a look at that.
Now, within the software bill of materials,
you can see here that it's nothing more than an audit form or software.
We identify the component name or the
specific software we're utilizing the version number.
This identifies whether the version is older or newer than what we've seen before.
If there's any
licensing information or associated information
where the product was purchased,
we have dependencies and sub dependencies with sub dependencies being.
Hey, does this software align to another software that we're utilizing
and then sub the sub dependencies being, is there a third strain of the software?
For instance, if I have Microsoft Windows, that is
part of
office, which is also part of Microsoft Windows,
then I would have a sub dependency of a sub dependency of a known software
and then finally known vulnerabilities,
you want to identify and detail the specific known vulnerability with
the CVE number or the critical vulnerability number and enumerate.
What known vulnerabilities are associated with that software.
When we're looking at a software composition analysis,
we're doing a scan or a specific
software that's looking at our current software in our system identifying.
Where is that software in play? Is it currently vulnerable to attack?
This is much like what we might see in
NSIS
or another vulnerability scanner, but it's specific to software itself.
What version are we currently running?
Are there no vulnerabilities to that specific version?
How is that interacting with our software as a whole?
And E can provide us detailed information and identify
outdated material that's currently residing on our operating systems.
We need to constantly be identifying and authenticating our users
that are currently residing on our network as a whole.
We need to be
to verify are they legitimately there are they who they say
they are and we properly identified and authenticated that specific user
and then authorize them to use specific software.
This usually co aligns with password policies
is the password they're currently utilizing something that
we want or is it an older password that quite honestly is weak in foundations?
When we're looking at password policies,
we also need to look at multifactor authentication or two factor authentication.
We are just going to depend on something they know we need to be aware.
Do they have something? They have something?
They are somewhere,
they are Multifactor authentication is becoming more
and more profound in the security world as
it limits Attackers from specifically using just
passwords to gain entry into our systems.
A Captcha is a little design you've probably seen
on websites before it thwarts automated responses for Softwares just
routinely going through and continually providing different passwords for
a system by requiring users to click on a,
on a specific button
that may not always be in the same spot or to arrange and
pinpoint specific bus terminals or street lights on a on a different picture.
This provides us a unique advantage
to identifying and stopping automated attacks.
When we look at rate limiting, how often am I allowing a user to provide a password?
If I know your username is your email,
then I want to limit the amount of times you can enter that password before
I start limiting the scope or the amount of times you can input that password.
This is usually routinely one second
as one second doubles, it continues to double and double again.
So if you enter a password wrong, I put a forced one second rule in there,
which means that you can't input another password for one second.
The second time, it's two seconds. Then 48, 16, you get the point.
However, a lot of times we can learn the passwords just three or more.
After three failed attempts,
we lock you out of the system and force
you to reidentify yourself and recreate a new password.
We can do session management,
limiting the amount of sessions which we've talked about before encryption.
Of course, access and control.
But the last one I really want to touch on is user education
with user education. We can identify and specifically state to our users.
Not only this is the policy, but this is why we have the policy.
You'd be amazed how many people in the office routinely go through and they're like,
I have no idea why I have to follow this stupid rule.
It doesn't make any sense. I don't like it.
It makes my life harder if they just understood why
they're required to input a new password every six months.
And why we require
two uppercase to lowercase two special characters and all the rules that we have.
You'd get a lot more buy in from your
employee base and that's done via user education educating.
Our user is probably one of the single greatest things you could
do for non it people to conform to our cybersecurity policies.
When we talk about remote code execution,
we're referring to the attacker's capability to execute malicious code
on a targeted platform that is remote ie it's not
there with them when we talk about remote
code execution and how to mitigate such attacks.
A lot of times we want to do that input validation.
Now I have drummed and beat that dead
horse on input validation all throughout this course,
I don't feel like I need to do it again.
But one more time input validation,
we are going to make sure that only the code or the special characters
that we want in the program are there and usable by the user.
We one special characters like semicolons in there
that is often referred to for code implementation.
And if we allow that into our system,
we're asking for trouble so we can do input validation.
My old adage, if I have a calculator,
I'm not letting somebody write a sentence into my calculator program.
We want application firewalls.
We want those firewalls to help protect our application.
They provide some unique advantages to protecting
our software from an application standpoint.
We want runtime application self protection.
We want also use containerization and virtualization.
If I'm using containerization and visualization,
then I'm able to set aside that
specific program or application or even operating system
and provide an extra layer of segmentation and thereby security,
which is going to help prevent remote code execution across the board.
They may get access to one container but are then able
to get access to multiple containers using the same code.
We also use containerization and virtualization for
a lot of honeypot and honeynets.
When we're going through
mitigating ignorance to remote code execution
really provides a defensive structure that
we really need to pinpoint when we're talking about software security.
When we talk about privilege escalation,
uh we're referring to the aspect of if an attacker gets into a system,
we don't want them to gain additional rules
or responsibilities or access into other systems.
We want to limit their escalation process as much as possible. Ie if I have a jit
that has access to Microsoft word and that's the only program
they have access to and somebody gets access to their account,
we don't want them to suddenly be able to access our servers.
This is referred to as privileged escalation.
When an attacker is able to move up the
chain or gain additional permissions or authority within our system
to prevent privilege escalation. We need to do least privilege.
It's not uncommon for an employee to change jobs over time or to get promoted.
If you have an it guy that has access to our servers,
our help desk policies and different aspects of our it
network and they suddenly get promoted into a managerial role
where they are doing that on a day to day basis and they really don't do it often at all.
Does it really make sense to maintain that access by doing lease privilege?
We can take away accesses where people don't need them.
When we talk about lease privilege, we're really referring to what is the
maximum access? They need
a uh maximum access, they need availability to
in order to do their job. No more, no less.
When we talk about mandatory access control, we're talking about military
level access control.
This is the most restrictive type of access control where we're identifying.
Hey, is this component,
does this specific person need access to this specific software?
It's very detailed and accurate and it takes a lot of time to pull off.
But we're really reflecting the user to the access level.
When we talk about discretionary access control or
DQ, this is the least restrictive access control,
the end user controls their access and with the
end user being able to control their access,
it's quite easy for them to go from one point of
access all the way up to a maximum access level.
This is probably not utilized very much in most enterprise environments. If at all,
we have role based access control,
which is the most widely used access control that I'm aware of.
This is where if I have an employee and that employee operates at the help desk,
then I can create access controls for every help desk employee.
If I have a new employee, they gain the role of help desk employee,
they gain access to every other thing.
A help desk employee needs no more, no less. Now, I can fine tune that.
Maybe I have a help desk employee that also has a subset of servers.
So I could give him specific access to a server that he's able to rely on.
But this role based access control is most likely used in enterprise environments.
I have rule based access control where I'm identifying specific rules.
IE is at this time of day that you have access to this system.
I may have a help desk employee that works from 8 to 5.
If he's trying to access our controls at 2 a.m. in the morning,
I probably might think that hey, this is an hourly employee.
He doesn't need access to the systems at 2 a.m. So they aren't authorized.
I have their access set from 8 a.m. to 5 p.m. No more, no less.
This would be an example of rule based access control.
Then I have something called attribute, access control.
I limit resources or access based on specific
attributes of the job title or location.
Meaning that if I have that same help desk employee and he works in,
I don't know Indianapolis, Indiana,
that's his location.
If he's only helping people in Indiana,
then why would he need access to systems or
to employees that are operating remotely out of Phoenix?
If that's not part of his job,
that would be an attribute that I'm going
to limit that's attribute based access control.
And then we talk about segmentation and isolation
when we're talking about isolation and segmentation,
where in the network are they able to be?
Do I want to segment them off this?
I most commonly denote this to an operations personnel who
works on the day to day operations of a company or
is this
not really needing access to the finance department?
Why did they need access to the pion
department or the department? I want to segment into their little, little area.
That's where they work. Stay in your lane.
That's segmentation and isolation.
Most often when we talk about privilege escalation,
we also need to take into account logging and monitoring.
How am I going to log the different peripheries that are going on within my network.
Again, if I have that help desk person and he does something on my network,
I want to be aware of that.
I want to log what he's doing.
If he accesses a server or attempts to log into a server, then that creates a log,
that log name needs to move to a stem where
it can be analyzed to find out what's going on.
At the same token,
if he's trying to log into the system at 2 a.m.
and his uh attributes or his role only permit from 8
a.m. to 5 p.m. Then I need to be aware of
that and I need to log that specific uh uh attempt.
And when that attempt is logged,
it's going to be monitored by the mechanisms in place
and then I can go back and detect what's going on.
I need to do regular patching and software updates. I pound this into the ground.
Patching is filling in vulnerabilities or flaws within our software.
We need to be regular patching to make sure that somebody doesn't
gain access to a vulnerability that we could have easily patched.
My favorite story about this is the Wannacry virus.
When Microsoft first came out with SMB 22 vulnerability,
the Wannacry virus didn't come out and take
advantage of that vulnerability for six months.
It was six months before the Wannacry virus
came out and actually exploited that vulnerability.
However, Microsoft had already patched it six months before any corporation,
any environment,
even the whole computer that had properly induced those
patches would have been protected from the Wannacry virus.
The first version
of a ransomware that was widely known across the world,
all it took was a patch yet millions upon millions of
users and organizations refused to patch their computers for whatever reason.
And the wannacry virus, even though it was completely preventable,
took stage front and center and took advantage of all those different computers
we want to do penetration testing.
Common folks doing penetration testing is not a good idea.
We want to hire professionals.
We want people that know what they're doing have a scope,
they understand what the rules are and they follow a contract.
We'll provide them a scope of work saying, hey, you're able to do this,
this and this but maybe not social engineering attacks.
When we talk about penetration testing for privilege escalation,
we're hiring professional organizations or special people to go through an
attempt to take advantage of vulnerabilities they find within our network.
It gives us a realistic idea of what's going on
through our network from the eyes of malicious users.
And finally, that application firewall, it's always going to be front and center.
It provides so much more defense in depth than what we're commonly used to.
It's just kind of that security blanket that spills over and helps fill in some
of those common gaps that we may see in our defense in depth structure,
local file inclusion or
LFI and remote file inclusion or RF I
pose common vulnerabilities found in web application where
LFI arises from the attacker manages to include a file located on
the server or in the webpage and grants access to sensitive information
RF I or remote file inclusion is the same except it's done via the remote structure.
As opposed to the local structure.
When we talk about input validation, we're going through that same process.
Am I validating the inputs that are in place?
Am I providing those access controls that we talked about before?
Am I sanitizing my files? What do I mean by file sanitization?
When we talk about file sanitization,
we're talking about going through a file and making sure
that pi I or sensitive data isn't front and center.
You can often see this in the military where
we have the full social security number in there.
But if you're pulling it off of a web server,
the 1st 5 to 6 digits may not be prole you'll
only see the last four digits of that social security number.
Maybe the date of birth is skewed out. Maybe the employee id is skewed out.
When we talk about file sanitization,
we're sanitizing files and getting rid of pertinent pi I or sensitive
data that may be located on that file on that server.
If it doesn't need to be there that it's gonna get blurred out,
it's gonna get removed.
We can do secure coding.
We've talked about this before where we're ensuring
that secure coding is from the get go.
We're making sure that code is not full of vulnerabilities or flaws that errors
have been detected and they've been corrected and that it handles errors properly.
We're going to do a web application firewall,
we're going to do patching and then finally, our file handling libraries,
are we using the library that's appropriate for the software that we're including?
Is that file library perceived to be truthful and honest,
it's not there to provide malware, it's not put there by just anybody.
We're ensuring that file library actually includes
relevant information from a good source.