|
|
ITS 2110 - Introduction to Network Security
Lesson 15 - Chapter 15, Risk Mitigation
Objectives:
This lesson covers chapter 15 in the
text. It discusses risk. Objectives important to
this lesson:
- Managing risk
- Reducing risk
- Common practices
Concepts:
Chapter 15
begins with the
concept of an attack on a heart patient's pacemaker (or other heart
management device). The text reports that a study was done on several
related heart devices, and they all had huge security problems. These
problems create risk for the patients, and for the companies that
produce and market the devices.
We have already had an introduction to risk, notably in
chapter 13. We catalog assets, we determine the known threats they are
vulnerable to, and we compute the level of risk for each vulnerability.
The text recommends several kinds of management to control risk:
- change management
- privilege management
- incident management
The
text presents several pages on calculating the risk for particular
asset/vulnerability pairs. This is a real activity, but it is a bit
above the scope of this course. This section leads to tables on pages
663 and 664 that are color coded to show the severity of several risks.
I would be more confident in the chart on page 663 if the first
calculation in it had been done correctly. (Likelihood times impact equals risk severity.)
As is probably obvious, controls are intended to reduce risk,
typically by reducing incident likelihood or of incident impact. Some
definitions may help:
- likelihood - the
probability that a threat will be realized; in the example on the right, it is expressed as a value from 0 to 4
- value - the monetary value of the asset; this
may be expressed as the income we lose if it is compromised and/or the
cost to replace the asset; alternatively, this may be a relative value as calculated in the
Prioritizing Assets section of the text
- mitigation - the percentage of the risk that we have protected against
- uncertainty - a fudge factor to express our confidence (or lack of it) in the other numbers
The text offers a list of types of controls on page 665.
Reviewing the categories may be useful when trying to brainstorm
additional controls that may be effective in your environment.We could classify security controls as one of three types:
- Physical controls -
These include any physical barrier, like a locked door or a fence, as
well as security cameras and guards
- Administrative
controls - These include the procedures
to create security policies and the security
policies themselves. Security policies are
rules about "the actions that users may
do, must do, and cannot do".
- Technical controls
- Actions that are performed by devices
(technical solutions), such as firewalls denying packets.
All three types of
controls
have the same subtypes.
- Deterrent controls
- used to discourage attacks;
applied before an attack;
example: warning attackers
that we are protected
- Preventive controls
- used to prevent attacks;
applied before an attack;
example: using a firewall to block
traffic for specific ports; these controls are typically automatic
controls
- Physical controls - used to prevent attacks;
applied before an attack; controls installed in a given place, like fences, turnstiles, or barriers
- Detective controls
- used to detect an attack or intrusion;; applied during an attack; example: using a Intrusion Detection System; these
controls are typically manual controls
- Corrective controls
- used to reduce damage and restore to service; applied after an attack; example: using an emergency cleaning program on a USB
memory stick, so that a computer can be usable
- Compensating
controls - alternative controls that are used when normal controls are
not possible; applied during
an attack; example: disabling switch
ports to isolate devices or LAN segments
- Mitigating controls
- any type of control may be a mitigating control if it finds or
notices errors and presents a
method to correct them
The text warns us to avoid having too many
policies and too many controls. People will be lost if there are too
many rules to remember, and they will have little chance of complying if the
the policies and controls are too hard to follow. Make fewer policies, and make controls easy to use to get better compliance.
The chapter gets around to defining policies. A policy is a rule, or a set of rules,
that affects how we want our organization and its employees
to function. As the text states, the idea behind a policy may start
with a principle, which is often a broad, general statement of
what we believe to be right, true, or beneficial.
A policy is more detailed, and more specific about what we expect our
people to do. The list below shows us a hierarchy of related concepts:
- Principle - a general statement about what we
believe or require in our area of authority (we will use only two
computer vendors at a time); what we expect
- Policy - rules about the conduct of our organization
with regard to particular actions (we will limit ourselves to
particular models chosen by the IT department); how we will approach
the expectation
- Standard - a method or process that may be
procedural or technical (orders are to be placed by approved requesters
within each work area); what steps are to be followed to assure general
compliance with policy
- Procedure - a detailed set of steps to follow to be
in compliance (requests are to be made to your manager, who will
forward approved requests to your authorized requester); variations or
limitations that apply to specific work areas, to be followed if they
apply to your area
- Guideline - a suggested addition to any of the items
above that is recommended but optional (submit your requests two weeks
before the end of a quarter to allow processing time); do this to make
it work better
- Definitions - when there is room for misinterpreting
any of the above items, definitions should be offered to clarify their
language and intent; if you didn't understand something, read this
The text warns us that simply making a policy does not
guarantee it is a good policy. Policies should be reviewed
before and after they are put in place. New
policies or revisions may be needed when processes are changed,
when systems are changed, when "improvements" are made,
and when problems are being resolved.
The text presents a discussion of several common security policies. You should review this material to consider the impact such a policy is meant to have.
The chapter ends with a list of common security problems, but there is no discussion of any of them.
|