In this lesson,
we're going to talk about two key terms:
hardening and patching.
Now, when I talk about system hardening,
this is the process by which a host or other device
is made more secure
through the reduction of a device's attack surface area.
Now, what does that mean
when I talk about an attack surface area?
Well, when I talk about an attack surface,
I'm talking about the services and the interfaces
that allow a user or program
to communicate with a target system.
This allows all of these different services that are there
to be vulnerable for somebody to attack them, right?
And that's the idea of system hardening,
is I want to close down as many of those as I don't need
because that will end up hardening my system
and reducing that attack surface.
Now, any service or interface
that is enabled through the default installation
and left unconfigured should be considered a vulnerability.
And so you should scan that, you should identify it,
and then mitigate or remediate that
based on what you need to do
as part of your system hardening.
Now, when we start talking about system hardening,
I have this wonderful system hardening security checklist.
These are 10 major areas that you need to check
when you're trying to harden a given system.
First, you need to remove or disable devices
that are not needed or used.
For example, are you using Wi-Fi?
If not, disable it and take out the Wi-Fi card.
Are you using a CD-ROM or a floppy drive?
If not, take those things out.
Anything you don't need, you should remove or disable
because anything you don't need is another thing that's open
and could be used by an attacker,
and that makes it part of our larger attack surface.
So, by removing it, we are going to harden our system
and reduce the attack surface.
The second thing is we want to install operating system,
application, firmware, and driver patches regularly.
If Microsoft knows there's a vulnerability in Windows
and they put out a patch on Patch Tuesday,
you should be downloading that patch, testing that patch,
and then deploying that patch across your network,
because you want to make sure you are patched regularly
and up-to-date with the latest security precautions.
Because if somebody has a patch out there,
bad guys will usually reverse engineer that patch
and create an exploit.
So you need to make sure that you are patched
to prevent those exploits
from being effective against your systems.
The third thing I want you to think about
is uninstalling all unnecessary network protocols.
Now, what I mean here is not necessarily your Wi-Fi,
but instead all of those network protocols
that might be used on your system.
Are you running a web server?
If you're not, close port 80.
Are you running a mail server?
If not, close port 25.
Are you running an SSH server?
If not, close port 22.
As a standard workstation,
you really should have no ports that are open,
unless you have something open
for something like a host-based intrusion detection system
to be able to receive reports and send reports back.
Other than that,
everything should be pretty much locked down on a system.
On a server, you should only have the ports open
for the services you need.
So if you're running a file server, or a web server,
or an email server, those ports should be open,
but everything else should be closed.
The fourth thing we want to look at
is uninstalling or disabling all unnecessary services
and shared folders.
Anytime you have something that is open, or shared,
or a service, that is, again,
something that is increasing your attack surface.
So, again, you've seen the common theme here,
anything you're not using,
go ahead and uninstall it or disable it.
I prefer to uninstall it
because that way nobody else can enable it,
but if you can't uninstall it,
then you should at least disable it.
Fifth, you need to enforce access control lists
on all system resources.
This means if you have local system files, or folders,
or shared files in folders or printers,
all of those things have to be controlled
using the appropriate access control list.
And we'll talk more about access control later on
as we define the four different types,
but for now, just remember,
you want to make sure you're enforcing access control
using the appropriate ACLs.
Number six, we want to restrict user accounts
to the least privilege needed.
You'll hear this concept a lot in security,
always use least privilege.
If you can do this with a user account
and not use an admin account,
go ahead and use a user account.
If you're a user, do you need to have admin rights?
No.
You just need to be able to access the computer
and run your systems.
And so you'll have these different things
like guest, and users, and superusers, and then admins,
and you only want to use admin accounts when you have to
because there's a high level of privilege
associated with them,
and that would also increase your attack surface.
Next, we want to look at number seven,
which is to secure the local admin or root account.
And one of the ways to do this
is by renaming it and changing the password.
Everybody knows on a Linux system,
the root account is called root.
Everybody knows on a Windows system,
the administrator account is called administrator.
So you should disable those two accounts
and instead create another superuser
that is called something else.
So instead of calling it administrator,
I might call it JASON ADM,
or if instead of calling it root,
I might call it root123.
Whatever you want to do,
try and make it at least a little bit harder
for the attacker is a good thing.
And then always make sure you change that default password.
If you have the default password of T-O-O-R for root,
which is root spelled backwards,
you are going to get hacked really, really quickly.
And so you want to make sure you keep those things in mind
and always change those passwords.
Number eight,
you want to disable unnecessary default user
and group accounts.
Again, if you're not using it and you don't need it,
you should go ahead and disable it.
This also helps harden your system
and reduce your attack surface.
Number nine, we want to verify permissions
on system accounts and groups.
This is because we can see things
that happen like permission creep,
where people gain permissions over time,
and they never get those permissions taken away.
For example, I worked at one company for almost a decade,
and every time I moved positions,
they added different security controls.
They said, "Oh, well, now you work in accounting,"
for instance, "So you need these access
to the accounting shared drives.
But you might still have your access
to the human resource files
because you were in human resources last."
And then you move over to the tech side,
and now you've got all three accesses.
And so what should happen
is every time you move to a new department,
your permissions should get taken away
and only the permissions you need should be added.
This is the idea of verifying permissions
on the accounts and on the groups.
This should also be done routinely,
whether that's monthly or quarterly,
against your entire system
to make sure everyone has the right permissions
for what they need.
And number 10, you always want to make sure
you're installing anti-malware software,
and you need to update its definitions automatically
and regularly.
So just having antivirus software on your computer
is not good enough.
It needs to check every single day for the latest updates
and scheduled to automatically do its scans.
This will help keep your system protected.
If you do these 10 things,
your system is going to be pretty strong
and pretty well-hardened.
Now, the other thing you need to consider
is how are you going to harden your systems
against availability attacks?
Remember, we have three sides of the triangle:
confidentiality, integrity, and availability.
Everything we just talked about
was a lot to do with confidentiality and integrity.
It's making sure our data is the way we want it to be
and that only the right people can read it.
But if we want to start focusing on availability,
what can we do?
If I have a server,
it should be powered by an UPS or a battery backup.
This will make sure that it can stay online
even if the power goes down in the facility,
and that'll give it enough time for your secondary power
to come online, which might be a generator, for instance.
This is the idea of how you can make sure you're protected
against availability attacks
that have to do with power outages.
But power edges aren't the only thing
we have to worry about.
For instance, in my area,
we have an issue with our primary Internet connection.
If power is out in town for more than an hour,
we lose our primary Internet connection,
so we have a backup Internet connection,
we have a backup cellular modem.
In addition to that,
we have a backup microwave connection,
or a satellite connection.
And so that way,
we have multiple different paths, so we won't be offline.
That's the idea of making sure
you're protecting yourself against availability.
Now, I only talked about power and Internet here,
but there are lots of other things
that are threats to your availability,
and you need to think through these
as you're building out your server farms and your systems
because that is one of the ways you can harden those systems
is making sure the resilient
against these availability attacks.
Now, the last thing I want to talk about here
is the second part of this topic.
We talked about hardening,
now we're going to talk about patching,
and this comes down to patch management.
Patch management involves identifying, testing,
and deploying operating system and application updates.
As I mentioned, patches are going to be there
to help you fix security bugs.
When Microsoft knows there's a bug in their software,
they're going to release a patch.
You need to identify that you have the appropriate software
that needs to be patched,
you need to make sure that you test that patch
before installing it,
and then you need to deploy that across your network
so everything gets updated.
These patches are often classified as critical,
security-critical, recommended, and optional.
If it's a critical or a security-critical,
you probably should make sure you get those out quicker.
If it's something that's optional,
you could probably wait a little while on that.
And again, this all goes back to your risk appetite
and risk management.
Now, when you're trying to conduct patch management
at the enterprise level, you're going to need
some sort of patch management tool suite.
There are lots of different tool suites out there,
but two of the most common are made by Microsoft.
Microsoft has the System Center Configuration Manager,
or SCCM, and the Endpoint Manager,
as you can see here on the screen.
These are designed to support both Microsoft systems
as well as having some ability
to detect things on other systems as well,
but really, they're primarily focused on Microsoft systems.
Now, one of the things you have to be aware of
when you're dealing with patch management
is that just patching
is actually an availability risk in itself,
because when I install a patch,
I actually can put that onto a critical system
and then that system needs to be rebooted.
When I do that, that might take 5, 10, 15 minutes
to reboot that server,
and that means that server is down for that time.
So you need to make sure you're planning
when these patches are going to go out.
You can't just do it in the middle of the workday.
You're going to have to have downtime window
or a maintenance window
for you to be able to install those patches
to critical systems
if you don't have a fully redundant network that's built.
Luckily, most of our organizations
have moved to the cloud now.
Most of us have a fully redundant network built out,
so we can take a single server offline, patch it,
and then bring it back up.
But if you're still working
with some of these older legacy systems,
you may have to reboot the system manually
and you may not have a backup,
and so that would be an availability risk
that you have to consider.
Finally, when we talk about patches,
you have to remember that patches don't always exist.
You might have a piece of software that's really, really old
or a system that's really, really old,
and manufacturer just doesn't even exist anymore.
They've gone out of business.
In which case there is no patch available.
Instead, you'll have to use compensating controls.
So if you're looking for patches that don't exist,
things like legacy systems, proprietary systems,
ICS/SCADA, or Internet of Things systems and devices,
and you can't find it,
you may have to either take that thing off the network,
if you can assume that business risk,
or you're going to put in compensating controls
to overcome the fact
that you can't patch that vulnerability.
Now, what do I mean by this?
Let's say you had an older network file system
and it requires port 445 to be open
for it to be able to share those files.
Well, we don't want to have port 445 open to the Internet
because that would be a vulnerability.
So, a compensating control,
if I can't patch this software
against a given vulnerability,
is to make sure that this file server
is only available internal to the network,
and I can block it from getting out of the firewall
or anything outside the firewall
from getting to this file server.
By doing this, I put a compensating control in place,
such as blocking port 445 from the Internet,
and that can solve the problem of an exploit over port 445
that this older proprietary system may be vulnerable to.