Rule of Change

For any organization to remain dynamic and competitive, it must be able to adapt and change with the world around it. For IT professionals, this means a continual flux of upgrading, enhancing, and replacing the technology. This presents several challenges to information security practices.

Concept

The Rule of Change states that change must be managed, coordinated, and considered for possible security implications. Any change within an environment carries with it some form of risk. Installing a new Linux system could introduce a security hole; patching a Windows 2000 server could cause a working application to crash; and, making a change to a firewall could block email from flowing to customers. To make matters worse, every change is prone to having different effects based on the current environment. If experience tells us anything, it's that Patch X working great at home does not mean that Patch X will work great on our critical server!

A great many changes are occurring in a technical environment at any given time: new applications are being installed, routing paths are being modified, software and operating systems are being updated and upgraded. You name it, and it's changing. Every changing component carries the risk of affecting the environment in terms of security, integrity, and availability; and most of the time, this risk is not obvious.

A significant contributing factor to down time in corporate environments is the lack of coordination among system administrators, network administrators, security administrators, and end-users as changes are taking place. Likewise, a great number of security vulnerabilities that appear within the average organization come from unmanaged changes. Everyone is a culprit: the IT administrator installing a new application, the desktop user plugging in the phone line to a new laptop, and the new intern installing video games to play during lunch. It is truly difficult for a human to sit in front of a dynamic device like a computer and resist making some form of major change. Most of these changes seem simple enough, and it is often hard to imagine the global impacts they can have. But changes, if not managed correctly, will eventually become loose bricks in the castle wall. Thus, managing change is key to the security of any organization.

The Guinea Pig Phenomena of Change

Changes should only occur after they have been proven to be safe. Software companies, especially the larger ones, are notorious for releasing products with more things broken than working. Partly credited to the lack of adequate testing requirements and closed source code issues, and partly credited to the extreme difficulty in testing abstract cases, new technical developments are inevitably "buggy." The human mind's desire for newer and better things, combined with our general lack of patience and caution, gives us the impulse to run out and get new products hot off the shelf. I call this the guinea pig phenomena: thousands of people rushing out to get a product, basically paying to be the ultimate testers for the development company.

Introducing any new software or hardware product into an environment comes with some degree of risk. Not only could the new product be unstable, but it could affect the stability of the software, systems, and networks around it. It is important to be aware of this fact before implementing any new objects in your environment.

Issues with Diversity in Change

Changes should be consistent and not introduce a great deal of diversity. Within an organization, the more diverse the technologies, the more difficult it will be to maintain security. If all systems within the organization are either Compaq or Dell, all the routers are Lucent, and all the systems are Windows 2000 or Solaris 2.7, then it will not be difficult to keep up with the various issues and vulnerabilities associated with these products. If, however, managers are allowed to purchase their own equipment, the environment will become very diverse in its technologies. It may prove to be impossible to keep up with the various security patches, hot-fixes, and other issues when such a wide variety of technology is deployed.

Practicing This Rule

Two key words every security manager must know are "change management." Without some form of change management or change control, an organization will be plagued with down time, security breaches, and general confusion. A significant change in any part of a network constitutes a significant change in the network as a whole. Multiple changes at the same time can cause unpredictable issues, and can make troubleshooting impossible. Unauthorized or unreported changes in an environment can bypass all security measures and leave the environment open to the most basic of hackers.

Without change management, there is little hope to maintain security within an organization. There is no security measure that cannot be undone by someone making an unauthorized and unreported change to a server, network, or workstation within the environment. Here are some good guidelines for following the Rule of Change within your organization:

• Implement change control It is essential that organizations implement some form of change control/change management system. I will cover a sample change management process at the end of this section.

• Make the process efficient The success of a change management process is heavily weighted on its ability to function without becoming an impediment. The primary goal of the process should be to document and coordinate changes. If the process is made too cumbersome, no one will follow it. Sometimes, the change management process can be as simple as an assistant compiling all proposed changes into a list reviewed by a good administrator capable of spotting major issues and changes that should not be made together.

• Apply the process universally Nothing should be installed, patched, or significantly modified on a server or device without first following the change management process. In some cases, permission may not even be required and simple documentation of the steps taken might suffice. In such cases, it is simply important that the change management process was observed.

• Scrutinize security changes Changes, upgrades, or modifications to any security filter must also go through the change management process. Decisions should not be left to the technical administrators alone, but rather, they should be made as a group.

