ITS 3050 - Security Policies and Auditing
Managing Risk in Information Systems
Chapter 10, Planning Risk Mitigation Throughout Your Organization
Chapter 11, Turning Your Risk Assessment into a Risk Mitigation Plan
This lesson presents two related chapters about risk mitigation planning.
Objectives important to this lesson:
- Where to start
- Legal and compliance issues
- Assessing countermeasures and safeguards
- Operational impacts
- Cost-benefit analysis
- Best practices
- Reviewing a risk assessment
- Overview of conversion to a mitigation plan
- Prioritizing risks
- Follow up on planning
- Best practices mitigation planning
The chapter begins by reminding us to identify assets. Having made an
inventory and rated each asset on its importance to our organization,
we might want to do some house cleaning by removing assets that are not
serving our needs, replacing them as necessary with assets that contribute
to reaching our goals.
The author takes a long winded approach to saying that he recommends
that we use NIST SP 800-53 as a reference book. Examine controls that
apply to our organization, and match appropriate controls to identified
Under the topic of determining the scope of your mission to mitigate
risks, the author tells us to consider several related topics that can
be thought of as a ladder to reach our goal:
- What are our critical business operations?
- These are the activities that
must be supported to keep our business open and operating.
The author reminds us to do a Business Impact Analysis, which was mentioned
in the last lesson. We need to identify what operations are critical,
and how long they can be down before the outage affects the company.
This downtime is referenced
by several names: maximum acceptable
outage (MAO), maximum
tolerable outage (MTO),
and maximum tolerable period of disruption
- How do we deliver services
to our customers? - The text is recommending that we have service
level agreements (SLAs) with our customers, so that we can tell
when we are not meeting, meeting, and exceeding expectations. A SLA
gives us a measurable level that we can't fall under.
- What are the mission-critical systems,
applications, and data
stores that support the two areas above? - Okay, so now we have
a list of what we have to do for ourselves and for our customers to
stay in business. Match that information with the systems
and assets needed to meet those
goals. More buzz words: critical business
functions (CBFs), and
critical success factors (CSFs).
In this case, a factor is anything needed to perform a function.
The text offers an example. To run an Internet business, we need for
our customers to make purchases.
This means that we need to maintain our Internet presence,
including the web servers, database
servers, and payment servers
that the customers use (often without knowing so). In addition, we need
to maintain our ordering and
shipping services, which includes
our warehouse operations, customer
service operations, and restocking
- How can we categorize our identified IT assets in the seven domains,
since the author thinks everything depends on that? - I think that the
domain concept is meant to break a complex problem into manageable pieces.
If your organization uses a different structure scheme, use that instead,
but break the concept down so that individual employees can see where
their efforts fit into the big picture.
- Where are our assets unprotected?
- The point in this step is to make sure that we find the gaps
and take action to fill them.
We want to be protected so we can continue to function.
The next section of the text is about ten pages long. It concerns federal
laws and regulations that require particular compliance. We will
see this list again in the second text.
- Federal Information Security Management
Act (FISMA, 2002) - mandates
that the Federal government and its contractors follow a common set
of information security standards. The standards are set by the National
Institute of Standards and Technology (NIST).
- Health Insurance Portability and Accountability Act (HIPAA,
1996) - Establishes a large, complicated rule set for storing health
information in a common format, making it sharable, and making it a
crime to share it with people who should not have it.
- Sarbanes-Oxley Act (Sarbox,
2002) - a reaction to corporate fraud and corruption; provides
penalties up to $5,000,000 and 20 years in prison for officers who file
false corporate reports. It also requires the protection of financial
- Family Educational Rights and Privacy
Act (FERPA, 1974) - Requires
that schools, such as colleges and universities, protect the privacy
of their student records, and provide students access to their own records
Internet Protection Act (CIPA,
2000) - A law that means to protect children from obscenity, pornography,
and harmful material. This law requires libraries to use filtering software
on computers used by minors, and also allows librarians to provide access
without the filter to adults who request such access.
- Payment Card Industry Data Security
Standard (PCI DSS, 2006)
- A global standard for processing payments by bank cards, credit cards,
and debit cards. It was created in 2006, but there have been updates
since then. It requires that an organization taking payments of this
type have and use
security policies. It also requires that the card processor have a secure
network, protect card holder data, manage vulnerabilities, and
have strong controls. Obviously, this standard has not always been followed.
The list above only deals with some of the laws in the United States.
Other countries have laws that are similar, and laws that are different.
On page 275, the text considers making choices among the controls and countermeasures
you may have identified. It is a simple rule that the author recommends.
Does the control do one of two things:
- reduce the impact
of a threat to a acceptable
- reduce a vulnerability
to an acceptable level
If a control, or a combination of controls, passes one or both tests,
it is worth conducting a cost-benefit analysis for it. Realize that we
should maintain internal documentation on our controls, and the reasons
we are using them. Controls should be reevaluated
regularly, and each time a threat or a vulnerability the control is associated
with has changed.
In addition to providing fines and other penalties for unlawful disclosure
of protected information, we often are obligated by law to maintain
and protect the information itself.
With that in mind, the text recommends a list of standard
controls that should be applied to any organization:
- account management controls such as putting accounts in suspense or
deactivating them when employees leave the organization
- access controls such as the rule of least privilege
- physical access controls such as locks, access logs, and video records
- personnel policies, such as separation of duties, job sharing, and
- security awareness training for all staff
The text repeats its advice to do cost benefit analysis, giving us two
- Loss without a control - loss
with a control = projected benefits
The formula above tells us if a control is effective.
Does using this control reduce losses?
- Projected benefits - cost
of control = control value
This formula tells us if the money saved by using the control justifies
the cost of using that control. Be careful with this one. Sometimes there
are other losses that are reduced by the same control, so they should
be considered. And sometimes we are obligated by law or ethics to do something
to reduce our risks.
Finally, the chapter offers some best practices regarding mitigation
- review historical documentation - the history of risk management in
your organization gives you insight into your current situation
- use a narrow focus,and a broad focus - focus on the project you are
doing, but don't lose sight of the big picture
- make sure you are compliant with laws
- when a control changes, do a new risk assessment
- provide a cost-benefit analysis to management
As our text keeps doing, it takes a couple of steps back when it starts
chapter 11. I wonder if these chapters were published in a serial format,
such as in a magazine, which may have caused the author to want to remind
the reader where he left off in the last article. Assuming we handed in
our risk assessment recently (in the last chapter), we should review it
for comments when it is returned to us by upper management. The text points
out three items to review:
- in-place countermeasures - are these controls staying
in place, being replaced, or no longer being used?
- planned countermeasures - the text says that these are new
controls, ones proposed by us or by someone else, that have just
been approved, so they may need to be purchased, installed, etc.;
the implication is that these are new approvals that we need to put
in the installation pipeline
- approved countermeasures - these are controls that have been
approved previously, but have not yet been installed; the text
implies that these are old approvals that need to be implemented
The author could have chosen clearer labels, but this appears to match
In the section that follows, the text suggests that we look for overlap,
or double coverage, in our growing list of controls. One might
consider looking for a way to save money by applying fixes that help us
in more than one area, and choosing not to buy the second defense.
The text advises us that this is not always a good idea. Having more
than one kind of defense for a particularly nasty threat/vulnerability
pair can be very helpful. If an exploit is found that bypasses one of
them, the other may still defend us if it uses a different method. This
is a good reason to seek out multiple defenses against loss, generally
called using a defense in depth strategy.
A few pages are devoted to discussing a password management policy, including
a list of features that are commonly spelled out for users and administrators.
This is good information, but outside the scope of this chapter, so we
should proceed to page 289, where the discussion of converting an assessment
to a mitigation plan begins.
The text is concerned about three major effects of a mitigation plan,
listed on page 289 and detailed in the pages that follow.
- cost to implement the countermeasures - The text reminds us
that some countermeasures have associated costs. The initial
cost of the hardware/software to be used, the cost to house the
equipment and staff who will use/maintain it, the cost
of installing the equipment and additional equipment (such
as racks, power runs, air conditioning changes, and UPS units), and
the cost of training staff to use and maintain it are common
costs associated with countermeasures, just as they are with any new
- time to implement them - We should consider the time
it costs our staff to achieve implementation, as well as the
time that we are still exposed before implementation is
- operational impact of the countermeasures and of the implementation
- Will the countermeasures raise operational costs in terms of time
to do one's job, time spent doing things in harder ways, time spent
venting frustration because what we could do before can't be done now?
Will staff be tied up during implementation, causing a loss of productivity
with regard to their regular jobs?
The text opens a new topic on page 297, making us wonder if a project
we work on in this way will ever be completed. It introduces another chart
that can be used to develop priorities for our organization. The two charts
on pages 298 and 299 represent one concept, but they do not appear to
be doing so. It is easier to understand if we start with the second chart,
and think of it in terms of something we discussed in chapter :
Risk Level = Probability that an exploit of a vulnerability
will succeed x Impact of that occurrence on the organization
- The chart on page 299 has threat descriptions in its first
- The second column contains a score for the probability
that each threat will be realized in a successful exploit. These scores
are only ballpark guesses, so our hypothetical analyst is assigning
scores of 100% for high probability, 50% for medium probability, and
10% for low probability.
- The third column contains impact scores, based on guesses about
the impact an occurrence of the threat would be to our company.
This column has raw scores of 100 for high, 50 for medium, and 10 for
- The fourth column shows risk level, expressed as the
result of the formula above. The text proposes that we use the scores
in this column to prioritize the actions we will include in our mitigation
||Risk level score
|Attacks on DMZ servers
||High = 100%
||Medium = 50
|Loss of key data
||Medium = 50%
||High = 100
||Low = 10%
||Low = 10
Note that in this evaluation scheme, the composite scores for the first
two rows are the same. Each is rated high on one factor, and medium on
the other. In the next couple of pages, cost benefit evaluations are done,
a recommendation is sent to upper management.
One page 304, we see that a risk mitigation project is being planned.
The text cautions us to watch two things carefully: schedule and
budget. This is good advice for any project, and it is most important
for this one because protection and risk reduction affect the entire organization.
With regard to project costs, make sure to account for the costs that
are listed above, and again on page 304. Regardless of cost increases,
staying on schedule is most important. It would be hard to explain falling
victim to an exploit that we should have already had protection against.
The text advises us to follow up on our plan, after it is carried
out, as well as while it is being carried out. We should make sure that
the controls we asked for have been implemented correctly, that
they are operating as needed, and that they are effective
against the risks we want them to protect us from.
The chapter ends with some recommendations for best practices:
- stay within scope
- redo CBAs (and other assessments) as needed
- prioritize countermeasures
- include current countermeasures in our analysis
- watch for cost changes, especially in controls
- control the schedule
- follow up