Requirement 1 - SECURITY POLICY - There must be an explicit and well-defined security policy enforced by the system..
Security policy shall be considered throughout the life cycle of an AIS from the beginning of concept development, through design, development, operation, and maintenance until replacement or disposal.
All systems or networks, regardless of their sensitivity, criticality, or life-cycle phase, will have a system security policy.
Security policy for AIS will be defined at concept development. Security requirements based on this policy will be considered throughout the life cycle.
Requirement 2 - MARKING - Access control labels must be associated with objects..
Requirement 3 - IDENTIFICATION - Individual subjects must be identified. Each access to information must be mediated based on who is accessing the information and what classes of information they are authorized to deal with....
Requirement 4 - ACCOUNTABILITY - Audit information must be selectively kept and protected so that actions affecting security can be traced to the responsible party.
Requirement 5 - ASSURANCE - The computer system must contain hardware/software mechanisms that can be independently evaluated to provide sufficient assurance that the system enforces requirements 1 through 4 above.
Requirement 6 - CONTINUOUS PROTECTION - The trusted mechanisms that enforce these basic requirements must be continuously protected against tampering and/or unauthorized changes.
1.2 GENERAL REQUIREMENTS
Agencies shall implement and maintain a program to assure that adequate security (see definition in App. A) is provided for all agency information collected, processed, transmitted, stored, or disseminated in general support systems & major applications.
Intelligence information shall be appropriately safeguarded at all times, including when used in information systems. The information systems shall be protected. Safeguards shall be applied such that (1) individuals are held accountable for their actions; (2) information is accessed only by authorized individuals* and processes; (3) information is used only for its authorized purpose(s); (4) information retains its content integrity; (5) information is available to satisfy mission requirements; and (6) information is appropriately marked and labeled.[ *Authorized individuals are those with the appropriate clearance, formal access approvals, and need-to-know.]
Appropriate security measures shall be implemented to ensure the confidentiality, integrity, and availability of that information. The mix of security safeguards selected for systems that process intelligence information shall ensure that the system meets the policy requirements set forth in this policy and its implementation manual.
All AIS hardware, software, and documentation and all data handled by the AIS will be protected to prevent unauthorized (intentional or unintentional) disclosure, destruction, or modification and will provide control measures. The level of control and protection will be commensurate with the maximum sensitivity of the information present in the system and will provide the most restrictive control measures required by the data to be handled. This includes personnel, physical, administrative, and configuration controls.
Data processed, stored and transmitted by information systems shall beadequately protected with respect to requirements for confidentiality, integrity, availabilityand privacy.
Classified information and sensitive unclassified information shall be safeguarded at all times while in AISs. Safeguards shall be applied so that such information is accessed only by authorized persons, is used only for its intended purpose, retains its content integrity, and is marked properly as required. When classified information is involved, the information security requirements in DoD 5200.1-R shall be met.
DISA information will be protected from unauthorized disclosure, destruction, or modification while collected, processed, transmitted, stored or disseminated.
Safeguard computer systems and information against sabotage, tampering, denial of service, espionage, fraud, misappropriation, misuse, or release to unauthorized persons. Protect hardware, firmware, software, and information against unauthorized disclosure, destruction, or modification.
IDENTIFYING SENSITIVE UNCLASSIFIED DATA. Examples of different type [sic] and categories of Sensitive Unclassified data: [See IRM-5239-08A, App. E, 3].
Controls will be established to identify, control, and protect information, particularly classified information, from unauthorized disclosure.
The following security safeguards are mandatory for computer systems used to process Sensitive Unclassified information. These security requirements can be fulfilled through a TCB or a combination of physical, information, communications, personnel, and procedural security measures including various security modes of operation. Minimum requirements are: a. Appropriate marking. b. Access control over processes, files, segments, and devices. c. Identification and authentication (user ID and password). d. Audit (system and file access). e. Protection of systems as a resource and protection against fraud, waste and abuse.
DISA information systems will be assigned an information sensitivity designation based upon their highest classification or sensitivity. Assets that are designated as classified require protection as mandated in DoD 5200.1-R, Information Security Program Regulation (reference 4a). Assets designated Sensitive but Unclassified require protection by virtue of law, federal statute, regulation, or when its disclosure, modification, or destruction would impact the DISA mission. Non-sensitive assets do not require stringent protection and, if destroyed or rendered unavailable, will not affect DISA's ongoing operational mission nor subject DISA to unwarranted legal action or create risk to the national security.
Computer systems handling Sensitive Unclassified information must protect information equal to the level of risk and magnitude of harm that could result from disclosure, loss, misuse, alteration or destruction. In this regard, The Computer Security Act of 1987 (P.L. 100-235), requires U.S. agencies to identify each computer system which contains Sensitive Unclassified information and to provide for the security and privacy of each such system.
All hardware, software, firmware, documentation, and sensitive data handled by the system shall be protected throughout its life cycle to prevent intentional or unintentional disclosure, destruction, or modification (i.e., data integrity shall be maintained). This includes having appropriate personnel, physical, administrative, and configuration controls. Such controls shall be provided for unclassified hardware, software, or firmware, or documentation that may be used to eliminate, circumvent, or otherwise render ineffective the security safeguards for classified information. Unless otherwise specified by the accrediting authority, the degree of control and protection for all IS components shall be at least equal to the highest classification and most restrictive control measures required for the processed data.
Classified information processed or stored by DON information systems shall be safeguarded as required by that level of classification.
Unclassified hardware, software, or documentation of an AIS will be protected if access to such AIS resources reveals classified information or information that may be used to eliminate, circumvent, or otherwise render ineffective the security safeguards for classified information.
Unclassified information while in AISs shall be safeguarded against tampering, loss, and destruction and shall be available when needed to protect the DoD investment in obtaining and using information and to prevent fraud, waste, and abuse. Suggested safeguards... are in OMB Circular No. A-130... and include applicable personnel, physical, administrative, and technical controls.
Handling Caveats and Handling Restrictions. Some intelligence information has handling caveats that specify control or releasability restrictions on the information.* Such information shall be controlled by agreement with the Data Owner, or under procedures established by the Data Owner, or by statute.[*Director of Central Intelligence Directive (DCID) 1/7, Security Controls on the Dissemination of Intelligence Information, 30 June 1998, DCID 5/6, Intelligence Disclosure Policy, 30 June 1998.]
Defense information labeled Classified, Unclassified Non-Sensitive, and Sensitive But Unclassified defense information in Army AIS must be safeguarded against unauthorized disclosure, modification, destruction, and denial of use. Information systems security measures must be designed to ensure confidentiality, integrity, and availability of information and AIS resources that impact on mission accomplishment. Information systems security countermeasures must also prevent unauthorized use of Army AISs.
Protect Sensitive Unclassified information the system processes equal to the level of risk that could result from disclosure, loss, misuse, alteration or destruction.
Systems that contain sensitive but unclassified information are exempt from the provisions of sections 1
Each agency's program shall implement policies, standards & procedures consistent with government-wide policies, standards and procedures issued by OMB, DoC, GSA & OPM.
Information labeled SBU must be protected to ensure confidentiality, availability, and integrity and may or may not require protection from foreign intelligence services or other unauthorized personnel. Examples may include information dealing with logistics, medical care, personnel management, Privacy Act data, contractual data, For Official Use Only (FOUO) information, and certain categories of financial data.
Different or more stringent requirements for securing national security information should be incorporated into agency programs as required by appropriate national security directives.
Commanders and accreditation authorities may impose more stringent requirements based upon a risk analysis.
Systems used for processing, handling or storing SCI information will be operated and secured in compliance with DIA Manual 50-4.
All AIS equipment used for processing, handling, and storing of SCI will be operated and secured in compliance with Defense Intelligence Agency Manual (DIAM) 50
The safeguarding of information and AIS resources (against sabotage, tampering, denial of services, espionage, fraud, misappropriation, misuse, or release to unauthorized persons) shall be accomplished through the continuous employment of safeguards consisting of administrative, procedural, physical and/or environmental, personnel, communications security, emanations security, and computer security (i.e., hardware, firmware, and software), as required. The mix of safeguards selected shall achieve the requisite level of security or protection.
For major applications, the controls of the General Support System(s) in which they operate are likely to be insufficient. Therefore, additional controls specific to the application are required. The cognizant Functional Application OPR will establish the minimum requirements necessary to ensure that adequate security is provided for all information processed, stored, or transmitted within their systems.
The mix of safeguards selected for an AIS that processes classified or sensitive unclassified information shall ensure the AIS meets the minimum requirements as set forth in enclosure 3. These minimum requirements shall be met through automation and manual means in a cost-effective and integrated manner. An analysis shall be performed using enclosure 4 to identify any additional requirements over and above the set of minimum requirements.
All DON information systems shall be protected by the continuous employment of appropriate safeguards.
For Major Applications, ensure that appropriate security controls are specified, designed into, tested, and accepted. For General Support Systems, ensure that cost-effective security products and techniques are appropriately used within the system.
All information systems regardless of classification or sensitivity will achieve compliance with the minimum security requirements described in this Section. Information systems that process non-sensitive information will be safeguarded from tampering, loss, and destruction, thereby safeguarding the DISA investment from fraud, waste, and abuse. Minimum security requirements for information systems processing non-sensitive information are indicated with an "*" following the subparagraph heading.
All AIS processing classified or SBU information will achieve the minimum requirements of this paragraph through automated or manual means.
Cost-effective ISS measures will be applied to counter identified risks....Costly or elaborate security countermeasures will be applied only when the risk analysis indicates that administrative, personnel, physical, and other less costly measures do not achieve an acceptable level of risk.
Although manual procedures are acceptable when an automated safeguard is not feasible, security safeguards should be embedded into design of AIS to ensure a secure infrastructure.
Information will be safeguarded by the application of protective measures addressed in Chapter 2....Measures taken to attain ISS objectives will be commensurate with the importance of the operation to mission accomplishment, the sensitivity and criticality of the material being processed, and the relative risks (threats and vulnerabilities) to the system.
1.3 MODES OF OPERATION AND SECURITY REQUIREMENTS DEFINITION
1.D.3 The requirements specified in this manual are based on the assumption that the system is otherwise protected at an appropriate level for the information processed on it. These other protections include appropriate levels of physical, personnel, communications, emanations, and technical surveillance countermeasures (TSCM) security, as required in other directives.
The following risk assessment procedure is extracted from CSC-STD-003-85.The procedure is used to determine the minimum evaluation class required for an AIS, based on the sensitivity of the information present in the AIS and on the clearances of its users. Any DoD component desiring to use a different method to accomplish the intent of this enclosure may do so, if prior approval has been granted by the ASD(C3I). Step 1. Determine System Security Mode of Operation. The system security mode of operation is determined [in accordance with paragraph A.1 of source].
All AIS will be accredited to operate in one of the following security processing modes: (1) Dedicated security mode. A mode of operation wherein all users who access the system directly or indirectly possess the required personnel security clearance or authorization, formal access, approval, and need-to-know for all information the system is accredited to process. (2) Systems high security mode. A mode of operation wherein all users who access the system directly or indirectly possess the required personnel security clearance or authorization and formal access approval but not necessarily a need-to-know for all information the system is accredited to process. (3) Compartmented security mode. A mode of operation wherein all users who access the system directly or indirectly possess the required personnel security clearance or authorization but not necessarily formal access approval or a need-to-know for all information the system is accredited to process. (4) Multilevel security mode. A mode of operation wherein not all users who access the system directly or indirectly possess the required personnel security clearance or authorization, formal access approval, or a need-to-know for all information the system is accredited to process.
Systems will be operated in "Systems High Mode". That means when the system is processing classified information, only those individuals possessing the requisite clearance for the highest classification of data in the system (or any media accessible through the system), and possessing the need-to-know for any of the information accessible through the system, will be allowed access.
The planned or implemented system security mode of operation must be defined. The system mode of operation is determined by completing the risk index tables identified in Enclosure 4 of the authority document, DoDD 5200.28 and is based on the sensitivity level of the data, the personnel security clearance or investigation of the users, and the user's need-to-know. The different modes of operation are: Dedicated Mode; System High Mode; Multilevel Mode; and Multilevel, Partitioned Mode.
1.E System Information Collection. The following information must be collected to determine the requirements for operating a system: 1.E.1 The category, classification, and all applicable security markings for all of the information on, or to be put on, the system; 1.E.2 The need-to-know status of the users on the system, including their formal access approval(s), clearance(s), and nationality(ies); 1.E.3 The perimeter and boundary of the system; 1.E.4 The operating environment of the system and connecting systems, including the service provided (e.g., electronic mail, Internet access), and foreign access to the system, connecting systems, and the facilities housing these systems; and 1.E.5 The technical and administrative security requirements of the system.
Systems processing unclassified may operate in several modes depending on system capabilities and security requirements. Modes of operation can be combined with other security disciplines to ensure a proper level of security.
In order to be certified and accredited, each IS must conform to a set of technical security requirements for confidentiality, integrity, and availability. The specific technical security requirements and associated assurances with which an IS must comply are provided in Chapters 4 (confidentiality), 5 (integrity), and 6 (availability) of this manual. To determine which of these requirements are appropriate for a given IS, the DAA must first ascertain the appropriate Levels-of-Concern and Protection Level for the IS.
1.3.1 SCI LEVELS OF CONCERN AND PROTECTION LEVELS
The DAA, using guidance from the Data Owner, and after examining the information characteristics of the IS in question, must determine the appropriate Levels-of-Concern ratings for confidentiality, integrity, and availability. The Level-of-Concern rating for each of these areas can be either Basic, Medium, or High. The Level-of-Concern rating is independent for each of these three areas.... When a system has more than one kind of information on it, the Level-of-Concern assigned is the highest Level-of-Concern for any information on the system. The DAA shall determine and assign a Level-of-Concern rating for confidentiality, integrity, and availability for each IS that is to be accredited.
The decision regarding the Levels-of-Concern shall be explicit for all (including interconnected) systems. The record of this decision shall be written, and the DAA shall ensure that these records are retained for the operational life of the system(s) involved. At the DAA's discretion, the decision can be made for groups of systems, but it shall be explicit.
1.3.1.1 DETERMINING THE LEVEL-OF-CONCERN
Confidentiality. Here the Level-of-Concern rating is based on the sensitivity of the information that the IS maintains, processes, and transmits....Systems that process intelligence information require a High Level-of-Concern. Since all systems accredited under the authority of this manual by definition process intelligence information, all systems accredited under this manual must be assigned a High Confidentiality Level-of-Concern.
Integrity. Here the Level-of-Concern rating is based on the degree of resistance to unauthorized modification of the information maintained, processed, and transmitted by the IS that is necessary for accomplishing the mission of its users. The greater the needed degree of resistance to unauthorized modification, the higher is the Level-of-Concern.
....For each IS, assurance commensurate with the Integrity Level-of-Concern shall be provided. Table 5.1 identifies factors used to select the appropriate Integrity Level-of-Concern ....TABLE 5.1 Integrity Level-of-Concern Basic: Reasonable degree of resistance required against unauthorized modification, or loss of integrity will have an adverse effect. Medium: High degree of resistance required against unauthorized modification, but not absolute, or bodily injury might result from loss of integrity; or loss of integrity will have an adverse effect on organizational-level interests. High: Very high degree of resistance required against unauthorized modification, or loss of life might result from loss of integrity; or loss of integrity will have an adverse effect on national-level interests, or loss of integrity will have an adverse effect on confidentiality.
3.B.2.c Availability. Here the Level-of-Concern rating is based on the degree of ready availability required for the information maintained, processed, and transmitted by the IS in order to accomplish the mission of its users. The greater the need for rapid information availability the higher the Level-of-Concern.
For each IS, assurance commensurate with the Level-of-Concern for Availability shall be provided. Table 6.1 identifies factors used to select the appropriate Availability Level-of-Concern.... Table 6.1 Availability Level-of-Concern.. Basic: Information must be available with flexible tolerance for delay,* or loss of availability will have an adverse effect. Medium Information must be readily available with minimum tolerance for delay, **or bodily injury might result from loss of availability; or loss of availability will have an adverse effect on organizational-level interests. High Information must always be available upon request, with no tolerance for delay; or loss of life might result from loss of availability; or loss of availability will have an adverse effect on national-level interests; or loss of availability will have an adverse effect on confidentiality.
The concept of Protection Levels applies only to confidentiality. Having verified that an IS will maintain, process, or transmit intelligence information and therefore that its Level of Concern for confidentiality must be High, the DAA must next ascertain the appropriate Protection Level for the IS based on the required clearance(s), formal access approval(s), and need-to-know of all direct and indirect users who receive information from the IS without manual intervention and reliable human review. It indicates an implicit level of trust that is placed in the system's technical capabilities.
The DAA must assign a Protection Level to each IS that is to be accredited. The decision regarding the Protection Levels shall be explicit for all (including interconnected) systems. The record of this decision shall be in writing, and the DAA shall ensure that these records are retained for the operational life of the system(s) involved. At the DAA's discretion, the decision can be made for groups of systems, but it shall be explicit.
Determining Protection Levels 3.C.2.a Table 4.1 presents the criteria for determining which of the five Protection Levels is appropriate for the IS being accredited.
3.C.2.a(1) An IS operates at Protection Level 1 when all users have all required approvals for access to all information on the IS. This means that all users have all required clearances, formal access approvals, and the need to know for all information on the IS.
3.C.2.a(2) An IS operates at Protection Level 2 when all users have all required formal approvals for access to all information on the IS, but at least one user lacks administrative approval for some of the information on the IS. This means that all users have all required clearances and all required formal access approvals, but at least one user lacks the need to know for some of the information on the IS.
3.C.2.a(3) An IS operates at Protection Level 3 when at least one user lacks at least one required formal approval for access to all information on the IS. This means that all users have all required clearances, but at least one user lacks formal access approval for some of the information on the IS.
3.C.2.a(4) An IS operates at Protection Level 4 when at least one user lacks sufficient clearance for access to some of the information on the IS, but all users have at least a Secret clearance.
3.C.2.a(5) An IS operates at Protection Level 5 when at least one user lacks any clearance for access to some of the information on the IS.
1.3.1.2 DETERMINING PROTECTION LEVELS
Having determined the appropriate Levels-of-Concern and Protection Level for an IS, the DAA next needs to ascertain the specific technical security requirements and assurances for confidentiality, integrity, and availability provided in Chapters 4, 5, and 6, respectively.
1.3.1.3 DETERMINING SECURITY FEATURES AND ASSURANCES
2.0 TECHNICAL
2.1 GENERAL
Implement a minimum of Class 2 (C2) functionality according to AFMAN 33-229, Controlled Access Protection (CAP).
All automated information systems that are accessed by more than one user, when those users do not have the same authorization to use all of the classified or sensitive unclassified information processed or maintained by the automated information system, shall provide automated Controlled Access Protection for all classified and sensitive unclassified information...Controlled Access Protection is the C-2 level of protection described in the Trusted Computer System Evaluation Criteria. [TCSEC]
The following risk assessment procedure is extracted from CSC-STD-003-85.The procedure is used to determine the minimum evaluation class required for an AIS, based on the sensitivity of the information present in the AIS and on the clearances of its users. Any DoD component desiring to use a different method to accomplish the intent of this enclosure may do so, if prior approval has been granted by the ASD(C3I).
Step 1. Determine System Security Mode of Operation. The system security mode of operation is determined [in accordance with [paragraph A.1 of source].
Step 2. Determine Minimum User Clearance or Authorization..[in accordance with Table 1 of source.]
Step 3. Determine Maximum Data Sensitivity Rating[in accordance with Table 2 of source]
Step 4. Determine Risk Index{in accordance with formula contained in source.]
Step 5. Determine Minimum Security Evaluation Class For Computer Based Controls.[in accordance with Table 3 of source.]
Information systems that process classified and/or sensitive but unclassified information will comply with the minimum requirements for controlled access protection. The implementation of controlled access protection or more stringent security features will be evaluated in operational environments to assess protection effectiveness.
Software trusted to make decisions involving classified information must be evaluated to meet the criteria of DOD Standard 5200.28-STD.
AIS operating in other than the dedicated security mode must provide security features that meet the trusted computing base (TCB) from DOD 5200.28-STD. as determined by the procedures in appendix D of this document. The following instructions for implementation of these provisions apply: (1) All AIS that process or handle classified or SBU information and require at least Controlled Access Protection (that is, TCB class C2 security protection) will implement required security features based on the procedures described in appendix C of this document.
3.3.1. Use computer-based security features to satisfy security requirements for information systems. Where computer-based security is not feasible, enhance existing safeguards and controls to satisfy security requirements according to AFMAN 33-229. 3.3.2. Evaluate, assess, or locally test and approve all hardware, software, and firmware products that provide security features prior to use on any accredited information system or network. Implement computer-based security solutions in the following order:3.3.2.1. Use products evaluated by the National Computer Security Center (NCSC) listed on the Evaluated Products List.3.3.2.2. Use products formally assessed by HQ AFCA listed on the Assessed Products List.3.3.2.3. Select a suitable product, then test and certify its security features according to AFSSI 5024VII. Certification must validate claims that the security features meet Air Force and DoD security policy or that additional countermeasures are required.
When acquiring a system to process either classified or Sensitive Unclassified information, adequate system internal security control mechanisms are essential to protect the system and data. Table F-1 identifies the level of trust (as defined in DOD Standard 5200.28-STD) needed to protect each level of classified or Sensitive Unclassified data in a particular mode of operation. Criticality may require a higher level of trust than that reached from the intersection of clearance and sensitivity. Presently, there are few systems meeting the established criteria. Until such systems become widely available, a combination of physical, personnel, administrative, procedural, firmware, and hardware and software controls are necessary to achieve an overall protection comparable to the identified criteria level. The DAA determines what constitutes an adequate level of overall protection for the system and data.
In instances where the introduction of controlled access protection is technically unsound or adversely impacts operational effectiveness, the Office of Primary Responsibility (OPR) of the General Support System or the Functional Application may request an exception to implementation of this policy. In cases where exceptions are requested, other safeguards may be substituted as long as the requisite level of security is maintained (e.g., physical, administrative, or procedural controls).
(2) If the procedures in appendix E require a Trusted Systems class above the trusted computing class of C2, a timetable for meeting this requirement will be determined individually for each system. This timetable will be part of the accreditation, and it must be approved by the DAA.
As defined in DOD 5200.28-STD, all computer resources designed, developed and procured, that process or handle classified or Sensitive Unclassified information, shall implement as a minimum Class C2 functionality (controlled access protection which includes a user-ID, password, audit trail and memory clearing before reuse).
Implementation of Class C2 security for all appropriate systems may not be feasible if the required security technology is not available. Responsible organizations may request waivers to MCCDC (AS) of this requirement under those conditions.
(3) These requirements will be met either by using trusted computer products listed in the NSA Information System Security and Service Catalogue, using a product not in the catalogue that has security features that meet the level of trust required for the AIS or developing a product that has security features that meet the level of trust required. In any case , the cognizant DAA will determine whether or not all security requirements in DOD 5200.28
For an existing AIS, there are cases where introduction of additional computer-based security features, according to the schedule given in subparagraphs 2
The AIS will be categorized based on the sensitivity of information that the system is authorized to process or store. (1) The AIS that process classified information will be designated by the highest classification, handling code, and category of information processed (for example, Confidential, Secret, TS/SCI, SIOP
An AIS accredited to process and/or store Sensitive Compartmented Information (SCI) may use automated means (software, firmware, or hardware) to permit classified non-SCI data to be extracted from the SCI system for use at the non-SCI classified level. This capability is permissible only if it was considered and approved as part of the security accreditation and the AIS is operating at a minimum security class of B1.
2.2 ACCESS CONTROL AND LEAST PRIVILEGE
2.2.1 ACCESS CONTROL
Access to resources and records should be limited to authorized individuals...
There shall be in place an access control policy for each AIS. It shall include features and/or procedures to enforce the access control policy of the information within the AIS.
A system operating at Protection Level(s) [1-5] shall employ the following features: Access control, including:(a) Denial of physical access by unauthorized individuals unless under constant supervision of technically qualified, authorized personnel.(b) Procedures for controlling access by users and maintainers to IS resources, including those that are at remote locations.
An access control policy will be developed to describe features and procedures for controlling and enforcing access to an information system.
Control access to prevent unauthorized persons from using network facilities.
Minimum requirements for access controls are listed below. Some pertain to classified systems only. If any of the automated requirements are not possible or available for a system, an equivalent manual method may be substituted. If the manual method is not possible, document that fact in the risk assessment. Deviations from the following minimum requirements may be necessary to accommodate conditions that vary from one computer facility to another. Conditions to consider include: the physical environment, volume, frequency, sensitivity, and criticality of processing; mode of operation; system configuration; and hardware and software functional capabilities.
Each AIS will have an associated Access control policy that will include features or procedures to enforce the access control measures required for the information within the AIS.
Control access to files, software, and devices so that only authorized users can use them.
Limit.. users to those with proper clearance and need to perform work on the system.
Use network components (e.g., trusted routers, bastion hosts, gateways, firewalls, etc.) or information systems that enforce mandatory access control and I&A to provide access controls.
All classified and Sensitive Unclassified multi-user systems must have some form of system access control. The most common type is the use of a password.
In system high, controlled, multilevel and multi-user security modes, the system must operate so users can access only authorized information.
Sensitive Unclassified information including privacy, financial, asset/resource, proprietary, or other Sensitive Unclassified information (including data aggregation) which automated systems are obligated to protect (to include the Computer Security Act of 1987), may be safeguarded against unauthorized use by installation of software/hardware log-on procedures commonly employed on remotely accessed, resource-shared systems. These procedures require each authorized user to authenticate oneself to the system. The same principle may be further developed, if deemed necessary, by applying unique passwords to protect individual files within a systems catalogue.
Specific requirements must be developed to ensure that information, when shared with other applications, can be protected consistent with the guidelines (i.e., security policy) developed for the information when it is processed within the application.
Each file or data collection on the AIS shall have an identifiable source throughout its Life Cycle. Its accessibility, maintenance, movement, and disposition shall be governed by security clearance, formal access approval, and need-to-know.
An owner or proponent will be identified for each file or data grouping on the AIS throughout its Life Cycle. The file or data grouping accessibility, maintenance, movement, and disposition will be governed by security clearance, formal access approval, need-to-know, and protective marking as appropriate. All files or data groupings will be labeled to ensure that the security classification and or special markings are maintained during storage, processing, and communication transfer.
Each data base, file, or data set must have an origin, use, and a defined set of access controls. Information classification, sensitivity, user clearance, and established need-to-know should be the basis for access controls.
The DBMS should provide file control and protection (paragraph 6.3)
Files are logical groupings of data and programs stored within a system allowing each user to access portions of the information stored. In system high, controlled, or multilevel security modes, files should be given another level of protection like data encryption to prevent compromise and to enforce need-to-know requirements.
Unless there is an overriding technical or operational problem, a terminal/desktop/laptop screen-lock functionality shall be associated with each terminal/desktop/laptop computer. When activated, a screen-lock function shall place an unclassified pattern onto the entire screen of the terminal/desktop/laptop, totally hiding what was previously visible on the screen. Such a capability shall:4.B.1.a(5)(a) Be enabled either by explicit user action or if the terminal/desktop/laptop is left idle for a specified period of time (e.g., 15 minutes or more).4.B.1.a(5)(b) Ensure that once the terminal/desktop/laptop security/screen-lock software is activated, access to the terminal/desktop/laptop requires knowledge of a unique authenticator.4.B.1.a(5)(c) Not be considered a substitute for logging out (unless a mechanism actually logs out the user when the user idle time is exceeded).
Protect against casual viewing of information by using password-protected screen savers when workstations are unattended.
Systems using automated access controls must lock users out after a predetermined number of sequential failed logon attempts. Restoral of user access after lockout shall require manual intervention by authorized personnel. For Major Applications and General Support Systems designated as mission-critical or those systems that process information classified higher than Secret, automatic lockout must occur after not more than two logon attempts. For all other systems, the lockout must occur after a maximum of three logon attempts.
Workstations and personal computers should include a local "idle lockout/screen saver" feature that automatically locks the screen and keyboard after a specified period of no activity (that is, 3
Protect the information system and data against tampering. Provide protection from outsider threats by controlling physical access to the information system itself. Provide protection from insider and outsider threats by installing keyboard locks, basic input/output system (BIOS) passwords, password-protected screen savers, add-on security software, etc., or by establishing controls for removal and secure storage of information from unattended information systems.
Terminal devices which are locked out should be "unlocked" by operators of the host computer site only after such action has been authorized by the CSSO, or, if site procedures permit, upon request of the TASO responsible for the terminal on which the lockout occurred. At locations where personal contact between the TASO/CSSO and the host system is not possible, the "unlock" authorization may be passed by telephone (preferably using a STU-III telephone in the secure mode), provided an authorized authentication system is used to confirm the identity of the requestor. Authorized manual, paper-based voice authenticators and instruction on their use are available through the COMSEC Material System (CMS).
All systems that process sensitive information will have a "timeout" protection feature that automatically terminates the user session after a predetermined period has passed without communication between the user and the system. The timeout feature may not be required if the DAA determines that the system must remain active as a communications device. However, physical security for the system will meet the requirements for storage of data at the highest level that could be received. The time period may vary, depending on the sensitivity of the data, but should not exceed 15 minutes.
...system(s) operating at Protection Level(s) [2-5] shall employ the following features:...Enforcement of Session Controls, including:4.B.2.a(16)(a) Procedures for controlling and auditing concurrent logons from different workstations.4.B.2.a(16)(b) Station or session time-outs, as applicable.4.B.2.a(16)(c) Limited retry on logon as technically feasible.4.B.2.a(16)(d) System actions on unsuccessful logons (e.g., blacklisting of the terminal or user identifier).
An AIS with remote terminal access containing classified data will have a "time-out" protection feature that automatically disconnects the remote terminal from the computer after a predetermined period has passed without communication between the terminal and the computer. The system should make periodic checks to verify that the disconnect is still valid. The automatic disconnect must be preceded by a clearing of the remote terminal's screen followed by the recording of an audit trail record for the System Administrator to use. The time period should not exceed 15 minutes but may vary depending on the sensitivity of the data, the frequency of use and location of the terminal, the strength of the audit mechanism, and other physical or procedural controls in place. The time-out feature is not required if the accreditation authority determines the AIS must remain active because it is being used as a communications device. However, physical security for the terminal will meet the requirements for storage of data at the highest level that could be received at the terminal.
Protect against unauthorized web browser access. Use protection measures in paragraph 3.5.1.4. and use dynamic host Internet protocol addressing or local operating system security features to force each workstation to log onto the network before granting web access.
Systems that process classified or SBU information will limit the number of user log-on attempts to three before denying access to that user. Users will not be re-installed until the ISSO or his designee has verified the reason for failed log-on attempts.
Disable ActiveX and Java features when visiting untrusted sites (non-.gov or -.mil sites). When mission accomplishment necessitates the need to enable these features, obtain DAA approval and update C&A documentation.
Networks and systems must automatically terminate sessions after periods of inactivity. The length of time will depend on the sensitivity of the information processed by the host system. When the network initiated the disconnect, the host must be able to detect the event and automatically log-out the user to prevent unauthorized access through the session.
Limit the number of unsuccessful attempts to access a network or networked system and lock out further attempts. Allow three attempts for networks processing unclassified information, two for classified. At a minimum, lock out the user-ID; and if possible, lock out the terminal. When a lock out occurs, notify the NSO or system operator. Only the NSO, CSSO, computer security staff or TASO administrator can authorize access reinstatement. Enforce these restrictions at each point in the network where access controls are applied (i.e., gateways, hosts).
2.2.2 LEAST PRIVILEGE
Automated or manual controls will be implemented to enforce...least privilege, and the separation of duties among users of an information system. Safeguards will be implemented to restrict users to information or functions to which the user is entitled (by virtue of clearance, formal access approval, or job title), but to no more. In the case of "need-to-know" for classified information, access must be essential for accomplishment of lawful and authorized U.S. Government purposes.
2.B.8.b Privileged users shall:2.B.8.b(1) Be United States citizens.2.B.8.b(2) Have a working knowledge of system functions, security policies, technical security safeguards, and operational security measures.2.B.8.b(3) Be limited to the absolute minimum number of privileged users needed to manage the system.2.B.8.b(4) Where technically feasible, be limited to the minimum number of privileges needed to perform their assigned duties.2.B.8.b(5) Possess a clearance equal to or higher than the highest classification of data processed on or maintained by the IS.2.B.8.b(6) Access only that data, control information, software, hardware, and firmware for which they are authorized access and have a need-to-know, and assume only those roles and privileges for which they are authorized.
Provide each user with only those system privileges needed for assigned tasks (least privilege concept).
The AIS will function so that each user has access to all of the information to which the user is entitled (by virtue of clearance, formal access approval), but to no more. In the case of "need-to-know for classified information, access must be essential for accomplishment of lawful and authorized Government purposes.
The AIS will function so that each user has access to all of the information to which the user is entitled (by virtue of clearance, formal access approval). In the case of need-to-know for classified information, access must be essential for accomplishment of lawful and authorized Government purposes. Users will also be restricted from having access to system privileges that allow operations on data and other system resources not required to perform their job.
Limit access to privileged programs (i.e., operating system, system parameter and configuration files, and databases), utilities (i.e., assemblers, debuggers, maintenance utilities), and security-relevant programs/data files (i.e., security monitor, password files, and audit files) to authorized personnel (i.e., system administrator and CSSO).
2.B.9.b General users shall:2.B.9.b(1) Access only that data, control information, software, hardware, and firmware for which they are authorized access and have a need-to-know, and assume only those roles and privileges for which they are authorized.
Only specifically identified personnel authorized by management are allowed access to system utilities provided by the operating system software or other add-on software. These utilities are usually very powerful and have fewer checks to prevent erroneous inputs. Sometimes the system will limit the scope of these utilities to prevent users from affecting other users. For example, a deletion utility should allow users to delete only their own files.
Limit the capability to conduct privileged actions (i.e., loading new users, password management, modifying and patching system routines or files, examining memory locations, real-time monitoring of user activities, and initiating or executing privileged routines) to authorized personnel.
A system operating at Protection Level(s) [4-5] shall employ the following features:...Access Control, including assurance that each user shall receive from the system only that information to which the user is authorized access.
A system operating at Protection Level(s) [2-5] shall employ the following features:...Least Privilege procedures, including the assurance that each user or process is granted the most restrictive set of privileges or accesses needed for the performance of authorized tasks.
Systems software and applications software shall function so that each user has access to all of the information to which the user is entitled (by virtue of clearance, formal access approval), but to no more. In the case of "need to know" for classified information, access must be essential for accomplishment of lawful and authorized Government purposes.
2.2.3 DISCRETIONARY ACCESS CONTROL
The TCB shall define and control access between named users and named objects (e.g., files and programs) in the ADP system.
A system operating at Protection Level(s) [2-5] shall employ the following features: Access control, including a Discretionary Access Control (DAC) Policy. A system has implemented DAC when the Security Support Structure defines and controls access between named users and named objects (e.g., files and programs) in the system. The DAC policy includes administrative procedures to support the policy and its mechanisms.
The enforcement mechanisms (e.g., self/group/public controls, access control lists, communities of interest [COIs], encryption) shall allow users to specify and control sharing of those objects by named individuals, or by defined groups of individuals, or by both, and shall provide controls to limit propagation of access rights.
The enforcement mechanism (e.g., self/group/public controls, access control lists) shall allow users to control sharing of those objects by named individuals or defined groups of individuals, or by both, and shall provide controls to limit propagation of access rights.
The discretionary access control mechanism shall, either by explicit user action or by default, provide that objects are protected from unauthorized access. These access controls shall be capable of including or excluding access to the granularity of a single user.
The discretionary access control mechanism shall, either by explicit user action or by default, provide that objects are protected from unauthorized access. These access controls shall be capable of specifying, for each named object, a list of named individuals and a list of groups of named individuals with their respective modes of access to that object. Furthermore, for each such named object, it shall be possible to specify a list of named individuals and a list of groups of named individuals for which no access to the object is to be given.
The DAC mechanism shall, either by explicit user action or by default, provide that objects are protected from unauthorized access. These access controls shall be capable of including or excluding access to the granularity of a single user.
Access permission to an object by users not already possessing access permission shall only be assigned by authorized users.
Access permission to an object by users not already permitted access shall only be assigned by authorized users.
Cryptography may also be used to separate compartments or protect "need-to-know" among cleared users on classified systems. For such uses the DAA may select the cryptographic mechanisms (including commercially available products) to be used after consulting with the Data Owner on requirements. DAAs should also consult with NSA for assistance and advice regarding the security of the proposed implementation. They should pay particular attention to key management, since appropriate secure key management is an important factor in overall system security.
A system operating at Protection Level 3 shall employ the following features: Access Control, including: Some process or mechanism(s) that allows users (or processes acting on their behalf) to determine the formal access approvals (e.g., compartments into which users are briefed) granted to another user. This process or mechanism is intended to aid the user in determining the appropriateness of information exchange.
A system operating at Protection Level 3 shall employ the following features: Access Control, including: Some process or mechanism(s) that allows users (or processes acting on their behalf) to determine the sensitivity level (i.e., classification level, classification category, and handling caveats) of data. This process or mechanism is intended to aid the user in determining the appropriateness of information exchange.
2.2.4 LABELS
Parameter Transmission. Security parameters (e.g., labels, markings) shall be reliably associated (either explicitly or implicitly) with information exchanged between systems.
Sensitivity labels associated with each ADP system resource (e.g., subject, storage object, ROM) that is directly or indirectly accessible by subjects external to the TCB shall be maintained by the TCB. These labels shall be used as the basis for mandatory access control decisions. In order to import non-labeled data, the TCB shall request and receive from an authorized user the security level of the data, and all such actions shall be auditable by the TCB.
A system operating at Protection Level 3 shall employ the following features:Marking procedures and mechanisms to ensure that either the user or the system itself marks all data transmitted or stored by the system to reflect the sensitivity of the data (i.e., classification level, classification category, and handling caveats). Markings shall be retained with the data.
A system operating at Protection Level(s) [4-5] shall employ the following features: Labeling procedures, including: Internal security labels that are an integral part of the electronic data or media. Procedures for managing content, generation, attachment, and persistence of internal labels that are documented in the SSP. Security labels that reflect the sensitivity (i.e., classification level, classification category, and handling caveats) of the information. Maintenance by the Security Support Structure of a record of the kind(s) of data allowed on each communications channel. A means for the system to ensure that labels that a user associates with information provided to the system are consistent with the sensitivity levels that the user is allowed to access.
A system operating at Protection Level(s) [4-5] shall employ the following features:.Labeling procedures, including internal and external labeling such as label integrity, exportation, subject-sensitivity labels, and device labels, as applicable.
Sensitivity labels shall accurately represent security levels of the specific subjects or objects with which they are associated. When exported by the TCB, sensitivity labels shall accurately and unambiguously represent the internal labels and shall be associated with the information being exported.
2.2.4.1 LABEL INTEGRITY
The TCB shall designate each communication channel and I/O device as either single-level or multilevel. Any change in this designation shall be done manually and shall be auditable by the TCB. The TCB shall Maintain and be able to audit any change in the security level or levels associated with a communication Channel or I/O device.
When the TCB exports an object to a multilevel I/O device, the sensitivity label associated with that object shall also be exported and shall reside on the same physical medium as the exported information and shall be in the same form (i.e., machine-readable or human-readable form). When the TCB exports or imports an object over a multilevel communication channel, the protocol used on that channel shall provide for the unambiguous pairing between the sensitivity labels and the associated information that is sent or received.
Single-level I/O devices and single-level communication channels are not required to maintain the sensitivity labels of the information they process. However, the TCB shall include a mechanism by which the TCB and an authorized user reliably communicate to designate the single security level of information imported or exported via single-level communication channels or I/O devices.
The ADP system administrator shall be able to specify the printable label names associated with exported sensitivity labels. The TCB shall mark the beginning and end of all human-readable, paged, hardcopy output (e.g., line printer output) with human-readable sensitivity labels that properly* represent the sensitivity of the output. The TCB shall, by default, mark the top and bottom of each page of human- readable, paged, hardcopy output (e.g., line printer output) with human-readable sensitivity labels that properly* represent the overall sensitivity of the output or that properly* represent the sensitivity of the information on the page. The TCB shall, by default and in an appropriate manner, mark other forms of human-readable output (e.g., maps, graphics) with human-readable sensitivity labels that properly* represent the sensitivity of the output. Any override of these marking defaults shall be auditable by the TCB.* The hierarchical classification component in human-readable sensitivity lables shall be equal to the greatest hierarchical classification of any of the information in the output that the labels refer to; the non-hierarchical category component shall include all of the non-hierarchical categories of the information in the output the labels refer to, but no other non-hierarchical categories.
2.2.4.2 EXPORTATION OF LABELED INFORMATION
2.2.4.3 SUBJECT SENSITIVITY LABELS
The TCB shall immediately notify a terminal user of each change in the security level associated with that user during an interactive session. A terminal user shall be able to query the TCB as desired for a display of the subject's complete sensitivity label.
The TCB shall support the assignment of minimum and maximum security levels to all attached physical devices. These security levels shall be used by the TCB to enforce constraints imposed by the physical environments in which the devices are located.
2.2.4.4 DEVICE LABELS
Sensitivity labels associated with each subject and storage object under its control (e.g., process, file, segment, device) shall be maintained by the TCB. These labels shall be used as the basis for mandatory access control decisions. In order to import non-labeled data, the TCB shall request and receive from an authorized user the security level of the data, and all such actions shall be auditable by the TCB.
2.2.5 MANDATORY ACCESS CONTROL
The TCB shall enforce a mandatory access control policy over all subjects and storage objects under its control (e.g., processes, files, segments, devices). These subjects and objects shall be assigned sensitivity labels that are a combination of hierarchical classification levels and non-hierarchical categories, and the labels shall be used as the basis for mandatory access control decisions. The TCB shall be able to support two or more such security levels. (See the Mandatory Access Control Guidelines.)
A system operating at Protection Level(s) [4-5] shall employ the following features:...Access Control, including a Mandatory Access Control (MAC) Policy that shall require:4.B.4.a(4)(a) The Security Support Structure to enforce a mandatory access control policy over all subjects and storage objects under its control (e.g., processes, files, segments, devices).4.B.4.a(4)(b) These subjects and objects to be assigned sensitivity labels that combine hierarchical classification levels and non-hierarchical categories; the labels shall be used as the basis for mandatory access control decisions.4.B.4.a(4)(c) The Security Support Structure to be able to support two or more such security levels.
The following requirements shall hold for all accesses between subjects and objects controlled by the TCB: a subject can read an object only if the hierarchical classification in the subject's security level is greater than or equal to the hierarchical classification in the object's security level and the non-hierarchical categories in the subject's security level include all the non-hierarchical categories in the object's security level. A subject can write an object only if the hierarchical classification in the subject's security level is less than or equal to the hierarchical classification in the object's security level and all the non-hierarchical categories in the subject's security level are included in the non-hierarchical categories in the object's security level. Identification and authentication data shall be used by the TCB to authenticate the user's identity and to ensure that the security level and authorization of subjects external to the TCB that may be created to act on behalf of the individual user are dominated by the clearance and authorization of that user.
The following requirements shall hold for all accesses between all subjects external to the TCB and all objects directly or indirectly accessible by these subjects: A subject can read an object only if the hierarchical classification in the subject's security level is greater than or equal to the hierarchical classification in the object's security level and the non-hierarchical categories in the subject's security level include all the non-hierarchical categories in the object's security level. A subject can write an object only if the hierarchical classification in the subject's security level is less than or equal to the hierarchical classification in the object's security level and all the non-hierarchical categories in the subject's security level are included in the non- hierarchical categories in the object's security level. Identification and authentication data shall be used by the TCB to authenticate the user's identity and to ensure that the security level and authorization of subjects external to the TCB that may be created to act on behalf of the individual user are dominated by the clearance and authorization of that user.
A system operating at Protection Level 4 shall employ the following features:...Access Control, including a Mandatory Access Control (MAC) Policy that shall require:4.B.4.a(4)(d) Identification and authentication data to be used by the Security Support Structure to authenticate the user's identity and to assure that the security level and authorization of subjects external to the Security Support Structure that may be created to act on behalf of the individual user are dominated by the clearance and authorization of that user.4.B.4.a(4)(e) Application of the following restrictions to all accesses between subjects and objects controlled by the Security Support Structure:4.B.4.a(4)(e)(1) A subject can read an object only if the security level of the subject dominates* the security level of the object (i.e., a subject can "read down").*Security level S1 is said to dominate security level S2 if the hierarchical classification of S1 is greater than or equal to that of S2 and the non-hierarchical categories of S1 include all those of S2.
4.B.4.a(4)(e)(2) A subject can write to an object only if two conditions are met: the security level of the object must dominate the security level of the subject, and the security level of the user's clearance* must dominate the security level of the object (i.e., a subject can "write up," but no higher than the user's clearance).* In those instances where a subject is an electronic entity (e.g., a process), then the subject is generally acting on the behalf of a user.
The TCB shall enforce a mandatory access control policy over all resources (i.e., subjects, storage objects, and I/O devices) that are directly or indirectly accessible by subjects external to the TCB. These subjects and objects shall be assigned sensitivity labels that are a combination of hierarchical classification levels and non-hierarchical categories, and the labels shall be used as the basis for mandatory access control decisions. The TCB shall be able to support two or more such security levels. (See the Mandatory Access Control guidelines.)
2.3 OBJECT REUSE
All authorizations to the information contained within a storage object shall be revoked prior to initial assignment, allocation or reallocation to a subject from the TCB's pool of unused storage objects.
Resource Control. All authorizations to the information contained within an object shall be revoked prior to initial assignment, allocation, or reallocation to a subject from the Security Support Structure's pool of unused objects.
No information, including encrypted representations of information, produced by a prior subject's action is to be available to any subject that obtains access to an object that has been released back to the system.
No information, including encrypted representations of information, produced by a prior subject's actions is to be available to any subject that obtains access to an object that has been released back to the system. There must be no residual data from the former object.
2.4 ACCOUNTABILITY
There shall be in place safeguards to ensure each person having access to an AIS may be held accountable for his or her actions on the AIS.
system(s) operating at Protection Level(s) [2-5] shall employ the following features: Auditing procedures, including: Individual accountability (i.e., unique identification of each user and association of that identity with all auditable actions taken by that individual) shall be enforced.
Safeguards will be implemented to ensure each individual having access to an information system may be held accountable for his or her actions while using the system.
Safeguards will be in place to ensure that each person having access to an AIS may be held accountable for his or her actions on the AIS.
Automated or manual controls will be implemented to enforce individual accountability
2.5 IDENTIFICATION AND AUTHENTICATION
The TCB shall require users to identify themselves before performing other actions TCB must mediate.
The identity of each user authorized access to the AIS shall be established positively before authorizing access.
Criteria will be established to positively identify each user authorized access to the system. The granularity of the identification shall be sufficient to support audit trail requirements.
Follow identification and authentication procedures according to AFMAN 33-223, Identification and Authentication.
a) Many of the security measures specified in this manual assume that an IS includes an acceptable level of individual accountability. This is normally assured by the use of unique user identifiers and authenticators. Operationally, the design of some ISs necessitates more than one individual using the same identifier/authenticator combination. Such situations are often referred to as requiring the use of group authenticators.b) In general, the use of group authenticators precludes the association of a particular act with the individual who initiated that act. In turn, this can preclude assignment of responsibility and can exacerbate the difficulties involved in incident investigation. DAAs shall avoid situations in which the group authenticator is effectively the sole access control mechanism for the system. Use of group authenticators for broader access after the use of a unique authenticator for initial identification and authentication carries much less risk. The use of group authenticators shall be explicitly authorized by the DAA.c) Positions and applications requiring the use of group authenticators shall be discussed in the SSP
A system operating at Protection Level 1 shall employ the following features:...Identification and Authentication (I&A) procedures that include provisions for uniquely identifying and authenticating the users. Procedures can be external to the system (e.g., procedural or physical controls) or internal to the system (i.e., technical). Electronic means shall be employed where technically feasible.
A system operating at Protection Level(s) [2-5] shall employ the following features:.... An Identification and Authentication (I&A) management mechanism that ensures a unique identifier for each user and that associates that identifier with all auditable actions taken by the user. The following must be specified:*(a) Initial authenticator content and administrative procedures for initial authenticator distribution.(b) Individual and Group Authenticators. (Group authenticators may only be used in conjunction with the use of an individual/unique authenticator, that is, individuals must be authenticated with an individual authenticator prior to use of a group authenticator).(c) Length, composition, and generation of authenticators.(d) Change Processes (periodic and in case of compromise).(e) Aging of static authenticators (i.e., not one-time passwords or biometric patterns)(f) History of static authenticator changes, with assurance of non-replication of individual authenticators, per direction in approved SSP.(g) Protection of authenticators to preserve confidentiality and integrity.[*Alternative controls, such as biometrics or smart cards, may be used at the discretion of the DAA. These alternative methods may have similar requirements. For example, the electronically stored version of biometric authentication patterns needs to be protected, as do password authenticators.]
Adhere to AFMAN 33-223 to ensure individual accountability and use of proper identification and authentication (I&A) procedures, and verify access.
User identity must be positively established. User access and activity in the system (material accessed and actions taken) must be controlled and open to scrutiny. Generally, this requirement is met by applying a combination of administrative procedures and hardware and software controls. The degree of reliance on hardware and software controls ranges from negligible in the dedicated security mode to extensive in the multilevel security mode.
The identity of each authorized user will be established positively before granting access.
Remotely accessed computer systems and file servers must possess features to positively identify users and authenticate their identification before processing.
In those instances where the means of authentication is user-specified passwords, the ISSO or ISSM may employ (under the auspices of the DAA) automated tools to validate that the passwords are sufficiently strong to resist cracking and other attacks intended to discover a user's password.
If automated, the password system should verify that only characters in the selected subset have been generated or selected when a password is created or changed. It must also verify that the passwords are an acceptable length.
User identification and password systems support the minimum requirements of accountability, access control, least privilege, and data integrity contained in paragraph 2-3a above. While not always appropriate for stand-alone small systems or for other systems operating in the dedicated mode, these mechanisms are often the most cost-effective and efficient method of achieving the minimum security requirements . Other techniques (for example, biometrics access control devices or smart cards) provide practical alternatives for use in conjunction with, or in place of, password systems.
..log-on attempts for classified systems should be limited to two.
Access to the IS by privileged users who either reside outside of the IS's perimeter or whose communications traverse data links (extranets, Internet, phone lines) that are outside of the IS's perimeter shall require the use of strong authentication (i.e., an I&A technique that is resistant to replay attacks).
In those instances where the users are remotely accessing the system, the users shall employ a strong authentication mechanism (i.e., an I&A technique that is resistant to replay attacks).
For Sensitive Unclassified systems, the DAA may permit up to three log-on attempts.
Certain hardware measures can be used in remotely accessed computer systems to improve means to authenticate users and terminal devices. These include the use of hardware-generated or firmware-generated characters that identify the terminal to the central system when connected, or magnetically encoded badges or cards which activate the terminal device when inserted into a reader.
The TCB shall use a protected mechanism (e.g., passwords) to authenticate the user's identity.
...the TCB shall maintain authentication data that includes information for verifying the identity of individual users (e.g., passwords) as well as information for determining the clearance and authorizations of individual users. This data shall be used by the TCB to authenticate the user's identity and to ensure that the security level and authorizations of subjects external to the TCB that may be created to act on behalf of the individual user are dominated by the clearance and authorization of that user.
The TCB shall protect authentication data so that it cannot be accessed by any unauthorized user.
The TCB shall be able to enforce individual accountability by providing the capability to uniquely identify each individual ADP system user.
The TCB shall have capability of associating [each individual user's] identity with all auditable actions of that individual.
2.5.1 TRUSTED PATH
The TCB shall support a trusted communication path between itself and user for initial login and authentication. Communications via this path shall be initiated exclusively by a user.
The TCB shall support a trusted communication path between itself and users for use when a positive TCB-to-user connection is required (e.g., login, change subject security level). Communications via this trusted path shall be activated exclusively by a user of the TCB and shall be logically isolated and unmistakably distinguishable from other paths.
A system operating at Protection Level(s) [2-5] shall employ the following features:...Identification and Authentication management mechanisms that include: Implementation and support of a trusted communications path between the user and the Security Support Structure of the desktop for login and authentication. Communication via this path shall be initiated exclusively by the user and shall be unmistakably distinguishable from other paths. In the case of communication between two or more systems (e.g. client server architecture), bi-directional authentication between the two systems.
2.6 AUDIT
There shall be an audit trail providing documented history of AIS use
An audit trail will be used to provide a documented history of information system use and record information in sufficient detail to permit a reconstruction of events should a security compromise or incident occur.
For all AIS except small computers (see the Glossary for workstations and laptops), a security audit trail will provide a documented history of AIS use. In a client server environment (CSE), audits will not be collected at the workstation level but will be maintained at the server level.
Implement auditing according to AFMAN 33-229 for C2 criteria class information systems. Information systems operating at higher criteria classes will implement audit requirements according to DoDD 5200.28-STD.[TCSEC]
Maintain audit trails on all security related activities. Audit trails may be automated or manual and should be reviewed periodically for security violations.
The use of audit trails is left to the discretion of the DAA for standalone, single user computer systems that process non-classified information.
If manual audit trails are used, the CSSO should make random checks to make sure usersare recording system usage.
The decision to require an audit trail of user access to a stand-alone, single-user AISshould be left to the discretion of the DAA
The audit trail shall be of sufficient detail to reconstruct events in determining the cause or magnitude of compromise should a security violation or malfunction occur.
system(s) operating at Protection Level(s) [2-5] shall employ the following features: Providing the capability to ensure that all audit records include enough information to allow the ISSO to determine the date and time of action (e.g., common network time), the system locale of the action, the system entity that initiated or completed the action, the resources involved, and the action involved.
The audit trail will be of sufficient detail to reconstruct events in determining the cause or magnitude of compromise or damage should a security violation or malfunction occur.
Ensure the audit mechanism records any event that attempts to change the securityprofile (e.g., access controls, security level of the subject, user password, etc.).
The TCB shall be able to create, maintain, and protect from modification or unauthorized access or destruction an audit trail of accesses to the objects it protects.
system(s) operating at Protection Level(s) [2-5] shall employ the following features: ...Protecting the contents of audit trails against unauthorized access, modification, or deletion.
Limit access to privileged programs..., utilities ..., and security-relevant programs/data files (i.e., security monitor, password files, and audit files) to authorized personnel (i.e., system administrator and CSSO).
Audit trail files must be protected to prevent unauthorized changes or destruction. As a minimum, the file should be protected so only the CSSO can make changes or delete the file.
The audit data shall be protected by the TCB so that read access to it is limited to those who are authorized for audit data.
Limit the capability to conduct privileged actions (i.e., loading new users, password management, modifying and patching system routines or files, examining memory locations, real-time monitoring of user activities, and initiating or executing privileged routines) to authorized personnel.
The manual or automated audit trail will document the following: (a) The identity of each person and device accessing the AIS. (b) The time of the access. (c) User activity sufficient to ensure user actions are controlled and open to scrutiny. (d) Activities that might modify, bypass, or negate safeguards controlled by the AIS. (e) Security-relevant actions associated with periods of processing or the changing of security levels or categories of information.
system(s) operating at Protection Level(s) [1-5] shall employ the following features:...The system's creating and maintaining an audit trail that includes selected records of:Successful and unsuccessful logons and logoffs.Accesses to security-relevant objects and directories, including opens, closes, modifications, and deletions.Activities at the system console (either physical or logical consoles), and other system-level accesses by privileged users.
As a minimum, the audit trail will record the identity of the user, time of access, interaction with the system, and sensitive functions that might permit a user or program to modify, bypass, or negate security safeguards.
Establish an audit record capable of tracing network activity and actions to an individual user.
An automated audit trail should show data collected from accesses made to system files and all unauthorized access attempts.
The manual or automated audit trail will document the following: (a) The identity of each person and devices accessing the AIS. (b) The date and time of the access. (c) User activity sufficient to ensure user actions are controlled and open to scrutiny. (d) Activities that might modify, bypass, or negate safeguards controlled by the AIS. (e) Security-relevant actions associated with periods of processing or the changing of security levels or categories of information. (f) Other security-relevant events. The list of events will be provided as part of the accreditation request for approval of the DAA.
The audit trails of networked software should be capable of identifying all user-IDs and time of access including sign-on/sign-off.
The TCB shall be able to record the following types of events: use of identification and authentication mechanisms, introduction of objects into a user's address space (e.g., file open, program initiation), deletion of objects, and actions taken by computer operators and system administrators and/or system security officers and other security relevant events.
The TCB shall also be able to audit any override of human-readable output markings.
A system operating at Protection Level 3 shall employ the following features:...An audit trail, created and maintained by the IS, that is capable of recording changes to mechanism's list of user formal access permissions. (NOTE: Applicable only if the [Access3] access control mechanism is automated.)
A system operating at Protection Level(s) [4 or 5] shall employ the following features: Auditing procedures, including: Enforcement of the capability to audit changes in security labels. Enforcement of the capability to audit accesses or attempted accesses to objects or data whose labels are inconsistent with user privileges. Enforcement of the capability to audit all program initiations, information downgrades and overrides, and all other security-relevant events (specifically including identified events that may be used in the exploitation of covert channels). In the event of an audit failure, system shutdown unless an alternative audit capacity exists.
For each recorded event, the audit record shall identify: date and time of the event, user, type of event, and success or failure of the event.
Systems are especially susceptible to exploitation by unauthorized personnel during scheduled or unscheduled system start-up, shutdown, or failure. Therefore, detailed logs, records, or other documentation of operational status at the time of failure are essential to provide audit trails and minimize the possibility of system compromise.
For identification or authorization events the origin of request (e.g. terminal ID) shall be included.
Some audit trails only record successful and unsuccessful access attempts; however, to be a more effective security tool, an audit trail must track all events including file accesses, type of transaction, peripheral usage, password changes and locking a user-ID because the password has expired. The audit trail must also track use of privileged, supervisory, or system level commands or instructions that can circumvent established security controls.
At a minimum, an audit trail must include login procedures, auditing of security-relevant events, and resource isolation that allows a computer system to be identified to a network.
Passwords should not be recorded in the audit trail so the audit trail can remain unclassified. This includes character strings incorrectly given as passwords possibly exposing a password. An audit trail should inform the user, during system log-in, of the date, time, and location of the last time the user-ID was used.
For events that introduce an object into a user's address space & for object deletion events the audit record shall include the name of the object and the object's security level.
For events that introduce an object into a user's address space & for object deletion events the audit record shall include the name of the object.
The system administrator shall be able to selectively audit the actions of any one or more users based on individual identity and/or object security level.
The TCB shall be able to audit the identified events that may be used in the exploitation of covert storage channels.
The ADP system administrator shall be able to selectively audit the actions of any one or more users based on individual identity.
Data-base systems that bypass the production of operating system audit trail data must produce their own audit trail data similar to those prescribed for the operating system. These audit trails must also be used in determining the confidentiality, integrity, and availability of the automated system and the data contained therein.
system(s) operating at Protection Level 2 shall employ the following features:....Periodic testing by the ISSO or ISSM of the security posture of the IS by employing various intrusion/attack detection and monitoring tools. The ISSO/M shall not invoke such attack software without approval from the appropriate authorities and concurrence of legal counsel. The output of such tools shall be protected against unauthorized access, modification, or detection.
system(s) operating at Protection Level(s) [3 and 4] shall employ the following features:....Periodic testing by the ISSO or ISSM of the security posture of the IS by employing various intrusion/attack detection and monitoring tools. The ISSO/M shall not invoke such attack software without approval from the appropriate authorities and concurrence of legal counsel. The output of such tools shall be protected against unauthorized access, modification, or deletion. These tools shall build upon audit reduction and analysis tools to aid the ISSO or ISSM in the monitoring and detection of suspicious, intrusive, or attack-like behavior patterns.
A system operating at Protection Level 5 shall employ the following features:...At least monthly testing by the ISSO or ISSM of the security posture of the IS by employing various intrusion/attack detection and monitoring tools. The ISSO/M shall not invoke such attack software without approval from the appropriate authorities and concurrence of legal counsel. The output of such tools shall be protected against unauthorized access, modification, or deletion. These tools shall build upon audit reduction and analysis tools to aid the ISSO or ISSM in the monitoring and detection of suspicious, intrusive, or attack-like behavior patterns.
A system operating at Protection Level [2,3,4,5, or 6] shall employ the following features:...Audit procedures that include the existence and use of audit reduction and analysis tools.
A system operating at Protection Level 4 shall employ the following features:...Auditing procedures, including: The capability of the system to monitor occurrences of, or accumulation of, auditable events that may indicate an imminent violation of security policies.The capability of the system to notify the ISSO of suspicious events and taking the least-disruptive action to terminate the suspicious events.
A system operating at Protection Level 5 shall employ the following features:...Auditing procedures, including: The capability of the system to monitor, in real-time, occurrences of, or accumulation of, auditable events that may indicate an imminent violation of security policies.The capability of the system to notify the ISSO of suspicious events and taking the least-disruptive action to terminate the suspicious events.
A system operating at the High Level-of-Concern for Availability shall implement the following features:... Periodic testing by the ISSO or ISSM of the security posture of the IS by employing various intrusion/attack detection and monitoring tools. The ISSO/M shall not invoke such attack software without approval from the appropriate authorities and concurrence of legal counsel. The monitoring tools shall be used for the monitoring and detection of suspicious, intrusive, or attack-like behavior patterns.
When technically feasible, ensure the information system aborts or suspends unauthorized user activity when detected, unless performing real-time analysis.
2.6.1 MONITORING
All ISs are subject to monitoring consistent with applicable laws and regulations, and as provided for by agency policies, procedures, and practices. As a minimum, monitoring will assess the adequacy of the confidentiality, integrity, and availability controls.
An audit trail allows the CSSO to monitor activities on the system, and reminds users that their actions are subject to monitoring.
The TCB shall contain a mechanism that is able to monitor the occurrence or accumulation of security auditable events that may indicate an imminent violation of security policy. This mechanism shall be able to immediately notify the security administrator when thresholds are exceeded, and if the occurrence or accumulation of these security relevant events continues, the system shall take the least disruptive action to terminate the event.
2.7 ASSURANCE
2.7.1 SYSTEM ARCHITECTURE
The TCB shall maintain a domain for its own execution that protects it from external interference or tampering (e.g., by modification of its code or data structures).
System Assurance shall include: (a) Isolating the Security Support Structure, by means of partitions, domains, etc., including control of access to, and integrity of, hardware, software, and firmware that perform security functions.
TCB shall maintain process isolation through the provision of distinct address spaces under its control.
System Assurance. The Security Support Structure shall maintain separate execution domains (e.g., address spaces) for each executing process.
The TCB shall be internally structured into well-defined largely independent modules. It shall make effective use of available hardware to separate those elements that are protection-critical from those that are not. The TCB modules shall be designed such that the principle of least privilege is enforced. Features in hardware, such as segmentation, shall be used to support logically distinct storage objects with separate attributes (namely: readable, writable). The user interface to the TCB shall be completely defined and all elements of the TCB identified.
The following assurances shall be provided for a system operating at a High Level-of-Concern for Integrity:... System Integrity that includes the isolation of the Security Support Structure, by means of partitions, domains, etc., including control of access to, and integrity of, hardware, software, and firmware that perform security functions.
The TCB shall be designed and structured to use a complete, conceptually simple protection mechanism with precisely defined semantics. This mechanism shall play a central role in enforcing the internal structuring of the TCB and the system. The TCB shall incorporate significant use of layering, abstraction and data hiding. Significant system engineering shall be directed toward minimizing the complexity of the TCB and excluding from the TCB modules that are not protection-critical.
The following assurances shall be provided for a system operating at a High Level-of-Concern for Integrity:....System Integrity, such that the Security Support Structure maintains separate execution domains (e.g., address spaces) for each executing process.
Resources controlled by the TCB may be a defined subset of subjects and objects in the system.
TCB shall isolate resources to be protected so that they are subject to access control and auditing requirements.
2.7.2 SYSTEM AND DATA INTEGRITY AND AVAILABILITY
Hardware and/or software features shall be provided that can be used to periodically validate correct operation of the on-site hardware and firmware elements of the TCB.
System Assurance shall include:(a) Features and procedures to validate the integrity and the expected operation of the security-relevant software, hardware, and firmware.(b) Features or procedures for protection of the operating system from improper changes.
Computer components should operate automatically to administratively detect and report system hardware and software malfunctions in time to prevent unauthorized disclosure.
Controls will be implemented to protect system software from compromise, subversion, or unauthorized manipulation.
Safeguards used by the information system must provide a level of availability commensurate with information system access control policy and all elements of the information system must function in a cohesive, identifiable, and predictable manner.
Certify all software prior to installation and use on an operational accredited system. Follow the software certification process outlined in AFSSI 5024VI and ensure DAA approval is granted. (NOTE: Freeware, public domain software, and shareware originating from questionable or unknown sources, [e.g., non-DoD bulletin boards or World Wide Web sites, etc.] are much more susceptible to malicious logic and may violate the system security policy. Base use of such software on operational need.)
Software developed or purchased to handle Sensitive Unclassified data (refer to Appendix E), must have configuration management controls to protect against unauthorized alteration.
Each Army AIS will include an identified list of executable software that is authorized to be run on that AIS. Such software will be protected from unauthorized modification to the maximum extent possible by the hardware and software mechanisms of the AIS. If the risk analysis reveals unacceptable risk from attacks by malicious software, additional measures (for example, commercial "anti-virus" programs, tamper-resistant holographic seals, and non-technical security methods) will be employed to reduce this risk to an acceptable level.
Avoid software development, testing, and debugging on operational information systems. If no alternate exists, meet the following conditions:3.4.2.1. Protect applications and files from unauthorized disclosure.3.4.2.2. Maintain the availability, confidentiality, integrity, and accountability of information system resources and information.
The following assurances shall be provided a system operating at a Medium [or] High Level-of-Concern for Integrity:....Security Support Structure Validation, including procedures or features to validate, periodically, the correct operation of the hardware, software, and firmware elements of the Security Support Structure.
System Assurance shall include: (a) Control of access to the Security Support Structure (i.e., the hardware, software, and firmware that perform operating system or security functions). (b) Assurance of the integrity of the Security Support Structure.
System Assurance shall include:. (b) Using up-to-date vulnerability assessment tools to validate the continued integrity of the Security Support Structure by ensuring that the system configuration does not contain any well-known security vulnerabilities.
There shall be safeguards in place to detect and minimize inadvertent modification or destruction of data, and detect and prevent malicious destruction or modification of data.
A system operating at the Basic, Medium [or] High Level-of-Concern for integrity shall implement the following features:. Procedures to prevent the introduction of malicious code into the system, including the timely updating of those mechanisms intended to prevent the introduction of malicious code (e.g., updating anti-viral software).
Procedures will be established to protect the information, its hardware, software, and documentation from unauthorized disclosure, destruction, or modification. The level of control and protection shall be commensurate with the maximum sensitivity level of the information and will include the security disciplines, administrative procedures, and configuration controls necessary to ensure availability of the information system.
The system should be capable of ensuring the integrity of the data being stored or processed.
Install vendor-produced system patches and implement procedural countermeasures according to AFCERT or Automated System Security Incident Support Team guidance immediately upon receipt. In the rare case where security-relevant system patches cannot be implemented, exceptions to implementing the remedies must be approved by the DAA and documented in the risk analysis. Send copies of approved exceptions and updated risk analysis to the MAJCOM IA office and command/SC (i.e., MAJCOM/SC, FOA/SC, DRU/SC).
Appropriate safeguards will be in place to detect and minimize unauthorized access and inadvertent, malicious or non-malicious modification or destruction of data. There will be an appropriate safeguard to ensure that security classification labels remain with the data if it is transmitted via a network to some other AIS.
When data base management systems containing classified defense information are used, the classified identifiable element (for example, word, field, or record) within the data base must be protected according to the highest security classification of any data-base element. If the data base cannot provide field protection, then it should provide record protection to the highest security classification level of the fields within the record. Data-base systems that do not provide protection at the record or field level will be restricted to operation in the dedicated or system high security mode. In all cases the data base management systems (DBMS) must meet the minimum trust requirements identified in paragraph 2
A system operating at the Basic Level-of-Concern for integrity shall implement the following features:... Good engineering practice with regard to COTS integrity mechanisms, such as parity checks and Cyclical Redundancy Checks (CRCs).
A system operating at the Medium [or] High Level-of-Concern for integrity shall implement the following features:... Data and software storage integrity protection, including the use of strong integrity mechanisms (e.g., integrity locks, encryption).
Memory and storage protection, implemented through hardware controls and supplemented by system software, should be exercised by the system over the memory addresses to which a user program has access.
Protect information systems (including network servers) from malicious logic (e.g., virus, worm, Trojan horse, etc.) attacks. Apply an appropriate mix of preventive measures to include user awareness training, local policies, configuration management, and anti-virus software. At a minimum:3.13.1. Implement anti-virus software on all information systems and networks.3.13.2. Where feasible, scan all incoming traffic and files for viruses at the network server level.3.13.3. Scan removable media for viruses before each use. Scan fixed media daily.3.13.4. Report all virus attacks according to AFSSI 5021.3.13.5. Use anti-virus software available through DoD channels. Forward waiver requests to HQ AFCA/GCI for approval or disapproval.3.13.6. Establish procedures to rapidly obtain, distribute, and install changes to anti-virus software on all information systems (including network servers).3.13.7. Preserve malicious logic reports as evidence for ongoing investigations.3.13.8. Include virus prevention, detection, eradication, and reporting procedures in user awareness training.
It will be considered a major security violation for any DISA employee or contractor to deliberately introduce malicious logic or computer viruses into any DISA information system. It is also a violation to withhold information necessary for effective implementation of countermeasures or antivirus procedures.
Systems must be properly maintained to ensure availability and integrity.
Safeguards used by the information system must be able to detect and minimize unauthorized modification or destruction of data. Safeguards shall ensure that DISA information and assets are protected from the potentially destructive impact of human error (inadvertent actions) as well as malicious logic and unauthorized modification of hardware, software, or data.
Ensure [ that].. personnel performing maintenance are authorized to perform the level of maintenance required.
Where the application promotes or permits public access, additional security controls should be added to protect the integrity of the application. Such controls should include segregating public accessible information from official agency records and employing techniques such as access control lists, permissions by group or domain, and separations either logical or physical.
A system operating at the Medium [or] High Level-of-Concern for integrity shall implement the following features:...Integrity, including the implementation of specific non-repudiation capabilities (e.g., digital signatures), if mission accomplishment requires non-repudiation.
A system operating at the High Level-of-Concern for Availability shall implement the following features:... Prevention of Denial of Service Attacks.* Where technically feasible, procedures and mechanisms shall be in place to curtail or prevent well-known, detectable, and preventable denial of service attacks (e.g., SYN attack).[*Only a limited number of denial-of-service attacks are detectable and preventable. Often, prevention of such attacks is handled by a controlled interface. (See Chapter 7 for a discussion on controlled interfaces.)]
A system operating at the High Level-of-Concern for Availability shall implement the following features:,,,, Priority protection that includes no "Deny Up" (i.e., a lower-priority process shall not be able to interfere with the system's servicing of any higher-priority process).
Uncleared personnel developing hardware, firmware, software, or data files shall not, to the maximum extent possible, have any knowledge that the software, hardware, firmware or data files will be used in a classified area. Before hardware, firmware, software, or data files that are developed or modified by uncleared personnel can be used in a classified processing period, appropriately cleared, technically knowledgeable personnel shall review them to ensure that no security vulnerabilities or malicious code exist.
....Software, hardware, and firmware used for maintenance or diagnostics shall be maintained within the secure computing facility and, even though unclassified, shall be separately controlled.
Personnel responsible for installing modifications to system- or security-related software, hardware, and firmware or data files on a classified IS shall be cleared to the highest level of information processed or stored.
....Software, hardware, and firmware that contains security-relevant functions (e.g., sanitization, access control, auditing) shall be validated by the ISSO to confirm that security-related features are fully functional, protected from modification, and effective.
General Support System OPRs who receive custom developed applications will establish security procedures to install, utilize, or operate such applications. The local ISSM/ISSO will review and assess the acceptability of the security documentation provided by the developing organization. As a minimum, the developing organization will provide a Security Plan, prepared IAW OMB Bulletin No. 90-08 (reference 4c), regarding the installation, operation, and maintenance of the application and a description of the existing security features. The developing organization will also submit a formal statement of accreditation.
2.7.2.1 SYSTEM BACKUP AND RECOVERY
...system(s) operating at Protection Level(s) [1-5] shall employ the following features:... Recovery procedures and technical system features to assure that system recovery is done in a trusted and secure manner. If any circumstances can cause an untrusted recovery, such circumstances shall be documented and appropriate mitigating procedures shall be put in place.
Procedures and/or mechanisms shall be provided to assure that, after an ADP system failure or other discontinuity, recovery without a protection compromise is obtained.
Computer facility managers must ensure that sufficient copies of files, documentation, and other supporting material essential to recovery and continued processing of mission essential applications are secured in a readily available location...Critical files will be routinely backed up. The periods between backup should depend on system criticality and frequency of changes...Purchased software should be backed up within the limits set by copyright laws and the purchase agreement. Official DOD generated software must be backed up or methods identified to obtain a copy...For applications critically dependent on the proper operation of the software, a backup copy of the software should be routinely compiled and compared to the working copy to detect unauthorized alterations.
All systems should have backup procedures, but not all systems will require recovery capabilities. A recovery capability can be expensive in system time and storage. To determine the proper length of time between backups and the need for a recovery capability, consider the following:(1) Criticality of the system and files.(2) How much and how often the files change.(3) Cost of backup or recovery software.(4) Manpower cost to perform backup.(5) Capability of duplicating lost information.(6) Cost of reentering lost information.(7) Effect on mission if information is not replaced.
A system operating at the Basic Level-of-Concern for integrity...[or]...at the Basic Level-of-Concern for Availability shall implement the following features:... Backup procedures, including good engineering practice with regard to backup policies and procedures.
A system operating at the Medium Level-of-Concern for integrity shall implement the following features: Backup procedures to ensure both the existence of sufficient backup storage capability and effective restoration* of the backup data. [*In this context, restoration includes both incremental and complete replacement of the system's contents from the contents of the backup media.]
A system operating at the Medium Level-of-Concern for Availability...[or] A system operating at the Medium Level-of-Concern for Integrity...shall implement the following features:...Backup storage that is located to allow the prompt restoration of data. If required by the DAA, there shall additionally be off-site backup storage of the data, as per approved SSP; such storage is intended to enable recovery if a single event eliminates both the original data and the on-site backup data. If regular off-site backup is not feasible, as, for example, on a ship at sea, alternative procedures, such a secure transmission of the data to an appropriate off-site location, should be considered.
A system operating at the Medium [or] High Level-of-Concern for Availability shall implement the following features:....Communications capability that provides adequate communications to accomplish the mission when the primary operations communications capabilities are unavailable.
A system operating at the High Level-of-Concern for Integrity... [or]...A system operating at the High Level-of-Concern for Availability shall implement the following features:...Backup procedures, including:(a) A capability to conduct backup storage and restoration of data.(b) Frequent backups of data.*(c) At least annual restoration of backup data.(d) Backup storage that is located to allow the immediate restoration of data. There shall additionally be off-site backup storage of the data, as per approved SSP; such storage is intended to enable recovery if a single event eliminates both the original and the on-site, backup data. If regular off-site backup is not feasible, as, for example, on a ship at sea, alternative procedures such as secure transmission of the data to an appropriate off-site location, should be considered.[*In this context, frequent means after any significant system hardware, software, or firmware change, and, in any case, no less often than once per year.]
A system operating at the Medium [or] High Level-of-Concern for Availability shall implement the following features.... Backup procedures to allow the restoration of operational capabilities with minimal loss of service or data. These procedures shall require:(a) Frequent backups of data.(b) To the extent deemed necessary by the DAA, assurance that the system state after the restore will reflect security-relevant changes to the system between the backup and the restore.(c) Assurance that the availability of information in storage is adequate for all operational situations, and that catastrophic damage to any single storage entity will not result in system-wide loss of information. These policies shall include, among others, procedures for ensuring the physical protection of operational and backup media and equipment, and for ensuring the continued functionality of the operational and backup media and equipment.(d) Restoration of any security-relevant segment of the system state (e.g., access control lists, cryptologic keys, deleted system status information) without requiring destruction of other system data.
A system operating at the High Level-of-Concern for Availability shall implement the following features:... Backup procedures, including:(a) Assurance that the system state after the restore will reflect security-relevant changes to the system between the backup and the restore.(b) Consideration to the use of technical features that enhance data integrity and availability including, among others, remote journaling, Redundant Array of Inexpensive Disks (RAID) 1 and above, and similar techniques.
2.7.2.2 TRUSTED FACILITY MANAGEMENT
The TCB shall support separate operator and administrator functions.
The functions performed in the role of a security administrator shall be identified. The ADP system administrative personnel shall only be able to perform security administrator functions after taking a distinct auditable action to assume the security administrator role on the ADP system. Non-security functions that can be performed in the security administration role shall be limited strictly to those essential to performing the security role effectively.
2.7.2.3 COVERT CHANNEL ANALYSIS
The system developer shall conduct a thorough search for covert channels and make a determination (either by actual measurement or by engineering estimation) of the maximum bandwidth of each identified channel. (See the Covert Channels Guideline section.)
The system developer shall conduct a thorough search for covert storage channels and make a Determination (either by actual measurement or by engineering estimation) of the maximum bandwidth of each identified channel. (See the covert channels guideline section.)
At the discretion of the DAA, a thorough search for covert channels shall be conducted, and a determination shall be made of the maximum bandwidth of each identified channel.
A thorough search for covert channels shall be conducted, and a determination shall be made of the maximum bandwidth of each identified channel.
2.7.3 SECURITY TESTING
Programs must be completely tested before becoming operational. Both valid and invalid data must be used for testing. Testing is not complete until all security mechanisms have been examined and expected results are attained and attempts to circumvent or defeat these mechanism [sic] fail.
Commercial off-the-shelf software should also be tested by a competent organization and certified by the DAA if it contains security controls. All public domain software should be tested by a competent organization and certified by the DAA to be free of any known security problems before being used.
Upon completion of maintenance or modification of software, independent testing and verification will be required before returning software to operation.
Special expertise must be used in designing and testing software for it to make critical decisions involving the protection of classified or Sensitive Unclassified information. Software that has been given this special attention is termed trusted software. Trusted software, regardless of how developed, must only be tested by an authorized agency. Trusted software must be evaluated by standards found in the DOD Standard 5200.28-STD. Formally evaluated software will receive a rating of the level of protection it provides. This rating can then be used to determine if the software is suitable for a particular security processing mode. Minimum ratings for each security mode are listed and described in Appendix F, "Security Modes of Operation."
Security included in the design of software must be tested to make sure it operates properly. Testing must be thorough since security controls must also protect against intentional hostile acts as well as accidents.
Security mechanisms of the system shall be tested & found to work as claimed in the system documentation.
The following assurance shall be provided a system operating at a Basic [or] Medium Level-of-Concern for Integrity [or] a Basic [or] Medium Level-of-Concern for Availability:...Verification by the ISSM that the necessary security procedures and mechanisms are in place; testing of them by the ISSM to ensure that they work appropriately.
The following assurance shall be provided a system operating at a High Level-of-Concern for Integrity [or] a High Level-of-Concern for Availability:...Verification by the DAA Rep that the necessary security procedures and mechanisms are in place; testing of them by the DAA Rep to ensure that they work appropriately.
Testing shall be done to assure that there are no obvious ways for an unauthorized user to bypass or otherwise defeat the security protection mechanisms of the TCB.
A team of individuals who thoroughly understand the specific implementation of the TCB shall subject its design documentation, source code, and object code to thorough analysis and testing. Their objectives shall be: to uncover all design and implementation flaws that would permit a subject external to the TCB to read, change, or delete data normally denied under the mandatory or discretionary security policy enforced by the TCB; as well as to assure that no subject (without authorization to do so) is able to cause the TCB to enter a state such that it is unable to respond to communications initiated by other users.
Testing shall include a search for obvious flaws that allow violation of resource isolation or that would permit unauthorized access to audit or authentication data.
All discovered flaws shall be removed or neutralized and the TCB retested to demonstrate that they have been eliminated and that new flaws have not been introduced. (See the Security Testing Guidelines.)
The TCB shall be found relatively resistant to penetration. All discovered flaws shall be corrected and the TCB retested to demonstrate that they have been eliminated and that new flaws have not been introduced. Testing shall demonstrate that the TCB implementation is consistent with the descriptive top-level specification. (See the Security Testing Guidelines.)
The TCB shall be found resistant to penetration. All discovered flaws shall be corrected and the TCB retested to demonstrate that they have been eliminated and that new flaws have not been introduced. Testing shall demonstrate that the TCB implementation is consistent with the descriptive top-level specification. (See the Security Testing Guidelines.) No design flaws and no more than a few correctable implementation flaws may be found during testing and there shall be reasonable confidence that few remain.
3.0 MANAGEMENT AND PROCEDURAL
3.1 GENERAL
Management controls must provide reasonable assurance against waste, loss, unauthorized use, and misappropriation.
...accountability for the custody and use of resources should be assigned and maintained.
For intelligence data, the designated Principal Accrediting Authorities with responsibility for all intelligence systems that are within their respective purviews are the DCI, EXDIR/CIA, AS/DOS (Intelligence & Research), DIRNSA, DIRDIA, ADIC/FBI (National Security Div), D/Office of Intelligence/DOE, SAS/Treasury (National Security), D/NIMA, and the D/NRO.
Per authority document, DoD Directive 5200.28, the Director, DISA, is responsible for implementing, maintaining, funding, and providing adequate resources for the DISA Information Systems Security Program. To ensure that the program receives effective management oversight, the Director, DISA, has designated the CIO as the sole Designated Approving Authority (DAA) for all DISA information systems. Additionally, the Center for Information Systems Security (CISS) has been designated as the sole DISA Certification Authority.
Key duties will be clearly delineated and separated to reduce the risk of one individual adversely affecting the entire system operation. Checks and balances will be established to detect deviations from assigned duties.
At a minimum agency (security) programs shall include the following controls:...Assign responsibility for security in each system to an individual knowledgeable in the information technology used in the system & in providing security for such technology.
A DAA shall be designated as responsible for the overall security of the AIS.The heads of DoD Components will.d. Assign official(s)) as the DAA (e.g., senior AIS policy official) responsible for accrediting each AIS under his or her jurisdiction and for ensuring compliance with AIS security requirements.
Certification authorities and accreditation authorities will be identified for all AIS as described in chapter 3...The DAA will be identified for each AIS or for networks processing classified or SBU information.
The DAA is the appointed management official tasked to determine the level of acceptable risk. The DAA is also the official tasked to authorize the operation of an information system once an acceptable level of risk has been obtained. If the level of risk is deemed acceptable, the DAA is responsible for issuing an accreditation statement. The accreditation statement indicates that the DAA formally accepts security responsibility for the operation of the system and officially declares that the specified system is adequately protected against compromise, destruction, or unauthorized modification under stated parameters of the accreditation. The DAA shall:
(1) Review and approve security safeguards, ensure that each information system is properly accredited based on its environment and sensitivity levels, and issue written accreditation statements.
(2) Ensure an effective information system security education, training, and awareness program is in place.
(3) Ensure that data ownership is established for each information system, to include accountability, access rights, and special handling requirements.
(4) Take action, where the Certification Authority has recommended a denial to accredit, to achieve an acceptable security level (e.g., allocate additional resources).
(5) Appoint a Component Information System Security Manager (CISSM).
(6) Periodically brief the Director, DISA, regarding unresolved issues relating to the accreditation of DISA information technology and other programmatic information security issues.
Systems processing intelligence information that operate at Protection Levels 4 or 5, and all components of such systems, shall be accredited only by the Director of the National Security Agency (DIRNSA), the Director of the Defense Intelligence Agency (DIRDIA), the Director of the National Reconnaissance Office (D/NRO), or the Executive Director of the Central Intelligence Agency (EXDIR/CIA). Only the DCI may further delegate the authority to accredit these systems.
A DAA will be responsible for the overall security of each AIS.
The DAA will be appointed for operational accreditation, as follows: [See AR380-19, 3-8]
The DAAs will be appointed for generic accreditation as follows: [See AR380-19, 3-8]
The Certification Authority is responsible for ensuring that information system security policy is satisfied through technical and non-technical evaluations of system compliance with stated requirements. The Certification Authority is responsible for conducting certification activities in support of the accreditation process. The Certification Authority's final report is used by the DAA in forming an accreditation decision. The Certification Authority will:
The DAA will ensure the following actions are accomplished:(1) The requirements of this regulation and other applicable procedures dealing with ISS are followed.(2) Accreditation statements issued by the DAA are based on the DAA's review and approval of the system security countermeasures employed.(3) The countermeasures approved by the DAA in the Accreditation Statement are implemented and maintained.(4) A program of recurring reviews exists for reaccrediting the AIS when significant changes to the system occur.(5) The AIS or networks that they accredit do not process data with a sensitivity level beyond the scope of the accreditation.(6) The security countermeasures selected and applied are sufficient and necessary to counteract the identified risk to the system and are cost-effective relative to other equally effective measures.(7) Security requirements are incorporated in the planning for system expansion.(8) A security education and awareness program is in place that meets the minimum requirements of this regulation.(9) An ISSM or ISSO with adequate training to carry out the duties of this function is named for each AIS or network.(10) A security plan is prepared and maintained in accordance with this regulation.
Each Designated Approving Authority (DAA) shall:
(1) Ensure security testing and evaluation is completed and documented IAW the DAA-defined information system security program goals.
(3) Provide the DAA with written recommendations for accreditation.
(4) Periodically review required safeguards as approved and identified in the accreditation documentation and ensure that the safeguards have been implemented and maintained via the compliance validation process.
(5) Identify security deficiencies and, where the deficiencies are serious enough to preclude accreditation, make recommendations to assist the organization in attaining an acceptable level of security.
NFIB members may delegate, to the extent they consider appropriate, their authority to accredit systems processing intelligence information or components of such systems that operate at Protection Levels 1, 2, or 3. But they retain ultimate responsibility for the security of the information processed in those systems.
CMS shall maintain a current directory of DAAs and a current directory of Data Owners.
a. Review and approve security safeguards of AISs and issue accreditation statements for each AIS under the DAA's jurisdiction based on the acceptability of the security safeguards for the AIS.
b. Ensure that all the safeguards required, as stated in the accreditation documentation for each AIS, are implemented and maintained.
c. Identify security deficiencies and, where the deficiencies are serious enough to preclude accreditation, take action (e.g. allocate additional resources) to achieve an acceptable security level.
d. Ensure that an Information System Security Officer (ISSO) is named for each AIS, and that he or she receives applicable training to carry out the duties of this function. It is recommended that the ISSO not report to operational elements of the AIS over which security requirements of this Directive must be enforced.
e. Require that an AIS security education and training program be in place.
f. Ensure that data ownership is established for each AIS, to include accountability, access rights, and special handling requirements.
Each Major Application will have an identified Functional Application OPR. In those cases where a Functional Application OPR cannot be determined, the DAA will assign responsibility, as necessary. Each General Support System will have an identified General Support System OPR. In those cases where a General Support System OPR cannot be determined, the DAA will assign responsibility, as necessary.
At all appropriate levels of command below Army MACOM and at DA staff and field operating agencies and at the PEO level, an information systems security manager (ISSM) will be appointed to establish and implement the ISS program for all AIS within that command or activity or for AIS under development. This includes posts, installations, and installation equivalents. These appointments will result in a chain of command for ISSM that parallels the command structure. The ISSM may not be capable of directly handling all aspects of ISS within their purview as AIS expand in geographic boundaries. The ISSMs can secure the growing complexity of personal computers (PCs), local area networks (LANs), metro area networks (MANs), and wide area networks (WANs) by assigning various tasks to ISSOs and system administrators.
Information System Security Manager (ISSM) 2.B.6.a Definition: The manager responsible for an organization's IS security program. Responsibilities of the ISSM include:2.B.6.c(1) Developing and maintaining a formal Information Systems Security Program.2.B.6.c(2) Implementing and enforcing IS security policies.2.B.6.c(3) Reviewing all SSPs (described in Appendix C) and endorsing those found to be acceptable.2.B.6.c(4) Overseeing all ISSOs to ensure that they are following established information security policies and procedures.2.B.6.c(5) Ensuring that all ISSOs receive the necessary technical and security training to carry out their duties.2.B.6.c(6) Ensuring the development of system certification documentation by reviewing and endorsing such documentation and recommending action by the DAA.2.B.6.c(7) Ensuring approved procedures are in place for clearing, purging, declassifying, and releasing system memory, media, and output.2.B.6.c(8) Maintaining, as required by the DAA, a repository for all system certification documentation and modifications.2.B.6.c(9) Coordinating IS security inspections, tests, and reviews.
2.B.6.c(10) Developing procedures for responding to security incidents, and for investigating and reporting (to the DAA Representative and to local management) security violations and incidents, as appropriate.2.B.6.c(11) Ensuring proper protection or corrective measures have been taken when an incident or vulnerability has been discovered within a system.2.B.6.c(12) Ensuring that data ownership and responsibilities are established for each IS, to include accountability, access rights, and special handling requirements.2.B.6.c(13) Ensuring development and implementation of an information security education, training, and awareness program.2.B.6.c(14) Ensuring development and implementation of procedures for authorizing the use of software, hardware, and firmware on the system.2.B.6.c(15) If a configuration management board exists, serving as a member of the board. (However, the ISSM may elect to delegate this responsibility to the ISSO).
The ISSM should be positioned organizationally to avoid having a vested interest in keeping the system operational at the expense of security.
For systems within their purview, ISSMs will
(a) Oversee the execution of the ISS training and awareness program within their command or activity.
(b) Ensure that an information systems security officer (ISSO) is appointed for each separate AIS, group of AIS, or network, as necessary.
(c) Establish an AISSP that will provide protection for all information systems and ensures all AIS and/or networks are accredited per this regulation.
(d) Periodically review the status of all AIS and networks to ascertain that changes have not occurred that affect security and negate the accreditation.
(e) Review threat and vulnerability assessments to enable the commander or manager to properly analyze the risks to the AIS information and determine appropriate measures to effectively man-age those risks.
(f) Report security incidents and technical vulnerabilities per this regulation, AR 381
(g) Implement the DODIIS COMPUSEC program and site-based accreditation, where feasible.
(h) Establish the scope of responsibilities for each ISSO using guidance from the ISSPM and applicable regulations.
Controls will be established to effectively operate an organization's information systems security program. Specifically identified are supplemental controls used in the management, operation, and use of information systems.
Each Information System Security Officer (ISSO) shall:
a. Ensure that the AIS is operated, used, maintained, and disposed of in accordance with internal security policies and practices.
b. Have the authority to enforce security policies and safeguards on all personnel having access to the AIS for which the ISSO has cognizance.
c. Ensure that users have the required personnel security clearances
d. Ensure that audit trails are reviewed periodically.
e. Begin protective or corrective measures if a security problem exists.
f. Report security incidents in accordance with DoD 5200.1-R...and to the DAA when an AIS is involved.
g. Report the security status of the AIS, as required by the DAA.
h. Evaluate known vulnerabilities to ascertain if additional safeguards are needed.
i. Maintain a plan for system security improvements and progress towards meeting the accreditation.
For each AIS or group of AIS, there will be an information system security officer (ISSO) appointed by the commander or manager of the activity responsible for the AIS. The same ISSO may be appointed for multiple AIS, particularly in the environment where personal computers, workstations, file servers, local area networks, or small systems are oriented toward the functional user as the operator.
An ISSO will be appointed for each information system or group of information systems that support the mission of the organization. The ISSO acts on behalf of the CISSM to ensure compliance with the information system security procedures developed for the local environment. The same ISSO may be appointed for multiple information systems, local area networks, or small systems or workstations that provide automated technical security controls for individual accountability, access control, and auditing. Within an organization, the ISSO may be one or more individuals who have the responsibility to ensure the security of an information system. "ISSO" does not necessarily refer to the specific functions of a single individual. ISSOs who function as System Administrators will be provided sufficient information security training to effectively administer the information systems under their cognizance.
Where the ISSO responsibilities have been contracted out, the Deputy Director, Commander, Chief, or Program Manager will designate a responsible government individual to oversee the "contractor" ISSO. ISSOs are responsible to the DAA for maintaining the approved accredited baseline. ISSOs will:
(1) Ensure that information systems under the ISSO's cognizance are operated, managed, secured, and used IAW internal security policies and procedures.
(2) Ensure that information systems under the ISSOs cognizance are accredited according to this Instruction.
(3) Ensure that users and operations personnel have the appropriate personnel security investigations, clearances, need-to-know, and authorization and that they are aware of their security responsibilities as they relate to the security of the information systems they access.
(4) review audit records and report any deviation of security practices to the ISSM.
(5) Prepare, maintain, and distribute plans and system-specific security guidance regarding the technical security controls implemented in the information system over which the ISSO has oversight.
(6) Report security incidents IAW site specific requirements for reporting computer security incidents and violations.
(7) Maintain the information systems accredited baseline according to the statement of accreditation. For information systems that have been accredited, annually evaluate the accredited baseline and document the result of the evaluation. For an information system that has been issued an Interim Authority to Operate (IATO), ensure that the plan approved for making system security improvements progress toward meeting the requirements to obtain accreditation.
Information System Security Officer (ISSO)2.B.7.a Definition: The person responsible to the ISSM for ensuring that operational security is maintained for a specific IS; sometimes referred to as a Network Security Officer.2.B.7.c Responsibilities of the ISSO include:2.B.7.c(1) Ensuring systems are operated, maintained, and disposed of in accordance with internal security policies and practices outlined in the security plan.2.B.7.c(2) Ensuring that all users have the requisite security clearances, authorization, and need-to-know, and are aware of their security responsibilities before granting access to the IS.2.B.7.c(3) Reporting all security-related incidents to the ISSM.2.B.7.c(4) Initiating, with the approval of the ISSM, protective or corrective measures when a security incident or vulnerability is discovered.2.B.7.c(5) Developing and maintaining an SSP as described in Appendix C.2.B.7.c(6) Conducting periodic reviews to ensure compliance with the SSP.2.B.7.c(7) Ensuring configuration management (CM) for security-relevant IS software, hardware, and firmware is maintained and documented. If a CM board exists, the ISSO may be a member of the CM.
2.B.7.c(7) Ensuring configuration management (CM) for security-relevant IS software, hardware, and firmware is maintained and documented. If a CM board exists, the ISSO may be a member of the CM board if so designated by the ISSM.2.B.7.c(8) Ensuring that system recovery processes are monitored to ensure that security features and procedures are properly restored.2.B.7.c(9) Ensuring all IS security-related documentation is current and accessible to properly authorized individuals.2.B.7.c(10) Formally notifying the ISSM and the DAA when a system no longer processes intelligence or SAP information.2.B.7.c(11) Formally notifying the ISSM and the DAA when changes occur that might affect accreditation.2.B.7.c(12) Ensuring that system security requirements are addressed during all phases of the system life cycle.2.B.7.c(13) Following procedures developed by the ISSM, authorizing software, hardware, and firmware use before implementation on the system.
Separation of Roles. The functions of the ISSO and the system manager/system administrator shall not be performed by the same person.
The CSSO is the key individual responsible for security related matters and should report directly to the head of the organization. The CSSO should not report to any manager or supervisor that is responsible for keeping a system operational once a security problem has been discovered. This is to insure a sense of objectivity in the decision making process with regards to operations. The position of the CSSO (officer, enlisted, or civilian employee) can either be full-time or part-time and should depend upon the facility or organization size, and the level of processing sensitivity.
The ISSO must report directly to the responsible manager of the AIS on security-related matters.
An ISSO will be appointed for a single system or cluster of information systems. For information systems undergoing development, the ISSO will function as the Application Security Engineer (ASE) responsible for designing security into life-cycle development. The ISSO/ASE should ensure that effective security products and techniques are appropriately used in the information system and should be contacted when security incidents or violations occur.
The ISSOs will perform the following duties for each AIS under their purview:
(a) Ensure systems are operated and maintained according to this regulation.
(b) Ensure managers, system administrators, and users have the appropriate security clearances, authorizations, and need-to-know. Include all personnel associated with AIS in system-specific and general awareness security training.
(c) Include all personnel associated with AIS in system-specific and general awareness security training.
(d) Conduct threat and vulnerability assessments to enable the commander or manager to properly analyze the risks to AIS information and determine appropriate measures to effectively manage those risks.
(e) Prepare, distribute, and maintain plans, instructions, guidance, and standing operating procedures (SOPs) concerning the security of system operations.
(f) Report immediately to the ISSM any attempt to gain un-authorized access to information or any system failure or suspected defect that could lead to an unauthorized disclosure, loss of integrity, or unavailability of system information.
(g) Review and evaluate the security impact of system changes, including interfaces with other AIS. Ensure that all interconnected systems comply with the security requirements levied within the infrastructure and do not have a negative security impact on any other systems with which they must interact and support.
(h) Report security incidents and technical vulnerabilities to the ISSM per this regulation, AR 381
(i) Prepare or oversee the preparation of the certification and accreditation documentation.
(j) Maintain a current network or AIS certification or accreditation statement and initiate re-certification and re-accreditation when changes affecting security have occurred.
(k) Establish and implement a system for issuing, protecting, and changing system passwords.
(l) Oversee the review of system audit trails and resolve discrepancies.
(m) Maintain access control records and ensure they are reviewed at least weekly. Ensure that only authorized personnel can gain access to the system.
(n) Ensure appointment of individuals, as needed, for securing each terminal, workstation, computer, or associated group of computers that are not under the direct control of the ISSO.
(o) Maintain close liaison with supporting system administrators to promote security at all levels of AIS operations.
An ISSO will be appointed for individual systems or groups of information systems. For a Major Application, the ISSO will function as an Application Security Engineer (ASE) and should be knowledgeable with the nature of the information processed by the application to assist in its secure design and the selection of management, operational, and technical controls needed to protect it. The ISSO for a General Support System must possess a broader knowledge of the information security technology employed in the General Support System environment and any inherent security vulnerabilities.
Network Security Officer (NSO). An NSO will be appointed for each identified network and will implement the Information System Security Program for all networks within their purview. The NSO's responsibilities are similar to those of the ISSO, with the NSO concentrating on network security and the ISSO concentrating on information system security. Depending on the size and complexity of the information system, the NSO may also be the ISSO. NSOs will:
(1) Ensure compliance with information system security procedures for the network.
(2) Develop, maintain, and distribute plans, guidance, procedures, and instructions concerning security of the network.
(3) Review and evaluate the security impact of changes to the network, including interfaces with other networks.
Terminal Area Security Officer (TASO). TASOs will be appointed for each workstation or contiguous group of workstations operating in a standalone mode. TASOs are responsible for overseeing the information system security procedures in an assigned area. TASOs may be assigned security responsibility for multiple workstations or areas as long as the ISSM/ISSO is satisfied that security is being maintained. If the TASO can logically maintain security control over multiple workstations in different rooms, then the intent of this requirement is met. TASOs will:
(1) Monitor local compliance with security procedures.
(2) Implement access management and other security related functions within the scope of their assigned authorities.
(3) Report actual or suspected security deviations to the system ISSO.
Each Major Application shall have an identified Functional Application OPR. Each OPR will define minimum security requirements that address accountability, access rights, special handling, confidentiality, integrity, and availability requirements of the Major Application under their cognizance. Functional Application OPRs shall provide for appropriate security, to include management, operational, and technical security controls. Functional Application OPRs shall also prepare a statement regarding the security integrity of the application and provide this statement to the OPR for General Support Systems.
Each General Support System that processes or operates a Major Application shall have an identified OPR. These OPRs will ensure the proper use of information technology and will implement the technical security controls that relate to the environment over which they have cognizance. The OPR will also establish minimum system requirements to include identifying system interfaces and product compatibility requirements. The General Support OPR will:
(1) Establish system-specific policy regarding the proper use of DISA information technology resources and will specify administrative sanctions for the misuse, abuse, and waste of these resources.
(2) Develop a set of system-specific rules to achieve adequate security. As a minimum, rules should include proper use of system privileges, sanctions regarding the unofficial use of DISA information technology, use of personally-owned software and hardware, connection to the INTERNET, dial-in access, and protection of system authenticators (e.g., smart cards, passwords).
(3) Provide security awareness training regarding the technical security features, system privileges, and security capabilities of general support applications made available for use. (Security awareness training will be made available prior to user access and offered within defined periodic intervals or, as a minimum, annually.)
(4) Establish a process to detect, eradicate, and report computer viruses; to identify and handle malicious code; and to describe events or conditions that may result in system penetrations by unauthorized individuals.
The COMSEC custodians and command COMSEC inspectors will be appointed as required in AR 380
Privileged Users2.B.8.a Definition: A user who has access to system control, monitoring, or administration functions. Example of privileged users include:2.B.8.a(1) Users having "superuser," "root," or equivalent access to a system (e.g., system administrators, computer operators, perhaps ISSOs); users with near or complete control of an IS or who set up and administer user accounts, authenticators, and the like.2.B.8.a(2) Users having access to change control parameters (routing tables, path priorities, addresses, etc.) on routers, multiplexers, and other key IS equipment.2.B.8.a(3) Users who have been given the authority to control and change other users' access to data or program files (e.g., applications software administrators, administrators of specialty file systems, database managers).2.B.8.a(4) Users who have been given special access for troubleshooting or monitoring an IS's security functions (e.g., those using IS analyzers, management tools).
2.B.8.c Responsibilities of privileged users include:2.B.8.c(1) Protecting the root or superuser authenticator at the highest level of data it secures and not sharing the authenticator and/or account.2.B.8.c(2) Reporting all suspected security-related IS problems to the ISSO or ISSM.2.B.8.c(3) Using special access or privileges granted only to perform authorized tasks and functions.2.B.8.c(4) Enrolling authorized users in an IS.2.B.8.c(5) Notifying the ISSO of any system configuration changes that might adversely impact system security.
Command intelligence officer (ODCSINT/G2/S2). For each network, the command intelligence officer or activity equivalent will be identified to assume the responsibility for identifying and assessing foreign intelligence threats to command assets.
2.B.9.b General users shall:...2.B.9.b(2) Immediately report all security incidents and potential threats and vulnerabilities involving an IS to the appropriate ISSO.2.B.9.b(3) Protect their authenticators and report any compromise or suspected compromise of an authenticator to the appropriate ISSO.2.B.9.b(4) Ensure that system media and system output are properly classified, marked, controlled, stored, transported, and destroyed.2.B.9.b(5) Protect terminals/workstations from unauthorized access.2.B.9.b(6) Inform the ISSO when access to a particular IS is no longer required (e.g., completion of project, transfer, retirement, resignation).2.B.9.b(7) Observe rules and regulations governing the secure operation and authorized use of an IS.
2.B.9.b(8) Use the IS only for authorized purposes.2.B.9.b(9) Not introduce malicious code into any IS or physically damage the system.2.B.9.b(10) Not bypass, strain, or test security mechanisms. If security mechanisms must be bypassed for any reason, users shall coordinate the procedure with the ISSO and receive written permission from the ISSM for the procedure.2.B.9.b(11) Not introduce or use unauthorized software, firmware, or hardware on an IS.2.B.9.b(12) Not relocate or change IS equipment or the network connectivity of IS equipment without proper security authorization.
The command intelligence officer will
(a) Ensure the Command Statement of Intelligence Interest (SII) (AR 381
(b) Provide assistance in the identification of threat factors impacting upon the risk management approach for implementing security safeguards in accordance with paragraph b above.
(c) Coordinate with national intelligence production agencies on behalf of commanders and managers to request information to fill intelligence gaps developed during any phase of the AISSP process.
3.2 LIFE-CYCLE MANAGEMENT
Plans and procedures will be established to implement the required automated and manual controls to ensure the confidentiality of classified and/or sensitive but unclassified information.
Compliance with ISS requirements is an integral part of the Information Management Area (IMA), the Army technical architecture, and life-cycle management of information systems defined in AR 25
This instruction shall be reviewed for applicability to all DON information systems being acquired in accordance with references (b), (n), (o), and (p). The INFOSEC policy and requirements are applicable throughout the life cycles of all DON systems...At each milestone decision point, INFOSEC requirements shall be discussed in sufficient detail and tailored to the milestone under review and the complexity of the project. The discussion shall specifically address the issues of confidentiality, integrity and availability.
Information systems security shall be an integral part of all system life-cycle phases for all systems.
Security planning is an essential part of any program, system, development project, or procurement action. Computer security addresses each phase of the system life cycle. As defined in the LCM manual (MCO P5231.1) and augmented with the System Development Methodology (SDM) process, computer security requirements are dictated by the system being developed, the security mode being implemented and the degree of trust under which the system must operate. Security is relative to all other requirements of the system.
The life-cycle process of a system and its software are addressed in MCO P5231.1 and require that computer security elements be addressed explicitly in each Life-Cycle Management (LCM) phase. This is critical at the conceptual and design phases. Security added after these phases is often ineffective and more expensive.
3.2.1 RISK MANAGEMENT
There shall be in place a risk management program to determine how much protection is required, how much exists, and the most economical way of providing the needed protection.
Risk management. A risk management program will be put in place to determine what level of protection is required, what protection currently exists, and the most economical way of providing the needed protection....Each AIS handling classified or SBU information will be subject to a risk management program per Chapter 5 and will undergo a detailed review leading to formal accreditation according to chapter 3.
The most effective means of protecting automated systems handling classified and/or Sensitive Unclassified information is through risk management procedures. Because each computer facility and operating environment is unique, management must identify those resources to be protected and analyze the risk of espionage, sabotage, damage and theft to determine the minimum level of protection. The objective of risk management is to achieve the most effective safeguards against the following deliberate or inadvertent acts. The most effective means of protecting automated systems handling classified and/or Sensitive Unclassified information is through risk management procedures. Because each computer facility and operating environment is unique, management must identify those resources to be protected and analyze the risk of espionage, sabotage, damage and theft to determine the minimum level of protection. The objective of risk management is to achieve the most effective safeguards against the following deliberate or inadvertent acts.
a. Unauthorized Disclosure of Information...b. Denial of Service or Use...c. Unauthorized Manipulation of Information...d. Unauthorized Personnel.
All risk analyses will evaluate the possible vulnerabilities and the security impact on associated AIS and networks within the area of responsibility
A risk management program will be developed to periodically review and assess the implemented security controls. The program will determine the effectiveness of the protection currently afforded and will assess what additional protective measures are needed to achieve an acceptable level of operating risk based upon the identified threats.
Risk management is relevant to the entire life cycle of an IS. During IS development, security countermeasures are chosen. During IS implementation and operation, the effectiveness of in-place countermeasures is reconfirmed, and the effect of current threat conditions on system security is assessed to determine if additional countermeasures are needed to sustain the accredited IS's security. In scheduling risk management activities and designating resources, careful consideration should be given to Certification and Accreditation (C&A) goals and milestones. Associated risks can then be assessed and corrective action taken for unacceptable risks. Risk management requires the routine tracking and evaluation of the security state of an IS.
The DoD Directive 5200.28 requires all computer resources that process or handle Classified or Sensitive Unclassified information to implement at least Class C2 functionality (Controlled Access Protection). If these Class C2 requirements cannot be met (including manual alternatives), they should be documented in the risk assessment.
The risk management process includes:a Analysis of the threats to and vulnerabilities of an information system, as well as of the potential impact that losing the system's information or capabilities would have on national security. This analysis forms a basis for identifying appropriate and cost-effective countermeasures.b Risk mitigation. Analysis of trade-offs among alternative sets of possible safeguards.c Residual risk determination. Identification of the risk remaining after applying safeguards.d Acceptable level of risk. Judicious and carefully considered assessment by the appropriate DAA that the residual risk inherent in operating the IS after implementing all proposed security features is acceptable.e A reactive or responsive risk management process. To facilitate investigation of, and response to, incidents.
Information will be safeguarded by the application of protective measures addressed in Chapter 2. Applicability of safeguards will be determined through the risk management review and may consist of the following: (1) Hardware security, (2) Software security, (3) Procedural security, (4) Telecommunications security, (5) Personnel security, (6) Physical security, (7) Network security, (8) Firmware, (9) TEMPEST per AR 381-14....Cost-effective ISS measures will be applied to counter identified risks....Costly or elaborate security countermeasures will be applied only when the risk analysis indicates that administrative, personnel, physical, and other less costly measures do not achieve an acceptable level of risk.
For interconnected systems, all of the requirements stated in paragraph 9.B.2, above, shall be applied to connections, including any changes or requested changes to, and exploitation (potential or real) of, connections.
The following, additional risk management considerations apply when systems are interconnected:a The risk management process must address new risks encountered by individual systems and the interconnected infrastructures to which they will connect.b The risk management process must address the concerns and requirements of the organizations and elements (e.g., Data Owners) that are part of the information infrastructure being used to achieve interconnectivity (e.g., Intelink, JWICS, IC e-mail).c Additional constraints can arise due to organizational commitments to specific technologies or architectures, variations in policies or treaty agreements.d Risk management responsibilities may be shared by multiple DAAs.
Testing shall include:(a) Security Penetration Testing to determine the level of difficulty in penetrating the security countermeasures of the system.(b) Formation of an Independent Verification and Validation team that at least annually assists in security testing and performing validation and verification testing of the system.
Data bases with a DBMS should be given additional protection because of increased ease of obtaining correlated data. A DBMS combines information and provides tools for correlating the information to obtain additional information through aggregation. Because new information may be of a higher sensitivity than the original, it may be necessary to protect the entire data base at a higher level than individual data elements of the data base. During the threat and vulnerability analysis of the risk assessment, systems with a DBMS could have a slightly higher threat identified.
A security posture statement is developed by summarizing the safeguards selected to meet the security requirements. This statement will be provided to the DAA with comments and recommendations such as those listed below:(1) Accredit the AIS or LAN for processing in a particular mode of operation for a certain classification level. (This should be recommended when the security posture of the AIS or LAN is very high and when the residual risk is at an acceptable level.)(2) Grant an IATO for a period of 90 days while additional security safeguards are installed. (This recommendation should be made when the security posture of the AIS or LAN requires enhancement due to a high level of residual risk.)(3) Deny approval to operate. (This recommendation should be made when the AIS or LAN has a very low security posture and the residual risk is unacceptable.)
....Risk management activities provide important information for DAAs and typically include:a Risk analysis. The analysis and assessment of information regarding threats, vulnerabilities and assets.b Cost/benefit analysis. An analysis of the costs of providing and maintaining a safeguard versus the cost of losing or compromising the information or IS resource, including the operational impact of implementing a security safeguard.c Security test and evaluation. An analysis of the safeguards protecting an IS in a given operational environment, for the purpose of determining the security posture of that system.d Countermeasure implementation. The implementation of any action, device, procedure, technique, or other measure that reduces risk.e Penetration testing. Security testing in which the testers attempt to circumvent the security features of an IS based on their understanding of the system design and implementation.f IS review. A periodic review of the security posture of an IS, done at regular intervals and whenever there are any major changes to the IS.
The review of the security posture statement and recommendations are a responsibility of commanders or managers who rely on advice from ISS, counterintelligence, physical security, and other functional area experts. Identifying areas of exceptional or unacceptable risk is directly related to the organizational mission, goals, and objectives as stated by the commander or manager. At this point in the risk management process, commanders can influence the commitment of resources to obtain the most effective security safeguard and financial return on the investment. This analysis may reveal areas where reduced security is appropriate, based upon a low level of risk to mission objectives. These savings may then be applied to other security requirements.
Chapters 3, 4, 5, and 6 provide guidance for determining the correct safeguards to employ at the selected Integrity and Availability Levels-of-Concern and the Confidentiality Protection Level. Chapter 7 provides guidance regarding the appropriate safeguards to employ when interconnecting information systems and using advanced technology. This guidance is generic, and addresses only minimum security requirements. Specific threats, vulnerabilities, or constraints associated with an IS and its environment may impose additional security requirements on an IS or the substitution of safeguards from different security disciplines.
If existing risks are determined to be unacceptable and require countermeasures impractical or impossible to implement, the commander or DAA should terminate the operation of the system.
The selection of security controls must include a consideration of functional, technical, and economic feasibility and operational efficiency. Security requirements generally broaden managerial, operational, and administrative procedures, and in some cases, separate expenses occur that are directly attributable to these requirements. Only the commander or DAA can properly judge and balance the additional expense of security against operational efficiency. Commanders and organizational leadership must completely understand the impact of AIS on mission accomplishment and the risks involved in operating the AIS. The commander or DAA must, therefore, resolve any perceived conflict between operational and security considerations.
If penetration testing is a countermeasure to be employed, see AR 380
An effectively applied risk analysis should lead to a series of interrelated countermeasures to be implemented according to a plan approved by the commander or DAA. The commander or DAA must always participate in this process because of the risk resulting from growing dependence upon AIS.
Initial information gathering for the risk management process determines mission requirements (e.g., requirements for timeliness, confidentiality, availability, and correctness of information), resources available to mitigate risks (e.g., financial, staffing), constraints (e.g., commitment to use specific information technologies, architectures, or products), and applicable policies and requirements. This information should be made available and updated as necessary throughout the IS life cycle.
Organizational and operational dynamics demand a continuous review of the risk management program for effectiveness. Commanders must be assured that controls are providing the desired results. This process is an important step in ensuring the documented security techniques have not created a more serious vulnerability or risk. The collective effectiveness of applied countermeasures is the basis for future security actions that assist in identifying problem areas and additional security requirements.
A risk assessment shall be performed for each IS to identify specific areas that require safeguards against deliberate or inadvertent unauthorized disclosure, modification, or destruction of information; denial of service; and unauthorized use of the IS. Countermeasures shall be applied in those areas to eliminate or adequately reduce the identified risk. The risk assessment shall be based on the accompanying manual, input from the organization's counterintelligence (CI) component, the organization's mission requirements, the classification and sensitivity of the information, and a balanced, cost-effective application of security disciplines and technologies. These security disciplines include, but are not limited to, information systems security, operations and administrative security, personnel security, physical security, and communications security.
The principles of risk assessment and mitigation will be used to ensure that organizations assess, reduce, and continually manage the risks to DISA information regardless of the technology used and to select and implement those countermeasures which effectively satisfy the requirements of confidentiality, integrity, and availability.
3.2.2 SECURITY REQUIREMENTS
Information system requirements documents must specify security requirements.
The AIS developer is responsible for ensuring the early and continuous involvement of the users, information system security officers, data owners, and DAA(s) in defining and implementing security requirements of the AIS.
Security requirements for systems that process classified and sensitive but unclassified information shall be identified prior to purchase of equipment or services.
Commanders and managers are responsible for implementing the AISSP in their command or activity and will ensure the following is accomplished:...Requests for new systems or changes to existing systems include security requirements appropriate to the system's concept of operation. Once validated, these security requirements must be incorporated into the system design and defined in procurement contracts.
Statements of security-related requirements will be accomplished in the earliest phases of AIS development and followed through subsequent phases of the system development life cycles.
The AIS developer must ensure the early and continuous involvement of the PEO, PM, the functional proponent, users, ISSM, ISSO data owners, certification authority, and DAAs in defining and implementing security requirements of the AIS.
3.2.3 SECURITY PLANS
Plan for adequate security of each general support system as part of the...IRM planning process. The security plan shall be consistent with guidance issued by NIST.
There shall be an evaluation plan for the AIS showing progress towards meeting full compliance with stated security requirements through the use of necessary computer safeguards.
Documentation shall include: A System Security Plan (see Appendix C).A Security Concept of Operations (CONOPS) (the Security CONOPS may be included in the System Security Plan). The CONOPS shall at a minimum include a description of the purpose of the system, a description of the system architecture, the system's accreditation schedule, the system's Protection Level, integrity Level-of-Concern, availability Level-of-Concern, and a description of the factors that determine the system's Protection Level, integrity Level-of-Concern, and availability Level-of-Concern.
System Security Plans (SSPs). An SSP shall be developed for each DISA Major Application and General Support System. (Guidance for developing SSPs is provided in chapter 3 of this Instruction.)
There will be a security plan for AIS processing classified information and SBU information, showing the steps planned to comply fully with stated security requirements..... An AIS security plan will be developed and maintained for the life of each AIS, including prototype, test, and developmental systems. The security plan evolves through system life cycle and security requirements into the Security Plan/Accreditation Document... The security plan evolves into the accreditation document and will be maintained to reflect system changes...Appendix D contains the security plan format, which is the basis for the accreditation documentation.
A System Security Plan (SSP) should be developed and maintained for all computer systems (reference (b)). This plan includes the protection strategy planned, including the certification and accreditation processes.
The impact of dial-in diagnostics and maintenance must be evaluated as an integral part of the security plan.
IAW the authority document, the Computer Security Act of 1987, each Major Application or General Support System that processes sensitive (classified or sensitive but unclassified) information will have a security plan. DISA has developed a standardized system security plan (SSP) that is compliant with OMB Bulletin No. 90-08, Guidance for Preparation of Security Plans for Federal Computer Systems that Contain Sensitive Information (reference 4c). The DISA Information System Security Plan (depicted in figure 3-1) is the format to be used when developing SSPs.
An SSP is required for all DISA information systems. Figure 3-1 provides a sample security plan that conforms to the requirements identified in Appendix A of OMB Bulletin No. 90-08 (reference 4c) and the U.S. Department Of Commerce Guidelines for Developing and Evaluating Security Plans for Sensitive and Classified Systems, June 1992. Where applicable, references to guidelines in OMB Bulletin No. 90-08 are shown in brackets { }. All DISA activities will use this format when submitting their SSPs. Section IV of the DISA SSP titled, Additional Comments, will be used to identify proposed safeguards for systems under development or modification methods used to ensure that up-front security requirements will be met.
Request for SSP exemptions will be submitted by the ISSO through the ISSM to the DISA CISSM. Specific, written justification must accompany all such requests.
A completed SSP will be considered to be at least sensitive but unclassified information and will be marked and safeguarded appropriately.
A completed SSP for systems that process classified information will be marked and safeguarded in a manner consistent with the classification level and sensitivity of the system in question. If the SSP is classified, the classification level of each paragraph and section must be indicated. Where feasible, classified SSP data should be supplied on a separate attachment and referenced appropriately.
A summary of the security plans shall be incorporated into the strategic IRM plan required by the Paperwork Reduction Act...and Section 8(b) of this circular. (OMB Circular A-130)
3.2.4 SECURITY SPECIFICATIONS
Mandatory statements of safeguard requirements shall be included, as applicable, in the acquisition and procurement specifications for AISs. The statements shall be the result of an initial risk assessment, and shall specify the level of trust requirement under DoD 5200.28-STD.
Security requirements for systems that process classified and sensitive but unclassified information shall be identified prior to purchase of equipment or services. These security requirements will be included in Statements of Work (SOW), requests for proposals, contracts, and other similar acquisition documents.
A security requirement statement must be part of the requirements documents for software on sensitive or critical systems. This statement should be based on a preliminary sensitivity and criticality analysis and must describe security software requirements needed to adequately protect the system and the information it processes.
AIS procurement packages will include security requirements that are based on stated needs and a cost-benefit analysis.
Commanders and managers are responsible for implementing the AISSP in their command or activity and will ensure the following is accomplished:...Requests for new systems or changes to existing systems include security requirements appropriate to the system's concept of operation. Once validated, these security requirements must be incorporated into the system design and defined in procurement contracts.
Statements of security requirements will be included, as applicable, in the acquisition and procurement specifications for AIS. The statements will reflect an initial risk assessment and will specify the required level of trust per DOD 5200.28
3.2.5 SYSTEM AND SOFTWARE DESIGN AND DEVELOPMENT
Software development and related activities (e.g. systems analysis) shall be controlled by physical controls (e.g. two person control) and protected when it is determined that the software shall be used for handling classified or sensitive unclassified data.
Activities that plan and design information systems shall have adequate internal controls that provide reasonable assurance that the recording, processing, and reporting of data are properly performed during operation of the information system and that they conform with applicable security regulations, policy, and requirements, as stated in the authority document DoDD 5200.28 and the DoD Technical Architecture Framework for Information Management (TAFIM), Volume 6, DoD Goal Security Architecture, 30 June 1994.
Although most access control mechanisms are in the operating system or special security package, security must be included in all levels of software. Software should be checked to make sure it does not circumvent system security controls. The level of security controls depends on the sensitivity and criticality of the system. Additional controls can be implemented by application software to provide more detailed control than that built into the operating system.
Plan integral telecommunications systems, considering all elements of COMSEC and baseline during the conceptual phase and throughout the system life cycle.
System planners and engineers designing automated systems should consult with CMC (CSBT) during the early phases of their planning. Early coordination will aid in establishment of proper COMSEC requirements and ensure early inspection and technical guidance throughout the systems installation and testing. Refer to CMS-1 "Communications Security Material System (CMS) Policy and Procedures Manual".
System developers that are responsible for acquiring, developing, or integrating information systems shall ensure that these systems are accreditable. System developers shall ensure that the requirements outlined in this Instruction, and the specific requirements established by the Functional Application OPRs, are incorporated into the systems during the development process. System developers will designate responsible individuals to oversee the security aspects of the acquisition, development, and integration of the information system IAW the DOD Technical Architecture Framework for Information Management (TAFIM), Volume 6, DOD Goal Security Architecture.
Quality control is a serious security concern since faulty software can produce undetected, inaccurate output that can affect the mission, or it can fail, causing denial of service. In most manual operations there are numerous quality control activities where unusual results are questioned and checks are used to detect errors. This capability must be included in the software to make the automated method as secure and reliable as the manual method. Below are some techniques to include in applications software to improve reliability:a. Edit input to agree with all assumptions made in the software and specifications.b. Perform range and reasonability checks throughout the software to ensure proper operation.c. Perform range and reasonability checks of the output to make sure it agrees with specifications.d. Provide additional checks before a critical code that can negatively affect the system, such as division by zero or memory accesses outside of the program area.e. Ensure edits default to error conditions rather than success.
Use only Government acquired software that comes in factory sealed containers from reputable dealers or Marine Corps authorized software provided through proper distribution or requisitioning channels....the use of public domain freeware or shareware software is not authorized unless it comes from an official U.S. Government sanctioned bulletin board and has been tested for the presence of a virus before it is used. Privately owned commercial software and game software is not authorized. Only U.S. Government software developed and approved or commercial software procured through the supply system are authorized.
Requirements stated below should be used whether software is developed by the Marine Corps or by a contractor. Purchased commercial off-the-shelf software should be selected using these criteria. Requirements that cannot be satisfied due to cost or non-availability should be carefully evaluated and documented in the risk assessment process...Unless justifiably approved by the DAA, no application software may circumvent the security provided by the operating system or special security software...The DBMS must not circumvent the controls present on the system.
Data bases with a DBMS should be given additional protection because of increased ease of obtaining correlated data. A DBMS combines information and provides tools for correlating the information to obtain additional information through aggregation. Because new information may be of a higher sensitivity than the original, it may be necessary to protect the entire data base at a higher level than individual data elements of the data base. During the threat and vulnerability analysis of the risk assessment, systems with a DBMS could have a slightly higher threat identified.
Marine Corps developed software containing security controls, including new releases for use on sensitive or critical systems, must be certified by the responsible manager of the developing activity. Contractor developed software containing security controls for use on mission critical systems must be initially certified by the senior manager of the organization responsible for the acquisition.
Software development and related activities (for example, systems analysis) will incorporate appropriate security measures.
Commanders and managers are responsible for implementing the AISSP in their command or activity and will ensure the following is accomplished:...Requests for new systems or changes to existing systems include security requirements appropriate to the system's concept of operation. Once validated, these security requirements must be incorporated into the system design and defined in procurement contracts.
Organizations must strive to ensure that new AIS development and modifications to existing AIS are performed in a manner that makes security an integral part of the development, acquisition, fielding, and operational processes.
Software security requirements must be considered in the future design, development, and acquisition of Army systems.
Designers and developers of data base management systems, in coordination with security specialists and proponents for the data elements, must consider the effect that compilation of data will have on the final security classification of the data-base system. The degree to which a given user can be reliably denied access to portions of the database will influence the final classification decision.
Software security packages are available from various commercial vendors. Products other than those evaluated by the NSA and included in the NSA Information System Security Products and Services Catalogue may be used; however, such products must be approved by the DAA and based on a valid justification...The decision to use software security packages will be based upon cost and the level of security protection required. The DISC4 must approve purchase or annual lease costs of products not listed in the NSA Information System Security and Services Catalogue that exceed $50,000.
3.2.6 SYSTEM ACCEPTANCE
The PEOs/PMs or functional proponents will not field and commanders will not accept, the following systems:
(1) Systems that do not meet minimum standards stated in the acquisition and procurement specifications.
(2) Systems that do not provide complete documentation supporting certification and accreditation.
(3) Systems that have not been fully certified or generically accredited.
3.2.7 SYSTEM OPERATION
No classified or sensitive unclassified data shall be introduced into an AIS without designation of the classification and sensitivity of the data. Approval to enter the data shall be obtained from the data owner where applicable.
Information Systems Using Periods Processinga An IS is said to operate in a periods processing environment if it is appropriately sanitized between operations in differing Protection Level periods, or with differing user communities or data.b As long as the sanitization procedures between each Protection Level segment have been approved by the DAA based on guidelines from the Data Owner(s) or responsible official(s), the IS need meet only the security requirements of each processing period, while in that period. If the sanitization procedures for use between periods are approved by the DAA(s), the security requirements for a given period are considered in isolation, without consideration of other processing periods. Such sanitization procedures shall be detailed in the SSP.c Under periods processing, the highest sensitivity level and the most restrictive data processed on the system will determine the DAA. The DAA shall coordinate authorizations for using the system at lower or less restrictive levels.
Classified or SBU data will not be introduced into an AIS until the data classification and sensitivity of the AIS has been determined. The appropriate AIS protection mechanisms will be in place and DAA approval to operate will be obtained. The data owner will approve entering the data, where applicable. Data will not exceed the security classification level for which the AIS is approved to process.
System Administrators are responsible for the daily monitoring and maintenance of system access and resources. The number of required System Administrators can best be determined by identifying the length of time it would take to perform the duties and who has the most technical knowledge in operating systems and security software. System Administrators are unique in the fact that they can normally access all data stored or processed on the information system and are, therefore, likely candidates to act as the system ISSO. In those instances where the System Administrator does not function as the ISSO, the System Administrator will perform the following information system security functions:
(1) Assist the ISSO to ensure that the information system is being operated and used in a secure manner.
(2) Assist the ISSO in developing an information system security incident reporting program.
(3) Assist the ISSO in maintaining configuration control of the systems and applications.
(4) Advise the ISSO of security anomalies or vulnerabilities associated with the information system and provide a potential means for fixing the identified vulnerabilities. Participate in the information system security incident reporting program.
(5) Administer, when applicable, user identification or authentication mechanisms of the information system or network.
Clear equipment and media when changing modes of operation or changing operations to the same or higher classification level. Sanitize storage devices that contain classified information before using at a lower classification level according to AFSSI 5020.
Each component of the system will be powered on and off at least three times before processing a different level of classification, such as changing from system high of Secret to system high of Confidential.
Use a separate copy of the operating system and other necessary software for each level of classification on information systems employing periods processing.
Before operation, each AIS will be certified and accredited under a set of security requirements and safeguards approved by the DAA.
All software used on Army AIS must be approved by the ISSM or ISSO prior to installation and operation.
Commanders will ensure that AIS under their purview are operated in a manner consistent with the system accreditation and this regulation.
3.2.7.1 SYSTEM MAINTENANCE
A system operating at the Medium [or] High Level-of-Concern for Availability shall implement the following features: Maintenance procedures that include preventive maintenance, scheduled to maximize the availability of the system, and thus to minimize interference with the operation of the system. Planning for maintenance shall include at least:(a) On-call maintenance.(b) On-site diagnostics.(c) Control of Remote Diagnostics, where applicable. (See para. 8B.8.d, below, for a discussion of remote diagnostics.)
A maintenance log shall be maintained. The maintenance log shall include the date and time of maintenance, name of the individual performing the maintenance, name of escort, and a description of the type of maintenance performed, to include identification of replacement parts.
Maintenance of systems shall be performed on-site whenever possible. Equipment repaired off-site and intended for reintroduction into a facility may require protection from association with that particular facility or program.
If systems or system components are to be removed from the facility for repair, they shall first be purged, and downgraded to an appropriate level, or sanitized of all classified data and declassified in accordance with DAA-approved procedures. The ISSO or designee shall approve the release of all systems and all parts removed from the system (see section on Release of Memory Components and Boards).
Introduction of network analyzers (e.g., sniffers) that would allow the maintenance personnel the capability to do promiscuous mode (real time) monitoring shall be approved by the ISSM or designee prior to being introduced into an IS.
If maintenance personnel bring diagnostic test programs (e.g., software/firmware used for maintenance or diagnostics) into a facility, the media containing the programs (1) shall be checked for malicious code before the media is connected to the system, (2) shall remain within the facility, and (3) shall be stored and controlled at the level of the IS. Prior to entering the facility, the maintenance personnel shall be advised that they will not be allowed to remove media from the facility. If deviation from this procedure is required under special circumstances, then each time the diagnostic test media is introduced into a facility, the media shall undergo stringent integrity checks (e.g., virus scanning, checksum) prior to being used on the IS and, before leaving the facility, the media shall be checked to assure that no classified information has been written on it. Such a deviation requires approval by the ISSM.
All diagnostic equipment and other devices carried into a facility by maintenance personnel shall be handled as follows:(a) Systems and system components being brought into the facility shall be inspected for obvious improper modification.(b) Maintenance equipment that has the capability of retaining information shall be appropriately sanitized by procedures outlined in paragraph 8.B.5 before being released. If the equipment cannot be sanitized, the equipment shall remain within the facility, be destroyed, or be released under procedures approved by the DAA and the Data Owner(s) or responsible official(s).(c) Replacement components that are brought into the facility for the purpose of swapping with facility components are allowed. However, any component placed into an IS shall remain in the facility until proper release procedures are completed. Any component that is not placed in an IS may be released from the facility.
(d) Communication devices with transmit capability (e.g., pagers, [RF] LAN connections) belonging to the maintenance personnel or any data storage media not required for the maintenance visit shall remain outside the system facility for return to the maintenance personnel upon departure from the facility.
Maintenance changes that impact the security of the system shall receive a configuration management review.
After maintenance has been performed, the security features on the IS shall be checked to assure that the IS is still functioning properly.
3.2.8 CONFIGURATION MANAGEMENT
All AIS hardware, software and documentation, and all classified and sensitive unclassified data handled by the AIS shall be protected to prevent unauthorized (intentional or unintentional) disclosure, destruction or modification (I.e. data integrity shall be maintained)...This includes having...configuration controls.
While proper configuration management is important for all software, it is even more important when proper operation of the software is critical to the mission. Control of changes to software prevents faulty software or covert code from entering the system. Covert code may be in one of several forms called computer virus, trap door, Trojan horse, or a software time bomb. Following are suggestions to enhance configuration management:a. An office other than the development office should control changes, from the initial change request to implementation.b. Changes should not be implemented by the office coding the changes.c. Changes should be examined at several levels within the development organization to make sure only authorized code is included. These examinations should be documented.d. After verification at all levels, changes should be applied to a protected source. Testing before verification should be performed on a copy of the software.e. After changes are applied, new software should be compared to the working copy used for testing to make sure only authorized changes were made and test results are valid.f. A new, protected source copy should be made and stored away from the system. The original is then the new working copy for operation or further developments and changes.
Configuration Management. The ISSM or designee must evaluate the impact to security for all changes (hardware, software, and firmware) to the system.
Use configuration management to ensure the integrity of critical functions in security-related hardware, firmware, and software of all information systems. Distributing hardware, firmware, and software under configuration management control shall be provided an appropriate level of protection to assure product integrity. Use the computer resources life-cycle management plan and the CCB to ensure system integrity throughout the life cycle of an information system.
A system operating at the Basic Level-of-Concern for integrity shall implement the following features: Configuration Management (CM) that includes:(a) Policies that assure the effectiveness of storage integrity.(b) Procedures to assure the appropriate physical and technical protection of the backup and restoration hardware, firmware, and software, such as router tables, compilers, and other security-related system software.
Upon acceptance for operational use, whether developmental, government off-the-shelf (GOTS) or commercial off-the-shelf (COTS), software must be kept under close and continuous configuration management controls so that unauthorized changes are not made. A master copy of the software must be safeguarded and never used for actual production operations. Production copies of software should be generated from the master copy as required. System and application program libraries will be protected and backup copies maintained. Strict configuration management controls will be enforced to lessen the risk of introducing untested or malicious software.
Ensure interoperability and compatibility with existing Air Force standard network security policies and procedures according to the Joint Technical Architecture-Air Force.
Maintain.. an accurate and up-to-date inventory of all hardware and software by serial number and location.
The statement of accreditation describes the definitive baseline of security operations with an acceptable level of risk. A statement of accreditation does not obviate the responsibility of the site for managing the accredited baseline. Therefore, the organization ISSM or ISSO will maintain the accredited baseline using and approved configuration management process and will perform an annual assessment of the baseline. The responsible ISSM or ISSO will maintain overall responsibility for retaining and maintaining records on the accreditation decisions for systems and networks under their purview. The responsible ISSM or ISSO will periodically evaluate the accredited status and will make a determination if re-accreditation is needed (as described in paragraph 3 of this chapter). If re-accreditation is not needed, the ISSM or ISSO will document the scope and date of the review performed and will maintain a file of the reviews conducted. As a secondary measure, CISS, operating under the DAA's authority, will periodically measure the effectiveness of the accredited baseline via the use of compliance validation
...Documentation must be protected or controlled commensurate with the classification or usefulness of the information it contains and placed under configuration management control.
Software developed or purchased to handle Sensitive Unclassified data (refer to Appendix E), must have configuration management controls to protect against unauthorized alteration.
During development and maintenance of the TCB, a configuration management system shall be in place that maintains control of changes to the descriptive top-level specification, other design data, implementation documentation, source code, the running version of the object code, and test fixtures and documentation. The configuration management system shall assure a consistent mapping among all documentation and code associated with the current version of the TCB. Tools shall be provided for generation of a new version of the TCB from source code. Also available shall be tools for comparing a newly generated version with the previous TCB version in order to ascertain that only the intended changes have been made in the code that will actually be used as the new version of the TCB.
A system operating at the Medium [or] High Level-of-Concern for integrity shall implement the following features:...(a) A CM Plan, including: (1) Policies that assure storage integrity. (2) Procedures for identifying and documenting system connectivity, including any software, hardware, and firmware used for all communications (including, but not limited to wireless, IR, etc.). (3) Procedures for identifying and documenting the type, model, and brand of system or component, security relevant software, hardware, and firmware product names and version or release numbers, and physical locations.(b) A CM process to implement the CM Plan.
Proposed changes to the AIS configuration (to include changes to the software, facility, environmental support, or equipment interfaces) will be reported to the ISSO for a determination about the security implications of the change. If required by AR 381
A system operating at the Medium [or] High Level-of-Concern for integrity shall implement the following features:...Change Control that includes:(a) Mechanisms that notify users of the time and date of the last change in data content.(b) Procedures and technical system features to assure that changes to the data or to security-related items are: (1) Executed only by authorized personnel. (2) Properly implemented.
A system operating at the High Level-of-Concern for integrity shall implement the following features:....Configuration management that includes:(a) A CM process to test, and verify the CM Plan periodically.(b) A CM control board, which includes the ISSM/ISSO as a member.(c) A verification process that assures it is neither technically nor procedurally feasible to make changes to the Security Support Structure outside of the CM process.
Operational software may be modified and maintained only under rigorously controlled conditions requiring verification.
A system operating at the High Level-of-Concern for integrity shall implement the following features:.... Change Control that includes:(a) A secure, unchangeable audit trail that will facilitate the correction of improper data changes.(b) Transaction-based systems (e.g., database management systems, transaction processing systems) that implement transaction roll-back and transaction journaling, or technical equivalents.
A data-base administrator (DBA) will be appointed for each data base and appropriate duties assigned by the ISSM.
3.3 CERTIFICATION AND ACCREDITATION
3.3.1 ACCREDITATION
Ensure that a management official authorizes in writing the use of each general support system based on implementation of its security plan before beginning or significantly changing processing in the system.
The wing commander is the DAA for the base-wide area or metropolitan area network and for all networks owned and/or operated by the wing.3.2.1.1. The wing commander may delegate DAA authority to each operational or support commander for his or her systems and networks. Further delegation is prohibited.3.2.1.2. The wing commander may delegate DAA authority to the ranking officer at each geographically separated organization for his or her systems and networks. Further delegation is prohibited.
The DAA must be aware of the essential operational and security requirements along with the specific threat(s) before deciding accreditation is merited. The DAA must balance the risk of disclosure, loss, or modification of information; asset availability based on the vulnerabilities identified by the certification or technical evaluation process; the threat of exploitation of these vulnerabilities; and the operational mission requirement in order to make a decision to issue either a Statement of Accreditation, an Interim Authority to Operate (IATO), or to terminate operations.
MAJCOM, FOA, DRU, and tenant unit commanders are DAAs for the systems and networks they own and/or operate.3.2.2.1. MAJCOM, FOA, DRU, and tenant unit commanders may, if appropriate, delegate the authority to the wing commander, to a single headquarters director (i.e., 2-letter office symbol), or each operational support commander for his or her systems and networks. Further delegation is prohibited.3.2.2.2. MAJCOM, FOA, DRU, and tenant unit commanders may delegate DAA authority to the ranking officer at each geographically separated entity (i.e., detachment, organization, center, unit, etc.). Further delegation is prohibited.
The heads of U.S. Government departments and agencies shall: a. Ensure that C&A programs consistent with the policy and principles set forth in this NSTISSP are established and implemented, and b. ensure that a DAA is identified for each system under their operational control, and that DAAs have the ability to influence the application of resources to achieve an acceptable level of security.
C&A programs established to satisfy this policy shall be based on the following principles:a. Certification of national security systems shall be performed and documented by competent personnel in accordance with specified criteria, standards, and guidelines.b. Accreditation of national security systems shall be performed by competent management personnel in a position to balance operational mission requirements and the residual risk of system operation. All accreditation decisions shall contain a statement of residual risk.
The Commandant of the Marine Corps (CMC) shall:...Ensure that DAAs are identified and security services provided for Marine Corps information systems.
The Chief of Naval Operations (CNO ) shall:...Serve as the DAA for Navy-wide and joint service information systems (where Navy is the assigned lead) and ensure that DAAs are identified for other Navy information systems.
All federal government departments and agencies shall establish and implement programs that mandate the certification and accreditation (C&A) of national security systems under their operational control. These C&A programs shall ensure that information processed, stored, or transmitted by national security systems is adequately protected with respect requirements for confidentiality, integrity, and availability.
An accreditation decision is based on the degree of existing residual risk resulting from the technical or non-technical evaluation. If the Certification Authority attests to the adequacy of the security safeguards, then the DAA must determine whether the existing residual risk is acceptable, given the organization's mission and operational environment.
Each AIS shall be accredited to operate in accordance with a DAA-approved set of security safeguards.
Agencies that direct the acquisition, development, fielding, and/or sustainment of a specific system ensure a DAA is appointed. DAA appointments (i.e., due to lead command responsibilities, joint or Air Force standard system, etc.) must be consistent with the above policy. For example, if Air Combat Command (ACC) is the lead command for a logistics standard system, the appropriate DAA would be HQ ACC/LG, or its lead agency.
A statement of accreditation is a formal declaration by the DAA that an information system has been approved to operate in a particular security mode using a prescribed set of safeguards. The decision to accredit is based on the residual risks identified during the certification process.
Accreditation of DON information systems shall be performed by competent management personnel in a position to balance operational mission requirements and the residual risk of system operation.
All DISA information systems will be accredited to operate IAW a set of security safeguards formally approved by the DAA.
Accreditation is a formal statement by a DAA stating that all known vulnerabilities and risks associated with a computer- based system have been considered, and all cost-effective countermeasures have been implemented, tested and found to be effective...The DAA authority (organization exercising operational control in conjunction with the functional owners of the data) to accredit computer facilities is listed in reference C. The DAA for all other computer-based systems (e.g., AISs, mini-computers, micro-computers, word processors, office automation systems, local area networks) processing Classified or Sensitive Unclassified data is determined by the followingdata sensitivity levels: [See IRM-5239-08A, 2.3.12]
Accreditation of DON information systems shall be performed when information systems are interconnected to other previously accredited information systems and networks. The DAA shall ensure that operation of the resultant system does not incur any additional unacceptable risk.
Interim Authority to Operate. The DAA may grant an IATO that indicates conditional approval to operate. An IATO may be issued in those situations where, due to unforeseen circumstances, the requirements for full accreditation cannot be met in a timely manner. When an IATO has been issued, the responsible organization will develop a milestone plan with dates to correct the deficiencies noted in the certification report. It is the responsibility of each organization to ensure that their information processing assets attain formal accreditation or cease operation by the expiration date of the IATO.
All computer-based systems are to be accredited to the maximum specified level of sensitivity (Sensitive Unclassified, Confidential, Secret, Top Secret, National Cryptologic, SCI/Intelligence, SIOP-ESI) of the information that will be processed.
A DAA may grant an interim approval to operate for a 90
The DAA will consider extending the period of the IATO beyond the initial period; however, no more that two IATOs will be issued.
For an IATO, the requesting organization will have 180 days from the date that the DAA issued the IATO to correct the deficiencies. No more than one extension to the first IATO will be granted without sufficient justification.
All accreditation decisions shall be documented and contain a statement of residual risk.
The AIS which provide remote access to a larger, clearly defined system do not require individual accreditation, but they must follow the security requirements of the larger system accreditation. When such AIS will be used to process data unrelated to the larger system, they must be accredited before processing the unrelated data.
System accreditation will not become effective until a formal, dated, Statement of Accreditation has been issued by the DAA as a result of a system accreditation review.
Information systems that process classified information will be certified and accredited prior to commencement of operations.
Accreditation is the DAA's formal declaration that an AIS or network is approved to operate as follows:(1) In a particular security mode of operation and security classification level.(2) With a prescribed set of minimum environmental, technical, and non-technical security countermeasures.(3) Against a threat assessed by the supporting intelligence staff office.(4) In a properly secured area in a clearly defined operational environment.(5) Under stated short- and long-term goals.(6) With stated interconnections to other AIS or networks.(7) At an acceptable level of risk for which the accrediting authority has formally assumed responsibility.
Accreditation is the official management authorization to operate an AIS or network and is based, in part, on the formal certification of the degree to which a system meets a prescribed set of security requirements. The accreditation statement affixes security responsibility with the accrediting authority.
All AIS will be accredited to operate in one of the following security processing modes:(1) Dedicated security mode. A mode of operation wherein all users who access the system directly or indirectly possess the required personnel security clearance or authorization, formal access, approval, and need-to-know for all information the system is accredited to process(2) Systems high security mode. A mode of operation wherein all users who access the system directly or indirectly possess the required personnel security clearance or authorization and formal access approval but not necessarily a need-to-know for all information the system is accredited to process.(3) Compartmented security mode. A mode of operation wherein all users who access the system directly or indirectly possess the required personnel security clearance or authorization but not necessarily formal access approval or a need-to-know for all information the system is accredited to process.
(4) Multilevel security mode. A mode of operation wherein not all users who access the system directly or indirectly possess the required personnel security clearance or authorization, formal access approval, or a need-to-know for all information the system is accredited to process.
Accreditation addresses the system's perimeter, its boundary, and its relationship to other AIS and networks in a particular infrastructure. The perimeter surrounds the specified set of equipment and peripherals under the control of the DAA. The boundary encompasses what may be a much larger environment that includes, for example, remote users, dial-in users or global network users, access to other AIS that are not controlled by a single DAA. The boundary may encompass numerous systems, users, organizations, and networks that support a similar mission objective. The collection of all potential users of the AIS (that is, users within the system boundary) is used to determine the security mode of operation. Only AIS equipment and peripherals within the perimeter of the AIS must be specifically identified in the accreditation document. However, security requirements for AIS equipment or peripherals accessing the system from outside the AIS perimeter, not controlled by the DAA, will also be addressed in the accreditation.
Accreditation must address each operational environment of the AIS for both fixed and deployable configurations. For example, an AIS may operate at one sensitivity level or mode of operation in a standalone mode and connect to a global network with another mode or sensitivity level. The accreditation must clearly establish procedures for transition between the two environments. Multiple operational environments can result in multiple accreditation for a single AIS if different DAAs are involved. However, in the concept of the operations document, a single accreditation that addresses all variations is sufficient.
The time and manpower expended in the accreditation process must be proportional to the system size, criticality, mode of operation, data sensitivity, and number of users. The process may be significantly streamlined if the accreditation addresses small computers or other AIS operating in the dedicated mode.
The appropriate Designated Approving Authority (DAA) shall accredit every DON information system before operation.
The DAA grants formal accreditation to operate a system processing intelligence information. The DAA has the authority to withdraw accreditation, suspend operations, grant interim approval to operate, or grant variances when circumstances warrant. The approval shall be a written, dated statement of accreditation that clearly sets forth any conditions or restrictions to system operation. DAAs are responsible and accountable for the security of the information and systems that they accredit.
Before operation, each AIS will be certified and accredited under a set of security requirements and safeguards approved by the DAA.
Prior to operating, certify and accredit all information systems according to AFSSI 5024VI and AFSSI 5024VII.
A statement of accreditation is a formal declaration by the DAA that an information system has been approved to operate in a particular security mode using a prescribed set of safeguards. The decision to accredit is based on the residual risks identified during the certification process.
The statement of system accreditation will include the specified level of sensitivity or classification for which the accreditation is based, a statement by the DAA as to the acceptability of identified risks (where applicable), and any exceptional circumstances incumbent to system accreditation. This brief statement should be adequate for purposes of subsequent system accreditation reviews and re-accreditation (every three years). Chapter 2 defines the approval authority depending on the sensitivity level of the data processing on the system.
The Accreditation of an AIS shall be supported by a certification plan, a risk analysis of the AIS in its operational environment, an evaluation of the security safeguards, and a certification report, all approved by the DAA. Accreditation of computers embedded in a system may be at the system level.
The accreditation statement shall identify the required confidentiality, integrity, and availability services and constraints under which the system can operate including data sensitivity, user authorization, physical and system configuration.
The accreditation process involves the collection and comprehensive analysis of security relevant information pertaining to an information system or network and a certification of the adequacy of safeguards against potential threats. Specific security requirements should be identified and an associated security concept of operations should be developed as early as possible within the system life cycle to ensure that appropriate safeguards are incorporated and that any associated risk can be managed at an acceptable level.
Report information system accreditation according to AFI 33-205.
The accreditation process that leads to either generic or operational accreditation involves the following steps:(1) Develop a security plan. Refine the plan throughout the accreditation process.(2) Determine accreditation goals and objectives. Include a review and validation of the need for the subject operations.(3) Define the proposed AIS operations. Define the key security features forming the basis of the accreditation and identify the security mode of operation.(4 ) Conduct a risk management review to identify risks and countermeasures (chap 5).(5) Select the security countermeasures required by the risk management review.(6) Employ a Certification Plan to establish that the AIS performs the security functions that support the mode of operation and security policy for the system.(7) Develop a security guide to provide security instructions for AIS users, operators, and the ISSO.(8) Modify the security plan as appropriate, add relative attachments, and forward the plan to the DAA for approval (see fig 3
Examination of the control over the procedures used to develop computer programs is an integral part of the software certification and AIS accreditation process. The key to eventual certification is to develop systems that are easily understood and verifiable.
This Instruction:1.1. Implements policy, assigns responsibilities, and prescribes procedures under reference (a) for Certification and Accreditation (C&A) of information technology (IT), including automated information systems, networks, and sites in the Department of Defense.1.2. Creates the DoD IT Security Certification and Accreditation Process (DITSCAP) for security C&A of unclassified and classified IT to implement references (a) through (d)....5.4. The Heads of the DoD Components shall:5.4.1. Implement the DITSCAP for security C&A of DoD Component and DoD contractor IT systems and networks in accordance with DoD Directive 5200.28, Pub. L. 100-235 (1987), OMB Circular A-130, DCID 1/16, DoD Directive 5220.22, DoD 5220.22-M, DoD 5220.22-M-Sup. and Chairman of the Joint Chiefs of Staff S3231.01 (references (a) through (h)) as applicable...5.4.3. Assign responsibility to implement the standard C&A process to DAA responsible for accrediting each IT and network under their jurisdiction.
For those information systems supporting cryptologic functions, Sensitive Compartmented Information (SCI)/Intelligence data, or Single Integrated Operations Plan (SIOP) data, accreditation requests shall be forwarded to the appropriate authority.
Before any computer-based system that is identified to process classified information can be accredited, a [TEMPEST Countermeasures Review] (TCR) must be conducted (except those systems located on military bases within the U.S. that process data classified no higher than secret) in accordance with OPNAVNOTE c5510 ser 09N/4C535007 dated 14 Apr 94. There are some exception to the rule dealing with processing classified data on military bases within the U.S., please refer to the above OPNAVNOTE for instructions before trying to accredit a system. DAA's should not accredit systems designated or acquired to process classified information unless a Certified Tempest Technical Authority (CTTA) has conducted or validated a TCR. Refer to Chapter 9 and Appendix G for details.
While the responsible requesting organization will develop a significant portion of the supporting security documentation, the DISA Certification Authority will determine the breath and depth of certification activity to take place.
The evaluation of software security packages must be included in the risk assessment so that the accreditation authority can document advantages and disadvantages.
Step 1: Requesting Accreditation. All requests for accreditation or to initiate the accreditation process will be sent to the DAA. The requesting organization will prepare and enclose an initial Computer Security Plan (see figure 3-1), appointment letters of officials assigned to information system security duties, Certification Checklist, and list of dates regarding the planned implementation (i.e., initial operating capability, final operating capability for information system, or application development). The requesting organization will forward a copy of the request to the Certification Authority.
Step 2: Initial DAA Action. The DAA will determine the accreditation approach to be used and forward to the Certification Authority. The Certification Authority will prepare an initial certification plan, conduct the necessary system/site security assessments, and identify personnel to perform on-site testing if deemed necessary. The Certification Authority will also assess the relevance and utility of existing security documentation.
The certification plan will also describe any requirements for additional documentation other than those described in Step 3 and will tentatively assign a timeframe for conducting the certification. The certification plan will be forwarded to the DAA for approval. Once approved, the certification plan will be sent to the requesting organization to be used as a guideline in their effort to receive an accreditation.
For new developments, or in operational environments where security documentation does not exist or is not adequate to support the certification effort, the organization will prepare an SSAA in lieu of a separate Computer Security Plan, Concept of Operations, Certification Test Plan, Security Test and Evaluation Test Plan and Procedures, Contingency Plan, and the description of the environment's hardware and software.
Step 3: Preparing for Certification. The organization will begin preparing for certification. The requesting organization, with guidance from the CISS, will:
(1) Implement a process to manage risk. (Past efforts, to precisely measure risk, have resulted in the expenditure of considerable resources [i.e., time, money, people] to perform formal risk analyses, of which the outcome has not be resulted in improved security. Therefore, Appendix III of authority document OMB Circular A-130, advises that efforts are best directed towards generally assessing risks and taking prudent measures to manage them. FIPS Special Publication 800-12, An Introduction to Computer Security: The NIST Handbook, provides guidance regarding risk management [specifically risk assessment and risk mitigation]. Organizations will either select the process described in the FIPS Special Publication to identify risk or use the DISA developed Expert Systems for Progressive Risk Identification techniques [ESPRIT]. Regardless of the effort, the end result will be in a concept document which discuses how risks will be managed in the operational environment and identifies the procedures to be used.)
(2) Prepare a Statement of Compliance with the Security Requirements in chapter 2. (The requesting organization must state that it has complied with the minimum security requirements described in chapter 2.)
(3) Prepare a Security Plan (see figure 3-1). Footnote 2: Minimum required documents for the approval of workstations (i.e., personal computers, laptops, and notebooks) processing classified or sensitive, but unclassified information in a standalone (without connectivity) mode.
(4) Prepare a Concept of Operations that discusses system security features and provides diagrams of network connectivity.
(5) Prepare a System User's Guide (with a chapter dedicated to a discussion of the security features designed and developed into the system for the user's awareness).
(6) Prepare a Configuration Management Plan. (This is a minimum requirement for site certification.)
(7)Submit appointment letters of the responsible Information System Security Officials.
(8) Execute any Memorandums of Agreement or Understanding or obtain appropriate connection approvals, as required in DoDD 5200.28.
(9) Prepare a Certification Test Plan. (The plan will address the conduct of both the technical and non-technical features to be tested.)
(10) Prepare a Security Test and Evaluation Plan and Test Procedures.
(11) Prepare a Contingency Plan.
(12) Prepare local SOPs.
(13) Complete the Certification Checklist.
(14) Prepare a written Physical Description of the Hardware and Software.
(15) Prepare the organization's statement that the information processing asset is ready for certification.
Step 4: Certification. The Certification Authority, along with assistance from the requesting organization, will conduct certification testing. The Certification Authority will determine the depth and breath of certification and the type of evaluation that will take place. Certification involves an assessment of the list of documentation described in Step 2, along with the requirements described in chapter 2. The Certification Authority will prepare, at the conclusion of the certification effort, a certification report. The certification report will be sent to the requesting organization for comment and a recommendation in support of an accreditation decision to the DAA.
Step 5: Resolution of Certification Test Findings. The Certification Authority will forward the list of categorized findings and a recommendation to the requesting organization for resolution. If the Certification Authority has recommended that a statement of accreditation or termination be issued, the certification report will go directly to the DAA with a copy to the requesting organization. If the Certification Authority has recommended an IATO, the requesting organization will have 30 working days to respond to the findings. The organization will prepare a response that describes its plan to correct the findings, provides milestone dates for correction, and cites the allocated resources (i.e., personnel and money) to be used to correct the deficiencies. If the Certification Authority has recommended termination, the organization will take immediate action to cease operations after receipt of the letter from the DAA.
Step 6: Accreditation Decision. The DAA will review the recommendation presented and make an accreditation decision. An accreditation is effective for 3 years from the date signed. For an IATO, the requesting organization will have 180 days from the date that the DAA issued the IATO to correct the deficiencies. No more than one extension to the first IATO will be granted without sufficient justification. The DAA will make an accreditation decision based on the recommendation of the Certification Authority and the results documented in the certification report. Any conditions required to maintain acceptable levels of risk will be established through the formal accreditation decision correspondence from the DAA to the requesting organization.
The following high level steps outline the process and requirements and identify the responsible entity.The high level process consists of several iterative, interdependent steps. The scope and specific activities of each step depend upon the system being certified and accredited.
Accreditation documentation describes the system in detail. The documentation must be protected to the degree that its compromise would jeopardize the security of the information contained in the system, since it reveals system vulnerabilities. The documentation will be handled as stated in AR 25
Documentation will be forwarded to the accreditation authority in sufficient time to be acted upon before operation of the system or the expiration of any existing accreditation.
If an information system's operational security risk exceeds an acceptable level, considering its operational mission and criticality, the DAA, in coordination with the operational manager, will issue a directive to terminate operations. The directive will recommend ways to improve the system's security to a minimally acceptable level for operation to resume under an IATO.
The AIS that include a PDS to transmit data will not be accredited to operate until the PDS has been approved. The PDS approval will be cited in the COMSEC portion of the accreditation packet and a copy of the approval will be attached.
The operational manager or functional proponent may appeal a directive to terminate operations on the basis of operational necessity and the Director or Vice Director will decide on the issue within 72 hours.
Information systems that fail to meet the minimum requirements and have not received an exemption will be denied accreditation. The cognizant Functional Application OPR or the General Support System OPR will terminate all system operations upon receipt of the Statement of Termination issued by the Director or Vice Director.
There are two general categories of acceptable AIS accreditation within the Army: generic accreditation of centrally fielded AIS and operational accreditation of AIS that are procured or obtained locally. Centrally fielded systems will be accredited under the generic approach unless DISC4 approves an exception for unusual circumstances. In the latter case, developer preparation of a users There are two general categories of acceptable AIS accreditation within the Army: generic accreditation of centrally fielded AIS and operational accreditation of AIS that are procured or obtained locally. Centrally fielded systems will be accredited under the generic approach unless DISC4 approves an exception for unusual circumstances. In the latter case, developer preparation of a users security guide, security certification, and all other portions of paragraph 3-2 (except the actual accreditation statement) are still applicable.
Accreditation of Similar Systems 9.D.3.a(1) At the DAA's discretion, the DAA can determine that systems in a group are, for accreditation purposes, essentially the same. Systems can be considered as "essentially the same" if (1) the Protection Levels and the Levels-of-Concern are the same; (2) the users have at least the required clearances and access approvals for all information on the systems; (3) the systems are processing the same level(s) and specific set(s) of information; (4) the system configurations are essentially the same; and (5) the environments of the systems are essentially the same. If the DAA chooses to accredit this set of systems as a unit, then an SSP may be written and approved by the DAA, to cover all of the similar systems. This type of approval applies only to systems operating at Protection Levels 1 and 2 (Chapter 3), and under the purview of a single DAA.
Under the generic approach, systems fielded to multiple users are accredited as a single entity prior to fielding. While generic accreditations will lessen the administrative burden for the field users, local ISS officials must still ensure that AIS under their purview are operating under the terms of the generic accreditation. Under the generic approach, systems fielded to multiple users are accredited as a single entity prior to fielding. While generic accreditations will lessen the administrative burden for the field users, local ISS officials must still ensure that AIS under their purview are operating under the terms of the generic accreditation. Under the generic approach, systems fielded to multiple users are accredited as a single entity prior to fielding. While generic accreditations will lessen the administrative burden for the field users, local ISS officials must still ensure that AIS under their purview are operating under the terms of the generic accreditation.
The generic accreditation will be applied to AIS fielded under the PEO/PM structure. Additionally, generic accreditation are appropriate whenever a single office or agency is responsible for fielding an AIS to multiple Army users. The ISSO will integrate new AIS into the established architecture and ensure that the new AIS do not adversely affect previously certified and accredited AIS.
A Master System Security Plan (MSSP) may also be used to refer to and identify common security information for "similar systems" at a given site or facility as specified above. In this case, the MSSP shall include the identity of all systems covered. Such a listing can be as simple as a reference to a particular database containing the identifying information and locations of applicable systems.
The SSP for these [similar] systems shall specify the information required for certification of each system to be accredited under this procedure. The DAA shall accredit the first system under the SSP. All of the other individual systems to be operated under such an SSP shall be tested by the ISSO and certified by the ISSM as meeting the conditions of the approved SSP. This certification, in effect, accredits the individual system to operate under the SSP. The ISSM shall retain a copy of each certification report with the approved copy of the SSP and make a copy available to the DAA.
In determining whether two sets of systems are "similar" for the purposes of this section, consideration must be given to any required changes to the SSP. Adding similar systems requires changes only in identification, such as location, internal system configuration, and so forth. Any other required changes, such as administrative control outside the purview of a single DAA, indicate that the systems are not "similar" within the meaning of this section.
The generic accreditation will address the projected local operating and risk environment for the system. The using activities should not normally be required to take significant additional steps to accredit the system. If additional security measures are necessary for a particular operating environment, they will be added as a supplement to the generic accreditation by the using command.
The following must be accomplished in support of a generic accreditation:(1) Clearly define the environment in which the system is to operate at the beginning of concept development. This facilitates an orderly analysis of the threats to which the system will be exposed and the subsequent determination of the appropriate security requirements for the system. Environmental factors that influence the security requirements include the users and their level of clearance; source, frequency, and types of input or output; levels of classification of the data; communications requirements; and physical protection afforded the system.(2) Establish and integrate security milestones into the life-cycle plan of the AIS. The AIS developer will ensure that users, data owners, system security officers, and accreditation authorities are involved in defining and implementing security requirements and that a security plan for meeting these requirements is prepared and implemented.
(3) Incorporate in procurement and acquisition documents applicable security requirements and requirements of DOD 5200.28
Identify the following during the initial stage of system design:(1) The accreditation authority: the DAA will be designated before the system design process begins to ensure applicable security requirements are integrated into the proposed AIS.(2) The ISSM for the system during pre-deployment: the pre-deployment ISSM ensures that the provisions of this regulation are met before system fielding. The pre-deployment ISSM will be distinct from the using activity ISSM who has purview over system security after the system is operational.(3) The classification of information to be processed.(4) The security mode of operation.(5) The required minimum evaluation class from DOD 5200.28 STD (see app E).
The following pre-fielding milestones will be developed:(1) A definition of the security requirements of the system. This will be based on the minimum evaluation class and on a detailed risk analysis that addresses all projected employment options for the system.(2) A plan to test and certify that the system meets the technical security requirements. In addition to the technical security requirements, a plan to ensure that environmental and physical security requirements are satisfied must be prepared prior to fielding. This certification testing should be part of the overall testing of the system. The DAA will coordinate with ODISC4 for planning, conduct, and approval of certification testing. (For DODIIS Core Product testing, see para 3
(3) The accreditation document will be fielded with the system as either a separate entity or a distinct part of the system documentation. It will incorporate the technical certification with the non-technical security measures and will address the items contained in the accreditation format at appendix D.(4) A security SOP for users, operators, and ISSOs. The security SOP will be fielded with the system as either a separate entity or a distinct section of the system's operating manuals. This SOP will identify all required security measures that must be enforced to operate the system at the level of classification and in the mode of operation for which it is accredited. It will incorporate all the countermeasures appropriate for the system and will address, as a minimum, the physical, personnel, hardware, software, communications, procedural, and emissions security countermeasures upon which the accreditation is based.
(5) A security classification guide. These security classification guides (SCGs) will be fielded either as a separate entity or as a distinct part of the system's documentation when the system will process classified information. This will conform with the headquarters classification guide and is highly important for systems supporting a tactical force.
The generic accreditation documentation will be forwarded to the ISSPM of each Army MACOM and each major installation or activity ISSM receiving the system following DAA approval. The MACOM ISSPM, together with the command information manager and command functional user representative, will either accept the generic accreditation or prescribe additional measures or procedures to meet the needs of a unique operating environment. Such additional measures will be appended to the generic accreditation to constitute the system accreditation in that MACOM.
The AIS subject to generic accreditation will not be fielded or operated in a MACOM until the cognizant ISSPM has granted an approval to operate on behalf of the MACOM commander.
The DAA may approve a "type accreditation" for information systems that have similar hardware and software configuration and modes of operation and sensitivity levels and where the risk of operating in a physically secure environment is considered low. The DAA will establish the requirements and conditions under which an information system can be accredited using the type accreditation scenario.
3.3.2.1 GENERIC OR TYPE ACCREDITATION
3.3.2.2 OPERATIONAL ACCREDITATION
Operational accreditation is applicable to all AIS that have not been accredited by a generic accreditation. Operational accreditation is also required for AIS covered by a generic accreditation if the AIS operates beyond the security bounds of the generic accreditation.
Operational accreditation may apply to the following areas:a. A single AIS.b . A grouping of more than one AIS sharing the following characteristics: (1) The same DAA. (2) Common risks and countermeasures to combat these risks, as determined by the risk management process. (3) Common data sensitivity. All AIS with differing data sensitivity may be grouped in a single accreditation provided that paragraphs a. and b. above apply and that the accreditation documentation clearly segregates the different levels and the security measures applicable to each level.
3.3.2.3 SYSTEM BASED ACCREDITATION
The DAA may determine that the information system undergo certification and accreditation in an environment where the system monitors and provides its own security. In this scenario, certification activities are focused on the safeguards that the system provides while the external controls (i.e., locks, guards, etc) are only identified in a cursory manner. The information system accreditation would apply to certain types of technology implementations, e.g., client-server or distributed system.
Under the system-based approach, the certification and accreditation focus may include a single system or network (as in the case of a complex, newly deployed system) or it may include smaller groupings of equipment as listed below:(1) A LAN can be accredited as a single unit. Individual personal computers and work stations on a LAN need not be accredited individually.(2) Groups of stand-alone personal computer systems, work stations, and office automation systems located in the same general area and performing the same general functions may be accredited as a single unit.
The ODCSINT Intelligence Information Management Directorate (DAMI
The AISs and networks must be certified and/or accredited on an individual basis to determine whether they operate at an acceptable level of risk under both the system and site-based approach.
The AIS, guard devices, or networks intended to operate in the compartmented or multilevel security mode will be given the highest priority for certification and accreditation due to the increased risk associated with their operation.
3.3.2.4 SITE BASED ACCREDITATION
Site-Based Accreditation The DAA may choose an alternate accreditation approach that consolidates all systems at a location into a single management entity called a "Site". The size and bounds of each site are determined by the relationship of each system (component) to the infrastructure, command lines of authority, and the span of control of the site's ISSM. Site accreditation begins with all systems at the site being evaluated and certified. The site is then accredited as a single entity, and the ISSM may be delegated the authority to add more systems to the site.
The DAA may determine that a site accreditation approach is the optimal way to effect an accreditation given the number of information systems, networks, or unique operational characteristics. Test sites, Network Operations Centers (NOCs), and large data processing facilities such as MegaCenters are candidates for site accreditation. In this scenario, certification activities are focused on the safeguards that are provided by the information system and all external controls (administrative, physical, personnel, COMSEC, emissions, and computer security). Where the DAA has accredited a site, the statement of accreditation will state the approved set of countermeasures that are accredited and will specify the conditions, given the operational concept and environment, under which the site has been approved to operate.
Under a site-based approach, the entire site as defined and documented may be certified and accredited as a unit if the individual AIS and components have been appropriately certified or ac-credited by a DAA. A site boundary is not limited to a specific geographic location and more than one site may be established at a single location (for example, Fort Bragg, NC, has five sites). A site may contain one or more systems and may also contain systems previously accredited by another DAA (for example, CIA, NSA, other MACOM commanders, or their representatives).
A Site Security CONOPS and a Site Security Architecture are required for site-based accreditation and shall contain a listing of all systems covered under the site-based accreditation, a description of how the site complies with the requirements of this manual, and a wiring diagram showing external connections.
The following actions are required to establish a site:(1) The ISSM and ISSO, in conjunction with the appropriate commander, will establish a Configuration Management/Control Board to ensure that AIS and networks included in the Site baseline can be securely maintained. The Configuration Management/Control Board will consist of information management, acquisition, operations, security, and user management personnel and ISS personnel.(2) New SCI systems integrated into the site baseline will meet the certification requirements of the DIAM 50
When practical, the Army will establish sites composed of non-sensitive, SBU, collateral, and SCI systems.
3.3.2.5 ACCREDITATION OF LAPTOPS AND PORTABLE AIS
Laptop/notebook computers or any other computers designed to allow periodic relocation must be accredited in accordance with chapter 3 of this regulation by the appropriate DAA. The DAA may accredit more than one computer on one document.
The DAA will indicate on the accreditation document exactly where the [portable] computer may be taken and the kind of classified material that may be stored on the computer. Users of the portable computer must follow the accreditation instructions at all times, and users must possess a copy of the accreditation documentation at all times when the computer is removed from their regular place of work.
All systems shall be certified and accredited in compliance with the requirements stated in the associated implementation manual and following the direction and guidance provided in the Designated Accrediting Authority (DAA)-approved certification and accreditation (C&A) process. C&A is a comprehensive process to ensure implementation of security measures that effectively counter relevant threats and vulnerabilities. C&A consists of several iterative, interdependent phases and steps whose scope and specific activities vary with the IS being certified and accredited.
3.3.2.6 ACCREDITATION OF SCI SYSTEMS
The AIS or networks that process non-cryptographic SCI data are subject to this regulation and DIAM 50
Prior to use, automated information systems located in a SCIF must be accredited under the provisions of this regulation, Defense Intelligence Agency Manual (DIAM) 50
Intelligence System Accreditations. Paragraph 2.B.2.a, above, designates the principal accrediting authorities with responsibility for all intelligence systems covered by this manual. Systems processing intelligence information or components of such systems that operate at Protection Levels 4 or 5 can only be accredited by the Director of the NSA, the Director of the DIA, the Director of the NRO, or the Executive Director of the Central Intelligence Agency. The authority to accredit these systems cannot be further delegated unless authorized by the DCI. Intelligence Community PAAs may delegate, to the extent they consider appropriate, their authority to accredit systems processing intelligence information or components of such systems that operate at Protection Levels 1, 2, or 3. But they retain ultimate responsibility for the security of the information processed in those systems.
For systems operating under the purview of more than one PAA, the following guidelines shall be followed: For systems processing intelligence data:*(1) Systems operating at Protection Levels 4 or 5 that are under the purview of three or more PAAs shall be jointly certified by a panel or board consisting of representatives of the affected parties, and accredited by the DCI.(2) Systems operating at Protection Level 3 that are under the purview of three or more PAAs shall be jointly certified by a panel or board consisting of representatives of the affected parties, and accredited by a single accrediting authority by mutual agreement or, if mutual agreement cannot be achieved, by the DCI.(3) Systems operating at Protection Level 2 that are under the purview of three or more PAAs may be jointly certified by a panel or board consisting of representatives of the affected parties, and accredited by a single accrediting authority by mutual agreement or, if mutual agreement cannot be achieved, by the DCI.[*Until indicated otherwise, the panel or board cited in the following paragraphs shall be the Defense and Intelligence Community Accreditation Support Team (DICAST).]
(4) Systems processing intelligence operated by an organization that is not part of the National Foreign Intelligence Board (NFIB) shall be jointly accredited by its NFIB sponsor and the most appropriate Principal Accrediting Authority (or an appropriately authorized designee).
For systems processing intelligence and DoD SAP data. Systems shall be accredited separately (i.e., via two separate accreditations) or jointly by the cognizant intelligence DAA and SAP DAA as per the guidance in paragraph 9.D.2.a above and in relevant SAP directives.
For systems processing intelligence information, operating under the purview of more than one PAA, and that are not jointly certified by a panel or board:(a) A Memorandum of Agreement (MOA) shall be required between the cognizant PAAs; the MOA should name a lead PAA, who will be responsible for the system certification. If no lead PAA is named, then both parties shall share responsibility.(b) The MOA shall be included in the SSP.
The accreditor for a system that is to be connected to another system shall consider the security characteristics of the other system, as well as the security characteristics of all systems directly connected to the other systems. This has been described as considering connections "one layer further." If any of the systems that are "one layer further" are considered a greater security risk (e.g., having users of a lower security level), then the accreditor should consider increasing the Protection Level or Integrity Level-of-Concern, or both.
(2) The DAA for each interconnected system is responsible for ensuring that all data is properly protected by each system that is directly connected to the DAA's system.(3) The security requirements applicable to the interconnected systems are determined by (a) the Confidentiality Protection Level and the Integrity and Availability Levels-of-Concern of the interconnected systems (Chapters 4, 5, and 6, and Appendix D), (b) their interface characteristics (Chapter 7), and (c) their operational environment.
Under periods processing, the highest sensitivity level and the most restrictive data processed on the system will determine the DAA. The DAA shall coordinate authorizations for using the system at lower or less restrictive levels.
Systems shall be reviewed for compliance with the policy and its implementation manual and the security documents derived from the manual.
Accreditation Process. Before accrediting a system to operate, the DAA shall (1) determine the IS's Confidentiality Protection Levels, and the Integrity and Availability Levels-of Concern, (2) inform the ISSM/ISSO of the DAA determination, (3) ensure that satisfactory safeguards (i.e., those requirements specified in Chapters 4, 5, and 6 for the Confidentiality Protection Level, and the Integrity and Availability Levels-of-Concern, respectively) have been implemented, (4) ensure that the applicable requirements specified in Chapter 7 ("Requirements for Interconnected Systems and Advanced Technology") and Chapter 8 ("Administrative Security Requirements") have been implemented, and (5) ensure that the residual risk is within acceptable limits.
Accreditation for all SCI systems with DIA as the accreditation authority will be prepared and processed in accordance with DIAMs 50
Single-User, Standalone ISs. Extensive technical safeguards are normally inappropriate and inordinately expensive for single-user, standalone ISs. DAAs can approve administrative and environmental protections for such ISs, in lieu of technical safeguards. Except for systems that operate in a periods processing environment as specified above, ISs that have one user at a time, but have a total of more than one user, are multi-user ISs, and the DAA shall consider the systems as such in determining the Protection Level and the resulting security requirements.
An impartial party selected by the DAA shall determine the level of residual risk. The impartial party may not be the system developer(s). However, the ultimate responsibility for accepting the residual risk rests with the DAA.
While the DAA assumes formal responsibility for operating a system (and accepting the risk of such operation), the Data Owner has statutory responsibility for the information processed on the system. As such, the Data Owner has the authority to revoke permission to process information on the system if unsatisfied with the protection provided by the system. The Data Owner shall notify the PAA/DAA of any decision to revoke access to information.
Eleven steps are required to accredit an IS. The following summarizes those steps and in each case refers to the relevant chapter or chapters of this manual:1.F.1 Determine Levels-of-Concern (Ch. 3). The DAA, using formal specifications from the Data Owner, examines the information* characteristics in light of the material in Table 3.1 and determines the appropriate Level-of-Concern ratings, one each for confidentiality, integrity, and availability. The Level-of-Concern ratings for integrity and availability are each Basic, Medium, or High. Because all of the ISs covered by this manual process intelligence information, the Level-of-Concern rating for confidentiality is always High.1.F.2 Determine Protection Level (Ch. 3). Based on the guidance provided in Chapter 3, the DAA determines a Protection Level for confidentiality for the system and also determines any threats unique to the system or the information.[*In this context, information is expressed as human-recognizable data and machine-recognizable data, in hardware, software, firmware, and, especially, data that is used to control security functions, such as router table entries.]
1.F.3 Determine Interconnected System Requirements (Ch. 7) and Administrative Requirements (Ch. 8). The DAA determines the appropriate security requirements for interconnected systems and for the use of advanced technology specified in Chapter 7 and the administrative requirements specified in Chapter 8.1.F.4 Identify Technical Security and Assurance Requirements (Ch. 4, 5, and 6). The applicable technical security requirements and assurances are identified. Chapter 4 presents the technical security requirements and assurances for confidentiality organized by Protection Levels. Chapters 5 and 6 present the technical security requirements and assurances for integrity and availability, respectively, organized by Levels-of-Concern.1.F.5 Determine Required Documentation and Testing Activities (Ch. 4, 5, and 6). The assurance requirements in Chapters 4, 5, and 6 are examined to determine the appropriate documentation and testing activities required for the system.
1.F.6 Write the System Security Plan (Ch. 9 and Appendix C). The System Security Plan (SSP), described in Appendix C, is written to describe the planned operating conditions of the system and the expected residual risk of operating the system (Chapter 9). The DAA and/or ISSM approves the SSP, and the system is then implemented with the security requirements that have been determined for it (paragraphs 1.F.1 through 1.F.5). In the case of operational systems (with their security requirements already implemented), the SSP is written to describe the operating conditions of the system and the residual risk of operating the system.1.F.7 Validate Security in Place. The ISSO ensures that the security requirements and procedures are in place for the system.1.F.8 Testing against Security Requirements (Ch. 4, 5, and 6) The system is tested based on the security testing requirements in Chapters 4, 5, and 6 .1.F.9 Prepare Certification Package (Ch. 4, 5, 6, 9). The ISSO and ISSM prepare the certification package, based on the documentation requirements in Chapters 4, 5, and 6, and the certification package requirements specified in Chapter 9.1.F.10 The certification package is presented to the DAA for accreditation1.F.11 Accreditation Decision by the DAA. The DAA* determines whether the level of residual risk is acceptable and consistent with that indicated in the SSP, and if it is, accredits the system. Testing shall be performed to validate the extent of residual risk.[*When this manual refers to the DAA, the DAA Representative is assumed to be included, at the discretion of the DAA.]
Both ISs under development and ISs in operation can be accredited.
If the DAA accredits the system, the system goes into operation (or continues to operate) according to the accreditation.
An IS accreditation provides formal approval for an IS to operate, and identifies the following:(1) Stated operational concept and environment, including mission criticality and characterization of user communities (i.e., approximate number of users, clearance, formal access approvals, need-to-know, privileges).(2) Classification and sensitivity of the information on the IS, including specific applicable classifications, compartments, caveats, control markings, and special handling instructions that may be handled by the IS.(3) A given Confidentiality Protection Level.(4) A given Integrity Level-of-Concern.(5) A given Availability Level-of-Concern.(6) Specified operating conditions, including prescribed safeguards.(7) Stated interconnections with other ISs, when applicable.(8) A specified period of time.
A DAA's accreditation of an IS and its environment is an assertion of an acceptable level of security risk. Acceptable security risk is the expectation that an IS will adequately protect against unauthorized access, alteration, or use of an IS's resources, and against denial of the IS's services to authorized users. This expectation is based on the assumption of continuous employment of administrative, procedural, physical, personnel, communications security, emanations security, and IS security controls. IS security controls can be features of the software, hardware, or firmware of an IS, or associated security-specific devices.
A system that is under development or major modification, and is expected to be under development or major modification for an extended period, can be accredited to operate in such an environment. Such an accreditation shall include detailed descriptions of changes (or types of changes) that would not require additional DAA approvals, and changes (or types of changes) that would require additional DAA approvals.
Accreditation Decision. Based on all available documentation and mitigating factors, the DAA shall decide whether to grant:a Accreditation approval for the system to operate as certified.b Accreditation disapproval, including recommendations and time lines for correcting specified deficiencies.c Interim approval to operate, identifying the steps and any additional controls to be completed prior to full accreditation.
The DAA may grant interim approval to operate a system to meet written validated requirements or to permit a major conversion of a system. This interim accreditation may be granted for up to 180 days and can be renewed once for an additional 180 days. By the end of the second 180-day period, the system shall either be accredited or cease operation.Protection measures specified by the DAA shall be in place and functioning during the period of interim approval.
If the DAA grants an interim approval to operate, the system may be operated for up to 180 days, and the interim approval to operate can be renewed once for an additional 180 days. The DAA must indicate, in the agreement granting interim approval to operate, the actions necessary to meet accreditation. By the end of the second 180-day period, the system shall either be accredited or cease operation.
If the DAA neither accredits the system, nor grants an interim approval to operate, then the requester must modify the system or its safeguards, and the process repeats from paragraph 1.F.6, above, until the DAA accredits the system, grants an interim approval to operate, or decides to disallow system operation.
Defense Intelligence Agency Manual 50
The request must define the physical locations and inter-connectivity of the AIS and networks. Documentation for sites certified and accredited under the site concept will be maintained through the configuration management process and security compliance reviews. The ISSM will integrate new AIS into the established site baseline and ensure that they do not adversely affect previously certified and accredited AIS.
The DAA has the authority to specify, notwithstanding the requirements of this manual, a greater Level-of-Concern or amount of protection for any given system in any given environment.
Responsibilities of the PAA include:...2.B.2.b(10) When justified, approving the operation of a system that does not meet the requirements specified in this manual. However, such approval shall be in writing, and the PAA granting such approval shall also accept, in writing, the responsibility for the resulting residual risks and shall inform the other PAAs responsible for systems interconnected to this system. The PAA may choose to delegate this authority to the DAA.
Integration of DODIIS Core Products is considered a form of generic accreditation. The DODIIS Core Product program officer is responsible for Core Products design, test, and evaluation.
Should the DAA choose to accredit a system even though the system implementers are unable (within fiscal and operational constraints) to implement all the requirements as specified in this manual, the DAA shall, prior to accreditation:2.B.4.f(1) Identify in writing to the Data Owner(s) of all data on the system any requirements that are not being implemented and which mitigating safeguards are being applied to the system.2.B.4.f(2) Identify in writing to the DAAs of directly connected systems any requirements that are not being implemented and which mitigating safeguards are being employed on the system.2.B.4.f(3) State in writing that the DAA accepts responsibility for the risk of operating the system with lessened protection.
Invalidation of an Accreditation. An accreditation immediately becomes invalid whenever detrimental, security-relevant changes occur to any of the following: the required Protection Level, the operational environment, the operational concept, or the interconnections. Any non-DAA-approved security-relevant changes to the IS may result in the invalidation of the accreditation.
All DODIIS AIS and networks processing SCI for which DIA is the DAA will be certified and accredited using the site-based accreditation methodology detailed in DIAM 50
The DAA shall withdraw accreditation and suspend operation if the security measures and controls established and approved for the system do not remain effective. The DAA shall withdraw accreditation when the system is no longer required to process intelligence information, or if the operational need for the system no longer outweighs the risk of operating the system.
3.3.2.7 SCI C&A PROCESS
Design and Development Phase(a) The Confidentiality Protection Level and the Availability and Integrity Levels-of-Concern are determined. See Chapters 4, 5, and 6 for specific requirements.(b) The security requirements are defined using the matrices and requirements tables in this document.(c) The threats to an IS and its vulnerabilities to the threats are identified. All known hardware, software, firmware, operational, and environmental vulnerabilities are identified. A determination is made whether or not the requirements of this manual satisfactorily mitigate the vulnerabilities. If they do not, it may be necessary to specify additional security requirements.(d) The SSP for the IS is developed and submitted to the DAA (or a DAA representative) for approval. This step is a prerequisite for starting the IS's Fabrication and Production Phase.
First Test and Evaluation (T&E I) Phase. During T&E I, the Certification Test Plan and Test Procedures are developed. The Certification Test Plan outlines the IS certification test. It describes the test sets needed to demonstrate that the IS implements its security requirements. The plan also gives specific guidelines for conducting the tests. Certification test procedures expand the test set descriptions into step-by-step descriptions of the security requirement tests.
Second Test and Evaluation (T&E II) Phase(a) Most of the C&A process is conducted during T&E II. Once functional testing is complete, the security test and evaluation is conducted based on the Certification Test Plan and Test Procedures. Shortfalls and vulnerabilities are identified, and risks are analyzed. The outcome of the risk analysis is used to develop a plan to address shortfalls. The plan includes actions required to fix or work around particular shortfalls. The Certification Package (see paragraph C of this chapter) is then prepared and submitted to the DAA.
The DAA reviews the Certification Package and uses its information as the basis for the accreditation decision. The DAA considers all relevant factors in determining whether to accredit a system. These factors include security environment, system mission, availability and cost of alternative countermeasures, and residual risks. The DAA may also consider factors that transcend security, such as program and schedule risks.
Operations and Maintenance (O&M) Phase. Changes to the IS's security structure may require re-certification and re-accreditation (see paragraphs C and D of this chapter).
Disposal Phase. When the IS is no longer required, the process ends with its secure disposal.
Operational Systems. These systems shall be accredited under the requirements of this document. All of the steps listed in paragraph 9.E.2.a, above, will be conducted. Except for disposal, this process will be conducted under the O&M Phase. Prudent risk management dictates that careful consideration be given before adding expensive additional safeguards to a system that has an extensive history of operation with effective security. DAAs accrediting existing systems are strongly encouraged to give appropriate weight to the system's operating history.
The C&A process (from initial certification and accreditation to the withdrawal of accreditation) covers the entire life cycle of an IS. The C&A process depends upon careful identification of the security-relevant aspects of an IS. A complete IS certification considers a large number of factors associated with the IS and its operational environment. These factors include identification of the DAA; mission criticality; functional requirements; IS security boundaries; applicable security policies; security CONOPS; IS configuration; IS components; user characteristics and authorizations (e.g., includes foreign nationals, integrees, contractors); IS applications; site/facility locations; external interfaces and interconnections; Protection Level; Levels of Concern; classification of the data and associated caveats; IS and data ownership; risk analysis, including threat and vulnerability assessments and countermeasure implications; and counterintelligence aspects.
3.3.2.8 EXCEPTIONS FOR SCI SYSTEMS
Limitations in resources and technical capabilities may prevent the satisfaction of all security requirements without introducing unacceptable delay in achieving the operational requirements that the system was intended to satisfy. Therefore, DAAs are authorized to grant written exceptions* to some security requirements identified in this manual under the following conditions:a) The written request for an exception shall state explicitly: (1) The requirements that are to be excepted and for what duration. The request shall include evidence stating why the identified requirements cannot be implemented, and indicate the countermeasures that are to be substituted.[*For the purposes of this manual, an exception indicates that the implementation of one or more security requirements is temporarily postponed and that satisfactory substitutes for the requirement(s) may be used for a specified period of time. This is in contrast to a waiver that implies a security requirement has been set aside and need not be implemented at all.]
(2) What aspect of the threat or associated vulnerabilities is related to the proposed request. The request shall include evidence that the consequent risk to the system and to the information it processes, stores, or transmits will be acceptable based on other countermeasures that will be employed over the specified period.b) A plan for implementing the "excepted" security requirements later in the life cycle of the system shall be developed.
c) Approval of the exception will make it incumbent upon the accrediting authority responsible for the system to ensure that the necessary programmatic, planning, and funding steps are taken to ensure implementation of any security requirements that are temporarily postponed as a consequence of approval of the exception.
There shall be no exceptions to the following requirements:a Development of a System Security Plan (including a User's Security Guide when applicable).b Implementation of a security training and awareness program.c Compliance with all applicable physical, personnel, and communications security requirements.d The appointment of an ISSO.e Completion of risk management requirements described in paragraph 9,B, above, the certification process described in paragraph 9.C, above, and the formal acceptance of the risk of operation by the designated accrediting authority as specified in paragraph 2.B.4, above.
Given the complexity of the asset to be accredited, its technology implementation, or nature of its operation, the DAA may require that the information system be certified and accredited in one of the following scenarios.
3.3.2 TYPES OF ACCREDITATION
3.3.3 CERTIFICATION
The ISSM shall provide written verification to the DAA that the system operates in accordance with the approved SSP, and that the security features, including access controls, configuration management, and discretionary access controls, are implemented and operational.
Certification is a technical evaluation of the effectiveness of AIS security features and supports the accreditation decision. Certification verifies that the AIS security functions are correctly implemented and sufficient to support the mode of operation and the security policy for the system in an intended operational environment...Certification primarily addresses software, hardware, and firmware security measures. It must also consider procedural, physical, personnel, and emissions security to the extent that these measures are employed to enforce security policy.
Assurance shall be provided by the ISSM to the DAA that the system operates in accordance with the approved SSP, and that the security features, including access controls and configuration management, are implemented and operational.
Software for mission critical systems must have a method of providing quality assurance, called certification. Before certification, software and related documentation must be tested to make sure it provides the quality assurance and security controls required. This is part of the Security Test and Evaluation (ST&E). Security controls and software must be tested to make sure they do not circumvent any security controls already in the system. ST&E should be performed by an organization other than the developing organization. Commercial off-the-shelf and public domain software also should be tested and certified if it contains security controls. A software release or version need only be certified once and a copy of the certification letter included with all copies of the software.
...system(s) operating at Protection Level(s) [2-5] shall employ the following features:...Additional testing, at the discretion of the DAA.4.B.2.b(7)(a) Certification testing shall be conducted including verification that the features and assurances required for the Protection Level are functional.4.B.2.b(7)(b) A test plan and procedures shall be developed and include: 4.B.2.b(7)(b)(1) A detailed description of the manner in which the system's Security Support Structure meets the technical requirements for the Protection Levels and Levels-of-Concern for integrity and availability. 4.B.2.b(7)(b)(2) A detailed description of the assurances that have been implemented, and how this implementation will be verified. 4.B.2.b(7)(b)(3) An outline of the inspection and test procedures used to verify this compliance.
The extent of the certification effort will vary with the security mode of operation of the system as follows:(1) Dedicated security mode. The certification will focus on the physical, procedural, and personnel security measures that ensure that all users have the appropriate clearance, access approval, and need-to-know for all data on the system. The certification effort will not be extensive, since the system is not required to separate users and data with technical security measures.(2) Systems high and compartmented security mode. The certification will cover the same factors as the dedicated mode. It will also establish that the hardware and software reliably separate users from any data for which they do not have a "need-to-know" or for which they do not have formal access approval.(3) Multilevel security mode. The certification will address the same factors as (1) and (2), above. It will also assure that the system software and hardware can reliably separate users from data on the system for which they are not properly cleared.
Testing, as required by the DAA:4.B.3.b(9)(a) Security Penetration Testing shall be conducted to determine the level of difficulty in penetrating the security countermeasures of the system.4.B.3.b(9)(b) An Independent Validation and Verification team shall be formed to assist in the security testing and to perform validation and verification testing of the system.
Testing shall include:4.B.5.b(11)(a) Security Penetration Testing to determine the level of difficulty in penetrating the security countermeasures of the system.4.B.5.b(11)(b) Formation of an Independent Verification and Validation team that at least annually assists in security testing and performing validation and verification testing of the system.
The certification process validates that appropriate Levels-of-Concern for integrity and availability and an appropriate Confidentiality Protection Level have been selected from the tables and descriptions (Chapters 3, 4, 5, 6, and 7, and Appendix D) in this manual, and that the required safeguards have been implemented on the system as described in the SSP.
The ISSM shall provide a package of certification documentation to the DAA. This certification package shall include (1) the SSP; (2) the test plans, if system testing is required; (3) the test results (or, at the DAA's discretion, a summary of the test results); (4) a statement that the system implements the required security safeguards as described in the SSP; (5) an identification of any additional safeguards required by the DAA; (6) an identification of factors mitigating potential risk; and (7) a recommendation for DAA approval or disapproval. The certification process culminates in an accreditation decision by the DAA.
Certification of DON information systems shall be performed and documented by competent personnel in accordance with specified criteria, standards and guidelines.
Certification is a key element of generic accreditation. The security certification testing will be performed as part of the overall system testing. However, security-relevant test objectives will be identified as separate events.
Where practical, individuals who complete the certification should be independent from the developer's staff.
The DISC4 will coordinate with technical personnel who will conduct a certification test under a certification plan to determine if an unclassified, SBU, or collateral system adequately meets pre-scribed security requirements. Commander, INSCOM, will coordinate with technical personnel for certification of SCI systems.
For operational accreditation, the ISSM or ISSO preparing the accreditation will supervise security certification.
The DAA, or a person appointed by the DAA, approves the results of the certification. For generic accreditation, the certification testing and approval must be a separate, distinct event in the accreditation process.
Using products or systems listed in the NSA Information Systems Security Products and Services Catalogue will not negate the requirement for certification. However their use can greatly reduce the testing required for certification approval. In many cases, using NSA-approved products can reduce the certification effort to simply establishing that the product is installed and implemented according to the specifications.
Since only a limited number of NSA-approved products are available that can satisfy user's requirements, other COTS and GOTS products should be integrated into the AIS. Certification testing of COTS and GOTS products must be performed to ensure that the infrastructure security posture is maintained per DOD 5200.STD, TCB C2 level of compliance.
3.3.4 REVIEW AND REVISION REQUIREMENTS
Use of the system shall be re-authorized at least every three years.
Minimally, an AIS shall be reaccredited every 3 years, regardless of changes.
ISs in operation shall be re-accredited whenever security-relevant changes occur in an IS or its operational environment. Even if no security-relevant changes occur, the accreditations shall be re-evaluated every three years.
Re-accreditation is merited at least every 3 years or whenever a major change occurs.
Computer-based systems processing classified or Sensitive Unclassified information must be reaccredited at least every three years or whenever the system is reconfigured in a way which significantly changes the risks and vulnerabilities associated with it.
Recertify and reaccredit all information systems every 3 years unless changes to the information system or environment baseline impact security, thereby necessitating re-certification or re-accreditation sooner.
An accreditation shall be re-evaluated within three years after it is issued or whenever any security-relevant change occurs. An accreditation shall immediately be re-evaluated upon a detrimental, security-relevant change in the threat to, or vulnerability of the system; a change to the technical or non-technical security requirements; or a significant increase in the level of residual risk.Re-evaluation of an accreditation involves a determination by the DAA, based on a recommendation by the ISSM, whether the original accreditation is still valid. The DAA can re-accredit the system or require further action.
Information processing assets will be reaccredited at least every 3 years or when a major change has been made that impacts security. The level of effort required for re-certification and re-accreditation action will depend on the scope of the change to the security environment. Review of configuration management activities and the current environment by the DAA and certifying authority will determine actions required for re-accreditation. Re-accreditation may include the same steps accomplished for the original accreditation; however, portions of the security documentation which remain valid will not need to be redone.
An independent review or audit of the security controls in each application should be conducted at least every 3 years. The review should support re-accreditation activities, ensure that deficiencies are documented and repaired, and provide an update to the cognizant ISSO on the effectiveness of the applications security controls. For General Support Systems, a review of the security controls in each system should be conducted when significant modifications are made and at least every 3 years. The review should identify that the security controls are commensurate with the acceptable level of risk for the system.
The responsible ISSM or ISSO will periodically evaluate the accredited status and will make a determination if re-accreditation is needed (as described in paragraph 3 of this chapter). If re-accreditation is not needed, the ISSM or ISSO will document the scope and date of the review performed and will maintain a file of the reviews conducted. As a secondary measure, CISS, operating under the DAA's authority, will periodically measure the effectiveness of the accredited baseline via the use of compliance validation
The following is a representative (not all inclusive) example of events that may impact security and could require re-accreditation action. The ISSM/ISSO must submit a request for re-accreditation under the conditions that follow: a. A change in criticality or sensitivity level of the information processed. b. A breach of security or violation of system integrity which reveals a flaw in security design, system security management, policy, or procedure. c. A change in the threat environment impacting overall system risk. d. A change in the system security mode of operation. e. A change in the operating system, security software, or hardware that affects the accredited security countermeasure implementation.
Review the security controls in each system when significant modifications are made to the system, but at least every three years. The scope and frequency of the review should be commensurate with the acceptable level of risk for the system.
The security of systems shall be reviewed whenever changes occur to missions, information systems, security requirements, or threat, and whenever there are significant adverse changes to system vulnerabilities.
ISSMs will.Periodically review the status of all AIS and networks to ascertain that changes have not occurred that affect security and negate the accreditation.
A program for conducting periodic reviews of the adequacy of the safeguards for operational, accredited AISs shall be established. To the extent possible, reviews are to be conducted by persons who are independent of the user organization and of the AIS operation or facility.
Any changes to the AIS or associated environment that affect the accredited safeguards or result in changes to the prescribed security requirements shall require re-accreditation. Re-accreditation shall take place before the revised system is declared operational.
All AIS accredited under this regulation will be reaccredited within 3 months following any event below:(1) Addition or replacement of a major component or a significant part of a major system.(2) A change in classification level of information processed.(3) A change in security mode of operation.(4) A significant change to the operating system or executive software.(5) A breach of security, violation of system integrity, or any unusual situation that appears to invalidate the accreditation.(6) A significant change to the physical structure housing the AIS that could affect the physical security described in the accreditation.(7) The passage of 3 years since the effective date of the existing accreditation.(8) A significant change to the threat that could impact Army systems.(9) A significant change to the availability of safeguards.(10) A significant change to the user population.
Re-accreditation will include the same steps accomplished for the original accreditation; however, those portions of the documentation that are still valid need not be updated.
Re-accreditation of AIS and networks that have been included in an infrastructure under the site-based accreditation (SBA) concept (para 3
3.4 RULES OF THE SYSTEM
Establish a set of rules of behavior concerning the use of, security in, and the acceptable level of risk for the system. The rules shall be based on the needs of the various users of the system.
DoDD 5500.7, Standards of Conduct, 30 August 1993, states that government assets will be used for the conduct of official government business. Therefore, organizations are responsible for developing specific guidance consistent with the use of technology purchased in support of their mission. Guidance should be as stringent as necessary to provide adequate security, clearly delineate security responsibilities, and define expected behavior for all individuals with access to this technology.
The General Support OPR will:... Develop a set of system-specific rules to achieve adequate security. As a minimum, rules should include proper use of system privileges, sanctions regarding the unofficial use of DISA information technology, use of personally-owned software and hardware, connection to the INTERNET, dial-in access, and protection of system authenticators (e.g., smart cards, passwords).
The security required by the rules [of behavior] shall be only as stringent as necessary to provide adequate security for information in the system.
Such rules of the system shall clearly delineate responsibilities and expected behavior of all individuals with access to the system...(and) shall be clear about the consequences of behavior not consistent with the rules.
Development of Guidance Regarding Acceptable User Behavior. Guidance should be as stringent as necessary to provide adequate security and to clearly delineate responsibilities and describe expected behavior of all individuals with access to the application. Additionally, guidance should be clear about the consequences of behavior that is not consistent with use of the information technology. For General Support Systems, guidance should also cover topics such as dial-in access, connection to the INTERNET, use of copyrighted software, obtaining system access, and unofficial use of government technology assets.
Behavior consistent with the rules of the system and periodic refresher training shall be required for continued access to the system.
(The rules of the system ) shall also include appropriate limits on interconnections to other systems and shall define service provision and restoration priorities.
3.5 DOCUMENTATION
3.5.1 SECURITY DOCUMENTATION
Documentation will be maintained that describes how security will be managed and will include rules for gaining both physical, local, and remote access. Additionally, procedures for providing local and remote access by maintenance personnel, and site specific rules for managing automated security management systems or access control programs will be documented. Standard security operating procedures include the development and review of audit trails, management of user identification codes (USERIDs) and passwords, and retention periods of information system security records.
A single summary, chapter, or manual in user documentation shall describe the protection mechanisms provided by the TCB, guidelines on their use, and how they interact.
Documentation shall include:.A general user's guide that describes the protection mechanisms provided, and that supplies guidelines on how the mechanisms are to be used, and how they interact.
End-product documentation for the user, operator, and programmer should include an explanation of software security features so they can be used effectively and not circumvented or destroyed by improper usage or by a change made to the program. User documentation should contain detailed information concerning software use. Programmer documentation should contain a description of the internal software operation. This information could be classified or Sensitive Unclassified and could make the software vulnerable to improper use or change. Documentation must be protected or controlled commensurate with the classification or usefulness of the information it contains and placed under configuration management control.
...Acquiring agencies will develop security-related documentation and deliver to the customer along with the information system.
The TCB modules that contain the reference validation mechanism shall be identified. The procedures for secure generation of a new TCB from source after modification of any modules in the TCB shall be described [in the trusted facility manual].
It [the Trusted Facility Manual] shall include the procedures to ensure that the system is initially started in a secure manner. Procedures shall also be included to resume secure system operation after any lapse in system operation.
Trusted Facility Manual - A manual addressed to the ADP system administrator shall present cautions about functions and privileges that should be controlled when running a secure facility. Procedures for examining & maintaining audit files as well as the detailed audit record structure for each type of audit event shall be given.
The [trusted facility] manual shall describe the operator and administrator functions related to security, to include changing the security characteristics of a user. It shall provide guidelines on the consistent and effective use of the protection features of the system, how they interact, how to securely generate a new TCB, and facility procedures, warnings, and privileges that need to be controlled in order to operate the facility in a secure manner.
Documentation shall include guide(s) or manual(s) for the system's privileged users. The manual(s) shall at a minimum provide information on (1) configuring, installing, and operating the system; (2) making optimum use of the system's security features; and (3) identifying known security vulnerabilities regarding the configuration and use of administrative functions. The documentation shall be updated as new vulnerabilities are identified.
3.5.2 DESIGN AND TEST DOCUMENTATION
As a minimum, either the site ISSM or local ISSO will retain automated or hardcopy records regarding system access, violations or security incidents, and Statements of Accreditation. Letters of appointments for ISSOs, TASOs, and NSOs, and documents relating to the conduct of security awareness training will also be retained.
The TCB implementation (i.e., in hardware, firmware, and software) shall be informally shown to be consistent with the DTLS. The elements of the DTLS shall be shown, using informal techniques, to correspond to the elements of the TCB.
Documentation that addresses software design and capabilities will be maintained for the use of programming, operations, and user personnel. Only personnel performing official duties should be allowed access to this software documentation.
Documentation shall be available that provides a description of the manufacturer's philosophy of protection and an explanation of how this philosophy is translated into the TCB. The interfaces between the TCB modules shall be described. A formal description of the security policy model enforced by the TCB shall be available and proven that it is sufficient to enforce the security policy. The specific TCB protection mechanisms shall be identified and an explanation given to show that they satisfy the model. The descriptive top-level specification (DTLS) shall be shown to be an accurate description of the TCB interface. Documentation shall describe how the TCB implements the reference monitor concept and give an explanation why it is tamper resistant, cannot be bypassed, and is correctly implemented. Documentation shall describe how the TCB is structured to facilitate testing and to enforce least privilege. This documentation shall also present the results of the covert channel analysis and the tradeoffs involved in restricting the channels.
All auditable events that may be used in the exploitation of known covert storage channels shall be identified. The bandwidths of known covert storage channels the use of which is not detectable by the auditing mechanisms, shall be provided. (See the Covert Channel Guideline section.)
Documentation shall be available that provides a description of the manufacturer's philosophy of protection and an explanation of how this is translated into the TCB. If the TCB is composed of distinct modules, the interfaces shall be described.
Documentation shall be available that provides a description of the manufacturer's philosophy of protection and an explanation of how this philosophy is translated into the TCB. If the TCB is composed of distinct modules, the interfaces between these modules shall be described. An informal or formal description of the security policy model enforced by the TCB shall be available and an explanation provided to show that it is sufficient to enforce the security policy. The specific TCB protection mechanisms shall be identified and an explanation given to show that they satisfy the model.
Documentation shall include:Certification test plans and procedures detailing the implementation of the features and assurances for the required Protection Level.Reports of test results.
Software documentation must include a description of the security provided by the system and what is required of the user, operator, or programmer.
A formal model of the security policy supported by the TCB shall be maintained over the life cycle of the ADP system that is proven consistent with its axioms. A descriptive top-level specification (DTLS) of the TCB shall be maintained that completely and accurately describes the TCB in terms of exceptions, error messages, and effects. It shall be shown to be an accurate description of the TCB interface.
A formal model of the security policy supported by the TCB shall be maintained over the life cycle of the ADP system that is proven consistent with its axioms. A descriptive top-level specification (DTLS) of the TCB shall be maintained that completely and accurately describes the TCB in terms of exceptions, error messages, and effects. It shall be shown to be an accurate description of the TCB interface. A convincing argument shall be given that the DTLS is consistent with the model.
An informal or formal model of the security policy supported by the TCB shall be maintained over the life cycle of the ADP system and demonstrated to be consistent with its axioms.
The system developer shall provide to the evaluators a document that describes the test plan, test procedures that show how the security mechanisms were tested, and results of the security mechanisms' functional testing.
It [test documentation] shall include results of testing the effectiveness of the methods used to reduce covert channel bandwidths.
3.5.3 ACCREDITATION DOCUMENTATION
A copy of the AIS accreditation or re-accreditation documentation will be maintained with the system and should be retained by the accreditation authority or the ISSM.a. Copies of accreditation documentation to support site-based accreditation or systems processing SCI must be provided to the designated accreditation authority.b. Copies of generic accreditation documentation must be maintained by the systems developers.
3.6 ACCESS CONTROL PROCEDURES
Verify each user's need for access to information system resources and information.
When users leave their workstations or personal computers, they will log-off or lock the keyboard and screen until re-authentication.
All requests for foreign national access to a DISA information system shall be adjudicated by the Director, DISA, or duly authorized representative.
system(s) operating at Protection Level(s) [2-5] shall employ the following features: Account Management procedures that include:Identifying types of accounts (individual and group, conditions for group membership, associated privileges).Establishing an account (i.e., required paperwork and processes).Activating an account.Modifying an account (e.g., disabling an account, changing privilege level, group memberships, authenticators).Terminating an account (i.e., processes and assurances).
Special Provision for Waivers of Citizenship Requirements. All concerned PAAs and Data Owners shall approve any exception to the citizenship requirements set forth below, including for systems jointly operated by the US and a foreign allied government.
Responsibilities of the Data Owner include:.2.B.3.b(2) Determining whether foreign nationals may access information systems accredited under this manual. Access must be consistent with DCID 1/7 and DCID 5/6.
Responsibilities of the DAA include:2.B.4.e(2) Providing written notification to the cognizant PAA and Data Owner prior to granting any foreign national access to the system.
Access by foreign nationals to a U.S. Government-owned or U.S. Government-managed AIS may be authorized only be the DoD Component Head, and shall be consistent with the Department of Defense, the Department of State (DoS), and the Director of Central Intelligence (DCI) policies.
3.7 PASSWORD CONTROL
In addition to the individual assignment of unique identifiers, guidelines must be established for the management of primary authenticators (e.g., passwords).
Passwords should not be recorded in the audit trail so the audit trail can remain unclassified. This includes character strings incorrectly given as passwords possibly exposing a password.
User identification and password systems support the minimum requirements of access control, least privilege, and data integrity contained in paragraph 2-3a above. While not always appropriate for stand-alone small systems or for other systems operating in the dedicated mode, these mechanisms are often the most cost-effective and efficient method of achieving the minimum security requirements. Other techniques (for example, biometrics access control devices or smart cards) provide practical alternatives for use in conjunction with, or in place of, password systems.
3.7.1 GENERAL
As a minimum, passwords will be...changed at least every 180 days or more frequently as warranted.
3.7.2 PASSWORD MANAGEMENT
The ISSO or designated representative is responsible for managing generation, issuance, and control of all passwords.
Passwords should be protected from disclosure and handled and marked as "FOR OFFICIAL USE ONLY."
All passwords are critical to the security of the system accessed and all associated activities. Persons using passwords employed on such systems must be instructed on password sensitivity, protection, and personal responsibility for their security.
After creation, passwords will be handled and stored at the level of the most sensitive data contained in the system. In the case of multilevel security mode operations, passwords will be safeguarded according to the level of system access to which the user is authorized.
Classified users should sign for the original password verifying they understand the requirements for protecting the password.
Passwords for systems that process classified information in the multilevel mode of operation, where the password is the only measure separating users from different levels of classified information, must be classified to the level of that user and protected accordingly.
Passwords will be inhibited, overprinted, or otherwise protected from unauthorized observation on terminals and video displays.
Maximum lifetime of a password cannot exceed one year.
Knowledge of individual passwords will be limited to a minimum number of persons, and passwords will not be shared...The holder of a password is the only authorized user of that password. Without proper authority, personnel may not use another person's password or allow another person who does not have proper authority to use his or her password.
A password must be changed as quickly as possible but at least within 1 workday of a possible compromise or mishandling of the password.
A password must be suspended immediately when the user leaves the organization. If the individual uses a group password, the group password will be changed immediately.
A password must be deleted when the user no longer requires the access for a period greater than 90 days. This includes temporary duty travel and permanent or temporary interorganization transfer.
Methods of password distribution will be appropriate to the level of information they protect.
Passwords will be issued if the user has a confirmed authorization to access the system.
A password will be issued only once and will be retired when the time limit has expired or the user has been transferred to other duties, reassigned, retired, discharged, or otherwise separated from the duties or the function for which the password was required.
Passwords on non-sensitive and SBU will be changed semi-annually.
Passwords on classified systems will be changed at least quarterly.
A single point of contact with one alternate should manage and control passwords. Additional control points may be used for systems with geographically separated remote processing sites for networks.
As a minimum, passwords will be a minimum of six characters ...
3.7.3 PASSWORD STANDARDS
Passwords must contain at least seven characters but may be longerThe selected password length range must provide a level of protection commensurate to the value or sensitivity of the resources or data it protects.
Passwords for AIS processing SCI/SIOP
The primary vulnerability of passwords is that the user must memorize a sequence of characters. The sequence must be random; however, the password may be pronounceable by randomly concatenating words or syllables...For additional information concerning standardized use of passwords and user-ID's, refer to IRM-5239-06, "DATA ACCESS SECURITY."
3.7.4 USER BRIEFING
At the time of password issuance, individual users will be briefed on the following:
(1) Password classification and exclusiveness;
(2) Measures to safeguard classified and unclassified passwords;
(3) Prohibitions against disclosure to unauthorized personnel. even though they may be assigned to the same project and hold identical clearances; and
(4) The requirement to inform an ISSO or designated representative immediately of password disclosure or misuse or other potentially dangerous practices.
Users who create or select their own password must be instructed to use a password selected at random, and never one related to their personal identity, history or environment.
3.8 AUDIT MANAGEMENT
Audit trail records must be retained for a period that meets or exceeds the most stringent retention requirements applicable to information on the system being protected by the audit trail. In cases where specific data or audit record retention requirements do not exist, audit records will be retained for a period of at least 1 year.
Audit trails should be reviewed for security implications daily but, as a minimum, will be reviewed once per week.
DAAs shall cause a review to be made of audit trails associated with the AIS(s) over which the DAAs have cognizance to determine an adequate retention period for the audit information.
system(s) operating at Protection Level(s) [2-5] shall employ the following features: .Maintaining collected audit data at least 5 years and reviewing at least weekly.
The DAAs will determine how long to retain the audit information.
The SA must be able to maintain the AIS audit functions and have the ability to review audit information for detection of possible system abuse and to coordinate with the ISSO. SA responsibilities for maintaining, securing and monitoring systems are provided in appendix G, "Monitoring Capabilities and Restrictions."
3.9 PROTECTION AND DISPOSITION OF IS MEDIA & SOFTWARE
Computer media consists of any substance or material on which data is represented or stored and which is used for input and/or output to an automated system...Computer media on which classified information is stored must be controlled, safeguarded and labeled according to the highest classification level of data they have ever contained. Refer to Appendix C for procedures relating to accountability, labeling, degaussing and destruction of classified data and media. Additionally, Appendix E identifies and addresses the requirements for the protection of Sensitive Unclassified data and media.
The AIS media consist of any substance or material on which information is represented or stored, used for either input or output to an AIS, or the media are an integral part of the AIS. Users of classified media must protect the media in accordance with the procedures of AR 380
Removable information storage media shall bear external labels indicating the security classification of the information and applicable associated security markings, such as handling caveats and dissemination control labels. SSPs shall identify the removable storage media to be used with a system. Classified removable media shall be controlled and protected in a manner similar to that used for classified paper materials. Removable media shall be marked as classified if the media has ever been used on the classified system, AND during any use on the system, was writable (i.e., the write-protect feature could not be verified).
Safeguard, mark, and label output products and removable media according to DoDD 5200.1, DoD Information Security Program, December 13, 1996; and AFI 31-401, Information Security Program Management.
All AIS processing SCI and classified collateral information will comply with the following requirements: (1) Any removable magnetic media placed in an AIS with fixed media must be protected at the same classification level as the system. Fixed media include systems having memory retention capabilities such as internal memory retention devices or non-removable hard disks. (2) Any removable magnetic media placed in an AIS without fixed media (for example, a diskless workstation in a client server environment) must be protected at the highest classification level of any media used simultaneously in the AIS.
General requirements for accountability, receipting, transmission, and all other measures for classified material prescribed in AR 380
Responsible organizations should implement security controls in accordance with OPNAVINST 5510.1 for classified ADP media to include, but not limited to, the following: a. Maintenance of an ADP media log to provide a complete inventory of classified media and files to include classification, media catalog number or file name, owner date created, date declassified or destroyed. b. Mark externally all media with highest classification thereon. c. Mark internally all files with classification authority, date created, owner and classification. d. Store all classified media in GSA approved security containers when not in use. e. Systems with internal hard disk or other internal mass storage media should be stored in a manner which provides the appropriate level of security for data resident in internal memory. f. Computer monitors should be inspected for burn-in. Consider usage of screen blanking software.
In those areas, designated in the SSP, where classified information is processed, unmarked media that are not in factory-sealed packages shall be protected at the highest level of classification processed within the facility, until the media has been reviewed and appropriately labeled.
Generate output only within the central facility or at a remote station staffed with personnel cleared for the highest sensitivity level of information processed by the information system when the system does not have controls that limit output to authorized users.
If the classification of removable media is more restrictive than the level for which the AIS is accredited under this regulation, the special security officer (SSO) must be notified of a security violation, and the AIS must be protected at the more restrictive level. Additionally, the AIS accreditation must be resubmitted to accommodate the more restrictive level unless the system is completely sanitized and there is no intent to process at the more restrictive level in the future.
All removable or transportable magnetic media on which classified information is stored must be color coded or marked with a label (sticker) indicating the classification and special access category of the recorded information. In those instances where it is not practical to label the media itself, the container in which it is stored must be labeled. All floppy diskettes used for Classified processing will be color coded (according to the color scheme in Appendix C) to the highest classification of the information on them. All other types of removable magnetic media (such as removable hard disks or cassette tapes will be labeled with a color coded label (sticker) as identified and listed in Appendix C.
Prevent vendor maintenance personnel from removing classified or sensitive media, products, etc., from government facilities when those personnel do not have the proper authorization (e.g., verified identity, security clearance, access approval for categories, need to know) to access that media. Before releasing an information system component containing non-volatile storage media (e.g., tapes, disks, battery-powered random access memory, etc.) to uncleared maintenance activities, sanitize the component of classified and/or sensitive information according to AFSSI 5020.
In those areas, designated in the SSP, where both classified and unclassified information are processed or stored, UNCLASSIFIED media labels (SF 710) shall be used to identify media that contain only unclassified information.
If the software is contained on removable magnetic media, a magnetic media label (sticker) must be placed on the media for identification and protection as required by law. The label reads "This medium is SENSITIVE UNCLASSIFIED U.S. Government Property. Protect it from unauthorized disclosure."
Clear or destroy media used to store sensitive information before release to unauthorized personnel. Follow procedures in AFSSI 5020, Remanence Security (will convert to AFMAN 33-224).
Media Accountability. Media accountability shall be implemented that provides a set of protection mechanisms comparable to those required for equivalent paper documents.
Physical access to sensitive media files or libraries will be restricted to individuals assigned that responsibility. Magnetic media and supporting documentation used to process classified information or other National Defense requirements will be secured in accordance with applicable regulations.
Removable storage media used for classified processing will be protected as classified. Storage media containing Sensitive Unclassified information must be protected to ensure against unauthorized access... All magnetic media which contain classified data will be accounted for by the highest classification of data that they have ever contained in accordance with OPNAVINST 5510.1 (non-SCI), DoD C-5105.21-M-1 (SCI), and local procedures.
Controls will also be established for the clearing, purging, and declassification of information stored on media used for classified processing. The process is described in the National Computer Security Center NCSC-TG-025, A Guide to Understanding Data Remanence in Automated Systems, September 1991. Additional procedures are described in DoD 5200.28-M, ADP Security Manual, January 1973.
...system(s) operating at Protection Level(s) [1-5] shall employ the following features:...Data Storage, implementing at least one of the following:(a) Information stored in an area approved for open storage* of the information.(b) Information stored in an area approved for continuous personnel access control (when continuous personnel access control is in effect), i.e., a 24-hour, 7-day-per-week operational area.(c) Information secured as appropriate for closed storage.(d) Information encrypted using NSA-approved encryption mechanisms appropriate (see paragraph 1.G.1) for the classification of stored data.[*In the context of storage confidentiality, "approved for open storage" must include consideration of the possibility of access by all users who have direct access to the system or network, wherever physically located.]
Information systems using non-volatile, non-removable storage media must meet one of the following conditions:3.5.2.2.1. Install the computer in an area approved for open storage of classified information at or above the highest classification level of the information processed.3.5.2.2.2. Use an NCSC-evaluated, AFCA-assessed, or locally tested and DAA-approved product or technique to prevent storing classified information on non-volatile, non-removable storage media. Ensure product protects against inadvertently writing information to storage media.
Using an AIS with non-removable, non-volatile media for processing classified information is discouraged. Classified information may not be stored on such media except under one of the following conditions:(1) The AIS is housed in an area approved under AR 380
If the conditions of paragraph a (above) are not met and the DAA elects to approve the use of non-removable, non-volatile media on AIS processing classified information, specific countermeasures must be implemented to ensure that classified information is not written on such media. These countermeasures must be identified in the accreditation documentation. Administrative techniques, such as an SOP requiring users to write classified information only to removable media, are not sufficient to meet the requirements of this paragraph, due to the high possibility of user error and the possibility of systems or application software using the non-removable media for its files.
Clearing. Only approved equipment and overwriting software that is compatible with the specific hardware for overwriting shall be used to clear media that have contained classified information. Use of such software shall be coordinated in advance with the DAA. The success of the overwrite procedure shall be verified through random sampling of the overwritten media. Items that have been cleared (i.e., not sanitized) shall remain at the previous level of classification and remain in a secure, controlled environment.
Overwriting is a software process that replaces the data previously stored on magnetic storage media with a predetermined set of meaningless data. Overwriting is an acceptable method for clearing....To clear magnetic disks, overwrite all locations three times (the first time with a random character, the second time with a specified character, and the third time with the complement of that specified character).
Sanitizing Media. Sanitization removes information from media or equipment so that data recovery using any known technique or analysis is prevented. Sanitizing is a two-step process that includes removing data from the media by effectively degaussing the media and removing all sensitivity labels, markings, and activity logs. After magnetic media are properly degaussed in accordance with NSA/CSSM 130-2, and all identifying labels removed, they are considered to be sanitized.
(a) Magnetic media containing classified information can be sanitized by use of an approved degaussing procedure. The DAA, with the Data Owner's approval (if applicable), can allow overwriting of some types of classified information as a sanitizing procedure.(b) Media that have ever contained Sensitive Compartmented Information, other intelligence information, TOP SECRET SAP information, or Restricted Data cannot be sanitized by overwriting; such media shall be degaussed before release. Media that has ever contained COMSEC material cannot be sanitized at all; it shall be destroyed before release.
Destroying Media. Data storage media will be destroyed in accordance with PAA-approved methods.
Optical Disks. Optical disks (including compact disk/read only memory, write once/read many, Digital Versatile Disk, and writable compact discs) offer no mechanism for sanitization and must be destroyed via incineration or any other NSA-approved method. They should be placed in a classified trash bag labeled "non-soluble" and disposed as classified waste.
Malfunctioning Media. Magnetic storage media that malfunctions or contains features that inhibit overwriting or degaussing shall be reported to the ISSO, who will coordinate repair or destruction with the responsible DAA.
Before the release of any components or boards from an area used to process or store classified information, whether because they are malfunctioning or because they are no longer needed, the requirements of subsections (2) and (3), below, shall be met. This section applies only to components identified by the vendor or other technically-knowledgeable individual as having the capability of retaining user-addressable data and does not apply to other items (e.g., cabinets, covers, electrical components not associated with data), which may be released without reservation. For the purposes of this document, a memory component is the Lowest Replaceable Unit (LRU) in a hardware device. Memory components reside on boards, modules, and sub-assemblies. A board can be a module, or may consist of several modules and sub-assemblies. Unlike magnetic media sanitization, clearing may be an acceptable method of sanitizing components for release (see NSA/CSSM 130-2). Memory components are specifically handled as either volatile or nonvolatile, as described below.
Volatile Memory Components. Memory components that do not retain data after removal of all electrical power sources, and when re-inserted into a similarly configured system do not contain residual data, are considered volatile memory components. Volatile components that have contained classified information may be released only in accordance with procedures developed by the ISSO and stated in the SSP. A record shall be maintained of the equipment release indicating that, per a best engineering assessment, all component memory is volatile and that no data remains in or on the component when power is removed.
Non-volatile Memory Components. Components that do retain data when all power sources are discontinued are non-volatile memory components; these include read-only memory (ROM), programmable ROM (PROM), or erasable PROM (EPROM), and their variants. Those that have been programmed at the vendor's commercial manufacturing facility, and are considered to be unalterable in the field, may be released. All other non-volatile components may be released after successful completion of the procedures outlined in NSA/CSSM 130-2. Failure to accomplish these procedures shall require the ISSO to coordinate with the DAA for a determination of releasability
Release of Systems and Components. The ISSO shall develop equipment removal procedures for systems and components that have processed or contained classified or extremely sensitive information; these procedures shall be stated in the SSP. When such equipment is no longer needed, it can be released after:(1) Inspection of the system equipment by the ISSO or designee. This review shall assure that all media, including internal disks, have been removed or sanitized.(2) Creation of a record of the equipment release indicating the procedure used for sanitization, and to whom the equipment was released. This record shall be retained for a period prescribed by the DAA.(3) Using procedures specified by the DAA, notification to the DAA of the release of the equipment.
DAA approval is necessary to co-locate classified and unclassified ISs in a Sensitive Compartmented Information Facility (SCIF). The following conditions shall be adhered to:(1) An IS approved for processing unclassified information must be clearly marked as such when located within a SCIF.(2) An IS approved for processing unclassified information must be physically separated from any classified IS.(3) An IS approved for processing unclassified information must not be connected to any classified IS without the PAA's written approval.(4) Users must be provided with co-location process and procedures as part of their required security and awareness training.(5) The ISSO must document in the SSP the procedures and technical safeguards to ensure the protection of classified information.(6) All unmarked media must be treated as classified at the highest level processed by the facility until reviewed and verified.
Media Clearing and Sanitization. Storage media shall be physically controlled and safeguarded in the manner prescribed for the most-sensitive designation, or highest classification level, and category of data ever recorded on it until destroyed or sanitized using approved procedures. The SSP shall specify the approved release procedure for the media of a given system. Procedures to be used for the sanitization, declassification, and reuse of storage media are described below:
Procedures must be established for the physical and administrative control of vendor and custom developed applications under the cognizance of the local site.
Classified media, products, etc, must not be given to vendor maintenance personnel for testing or use.
Appendix F of this document contains guidance in declassifying, releasing, and shipping of media containing sensitive compartmented information...Storage media containing Sensitive Compartmented Information (SCI) will be handled as stated in appendix F of this document... Appendix F of this document provides additional information concerning fixed storage media containing sensitive compartmented information.
To prevent unauthorized modification, software providing internal security controls which identify and separate users and data must be protected commensurate with the highest sensitivity level of the information processed.
Media will be declassified or destroyed in accordance with CSC-STD-005-85 "DoD Magnetic Remanence Security Guideline." Classified information handling procedures are contained in Appendix C.
Clearing of media means erasing or overwriting all information on the media without the totality and finality of purging. The clearing procedure is adequate when the media will remain within the facility; however, removable media must continue to be con-trolled at their prior classification or sensitivity level. Purging or sanitizing of media means to erase or overwrite, totally and unequivocally, all information stored on the media. Declassifying of media refers to the administrative action taken after it has been purged. Declassifying is required when the media must leave the facility under the control of uncleared personnel; for example, for maintenance operations.
When disposing of or declassifying media, ensure that special procedures as they relate to the specific media involved are followed, i.e., degaussing magnetic media, overwriting mass storage media, burning or shredding of floppy disks, replacement and destruction of monitors with classified information burned into the screen.
The decision to declassify media will be made only after comparing the inherent risks (in the Magnetic Media Remanence Guide - Rainbow Series) with the financial or operational benefit of media declassification. For example, destruction of media is normally more appropriate than declassification and reuse, given the low cost of the media. Media can be declassified only after purging. The appropriate ISSO must verify that the technique chosen for purging (or sanitizing) meets applicable requirements. Additionally, the ISSO must establish a method to periodically verify the results of the purging. As a minimum, a random sampling will be taken to verify each purge.
Degaussing must be accomplished using NSA-approved equipment from the Degausser Products List of the Information Systems Security Products and Services Catalogue. Information on degaussers is available through the information systems security management structure. Some listed products may be used only to degauss magnetic media that has coercivity no greater than 350 oersteds (also known as type I media), while others are approved for media with coercivity no greater than 750 oersteds (also known as type II media). Certain tape media have a coercivity greater than 750 oersteds (also known as type III media) and cannot, at this time, be completely degaussed. (See app F for more information.)
Due to the large variety of ribbons and printers in use, it is difficult to state with certainty that any and all classified information has been totally obscured from a given ribbon without a detailed examination of that ribbon. a. Printer ribbons should be controlled at the highest level of information ever printed by that ribbon until that ribbon is destroyed. b. The same ribbon should be retained in the printer for unclassified and classified information consistent with the levels of physical security enforced for the work area. c. Laser technology printers used for both unclassified and classified printing can be sanitized by simply printing three blank pages after the last classified page has printed. However, laser printer parts, (i.e., cartridges, drums, and belts, etc.), regardless of classified or unclassified processing, must be disposed of IAW classified destruction procedures. This will ensure that any residue left from previous classified printing will not be compromised.
Establish provisions for emergency destruction of ADP media or resident data.
AR 380
All toner cartridge assemblies used in laser printers that are connected to a collateral classified AIS will be considered to be unclassified after three blank pages have been printed. Cartridge assemblies used in printers connected to an AIS that processes SAP or SCI must be controlled per NSA policies as defined in National Security Telecommunications and Information Systems Security Agency [sic] Manual (NSTISSAM) COMPUSEC/2
3.10 CONTINGENCY PLANS
Contingency plans shall be developed and tested in accordance with OMB Circular No. A-130... to ensure that AIS security controls function reliably and, if not, that adequate backup functions are in place to ensure that security functions are maintained continuously during interrupted service. If data is modified or destroyed, procedures must be in place to recover.
The following assurances shall be provided for a system operating at a Medium [or] High Level-of-Concern for Availability:.Contingency Planning that includes a Contingency/Disaster Recovery Plan.
Plans will be established to ensure the continuity of information processing support in the event of a disruption of service. Contingency plans will be developed and periodically tested IAW authority document OMB Circular A-130 to ensure that the information systems security controls function reliably and can be maintained continuously during interrupted service. Procedures must be in place for recovery if data is modified or destroyed.
Computer facility managers must ensure that sufficient copies of files, documentation, and other supporting material essential to recovery and continued processing of mission essential applications are secured in a readily available location. Conversely, end users should also maintain emergency plans to allow essential functions to continue in the event their automated support becomes unavailable due to any unforeseen circumstances. Detailed information and procedures are contained in IRM-5239-09, "CONTINGENCY PLANNING" and IRM-5239-16, "LOCAL AREA NETWORKS DISASTER PLANNING." (under development)
The following assurances shall be provided for a system operating at a High Level-of-Concern for Availability:Contingency Planning, including: (a) Adequate hardware, firmware, software, power, and cooling to accomplish the mission when the operational equipment is unavailable. Consideration shall be given to fault-tolerant or "hot-backup" operations. The decision whether or not to use these techniques shall be explicit.(b) Regular exercising and testing of the contingency plans. The plans for the tests shall be documented in the Contingency/Disaster Recovery Plan.
The [contingency] plans shall be tested periodically under realistic operational conditions.
For Major Applications, establish and periodically test the capability to perform the function supported by the application in the event of an application or system failure. For General Support Systems, periodic testing should occur to ensure that service provided by the system can be continued based upon the needs and priorities of the participants of the system.
[Rules of the system prepared in accordance with OMB A-130, App. III, A.3.a.2)a)] shall define service provision and restoration priorities.
3.11 INCIDENT RESPONSE CAPABILITY
Ensure that there is a capability to provide help to users when a security incident occurs in the system and to share information concerning common vulnerabilities and threats.
The PAA shall ensure the establishment of an information systems security incident response and reporting capability that detects incidents, establishes a trained response element, maintains statistics, initiates an investigation, and recovers operational capability for the information.
Report information system vulnerabilities, security incidents, and virus attacks according to AFSSI 5021.
The following guidance is provided for reporting actual or suspected computer security violations, (i.e. compromise of systems or data as a result of espionage, sabotage, fraud, misappropriation, misuse) and viruses: a. Marine Corps personnel will immediately report through their organizational chain any indication of computer security violations or viruses to the computer systems security officer or the security manager for the local command.
Any AIS security incidents will be investigated to determine their cause and the cost effective actions required to prevent reoccurrence.
A formal incident-reporting program shall be put in place, and it shall be evaluated on a regular basis by the DAA. All security incidents shall be reported to the DAA and the Data Owner through the incident-reporting system. All incidents that may affect (or have affected) systems under more than one DAA shall be reported to the DAA responsible for the affected system. As appropriate, the information shall be forwarded to other involved DAAs and Data Owners. Additionally, organizational investigative agencies shall be immediately apprised of all security incidents and, if deemed necessary and appropriate, shall participate in their resolution.
Commands will report by naval message or E-Mail within 24 hours to CMC (Code CSBT) any occurrence where preliminary investigations confirm a possible security violation or virus attack. The message must include a point of contact with knowledge of the violation being reported.
This (incident response) capability shall share information with other organizations, consistent with NIST coordination, and should assist the agency in pursuing appropriate legal action, consistent with Department of Justice guidance.
ISSMs will....Report security incidents and technical vulnerabilities per this regulation, AR 381
Appropriate authorities, as defined in the Manual, shall be immediately notified of any threats or vulnerabilities impacting systems that process their data.
Procedures will be established to ensure the reporting of security violations as required by DISAI 240-110-8, Information Security Program (reference 4b). Security incidents, whether caused by computer viruses, hackers, or software bugs will be considered in the development of these procedures and will be reported to the local information system security officials and to the DISA Automated Systems Security Incident Support Team (ASSIST) Branch. ASSIST can be reached via e-mail at assist@assist.mil. Procedures will be developed for the reporting of security incidents for non-sensitive systems.
Local commands should determine if Naval Criminal Investigative Service (NCIS) involvement in computer security violations is warranted. CMC (Code CSBT) will notify Naval Electronics Systems Security Engineering Center (NAVELEXSECCEN) if their services are required to support a computer virus problem reported by a command.
This Directive establishes the National Security Information Systems Incident Program to provide a strategy for responding to information systems security incidents and vulnerabilites among national security systems, as defined in National Security Directive 42, dated July 5, 1990....The National Manager...shall oversee the administration of this program.... The administrator of this program shall be responsible to the National Manager for: a. eatablishing and operating a National Security Incident Response Center (NSIRC) to centrally coordinate actions involving security incidents and vulnerabilities that threaten national security systems;....Heads of U.S. Government departments and agencies using national security systems shall: a. establish a security incident response capability (SIRC) to meet the objectives of this program; b. identify to the program administrator an individual to act as their organizations's focal point for this program; ensure the direct reporting of violations of law to the appropriate authority; and d. develop organizational policies, procedures and guidance to implement this program.
Suspected or actual incidents will be reported to the appropriate ISSO, who will notify the ISSM. Concurrently, the operator and ISSM will notify the Army Computer Response Team/ Coordination Center (ACERT) or its subordinate CERT infrastructure and request immediate technical assistance. The LIWA will notify HQ, CID; DISA/automated systems security incident support team (ASSIST); and ACCO INSCOM of actual penetrations of Army AIS.
Responsibilities of the DAA include:.2.B.4.e(13) Reporting security-related events to affected parties (i.e., interconnected systems), Data Owners, and all involved PAAs.
Examples of the types of incidents that will be reported include but are not limited to the following:(1) Known or suspected intrusions or attempted intrusions into classified and unclassified AIS by unauthorized users or by authorized users attempting unauthorized access.(2) Unauthorized access to data, files, or menus by otherwise authorized users.(3) Indications of an unauthorized user attempting to access the AIS, including unexplained attempts to log-on unsuccessfully from a remote terminal.(4) Indications of unexplained modifications of files or unrequested "writes" to media.(5) Unexplained output received at a terminal, such as receipt of unrequested information.(6) Inconsistent or incomplete security markings on output with extraneous data included in the output, or failure to protect the output properly.(7) Abnormal system response.(8) Malicious software.(9) Alerts by network intrusion detection (NID) systems installed to detect "hackers" and other unauthorized personnel attempting system penetration.
A process must be developed to incorporate recommendations to correct technical vulnerabilities that impact the security of an information system. Such recommendations are posted in Automated Systems Security Incident Support Team (ASSIST) Bulletins. The process must cite the bulletin number, the date that the security patch or fix was made, and the name of the individual who performed the correction. Reports or bulletins regarding a technical vulnerability does not necessarily mean that an actual violation or security incident has occurred. However, the potential for exploitation does exist, and the technical vulnerability should be corrected in a timely manner. Procedures must be established to ensure that the ASSIST Bulletin Board or other advisory bulletin boards (i.e., Computer Emergency Response Team [CERT]) are reviewed periodically to gather information on identified technical vulnerabilities.
8. Protection of Vulnerability Reports - a. Vulnerability reports shall be protected from public disclosure in accordance with applicable statures, directives, executive orders, and regulations. b. Vulnerability reports for commercial off-the shelf systems or components...shall be unclassified and marked...FOUO. c. Reports of vulnerabilities in national security systems that are not available for purchase by the general public shall be unclassified unless the exploitation of the vulnerability would result in the compromise of classified information or would present a significant negative impact on a national security organizational mission. In those instances, the originator may place a maximum classification on the vulnerability report equal to the level of the classified information processed on that system.
Procedures shall be developed by the ISSM and approved by the DAA to provide the appropriate responses to incidents.
Dialogue between CMC and the field command will continue until the reported computer security issue is considered under control or resolved... Additional information and guidance pertaining to viruses are contained in IRM-5239-10, "SMALL COMPUTER SYSTEMS SECURITY."
If the cause of the incident can be directly attributed to administrative error and be readily corrected then no further action is required. Otherwise the incident will be reported by the ISSO to the centralized incident reporting activity for the ACERT and to the appropriate ISSM. The initial notification will be within 24 hours and will include a brief statement containing the location affected, system, a description of the suspected or confirmed incident, action taken, and point of contact. The centralized reporting activity will provide further guidance on any reporting requirements.
When the incident is also reportable as a generic technical vulnerability as described above, required reports to Army's centralized reporting activity may be consolidated and will cite both applicable portions of this regulation.
The ISSO or ISSM should also notify the supporting CID and INSCOM offices if an unauthorized person successfully penetrated the AIS. The two commands will coordinate to determine investigative jurisdiction, with CID taking the lead if there are no indications of foreign intelligence service (FIS) involvement. If FIS involvement is suspected or known, INSCOM will initiate a Subversion and Espionage Directed Against the Army (SAEDA) report per AR 381
If CID, INSCOM and the FBI rule out FIS or criminal activity and decline investigative jurisdiction, the reporting command or agency is authorized to initiate a preliminary inquiry per AR 380
Develop criteria to assist users in identifying computer security incidents (e.g., virus contamination, intruder attacks). Guidance should also be developed to allow for the reporting of these incidents and the sharing of information concerning common vulnerabilities and threats. Computer security incidents must be reported to the local site ISSM/ISSO and to the DISA ASSIST at assist@assist.mil.
PAAs shall ensure the establishment of an incident reporting and response capability in the components under their purview. Notification to the PAA shall be made within 24 hours of incidents involving intelligence information which, if compromised, could affect the safety of human life or could cause exceptionally grave damage to the national security. The PAA shall be notified within 4 days after the determination of:(1) The compromise of intelligence information resulting from the failure of systems covered by this manual; or(2) Attempts by hostile elements (e.g., agents of a foreign intelligence service, recruited insiders, hostile outsiders) to penetrate any of these systems; or(3) The discovery of flaws or vulnerabilities that could result in the compromise of intelligence information.
9. Protection of Incident Reports - a. Incident reports shall be protected from public disclosure in accordance with applicable statures, directives, executive orders, and regulations. b. Incident reports shall be unclassified and marked FOUO unless the exploitation of the information in the incident report would result in the compromise of classified information or would present a significant negative impact on a national security organizational mission.
Technical vulnerabilities shall be reported to CMC (Code CSBT) by message or letter and must be classified at the highest classification level of information accessible by the vulnerability, but at least For Official Use only. Since unauthorized access to technical vulnerability information can lead to exploitation of a Marine Corps computer system, release of this information must be based on a validated security clearance and need-to-know. Technical vulnerability information must not be released to foreign nationals.
The ISSOs will review all incident reports and related documentation and, in cooperation with other security and investigative personnel, advise the ISSM and commander or manager having jurisdiction over the possible system penetration or security violation. The ISSM will ensure that all available audit trail information is maintained until the incident is resolved.
In the case of interconnected systems or systems that involve two or more PAAs:(1) Each DAA with responsibility for the affected system shall report all security-relevant events to affected parties, Data Owners, and all involved PAAs.(2) Each system's audit information shall be made available for investigations of security-relevant events.
Reports of technical vulnerabilities should be in sufficient detail so the vulnerability can be demonstrated and repeated. Appendix H contains the format and the categories of information for reporting a technical vulnerability. Compliance with this DoD program does not preclude the responsibility to take any necessary and prudent action to reduce any risk presented by the vulnerability.
All vulnerability reports received by CMC (Code CSBT) will be forwarded to CDA, Quantico to be screened for technical validity and determine the extent of risk presented by the technical vulnerability to other Marine Corps sites.
Within four weeks of receipt of a valid vulnerability, CMC (Code CSBT) will submit the original report to the NCSC with a summary of the reported vulnerability and any analysis of the risk involved. This report will be entered into the NCSC data base and forwarded to the NCSC for analysis and resolution. If the product is on the EPL, NCSC will evaluate the risk and make a specific determination as to whether or not to retain, reduce, or rescind the product from its current trusted system rating. If a product rating is changed, appropriate warnings will be submitted to the DoD focal points (CMC contact is Code CSB) for dissemination. NCSC will report their findings on the technical vulnerability being analyzed to NCSC for reporting back to the originator. A technical vulnerability report with findings and recommended solutions will be submitted by the NCSC to CMC (Code CSBT). CMC will then contact the Marine Corps organization submitting the report with guidance to resolve the vulnerability...
In those cases where AIS security incidents affect the supported user community, the ISSM must formally advise all users of the problem and the action taken or expected. The centralized incident reporting activity for the Army will, through the ISSM or ISSO, as appropriate, provide the user with guidance and instructions received from the CID or CI.
The General Support OPR will: Establish a process to detect, eradicate, and report computer viruses; to identify and handle malicious code; and to describe events or conditions that may result in system penetrations by unauthorized individuals.
This (incident response) capability shall share information with other organizations , consistent with NIST coordination, & should assist the agency in pursuing appropriate legal action, consistent with DOJ guidance.
4.0 PHYSICAL SECURITY
4.1 GENERAL
All AIS hardware, software and documentation, and all classified and sensitive unclassified data handled by the AIS shall be protected to prevent unauthorized (intentional or unintentional) disclosure, destruction or modification (I.e. data integrity shall be maintained). The level of control and protection shall be commensurate with the maximum sensitivity of the information and shall provide the most restrictive control measures required by the data to be handled. Additionally, protection against denial of service of AIS resources (e.g., hardware, software, firmware, and information) shall be consistent with the sensitivity of the information handled by the AIS.
A balanced AIS security program must include a firm physical security foundation with the following objectives: (1) Safeguard personnel. (2) Prevent unauthorized access to equipment, facilities, material, media, and documents. (3) Safeguard against espionage, sabotage, damage, and theft. (4) Reduce the exposure to threats that could cause a denial of service or unauthorized alteration of data...Commanders and managers will protect AIS assets under their control through cost-effective physical security measures.
The number and diversity of Army AIS (fixed and deployable systems) and installations make it impractical to establish universal, rigid physical security standards. However, adequate physical security at each installation is essential to achieving a secured data processing environment. Physical security standards must be based on an analysis of both wartime and peacetime mission criticality, sensitivity levels of the information processed, overall value of the information to the mission of the organization, the local criminal and intelligence threat, and the value of the automated equipment.
Measures must insure external protection against unauthorized access to the main computer location, to the system from remote terminals, and to data storage media.
Protect the information system and data against tampering. Provide protection from outsider threats by controlling physical access to the information system itself.
Physical security will be provided through an in-depth application of barriers and procedures, which may include continuous monitoring (human or electronic) of the protected area. Barriers and procedures include structural standards, key control, lighting, lock application, and inventory and accountability.
Implement normal building and area entry controls (i.e., physical, administrative, and personnel security) at remote terminal sites when host systems have adequate internal access controls. Disable communications lines and take other necessary actions to protect information, systems, and resources when adequate internal controls do not exist.
...system(s) operating at Protection Level(s) [1-5] shall employ the following features: Data Storage, implementing at least one of the following:4.B.1.a(7)(a) Information stored in an area approved for open storage* of the information.4.B.1.a(7)(b) Information stored in an area approved for continuous personnel access control (when continuous personnel access control is in effect), i.e., a 24-hour, 7-day-per-week operational area.4.B.1.a(7)(c) Information secured as appropriate for closed storage.4.B.1.a(7)(d) Information encrypted using NSA-approved encryption mechanisms appropriate (see paragraph 1.G.1) for the classification of stored data.[*In the context of storage confidentiality, "approved for open storage" must include consideration of the possibility of access by all users who have direct access to the system or network, wherever physically located.]
Physical Security Controls. Controls will be implemented to adequately protect facilities, personnel, equipment, and sensitive information. Minimum physical security requirements may be obtained from CISS.
Physically protect each network node to a level adequate for protecting the most restricted information accessible at the node.
Physical security is provided through an in-depth application of barriers and procedures, including continual surveillance (human or electronic) of the protected area. Barriers and procedures include structural standards, key control, lighting, lock application, and inventory and accountability. Physical access controls, commensurate with the level of processing, will be established to deter unauthorized entry into the computer facility and other critical areas which support or affect the overall operation.
4.2 FACILITIES
All systems shall comply with the applicable standards for physical protection of the data processed, stored, or transported therein. For facilities housing ISs processing Sensitive Compartmented Information (SCI), the applicable standard is DCID 1/21, Physical Security Standards for Sensitive Compartmented Information Facilities (SCIF). Unencrypted SCI shall be processed only in a SCIF.
Where the facility (building and room) plays a major role in providing security for information systems, establish procedures to notify IA personnel of impending changes to the facility.
All operations within a controlled zone environment will be safeguarded and classified to the highest level of processing in accordance with applicable regulations or directives. This includes personnel, access lists, documentation, storage, equipment, and processing.
Facilities that house systems, computer rooms, network components (for example, routers or file servers), and related sensitive areas may be designated as restricted areas or mission essential vulnerable areas under AR 190
....A Temporary SCIF (TSCIF), set up and formally accredited as specified in the DCID 1/21, is an approved SCIF that may be used to process intelligence information for a limited time period.
The effects of disasters such as fire and floods will be prevented, controlled, or minimized to the extent economically feasible by the use of detection equipment, fire extinguishing systems, and tested emergency measures.
Physical access controls commensurate with the level of processing will be established to deter unauthorized entry into the facility and other critical areas (such as input or output area, programming, data preparation, and storage) that support or affect the overall operation.
Facilities selected or designed to house computer equipment will be of sufficient structuralintegrity to provide, or will be capable of being made to provide, effective physical security at a reasonable cost.
Facilities housing AIS equipment will be of sufficient structural integrity to provide effective physical security at a reasonable cost. Trained physical security specialists will be consulted in all phases of selection, design, and modification of such facilities to provide expertise in physical security requirements.
Facilities that house systems processing SCI material will be subject to the provisions in DCID 1/21.
4.3 INFORMATION SYSTEMS AND EQUIPMENT
The safeguarding of all documentation supporting mission critical applications and systems programs and their interaction is vital to effective security. Protection should be extended to all documentation revealing the logic, methodology, or instructions for system use. This includes, but is not limited to the following: a. Software development documents (such as, system and logic diagrams, decision tables, program code, test data, data editing, error detection, test, and verification). b. Debug routines and output (such as, core dumps, memory snapshots, trace routines), and vendor software instructions for loading and executing programs. c. Documentation pertaining to software, system errors, or flaws (such as, security violation reports, generic system flaws, justifications for software or modification, or other software maintenance requirements).
Unclassified hardware, software or documentation of an AIS shall be protected if access to such hardware, software , or documentation reveals classified information, or access provides information that may be used to eliminate, circumvent or otherwise render ineffective the security safeguards for classified information.
A system operating at the Medium [or] High Level-of-Concern for Availability shall implement the following features:.... System Availability, including, by default for a multi-user system, conditioned, battery-backed power adequate to allow the system to be fail-soft. If the system is multi-user, the decision not to use an Uninterruptible Power Supply (UPS) for the system shall be explicit.
Information systems using non-volatile, non-removable storage media must meet one of the following conditions:3.5.2.2.1. Install the computer in an area approved for open storage of classified information at or above the highest classification level of the information processed.3.5.2.2.2. Use an NCSC-evaluated, AFCA-assessed, or locally tested and DAA-approved product or technique to prevent storing classified information on non-volatile, non-removable storage media. Ensure product protects against inadvertently writing information to storage media.
Particular attention must be paid to the physical security of AIS that are not operated or otherwise attended continuously. An AIS that processes classified defense information must be properly declassified prior to being left unattended, unless it is secured in areas or containers approved for storage of classified material under AR 380
Software development and related activities (e.g. systems analysis) shall be controlled by physical controls (e.g. two person control) and protected when it is determined that the software shall be used for handling classified or sensitive unclassified data.
Software development and related activities (for example, systems analysis) will incorporate appropriate security measures.
Systems containing integral hard disks should not be used to process classified information. However, if no alternative exists, the system must be protected and physically secured at all times at the level afforded the highest classification of data ever processed on the system (See paragraph 4 below for procedures). These systems will be declassified or downgraded and will be handled in accordance with CSC-STD-005-85, DOD Magnetic Remanence Guideline.
the following are recommended procedures for classified processing on systems with non-removable hard disks. If the DAA accepts the risks and approves these procedures, he (DAA) may waive the requirement to classify the non-removable hard disk after classified processing. Implementation of these procedures should be in writing and the limits and sensitivity of information to be processed should be specified: [See IRM-5239-08A, App. C, 5]
A system operating at the Medium [or] High Level-of-Concern for Availability shall implement the following features:.... System Availability, including procedures for graceful transfer of the system to an alternate power source; these procedures shall ensure that the transfer is completed within the timing requirements of the application(s) on the system.
Current policy does not prohibit the use of computers with non-removable hard disk drives when processing classified information. However, certain criteria must be met and adhered to when doing so: a. If the facility is approved for open storage of classified information, there are no special requirements. b. If the facility is not approved for open storage of classified information, one of two procedures must be followed. (1) The system must be secured in a safe or vault whenever not attended by cleared, authorized persons. (2) A review of the hard disk directory must be accomplished prior to classified processing and again after the classified processing is completed. c. If the option in paragraph 4.b.2 is implemented, the DAA must waive the requirement to classify the system and accept any residual risk that classified data might have been transferred onto the hard disk.
Many AIS, including some file servers, clearly do not warrant the physical protection detailed in paragraphs 2
Physical security requirements must be considered and selected based on the sensitivity and classification of data being protected, as well as assessed risk to the information and the risk of equipment theft. The physical security requirements must be examined to ensure protection of equipment is cost effective, that the impact on objectives is negligible, and that the level of risk is acceptable to the local commander.
All AIS must be protected, and physical security requirements must be carefully selected. (1) An AIS with non-removable media that processes classified information must be stored in an area or a container approved for safeguarding classified media per AR 380
All fixed media systems processing SCI data must be stored in a GSA-approved container, or the SCIF must have authority for open storage of SCI material. If such authority is not granted in the facility accreditation, permission will be requested through command channels to HQDA (ODCSINT).
Any parts removed from an AIS operating in a sensitive compartmented information facility (SCIF) will be retained in the facility until approved for release by the local special security officer (SSO) in coordination with the ISSM or ISSO per AR 380
Remote terminal devices must be secured consistent with the mode of operation and information that the remote terminal is authorized to access...Physical safeguards will be implemented to ensure that only authorized persons use remote terminal equipment and that only authorized persons receive and remove sensitive information from the remote access areas. During periods when effective monitoring cannot be maintained, the doors to these terminal areas will be locked or the terminals otherwise secured, to prevent loss, damage, or unauthorized access.
4.3.1 REMOTE TERMINALS OR WORKSTATIONS AND PCs
The introduction and use of large-scale, remotely accessed computer systems and networks require that all terminal connecting equipment be protected according to the data sensitivity level to prevent unauthorized (intentional or unintentional) disclosure, destruction, or modification. Additionally, MCO P5510.14 requires any organization that is connected by a remote terminal device to a main or host computer be responsible for the appointment of a Terminal Area Security Officer (TASO).
Remote terminal devices must be secured during and after normal operational hours consistent with the mode of operation and level of information which the remote terminal is authorized to access. Safeguards will be implemented to ensure that only authorized persons use remote terminal equipment capable of accessing sensitive computer systems. Caution will also be used to ensure that sensitive hard copy output is received and removed from the terminal area only by authorized persons. After normal business hours or during periods when effective monitoring cannot be maintained, all physical access to the area will be secured. Remote terminals will be disabled from the system at the host or remote concentrator during non-duty hours. If this disabling is via a logical disconnect, then a periodic check should be made by the system to verify that the disconnect is still valid. For information and guidance concerning access to Marine Corps systems connected by the Marine Corps Data Network (MCDN), refer to IRM-5239-06, "DATA ACCESS SECURITY."
Because of the increased vulnerability inherent in acoustically-coupled terminals, their use in accessing sensitive systems should be minimized and where practical prohibited (non-acoustically coupled devices are currently considered the industry standard). If such devices are used to access commercial time-sharing services, they should be located in an area that can be secured after normal business hours. If this is not possible, other measures such as use of a telephone lock or removal of the acoustic coupler should be considered.
Physical security reviews of computer facilities and supporting areas designated to process sensitive information will be conducted annually as part of the facility risk management program. Specific items for consideration should include adequacy of physical barriers, access and egress controls, and the use of guard personnel from the first barrier (wall) surrounding the computer system outward. The review will also provide an assessment of the overall posture, such as breaches of physical security, bomb threats, fire, and natural disasters. Physical security inspectors will not inspect internal operating procedures and computer system security.
4.4 MARKINGS
Classified and sensitive unclassified output shall be marked to accurately reflect the sensitivity of the information. Requirements for security classification and applicable markings for classified information are set forth in DoD 5200.1-R.
Safeguard, mark, and label output products and removable media according to DoDD 5200.1, DoD Information Security Program, December 13, 1996; and AFI 31-401, Information Security Program Management.
Markings on classified or SBU output will reflect the sensitivity of the information as required by existing directives. Army Regulation (AR) 380
A system operating at Protection Level 3 shall employ the following features:Marking procedures and mechanisms to ensure that either the user or the system itself marks all data transmitted or stored by the system to reflect the sensitivity of the data (i.e., classification level, classification category, and handling caveats). Markings shall be retained with the data.
A system operating at Protection Level(s) [4-5] shall employ the following features:.Labeling procedures, including internal and external labeling such as label integrity, exportation, subject-sensitivity labels, and device labels, as applicable.
Automated or manual procedures will be developed to mark or accurately reflect the sensitivity or classification of the information being processed. Automated markings of output cannot be relied on to be accurate unless the security features and assurances of the information system meet the requirements for a minimum security class of B1, as specified in DoD 5200.28-STD, Department of Defense Trusted Computer System Evaluation Criteria, December 1985. If class B1 is not met, but automated controls are used, all output shall be protected at the highest classification level of information handled by the information systems until manually reviewed by authorized personnel to ensure that the automated markings are accurate.
All information systems that process classified information will be marked with the highest classification level of information being processed and stored. The equipment must be marked so that it can be easily read from a minimum distance of 10 feet. Some examples of marking methods are tags or classified document cover sheets. Systems that process both classified and unclassified information must have their equipment clearly marked according to the level of information being processed or stored, to include unclassified information.
Provide internal markings on files to indicate the information sensitivity level and any special handling instructions, where practical.
Hardcopy reports or printouts from a line printer, terminal, plotter, or other computer-based system will be marked as follows: a. Reports prepared during classified processing will be marked at the top and bottom of each page with the appropriate classification or the word "UNCLASSIFIED."b. Page numbering and binding of classified reports are to be used when possible. Forewords, prefaces, or special instructions may be bound as a computer report, but will be in a separately numbered section or distinguished by Roman numeral page numbers to avoid renumbering of machine numbered pages. c. Computer output microfilm/microfiche will be machine marked the same as described for hard copy reports.d. All classified monitors (CRT displays) will have the appropriate security classification markings displayed at the top of the screen. Hard copy reports generated from such a device will be marked as cited above.
Appropriate markings will be applied manually or through an automated means (that is, the AIS has a feature that produces the markings). Automated markings on classified output must not be relied on for accuracy unless the security features and assurances of the AIS meet the requirements for a minimum trusted computing base class of B1 as specified in DOD 5200.28
The marking [of classified and sensitive output] may be automated...or may be done manually. Automated markings on output must not be relied on to be accurate, unless the security features and assurances of the AIS meet the requirements for a minimum security class B1 as specified in DoD 5200.28-STD. If B1 is not met, but automated controls are used, all output shall be protected at the highest classification level of the information handled by the AIS until manually reviewed by an authorized person to ensure that the output was marked accurately with the classification and caveats.
Machine-mark and protect classified information according to its classification.
All media will be marked and protected commensurate with the requirements for the highest security classification level and the most restrictive category of information ever stored on the media until the media is declassified or destroyed under this regulation or until the information is declassified or downgraded under AR 380
Personnel will mark and label all media that are not integral parts of the AIS according to the highest accreditation level of the system in which they were operated in accordance with AR 380
Personnel will use Standard Form (SF) 706 (Top Secret), SF 707 (Secret), or SF 708 (Confidential) to mark non-paper collateral classified media. Personnel will affix two labels to SCI media, SF 712 (Classified SCI), and a completed SF 711 (Date Descriptor). The SF 711 will indicate the security classification of the data. The SF 712 is provided by the Defense Intelligence Agency, Application Division, Bolling Air Force Base, Washington, DC.
Personnel will use the label SF 710 (Unclassified) to label unclassified media that contain data representatives that cannot be read by the human eye when media are stored, transmitted, or otherwise intermingled with classified media.
Personnel will mark and label all compact disks (CDs) for AIS according to the highest classification level of the system in which they were operated. Personnel will mark the non-readable side of the CD with permanent ink to the case and the accreditation level of the system in which it was operated.
All media (and containers) shall be marked and protected commensurate with the requirements for the highest security classification level and most restrictive category of the information ever stored until the media are declassified (e.g. degaussed or erased) using a DoD approved methodology set forth in the DoD AISA Security Manual, DoD 5200.M..., or unless the information is declassified or downgraded in accordance with reference (b) [ DoD 5200.1-R].
When a standard computer configuration (system unit, monitor, keyboard, and printer), or peripheral devices cabled to the system unit, have been formally accredited, or have received the DAA's interim authority to process classified information (to include a formal TCR), a system accreditation label (sticker) that specifies the highest level of system sensitivity will be placed on each device in a conspicuous place. The rectangular block on the label will reference the DAA's accreditation or interim authority to operate. System accreditation labels are available through normal Marine Corps supply channels. Stock numbers for ordering accreditation labels are contained in Appendix C.
Removable information storage media shall bear external labels indicating the security classification of the information and applicable associated security markings, such as handling caveats and dissemination control labels. SSPs shall identify the removable storage media to be used with a system. Classified removable media shall be controlled and protected in a manner similar to that used for classified paper materials. Removable media shall be marked as classified if the media has ever been used on the classified system, AND during any use on the system, was writable (i.e., the write-protect feature could not be verified).
In those areas, designated in the SSP, where classified information is processed, unmarked media that are not in factory-sealed packages shall be protected at the highest level of classification processed within the facility, until the media has been reviewed and appropriately labeled.
In those areas, designated in the SSP, where both classified and unclassified information are processed or stored, UNCLASSIFIED media labels (SF 710) shall be used to identify media that contain only unclassified information.
Non-removable information storage media shall bear external labels indicating the security classification of the information and applicable associated security markings, such as handling caveats and dissemination control labels. If it is difficult to mark the non-removable media itself, the labels described below may be placed in a readily visible position on the cabinet enclosing the media.
For a system operating at Protection Level 1, 2, or 3, storage media shall bear external labels indicating the highest classification level and applicable associated security markings of information ever processed on the system, unless a reliable human review of the media's entire contents is performed.
For a system operating at Protection Level 4 or 5, storage media shall be labeled with the classification level and applicable associated security markings of information on the media.
Marking Hardware Components. Procedures identified in the SSP shall be implemented to ensure that all components of an IS, including input/output devices that have the potential for retaining information,* terminals, standalone microprocessors, and word processors used as terminals, bear a conspicuous, external label stating the highest classification level and most restrictive classification category of the information accessible to the component in the IS. This labeling may consist of permanent markings on the component or a sign placed on the terminal.[*For example, mice and trackballs do not normally retain information.]
Marking Human-Readable Output. Human-readable output shall be marked appropriately, on each human-readable page, screen, or equivalent (e.g., the proper classification must appear on each classified microfiche and on each page of text on the fiche).
Adding a Banner Page. Except as provided by the DAA, the first page of the output (the banner page) shall include a warning message reminding the person receiving the output to control every page according to the markings on the banner page until a reliable human review has determined that the output is marked appropriately. If the capability to provide automatic banner pages does not exist, procedures shall be developed to mark manually or otherwise assure review of printed output, as appropriate.
Using procedures approved by the Data Owner or responsible official, explicit approval shall be obtained from the DAA or his designee before forwarding output, which has not had a reliable human review for appropriate security classification and marking, to recipients who do not have system access. Such approval(s) can be for a specific release, for the overall release procedure(s), or for both.
Marking Printed Output. Individual pages of output shall be marked as appropriate either (a) to reflect the classification and applicable associated security markings of the data that is printed on each page, or (b) with the highest classification and all applicable associated security markings of the data that is to be printed.
Marking Output From Shared Printers(a) At the DAA's discretion, systems operating at Protection Level 1, 2, or 3 shall mark the beginning (banner) page of all human-readable, paged, hardcopy output (printer output) with a human-readable representation of the system's security parameter, which is the highest classification and all appropriate associated security markings of the information processed by the system. For Protection Level 3, procedures shall be implemented to ensure output is given only to authorized users.(b) For systems that operate at Protection Level 4 or 5, the banner page of output shall be marked with the appropriate level of classification contained in the document produced.
Variations. DAAs or their designees may identify specific types of media or hardware components that need not be marked in accordance with this policy so long as they remain within a single, secure environment, and:(1) All systems are operating at the same classification level and access authorizations;(2) The media or hardware components are documented in the SSP;(3) Mechanisms or procedures have been established to provide the security protection intended by this policy; and(4) If removed from the single, secure environment, the media are either appropriately marked or sanitized or declassified in accordance with paragraph 8.B.5, below.
Removable system media shall be externally marked with the established classification label (or a facsimile of it), specified in Table 8-1 and published by the Information Security Oversight Office (ISOO).
Security labels shall be conspicuously placed on media; however, their placement must not adversely affect the operation of the equipment on which the media is used. A security label may be placed on the protective cover rather than on the media only if labeling the media would impair operation or if the media is too small to accommodate a label. The intent of marking is to provide a visible indicator of content to support proper handling and storage of the media.
The security marking does not replace internal classification control detail. DAAs or their designees shall approve any other identifying marking (e.g., library retrieval number/locator) to be placed externally on the media.
The downgrading or declassification instructions applicable to the data contained on the portable system media shall accompany the data when it is transferred from one security control point to another. These instructions may be internal to the media.
Manual Review of Human-Readable Output. Before human-readable output is released outside the security boundary, an appropriately authorized individual shall provide a reliable human review of the output to determine whether it is accurately marked with the appropriate classification and applicable associated security markings. The authorized reviewer shall be knowledgeable enough about the data to determine the presence of improper data in the information being reviewed, and shall be cleared for and have formal access approval for he information being reviewed. The review shall be at a level of detail, as set forth by the DAA, to allow the reviewer to accept security responsibility for releasing the data to its recipient.
The electronic output (i.e., softcopy) to be released outside the security boundary shall be verified by a review (in human-readable form) of all data including embedded text (e.g., headers and footers, hidden text, notes, edited text, control characters) before being released.
Information on media that is not in human-readable form (e.g., embedded graphics, sound, video, imagery) shall be examined for content with the appropriate software, hardware, and firmware. Care is required to ensure that all layers or levels of the graphics or image are reviewed.
Random or representative sampling techniques may be used to verify the proper marking of large volumes of output. If available, automated techniques approved by the DAA may be used to verify the proper output marking of data.
5.0 PERSONNEL SECURITY
5.1 CLEARANCES
Personnel who require access to AIS processing classified defense information to fulfill their duties will possess a security clearance based on the appropriate personnel security investigation as delineated in AR 380
Unless multi-level security (i.e., criteria class B) is implemented according to DoD 5200.28-STD, ensure all personnel authorized to use the information system are cleared to the highest level and most restricted category of information contained in the information system.
Screen individuals who are authorized to bypass significant technical and operational security controls of the system commensurate with the risk and magnitude of the harm they could cause. Such screening shall occur prior to an individual being authorized to bypass controls and periodically thereafter.
Personnel Security. Every user who has access to a system processing SCI (including remote components) must be cleared and indoctrinated for SCI in accordance with DCID 1/14, Personnel Security Standards and Procedures Governing Eligibility for Access to Sensitive Compartmented Information.
Computer facility managers will ensure that sensitive positions under their jurisdiction are formally identified and designated as sensitive. For all computer facilities (design and operation) assigned the responsibility of processing Classified data or Sensitive Unclassified data, the following positions (as a minimum) will be designated as sensitive: (1) Facility director. (2) CSSO. (3) System programmers. (4) Computer operators. (5) System analyst/Functional manager liaison. c. In addition to the above positions, other positions may be designated sensitive depending on their purpose and function to the organization. An application programmer position, for example, is not necessarily a sensitive position. However, if the incumbent is involved with programs which process classified data, privacy data, financial data, etc., or has access to such programs, then the position should be designated sensitive. As the level of sensitivity decreases, it can be expected that the percentage of positions designated sensitive should also decrease.
Access control procedures will ensure that access permissions can be justified for personnel who satisfy one or all the following criteria: a successfully adjudicated security clearance or level of security investigation appropriate for either access to classified or sensitive but unclassified information, formal access approval from the OPR of the respective Major Application, need-to-know approval from supervisor of the user, or as a result of being assigned to an appropriate ADP sensitivity designation (i.e., ADP-I, ADP-II, or ADP-III).
Information System Security Officials and System Administrator positions will be designated as ADP-I and investigated according to the requirements described in DoD 5200.2-R, Personnel Security Program, January 1987.
All personnel, whether military or civilian, will be subjected to a National Agency Check (NAC) as a part of their entry screening.
....Because of the potential for damage to the national security interests of the United States inherent in the depth and sensitivity of access to intelligence programs by privileged users, agencies and organizations must provide strong security measures for such users. These measures must ensure that privileged users have no serious unresolved personnel security or counterintelligence issues prior to obtaining such access, and they must identify and resolve such issues as long as a person remains a privileged user.
Controls will be established to screen personnel who have access to an information system or to its information. Guidance regarding personnel security investigations can be found in DISAI 240-25-6, DISA Personnel Security Program, 24 January 1983. Individuals occupying information system processing positions will be designated as ADP-I, ADP-II, or ADP-III. Individuals with the capability to bypass security as part of their interaction with an information system, such as the ISSO or System Administer, will be designated as ADP-I and be investigated accordingly.
All positions will be designated as Critical-Sensitive for ADP-I, Non-Critical Sensitive for ADP II, and Non-Sensitive for ADP III per AR 380
A favorable NAC and a satisfactory review of an individual's service or employment record, including an acceptable performance record, should provide the local commander a basis for authorizing a responsible individual access not only to Sensitive Unclassified information (if the duties so require), but also classified information at the SECRET level. ADP installation managers may utilize the NAC plus the initial screening and evaluation interview as a basis for the granting of Interim SECRET clearances. This will allow personnel to access computer systems engaged in the processing of general business applications classified no higher than SECRET.
Civilian, military, consultant, and contractor personnel meeting the requirements of an automated data processing (ADP) I, II, or III position (see AR 380
Commanders or supervisors who become aware of adverse information, either through the formal security investigation or through other official sources, will follow the procedures in chapter 8 of AR 380
Additional responsibilities for personnel managing, supervising, and performing ADP I, II, and III duties are found in AR 380
The Personnel Security Program should incorporate controls such as separation of duties, least privilege, and individual accountability into the application, as appropriate. In cases where such controls cannot adequately protect the application and information, position sensitivity must be designated to determine the level of background investigation that is commensurate with the risk and magnitude of the harm they could cause. The Functional Application OPR or General Support System OPR should designate ADP sensitivity of positions for individuals who are authorized to bypass technical and operational security controls of the system (e.g., LAN administrators or system programmers). Such screening should be done prior to the individuals being authorized to access the application and periodically thereafter.
Computer systems which process or store TOP SECRET data will be accessed only by persons holding TOP SECRET clearances resulting from the conduct of a favorable Background Investigation (BI). TOP SECRET systems containing SCI or SIOP-ESI data require a SBI of all personnel exposed to their classified data.
Screen.. individuals for disciplinary or behavioral problems prior to use.
Before users are granted access to any system, the system owner must determine if access requires a background check and the type of background check required per the level of ADP sensitivity and the ADP position requirements defined in paragraph b above.
5.1.1 MAINTENANCE PERSONNEL
Restrict information system maintenance to authorized personnel with a security clearance for the highest classification and most restricted category of information processed. Uncleared individuals may perform maintenance on information systems used to process classified information only if the information is purged or an appropriately cleared individual (capable of identifying unauthorized activity) observes their actions.
a. Maintenance personnel must be cleared to the highest level of data the AIS is accredited to process. b. Maintenance personnel who do not access classified data during their maintenance operation should, nevertheless, be cleared for the highest level of data processed on the system. However, if this is not feasible, maintenance personnel will be monitored at all times during their maintenance operation by individuals with the technical expertise to detect unauthorized modifications.
Vendor personnel who must enter areas where classified information is processed must havethe proper security clearance or be constantly escorted until all maintenance is completed.Escorts must be briefed by the CSSO on their responsibilities while performing escort duties of uncleared maintenance personnel.
Procedures will be established to control both on-site and remote access of personnel assigned to conduct performance maintenance.
Except as authorized by the DAA, personnel who perform maintenance on systems shall be cleared to the highest classification level of information on the system, and indoctrinated for all information processed on that system. Cleared personnel who perform maintenance or diagnostics on an IS do not require an escort, unless need-to-know controls must be enforced. However, an appropriately cleared and, when possible, technically knowledgeable, facility employee shall be present within the area where the maintenance is being performed to assure that the proper security and safety procedures are being followed.
Allow remote software diagnostics or maintenance only if the information system audits such activities or an appropriately cleared individual (capable of identifying unauthorized activity) observes such activities. When maintenance activities are suspended or completed, disconnect or disable access to the information system. Additionally, verify the identity of the maintenance personnel to prevent the unauthorized disclosure of sensitive and classified information.
Non-U.S. citizens will not perform maintenance on TS/SCI-and SIOP
For US-owned and operated ISs, uncleared/lower-cleared maintenance personnel must be US citizens.
Prior to maintenance by uncleared/lower-cleared personnel, the IS shall be completely cleared and all non-volatile data storage media removed or physically disconnected and secured. When a system cannot be cleared, DAA-approved procedures shall be enforced to deny the uncleared/lower-cleared individual visual and electronic access to any classified or sensitive data that is contained on the system.
A separate, unclassified copy of the operating system and application software, including any micro-coded floppy disks, cassettes, or optical disks that are integral to the IS, shall be used for all maintenance operations performed by uncleared/lower-cleared personnel. The copy shall be labeled "UNCLASSIFIED
If appropriately cleared personnel are unavailable to perform maintenance, an uncleared person, or one cleared to a lower level, may be used provided a fully cleared and technically qualified escort monitors and records that person's activities in a maintenance log.
5.1.2 FOREIGN NATIONALS
Special Provision for Waivers of Citizenship Requirements. All concerned PAAs and Data Owners shall approve any exception to the citizenship requirements set forth below, including for systems jointly operated by the US and a foreign allied government.
USAF/CVA is responsible for authorizing foreign national access to information systems operated by HQ USAF, DRUs, and Secretary of the Air Force (SAF) functionals. USAF/CVA may further delegate authority to HQ USAF Deputy Chiefs of Staff, AFCIC/CC, and the USAFA Superintendent. Authorizing access to SAF-operated systems is delegated to the SAF assistant secretary level. Delegating authority for these positions shall not occur below the three-star level. MAJCOM commanders (MAJCOM/CC) are responsible for authorizing foreign national access to information systems within their respective commands. Delegating authority shall not occur below the MAJCOM vice commander.
Use of foreign national employees in positions that allow access to AIS is discouraged. However, when circumstances necessitate this practice, the requirements in this paragraph apply...Army Regulation 380
Foreign nationals will not be employed in positions that meet the definition of ADP I or II, unless specifically approved by officials listed in AR 380
Before authorizing foreign national access to specific information contained within an information system, the designees will:3.7.1.1. Ensure the information is properly processed for disclosure.3.7.1.2. Ensure systems accreditation authorities concur with the access.3.7.1.3. Ensure the C&A documentation for the system is updated to reflect foreign national access.3.7.1.4. Ensure security measures employed adhere to information assurance policy.
Foreign nationals will not be employed in AIS positions which will afford access to classified defense information except when the foreign national meets the provisions for a limited access authorization (LAA) due to other special expertise. An LAA may be granted only under the provisions of AR 380
Cleared foreign nationals may be utilized as maintenance personnel for those systems jointly owned and operated by the US and a foreign allied government, or those owned and operated by foreign allied governments. Approvals, consents, and detailed operational conditions must be fully documented within a Memorandum of Agreement.
...For systems jointly owned and operated by the US and a foreign allied government, or those owned and operated by foreign allied governments, uncleared/lower-cleared foreign nationals may be used. Approvals, consents, and detailed operational conditions must be fully documented within a Memorandum of Agreement.
The LAA must be reviewed annually to verify that it is still required as approved and has not evolved into a need for greater access. The LAAs will always be kept to the minimum, consistent with mission requirements, and will be terminated when no longer required.
US Government intelligence information is not releasable to foreign nationals except as authorized by the US Government. Data Owners can designate their information as releasable to individuals of specific nationalities in accordance with DCIDs 1/7 and 5/6. PAAs/DAAs shall obtain the written permission of all applicable Data Owners before allowing access by foreign nationals to a system that contains information not releasable to individuals of those nationalities. The decision to allow access by foreign nationals to systems that process intelligence information shall be explicit and shall be in writing.[*Director of Central Intelligence Directive 1/7, Security Controls on the Dissemination of Intelligence Information, 30 June 1998, Director of Central Intelligence Directive 5/6, Intelligence Disclosure Policy, 30 June 1998.]
In the absence of reliable human review, a foreign national may access or receive output from a system processing intelligence marked NOFORN only when (a) the system can reliably ensure that all NOFORN data is protected from foreign access, (b) the accrediting authority has obtained written approval from the head of CIA, DIA, NRO, or NSA (as appropriate to the sponsorship of the system in question), and (c) the accrediting authority has obtained concurrence from all Data Owners of NOFORN data processed by the system before any data is accessible, directly or indirectly, by foreign nationals. Failing agreement by the Data Owners to allow the foreign national access, the accrediting authority can appeal to the DCI/DDCI.
Access requests to information systems by foreign nationals can only be approved by the Director, DISA, or a designated representative. The following conditions must be met prior to granting access to a foreign national: (1) No classified information is processed on the information system and it is not connected to other systems that process classified information. (2) The foreign national is a resident alien of the United States, has been in resident alien status for at least the most recent 5 consecutive years, and has been subjected to a Background Investigation or National Agency Check.
5.1.3 REVOCATION OF ACCESS
Measures must be taken to ensure the security of data and information from disgruntled employees. Formal procedures must be identified and implemented for most situations that are vital to an organization. These situations do not necessarily have to be sensitive or critical in nature. Another related matter that must be addressed is the potential for system sabotage by employees. There are certain signs to look for in employees that have recently been reassigned or removed from a section because of poor performance or relations. Anger, bitterness, vindictiveness, or threats and revenge promises should not be taken lightly when the employee has access to a terminal or a computer. Immediate action must be taken to safeguard information and data. Anticipating a problem and taking measures before the employee is actually fired or removed can ensure system integrity.
Revoke].. authorizations of personnel who have become disciplinary or behavioral problems, and denying access of these personnel to rooms or compartments containing computers used for classified processing.
5.2 SECURITY TRAINING
INFOSEC education, training, and awareness activities are required for all employees. Such a comprehensive effort must meet the varying levels of knowledge, experience, and responsibilities of employees, as well as the specific needs of individual departments and agencies. There are certain messages that need to be conveyed:a. Organizations critically rely on information and information systems' resources.b. The organization, through its management, commits to protect information and information systems' resources.c. There are threats, vulnerabilities, and related risks associated with the organization's information systems.d. There are consequences from the lack of adequate protection of the organization's information systems' resources.e. The employee is the essential element of a successful protection program.
In accordance with references (b), (d) and (e) all individuals operating DON information systems will be afforded appropriate training and awareness information commensurate with their duties, responsibilities and the level of information protection required.
Computer security awareness encompasses formal and informal training to insure thatall personnel involved in the use and management of computer resources understand and canimplement their respective security responsibilities for safeguarding Sensitive Unclassified data derived from computer systems. Awareness training must be provided to new personnel, refreshed annually, and tailored to the types of responsibilities within the computer environment. In addition, personnel processing classified information must be indoctrinated with all applicable classified directives.
All Air Force personnel will receive IA awareness, training, and education throughout their assignments according to AFI 33-204, Information Protection Security Awareness, Training, and Education (SATE) Program.
Every INFOSEC education, training, and awareness program will contain three types of activities: initial orientation, more advanced education and training commensurate with duties and responsibilities, and reinforcement activities.
In support of the C&A process, the DCI shall establish and maintain a formal information security education, awareness and training program. The agencies, departments, and components covered by this policy, including those to which accrediting authority is delegated, will establish similar programs, as well as accreditation programs.
In compliance with the authority document, Computer Security Act of 1987, DISA requires mandatory periodic training in computer security awareness and accepted computer security practices for all personnel having access to government information systems including contractors, employees of other agencies, and members of the public.
Training in ISS principles and techniques will be integrated into unit operations at all levels of command.
All individuals who are appointed as ISSPM, ISSMs, ISSOs, and systems administrators must complete an AIS security course of instruction equal to the duties assigned to them.
All training activities pursuant to the requirements of this directive shall be conducted by individuals who are knowledgeable of INFOSEC principles and concepts, as well as their application.
Each federal department and agency will:a. Develop, implement, and evaluate an INFOSEC education, training, and awareness program in accordance with the National Manager guidelines.
Ensure that all individuals are appropriately trained in how to fulfill their security responsibilities before allowing them access to the system.
The Deputy Director for Personnel and Manpower (D1) shall establish, with the assistance of the CISSM and CISS, an information systems security awareness and professionalization program. (The program shall provide for the continual systems security awareness of DISA users and for the continued professionalization of the individuals appointed to information systems security positions.)
All persons accessing an AIS will be a part of the security training and awareness program.
The briefing will stress the importance of the individual's duties as a part of the unit mission and emphasize individual security responsibilities. No question having security impact will be allowed to go unanswered and no person will begin duties in a classified and/or sensitive area without a clear understanding of what is expected. The appropriate personnel available for questions throughout the assignment will be identified.
All computer personnel will be given a security briefing upon arrival and prior to beginning their assigned duties. The briefing may be given by the manager or delegated to the CSSO. It will be tailored to the assigned duties and oriented toward the local security environment and include the computer hardware, software and data sensitivity level.
There shall be in place a security training and awareness program with training for the security needs of all persons accessing the AIS.
A security education and awareness program, specific to the use and operation of the information system, will be established to provide mandatory, periodic, and refresher training. Users will be trained in the specific security features of the information system and will be provided the rules regarding acceptable use and operation.
A program will be established to ensure that all individuals receive specialized awareness training that is focused on their responsibilities and application rules before being allowed access to the application. This may be in addition to awareness and training required for access to a system. Such awareness training may vary from a notification at the time of access (e.g., for members of the public using an information retrieval application) to formal training (e.g., for an employee that works with a high risk application).
Initial and Recurring Training (1) Initial. Newly assigned personnel will receive security training prior to being granted access to DISA information. (2) Periodic. All personnel will receive security training on an annual basis. (3) Refresher. Refresher security training will be provided as needed whenever there has been a change in security requirements.
Such (security) training shall assure that employees are versed in the rules of the system [adopted pursuant to OMB A-130], be consistent with NIST & OPM guidance & and apprise them of available assistance, security products & techniques.
All individuals involved in the Certification and Accreditation (C&A) process shall be trained in that process and in its documentation requirements.
The [security training] program shall ensure that all persons responsible for the AIS and/or information, therein, and all persons who access the AIS are aware of proper operational and security-related procedures and risks.
The [security training] program will ensure that all persons responsible for managing AIS resources or who access AIS are aware of proper operational and security-related procedures and risks. As a minimum, items detailed in paragraph 2
All other personnel who manage, design, develop, maintain, or operate AIS will undergo a training and awareness program consisting of the following topics:
a. An initial security training and awareness briefing for AIS managers and users. This briefing can consist of training material governing ISS in general but must be tailored to the system the employee will be managing or using. The briefing will include the following:
(1) Threats, vulnerabilities, and risks associated with the system. Under this portion, specific information regarding measures to re-duce the threat from malicious software will be provided, including prohibitions on loading unauthorized software, the need for frequent backup, and the requirement to report abnormal program behavior immediately.
(2) Information security objectives (that is, what is it that needs to be protected?).(3) Responsibilities and accountability associated with system security.(4) Information accessibility, handling, and storage considerations.(5) Physical and environmental considerations that are necessary to protect the system.
(6) System data and access controls.(7) Emergency and disaster plans.(8) Authorized system configuration and associated configuration management requirements.
b. Periodic security training and awareness, which may include various combinations of the following: (1) Self-paced or formal instruction. (2) Security education bulletins. (3) Security posters. (4) Training films and tapes. (5) Computer-aided instruction.
The General Support OPR will:....Provide security awareness training regarding the technical security features, system privileges, and security capabilities of general support applications made available for use. (Security awareness training will be made available prior to user access and offered within defined periodic intervals or, as a minimum, annually.)
General awareness and training provides an understanding of: DISA policy and goals for protecting information and information systems, the roles and responsibilities of the various security staff personnel, and the relationship between information systems security and other security disciplines. General awareness and training sensitizes personnel to the existence of potential threats and vulnerabilities associated with the use of information systems. Training also heightens awareness of the need to protect data, information, and information system assets. All personnel should be trained in the areas outlined below as well as those areas identified in table 4-1.
Briefing and training content should be based on the following list of topics derived from National Institute of Standards and Technology (NIST) guidelines and supplemented by any others deemed necessary by the CISSM. (1) Understanding the roles of various DISA organizational units in ensuring adequate security and safety of information resources. (2) Understanding DISA policy and goals for protecting data and information, to include a discussion of security violations and incidents. (3) Working at home. (4) Dial-in access. (5) Connection to the Internet. (6) Unofficial use of government equipment. (7) Designation of sensitive data, applications, and systems. (8) Reporting violations, infractions, or incidents. (9) Marking, accountability, transmitting, destruction, and disclosure of sensitive data.
As a minimum, training shall include the following:(a) System security regulations and policies (individuals shall have the ability to implement and interpret national and agency/department regulations and policies).(b) Common information security technologies and practices.(c) Testing and evaluation techniques.(d) Risk management concepts.(e) Interconnected systems security concepts.(f) Procedures for incident handling.(g) C&A concepts, policies, and procedures.(h) Audit analysis procedures and tools.
In addition to the requirements specified in (1), above, DAAs and DAA Reps shall have the following training:(a) General information security orientation. An overview of what is expected of the person in this position, to include: infrastructure, risk management, the responsibility for accepting risks and the consequences, residual risks, basic security requirements, Protection Levels and Levels-of-Concern, C&A process.(b) Software protection and validation techniques.
Information System Specific. Personnel must also receive security training on each specific system to which they have access. Personnel must have a clear understanding of the threats to and vulnerabilities of the system. This includes a definition of terms, a discussion of the major categories of threats (e.g., unauthorized accidental or intentional disclosure, modification, destruction, or delay), a discussion of threat impact areas, common examples of computer abuse, and examples of common system vulnerabilities.
Initial and Recurring Training. (1) Initial. Newly assigned personnel will receive system specific training prior to being granted access to the information system. (2) Periodic. All personnel will receive system specific training on an annual basis. (3) Refresher. Refresher security training will be provided as needed whenever there has been a change in the system, system rules, or user procedures.
Content. The amount and depth of training needed will depend upon the specific duty requirements and expertise of the individual to be trained. The overall content will be determined by the ISSO in coordination with the System Programmer, Executive Software Group, or anyone involved in the day-to-day operation of the system in question. The briefing should contain specifics in the areas of: (1) Assignment and limitations of privileges. (2) Restoral activities. (3) Cognizant security staff. (4) Information system accreditation. (5) Risk assessments. (6) Security controls. (7) Viruses and malicious logic protection. (8) Contingency planning. (9) Data sensitivity and protection requirements.
In addition to the requirements specified in (1) above, ISSMs shall have training in the destruction and release procedures for systems, components, and media.
Professionalization Training Professionalization training is primarily aimed at the security staff and provides the skills necessary to evaluate computer security procedures and practices. Professionalization training ensures that the security staff is able to apply security concepts while performing the tasks that relate to their particular positions. This training should be given in addition to the training outlined above.
Continuous Training. ISSMs, ISSOs, and TASOs must be knowledgeable on current Federal and DISA policies. Additionally, they must be trained on their specific local security policies, requirements, and procedures.
Content. Professionalization training should address the areas outlined below as well as those areas identified in table 4-2. (1) Computer security basics. (2) Good computer security practices. (3) Roles of various organizations in ensuring adequate security and safety of information and information system resources. (4) Basic concepts of risk management. (5) Security planning. (6) Auditing and monitoring. (7) Information system security disciplines. (8) Contingency planning. (9) Life-cycle management.
In addition to the requirements specified in (1) above, ISSOs shall have the following training:(a) How to implement common information systems security practices and technologies. This training shall include information on support infrastructures, help teams, and organizations that could assist the ISSO.(b) How to implement testing and evaluation procedures.(c) How to implement configuration management concepts.(d) Destruction and release procedures for systems, components, and media.(e) Other security disciplines that affect the ISSO's operations.
The following individuals shall be trained in their responsibilities and those of their subordinates:Privileged Users, with training to include:(a) How to protect the physical area, media, and equipment (e.g., locking doors, care of diskettes).(b) How to protect authenticators and operate the applicable system security features.(c) Security consequences and costs so that security can be factored into their decisions (manager).(d) How to implement and use specific access control products (system administrators).(e) How to recognize and report potential security vulnerabilities, threats, security violations, or incidents.(f) The organization's policy for protecting information and systems and the roles and responsibilities of various organizational units with which they may have to interact.(g) The system security regulations and policies.(h) What constitutes misuse or abuse of system privileges.
The following individuals shall be trained in their responsibilities and those of their subordinates:....General Users, with training to include:(a) How to protect the physical area, media, and equipment (e.g., locking doors, care of diskettes).(b) How to protect authenticators and operate the applicable system security features.(c) How to recognize and report security violations and incidents.(d) The organization's policy for protecting information and systems.
System administrators (SAs) must be trained in in all aspects of information system security and must be highly trained and experienced on the AIS that they are required to maintain. The SA must be able to maintain the AIS audit functions and have the ability to review audit information for detection of possible system abuse and to coordinate with the ISSO.
6.0 COMMUNICATIONS SECURITY
Cryptography is a critical tool used to protect confidentiality of data, to assure the authenticity of information, and to detect the alteration of information. National policy requires the National Security Agency (NSA) to review and approve all cryptography used to protect classified information from access by unauthorized persons (i.e., not cleared for the information).
Controls will be established to deny unauthorized persons from receiving information derived over telecommunication lines or from equipment. Established measures and controls must also ensure the authenticity of communication transmissions. Further guidance can be found in DISAI 240-115-3, Communications Security, 23 July 1992.
Protect transmissions of classified, sensitive, or a combination of classified and sensitive information according to AFSSI 4100VI, (FOUO) The Air Force Communications Security (COMSEC) Program.
All communications circuits employed to interconnect remotely located components of Marine Corps automated systems or networks which process classified or Sensitive Unclassified information will be provided COMSEC. Appropriate COMSEC will be achieved by use of standard military encryption systems produced and or endorsed by the National Security Agency (NSA), installed in accordance with the provisions of NACSIM 2203; Protected Distribution System (PDS) or intrusion-resistant cables.
Communications security techniques will be applied to the extent necessary to deny information to unauthorized personnel and to effectively defend against interception, traffic analysis, and imitative deception.
The objectives of COMSEC will be an integral part of program planning for all telecommunications systems (including those integral to weapons systems and weapons support systems) and will be addressed throughout a system's life cycle. Systems planning shall include threat analysis and vulnerability assessments to support operational requirements and to establish resource allocation priorities and satisfy requirements for countermeasures.
Operate networks in a system high or dedicated security mode unless all network nodes are accredited for operation in the multilevel or partitioned security mode.
Communications Security. The communications links connecting the components of the systems, associated data communications, and networks shall be protected in accordance with national policies and procedures applicable to the sensitivity level of the data being transmitted.
Classified and SBU information will be transmitted only by secure means. When information transits an area not under access controls as stringent as required for that classification of the information, it will be secured by encryption or a protected distribution system.
Only keying material produced by NSA or generated by NSA approved key generators will be used to key cryptographic systems which protect classified or SBU information.
Maximum use will be made of electronic key generation as well as remote electronic keying and re-keying of cryptographic systems with that capability.
Safeguarding and controlling COMSEC material, including CCI, is governed by AR 380
Authentication methods will be used to defend against imitative communications deception and to authenticate stations, transmissions, and communicators. The authentication process may be embedded in the communications equipment.
6.1 POLICY
system(s) operating at Protection Level(s) [1-5] shall employ the following features: Data transmission that implements at least one of the following:(1) Information distributed only within an area approved for open storage of the information.(2) Information distributed via a Protected Distribution System* (PDS).(3) Information distributed using NSA-approved encryption mechanisms appropriate (see paragraph 1.G.1) for the classification of the information.(4) Information distributed using a trusted courier.[*A PDS provides physical protection or intrusion detection for communications lines. A PDS can also provide need-to-know isolation for communications lines.]
Classified information shall be protected during transmission by approved National Security Agency (NSA) methods.
Telecommunications circuits of Marine Corps automation systems handling classified information will be encrypted using only NSA endorsed Type I COMSEC equipment...Where operationally feasible, and cost effective, a PDS may provide the requisite security, as an alternative to encryption.
6.2 CLASSIFIED COMSEC REQUIREMENTS
Only approved cryptographic systems will be used within the Army. Approved cryptographic systems include
Separation of Data. Information transmissions of different security levels shall be segregated from each other (e.g., encryption, physical separation).
Marine Corps automation facilities will use only COMSEC equipment and keying materials produced by the NSA and installed and secured in accordance with paragraph 7.1 when national defense information is passed over telecommunications circuits connecting remotely located peripheral or terminal devices with a host computer or among a group of host computers and their outstations which serve as components of a larger teleprocessing network. The use of mathematical algorithms, compression, or compaction techniques, for the purpose of protecting classified information stored or processed with an automated system is prohibited. At no time will a Marine Corps automated system processing classified data attempt its protection during transmission over telecommunications circuits with commercially available computer-generated algorithm encryption systems such as the National Bureau of Standards Data Encryption Standard (DES).
Systems will be designed and deployed using embedded cryptography to the maximum extent possible. When embedded cryptographic equipment is not employed, off-line electronic, automanual, or manual systems will be used to provide the required security, if the transmission is not otherwise protected. Army system COMSEC requirements will emphasize small, reliable, lightweight, low-powered equipment that is unclassified when not keyed and will be achieved with no increase in the frequency band width required by the equipment being supported. Requirements must address interoperability for both routine and contingency operations.
There will be an appropriate safeguard to ensure that security classification labels remain with the data if it is transmitted via a network to some other AIS.
A system operating at the High Level-of-Concern for integrity shall implement the following features:.... Data Transmission, including:(a) Integrity mechanisms adequate to assure the integrity of all transmitted information (including labels and security parameters).(b) Mechanisms to detect or prevent the hijacking of a communication session (e.g., encrypted communication channels).
The security safeguards applied to SBU information during transmission will be consistent with the need for protection against disclosure, loss, misuse, alteration, destruction, or non-availability. Sensitive but Unclassified information as described in paragraph 1
NSA-approved techniques, which may be used separately or in various combinations, to protect the transmission of SBU, are listed below:
(1) Encryption. A number of cryptographic products are acceptable for this purpose and are listed in NSA Information Systems Security Products and Services Catalogue.(a) Type I products. These products may be used to protect both classified and SBU defense information.(b) Type II products. These products may be used to protect only SBU information; they are handled as an Endorsed for Unclassified Cryptographic Item (EUCI). A FORTEZZA card is an exception to this policy when used in "FORTEZZA for classified applications."(c) Data encryption standard equipment. unclassified cryptographic equipment employing the DES algorithm, which meets the requirements of Federal Standard 1027, may be used to protect only the transmission of unclassified information.(d) Commercial equipment. As other equipment is developed and available, when approved by NSA (for example, RSA), it can be used to protect SBU information.
(2) Unencrypted cable circuits. Although encryption is the preferred protection, unencrypted cable circuits of copper or fiber optics may be used. The degree of protection provided will depend on the type of cable used. The cable least vulnerable to exploitation is fiber optic cable, followed by copper coaxial cable and copper strand cable. Cable protection can be enhanced by burying the cable underground or in walls or floors and providing access controls for entry to cable vaults, rooms, and switching centers. Unencrypted cable circuits can be employed to transmit SBU information under the following two conditions: (a) The cables are used only within the geographic boundaries of the Unite States or within areas totally within U.S. control overseas. (b) Adequate measures are implemented such that circuits are maintained on cable and not converted to unencrypted radio transmission.
(3) Protected services. Commercial telecommunications companies offer services that are endorsed to protect the transmission of unclassified information. The companies authorized to offer such services are listed in NSA Information Systems Security Products and Services Catalogue.
6.3 SENSITIVE COMSEC REQUIREMENTS
Sensitive but unclassified information shall be protected during transmission in a manner commensurate with the level of risk and magnitude of loss or harm that could result from disclosure, loss, misuse, alteration, destruction, or non-availability.
Telecommunications circuits handling Sensitive Unclassified information may be encrypted using either NSA endorsed Type I or Type II equipments. Where operationally feasible, and cost effective, a PDS may provide the requisite security, as an alternative to encryption.
6.4 PROTECTED DISTRIBUTION SYSTEM (PDS)
This instruction [NSTISSI 7003] stipulates approval authority, standards and guidance for the design , installation, and maintenance of Protected Distribution Systems.
PDS wiring/cable will be installed as prescribed by NACSIM 2203. A PDS is costly and suitable for only short-distance communication (normally within a single building or facility, which is under continuous physical/personnel security controls), and approved methods of user-authentication.
Communications circuits can be protected by appropriate physical, acoustical, electrical, or electromagnetic safeguards such that classified data can be transmitted on these lines in clear text. These circuits must be formally approved as a protected distribution system (PDS).
An additional area of concern - one which receives very little attention - is the requirement that any distributed system must use an approved PDS for its interconnecting wirelines (in accordance with OPNAVINST C5510.93), if they will extend beyond the boundary of the controlled space within which the processing equipments are located. In all cases, the PDS must be technically reviewed by NESSEC Code 04 and approved by appropriate authority as stated in OPNAVINST C5510.93.
A PDS will be used only if it is cost-effective and sufficiently controlled to prevent covert penetration and interception.
A PDS must be constructed according to criteria published by HQDA DISC4.
A PDS may not be required if fiber optic cable is installed in a controlled environment and if the system design is approved by the DAA prior to installation.
Fiber optic lines can be adequately protected by Intrusion Detection Optical Communications systems approved by NSA and listed in the NSA Information Systems Security Products and Services Catalogue.
The AIS that include a PDS to transmit data will not be accredited to operate until the PDS has been approved. The PDS approval will be cited in the COMSEC portion of the accreditation packet and a copy of the approval will be attached.
Authority to approve a PDS for the clear text transmission of classified information within fixed plant and garrison installations is delegated as follows:(1) Principal HQDA officials for activities under their staff supervision, direction, or control.(2) Commanders of MACOMs or their designees at MACOM level, for their organic activities.
Requests for approval of a PDS to transmit top secret information must include an evaluation by the appropriate support element. Approval authorities may request technical assistance from INSCOM, 902nd MI Group, Fort Meade, MD 20755, in applying security criteria and processing the approval action for other PDS.
Commanders of battalion and higher echelons may approve circuits for clear text electrical transmission of Secret and Confidential information in tactical environments. Under combat conditions, commanders may delegate this authority to the company level. Tactical PDS will not be approved for clear text transmission of Top Secret information.
Once a PDS is approved, no changes in installation, additions, or use may be made until approval for such changes has been granted by the approval authority.
Requests to approve a PDS will be submitted through channels to the appropriate approval authority. Requests will be classified at least confidential and will contain the following information:(1) Full identification and location of the requesting organization.(2) A statement of the classification of information to be transmitted on the PDS.(3) A copy of the building floor plan (or a diagram of the field area as appropriate) designating the following: (a) Proposed cable route and location of subscriber sets, distribution frames, junction boxes, and any other components associated with the circuit. (b) Other wiring along the PDS route.
(4) Description of the cable installation (for example, 24 pairs of shielded cable in rigid steel conduit, 6 pairs of shielded cable in floor, or fiber optic cable). Indicate the cable length. (5) Description and nomenclature of terminal and subscriber equipment to be used. (6) Clearance of individuals having access to the circuit. (7) Type of guards (for example, U.S. military, U.S. civilian, foreign civilian) and their security clearance or access authorization status. (8) Description of access control and surveillance of uncleared personnel who may be allowed entry into the area housing any part of the PDS. (9) Identification of the power source to be used for the PDS and a statement of the distance to the nearest point where undetected tampering would be possible. (10) A justification for using the proposed PDS. (11) A statement concerning any deviations from the established PDS criteria, and an evaluation of their security implications. (12) A copy of the security evaluation for PDS used with Top Secret information.
The AIS that include a PDS to transmit data will not be accredited to operate until the PDS has been approved. The PDS approval will be cited in the COMSEC portion of the accreditation packet and a copy of the approval will be attached.
6.5 RADIO SYSTEMS
a. All voice or data military radio systems used for transmitting classified or SBU information will be secured or securable by an approved cryptographic system. Military radios are those radios built or adopted for use as standard military communications systems with a type classification or military nomenclature.
b. Electronic, automanual, or manual cryptosystems will be used to provide the needed security for existing radio systems that do not have embedded or electronic cryptosystems. However, all future procurements must comply with 4
Excluded from the requirements of paragraphs a and b, above, are
Commercial non-encrypted radio systems will not be used in support of command and control functions.
6.6 TEMPEST AND TSCM
It is the policy of the U.S. Government that federal departments and agencies and their designated agentsuse TEMPEST countermeasures in proportion to the threat of exploitation and the associated potential damage to the national security. The provisions of this policy apply to national security systems and are applicable to U.S. Government operations worldwide. Within the United States only the most critical information will be protected by implementation of countermeasures which entail cost.
Where required, controls will be established to deny unauthorized persons from receiving information of value that might be derived from interception and analysis of compromising emanations.
This chapter is applicable to only those computer facilities (any size) processing CLASSIFIED defense information. OPNAVINST C5510.93, "DON Implementation of National Policy on Control of Compromising Emanations (U)", promulgates DON implementation of national policy on control of compromising emanations, generally referred to as TEMPEST. It applies to all activities of the DON responsible for the design, procurement, installation, operation, maintenance, or repair of electronic equipment or systems used to process classified information.
All equipment used to transmit, handle, or process SCI electronically (including communications, word processing and automated information systems equipment) must satisfy the requirements of AR 381
The components of the systems, associated data communications, and networks shall be protected in accordance with national EMSEC/TEMPEST policies and procedures applicable to the sensitivity level of the data being transmitted.
Technical Surveillance Countermeasures (TSCM). The components of the systems, associated data communications, and networks shall be protected in accordance with national TSCM policies and procedures applicable to the sensitivity level of the data being transmitted.
Accreditation for laptop or notebook computers generally must address processing in the user's normal work location and in the official travel location. If classified processing is included in the accreditation, TEMPEST (inspectable space) requirements must be addressed for the normal work location. When approval has been granted to process classified information at a temporary location for more than 90 days, a TEMPEST Countermeasures Review must be performed for that location per AR 381
Any system which is or will be used to process classified data (except those systems located on military bases within the U.S. that process data classified no higher than CONFIDENTIAL), must be afforded a TEMPEST Countermeasure Review. OPNAVINST C5510.93 details the information required to prepare and submit a TCR to NISE EAST. A TCR must be submitted (with the exception above) before a system or equipment can be used to process classified information. After the TCR has been submitted, classified processing can begin on the system provided all the necessary countermeasures or procedures identified have been implemented.
Prior to use in processing classified information or as soon as possible after the start of classified processing, all commands will submit a TCR (See Chapter 8, paragraph 8.3.c, for exceptions) for all main-frame, mini and microcomputer systems. In assessing the TCR, NISE EAST will designate the system as an acceptable risk or, to ensure the system is TEMPEST certified, assign an Instrumented TEMPEST Survey (ITS). If NISE EAST determines that upon completion of the TCR that an ITS is required, then NISE EAST will assign a priority for conducting that survey. NISE EAST will respond by message or letter to all units submitting TCRS with the assigned survey priority (if required) and he security classification processing level authorized for each system.
When the processing level of a system changes, a new TCR must be submitted.
The TEMPEST countermeasures required for your facility can be determined by using NISE EAST TEMPEST Alternatives Determination Procedures available from Navy Electronic System Security Engineering Center (NESSEC) Code 04. It is emphasized here that the need for a Preferred Products List (PPL) item or a shielded enclosure must be coordinated with and or approved by NESSEC Code 04, prior to implementation. If your facility is already in operation, no changes to implement TEMPEST countermeasures should be made until your TCR [TEMPEST Countermeasure Review] has been evaluated. A copy of any countermeasures determination data should be attached to your TCR submittal. If you are planning a new facility, NESSEC should be contacted for support in determining your TEMPEST countermeasure requirements.
Exceptions to the National Policy on Compromising Emanations are required as set forth in Section II of enclosure (4) of OPNAVINST C5510.93. Request for exceptions will be submitted by message within 30 days of the ITS. This message must be classified SECRET. Forward request to NISE EAST via CMC (Code CSBT) with a copy to CO, NAVELEXSECCEN, and any other appropriate command.
Systems used for processing Sensitive Compartmented Information (SCI) must first have a Technical Surveillance Countermeasures (TSCM) inspection prior to placement in the SCI Facility (SCIF). Request for TSCM inspections should be submitted through the Special Security Office (SSO) to the nearest Counter Intelligence Team (CIT). Additionally, TCR's for systems processing SCI will be forwarded to NISE EAST with a info copy to NAVELEXSECCEN and CMC (code CSB). NISE EAST may authorize processing of information up to Top Secret. An authorization from NISE EAST will be forwarded with a copy of the TCR to CNO (OP-OO9P) for accreditation of the computer system to process SCI in the SCIF.
6.7 SYSTEM INTERCONNECTION AND NETWORKS
Obtain written management authorization, based upon the acceptance of risk to the system, prior to connecting with other systems.
Adhere to the DISA Connection Approval Process if the system is connected to SIPRNET.
Where connection (with other systems) is authorized, controls shall be established which are consistent with the rules of the system and accordance with guidance from NIST.
Use only Secret and Below Interoperability (SABI)-approved devices and adhere to SABI configuration guidelines when connecting classified systems or networks to unclassified systems or networks.
When AISs managed by different DAAs are interfaced or networked, a memorandum of agreement (MOA) is required that addresses the accreditation requirements for each AIS involved. The MOA ;should include description and classification of the data; clearance levels of the users; designation of the DAA who shall resolve conflicts among the DAAs; and safeguards to be implemented before interfacing the AISs. MOAs are required when one DoD Component's AIS interfaces with another AIS within the same DoD Component or in another DoD Component and when a contractor's AIS interfaces with a DoD Component's AIS or to another contractor's AIS.
Organizations that depend on interservice or interagency networks should develop a Memorandum of Agreement (MOA) for each AIS networked with another service or agency system and forward it to each command, service or agency DAA for review and mutual acceptance.
An Interconnection Security Agreement (ISA) is required whenever an accredited system is connected to a system accredited by a different DAA.* The contents of such an ISA are specified in Appendix A.[*Some types of interconnected networks, particularly those that are community wide, do not require a formal ISA. In this case, the function of the ISA is handled with a list of requirements to be satisfied prior to connection. Upon verification that the list has been satisfied, the interconnection is made.]
Establish a Memorandum of Agreement (MOA) when interconnected systems are managed by different DAAs. The MOA should include a description and sensitivity of the information, clearance levels of the users (if required), designation of the DAA who will resolve conflicts among the DAAs, and safeguards to be employed to ensure adequate security. Where connection is authorized, controls should be established that are consistent with the rules established for the interconnecting General Support System.
For a multi-user telecommunications network (e.g., the Defense Data Network or the Worldwide Military Command and Control System Intercomputer Network, a DAA shall be designated as responsible for the overall security of the network and shall determine the security and protection requirements for connection of AISs to the network. Necessary safeguards shall be agreed to and implemented and the AISs accredited for interconnection before they are connected to the network. The security of each AIS connected to the network remains the responsibility of its DAA. The DAA responsible for the overall security of the network shall have the authority and responsibility to remove from the network any AIS not adhering to the security requirements of the network.
It is permissible to define network interfaces and boundaries into manageable subnetworks based upon physical or logical boundaries, when there is a need to do so. Cryptographic separation and/or equivalent computer security measures, as defined by the NSA or the DIA where applicable, shall be a basis for defining such network and/or subnetwork interfaces or boundaries.
Confirm that information systems added to the network comply with the system security policy.
The provisions of this regulation apply to networks, which are included in the definition of an AIS. However, for the purpose of applying these standards and identifying responsible officials, the following views of a network must be considered:(1) The Interconnected Accredited AIS (IAA) view is one in which the network is treated as an interconnection of separately created, managed, and accredited AIS. An IAA consists 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.(2) The Single Trusted System (STS) view is one in which the network is accredited as a single entity by one DAA. The STS view is normally appropriate for local area networks but can also be applicable to wide-area networks for which a single agency or official has responsibility.
Accreditation of DON information systems shall be performed when information systems are interconnected to other previously accredited information systems and networks. The DAA shall ensure that operation of the resultant system does not incur any additional unacceptable risk.
Networks, including all connected subnetworks, shall be accredited for the highest division and class of security required based on the concepts and procedures in enclosures 4 and 5.
Any interconnection of computers and terminals via communications lines is considered a data network for security purposes....The mechanisms and procedures to protect information and processes must at least complement and should enhance the security provided in the networked terminals and systems. a. The DAA for networks that pass sensitive information shall designate a Network Security Officer (NSO). Each network shall be accredited by the DAA to operate at the maximum specified level of sensitivity. b. Each NSO must maintain a record of authorized users of a network and their network privileges. The record may be automated or manual. c. Each NSO must limit knowledge of access codes, telephone numbers, passwords, etc., to those with a need to know. d. A risk assessment is mandatory for the network. The assessment must include each component of the network. This assessment becomes part of the accreditation documentation that is required by the DAA to determine if the network is worthy of accreditation.
The following security provisions are applicable to the IAA view network:(1) Even though there are multiple individually accredited AIS, there should still be a single identified network DAA (for example, DISA has overall control and publishes security parameters for use of the Defense Data Network (DDN)). However, a central focal point cannot always be identified. In this latter case, each individual AIS DAA must establish procedures to protect the data contained in the AIS and to ensure that only authorized data are transmitted on the IAA network.(2) The DAA of the individual AIS must specifically approve connection of the AIS to an IAA. This approval will be part of the AIS accreditation. It will be made only after assessing the additional risks involving the potential exposure of data within the larger community of AIS infrastructure.(3) The DAA's approval will include a description of the classification and categories of information that can be sent over the IAA. Unless the AIS is accredited for multilevel operations and can reliably separate and label data, the AIS is assumed to be transmitting the highest level of data present on the system during network connection.
NETWORK PROTECTION. Information, including users IDs and passwords transmitted on a network is vulnerable to unauthorized disclosure. Mechanisms to prevent compromise of classified and sensitive unclassified information are mandatory. Protection levels and associated requirements for data and devices are described in Appendices E, F, and G. Detailed guidance for required protection (minimum level is Class C2 for sensitive unclassified systems) to operate trusted systems/networks is contained in DoD Standards 5200.28-STD "DoD Trusted Computer System Evaluation Criteria", and NCSC-TG-005 "Trusted Network Interpretation." Refer to Appendix C for ordering these DoD documents.
(4) The DAAs of the participating AIS and the DAA of the overall network (if one has been designated) will sign a Memorandum of Understanding (MOU). In those cases where standard procedures for connecting to the network have been defined by a DAA, those procedures, coupled with the approval of the DAA to connect, will serve as the MOU.(5) Connections between accredited AIS must be consistent with the mode of operation, sensitivity level or range of levels, and any other restrictions imposed by the accredited AIS.(6) Connections to unaccredited AIS (that is, from other agencies or non-governmental entities) are authorized, but only non-sensitive unclassified and SBU data may be transmitted to and from such AIS. Data that are SBU must be afforded the proper protection requirements (data confidentiality, data integrity, and data availability) to ensure compliance to paragraph 1
The following security provisions apply to the STS view of a network:(1) The STS view of a network 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.(2) Sensitivity category and mode of operation of the STS network will be determined as described in paragraph 2
Limit access to networked terminals and systems commensurate with the highest sensitivity and criticality of the data processed. It is especially critical to protect the access mechanisms used by the terminals and systems.
(b) Denial of service characteristics, including continuity of operations, protocol-based protection against denial of service, and adequacy of network management; and, (c) Compromise protection, including data confidentiality, traffic flow confidentiality, and the ability to route transmissions selectively in the network.(3) The security services described in paragraph (2) above can be addressed only in a subjective manner and may not be applicable or desirable in all situations. Nevertheless, ISSOs and network DAAs must consider each of them in defining their network security requirements and develop countermeasures for those services that are required but not present.
Limit the number of unsuccessful attempts to access a network or networked system and lock out further attempts. Allow three attempts for networks processing unclassified information, two for classified. At a minimum, lock out the user-ID; and if possible, lock out the terminal. When a lock out occurs, notify the NSO or system operator. Only the NSO, CSSO, computer security staff or TASO administrator can authorize access reinstatement. Enforce these restrictions at each point in the network where access controls are applied (i.e., gateways, hosts).
Networks and systems must automatically terminate sessions after periods of inactivity. The length of time will depend on the sensitivity of the information processed by the host system. When the network initiated the disconnect, the host must be able to detect the event and automatically log-out the user to prevent unauthorized access through the session.
Use only official U.S. Government authorized bulletin boards. It is imperative that the software/information from a bulletin board be tested for the presence of a virus by the individual or organization responsible for computer security matters. (Ensure that software/information downloaded from a bulletin board be downloaded only to a floppy diskette drive and not to permanently installed magnetic media.)
There will be an appropriate safeguard to ensure that security classification labels remain with the data if it is transmitted via a network to some other AIS.
Any interconnection of computers and terminals via communications lines is considered a data network for security purposes.....Maintain audit trails on all [network] security related activities. Audit trails may be automated or manual and should be reviewed periodically for security violations. At a minimum, an audit trail must include login procedures, auditing of security-relevant events, and resource isolation that allows a computer system to be identified to a network.
6.7.1 CONNECTIONS WITH FOREIGN NATIONAL IS
Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 6740.01, Military Telecommunications Agreements and Arrangements Between the United States and Regional Defense Organizations or Friendly Foreign Nations, 18 September 1996, directs establishing a memorandum of agreement between the United States and the foreign nation requiring use of the Defense Information Systems Network (DISN) prior to providing the foreign national telecommunications service, such as access to United States information systems. This agreement must clearly define all obligations and benefits concerning military communications support and related supplies and services provided and the mechanism for reimbursement of costs.
CJCSI 6211.02A, Defense Information System Network and Connected Systems, 22 May 1996 identifies the Joint Staff/J6 Director as the responsible agent for DISN operational network policy. The instruction also requires the DISA Director to establish and publish DISN connection requirements. Authority to connect to the DISN-SIPRNET, DISN-Nonsecure Internet Protocol Router Network (NIPRNET), or other networks by foreign entities does not equate to authority to exchange data or access systems located on that network. The DAA or designated release/disclosure authority, grants access to information and information systems. Ensure authorization is pursuant to a written arrangement concluded in accordance with applicable instructions enabling access to the information. Submit requirements to your MAJCOM foreign disclosure office and other appropriate offices (i.e., MAJCOM IA office, personnel security, DAA, etc.) for proper processing before seeking service, commander-in-chief (CINC), and/or Joint Staff/J6 approval.
The United States Military Communications-Electronics Board establishes DISN connection requirements for information systems connecting to the DISN-SIPRNET requiring access by foreign nationals.3.7.4.1. The service sponsor and authority responsible for granting foreign national access to Air Force information systems shall request Joint Staff/J6 approval in order to connect to DISN-SIPRNET. For Air Force information systems requiring DISN-SIPRNET access that support a CINC, the sponsoring CINC for the foreign national requests Joint Staff approval. Furthermore, the request must include items identified in the draft DISA Connection Approval Process (see AFCA Home Page) (i.e., mission statement, organizations involved, and points of contact [POC], brief description of current environment to include topology, consent-to-monitor statement, etc.).
DISA, the National Security Agency, the CINC, and/or service representatives engineer a technical solution through the SABI process upon validation of the requirement [for DISN-SIPRNET connections requiring access by foreign nationals] by Joint Staff/J6. The technical solution must include a high assurance guard in United States-controlled space to protect United States-only information and information systems. The functional user must submit C&A documentation to DISA and present the technical solution to the DISN Security Accreditation Working Group (DSAWG). If approved, the DSAWG advises the sponsoring CINC and/or service and DISA, in writing, so DISA can grant the approval to connect.
3.7. Foreign National Access to Air Force Information Systems....3.7.5. For DISN-NIPRNET access, the appropriate sponsor (CINC, USAF/CVA, or MAJCOM/CC) sends service-validated requirements to the Joint Staff/J6 for approval. The request must contain the following information from the system C&A documentation: a brief mission statement and description of current environment, organizations involved and POCs, type of connectivity required (e.g., Hypertext Transfer Protocol, Simple Mail Transfer Protocol, FTP, etc.), what and how often information will be transmitted, releasability of information as determined by the MAJCOM foreign disclosure office, and a copy of the accreditation statement by the local DAA. In addition, include a proposed solution that explains how access by the foreign national will be limited to only the information determined to be releasable by the appropriate foreign disclosure office (a high assurance guard is not a requirement for NIPRNET access).
3.7. Foreign National Access to Air Force Information Systems .3.7.6. Connection by stand-alone systems or networks within a local enclave or through means other than the DISN requires approval by the MAJCOM/CC or USAF/CVA. Coordinate requests through appropriate offices and include complete C&A documentation according to AFSSI 5024VI.
3.7. Foreign National Access to Air Force Information Systems . 3.7.7. For all Air Force systems accessing the DISN-SIPRNET or DISN-NIPRNET, get appropriate service coordination and service authorization before proceeding with CINC coordination and/or Joint Staff approval.
6.7.2 INTERCONNECTED SCI ISs AND ADVANCED TECHNOLOGY
An interconnected IS is composed of separately accredited ISs. Each self-contained IS maintains its own intra-system services and controls, protects its own resources, and retains its individual accreditation. Each participating IS has its own ISSO.a Interconnected ISs shall have a mechanism capable of adjudicating the different security policy implementations of the participating ISs.b Interconnected ISs require accreditation that explicitly addresses their interconnectivity (see Chapter 9 for discussion and definition of accreditation).
When connecting two or more ISs, the DAA(s) shall review the security attributes of each system to determine whether the combination of data or the combination of users who have access to the interconnected ISs necessitates a higher level of security requirements. DAA(s) shall explicitly make this determination, even if the systems are accredited at the same level of technical requirements.
A Controlled Interface is a mechanism that facilitates adjudicating the security policies of different interconnected ISs (e.g., controlling the flow of information into or out of an interconnected IS). Controlling the flow of information into an interconnected IS helps preserve the integrity of the IS, and the integrity and confidentiality of the information maintained and processed by the IS. Controlling the flow of information out of the IS* helps preserve the confidentiality of the information leaving the IS, and may protect the integrity of the receiving ISs. The adjudication of integrity and confidentiality policies may be handled in a variety of ways. For example: (1) A single Controlled Interface may perform all of the confidentiality and integrity adjudication; or (2) One Controlled Interface may be employed for adjudicating confidentiality policies while another adjudicates integrity policies; or (3) The adjudication of confidentiality and integrity policies may be distributed across a set of Controlled Interfaces where each performs some subset of confidentiality and integrity policy adjudication. In this instance, the set of Controlled Interfaces adjudicates all of the required integrity and confidentiality policies.
While a Controlled Interface is often implemented as a mechanism (or a set of mechanisms) separate from the ISs it is intended to protect, this need not be the case. A Controlled Interface can be constructed so that some of its functionality resides in the ISs themselves. Regardless of its implementation, the Controlled Interface must conform to the requirements provided below.
The DAA shall ensure that:(1) Mechanisms or procedures exist to prohibit general users from modifying the functional capabilities of the Controlled Interface.(2) Automated mechanisms are employed that can monitor the Controlled Interface for symptoms of failure or compromise. The mechanisms shall be protected against failure or compromise.(3) The Controlled Interface is physically protected.
Routing information, employed for either controlling the release of outgoing information or the delivery of incoming information, shall be supplied or alterable only by the Security Support Structure of the Controlled Interface.
Each Controlled Interface shall be configured and located to facilitate its ability to provide controlled communication between the interconnected systems.
Each Controlled Interface shall be configured to ensure that all (incoming and outgoing) communications protocols, services, and communications not explicitly permitted are prohibited.
Each Controlled Interface shall be tested to ensure that it satisfies all of the appropriate Controlled Interface criteria listed in this chapter.
The Controlled Interface shall be included in a configuration management program. Security policies, procedures, etc., shall be documented.
Safeguards shall be provided to assure that users cannot circumvent technical controls [of the Controlled Interface].
All direct user access to the Controlled Interface shall be audited.
Remote administration of the Controlled Interface is discouraged. All remote administration of Controlled Interfaces requires written approval of the DAA. If remote administration is employed, the session must be protected through the use of the following techniques:(1) Strong authentication, and either(2) Physically separate communications paths, or (3) Logically separated communications paths based upon either (a) NSA-approved encryption; or (b) NSA-approved encryption and DAA-approved privacy encryption to provide privacy of the remote administration session.
Direct user access to the Controlled Interface shall require strong authentication.
The requirements imposed upon Controlled Interfaces do not release the DAA, ISSO, or ISSM of the obligation to ensure that the ISs comprising the interconnected IS provide the required security functionality. The introduction of a Controlled Interface does not impact the determination of the Protection Level or Levels-of-Concern of the ISs comprising the interconnected IS.
6.7.2.1 CONTROLLED INTERFACE
A Controlled Interface shall be required for facilitating the adjudication of confidentiality policies if:(1) The two interconnected ISs are approved to process information of different classifications; and(2) Neither interconnected IS is operating at Protection Level 4 or 5.
A Controlled Interface shall be required for facilitating the adjudication of confidentiality policies if:(1) The compartments, sub-compartments, caveats, control markings, or special handling of information processed by one interconnected IS is different than the compartments, sub-compartments, caveats, control markings, or special handling of information processed by the other interconnected IS; and(2) Neither interconnected IS is operating at Protection Levels 3, 4, or 5.
At a minimum,* the following confidentiality policy adjudication features shall be provided [for controlled interfaces]:[*One circumstance in which additional security requirements should be considered involves the IS receiving information via the Controlled Interface, which in turn is directly connected to another system accessible by a user holding a lower clearance. This topic is further discussed in paragraph 9.D.3.c(1).]
(1) Traffic Review. Review the classification of all outgoing (i.e., going outside of the interconnected IS perimeter) traffic based on associated security labels (where provided) or data content (if applicable) before being released. If labels are used, the Controlled Interface must maintain the integrity of the labels.
(2) Controlled Release. Ensure that only traffic that is explicitly permitted (based on traffic review) is released from the perimeter of the interconnected IS.
(3) Encryption. Encrypt (as needed) all outgoing communication (including the body and attachment of the communication) with the appropriate level of encryption for the information, transmission medium, and target system.
(4) Protection. Ensure that users and processes in a lower protection domain are prevented from accessing information for which they are not authorized that resides in a higher domain. In addition, when information at a higher security level is made available to a lower security level, the information shall be protected and maintained at the higher security level until it satisfies the traffic review and controlled release requirements described above.
(5) Audit/Logging. Log all data release activities, to include identity of releaser, identity of recipient, identity of data released, device identifier (id) (e.g., port id), time, and date of release, modification, or application of security labels.
(6) Fail-secure. Ensure that the operational failure of the Controlled Interface does not result in any unauthorized release of information outside of the IS perimeter.
The Availability Level-of-Concern of each Confidentiality Controlled Interface shall be at least as high as the lowest Availability Level-of-Concern level of the interconnected ISs.
In addition to the requirements imposed upon the Controlled Interface, each interconnected IS that is receiving information shall:(1) Be accredited to process the level(s) and compartment(s) of information that it receives.(2) Provide the features and assurances necessary to ensure that information received is made available only to those authorized to receive the information.
The security requirements imposed upon Confidentiality Controlled Interfaces are less stringent than those imposed upon PL4 or PL5 systems because Confidentiality Controlled Interfaces are more constrained in their operation and function than complete ISs. The information that flows through the Controlled Interface is generally push only or pull only. In those instances where the Controlled Interface supports both push and pull capabilities, some other constraint limits the bandwidth or format of information flowing through (e.g., information may be limited to a fixed format, or users may be limited to a set of fixed-format queries). Where information is flowing between systems approved to process different security levels or compartments and the information flow is not constrained in some manner similar to that described above, then the requirements of PL3, PL4, or PL5 as appropriate shall be applied.
A Controlled Interface facilitating the adjudication of integrity policies shall control all information flows into an interconnected IS. The Controlled Interface shall be required regardless of (1) the Protection Level of the systems comprising the IS; or (2) the Protection Level of the systems comprising the interconnected systems with which it communicates.
At a minimum,* the following integrity policy adjudication features shall be provided [by the controlled interface]:[*One circumstance in which additional security requirements should be considered involves the IS sending information to the Controlled Interface, which in turn is directly connected to another system accessible by users holding a lower clearance. This topic is further discussed in paragraph 9.D.3.c(1).]
(1) Malicious code screening.* Review incoming information for viruses and other malicious code as feasible.[*Having the Controlled Interface review incoming information for malicious code does not relieve the receiving IS from the responsibility of also checking for malicious code.]
(2) Delivery. Ensure that incoming communications have an authorized user (and, as applicable, authorized addresses) as a destination.
(3) Filtering. Support and filter communications protocols/services from outside the perimeter of the interconnected IS according to IS-appropriate needs (e.g., filter based on addresses, identity, protocol, authenticated traffic, and applications).
(4) Proxies. Support, as appropriate, protocol-mediation software (i.e., proxies) that are able to understand and take protective action based on application-level protocols and associated data streams (e.g., filtering FTP connections to deny the use of the put command, effectively prohibiting the ability to write to an anonymous FTP server).
(5) Extensibility. Where appropriate, provide security support for the incorporation of additional system services as they become available.
(6) Auditing/Logging. Log data communications into the interconnected IS, to include identity of sender (e.g., person, end-system), identity of recipient (e.g., IP address, host and user), device id (e.g., port id), data [sic], time, and event.
(7) Fail-secure. Ensure that in the event of the operational failure of the Controlled Interface, no information external to the interconnected IS shall enter the IS.
The Availability Level-of-Concern of each Integrity Controlled Interface shall be at least as high as the Availability Level-of-Concern of the IS into which the information flows are directed.
Controlled Interface Platform Protection Requirements. Unless the DAA provides a written exemption, the platform underlying the Controlled Interface mechanism must be able to isolate and protect the Controlled Interface application.
6.7.2.2 WEB SECURITY
6.7.2.2.1 SECURING WEB CLIENTS
Because of the power of Web technology, the Web client and associated workstation must be appropriately configured and secured. It is particularly important to be sensitive to combinations of unclassified data that in aggregate reveal classified information, and to combinations of information classified at one level that in aggregate reveal more highly classified information.
(1) All certificates* shall be protected via passwords that adhere to DAA guidelines or some DAA-approved biometric mechanism.[*A certificate is an association between an identity and a public key. Certificates are used as a way to verify the authenticity of an organization or individual.]
(2) Only DAA-approved certification authorities* shall issue certificates that are installed on ISs that process intelligence information.[*A Certification Authority is an organization that issues public key certificates.]
(3) If the Web client supports other capabilities (e.g., e-mail, collaborative computing, mobile code) in addition to traditional browser capabilities, then the use of these other capabilities shall be consistent with the appropriate guidelines stated elsewhere in this manual or as called for by the DAA.
In addition, as Web client updates that address known security flaws become available, the ISSO shall ensure that they are implemented as soon as possible.
6.7.2.2.2 SECURING WEB SERVERS
7.D.1 Various technologies such as Web or file transfer protocol (FTP) provide a convenient means for sharing information. Such technologies are examples of push/pull technology, which allow one entity to push information into a location and another entity to pull it from that location. Documents that an organization wishes to share with other organizations could be placed on (pushed out to) an external Web or FTP server (i.e., outside of the organization's IS), and then anyone able to access the server could access (pull off) the information. Documents that an organization wishes to share internally could be placed on an internal Web or FTP server (i.e., within an organization's IS) and then anyone within the organization able to access the server could obtain (pull off) the information.
Because such [Web] servers are by their nature relatively accessible, they are potentially subject to attacks that could result in modification or destruction of the operating system, or insertion of malicious code. To address these concerns, unless the DAA provides written permission to do otherwise:a External servers shall be located external to a site's Controlled Interface (e.g., firewall) or shall be on a network separate from the site's intranet.b The operating services and programs on servers (external and internal) shall be kept to a minimum, and services that are security risks (e.g., tftp, rlogin, rshell) or not required shall be disabled.c The system that supports the server functionality shall, as much as possible, be dedicated to that purpose.d All operating system, protocol and application (e.g., FTP and Web) security patches shall be implemented as soon as possible after they become known and their functionality has been tested.e Remote access to servers by privileged users requires the use of a strong authentication mechanism, and all such accesses shall be audited.
Public Servers. The information that is placed on a public server shall be limited to general access holdings that can be accessed by anyone who has authorized access to the inter/intranet/LAN on which the server resides. Servers employed as public servers shall implement all of the requirements stated in paragraph 7.D.2, above, and no general user accounts shall be permitted on the server.
Restricted Access Servers. The information that is placed on a restricted access server is information which should only be accessed by authorized, authenticated users. In addition to the requirements stated in paragraph 7.D.2, above, restricted access servers shall implement the following security requirements:(1) The underlying operating system shall satisfy the confidentiality requirements of Protection Level 2 or higher, integrity requirements for Basic Level-of-Concern or higher, and availability requirements for Basic Level-of-Concern or higher.(2) Web servers shall implement secure Web technology (e.g., Secure Sockets Layer, Secure HTTP) where capable.(3) Strong authentication shall be required for all users accessing the restricted servers, and all such accesses shall be audited.
6.7.2.3 MOBILE CODE AND EXECUTABLE CONTENT
Until reliable executable content scanning detection technology* is available (as determined by the DAA) to address the security concerns with regard to mobile code or executable content obtained via the Web, the following requirements apply:a All mobile code or executable content employed within an intelligence intranet enclave shall be registered within that enclave unless the DAA authorizes otherwise.b As feasible, organizations shall implement a code review and quality control process for deployed mobile code or executable content and shall be responsible for the mobile code or executable content that they deploy.c For those instances where there is no operational need to download mobile code or executable content, the ISSO or appropriate privileged user shall configure the IS or Controlled Interface to prevent the downloading of mobile code or executable content.d Unless a written exception is granted by the DAA, organizations shall not run mobile code or executable content on mission-critical information systems.
e Downloading of mobile code or executable content from a system that processes information of a different classification level shall only be permitted if a Controlled Interface appropriately configured to handle such a download is in place, and with the written approval of the DAA.
6.7.2.4 ELECTRONIC MAIL
Encryption and E-Mail. E-mail shall conform to the electronic communications and transmission requirements regarding confidentiality stated elsewhere in this manual. In particular, an e-mail message (and associated attachments) shall be appropriately encrypted if during its transmission it may be accessible to individuals who lack either clearance or formal access approval for the information contained in the e-mail (and associated attachments).
a The DAA shall ensure that the threat of viruses in e-mail or attachments is addressed.b Where technically feasible the DAA shall require the use of anti-viral mechanisms to detect and eradicate viruses in incoming and outgoing e-mail and attachments.
The means employed to address the virus threat shall be stated in the SSP.
The use of anti-viral procedures and mechanisms to detect and eradicate viruses transported by e-mail or attachments does not relieve the ISSO of ensuring that there are procedures and mechanisms (e.g., central choke points where diskettes are scanned for viruses prior to distribution within the IS) in place to safeguard against virus infection of the IS from other sources.
6.7.2.5 COLLABORATIVE COMPUTING
Until collaborative computing technologies incorporate security capabilities (e.g., I&A, access control, auditing) to the satisfaction of the DAA, the following requirements apply:
Collaborative computing mechanisms shall be hosted only on systems operating at Protection Levels 1, 2, and 3, and between systems that process information of the same classifications. But hosting collaborative computing mechanisms on systems operating at Protection Level 3 requires the explicit, written approval of the DAA, and the DAA may impose additional technical or other security safeguards as needed.
Collaborative computing mechanisms shall not be remotely activated. Activation requires an explicit action by the workstation user (e.g., in the case of a desktop video teleconference, the user of the desktop shall be required to take an explicit action to turn on the camera and microphone, remote users shall not be allowed to activate a user's camera or microphone remotely).
Peer-to-peer collaborative computing mechanisms between systems operating at Protection Level 2 shall be configured to ensure that only the information on the screen is observable to the remote user. Information located elsewhere on the workstation shall not be observable, nor shall the remote user be able to modify or delete any information on the workstation. These restrictions also apply to any other IS to which the user's workstation is logically connected (e.g., any logically mounted disks).
Collaborative computing mechanisms that provide video and/or audio conference capabilities shall provide some explicit indication that the video and audio mechanisms are operating.
Running collaborative computing mechanisms on mission-critical systems is discouraged and shall require explicit, written DAA approval.
The server portion of the client-server collaborative computing mechanism shall authenticate all users or processes acting on their behalf.
While conducting a collaborative computing session, the user shall take all reasonable measures to ensure that no sensitive information is inadvertently made either audibly or visually accessible to the collaborative computing mechanism. This includes advising all personnel in the immediate area that the collaborative computing mechanism will be operating.
Once the collaborative session is completed, the user shall immediately take an explicit action to disconnect/terminate the collaborative computing mechanism.
Users shall not leave the workstation unattended while a peer-to-peer collaborative computing mechanism is in progress.
6.7.2.6 DISTRIBUTED PROCESSING
Distributed processing systems can be considered single or network systems, and can be handled in accordance with the guidelines provided in Chapters 4, 5, 6, and 8. Distributed parallel processing occurs when an application on one IS divides a task into two or more parts and then sends the parts to the other ISs on the network for processing. This allows the idle CPU cycles on many ISs to be used for CPU intensive calculations. The results are then sent back to the originating IS for final processing. Distributed parallel processing should be restricted to Protection Level 1 and Basic Level of concern networks, and not be permitted on mission critical systems.
6.8 DIAL-UP AND REMOTE ACCESS
Remote diagnostic or maintenance services are acceptable if performed by a service or organization that provides the same level and category(ies) of security as the IS. The communications links connecting the components of the systems, associated data communications, and networks shall be protected in accordance with national policies and procedures applicable to the sensitivity level of the data that may be transmitted over the link.
Remote Access via Modem.3.9.1. Centralize modem management under the NCC according to AFSSI 5027. Do not use modems in any PC or laptop computer while physically connected to the base network. Stand-alone PCs may use modems when approved by the DAA (i.e., Bulletin Board).
All Dial-up circuits to Marine Corps systems will be secured according to the requirements specified below. Dial-up circuits used to gain access to applications which run on MCDN hosts will be supported in the following manner:a. All Dial-up communications will be controlled through: - ACF/VTAM using IBM's Synchronous Data Link Control (SDLC) protocol or, - authorized asynchronous methods described in paragraph 11.6.4. or, - approved alternatives as stated in paragraph 11.6.5.b. All dial-up access into MCDN must be approved by MCCDC (Code AS) prior to implementation.
If remote diagnostic or maintenance services are required from a service or organization that does not provide the same level of security required for the system being maintained, the IS shall be sanitized and physically separated from other information systems prior to the connection of the remote access line. If the system cannot be sanitized (e.g., due to a system failure), remote maintenance shall not be allowed.
c. Network Software Associates, Inc.'s Adaptasynch has been evaluated by the Marine Corps Central Design Activity (CDA), Quantico and has been determined to provide the necessary security requirements for entry into MCDN for asynchronous terminals.d. Dial-up access using the SDLC protocol or Adaptasynch will adhere to the following: (1) All dial-up resources will be named using MCDN naming standards as specified in IRM-5234-07, DATA CENTER IDENTIFICATION STANDARDS. That is, dial-up terminal resource ID's will have a "D" in their third position (e.g., GGD74A00). (2) All dial-up resources will be defined as TERMINALs and controlled by CA-Top Secret (CA-TSS). Ownership of these resources (i.e., TERMINALs) will be assigned to the CSSO of the local MCDN host computer. (3) All non-LAN dial-up access will be accomplished by dialing into a port on a front end processor (FEP) at a MCDN node (i.e., physical unit type 4). VTAM is the authentication system used for SDLC dial-up and Adaptasynch is used for asynchronous dial-up.
Initiation and termination of the remote access shall be performed by the ISSO or designee. Keystroke monitoring shall be performed on all remote diagnostic or maintenance services. A technically qualified person shall review the maintenance log, and if appropriate, the audit log to assure the detection of unauthorized changes. The ISSM/ISSO shall assure that maintenance technicians responsible for performing remote diagnosis/maintenance are advised (e.g., contractually, verbally, or by banner) prior to remote diagnostics/maintenance activities that keystroke monitoring will be performed.
...Unless an exception has been granted by the DAA, maintenance personnel accessing the information systems at the remote site shall be cleared to the highest level of information processed on that system, even if the system was downgraded/sanitized prior to remote access.
...Installation and use of remote diagnostic links shall be specifically addressed in the SSP and agreed to by the DAA.
...An audit log shall be maintained of all remote maintenance, diagnostic, and service transactions including all commands performed and all responses. The log shall be periodically reviewed by the ISSO.
In addition, other techniques to consider for improving the security of remote maintenance include encryption and decryption of diagnostic communications, strong identification and authentication techniques, such as tokens, and remote disconnect verification. Where possible, remote sessions should involve an interactive window for coordination with the information system's ISSM or ISSO. When the work has been completed, the sessions are terminated and the remote connection is physically broken.
Passwords used during the maintenance process shall be changed following each remote diagnostic maintenance service. All passwords are assigned and controlled by the information system's ISSM or ISSO.
Procedures will be established to control both on-site and remote access of personnel assigned to conduct performance maintenance. Procedures will be established to control and audit remote access and the use of remote system diagnostics under routine and emergency cases. Use of remote diagnostics is authorized for information systems that process sensitive but unclassified information only when some form of enhanced identification and authentication is used. The use of remote system diagnostics for systems that process classified information is authorized only when the transmission paths are encrypted using NSA endorsed equipment and key material and all maintenance personnel have the appropriate security clearance.
3.9.2. The security requirements (e.g., I&A, audit, etc.) of the local information system also apply to systems allowed to remotely access that information system.3.9.3. Make sure that access tables, when used, remain current.3.9.4. Prohibit the use of call-forwarding capabilities when using callback or dialback technology.3.9.5. Annotate remote access in the audit logs.3.9.6. Do not publicize telephone numbers to anyone other than those with a need to know.3.9.7. Employ methods for controlling access (e.g., callback, token generation, etc.) where the capability exists.
e. All dial-up access from remote sites using asynchronous communications to the MCDN via a Local Area Network (LAN) will adhere to the following: (1) LANs and microcomputers which have connections into MCDN may be configured to allow dial-up access into MCDN via the connection using the asynchronous product Banyan Vines "PC Dial-In" or an approved alternative; (Paragraphs 11.6.4. and 11.6.5. apply). (2) MCDN nodes are responsible for ensuring compliance with this provision prior to providing a connection to MCDN. The node will review the LAN's and microcomputer's configuration for compliance. Nodes will periodically audit LANs and microcomputers connected to their MCDN node in support of the site accreditation process.
Allow remote software diagnostics or maintenance only if the information system audits such activities or an appropriately cleared individual (capable of identifying unauthorized activity) observes such activities. When maintenance activities are suspended or completed, disconnect or disable access to the information system. Additionally, verify the identity of the maintenance personnel to prevent the unauthorized disclosure of sensitive and classified information.
f. Minicomputers, word processors and office automation equipment, excluding LAN servers, configured to emulate IBM 3270 control units (i.e., physical unit types 1 & 2) will not be configured to allow dial-up access into MCDN through their ports. MCDN nodes are responsible for ensuring compliance with this provision through regular audits and inspections of their subnetworks. These audits and inspections will be included in the site accreditation process required by MCO P5510.14.
g. AIS applications designed to run on MCDN hosts will be designed so that they use standard, formatted IBM 3270 screens. Unformatted screens will not be used.
Asynchronous Dial-Up (Class C2 or Above). Asynchronous Dial-up circuits that allow access to other computer-based systems (e.g., microcomputers, maintenance ports on communication processors and mainframes, local area networks, etc.), which have been certified to meet Class C2 or above criteria as specified in DoD 5200.28-STD, require no additional security provided the Class C2 features and functions have been fully and effectively implemented.
Asynchronous Dial-Up (Non-Class C2). Asynchronous dial-up circuits that allow access to other computer-based systems which have not been certified to meet the Class C2 or above criteria in DoD 5200.28-STD or where the Class C2 features and functions have not been implemented, will be secured in one of the following ways: a. Dial-up communication ports will be protected using an authentication or encryption device which requires unique identification and accountability of authorized dial-up users. b. If no authentication or encryption device is used, communication ports will be disconnected from the circuit when not in use in a manner which prevents unmonitored dial-up access. Auto-answer modems will not be used unless the circuit is physically disconnected from the modem when a session is not active.
a. The only approved Marine Corps method of establishing asynchronous dial-up communications to a LAN or to MCDN through a LAN is the Banyan Vines "PC Dial-In" option.b. The minimum password length for any Banyan Vines account is seven characters and must be changed at least every 30 days. This restriction should be established at the group security level.c. Users requiring dial-up access must be explicitly granted permission for such access.d. No automatic logon and password entry procedures are authorized.
Marine Corps organizations desiring to procure products for asynchronous communications other than the Banyan Vines "PC Dial-In" option or Network Software Associates' Adaptasynch, must provide justification to MCCDC (Code AS) for approval prior to implementation. The alternative product justification should clearly state the functionality that is not provided by the "PC Dial-In" option or Adaptasynch that necessitates the request and should describe the product and its security features.
Call back systems provide marginal access protection. Do not use telephones with call forwarding capability in call back systems.
6.9 COMMUNICATIONS WITH CONTRACTORS
Classified and SBU communications between Army activities and contractors will be protected per this regulation. Procedures for contractors to procure the necessary equipment will be published by DISC4.
7.0 SPECIAL PROVISIONS
7.1 PERSONALLY OWNED COMPUTERS AND OFF-SITE PROCESSING
Do not use personally owned hardware or software to process classified information. Using personally owned hardware and software for government work is strongly discouraged; however, it may be used for processing unclassified and sensitive information with DAA approval (see AFI 33-112, Computer Systems Management; and AFI 33-114, Software Management). (NOTE: Document blanket approvals for the purpose of telecommuting in a local operating instruction.) Base approval on the following requirements:3.10.4.1. The written approval specifies the conditions under which the information system operates.3.10.4.2. When using a personally owned information system for official work, the system must employ anti-virus software, government-owned sensitive information must remain on removable media, and government-owned sensitive information must be marked and protected according to the sensitive category (e.g., Privacy Act, For Official Use Only [FOUO], etc.) program directives.
Privately owned systems are not authorized to process classified information. Additionally, privately owned software or public domain software from non-government sources is not authorized to process classified information. This security measure is intended to prevent a computer virus or any form of system contamination from occurring. Classified information will only be processed on U.S. Government equipment, in secured work spaces, and handled in accordance with applicable directives.
Personally owned hardware or software will not be used in the official conduct of government business nor will it be installed on DISA information assets for personal use or gain. Additionally, use of entertainment and games software is prohibited. When expressly permitted to work at home, personally owned hardware and/or software may be used. However, when permitted to work at home, such approval must specifically establish the conditions under which permission is given and provide guidance regarding system use and security (particularly if the user is processing sensitive but unclassified information).
Army Regulation 25
The use of privately owned computers (those not owned or leased by DISA or a DISA contractor) to process classified information is absolutely prohibited.
Army Regulation 25
7.2 TACTICAL OR BATTLEFIELD AUTOMATION SYSTEMS
Tactical or Deployable Systems. A tactical system may be part of a fixed location or maintained in a deployable configuration so that it can be moved quickly to another location to support operational mission requirements. The system can operate in a stand-alone mode or be attached via communications to a mobile or fixed facility under an extended LAN or WAN configuration. Tactical systems shall provide the appropriate Protection Level and Levels-of-Concern based upon the operating environment, network connection requirements, portability, and degree of access to other systems. The Protection Level and Levels-of-Concern shall be applied while the system is in-garrison, in-transit, and/or deployed. The DAA may require additional security requirements or safeguards for tactical systems while in-transit or in the deployed environment.
The requirements of this regulation apply to Battlefield Automation Systems (BAS), to include all systems developed under the PEO/PM structure. When one or more of the minimum security requirements from paragraph 2
Prior to deployment or fielding, BAS will be generically accredited in accordance with chapter 3. Any BAS which also function as peacetime systems must fully comply with this regulation. Their accreditation must address operation in both garrison and deployed modes.
The following additional items must be considered in the security planning for BAS:(1) Physical security objectives and safeguards (para 2
7.3 LAPTOP, NOTEBOOK, OR PORTABLE AIS
An unclassified portable IS (including personally owned ISs) is prohibited in a SCIF unless the DAA specifically permits its use. If permitted, all personnel shall adhere to the following procedures:(1) Connection of an unclassified portable IS to a classified IS is prohibited.(2) Connection of an unclassified IS to another unclassified IS may be done only with the DAA's written approval.(3) Use of an internal or external modem with the IS device is prohibited within the SCIF without the DAA's written approval.(4) The portable ISs and the contained data are subject to random reviews and inspections by the ISSO/ISSM. If classified information is found on the portable IS it shall be handled in accordance with the incident handling policy.
Laptop/notebook computers or any other computers designed to allow periodic relocation must be accredited in accordance with chapter 3 of this regulation by the appropriate DAA. The DAA may accredit more than one computer on one document.
The DAA will indicate on the accreditation document exactly where the computer may be taken and the kind of classified material that may be stored on the computer. Users of the portable computer must follow the accreditation instructions at all times, and users must possess a copy of the accreditation documentation at all times when the computer is removed from their regular place of work.
Any media or other material produced by the computer must be handled and stored by users of computers in accordance with AR 380
Accreditation for laptop or notebook computers generally must address processing in the user's normal work location and in the official travel location. If classified processing is included in the accreditation, TEMPEST (inspectable space) requirements must be addressed for the normal work location. When approval has been granted to process classified information at a temporary location for more than 90 days, a TEMPEST Countermeasures Review must be performed for that location per AR 381
If a [lap-top or portable] computer contains a non-removable hard disk that stores classified material, the entire computer must be stored in an approved storage area at all times that the computer is not in the possession of the user.
If the [lap-top or portable] computer configuration includes non-removable hard disks that store classified material, the entire system must be stored in an area approved for storage of the highest classification of information the system is accredited to process when left unattended. The provisions of paragraph 2
If the accreditation document so provides, classified processing may be done on laptop or notebook computers if it occurs in normal work areas otherwise acceptable for the storage, preparation, or discussion of classified material. The accrediting authority may limit the classified processing to the user's regular place of work or, in cases of compelling operational need, may include approved areas while at a Temporary Duty (travel) (TDY) location. In the latter case, the user will carry a copy of the accreditation statement while on TDY. Media or output products produced must be handled per this regulation and AR380-5, including marking and storage standards.
Personnel will not be allowed to enter and exit sensitive compartmented information facilities with laptop/notebook or other portable computers unless approval has been granted by the local special security officer (SSO), after coordination with the site ISSO.
7.4 CONTRACTORS
Contractor-owned or -operated hardware and software must meet all security requirements for government-owned hardware and software. AFI 31-601, Industrial Security Program Management, provides security policy and guidance relating to contractor actions involving classified information. DoD Manual 5220.22 (DoD 5220.22-M), National Industrial Security Program Operating Manual, January 1995, applies to off-base contractor information systems and on-base contractor facilities when the Air Force does not have responsibility for industrial security inspections. If DoD 5220.22-M applies, Defense Investigative Service approval is mandatory before processing classified information. If the contractor must comply with this instruction instead of the manual, the Air Force must provide the contractor with specifications that establish contractor and Air Force responsibilities for security, including who should conduct the information system C&A and who the DAA is for the system. The program or project manager, contracting or procurement officer, and appropriate COMPUSEC personnel should jointly develop this guidance.
Classified and SBU communications between Army activities and contractors will be protected per this regulation. Procedures for contractors to procure the necessary equipment will be published by DISC4.
Contractors utilizing AIS within a contractor SCIF that is intended to process or store SCI in support of Army SCI contractual efforts will refer to DIAM 50
Supporting contractor support detachments (CSDs) or the 902d MI Group may approve the entry of processing equipment into contractor SCI facilities (SCIFs). This approval does not constitute processing approval. Department of Defense (DD) Form 254 (Contract Security Classification Specifications) and other contractual documents will require appropriate TEMPEST countermeasures to be applied in the contract (see AR 381
7.5 TENANT UNITS OR ACTIVITIES
Implementing the AISSP in installation or installation-equivalent environments involving host and tenant units or activities requires thorough coordination between the host and tenant ISS personnel. Army tenant units or activities must comply with this regulation and the ISS requirements of their parent MACOM. Army tenant's and non-Army tenant's AIS operations must comply with the host installation ISS policy that does not conflict with their parent command/activity or agency ISS policy and that does not impede their operational mission objectives.
Non-Army tenants must comply with the host installation security requirements if they connect to the installation's information infrastructure. This includes the use of gateways or information management resources as pathways to connect their information systems. If the non-Army tenant uses any part of the host installation IMP infrastructure, the host installation ISSM will require the use of configuration management control consistent with the installation's information management and configuration management process.
Conflicts of ISS policy that cannot be resolved per this regulation should be addressed through local command channels to HQDA, DISC4.
Host installation ISSM will
Army tenant activities will
7.6 USE OF OTHER SERVICE OR AGENCY IS
Other Service or Agency Owned (NOTE: Where a lead service is other than the Air Force, some protection requirements may not be achievable). Develop an agreement before using equipment and facilities owned or operated by other services or agencies to ensure:3.10.2.1. Air Force use of other services' or agencies' resources does not degrade the required security posture.3.10.2.2. Mission-critical processing takes priority.3.10.2.3. The lead service (in joint-service activities) identifies the DAA for the information system and determines security requirements for the information systems supporting the activity.3.10.2.4. Satisfying Air Force requirements in this instruction for the protection of Air Force information.
7.7 USE OF FOREIGN OWNED IS
Do not use foreign-owned or -operated (e.g., joint/coalition) information systems to process sensitive or classified information or for critical processing, unless required by international treaties or security agreements.
8.0 SPECIAL CATEGORIES OF SCI ISs
a This subsection describes several categories (e.g., dedicated servers, embedded systems, tactical systems) of ISs that can often be adequately secured without implementation of all the technical features specified in Chapters 4, 5, and 6. These systems are not exceptions or special cases of the requirements specified in Chapters 4, 5, and 6.b Unthinkingly applying the technical security requirements specified in Chapters 4, 5, and 6 to these ISs could result in unnecessary costs and operational impacts. In general, the technical question is where, when, and how to apply a given set of safeguards, rather than whether to apply the safeguards. For many of these special ISs (such as dedicated servers, and tactical, data acquisition, and embedded systems), the physical security protections for the IS provide the required access control, while the application running on the platform provides the required user separation.c These special systems still must undergo the C&A process (including risk management) described earlier in this chapter. A key part of that C&A process for these systems is determining whether all of the technical features specified in Chapters 4, 5, and 6 are applicable.
Dedicated Serversa Certain specialized ISs, when acting as part of a network as dedicated servers, may need fewer technical security countermeasures. These ISs have the characteristics listed below: (1) No user code is present on the IS. (2) Only IS administrators and maintainers can access the system. (3) The IS provides non-interactive services to clients (e.g., packet routing or messaging services). (4) The hardware and/or application providing network services otherwise meets the security requirements of the network. (5) The risk of attack against the Security Support Structure using network communications paths is low. (6) The risk of attack against the Security Support Structure using physical access to the system itself is sufficiently low.
b The platform (i.e., hardware and operating system) on which the dedicated server runs usually needs meet no more than Protection Level 2 security requirements. The dedicated server may have a large number of clients (i.e., individuals who use the server's functional capabilities in a severely constrained way). The server application itself will have to provide the more stringent technical protections appropriate for the system's Protection Level and operational environment. Assurances appropriate to the Protection Level and Levels-of-Concern for the IS shall be implemented.
c An IS that does have general users or does execute general user code is not a dedicated server within the meaning of this section, and so shall meet all security requirements specified for its Protection Level and operational environment.
d The term "dedicated server" is not intended to limit the applicability of this section to systems that have traditionally been referred to as servers. For example, a messaging system implemented on a general-purpose computer platform could be accredited under this manual and, if such a system meets the specifications in a., above, the system's technical requirements could be characterized by this section.
e The use of the above technical security requirements does not imply any relaxation in other security requirements (e.g., physical and communications security requirements), which are determined by the information handled or protected by the IS. Changes to technical requirements are predicated upon adequate application of physical security and other appropriate security disciplines.
Embedded and Special-Purpose ISs. Some ISs have no general users, are incapable of alteration by users, and are designed and implemented to provide a very limited set of predetermined functions. For such ISs, if the DAA determines that the applications running on the IS provide an adequate level of security, then the security requirements specified in Chapters 4, 5, and 6 do not apply.
[Edit footer.html to set your custom footer here]
Current URL: http://compliancemanager.com/ModelStore/ModelPreview?ModelStoreId=fec3075e-1484-41a1-9c0e-10109ebe9b80 Base URL: http://compliancemanager.com/ Current URL Domain Name: compliancemanager.com
1.0 GENERAL
Security policy shall be considered throughout the life cycle of an AIS from the beginning of concept development, through design, development, operation, and maintenance until replacement or disposal.