The default installation of an operating system
is probably not going to provide you with the security
posture you're looking for.
You need to do a little more work to make your operating
system as secure as possible.
And we call this process hardening the operating system.
It's usually not just one thing or two things.
There's usually a group of things
that should be considered as best practices
when you're trying to make your operating system as
secure as possible.
This is also something that you always have to keep working on.
You don't just harden your operating system,
and you're done.
There's constant maintenance that has to be done.
There's weekly updates, monthly patches.
There may be updates that occur without any type of warning.
And all of these have to be applied to the operating system
to maintain its security.
In fact, it's not just about patches.
It can also be about the way that you set up the operating
system.
You make one tiny configuration change
and open a particular network share up
to have a broader set of permissions than you wanted,
and now, suddenly, you have a security problem on your hands.
So you have to consider how you're
going to secure the operating system
from many different perspectives,
and you have to stay up on what the latest patches might be.
One way to make your operating system a bit more secure
is to disable any services that you don't need.
Well, what services are really unnecessary?
With Windows XP, there were almost 90 services
that were installed by default.
In Windows 7, that number was over 130 different services.
It can be difficult to piece through all of those services
and know exactly which ones are OK to run
and which ones can be disabled.
Every service, of course, has the potential
to provide us with a security issue
because they might all have vulnerabilities inside of them.
We just haven't found what those vulnerabilities are yet.
Normally, our monthly patches from Microsoft,
from Apple, from the Linux consortiums,
they will help us resolve these types of security issues,
but it's the zero day problems, the ones
that we don't know about, that are our biggest security
concern.
This is, of course, going to require a lot of research
to determine which one of these services do I turn off?
Which one of these services stay on?
There are a lot of different sources
out on the internet to gather these details,
and very often, the manufacturer of the operating system
can give you a lot more specifics
over what services are required and which ones
can be optionally disabled.
If you're still not sure what services should be disabled,
you could always try turning some off to see what happens.
Turn off a service.
Run your applications.
Print some things.
Make sure your file transfers work properly,
and maybe that particular service can remain off.
But if you run into a problem, you
may need to re-enable that service.
It may take some time to go through your entire service
list, but this at least gives you
a strategy for finding and disabling
those unnecessary services.
Another potential for operating system vulnerabilities
is any place there might be open ports.
These services that we run on our computer
open ports up to the network to allow access for others
to come into our system.
You can see that this web server, for example,
has an open port UDP 53, TCP 80, and TCP 443,
and that's because this web server
is providing DNS services over UDP 53
and providing web services over TCP 80 and TCP 443.
Now, normally, that's absolutely acceptable, especially
if you want to provide those services
to the rest of the network.
But if any of those services is unnecessary,
they should be disabled, and sometimes a service itself
has a vulnerability, and the way that vulnerability is accessed
is through these open ports.
If there are any devices on your network, then eventually
they're going to need to be patched.
These might be your computers, your servers, and even
the operating systems running inside
of your infrastructure devices.
There's usually a change control process
you would follow to make sure that these updates go smoothly.
You plan the update, you perform the update,
and then you have a back up plan in case there's
a problem with the update.
You should always plan for problems,
and that way, you always know what
to do if you run into any issues.
Between the time that a patch is released
and the time that it is installed,
there's usually a delay.
The length of this delay is really up to you.
You have to take this patch, install it on your own systems,
test it, and make sure that it doesn't
create a problem for your operating
systems or your applications.
And then you roll it out to the rest of the organization.
Some systems, though, don't like to be touched.
Maybe the operating system running on this device
doesn't have any type of support.
Maybe the application itself is so old,
the company isn't even around any longer to provide support,
and you're concerned that changing anything
on that computer is going to cause that application
to stop working.
Even rebooting the system has a number
of issues associated with it.
It'd be better if the system just kept running
and kept running, and you wouldn't
have to touch anything.
That, of course, is a pipe dream.
We still have to have patches and updates
and provide security for all of the systems on our network,
so there needs to be a plan in place.
Maybe you have constant images being
made of these legacy systems.
That way, if you perform an update,
you can always revert back with a complete reimaging
of the operating system.
If you're communicating to a device that's over the network,
you would ideally be using a set of protocols
that encrypt the data.
You don't want to send in the clear information
across the network.
It is so easy to gather information that's
being sent over a wired or wireless networks these days,
so you want to have some encryption method in place.
This is not a simple thing to implement.
It requires some planning, a certificate authority.
You need certificates put on your web servers,
but that hard work is going to result
in a very secure channel between the devices on your network.
This in the clear information is so easy
to gather, especially on wireless networks.
We use so many open wireless networks
in coffee shops and hotels, in conference centers,
that you want to be very careful about what you're sending
over those particular networks.
You need to always consider that there may be somebody listening
in on the conversations that are going out over the network,
and if you do that, you'll be much more aware of what you're
sending, and you'll be much more apt to have
an encrypted channel between you and the other device.
We're creating a username and password
for a particular service.
Those credentials have to be stored somewhere.
Generally, the username is stored in plain text.
My name will be there and readable in that database,
but the password will not.
Ideally, the password is never going
to be stored in plain text.
It's going to be encrypted or hashed in some way.
Generally, information is added to the password,
and all of that information is then hashed
so that you have this extra salt that's added to the hash.
Having the salt in place makes it
harder for somebody to perform a brute force against that hash
to determine what the password might be.
If you're wondering if someone is storing your password
in plain text, one way that you can tell
is if you're asking for a password reset,
and you get an email that has your password
inside of it in plain text.
Then you know that particular password is insecure.
It's being stored somewhere in this plain text format,
because you can't reverse engineer a hash.
A hash is a one way function, and, of course, sending me
the hash doesn't help me.
A secure password reset would send you a link into your email
that then takes you back to that service to update and change
your password information.
A plain text password should never
be sent over any electronic medium.
If you're finding that you're receiving emails
with your password inside of it, or you're
the one sending the emails with the password inside of it,
you need to find a different way to communicate that information
to the end user.
If you have a packet analyzer, and you're
gathering information from a wired or wireless network,
there's a lot of information that's being sent in the clear.
There's a number of protocols that you
could use to protect this information instead
of sending it in a way that anybody would be able to read.
For example, a communication protocol
that you would not want to use over network
is this relatively old SLIP, or serial line interface protocol.
We don't do a lot of serial line communication,
and this is a protocol that we definitely don't want
to use on our modern networks.
If you want an example of a more modern protocol
you should not be using, then you can
see Telnet is a good example.
That's a terminal communication, and everything sent over
that terminal communication using Telnet
is all in the clear.
We also have in the clear communication
to our web servers inside of our browser
if we're only using HTTP.
Sometimes, this information is perfectly acceptable
to send in the clear.
But if you're performing anything that needs security,
do not want to be using HTTP.
File transfers can also be a good place to gather details,
and some insecure file transfers can be done by FTP and TFTP.
And lastly, on the network management side,
SNMP is all in the clear, so SNMP version 1
and SNMP version 2 should not be used on a network
if you are at all concerned about the security.
A type of security concern that we don't often think about
are radiofrequency emissions.
Everything we have on our computer is sending RF signals.
We have sounds from the computer,
from our monitors, the keyboards and wireless devices
that we're using.
Everything has some type of RF associated with it.
You'll sometimes hear the code word
Tempest associated with this.
Tempest is a National Security Agency specification and a NATO
certification.
This is one that these organizations
are very concerned about, because they
want to be sure that your networks and your devices
are as secure as possible.
So they have standards for minimizing
the amount of radio frequency emissions coming
from your computer.
Here's an example of just some of the things
that you can do to minimize the amount
of radiofrequency emissions.
One is to shield the devices that you're using.
You can shield inside of the computers,
and you can shield the cables that you happen to be using.
Maybe you separate the information
going over these network cables, where
you have one cable sending classified information
and another one that would send unclassified information.
It's common to have are classified networks
run on a fiber network since those have such little amounts
of RF associated with them.
You can also add filters to the cables you're
using to prevent some of this RF,
and maybe you move away from walls,
since it's through the walls that you're
able to hear a lot of these radio frequencies coming
through.
If you can minimize how close people
can get to the computers, then you're
minimizing their chance of hearing
any of these RF emissions.