ITS 2110 - Introduction to Network Security

Lesson 15 - Chapter 15, Risk Mitigation


This lesson covers chapter 15 in the text. It discusses risk. Objectives important to this lesson:

  1. Managing risk
  2. Reducing risk
  3. Common practices

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

Risk Calculation ExamplesThe 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.