18
Secure Software Installation and Deployment
In this chapter you will
• Explore the fundamental principles of software installation and deployment
• Learn basic terminology associated with deploying and installing software
• Discover how software installations are managed and controlled
• Examine the fundamentals of configuration and baseline management
• Explore the post-release period of the lifecycle
The overall goal of the software installation and deployment phase is to ensure that the system is embedded in the customer’s existing systems in an approved state of correctness and that the necessary strategic planning is done to ensure that it is operationally effective. In effect, installation and deployment are part of a short, practical, transitionary phase of the lifecycle. Nevertheless, because they set the tone for operational use, the activities that are initiated in this phase have long-term implications for the overall success of the system.
The purpose of the installation and deployment process is to embed a product that meets the agreed-upon requirements of the customer into the target environment. In order to execute this process effectively, it is necessary to develop a software installation strategy and criteria for installation. These criteria must allow the stakeholders in the system, normally the customer and supplier, to demonstrate compliance with the software installation requirements specified in the contract. The product is then installed in the target environment and deployed for use. Its readiness for use in its intended environment is assured by tests and reviews. This is all done based on a plan that the stakeholders have prepared in advance of the installation and deployment activity. As we said, this plan is usually stipulated in the overall contract. In this plan, the developer specifies all of the key information and resources that will be required to ensure proper installation. That specification then ensures that critical resources are available when needed.
Generally, and this is almost always an artifact of the contract, the developer is required to assist the acquirer with installation setup. In addition, where the installation replaces an existing system, the contract might require the developer to support any parallel activities or the overall business process. The developer then installs and deploys the product in conformance with the installation plan. Any and all contract provisions that the software code and databases initialize, execute, and terminate as specified are established and accepted by the acquiring organization as confirmed, and this installation plan is documented, as are the installation events.
Secure Software Installation and Its Subsequent Deployment
The software installation and deployment function is not, strictly speaking, part of the development lifecycle. In concept, the lifecycle is broken into two separate phases: development and sustainment. The installation and deployment functions are two of the processes in the latter category, along with operations and maintenance, which are discussed in the next chapter. The installation and deployment processes describe activities and tasks that could be carried out by the acquirer, the supplier, or the developer roles, or any combination of those roles working in cooperation with each other.
Like most processes, installation and deployment are initiated by a plan. The managers of these activities need to develop a plan and establish installation and deployment policies and procedures. These documents specify the activities and tasks of the installation and deployments process. The plan is then executed as a set of real-world actions that constitute standard operating procedure for that particular installation. In its particulars, the installation and deployment plan ought to document a tangible set of regular activities that the planners consider to be the most effective means of ensuring a correct and proper set of installation and deployment practices.
In addition to the planned installation and deployment activities, the installation and deployment plan ought to incorporate a mechanism for obtaining real-time performance data for the purposes of process management and further improvement. Thus, management needs to include a mechanism for receiving, tracking, and resolving problem reports. Logically, problems in the installation and deployment process ought to be resolved when they are encountered in order to ensure that the product will be ready for release. Therefore, there has to be some type of formal documentation and resolution process to ensure that the final product is as free of problems as is reasonably possible. In practice, this process is usually called “change management.” In order to ensure effective control over all meaningful changes, any problem information ought to be routed to the organization’s designated decision makers for authorization of the selected resolution.
Installation Validation and Verification
In order to ensure the effectiveness of the installation, there should be a formal process to evaluate whether the deployment and installation of the product were correctly executed and remain useful. Thus, the organization has to establish procedures for testing and verifying the installed product within the actual environment that it is deployed in and for releasing the product for use.
Because the product has normally been passed to the customer for installation, it is that role that is responsible for carrying out all of the tests and reviews that are required to support product release. Thus, upon satisfying whatever testing criteria are specified in the installation plan, the customer’s decision makers are typically the people empowered to promote the product to operational status. In order to approve any release of a product, decision makers must confirm that all stipulated installation and deployment criteria, including the correctness of the code and the accuracy of the database, conform to the criteria that are laid out in the installation and deployment plan.
Upon satisfying those specified criteria, the customer organization’s decision makers then authorize the product for operational use. The assessments that support that decision include evaluations of the code in order to ensure that it is free of known defects. That examination can be supported by such useful references as MITRE’s Common Weakness Enumeration (CWE). The aim is to ensure that the software performs the specific functions that are described in the deployment and installation plan.
Finally, once the product under question has been approved for release, there must be a formal plan to guide the changeover process. The reason why such a plan is necessary is that more often than not, the new system is replacing an existing system that performs the exact same function. If that is the case, the timing and degree of concurrent operation must be clearly defined and the specific steps to phase out the existing system and phase in the new one have to be specified in order to ensure continuing conformance to stakeholder needs.
Planning for Operational Use
Once the system has been brought to operational status in the installation phase, there have to be plans in place to ensure that it is operating as intended once it is deployed. There is a statement of policies and procedures to ensure that the newly installed product is operating in the way it was intended and that its outcomes satisfy all contractual expectations. That goal is normally satisfied by a wide-ranging and continuous review process, which provides the necessary assurance.
Several givens need to be recognized in order to ensure the maintenance of an effective operational-use phase. First, the monitoring and reporting responsibility for the newly installed system has to be plugged into the formal management system of the organization. This connection does not just automatically take place with the launch of a new system. Instead, the management roles and responsibilities for monitoring and control have to be assigned and accountability enforced.
There are a few simple guidelines for making that assignment. Typically, that includes making certain that the people responsible for the operational testing and review activity are not directly accountable to the management team for the product itself, but that all review and test results are fed directly into the decisions of the organization’s management process. In that respect then, there should be no more than one position between the operational monitoring process and senior management.
Second, the operational monitoring and control that is implemented in the installation and deployment phase must be based on an explicit enforcement mechanism, which has been put in place to ensure that any and all operational policies and procedures are being followed. That enforcement is usually carried out by the configuration management process. A formal conflict resolution process, called “problem resolution,” is installed to ensure that all issues that are encountered in the operation of the product are dealt with in a fashion that will ensure continuing operational integrity.
Finally, the basic activities in the installation and deployment process are different from those of actual development work. Therefore, to ensure competent execution of the deployment and installation process, professionals who have a specific installation and sustainment perspective ought to be assigned to do the practical work. That includes such routine functions as participation in the development of sustainment plans and the ability to review test results in order to determine whether those plans have been adhered to. In cases where operational actions have been found to not adhere to formal sustainment plans, the professionals who are doing those reviews and tests have the ability to register effective nonconcurrences.
Where appropriate, the monitoring of operational-use activities takes place against defined criteria. Evaluating whether an installation has met those criteria requires the organization to develop a mechanism for judging proper use. Then, using that mechanism, it is possible for the organization to ensure strict compliance with the agreed-upon criteria for a proper operation. Moreover, each successive release of the product can then be judged against the same criteria, which will ensure the maintenance of continuous alignment between the product and the organization’s overall goals and standards for effectiveness.
Customer Support
The installation and deployment phase is the transitionary stage between development and long-term use. Therefore, besides providing the necessary assurance of product correctness, the installation and deployment phase is also the point where the necessary activities are defined to support the end users of the product. Each user request for support and the subsequent actions that are taken to resolve them must be carefully controlled, recorded, and maintained as part of the customer support process.
The people in the organization who are responsible for customer support, and who may also fulfill the role of configuration manager, ought to be the sole recipients of customer requests. These people then distribute those requests to the appropriate parties for action or resolution. According to best practice, any actions that have permanent effects on system operation, including the installation and deployment of new releases, have to be performed by the system’s technical staff. However, it is the customer-use process that is responsible for ensuring effective interactions between the originators of the request and its eventual resolution.
Therefore, because this part of customer support involves the reception of support or change requests from the user community, the customer support function that is part of installation and deployment also has to utilize a formal process to forward user requests to the organizational elements who will handle them. In order to ensure two-way communication, once a user request has been analyzed and a resolution decided on, that resolution and its eventual outcomes are reported to the originators of the request. All resolutions are then monitored to their final conclusion by the customer support process. It should be clear at this point that the formal configuration management process underwrites customer support. Because of the fundamental relationship between the customer and the rational management of the configuration, there is an explicit requirement that any user requests must be monitored to their conclusion by customer support. In that respect, another role of customer support is to obtain an “official” sign-off to assure that the user’s request has been satisfied. Sometimes, because of the realities of everyday business operation, temporary workarounds might be created to address a problem. These are usually intended to furnish a short-term solution for the user while a long-term fix is being made. If that is the case, however, it is a best practice to allow the originator of the customer support request to choose whether to employ that proposed workaround while the long-term problem is being addressed, or to adopt other measures. To summarize, customer support is the function that is responsible for ensuring that the customer’s decision is documented and properly implemented.
Also, customer support best practices always provide some form of day-to-day technical assistance and consultation to the users. That usually includes such activities as the provision of training, documentation, and other support services that ensure the effective use of the product. Customer support is generally provided as requested, but some forms can be provided as a result of higher-level organizational planning, such as the case where scheduled training might be provided for an entire unit. All requests for support that originate with the user community and any subsequent responses have to be recorded and monitored for successful completion.
Bootstrapping
Bootstrapping is a term that has been part of computing since at least 1953. In its earliest sense, the term referred to a set of instructions that were set to automatically initiate the execution or loading of a program into computer memory. Since those instructions, in effect, launch the intended program, they essentially “pull” the program up by its “bootstraps,” which is a 19th-century metaphor for actions that take place without external help. Over time, this metaphor has been extended to apply to any type of function that ensures self-sustaining operation. Thus, the application of the bootstrapping principle to the deployment of any product or process implies a set of operations that will both properly launch the function and ensure its continuing correctness.
With regard to the technical aspects of the deployment of a software product, bootstrapping tends to entail any one-shot process that ensures the correctness of the initial configuration. That includes setting the proper defaults and execution parameters, as well as ensuring the accuracy and correctness of the security features in the operational product. Examples of this would be the configuration of the reference monitor settings in the operating system to ensure the desired level of access control and the definition of privacy, security, and public key infrastructure management settings to ensure effective protection of information.
 | EXAM TIP The term bootstrapping is also known as booting. For a PC, typical boot processes are the power on self-test (POST) followed by the initial program load (IPL). Integrity of these processes must be mandatory, or all subsequent processes on the machine cannot be trusted. |
