A Guide to the Procurement of Trusted Systems: An Introduction to Procurement Initiators on Computer Security Requirements - Volume 1 of 4
Table of Contents
NCSC-TG-024
Volume 1/4
Library No. 5-239,669
Version 1
This guideline, volume 1 of 4 in the series, "A Guide to Procurement of Trusted Systems," is written to help facilitate the acquisition of trusted computer systems in accordance with DoD 5200.28-STD, "Department of Defense Trusted Computer System Evaluation Criteria." It is designed for new or experienced automated information system developers, purchasers, or program managers who must identify and satisfy requirements associated with security-relevant acquisitions. Information contained within this series will facilitate subsequent development of procurement guidance for the Federal Criteria. This series also includes information being developed for certification and accreditation guidance. Finally, this introductory guideline addresses both the complex acquisition process and the many regulations, standards, and criteria to be satisfied in providing a secure system.
There is a large body of national policy established in the form of regulations, directives, Presidential Executive Orders, and Office of Management and Budget (OMB) Circulars that forms the basis for procedures to handle and process Federal information, particularly classified information. These are presented and discussed in Appendix A, "Historical Basis."
The business of computers, security, and acquisitions is complex and dynamic. As the Director, National Computer Security Center, l invite your recommendations for revision to this technical guideline. Our staff will work to keep it current. However, experience of users in the field is the most important source of timely information. Please send comments and suggestions to;
National Security Agency
9800 Savage Road
Fort George G. Meade, MD 20755-6000
ATTN: Standards, Criteria, and Guidelines Division
December 1992
Patrick R. Gallagher
Director
National computer Security Center
This document has been produced under the guidance of Major (USA) Melvin L. DeVilbiss, assisted by CPT (USA) Michael Gold and Mary Whittaker, from the National Security Agency. Much of this document is taken directly from "Computer Security in Acquisitions (Draft)," prepared by the Air Force Intelligence Command (AFIC), Air Force Cryptologic Support Center, Directorate of Securities (AFCSC/SR), under the direction of Captain (USAF) Bob Pierce. Initial ideas for the Air Force draft document were those of TRACOR, Inc. Interpretation and adaptation as a DoD handbook was accomplished by Howard Johnson, Information Intelligence Sciences, Inc.
The following organizations were particularly helpful in providing constructive reviews and advice: Harris, Grumman Data Systems, CTA, Inc., Seidcon, Naval Computer and Telecommunications Command, Naval Electronic Systems Security Engineering Center, U.S. Army Information Systems Engineering Command, GSA, MlTRE, Federal Emergency Management Agency, and Logicon.
Special thanks to Carol Oakes, Senior Technical Editor, MITRE, for her assistance with final editing of this guideline.
ii
LIST OF FIGURES
Figure 1-1 How to Use This Guideline.... 2
Figure 1-2 Layers of Regulation 3
Figure 2-1 Key Interactions 9
Figure 3-1 Trusted Computer System Evaluation Criteria 24
Figure 3-2 Security Protection in the Software Development Process 31
Figure 6-1 Certification and Accreditation Processes 65
Figure 7-1 Acquisition Milestones and Phases 88
LIST OF TABLES
Table 1-1 Procurement Guideline Series 1
Table 1-2 Guideline Overview 4
Table 2-1 RFP Organization 18
Table 3-1 Division D, Minimal Protection 24
Table 3-2 Division C, Discretionary Protection 25
Table 3-3 Division B, Mandatory Protection 25
Table 3-4 Division A, Verified Protection 26
Table 4-1 Security Modes and Minimum Division/Class 45
Table 4-2 Input to the System Threat Assessment Report (STAR) 48
Table 4-3 Suggested Changes and Additions to the DoD 5000.2-M
STAR Guidance to Adapt to AISs 49
Table 5-1 DT&E Objectives 56
Table 5-2 OT&E Objectives 57
Table 5-3 Desired MOE/MOP Characteristics 59
Table 6-1 Risk Management Activity 64
Table 6-2 Supporting Documentation 67
Table 6-3 Supplementary Documentation 68
Table 6-4 Data Collection Sources 70
Table 6-5 Accreditation Supporting Documentation 73
xiii
This document is a guideline designed for those who must identify and satisfy deliverable data requirements associated with security-relevant acquisitions of trusted, stand-alone systems. It identifies what must be complied with, what must be read, what must be written, and what others must be instructed to write. The detailed acquisition process, coupled with the technical complexity of computers, security, and contracting, represents an unsolvable mystery for many. The goal of this document is to help clarify the complex issues.
The National Security Agency (NSA) wants to clarify the computer security aspects of the Department of Defense (DoD) Automated Information System (AIS) acquisition process. Therefore, it is producing the guideline series (shown in Table 1-1), of which this document is the first.
Table 1-1 Procurement Guideline Series
An Introduction to Procurement Initiators on Computer
Security Requirements (December 1992)
Language for RFP Specifications and Statements of Work - An
Aid to Procurement Initiators (To be published in 1993)
Computer Security Contract Data Requirements List and Data
Item Description Tutorial (To be published in 1993)
Row to Evaluate a Bidder's Proposal Document - An Aid to
Procurement Initiators and Contractors (To be published in
1993
National Computer Security Center (NCSC)-TG-004, "Glossary of Computer Security Terms," defines security terms used in this publication. DoD Instruction 5000.2, "Defense Acquisition Management Policies and Procedures," defines acquisition terms. DoD Instruction 5000.33, "Uniform Budget/Cost Terms and Definitions," defines budget terms.
This guideline is for use by all DoD agencies. It applies to AlS developers purchasers, or program managers who deliver systems to customers. It specifically supports acquisitions of systems from commercial-off-the-shelf (COTS) products on the Evaluated Products List (EPL).
Figure 1-1 shows how to use this document. The purpose of this document is to provide the Program Manager and the Security Manager a guide to the activities and the documentation in an acquisition of a secure system. This document will help those responsible to develop plans and procedures for acquisition of trusted, stand-alone systems. Specifically, it will help identify security-relevant data to be delivered by a contractor.
Chapter Titles Who They Should Help
General Information Introduction to Acquisition
The Acquisition Process (e.g., for security specialist)
Computer Security
Threat Risk Mgmt. Introduction to Security
Security Test & Eval. (e.g., for acquisition specialist)
Certification &
Accreditation
Guidance for Acquisition
Managing the Acquisition of of a Secure System
Secure Systems (e.g., for program and security
managers)
Figure 1-1 How to Use This Guideline
The second in this series of documents provides a way to specify security requirements accurately in a standardized way, while complying with current acquisition regulations. The Government decides the split of responsibility between the Government and the Contractor. Once documents the contractor is required to write have been identified, a Data Item Description (DID) can be chosen from the third document in this series. If a document is not available, the third document will also help tailor an existing DID to create the desired DID. The fourth document in this series provides a guide to evaluate contractor proposals addressing computer security (COMPUSEC). The fourth guideline is intended for the procurement initiator, but will also be helpful to the contractor preparing his/her proposal.
Most users will be building a Request for Proposal (RFP) and therefore will need to develop deliverable data packages. The security functional requirements must have been previously established.
The people reading this document will most likely be assigned to a Program Management Office (PMO) or System Program Office (SPO). These organizational elements are responsible for managing acquisition activities. The PMO/SPO could be a several hundred person organization, or it could be just one person. In either case, the principles and concepts are basically the same; only the scale might change.
This set of four acquisition documents does not address the complex acquisition of multiple security entity systems. The reason is that the DoD policy has not been finalized that addresses systems with combinations of EPL products and "built and certified" system entities, perhaps using different division/class criteria as requirements from DoD 5200.28-STD. Strong motivation exists to resolve the problem with an NSA-evaluated product on the EPL. Because this resolution cannot be guaranteed, these acquisition documents must deal with a single-system entity (called "the product" or "the system"). In this context, little difference exists between the terms "computer system" and "automated information system," both used here. Section 3.8, "Rationale for Single Entity Approach," presents the rationale for this approach. Chapter 5 addresses use of the EPL.
Regulations may be written for a major system acquisition, an AlS, a computer system, or only the software in a computer system. These entities must be thought of as a nested hierarchy. If the scope is a computer system, for example, then AS and major system regulations also apply. A similar situation exists in security. Regulations deal with information system security (INFOSEC), AlS security, and COMPUSEC. These entities are nested when applied to applications. Considering the system hierarchy and the security hierarchy, a situation exists that is illustrated in Figure 1-2. Thus, requirements for a COMPUSEC acquisition must consider, for example, DoD Instruction 5000.2, DoD 5200.1-R, DoD Directive 5200.28, Figure 1-2 Layers of Regulation DoD-STD-21 67A, and DoD 5200.28-STD.
This guideline has seven chapters, and three appendices. Each chapter contains pertinent references. The text focuses on the chapter's subject, incorporating both acquisition and security. Note that Chapter 2 primarily addresses the acquisition process, although it is sometimes placed in the context of security. Chapters 3 through 6 emphasize security, especially in Chapter 3, which addresses security functionality. The two topics finally merge in Chapter 7. Table 1-2 identifies chapters and objectives.
Table 1-2 Guideline Overview
Chapter l General Information - Introduces the guideline.
Chapter 2 The Acquisition Process - Provides an overview of the acquisition process. Identifies the major elements of financial management. It also briefly describes the most important documents to be referenced, produced, or requested when working on a security-related acquisition.
Chapter 3 Computer Security - Provides insight to trusted computing bases (TCBs) and other trusted protection. Discusses the various TCB divisions/classes and security policy.
Chapter 4 Threat Risk Management - Analysis, Design, and Implementation - Discusses the key aspects of risk management. Addresses the areas of sensitivity levels, risk assessment, risk analysis, and cost benefit analysis.
Chapter 5 Security Test and Evaluation - Addresses the full range of ST&E, single product evaluation, project inception, and system implementation. Also presents a simplified approach to generating contractor test plans.
Chapter 6 Certification and Accreditation - Covers the certification and accreditation processes. It also provides a useful list of documents required for a complete certification or accreditation package.
Chapter 7 Managing the Acquisition of Secure Systems - Discusses the management policy and objectives. Identifies how to prepare plans and conCepts. Provides an overview of all security activities associated with the life-cycle process.
This document will not answer all the questions or solve all of the problems encountered in an acquisition. Other sources follow.
Each chapter lists the most important references for the chapter's subject matter. Having a personal, current copy of many of the references is important. The documents will be referred to often. The "must have" list, referenced below in the last section of this chapter, is a good place to start.
Every major agency or organization has several offices that can be of assistance:
a. Each organization usually has a security focal point. Some offices specialize in most aspects of COMPUSEC. Start with a phone call to the Director's office and ask for a directory or a list of offices with names and phone numbers.
b. The investigative organization (e.g., security police) sometimes has experts in applicable areas.
c. Each organization normally has a contracting staff and a planning and budget management staff with expertise in the acquisition process.
d. The user should have a point of contact for the system or project.
When SCI information is involved, consult the supporting Special Security Officer (SSO) or Intelligence Staff Officer (ISO) within the organization with whom the responsibility has been delegated.
The SS0 can assist with the special clearances, handling, storage, marking, and other details required for SCI. The SSO should know how to meet Director of Central Intelligence (DCID) 1/16, "Security Policy for Uniform Protection of Intelligence Processed in Automated Information Systems and Networks," and Defense Intelligence Agency (DIAM) 50-4 "Security of Compartmented Computer Operations."
The SS0 will be able to assist in requesting an "intelligence community" threat summary related to an individual project. See Chapter 4, "Threat Risk Management," for more on this subject.
Other PMOs or SPOs are lucrative information sources. Contact the program offices for information on how they have handled similar requirements
If additional help is still needed, call or write NSA (at the address shown in the Foreword page of this guideline). This organization can usually put you in contact with the right person and get you back on track.
Very few PMOs or SPOs have a complete suite of reference material. There are, however, a few "must have" documents for all program offices. This document listing will help those new to acquisition, who are working on computer security in an acquisition environment. Appendix A contains a more complete list of historical documents. Working and agency/protection-specific bibliographies are provided in Appendix C at the end of this document.
a. DoD 5200.1-R, "Information Security Program Regulation" - This document is the basic DoD information security regulation, authorized by DoD Directive 5200.1.
b. DoD Directive 5200.28, "Security Requirements for Automated Information Systems (AISs)" - This document is the overall security policy document for DoD AlSs that process Classified, sensitive unclassified, or unclassified information, with the exception of certain standalone and embedded computers.
c. DoD 5200.28-STD, "Department of Defense Trusted Computer System Evaluation Criteria" - This document categorizes AISs into hierarchical classes based on evaluation of their security features and assurance for believing the security functionality has been achieved. It is often used to help state the security requirements for any ASs to guarantee satisfaction of a certain minimum risk level.
d. NCSC-TG-005, "Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria" - This document, also called the "TNI," interprets the DoD 5200.28-STD for networks.
e. NCSC-TG-009, "Computer Security Subsystem Interpretation" - This interpretation of DoD 5200.28-STD is used when a subsystem is to be added to a protected AIS to enhance its security. This document is useful in identifying subsystem security requirements.
f. NCSC-TG-024, Version-1 Vol. 1/4, "A Guide to Procurement of Trusted Systems: An Introduction to Procurement Initiators on Computer Security Requirements," (this guideline) Vol. 2/4, "A Guide to Procurement of Trusted Systems: Language for RFP Specifications and Statements of Work - An Aid to Procurement lnitiators," (draft)
Vol. 3/4, "A Guide to Procurement of Trusted Systems: Computer Security Contract Data Requirements List and Data Item Description Tutorial," (draft)
Vol. 4/4, "A Guide to Procurement of Trusted Systems: How to Evaluate a Bidder's Proposal Document - An Aid to Procurement lnitiators and Contractors," (draft)
g. DoD Directive 7920.1, "Life Cycle Management of Automated Information Systems (AIS)" - This document defines life-cycle phases and policy for AISs.
h. DOD Directive 5000.1, "Defense Acquisition" - This directive provides policy and an overview for integrating the efforts and products of 1) requirements generation, 2) acquisition management, and 3) planning, programming, and budgeting systems.
i. DoD Instruction 5000.2, "Defense Acquisition Management Policies and Procedures" - This instruction implements the regulations of DoD Directive 5000.1 and contains DoD acquisition management policies and procedures, replacing many past regulatory documents.
j. DoD Manual 5000.2-M, "Defense Acquisition Management Documentation and Reports" - This manual contains procedures and formats to be used to prepare various milestone documents and periodic status reports.
k. DoD-STD-2167A, "Defense System Software Development" - This software development regulation establishes requirements to be applied during acquisition, development or support of software standards.
i. DoD 7935-A STD, "ADS Documentation Standard" - This standard provides guidelines for the development and revision of documents for an automated information system.
m. "Model Framework for Management Control Over Automated Information Systems," President's Council on Management Improvement and the President's Council on Integrity and Efficiency, 1988 - This report identifies 55 requirements Federal managers should follow. This list is derived from the Financial Integrity Act of 1982, the Privacy Act of 1974, OMB Circulars A-I 23, A-I 27, and A-I 30.
n. "Information Systems Security Products and Services Catalogue," prepared by the National Security Agency - Complete editions are printed in January and July. Changed chapters from the basic document are reprinted as a supplement in April and October. A large part of Chapter 4, in this catalogue, contains the Evaluated Products List for Trusted Computer Systems. Many trusted system requirements can be effectively met, using existing evaluated products from this source document.
o. "Federal Acquisition Regulation" (FAR) and "DoD FAR Supplement."
p. Federal Information Processing Standard (FIPS) Publication (PUB) 73, "Guidelines for Security of Computer Applications," United States (U.S.) Department of Commerce, National Bureau (NBS) - Planning, development and operations of Federal computing applications requires protection because of the nature of the data or the risk and magnitude of loss or harm. This document addresses risk analysis, objective and vulnerability specifications, management of programming trusted computing systems, and contingency planning.
q. "Federal Information Resources Management Regulation," (FIRMR) General Services Administration (41 CFR 201).
THIS PAGE INTENTIONALLY LEFT BLANK
DoD acquisitions are worth billions of dollars each year. Nearly 98 percent of these acquisitions are small contracting efforts worth less than $25,000. That accounts for only 20 percent of DoD's procurement dollars. The other two percent of DoD's contract actions (those over $25,000) account for 80 percent of the dollars. The large dollar contracts bring with them a large number of people and requirements that the program manager must deal with efficiently and effectively. This chapter provides a brief overview of the acquisition process and the environment one can expect to encounter. It provides information on financial management concepts. It also introduces the major documents to be prepared during acquisition.
DoD Directive 5000.1, Part 2, discusses three separate decision making support systems: Planning, Programming and Budgeting (PPBS); Requirements Generation; and Acquisition Management. (See Figure 2-1, taken from that directive.)
Requirements Very Broad Performance Requirements
Generation Needs Objectives
System
Studies Prototyping Design & Test P
R
Acquisition Alternative Concept Stable Design O
Management Concepts Selection D
System U
Resource Requirements & Constraints C
T
I
Programming Affordability Affordability Firm Unit O
& Budgeting Goals Constraints Costs N
System
Figure 2-1 Key Interactions
PPBS is supported by three operational functions: 1) the Action Officer (AO) is the primary advocate of a particular program. He/she develops a Program Decision Package (PDP) and presents it to senior management. 2) The Program Element Monitor (PEM) is the functional staff advocate. The PEM guides and monitors PDPs through the PPBS process. When a PDP is approved, the PEM monitors and briefs its progress (e.g., quarterly). The AO needs to stay in contact with the PEM to ensure the latest information is available. 3) The Resource Advisor (RA) is the person in the SPO or PMO who monitors the use of resources on a day-to-day basis, helps develop fund targets, and prepares the annual budget submission.
The mission users are present in all acquisitions. They generate mission requirements and ultimately receive and use the item or services acquired. The user function may be represented by a functional area expert, a major organization (e.g., agency), or even a special office. The user sometimes maintains a liaison in the Program Office.
This function can be further divided into Program Management and Contract Management. 1) The program management function could have any of several names - PMO, SPO, or Program Office. In a large acquisition, the program management function is a separate organization staffed with specialists who are tasked to conduct the acquisition. In a small acquisition, it could be one person. 2) A contracting function is present in all acquisitions and usually includes a Contracting Officer and a Buyer. The contracting function may be located within the program management organization or within a special contracting activity. The Contracting Officer is the ~ person authorized to obligate the Government (i.e., negotiate, modify, and sign contracts). It is important to seek the Contracting Officer's advice and assistance early to avoid later problems.
A structured process of identifying financial requirements, obtaining funds, and allocating them to competing programs (so top priorities are satisfied) is called the PPBS. The PPBS is the official DOD resource management system and is described in DoD Instructions 7045-7 and 7045-14. The PPBS is a complex and continuous year-round process. It involves people from the President all the way down to individual organizations. The PPBS operates in both a top-down and a bottom-up mode. 1) In the top-down mode, high level DoD officials prepare policy and strategy documents. Those documents consider the threats to the worldwide national interests and define the strategy and objectives necessary to counter those threats. 2) In the bottom-up mode, a particular organization tracks every penny it spends. "Fund cites," noted on every document, involves a financial transaction (e.g., travel orders and contracts). The process is complicated, but it achieves visibility and accountability for every expense. The information collected is required by law to be rolled into successively broader accounting Categories and used for tracking appropriations, both for historical purposes and for planning future programs.
All acquisitions involve dealing with the information processing industry, known as Offerors or Contractors. Their organizations have similarities to Government organizations. They will generally have contracting, program management, and functional (technical) personnel. However, a business relationship with them is not the same as a working relationship with another Government office.
Civilian corporations can track potential Government contracts using the following sources.
Corporations can get on a mailing list at any Government contracting office. The contracting office then sends the corporation solicitations for the types of items or Services the corporation provides.
The Commerce Department publishes a newspaper called the "Commerce Business Daily" (CBD). The CBD is available to civilian organizations by subscription. Every open acquisition with an estimated value over $25,000 must be advertised in that paper. The CBD also lists potential subcontracting opportunities with major defense contractors. The Program Manager normally prepares a synopsis for the Contracting Office to submit for publication.
Smaller corporations can participate in large procurements as subcontractors. Local contracting offices, the Commerce Business Daily, and the Small Business Administration provide leads and contacts that small corporations can pursue.
During source selection, the interface with the Offerors is strictly controlled and limited to the Contracting Officer or his/her designee. Some formal communications between the Government and the Offeror(s), usually relate to clarifying the Offeror's proposal. Often a Government central point of contact for technical matters is identified, known as the Contracting Officer's Technical Representative (COTR). However, the COTR does not have the authority to obligate the Government.
Two important meetings are conducted at contract award.
Security technology is often an eliminator in competition. This session provides feedback for industry on how well, in general terms, their responses met the Government's requirements. The Program Manager should attend the debriefing and be prepared to provide "lessons learned" from the security vantage point. This process will help the industry representatives understand where they were responsive and where improvements can be made. The purpose is not to recite all the details, but to point out security strengths and weaknesses noted in the evaluation of Offerors' proposals.
This meeting is the first formal exchange between the Government and the successful Offeror, which is now termed the "Contractor." The Program Manager should attend the meeting to ensure that security issues are addressed and reflected in the minutes.
After contract award, interface with the Contractor is somewhat easier. Keep the following issues in mind.
No one may obligate the Government except a Contracting Officer.
Specification of security is extremely difficult. What has been given to the contractor in an RFP, or the response, may later prove to be inadequate. The implications of a modification may be great, increasing significantly the effort the contractor originally proposed. The result is another negotiation -- bargaining with security and dollars as the chips. Diluting security is not an option. Neither is overinflated security costs. From the Government's standpoint, two solutions apply: adequate specification in the first place or, if that has not happened, technically astute trade-offs and cost effective technological innovation. This is the most important time to call on security expertise.
The safest way to communicate with a Contractor is via a Technical Interchange Meeting (TIM). A TIM is formal and requires preparation of minutes that document the proceedings. The Contractor usually prepares these minutes and the Contracting Officer reviews the minutes to ensure that changes in contract scope have not been made.
The Government initiates most contract changes. Exceptions include Contractor- proposed engineering changes. Changes may be necessary to clarify, correct, or change requirements or schedules. All changes require the same care and review as the original RFP.
Telephone calls, face-to-face meetings, and general correspondence are frequently used for informal discussions of technical and administrative matters. Both parties must be careful not to exceed the limits of their authority. If a question arises about what may be discussed, consult the Contracting Officer in advance.
A large number of documents must be prepared for most acquisitions. Most can be scaled up or down according to the size, scope, and particular needs of individual programs. Appendix B provides an overview of the most important and widely used documents for each of the four major areas, respectively: planning and financial management, program management, mission user, and contracting. Appendix B includes major references to help document preparation. Subsequent paragraphs discuss the documents most important to the user of this guideline. These key documents are usually required for "most" programs. Smaller programs could either combine or reduce the size of individual documents according to the needs of the program.
These documents provide guidance to people in the organization responsible for conducting acquisition activities.
In the top-down mode, high-level DoD officials prepare policy and strategy documents, which include National Security Decision Directives, Defense Guidance, and the long-term (e.g., five year) Defense Program. They consider the threats to worldwide national interests, and define the strategy and objectives necessary to counter those threats.
The POM provides the response, listed in priority order, to the DoD planning documents.
The DoD then adjusts the POM to ensure each organization's plans are consistent with DoD guidance. The results are published as the Program Decision Memorandum.
Budget estimate submission and final publication of the Budget are the next steps in the process.
Appropriations are legal authority from Congress to spend dollars on specific line items, or for specific programs. Appropriations to an organization are the result of the budget submission, often followed by a long negotiation process. An appropriation category helps define how funds will be spent. Congress enacts Public Laws to appropriate funds formally to specify these categories.
The DoD passes funds via documents called "Obligation Authorities (OAs)." At the lowest organizational level, the target dollars an organization has available to spend are usually distributed quarterly.
The PDP, used in conjunction with budget submissions, explains what is needed, why it is needed, and the impact to the functional area operational mission if the program does not receive funding. The PDP is the basic input to the PPBS. Although the Organization responsible for planning and financial management (e.g., Plans) writes the PDP, Program Management input is normally solicited. The document should be kept current. The dollar figures in the PDP must be supportable and the words must be as compelling as the need.
These documents provide guidance to the people in the organization responsible for conducting acquisition activities.
The PMD is the first document that authorizes a program to begin. The Program Manager should get a copy and review it thoroughly to determine the program participants and their roles, the basic operational objectives, schedule and milestones, and the resources (both people and dollars) approved by the acquiring organization. The PMD usually identifies a series of supporting plans to be written (e.g., the Test and Evaluation Master Plan (TEMP)). If security is a major concern, a separate section of the PMD will address this topic.
The PMP is written in response to tasking cited in the PMD. The PMP amplifies the roles, responsibilities, tasks, and objectives called out in the PMD. The PMP specifically describes the organizations, players, and assigned tasks. Like the PMD, the PMP often lists a number of supporting plans, identifies who will prepare them, and gives dates for submission (e.g., Human Systems Integration Plan, Program Protection Plan, Software Development Plan, Systems Engineering Management Plan, Technology Assessment and Control Plan, Training and Development Plan, and Risk Management Plans). Security-relevant issues are often described in broad terms. Based on this general guidance, the Program Manager will prepare security- relevant chapters or annexes for a number of support plans.
The CMP provides both high-level and detailed procedures for developing the baseline the system and identifying, processing, and controlling system changes. Usually, the CMP will identify a Configuration Control Board (CCB), which is responsible for the administrative processes, and serves as a technical body to evaluate proposed changes. As the security focal point, the Program Manager should serve as a member of the CCB to ensure that security-relevant issues are adequately addressed. He/she may also be asked to evaluate changes to assess their "security impact."
The SSP describes the Source Selection Organization, its roles, functions, responsibilities, and the overall strategy for evaluating proposals (the topic of volume 4 of this guideline series). Normally, the 55P calls for several teams of people to participate in the Source Selection Evaluation Board (SSEB). Typically, these teams will be functionally organized, for example, responsible for technical, management, and cost issues. The SSP also outlines award criteria and evaluation factors along with a scoring methodology. The Program Manager should prepare input for the security-relevant portions of the SSP. The Program Manager may also chair the Security Panel of the Technical Team.
Derived from the SSP, the PEG contains detailed procedures on the SSEB's operation. The PEG describes the composition of the evaluation teams, their subordinate panels, and their operating rules. The PEG contains the specific evaluation standards and factors against which Offeror proposals will be judged. The Program Manager should prepare and coordinate the evaluation standards for security matters. Typically, these standards would be used predominately in the Technical Area. However, several Management Area standards must be prepared as well (e.g., an Offeror must describe his/her compliance with DoD 5220.22-M, the Industrial Security Manual). Above all, the Program Manager's role in providing (or coordinating for) evaluation criteria and standards must not be neglected. After contract award, it will be too late to correct discrepancies or oversights without the Contractor justifiably seeking "fair and equitable" compensation for errors. Furthermore, it must be ensured that an Offeror is selected whose proposal best meets the Government's requirements. The PEG is the vehicle to ensure that outcome.
This memorandum represents approval of a particular milestone phase and authorization for a program to move into the next milestone phase.
Baselines embody the cost, schedule, and performance objectives for a program and should be approved by the milestone decision authority at milestone reviews. Baselines include the Concept Baseline, the Development Baseline, and the Production Baseline.
Like the PMD, the CRLCMP focuses on managing computer resources used in systems throughout their individual life cycles. That is, the CRLCMP identifies the resources, responsible supporting organizations, and the overall strategy to ensure adequate life-cycle support is available. Also, similar to the PMD, the CRLCMP has a subordinate document that provides detailed support procedures. This document, called the Computer Resources Integrated Support Document (CRISD), describes in detail the organizational tasks and procedures for life-cycle support of the computer resource.
As prescribed by the PMD, the TEMP is the principal source of information for all testing activities. The TEMP describes the complete suite of tests, the test objectives, and cites the organizations that will participate in the testing program. Depending on the testing program scope, the TEMP may have a separate chapter or annex that describes security testing. The Program Manager should beCome familiar with the TEMP and be prepared to provide test plans, test data, and test procedures for the security-relevant concerns and issues identified in the TEMP.
The ILSP addresses reliability, maintainability, and sustainability for the AIS. The plan also describes the maintenance, supply, transportation, training, packaging, and other support capabilities required to Operate and maintain the secure AIS. The Program Manager should ensure security-relevant issues are addressed in the ILSP (e.g., methods for shipping classified devices to a depot for repair).
These documents describe the required Capabilities, functions, and features of the secure AIS. Both DoD Instruction 5000.2 and DoD-STD-7935A will be helpful in preparing these documents.
This non-system specific statement establishes a new operational capability or improves an existing capability.
This documentation describes a full range of alternatives before deciding to initiate a new acquisition. The justification describes operational needs, projected threats, and plans to identify and research alternative concepts for POM submission. This is supported by the "Federal Information Resources Management Regulation," (FIRMR) (Code of Federal Regulations (CFR) 201, Chapter 29) requirement to conduct a Requirement Analysis and an Analysis of Alternatives.
A threat assessment is required for all major programs. Historically, the STAR has not placed adequate emphasis on COMPUSEC. Identifying the threat of malicious logic attacks (e.g., viruses, worms, and Computer misuse) is important to the security of the system. The STAR will also be used as input to the System Threats and Vulnerabilities Risk Analysis required by DoD 5200.28-M. The user, or the security expert in the PMO or SPO, should contact the intelligence function to initiate the process. See Chapter 4, "Threat Risk Management",for more details.
The Operational Requirements Document contains performance (operational effectiveness and suitability) and related operational parameters.
This document describes a required capability, justifies the need, and serves as the validation and approval document for that need. The mission user generates this document, which identifies requirements that flow from base level up the chain of command.
The Functional Description is also referred to as the System/Segment or "A" Specification. It is the top-level specification that describes in broad terms the operational capabilities of the system, or a major component (segment) of the system, to be acquired. The document should include macro-level functional, performance, and interface requirements that must be satisfied. The "A" Specification always answers the "what" question, and, in general, is prepared by the mission user, but may also be prepared by a support organization or contractor. Once approved, the "A" Specification becomes the functional baseline for the secure AIS.
The System/Subsystem Specifications consist of a series of documents that divides and describes in more detail the specific functions and features first described by the "A" Specification. The "B" Specifications begin to further describe the design and development parameters of specific subsets of the secure AIS. Different types of these specifications include prime item, critical item, and software development specifications.
Software Unit Specifications are also called "C" Specifications. A detailed development specification applies to each component of the system. The "C" Specifications are the documents that the "builders" of the system use to construct the various parts of the system. Different types of "C" Specifications can exist, including critical item product specifications and software design documents.
Contracting documents are written in support of solicitations. The Federal Acquisition Regulation (FAR) provides guidance, indicates content, and sometimes provides standard formats for these documents.
This type of document is normally used for acquisitions of standard commercial off-the-shelf (COTS) items, where several vendors could provide the same item or capability. If the requirements are satisfied, the low bidder has the highest likelihood of winning the contract.
This document is a request by the Government for vendor pricing information.
This type of document typically precedes an RFP. The RFP is actually a draft RFP issued to obtain feedback from industry on the approach, content, and language of the proposed solicitation. The objective is to ensure the final RFP is clear, comprehensive, and fair to all Competitors. An RFP also helps to ensure requirements can be met using available technology, that the schedule is realistic, and the approach is workable. It is important for the Program Manager to listen to industry's feedback, although he/she does not always have to agree.
The RFP is often referred to as the solicitation package. The RFP is the most widely used document for AlS oriented acquisitions and is the focus of this procurement guideline series. The General Services Administration (GSA) has available standard solicitation documents for Systems, Software, Equipment and Maintenance. A guide on how to use these documents is also available. While the specifications for security must still be developed, the basic acquisition documents have proven to be valuable, especially to those new to acquisition. A standard RFP has thirteen sections, which are each referred to by a letter (see Table 2-1). Upon contract award, the final RFP, with sections L and M omitted, becomes the final contract guideline, including security-relevant aspects, are discussed below.
Table 2-1 RFP Organization
Letter Section Title
A Solicitation/Contract Form - Standard Form 33
B Supplies or Services with Prices and Costs
C Descriptions/Specifications/Statements of Work
D Packaging and Marking
E Inspection and Acceptance
F Deliveries and Performance
G Contract Administration Data
H Special Contract Requirements
I Contract Clauses
J List of Documents, Exhibits and Other
Attachments
K Representations, Certifications and Other
Statements of Offerors or Quoters
L Instructions, Conditions, and Notices to
Offerors
M Evaluation Factors for Award
a. Section C - Descriptions/Specifications. The first part of Section C describes the mandatory technical and performance requirements to the contractor. The section is mission user-oriented, and will normally contain a Specification or Requirements section.
b. Section C - Statements of Work. The second part of Section C identifies the specific tasks the contractor will perform during the contract period. The SOW could include tasks such as design, build, test, and train. It could also require the Contractor to perform System engineering, configuration management, planning, and analysis.
c. Section H - Special Contract Requirements. This section of the solicitation contains clauses that are specially tailored for each acquisition. Typical topics covered include site access and preparation, data rights, maintenance, liquidated damages, training responsibilities, and safety.
d. Section J - List of Documents, Exhibits, and Other Attachments. This section contains a list of all documents, exhibits, attachments, and other forms used to build and execute the RFP. This section usually includes a series of attachments, each one dedicated to a list of specific items. For example, the Glossary of Terms would be one attachment, the CDRL would be another, while the list of FIPS PUBS and Federal Standards (FED STDS) would be yet another.
e. Section L - Instructions, Conditions, and Notices to Offerors. This section contains the instructions and conditions of the acquisition. It informs Offerors of their actions and responsibilities if they submit a proposal. It covers such things as proposal format, oral presentations, and the proposal preparation instructions. Proposal preparation instructions can be used to an advantage by requiring the Offerors to submit outlines of how they will conduct SOW tasking. This process will assist in understanding the Offeror's technical approach and allow assessment of their understanding of the technical requirements.
f. Section M - Evaluation Factors for Award. This section presents to the bidder the basis of award and how proposals will be validated and evaluated. It should be taken from the evaluation team evaluation criteria (with respect to security in AISs, the topic of volume 4 of this guideline series).
Although many references address the COMPUSEC acquisition process, the most important ones follow:
a. DoD Directive 5000.1, "Defense Acquisition" - Part 2 of this directive discusses integration of requirements generation, acquisition management and the PPBS (planning, programming, and budgeting system).
b. DoD Instruction 5000.2, "Defense Acquisition Management Policies and Procedures" - This instruction is authorized under the direction of DoD Directive 5000.1, and is the principal acquisition directive for hardware/software systems. The document addresses subjects like acquisition planning and management, risk management, engineering and logistics, configuration management, cost estimating, source selection, and program control.
c. DoD 5000.2-M, "Defense Acquisition Management Documentation and Reports" - This manual contains procedures and formats to be used to prepare various documents addressed in this section, including the Test and Evaluation Master Plan, the System Threat Assessment Report, Mission Need Statement, Operational Requirements, and the Life-Cycle Cost Estimate.
d. "Acquisition of Information Resources; Overview Guide," U.S. General Services Administration.
a. DoD Directive 7740.2, "Automated Information System Strategic Planning."
b. DoD Directive 7750.5, "Management and Control of Information Requirements."
c. DoD Instruction 7041.3, "Economic Analysis and Program Evaluation for Resource Management."
d. DoD Instruction 7045.7, "Implementation of the Planning, Programming, and Budgeting System (PPBS)."
e. DoD Instruction 7045.14, "The Planning, Programming and Budgeting System
(PPBS)."
f. DoD Instruction 7110.1, "DoD Budget Guidance."
g. DoD 71 10.1-M, "DoD Budget Guidance Manual."
a. Competition in Contracting Act of 1984 (CICA).
b. "Federal Acquisition Regulation" (FAR) and "DoD FAR Supplement."
c. "Federal Information Resources Management Regulation," (FlRMR) General Services Administration (41 CFR 201, Part 39).
d. DoD 5010.1 2-L, "Acquisition Management Systems and Data Requirements Control List."
a. "Federal Information Resources Management Regulation," (FIRMR) General Services Administration (41 CFR 201)
b. Military Handbook (MIL-HDBK)-245B, "Preparation of Statements of Work" - This document provides guidance for preparing statements of work.
c. DoD-STD-7935A, "Automated Data Systems (ADS) Documentation Standards" - This document provides guidance for the development and revision of documentation for automated information systems. These standards apply to the documentation developed to support applications systems. This is a source for specific guidance on format and content of specifications.
d. DoD 5220.22-R, "Industrial Security Regulation" - This regulation provides uniform procedures that ensure safeguarding classified information.
e. GSA Index of Federal Specifications, Standards and Commercial Item Descriptions.
a. "Information Systems Security Products and Services Catalogue," Prepared by the National Security Agency, (Published Quarterly) - This is the NSA publication that contains the EPL.
b. Federal Information Processing Standards Publications and Federal Standards - These two groups of Federal technical documents are also associated with most AS oriented acquisitions. The FIPS PUBS come from the National Institute of Standards and Technology (NlST) (formerly NBS); the FED STDS come from GSA. Both cover a wide range of topics. The System Engineer in the PMO or SPO should have them available and determine their specific applicability.
c. Publications issued by the Standards, Criteria, and Guidelines Division of the National Security Agency (NSA), see Appendix C, section C.t, "Working Bibliography," for a complete listing of available NCSC publications.
d. DoD Directive 3020.26, "Continuity of Operations Policies and Planning."
a. DoD 5200.28-STD, "DoD Trusted Computer System Evaluation Criteria."
b. DoD Directive 7920.1, "Life-Cycle Management of Automated Information Systems" - This directive specifies the six life-cycle management phases and the applicable policies.
c. DoD Instruction 7920.2, "Automated Information Systems (AIS) Life-Cycle Management Review and Milestone Approval Procedure" - This instruction defines specific tasks to be completed for each life-cycle management phase.
d. Military Standard (MIL-STD)-483A, "Configuration Management Practices for Systems, Equipment, Munitions, and Computer Software" - This military standard identifies the requirement for configuration identification, a configuration management plan, specification allocation and audits. The document addresses the relationship with other documents, reporting, configuration control, and specification maintenance.
e. MIL-STD-490A, "Specification Practices" - This standard usually applies when major systems are being acquired. This is a source of specific guidance on format and content of the specifications. Most contractor-developed documentation will follow this guideline.
f. MIL-STD-499, "Engineering Management."
g. MlL-STD-499B (Draft), "Systems Engineering."
h. MlL-H-46855, "Human Engineering Requirements for Military Systems, Equipment, and Facilities."
i. MIL-STD-1521A, "Technical Reviews and Audits for Systems, Equipments and Computer Programs. "
j. MlL-STD-1785, "System Security Engineering Program Management Requirements."
k. DoD-STD-21 67A, "Defense System Software Development."
Because of its general application and the use of formal methodologies, COMPUSEC has become the most rigorous and complex of all the security disciplines. Nevertheless, a systems programming expertise is not required to understand the basic concepts. This chapter provides most of the information needed to ensure that AlS acquisitions satisfy COMPUSEC concerns.
This section interprets requirements provided by DoD Directive 5200.28 and DoD 5200.28-STD.
Security policy statements and directives form the basis for requiring security protection features in an AS. They are based on Public Laws, Executive Orders, and Federal (e.g., DoD) regulatIons. Protecting sensitive data or information from compromise, denial of service, and unauthorized alteration are fundamental requirements of DoD policy. When dealing with an AlS, the security policy can be implemented by some mixture of measures.
These security protection features are outside the physical or logical boundaries of the AlS. They include the physical, personnel, administrative (procedural), and operations security disciplines. External security protection measures also include the study/control of compromising emanations (TEMPEST) and communications security (COMSEC).
COMPUSEC protection features are inside the physical or logical boundaries of the AlS, and are emphasized in this guideline. The focus of this guideline is on computer-enforced measures, or COMPUSEC, but some overlap with the other disciplines can occur. Internal security protection measures really mean the Trusted Computing Base (TCB). The TCB is the collection of hardware, software, and procedures implemented to protect the data or information processed or stored by the AIS.
A TCB must be evaluated and approved to meet a set of evaluation standards.
DoD 5200.28-STD contains these standards. The four divisions of evaluation standards follow: D is minimal protection, C is discretionary protection, B is mandatory protection, and A is verified protection. C and B are further divided into two and three classes, respectively. Systems evaluated by NSA that meet a set of standards receive a TCB division/class rating. These and other systems that are evaluated for certification against the division/class ratings are presumed to provide a degree of security protection that is "trusted" to meet the protection requirements for that division/class.
Figure 3-1 portrays the way the requirements for each class build upon preceding requirements as the division/class increases. Following Figure 3-1 are Tables 3-1 through 3-4, which cite brief definitions of each division/class under the appropriate division heading. Note that the criteria for each division/class include and incorporate the criteria for the preceding class. The tables list the division/classes from lowest to highest confidence.
Table 3-1 Division D, Minimal Protection
There is little or no evidence of specific security protection features. (No classes exist).
Table 3-2 Division C, Discretionary Protection
Class Cl, Discretionary Security Protection - A primitive TCB provides elementary protection to separate users from data. The system is expected to operate in an environment of cooperating users processing data at the same level.
Class CS, Controlled Access Protection - A basic TCB provides intermediate-level protection. C2 features more clearly distinguish user actions through log-in procedures, auditing security-relevant events, isolating data, providing resource protection and ensuring each user is accountable.
Table 3-3 Division B, Mandator Protection
Class B1, Labeled Security Protection - An intermediate-level TCB provides elementary Mandatory Access Control protection, as well as intermediate-level Discretionary Access Control. Mandatory Access Control is extended to users and data. Data must be labeled and users must be given explicit permission to access data. Sensitivity labels are used to make access- control decisions. Such decisions are based on an informal security policy model that states the rules for how named subjects (e.g.,users) may access named objects (e.g.,files).
Class B2, Structured Protection - An enhanced-level TCB provides intermediate-level Mandatory Access Control protection and enhanced-level Discretionary Access Control. Sensitivity labels enforce access-control decisions. Decisions are based on a formally specified security policy model that regulates how every subject (e.g.,users, programs) may access every object (e.g.,files, records). Protection features are carefully separated into protection-critical and non-protection-critical elements. Class B2 requires additional internal protection, such as the prevention of information passing through covert channels. Operational support features are provided, including Information System Security Officer (ISSO) and Administrator functions. Stringent configuration management practices are required.
Class B3, Security Domains - An advanced TCB provides highly effective Discretionary and Mandatory Access Controls. B3 controls must implement the "reference monitor concept" so that all accesses are shown to satisfy a formally specified security policy model. Significant security and software engineering must be accomplished during the design, testing, and implementation phases to achieve the required level of confidence, or trust. Operational support features extend auditing capabilities, as well as ISSO functions needed for a trusted system recovery.
Table 3-4 Division A, Verified Protection
Class A1, Verified Design - A highly advanced TCB provides exceptionally effective Discretionary and Mandatory Access Controls with identical requirements to those of Class B3 TCB systems. Formal analyses prove the design and its implementation are rigorous (in the mathematical sense) using a Formal Top-Level Specification. Operational support features are further extended, providing techniques for trusted system distribution to deployed sites.
Each TCB division/class has a set of requirements. Only a general description of the protection concept appears below. No attempt is made to distinguish between divisions/classes.
Security policy statements govern the manner in which sensitive (classified) information is protected.
This is the need-to-know concept. DAC enforces rules for sharing data among users.
All storage areas (e.g., main memory or mass storage) reallocated by the system must not contain residual data for which the new subject is not authorized.
Within a TCB, labels represent the sensitivity or security level. A subject's label represents its clearance level and need-to-know privileges; an information object's label indicates the actual sensitivity of the information. A storage object's label indicates the sensitivity of the data held or permitted to be held.
Sensitivity labels must correspond exactly to the sensitivity level of the subject (person who uses resources) or object (resources used) with which they are associated.
Exchanging (e.g., importing or exporting) information between the TCB and a Communications channel or the TCB and a device requires the TCB to distinguish between multilevel and single-level devices.
a. Multilevel Devices (Class B1 and above): For multilevel devices, the TCB ensures that an object's sensitivity is within the range permitted. The TCB exchanges both the object and its sensitivity label.
b. Single-Level Devices (Class 01 and above): For a single-level devices, only the object needs to be exchanged. Since the sensitivity level is "fixed" and known in advance, the TCB only allows exchange at that level.
Output must be marked with a plain language version of the object's sensitivity level (e.g., English language security classification banner at the top and bottom of each page).
From Mandatory Access Control (MAC) rules, subjects (e.g., users, programs) are allowed access (e.g., read, write, change, delete) to objects (e.g., data). A subject's clearance level must always be consistent with an object's sensitivity level. Thus, subjects may read from an area (e.g., main memory) with an equal or lesser sensitivity level, and may write to an area with an equal or greater sensitivity level.
During an interactive session, the TCB must keep the terminal user informed of changes in the "current working security level." Terminal users may request a display of the complete sensitivity label for processes they are using.
The TCB must keep track of the minimum and maximum security level assignments of all physically attached devices (e.g,., terminals, printers). These assignments are often called "classmarks".
Accountability is the ability to trace actions affecting security to the responsible party. This feature ensures the user's dialogue is with the TCB and not with a masquerading program (e.g., during log-in).
Users must identify themselves (e.g., provide user-identifications) to the system and the TCB must authenticate the user's identity (e.g., passwords).
The TCB must record all security- relevant events (e.g., changes to device classmarks) in a TCB-protected area called the "audit trail."
The TCB must provide a means to identify itself clearly to the user.
Assurance provides the steps necessary to demonstrate that the security policy has been correctly implemented.
The system architecture must separate TCB processes (e.g., reference monitor) from user processes (e.g., application programs). The system architecture must also separate each user's data from every other user's data.
Periodic validation checks must ensure the correct functioning of the TCB protection elements. The checks can either be automated, or they can be invoked manually by the system operator.
Covert channels are signalling paths that can bypass the TCB's access controls and therefore, can allow violation of policy. Covert channels must be identified, their bandwidth minimized, and their use audited.
The separate functions of system operator and system administrator must be defined and supported with TCB features. The system operator has fewer security-relevant privileges than the system administrator.
The range and depth of testing increases for each division/class. Test results must affirm the implementation of security protection features as intended.
The security policy enforced by the TCB must be informally (i.e., non-mathematically) struCtured or formally (i.e., mathematically) modeled. At higher TCB classes, the mathematical modeling becomes more rigorous (e.g., the spectrum includes demonstration, providing a Convincing argument, and proving). The requirement for correspondence between the policy model and the design specifications (e.g., Descriptive Top-Level Specification (DTLS) and Formal Top-Level Specification (FTLS)) also increases.
Configuration management refers to the procedures used to establish a baseline and then to control changes throughout the system's life cycle. Configuration management becomes more comprehensive as the TCB division/class increases.
Procedures must be available to preserve seCurity protection integrity and return the system to a secure processing environment after a failure.
This feature ensures the provision of a "high confidence" system for distributing each TCB version, also ensuring its integrity upon receipt at each site.
The documents required describe the TCB's objectives, design, performance, and operation. Documentation must include a Statement of Work task to develop these documents and invoke the Contract Requirements Lists (CDRLs) to specify delivery to the Government.
This guide targets system users and developers. The document describes the security protection features of the TCB, provides guidelines on their use, and explains how they interact. The guide should also describe expected system reaction to security-relevant events, such as access violations.
This manual applies to the System Administrator, Security Officer, users, and operators. Since this document provides detailed information about the security protection features provided by the TCB and describes how to use them, its distribution should be strictly controlled. The document should cover "everything you need to know" to generate and operate the specific TCB in an operationally secure environment. This information should include loading, generating, and initializing a new TCB; maintaining and examining audit files; conducting shutdown, restart, and recovery; as well as running diagnostics, managing sensitivity labels, and managing user access authorizations.
Test documentation provides the test plan(s) and the results of testing the TCB security protection features. The range and depth increases as the TCB division/class increases. Test results must be controlled if they point out vulnerabilities.
A full complement of design documentation is required. The scope depends on the TCB division/class. The scope ranges from a simple statement of the protection objectives through a mathematically based description, to the detailed proofs and correspondence of the specifications, and back to the security policy model and its objectives.
Since most computer security protection features are implemented in software, a clear majority of the Program Manager's time is spent dealing with software issues. Time should be taken to review DoD 5200.28-STD as well as the other references given at the end of this chapter. This review will help the Program Manager prepare for the acquisition concerns about software.
This section identifies software factors important in a trusted application.
Software matters require structure and discipline. Structure provides procedures, techniques, and check-points used to measure progress. Detailed planning, step-by-step execution of the plans, and an iterative approach are important. Discipline provides a way to remain on the charted course without being trapped by pitfalls. One must do more than blindly "follow the rules." Good documentation configuration management, and strict adherence to details are important discipline factors.
Estimating the cost of software development is difficult, at best. Cost overruns invariably lead to increased software risk, a serious concern for secure systems. Tools are available that contractors and other software developers use for cost estimation. Nevertheless, a great deal of subjective input influences to the "final" estimate. The skill level of the people involved, the complexity of the system, and many other factors all play a role. The contractor must describe the process, ground rules, and assumptions used to estimate software development costs. The Program Manager should "walk through" the steps to be certain the process makes sense. If the contractor's documentation cannot be fully understood, he/she should be asked for an informal briefing or chalk-board session. This process may avoid major cost and schedule changes later.
An appropriate modern, high-order programming language should be required to improve security. For example modern languages that strictly enforce "strong typing" should be used. Strong typing is the assignment of legal access (e.g., read, write, modify) to objects. Moreover, languages often require programmers to restrict their data definitions to pre-designated storage areas (e.g., certain main memory blocks). Ada is the DoD required language, and alternate languages must be preapproved. Software engineering disciplines (structured programming with structured "walkthroughs") make it more difficult for an attacker to hide covert code or logic bombs. If the use of assembly language for applications is allowed, the source must be checked carefully for illegal Operations (e.g., the use of undocumented operations codes). Such use would require a special section in the test plans and configuration management plan.
Systems that use DBMSs can introduce an additional element of risk not present in non-DBMSs. NCSC-TG-021, "Trusted Database Management System Interpretation of Trusted Computer System Evaluation Criteria," provides criteria for dealing with this important issue.
System utilities provide powerful tools for augmenting or developing operating system capabilities. Their use must be limited and controlled by the TCB software. The security implications for compilers that "automatically optimize" the generated object code must be understood. That is, the generated object code will likely not be in the identical sequence Corresponding to the source language, although the function performed will be correctly done. Linkers (sometimes called "Linkage Editors") can also be a security concern, since access to unintended data areas can Occur through "external reference" directives. Finally, some languages incorporate what is known as "run-time packages," chiefly to perform input-output operations. Run-time packages must be included within the security-relevant boundary, especially at the higher TCB divisions/classes.
Figure 3-2 illustrates the software development process in terms of documentation required. Different terms are used for some of the design documents, but the document requirements are similar, if not identical. For example, the terms Functional Description, "A" Specification, and System Specification, are usually used interchangeably. Note that the process is iterative, and flows from very general top-level policy and capabilities requirements statements, down to very precise implementation details.
Security Policy
*
Security Policy Model
*
Functional Description
("A" Specifications
Descriptive Top Level Specification (DTLS)
Formal Top Level Specification (FTLS, A1 only))
*
System/Subsystem Specifications
("B" Specification)
*
Unit Specifications
("C" Specification)
Figure 3-2 Security Protection in the Software Development Process
As noted above, the key to success with software is structure and discipline. Some of the specific success factors follow:
Documentation must start from the initial statement of requirements and continue through to the details of implementing, operating, and maintaining the system. The root is in the initial statement of requirements.
An explicit statement of the security policy should be enforced by the AS. The policy should be documented in the specification (requirements) section of the RFP, and should clearly state the security enforcement rules by which the system will operate.
Each TCB division/class requires a vendor or manufacturer (i.e., contractor) to provide a description of the security protection philosophy and how that philosophy is translated into the TCB. TCB Class B1 requires development of an informal or formal description of the security policy to be enforced by the TCB. TCB Class B2 and above require formal models of the security policy. As might be expected, these models (both informal and formal) require special expertise to develop and evaluate, since they will be written in special mathematical notation (e.g., algebraic specification or set theory). It should be ensured that the expertise needed to review and evaluate the contractor's submissions is available, either internally or from the NSA.
The DTLS is equivalent to a Security Features Functional Description. This
specification describes the security protection capabilities required by the AIS, and is required for TCB Classes B2, B3, and A1. Although written in English prose, this document will contain a good deal of technical language. The DTLS should address both hardware and software capabilities.
This document is required for TCB Class A1 only. It is written in a formal mathematical language to ensure that the design is consistent with the model of the security policy being enforced. The FTLS also addresses both hardware and software protection. This specification is accompanied by a separate formal verification of the specification. This verification proves that the design corresponds completely and accurately to the formal security policy model. Special expertise is also required to review and evaluate this document.
The design documentation, from this level down, begins to describe, in ever-increasing detail, the "how-to" of the TCB build process. At this level of detail, care must be taken when reviewing the contractor's design approach. Concern should focus on thoroughness and completeness, not "how to." If the required capabilities, functions, and features are present, the contractor should have some freedom of choice. The contractor must also comply with the contract-specified standards and specifications. If a question arises as to what the document is saying, the program manager should ask for an informal briefing or chalk-board session.
Programming, or writing computer programs, is the "build" of the development process. The contractor should not begin to program until after approval of the specifications. This restriction will avoid restarts and changes as the acquisition progresses.
Both the contractor and the Government are heavily involved in testing. The attitude should be "Show me, please" throughout the test effort. For the internal TCB-provided security protection features, DoD 5200.28-STD requirements should be reviewed for testing each division/class. A team of experts should be assembled to help test. Also, Chapter 5 of this document, "Security Test and Evaluation," should be reviewed.
Configuration Management (CM) for TCB software is only required for TCB Classes B2 and above. However, CM should be required for all acquisitions, whenever possible. CM is the only way to achieve a structured and disciplined approach to software management, regardless of the TCB division/class. The situation is likely that some CM will be required in every program. The requirement extends to the TCB software by including a Statement of Work task. The Program Manager should also participate in the Configuration Control Board (CCB), which is the committee that reviews all changes to established baselines. Note that the documented procedures for control of changes do not need to be as extensive for the lower TCB division/classes (C1 through B1). Configuration control must extend to distribution, delivery, installation, Operation, and maintenance.
Auditing of security-relevant events is required for all TCB division/classes (C2 and above). The early identification of audit requirements and strategy is necessary to ensure that the accountability requirements are satisfied for the TCB division/class, and to ensure they are included in the TCB design. The NSA publication NCSC-TG-001,"A Guide To Understanding Audit In Trusted Systems," describes the specific audit requirements for each TCB division/class, including the events that must be audited and the specific information that must be recorded.
One of the major requirements of all TCB division/classes is accountability. The CSC-STD-002-85, "DoD Password Management Guideline," and NCSC-TG-017, "A Guide to Understanding Identification and Authentication," provide sound practices that will help satisfy the accountability requirement. Ensure accountability is included in all AIS RFP requirements. Also ensure the information provided in the Trusted Facility Manual and Security Features User's Guide is consistent with the principles in this guideline.
The process of assuring that the TCB is "properly done" is called "correspondence." The technique used is to map the TCB design back to the security policy model at the B1 and above levels. In addition, the TCB Class A1 requirement calls for mapping the TCB design down to the TCB source code.
If any of the software being developed is classified, be sure to check Block 11c, Receipt and Generation of Classified Documents and Other Material, of the DD Form 254, Contract Security Classification Specification. Trusted software must be protected at the highest level of information to be processed.
To ensure a structured and disciplined approach to software concerns, provide Statement of Work tasks appropriate for the TCB division/class being developed.
Several features of a TCB have an impact on hardware or require hardware for support.
This section identifies factors associated with hardware that are important in a trusted appliCation.
Sometimes referred to as "boot" or "bootstrap," the IPL function is always hardware based. The IPL feature loads and begins executing the first few instructions necessary to start the system. The chief security concern is the initial secure state for TCB Classes B2, B3, and A1. Without assurance the system achieves the initial secure state, the TCB cannot be considered secure.
To be suitable for a TCB, a computer must have at least two distinct processor states (sometimes referred to as "operating modes"). The most privileged state should be reserved exclusively for the TCB's use and should include special instructions or features needed to enforce access control rules or perform input/output functions. Another, less privileged state should be used by the application programs and must not include those powerful security-related capabilities reserved for the TCB. The idea is to isolate privileged capabilities and restrict the use of certain instructions (e.g., those which do input/output or enforce access control rules) to the TCB alone, while permitting the applications programs to perform their mission-oriented functions at a less privileged level.
Small domains (e.g., a few bytes) are ideal for providing precise control (down to the byte or word level) but they require a significant amount of computer overhead to maintain. The trade-off usually made is to have larger protection domains (e.g., 1024 byte blocks) to reduce hardware complexity and retain acceptable performance.
MECHANISMS
Hardware features (usually called "keys") allow the TCB to associate specific hardware "registers" with the main memory areas (domains) they are protecting. There should be sufficient types and numbers of "registers" to ensure the number of sensitivity labels for information in the system can be adequately mapped. Common ways to achieve these capabilities are through "Descriptor Base Registers," "Bounds Registers," and "Virtual Memory Mapping Registers," although other approaches may also be used.
Integrity checking mechanisms usually provide support for security functions. For example, memory parity checks and cyclic redundancy check schemes ensure errors are detected. Another commonly used technique is called a watchdog timer. This timer performs a direct security-related function by ensuring an application program cannot "steal all the processor's time" by independently checking allocations of processor time.
DMA allows input-output to occur simultaneously with t