Often when we look at end of life or outdated components, we need to understand 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 lifespan of about a decade, and after that
decade occurred, they stopped supporting it.
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 hack 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.
For 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 to sub dependencies being is there a third strain
of the software?
For instance, if I have Microsoft Windows, that is my part of Microsoft 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 on our system, identifying where is that software in play?
Is it currently vulnerable to attack?
This is much like what we might see in Nessus or another vulnerability scanner, but it's specific to
software itself.
What version are we currently running?
Are there known vulnerabilities to that specific version?
How is that interacting with our software as a whole?
And she can provide us detailed information and identifying 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 able to verify are they legitimately there?
Are they who they say they are?
And have we properly identified an authenticated that specific user and then authorize them to use specific
software?
This usually 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 multi-factor 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 multi-factor.
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 software's 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 four, eight, 16.
You get the point.
However, a lot of times we can limit the passwords to just three or more.
After three failed attempts, we lock you out of the system and force you to re-identify 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, two 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 users 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, i.e., 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 don't want 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 applications.
They provide some unique advantages to protecting our software from an application standpoint.
We want runtime application self-protection.
We want to also use containerization and virtualization.
If I'm using containerization and virtualization, 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 they able to get access to multiple containers using
the same code?
We also use containerization and virtualization for a lot of honeypots and honey nets.
When we're going through mitigating against 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, we're referring to the aspect of if an attacker gets into
a system, we don't want them to gain additional roles or responsibilities or access into other systems.
We want to limit their escalation process as much as possible, i.e., if I have a janitor 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 privilege 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 aren't 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 least privilege?
We can take away accesses where people don't need them.
When we talk about least privilege, we're really referring to what is the maximum access they need
access.
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 DAC, 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 that 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 and servers, so I could give him specific
access to a server that he's able to, uh, 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 i.e. is it 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, where 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 business, not really needing access to the finance department.
Why do they need access to the finance department or the HR 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 needs to move to a CRM 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 attributes or his rule only
permit from 8 a.m. to 5 p.m. that I need to be aware of that, and I need to log that specific, 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 regularly 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 any home computer that had properly introduced 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 professional people to go through and 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 a malicious user.
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 fills 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 RFI 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 web page,
and grants access to sensitive information.
RFI, 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 we mean by file sanitization?
When we talk about file sanitization, we're talking about going through a file and making sure that
PII 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 first 5 to 6 digits may not be prevalent.
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, where sanitizing files and getting rid of pertinent PII or sensitive
data that may be located on that file on that server, if it doesn't need to be there, then it's going
to get blurred out.
It's going to 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.