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
Intelligence information shall be appropriately safeguarded at all times, including when used in information systems.
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.
Appropriate security measures shall be implemented to ensure the confidentiality, integrity, and availability of that information.
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.
Data processed, stored and transmitted by information systems shall be adequately protected with respect to requirements for confidentiality, integrity, availability and privacy.
Classified information and sensitive unclassified information shall be safeguarded at all times while in AISs.
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.
Controls will be established to identify, control, and protect information, particularly classified information, from unauthorized disclosure.
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.
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).
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.
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.
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.
Different or more stringent requirements for securing national security information should be incorporated into agency programs as required by appropriate national security directives.
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 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.
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.
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.
Security safeguards should be embedded into design of AIS to ensure a secure infrastructure.
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.3.1 SCI LEVELS OF CONCERN AND PROTECTION LEVELS
1.3.1.1 DETERMINING THE LEVEL-OF-CONCERN
CONFIDENTIALLY
INTEGRITY
For each IS, assurance commensurate with the Integrity Level-of-Concern shall be provided.
AVAILABILITY (3.B.2.c)
For each IS, assurance commensurate with the Level-of-Concern for Availability shall be provided.
1.3.1.2 DETERMINING PROTECTION LEVELS
The concept of Protection Levels applies only to confidentiality.
The DAA must assign a Protection Level to each IS that is to be accredited.
1.3.1.3 DETERMINING SECURITY FEATURES AND ASSURANCES
DAA needs to ascertain the specific technical security requirements and assurances for confidentiality, integrity and availability
Systems will be operated in "Systems High Mode".
The planned or implemented system security mode of operation must be defined.
Systems processing unclassified may operate in several modes depending on system capabilities and security requirements.
The decision regarding the Levels-of-Concern shall be explicit for all (including interconnected) systems.
In order to be certified and accredited, each IS must conform to a set of technical security requirements for confidentiality, integrity, and availability.
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 shall provide automated Controlled Access Protection for all classified and sensitive unclassified information.
The following risk assessment procedure extracted from CSC-STD-003-85 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.
Information systems that process classified and/or sensitive but unclassified information will comply with the minimum requirements for controlled access protection.
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.
Use computer-based security features to satisfy security requirements for information systems.
Use products evaluated by the National Computer Security Center (NCSC) listed on the Evaluated Products List.
Use products formally assessed by HQ AFCA listed on the Assessed Products List.
Select a suitable product, then test and certify its security features according to AFSSI 5024VII.
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).
The AIS will be categorized based on the sensitivity of information that the system is authorized to process or store.
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.
A system operating at Protection Level(s) [1-5] shall employ features for Access control.
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.
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.
In system high, controlled, multilevel and multi-user security modes, the system must operate so users can access only authorized information.
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.
An owner or proponent will be identified for each file or data grouping on the AIS throughout its Life Cycle.
Each data base, file, or data set must have an origin, use, and a defined set of access controls.
The DBMS should provide file control and protection (paragraph 6.3)
A terminal/desktop/laptop screen-lock functionality shall be associated with each terminal/desktop/laptop computer.
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.
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.
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.
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.
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.
Protect against unauthorized web browser 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.
Disable ActiveX and Java features when visiting untrusted sites (non-.gov or -.mil sites).
Networks and systems must automatically terminate sessions after periods of inactivity.
Limit the number of unsuccessful attempts to access a network or networked system and lock out further attempts.
Verify system(s) operating at Protection Level(s) [2-5] employ the appropiate features for the Enforcement of Session Controls, including:
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.
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.
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).
Only specifically identified personnel authorized by management are allowed access to system utilities provided by the operating system software or other add-on software.
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 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 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.
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 Access control, including a Discretionary Access Control (DAC) Policy.
The DAC mechanism shall, either by explicit user action or by default, provide that objects are protected from unauthorized access.
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.
The discretionary access control mechanism shall, either by explicit user action or by default, provide that objects are protected from unauthorized access.
The discretionary access control mechanism shall, either by explicit user action or by default, provide that objects are protected from unauthorized access.
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 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.
Cryptography may also be used to separate compartments or protect "need-to-know" among cleared users on classified systems.
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.
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.
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).
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.
2.2.4.1 LABEL INTEGRITY
The TCB shall designate each communication channel and I/O device as either single-level or multilevel.
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).
Single-level I/O devices and single-level communication channels are not required to maintain the sensitivity labels of the information they process.
The ADP system administrator shall be able to specify the printable label names associated with exported sensitivity labels.
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.
The TCB shall support the assignment of minimum and maximum security levels to all attached physical devices.
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.
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).
A system operating at Protection Level(s) [4-5] shall employ the following features: Access Control, including a Mandatory Access Control (MAC) Policy.
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.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.
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.
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
2.5.1 TRUSTED PATH
The TCB shall support a trusted communication path between itself and user for initial login and authentication.
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).
A system operating at Protection Level(s) [2-5] shall employ 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.
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.
Follow identification and authentication procedures according to AFMAN 33-223, Identification and Authentication.
A system operating at Protection Level 1 shall employ Identification and Authentication (I&A) procedures that include provisions for uniquely identifying and authenticating the users.
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.
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.
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.
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.
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.6 AUDIT
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.
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.
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.
Implement auditing according to AFMAN 33-229 for C2 criteria class information systems.
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.
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 security profile (e.g., access controls, security level of the subject, user password, etc.).
Audit trail files must be protected to prevent unauthorized changes or destruction.
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.
2.7 ASSURANCE
2.7.1 SYSTEM ARCHITECTURE
2.7.2 SYSTEM AND DATA INTEGRITY AND AVAILABILITY
2.7.2.1 SYSTEM BACKUP AND RECOVERY
2.7.2.2 TRUSTED FACILITY MANAGEMENT
2.7.2.3 COVERT CHANNEL ANALYSIS
2.7.3 SECURITY TESTING
3.0 MANAGEMENT AND PROCEDURAL
3.1 GENERAL
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.
(6) Ensure an effective information system security education, training, and awareness program is in place.
(7) Ensure that data ownership is established for each information system, to include accountability, access rights, and special handling requirements.
(8) Appoint a Component Information System Security Manager (CISSM).
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.
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.
ISSOs are responsible to the DAA for maintaining the approved accredited baseline and 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.
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.
(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.
(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.
3.2 LIFE-CYCLE MANAGEMENT
3.2.1 RISK MANAGEMENT
3.2.2 SECURITY REQUIREMENTS
3.2.3 SECURITY PLANS
3.2.4 SECURITY SPECIFICATIONS
3.2.5 SYSTEM AND SOFTWARE DESIGN AND DEVELOPMENT
3.2.6 SYSTEM ACCEPTANCE
3.2.7 SYSTEM OPERATION
3.2.7.1 SYSTEM MAINTENANCE
3.2.8 CONFIGURATION MANAGEMENT
3.3 CERTIFICATION AND ACCREDITATION
3.3.1 ACCREDITATION
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.
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.
(2) Prepare a Statement of Compliance with the Security Requirements in chapter 2.
(3) Prepare a Security Plan (see figure 3-1).
(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.
(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.
(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.
3.3.2 TYPES OF ACCREDITATION
3.3.2.1 GENERIC OR TYPE ACCREDITATION
3.3.2.2 OPERATIONAL ACCREDITATION
3.3.2.3 SYSTEM BASED ACCREDITATION
3.3.2.4 SITE BASED ACCREDITATION
3.3.2.5 ACCREDITATION OF LAPTOPS AND PORTABLE AIS
3.3.2.6 ACCREDITATION OF SCI SYSTEMS
3.3.2.7 SCI C&A PROCESS
3.3.2.8 EXCEPTIONS FOR SCI SYSTEMS
3.3.3 CERTIFICATION
3.3.4 REVIEW AND REVISION REQUIREMENTS
3.4 RULES OF THE SYSTEM
3.5 DOCUMENTATION
3.5.1 SECURITY DOCUMENTATION
3.5.2 DESIGN AND TEST DOCUMENTATION
3.5.3 ACCREDITATION DOCUMENTATION
3.6 ACCESS CONTROL PROCEDURES
3.7 PASSWORD CONTROL
3.7.1 GENERAL
3.7.2 PASSWORD MANAGEMENT
3.7.3 PASSWORD STANDARDS
3.7.4 USER BRIEFING
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.
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 maintain 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.
3.9 PROTECTION AND DISPOSITION OF IS MEDIA & SOFTWARE
3.10 CONTINGENCY PLANS
3.11 INCIDENT RESPONSE CAPABILITY
4.0 PHYSICAL SECURITY
4.1 GENERAL
4.2 FACILITIES
4.3 INFORMATION SYSTEMS AND EQUIPMENT
4.3.1 REMOTE TERMINALS OR WORKSTATIONS AND PCs
4.4 MARKINGS
5.0 PERSONNEL SECURITY
5.1 CLEARANCES
5.1.1 MAINTENANCE PERSONNEL
5.1.2 FOREIGN NATIONALS
5.1.3 REVOCATION OF ACCESS
5.2 SECURITY TRAINING
6.0 COMMUNICATIONS SECURITY
6.1 POLICY
6.2 CLASSIFIED COMSEC REQUIREMENTS
6.3 SENSITIVE COMSEC REQUIREMENTS
6.4 PROTECTED DISTRIBUTION SYSTEM (PDS)
6.5 RADIO SYSTEMS
6.6 TEMPEST AND TSCM
6.7 SYSTEM INTERCONNECTION AND NETWORKS
6.7.1 CONNECTIONS WITH FOREIGN NATIONAL IS
6.7.2 INTERCONNECTED SCI ISs AND ADVANCED TECHNOLOGY
6.7.2.1 CONTROLLED INTERFACE
6.7.2.2 WEB SECURITY
6.7.2.2.1 SECURING WEB CLIENTS
6.7.2.2.2 SECURING WEB SERVERS
6.7.2.3 MOBILE CODE AND EXECUTABLE CONTENT
6.7.2.4 ELECTRONIC MAIL
6.7.2.5 COLLABORATIVE COMPUTING
6.7.2.6 DISTRIBUTED PROCESSING
6.8 DIAL-UP AND REMOTE ACCESS
6.9 COMMUNICATIONS WITH CONTRACTORS
7.0 SPECIAL PROVISIONS
7.1 PERSONALLY OWNED COMPUTERS AND OFF-SITE PROCESSING
7.2 TACTICAL OR BATTLEFIELD AUTOMATION SYSTEMS
7.3 LAPTOP, NOTEBOOK, OR PORTABLE AIS
7.4 CONTRACTORS
7.5 TENANT UNITS OR ACTIVITIES
7.6 USE OF OTHER SERVICE OR AGENCY IS
7.7 USE OF FOREIGN OWNED IS
8.0 SPECIAL CATEGORIES OF SCI ISs
[Edit footer.html to set your custom footer here]
Current URL: http://compliancemanager.com/ModelStore/ModelPreview?ModelStoreId=d735811b-cf54-44b2-bc0b-b583a9ee206c 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.