Rating Maintenance Phase Program
NCSC-TG-013-89 
Library No. S-232,468 
Version - 1 
FOREWORD
The National Computer Security Center has established an aggressive program to study and implement computer security technology, and to encourage the widespread availability of trusted computer products for use by any organization desiring better protection of their important data. The Trusted Product Evaluation Program, and the open and cooperative business relationship being forged with the computer and telecommunications industries, will result in the fulfillment of our country's computer security requirement. We are resolved to meet the challenge of identifying trusted computer products suitable for use in protecting information. 
"Rating Maintenance Phase Program Document" is the latest in the series of technical guidelines published by the National Computer Security Center. The Rating Maintenance Phase (RAMP) of the Trusted Product Evaluation Program provides for the maintenance of computer security ratings across product revisions. This document describes RAMP for current and prospective vendors of trusted systems. The primary objectives are to provide formal statements of program requirements and to provide guidance on addressing them. 
As the Director, National Computer Security Center, I invite your recommendations for revising this technical guideline. We plan to review this document as the need arises. 
________________ 
Patrick R. Gallagher, Jr. 
23 June 1989 
Director, National Computer Security Center 
ACKNOWLEDGMENTS
The National Computer Security Center extends special recognition and acknowledgment to Tommy Hammer, Ph.D., as principal author of this document and to LT Patricia R. Toth (USN) as project manager for the publication of this document. 
We wish to thank the following for their contributions in developing the concepts and procedures of rating maintenance characterized by this document: Blaine Burnham, Ph.D., David M. Chizmadia, Donald Crossman, Major Doug Hardie, Howard Israel, Shawn P. O'Brien, Michael J. Oehler, Mary D. Schanken, Dana Nell Stigdon, John W. Taylor, and W. Stan Wisseman. 
1. OVERVIEW OF THE RATING MAINTENANCE PHASE 
1.1 BACKGROUND AND CHARACTERISTICS OF RAMP
The National Computer Security Center (the Center) evaluates commercially marketed products against the Department of Defense Trusted Computer System Evaluation Criteria (TCSEC) classes D through A1. Each evaluation by the Center yields a TCSEC class designation, or rating, for the given product. The Center publishes these ratings in the Evaluated Products List (EPL), which is widely cited in computer system procurements. The Center thus works in partnership with private industry to establish product trust. 
The purpose of the Rating Maintenance Phase (RAMP) is to provide currently available trusted products. RAMP is essential for this purpose because of the frequency with which many vendors revise their offerings. Vendors often market new releases of a product every few months and keep multiple versions under development at all times. Without RAMP, only the initial evaluated version is a trusted system with a TCSEC rating. RAMP allows the Center to establish a rating and an EPL listing for each product release following an evaluated release. 
RAMP is intended to yield an EPL listing for a revised product shortly after its release date. This outcome is possible because RAMP builds cumulatively upon the evidence and assurance established by a product evaluation, and because the vendor bears primary responsibility in RAMP for maintaining product trust as the system evolves. The vendor follows strict procedures that integrate security analysis, configuration management, and evidence accumulation into the development process. The Center then extends the product rating to each successive release by ascertaining that the vendor has executed all rating maintenance responsibilities fully and correctly. 
RAMP always builds upon a product evaluation; it provides no opportunity to avoid an evaluation. The program does not diminish the role of evaluations in any sense other than reducing vendor motivation to seek product reevaluations. RAMP provides no opportunity for a product release to obtain a different rating from the one held by the original evaluated version (other than a D rating, which terminates RAMP for the given product). 
1.2 RAMP BENEFITS AND COSTS
The following are potential benefits of RAMP for system vendors: 
1) Vendors participating in RAMP can offer their latest products in response to procurements that favor or require systems rated under the Trusted Product Evaluation Program. 
2) RAMP makes it easier for vendors to discontinue support of previously rated products that have become outdated. 
3) RAMP can reduce a vendor's long-term need for reevaluations while increasing the vendor's rated product offerings. 
4) RAMP can clarify a vendor's representation of a new product version as a trusted system. 
5) RAMP creates a learning process for vendors that can yield valuable knowledge for trusted system development and marketing. 
RAMP participation creates four general types of cost for vendors: 
1) Initial expenses of personnel training and program planning. 
2) Net vendor costs of establishing RAMP and undergoing a product evaluation with RAMP. 
3) Net costs of complying with RAMP procedural requirements when developing product revisions. 
4) Costs of producing the Rating Maintenance Report and conducting related tasks to obtain rating approval. 
Costs in the second and third categories largely involve the establishment of a rigorous configuration management system for product changes. These net costs are highly dependent upon company policies and procedures in the absence of RAMP, and must be judged on a case - by - case basis from the description of the program in the following sections. 
1.3 RAMP COVERAGE
RAMP is currently available only for the maintenance of C1, C2, and B1 ratings. At present, a product cannot hold a B2, B3, or A1 rating without an evaluation of the precise version in question. RAMP is currently directed toward operating systems. Layered products are also eligible if their sponsors can meet the same requirements that apply to operating systems. RAMP does not cover subsystems. The Center can accommodate the evolution of subsystem products more appropriately through reevaluations. Networks and network components are not eligible for RAMP at this time, pending resolution of relevant issues for these products. 
Vendor participation in RAMP is required for all products under evaluation for a C1, C2, or B1 rating. A vendor must establish an intent to participate in RAMP prior to the vendor assistance phase of an evaluation for the original product, and must then pursue the process continuously so that successive versions of the product are rated at the same level as the preceding version. (Previously evaluated products can remain on the EPL, without RAMP involvement.) The Center reserves the right to determine at any point in an application of RAMP that further rating maintenance is not viable under the program because of the nature of product changes. As described in Section 6, the Center provides advance notice of such determinations whenever possible. 
1.4 RAMP APPROACH
Figure 1 shows the aspects of a typical product life cycle that create the need for RAMP. Figure 1 does not cover participation in RAMP (or the first two evaluation steps listed below). The uppermost time line depicts a vendor's development of a new product, and the second time line describes the Center evaluation of this release. The sequence of events for a product evaluation without RAMP is as follows. 
1) The vendor submits an evaluation proposal package to the Center for the given product. 
2) The Center assesses the company, the marketability of the product, and the feasibility of evaluating the product under the TCSEC. 
3) The Center prepares a Preliminary Technical Report (PTR) describing the condition of the product, its development schedule and requirements, and its candidate rating level. 
4) The vendor develops the product according to the schedule identified in the PTR. The Center provides assistance in meeting the intended rating level. 
5) The vendor declares a code freeze (CF) on the given release of the product. The code freeze is the end of substantive product changes (as opposed to testing and fix activities). 
6) The Center prepares an Initial Product Assessment Report (IPAR) for review by the Center's Technical Review Board (TRB). In contrast to the PTR, the IPAR is an intensive analysis yielding an estimation of whether or not the product is able to sustain an evaluation at the targeted level of trust. 
7) The Center conducts an evaluation wherein product trust must be demonstrated and defended to the satisfaction of the TRB. 
8) The TRB makes a rating recommendation. 
9) Upon ratification by the Chief of the Product Evaluation Division, the rating is forwarded for publication on the EPL. 
10) The Center publishes a Final Evaluation Report (FER) at roughly the same time that the product appears on the EPL. The FER is a summary, intended to be publicly releasable, of evidence on product trust. 
The central portion of Figure 1 describes the vendor's evolution of the hypothetical product over time. Long-range planning of the product's development typically yields a prioritized list of desirable system modifications for inclusion in releases following the original product. The revision process works progressively down this list, with the number of modifications in each revision determined by technical, financial, and marketing factors. 
Figure 1 depicts a fast revision cycle in which the development of each successive product version begins before the code freeze for the previous release. A slower cycle might involve the development of each new version after the previous version is released. As already stated, without RAMP only the specific product version evaluated by the Center is a trusted system with a TCSEC rating and a listing on the EPL. This holds regardless of the nature of system changes, because evaluation and RAMP are the only acceptable mechanisms for verifying the performance and assurance of the security features of the product. All new releases without RAMP continue to be unrated until such time as the product is reevaluated, i.e., some version undergoes evaluation by the Center and thereby receives a rating. 
A goal of RAMP is life-cycle product assurance, meaning production of evidence that the security features functionality and assurance established in an evaluation are maintained across every system revision. Figure 1 shows the need for several key aspects of RAMP. First, life-cycle product assurance clearly requires vendor involvement and willingness to integrate security concerns into the system development process. Security analysis and the assembly of product evidence cannot be treated as intermittent or external functions. Second, rating maintenance activities obviously must be established very early in the product life cycle, before the original product is completed and work has begun on subsequent releases. Third, the manner in which the Center achieves rapid turnaround of rating maintenance requests is reliance upon ongoing procedural controls. These controls include program planning requirements, training of vendor personnel to perform security analysis, and Center reviews of the rating maintenance process. 
The key elements of RAMP are security analysis and configuration management. Security analysis is the intellectual process of designing, analyzing, and testing product changes to assure that they do not compromise the security characteristics of the product. Configuration management*defined as a process of systematically managing changes across an entire system*is the overall procedural framework for implementing and documenting the directives and conclusions from security analysis. Configuration management provides the fundamental linkage of product evidence between the evaluated product and each new release under RAMP. A rigorous configuration management system should be established prior to the evaluation phase and applied to every product change throughout the duration of rating maintenance. This requirement holds for any product in RAMP. (Product evaluations without RAMP require configuration management only for rating levels B2 and above.) 
Figure 2 describes the general structure of RAMP. This diagram provides a brief overview of the topics discussed in the following sections, and is superseded in Section 8 by a more detailed graphic depiction of RAMP activities. The boxes in Figure 2 are task groupings arranged on a time scale from left to right. The arrows denote flows of information and program directives. 
Ramp Approach - Continued 
Box 1 depicts the Center evaluation of the original product. 
(This document commonly refers to the evaluated product that starts a RAMP process as the "original" product, even though it may in fact be a reevaluated version of some earlier product.) The vendor has already established an intent to participate in RAMP in the evaluation proposal package for the given product. While the product is still under development, one or more vendor representatives undertake a Center training program in computer security and RAMP requirements (box 2 in Figure 2). A person completing this program can serve as a Center-recognized Vendor Security Analyst (VSA) in representing the vendor's product to the Center. The VSA role is a key source of product assurance in RAMP. (See Section 2 for a discussion of Center recognition of VSAs.) 
The vendor specifies every aspect of the vendor's RAMP process in a Rating Maintenance Plan (RM-Plan). The RM-Plan establishes all procedures for maintaining product trust, including control of changes to the RM-Plan itself. The RM-Plan can be tailored to the vendor's preexisting business practices, but it must be followed precisely throughout the product life under RAMP. Preparation of the RM-Plan (box 3 in Figure 2) begins as soon as the vendor has gained a sufficient understanding of rating maintenance. The RM-Plan must be approved by the Center before the Center's issuance of an IPAR for the original product. The RM-Plan must be in force before development begins on the version that will supersede the evaluated version. 
The activities depicted by boxes 4 through 6 in Figure 2 recur for each product revision. (Box 3 recurs whenever the RM-Plan is changed.) Rating maintenance actions*box 4*are configuration management tasks conducted entirely by the vendor. These actions include: examining proposed system changes for security relevance; analyzing the direct and indirect impacts of changes; giving instructions for the implementation of changes; monitoring the implementation process; testing the revised system; modifying the tests as necessary; and updating all documentation to reflect each change. A VSA conducts, supervises, or monitors each of these tasks. 
The vendor's RAMP process is subject to two types of reviews by the Center (box 5). The Center conducts an interim review after the start of rating maintenance for each new product revision. These interim reviews may or may not involve site visits after RAMP has operated for one or more releases. The Center also conducts aperiodic on-site reviews. Both types of program review have the purpose of assuring that security features functionality and assurance are being maintained by adherence to all the procedures established in the RM-Plan. Both reviews serve the mutual interest of the vendor and the Center in identifying problems quickly so that the vendor can initiate corrective actions in a timely manner. 
The Center assigns a Technical Point of Contact (TPOC) to advise and coordinate the use of RAMP for the given product. A Center Business Point of Contact (BPOC) handles administrative and programmatic aspects of the process. A Responsible Corporate Officer represents the vendor in administrative matters. The Responsible Corporate Officer is a person empowered to commit the company financially to the program and support the technical role of the VSA. Sections 2 and 5 describe these persons and their interactions in greater detail. 
Box 6 in Figure 2 covers the submission and review of evidence for a completed revision. The vendor submits to the Center a Rating Maintenance Report (RMR) containing a summary of product evidence. Following an initial review for completeness and general adequacy, the RMR is forwarded to the Center's Technical Review Board (TRB). The VSA or VSAs associated with the product then defend the RMR and other evidence before the TRB. The remaining steps in a successful application of RAMP include a recommendation by the TRB, a rating approval by the Chief of the Product Evaluation Division, and a product listing on the EPL. The process is designed so that, if all the vendor's preparations are complete and accurate, only a short time should elapse between the end of the initial RMR review and the listing of the product on the EPL. 
1.5 LINKAGES BETWEEN RAMP AND EVALUATION
The establishment of RAMP is tied to the evaluation process at four points. First, the vendor must include an intent to participate in RAMP as part of the evaluation proposal package that starts the evaluation process. Second, the Preliminary Technical Report (PTR) prepared by the Center establishes the ability of the vendor to conduct RAMP activities. The PTR examines the vendor's understanding of configuration management; explains the implications of the TCSEC for the given product; and advises the vendor about the contents of the RM-Plan. 
Third, the Center does not complete an Initial Product Assessment Report (IPAR) for a product covered by RAMP until an RM-Plan is approved. A section of the IPAR confirms the adequacy of the RM-Plan and the vendor's ability to comply with all provisions of the plan. 
Fourth, the vendor of a product in RAMP prepares a RAMP audit to support the evaluation by the Center. The RAMP audit is discussed in Section 3. The Center conducts three TRB sessions. During the first session, at the end of the Design Analysis Phase, the IPAR is reviewed. The second and third TRB sessions occur during the Evaluation Phase. The second session covers product testing. The third is a final, comprehensive session. The initial RAMP audit must be evaluated and approved at the second TRB session. (The program assessment performed at this time constitutes the first RAMP interim review. See Section 5 for further discussion of interim reviews.) The RAMP audit is treated at that time as an integral part of the functional testing requirement (test suite) for the product. This is one of several respects in which RAMP participation increases the evaluation effort for both the vendor and the Center. 
1.6 APPLICABILITY OF RAMP
The following table summarizes RAMP eligibility in terms of product type. 
RAMP ELIGIBILITY BY TYPE OF PRODUCT
Eligible Products Ineligible Products 
Operating Systems Subsystems 
Layered products, if vendor Networks 
demonstrates knowledge of base 
product consistent with RAMP 
requirements* 
*See Sections 3 and 7 
A vendor must satisfy the RAMP requirements summarized in the Appendix. These requirements are linked to the timing of the product evaluation and are determined as the evaluation proceeds. A vendor failing to satisfy these requirements loses the opportunity to participate in RAMP until such time as the product in question is reevaluated. 
1.7 DOCUMENT CONTENTS
The organization of material in the remainder of this document generally follows the numbering of boxes in Figure 2. The one exception is that description of the RM-Plan is deferred until all subjects covered by the plan have been discussed. 
Section 2 addresses the training of vendor personnel as VSAs. 
(Description of the VSA role continues in Sections 4 through 6.) Rating maintenance actions are the subject of Sections 3 and 4. Section 3 discusses the conceptual aspects of configuration management in RAMP, and Section 4 addresses procedural issues. Section 5 deals with program reviews and the structure of RAMP in terms of communication and accountability. Section 6 covers the presentation of evidence for a product revision and the steps leading to a rating determination. Section 7 describes the contents of the RM-Plan. Section 8 provides an overview of the RAMP process. The Appendix summarizes the vendor's and the Center's requirements for RAMP. 
2. VENDOR PERSONNEL
2.1 INTRODUCTION
RAMP defines two roles for vendor personnel: the Vendor Security Analyst (VSA) and the responsible corporate officer. At least one Center-recognized VSA, and a responsible corporate officer, must be maintained while rating maintenance actions are underway. The use of multiple persons in the VSA role is a practical necessity for some products. Vendors choosing to use multiple VSAs must designate one of these persons as the lead VSA and must maintain clearly defined areas of VSA responsibility. 
VSAs are responsible for the execution of all technical tasks in RAMP including the presentation and defense of product evidence. Other persons can participate in RAMP tasks at the discretion of the vendor, but only VSAs can represent the RAMP process technically to the Center. The ability of RAMP to yield timely rating approvals for an evolving product depends heavily upon the credibility and expertise of the responsible VSA or VSAs. These VSA characteristics are acquired and demonstrated through the VSA training program and the operation of the RAMP process. 
The responsible corporate officer provides overall management of the vendor's RAMP effort and serves as the point of corporate responsibility for RAMP to the Center. The responsible corporate officer designates persons as VSAs; oversees the nonresident phase of VSA training; establishes VSA responsibilities; communicates with the Center on administrative and programmatic issues; and provides corporate assurance that the RM-Plan and submissions of evidence accurately describe the vendor's RAMP process. Any misrepresentation of the process places the product rating at risk, reflecting upon both the responsible corporate officer and the VSAs involved. The responsible corporate officer must occupy a sufficiently prominent position in the corporate structure to bear this responsibility and to commit the necessary company resources to RAMP. 
This subsection addresses the VSA training program, the establishment of VSA credibility, and the program requirements pertaining to multiple VSAs. The next four subsections describe VSA duties and responsibilities in more specific terms. Section 7 then discusses the establishment of the VSA role in the RM-Plan, and Section 8 covers Center and vendor responses to failures in this role. 
2.2 SELECTION AND RECOGNITION OF VSAS
While the vendor will probably employ numerous technical personnel in support of product development and maintenance, the Center only recognizes as RAMP representatives those individuals who have completed the VSA training program and are named by the vendor's RM-Plan as VSAs. Only these Center-recognized VSAs and the responsible corporate officer can interact with the Center on behalf of the product. 
The remainder of this subsection discusses criteria that should be considered by the responsible corporate officer when selecting personnel who will support the technical development or maintenance of a product (to include both VSAs and other technical personnel). Additional criteria, applying only to VSAs, are discussed in the next subsection, Admission To Training Program. 
Recommended Criteria for Vendor Selection of Technical Personnel: 
1) Knowledge of the product on which the person will work. 
2) Knowledge of computer science and computer security. 
3) Corporate position and expected longevity of association with the vendor and the given product. 
4) Time availability for involvement in RAMP tasks. 
5) Contribution to multiple-VSA strategy (if used). 
Regarding the first two criteria, the emphasis of RAMP upon VSA capability provides strong motivation for vendors to staff this function with the most knowledgeable persons available. The third and fourth criteria are practical considerations of obvious significance and are particularly relevant to personnel serving as VSAs. Problems can result from relying upon persons at either end of the corporate hierarchy. Low-ranking persons may lack sufficient authority and influence to fill the VSA role effectively, whereas high-ranking persons may not have enough time for day-to-day participation in rating maintenance tasks. Ideally, a VSA should be devoted full-time to the security analysis and rating maintenance of the given product. Continuity of involvement is critical because smooth operation of RAMP depends upon the progressive establishment of VSA credibility with the Center. 
The last criterion covers such possibilities as using backup VSAs, establishing mentoring relationships among VSAs, and selecting VSAs to fill specialized roles within the RAMP process. 
2.3 ADMISSION TO TRAINING PROGRAM
Vendors should submit VSAs for training by the Center as soon as possible when planning to use RAMP. The Center views timely involvement in the training program as an indicator of vendor commitment to the RAMP process. The responsible corporate officer sends a written request for vendor training with a statement of qualification for each potential trainee. (Ideally, the responsible corporate officer also undergoes training.) The Center strongly urges vendors to submit candidates with the following qualifications: 
General: 
1) Participants in the Center training program should have sufficient background in computer science to analyze all aspects of system design including functional hardware logic and software code. 
2) A trainee should be knowledgeable about the specific product for which he or she will serve as VSA. (A person can possibly serve as a Center-recognized VSA for multiple products, but at any given time the Center only deals with a VSA as a representative of a specific product.) 
Specific: 
3) A trainee should have obtained a degree from a four- or five-year college program with a major in computer science, engineering , or other technical field that emphasizes computer science; 
OR, a trainee should have at least five years of professional experience working with computers in a design or analytical capacity. 
4) A trainee should have at least one year of experience with the specific product for which she or he will serve as VSA. 
2.4 CENTER TRAINING PROGRAM
The VSA training program addresses the following subject areas: 
general principles of computer security; requirements and Center interpretations of the TCSEC; security issues in the system development process; and all aspects of RAMP. The calendar time required for a trainee to complete the course depends upon scheduling factors but should not exceed two months given an adequate time commitment. It is not possible in such a period to train persons as security evaluators capable of conducting an unsupervised product evaluation; but the course does impart sufficient capability to establish product trust when working from an evaluated system. The Center assumes no responsibility for the selection of a VSA and, in particular, the consequences of an inappropriate selection of a VSA by a vendor. The Center training program is provided as an additional measure to help the vendor prepare and select appropriate personnel to serve as VSAs who will, in turn, increase the likelihood that the vendor will be able to maintain a given product's level of trust. The Center's principal concern is, and will remain, the maintenance of a product's rating, not the certification of a VSA. For this reason, the Center will assist in the training of, but will not formally certify, VSAs. 
The training program currently consists of a three-week program of study conducted at facilities in the Baltimore/Washington, D.C., area. Beginning in 1990 the Center plans to implement a dual-phase program, which will include a nonresident (correspondence) phase and a resident phase (with the former always occurring first). 
The remaining description of the Center training program describes the planned implementation of the dual-phase program. The current Center residence program incorporates all resident testing and assessment of VSAs. 
The nonresident portion of the training program does not require a classroom setting and can take place at any location convenient to the vendor and the trainees. The flexibility of this phase with regard to location and scheduling allows the training program to be driven by vendor demand. However, the course requires a significant block of time and cannot simply be scheduled around an employee's normal workload. The responsible corporate officer must take responsibility for assuring that each trainee has adequate time for the program. In addition, the nonresident phase will not begin until the vendor has provided for VSA utilization of the Center's Dockmaster information system (described in Section 5). 
The materials utilized in the nonresident phase of the training program include: 
1) documents prepared by the Center for use in the course; 
2) additional required and recommended readings; and 
3) tests covering the course documents and required readings. 
A vendor representative serves as proctor for the nonresident coursework. The proctor monitors the progress of each trainee and administers tests and written assignments. The responsible corporate officer designates the proctor, monitors the conduct of the course, and provides assurance to the Center that all aspects of the nonresident phase are executed conscientiously. A Center training point of contact is available to answer technical and administrative questions about the program. 
Trainee performance in the nonresident phase is evaluated on the basis of tests, written assignments, and open-book group projects. The tests cover the course documents and required readings. These materials are forwarded to the vendor with guidelines for interpreting results, such as the scores that constitute satisfactory performance on each test. The vendor has responsibility for determining that a trainee has mastered the nonresident coursework sufficiently to enter the resident phase. 
Trainees then undertake approximately one week of resident classwork at the Center facility in Maryland. The resident phase focuses upon a worked example of a Trusted Computing Base (TCB), designed to provide practical experience in security analysis. The related course materials include a sample RM-Plan and a sample Rating Maintenance Report. Trainees are evaluated in this phase by written assignments and an oral examination that takes the form of a product defense before a mock Technical Review Board (TRB). 
The Center will notify the vendor of each trainee's performance in the resident phase and offer a recommendation as to whether or not the given person should be used as a VSA. The assessment provided will note the VSA's performance using both an absolute scale of reference (i.e., raw scores on tests) as well as a relative scale (i.e., the VSA's performance as compared to other VSA candidates who have attended the training). These scores will be supplemented by a subjective assessment of the candidate VSA's performance. In the case of a weak candidate, the Center may indicate that using the given person as a VSA will jeopardize the vendor's RAMP process. The vendor makes the final decision in this regard. The only absolute requirements for Center recognition of a vendor representative as a VSA are: 1) completion of both phases of the training program, and 2) assignment of VSA responsibilities to the given person in the vendor's RM-Plan (discussed later). 
The VSA training program addresses general principles of computer security and system development, and is not product-specific. In the event a VSA becomes a vendor representative for some other product, the training program need not be repeated. 
2.5 FURTHER ESTABLISHMENT OF VSA CREDIBILITY
Smooth operation of the RAMP process requires a higher level of VSA credibility and expertise than can be established in classroom training alone. In each RAMP cycle, vendors must demonstrate to the satisfaction of the Technical Review Board (TRB) that security analysis has been conducted thoroughly and correctly according to the RM-Plan. This demonstration involves written evidence, VSA defense of the evidence, and VSA credibility based upon past performance in RAMP. The higher the level of demonstrated VSA capability, the less need for time-consuming examination and information requests, and the less risk of a negative rating determination. 
A practicing VSA builds credibility through program reviews and presentations to the TRB. The former includes interim reviews during every RAMP cycle and aperiodic reviews on a less frequent basis. The Center places major emphasis on a VSA's first interim review. (See Section 5.) In the first presentation of evidence by a VSA, the TRB examines the VSA's understanding of the product as well as the management of changes under RAMP. The topics of questioning include: 1) the product and its security features and assurances; 2) the procedures followed in applying RAMP on a day-to-day basis; and, 3) the substance and rationale of decisions regarding product changes. Section 6 provides further discussion of the evidence submission process. 
Vendors are made aware of any VSA credibility problems through TRB recommendations and other communications between the Center and the responsible corporate officer. A VSA who knowingly misrepresents any aspect of rating maintenance for a product will no longer be recognized by the Center as a RAMP participant for any product. Furthermore, when a vendor (responsible corporate officer) allows a misrepresentation to occur, the RAMP process is terminated with no rating approval for the product version that was misrepresented. The Center then reviews the previous cycles of rating maintenance to determine whether the rating should be rolled back across earlier releases. (See Section 8.) Lesser infractions consisting of inadvertent VSA errors and oversights can yield serious delays and uncertainties in rating approval. Overall, there is strong vendor self-interest in using VSAs who can establish and maintain a high level of credibility with the TRB. 
2.6 MULTIPLE VSAS
Vendors can often benefit from using more than one Center-recognized VSA for a given product. The multiple-VSA approach supports program continuity in the event that a VSA becomes unavailable for duty or proves to be deficient in some respect. For some products, multiple VSAs may be essential in order to assign separate responsibility for different production sites, different parts of a product, or different aspects of rating maintenance. A vendor may also employ some VSAs without assigning them any official responsibilities in the RM-Plan. The vendor can use such persons in backup, apprenticeship, or other supporting roles while limiting the number of product representatives. 
The Center encourages the use of multiple VSAs subject to the conditions stated in the following paragraphs. These conditions, and all further references to VSAs in the present document, pertain just to Center-recognized VSAs who have completed the training program and are assigned RAMP responsibilities in the RM-Plan. Other VSAs can be deployed freely by the vendor in the same fashion as regular employees but cannot interact directly with the Center. 
The Center must know at all times which VSAs are representing the product and precisely what their individual responsibilities are. At least one Center-recognized VSA must be representing the product at any time that rating maintenance actions are underway. The RM-Plan should describe the primary area of responsibility for each VSA in such a fashion that all RAMP activities are covered and there is no ambiguity as to who is answerable for any given aspect. Divisions of responsibility by production site or corporate department should be noted along with divisions of responsibility by RAMP task. VSA responsibilities cannot be altered without formally changing the RM-Plan to describe the new assignments. As described in Section 7, the vendor must obtain approval for any change in the RM-Plan from the Center Technical Point of Contact. The RM-Plan approval constitutes the Center's recognition of any VSAs named for the first time as responsible representatives of the RAMP process. Vendors are urged to make any changes in VSA responsibilities at the beginning of a rating maintenance cycle, i.e., within a month after the previous rating approval. 
Every recognized VSA must sign the Rating Maintenance Report and be prepared to defend product evidence for the given cycle before the TRB. Ultimate responsibility for the RMR rests with the responsible corporate officer. Other VSA duties can be conducted by one rather than all VSAs. For example, only one VSA need be a member of the Configuration Control Board. (See Section 4.) Vendors should nevertheless be aware that the use of multiple VSAs does not lessen the degree to which each is accountable. An application of RAMP is only as strong as its weakest link in terms of VSA credibility. 
A vendor using multiple VSAs must designate one person as the lead VSA. Most technical communication between the vendor and the Center involves the lead VSA. The Center may require at its discretion that all technical communication be routed through the lead VSA during some or all of the RAMP cycle. It is logical but not necessary for the lead VSA to have supervisory powers over other VSAs. The RM-Plan should describe any supervisory or coordinating relationships among VSAs. These issues are discussed further in Sections 5 and 7. 
3. SECURITY ANALYSIS AND CONFIGURATION MANAGEMENT
3.1 SECURITY ANALYSIS
Security analysis is the intellectual core of rating maintenance. 
Configuration management is the supporting framework that assures an accurate translation of security analysis findings into implemented product changes and evidence of product trust. Security analysis can be viewed as an aspect of configuration management (or configuration control). The present document maintains a distinction between these concepts because for many persons configuration management connotes a set of mechanical procedures rather than a thought process. 
Security analysis is closely associated with design tasks that would be needed to effect product changes whether or not a product was a trusted system. RAMP not only introduces security as a design consideration but also requires security to be the dominant consideration. RAMP does not permit any compromise of security for the sake of other product design criteria such as performance, cost, and marketability. There can be negotiation among possible ways of implementing security for a given change, but no tradeoff of security features and assurances against other objectives. The dominance of security is always an integral part of security analysis as referenced here. 
Security analysis draws upon the vendor's full understanding of the function and interrelationships of security features in the product. This understanding is applied in diverse ways that do not permit description of security analysis as a standardized set of procedures. The following paragraphs indicate briefly the activities, issues, and outcomes of security analysis for a typical product. 
Security analysis starts by establishing the precise nature of all effects of a product change upon the Trusted Computing Base (TCB). (There may or may not be a separate, preliminary screening for the existence of TCB effects; see Section 4.) As defined by the TCSEC, the TCB is the totality of protection mechanisms *including hardware, firmware, and software*that together enforce a security policy. The present document uses a somewhat different definition covering all system elements that support protection mechanisms. The TCB addressed by security analysis and configuration management in RAMP includes system code, tests, associated software tools, test plan documentation, test results, the trusted facility manual, the security features user's guide, and design documentation. (For hardware, the program relies upon functional testing rather than configuration management.) 
A product change affects the TCB if it: alters code or documentation within the identified TCB boundary; augments the contents of the TCB; or indirectly affects the function of TCB elements. The determination of indirect effects on the TCB is a critical aspect of security analysis. The analysis considers any possibility of effects due to interrelationships among the product's security features. The analysis also acknowledges and assesses cumulative effects involving multiple product changes. (For example, two otherwise acceptable changes may conflict in terms of security because one change assumes conditions that no longer hold, given the other change.) Security analysis can potentially identify many different TCB effects resulting from a proposed change to a single configuration item. 
Security analysis enters a design mode once all TCB effects are identified and understood. The requirement is then to verify that a proposed change can be implemented without compromising the security features and assurances of the product, or else to remove the change from consideration. The security analysis assures that any change is consistent with approved architectures and does not circumvent defined security policy. The process of addressing these criteria is usually integrated or coordinated with the pursuit of other design objectives, but security is always the paramount concern. Depending upon the nature of the change and the vendor's business practices, this phase of security analysis may or may not extend into code-level product development tasks. (See Section 4.) Security analysis includes checking the adequacy of existing system tests as affected by each proposed change. The analysis modifies existing tests or creates new tests as necessary to maintain the effectiveness of the test suite. 
The outputs of security analysis include: instructions for implementing changes; recommendations for rejecting other changes; new tests and test documentation; and descriptions of all identified TCB effects, related analytical findings, and design decisions. The RAMP process subjects the conclusions of security analysis to two stages of review and retains all of the above outputs in the configuration management system. Security analysis is also addressed by the RAMP audit function described at the end of this section. 
3.2 OVERVIEW OF CONFIGURATION MANAGEMENT
Configuration management is a discipline applying technical and administrative direction to: 1) identify and document the functional and physical characteristics of each configuration item for a product; 2) manage all changes to these characteristics; and 3) record and report the status of change processing and implementation. Configuration management involves process monitoring, information capture, quality control, bookkeeping, and an organizational framework to support these activities. The "configuration" being managed is the TCB plus all tools and documentation related to the configuration management process. 
The overall objectives of configuration management in RAMP are to assure that the findings of security analysis are implemented correctly, and to generate product evidence linking with the evidence established in the evaluation. Configuration management records the "footprint" of the security analysis and controls and documents all subsequent rating maintenance tasks. This involves the central direction of system changes to: 
1) maintain the integrity of system information and the standards affecting its accuracy, timeliness, and reliability; 
2) ensure that documentation and tests remain congruous with the rest of the system; 
3) ensure adequate testing of changes prior to incorporation; 
4) maintain the integrity of all system interfaces; and 
5) support the objective of security analysis. 
Many vendors of products rated C1 through B1 already use some form of configuration management before participating in RAMP. The existing procedures can often meet RAMP requirements with few modifications, although fundamental changes are sometimes needed. The RAMP requirements are sufficiently flexible to accommodate substantial variations in vendor business practices. Typically, the greatest deficiencies of existing practices relative to RAMP standards involve security analysis rather than the record-keeping aspects of configuration management. 
The four major aspects of configuration management are configuration identification, configuration control, configuration status accounting, and configuration auditing. The present section summarizes these activities in conceptual terms. Section 4 then addresses procedural issues in rating maintenance using a representative business model to discuss specific functions needed for RAMP. 
3.3 CONFIGURATION IDENTIFICATION
Configuration management entails decomposing the TCB into identifiable, understandable, manageable, trackable units known as configuration items (CIs). The decomposition process is called configuration identification. To support RAMP, this process must occur before the initial RM-Plan is completed so that the plan can include the CIs for the original product. The configuration of the evaluated system is thereby established as a baseline for assessing future changes. 
CIs can vary widely in size, type, and complexity. Although there are no hard-and-fast rules for system decomposition, the granularity of CIs can have great practical importance. Selecting CIs that are too small can impede the audit process by yielding an unmanageable volume of identifying data. Overly large CIs can hinder configuration management by obscuring product changes and interrelationships among changes. A potentially favorable strategy is to designate relatively large CIs for system elements that are not expected to change over the life of the product, and small CIs for elements likely to change. System identification ideally should begin early in the design stage for a product when CIs are most readily established on a logical basis. For example, each CI might be a module of code designed to meet one requirement. Regardless of the strategy for establishing CIs, the granularity of control is defined to be the module level. The process must allow for the possibility that system changes will convert non-CI components into CIs. 
Vendors in RAMP decompose at least the following system components into CIs and assign a unique identifier to each. 
1) Software and firmware components of the baseline (evaluated) TCB. 
2) Design and user documentation. 
3) Software tests including functional and system integrity tests and associated documentation. 
4) Development tools including any configuration management tools. 
5) Any tools used for generating current configuration items. 
6) Any audit trail reduction tools used in the configuration management context. 
7) Any other components of the TCB as broadly defined. 
Throughout the application of RAMP to product revisions, each change in a configuration item is uniquely identified. The changes of significance for RAMP are any alterations to the TCB since the product evaluation. The date of a CI change is identifiable along with any changes to the related documentation, tests, or development tools. Each change in software source code is separately identifiable, although changes need not be separately stored. 
3.4 CONFIGURATION CONTROL
Configuration control is a means of assuring that system changes are approved before being implemented, that only the proposed and approved changes are implemented, and that the implementation is complete and correct. This involves strict procedures for proposing, monitoring, and approving system changes and their implementation. Configuration control entails central direction of the change process by corporate functions that coordinate analytical tasks, approve system changes, review the implementation of changes, and supervise other tasks such as documentation. These procedural requirements of RAMP are the primary subject of Section 4. 
Configuration control involves not only the approval of changes and their implementation but also the updating of all related material to reflect each change. There should be guidelines for creating and maintaining functional test software and documentation throughout the life of the system. The change process should include a phase for test creation and maintenance, with associated updating of documentation. Relevant tests should be performed and evaluated whenever system changes are implemented and/or tests are updated. The vendor must rerun the entire test suite before submitting RAMP evidence to the Center. 
A vendor's production arrangements may hinder or complicate the process of controlling system change. Hardware and software may be developed by separate groups within the vendor organization, perhaps located at different sites. Code development and integration may occur in different cities, with testing conducted at both locations. Also, a vendor may propose RAMP for a system (layered product) that incorporates another vendor's products. Vendors faced with these difficulties acknowledge the resulting limitations on security analysis and configuration control in their RM-Plans, and establish alternative procedures of equal effectiveness for upholding product trust. 
A vendor applying RAMP to a layered product demonstrates configuration management cognizance over all parts of the product, including parts manufactured by other vendors. This means that the vendor understands the base product and its changes since evaluation and conducts security analysis of these changes, to the same extent as required by RAMP for an in-house product. (See Section 7.) Some form of collaboration among vendors is thus virtually essential for RAMP coverage of a layered product. 
A vendor's configuration management system includes policies and procedures for correcting any security bugs identified in the product. Responses to flaws, bugs, and breakdowns of RAMP assurance are discussed in Section 8. 
3.5 CONFIGURATION ACCOUNTING
Configuration accounting documents the status of configuration control activities and in general provides the information needed to manage a configuration effectively. It allows managers to trace system changes and establish the history of any developmental problems and associated fixes. Configuration accounting also tracks the status of current changes as they move through the configuration control process. Configuration accounting establishes the granularity of recorded information and thus shapes the accuracy and usefulness of the audit function. 
Configuration accounting should yield answers to questions such as the following. What source code changes were made on a given date? Was a given change security relevant? Why or why not? What were all the changes in a given CI between releases N and N+1? By whom were they made, and why? What other TCB modifications were required by the changes to this CI? Were modifications required in the test set or documentation to accommodate any of these changes? What were all the changes made to support a given change request? 
The accounting function is able to locate all possible versions of a configuration item and all of the incremental changes involved, thereby deriving the status of that CI at any point in time. The associated records include commentary about the reason for each change and its implications for the TCB. Configuration accounting provides convenient access to such records for use as evidence in the rating maintenance process. In general, the effectiveness of configuration accounting depends upon the quality of system identification and control efforts. 
3.6 CONFIGURATION AUDIT
Configuration audit is the quality assurance component of configuration management. It involves periodic checks by the vendor to determine the consistency and completeness of accounting information and to verify that all configuration management policies are being followed. (The following subsection identifies when configuration audits occur.) A vendor's configuration management program must be able to sustain a complete configuration audit by a Center aperiodic review team. 
A configuration auditor should be able to trace a system change from start to finish. The auditor should check that only approved changes have been implemented and that all tests and documentation have been updated concurrently with each implementation to reflect the current status of the system. A configuration audit in RAMP must be conducted by a VSA. 
3.7 RAMP AUDIT
The RAMP audit process addresses both security analysis and configuration management procedures. The two components of a RAMP audit are a configuration audit as described above and a detailed review of security analysis records for a selection of product changes. The security analysis component involves drawing a random sample of past Service Improvement Requests (SIRs, as described in Section 4) and assessing all the security analysis activities undertaken to meet each request. The objective is to confirm in each case both the adequacy of the analysis and the completeness of the stored records. 
As already indicated, the RAMP audit is part of the functional testing requirement for a product in RAMP, and the results of the initial audit are reviewed by the Center evaluation team during the product evaluation. This review ensures that the vendor's RAMP process follows the procedures outlined in the vendor's RM-Plan. A vendor's audit program is established clearly in the RM-Plan. The plan describes the frequency of audits and the procedures for assessing configuration management and security analysis practices. The results of all subsequent RAMP audits are reviewed by the Center's TPOC. (See Section 7.) 
4. PROCEDURAL ASPECTS OF RAMP
4.1 INTRODUCTION
RAMP uses strong procedural controls to assure that rating maintenance actions by vendors do not compromise the product trust established in Center evaluations. On the other hand, overly rigid requirements would be costly and inefficient for some vendors and thus could limit program involvement. The Center reconciles these concerns in RAMP by allowing considerable vendor discretion in the design of configuration management procedures, but requiring meticulous adherence to plans once developed. 
Rating maintenance procedures are described here using a generic business model. The Center developed this generic model by interviewing numerous vendors and identifying common elements in their business practices. Discussing RAMP in this context serves to: 
1) provide a specific illustration of acceptable procedures; 
2) establish common names for certain activities and functions; 
3) clarify the elements essential for RAMP; and 
4) provide a baseline against which alternative approaches can be evaluated. 
The discussion does not imply that each vendor's product revision process must conform to the generic model. What RAMP requires is that the chosen procedures be no less effective than the generic model in maintaining continuity of assurance and providing evidence of product trust. 
The following text assigns standard names to various procedural elements and functions (summarized in the glossary). This does not imply that a vendor must create new entities corresponding to the names, if equivalents already exist. The Center requests vendors to utilize the standard names in their RM-Plans and other formal communications as an assistance to the Center in dealing with diverse products and business plans. Vendors should feel no need to alter their internal language, since the VSAs interacting with the Center can readily translate the few terms at issue. 
4.2 GENERIC MODEL
Figure 3 depicts the generic model of rating maintenance actions in RAMP. The diagram emphasizes configuration control, although configuration identification, accounting, and auditing tasks are no less important. All of the boxes and arrows represent configuration management procedures identified in the Center survey of business practices prior to RAMP. The diagram has been converted to a RAMP description by highlighting two control and approval functions (using dotted lines and decision nodes), and by including commentary on the VSA role. 
The generic model can be summarized as follows, ignoring momentarily the elements specific to RAMP. Proposed system changes are drawn from a prioritized list of desirable system modifications as described in Section 1. Requests for changes reach the system design group through some mechanism that we call a Service Improvement Request (SIR). Each proposed change receives a preliminary screening for effects on the TCB. A change that clearly does not affect the TCB directly or indirectly enters a design analysis phase addressing product characteristics other than security. (Code-level design of the change may occur in varying proportions at this stage and at the implementation stage.) The design analysis ends with some form of review. A change that affects the TCB, or may affect the TCB, undergoes security analysis in conjunction with design analysis. 
The analysis and