ITS 3050 - Security Policies and Auditing

Managing Risk in Information Systems
Chapter 7, Identifying Assets and Activities to Be Protected
Chapter 8, Identifying and Analyzing Threats, Vulnerabilities, and Exploits
Chapter 9, Identifying and Analyzing Risk Mitigation Security Controls

Objectives:

This lesson presents three chapters about identification and analysis of our assets, their risks, and controls. Objectives important to this lesson:

  1. Downtime in availability
  2. Review of asset types
  3. Identifying assets: immediate importance to incidents, to business continuity, and to disaster recovery

  4. Identification of threats, vulnerabilities, and exploits

  5. In-place controls
  6. Planned controls
  7. NIST classification of controls
  8. Procedural, technical, and physical controls
  9. Best practices regarding controls
Concepts:
Chapter 7

The chapter begins by returning to access and availability, this time with some common measures. We may need our systems to be up 24/7/365(366), or we may only be interested in having them up and available for specific business hours. The idea of needing to be up for a limited time each day applies to a smaller audience than it did before the Internet made every business feel the need to be open to customers on any schedule, in any time zone. Because this is so, we generally see charts about uptime that assume a goal of the system being always available.

The text only mentions downtime briefly. You should know more about it. Below, you see a table of downtimes (third column) expressed as a span of time that represents a percentage of a year. This is a common measure, but you should be aware the vendors often show their expected downtime by spreading the yearly time over the entire year, and treating the system as if it would be off line by the amortized amount in a week or a month. This is interesting, but you should realize that system outages measured as annual amounts may be clustered around only a few events, not spread evenly throughout each month, week, or day of the year. You should be aware of the notation regarding the number of nines in each example, since it is commonly used:

Percentage of Uptime Name Yearly Downtime
90 One Nine 36.5 days (10%)
99 Two Nines 3.65 days (1%)
99.9 Three Nines 8.76 hours (0.1%)
99.99 Four Nines 52.56 minutes (0.01%)
99.999 Five Nines 5.26 minutes (0.001%)
99.9999 Six Nines 31.5 seconds (0.0001%)

Note that we are not really under an hour of downtime for the year until we reach five nines, which is more reliability than the average customer would think to ask for until they see a chart like this. Do you think an hour per year isn't much? What if it happens all at once? What if your cable system was out for an hour a year? Which hour? How about your phone? How about the 911 service in your area? How about the power to a hospital or to an air traffic control system? For some systems, failure is not an option.

The text mentions that server redundancy with failover is a common practice. It is briefly described on page 168 in a system with two servers, one designated as the failover server. It is ready to go into service should the primary server go down. Be aware of the concept. Having your key servers in clusters that provide failover allows for more uptime, and also allows for maintenance without downtime in service. Think about redundancy in other areas where it is probably needed:

  • storage
  • network runs and networks
  • power
  • operating sites

Let's move on to page 173, where the text discusses assets again.

  • It expands on the level of detail we should capture about our software assets. For each program, record its name, published, version number, and more. The text recommends using an automated system that regularly polls all hosts, or requires them to regularly report, to keep up to date records of software and patches. In a small shop, you could do this by visiting each workstation, but a larger shop makes manual listing unworkable. To determine which option is better for your organization, do a cost benefit analysis.
  • Personnel assets are mentioned, and it is recommended to use management software to track incoming and outgoing personnel, training, jobs, skills, and evaluations.
  • Data assets are the ones that come to most minds first for large organizations.

The text offers several categories of data, to remind you to look in those corners of the company assets as well.

  • Employee data - payroll data, insurance data, job performance data
  • Billing and financial data - bills we are owed as well as bills we must pay
  • System configuration data - you do keep records about your systems' state when set up, as well as their current states? If not, why not?
  • System data - everything that explains how our systems work, where everything is, and how it is all connected
  • Vendor data - who do we buy from, what do we buy, what do we do with what we buy?
  • Customer data - everything we know about our customers
  • Intellectual property - inventions, patents, trademarks, and company secrets

