ITS 4350 - Disaster Recovery

Chapter 1, An Overview of Information Security and Risk Management

Objectives:

This lesson presents an overview IT security concepts. and how they relate to plans for handling incidents and disasters. Objectives important to this lesson:

1. Key concepts
   
2. Risk management
   
3. Contingency planning
   
4. Relating security policy to contingency planning

Concepts:

Chapter 1

Our text defines contingency planning as being the process that makes us prepared for incidents and disasters related to our organization's IT assets. We are given a few examples of historic incidents and a statistic that makes a good point. The author tells us that "80% of businesses affected by a disaster either never reopen or close within 18 months of the event". These are organizations that either had no disaster plans, or they had plans that were inadequate for the disasters they encountered.

Having made this point, the author spends several pages discussing terms that you will need to know. Many should be familiar to you.

• Information Security - protection of information and the systems that collect, store, disperse, and use it
  

The next set of terms is one you see in a lot of texts about security:

• Confidentiality - information should only be accessible to users who have been granted access to it for valid reasons. Only authorized users can access data if it is protected properly, and if authorized users do not violate security policy.
• Integrity - data may not be changed except by authorized users or processes. This means that data must be protected from alteration, deletion, or other changes to its intended form.
• Availability - authorized users can access data when they need to do so. Availability includes the idea that proper access methods are provided to only to authorized users, not to everyone.

The text confuses the issue with a graphic on page 4 that the author does not explain. The classic CIA concept defines security from the point of view of the IT Security staff. The text should explain that an expansion of this concept is called by several names, one being the McCumber Cube, another being the CNSS Security model. This is the name used in the text. It provides three different perspectives on security, which should be considered together to make better security decisions:

• IT Security perspective: Confidentiality, Integrity, Availability
  How do we protect the information, make sure it is not tampered with, and provide access to those who need it?
  
• IT Operations perspective: Storage, Processing, Transmission
  How do we perform the basic IT functions of storing, processing, and transmitting data? Are our processes secure?
  
• Business perspective: Policy, Education, Technology
  How do we make the rules for employees about protecting information, educate our staff about protecting it, and use the technology we have to run our business safely?

This link will take you to a Google search for images that represent these concepts.

The author continues with more 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
• Control - A process that we put in place to reduce the impact and/or probability of a risk. The author mentions that a control can also be called a safeguard or a countermeasure.
  

On page 5, the text presents a list of threat types ranked from 1 to 12 in two different surveys. The rankings changed a bit, but the list is given an aura of accuracy by showing us the same categories in both survey years. Don't hope too much that these are the only threat categories that matter. The surveys were done by the same people, so they used the same categories. The author discusses each of the twelve categories to give you a feeling for what they are. Browse through any that are unfamiliar to you.

On page 12, the author changes topics, and discusses risk. As some of you know, we have classes just about risk management, so this section is not all there is to know about it. However, the graphic on page 12 gives us a nice overview of a workable process for managing risk.

• In the first phase, we identify risks, by inventorying and classifying all our assets, and then identifying the threats that apply to those assets, and the vulnerabilities those threats could use against us.
• The second phase takes us to the selection of appropriate controls, and justification of their cost and value to decision makers in our organization.
  

The chapter continues with an expansion on each of the topics in the graphic.

• Know something about the big picture - Who and what are we protecting, from whom and what. To know details about these subjects, do everything on the green chart.
  
• Identify, classify, and assign values to assets - To know our exposure to risk, we have to know what we have and how it is exposed. Assets can be classified by their level of secrecy, their value to the organization, their need to be protected, or by combinations of these factors as well as others.
  
  In the chart on page 16, we see five information assets, each on a separate line. Each is given a rating (from 0 to 1) on each of three measures of how a compromise of that asset would affect the company. The three measures in this case are impact on revenue, impact on profitability, and impact on image. Assuming these are the most important impacts our organization cares about, each is given a relative percentage score. In the example, the organization cares 30% about revenue, 40% about profitability, and 30% about image. That is the criterion weight. For each asset, its score for a given criterion is multiplied by that criterion's weight, producing three weighted criterion scores for each asset. The asset's total weighted score is the sum of its  three weighted criterion scores.  For instance, the first asset has a score of .8 for revenue (weighted criterion score is .8 times 30 = 24), .9 for profitability (weighted criterion score is .9 times 40 = 36), and .5 for image (weighted criterion score is .5 times 30 = 15), so its total weighted score for the comparison is 75. Compare that score to the other lines, and you see that this asset is the third most important asset in this comparison. Warning: do not compare scores from one table to another unless they use the same criteria and the same weights.
  
  The text provides another example of rating assets, based on a military scale that uses four levels for secrecy. A scale like this may be more useful for assets that do not have a particular effect on the organization unless they are compromised.
  
