Microsoft Word Hardware Reconfiguration Methodology V final2

Technical background

1. Objective

In this section, several important aspects important for operating systems, regardless of the type of system or underlying computer platform are examined. The first aspect presents basic technical information on operating system migrations and reconfigurations. The second presents technical information on operating systems including dependencies and call facilities. Thirdly, compatibility-based issues are briefly examined.

2. Reconfigurations and migrations

1. Background

The most common reason for performing a hardware reconfiguration is to save time and avoid a complete security recertification of the operating system. Rather than install a newer operating system, often considered a daunting task, it may be more appropriate to leverage on the existing operating system with its current configurations and settings.

The Navy has stated that it may not be possible for them to perform full operating system upgrades¹ due to restraints in security, certification, auditing, system and change management as well as overall maintenance. Essentially, the Navy is opting to freeze or “lock out” the operating system with a given configuration for its entire lifetime of between 15 and 25 years. However, it is reasonable to assume that over this period there will be periodic hardware upgrades to the C2 systems. These upgrades may include minor hardware changes or be complete system overhauls.

Generally, outdated operating systems that are not kept at least partially up to date will not fair well in supporting modern hardware. Although the Navy may not be able to switch to a more recent operating system, it can nevertheless benefit from a reconfiguration in so long as the kernel, drivers, and other subsystems are kept to reasonably up to date. Thus, existing applications, preferences, and configurations can be maintained, as can the majority of operating system dependencies and interdependencies, thereby forgoing the necessity for an in-depth recertification of the system before redeployment. Only software that has actually changed would need to be tested and recertified; specifically, the kernel. In large modern operating systems such as Linux, the kernel normally represents less than 1% to 2% of the entire operating system. Furthermore, using modern techniques in static analysis it becomes possible to better assess various vulnerabilities and flaws in the kernel source code [8, 9]. This will help to make a multi- month recertification process last only several weeks, significantly reducing costs and complexities.

¹ By this it is meant going from one version of a Linux distribution to another version of that distribution. An example of this would be going from Red Hat Enterprise Linux (RHEL) 3 to version RHEL 4.

2.