CSS 111 - Introduction to Information System Security

Chapter 5, Planning for Security


This lesson discusses policies and related guidelines, security blueprints, and contingency planning. Objectives important to this lesson:

  1. Define information security strategy and policy
  2. Benefits of risk management, controlling, and mitigating
  3. Understand the importance of education and training in relation to security policies and standards
  4. Understand contingency planning and incident response
  5. Understand disaster recovery plans (DRPs) and business continuity plans (BCPs)

The chapter begins with an episode that is meant to put the fear of failure in all of us. Despite the fact that the story of a business burning down turns out to be only a dream of one of the characters (which may be the most tired cliché in literature), we can still learn from the cautions that it contains.

We will begin on page 177, with the discussion of security policies., which our authors believe are critical to having a functional organization. So what makes a good policy?

  • A policy should not be in conflict with applicable law. (Should not? Maybe the author meant must not.)
  • A policy must stand up in court when challenged. This sounds like the first rule, but it is more about proving the legality of the policy itself, not its being in accord with existing laws.
  • A policy must be properly supported and administered: supported by authority in the enterprise, and implemented and enforced correctly and fairly.

Let's consider some definitions:

  • policy - a plan that influences decisions;
    a guideline for decisions and actions;
    a set of rules about what actions are acceptable and what actions are unacceptable

    The text says that policies are "organizational laws". This is true, but you will lose your audience as soon as you say something that arrogant in a memo or a meeting. Realize that you and your policy committee are not the UN, not the US Congress, not even the Masons or Knights of Columbus. Your employees will not receive a "law" from you, or obey it. They may listen to a new rule, if you explain it correctly.

  • standard - a statement of what must be done to comply with a policy;

    example: a standard might require that workstations bought for use in a particular area (e.g. systems development) must be either of two specific approved workstation models in order to comply with a policy that we only purchase workstations from a short list from a contracted vendor;
    a standard is typically more specific and narrow than a policy, and tells you how do what you need to do so you don't break the rules that apply to a particular job

  • practice - if a policy and its standards are still a bit vague, a practice is document that spells out more specifically what we must do to be in compliance;

    if standards are specific enough, a statement of practice may not be necessary;
    if different work areas, for example, must follow the rules in different ways, they may each have a statement of practice to tell staff how to comply in their jobs

The text has a list of requirements for a policy to be effective:

  • must be properly written - understandable, relevant, clear
  • must be distributed - although the historical legend about ignorance of the law not being an excuse, it is not sensible to expect staff to comply with a policy they are not told about
  • must be read - if we email a policy statement to all employees, does that guarantee that they all will read it?
  • must be understood and agreed to - it is frequently amazing that people will agree completely with a policy as long as it applies to someone else, not them
  • must be uniformly applied - the rules should be the same rules for everyone, or the policy will cause those who must follow it to resent those who do not and those who make and enforce the rules

The points above are sensible but arguable. Have you ever worked someplace where all the rules apply equally to all employees? If so, it must not have been a very large organization.

The text describes three types of policies. The types vary by the scope of their policies, what they affect, and who they affect:

  • Enterprise information security policies - policies that apply to an entire organization
  • Issue-specific security policies - policies that apply to a particular technology or problem, which may only concern staff who are concerned with the issue; concerned with usage and operational rules for specific systems
  • Systems-specific security policies - may be standards for setting up or maintaining systems; policies that apply to a particular system, such as the Law Enforcement Information Network, a system that is primarily used by police officers. There is an enterprise policy about this system: no one may use it but authorized personnel. All other policies are system-specific, and are made known to authorized users.

A security management model is meant to be a generic description of what an organization should do to provide a secure environment for itself. It is generic in that it describes what should be done, but not how to do it, which makes it flexible enough to be used by many kinds of organizations. The text states on page 190, that you should choose a model for your organization to follow that is "flexible, scalable, robust, and sufficiently detailed". Many security management models exist, some of which are discussed in detail in the chapter.

Once your organization chooses a security management model, it should create a custom version of it that applies to your organization. The text refers to this as your security blueprint. In the course of developing your security blueprint, you may need to create an outline to follow, which the text calls your security framework. This is confusing because the text explains these words in terms of each other, and also refers to some standards as frameworks. Close your eyes, shake your head, and let's try again.

To put those terms in perspective, imagine three phases of a project to develop your security management policies, standards, and practices:

  1. First, select a security management model that fits your organization's needs and goals.The text discusses the ISO 27000 model and the NIST model.
  2. Second, write a security framework document, a plan that outlines the work needed to adapt the model to the realities of your organization. This document might compare your organization's needs to the chosen model.
  3. Third, create the security blueprint, which is a working, operational document. It describes how your organization will meet each applicable requirement of your security model, through the goals that are established in your framework.

So, that means you need to create the framework and the blueprint, but your first goal is to select a model that makes sense. How do you select a model? Sometimes, a model has been selected for you by another part of the organization (upper management) and you simply have to use it. The good news is that whichever model was chosen, it will probably work after being customized into the blueprint for your organization.

