Lesson 13 - Chapter 13, Vulnerability Assessment and Data
This lesson covers chapter 13 in the
text. It discusses vulnerability in a network. Objectives important to
Vulnerability scanning and penetration testing
Data privacy and security
Chapter 13 begins with story about
data captured by several honeypots. A honeypot is an attractive target
intentionally set up to waste the time of an attacker. The honeypots in
question gathered information about what the attackers did. The author
wonders why the data shows that the attackers attempted to log in to
the system with simple passwords. This could be because the attackers
lacked experience, or because they used a brute force password tool. A
potential flaw in the experiment might be that the data was only
gathered from attackers who were attracted by the honeypots. The
researchers only watched the actions of the hackers they caught. They
don't have data on the ones they did not catch.
The lack of complete data is a good point to remember as we
consider the main topic of the chapter. We can prepare for the problems
we know about, but we should not assume we have prepared for
everything. This is one reason that security is an ongoing problem. The
text tells us to begin our security measures by examining our current
security posture: what do we have, and what is at risk?
Another text we have used quotes Sun Tzu,
and his observation that you must know yourself and your enemy. The
quote is from the end of chapter 3 of The
Art of War. It is not accidental that many authors discussing
risk refer to a classic source used as a management text and as a guide
for warfare. The point is that we must know our assets, know their
weaknesses and strengths, and know the attacks that are likely to occur
if we hope to defend against the attacks. The authors might have quoted
the beginning of chapter 3
to give us more hope. Sun Tzu wrote that "the worst policy of all is to
besiege walled cities". It is our goal in mounting a defense to present
such a wall that the enemy will not waste its effort in an attack.
Is it possible to protect everything we might call an IT
asset? Given enough time and money, yes, but we will always have limits
on what we can spend, how many staff we can hire, and what time we can
devote to the project given what else we are assigned to do. The text
devotes much of the chapter to a sequence of processes that lead to a
prioritized list of assets which will tell us what we should spend the
most effort to protect.
The first process creates a catalog
of our IT assets. Note that any list represents only a snapshot
in time. The procedures used to create such lists must be available to
appropriate staff any time a new
asset is added, or an old one is changed or removed.
The text briefly considers several scales on which assets might be
rated to assign a "value to the organization". For example, it may be
replacement value or revenue value that will be more important to your
organization, but it is more likely that a composite
score makes the most sense if several measures of value can be applied.
The text moves on to identifying threats. On page 569, a chart
of twelve threat categories is presented. Some are acts of nature, some
are created by human error or human attackers.
The next concept combines the previous two. Once we know what
trying to protect, and we have a set of threats, we need to examine
each asset to determine whether it is vulnerable to specific threats.
The text makes a point, over several pages, that some assets are
threatened only by specific
threats, and some of them are much more likely to occur. Which ones?
The text asks us to consider which threats are hazardous to
our company and which of those are the most dangerous. Consider table
13-2, which gives us a scale for the impact of a successful attack on
any asset. How serious would the impact be? How dangerous is our
vulnerability to specific or general threats? Considering this concept
leads us to making decisions about which assets we must concentrate on
protecting. We protect our assets with risk mitigation, which comes in
several types. We will spend entire classes on this topic. For now,
look at table 3-3, which summarizes this chapter so far:
Identify assets -
What are we going to protect?
Identify threats - What can go wrong? Examples:
attack from the Internet, hardware and/or software failure, and loss of
Identify vulnerabilities - With those threats in
mind, how are we vulnerable? These are examples of vulnerabilities:
no intrusion detection
no antivirus software (and no updates?)
no updates for the server
Assess risk - If
we assume that the vulnerabilities identified above are only suspected
vulnerabilities, then we should verify that they do
exist or they don't. If they do, we need to propose
remediations for them.
Risk mitigation -
This is actually a series of steps, but for now we will assume that we
will do everything that should be done.
Some vulnerabilities can be assessed with software. The text
discusses particular kinds of network tools useful to
people looking for vulnerabilities:
port scanners -
Many texts recommend Nmap. This sort of utility looks
for devices on a network, and scans them for open ports. In this case,
a port is not a physical thing waiting for a plug. It is a service
running on a computer that is identified by a number which stands for a
place in that computer's memory. A service of this sort may run at a
port whose number is commonly used (like 80 for HTTP, or 25 for SMTP)
or it may run at any port number specified by the person or process
that started it. A Wikipedia page with lots of port numbers and their
commonly associated services can
be seen here. If a port is open,
it can receive requests, and possibly commands from an attacker. If it
is closed, the server will not
allow connections to the port, but will reply to attempts to connect.
If it is blocked, connections
are refused and no replies are made.
firewall analysis tools
- One way the Nmap tool can be used is tto determine if a
machine is live beyond a firewall. Firewalk
and HPING are two other tools
that can help
an attacker determine what a firewall is allowing to pass.
tools - The text offers nine command line tools that can be
found in most operating systems on page 582. You should look up some of
the ones you are not familiar with.
is a free program that does everything we have discussed so far, as
as having other features. It is effective for scanning a network that
is using over the counter software.
packet sniffers - A
more formal term is network protocol
analyzer. Sniffer is
one you have to buy, Snort is
an open source product, and Wireshark
freeware. Do not use them
unless all three of the
following tests are met. As you might imagine, it is rather difficult
to pass all three of these
You must be using this on a network your organization
You must have been authorized by the network owners to do
You must be doing this with the knowledge and consent of
the content owners.
The text discusses port scanning for several pages. The items
below are six kinds of port scans:
TCP connect scan - The hacker sends a SYN packet to a specific port on a
server. A server whose port is open
will send a SYN-ACK packet,
acknowledging the synchronize
request. A server whose port is closed
will respond with an RST-ACK
packet, which resets (refuses)
the connection. In this scan, if the hacker receives the SYN-ACK
response, the hacker will send
packet, confirming the connection. The hacker will probably then send
an RST packet, closing the connection. The targeted port might also
send no response to a SYN packet, which means that the attacker must
send a SYN packet again to be sure it was not just lost.
- This is a shorter version of the connect scan. In this scan, the
hacker sends an RST packet as soon as the open port sends a SYN-ACK.
That makes this scan faster, and a bit less intrusive because the
connection is never completed.
TCP FIN scan, NULL scan, and XMAS tree scan
- The text presents these as three types, but their responses are the
same, so the more illustrative site I have linked for you discusses
them together. These present good data about closed ports: they respond
with an RST packet. Open ports should not respond, which is not very
good proof. Filtered ports will not respond, either, which makes this
scan only beneficial for finding closed ports.
TCP ACK scan
- This scan fills in a gap in the behaviior of the FIN, NULL, and XMAS
tree scans. It is expected that both open and closed ports will respond
with an RST packet, but only if they are unfiltered. A lack of response
is interpreted as a filtered port. The lack of filtering may mean that
the connections to the port are not being monitored for their
So, vulnerability scanning is the process of determining where
some weak spots in the network exist. The text moves on to discuss penetration testing. In a
penetration test, the tester tries to exploit identified (or suspected)
vulnerabilities. This is different from hacking a system. A pen tester
only tests a system with the permission of the system owner. It is not
done without permission, typically granted with a contract that spells
out what will and will not be done. A professional (or a student, for
that matter) should never probe a system without permission
from someone who has the authority to grant such permission. The text
specifies that this should be the system owner, but in the case
of corporate or government systems, ownership can be hard to define. At
the very least, it should come from someone who is part of the group
charged with protecting that system, someone with the authority to give
assignments, to approve contracts, and to make a case for conducting
such work to the upper management of the organization. You don't just
try to break in to a system because your buddy dares you to do it, even
if your idiot buddy works on that system. (Hmm. You and your buddy. Now
it sounds like a conspiracy. Think you should call a lawyer, kid?)
Having stressed permission the text elaborates on its
definition of a penetration test, either without insider knowledge of the
system (black box testing) or with it (white box testing).
Note that the use of the colors black and white in this context does
not mean anything about the tester's motives. It only refers to the
level of insider information being provided to the tester. In either
case, the tester will seek more information as part of the test.
Consider the following to be part of a code of conduct for
Don't hack without permission.
Use the same (or better) tools and tactics as those an
attacker might use.
Use care NOT to harm the the system you are hacking. (Primum
non nocere) You are examining it, not trying to destroy it.
Study the work done by malicious hackers to understand what
they are likely to do, to learn what you may not know.
If you are pen testing, make sure that you and the
authorizer both understand what is going to happen. This is good for
any kind of contract, but it is critical when you are doing something
that might be considered illegal without proper permission.
Your goal is the help maintain the standard of
Confidentiality, Integrity, and Availability. You can do this by
finding the vulnerabilities that lead to the opposites of those
characteristics: Disclosure, Alteration, and Disruption. If you can do
any of those things, we do not have security.
There is no universal method, no absolute set of steps that
every attacker will follow. The series of steps below is representative
of what an organized, determined hacker will probably do, even though
it is not required that the hacker carry out every step listed.
Reconnaissance - Gather information about your target from
public information and from social engineering.
Scanning - Build on the initial information with more
focused attacks, like spear phishing, waterholing, and exploiting
vulnerabilities in systems identified in the first step.
Infiltration and escalation - Get into the system with the
IDs and access you have gathered. Get escalated right to gather more
Exfiltration - Take the material you have captured out of
the system, and get yourself out of it as well.
Access extension - Use the backdoors you found or installed
to go back for more later.
Assault - If this was an exercise in data mining, you may
want to continue to do it in the future. Destruction is not part of
that plan. However, if destruction is part of the plan, this is the
phase in which it happens. If that is all the attacker wants to do, the
previous two steps may not take place.
Obfuscation - This is the application of anti-forensics.
Clean up your mess. Don't let the victim know anything happened. You
can come back to get more goodies if they don't know you were here.
The last several pages of the chapter discuss privacy and security. The discussion takes us back to the idea of a security posture, and the definition is expanded:
what do we have, and how are we protecting it?
what are we doing to monitor our systems and our assets? what new threats are appearing?
what are we doing to reduce new vulnerabilities?
Projects and Cases as directed in the
course Assignment Summary. Lab simulations as directed in the course Assignment