ITS 2110 - Introduction to Network Security

Lesson 13 - Chapter 13, Vulnerability Assessment and Data Security


This lesson covers chapter 13 in the text. It discusses vulnerability in a network. Objectives important to this lesson:

  1. Security posture
  2. Vulnerability assessment
  3. Vulnerability scanning and penetration testing
  4. 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 we are 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:

  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 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.
  • operating system command-line 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.
  • vulnerability scanners - Nessus is a free program 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.

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 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 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 connection state.

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 ethical hacking:

  • 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 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. 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?