Let's take a look at malware.
Well, malware used to stand for malfeasance software,
but since we all have a problem trying to spell malfeasance,
we often call it today, malicious software.
Malware is software that was written to do harm.
It was written to damage.
It wasn't a bug or some type of a problem in the software,
but rather, it was software written in order to try to harm somebody's system.
As we say, malware, for example,
is often written by different hackers to try to get around some security
controls, maybe take over a system, or steal some data.
The idea is that malware has evolved a lot over the years.
We used a lot of terms like virus, and worm, and so on, and
those in the early days were quite different.
But now a lot of malware today is also kind of a combination of
many different types of malware. And malware authors went from
being what we often called script kiddies,
where people were just casually doing this for fun, to a very
professional type of skill as we see it today.
We try to prevent malware through anti‑malware systems.
Now,
the best way to prevent malware is through awareness training, telling
people what to watch for, don't click on that link,
don't open that attachment, for example.
And we, of course, back that up with a number of really good
anti‑malware tools. We have, for example,
anti‑virus systems, anti‑spam systems that very often are
looking for known signatures of types of attacks.
It's important that we monitor in two places. We monitor network traffic, so
we see malware going through a network, but we also monitor on endpoint
devices to see if that device itself has been affected.
One of the things we will often do if we see something
suspicious is we'll put it into a sandbox.
The idea of a sandbox is that it's an isolated environment.
So, let's say, for example,
a security professional sees something that could be malware.
Well,
they don't want to run it on their machine to see what it does, instead
they'll put it into a virtual machine where it's very closely limited
and very often then not network connected. That as an isolated sandbox
where now they can let that malware, or suspected malware, execute and
see what it does.
It's important that we isolate both the actual sandbox itself,
but also the system, so even if something does go wrong,
it can't spread to other systems.
We do this a lot when we're doing forensics. We need to look at something,
and obviously you don't want it, whatever that bad stuff is, to now appear
on your machine or the investigator's machine.
So we'll put it into a separate area for that reason.
When we're looking at malware analysis,
we want to see what does this malware try to do? What are its
intents, what are its techniques, so that we can see how it executes
and how it operates in that sandbox and learn how to prevent that
malware from infecting other systems.
These sandboxes are usually a virtual environment, an environment
we've set up on a system where it is virtual,
but it's not running directly on the physical hardware of the system.
Instead,
a virtual environment is an environment which is a
logical configuration of a system.
And in that way, as a virtual environment, we can now try to
execute it, and if it does something wrong,
the nice thing about a virtual environment, it's just
logical, we just power it down, and we can restart the
system with no lasting damage to it.
One of the ways we learn what attackers do is through
the use of honeypots and honeynets.
We set out something that is attractive to an intruder.
You could call it a target of opportunity if you like.
Something, for example, in our demilitarized zone that has an attractive name,
executive bonus scheme, or something like this.
Now,
nobody should be looking at that because it doesn't belong to anybody
that really is there in our demilitarized zone.
But we want to see who does look at it.
They're a little curious because it's something that is attractive to them.
And the idea is we learn who goes there. We learn the types of tools they
use to break into that system. So we learn their attack behaviors, and that
allows us to build better defenses as well.
We can analyze the type of traffic on that network or attacking that
host, the honeypot itself. A honeypot being a host, honeynet being the
network that is leading up to that host.
We also have to watch out for something we call side channel attacks. So
they're not attacking the actual host directly. You take,
for example, with cryptography,
they don't necessarily attack the cipher text or the algorithm, instead
they attack the actual memory units and CPU units that are being used
to try to process that encrypted traffic.
That gives us information about how these attacks are configured.
We have many different types of attacks we face. When we take a look at malware,
for example, at a high level, it often goes after applications.
We see spam going after email. We see people trying to intercept traffic,
say on a wireless or even between two communicating processes, and
we'll call that the man‑in‑the‑middle attack.
We've seen, of course, many attacks that take advantage of a flaw
within the software, and that flaw or that unprotected software
has created a target of opportunity.
We've seen this a lot with different types of commercial
software where the moment a vulnerability is found,
the attackers, just in mass, actually then develop a number
of different ways to try to break into that software through
that detected vulnerability.
The other thing is session management.
We've had a number of attacks, such as Cross‑Site Request Forging, that was
a very good example of a session management type of attack because a person
didn't log out property and their session could be taken over by somebody
else in something we'll often call session hijacking. This is why it's
important we have things like timeouts, so if a person has not used their
system for a few minutes,
it'll just lock it out. And it could be that it's not been used because the
person forgot to log out, or maybe they just lost their internet
connection, and all of a sudden, they couldn't even log out because they
weren't connected to that application anymore.
So we have a timeout that kicks in after a few minutes of
inactivity and just terminates that session.
We also have attacks at the transport layer.
We have flooding of traffic, such as a SYN flood attack.
The best example of a SYN flood attack is when you're standing
talking to a good friend, and all of a sudden, your 3‑year old
granddaughter comes up and says Grandpa,
Grandpa, Grandpa, Grandpa, Grandpa, that's a SYN flood.
She's trying to get your attention, she's trying to synchronize,
but quite simply, you're not able to hold a conversation with
anybody else while you're under a SYN flood attack.
And this is what we've seen with a number of the
distributed Denial of Service attacks.
You have a flood of synchronization requests come in that certainly make it
impossible to carry on any type of legitimate business.
We've also seen this with UDP. We've seen where UDP, there's been a
whole flood of traffic coming in using the UDP protocol.
There's been attacks using things like TCP sequence numbers to hijack or
take over somebody else's established say banking session.
And, of course, this is where the man‑in‑the‑middle
attack becomes again, a problem.
Can somebody get in between the two people that are trying to
talk and may be able to take over that session,
take over your banking session, or could they alter the traffic, rerouting money
to a different location, for example? At the network layer,
we also have attacks. We have things like IP spoofing, ICMP, Internet
Control Message Protocol, and we talked earlier about how this lent
itself to that attack known as the ping of death.
You can have floods of ICMP traffic. And some of you have noticed this.
You may have a person that if you send them an email,
you know you're going to get seven or eight emails back.
That's the type of, should we say, your flooding
attack. And in the area of using ICMP,
it's the sort of case if I send a ping off to a large broadcast address where
there's many machines and they all reply back, there's going to be a whole
flood of these replies coming back that I could target or divert those off to
an unsuspecting victim. That was sometimes known as the smurf attack. At the
data link and physical layers, we also have attacks there.
If we're using wireless, does somebody jam the wireless signal, is
somebody sniffing the wireless traffic going by, or did someone damage the
cable or even intercept the cable to tap into it?
We've seen cases where people stole the copper cable so they could sell it.
So these are all types of attacks that can very
definitely affect network communications.