ITS 4210 - Access Control, Authentication, and PKI
Chapter 14, Testing Access Control Systems
Objectives:
This lesson discusses system testing. Objectives important
to this lesson:
Why we test
SDLC, SSLC
Testing activities
Penetration testing and reporting
Concepts:
Chapter 14
The chapter begins with a reminder that access control
systems must work properly or our systems become available to the wrong
people. We test them to make sure they are working. The text might also
have said that we test them to make sure they have not been
compromised. Testing can disclose faults in a system, but it can also
disclose damage that has been done to it.
The text introduces three levels of testing that make sense
for any IT project:
software design - if we are having software written for
our project, we should make sure that security is designed in along
with the feature required by future users
hardware design - what hardware does the control require?
are there options? do the options all work as well as each other?
(usually not)
penetration testing - staging a simulated attack on the
system to determine whether the controls are effective or not
On
page 317, the text offers a seven step version of system development,
the Software Development Life Cycle (SDLC).
This is often depicted as a waterfall
model, in which the outputs of one stage supply the inputs for the next
state. In the image on the right, the process is shown as five steps.
Both views are correct. A version that shows the process as a circle
would also be correct because software (and the systems that use it)
should be re-evaluated regularly to see whether updates, corrections,
or improvements are needed. The image on page 318 supports this
concept, but it looks more like a flow chart.
The text expands on the SDLC model by introducing us to a
model it calls the security system
life cycle (SSLC). Several steps are the same: figure out what
you need, develop and build it, then install it and use it. Operation
and maintenance is also a familiar step, but you may not have seen a
step called sunset before.
This step is common in more modern versions of the SDLC, and it is important in the case of a security
system. Like a protocol or a cipher that has been compromised, a
security system will eventually have no further value. If every
attacker knows how to defeat a system, it must be replaced by one the
attacker does not understand.
On page 321, the text seems to backtrack. It continues with
a section on gathering requirements for a security system. The text
explains that a set of critical features for a system is vital not only
in its design, but also in its testing. If the tests are not passed,
the system does not fulfill project requirements. (In the case of a
contract, that means you don't get paid.)
The chapter takes on an uncanny resemblance to last week's
chapter in ITS 2110. Here are some notes from that lesson:
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
Internet connection.
Identify vulnerabilities - With those threats in
mind, how are we vulnerable? These are examples of vulnerabilities:
no firewall
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 to determine if a machine is
live beyond a firewall.
operating system
command-line
tools - There are various command line tools that can be
found in most operating systems. You should look up some of
the ones you are not familiar with.
netstat
tracert
nslookup (or dig in Linux)
ipconfig (or ifconfig in Linux)
ping
vulnerability scanners
- Nessus
has a free home version that does everything we have discussed so far,
as
well
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
is
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
tests:
You must be using this on a network your organization
owns.
You must have been authorized by the network owners to
do
this.
You must be doing this with the knowledge and consent
of
the content owners.
Port scanning:
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
an ACK
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.
TCP
SYN scan
- 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 behavior 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
connection state.
The text wastes a few pages with a discussion based on the
seven
network domains concept. We can safely skip it.
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. 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 into a system because your buddy dares you to do it, even
if your idiot buddy works on that system.
The text continues with a section on conducting the
penetration test. As it has already pointed out, the only real
difference between a pen test and an attack is that the pen tester has
permission. 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
resources.
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. You may
think of that as the deployment of countermeasures. 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 text offers a set of objectives for the pen test that
should be
represented in the report that the pen test team will file.
are the security policies and standards of the organization being
followed? are they working?
is the security baseline being met on all equipment? if so, are
changes needed?
do the countermeasures and controls we use work? are new ones needed?
Assignments
Continue the reading assignments for the course.
Complete the assignments and class discussion made in
this module