ITS 4210 - Access Control, Authentication, and PKI

Chapter 14, Testing Access Control Systems

Objectives:

This lesson discusses system testing. Objectives important to this lesson:

1. Why we test
2. SDLC, SSLC
   
3. Testing activities
4. 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:

1. Identify assets - What are we going to protect?
   
2. Identify threats - What can go wrong? Examples: attack from the Internet, hardware and/or software failure, and loss of Internet connection.
3. Identify vulnerabilities - With those threats in mind, how are we vulnerable? These are examples of vulnerabilities:
   1. no firewall
   2. no intrusion detection
   3. no antivirus software (and no updates?)
   4. no updates for the server
4. 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.
5. 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?