|
|
ITS 4350 - Disaster Recovery
Chapter 5, Detection and Decision Making
Objectives:
This lesson is about chapter 5. Objectives important to this
lesson:
- Detecting incidents
- Intrusion systems
- Processes and services
- Port scanning
- 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.
|