Attachment 8 - Risk Management Framework (RMF) Package Format.xlsx
XLSX spreadsheet 3 MB Posted
- Attached to
- UNITED STATES MARINE CORPS (USMC) MARINE COMMON AIRCREW TRAINER MODERNIZATION PROGRAM (MCAT MP)
- Solicitation number
- N6134024R0007
About this file
This document is an attachment titled "Attachment 8 - Risk Management Framework (RMF) Package Format.xlsx" that provides a template and instructions for the assessment and accreditation package for a U.S. Marine Corps simulation training device.
The document outlines the system description, project details, system interfaces, security requirements, assessment objectives, and required artifacts for the assessment and accreditation process. It specifies the need to meet Defense Level 3 (DL3) security control requirements and provides details on access control, audit and accountability, and security awareness and training controls. The document is classified at the highest level of the system and requires the inclusion of several assessment outputs and plans as artifacts.
View the file
Other files
Show all 18
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Cover Sheet
United States Marine Corps
| Assessment and Accreditation (A&A) |
| PACKAGE TEMPLATE |
DISTRIBUTION STATMENT D - DISTRIBUTION AUTHORIZED TO U.S. GOVERNMENT AGENCIES AND THEIR U.S. DOD CONTRACTORS ONLY (ADMINISTRATIVE OR OPERATIONAL USE) (10 MAR 2020). OTHER REQUESTS FOR THIS DOCUMENT SHALL BE REFERRED TO THE COMMANDING OFFICER, NAVAL AIR WARFARE CENTER TRAINING SYSTEMS DIVISION (NAWCTSD), 12211 SCIENCE DRIVE, ORLANDO, FL, 32826-3275.
System Registration
| System Registration | ||
| Project Definition | ||
| Acronym: | ||
| System Description: | The _______ device number _____ is the subject of this accreditation. The device will be located at ________. |
Department of Defense (DoD) policy dictates that all information systems processing Classified and/or Sensitive information be designed, developed, and implemented taking into account appropriate security safeguards that allow the system to operate at an acceptable level of risk and still meet Certification and Accreditation (C&A) requirements. DoD Directive (DoDD) 8500.1, Information Assurance, mandates C&A of information systems, including standalone personal computers, connected systems, and networks.
The ________ simulates the necessary functions required by a pilot and co-pilot to fly the aircraft. It replicates the full size attack helicopter cockpit. It includes aircraft operational tactical hardware equipment where commercial functional equivalent is not feasible. It includes the following main components: Instructior Operator Station (IOS), Image generator, Tactical Environment Network (TEN), Host (provides simulation), and Software Support Environment (SSE), and Motion Computer.
The _________ will have one external connection to the classified ADVTE network. This is the only external connection outside of the accreditation boundary.
| Assessment Objective: | ATO or ATO/ATC | |
| Estimated Completion Date: | ||
| Project Information Detail | ||
| System ID: | (DIPR-DON #) | |
| System Component: | NAVAIR PMA-205 | |
| Governing DoD Component IA Program: | HQMC | |
| C&A Activity: | Initiate and Plan IA A&A | |
| System Life Cycle or Acquisition Phase: | MS-B System Development and Demonstration | |
| System Operation: | GOGO | |
| Project Milestones | ||
| Add dates for the following (additional milestones can be added if needed): | ||
| 1. Initial Controls Submittal | ||
| 2. Initial Scan & Patch | ||
| 3. Final Scan & Patch | ||
| 4. Final Validation Scans | ||
| 6. RFT Date | ||
| System Boundary | ||
| Simple Network Diagram | Must show the following: |
1. All computational systems, routers, external connections, data flow information
2. Color Code computational Systems (Blue-IA Enabled; Green-IT Appliance)
| Insert Diagram Here | ||
| System Environment | ||
| General | ||
| Name: | ||
| Description: | Trainer is located in builing _____. The trainer building is located within a secure area of Camp Pendleton marine Corps Base. Access by the general public is not permitted. | |
| Threats | (Auto populated) | |
| Geography | ||
| Site: | ||
| Bldg: | ||
| Room: | ||
| City: | ||
| State: | ||
| Country: | ||
| System Interfaces | ||
| Complete System Interfaces template below (double click green area below): | ||
| Insert File Here | ||
| System Data Flow Worksheet | ||
| Complete Data Flow Worksheet below: | Create a spreadsheet with the following columns (Only for IA Enabled systems): Name, Port (if there is no port, leaving it blank is fine), Protocol, Description. |
Ex:
Host to IG; 5000, 5001; UDP; CIGI control packets that impact the visual scene and Image Generator functions, and CIGI request packets for Line Of Sight and Height Of Terrain.
| System Secruity | ||
| Confidentiality: | Low | |
| Integrity: | Low | |
| Availability: | Low | |
| Classification Level: | ||
| Mission Criticality: | Mission Support |
Requirements Selection Requirements Selection
Insert Artifact Here
Inventory & System Information Inventory & System Information
| Equipment Inventory | ||
| 1. | Create matrix table of equipment (Computational Systems, Network devices, and Printers) to installed S/W | Insert Artifact Here |
| Manage Project Artifacts | ||
| 1. | COOP/Contigency Plan | Insert Artifact Here |
| 2. | Configuration Management Plan | Insert Artifact Here |
| 3. | Incident Response Policy/Plan | Insert Artifact Here |
| 4. | System Security Plan | Insert Artifact Here |
| 5. | Simple Network Diagrams - original (Visio) and jpg/png formats | Insert Artifacts Here |
| 6. | Detailed Network Diagrams - original (Visio) and jpg/png formats | Insert Artifacts Here |
| Manage Software | |||
| ` | 1. | Create table of installed S/W | Insert Artifact Here |
Self Assessment
| Self Assessment | ||||
| ****This is CLASSIFIED at the highest level of the system**** | ****This is CLASSIFIED at the highest level of the system**** | ****This is CLASSIFIED at the highest level of the system**** | ||
| 1. | Provide ACAS .nessus file | Insert .nessus file(s) | ||
| 2. | Provide output from SCAP benchmarks | Insert SCAP results | ||
| 3. | Provide output from STIG Viewer .ckl file | Insert Checklist | ||
| 4. | Create POA&M from above results with comments for all Open and Not Reviewed findings | Insert POA&M |
****This is CLASSIFIED at the highest level of the system****
POA&M
| POA&M | |||
| ****This is CLASSIFIED at the highest level of the system**** | |||
| Update POA&M created during Self Assessment with latest results | Insert updated POA&M | ||
| ****This is CLASSIFIED at the highest level of the system**** |
CSAG
IASAG
Cybersecurity System Admin Guide Insert Artifact Here
MFR
MFR
Memorandum For The Record (MFR) Insert Artifact Here
VCTRS
VCTRS
Vendor Compliance Test Report for Software (VCTRS) Insert Artifact Here image1.jpeg
Microsoft_Excel_Worksheet.xlsx Sheet1
System Interfaces
Name: Port: Protocol: External IP: Internal IP: Direction: Classification: Description:
TEN 40001,40011,40021,40031, 40041 UDP Multicast Insert IP of Host Here bi-directional HLA communication image2.emf
Microsoft_Excel_Worksheet1.xlsx System Data Flow
Computer Communication Flow Network VLANs Protocol Port Description image3.emf
Simple Network Diagram.png image4.emf
Microsoft_Excel_Worksheet2.xlsx M-M-L Baseline
CNSSI 1253 Security Controls
Overlay Applied: Classified Systems
Defense Level Selection: Defense Level 3 Moderate-Moderate-Low
Control ID Title Control Text Supplemental Guidance Assignment Value Defense Level Comments Sensitive Classified Contractor Implement
AC-1 Policy and Procedures The organization:
a. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles]:
1. [Selection (one or more): Organization-level; Mission/business process-level; System-level] access control policy that:
(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and
2. Procedures to facilitate the implementation of the access control policy and the associated access controls;
b. Designate an [Assignment: organization-defined official] to manage the development, documentation, and dissemination of the access control policy and procedures; and
c. Review and update the current access control:
1. Policy [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]; and
| 2. Procedures [Assignment: organization- | Access control policy and procedures address the controls in the AC family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of access control policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies reflecting the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to access control policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure. |
| Related Controls: IA-1, PM-9, PM-24, PS-8, SI-12. | a. Not appropriate to define at the CNSS level for all organizations operating NSS. |
b.1. At least annually if not otherwise defined in formal organizational policy b.2. At least annually if not otherwise defined in formal organizational policy
DL3
AC-2 Account Management The organization:
a. Define and document the types of accounts allowed and specifically prohibited for use within the system;
b. Assign account managers;
c. Require [Assignment: organization-defined prerequisites and criteria] for group and role membership;
d. Specify:
1. Authorized users of the system;
2. Group and role membership; and
3. Access authorizations (i.e., privileges) and [Assignment: organization-defined attributes (as required)] for each account;
e. Require approvals by [Assignment: organization-defined personnel or roles] for requests to create accounts;
f. Create, enable, modify, disable, and remove accounts in accordance with [Assignment: organization-defined policy, procedures, prerequisites, and criteria];
g. Monitor the use of accounts;
h. Notify account managers and [Assignment: organization-defined personnel or roles] within:
1. [Assignment: organization-defined time period] when accounts are no longer required;
2. [Assignment: organization-defined time period] when users are terminated or transferred; and
3. [Assignment: organization-defined time period] when system usage or need-to-know changes for an individual;
i. Authorize access to the system based on:
1. A valid access authorization;
2. Intended system usage; and
3. [Assignment: organization-defined attributes (as required)];
j. Review accounts for compliance with account management requirements [Assignment: organization-defined frequency];
k. Establish and implement a process for changing shared or group account authenticators (if deployed) when individuals are removed from the group; and
l. Align account management processes with personnel termination and transfer processes.
Examples of system account types include individual, shared, group, system, guest, anonymous, emergency, developer, temporary, and service. Identification of authorized system users and the specification of access privileges reflect the requirements in other controls in the security plan. Users requiring administrative privileges on system accounts receive additional scrutiny by organizational personnel responsible for approving such accounts and privileged access, including system owner, mission or business owner, senior agency information security officer, or senior agency official for privacy. Types of accounts that organizations may wish to prohibit due to increased risk include shared, group, emergency, anonymous, temporary, and guest accounts.
Where access involves personally identifiable information, security programs collaborate with the senior agency official for privacy to establish the specific conditions for group and role membership; specify authorized users, group and role membership, and access authorizations for each account; and create, adjust, or remove system accounts in accordance with organizational policies. Policies can include such information as account expiration dates or other factors that trigger the disabling of accounts. Organizations may choose to define access privileges or other attributes by account, type of account, or a combination of the two. Examples of other attributes required for authorizing access include restrictions on time of day, day of week, and point of origin. In defining other system account attributes, organizations consider system-related requirements and mission/business requirements. Failure to consider these factors could affect system availability.
Temporary and emergency accounts are intended for short-term use. Organizations establish temporary accounts as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. Organizations establish emergency accounts in response to crisis situations and with the need for rapid account activation. Therefore, emergency account activation may bypass normal account authorization processes. Emergency and temporary accounts are not to be confused with infrequently used accounts, including local logon accounts used for special tasks or when network resources are unavailable (may also be known as accounts of last resort). Such accounts remain available and are not subject to automatic disabling or removal dates. Conditions for disabling or deactivating accounts include when shared/group, emergency, or temporary accounts are no longer required and when individuals are transferred or terminated. Changing shared/group authenticators when members leave the group is intended to ensure that former group members do not retain access to the shared or group account. Some types of system accounts may require specialized training.
Related Controls: AC-3, AC-5, AC-6, AC-17, AC-18, AC-20, AC-24, AU-2, AU-12, CM-5, IA-2, IA-4, IA-5, IA-8, MA-3, MA-5, PE-2, PL-4, PS-2, PS-4, PS-5, PS-7, PT-2, PT-3, SC-7, SC-12, SC-13, SC-37. a. Not appropriate to define at the CNSS level for all NSS.
e. Not appropriate to define at the CNSS level for all NSS.
f. Not appropriate to define at the CNSS level for all NSS.
j. At least annually if not otherwise defined in formal organizational policy.
DL3
AC-2 (1) ACCOUNT MANAGEMENT | AUTOMATED SYSTEM ACCOUNT MANAGEMENT The organization employs automated mechanisms to support the management of information system accounts. The use of automated mechanisms can include, for example: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using telephonic notification to report atypical system account usage. DL3
AC-2 (2) ACCOUNT MANAGEMENT | REMOVAL OF TEMPORARY / EMERGENCY ACCOUNTS The information system automatically [Selection:; removes; disables] temporary and emergency accounts after [Assignment:; organization-defined time period for each type of account]. This control enhancement requires the removal of both temporary and emergency accounts automatically after a predefined period of time has elapsed, rather than at the convenience of the systems administrator. DL3
AC-2 (3) ACCOUNT MANAGEMENT | DISABLE INACTIVE ACCOUNTS The information system automatically disables inactive accounts after [Assignment:; organization-defined time period]. No Supplemental Guidance DL3
| AC-2(4) | Account Management | Automated Audit Actions | Automatically audit account creation, modification, enabling, disabling, and removal actions. | Account management audit records are defined in accordance with AU-2 and reviewed, analyzed, and reported in accordance with AU-6. | |
| Related Controls: AU-2, AU-6. | DL3 |
| AC-2(5) | Account Management | Inactivity Logout | Require that users log out when [Assignment: organization-defined time period of expected inactivity or description of when to log out]. | Inactivity logout is behavior- or policy-based and requires users to take physical action to log out when they are expecting inactivity longer than the defined period. Automatic enforcement of inactivity logout is addressed by AC-11. | |
| Related Controls: AC-11. | At the end of the users standard work period unless otherwise defined in formal organizational policy. | DL3 |
AC-2(7) Account Management | Role-Based Schemes The organization:
(a) Establish and administer privileged user accounts in accordance with [Selection: a role-based access scheme; an attribute-based access scheme];
(b) Monitor privileged role or attribute assignments;
(c) Monitor changes to roles or attributes; and
(d) Revoke access when privileged role or attribute assignments are no longer appropriate. Privileged roles are organization-defined roles assigned to individuals that allow those individuals to perform certain security-relevant functions that ordinary users are not authorized to perform. Privileged roles include key management, account management, database administration, system and network administration, and web administration. A role-based access scheme organizes permitted system access and privileges into roles. In contrast, an attribute-based access scheme specifies allowed system access and privileges based on attributes. (c) Disables (or revokes) privileged user account. DL3
AC-2(9) Account Management | Restrictions on Use of Shared Groups / Accounts The organization only permits the use of shared/group accounts that meet [Assignment: organization-defined conditions for establishing shared/group accounts]. Before permitting the use of shared or group accounts, organizations consider the increased risk due to the lack of accountability with such accounts. DL3
AC-2 (10) ACCOUNT MANAGEMENT | SHARED / GROUP ACCOUNT CREDENTIAL TERMINATION The information system terminates shared/group account credentials when members leave the group. No Supplemental Guidance DL3
AC-2(12) Account Management | Account Monitoring / Atypical Usage The organization:
(a) Monitors information system accounts for [Assignment: organization-defined atypical use]; and
(b) Reports atypical usage of information system accounts to [Assignment: organization-defined personnel or roles].
| Atypical usage includes accessing systems at certain times of the day or from locations that are not consistent with the normal usage patterns of individuals. Monitoring for atypical usage may reveal rogue behavior by individuals or an attack in progress. Account monitoring may inadvertently create privacy risks since data collected to identify atypical usage may reveal previously unknown information about the behavior of individuals. Organizations assess and document privacy risks from monitoring accounts for atypical usage in their privacy impact assessment and make determinations that are in alignment with their privacy program plan. | ||
| Related Controls: AU-6, AU-7, CA-7, IR-8, SI-4. | DL3 |
AC-2(13) Account Management | Disable Accounts For High-Risk Individuals The organization disables accounts of users posing a significant risk within [Assignment: organization-defined time period] of discovery of the risk. Users posing a significant risk to organizations include individuals for whom reliable evidence or intelligence indicates either the intention to use authorized access to information systems to cause harm or through whom adversaries will cause harm. Harm includes potential adverse impacts to organizational operations and assets, individuals, other organizations, or the Nation. Close coordination between authorizing officials, information system administrators, and human resource managers is essential in order for timely execution of this control enhancement. Related control: PS-4. 30 minutes unless otherwise defined in formal organizational policy. DL3
| AC-3 | Access Enforcement | The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies. | Access control policies control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (i.e., devices, files, records, domains) in organizational systems. In addition to enforcing authorized access at the system level and recognizing that systems can host many applications and services in support of mission and business functions, access enforcement mechanisms can also be employed at the application and service level to provide increased information security and privacy. In contrast to logical access controls that are implemented within the system, physical access controls are addressed by the controls in the Physical and Environmental Protection (PE) family. | |
| Related Controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AC-24, AC-25, AT-2, AT-3, AU-9, CA-9, CM-5, CM-11, IA-2, IA-5, IA-6, IA-7, IA-11, MA-3, MA-4, MA-5, MP-4, PM-2, PS-3, PT-2, PT-3, SA-17, SC-2, SC-3, SC-4, SC-12, SC-13, SC-28, SC-31, SC-34, SI-4, SI-8. | DL3 |
AC-3 (2) ACCESS ENFORCEMENT | DUAL AUTHORIZATION The information system enforces dual authorization for [Assignment:; organization-defined privileged commands and/or other organization-defined actions]. Dual authorization mechanisms require the approval of two authorized individuals in order to execute. Organizations do not require dual authorization mechanisms when immediate responses are necessary to ensure public and environmental safety. Dual authorization may also be known as two-person control. Related controls: CP-9, MP-6. DL3
AC-3(4) Access Enforcement | Discretionary Access Control The information system enforces [Assignment: organization-defined discretionary access control policies] over defined subjects and objects where the policy specifies that a subject that has been granted access to information can do one or more of the following:
(a) Pass the information to any other subjects or objects;
(b) Grant its privileges to other subjects;
(c) Change security attributes on subjects, objects, the information system, or the information system’s components;
(d) Choose the security attributes to be associated with newly created or revised objects; or
(e) Change the rules governing access control.
When discretionary access control policies are implemented, subjects are not constrained with regard to what actions they can take with information for which they have already been granted access. Thus, subjects that have been granted access to information are not prevented from passing the information to other subjects or objects (i.e., subjects have the discretion to pass). Discretionary access control can operate in conjunction with mandatory access control as described in AC-3(3) and AC-3(15). A subject that is constrained in its operation by mandatory access control policies can still operate under the less rigorous constraints of discretionary access control. Therefore, while AC-3(3) imposes constraints that prevent a subject from passing information to another subject operating at a different impact or classification level, AC-3(4) permits the subject to pass the information to any subject at the same impact or classification level. The policy is bounded by the system. Once the information is passed outside of system control, additional means may be required to ensure that the constraints remain in effect. While traditional definitions of discretionary access control require identity-based access control, that limitation is not required for this particular use of discretionary access control. DL3
AC-4 INFORMATION FLOW ENFORCEMENT The information system enforces approved authorizations for controlling the flow of information within the system and between interconnected systems based on [Assignment:; organization-defined information flow control policies]. Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Flow control restrictions include, for example, keeping export-controlled information from being transmitted in the clear to the Internet, blocking outside traffic that claims to be from within the organization, restricting web requests to the Internet that are not from the internal web proxy server, and limiting information transfers between organizations based on data structures and content. Transferring information between information systems representing different security domains with different security policies introduces risk that such transfers violate one or more domain security policies. In such situations, information owners/stewards provide guidance at designated policy enforcement points between interconnected systems. Organizations consider mandating specific architectural solutions when required to enforce specific security policies. Enforcement includes, for example: (i) prohibiting information transfers between interconnected systems (i.e., allowing access only); (ii) employing hardware mechanisms to enforce one-way information flows; and (iii) implementing trustworthy regrading mechanisms to reassign security attributes and security labels.Organizations commonly employ information flow control policies and enforcement mechanisms to control the flow of information between designated sources and destinations (e.g., networks, individuals, and devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path. Enforcement occurs, for example, in boundary protection devices (e.g., gateways, routers, guards, encrypted tunnels, firewalls) that employ rule sets or establish configuration settings that restrict information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics). Organizations also consider the trustworthiness of filtering/inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement. Control enhancements 3 through 22 primarily address cross-domain solution needs which focus on more advanced filtering techniques, in-depth analysis, and stronger flow enforcement mechanisms implemented in cross-domain products, for example, high-assurance guards. Such capabilities are generally not available in commercial off-the-shelf information technology products. Related controls: AC-3, AC-17, AC-19, AC-21, CM-6, CM-7, SA-8, SC-2, SC-5, SC-7, SC-18. DL3
AC-5 Separation of Duties The organization:
a. Identify and document [Assignment: organization-defined duties of individuals requiring separation]; and
| b. Define system access authorizations to support separation of duties. | Separation of duties addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion. Separation of duties includes dividing mission or business functions and support functions among different individuals or roles, conducting system support functions with different individuals, and ensuring that security personnel who administer access control functions do not also administer audit functions. Because separation of duty violations can span systems and application domains, organizations consider the entirety of systems and system components when developing policy on separation of duties. Separation of duties is enforced through the account management activities in AC-2, access control mechanisms in AC-3, and identity management activities in IA-2, IA-4, and IA-12. | |
| Related Controls: AC-2, AC-3, AC-6, AU-9, CM-5, CM-11, CP-9, IA-2, IA-4, IA-5, IA-12, MA-3, MA-5, PS-2, SA-8, SA-17. | DL3 |
| AC-6 | Least Privilege | Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks. | Organizations employ least privilege for specific duties and systems. The principle of least privilege is also applied to system processes, ensuring that the processes have access to systems and operate at privilege levels no higher than necessary to accomplish organizational missions or business functions. Organizations consider the creation of additional processes, roles, and accounts as necessary to achieve least privilege. Organizations apply least privilege to the development, implementation, and operation of organizational systems. | |
| Related Controls: AC-2, AC-3, AC-5, AC-16, CM-5, CM-11, PL-2, PM-12, SA-8, SA-15, SA-17, SC-38. | DL3 |
AC-6(1) Least Privilege | Authorize Access to Security Functions Authorize access for [Assignment: organization-defined individuals or roles] to:
(a) [Assignment: organization-defined security functions (deployed in hardware, software, and firmware)]; and
| (b) [Assignment: organization-defined security-relevant information]. | Security functions include establishing system accounts, configuring access authorizations (i.e., permissions, privileges), configuring settings for events to be audited, and establishing intrusion detection parameters. Security-relevant information includes filtering rules for routers or firewalls, configuration parameters for security services, cryptographic key management information, and access control lists. Authorized personnel include security administrators, system administrators, system security officers, system programmers, and other privileged users. | |
| Related Controls: AC-17, AC-18, AC-19, AU-9, PE-2. | DL3 |
| AC-6(2) | Least Privilege | Non-Privileged Access For Nonsecurity Functions | Require that users of system accounts (or roles) with access to [Assignment: organization-defined security functions or security-relevant information] use non-privileged accounts or roles, when accessing nonsecurity functions. | Discussion: Requiring the use of non-privileged accounts when accessing nonsecurity functions limits exposure when operating from within privileged accounts or roles. The inclusion of roles addresses situations where organizations implement access control policies, such as role-based access control, and where a change of role provides the same degree of assurance in the change of access authorizations for the user and the processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. | |
| Related Controls: AC-17, AC-18, AC-19, PL-4. | Privileged functions. | DL3 |
AC-6(5) Least Privilege | Privileged Accounts The organization restricts privileged accounts on the information system to [Assignment: organization-defined personnel or roles]. Privileged accounts, including super user accounts, are typically described as system administrator for various types of commercial off-the-shelf operating systems. Restricting privileged accounts to specific personnel or roles prevents day-to-day users from having access to privileged information/functions. Organizations may differentiate in the application of this control enhancement between allowed privileges for local accounts and for domain accounts provided organizations retain the ability to control information system configurations for key security parameters and as otherwise necessary to sufficiently mitigate risk. Related control: CM-6. DL0
AC-6(7) Least Privilege | Review of User Privileges The organization:
(a) Reviews [Assignment: organization-defined frequency] the privileges assigned to [Assignment: organization-defined roles or classes of users] to validate the need for such privileges; and
(b) Reassigns or removes privileges, if necessary, to correctly reflect organizational mission/business needs.
The need for certain assigned user privileges may change over time reflecting changes in organizational missions/business function, environments of operation, technologies, or threat. Periodic review of assigned user privileges is necessary to determine if the rationale for assigning such privileges remains valid. If the need cannot be revalidated, organizations take appropriate corrective actions. Related control: CA-7. DL0
AC-6 (5) LEAST PRIVILEGE | PRIVILEGED ACCOUNTS The organization restricts privileged accounts on the information system to [Assignment:; organization-defined personnel or roles]. Privileged accounts, including super user accounts, are typically described as system administrator for various types of commercial off-the-shelf operating systems. Restricting privileged accounts to specific personnel or roles prevents day-to-day users from having access to privileged information/functions. Organizations may differentiate in the application of this control enhancement between allowed privileges for local accounts and for domain accounts provided organizations retain the ability to control information system configurations for key security parameters and as otherwise necessary to sufficiently mitigate risk. Related control: CM-6. DL3
AC-6 (7) LEAST PRIVILEGE | REVIEW OF USER PRIVILEGES The organization:
(a) Reviews [Assignment: organization-defined frequency] the privileges assigned to [Assignment: organization-defined roles or classes of users] to validate the need for such privileges; and
(b) Reassigns or removes privileges, if necessary, to correctly reflect organizational mission/business needs. Supplemental Guidance: The need for certain assigned user privileges may change over time reflecting changes in organizational missions/business function, environments of operation, technologies, or threat. Periodic review of assigned user privileges is necessary to determine if the rationale for assigning such privileges remains valid. If the need cannot be revalidated, organizations take appropriate corrective actions. Related control: CA-7. DL3
AC-6(8) Least Privilege | Privilege Levels For Code Execution Prevent the following software from executing at higher privilege levels than users executing the software: [Assignment: organization-defined software]. In certain situations, software applications or programs need to execute with elevated privileges to perform required functions. However, depending on the software functionality and configuration, if the privileges required for execution are at a higher level than the privileges assigned to organizational users invoking such applications or programs, those users may indirectly be provided with greater privileges than assigned. All DL3
| AC-6(9) | LOG USE OF PRIVILEGED FUNCTIONS | Log the execution of privileged functions. | The misuse of privileged functions, either intentionally or unintentionally by authorized users or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Logging and analyzing the use of privileged functions is one way to detect such misuse and, in doing so, help mitigate the risk from insider threats and the advanced persistent threat. | |
| Related Controls: AU-2, AU-3, AU-12. | DL3 |
AC-6(10) Least Privilege | Prohibit Nonprivileged Users from Executing Privileged Functions Prevent non-privileged users from executing privileged functions. Privileged functions include disabling, circumventing, or altering implemented security or privacy controls, establishing system accounts, performing system integrity checks, and administering cryptographic key management activities. Non-privileged users are individuals who do not possess appropriate authorizations. Privileged functions that require protection from non-privileged users include circumventing intrusion detection and prevention mechanisms or malicious code protection mechanisms. Preventing non-privileged users from executing privileged functions is enforced by AC-3. DL3
AC-7 Unsuccessful Logon Attempts Control:
a. Enforce a limit of [Assignment: organization-defined number] consecutive invalid logon attempts by a user during a [Assignment: organization-defined time period]; and
| b. Automatically [Selection (one or more): lock the account or node for an [Assignment: organization-defined time period]; lock the account or node until released by an administrator; delay next logon prompt per [Assignment: organization-defined delay algorithm]; notify system administrator; take other [Assignment: organization-defined action]] when the maximum number of unsuccessful attempts is exceeded. | The need to limit unsuccessful logon attempts and take subsequent action when the maximum number of attempts is exceeded applies regardless of whether the logon occurs via a local or network connection. Due to the potential for denial of service, automatic lockouts initiated by systems are usually temporary and automatically release after a predetermined, organization-defined time period. If a delay algorithm is selected, organizations may employ different algorithms for different components of the system based on the capabilities of those components. Responses to unsuccessful logon attempts may be implemented at the operating system and the application levels. Organization-defined actions that may be taken when the number of allowed consecutive invalid logon attempts is exceeded include prompting the user to answer a secret question in addition to the username and password, invoking a lockdown mode with limited user capabilities (instead of full lockout), allowing users to only logon from specified Internet Protocol (IP) addresses, requiring a CAPTCHA to prevent automated attacks, or applying user profiles such as location, time of day, IP address, device, or Media Access Control (MAC) address. If automatic system lockout or execution of a delay algorithm is not implemented in support of the availability objective, organizations consider a combination of other actions to help prevent brute force attacks. In addition to the above, organizations can prompt users to respond to a secret question before the number of allowed unsuccessful logon attempts is exceeded. Automatically unlocking an account after a specified period of time is generally not permitted. However, exceptions may be required based on operational mission or need. |
| Related Controls: AC-2, AC-9, AU-2, AU-6, IA-5. | a. 3 |
a. 15 minutes
b. locks the account/node for at least 15 minutes, or until unlocked by an administrator.
Not appropriate to define at the CNSS level for all NSS.
DL3
AC-8 System Use Notification a. Display [Assignment: organization-defined system use notification message or banner] to users before granting access to the system that provides privacy and security notices consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines and state that:
1. Users are accessing a U.S. Government system;
2. System usage may be monitored, recorded, and subject to audit;
3. Unauthorized use of the system is prohibited and subject to criminal and civil penalties; and
4. Use of the system indicates consent to monitoring and recording;
b. Retain the notification message or banner on the screen until users acknowledge the usage conditions and take explicit actions to log on to or further access the system; and
c. For publicly accessible systems:
1. Display system use information [Assignment: organization-defined conditions], before granting further access to the publicly accessible system;
| 2. Display references, if any, to monitoring, recording, or auditing that are consistent with privacy accommodations for such systems that generally prohibit those activities; and 3. Include a description of the authorized uses of the system. | System use notifications can be implemented using messages or warning banners displayed before individuals log in to systems. System use notifications are used only for access via logon interfaces with human users. Notifications are not required when human interfaces do not exist. Based on an assessment of risk, organizations consider whether or not a secondary system use notification is needed to access applications or other system resources after the initial network logon. Organizations consider system use notification messages or banners displayed in multiple languages based on organizational needs and the demographics of system users. Organizations consult with the privacy office for input regarding privacy messaging and the Office of the General Counsel or organizational equivalent for legal review and approval of warning banner content. | |
| Related Controls: AC-14, PL-4, SI-4. | DL3 |
AC-10 CONCURRENT SESSION CONTROL The information system limits the number of concurrent sessions for each [Assignment:; organization-defined account and/or account type] to [Assignment:; organization-defined number]. Supplemental Guidance: Organizations may define the maximum number of concurrent sessions for information system accounts globally, by account type (e.g., privileged user, non-privileged user, domain, specific application), by account, or a combination. For example, organizations may limit the number of concurrent sessions for system administrators or individuals working in particularly sensitive domains or mission-critical applications. This control addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts. DL3
| AC-11 | DEVICE LOCK | a. Prevent further access to the system by [Selection (one or more): initiating a device lock after [Assignment: organization-defined time period] of inactivity; requiring the user to initiate a device lock before leaving the system unattended]; and | |
| b. Retain the device lock until the user reestablishes access using established identification and authentication procedures. | Device locks are temporary actions taken to prevent logical access to organizational systems when users stop work and move away from the immediate vicinity of those systems but do not want to log out because of the temporary nature of their absences. Device locks can be implemented at the operating system level or at the application level. A proximity lock may be used to initiate the device lock (e.g., via a Bluetooth-enabled device or dongle). User-initiated device locking is behavior or policy-based and, as such, requires users to take physical action to initiate the device lock. Device locks are not an acceptable substitute for logging out of systems, such as when organizations require users to log out at the end of workdays. | ||
| Related Controls: AC-2, AC-7, IA-11, PL-4. | Not to exceed 30 minutes | DL3 |
AC-11(1) Device Lock | Pattern-Hiding Displays Conceal, via the device lock, information previously visible on the display with a publicly viewable image. The pattern-hiding display can include static or dynamic images, such as patterns used with screen savers, photographic images, solid colors, clock, battery life indicator, or a blank screen with the caveat that controlled unclassified information is not displayed. DL3
AC-12 SESSION TERMINATION The information system automatically terminates a user session after [Assignment:; organization-defined conditions or trigger events requiring session disconnect]. Organizations may define the maximum number of concurrent sessions for information system accounts globally, by account type (e.g., privileged user, non-privileged user, domain, specific application), by account, or a combination. For example, organizations may limit the number of concurrent sessions for system administrators or individuals working in particularly sensitive domains or mission-critical applications. This control addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts. DL3
AC-12 (1) SESSION TERMINATION | USER-INITIATED LOGOUTS/ MESSAGE DISPLAYS The information system:;(a) Provides a logout capability for user-initiated communications sessions whenever authentication is used to gain access to [Assignment:; organization-defined information resources]; and(b) Displays an explicit logout message to users indicating the reliable termination of authenticated communications sessions. This control addresses the termination of user-initiated logical sessions in contrast to SC-10 which addresses the termination of network connections that are associated with communications sessions (i.e., network disconnect). A logical session (for local, network, and remote access) is initiated whenever a user (or process acting on behalf of a user) accesses an organizational information system. Such user sessions can be terminated (and thus terminate user access) without terminating network sessions. Session termination terminates all processes associated with a user"s logical session except those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, time-of-day restrictions on information system use. Related controls: SC-10, SC-23. DL3
AC-14 Permitted Actions Without Identification or Authentication The organization:
a. Identifies [Assignment: organization-defined user actions] that can be performed on the information system without identification or authentication consistent with organizational missions/business functions; and
b. Documents and provides supporting rationale in the security plan for the information system, user actions not requiring identification or authentication.
This control addresses situations in which organizations determine that no identification or authentication is required in organizational information systems. Organizations may allow a limited number of user actions without identification or authentication including, for example, when individuals access public websites or other publicly accessible federal information systems, when individuals use mobile phones to receive calls, or when facsimiles are received. Organizations also identify actions that normally require identification or authentication but may under certain circumstances (e.g., emergencies), allow identification or authentication mechanisms to be bypassed. Such bypasses may occur, for example, via a software-readable physical switch that commands bypass of the logon functionality and is protected from accidental or unmonitored use. This control does not apply to situations where identification and authentication have already occurred and are not repeated, but rather to situations where identification and authentication have not yet occurred. Organizations may decide that there are no user actions that can be performed on organizational information systems without identification and authentication and thus, the values for assignment statements can be none. Related controls: CP-2, IA-2. a. No user actions DL3
AC-16 SECURITY AND PRIVACY ATTRIBUTES a. Provide the means to associate [Assignment: organization-defined types of security and privacy attributes] with [Assignment: organization-defined security and privacy attribute values] for information in storage, in process, and/or in transmission;
b. Ensure that the attribute associations are made and retained with the information;
c. Establish the following permitted security and privacy attributes from the attributes defined in AC-16a for [Assignment: organization-defined systems]: [Assignment: organization-defined security and privacy attributes];
d. Determine the following permitted attribute values or ranges for each of the established attributes: [Assignment: organization-defined attribute values or ranges for established attributes];
e. Audit changes to attributes; and
f. Review [Assignment: organization-defined security and privacy attributes] for applicability [Assignment: organization-defined frequency]. Information is represented internally within systems using abstractions known as data structures. Internal data structures can represent different types of entities, both active and passive. Active entities, also known as subjects, are typically associated with individuals, devices, or processes acting on behalf of individuals. Passive entities, also known as objects, are typically associated with data structures, such as records, buffers, tables, files, inter-process pipes, and communications ports. Security attributes, a form of metadata, are abstractions that represent the basic properties or characteristics of active and passive entities with respect to safeguarding information. Privacy attributes, which may be used independently or in conjunction with security attributes, represent the basic properties or characteristics of active or passive entities with respect to the management of personally identifiable information. Attributes can be either explicitly or implicitly associated with the information contained in organizational systems or system components.
Attributes may be associated with active entities (i.e., subjects) that have the potential to send or receive information, cause information to flow among objects, or change the system state. These attributes may also be associated with passive entities (i.e., objects) that contain or receive information. The association of attributes to subjects and objects by a system is referred to as binding and is inclusive of setting the attribute value and the attribute type. Attributes, when bound to data or information, permit the enforcement of security and privacy policies for access control and information flow control, including data retention limits, permitted uses of personally identifiable information, and identification of personal information within data objects. Such enforcement occurs through organizational processes or system functions or mechanisms. The binding techniques implemented by systems affect the strength of attribute binding to information. Binding strength and the assurance associated with binding techniques play important parts in the trust that organizations have in the information flow enforcement process. The binding techniques affect the number and degree of additional reviews required by organizations.
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .