|
|
CSS 111 - Introduction to Information System Security
Chapter 10, Implementing Information Security
Objectives:
This lesson discusses putting a security program in place.
Objectives
important to this lesson:
- Planning an implementation project
- Handling the technical problems
- Handling the non-technical problems
Concepts:
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.
|
