|
Cryptome DVDs are offered by Cryptome. Donate $25 for two DVDs of the Cryptome 12-years collection of 46,000 files from June 1996 to June 2008 (~6.7 GB). Click Paypal or mail check/MO made out to John Young, 251 West 89th Street, New York, NY 10024. The collection includes all files of cryptome.org, jya.com, cartome.org, eyeball-series.org and iraq-kill-maim.org, and 23,000 (updated) pages of counter-intelligence dossiers declassified by the US Army Information and Security Command, dating from 1945 to 1985.The DVDs will be sent anywhere worldwide without extra cost. | |||
10 March 1997
Source:
http://deskbook.wpafb.af.mil/AskAProfessor/Security/appenx-g.htm
| HEADQUARTERS U.S. Army Information Systems Engineering Command Fort Huachuca, Arizona 85613-5300 |
Automated Information System (AIS)
Design Guidance
Information Systems Security (ISS)
Version 1.0
27 December 1996
This document provides technical guidance to incorporate Information Systems Security (ISS) support in the overall design of United States (U.S.) Army Automated Information Systems (AIS). The technical guidance provided in this document will provide the basis for development of a detailed System Design Plan (SDP) for specific applications.
The design of an AIS is increasingly dependent upon data communications and system platform operations in a distributed processing environment to satisfy users' requirements during peace, transition to war, and wartime. As the internet becomes more accessible worldwide, it has magnified the need for security from end-to-end to protect the information being transferred, stored and processed. This document will provide guidance in the design and development of an AIS to incorporate ISS. Security policy and standards are the basis that enable users to securely interoperate seamlessly across applications, platforms, and organizations.
a. Minimize the labor intensive requirement to design security into U.S. Army AISs across all Army and Department of Defense (DoD) systems.
b. Assist in integrating a secure common baseline or Common Operating Environment (COE) to avoid incompatibility problems between Army and DoD systems.
c. Provide the systems engineers with the standards and guidelines used to implement security across Army and DoD systems.
The objectives involve security policy, architecture, standards and protocols, accreditation procedures, technology, transition planning, organizational improvement, and products and services availability.
ISS is an area that stretches across the whole spectrum of the DoD Technical Architecture Framework for Information Management (TAFIM). The DoD Goal Security Architecture is Volume 6 of the TAFIM. It includes a secure architecture for mission applications, authentication, access controls, integrity, confidentiality, non-repudiation, availability, security management, and security labeling.
The present DoD computing and communications environment is based on stand-alone systems that do not interoperate. As a result, expensive and manually intensive workarounds are needed in the present Defense Information Infrastructure (DII) to meet the stated goals of interoperability, transparency, responsiveness, maintainability, reliability, and security. The DoD TAFIM is now the basis for meeting these goals.
DoD is becoming a smaller, more tightly integrated organization, with major emphasis on the ability to provide rapid force projection into regional situations. Flexible integration and interoperability of information systems play a vital role. Although this increased reliance on technology and connectivity provides greater benefits in terms of capabilities and productivity, it also leads to greater vulnerabilities. Traditional ways of providing security, while still necessary, are no longer sufficient to ensure adequate protection. Not only is classified information at risk, but so is much of the unclassified information that supports the economic and political functioning of the nation. Information security requirements today include:
The DoD Defensive Information Warfare (DIW) Management Plan provides the basis for actions to achieve information superiority in support of the national military strategy by affecting adversary information and information systems while leveraging and protecting our information systems. The DoD challenge is to produce a global Command, Control, Communications, Computers, and Intelligence (C4I) system which provides the Warrior a fused, real-time, true picture of his battle space and the ability to order, respond, and coordinate horizontally and vertically in the battle space, safe from denial, deception, and destruction. DoD is implementing this strategy through the DIW concepts of protect, detect, and react. DoD first protects the infrastructure and data from a security attack. It then provides the security tools and training to detect attacks upon the information infrastructure and data, and then reacts properly to attacks and maintains the level of information services required.
The Defense Information Infrastructure (DII) Master Plan establishes the common DII vision for the DoD. The vision for ISS is provided for technical guidance and is an integral part of the DII. The Global Command and Control System (GCCS) Technical Architecture tailors and extends the guidance provided by the DII architecture to meet specific C4I needs. The DII Common Operating Environment (COE) Integration and Run-Time Specification (I&RTS) provide the technical requirements to build and integrate systems. Two systems presently use the DII COE: the GCCS and the Global Combat Support System (GCSS). Both use the same infrastructure and integration approach and the same COE components for functions that are common between the two systems. GCCS is the C4I system, and the warfighting support functions (logistics, transportation, etc.) necessary to provide a system that is fully interoperable with the GCSS.
The DoD Goal Security Architecture (DGSA) establishes the future security vision for the DoD information systems, setting the target and transition perspective for the 21st Century ISS. It provides guidance for a process that will correct security deficiencies in information systems, set the security target and transition perspective, provide a vision for future information systems security, and present a flexible and evolvable security plan consistent with open systems policies. The DGSA is based on the expectation that secure and non-secure components will be integrated by necessity and that the products developed for open systems operation will offer varying degrees of protection. The DII security architecture objectives are based on the security policy statements from the DGSA, which state that the DoD information systems must:
These policy statements are the basis of the DII target security architecture and provide a traceable path for the protection of DoD information processing as it evolves toward a distributed, open systems approach to accomplishing the DoD mission. Beyond the concerns of confidentiality, availability, and integrity, the significant issues from a security perspective are based on:
These issues also bring derivative concerns, such as compatibility of protection, interoperability of processing and communication environments, and availability of mission-essential data and infrastructure services.
The strategy for the DII Target Security Architecture is to implement the DGSA in systems, to implement timely initiatives early in the process to allow cost-effective purchasing, and to test results as appropriate parts become available. The main thrust is to implement practical fixes in a timely manner with cost-effective designs accomplished early in the life-cycle process. Partnership with other elements in DoD and business are critical to successful implementation of the DGSA and the DII Target Security Architecture.
The following high-level security objectives represent the fundamental elements in the DII Target Security Architecture.
The DII Target Security Architecture is based on the DGSA and the Multilevel Information Systems Security Initiative (MISSI) set of solutions. User MISSI components include the workstation capabilities such as the FORTEZZA cryptographic card. All MISSI components coexist and interoperate with each other and with other appropriately equipped non-MISSI protected workstations. The infrastructure also includes the Defense Message System (DMS) Directory Service Agent (DSA) and the Certification Authority Workstation (CAW).
The DII Target Security Architecture includes command centers, intelligence facilities, Combined and Joint Task Forces, base-level information systems facilities, Megacenters, mission support facilities, and land, air, and maritime components. Both strategic and tactical environments are included. All are interconnected by the Defense Information System Network (DISN). Several network management centers provide central oversight of the network to include central oversight of key management. One supports the Root CAW (for public keys) and another the National Security Agency (NSA) Central Facility for the Electronic Key Management System (EKMS). MISSI components are being developed in accordance with a cohesive security architecture and will be supported by a common security infrastructure as an integral part of the DII COE.
The Global Command and Control System (GCCS) Multilevel Security (MLS) Plan has been developed to support information sharing and interoperability, especially across security boundaries such as intelligence, operations, law enforcement, and open resource systems. MLS enables information dominance that is critical to warfighting. It compresses the decision loop of commanders and exploits technological advances that are not available to most of our potential adversaries. This GCCS MLS Plan provides the infrastructure for evolving security technology by enabling access between and access across heterogeneous and disparate security environments.
The Multilevel Information Systems Security Initiative (MISSI) Implementation Guide provides a basis for Service and Agency planners to implement MISSI technology and to support program objective memorandum (POM) and budget planning. The objective of MISSI is to make available a set of products that can be used to construct secure computer networks in support of a wide variety of missions. MISSI provides affordable and adequate security. It provides writer-to-reader ISS including data integrity, access control, authentication, non-repudiation, and confidentiality. MISSI is designed to be used for applications such as electronic mail (E-mail), file transfer, file storage, work groups, remote login, database management, search/retrieval, and electronic commerce.
Two critical characteristics of MISSI are that (1) it is based on building block products and (2) the products are integrated into a cohesive security architecture. The building block products can be assembled in a variety of ways to meet different user needs. The products are interoperable and compatible and are based on common security protocols and standards and on standard security mechanisms. Some building block products are MISSI products and others are commercial products that can be integrated and used with MISSI products. The basic MISSI building blocks include:
The Common Criteria for Information Technology Security provides a program to achieve international harmonization of information technology security standards and evaluation schemes. The goal of the program is the international harmonization of security evaluation activities leading to the international recognition of the resulting product evaluation certificates. The Common Criteria is planned to replace the DoD Trusted Computer System Evaluation Criteria (DoD 5200.28-Standard (STD)) (Orange Book) after final demonstration testing.
Office of Management and Budget (OMB) Circular No. A-130, Appendix III establishes a minimum set of controls to be included in Federal automated information security programs; assigns Federal agency responsibilities for the security of automated information; and links agency automated information security programs and management control systems established in accordance with OMB Circular No. A-123, Management Accountability and Control. The Appendix revises procedures and incorporates requirements of the Computer Security Act of 1987 and responsibilities assigned in applicable national security directives.
The Circular states that each agency shall implement policies, standards, and procedures which are consistent with Government-wide policies, standards, and procedures issued by the Office of Management and Budget, the Department of Commerce, the General Services Administration, and the Office of Personnel Management (OPM). Different or more stringent requirements for securing national security information should be incorporated into agency programs as required by appropriate national security directives. At a minimum, agency programs shall include the following controls: Assign Responsibility for Security, System Security Plan, Review of Security Controls and Authorize Processing. The Systems Security Plan will include: Rules of the System, Training, Personnel Controls, Incident Response Capability, Continuity of Support, Technical Security and System Interconnection.
The DoD EC/EDI Security Plan supports the computer-to-computer exchange of business information in standard format. DoD has developed this EC/EDI system to reduce errors in data entry, decrease paper handling, reduce inventory, improve cash management, and shorten order times. The EC/EDI security system provides the protection against threats to the Government and its Trading Partners to trust the individual business transactions carried on between them. The security services provided include: Protections Required for DoD Information Domains, Data Integrity, System Integrity, Non-Repudiation, Time-Stamp, Confidentiality, Access Control, Availability, Archive, Audit, Key Management, and Security Management.
The tactical deployments for exercises/training and for combat will expose the DA/DoD systems to a variety of risks to ISS associated with these field environments. In addition, operations while in garrison/sustaining base will result in the same exposure with additional ISS risks because of the location and operations performed by those facilities. The common security architecture (DII COE) will assist in protecting information (storage of information, sharing between services/agencies systems, and transferring of information) and computer platform resources. This architecture must often be combined with security procedures, which are beyond the scope of the information technology service areas to fully meet security requirements. Security architecture includes security policy, accountability, integrity, and assurance of the information being processed.
The primary ISS functional requirement areas are to use existing Army security policy and to establish a common functional security baseline (U.S. Army COE) for the ISS environment. The U.S. Army COE for ISS will include a security policy, a security classification guide (SCG), information security (software and hardware), physical security, procedural security, personnel security, media security, network security, communications security, and emanations security. These system security parts will be integrated together to fit into the Army Technical Architecture (ATA). The ATA Section 6 describes the information security standards that apply to Army systems that produce, use or exchange information electronically. These standards provide the warfighter with a seamless flow of timely, accurate, accessible, and secure information. This approach supports the Army systems in migrating to the DoD TAFIM and DII COE.
The primary purpose for ISS is to deny unauthorized persons access to classified and unclassified-sensitive information while it is being transmitted, processed, and stored at local and remote locations. Also of critical importance is the denial of unauthorized access by authorized persons, the prevention of denial of service, and data integrity. Each of these concerns are addressed in the required security functions. These functions will provide the security mechanisms to protect, detect, and react to all threats to the information system and data.
A security policy details the requirements and standards to achieve security for data processed by Army information systems and provides security requirement guidance for specific types, categories/caveats, sensitivities of data, and environments of operation (tactical deployment, garrison, etc.) obtained from applicable regulations. Once the security threats have been identified by Department of the Army (DA) and/or the Defense Intelligence Agency (DIA), a security policy will be established and incorporated in the System Requirements Definition (SRD) so that the policy can be included in the System Requirements Specification (SRS) from which the system will be designed.
The Security Classification Guide (SCG) is concerned with identifying the specific classified or sensitive items of information requiring protection against unauthorized disclosure, specifying the level of protection afforded those items, discussing protection when data aggregation of any required items causes the item to change classification (e.g., Unclassified-Sensitive to Confidential or Secret), combining data item groups together causing information to become classified or causing a higher classification, and establishing the time period required to protect the information. The functional proponent will develop a SCG according to DoD 5200.1H if one is deemed required. This information will also be included in the SRS.
Information security (software and hardware) measures and controls protect an AIS against denial of service and unauthorized (accidental or intentional) disclosure, modification, or destruction of AIS and data. Information security requirements are broken into two parts. The first part is the minimum requirement of Army Regulation (AR) 380-19 which covers information accountability, access, least privilege, data continuity, contingency planning, accreditation, risk management, and security planning. The second part is the trusted computing base requirements or the DoD 5200.28-STD (Orange Book) adherence requirements. The trusted computing base (TCB) requirement is based on the required security features for the level of trust and mode of operation needed, becoming more restricted as level of trust increases.
Physical security are those measures used to: 1) Prevent unauthorized access to equipment, facilities, material, and documents; 2) Safeguard against espionage, sabotage, damage, and theft; and 3) Reduce the exposure to threats which could result in a disruption or denial of service. The implementation is for special site location and construction standards of a central computer complex for the mainframe computer equipment room, small computers, and other AISs.
a. For the overall requirements, see:
b. For the special facilities requirements processing classified information, see:
c. For the SCI processing facilities, see:
Procedural security includes the management constraints; operational, administrative, and accountability procedures; and supplemental controls established to provide protection for sensitive defense information. These are reporting and accountability procedures that apply to AIS operations as well as software development, maintenance activities, and other support operations. For example, assigning key duties to individuals as a check and balance so that no one individual can adversely affect the whole AIS operation. Proposed changes to the AIS configuration will be reported to the Information Systems Security Office (ISSO) to determine the security implications of the change, and also establish password control procedures and techniques. Procedural security measures are usually cost-effective because they involve a minimum financial expenditure while producing a higher corresponding level of security.
a. For the password control, reporting, and accountability procedural requirements on unclassified-sensitive and classified systems, see:
b. The facility Telecommunications Electronics Material Protected From Emanating Spurious Transmissions(TEMPEST) Assessment/RA report will be done for all classified systems that have proposed changes to the AIS configuration. See:
c. For guidance on password management procedures, see:
Personnel security is the application of standards and criteria to determine whether or not an individual is eligible for access to classified information, qualified for assignment to or retention in sensitive duties, and suitable for acceptance and retention in the total Army consistent with national security interests. All personnel doing work for or on behalf of the U.S. Government need to be trained on their overall responsibilities, have a security background check performed and be made aware of all aspects of security. This is particularly true for the Information Systems Security Officer (ISSO), the database administrator (DBA), and the system administrator (SYSADMIN).
The directives that apply to personnel security are:
a. For general personnel security requirements for training and awareness programs, personnel security standards, and using foreign national employees, see:
b. For those who are required to work with unclassified-sensitive or classified information because of their duties, see:
c. For the required security education requirements for all personnel that are in possession of a security clearance of any kind, see:
d. For those classified Sensitive Compartmented Information (SCI) systems that will be developed on behalf of the U.S. Government, contractors must follow the requirements and procedures specified by:
AIS media security is the handling of any substance or material on which information is represented or stored, used for input or output to an AIS or as an integral part of the AIS. Media security fulfills unclassified and classified data protection requirements for clearing, purging, declassifying, destroying, special handling instructions, labeling and marking of media. Media can range from nonremovable and removable hard drives, printouts, printer ribbons, and floppy disks to anything that is not an integral part of the AIS.
a. For an overview of AIS media protection consisting of any substance or material on which information is represented or stored, see:
b. For a list of approved National Security Agency (NSA) degausser products for purging magnetic media, see:
c. For the proper way of declassifying and downgrading media (III), of marking the media (IV), of safekeeping and storing media (V), of controlling the access, dissemination, and accountability of media (VII), and for special procedures for handling and shipping of media (VIII), and the disposal and destruction of media (IX) so that the media is protected for its life expectancy, see:
When the software developers start developing/modifying code and screens, the programmers can code in the required markings or labeling of the screen's data fields and the screen's top and bottom; the same applies to printed hard copies of information. This will help serve as a reminder to the user, so that the information is protected and handled at the appropriate level of sensitivity.
d. For the proper method of shipping trusted computing system parts (software, firmware, hardware) from the vendor site to the final destination, so that the system does not get corrupted in the shipping process, see:
e. For the method to clean or purge magnetic and memory media, see:
Network security is defined as a secure communications medium and all components attached to that medium whose function is the transfer of information. Components may include AIS, packet switches, telecommunications controllers, key distribution communications components that reside in switching and transmission subsystems, and communications-related hardware and software components that reside on hosts. Network security includes protecting networks and their services from unauthorized modification, destruction, or disclosure as well as providing an assurance that the network performs its critical functions correctly and that there are no harmful side effects. Network security also provides for information accuracy. There are two views of a network security (NCSC-TG-011 (RED BOOK)) to consider:
The interconnected accredited AIS (IAA) view is one in which the network is treated as an interconnection of separately created, managed, and accredited AISs. IAA consist of multiple systems that have been accredited to operate within a range of values and may include systems that do not fall under DoD directives and have not been accredited. Connections between accredited AISs must be consistent with the mode of operation, sensitivity level, or range of levels and any other restrictions imposed by the accredited AIS. Connections to unaccredited AISs are authorized, but only nonsensitive data may be transmitted to and from such AISs.
The Single Trusted System (STS) is a view in which the network is accredited as a single entity by one Designated Approval Authority (DAA). The STS view is virtually always appropriate for local area networks (LAN) but can also be applicable to wide area networks (WAN) where a single agency or official is responsible. The STS view provides the greatest probability that security will be adequately addressed in a network, and it will be used in lieu of the IAA view whenever possible.
a. For a general overview of network security, see:
b. For Defense Information Systems Network (DISN) security requirements, see:
DISN will evolve to be a worldwide information transfer infrastructure supporting National Defense Command, Control, Communications, and Intelligence (C3I) requirements as well as other DII areas. The DISN focuses on providing integration of current systems and providing for future long-haul transmission services as well as a data transport service. The DISN DAA will assure that the security features and procedures of systems are sufficient to allow connection to the DISN network.
c. For a list of protected network services, see:
d. For guidance on how to implement the DoD 5200.28-STD requirements as they apply to networks that will interconnect trusted computing base systems, see:
e. For assistance for the Systems Engineer (SE) to interpret the NCSC-TG-005 (Red Book) requirements and implement the security features into the network design, see:
f. For the systems that need to connect to the DII, GCCS, and GCSS see:
g. The progress in the NSA MISSI program will be monitored so that as products become available to provide network security (e.g., secure network server, directory system agent, in-line network encryptors, firewalls, FORTEZZA) they are incorporated into the design.
h. For the security network management requirements, see:
COMSEC is the protection resulting from all measures designed to deny unauthorized persons information of value which might be derived from possession and study of telecommunications and to ensure the authenticity of such communications. It includes crypto security, emission security, transmission security, and physical security of handling COMSEC material and information. It provides protection for transmission of computer, voice, and radio systems signals through approved National Security Agency (NSA) techniques for sensitive and classified information. It provides a protected distribution system for classified communications circuits, wherever cost-effective and sufficiently controlled, to prevent covert penetration and interception.
a. For an overview explanation of COMSEC, required protection of classified and unclassified-sensitive information, radio systems, and an explanation of protected distribution systems and their approving authority for each environment of operation, see:
b. For a list of products that are NSA-approved/endorsed for data encryption types I and II for handling of classified and unclassified-sensitive information, see:
c. For security requirements in support of the worldwide communication infrastructure (DISN) as supported by the Defense Information Systems Agency (DISA), see:
d. The NSA MISSI products and services will be implemented as they become available to support communications in the DII and ATA architecture for voice and data transmissions.
e. For the SCI and general service communication facilities, see:
Control of compromising emanations security is the investigation, study, and control of compromising emanations from electrical and electronic equipment, which might compromise the system to foreign intelligence-gathering units. The Systems Engineer (SE), with the cooperation of the ISSO, will determine the applicable TEMPEST countermeasures and control measures sufficient to prevent foreign intelligence exploitation of compromising emanations from environments in which the equipment, systems, and facilities electronically generate, store, process, transfer, or communicate classified information. TEMPEST countermeasures shall be applied continuously throughout the life cycle management and will be implemented in proportion to the threat of exploitation and potential damage to the national security. Tactical systems that process classified information require special examination of the threat to be defeated in the tactical environment and the number of days the system is used in the garrison environment. A system/facility TEMPEST assessment/risk analysis (FTA/RA) will be performed. There are also special requirements when dealing with contractors for operating system facilities.
a. For a description of TEMPEST standards and requirements, see:
b. For the required format for the Facility TEMPEST Assessment/RA report, see:
c. For a list of products that are NSA-approved/endorsed for protection of classified processing, see:
d. For the guidelines and procedures, see:
e. For the DoD standard for equipment and facilities grounding, bonding, and shielding, see:
The guidance to develop a systems security solution is documented in the Information Systems Security Engineering (ISSE) Handbook that has been developed by the National Security Agency (NSA). This handbook provides a basic structure for developing a security solution and the system security certification and accreditation documentation. The guidance emphasizes the process to develop security needs and requirements and includes:
System security engineers will use the Sustaining Base Information Services (SBIS) ISS Plan as an example standard solution set. For those applications that will not run on the SBIS platform, they will use the SBIS lessons learned from their work on developing a system security design for compliance with the ATA security requirements. Section 6, Information Security, of the ATA will be implemented into all new programs/systems that have not progressed past the Major Army Information Systems Review Council II (MAISRC-II) point. For those systems/programs that are past the MAISRC-II point, the system engineer will show a migration plan to incorporate Section 6 of the ATA. Once the SE is familiar with the security policy doctrine for the environment(s) in which the system needs to operate and the functional proponent has developed a Security Classification Guide (SCG) to specify sensitivity of the information for special operational needs, a System Security Design Plan (SSDP) can be developed. See AR 380-19 (Information Systems Security), chapter 1, paragraphs 1-1 and 1-4 which provide a general overview of ISS, roles, and responsibilities.
The following contractual sources will provide the tools to support the requirements for a U.S. Army system security architecture.
a. ISC/ISEC and DISA technical support contracts for security.
b. A Sustaining Base Information Services (SBIS) indefinite delivery/indefinite quantity (ID/IQ) contract.
c. Other existing DoD contracts (e.g., NSA Multi-level Information Systems Security Initiative (MISSI) program, small multi-user computer (SMC), Unified Local Area Network Architecture II (ULANA-II), Defense Message System (DMS), DISN).
d. Commercial off-the-shelf (COTS) products listed in the Information Systems Security Products and Services Catalogue (published quarterly).
e. COTS products not listed in the Information Systems Security Products and Services Catalogue, but which have features that implement the security requirements.
f. Developing products that have features implementing the security requirements. This includes using the existing operating system(s) with shell scripts/subroutines running in such a way as to implement the minimum and required trusted computing base (TCB) features.
As a minimum, all AIS environments that process or handle classified or unclassified-sensitive information shall have as a minimum a Controlled Access Protection Level Two (C2) TCB of security protection. If one or more of the security requirements cannot be readily met, a timetable showing its proposed date of implementation will be developed. Security requirements which can never be met, because of unavailability of a product or design, high cost, or other factors, will be identified and evaluated in the risk assessment (RA). The Designated Approval Authority (DAA) will be presented with the relative risk of each non-implemented security requirement, and allowed to accept or reject this risk. The decision to use the system despite missing security features is ultimately that of the DAA. A list and description of the directives that apply to information security in the following areas are contained in Section 6.
a. To provide a general background overview of AIS requirements, definitions, and accreditation procedures and responsibilities, see:
b. To satisfy the minimum computer security requirements of AR 380-19 (Information Systems Security), see AR 380-19, chapter 2, section 2-3. Use the following guidance for:
(1) Accountability. For the security-relevant auditing requirement features, see:
(2) Access. For the access control features or procedures to enforce the access requirements, see:
(3) Security training and awareness. For the personnel security training and awareness requirements, see:
(4) Physical controls. For the level of control and protection that is commensurate to the maximum sensitivity of the information present, see:
(5) Marking. For the markings required on all media and screens, see:
(6) Least privilege. For the requirements to control access of each user required to do their work, see:
(7) Data continuity. For the requirements to control access of each file or data grouping and data ownership for the life cycle of the AIS, see:
(8) Data integrity. For appropriate safeguards in place to detect and minimize inadvertent or malicious modification or destruction of data, see:
(9) Contingency planning. To develop a recovery procedure if data is modified or destroyed unexpectedly, see:
(10) Accreditation. For the method in which systems go through certification and lead to an accredited system, see:
(11) Risk management. For the method used to evaluate and analyze the system for the amount of protection needed and how well the system implemented security features to protect it from attack or from the natural environment hazards, see:
(12) Security planning. For the format of the plan and how the system plans to secure the overall system from unauthorized activity and attack, see:
c. To apply the following guidance depending on the required TCB features that need to be implemented:
(1) Security policy.
(a) Discretionary access control: For the guidance on the discretionary access control requirements, see:
(b) Object reuse: For guidance on object-reuse required features, see:
(c) Labels: For the labeling required on all media and screens, see:
(d) Mandatory access control: For a guideline on configuring mandatory access control, see:
(2) Accountability.
(a) Identification and authentication (I&A): For the requirements, see:
(b) Audit: For the requirements, see:
(3) Operational assurance.
(a) System architecture: For the requirements, see:
(b) System integrity: For the requirements, see:
(c) Covert channel analysis: To ensure that the system has been designed properly and has no illegal back doors, see:
(d) Trusted facility management: To support security and accountability policies throughout a system's operation, see:
(e) Trusted recovery: To ensure the maintenance of the security and accountability properties of a system in the face of failures and discontinuities of operation, see:
(4) Life-cycle assurance.
(a) Security testing: To gain an understanding of the requirements for security testing, see:
(b) Design specification and verification: To explain the requirements and the process used to evaluate formal verification systems, see:
(c) Configuration management (CM): For guidance on the functions of CM in trusted systems, see:
(d) Trusted distribution: For the procedure to properly handle the shipping of trusted computing base systems components, see:
(5) Documentation.
(a) Security Features User's Guide (SFUG): For the required content and format of the guide, see:
(b) Trusted Facility Manual (TFM): For the required content and format of the manual, see:
(c) Design documentation: To provide guidance in understanding and meeting the design documentation requirements contained in the trusted computer system evaluation criteria (TCSEC), see:
(d) Test documentation: For the proper way to write and record security testing results to validate the security design features built into the system, see:
d. Helpful miscellaneous information:
(1) Guidance for procurement of trusted systems. For information on the language for Request for Proposal (RFP) specifications and Statements of Work (SOW), Contract Data Requirements Lists (CDRL), and Data Item Descriptions (DID), see:
(2) Guide for computer viruses. For information on the prevention, detection, and treatment of computer viruses, see:
(3) Security products. For a list of computer products that are NSA approved/endorsed for the protection of unclassified-sensitive and classified systems, see:
(4) Guide for ISSO responsibilities. For information on the ISSO job and responsibilities for AISs, see:
(5) Guide to evaluate trusted data base management design. For an interpretation to the degree of trust built into the database management system (DBMS), see:
(6) Glossary. For a definition of computer security terms, see:
MISSI and commercial building blocks are integrated into solution sets to address the needs of particular security environments. DoD has mandated the use of MISSI products for DoD managed systems. The various specifications and types of products available that implement the security services are identified in the MISSI Implementation Guide. MISSI security solution sets include the following:
The DISN backbone solution set has two purposes:
The DISN focus is on protecting the backbone and high priority hosts and users. The DISN will use MISSI products and services as well as commercial solutions. These solutions include firewalls supplemented by a strong challenge/response identification and authentication (I&A) using FORTEZZA.
The SBU to SBU solution provides security services intended primarily for the protection of SBU data. Applications to be supported include user network access, E-mail, file transfer, remote login (rlogin), and others. The DISN backbone solution is a key application of the SBU to SBU security solution set.
The Secret to SBU solution is based on the Secure Network Server (SNS), which is a high assurance firewall. The basic SNS performs the E-mail function and is called a Standard Mail Guard (SMG). Other functions such as file transfer and rlogin will be added. The SMG is used to control traffic between two networks or communities of interest. Based on the network security policies on either side of the SMG, security filters with the guard application can be configured to enforce different security policies to allow or disallow certain information flow between the Secret and SBU networks. In spanning Secret and SBU networks, the SMG allows the exchange of SBU data only.
The Secret to Secret solution is a workstation security product based on the FORTEZZA Plus cryptographic card. It uses the solutions of DISN, SBU to SBU, and the Secret to SBU as a base. The FORTEZZA Plus cards enable classified data to be encrypted and sent over SBU or public networks.
The APPLIQUE is a workstation package that is trusted. It consists of high assurance Security Monitor software coupled with FORTEZZA Plus and FORTEZZA Plus-based software. The Security Monitor software effectively turns an untrusted COTS workstation into a high assurance workstation that can provide MLS capabilities. This permits a single workstation to process information spanning a range of classification levels. APPLIQUE will support e-mail, file transfer, and rlogin capabilities and will be interoperable with workstations using FORTEZZA and FORTEZZA Plus.
The U.S. Army ISS transition strategy is based on the DGSA and the integration of MISSI products and services. The integration of MISSI technology into the U.S. Army environment requires planning, integration, testing, and the certification and accreditation for the specific environments. The recommended transition strategy is to:
The transition strategy is to move from relatively unprotected Military Network (MILNET) by adding firewall technology and FORTEZZA-based strong identification and authentication to bolster MILNET security. Secure Network Servers (SNS) are then added to establish SBU interoperability between Secret enclaves and the protected MILNET. FORTEZZA cards are added at the Secret level to bind together and protect the Secret community. APPLIQUEs and In-line Network Encryptors (INE) will be integrated across the TS and SCI communities and will provide significant Multilevel Security (MLS) capabilities at the workstation and application level for classified communities. INEs are recommended for use if TS and SCI data is sent over SBU or public networks.
| AIS | Automated Information System |
| AR | Army Regulation |
| ASD (C3I) | Assistant Secretary of Defense (Command, Control, Communications and Intelligence) |
| ATA | Army Technical Architecture |
| C2 | Control Access Protection Level Two |
| C3I | Command, Control, Communications, and Intelligence |
| C4I | Command, Control, Communications, Computers, and Intelligence |
| CAW | Certification Authority Workstation |
| CC | Common Criteria |
| CDRL | Contract Data Requirements List |
| CLNP | connectionless network protocol |
| CLNS | connectionless network service |
| CM | Configuration Management |
| COE | Common Operating Environment |
| COMSEC | Communications Security |
| COTS | commercial off-the-shelf |
| CS1 | Classified Sensitive 1 |
| CS2 | Classified Sensitive 2 |
| CS3 | Classified Sensitive 3 |
| CSC-STD | Computer Security Center Standard |
| DIW | Defensive Information Warfare |
| DA | Department of the Army |
| DAA | Designated Approval Authority |
| DBA | database administrator |
| DBMS | database management system |
| DGSA | DoD Goal Security Architecture |
| DIA | Defense Intelligence Agency |
| DIAM | Defense Intelligence Agency Manual |
| DID | data item description |
| DCID | Director of Central Intelligence Directive |
| DII | Defense Information Infrastructure |
| DIS | Defense Information System |
| DISA | Defense Information Systems Agency |
| DISN | Defense Information Systems Network |
| DMS | Defense Message System |
| DoD | Department of Defense |
| DoDD | Department of Defense Directive |
| DSA | Directory Service Agent |
| EC/EDI | Electronic Commerce / Electronic Data Interchange |
| EKMS | Electronic Key Management System |
| electronic mail | |
| FOUO | For Official Use Only |
| FTA/RA | facility TEMPEST assessment/risk analysis |
| GCSS | Global Combat Support System |
| GCCS | Global Command and Control System |
| GOSIP | Government Open Systems Interconnection Profile |
| I&A | identification and authentication |
| IAA | interconnected accredited AIS |
| IAW | in accordance with |
| ID/IQ | indefinite delivery/indefinite quantity |
| INE | In-Line Encryptor |
| IP | internet protocol |
| ISC | Information Systems Command |
| ISEC | Information Systems Engineering Command |
| ISO | International Standards Organization |
| ISS | Information Systems Security |
| ISSE | Information Systems Security Engineering |
| ISSO | Information Systems Security Office |
| I&RTS | Integration and Runtime Specification |
| JCS Pub | Joint Chiefs of Staff Publication |
| LAN | local area network |
| MAISRC-II | Major Army Information Systems Review Council II |
| MIL-HDBK | Military Handbook |
| MISSI | Multilevel Information Systems Security Initiative |
| MLS | multilevel security |
| NES | Network Encryption System |
| NATO | North Atlantic Treaty Organization |
| NCSC-TG | National Computer Security Center-Technical Guide |
| No. | number |
| NS | Nonsensitive |
| NSA | National Security Agency |
| OMB | Office of Management and Budget |
| POM | program objective memorandum |
| RA | risk assessment |
| RFP | request for proposal |
| RI | risk index |
| SBIS | Sustaining Base Information Services |
| SBU | Sensitive But Unclassified |
| SCG | Security Classification Guide |
| SCI | sensitive compartmented information |
| SDP | System Design Plan |
| SE | Systems Engineer |
| SFUG | Security Features User's Guide |
| SIOP-ESI | Single Integrated Operational Plan-Extremely Sensitive Information |
| SMC | small multi-user computer |
| SNS | Secure Network Server |
| SOW | statement of work |
| SRD | System Requirements Definition |
| SRS | System Requirements Specification |
| SSDP | System Security Design Plan |
| STD | Standard |
| STS | Single Trusted System |
| SYSADMIN | system administrator |
| TA | Technical Architecture |
| TAFIM | Technical Architecture Framework for Information Management |
| TCB | trusted computing base |
| TCSEC | trusted computer system evaluation criteria |
| TEMPEST | Telecommunications Electronics Material Protected from Emanating Spurious Transmissions |
| TFM | Trusted Facility Manual |
| TR | Technical Report |
| U.S. | United States |
| ULANA-II | Unified Local Area Network Architecture II |
| US1 | Unclassified Sensitive 1 |
| US2 | Unclassified Sensitive 2 |
| WAN | wide area network |
| Go to Reference List | |
| Back to USAISEC Technical Guidance Home Page |
27 December 1996