Lec3: Managing Risk: Threats, Vulnerabilities, and

Exploits

Objectives important to this lesson:

1. Managing threats
2. Managing vulnerabilities
3. Managing exploits
4. Risk management strategies
5. Objectives of a risk management plan
6. Scope of a risk management plan
7. Assigning responsibilities
8. Procedures and schedules
9. Reporting requirements
10. Plans of action and milestones
11. Charting progress.

Frist We need to know some terms:

• Threat - a potential form of loss or damage; many threats are only potential threats,
but we plan for them because they might happen
• Threat agent - a vector for the threat, a way for the threat to occur; could be a
person, an event, or a program running an attack.
• Vulnerability - a weak spot where an attack is more likely to succeed.
• Exploit - a method of attack.

The list of threat categories

Unintentional Threats

• Environmental - IT damage can be caused by weather related disasters. The

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 – 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 to start.
• 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?

Intentional Threats

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 disruption
• 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 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 - 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 their secrets?
 • 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 financial instruments.
• 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 it
• cyberterrorists - a cyberterrorist is defined as a system attacker whose
motivations are ideological.

The 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
o principle of least privilege - grant only the privileges needed, and only to
the resources actually needed, not to other resources
o principle of need to know - grant rights only to individuals who need
access to data, not to entire groups when all members do not need
access
• 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
The vulnerabilities can appear in any part of IT systems. The 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 vulnerability /threat pairs, each of which has a stated expected loss.
Compare it to the following table in which a column has been added to each line
proposing a mitigation plan, an action plan to reduce risk.

The list of possible mitigation plans/actions.

• policies and procedures - what is our goal and what do we do to reach it safely
• 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 other computer
• 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.

As a quick definition, an exploit is an attack. It is often an attack that is based on a

known or suspected vulnerability. The many exploits begin in the public facing part of
a network, its public Internet presence. This 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 and reboot.
• 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 its attention.

The 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 several sources of known or discovered vulnerability data:

• 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 (CVE) list - A master list of
discovered vulnerabilities, using a standardized naming scheme
• 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

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
machines
• 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 intrusion
• 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
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.:

1. Identify threats - What can go wrong? The text lists three threats: attack from
the Internet, hardware and software failure, and loss of Internet connection.
2. Identify vulnerabilities - With those threats in mind, how are we vulnerable?
The text lists several vulnerabilities.
1. no firewall
2. no intrusion detection
3. no antivirus software (and no updates?)
4. no updates for the server
3. 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.
4. Identify costs of an outage. - The text reminds us to think about tangible and
intangible costs, as well as cost to return to our normal state.
5. 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.
6. 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.
7. 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?
8. Accept, defer, or modify recommendations - Document the choices of
management regarding the recommendations.
 9. Create a POAM - 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 so.

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 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, so let's do something and prepare for the risk.

• Identify and evaluate threats

• Identify and evaluate vulnerabilities
• Identify and evaluate countermeasures
• Assess threats, vulnerabilities, and exploits
• Evaluate risks
• Develop recommendations
• Present recommendations

Before we start breaking down the steps of assessment, the reasons for doing them. Two are listed:

• to support decision making - we must decide where to spend our budget, so we assess our
situation to make reasonable choices
• to evaluate control effectiveness - are our controls sufficient or must they be changed?

There are three suggested times to do an assessment. This list appears above the reasons, but it
should follow it, so I will mention them here:

• when evaluating a risk - actually, this should say "when beginning a risk management process"
• when evaluating a new control - as noted above, a to measure the effectiveness of a control
you have to understand the risk it is associated with
• when reviewing a control - you should avoid continuing processes just because they are in
place; examine your controls on a regular schedule to improve or replace them as needed

Let's turn to three parts that begin a risk assessment.

• Identify scope - The text gives us an example of an evaluation of the risks associated with a
web server. Do we evaluate only the web server, its associated database server, its network
zone, or some combination of these? Since the services provided by the web server depend on
the other server as well, it might be best to adopt the largest scope in this situation, but your
deadlines and project funding may limit the scope. Make the best decision you can and get
something done.
• Identify critical areas - Each of the three elements in the largest scope mentioned above are
considered in the text's example. Each is examined in terms of its own hardware, software,
 network connections, and power needs. In terms of hardening and reducing risk, the text
suggests that neither the web server, nor the database server, should be allowed to contain
services or data not needed for the purposes they serve. The more a box does, the more
avenues for attack may exist on it.
• Identify team members - Ideally, the people doing the risk assessment should not be the people
who do the daily service, protection, and correction on the components being assessed. This
may not be possible in a small organization, but it may be useful for cross training in an
organization large enough to have several teams who can regularly examine the work and
assets of another team. In other words, if you don't have specialists doing the assessment, at
least your separate teams can assess risks for each other.

The two general methods for conducting risk assessment. They differ in their methods of assigning
value to assets. How shall we count the value of an asset? This is easier to answer once we choose
between two points of view:

• Quantitative Risk Assessment - Every asset must be given a currency value of some sort that
can be used in the measure of its impact on the organization. Several methods of assigning this
value can be considered.
o Replacement cost - What would it cost us to replace this asset if it
were compromised or destroyed in an attack? If a partial loss is possible, what would
be the value of each part of it?
o Purchase cost - What did the asset cost to acquire it or develop it?
o Depreciated cost - If the asset loses value over time, at what rate is it lost, and what is
it worth now?
• Qualitative Risk Assessment - In this method, every asset is given a relative value, not a
currency value, which means that each must be measured against the others in terms of its
worth to the organization

The Quantitative Risk Assessment that leads to a complicated calculation

• Asset Value (AV): the value that an asset has for the next several calculations; this
value may be different depending on the context of its use
• Exposure Factor (EF): the percentage of the value that would be lost in a single successful
attack/exploit/loss; this accommodates the idea that an entire asset is not always lost to an
attack
• Single Loss Expectancy (SLE): this is a number that can be obtained by
multiplying AV times EF. You may want to start two columns of data at the point, one holding
the SLE for a probable loss, the other holding the SLE for a total loss. In both cases, use this
formula:
SLE = AV * EF
• Frequency of Occurrence: this number tells you how many attacks to expect in some time
period; this is ambiguous if we are not told whether this is the rate for all such attacks, or the
rate for all such successful attacks We generally assume that the number given is the rate at
which successful attacks occur.
• Annualized Rate of Occurrence (ARO): often, known frequency of occurrence may be
expressed in days or hours, but the executive you report to may want the numbers expressed
in years. This is understandable if, for example, we are talking about establishing a yearly
budget for IT Security. Reporting is often done based on calendar or fiscal years, which is
another argument for making this conversion.
• Annualized Loss Expectancy (ALE): the final number stands for the currency value of our
expected loss for a given asset in one year; provided you have calculated the numbers so
far, ALE equals SLE times ARO.
ALE = SLE * ARO
 • Safeguard value - Also known as the Cost of the Control, this is the cost to the organization
of applying a control to reduce the risk. It must be compared to the ALE of the risk to determine
if the cost is justified. Be aware, however, that some controls must be implemented regardless
of their cost because there may be a legal or moral reason for doing so. We will consider this
further in the second half of the course.

As the text explains, some or all of the numbers used in the equations above may
be estimates or guesses. There is lack of certainty about them, so we should not be too confident that
our numbers are right and always will be.

Risk Level = Probability that an exploit of a vulnerability will succeed x Impact of that occurrence on
the organization