Sometimes you are not handed a decision, and you must make one. Even though many of the models will yield good results in most cases, you should examine some of the major models available to make a choice that fits well with your organization. Starting on page 191, the text finally begins a discussion of several security management models. This section is confusing as well, this time because the text starts discussing a new standard before it finishes showing us tables and figures for the last one.

  • ISO 27000 Series (International Organization for Standardization) - see the list of topics on page 193 that relate this model to the Continuous Quality Improvement concept of Plan-Do-Check-Act
  • NIST (National Institute of Standards and Technology) Models - see the table on page 200, 33 principlles in NIST Special Publication 800-14, and the bullet points on page 194
  • ITIL (formerly Information Technology Infrastructure Library, now just ITIL) - the text does not discuss this standard, but you should know about it due to its wide and growing use; see the ITIL official site for more information; it was created by the British government and has become a world wide standard

The text continues with an overview of some concepts that apply to actual security designs for an organization. We will make of of some of the good ones:

  • defense in depth - security measures should have multiple layers; an attack that bypasses a layer of security should encounter another that may stop it
  • security perimeter - your security measures can only extend over what you control, so you take particular measures to protect at the boundary, the perimeter, between your assets and the rest of the world
  • firewall - a filter that denies or allows particular kinds of network traffic; a firewall for a web server might allow traffic on port 80, which is used for HTTP traffic, but deny it on most other ports; a firewall might also allow or deny traffic based on IP address, domain name, or the state of the connection
  • DMZ - I have never understood why this term is used. The letters stand for Demilitarized Zone, which is a military term for a geographic area in which contending forces do not place troops or other military assets. Its purpose in that context is to prevent conflict by establishing a buffer between two armed forces.
    In the context of information system security, a DMZ is a part of your network that has no connection with the other parts, and holds no assets that the rest of the world may not see.Your text calls it a "no man's land" but that is not accurate. We still protect this area with security measures, but we use it as an area where public business is conducted. The metaphor is flawed, as you should see, but it is commonly used so you need to know about it.
  • proxy server - a server that receives requests, then forwards them to the actual server that will meet the request; the proxy server acts like a firewall filter, refusing requests that it has been told are invalid, and it acts like a DMZ device, protecting the "real" network from the outside world
  • Intrusion Detection and Prevention Systems (IDPSs) - this time the name is accurate: an IDPS watches what happens on a network, notices unusual behavior (detection), and acts to stop attacks in real time (prevention). The text points out that this kind of system may run on a network for general protection, or may run as a service on a particular host for more local protection. (In case you have not run into that word, any device that is connected to an IP network, and has a network address, is called a host.)

We will move ahead to the discussion that starts on page 209 about Security Education, Training, and Awareness (SETA) programs. The text says that such programs offer three main benefits, but we should consider these benefits as goals, since they are not guaranteed:

  • Improving employees' security related behavior
  • Informing employees about security issues so they can work more securely
  • Enabling the organization's technical staff to create more secure systems and policies

As the acronym says, there are three parts to a SETA program, each of which the text briefly describes on page 210:

  • Education - ongoing education for the professionals who will need periodic enhancement of their skills and knowledge, regardless of whether the organization requires staff to pursue formal certification
  • Training - training generally means teaching someone how to do something without necessarily teaching them the formal knowledge that a professional employee may need; training in this sense is the practical information that people need to do a job that is not an IT security job, such as knowing how to update the virus signatures on a workstation, or knowing how to scan a file or a hard drive for viruses;
    training will need to be refreshed or updated as your environment changes;
    different training may be offered to staff who perform different jobs or who have different skill levels
  • Awareness - this part of the program is a reminder to staff to be aware and act on their awareness, to promote new information as needed, to remind users to use the training related to their jobs;
    the text presents several methods of presenting material in an awareness program, much of it resembling advertising

Assignment 1: Policy announcement

  1. Create an imaginary company whose Chief IT Security Officer you will be. Name the company, briefly state the business the company is in, and describe a security issue for it.
  2. Write an enterprise security policy for your company. Write it in the form of an announcement to your employees. It should be one page long, or less, and it must state the policy, the reason it is needed, examples of compliance and non-compliance, and the possible penalties for non-compliance.

The text discusses the plans (mentioned last week) that are part of mitigation. This material is taken from another of our authors' books:

  • 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 to 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.
    In another text, the same authors tell us a story about a coffee pot that burned up, causing smoke in the area, causing sprinklers to go off, causing damage to paperwork on one person's desk. Despite the emotional response of the person in the text's parable, one person having a desk full of paper ruined by water damage is not a disaster, except to that person. (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.
  • Your text says 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 its users. Your authors seem to 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.

On page 225, the text discusses an interesting concept: incident containment. Some incidents are contained by their nature. A person who can't print because he needs a driver is experiencing a problem that does not affect other users. The worm infestation back in the introduction to chapter 1, however, is a classic example of a problem that needs to be contained. The text offers some advice on containment:

  • Is the incident happening inside or outside our network? If it's outside, can we close off our connections to the outside to contain it? If it's inside, can we kill the network ports of the affected machines?
  • Are network accounts being used by the incident/virus/worm/attacker? Can we deactivate the account(s)?
  • Can we put a new rule in our firewalls to stop identifiable traffic?
  • A port can be a jack that connects a device to the network, but port also means a service (a program) running on a device. We may need to kill that kind of port to stop an attack.
  • Do we need to tell other essential services, like email, to ignore requests from particular accounts or addresses? It may be necessary to take the service off line temporarily to reconfigure it, but this is better than taking it down indefinitely, disrupting business.

Assignment 2: Exercise 5 from the text

  1. Exercise 5 on page 242 has five parts. For each part, tell me whether the situation is an incident or a problem/disaster.
  2. For each of the five scenarios, what would be an effective strategy to handle the incident or problem? Describe all steps you would want to occur on the day that the event happens.