ITS 305 - Security Policies and Auditing

Chapter 6, Security Management Models


This lesson presents an overview of several information security models. Objectives important to this lesson:

  1. Knowing the difference between blueprints, frameworks, and security management models
  2. Knowing basic facts about several industry standard security management models
  3. Applying a model to a specific problem

This chapter starts very confusingly, defining terms with other terms that have not been defined. Let's examine the first two pages, and try to make some sense of them.

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 213, 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 standards:

  1. First, select a security management model that fits your organization's needs and goals.
  2. Second, write a security framework document, a plan that outlines the work needed to adapt the model to the realities of your organization.
  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 224, 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 lists of topic documents on page 230 and the list of topics in document 27002 on page 225
  • NIST (National Institute of Standards and Technology) Models - see the table on page 234, 33 principles in NIST Special Publication 800-14, and the bullet points on pages 232-233
  • COBIT (Control Objectives for Information and Related Technology) - discussed on pages 237 and 239 (238 is about an NIST document)
  • ITIL (formerly Information Technology Infrastructure Library, now just ITIL) - the text gives us only one paragraph about it; see the ITIL official site for more information; it was created by the British government and has become a world wide standard

Last week I asked you to look at the Krebs on Security website article from February 12, 2014 about the security problems at Target and other retail stores. If you have not read this article yet, do so now.

Mr. Krebs discusses a believable theory that Target's security was breached by an attacker who first attacked a contractor who had been given an email account at Target. For our purposes, this article can be considered as a post-mortem security audit of the situation, except that it is missing what a paid analyst would typically be expected to provide: a list of recommendations to the client on how to avoid this situation in the future.