The text breaks things down again in terms of where our concerns are in each of its seven domains. I begin to think that the author came up with this concept. After making a diligent search for assets and their associated information, the text leads us to the next logical step. Each asset should be tagged with information about our need for that asset in order to continue doing business. Several kinds of planning are involved in a cycle that starts here. In different organizations, several different kinds of plans are made, called by different names that relate to the circumstances of the event and the scope of the plan.

  • Business Impact Analysis - The green highlight on this bullet is to show that this step should be done when times are good and we can examine our systems performing normally.
    Before you can plan for what to do, you have to figure out what is normal for your business, what can go wrong, and what can be done to minimize the impact of incidents and problems/disasters (see the bullets below).
    • What are the business's critical functions? Can we construct a prioritized list of them?
    • What are the resources (IT and other types as well) that support those functions?
    • What would be the effect of a successful attack on each resource?
    • What controls should be put in place to minimize the effects of an incident or disaster? (Controls are proactive measures to prevent or minimize threat exposure.)
  • Incident Response Planning - The red highlight on this bullet is to acknowledge that the plans made in this step are used when there is an emergency for one or more users. (Shields up, red alert? Why were the shields down?)
    The text is consistent with the ITIL guidelines that call a single occurrence of a negative event an incident. An incident response plan is a procedure that would be followed when a single instance is called in, found, or detected. For example, a user calls a help desk to report a failure of a monitor that is under warranty. (Note that this is an example of an IT incident, not an IT security incident. What further details might make this part of a security incident?) There should be a common plan to follow that will repair or replace the monitor. Incident Response Plans (Procedures) may be used on a daily basis.
  • Business Continuity Planning - The orange highlight is meant to indicate that these plans are not concerned with "fighting the fire", but with conducting business while the "fire" is being put out.
    Business continuity means keeping the business running, typically while the effects of a disaster are still being felt. If we have no power, we run generators. If we cannot run generators (or our generators fail), we go where there is power and we set up an alternate business site. Or, if the scope of the event is small (one or two users out of many) maybe we pursue incident management for those users and business continuity is not a problem.
  • Disaster Recovery Planning - The yellow highlight here is to indicate that the crisis should be over and we are cleaning up the crime scene with these plans.
    Determining that a disaster has even occurred requires that we judge its scope. One person having a desk full of paper ruined by spilled water is not a disaster. (For perspective, consider the legend about Isaac Newton, who reportedly handled a worse circumstance with more grace.) A disaster requires widespread effects that must be overcome. A disaster might be most easily understood if you think of a hurricane, consequent loss of power, flooding that follows, and the rotting of the workplace along with the ruined computers and associated equipment. A disaster plan is what we do to restore the business to operational status after the disaster is over. There may be specific plans to follow for disasters under the two bullets above, but the disaster recovery plan is used after the crisis, unless this term is applied differently in your working environment. Multiple incidents can become a disaster, or may lead us to realize that there is one, especially if there is no plan to overcome them.
  • By the way, in ITIL terms, a series of incidents may lead us to discover what ITIL calls a problem, something that is inherently wrong in a system that might affect all of its users. Some books call this a disaster. The organization you work for may use all three terms, or any two of them to mean different scopes of trouble. You need to know the vocabulary to use in the setting where you work, and you need to call events by the names they use.
  • Is there a condition for a blue highlight? We might pretend there can be, but it is unlikely that the IT Security staff would ever feel that safe and serene.

Chapter 8

You may note, in the objectives above, that I only assigned one objective to Chapter 8. It is very repetitive and we can skim through it easily. The main purpose of the chapter seems to be to introduce more technical definitions and to fill pages with material from other chapters. On second thought, let's not go to chapter 8. It is a silly place.

Chapter 9

Chapter 9 has more content, so we will move on to it. (See, it's not always the last one in sequence that's the most worthless.)

The chapter begins by dividing controls into two groups:

  • in-place controls - controls we are already using, which should be evaluated according to their performance
  • planned controls - controls we are planning to use, but have not for various reasons; we need to know what controls have already been approved, purchased, or sit in a box waiting to be installed, so that we do not notice a need and run off looking to find a solution that is already in our pipeline

The text warns us that there are more controls than we could possibly list in this chapter. This link will take you to NIST SP 800-53, revision 4, a 462 page document whose bulk is mostly taken up by its appendices, mostly F and G. It is one of several models for organizations who are planning on adopting security controls. This one discusses over 200 security controls. (We will discuss more models in the second half of this course.) Pages 227 through 229 in our current text describe 18 categories (or families) of controls in NIST SP 800-53. You should browse through the list to get an idea of the many things you may have to make rules about, make procedures for, or install equipment to protect.

