ITS 3050 - Security Policies and Auditing
Managing Risk in Information Systems
Chapter 2, Managing Risk: Threats, Vulnerabilities, and Exploits
Chapter 4, Developing a Risk Management Plan
This lesson presents more terminology and planning ideas in chapter
2, and material about components of a risk management plan in chapter
4. Objectives important to this lesson:
- Managing threats
- Managing vulnerabilities
- Managing exploits
- Risk management strategies
- Objectives of a risk management plan
- Scope of a risk management plan
- Assigning responsibilities
- Procedures and schedules
- Reporting requirements
- Plans of action and milestones
- Charting progress
Let's examine the list of threat categories that begins on page 31.
- Environmental - IT damage can be caused by weather related disasters.
The text lists floods, tornadoes, hurricanes, earthquakes, and volcanoes.
Buying insurance against possible threats is one way to handle them.
Another is to move the company away from them, in whole or in part.
- Human - Employee errors and omissions lead to procedures not being
done, or being done ineffectively. Systems can be automated to reduce
human error, software can be error trapped to reduce data being entered
incorrectly or not being entered where it is needed. Input validation
for computer forms is a usual place to start.
- Accidental - The text describes a construction accident with a backhoe.
I know of an instance in which a train derailed and cut a fiber optic
line, cutting off data services for hours. Requiring our staff and our
contractors to check for problems before they take actions is a place
- Failure - All hard drives fail, eventually. Any piece of equipment
can fail. The larger a system is, the more components it has, the greater
the chance that something will go wrong before long. When failure happens,
have we prepared for it?
The text begins with a short list of motivations that can cause people
to want to harm our organization. We can probably add to this list.
- Greed - stealing information to use it or sell it; stealing personal
information to access accounts
- Anger - seeking to hurt the victim through destruction, damage, or
- Desire to damage - sometimes the victim is not the reason, if the
attacker simply wants to damage something and is seeking a vulnerability
to will provide access
The text changes the topic a bit to talk about kinds of attackers.
- hackers - one of the buzzwords of computer system
geeks, this one can mean anything; it is generally accepted to mean
someone with more skill than an average user, may be a white
hat (good guy) or black hat
(bad guy). A hacker may break in to a system for a thrill, to show off,
or to cause some kind of damage.
- cracker - according to your text, a hacker whose
intent is to damage a system or steal data.
- script kiddies - attackers who use hacking tools
that they don't really understand
- spies - computer attackers who are looking for specific
data from specific systems
- employees - Computer security includes the concept
of protecting data from people who aren't authorized to access it. What
about protecting it from authorized users who want to give or sell it
to someone else? What about authorized users who give out their password
because someone asks for it? What about users who are no good at protecting
- computer criminal - someone who uses a computer in
the commission of a crime
- cybercriminals - a computer criminal whose crime
also involves a network. They are often after some financial gain, which
could be from data they can sell, actual fund transfers, or theft of
- cyberextortionists - a cybercriminal who may attempt
to hold a system or its data hostage (extorting money for its release),
or may threaten a system with damage unless money is paid to prevent
- cyberterrorists - a cyberterrorist is defined as
a system attacker whose motivations are ideological.
- advanced persistent threats (APTs) - may be related
to state sponsored cyberterrorism, an attack that goes on indefinitely;
The text references, but gives no details on Operation
Aurora. Click the link for a Wikipedia article on the incident.
Page 34 gives a list of best practices for dealing with general threats.
- create and enforce security policies
- The text says "a policy" but you will need several. A separate policy
may be needed to address each threat, or to address the procedures you
want different staff in the organization to follow.
- purchase insurance - policies
to insure against losses due to fire, flood, wind storm, theft, and
business interruption are common
- use access controls - grant
users access to network resources once they have properly authenticated
to the system; the text reminds us to use two principles
- principle of least privilege - grant only the privileges needed,
and only to the resources actually needed, not to other resources
- principle of need to know - grant rights only to individuals who
need access to data, not to entire groups when all members do not
- use automation - automate
processes that should be done the same way each time, such as making
backups, to avoid human error
- use input validation - as
noted above, restrict data entry to only the correct kind of data; checking
data entries for validity can avoid problems like SQL injections
- provide training - regular
training for all employees keeps them mindful of mistakes to avoid and
proper procedures to follow
- use antivirus software - install
and configure an antivirus solution to be proactive, and make sure that
it is updated regularly
- use boundary protection -
strategic placement and configuration of firewalls
and intrusion detection products should be used at the Internet interface
and between divisions of the organization
Page 35 takes us to a discussion about vulnerabilities.
They can appear in any part of our IT systems. The text reminds us that
a vulnerability alone does not cause a loss. It must be exploited by threat
for a loss to occur, so it tells us to look for threat/vulnerability
pairs, threats that match
an existing vulnerability and are likely
to cause loss. Upon finding such a pair, we should create a mitigation
plan to reduce the vulnerability, the probable loss, or both.
Consider the table of threat/vulnerability
pairs on page 36, each of which has a stated expected loss. Compare
it to the same table on page 37 in which a column has been added to each
line proposing a mitigation plan,
an action plan to reduce risk.
Starting on page 38, this text has a longer list of possible mitigation
plans/actions than most books we have used in this program.
- policies and procedures - what is our goal and what do we do to reach
- documentation - systems documentation, procedure documentation, documentation
for any job that exists in our organization with attention to security
in such documentation
- training - not only initial training, but reminders, updates, congratulations
to people and areas that are doing a good job.
- separation of duties - critical and financial operations should require
at least two responsible staff, to assure that important functions cannot
be performed by one hacker or one rogue employee
- configuration management - using approved equipment, enterprise images
for operating systems, controlled updates and software installations
leads to a predictable environment that can be maintained or reset more
easily than one in which every computer may be different from every
- version control - the text is talking about preserving old versions
and creating new versions of documents and software whenever someone
makes a change in either by use of a version control system
- patch management - Software companies, especially the ones who produce
operating systems, are always patching and updating their products,
typically when new vulnerabilities and solutions to them are announced.
Managed organizations will test, modify, package, and push such patches
and updates to their users, often on a monthly cycle with emergency
pushes as needed.
- 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 (may serve a network or only one device
on a network)
- intrusion prevention -
if a product reacts to intrusions, it attempts to stop them, contain
them, or minimize their effects (may serve a network or only one device
on a network)
- incident response - there
should be a multidisciplinary team in place to handle significant security
issues; this is different from the team that handles day to day calls
to the help desk
- continuous monitoring - someone needs data on the big picture, to
better update and customize our vision and goals
- technical controls - This is a control that uses automated technology,
such as intrusion detection and antivirus software
- physical controls - This is a control implemented by physical barriers,
such as locked doors, guard desks, and cable locks.
Last week we mentioned exploits, and the text brings them up on page
41. As a quick definition, an exploit
is an attack. It is often an attack
that is based on a known or suspected vulnerability. The text tells us
that many exploits begin in the public facing part of a network, its public
Internet presence. The author of the text is focusing on exploits are
implemented by using a computer program to attack a target, but I think
many people use the word more generally, to include other means of attack.
Some exploit types are discussed.
- buffer overflow - This is a general category, in which the attacker
sends more data or impossible data to a system that is not validating
inputs from the user. The stream of data sent by the attacker may include
commands to the system, which may be followed because the overflow has
caused the system to stop running the program it was running. In addition
to system commands, the attacker may succeed in loading a program into
the target system, such as malware, a virus, or a worm. (What
are those things? Notes on them are available.)
- SQL injection - Instead of sending a program file, the attacker may
send an SQL command, hoping that the data the system was expecting was
about to be handed to a Structured Query Language interface. This can
also be avoided by properly validating the data supplied by the user.
- Denial of Service (DoS) - The text describes one way to start a denial
of service attack. The attacker sends a request to connect to a network,
fails to complete it, then sends another request. This pattern is repeated
many times, in the hope that the attack will prevent legitimate users
from connecting to the system, or that the server will eventually hang
- Distributed Denial of Service (DDoS) - This is like the DoS attack,
but it is carried out by a number of computers under the control of
the attacker. The attacking computers are called clones or zombies.
They are typically machines that the attacker has previously attacked,
and infected with a program to put them in the attacker's control. The
actual DDoS attack on the target system may be as simple as sending
as many pings as possible to it, tying up its communication lines and
The author uses a hypothetical foreign government to describe steps that
an attacker might follow to find a target and prepare for an attack:
- discover public servers
- establish a list of vulnerabilities for known server types, match
discovered servers against this list
- try old and new techniques against found servers to develop more vulnerabilities
to add our list
- develop new programs to attack newly discovered vulnerabilities, giving
us new exploits
- use old and new exploits to attack discovered targets
The method above depends on information that is found or known about
vulnerabilities. The text lists several sources of known or discovered
- blogs and newsletters
published by security professionals
- forums where professionals
discuss new discoveries
- 2600 - a quarterly magazine
about hacking many kinds of systems; content varies greatly from one
issue to another
- Common Vulnerabilities and Exposures
list - A master list of discovered vulnerabilities, using a standardized
- patch Tuesday and exploit
Wednesday - Microsoft typically puts out patches on the second
Tuesday of each month; patches are often reverse engineered to determine
how to exploit the vulnerability the patch addresses; exploits for unpatched
systems are then created
Pages 47 and 48 provide a list of standard techniques to harden (protect)
servers against common exploits:
- remove or change defaults
- many systems have well known default privileged IDs and passwords:
these should be changed every time a computer is set up
- reduce the attack surface
- attack surface means the things that can be attacked, so we should
stop running any services that are not needed by the device or its users;
we should also remove unnecessary protocols, so the computer does not
respond to attempts to use them
- keep system patches up to
date - patches must be tested in managed environments, but those that
are approved should be applied without further delay, to avoid attacks
from the exploit Wednesday folks
- enable firewalls - there is
no point in disabling all protocols (how could you do anything?) but
you can filter traffic based on where it came from and by other rules
if you use firewalls, at strategic places in the network and on individual
- intrusion detection/prevention
- if your budget supports it, intrusion detection make sense, and intrusion
prevention is better; note that only intrusion prevention
systems take steps to stop an
- antivirus software - it should
be a given that you want an effective antivirus
solution, and an antimalware
solution as well
- use configuration management
- don't allow users to install anything; use enterprise approved operating
systems, hardware, and software
- regularly perform risk, vulnerability,
and exploit assessments - things
change, so you should look for changes, new risks, and appropriate solutions
on a regular cycle and when there is a significant change in your environment
The remainder of the chapter covers US federal agencies and their initiative
to assist in protection of assets. Go over this material to get an idea
of who does what and where to look for information.
Chapter 4 puts several concepts from the first three chapters into focus.
In the previous chapters, we have talked about concepts, definitions,
and a bit about their utility. Now we put some of the pieces together
to make a plan for our organization. The text uses the example of a company
that is concerned about its web site. The text also complicates the example
with a concern that the company has not been compliant with HIPAA rules.
At the moment, that is a distraction better handled by another division
of the company, so we will consider the web site and its risks.
In general, making our plan starts with identification. We assume that
identifying assets has already been done.:
- Identify threats - What can go wrong? The text lists three
threats: attack from the Internet, hardware and software failure, and
loss of Internet connection.
- Identify vulnerabilities - With those threats in mind, how
are we vulnerable? The text lists several vulnerabilities.
- no firewall
- no intrusion detection
- no antivirus software (and no updates?)
- no updates for the server
- The text assigns staff to collect data. It is not clear what
data that is. If we assume that the vulnerabilities listed 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.
- Identify costs of an outage. - The text reminds us to think
about tangible and intangible costs, as well as cost to return to our
- Provide possible recommendations - What should be done to reduce
our risks? Can we reduce the vulnerability, the impact of the threat,
or both? The text does not state that the recommendations in this step
are only potential recommendations until the next two steps are done.
- Identify costs of recommendations - What is the cost of each
recommendation, and the cost of sensible combinations of recommendations?
For example, if we are considering three antivirus solutions, we should
consider the cost of updates for them as well, and consider the update
cost as a necessary part of the cost of each choice.
- Perform a cost-benefit analysis (CBA) - For each recommendation,
or combination of them, what is the cost of implementation compared
to the probable impact of the risk it protects against?
- Accept, defer, or modify recommendations - Document
the choices of management regarding the recommendations.
- Create a POAM - The text does not define this acronym. It is
a Plan of Action and Milestones. It is a silly phrase. We need to make
a plan to implement the approved changes, including a timeline for doing
The text goes through this process with the HIPAA concern as well. Note
that the process is the same, but the focus is different, leading us to
examine different items in each step.
On page 89, the text introduces the scope of a risk management
plan. If this plan is to address the entire organization, it requires
approval and endorsement at the highest level. If the the plan
is for a smaller area, the approving authority is at a lower
level, and the boundaries of the project are much closer.
Any project can suffer from scope creep, which means that we suddenly
find ourselves burdened with a larger project than we planned, causing
inevitable increases in cost, time, staff commitment,
and resources needed. When changes of this nature happen to a project,
the costs and timeline must be reconsidered and adjusted,
or the project should not be allowed to adopt new aspects,
The rest of the chapter considers each of the major steps in the plan
in detail, adding considerations such as who should participate in making
the plan, finding the facts, and reviewing the proposals. Look over each
section to prepare for doing the assignments this week.