CSS 111 - Introduction to Information System Security

Chapter 10, Implementing Information Security


This lesson discusses putting a security program in place. Objectives important to this lesson:

  1. Planning an implementation project
  2. Handling the technical problems
  3. Handling the non-technical problems
Chapter 10

Chapter 10 opens with a typical story about things going badly for someone. This time the author tells us about an IT security analyst who goes to a change control board meeting, where he tells a lot of people about changes to the company's security program, which will require a lot of work on their part. The analyst has forgotten to get the people to accept and endorse his plan. Perhaps he has no idea that these people already have jobs, plans, and deadlines to meet. This is not the kind of news you bring to people in a change control board meeting. Those meetings are to announce changes that you need to make, not changes you want them to make.

What should our hero have done instead? Any major change in an organization should be considered as a project, which requires planning, obtaining and allocating resources, budgeting, and obtaining agreement from responsible parties.

Skip ahead to page 436, where the author discusses the elements of a project plan.

  • work to be accomplished - what are you going to do (tasks), and what are you going to produce (deliverables)
  • assignees/resources/staffing - knowing what skills are needed for each task leads to decisions about needing specific staff or more/new staff with specific skill sets
  • start and end dates - although a project should have a start and end date specified at the start of planning, these are often only estimates which become more definite as plans are made for each task; determining which tasks must follow (are dependent on) others, which tasks may be done at the same time, and the duration of each task will complete the equation that tells us how long the project may/should run; picking a start date is easy compared to determining the end date
  • amount of effort - the text says determining this is difficult, and sometimes it is, depending on the kind of effort your are trying to estimate; uploading a set of rules to a firewall takes a more predictable effort than writing and troubleshooting those rules before they are loaded; coding an application may take a lot more effort than troubleshooting it; sometimes adding more staff to a task does not help and may hurt; the best advice here is to ask people who are familiar with the work involved to make reasonable estimates of how long a task will take with how many staff assigned to do it
  • capital expenses - generally, large expenses for items that are intended to last for a long, indefinite time
  • non-capital expenses - what else is it going to cost us to do this project?
  • dependencies - the text makes a separate bullet for this; it might be good to look over the work so far, and to consider whether our decisions on staffing, effort assigned to tasks, and most probable durations have optimized our project; if we can't do a task until an earlier one is finished, are we sure of finishing the earlier one on time and successfully?

The author begins a list of considerations (constraints, problems, roadblocks) that typically affect a project on page 441. These are some of the highlights:

  • The author observes that financial considerations drive project decision, just as they drive any other decisions in a company. He brings us back to the idea of a cost benefit analysis, this time doing it for the project and its outcome instead of for a list of safeguards, such as we had in chapter 4.
  • Priority considerations can affect a project and its scheduling. If a particular part of a project is a priority for your management, that part may have to be scheduled sooner that some may want. Be sure you understand what is meant by priority. Do we need it done sooner or do we want to be certain it works?
  • Staffing and training are related considerations. Do we have the skills to run the project? Do we have someone who can use the products of the project, or can we have someone learn how to do that? The outcome of the project may be that we have a new system no one knows how to use or maintain.
  • The text's bullet on training and indoctrination is about general staff in the company, and like other ideas in the text, it makes the company sound totalitarian. If you build a new system, you should plan to train people to use it, or you are asking for a disaster. Whoever interfaces with the system should be told why it is going to be used, how to use it, and what its benefits are. If you can't answer those questions, you need to do so before planning your user training.

On page 445, the author starts a new section on the technical aspects of implementing a new security program. The first topic is conversion strategies, which has to do with how we will change from our current system to the new one.

  • direct changeover, direct cutover - a clean change; we stop using the old system and start using the new one on a chosen date; dangerous if/when there are unexpected problems
  • phased operation - we start with a few users, like a pilot, but we do not move the rest of the users all at once, we move the remainder in bunches; the changeover may be made by organization, by functional org chart unit, or by geography, depending on the needs of the organization or the new system
  • pilot operation - we begin with only a few users on the new system, and when it is proven successful, we move the rest of the users to the system
  • parallel operation - both the old and new systems may need to operate for a while, if we are in doubt about the new one working, if we need to close out operations that depend on the old system, if we cannot transfer some kinds of data and must complete cases in the database rather than move them to the new system

Another text from this author compares these four choices based on their cost and risk. Note that cost and risk are inversely proportional.
Direct cutover - High risk, lowest cost (unless it fails)
Pilot operation - Medium risk, low to medium cost
Phased operation - Medium risk, medium to high cost
Parallel operation - Low risk, highest cost

We will skip ahead to page 448, where the author discusses technology governance and change control. These are two concepts but the author gives the impression that they are the same. Governance is more often associated with large scale decisions that affect the entire organization, such as selecting approved vendors and approval of applications that all staff will use. In that respect, governance is more strategic than tactical. Change control is more often a review of tactical and operational decisions that may affect any number of users or staff. Several goals of a change control program appear on page 448.

The text moves on to what looks like the same concept. It is not, so let's think about the differences. Change control is about technical issues: hardware, software, system, and so on. Change management is about people. Sometimes a change in security, like the one in the introduction to the chapter, requires a change in how people do their work, and what their work actually is. When Bell Telephone implemented automatic circuit switching, the change control issues would have been about the equipment changes. The change management issues would have been about the elimination of all the associated operator jobs and what would happen to the people working in those jobs.

The text tells us that we should develop a culture that supports change in our organizations. This has been the goal of every major change management project I have seen in my career. I can tell you from sitting on both sides of the management desk that the platitudes offered to soothe the nerves of  employees are typically worthless. You are better off providing proof of the benefits of the change, whatever it is, than trying to tell people that they will like it. They may like it or they may not, but they need to be told about it, shown how and why to use it, and given time to transition from one state to the other. (Hint: another reason that the direct cutover method has the highest risk, and may have hidden costs that the project did not plan for.)

The rest of the chapter is about security certifications. You should be aware that several exist, but you may not be interested in any particular certifications until you know what the requirements of your employer are or may be. This should be on your list of things to do when searching for a job: find out what certifications are required or preferred by the organizations you want to apply to.

Assignment 1: Chapter 10 Case Exercise

  1. If you have not done it yet, read the introduction to chapter 10.
  2. Read the Case Exercise that starts at the bottom of page 468.
  3. In the context of our class discussion, answer the three questions for the exercise that are on page 469. For each question, provide at least three different responses.

Assignment 2: Group assignment

  1. Work in a group of at least 3 people. People must be named on your submission.
  2. Research change management exercises on the Internet.
  3. Pick at least two exercises and do them in your groups.
  4. Report on how the exercises went: what did you choose, did the exercises teach you anything.
  5. Tell me what effect you think the exercises are supposed to have on staff experiencing change, and what the effect probably really is.