ITS4350A - Incident Response and Disaster Recovery

Chapter 6, Incident Detection Strategies; Chapter 7, Detection Systems


This lesson is about chapter 6. Objectives important to this lesson:

  1. Incidents that pose risks
  2. Detecting incidents
  3. Incident types
  4. Kill chains
Chapter 6

The text presents some information from NIST SP 800-61, R1. It is a classification table for incidents. Note that this table is a list of types, and its order does not imply a scale of urgency.

  • denial of service
  • malicious code
  • unauthorized access
  • inappropriate usage
  • multiple component - an incident that falls in more than one of the categories above

The text does not explain how these classifications are useful, but they will give us some causes that may be linked to events we can observe.

The text proceeds to three lists of indicators that an incident has occurred. The lists can be referred to as possible, probable, and definite indicators.

Possible Indicators

  • unfamiliar files - files that do not belong in the folder where they appear or that do not appear to have an owner; the text warns that this may be an indicator for a rootkit infection
  • presence or execution of unknown programs or processes - programs that no authorized user started can indicate infection
  • unusual consumption of resources - unusual usage of memory, processing cycles, or hard drive operations indicate process that something else is using your computer
  • unusual system crashes - a system crash should be unusual, so a better adjective might be "frequent" or "wide-spread", indicating that something adverse is affecting one or more users

Probable Indicators

  • activities at unexpected times - activities on a computer or on a network that differ from the baseline without an ready explanation
  • unexpected new accounts - accounts should not be created without there being a valid audit trail; strange new accounts probably indicate hacking
  • reported attacks - a report of an attack could be accurate, according to the text (it would be inadvisable to ask the reporting party how tech savvy they are)
  • IDPS notification - a notification from an Intrusion Detection/Prevention System should be investigated right away

Definite Indicators

  • use of dormant accounts - unless a person on leave has suddenly come back, this should not happen, especially if the account has been disabled
  • changes to logs - the text recommends making backups of system logs and comparing the live files to the backups to look for changes made without authorization
  • presence of hacker tools - network scanners and packet sniffers should not be present unless authorized by administrators
  • notification by a respected source - a report from a business partner or another part of your organization may be given the trust you give that entity
  • notification by hacker - polite hackers leave a note, pirates leave ransom notes

The text offers another diagnostic that really isn't one. It just says to look for a failure/loss/reduction in confidentiality, integrity, or accessibility, as well as violations of organizational policy or actual law. It stands to reason that any one of events would be something to trigger an incident declaration.

The text moves on to discuss what seems like red tape around handling incidents: the determination of whether they are real incidents, false-positive reports, or just background noise. The second two phrases in that list are more metaphorical than we might like. A false-positive can be a mistake on someone's part or a misunderstanding of what has been observed. It is less likely that a log report or a notification from an IDPS would be false. Noise, in this case, means something that is not important enough to be noticed, kind of like music in a waiting room, but that is not really applicable to the idea of a breach of a CIA service.

The text discusses IDPS usage for several pages. You should know that they can be network based, which means that they watch for anomalous signals and behaviors from any device connected to their network. You should also know that they can be host based, which means that such a device/service/appliance is watching and protecting only a single computer (or other network device), the one it is now part of.

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.The text refers to this sequence as the anatomy of an attack, and as a cyber kill sequence.

  • 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 back doors 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?

Chapter 7, Detection Systems


This lesson is about chapter 7. Objectives important to this lesson:

  1. Components of an IDPS
  2. Optimal placement of components
  3. Processes used by an IDPS to make decisions
Chapter 7

The chapter reminds us that in intrusion detection system may be used to protect a network, a portion of a network, or an individual host (any device that is on the network). Also that such devices may only perform detection, and not be capable of intrusion prevention. Let's review:

  • intrusion - someone tries to access or disrupt a system
  • intrusion detection - if a product only does detection, it will notice an attempted or actual intrusion, and will probably tell someone; a detection system does not take action against the intrusion
  • intrusion reaction - if a product reacts to intrusions, it attempts to stop them, contain them, or minimize their effects
  • intrusion prevention - if a product acts to prevent intrusion, it probably does detection as well; I am sometimes notified by my security suite that an attempted intrusion has been detected and stopped, which is what you want such a system to do

When you are researching products in this category, you should be careful to note what the product actually does. If it is marketed as an intrusion detection system, don't expect it to prevent or stop intrusions. As the text says, an intrusion detection and prevention system (IDPS) would be preferable to a system that only performed one of those functions.

The text asks the question "Why use an IDPS?" Well, which would you rather see on your screen, a message that says an attack has just been stopped without damage, or a  (insert your favorite emblem of disaster)? These are some reasons that go a bit farther:

  • If employees know about an IDPS, they may be less likely to go postal on your network. They will probably be caught.
  • Detection of events will tell you when your other layers of security are not working.
  • Dealing with probes that are used before an attack may serve to present a harder target to potential attackers
  • An IDPS keeps a log of events, which can be analyzed for current threats and for trends.

As mentioned earlier, an IDPS may be installed on a computer or a network appliance and allowed to sniff all the packets that pass by. This sort of network-based IDPS may need to be duplicated in various parts of your network, since it has to watch every packet that goes by, and it will not see any packets that are not passed to the network segment it lives on.

The second major option for an IDPS is a host-based IDPS. This kind of system can detect changes on the host where it is installed that do not depend on network traffic. On the other hand, it needs to be installed on every host you intend to protect. In a home network, this is not a large burden, but in a commercial setting it can be a lot of work. A convincing argument may be that the antivirus program provided as part of your home contract with a cable provider probably includes this feature. If you are installing Norton 360, for example, you are already installing a system to watch for intrusions as well as to watch for viruses.

The text moves on to discuss tools that analyze networks. We have already discussed intrusion detection and prevention tools and firewalls. The authors suggest vulnerability scanners, log analyzers (application log, security log,system log), and packet sniffers.

They describe preliminary processes that a would-be attacker might use in gathering information about a target. Common early practices are examining web resources and using social engineering.

The text discusses particular kinds of network tools useful to people looking for vulnerabilities. As I advised you before, these are useful to attackers and to defenders.

  • port scanners - The text recommends 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.
  • firewall analysis tools - The text explains one way that Nmap can be used to determine if a machine is live beyond a firewall. It also discusses Firewalk and HPING, two other tools that can help an attacker determine what a firewall is allowing to pass.
  • operating system detection tools - XProbe sends ICMP packets to computers and checks their responses against a list of responses from machines with known operating systems. Why do you want to know the OS of a computer? To exploit known vulnerabilities or protect against such exploits.
  • 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. To scan a network with custom or in-house-developed software, use a "fuzzy" scanner like SPIKE. It features a proxy server that sounds like a good tool for a man in the middle attack, as well as being a tool to test the stability of your own web servers and sites. These are both active scanners, that send traffic into a network to test it.
    Passive scanners only watch the traffic that is already being sent through a network. Two products of note are Passive Vulnerability Scanner (PVS) and RNA.
  • packet sniffers - A more formal term is network protocol analyzer. The text lists three products. Sniffer is one you have to buy, Snort is an open source product, and Wireshark is freeware. Be aware of the legal requirements for using this sort of software. Do not use them unless all three of these tests are met:
    • 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.
    • As you might imagine, it is rather difficult to pass all three of these tests.