Rating Maintenance Phase Program Library

Found at: 0x1bi.net:70/textfiles/file?hacking/COLORBOOKS/pink.txt

Rating Maintenance Phase Program
Library No. S-232,468 
Version - 1 
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 
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. 
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). 
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. 
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. 
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. 
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. 
The following table summarizes RAMP eligibility in terms of product type. 
Eligible Products Ineligible Products 
Operating Systems Subsystems 
Layered products, if vendor Networks 
demonstrates knowledge of base 
product consistent with RAMP 
*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. 
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. 
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. 
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. 
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: 
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.) 
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. 
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. 
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. 
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. 
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. 
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. 
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. 
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. 
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. 
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. 
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.) 
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. 
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 review tasks yield an Engineering Change Order (ECO), which directs the implementation of an approved change. The ECO covers modifications of tests and documentation as well as the system software. Code is written for the change and entered into a working copy of the system for testing. Existing and modified tests are applied as appropriate. The change is then subjected to a final review. Any change that fails to gain acceptance in this final review is removed from the system. If rejection has been caused by an implementation problem, the change may recycle back to the ECO stage. Other changes rejected in the design review or final review are sent back to the beginning of the configuration management process or discarded altogether. Implemented changes that gain final approval are incorporated into the product, and all documentation is updated accordingly. 
This and the following subsections describe the requirements of RAMP in the context of the generic model. For convenience, the text often references the VSA role as if played by a single person even though multiple VSAs are likely. 
The system revision process in RAMP starts with an evaluated product (although the first changes may occur while the evaluation is still in progress, or even before the code freeze for the evaluated product). The full configuration management process should be operative as soon as a system is identified, so that all changes relative to the original product can be managed uniformly. 
The vendor selects changes from the prioritized list of desirable system modifications established during the product development. Financial and marketing factors affect the choice of changes, since these factors influence the revision cycle and the feasible number of modifications per cycle. RAMP requires some equivalent of the Service Improvement Request (SIR) to provide a formal record of all proposed changes entering the analysis and implementation process. 
All analytical and design tasks in RAMP should be conducted under the direction of a corporate entity called the Configuration Control Board (CCB). The upper dashed line in Figure 3 encompasses the activities in the generic model that the CCB should supervise. These include: 1) screening of proposed changes for impact on the TCB; 2) security analysis of changes that affect the TCB; 3) associated design analysis and review tasks; 4) approval and disapproval of changes on the basis of product trust; and 5) issuance of instructions for change implementation (ECOs). 
Central direction by a CCB does not necessarily mean that a vendor must discard other ways of administering configuration management in order to participate in RAMP. The vendor can base the CCB on an existing design supervision group, perhaps joined by other persons when it sits as the CCB, or the vendor can establish the CCB as a forum of representatives from multiple groups involved in product development. 
The membership of the CCB must include at all times a Center-recognized VSA for the given product. Furthermore, the responsible corporate officer must have the power to veto any CCB approval of a product change. This veto power can derive from inclusion of the responsible corporate officer as a CCB member with special voting rights; from some other explicit provision of the CCB rules, or from the authority vested in the responsible corporate officer by his or her corporate position. The responsible corporate officer is not required to participate in CCB deliberations or decision-making on a routine basis. This arrangement gives the VSA two ways of influencing product changes (over and above contributing to analysis and design tasks). The VSA can influence changes by participating as a full member in the CCB function, and also by notifying the responsible corporate officer that a given change approved by the CCB is unacceptable in terms of RAMP assurance. In essence, the VSA represents security concerns to the CCB, and the responsible corporate officer enforces the dominance of these concerns. The Center holds the vendor accountable for change control through the responsible corporate officer. 
RAMP requirements for the CCB are summarized as follows: 
1) The CCB operates at all times in accordance with the vendor's RM-Plan. 
2) No product change can be implemented without approval by the CCB. 
3) The CCB has authority over all analysis, design, and review tasks from the receipt of SIRs through the issuance of ECOs. 
4) The CCB has access to all information used in, and generated by, the activities under its purview. 
5) The VSA (or a VSA) is a CCB member with all of the rights, powers, and information access possessed by other members. 
6) The responsible corporate officer has the power to veto any CCB approval of a product change. Changes vetoed by the responsible corporate officer are disposed in the same fashion as changes disapproved by the CCB. 
There are no restrictions upon CCB procedures for reaching decisions, but the Center encourages using the CCB as a forum for deliberations that can be recorded as RAMP evidence. The CCB ideally functions as a central source of "security wisdom" as well as program oversight. 
The preliminary screening of proposed changes for effects on the TCB is an optional feature of the generic model, although some arrangement of this nature is probably necessary for efficiency. A nonoptional feature of the model is that the changes that bypass preliminary screening are routed through the subsequent phases of the change control process (i.e., EACH CHANGE MODEL MUST CONTAIN SOME TYPE OF CONFIGURATION REVIEW). Retention of these changes in the process allows the reviews by the CCB and Configuration Review Board (CRB) to verify the absence of any direct or indirect effects on the TCB. 
Section 3 has already described the scope and responsibilities of security analysis. This task must determine that a proposed change upholds the security features and assurances of the product in compliance with the TCSEC and the Criteria interpretations. The outcome for each change is evidence that links with product evidence from the evaluation. Security analysis may require intensive problem-solving efforts in establishing TCB effects, designing changes, and developing appropriate tests. The fundamental requirement of RAMP is dominance of security over other design considerations. 
The Center periodically issues Criteria interpretations to clarify the application of the TCSEC. An important issue in RAMP is the time that is allowed to elapse between the issuance of an interpretation and the compliance of a product release (and all subsequent releases) with this interpretation. The reasonable maximum time is related to the length of a product's revision cycle (e.g., three months, six months), but it cannot be linked rigidly to the revision cycle without creating excessive difficulties for fast-cycling products and excessive slack for slow-cycling products. The Center recommendation is that each product release in RAMP should comply with all Criteria interpretations for which at least one of the following conditions is true: 
1) The interpretation was issued prior to the EPL listing for the previous release of the given product. 
2) The interpretation was issued at least one calendar year prior to the submission of a Rating Maintenance Report (RMR) for the release in question. 
3) The interpretation is accompanied by an effective date, which precedes the RMR submission date for the release in question. 
This policy would give vendors a grace period of one revision cycle within which to comply with an interpretation, unless the revision cycle is longer than one year or unless the interpretation has an effective date that overrides the grace period. The Center cites an effective date if rapid compliance with an interpretation is considered especially critical. Each vendor proposes a policy for complying with Criteria interpretations when submitting an RM-Plan for Center approval. (See Section 7.) The approved policy becomes a plan element that must be followed rigorously throughout the RAMP process. 
The need to comply with interpretations issued after the product evaluation can mandate design analysis and even product changes that have nothing to do with service improvements desired by the vendor. It is unlikely but possible that an interpretation will terminate rating maintenance for a product and necessitate a reevaluation. Because the interpretations issued during one revision cycle for a product typically do not apply until the next cycle, the Center can usually indicate in advance whether or not a given interpretation will affect the continued use of RAMP. The VSA has responsibility, however, for keeping abreast of interpretations and assessing their impacts on the product. Criteria interpretations do not apply retroactively, so that product ratings established through RAMP are not withdrawn because of subsequent interpretations. 
An approved system change is implemented through an ECO or a set of ECOs. An ECO tells the maintenance establishment what must be done to the code, the documentation, and other elements of the system to implement the change. The generic model shown in Figure 3 assumes that an ECO contains instructions in relatively high-level language, but code-level directives are also possible. Vendors can determine the format and content of ECOs subject to the following general requirements. In the generic model: 
1) The ECO provides an orderly mechanism to propagate change across the system and assure synchronization, connectivity, and continuity of alterations. 
2) The preparation of ECOs is under CCB control. 
3) No system change of any kind can occur without direction by an ECO. 
4) Each ECO retains the identities of the initiating SIR and any other SIRs or ECOs occasioned by the initiating SIR. 
5) ECOs are retained as evidence for rating maintenance and should have a form suitable for record-keeping purposes. 
RAMP assigns considerable importance to the ECO as part of the trail of product evidence. The vendor should establish the granularity of ECOs so that they provide convenient reporting units throughout rating maintenance. As discussed in Section 6, the RMR describes system changes at the ECO level. 
The lower portion of Figure 3 describes the general process of implementing and testing a system change. The tests must verify that the implemented change preserves the function of security features and the assurance of correct feature operation. Testing and test development should be conducted independently from the implementation of changes as a check on the latter process. (Separation of functions as practiced by accountants can provide a useful safeguard in other areas of rating maintenance as well, subject to RAMP requirements for overall coordination and control.) The reference to testing in Figure 3 covers both functional security tests and performance tests, but only security tests contribute to RAMP evidence. 
The results of implementing and testing each change are assembled for a final review before the change is incorporated into the product. An entity called the Configuration Review Board (CRB) carries out this review. The CRB membership should include a Center-recognized VSA (not necessarily the same VSA belonging to the CCB). The VSA should have all of the information access and influence over CRB decisions possessed by any other CRB member. The CRB can have the same overall membership as the CCB or can be an independent quality assurance group. 
The final review by the CRB provides closure on each ECO by verifying that every aspect of the approved change was implemented correctly and that no other alterations were made. There should also be a reassessment of test results and system assurances to confirm that system trust has been upheld. The CRB then decides whether or not to accept a given change as part of the product. Rejected changes are removed from the system and disposed in the manner discussed above. The process ends for an accepted change with final incorporation and documentation tasks. 
General suggestions of configuration accounting and auditing have been indicated in the previous section. The configuration management system should include numerous checks to assure that all relevant information is recorded and that documentation is updated fully to reflect each product change. As the custodian of RAMP evidence, the VSA must remain in close touch with all documentation tasks and should be able to influence the execution of these tasks. 
A vendor with a functioning configuration management system prior to RAMP may choose to record some RAMP evidence externally in order to avoid overloading the system. For each product change, RAMP evidence will include the following commentary: the SIR from which the change originated; the procedures and arguments used in establishing TCB effects; the issues and conclusions of the security analysis; the ECOs generated for the change; and the completion status of ECOs. The vendor must be able to perform line-by-line code comparisons with pointers back to the ECOs causing specific modifications. The commentary on tests should include descriptions of new and modified tests, with stated reasons for the alterations and pointers to the test results. 
The required duties of a VSA are suggested by the items on the right-hand side of Figure 3. The VSA is the focus of security wisdom in RAMP. The VSA (or VSAs) tracks the entire rating maintenance process and understands product changes in sufficient depth to verify the adequacy of security analysis and configuration control procedures. The VSA represents the Center concerns to the CCB and CRB, and assures that these functions are operating effectively to maintain product trust. 
The VSA is custodian of all RAMP evidence, meaning that the VSA monitors the accumulation of evidence and has sufficient resources to assure its accuracy, completeness, and accessibility. The VSA has direct responsibility for proposing and managing revisions to the RM-Plan. The VSA performs or supervises the RAMP audit function and the preparation of all materials for submission to the Center. Lastly, the VSA is the vendor contact for all technical communication with the Center. 
Section 2 has addressed the subjects of VSA training, VSA recognition by the Center, establishment of VSA credibility, and multiple-VSA approaches. At least one Center-recognized VSA must be representing the product at any time that rating maintenance actions are underway. A vendor using multiple VSAs must designate a lead VSA and must maintain an accurate description of VSA responsibilities in the RM-Plan at all times. Communications between VSAs and the Center are discussed in the next section. 
Two types of program review occur during the RAMP cycle between submissions of product evidence. An interim review takes place following each vendor RAMP audit. Aperiodic reviews occur irregularly throughout an application of RAMP on an average of less than one review per cycle. An aperiodic review is always conducted by a Center review team at the vendor's site (or multiple sites if applicable). Interim reviews may or may not occur on-site. As noted in Section 1, the first interim review for a product in RAMP occurs following the vendor's RAMP audit performed in preparation for the product testing TRB session. 
Both types of review have the general purpose of establishing VSA credibility and confirming process assurance in RAMP. The reviews serve the common interest of vendors and the Center in identifying problems as early as possible so that the vendor can make corrections with minimum impact upon rating maintenance and product evolution. 
Review teams examine the evidence accumulation process and scrutinize records such as SIRs, ECOs, test results, and reports on CCB and CRB proceedings. VSAs are questioned about RAMP procedures and may be required to trace the course of events for specific product changes. The vendor must have the ability to perform a line-by-line code comparison for any two points in time and to sustain a RAMP audit by a Center review team. Program reviews are also an occasion for assessing the adequacy of the vendor's RM-Plan, and may lead to RM-Plan modifications. 
Interim reviews and aperiodic reviews differ somewhat in emphasis. 
An interim review has a procedural focus, addressing the credibility of the configuration management process and its adherence to the RM-Plan. An aperiodic review covers much of the same ground but includes an in-depth examination of the vendor's ability to conduct security analysis. 
The subjects of investigation include the procedures for generating SIRs and ECOs, the adherence to established security analysis and design analysis policies, the exercise of central control by the CCB, the effectiveness of the CCB and CRB review functions, the adequacy of test development and documentation procedures, and all aspects of the configuration accounting system. The interim review team verifies that all product changes are controlled uniformly, that security concerns have precedence over other development objectives, and that sufficient evidence is accumulating to support process assurance. 
Interim reviews focus strongly upon the credibility of each VSA as a representative of the vendor's RAMP process. The first interim review for a VSA is a critical milestone in the establishment of VSA credibility. All VSAs demonstrate to the interim review team a broad knowledge of security-related policies, issues, and practices for the given product, and an ability to apply the TCSEC in concrete situations. The interim review verifies that the VSA (or group of VSAs) is tracking every aspect of the configuration management process and is participating sufficiently in each task to understand the major issues and decisions for every product change. 
An aperiodic review constitutes an assurance checkpoint in a vendor's RAMP program. Vendors receive no information about the timing of aperiodic reviews other than sufficient advance notice to allow an orderly review process (i.e., a few days). Vendors designate one point of contact per RAMP activity site to be notified in case of an aperiodic review. 
An aperiodic review examines in detail the soundness of a vendor's decisions and the adequacy of product evidence to support the assertions of product trust contained in Rating Maintenance Reports and other VSA statements. An objective in some cases is to determine the reasons for problems already identified. The review team may select several recent product changes and trace the entire sequence of events leading to the implementation of each, with particular emphasis upon the thoroughness and accuracy of security analysis. This process examines the vendor's analytical competence and sensitivity to security issues as well as the effectiveness of configuration control and configuration accounting procedures. 
The aperiodic review team looks for trust violations consisting of: insufficient understanding and application of computer security principles; failure to give top priority to security concerns; errors in security analysis and product testing; failure to follow the RM-Plan; and failure to report all relevant actions and circumstances as product evidence. If an aperiodic review identifies a security flaw in the product or a breakdown of process assurance, the Center reserves the option of withdrawing EPL status from the affected version of the product and all subsequent versions. (See Section 8.) 
There is a designated Center Technical Point of Contact (TPOC) for each product in RAMP. The TPOC tracks the rating maintenance process from the planning phase onward and coordinates all technical interchange between the vendor and the Center. The TPOC is the vendor's entry into the Center for the resolution of computer security issues and concerns. The TPOC assesses VSA performance and other aspects of the program, particularly during the first RAMP cycle but does not directly supervise vendor activities. 
There is also a Center Business Point of Contact (BPOC). The BPOC carries out administrative functions in RAMP such as: making programmatic decisions; planning the use of Center resources; providing a conduit for official documentation; and notifying the vendor of rating determinations. 
Section 2 has discussed the general duties and responsibilities of the vendor's responsible corporate officer. The responsible corporate officer administers the RAMP program and is the vendor's point of accountability to the Center. The responsible corporate officer is a person empowered to make financial commitments on behalf of the program; maintain a favorable corporate context for its execution; and limit product changes as necessary for protection of RAMP assurance. The responsible corporate officer assumes full responsibility for the contents of each Rating Maintenance Report. 
Figure 4 shows the lines of communication in RAMP between the TPOC, BPOC, responsible corporate officer and VSA(s). All interactions on administrative matters are routed between the BPOC and the responsible corporate officer. All technical communication passes through the TPOC, with two exceptions. These exceptions are on-site reviews and VSA interactions with the TRB when defending an RMR. 
The Center requires the vendor to designate a lead VSA in multiple-VSA situations primarily to facilitate orderly communications. The lead VSA should conduct most technical interactions with the Center (possibly excluding on-site reviews and RMR presentations), and should receive copies of any written documents passing between the vendor and the Center. In some cases the TPOC may require that all technical communication be routed through the lead VSA. 
The lead VSA will provide quarterly, informal status reports to the TPOC (via the Dockmaster system mentioned below). These reports are intended to keep the Center apprised of the vendor's rating maintenance activities. 
The Center discourages excessive vendor reliance upon the TPOC as a program advisor. The TPOC apprises the vendor of important developments in the computer security field and is available for consultation on major issues. This does not relieve the vendor of responsibility for keeping abreast of developments through other means (such as the Dockmaster system mentioned below) and exercising security wisdom independently of the Center. Vendors are discouraged from attempting to pass program responsibility back to the Center by submitting routine decisions to the TPOC. The success of RAMP depends upon a vendor's own security analysis capability and willingness to be held accountable for actions affecting the product. 
All vendors participating in RAMP must provide for VSA access to the Center's Dockmaster information system by the time VSA training begins. Dockmaster is a Honeywell MULTICS system used by the evaluation community for electronic mail, electronic meetings, forums, queries, and other functions. A RAMP vendor must be prepared to communicate with the TPOC via Dockmaster and to use the system as a general information source. 
A vendor in RAMP preserves security features and assurances of a product through security analysis and configuration management. The documentation of this process in a body of evidence linking to the evaluation yields RAMP assurance of product trust. Because the process is subject to strong procedural controls*the RM-Plan, on-site reviews, and VSA training*the Center can extend the product rating to each new release without performing a full reevaluation or a lengthy assessment of all product evidence. Rating approvals are based upon a moderately detailed summary of evidence and a face-to-face presentation of this material by the vendor to the Center. The Center reserves the right to request additional evidence as necessary. 
The vendor prepares the summary of evidence in the form of a Rating Maintenance Report (RMR). The vendor can submit the RMR to the Center at any time after all changes have ended for the product version in question. Delays can be minimized by preparing much of the RMR while the product is being revised, i.e., by summarizing the evidence as it accumulates. 
The following are the major steps leading to a rating approval and EPL listing for a revised product. These steps are discussed at greater length following the description of the RMR. 
1) Vendor submits RMR and other materials to TPOC. 
2) TPOC circulates RMR to Center evaluators for review. 
3) TPOC forwards RMR and supporting materials to Technical Review Board (TRB). 
4) TRB reviews RMR and issues comments to vendor (through TPOC). 
5) VSA or VSAs defend RMR before TRB. 
6) TRB makes recommendations on rating maintenance to Chief of Center Product Evaluation Division. 
7) Chief of Product Evaluation Division approves or disapproves product rating. 
8) Revised approved product receives EPL listing. 
Steps 1 and 2 may iterate until the TPOC is satisfied with the level of detail of the RMR. Only a short time should elapse between steps 3 and 8 if the vendor has properly satisfied the RAMP requirements (summarized in Appendix A) and has a well-executed RAMP process (defined by the vendor's RM-Plan) with adequate VSA credibility. Thus, efficient preparation of the RMR and supporting materials can lead to an EPL listing at roughly the same time that the new product version is released. 
The RMR summarizes product evidence at a level of detail intermediate between the information that would be required to conduct an evaluation and the information typically contained in a Final Evaluation Report. The RMR asserts that product trust has been upheld and includes sufficient commentary to allow an understanding of individual product changes. Figure 5 presents a suggested outline for an RMR. The Center does not impose a standard format on these documents but requires coverage of all the listed items. 
The major components are a cover letter, a description of the system configuration, a section on Criteria interpretations, a discussion of each product change at the ECO level, and a future change analysis. The cover letter identifies the product and describes its history of rating maintenance. The cover letter must be signed by the responsible corporate officer and all recognized VSAs. It affirms that the responsible corporate officer: 1) has reviewed the RMR; 2) assumes full responsibility for the RMR contents; and 3) acknowledges responsibility for the sincere and conscientious execution of all rating maintenance actions. 
The first report section gives a complete overview of the system configuration and its changes since the product evaluation. Much of this material can often be carried forward from earlier documents. General discussion of RAMP policies and procedures can appear either here or in a separate section. The second section discusses the significance of all Criteria interpretations applying to the given product release. (The vendor's policy with regard to interpretations is discussed in Section 4 and Section 7.) 
The items in the third section of the suggested RMR outline are repeated for each product change. RAMP defines an individual change in this context as an Engineering Change Order (ECO) that has been implemented. Figure 5 assumes a classification of ECOs according to product module and configuration item. (The classification may vary if ECOs overlap configuration items.) Discussions can be pooled and cross-referenced in cases where several ECOs have been used to achieve a common purpose, but the RMR should list each ECO individually. 
The last lines in the third section of the RMR outline suggest the topics requiring mention in the evidence summary for an ECO affecting the TCB. Very little discussion is necessary for other ECOs*one or two sentences as compared with at least a paragraph for each ECO having TCB impact. (These two categories of ECOs may be segregated in the RMR.) The appropriate depth of discussion for an ECO affecting the TCB depends upon the sensitivity of relevant security mechanisms and assurances and upon the complexity of the security analysis. 
The fourth section of the RMR as outlined in Figure 5 is a discussion of probable changes in the product beyond the current version. The Center uses this future change analysis to assess the future applicability of RAMP to the product (as discussed below). The Center requests vendors to describe the major product changes anticipated for the next two release cycles or the next 18 months, whichever period is greater. A failure to provide this information increases the vendor's risk of discovering suddenly that RAMP is no longer feasible and the product is no longer eligible to participate in RAMP. In order to be placed on the EPL, the product must then be reevaluated. 
Figure 5. Suggested Rating Maintenance Report Outline 
Identification of the new product version, the evaluated product, and any intervening product releases. 
Identification of the product rating established in the evaluation and maintained through the previous release. 
Serial numbers of the Final Evaluation Report (FER), any revised versions of the FER, and the RMR for the most recently maintained release. Assertion that the new release maintains the product rating. Responsible corporate officer warranty of document contents. 
Signatures of the responsible corporate officer and all Center-recognized VSAs. 
Listing of the hardware/software configuration for the 
evaluated product 
(original TCB by module). 
Rationale for system decomposition into configuration items. Updated listing of the configuration, noting changes: List of hardware contained in the secure configuration. List of TCB software modules, noting any modules that have been changed and the file length (lines of code) of each module. Rationale for determining effects on the TCB of product changes, with pointers to specific changes itemized in Section 3. 
List of all Criteria interpretations applying to this product release. 
Comments on the significance of each interpretation for the product as revised. 
Pointers to discussions in Section 3 of product changes 
made because of specific Criteria interpretations. 
Name of module or document changed. 
ID number(s) of configuration item(s) changed. 
Engineering Change Order (ECO) number. 
Description of change: 
Functional description. 
Description of user-visible effects. 
Classification of change according to effects on the TCB (yes or no). 
Evidence of product trust (if change affects the TCB): 
Explanation of relevant Criteria and interpretations. 
Relevant TCB mechanisms and assurances. Design issues, alternatives, and solutions. Tests and test modifications if any. Summary of test results. Pointers to system and test documentation. Pointers to specific code-level changes. 
Expected product changes in next revision cycle. 
Expected product changes in second revision cycle. 
Later evolution of product.] 
The materials submitted concurrently by the vendor to achieve rating maintenance include several items in addition to the RMR. The overall package is as follows. 
As discussed elsewhere, RM-Plans often change during a rating maintenance cycle because of procedural refinements and changes in VSA responsibilities. The Center is always aware of changes and always possesses a current version of the RM-Plan, because changes cannot be effected without Center approval. The vendor's submission package at the end of a rating maintenance cycle includes an additional copy of the RM-Plan with change bars showing every alteration relative to the plan that was in force at the end of the previous cycle (i.e., when the previous RMR was submitted). This document must show the date on which each RM-Plan change was approved by the Center. Its purpose is to assist review of the vendor's program by the TRB. (A general principle of the rating approval process is that the vendor should not assume a TRB "memory.") The vendor may also choose to include a separate document consisting of a proposed RM-Plan for the next revision cycle. Submitting proposed RM-Plan changes at this time facilitates Center approval and serves the Center objective of confining most plan alterations to the beginning of a cycle. 
The submission package includes a copy of the Final Evaluation Report (FER) for the initial evaluated product, with change bars converting the FER to a description of the current release. The vendor also provides a copy of the FER with these changes integrated into the text. The latter document is called a RAMP FER to distinguish it from the direct output of a Center evaluation. 
The remaining document submitted with the RMR is a brief description of the revised product for use by the Center in publishing an EPL listing if the new version maintains the product rating. This and the RAMP FER are the only program documents intended for public release. 
The TPOC receives the RMR and associated materials from the vendor and forwards these documents to Center evaluators for review. A primary objective is to prepare the VSAs for examination by the TRB. The reviewers point out areas of the RMR that are deficient or likely to receive special TRB attention. The VSAs respond by revising the RMR and/or assembling supplementary evidence for the product defense. The TPOC then submits the RMR and related materials to the TRB. After examining the RMR, the TRB may transmit written comments to the VSAs (through the TPOC), which establish a partial agenda for the VSAs' oral presentation and defense. 
All Center-recognized VSAs should be prepared to meet face-to-face with the TRB and discuss the aspects of RAMP for which they have been responsible. The TRB will expect the VSAs to present a thorough technical overview of changes to the product TCB and the security analysis of those changes, thus demonstrating continuity of function and retention of assurance. When new VSAs are involved, the face-to-face examination is strongly concerned with establishing VSA credibility. The TRB questions each new VSA in depth about the nature of the product as well as about rating maintenance procedures and individual changes. 
The TRB will focus upon changes which raise complex security questions, or which are not fully understandable from the RMR description, or which provide a good context for detailed examination of procedures. The responsible VSA first describes the change and answers questions on the basis of memory and supplementary information brought to the session. If these responses are inadequate, the TRB requests additional evidence. 
The TRB subsequently issues a recommendation to the Chief of the Product Evaluation Division stating that product trust has or has not been maintained by the current product version at the level established by evaluation. If the product does not sustain its rating, the vendor may or may not be given the option of reconstructing the RAMP process in some fashion and returning for another TRB review. The given RAMP cycle ends with a rating determination by the Chief of the Product Evaluation Division and, if the determination is favorable, a listing of the new release in the EPL. 
RAMP applicability is limited. If product revisions fundamentally alter security mechanisms and assurances, the result from a security standpoint is a new product requiring evaluation to qualify as a trusted system. At the start of RAMP, the Center verifies the potential applicability of the program to the initial revisions of the product before approving the vendor's RM-Plan. The RMR review at the end of each cycle is the occasion for later forecasts of RAMP applicability. These forecasts of future RAMP applicability are an integral part of the trusted products partnership established between the Center and the vendor. 
The Center uses the information in the vendor's future change analysis to estimate (if possible) the point at which RAMP will no longer be viable and the product cannot be placed on the EPL without a reevaluation. This point can result from cumulative changes as well as from especially significant changes in any one revision cycle. The Center criteria for RAMP applicability cannot be summarized conveniently here. The extremes are that most changes in system architecture are not coverable by RAMP, whereas product changes that do not affect the identified TCB directly or indirectly can always be covered. 
The Center has designed RAMP with the intention of giving vendors at least one cycle's advance notice of the need for a product reevaluation. (Hence the request for information in the future change analysis describing at least two cycles.) The degree of certainty expressible by a RAMP forecast is governed, in large measure, by the level of detail, completeness, and the schedule provided in the future change analysis by the vendor. Notifying the vendor that RAMP can proceed for another revision cycle does not commit the Center to approve rating maintenance for that cycle when completed, and a forecast of RAMP applicability for a later cycle may be changed as that cycle approaches. The Center reserves the right to deny a rating and/or discontinue a RAMP process at any time. 
When forecasting RAMP applicability for a product, the Center addresses any expected difficulty in complying with recent or prospective Criteria interpretations that do not apply to the current product version. 
As discussed in Section 4, Criteria interpretations can affect the use of RAMP irrespective of the nature of product changes. 
Strict adherence to a comprehensive RM-Plan is one of the most important program controls in RAMP. The RM-Plan is the vendor's document, tailored to the product in question and to the company's business practices and personnel. The plan and any proposed changes must be approved by the Center and must describe accurately throughout product maintenance what the vendor is doing to the product and what evidence is being recorded. 
A vendor starting a new RAMP process should commence preparation of an RM-Plan during or immediately after VSA training. No rating maintenance actions on the product can occur until an approved RM-Plan is in place, which means that delays in program planning can slow the startup of product revisions. Vendors should develop a new RM-Plan by building upon rather than rejecting previous practices. The Center encourages this approach in order to minimize the chances of conflict and inefficiency in RAMP. Also, the vendor should not attempt to resolve every issue and establish an ideal plan before submitting a draft to the Center for review. A period of consultation between the vendor and the Center is usually necessary to arrive at a mutually acceptable RM-Plan. In plan development as in later phases of RAMP, the Center is eager to help vendors who approach the process constructively. 
A vendor initiates the RM-Plan approval process by submitting a new or revised plan to the TPOC. The TPOC coordinates the Center review and issues an approval when the plan is judged to comply with RAMP requirements. The TPOC will document approvals of new or revised RM-Plans and changes to existing plans via the Center's Dockmaster system. 
A vendor may wish to change an existing RM-Plan in order to improve the rating maintenance process or alter VSA responsibilities. There are no fixed limitations on changing an RM-Plan, but the Center urges vendors to minimize the total number of changes and to confine change requests to the beginning of each rating maintenance cycle. A change request includes a copy of relevant sections of the RM-Plan with all proposed changes shown by change bars, plus a copy of the entire plan with the changes integrated into the text. The latter becomes the operative RM-Plan when approval is granted. 
All RM-Plan changes must receive Center approval regardless of their nature. On receiving a change request, the TPOC determines the scope of the Center review based upon the magnitude and implications of the proposed change(s). The TPOC can grant immediate approval of a change that is very minor or unavoidable (such as a reassignment of program responsibilities due to loss of a VSA). In all cases, however, the old RM-Plan remains in force until the change is approved and documented on the Center's Dockmaster system. 
RM-Plans are intended to be current but not release-specific. 
This distinction becomes relevant when successive product releases overlap in terms of development, i.e., when work starts on version N+1 before the code freeze for version N. In such cases, a single RM-Plan describes the vendor's RAMP process for all work on the product. The RM-Plan may reference specific product versions when describing VSA responsibilities, thus creating a need to update the plan periodically; but this is similar to cases in which VSA assignments are based upon specific product changes or other transient factors. The single-plan format applies unless there is a branching of the product, i.e., a situation in which version N includes changes that are not contained in version N+1, as well as vice versa. If the Center allows RAMP coverage of both branches, the vendor must maintain a separate RM-Plan for each. 
The RM-Plan tells how the vendor will accomplish all the tasks and achieve all the results described previously in sections 3, 4, and 6. The RM-Plan cannot state exhaustively how security analysis will be conducted and cannot guarantee that errors will never occur. However, the plan describes the vendor's procedures and safeguards in sufficient detail to constitute an essential part of RAMP assurance. 
While the format of individual RM-Plans may vary, a vendor's RM-Plan must address the following topics. Each of these topics is discussed in the subsections that follow. 
A. The product and its configuration. 
B. Security analysis. 
C. Configuration control. 
D. Collection and verification of evidence (configuration accounting and RAMP auditing). 
E. Compliance with Criteria interpretations. 
F. Presentation and defense of security analysis and product evidence. 
G. VSA responsibilities and program administration. 
H. Vendor response to failures. 
I. Numbering and retirement of product versions. 
J. Management of the RM-Plan. 
An RM-Plan must begin with a description of the rated product and all its components. This description should address all elements of the TCB in specific terms. It should also cover business aspects of the product such as control over the distribution of documentation. 
The RM-Plan describes how configuration identification has been performed. The plan should discuss the vendor's approach and objectives in decomposing the system, and should describe system elements in sufficient detail to show compliance with the configuration identification requirements listed in Section 3. 
There should be commentary on any special implications of the system identification for configuration control. The plan specifies the naming conventions used for configuration items (CIs) and for changes to CIs. Policies regarding the creation of new CIs for revised products should also be discussed. 
A startup RM-Plan includes a development process timetable, indicating when submissions of evidence are anticipated, and a future change analysis discussing the expected evolution of the product. As in the RMR for a completed RAMP cycle, the future change analysis should cover at least the first two cycles or 18 months of RAMP, whichever is longer. The Center assesses the expected changes and expresses a judgment by way of the RM-Plan approval that the product rating can probably be maintained through the initial revisions. 
The RM-Plan states the vendor's policies and procedures for security analysis in as much detail as possible. It describes security analysis and related design activity on a task-by-task basis, from identifying TCB effects through developing new tests and reporting on the acceptability of changes. The plan should demonstrate clearly that the vendor understands and adheres to the concept of security dominance in product development. This part of the RM-Plan may or may not be integrated with discussion of the vendor's configuration control system, which covers the overall structure of change control and the participation of corporate groups in this process. 
The RM-Plan must describe the steps taken by the vendor in assessing the effects of product changes on the TCB. This description covers methods of establishing indirect TCB effects as well as effects due to interrelationships among security features. The plan should reference any generic procedures used such as regression testing. There should be clearly stated arrangements for identifying any cumulative effects due to multiple product changes and/or collateral modifications entailed by changes. These arrangements are especially critical when security analysis and system design tasks are spread among several operating groups. 
The RM-Plan then describes the principles and procedures followed by the vendor in establishing acceptable designs for product changes and determining when changes cannot be implemented for security reasons. If no single description of this process is adequate, the plan can reference various categories of product changes and show how the process operates for each. There should be explicit discussion of the relationships between security analysis and the pursuit of other design objectives. 
A section of the RM-Plan must address the development and application of system tests as an element of security analysis. This discussion covers: the vendor's general testing policies; the determination of test adequacy as affected by product changes; the guidelines followed when modifying or creating tests; and the vendor's procedures for updating the test plan on the basis of security analysis findings. 
The RM-Plan summarizes the vendor's criteria and methods for concluding that a change is or is not acceptable under the TCSEC and describes how these conclusions are documented and forwarded for Configuration Control Board (CCB) review. The plan must demonstrate that the security analysis yields adequate RAMP evidence in the form of recorded analytical findings and support for all decisions affecting the product. 
As established in Section 3, configuration management is the framework for reviewing, implementing, and documenting the conclusions of security analysis. The portion of the RM-Plan on configuration control presents the vendor's business plan for accomplishing these objectives. 
A vendor developing a startup RM-Plan may find it convenient to work incrementally from existing practices. First, the vendor's existing configuration management system is modeled and evaluated against the conceptual requirements of RAMP discussed here in Section 3. The vendor revises the model by identifying needed elements and finding the most harmonious ways of including these elements within the present business context. The vendor then evaluates the revised model against the procedural requirements and VSA responsibilities outlined in Section 4. Functional equivalents of the SIR, ECO, CCB, and CRB are identified. If there is no full equivalent for one of these entities*e.g., no central authority that can be designated as the CCB*the vendor overcomes the deficiency by building upon present functions with as little disruption as possible. Similarly, the vendor seeks to identify persons who can serve effectively as VSAs in their present corporate positions (and who are qualified and available for VSA training). Only if such persons are unavailable does the vendor consider restructuring groups and reassigning personnel to achieve adequate VSA involvement. 
The RM-Plan must present a unified discussion of configuration control centering upon the vendor's business model as revised. The discussion should trace the course of events for a product change from its entry into the RAMP process as a SIR through its final approval and incorporation. 
The plan should explain the preliminary screening of changes for TCB effects, if conducted as a separate task, and describe the vendor's safeguards against incorrect categorization of changes. The plan shows how product changes that lack TCB effects are routed through the various design and implementation steps and change reviews. The RM-Plan then presents the detailed discussion of security analysis for changes affecting the TCB, if this discussion has not already been provided. The vendor indicates which operating groups conduct the security analysis and to what extent the VSA or VSAs participate in each aspect. (Coverage of the VSA role by the RM-Plan is discussed further below.) 
The RM-Plan should describe in specific terms how the CCB will coordinate the security and design analyses and will review system changes. The discussion addresses the composition of the CCB, the lines of authority among its members, the nature of its deliberations, and the manner in which the CCB assures security dominance in the product development process. Other topics are the power of the CCB to influence security analysis, the quality control steps involved in CCB review, the ability of the CCB to request additional information, and the disposition of product changes that fail to receive CCB approval. The RM-Plan should describe VSA membership and participation in the CCB, and the ability of the responsible corporate officer to veto a CCB approval when requested by the VSA. 
The RM-Plan should discuss the manner in which ECOs are generated and what they contain. The relevant data include: who prepares ECOs; the granularity of ECOs; the conditions under which multiple ECOs are used to effect a given change; the level of detail at which ECOs direct implementation tasks; the instructions in ECOs for testing implemented changes; any quality control procedures for ECOs; and the manner in which the CCB controls the production of ECOs. The RM-Plan should also indicate the role of ECOs in the vendor's record-keeping system. 
The RM-Plan describes the vendor's procedures for assuring that all approved changes are implemented correctly and that only these changes are made. The plan should discuss the structure of the implementation and testing groups, indicating the degree to which the testing function is conducted independently. The description of testing procedures should mention interactions with the design group (outside the ECO process) on the subjects of test adequacy, test development, and test results. The plan should also summarize briefly the management of the system code, e.g., the use of working copies to implement and test changes. 
The RM-Plan must specify the nature and operation of the Configuration Review Board (CRB) as described above for the CCB. The plan then discusses the final review process in terms of: the information delivered to the CRB on each implemented change; the quality control procedures utilized by the CRB to assure that the implementation is correct; the means of verifying that no system modifications have occurred other than the approved change; and the CRB policies for granting final approval or disapproval. Any exceptions to the review process should be noted. The RM-Plan describes the removal of disapproved changes from the product and the policies for returning such changes to an earlier stage of assessment. 
The RM-Plan must acknowledge any special limits upon configuration control. For example, if the vendor's product development activities take place at more than one site, the RM-Plan states what aspects of RAMP occur at each site and how central coordination is achieved. 
RM-Plans for layered products must describe specifically how the vendor will deal with the involvement of more than one company in producing the product. There is no compromise in the required level of RAMP assurance to accommodate layered products. The vendor demonstrates full configuration management cognizance, meaning that the vendor has evidence on the base product and its evolution comparable to the evidence required by RAMP for an in-house product. The vendor's RM-Plan describes in detail how this evidence is obtained, covering the nature of security analysis and the existence of any cooperative arrangements among producers. 
The RAMP process essentially yields three categories of product evidence: 1) the findings of security analysis, with support for all conclusions from that analysis; 2) the records from configuration control of the design phase, from SIR receipt through CCB review and ECO issuance; and 3) the configuration control records for the implementation phase, covering test results, test documentation, and verification of changes by the CRB. Ideally, there should be a unified configuration accounting system that embraces all of this information. Vendors entering RAMP may find, however, that the first category of evidence overloads existing configuration accounting systems because of the extensive commentary on security analysis findings and decisions. An acceptable solution is to establish supplementary information files with clear linkages to the configuration management data via pointers and cross-references. 
The RM-Plan must include an overall description of the vendor's record-keeping system, covering basic facts such as where the master version of the code is stored and how it is protected from unauthorized modification or use. The discussion lists the major database elements and notes any associated divisions of activity. (For example, the recording of information for system changes might be distinguished from the management of system documentation, tests, tools, test documentation, etc.) The plan describes how the vendor can determine the status of proposed and approved changes and can locate any supporting information. 
The RM-Plan then revisits the entire configuration control process and states the documentation requirements associated with each step (unless documentation has already been covered in the section on configuration control). There should be one or more reporting tasks associated with almost every element of a rating maintenance model such as shown earlier in Figure 3. In each case, the RM-Plan must describe: what information is recorded; where it is recorded; who is authorized to store and retrieve information; and what steps are taken to assure that information is accurate and comprehensive. The plan also discusses the uses of this information in the configuration control process for review and approval purposes. 
The Center recognizes that there may be a time granularity below which the system code, documentation, tests, and test documentation cannot be maintained on a synchronous basis because of lags in the updating process. The RM-Plan should estimate the duration of configuration accounting lags and describe any necessary steps to avoid problems from this source. 
The RM-Plan must address the RAMP audit function and the VSA role in this function. The plan must establish configuration audit procedures for verifying compliance with every configuration control and configuration accounting requirement, and for checking the adequacy of all associated evidence. The plan should describe the security analysis portion of the RAMP audit in terms of: the procedures for sampling SIRs; the number of SIRs investigated; and the standards for assessing the adequacy of security analysis and related documentation. The RM-Plan should also state the vendor's intended schedule of RAMP audits. The Center does not impose a uniform requirement in this regard because of the widely varying circumstances encountered, with the exception that at least one RAMP audit must occur per RAMP cycle. 
The RM-Plan must explain in detail the vendor's policy for complying with Criteria interpretations as they occur. The Center's recommended guidelines for such a policy have been discussed in Section 4. The objective is to provide the maximum compliance with interpretations consistent with a vendor's unique ways of doing business. Center approval of the RM-Plan is contingent upon attaining this objective. The policy statement in the RM-Plan should refer to the product revision cycle (i.e., the maximum number of cycles that can elapse before compliance occurs) and should also include calendar time as a factor if the revision schedule is variable. 
Section 6 has described the contents of the Rating Maintenance Report (RMR) and other documents submitted by the vendor to the Center at the end of each RAMP cycle. The RM-Plan should discuss briefly how these documents are prepared and how they will be used to defend the product, the security analysis, and the configuration management process before the TRB. 
The new material in any given RMR consists primarily of the evidence summaries for product changes. (See Figure 5 in Section 6.) The RM-Plan should describe the contents of these summaries for product changes that do and do not affect the TCB. The summarization process should be discussed with reference to the extent of VSA involvement, the configuration accounting files used, and the vendor's ability to prepare evidence summaries while other product changes are still under way. The RM-Plan should estimate the time delay between the end of product changes and the submission of an RMR to the Center for review. 
Regarding the defense of evidence, the RM-Plan should indicate which VSA or VSAs will represent the product at the next evidence submission and what provisions will exist for supplying evidence not contained in the RMR. Rough estimates should be given for the number of hours or days needed to comply with various types of information requests by the TRB. 
The RM-Plan must establish the VSA and responsible corporate officer roles in very specific terms. The required topics include: the qualifications and corporate position of the responsible corporate officer and the VSA or VSAs; the ability of the responsible corporate officer to support RAMP and the VSA function; the division of technical responsibilities among multiple VSAs, if used; and the extent of VSA involvement in every individual RAMP activity. The plan normally presents the task-by-task description of VSA duties as an integral part of the material on configuration control and collection of evidence. 
The RM-Plan names the person or persons occupying the VSA role and summarizes briefly the qualifications and experience of each. Any person representing the product as a VSA must have completed the Center training program. (As noted earlier, the approval of an RM-Plan confers Center recognition upon the VSAs referenced in the plan as product representatives.) The description of each VSA's corporate position should cover both line management and matrix management responsibilities. Any intended use of contractors or part-time employees as VSAs should be noted and explained. 
There should be a general statement of the vendor's strategy for assuring that the VSA or VSAs can: track all aspects of the revision process; confirm the findings of security analysis; influence product changes; assure the accuracy and completeness of evidence; and represent the product effectively to the Center. If multiple VSAs are utilized, the RM-Plan explains the reasons for this approach and describe the primary areas of VSA responsibility in such a fashion that the Center can associate one and only one VSA with each element of the RAMP process. 
The task-by-task description of VSA duties must cover for each activity in RAMP: 1) the share of work conducted personally by a VSA; 
2) the extent of VSA supervisory authority over the given task; 3) the ability of a VSA to influence how work is done and what outputs are produced; 4) the arrangements whereby a VSA can evaluate the adequacy of procedures and accuracy of data; and 5) the terms of VSA access to all information used in and generated by the task. 
The RM-Plan should emphasize VSA involvement in the CCB function, the CRB function, the configuration audit, and the presentation and defense of evidence. The plan should name the VSA who serves as a CCB member and show how this function allows the VSA to control product changes through direct input to CCB decisions and through the veto power of the responsible corporate officer. VSA involvement with the CRB is discussed similarly. The plan describes VSA responsibilities for producing the RMR and representing the product to the TRB. It names the VSA or VSAs who serve as configuration auditor(s) or audit supervisors. The RM-Plan must confirm that VSAs have access to Dockmaster and are responsible for tracking Criteria interpretation activity. 
The RM-Plan must describe how the responsible corporate officer will support the RAMP process and serve as the point of vendor accountability to the Center. This description covers: the power of the responsible corporate officer to make decisions and corporate commitments on behalf of RAMP; the extent of responsible corporate officer supervisory authority over the VSA(s) and over the operating groups involved in RAMP tasks; the influence of the responsible corporate officer over product changes; the role of the responsible corporate officer as the vendor's contact with the BPOC; and the ability of the responsible corporate officer to influence the corporate response to failures in the product or the RAMP process. As described in Section 6, the responsible corporate officer must be in a position to assume full responsibility for the content of RMR submissions. 
The RM-Plan must name the lead VSA, if there are multiple VSAs, and describe all lines of authority among the responsible corporate officer, the lead VSA, and other VSAs. There should be an overview of RAMP program administration showing how RAMP fits into the corporate management structure. The RM-Plan should include a corporate organization chart and a personnel directory listing the department and job title of all persons who might contact the Center on the subject of RAMP. The organization chart should be abbreviated horizontally by showing only the portion of the corporate hierarchy that contains the responsible corporate officer, the VSAs, all CCB and CRB members, and all operating groups with major involvement in RAMP. 
The RM-Plan must describe any and all exception handling procedures that may be used in the development of the product. Exception handling refers here to actions outside the normal cycle of releases, not exceptions to RAMP practices. Under no circumstances are interruptions in configuration management allowable. 
Specifically, the RM-Plan must address the vendor's response to product and process failures. The failures that can occur for a product in RAMP fall into three categories, as follows. 
Bug: Improper execution of an acceptable design. 
Flaw: Incorporation of an inadequate design decision. 
Breakdown of process: Deficiency in the security analysis and/or configuration management procedures that confer RAMP assurance. 
These failures can have widely varying impacts upon the responsible vendor, the user community, and the product rating. Bugs and flaws are of greatest immediate concern to users. However, breakdowns of process tend to have the greatest long-term impacts on product ratings and continued RAMP applicability. Errors can usually be located and corrected if the process remains pure, but RAMP assurance may not be recoverable if the process fails. Section 8 discusses the response of the Center to these types of failures. 
The primary focus of exception handling is the management of system bugs. The Center recognizes that at the C1 through B1 rating levels (which are features-oriented rather than assurance-oriented), a product may contain implementation errors that are undetected by evaluation and that may be exploitable under some circumstances. It is not acceptable to pass responsibility for vulnerability management on to system users. Vendors should therefore plan ahead for the possibility of bugs and should develop procedures for correcting bugs with minimum delay and risk to users. 
The following are suggested steps to deal with a potentially exploitable bug once identified. The vendor: 
1) immediately deploys a repair and recovery team to analyze and solve the problem 
2) contains information regarding the bug in order to minimize risk to operational systems 
3) provides immediate notice to the TPOC so that the Center can take any necessary steps to assure the protection of system users 
4) undertakes the replacement or repair of all operational systems that contain the bug 
5) reports progress to the Center on a weekly basis 
6) packages the repair or replacement in such a fashion that the exploitable bug is not easily determinable from the repair distribution. 
The RM-Plan must explain how these and related tasks will be accomplished in case of product failure, and must state corporate policies for using exception-fix procedures and for correcting bugs in subsequent scheduled product releases. 
The RM-Plan must also describe the vendor's internal procedures for restoring the RAMP process if there is a process failure (and if the Center determines that the process can potentially be restored). These procedures include: establishing the precise nature of the error or breakdown and the reasons for its occurrence; tracing the full ramifications of the problem for all affected product versions; conducting security analysis to establish corrective measures and verify product trust; and reestablishing the unbroken trail of evidence linking to the evaluated product. 
A product release that includes any correction for a bug or flaw becomes a different product from the standpoint of the Center and the user community. The vendor must develop a product identification system that reflects this fact. A favorable approach is an alphanumeric system in which the numeric portion (typically involving decimals) denotes the product version as released and the letter suffix denotes corrections. For example, version 1.0 might be the original product subjected to evaluation; versions 1.1, 1.2, and so on might be successive releases in RAMP; and versions 1.0a and 1.1a might be the first two versions after a correction has been added. This system yields a two-dimensional product flow as illustrated in Figure 6. 
In this example, a system bug is discovered after the second version (1.1) has been released. The development of a correction for this bug yields two new products, 1.0a and 1.1a. Then another bug is identified after version 1.2 has been released. This bug is corrected in 
1.1 and 1.2, yielding products 1.1b and 1.2b, but is not corrected in 1.0 because the original product version has been retired (as defined below). The two diagonal arrows in the diagram indicate that each bug correction is incorporated in the next scheduled release. Every RM-Plan should establish a product identification system that has this degree of flexibility and comprehensiveness. 
The RM-Plan should also indicate that the vendor will inform the Center whenever a rated product version is retired. Retirement is defined in this context as the point at which a vendor no longer offers a product version for sale and no longer provides bug fixes and related services for that version. The Center needs to be informed of retirement decisions so that the affected products can be shifted to a separate section of the EPL. 
Previous discussion has suggested why RM-Plans may change 
occasionally and how changes are effected. Due to the possibility of change, the RM-Plan must describe how the plan itself is managed. This discussion should indicate how the vendor establishes a need to change the RM-Plan; how the vendor formulates and proposes specific changes; and how the vendor assures compliance with RM-Plan changes when in place. 
Figure 7 depicts graphically various processes from the initial evaluation and VSA training to the establishment and application of RAMP for a product. (Figure 7 is an expansion of Figure 2). The starting points for establishing RAMP are the original product and the training of vendor representatives as VSAs. The vendor develops an RM-Plan and obtains approval for the plan before the Center starts the phase of product evaluation. Figure 7 emphasizes that the RAMP process builds upon an evaluated product and upon the evidence yielded by evaluation. 
The RM-Plan establishes a configuration management framework for the analysis, design, implementation, and approval of product changes. The VSAs participate in these rating maintenance actions and assure that security concerns dominate all decisions affecting the product. The outputs of rating maintenance consist of approved product changes and evidence supporting the changes. The VSAs summarize this evidence in an RMR, which is submitted to the TPOC and reviewed by the Center community. The TRB then receives and reviews the RMR, examines the VSAs on the evidence, and recommends that the product rating be extended (or not extended) to the new release. The cycle ends with approval or disapproval of the rating by the Chief of the Product Evaluation Division and listing of the new approved release on the EPL. The TPOC is the interface between the vendor and the Center in all technical communications except the interim and aperiodic reviews and the TRB examination. (The diagram omits the responsible corporate officer and BPOC roles.) 
There is no fixed limit on the number of revision cycles that can be covered by an application of RAMP. The termination of a RAMP process can be either voluntary or involuntary from the vendor's standpoint. A vendor might choose to terminate RAMP because the product is being discontinued; because no further revisions are planned; or because rating maintenance is not considered essential for further releases. 
Applications of RAMP tend to have a natural life span ending with the vendor's introduction of a replacement product that requires evaluation and a new RAMP process. Voluntary exits from RAMP are usually pre-arranged to occur at the end of a rating maintenance cycle. 
The intermediate cases are situations in which a vendor desires to continue RAMP but needs to implement product changes that RAMP cannot cover. Given a commitment to the changes, the vendor must decide whether to terminate RAMP permanently or undergo reevaluation to start another RAMP process. The requirement for such a choice might be established by the VSAs when analyzing changes during a revision cycle; by the vendor when planning future changes; or by the Center when reviewing the vendor's future change analysis in an RMR. Advance notice of the decision point obviously benefits the vendor by minimizing wasted effort and allowing timely placement of the product in the queue for a reevaluation (if future rating maintenance is intended). Consequently, the vendor should supply as much information as possible to the Center in each future change analysis. The Center attempts to provide an interval of at least one revision cycle within which the vendor can seek reevaluation while rating maintenance is still under way. However, the Center cannot guarantee that this outcome will occur, or that any given rating maintenance cycle will be successful. 
Involuntary termination of RAMP is associated with failure in the product or process. Failures can be identified through program reviews, TRB examinations, or other mechanisms. The Center response to an identified failure depends upon the nature of the problem and how it occurred. 
The Center terminates permanently the use of RAMP for a product if the vendor has knowingly misrepresented any aspect of the product or its RAMP process. The VSA or VSAs responsible for the misrepresentation will no longer be recognized by the Center as representatives of any product. The Center permanently lifts the rating of the product release for which the misrepresentation occurred and the ratings of any later versions dependent upon that release for rating maintenance. Furthermore, the Center activates the aperiodic review process to investigate the possibility of misrepresentations or other errors in earlier releases. The product rating is then rolled back at least to the earliest known breakdown of RAMP assurance. 
When an inadvertent failure is identified, the Center may or may not allow the vendor to rebuild RAMP assurance and continue the rating maintenance process. If a failure is identified during a TRB review, the vendor may or may not be allowed to fix the failure and resubmit the product depending on the nature of the failure. A vendor usually is permitted and able to fix a bug (implementation error) while rating maintenance is under way. The Center treats a system flaw (design error) similarly to a bug unless its correction requires an architectural change that RAMP cannot accommodate. The Center does not approve any new ratings until all identified bugs and flaws have been eliminated, but normally does not suspend past ratings so long as the RAMP process is unimpeached and the vendor makes every reasonable effort to protect the user community. A breakdown of process, such as a loss of product evidence, tends to have the most serious consequences for rating maintenance even if no deliberate malfeasance is involved. The Center usually lifts the ratings for all affected releases at least temporarily, and determines on the basis of individual circumstances whether and how the vendor can reconstruct the RAMP process. 
There are no sanctions in RAMP that apply retroactively to products evaluated by the Center. Choosing to participate in RAMP cannot place an existing product rating in jeopardy. Thus, a vendor's decision to initiate a RAMP process can only create the following risk. There is a chance that the net costs incurred to participate in RAMP will not yield the desired ratings for product revisions, and hence may be viewed as financial losses. 
Section 1 has suggested the ways in which RAMP participation can create net monetary costs for a vendor. A major determinant is the extent to which a vendor's business practices need to be altered to meet RAMP requirements for security analysis and configuration management. When evaluating whether these costs and adjustments are supportable, a vendor should be aware of the following considerations. 
1) The chance that an application of RAMP will be unsuccessful can be greatly reduced by approaching the program constructively and conscientiously. This means allocating the time of highly capable and experienced personnel to the RAMP process; applying scrupulously the RAMP principles of security dominance and configuration management; and keeping the Center as well-informed as possible about upcoming product changes. 
2) The net costs of creating and pursuing a RAMP process can be viewed as an investment with potential returns extending well beyond the given product. The capabilities developed in one RAMP experience are valuable not only for other applications of the program but also for the creation of new trusted products from start to finish. 
Regarding the second point, the value of in-house security wisdom is increasing very rapidly for computer vendors. Various factors are making access to the expanding market for trusted systems more and more dependent upon the availability of this resource. RAMP is the appropriate context and focus for developing security analysis capability. 
This appendix summarizes the vendor's and the Center's requirements for RAMP. These requirements are linked to the timing of the product evaluation and are listed in approximate order of occurrence, under the phase of the evaluation process in which they occur. A vendor failing to satisfy these requirements loses the opportunity to participate in RAMP until such time as the product in question is reevaluated. The Center reserves the right to deny a rating and/or discontinue the Rating Maintenance Phase at any time. 
1. Vendor establishes an intent to participate in RAMP in the evaluation package/proposal for a given product. 
1. The vendor must identify and maintain a responsible corporate officer. The responsible corporate officer represents the vendor in administrative matters, serves as the point of vendor accountability to the Center, is able to make decisions and corporate commitments on behalf of RAMP, and supports the technical role of the VSA. 
2. The vendor must complete training of one or more Vendor Security Analysts (VSAs) before implementation of the vendor's Rating Maintenance Plan but not later than completion of the IPAR. The vendor must provide for VSA access to the Center's Dockmaster computer system at the time VSA training begins. Whenever a vendor uses more than one VSA, a lead VSA will be identified by the vendor. 
3. The Center will provide RAMP training for VSAs. 
4. The vendor must develop, have approved, and implement a 
Rating Maintenance Plan (RM-Plan). The RM-Plan must be approved by the Center prior to its implementation but not later than completion of the IPAR. The approved RM-Plan must be implemented before development begins on the version that will supersede the evaluated version. 
5. The Center will review the vendor's RM-Plan for purposes of approving the RM-Plan. 
1. The vendor must maintain a responsible corporate officer. 
2. The vendor must maintain one or more Center-trained Vendor 
Security Analysts (VSAs) once the vendor's RM-Plan has been implemented. The vendor must provide for VSA access to the Center's Dockmaster computer system. Whenever a vendor utilizes more than one VSA, a lead VSA will be identified by the vendor. 
3. The Center will provide RAMP training for VSAs. 
4. The vendor must complete implementation of the 
Center-approved Rating Maintenance Plan (RM-Plan) and must follow the business practices outlined in the RM-Plan. The RM-Plan must be implemented before development begins on the version that will supersede the evaluated version. Any changes to the RM-Plan must be approved by the Center and must be made according to the provisions within the approved RM-Plan. 
5. The vendor must conduct, for his own purposes, an initial 
RAMP audit to assure that security feature functionality and assurances are being maintained by adherence to all the procedures established in the vendor's approved RM-Plan. 
6. The Center evaluation team will review the results of the vendor's initial RAMP audit to ensure the vendor's RAMP process follows the procedures outlined in the vendor's RM-Plan. 
7. The Center assigns a Technical Point of Contact and a Business Point of Contact before completion of the evaluation phase. The TPOC advises and coordinates the use of RAMP for the given product. The BPOC handles administrative and programmatic aspects of the process. 
1. The vendor must maintain a responsible corporate officer. 
2. The vendor must maintain one or more Center-trained Vendor Security Analysts (VSAs) once the vendor's RM-Plan has been implemented. The vendor must provide for VSA access to the Center's Dockmaster computer system. Whenever a vendor uses more than one VSA, a lead VSA will be identified by the vendor. 
3. The Center will provide RAMP training for VSAs. 
4. The Center maintains a Technical Point of Contact and a Business Point of Contact. 
5. The vendor must provide product instruction for the Center Technical Point of Contact, as needed throughout the Rating Maintenance Phase. This is to include product documentation, vendor provided classes, and hands-on system access time. 
6. The vendor will provide quarterly informal status reports to the Technical Point of Contact via the Center's Dockmaster system throughout the Rating Maintenance Phase. 
7. The vendor must conduct, for each RAMP cycle, at least one RAMP audit to assure that security feature functionality and assurances are being maintained by adherence to all the procedures established in the vendor's approved RM-Plan. 
8. The Center Technical Point of Contact will review the results of the vendor's RAMP audit to ensure the vendor's RAMP process follows the procedures outlines in the vendor's RM-Plan. 
9. The vendor will submit concurrently to the Center the following documents for each version of an evaluated product for which the vendor desires to have the rating maintained via RAMP: 
a) Rating Maintenance Report (RMR) 
b) Rating Maintenance Plan (RM-Plan) with change bars 
c) Final Evaluation Report with change bars 
d) Final Evaluation Report with integrated changes 
e) Proposed product description for EPL 
The documents intended for public release are the final evaluation report with integrated changes and the proposed product description for EPL. 
10. The Center will review the vendor's documents for purposes of extending the rating to the specific release and for placement on the Evaluated Products List. 
11. The vendor's RAMP process is subject to two types of reviews (Interim Reviews and Aperiodic Reviews) by the Center. Both types of program review have the purpose of assuring that security feature functionality and assurances are being maintained by adherence to all the procedures established in the vendor's approved RM-Plan. 
BPOC - Business Point of Contact (Center). 
CCB - Configuration Control Board. 
Center - National Computer Security Center. 
CF - Code Freeze. 
CI - Configuration Item. 
COMPUSEC - Computer Security. 
CRB - Configuration Review Board. 
Criteria - Same as TCSEC. 
Dockmaster - A Center computer system serving 
the evaluation community. 
ECO - Engineering Change Order. 
EPL - Evaluated Products List. 
Evaluated Product - A product version that has undergone evaluation by the Center. (By convention, excludes products assigned D ratings. An evaluated product is always a rated product, but the reverse is not always true for products in RAMP.) 
FER - Final Evaluation Report. 
Interpretations - Published Center Interpretations of the TCSEC. 
IPAR - Initial Product Assessment Report. 
PTR - Preliminary Technical Report. 
RAMP - Rating Maintenance Phase. 
Rated Product - A product version with a TCSEC rating and a listing on the EPL, obtained either through evaluation or RAMP. (By convention, excludes products with D ratings.) 
RM-Plan - Rating Maintenance Plan. 
RMR - Rating Maintenance Report. 
SIR - Service Improvement Request. 
TCB - Trusted Computing Base. 
TCSEC - Department of Defense Trusted Computer System Evaluation Criteria (DoD 5200.28-STD); the Criteria against which products are evaluated to establish security ratings. 
TPOC - Technical Point of Contact (Center). 
TRB - Technical Review Board (Center). 
VSA - Vendor Security Analyst. 
Department of Defense Trusted Computer System Evaluation Criteria, December 1985 (DOD 5200.28-STD). 
Brown, Leonard, R. "Specification for a Canonical Configuration Accounting Tool," Proceedings of the 10th National Computer Security Conference, 21 September 1987, p. 84.