Configuration Management
When we develop software, it
is important to know who is making which changes to what and when:
corrective changes:
maintaining control of the system's day-to-day functions
adaptive changes: maintaining
control over system modifications
perfective changes:
perfecting existing acceptable functions
preventive changes:
preventing system performance from degrading to unacceptable levels
We want some degree of
control over the software changes so that one change does not inadvertently
undo the effect of a previous change. And we want to control what is often a
proliferation of different versions and releases. For instance, a product might
run on several different platforms or in several different environments,
necessitating different code to support the same functionality. Configuration management is the process by which we control changes during
development and maintenance, and it offers several advantages in security. In particular, configuration
management scrutinizes new and changed code to ensure, among other things, that
security flaws have not been inserted, intentionally or accidentally.
Four activities are involved
in configuration management:
configuration identification
configuration control and change management
configuration auditing
status accounting
Configuration identification sets up baselines to which all other code will
be compared after changes are made. That is, we build and document an inventory of all components that comprise the system.
The inventory includes not only the code you and your colleagues may have
created, but also database management systems, third-party software, libraries,
test cases, documents, and more. Then, we "freeze" the baseline and
carefully control what happens to it. When a change is proposed and made, it is
described in terms of how the baseline changes.
Configuration control and configuration
management ensure we can coordinate separate, related versions. For example,
there may be closely related versions of a system to execute on 16-bit and
32-bit processors. Three ways to control the changes are separate files,
deltas, and conditional compilation. If we use separate files, we have
different files for each release or version. For example, we might build an
encryption system in two configurations: one that uses a short key length, to
comply with the law in certain countries, and another that uses a long key.
Then, version 1 may be composed of components A1 through Ak
and B1, while version 2 is A1 through A k and
B2, where B1
and B2 do key length. That is, the
versions are the same except for the separate key processing files.
Alternatively, we can
designate a particular version as the main version of a system and then define
other versions in terms of what is different. The difference file, called a
delta, contains editing commands to describe the ways to transform the main
version into the variation.
Finally, we can do conditional compilation, whereby a
single code component addresses all versions, relying on the compiler to
determine which statements to apply to which versions. This approach seems
appealing for security applications because all the code appears in one place.
However, if the variations are very complex, the code may be very difficult to
read and understand.
Once a configuration management technique is
chosen and applied, the system should be audited regularly. A configuration audit confirms that the
baseline is complete and accurate, that changes are recorded, that recorded
changes are made, and that the actual software (that is, the software as used
in the field) is reflected accurately in the documents. Audits are usually done
by independent parties taking one of two approaches: reviewing every entry in
the baseline and comparing it with the software in use or sampling from a
larger set just to confirm compliance. For systems with strict security
constraints, the first approach is preferable, but the second approach may be
more practical.
Finally, status accounting
records information about the components: where they came from (for instance,
purchased, reused, or written from scratch), the current version, the change
history, and pending change requests.
All four sets of activities
are performed by a configuration and change control board, or CCB. The CCB
contains representatives from all organizations with a vested interest in the
system, perhaps including customers, users, and developers. The board reviews
all proposed changes and approves changes based on need, design integrity,
future plans for the software, cost, and more. The developers implementing and
testing the change work with a program librarian to control and update relevant
documents and components; they also write detailed documentation about the
changes and test results.
Configuration management
offers two advantages to those of us with security concerns: protecting against
unintentional threats and guarding against malicious ones. Both goals are
addressed when the configuration management processes protect the integrity of
programs and documentation. Because changes occur only after explicit approval
from a configuration management authority, all changes are also carefully
evaluated for side effects. With configuration management, previous versions of
programs are archived, so a developer can retract a faulty change when
necessary.
Malicious modification is
made quite difficult with a strong review and configuration management process
in place. In fact, as presented in Sidebar 3-8, poor configuration control has resulted in at least one
system failure; that sidebar also confirms the principle of easiest penetration from Chapter 1. Once a
reviewed program is accepted for inclusion in a system, the developer cannot
sneak in to make small, subtle changes, such as inserting trapdoors. The
developer has access to the running production program only through the CCB,
whose members are alert to such security breaches.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.