ITS 4350 - Disaster Recovery

Chapter 5, Detection and Decision Making

Objectives:

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

1. Detecting incidents
   
2. Intrusion systems
3. Processes and services
4. Port scanning
   
5. Decision making
   

Concepts:

Chapter 5

 The chapter begins with a few terms again. Some have definitions we may want to debate:

• event - any observable occurrence in a system or a network (What if someone cuts down a tree in our network forest and no one hears it fall? Did it happen? Yes, I think so.)
• adverse event - an event that has negative consequences
• incident - an event that threatens ongoing operations
• incident classification - a process that examines events, determines which events have adverse effects, and which of those are incidents that must be addressed

In addition to declaring that events are incidents, your organization may have an additional step to classify an incident as a system-wide problem, which upgrades its need for resolution.

The text presents some information from NIST SP 800-61, R1. It is a classification table for incidents. Note that this table is by type, and it does not have 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.

Two of the objective areas for this chapter are not presented in the body of the chapter. They are discussed in gray pages that are typically for footnote articles added to chapters. In this case, they are two larger sections of the chapter, so we should consider the pages about processes and services, and those about ports and port scanning.

Processes and Services

The text explains that a process can be a program that is loaded by the operating system (or an application), that has been allocated memory, that has been given access to files, and that is waiting to be called by the OS or by its host program. It can also be any regular program, but that is not what the author is talking about. The text presents a list of processes that are common to Windows on pages 177 and 178. We should expect to find these running in memory during the normal running of a Windows computer. There is a much longer list of services on pages 179 through 182. A good host based IDPS can watch the processes and services that are running on a computer, and can alert the user (or an administrator) when there is an anomaly compared to the baseline that IDPS has come to expect.

Ports and Port Scanning

On page 193, the text begins another article in the chapter, this time about commonly used ports, which in this case are named memory locations that are typically used by services. Which ports for which services? Well, the text follows a standard convention, telling us that port 0 through 1023 are called the well-known ports, which are generally associated with only one or two specific services. Ports 1024 through 49151 are called the registered ports because the services associated with them are assigned (registered) by ICANN or IANA. (Yes, some agencies do kind of run the Internet.) The third range of port numbers, 49152 through 65535, is called the dynamic or private ports. On pages 195 and 196, as we observed last week, the text lists some of the malware programs that have used various ports for evil purposes. Port scanning can be done for good reasons or for bad reasons. The text lists several programs that can be used to passively or actively scan the ports on a particular machine, or on a network, to see what is being used, what is blocked, and what might be exploited.

On page 207, the text briefly discusses honeypots and honeynets, which you may have heard about. Both are meant to be sections of a server or a network that are actually worthless to a hacker, but are meant to look attractive to a hacker looking for treasure. The text tells us to be aware of the difference between enticement, which is the act of making something look attractive, and entrapment, which is the act of convincing someone to perform an unlawful act so that they may be arrested. The former is legal, but the latter is not. Because most tech people are not lawyers, it is probably better not to create something that a good lawyer might convince a jury was part of an entrapment scheme.

The text resumes talking about incidents on page 208, presenting the theory that most suspected incidents may only be authorized or allowed activity on a system. Such activity should be detected and categorized as benign activity as quickly as possible. That will leave more time for dealing with the real incidents. The text presents a list of advice from the NIST about analyzing data for incidents on pages 209 and 210. The amount of data to go through should impress on you the need to watch some of these data sources with automated equipment. The text does not bring it up, but we should recall that a good antivirus or antimalware program should be on each computer, watching for known exploits.