Change Management

Dealing with change is a very difficult proposition for most organizations. Unfortunately, in our environment, changes are necessary and frequent. They can have a huge impact on an organization's safety. As a security professional, you have the added burden of ensuring that changes made in your organization do not compromise security. In order to prepare you, we need to discuss some of the methods and processes of change and then focus on change management. This section covers change first from a systemic perspective. Then it looks at how the process of change can be executed in an organization. Understanding these issues and the roles involved in a change process make the process easier to manage and understand.

Systemic Change

When a change such as the implementation of a security policy occurs, it fundamentally changes the way people view the work they do, their relationship to the organization, and their relationship to the management of the company. No doubt, issues of trust will be brought up, as well as confidentiality, work habits, and numerous other issues. If you think of your organization as a community, you are now putting a brick wall around your community. People may be afraid of these changes and deny their involvement in the process. Their fear manifests itself as resistance, unwillingness to discuss issues, and in some cases outright defiance.

This type of posturing can make it difficult to build the consensus, get participation, and establish the sense of cooperation needed to carry out the change. As a security professional, you are the front line of this type of change effort, and you may be blamed for the additional work that is needed. Unfortunately, you may not be in a position to do anything about it, except to stick to your guns. You have a job to do, and you will be measured on your ability to carry it out.

In order for a change process to occur, you must recognize that there are three primary roles in a change process. They are the sponsor, the agent, and the target. Each of these roles is affected in different ways by a change process. The next few paragraphs will explain these roles.

Understanding the Roles in a Change Process

Knowing who is responsible for what roles in the change process must be clear to you when you operate as a change agent. This section discusses the three primary roles of a change process:

Sponsor The sponsor, in most cases, is the management of the organization. Sponsors are responsible for providing direction to the organization empowering a change process. This means that the sponsor must buy into the effort. In order for a sponsor to do that, they must have the facts, figures, and information necessary to make intelligent decisions. Further, sponsors are your primary supporters in the change process. The sponsor gives you the authority to carry out the job that needs to be accomplished.

Change Agent The change agent is the individual responsible for assisting the organization in making the changes needed. Change agents do not own the change; they assist in accomplishing it. A change agent in a security environment may be an implementer, a security professional, an outside consultant, or any other person involved in making the changes occur. The change agent acts as a representative of the sponsor. You will most likely be acting as the change agent in this process. You cannot direct people to do things; you can merely represent the management of the organization. Management is responsible for enforcing changes. An effective change agent is a consultant, a teacher, and a specialist in the activities that need to be accomplished. You are that person. Being a change agent is a big job, and you may feel that you are caught in the middle of a battle at times. The plain truth of the matter is that you are. Nevertheless, you must accomplish the tasks that are set out before you.

Target The target is the people, processes, or issues that need to be changed. In a security implementation, the target is the systems, networks, procedures, policies, and individual behaviors needed to make the changes occur. From a security perspective, all of these targets must be addressed. If they are not, the likelihood that the change will be successful will diminish.

Justifying the Need for Change

The biggest aids you have in justifying the need for change are the facts themselves. Simply, organizations are at risk, and this risk costs money. Some simple questions that you can ask that might help you identify those costs are part of the Business Impact Analysis (BIA). The BIA helps the company quantify the losses of particular systems or services. This analysis of loss and risk includes both hard data and intrinsic (or soft) costs of a security problem. Several formulas are available that you can use to help quantify the loss of a system, server, or network. These formulas can help you explain to management why they need to take it seriously and what their exposures are to system loss.

Note 

You will not be tested on these formulas in the Security+ exam. They are intended to help you understand some of the costs of a system loss.

Single Loss Expectancy The single loss expectancy (SLE) is the cost of a single loss when it occurs. This loss may be a critical failure or the result of an attack. The SLE is calculated using the asset value and the exposure factor (EF). Asset value is the value assigned by an organization to a resource or data. In the case of a virus that is successful in erasing a hard disk, the data may cost thousands of dollars to recover—if it can be recovered. The EF identifies the amount of damage that may be unrecoverable if a loss occurs.

SLE = asset value ´ exposure factor (EF)

If a server containing customer records were attacked, the customer record file may have an asset value of $20,000. If this is likely to occur once during the life of the project, and 30 percent of the data would be unrecoverable, the loss would cost the organization: $20,000 ´ .3 or $6,000. In the case of a customer master file, that information is probably worth considerably more than $6,000. You would want to gather the raw data from the management of the organization.

Annualized Loss Expectancy The annualized loss expectancy (ALE) is a measure that represents the possibility of a loss occurring more than once in a year. The formula for this is based on the SLE, and it is multiplied by the number of occurrences or annualized rate of occurrence (ARO).

ALE = SLE × ARO

If you have a server that is repeatedly being attacked, and it costs $6,000 per event, and the server is being successfully attacked three times in a year, the cost of these incidents is $6,000 × 3 or $18,000.

You can use these formulas to help make your case to your company about the cost of losses in the organization. It does not take long for these figures to reach a painful level for an organization.

These tools are only two of the methods that you can use to help identify the costs of attacks or other losses. Consider them when you are asked to justify why these measures are needed. They can help strengthen your case.