Several pages of the text are devoted to describing controls that fall into three categories. Before we discuss them, be aware that there are many ways to categorize controls, even in the same model. Some categories overlap, so don't wonder much if your intuition is not mirrored in any one particular scheme::

  • procedural controls - This category has several parts which include policies (rules), procedures (methods of following rules), standards (specific applications of rules), and guidelines, which are more like good suggestions that are not actually enforced.
  • technical controls - Technical controls have to do with technologyand actions that are performed by devices (technical solutions), such as firewalls denying packets.
  • physical controls - These include any physical barrier, like a locked door or a fence, as well as security cameras and guards.

The examples of most of these controls are clear, but make sure you look at them as examples, not as a definitive list. In the section about physical controls there is a short discussion about fire suppression, which belongs in any safety class, as well as any class concerned with network or system security.

For a fire to exist, three factors are needed:

  • oxygen
  • fuel
  • heat

If you can eliminate any one of these factors, the fire will go out. This is why Carbon Dioxide extinguishers work: the CO2 replaces the oxygen in the immediate vicinity of a fire, and the fire stops. Smothering a campfire works about the same way.

A fire break is an example of fighting a fire by depriving it of fuel. Forest fires can be fought this way. Somewhat similarly, I once walked into a rest room in an office and found that someone had placed a roll of toilet paper on top of the light fixture over the sink. I noticed it because it was on fire. I grabbed the roll of paper and tossed it into the sink. This established a fire break between the fire and the rest of the building. I then put out the fire on the roll of paper with water (depriving it of oxygen).

Keeping your computer system cool, so that a fire will not ignite, is your most effective form of firefighting: don't let it start.

Fire Extinguishers - American fire extinguishers are classed by the kind of fire they are able to put out. The links below will take you to sites with more information about fire classes and extinguishers. In surveying several sites, I found that there are currently at least four classes of fires, and that the symbols for them have been updated to use pictures instead of letters. Some sites list a Class K for cooking oils (Kitchen fires), but this does not seem to be universal. The chart below contains American symbols:

Description of Extinguisher Class
Letter and Shape Symbol for Class
Picture for Class
Class A: paper, cloth, wood.
A in a triangle symbol
Icon for class A fires
Class B: oil, gasoline, kerosene, propane.
B in a square
Icon for class B fires
Class C: electrical
C in a circle
Icon for class C fires
Class D: combustible metals, such as magnesium, potassium, sodium
D in a sta
Icon for class D fires
Class K: combustible cooking oils
K symbol for kitchen fires
Icon for class K fires

The table below is from a Wikipedia article on fire classes. It shows that the same kind of fire is called by a different name in different places:
Comparison of fire classes
American European Australian/Asian Fuel/Heat source
Class A Class A Class A Ordinary combustibles
Class B Class B Class B Flammable liquids
Class C Class C Flammable gases
Class C UNCLASSIFIED Class E Electrical equipment
Class D Class D Class D Combustible metals
Class K Class F Class F Cooking oil or fat

In most cases, a multiclass extinguisher is preferred. On extinguishers I examined at my workplace, multiple picture symbols were used, showing the pictures for classes A, B, and C.

Another text discusses some fire extinguishing systems. Common types are sprinkler systems, foam systems, and gas dispersant systems.

  • Sprinklers typically spray streams of water or water mist. The test in the video behind this link seems to point out a limitation of automatic mist.
  • Gas dispersant systems used to use Halon, and still can, but they are restricted to existing Halon supplies. Carbon dioxide is an alternative, but both solutions tend to be dangerous to air-breathing life forms in the immediate area.
  • Another system uses foam as a suppressant, and the people testing this system seem to be enjoying it greatly.
  • The text also mentions dry chemical systems which spray a fine powder over the fire. This is similar to using baking soda to fight a small kitchen fire.

The chapter ends with some best practices about mitigation controls:

  • ensure controls are effective
  • review controls in all areas
  • review NIST SP 800-53 families of controls
  • review the matching risk assessment if a control is changed

Assignments

Assignments for these chapters will be found in Canvas. We will explore that in class.