• Threats must be identified, and matched with assets affected by them. Not all threats will affect all assets.
• Assets must be examined again, with respect to the threats that could affect them. How vulnerable is each asset to each of its possible threats? This evaluation gets us ready to do the big one on page 18.
  

Assuming you have followed the steps so far, there is an important calculation to do.

• Each asset needs to be given a value, based on its replacement cost, its current value to the organization, or the value of the income it generates. Pick one of those or some other value you care about. This is the Asset Value. Let's choose $100 as an example for Asset Value.
  
  
• Next, we need to determine, for each exploit, what the probable loss would be if that exploit occurs successfully. Would we lose the entire asset? Half of it? Some other percentage? Which percentage we pick tells us the Exposure Factor of a single occurrence of that exploit for this asset. Let's choose 50% as an example for Exposure Factor.
  
  
• We are still not where we want to be. Asset Value times Exposure Factor equals the Single Loss Expectancy. This is the Impact if the event occurs. In this example, it is $50.
  
  
• Now, we still need the Likelihood the event will occur. The classic way to do this is to consult your staff about the frequency of successful attacks of this type, or to consult figures from vendors like Symantec, McAfee, or Sophos about expected attack rates for your industry or environment. Let's assume we have done that, and we are confident that we expect 10 successful attacks per year in our example. This is the Annualized Rate of Occurrence.
  
  
• Taking the numbers we have so far, we should multiply the Annualized Rate of Occurrence times the Single Loss Expectancy, which will give us the Annualized Loss Expectancy for this asset from this kind of attack. This corresponds to the Risk Exposure. In the example we are considering, that amounts to $500.
  

All that work led us to just one loss expectancy for one asset from one kind of attack. That gives you an idea of the work involved in calculating the numbers for each asset, each asset vulnerability, and each kind of attack on those vulnerabilities.

The next idea is to identify controls that can reduce or eliminate our risk. The text mentions five control strategies that are often considered. The terms are a little different from some other texts:

• Defense - also called Avoidance, this means to use policies, training, and technology to avoid the situations that can be exploited.
  
• Transferal - this means to hire expertise when you do not have it, or to pay a fee to another department or organization that is in the business of managing risk
  
• Mitigation - this means to reduce the damage that will be done in a successful attack, such as not putting all assets of a given type in the same place, protected by the same defenses.
  
• Acceptance - this is when you decide that a risk is not as costly to us as the controls that might be used to avoid or mitigate that risk.
  
• Termination - this means that we decide to stop doing the things that put us at risk; we simply stop dong the things that use or produce the assets that a risk applies to.

Business impact analysis - This process is used to determine the effect that successful attacks would have on our organization. We determine what could happen, what the effects of that event would be, and what state the organization's functions would be in at that time.

Incident response plan - For known incident types, given the BIA done in the section above, what should we do to handle the incident? Who do we call? How do we stop the attack and it effects? This plan is about handling the incident.

The text has the next two topics out of order. Let's fix that.

Business continuity plan - How do we continue business when we have an incident? Do we change our procedures? Do we use alternate locations or resources to continue business? How do we continue providing products or services when part of our organization has been damaged, compromised, disabled, or destroyed? Business continuity plans discuss keeping the business in business during the incident.

Disaster recovery plan - A disaster has occurred. How do we get back to normal, or what will be the new normal? The incident(s) has/have been handled. What do we do to return to our undamaged state, stronger and wiser than we were before?

All four of the major topics above are part of Contingency Planning, what we do when we know things can go wrong. The level of detail in each of the plans will be determined by the size and complexity of the organization making that plan. On pages 28 and 29, the text presents more plans identified by the NIST that would apply to organizations like federal agencies.

The chapter ends with five pages on Information Security Policy. This section introduces the components you might find in a very detailed policy. It begins with some definitions:

A policy is a rule, or a set of rules, that affects how we want our organization and its employees to function. 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. 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

1. Statement of the policy - what it is, where it applies, and who has to do what
2. Authorized access - who is and is not allowed to use equipment or software related to the policy, and what is private about any related data
3. Prohibited use - a graduated scale of offenses and discipline to be applied for violations of various types
4. System management - who runs it, who watches it, how it is to be protected, secured, and/or encrypted
5. Violations of policy - a graduated scale of offenses and discipline to be applied for violations of various types of the policy itself
6. Policy review and modification - how often the review will take place, who will do it, and the process to change or remove the policy
7. Limitations of liability - standard lawyer section