• Control desktop changes as well A list of tested and approved applications for desktops should be included in the desktop policy. Any new applications to be installed should first be approved by management and included in this list.

• Remove the guinea pig phenomena As a general rule, do not deploy a product until it has been tested by the first wave of users. Go so far as to make this a written policy: "No new product may be installed within the environment unless it has been distributed in its final form for at least 4 6 months, or unless permission has been granted from a higher source." This should include new operating systems, new applications, and new devices that attach to the network.

• Standardize on a handful of technologies By no means should you lock yourself into one particular vendor or any specific technology; however, it is important to have some limit in the diversity of your environment. This will greatly reduce the number of potential issues and vulnerabilities, while enhancing the organization's ability to keep up with security updates and fixes.

Concerning New Updates

Avoiding the guinea pig phenomena with new products is easy enough; however, sometimes we find ourselves in a tight position regarding new updates. When a new patch is released to fix an annoying problem, we want to install it right away. This begs the question: "Should we install a new patch in light of the risk of change?" A good measurement is to imagine the cost of having to reinstall the entire application and troubleshoot for hours before determining if the patch is worth it. Remember that it is very common for development companies to patch their patches because of errors and incompatibilities. New patches introduce new bugs that need to be patched again until everything functions correctly.

Concerning New Security Updates

Security patches are often the most difficult objects to deal with. There is a direct need for the patch, but otherwise, the system is running fine. We don't want to take a chance of hurting a functional system with a new patch, but at the same time, we do not want to be vulnerable! Again, the decision can be very logical if we consider the nature of the patch and the potential risk of an issue. It is important to understand the extent of the vulnerability being patched and compare that against the cost of disaster (if the system was affected by the patch and had to be rebuilt).

Always remember: For a vulnerability that goes unpatched, it is simply a matter of time before that vulnerability is exploited. Security patches should always be installed unless the risk of applying the patch is higher than the risk of being compromised.

Reflecting on the Rule of Least Privilege

The Rule of Least Privilege says if access is not required or access cannot be handled properly, access should be denied. This holds very true with end-users and administrators making changes within the environment. No group should be given access to make changes if they are not qualified to make them. The word "group" is used here specifically because this must be enforced even when we have some individual end-users who are quite capable of making intelligent system changes.

Professionals are certainly no exception to this rule. Specifically, we should watch what we install and where we install it. If many changes are required, consider building a test network unattached to the main network. Also refer to the discussion on limiting the use of administrator and root accounts later on in Chapter 11, The Rules in Practice.

Six Steps for Implementing a Basic Change Management Process

Here, I have provided a basic change management process. This process is just a guideline to get started. Keep in mind that a change management process should be tailored to the needs of an organization.

1. Write a policy to designate a change management process and the types of changes that fall under it. The rules in this policy should be made mandatory and readily enforced for all engineers and managers.

2. Make a standard schedule of events for common changes and activities that affect the environment:

   Every 11:00 p.m.:	Start system backups for all networks
   Every 2:00 a.m.:	Download latest antivirus update
   Tuesday 5:00 a.m.:	Perform standard security scan

3. Provide a classification for all uncommon types of changes, summarizing the risks they pose to the environment. This list should be tailored to the specific needs of the organization. Here is an example:

   Level 1:	Cosmetic change to a server, router, WAN, or other device
   Level 2:	Functional change to a normal server, router, WAN, or other device
   Level 3:	Functional change to a critical server, router, WAN, or other device, or change that affects multiple devices

4. Provide a classification for all types of changes being made using a scale of criticality. The assigned value should designate how urgent a change is.

   Normal:	These are the average IT changes that could wait several days to be performed. Most changes fall into this category.
   High:	These are urgent changes that should be performed within 24 hours. Changes like this include patches, updates, and configuration changes that would be highly beneficial to the organization if performed quickly.
   Critical:	These are extremely urgent changes that should be performed immediately on approval. This category covers urgent security patches and updates that are required to avoid pending issues.

5. An approval system should be put in place by which engineers and managers must announce changes they plan to make. For changes of a significant level, approval must be received from the individual or group in charge of coordinating changes. At a minimum, the following information should be submitted for approval:

   • Basic details of the change being made

   • The levels of risk and criticality for the type of change

   • A scheduled time and date for the change to occur

   • Contact information for the individual making the change and the individual who approved the change

6. An updated list of approved changes should be made available to engineers and managers. If there is ever an issue during normal daily activities, this list should be reviewed to see if any scheduled changes could be at fault. Suspicious events should also be compared to this list to see if there is any correlation.