In the case of the overall use of the product, bootstrapping involves the definition and deployment of policies, rules, and practices to ensure that the operational-use process is effective and will always remain effective. That could include the implementation of internal review and inspection processes to gather meaningful data about product performance. In conjunction with that activity, it would also include steps to provide course correction information to ensure management responsiveness, as well as error correction and self-correcting features that would operate within the product itself to ensure its integrity. In the most practical sense, implementing error detection and correction into overall product will provide a much more secure and effective product.
Secure Startup
Secure startup refers to the entire collection of processes, from the turning on of the power until the operating system is in complete control of the system. The use of the Trusted Platform Module (TPM) chip enables a significant hardening of startup parameters from tampering or compromise. A TPM chip can provide secure storage of cryptographic keys and other security elements, enabling a level of assurance of correctness upon entering the operational mode after startup. The keys stored on the TPM can be restricted to the machine itself and can be used to validate keys needed to securely encrypt hard drives, identify personnel, and manage secure communications.
Configuration Management
The set of practices that describe how an organization controls its software assets is generally considered to fall under the generic heading of “configuration management.” That has been the case since the U.S. Department of Defense coined the term in the 1950s to apply to hardware configurations. Configuration management is a formal process that is followed to ensure coherent management control over the intangible assets of an organization. In that respect, configuration management enables management of all of the software assets and software-related processes of the organization.
Configuration management’s specific function is to exercise rational control over changes to software and related artifacts during development and after release. In the literal sense, then, software configuration management (SCM) is not a strictly deployment-centered concern. Instead, it is an essential technique that is used to monitor and control the development and sustainment of all forms of software. Thus, SCM functions independently of the type of project or product. SCM dictates the steps necessary to monitor the process and reduce errors and costs in product development and sustainment, and it applies throughout the complete lifecycle of the product
In concept, configuration management refers to the “organization and maintenance of software objects.” Its main purpose is to try to control the changes that are made to the software. This control is exercised in a manner intended to preserve the integrity of the system. Configuration management offers two primary advantages for the organization. First, SCM ensures the integrity of all configuration items. Second, SCM permits the rational evaluation and performance of changes to the product and process. SCM also provides the organization’s decision makers with visibility into the development and sustainment processes and allows them direct input into the process of determining how the company’s software assets should evolve. Configuration management does this by providing the analysis and decision support necessary to let decision makers make concrete decisions about the form of the product. By generating real visibility into the product and process, configuration management provides the ability to measure its security and quality, as well as control its overall development and sustainment process. This visibility and control makes testing and assurance easier, removes errors from the product’s deployment and subsequent management, provides traceability of related components, and dramatically eases the problems of change management and problem tracking.
Configuration management requires the involvement of three major stages in the overall software lifecycle. First, SCM involves the development process. Development is the stage that implements the identification and baselining requirements of the SCM process. SCM also involves the sustainment process. In sustainment, ongoing operational problems and enhancements are addressed through formal reporting, analysis, and authorization. All of these functions assure sufficient management control over the evolution of the software to ensure its status at all times. Finally, SCM involves the assurance process. Assurance maintains product integrity over time. It is supported by an appropriate and meaningful set of verification and validation activities. The latter two conventional functions, sustainment and assurance, are the cornerstones of the overall SCM process in that they assure that the configuration of the product is always accurate at any given point in the process.
Organizing the Configuration Management Process
Configuration management involves three separate roles. The customer role is responsible for the maintenance of the product after release. The supplier role is responsible for managing the configuration of the product prior to release, and any associated subcontractor role is involved in the process if the product is developed through a supply chain. The supplier is the entity that maintains the product throughout the development lifecycle, so it is the supplier organization that writes the configuration management plan. However, in order to maintain continuity with the customer, the configuration plan is written in conjunction with managers from that organization.
Joint creation of the plan ensures that all configuration management responsibilities are fully understood and properly defined and maintained throughout both organizations. From an implementation standpoint, the producer appoints specific overseers who have been given explicit responsibility for ensuring that the requirements of the plan are carried out throughout the development process. Those individuals are usually called configuration managers. Besides controlling the configuration during development, the supplier must also be able to assure the security and quality characteristics of the product. This is achieved by conducting audits, which are carried out independently of the activity of the development team.
The customer assigns a representative to the configuration management process during development. This individual should have sufficient authority to be able to resolve any configuration control issues that might arise between the producer and the customer. The customer’s representative is responsible for approving change proposals and concluding agreements about the shape of the configuration as it evolves. The customer representative is also responsible for ensuring the transition between the configuration under development and the management of the eventual product that will be handed to the customer organization. The supplier organization is responsible, through the configuration manager, for ensuring the full understanding and participation of any subcontractor organizations in the maintenance of proper configuration control. All aspects of the producer’s agreement with the customer generally apply to the subcontractor and are included in the configuration management plan.
Configuration management incorporates two large processes: 1) configuration control and 2) verification control. These are implemented through three interdependent management entities. In actual practice, the activities of these three entities must fit the individual needs of each project. These activities are: 1) change process management, which is made up of change authorization, verification control, and release processing; 2) baseline control, which is composed of change accounting and library management; and 3) configuration verification, which includes status accounting to verify compliance with specifications.
Configuration Management Roles
Each of the management entities carries out a discrete part of the process. Based on the size of the project, the actual work can be done by an individual manager or management team. The configuration manager ensures that all of the fundamental requirements of change management are carried out. The configuration manager’s general role in this process is to receive and document all software change requests, manage all software change authorizations, and verify that the change is complete. The organization also appoints a baseline manager to assure the integrity of all configuration baselines. This manager is responsible for ensuring that all configuration items that are part of the project configuration management plan are identified, accounted for, and maintained consistently with an explicit identification scheme. This individual establishes a baseline management ledger (BML) for each controlled product and records all changes and promotions and maintains all libraries associated with that product.
Baseline Management
The baseline manager accounts for all of the configuration items in every baseline. To do this job successfully, the baseline manager, together with any relevant development personnel, establishes and maintains a baseline management ledger. This ledger documents and accounts for the complete set of software configuration items in the current baseline of each controlled product. That documentation includes the configuration item (CI) descriptor label, the promotion/version level, and any associated change activity. Since items not in the ledger are, by definition, not controlled, the baseline manager is also responsible for keeping the ledger up-to-date. The baseline manager maintains an accounting of the baseline that sufficiently reflects the current state of all configurations of the product, and the baseline manager is responsible for the authorization of entries into the BML.
Change Assurance
The verification manager is responsible for assuring that product integrity is maintained throughout the change process. The general role of the verification manager is to confirm that items in the BML conform to the identification scheme, verify that changes have been carried out, and conduct milestone reviews. The verification manager also maintains documentation of all reviews. The verification manager must guarantee that items maintained in the BML reflect the true status of the product at any given point in time.
The Configuration Management Plan
The configuration management process is established through a formal configuration management plan. At a minimum, this plan should specify the change management, baseline management, and verification management roles, as well as the methods for establishing and maintaining the configuration identification scheme. The organization’s commitment to carrying out this plan must be rigorously enforced throughout the lifecycle of the product.
In addition to the process, there should be a detailed specification of how the basic structure of the product identification number (PIN) will be set up and maintained, including the exact format of the PIN. In addition, the composition and roles of the configuration control boards should be formally assigned, and each board ought to have its authority, scope, and responsibility for decision making defined. The means for monitoring baselines and new releases ought to be created. In addition, the mechanism for ensuring the provision of timely information to managers in support of the authorization function has to be established. Finally, the approach to verifying and validating changes must be defined, and the rules for maintaining the dynamic, controlled, and static libraries must be itemized in the plan.
The Configuration Management Process
The purpose of the software configuration management process is to establish and maintain the integrity of the software items of a process or project and make them available to concerned parties. Configuration management does this by developing a coherent software configuration management strategy and by identifying the controlled items and putting them in a baseline.
The configuration management process is composed of six major activities: 1) process implementation, 2) configuration identification, 3) configuration control, 4) configuration status accounting, 5) configuration evaluation, and 6) release management and delivery. Configuration management is founded on a concrete identification scheme that identifies, defines, and formulates the baseline, which is composed of the configuration items that make up a system, software product, or service.
The configuration identification scheme is the foundation of the configuration management process. Therefore, a proper and thorough identification and labeling of all elements of the configuration is a prerequisite for conducting the configuration management process. The configuration identification scheme is critical because it sets up the “day one” baseline. The identification of configuration items is usually done during the requirements analysis phase of the specification process. All of the discrete elements of the specification are identified and uniquely labeled. These elements are then arrayed in a baseline scheme based on their interrelationships and dependencies. The scheme represents the basic structure, or configuration, of the software. It must be noted that the decisions that determine the shape of the elements themselves are made outside configuration management, usually in development. Nevertheless, once a distinct element has been added to the product, it becomes part of the formal baseline and that baseline becomes the structure that is maintained by the configuration management process.
Once established, the baseline is maintained throughout the lifecycle. Items defined at any level of abstraction within that baseline must be given unique and appropriate labels, which are typically referred to as product identification numbers (PINs). Generally, the numbering of PINs is associated with the item’s placement in the structure itself. Thus, PINs can be used to designate and relate the position of any given item in the overall “family tree” of the product. Change occurs when new baselines are created through the promotion or release of a baseline. If the items in the evolving structure represent a new configuration of the product, the PINs are modified to reflect that changed configuration.
In order to ensure proper management control, the management level authorized to approve change for each baseline must be explicitly defined. Authorization is always given at the highest practical level in the organization. It is assumed that as the software product evolves, it will be necessary to increase the level of authority required to authorize a change. Nonetheless, changes that are authorized at any level in the baseline structure must be maintained at all levels.
The changed status of the items is formally recorded and reported from the baseline. Using that baseline as a point of reference, all modifications and changes to the software product are controlled and made available to all appropriate parties. The specific aim of change control is to ensure the completeness, consistency, and correctness of each of the items in every one of the formal baselines. Consequently, once the software configuration management process has been established, it controls each modification and release of any baseline item. SCM records and reports on the status of each of these items, and it maintains a record of the modification or change requests that have been submitted for each configuration item that is maintained in the baseline management ledger.
| | EXAM TIP A common way of keeping track of changes is through a configuration management database (CMDB). A CMDB contains details of the configuration and all subsequent changes in an organization. Another, more generic term is the configuration management system (CMS). Entities seeking ISO/IEC 15408 (Common Criteria) accreditation are expected to maintain a comprehensive CMS. |
Software configuration management ensures the integrity of product baselines throughout the lifecycle through the operations and maintenance processes. Because change often requires the activities of the development lifecycle—for instance, design and coding—the development process might be involved as well. In addition, configuration management is administered as an organizational function, no different from other, more conventional functions, such as finance or project management. Finally, the generic configuration management process has to be tailored to fit the actual environment and requirements of a given situation. The specific approach to that tailoring is usually specified in the configuration management plan.
A control entity called a configuration control board (CCB) authorizes changes to baselines at defined levels of authority. CCBs are hierarchical and are composed of managers with sufficient authority to direct the change process. At a minimum, the organization has three control boards. The board with the highest authority is composed of top-level policy makers. Then there is a control board for each of the product’s major components: software and hardware. Each board is composed of members who are appropriate decision makers for each component and at the right level of authority to oversee the decision process for that area. This rule also implies that it is generally not good practice for conventional managers to be placed on technical boards and for programmers to serve on top-level CCBs. The scope of each of the board’s oversight must be formally and explicitly defined, usually in the general configuration management plan.
Configuration Management Process Implementation
The software configuration management process is a major strategic activity of the organization. Therefore, a formal strategic plan has to be written to guide the conduct of the process. The plan itself describes the specific configuration management activities and the procedures and schedule that will be adopted to perform configuration management activities and tasks, as well as the units that will be responsible for performing each activity that is specified in the plan and that unit’s relationship to all other parts of the organization.
The software configuration management plan enumerates, in clear and unambiguous terms, the generic activities that will comprise the configuration management process for that particular organization. That enumeration includes a specification of the procedures for performing any configuration management activity or task that has been delegated to any entity or role, both inside and outside the organization. This specification of procedures will apply to an internal unit—for instance, development or maintenance—or an external entity—for example, subcontractors. Because of its importance in determining the course of the day-to-day operation, that plan is also maintained under configuration management. The end product of this stage is a complete, correct, and fully documented plan for the entire lifecycle of the configuration management process.
Configuration Identification
The next step in the process involves setting up the identification scheme. In this step, a formal approach is established that will accurately identify the software items that comprise the baselines, as well as the versions of those baselines that will be controlled for the project. Then the formal documentation that establishes the baseline and the version designations and other identification details are defined for each software item and its versions. This documentation must embody all of the configuration items that make up the software into a coherent baseline configuration. That configuration must be kept for every official version of the system, software product, or even contracted service. These baselined versions are then controlled for the lifecycle of the product.
Configuration Control
Configuration control is the element of the configuration management process that is most visible to the end users. It is also the part of the process that has the biggest payoff for the members of the organization. Configuration control is the fundamental core of configuration management because, as the name implies, configuration control manages change. Configuration control receives all requests to fix or enhance the product. It then analyzes and evaluates the impact(s) of those proposed changes and passes that analysis along to the appropriate decision maker, who will either approve or disapprove the request.
Following confirmation that the change request is proper, a review is conducted by the appropriate entities that have been designated in the configuration management plan. Because the delay in fixing a problem can be costly, these reviews must be done in a timely fashion. Then at the time of the authorization of the review, the person responsible for overseeing the configuration management process provides a map of all of the interfaces between items that have been proposed for change, as well as an analysis of anticipated impacts. This analysis is accompanied by a resource analysis. Using this information, the appropriate entity, which is usually the designated configuration control board, either authorizes the change or denies it. If authorization is given, the configuration manager will pass the documentation necessary to perform the change to the appropriate change agent. In most cases, this is development. However, that is not always the case. The change agent then modifies, verifies, and incorporates the modified software item into a new controlled baseline. The verification function then performs the necessary reviews and tests to confirm correctness and then releases the modified software item for normal use in the organization. The software problem resolution management process provides support for this final activity.
Configuration control also establishes an audit trail that can be used to track each modification. Configuration management employs audits, which are normally conducted on the baseline management ledger, to record and track the justification and authorizing body for each change. Audit information includes the reason for the modification and who authorized it. The purpose of this latter step is to ensure that accountability is assigned for the modification. In particular, configuration control ensures that all accesses to software items that entail any kind of safety or security concern are controlled by audit. Finally, configuration management controls and audits access to the controlled libraries. The controlled libraries contain the officially authorized developmental or release baselines.
Configuration Status Accounting
Configuration management is also responsible for keeping track of all baseline configurations and maintaining an associated recording function that indicates the status and history of each baseline item. In that respect, configuration status accounting records and prepares reports that show the status and history of controlled software items, including baselines. Status reports normally include the number of changes for a project, latest software item versions, release identifiers, the number of releases, and comparisons of releases.
Configuration Evaluation
Evaluation for the purpose of certifying correctness is an important function in the configuration management process. This evaluation normally takes place at the conclusion of a change that has been executed by another unit, such as maintenance or development. At a minimum, the functional completeness of the software items is verified against their requirements, and the physical completeness of the software items is inspected and ensured by the verification process. The criteria for evaluating the correctness of those features typically include whether the design can be confirmed to reflect an up-to-date description of the product and that the code is acceptable. These requirements are normally communicated to the verification function through a statement of work (SOW) that has been authorized by a suitable body—for instance, the CCB—and prepared by the configuration manager.
Release Management
In practice, the release and delivery of software products and documentation have to be formally controlled. As a result, master copies of code and documentation are maintained for the life of the software product. Configuration management controls the release and delivery of modifications through the library function. In particular, the code and documentation that contain critical safety or security functions are handled, stored, packaged, and delivered in accordance with the policies of the organizations involved.
Because they represent a significant investment in time and resources, all releases of a product should be kept under some form of management control. That control is particularly important as the software industry becomes more global and its products are more frequently integrated from parts that come from a widely distributed supply chain. Release management ensures the inherent correctness of software products or updates.
Release management is a control function that is designed to ensure the integrity of the baselines of a given product. That security is normally enforced through repositories that keep a tightly controlled representation of the current baseline. Because it is possible to get multiple, and even conflicting, versions of the product by giving the organization’s programmers uncontrolled access to repositories, there is a need for a formal system to ensure the integrity of the various software development, testing, deployment, and support activities.
Release management addresses the need to maintain confidence in the integrity of the product. An appointed manager controls check-in and check-out of any baselines that are part of the controlled library and takes responsibility for any changes that are made. This manager is, in essence, an architect who helps manage the release of code.
Normally, there are always three separate repositories for each product baseline. These are the “controlled” repository, the “dynamic” repository, and the “archive” repository. The controlled repository contains the current, official, authorized version of each product baseline. This repository is the bank vault for baselines, and, therefore, it is kept under strict management control. Any access to a baseline in these repositories must be approved as part of the configuration management authorization process.
However, once authorization is given, the current baseline can be checked out of the controlled repository and moved into free programming space. That space is termed a “dynamic” library, but in essence that term simply designates that the version that is contained there is not trusted to be correct. Dynamic repositories are necessary to allow programmers to do the experimentation needed to provide an acceptable and proper change. Since the items in a dynamic repository are, by definition, untrusted, they must be fully inspected and tested in order to be reintegrated into the controlled repository. Once the baseline in the dynamic repository has been fully verified and validated and a sign-off given from the authorizing agent, it is moved back into the controlled library as the new current version of the product. Alternatively, the new item might be given a different version label and will not replace a concurrent version of the same product. That decision strictly rests on business factors.
| | EXAM TIP The term version control is commonly used in the security industry to refer to the process of labeling different releases of software such that the end user has the ability to determine which specific release they are using. Version control is the means by which operations can manage their software deployments to specific configurations. |
A current baseline that has been replaced by a newer authorized version is moved to the archive repository. Archives do not simply hold dead versions. Instead, the versions in an archive provide a wealth of assurance data for the organization. In many respects, archive baselines are the collective memory of the IT function, and they can be consulted for guidance about a wide range of issues confronting the organization. Therefore, the archive is maintained at the same level of strict management control as the controlled repository. An archive manager is typically appointed to exercise this control. That manager is often a member of the organization’s quality assurance team, as it is common for quality assurance professionals to utilize the data that exists in that repository.
Chapter Review
This chapter began with an examination of the installation and deployment issues. Installation and deployment activities are implemented by plans, which can be used to document best practices. Validation assesses the product in order to ensure that it complies with its purpose, and this information is used to drive all deployment processes. Customers can carry out the installation tasks with the help of the software supplier, using formal plans to guide the changeover from supplier to customer.
Proper configuration is necessary to ensure a secure deployment of functionality and to ensure that the product is appropriately configured to meet the necessary operational requirements. Security begins at boot and continues through the boot process up to the point of logging in to the operation system. Protecting the initial startup processes is done through the integration of elements such as the TPM chip.
Ensuring that the software is properly deployed is the key function of the configuration management system (CMS). Configuration management is more than a series of technical steps; it is a management process designed to enable control over software deployments.
Software configuration management (SCM) ensures rational control over software evolution. SCM comprises three roles: configuration manager, baseline manager, and quality assurance. Disciplined installation practices must be followed in order to ensure proper deployment of the software.
The chapter concluded with release management, a set of processes designed to ensure the orderly updating of software across an enterprise and tracking of versions. Version control is a library database–enabled activity that can function to assist in identifying specifically which versions of software are deployed.
Quick Tips
• Keep in mind that installation is not necessarily a part of the product development lifecycle, so plans for installation and deployment should be developed to ensure a smooth transition from development to use.
• Customer support requests need to be coordinated by a single entity. This entity is normally called a configuration manager.
• Installation and deployment activities that involve the supplier should be planned as early as possible in order to be written into the contract. This is the only way they can be enforced.
• The interface between the user community and the configuration management process is a critical point of failure, so the establishment of a configuration manager is a critical role.
• Audits are essential to the configuration management process because they confirm that the process continues to be effective.
• Baselines and baseline managers are also critical elements of the configuration management process. Without a good baseline, it is impossible to know the current status.
• All changes have to be verified for correctness prior to reintegrating the changed code into the current controlled baseline.
• The archive of former controlled baselines provides a wealth of quality and security assurance information. Therefore, it has to be kept safe from tampering.
• Configuration management decisions can be strategic. Therefore, upper-level management has to be involved in the decision-making process where a major change is concerned.
• Besides being planned, configuration management should also be managed in a disciplined fashion. Simply planning the process does not guarantee its proper execution.
• Configuration management decisions need to be driven by in-depth analysis. Therefore, the analyst role is not trivial. Analysts must be able to communicate with top-level decision makers.
• Installation and deployment are significant stages in the lifecycle, even if they are relatively short periods. Therefore, the installation and deployment process should be planned.
Questions
To further help you prepare for the CSSLP exam, and to provide you with a feel for your level of preparedness, answer the following questions and then check your answers against the list of correct answers found at the end of the chapter.
1. Installation criteria are used to judge:
A. Effectiveness
B. Correctness
C. Usability
D. Reliability
2. It is important to test the product:
A. Thoroughly
B. Correctly
C. When the design is approved
D. Within its environment
3. Part of customer management is:
A. Reception of change requests
B. Marketing and sales
C. Human resources management
D. Billing and collecting
4. Configuration management exercises:
A. Rational control over the code
B. Rational control over the design
C. Rational control over the change process
D. Enforcement of the change process
5. Configuration management processes should be:
A. Unobtrusive
B. Simple
C. Planned
D. Constrained
6. Configuration management functions independently of:
A. The process
B. The project
C. The other elements
D. Security
7. Bootstrapping involves deployment of processes to:
A. Maintain confidentiality, integrity, and authentication
B. Maintain certificates, integrity, and availability
C. Maintain confidentiality, inspection, and authentication
D. Operational-use effectiveness
8. Configuration management originally only applied to:
A. Top secret projects
B. Hardware
C. Software
D. Systems
9. Bootstrapping ensures:
A. Continuing use
B. A fast start
C. Continuing correctness
D. Continuing control
10. Prior to authorization, the control board gets a mapping of:
A. Impacts and resources
B. Design effectiveness
C. Code requirements
D. Project management features
11. The baseline is maintained throughout:
A. The project
B. The process
C. The lifecycle
D. The year
12. The management level authorized to approve changes must be:
A. As high as possible
B. As simple as possible
C. Clearly defined
D. Approved
13. PINs designate the configuration item’s:
A. Priority
B. Importance to the process
C. Level of required integrity
D. Placement in the product hierarchy
14. The repository where the current baseline is preserved is called the:
A. Controlled repository
B. Dynamic repository
C. Archive repository
D. Master Repository
15. The archive repository represents:
A. Old, useless artifacts
B. The collective memory of the IT function
C. Safe storage for new things
D. A controlled environment to preserve the current baseline
Answers
1. B. Correctness. Installations must be judged correct.
2. D. The product has to be proved correct within its operating environment.
3. A. Reception of requests for change from the customer is a critical function.
4. C. Configuration management ensures rational change.
5. C. Configuration management must be planned.
6. B. Configuration management functions independently of project work.
7. D. Bootstrapping ensures operational-use effectiveness.
8. B. Hardware in the 1950s.
9. C. Bootstrapping ensures continuing operational correctness.
10. A. The control board gets a mapping of impacts and resources.
11. C. Baselines are approved for the lifecycle.
12. C. Management approval must be clearly defined.
13. D. PINs designate placement in the hierarchy.
14. A. Controlled repository.
15. B. All prior baselines represent collective memory of past configurations.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.