Scheduling Changes

Changes in an organization can be very disruptive and chaotic. Effectively scheduling changes can help an organization adjust workloads, reschedule activities, and feel more in control of the process. Scheduling changes to occur in manners that cause the least amount of disruption to the fewest number of people is important. If you consider this, you make the change process more palatable.

Additionally, schedules and the anticipated duration of outages need to be made public. In many situations, your scheduling may be somewhat optimistic. You are encouraged to give yourself enough time to make changes to systems. If you allow more time than you actually think it will take, you will frequently come out ahead in the process.

For example, if you have to take the network down to add a new router, it may cause an outage of an hour. In many situations, this would be all the time that you need. What would happen, however, if the router needed to be reprogrammed because of an error? If you tell users that the network will be down from 8:00 A.M. to 9:00 A.M., users will expect to be able to use their systems at 9:00 A.M. By 9:10 A.M., you will start getting phone calls complaining about the delay. If you allocate an hour and a half to the process in your announcement, you may find that you are a hero by bringing the network back up at 9:15 A.M. After all, you did bring the network up 15 minutes early. You should allow yourself enough time to deal with unusual situations when they occur.

If you are making multiple changes to a network, you must decide whether to make them incrementally (one change at a time and provide small interruptions in service) or all at once. These decisions have a huge impact on an organization, and you should solicit input from users (especially those who are directly affected) and management about how best to accomplish a change.

Change Staging

Change staging focuses on performing changes and testing implementations on systems that are not high-value production assets. This means that a change process should be tested in a lab environment before it is attempted in a production environment. You want to be clear about what must occur, what steps must be taken, and how long it will take to accomplish the change.

Note 

If possible, do your initial implementations away from witnesses. It is better to test new technologies in a manner that protects you from losing credibility with your customers. End users become very nervous when they see an implementer having difficulty with a new process.

Using a test-bed environment or a test lab allows you to perform the more difficult tasks and develop proficiency in them before you work with production systems. This reduces the likelihood of errors or mistakes, and it should lower the actual implementation time. This may not always be possible, but it is a good way to verify your procedures and to reduce risks.

Change Documentation

Change documentation accomplishes several things in the change process. It helps keep track of what changes have occurred, and it also helps implementers remember what was accomplished and why. In a large implementation or change, hundreds or even thousands of changes may be occurring across a network. These changes can become confusing if a crisis develops in the middle of the process. It may become hard to remember which systems have been changed, which systems have not, and which systems developed difficulties.

By documenting changes, you help establish a history and share knowledge about the difficulties and experiences in the change process. Documentation does not have to be any more difficult than keeping records about systems, implementations, and experience. Many smaller companies use a three-ring binder with notes in it about changes that are made to the system. These binders are frequently kept with system logs for fast review.

Note 

Many older systems will have little if any documentation about what was done to them and why. A system review is a great time to investigate these systems and bring documentation up-to-date.

Large change processes may involve formalized documentation methods, databases, and other technologies to help track changes. It is usually best to enter these changes into whatever system is used immediately after you complete a step. You will have to do the paperwork eventually. So why not do it while the facts are still in your mind? In any case, follow the procedures established by your organization for documenting changes. Doing so will save you hours of research later.

Change Notification

One of biggest complaints during change processes is the lack of communication. Make sure that you give end users adequate notice about changes, schedules, and the results of previous changes. This helps reduce anxiety, and it can help establish confidence in the effort and its results. Change notification can be performed using e-mails, newsletters, or any other vehicles that are commonly used in your organization.

Make a special point to notify remote users about changes. It seems to be a universal truth that outlying sites will never get a message until it is too late. The more effectively you inform everyone in an organization, the less likely you are to encounter resistance.

From a public relations perspective, you may want to include success stories and other information that builds credibility about your efforts. If you projected that a change would take an hour and a half and you are averaging an hour per system, this is good news to people who may be expecting your change to actually take two or three hours.

Note 

Communicating changes in the schedule can relieve a great deal of anxiety in any organization.

If possible, develop a master schedule of individuals who have key roles in your organization. Keep this schedule updated and current. An out-of-date schedule, in many respects, is worse than no schedule. Remember that change is hard for everyone involved. The more you communicate about progress, events, and results, the less chance the change process has to become chaotic.

Real world Scenario: Upgrading Your Servers

You need to install a set of updates to your servers and network devices. This process will probably take about an hour per system. Updating some of the servers will only impact departments, while updating others will require bringing down the entire network.

How might you schedule this downtime with your network users?

A great way to do this would be to ask the various major department heads about when outages are possible without totally disrupting their work. You could create a weekly or monthly calendar to graphically display possible times. You would probably want to schedule your major updates late in the day on Fridays. Individual servers could be updated as departments' work schedules allow. Once you have scheduled your outages, you would want to give at least five working days' notice to people in the organization. If you predict an outage to last an hour, inform people that it will be an hour and a half. This way you have a little cushion to deal with the unexpected. Friday afternoon is usually a good choice because most networks see a tremendous drop in usage late in the day on Friday. This also gives you the entire weekend to fix a problem if one develops. While it may impact your work schedule, it will probably impact the organization in a less traumatic way.