800-171 CUI Controls (124 Controls)

*PE - 17* ALTERNATE WORK SITE

Short Description: The organization: a. Employs [Assignment: organization-defined security controls] at alternate work sites; b. Assesses as feasible, the effectiveness of security controls at alternate work sites; and c. Provides a means for employees to communicate with information security personnel in case of security incidents or problems. Example: Evidence: Supplemental Guidance: Alternate work sites may include, for example, government facilities or private residences of employees. While commonly distinct from alternative processing sites, alternate work sites may provide readily available alternate locations as part of contingency operations. Organizations may define different sets of security controls for specific alternate work sites or types of sites depending on the work-related activities conducted at those sites. This control supports the contingency planning activities of organizations and the federal telework initiative.

*PS - 4* PERSONNEL TERMINATION

Short Description: The organization, upon termination of individual employment: a. Disables information system access within [Assignment: organization-defined time period]; b. Terminates/revokes any authenticators/credentials associated with the individual; c. Conducts exit interviews that include a discussion of [Assignment: organization-defined information security topics]; d. Retrieves all security-related organizational information system-related property; e. Retains access to organizational information and information systems formerly controlled by terminated individual; and f. Notifies [Assignment: organization-defined personnel or roles] within [Assignment: organization-defined time period]. Example: Evidence: Termination procedures and/or termination checklist Supplemental Guidance: Information system-related property includes, for example, hardware authentication tokens, system administration technical manuals, keys, identification cards, and building passes. Exit interviews ensure that terminated individuals understand the security constraints imposed by being former employees and that proper accountability is achieved for information system-related property. Security topics of interest at exit interviews can include, for example, reminding terminated individuals of nondisclosure agreements and potential limitations on future employment. Exit interviews may not be possible for some terminated individuals, for example, in cases related to job abandonment, illnesses, and nonavailability of supervisors. Exit interviews are important for individuals with security clearances. Timely execution of termination actions is essential for individuals terminated for cause. In certain situations, organizations consider disabling the information system accounts of individuals that are being terminated prior to the individuals being notified. What to Say:

*PE - 6* MONITORING PHYSICAL ACCESS

Short Description: The organization: a. Monitors physical access to the facility where the information system resides to detect and respond to physical security incidents; b. Reviews physical access logs [Assignment: organization-defined frequency] and upon occurrence of [Assignment: organization-defined events or potential indications of events]; and c. Coordinates results of reviews and investigations with the organizational incident response capability. Example: Evidence: Evidence of physical intrusion alarm and surveillance equipment monitoring, Physical security incident response policy (if not included in the physical and environmental protection policy), Example system-generated badge access system log demonstrating that successful and unsuccessful access attempt are logged, Evidence of physical intrusion alarm and surveillance equipment monitoring Supplemental Guidance: Organizational incident response capabilities include investigations of and responses to detected physical security incidents. Security incidents include, for example, apparent security violations or suspicious physical access activities. Suspicious physical access activities include, for example: (i) accesses outside of normal work hours; (ii) repeated accesses to areas not normally accessed; (iii) accesses for unusual lengths of time; and (iv) out-of-sequence accesses. What to Say:

*PS - 5* PERSONNEL TRANSFER

Short Description: The organization: a. Reviews and confirms ongoing operational need for current logical and physical access authorizations to information systems/facilities when individuals are reassigned or transferred to other positions within the organization; b. Initiates [Assignment: organization-defined transfer or reassignment actions] within [Assignment: organization-defined time period following the formal transfer action]; c. Modifies access authorization as needed to correspond with any changes in operational need due to reassignment or transfer; and d. Notifies [Assignment: organization-defined personnel or roles] within [Assignment: organization-defined time period]. Example: Evidence: Evidence of recent security review performed on a transfer, if available Supplemental Guidance: This control applies when reassignments or transfers of individuals are permanent or of such extended durations as to make the actions warranted. Organizations define actions appropriate for the types of reassignments or transfers, whether permanent or extended. Actions that may be required for personnel transfers or reassignments to other positions within organizations include, for example: (i) returning old and issuing new keys, identification cards, and building passes; (ii) closing information system accounts and establishing new accounts; (iii) changing information system access authorizations (i.e., privileges); and (iv) providing for access to official records to which individuals had access at previous work locations and in previous information system accounts. What to Say:

*PS - 3* PERSONNEL SCREENING

Short Description: The organization: a. Screens individuals prior to authorizing access to the information system; and b. Rescreens individuals according to [Assignment: organization-defined conditions requiring rescreening and, where rescreening is so indicated, the frequency of such rescreening]. Example: Evidence: Overview of Human Resources screening procedures, Example of one new hire screening process, Example of one rescreening process, if rescreening is required by the organization, Position sensitivity background screening requirements Supplemental Guidance: Personnel screening and rescreening activities reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, guidance, and specific criteria established for the risk designations of assigned positions. Organizations may define different rescreening conditions and frequencies for personnel accessing information systems based on types of information processed, stored, or transmitted by the systems. What to Say:

*AU - 2* AUDIT EVENTS

Short Description: a. The organization *defines* auditable events and the auditing mechanisms in place are *capable* of logging these types of events b. does the organization *coordinate* security audit function with other parts of the organization c. develop *supporting rationale* for why the events that are chosen are adequate for triage (after-the-fact) d. determining the *frequency* of auditing each event defined in 2a Example: First off how and why you chose audit events and how often you capture those events on a packet level. Some examples of audit events are (Admin privelige usage, password changes, failed logons, etc.) And then overall with all three of those considerations, does it work? Evidence: Listing of all auditable events and subset of auditable events, auditable events review and update records, automated mechanisms supporting the review and update of auditable events, procedures for reviewing and updating auditable events, listing of rationale for all auditable events, last review of audit logs, authoated mechanisms implementing system auditing. Supplemental Guidance: An event is any observable occurrence in an organizational information system. Organizations identify audit events as those events which are significant and relevant to the security of information systems and the environments in which those systems operate in order to meet specific and ongoing audit needs. Audit events can include, for example, password changes, failed logons, or failed accesses related to information systems, administrative privilege usage, PIV credential usage, or third-party credential usage. In determining the set of auditable events, organizations consider the auditing appropriate for each of the security controls to be implemented. To balance auditing requirements with other information system needs, this control also requires identifying that subset of auditable events that are audited at a given point in time. For example, organizations may determine that information systems must have the capability to log every file access both successful and unsuccessful, but not activate that capability except for specific circumstances due to the potential burden on system performance. Auditing requirements, including the need for auditable events, may be referenced in other security controls and control enhancements. Organizations also include auditable events that are required by applicable federal laws, Executive Orders, directives, policies, regulations, and standards. Audit records can be generated at various levels of abstraction, including at the packet level as information traverses the network. Selecting the appropriate level of abstraction is a critical aspect of an audit capability and can facilitate the identification of root causes to problems. Organizations consider in the definition of auditable events, the auditing necessary to cover related events such as the steps in distributed, transaction-based processes (e.g., processes that are distributed across multiple organizations) and actions that occur in service-oriented architectures.

*AC - 8* SYSTEM USE NOTIFICATION

Short Description: *Displays* an organization defined *banner* *before* *granting* access to the system that provides privacy and security notices that are consistent with applicable federal laws etc. that states that users are access a gov't system, their usage may be monitored, unauthorized use can be punished. The banner/notification message should also *require acknowledgement in the form of a check box, etc.* Supplemental Guidance: System use notifications can be implemented using messages or warning banners displayed before individuals log in to information systems. System use notifications are used only for access via logon interfaces with human users and are not required when such human interfaces do not exist. Organizations consider system use notification messages/banners displayed in multiple languages based on specific organizational needs and the demographics of information system users. Organizations also consult with the Office of the General Counsel for legal review and approval of warning banner content. Example: A banner that requires mandatory acknowledgement and action by users, before users can access the system. (e.g. "Hey you're about to get access to the launch codes, we're watching you, we can lock you up, if you check yes you're okay with all this) Evidence: System notification message or banner displayed prior to users logging in for all in-scope systems including externally facing interfaces what to say: this one is pretty cut and dry. Many orgs just copy and paste the statement. Still remember to keep in mind scoping may be multiple login forms. Remember that the banner has to be defined and users must consent to it in some way. (submit buttons work)

*IA - 5(1)* AUTHENTICATOR MANAGEMENT | Password_Based Authentication

Short Description: The Information System, for password-based authentication: Enforces minimum password complexity of [Assignment: organization-defined requirements for case sensitivity, number of characters, mix of upper-case letters, lower-case letters, numbers, and special characters, including minimum requirements for each type]; Enforces at least the following number of changed characters when new passwords are created: [Assignment: organization-defined number]; Stores and transmits only cryptographically-protected passwords; Enforces password minimum and maximum lifetime restrictions of [Assignment: organization-defined numbers for lifetime minimum, lifetime maximum]; Prohibits password reuse for [Assignment: organization-defined number] generations; and Allows the use of a temporary password for system logons with an immediate change to a permanent password. Example: Evidence: Supplemental Guidance: This control enhancement applies to single-factor authentication of individuals using passwords as individual or group authenticators, and in a similar manner, when passwords are part of multifactor authenticators. This control enhancement does not apply when passwords are used to unlock hardware authenticators (e.g., Personal Identity Verification cards). The implementation of such password mechanisms may not meet all of the requirements in the enhancement. Cryptographically-protected passwords include, for example, encrypted versions of passwords and one-way cryptographic hashes of passwords. The number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. Password lifetime restrictions do not apply to temporary passwords. To mitigate certain brute force attacks against passwords, organizations may also consider salting passwords.

*AU - 8(1)* TIME STAMPS | Synchronization With Authoritative Time Source

Short Description: The Information System: Compares the internal information system clocks [Assignment: organization-defined frequency] with [Assignment: organization-defined authoritative time source]; and Synchronizes the internal system clocks to the authoritative time source when the time difference is greater than [Assignment: organization-defined time period]. Example: Evidence: Supplemental Guidance: This control enhancement provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network.

*IA - 4* IDENTIFIER MANAGEMENT

Short Description: The information *manages* system identifiers (for individual, group, role, or devices) by selecting appropriate identifiers by *receiving authorization* from personnel or roles that assign these identifiers and subsequently *prevent the reuse* of identifiers for an org def amount of time and *disabling* the identifier after an org def amount of time. Example: Media Access Control, Internet Protocol, or device unique token identifiers. Management of individual identifiers is not applicable to shared information system accounts (e.g. guest and anonymous). Evidence: Evidence of an authorization form to assign an individual, group, role, user status or device identifier, Configuration to prevent reuse of identifiers for organization time periods, Configuration to disable the identifier after organization-defined time period of inactivity, Automated mechanisms supporting and/or implementing identifier management. Supplemental Guidance: Common device identifiers include, for example, media access control (MAC), Internet protocol (IP) addresses, or device-unique token identifiers. Management of individual identifiers is not applicable to shared information system accounts (e.g., guest and anonymous accounts). Typically, individual identifiers are the user names of the information system accounts assigned to those individuals. In such instances, the account management activities of AC-2 use account names provided by IA-4. This control also addresses individual identifiers not necessarily associated with information system accounts (e.g., identifiers used in physical security control databases accessed by badge reader systems for access to information systems). Preventing reuse of identifiers implies preventing the assignment of previously used individual, group, role, or device identifiers to different individuals, groups, roles, or devices.

*AC - 12* SESSION TERMINATION

Short Description: The information System *automatically terminates* a user session after any org def *trigger events* (could just be period of inactivity) Examples: Session termination settings or other domain management Evidence: Listing of trigger events, configuration setting that automatically terminates based on any events including inactivity Supplemental Guidance: 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. what to say: goes hand in hand with inactivity in many cases, typically "Trigger events" are not defined. The distinction is made in the previous example. Keep in mind that this control can also apply to remote session terminations. Essentially this control is looking for GPO proof that a computer locks after a user is away from their desktop, thus causing a disconnect due to inactivity.

*AC - 4* INFORMAITON FLOW ENFORCEMENT

Short Description: The information system *enforces approved authorization* for controlling the flow of information within the system and between interconnected systems based on org def *flow control policies* Examples: Flow control policy, Firewall rules, Router ACL's, encryption settings, Active Directory Dumps Evidence: Network Diagrams, Data Flow Diagrams, Flow control policies, Firewall configurations, Captured Network packets, opened ports and services Supplemental Guidance: 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. What to say: This control, at it's simplest explanation, relies on a mapping of a roles and responsibilities matrix to a Network Diagram, to firewall rules. Typically R&R's aren't developed and Network Diagrams aren't detailed enough to express what resources are stored where. R&R/Resources on the Network = firewall rules.

*AC-3* ACCESS ENFORCEMENT

Short Description: The information system *enforces approved authorizations* for *logical access* in accordance with *access control policies* Examples: Through Active Directory, LDAP, Redhat Directory Servers Evidence: Overview of access control measures employed to protect sensitive information including encryption, Access Control Policies, Access control lists, Access Request forms, Hiring checklists, etc Supplemental Guidance: Access control policies (e.g., identity-based policies, role-based policies, control matrices, cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. What to Say: Who authorizes your account creations? Could be different for system and app. Typically a system administrator or department manager that hands off to system administrator for approval.

*AU - 3* CONTENT OF AUDIT RECORDS

Short Description: The information system *generates* audit records containing information that establishes what *type* of event occurred, *when* the event occurred, *where* the event occurred, the source of the event, the *outcome* of the event, and the *identity* of any individuals or subjects associated with the event Example: metadata including time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked Evidence: Audit logs for all in scope systems that show: the type of the event that occurred, when the event occurred, the source of the event, the identity of any individuals or subjects associated with the event. Audit logs that may qualify as being outside any of those four guidelines. Supplemental Guidance: Audit record content that may be necessary to satisfy the requirement of this control, includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the information system after the event occurred).

*CA - 3* SYSTEM INTERCONNECTIONS

Short Description: The information system *utilizes interconnection security agreements* (i.e. dedicated connections) or *takes compensating procedures*. If the organization does utilize Interconnection Security Agreements, the agreement is *documented*, *reviewed*, and *updated*. Example: Dedicated Lines between organizations with different security requirements. This control does not apply to transitory, user-controlled connections such as email and website browsing. If interconnecting systems have the same *authorizing official*, organizations do not need to develop Interconnection Security Agreements. instead, organizations can describe the interface characteristics between those interconnecting systems in their respective security plans. If interconnecting systems have different authorizing officials within the same organization, organizations can either develop Interconnection Security Agreements or describe the interface characteristics between systems in the security plans for the respective systems. The details for developing Interconnection Security Agreements is outlined in NIST Special Publication 800-47. Evidence: List of any dedicated connections with external parties, automated mechanisms implementing restrictions on external system connections, authorization agreements with external parties that have direct connectivity with the information system, documentation of the connection and monitoring controls that are in place for each connection. Supplemental Guidance: This control applies to dedicated connections between information systems (i.e., system interconnections) and does not apply to transitory, user-controlled connections such as email and website browsing. Organizations carefully consider the risks that may be introduced when information systems are connected to other systems with different security requirements and security controls, both within organizations and external to organizations. Authorizing officials determine the risk associated with information system connections and the appropriate controls employed. If interconnecting systems have the same authorizing official, organizations do not need to develop Interconnection Security Agreements. Instead, organizations can describe the interface characteristics between those interconnecting systems in their respective security plans. If interconnecting systems have different authorizing officials within the same organization, organizations can either develop Interconnection Security Agreements or describe the interface characteristics between systems in the security plans for the respective systems. Organizations may also incorporate Interconnection Security Agreement information into formal contracts, especially for interconnections established between federal agencies and nonfederal (i.e., private sector) organizations. Risk considerations also include information systems sharing the same networks. For certain technologies (e.g., space, unmanned aerial vehicles, and medical devices), there may be specialized connections in place during preoperational testing. Such connections may require Interconnection Security Agreements and be subject to additional security controls.

*AC - 6 (9)* LEAST PRIVILEGE | Auditing Use Of Privileged Funcitons

Short Description: The information system audits the execution of privileged functions. Examples: Audit logs of vuln scan log ins, audit logs of admins accessing management servers, etc. Evidence: Supplemental Guidance: Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing 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 (APT).

*AC - 11 (1)* SESSION LOCK | Pattern Hiding Display

Short Description: The information system conceals, via the session lock, information previously visible on the display with a publicly viewable image. Examples: a lock screen Evidence: a locked screen Supplemental Guidance: Publicly viewable images can include static or dynamic images, for example, patterns used with screen savers, photographic images, solid colors, clock, battery life indicator, or a blank screen, with the additional caveat that none of the images convey sensitive information. Evidence: What to say: just observe a locked computer, or take a screenshot of a lock screen. This is the easiest control in the framework.

*AC - 7* UNSUCCESSFUL LOGIN ATTEMPTS

Short Description: The information system enforces a limit of an org def number of consecutive login attempts by a user during an organization defined time period and either retains the lock for an org def time period or until the admin unlocks the account. Also addresses the logon delay for the next prompt when the number of unsuccessful attempts number is exceeded. Supplemental Guidance: Accounts are typically set to lock after a defined number of unsuccessful logon attempts. Usually this is configured by AD or other domain services. This control applies to both local and network connections. Responses to unsuccessful attempts may be implemented at either the operating system and application levels. Examples: any account lockout threshold Evidence: System configuration setting for invalid login attempts for all in-scope systems, system configuration setting for automatic action taken when invalid login threshold is met for all in scope systems What to say: this is where the abstractness of the AC family takes a break.You will typically be able to get this from GPO configurations in AD. "How many times can users attempt to log on to something, using certain credentials, until logging on to that resource with that user name becomes blocked, using an account lockout?" Make sure to test this one. Also make sure to scope out each "Type" of credential the organization uses. If the org uses a WebApp then that's an additional login screen/credentials so it may be a different config setup for account lockout parameters.

*MP - 5(4)* MEDIA TRANSPORT | Cryptographic Protection

Short Description: The information system implements cryptographic mechanisms to protect the confidentiality and integrity of information stored on digital media during transport outside of controlled areas. Example: Evidence: Supplemental Guidance: This control enhancement applies to both portable storage devices (e.g., USB memory sticks, compact disks, digital video disks, external/removable hard disk drives) and mobile devices with storage capability (e.g., smart phones, tablets, E-readers). What to Say:

*AC - 17(2)* REMOTE ACCESS | Protection of Confidentiality / Integrity Using Encryption

Short Description: The information system implements cryptographic mechanisms to protect the confidentiality and integrity of remote access sessions. Examples: Evidence: Supplemental Guidance: The encryption strength of mechanism is selected based on the security categorization of the information.

*IA - 2(1)* IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS) | Network Access To Privileged Accounts

Short Description: The information system implements multi factor authentication for network access to privileged accounts. Example: Evidence: Supplemental Guidance: N/A

*IA - 2(3)* IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS) | Local Access To Privileged Accounts

Short Description: The information system implements multifactor authentication for local access to privileged accounts. Example: Evidence: Supplemental Guidance: N/A

*IA - 2(2)* IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS) | Network Access to Non-Privileged Accounts

Short Description: The information system implements multifactor authentication for network access to non-privileged accounts. Example: Evidence: Supplemental Guidance: N/A

*IA - 2(9)* IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS) | Network Access to Non-Privileged Accounts - Replay Resistant

Short Description: The information system implements replay-resistant authentication mechanisms for network access to non-privileged accounts. Example: Evidence: Supplemental Guidance: Authentication processes resist replay attacks if it is impractical to achieve successful authentications by recording/replaying previous authentication messages. Replay-resistant techniques include, for example, protocols that use nonces or challenges such as Transport Layer Security (TLS) and time synchronous or challenge-response one-time authenticators

*IA - 2(8)* IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS) | Network Access To Privileged Accounts - Replay Resistant

Short Description: The information system implements replay-resistant authentication mechanisms for network access to privileged accounts. Example: Evidence: Supplemental Guidance: Authentication processes resist replay attacks if it is impractical to achieve successful authentications by replaying previous authentication messages. Replay-resistant techniques include, for example, protocols that use nonces or challenges such as Transport Layer Security (TLS) and time synchronous or challenge-response one-time authenticators

*AU - 12* AUDIT GENERATION

Short Description: The information system is *capable* of providing audit records for the *defined events* and allows * org def roles* to choose *which events* are audited for which * org def information system components* Example: different people or groups choose different events for different components. (e.g. Organizition determines that the finance team works with the IDS/IPS managers to determine which events should be audited for financial software and the finance dept) Evidence: audit logs, log management policies, automated mechanisms implementing audit record generation capability Supplemental Guidance: Audit records can be generated from many different information system components. The list of audited events is the set of events for which audits are to be generated. These events are typically a subset of all events for which the information system is capable of generating audit records.

*AC - 17(1)* REMOTE ACCESS | Automated Monitoring / Control

Short Description: The information system monitors and controls remote access methods. Examples: Evidence: Supplemental Guidance: Automated monitoring and control of remote access sessions allows organizations to detect cyber attacks and also ensure ongoing compliance with remote access policies by auditing connection activities of remote users on a variety of information system components (e.g., servers, workstations, notebook computers, smart phones, and tablets).

*AC - 6 (10)* LEAST PRIVILEGE | Prohibit Non-Privileged Users From Executing Privileged Functions

Short Description: The information system prevents non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures. Examples: windows OS function that requires non admins to enter admin credentials before downloading/executing a file. Evidence: Supplemental Guidance: Privileged functions include, for example, establishing information system accounts, performing system integrity checks, or administering cryptographic key management activities. Non-privileged users are individuals that do not possess appropriate authorizations. Circumventing intrusion detection and prevention mechanisms or malicious code protection mechanisms are examples of privileged functions that require protection from non-privileged users. what to say: this almost certianly is covered in the previous couple controls, but what I think of when I see this control is the windows os function that requires users to sign in with administrator credentials when they want to download, or execute a file.

*CM - 7(2)* LEAST FUNCTIONALITY | Prevent Program Execution

Short Description: The information system prevents program execution in accordance with [Selection (one or more): [Assignment: organization-defined policies regarding software program usage and restrictions]; rules authorizing the terms and conditions of software program usage]. Example: Evidence: Supplemental Guidance: N/A

*AU - 9* PROTECTION OF AUDIT INFORMATION

Short Description: The information system protects audit information and audit tools from unauthorized access, modification, and deletion Example: This control has to do with every possible way that audit records can be altered by user/human/environmental influence. Access should be correctly authorized as well as physical considerations to the tangible location of components involved in maintaining and producing audit records. This control has a large overlap with media protection and physical and environmental protection. Evidence: Procedures addressing protection of audit information from unauthorized access, modification, and deletion, Procedures addressing protection of audit information , Evidence showing that the organization authorizes access to management of audit functionality to only the organization defined subset of privileged users, Automated mechanisms implementing audit information protection Supplemental Guidance: Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. This control focuses on technical protection of audit information. Physical protection of audit information is addressed by media protection controls and physical and environmental protection controls.

*AC - 17(3)* REMOTE ACCESS | Managed Access Control Points

Short Description: The information system routes all remote accesses through [Assignment: organization-defined number] managed network access control points. Examples: Evidence: Supplemental Guidance: Limiting the number of access control points for remote accesses reduces the attack surface for organizations. Organizations consider the Trusted Internet Connections (TIC) initiative requirements for external network connections.

*AU - 8* TIME STAMPS

Short Description: The information system uses internal system clocks to generate time stamps for audit records and records time stamps for audit records that can be mapped to either UTC or GMT and meets org def granularity of time measurement. Example: Greenwich Mean Time and Coordinated Universal time are solar clocks that are recognized by the scientific community as being authoritative sources of time keeping. Using sources like these helps provide consistency when dealing with more granular measurements of time such as milliseconds, nanoseconds, etc. Evidence: Procedures addressing time stamp generation, System configuration from 2 (two) in scope servers showing NTP/time clock source in accordance with audit and accountability policy, System configuration from 2 (two) in-scope servers showing time synchronization occurs daily and on system reboot, automated mechanisms implementing time stamp generation Supplemental Guidance: Time stamps generated by the information system include date and time. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. Granularity of time measurements refers to the degree of synchronization between information system clocks and reference clocks, for example, clocks synchronizing within hundreds of milliseconds or within tens of milliseconds. Organizations may define different time granularities for different system components. Time service can also be critical to other security capabilities such as access control and identification and authentication, depending on the nature of the mechanisms used to support those capabilities.

*AC - 19* ACCESS CONTROL FOR MOBILE DEVICES

Short Description: The oragnization: Establishes usage restrictions, configuration requirements, connection requirements, and implementation guidance for organization-controlled mobile devices; and Authorizes the connection of mobile devices to organizational information systems. Examples: Evidence: Supplemental Guidance: A mobile device is a computing device that: (i) has a small form factor such that it can easily be carried by a single individual; (ii) is designed to operate without a physical connection (e.g., wirelessly transmit or receive information); (iii) possesses local, non-removable or removable data storage; and (iv) includes a self-contained power source. Mobile devices may also include voice communication capabilities, on-board sensors that allow the device to capture information, and/or built-in features for synchronizing local data with remote locations. Examples include smart phones, E-readers, and tablets. Mobile devices are typically associated with a single individual and the device is usually in close proximity to the individual; however, the degree of proximity can vary depending upon on the form factor and size of the device. The processing, storage, and transmission capability of the mobile device may be comparable to or merely a subset of desktop systems, depending upon the nature and intended purpose of the device. Due to the large variety of mobile devices with different technical characteristics and capabilities, organizational restrictions may vary for the different classes/types of such devices. Usage restrictions and specific implementation guidance for mobile devices include, for example, configuration management, device identification and authentication, implementation of mandatory protective software (e.g., malicious code detection, firewall), scanning devices for malicious code, updating virus protection software, scanning for critical software updates and patches, conducting primary operating system (and possibly other resident software) integrity checks, and disabling unnecessary hardware (e.g., wireless, infrared). Organizations are cautioned that the need to provide adequate security for mobile devices goes beyond the requirements in this control. Many safeguards and countermeasures for mobile devices are reflected in other security controls in the catalog allocated in the initial control baselines as starting points for the development of security plans and overlays using the tailoring process. There may also be some degree of overlap in the requirements articulated by the security controls within the different families of controls. AC-20 addresses mobile devices that are not organization-controlled.

*CM - 7(5)* LEAST FUNCTIONALITY | Authorized Software/Whitelisting

Short Description: The oragnization: Identifies [Assignment: organization-defined software programs authorized to execute on the information system]; Employs a deny-all, permit-by-exception policy to allow the execution of authorized software programs on the information system; and Reviews and updates the list of authorized software programs [Assignment: organization-defined frequency]. Example: Evidence: Supplemental Guidance: The process used to identify software programs that are authorized to execute on organizational information systems is commonly referred to as whitelisting. In addition to whitelisting, organizations consider verifying the integrity of white-listed software programs using, for example, cryptographic checksums, digital signatures, or hash functions. Verification of white-listed software can occur either prior to execution or at system startup.

*RA - 3* RISK ASSESSMENT

Short Description: The organization *conducts a risk assessment* that includes *likelihood* and *impact*, *documents* the results in an org def document, *reviews* the results in an org defined *frequency*, *disseminates* the risk assessment to org defined *personnel or role*s and *updates* the risk assessment within the org defined *frequency* or whenever there are *significant changes* to the information system. Examples: Conducting an asset based risk assessment is a cornerstone to defining policies that treat different segments of the organization (people, processes, and data) with varying levels of sensitivity. Authoritative sources for threats and vulnerabilities can be of significant aid in assessing risk based on a list of the organizations assets. Threat * Vulnerability * Impact = Risk Evidence: Risk Assessment policies and procedures which covers all relevant FISMA requirements Supplemental Guidance: Clearly defined authorization boundaries are a prerequisite for effective risk assessments. Risk assessments take into account threats, vulnerabilities, likelihood, and impact to organizational operations and assets, individuals, other organizations, and the Nation based on the operation and use of information systems. Risk assessments also take into account risk from external parties (e.g., service providers, contractors operating information systems on behalf of the organization, individuals accessing organizational information systems, outsourcing entities). In accordance with OMB policy and related E-authentication initiatives, authentication of public users accessing federal information systems may also be required to protect nonpublic or privacy-related information. As such, organizational assessments of risk also address public access to federal information systems. Risk assessments (either formal or informal) can be conducted at all three tiers in the risk management hierarchy (i.e., organization level, mission/business process level, or information system level) and at any phase in the system development life cycle. Risk assessments can also be conducted at various steps in the Risk Management Framework, including categorization, security control selection, security control implementation, security control assessment, information system authorization, and security control monitoring. RA-3 is noteworthy in that the control must be partially implemented prior to the implementation of other controls in order to complete the first two steps in the Risk Management Framework. Risk assessments can play an important role in security control selection processes, particularly during the application of tailoring guidance, which includes security control supplementation.

*CM - 5* ACCESS RESTRICTIONS FOR CHANGE

Short Description: The organization *defines, documents, approves, and enforces* *physical and logical access restrictions* associated with the *changes* to the information system. Example: This control applies particularly to defining, documenting, and approving changes in hardware, software, and firmware, such as upgrades and modifications, changes to software libraries, physical and logical access controls, workflow automation, media libraries, abstract layers, and change windows. Evidence: Example of documented approval of changes that impacted logical or physical access restrictions, Organizational processes for managing access restrictions to change OR automated mechanisms supporting/implementing/enforcing access restrictions associated with changes to the information system. Supplemental Guidance: Any changes to the hardware, software, and/or firmware components of information systems can potentially have significant effects on the overall security of the systems. Therefore, organizations permit only qualified and authorized individuals to access information systems for purposes of initiating changes, including upgrades and modifications. Organizations maintain records of access to ensure that configuration change control is implemented and to support after-the-fact actions should organizations discover any unauthorized changes. Access restrictions for change also include software libraries. Access restrictions include, for example, physical and logical access controls (see AC-3 and PE-3), workflow automation, media libraries, abstract layers (e.g., changes implemented into third-party interfaces rather than directly into information systems), and change windows (e.g., changes occur only during specified times, making unauthorized changes easy to discover).

*CM - 8* INFORMATION SYSTEM COMPONENT INVENTORY

Short Description: The organization *develops and documents* an *inventory of information system components* that accurately reflects the current information system, *Includes all components within the authorization boundary*, and is at the *level of granularity deemed necessary* for *tracking and reporting* and includes organization defined information deemed necessary to *achieve effective information system component capability*. The organization should also *review and update* the information system *component inventory* within an org def frequency Example: organizations may choose to implement centralized information system component inventories that include all components from every information system that the organization owns. Some examples of information deemed necessary for effective accountability of info sys components includes: hardware inventory specifications, software license information, software version numbers, component owners, and for network components of devices, machine names and network addresses. Inventory specifications can include, for example, manufacturer, device type, model, serial number, and physical location. Evidence: Documentation that outlines the process for ensuring that new, updated or removed devices are reflected in the information system inventory, Organizational processes for updating inventory of information system components or automated mechanisms implementing updating of the information system component inventory, Evidence of automated mechanisms used to detect the presence of unauthorized hardware, software, and firmware components. Supplemental Guidance: Organizations may choose to implement centralized information system component inventories that include components from all organizational information systems. In such situations, organizations ensure that the resulting inventories include system-specific information required for proper component accountability (e.g., information system association, information system owner). Information deemed necessary for effective accountability of information system components includes, for example, hardware inventory specifications, software license information, software version numbers, component owners, and for networked components or devices, machine names and network addresses. Inventory specifications include, for example, manufacturer, device type, model, serial number, and physical location.

*CA - 7* CONTINUOUS MONITORING

Short Description: The organization *develops* a *continuous monitoring strategy* and *implements* a *continuous monitoring program* that includes the *establishment of org def metrics* to be *monitored* at org def *frequencies* *according to assessments* that should be *conducted at org def frequencies*. Both the *metrics defined* as well as the *assessments* that support such monitoring should be in accordance with the *continuous monitoring strategy*. The *continuous monitoring strategy* should also *include* the *correlation and analysis* of *security-related information* generated by *assessments and monitoring*, *response actions* put in place to *preemptively address* the results of the analysis of security related informaiton, and the *reporting of the security status* of the organization and the information system to org def *personnel* within an org def *frequency* Example: Kinda specific here. Ok - you start with defined metrics to monitor. The metrics should be subject to assessments that occur at organization defined time periods and should be updated with any findings from the assessments. analysis should be conducted based on the correlation of the assessments and the monitoring and response actions should be developed as a result. The security status of the organization should then be reported to personnel or roles at a defined frequency. Continuous monitoring programs facilitate the ongoing awareness of threats, vulnerabilities, and information security to support organizational risk management decisions. The terms continuous and ongoing imply that organizations assess and analyze security controls and information security-related risks at a rate which is sufficient to support organizational risk-based decisions. Continuous monitoring activities are scaled in accordance with the security categories of information systems. Evidence: Automated mechanisms implementing continuous monitoring, Evidence of continuous monitoring through an independent assessment Supplemental Guidance: Continuous monitoring programs facilitate ongoing awareness of threats, vulnerabilities, and information security to support organizational risk management decisions. The terms continuous and ongoing imply that organizations assess/analyze security controls and information security-related risks at a frequency sufficient to support organizational risk-based decisions. The results of continuous monitoring programs generate appropriate risk response actions by organizations. Continuous monitoring programs also allow organizations to maintain the security authorizations of information systems and common controls over time in highly dynamic environments of operation with changing mission/business needs, threats, vulnerabilities, and technologies. Having access to security-related information on a continuing basis through reports/dashboards gives organizational officials the capability to make more effective and timely risk management decisions, including ongoing security authorization decisions. Automation supports more frequent updates to security authorization packages, hardware/software/firmware inventories, and other system information. Effectiveness is further enhanced when continuous monitoring outputs are formatted to provide information that is specific, measurable, actionable, relevant, and timely. Continuous monitoring activities are scaled in accordance with the security categories of information systems.

*CM - 2* BASELINE CONFIGURATION

Short Description: The organization *develops*, *documents*, and *maintains* under configuration control, a *current baseline configuration* of the information system Example: baseline configuration are documented, formally reviewed and agreed upon sets of specification for information systems or configurable items within those components. Examples of things that baseline configurations can include are: software packages pre installed on workstations, current version numbers and patch information on operating systems and applications, network topology and logical placement of those components within the system architecture. Baseline configurations serve as the bedrock for future builds, releases, or changes to the system. Evidence: Baseline configuration documentation for components of the information system, evidence of recent review of current baseline configuration, automated mechanisms supporting review and update of the baseline configuration, Evidence of previous baseline configuration versions, Evidence that systems and/or components are configured for high-risk areas, Organization processes for managing baseline configuration or automated mechanisms supporting configuration control of the baseline configuration Supplemental Guidance: This control establishes baseline configurations for information systems and system components including communications and connectivity-related aspects of systems. Baseline configurations are documented, formally reviewed and agreed-upon sets of specifications for information systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, and/or changes to information systems. Baseline configurations include information about information system components (e.g., standard software packages installed on workstations, notebook computers, servers, network components, or mobile devices; current version numbers and patch information on operating systems and applications; and configuration settings/parameters), network topology, and the logical placement of those components within the system architecture. Maintaining baseline configurations requires creating new baselines as organizational information systems change over time. Baseline configurations of information systems reflect the current enterprise architecture.

*AC - 6* LEAST PRIVILEGE

Short Description: The organization *employs* the principle of *least privilege*, allowing only authorized accesses for *users or processes* which are *necessary* to accomplish assigned tasks in accordance with organizational objectives Examples: Least privilege is implemented that is directly correlated to organizational objectives and reflects this with privilege levels tied to account types. Evidence: Example access authorization form, list of security functions (deployed in hardware, software, and firmware) and security-relevant information for which access must be explicitly authorized, Evidence of automated mechanisms implementing least privilege functions for non-privileged users, evidence that non-privileged accounts, or roles, are used when accessing non-security functions, list of administrative accounts, List of privileged functions to be audited, list of audited events, information system audit records, evidence of automated mechanisms implementing least privilege functions Supplemental Guidance: Organizations employ least privilege for specific duties and information systems. The principle of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions/business functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary, to achieve least privilege. Organizations also apply least privilege to the development, implementation, and operation of organizational information systems. What to Say: Least Privilege is a concept. This is very similar to the prior control. Think about this one, rather, from a top down approach. Data owners/users/custodians. *Data owners* (CEO's upper level management, Authorizing Officials) own the data but don't MODIFY data as regularly as *Data Custodians* (Sys Admins, Network Admins, people with root level access, or approvers who approve LAST with no further checks). Data users are everyone who doesn't need additional approvals. Department managers are somewhat in the middle of a custodian and *Data User* because they regularly approve account modifications. They typically aren't editing logical access applications though so they are typically considered data users also.

*AC - 17* REMOTE ACCESS

Short Description: The organization *establishes and documents* *usage restrictions*, (configuration and connection requirements*, and *implementation guidance* for every *remote access type* AND undergoes a formal *authorization process* *before* allowing the remote connection Example: VPN, RDP, Secure Shells, etc. Policies and procedures for Anything that communicates to the organization through the Internet. Interconnection service agreements may be utilized to authorize remote access although aren't necessary, as this control addresses remote access authorization prior to allowing remote access without specifying the formats for such authorization Evidence: Remote access policies and procedures, unless incorporated in the access control policies and procedures, Evidence that the information system monitors and controls remote access methods, system configuration for encryption level of remote access technology, list of all managed network access control points, automated mechanisms routing all remote accesses through managed network access control points, automated mechanisms implementing remote access management, Overview of remote access technologies including number of access points, primary use of remote access and primary user base, Examples of remote access authorization Supplemental Guidance: Remote access is access to organizational information systems by users (or processes acting on behalf of users) communicating through external networks (e.g., the Internet). Remote access methods include, for example, dial-up, broadband, and wireless. Organizations often employ encrypted virtual private networks (VPNs) to enhance confidentiality and integrity over remote connections. The use of encrypted VPNs does not make the access non-remote; however, the use of VPNs, when adequately provisioned with appropriate security controls (e.g., employing appropriate encryption techniques for confidentiality and integrity protection) may provide sufficient assurance to the organization that it can effectively treat such connections as internal networks. Still, VPN connections traverse external networks, and the encrypted VPN does not enhance the availability of remote connections. Also, VPNs with encrypted tunnels can affect the organizational capability to adequately monitor network communications traffic for malicious code. Remote access controls apply to information systems other than public web servers or systems designed for public access. This control addresses authorization prior to allowing remote access without specifying the formats for such authorization. While organizations may use interconnection security agreements to authorize remote access connections, such agreements are not required by this control. Enforcing access restrictions for remote connections is addressed in AC-3. What to say: This control is looking for a couple things. First establishing and documenting usage restrictions/configuration requirements: this is policy related. This could be part of onboarding documentation, just in a poilcy about remote access, or be something standalone. We want to see there being some kind of guidelines about how remote access is supposed to work, what those guidelines are are up the org. Configuration connection requirements might not be that detailed, but almost every org is going to say that they use some type of VPN. Implementation guidance can be part of something involving onboarding, or a "Remote Access Request" kind of thing. If IT admins set everything up for users though, having this documented could possibly be more informal.

*AC - 20* USE OF EXTERNAL INFORMATION SYSTEMS

Short Description: The organization *establishes terms and conditions*, consistent with any trust relationships established *with other organizations owning*, operating, and/or maintaining external information systems allowing individuals to: gain external access or process, store, or transmit organization controlled information using *external information systems* Examples: operating or maintaining eternal information systems any systems outside of the established boundary for the information system either through a dedicated line, personally owned devices, privately owned computing systems (e.g. coffee shops), anything that you don't typically accept the majority of the scope of risk for Evidence: Listings of applications that are accessible from external information systems, Information system configuration settings and associated documentation for external information systems, evidence of automated mechanisms implementing terms and conditions on use of external information systems Supplemental Guidance: External information systems are information systems or components of information systems that are outside of the authorization boundary established by organizations and for which organizations typically have no direct supervision and authority over the application of required security controls or the assessment of control effectiveness. External information systems include, for example: (i) personally owned information systems/devices (e.g., notebook computers, smart phones, tablets, personal digital assistants); (ii) privately owned computing and communications devices resident in commercial or public facilities (e.g., hotels, train stations, convention centers, shopping malls, or airports); (iii) information systems owned or controlled by nonfederal governmental organizations; and (iv) federal information systems that are not owned by, operated by, or under the direct supervision and authority of organizations. This control also addresses the use of external information systems for the processing, storage, or transmission of organizational information, including, for example, accessing cloud services (e.g., infrastructure as a service, platform as a service, or software as a service) from organizational information systems. For some external information systems (i.e., information systems operated by other federal agencies, including organizations subordinate to those agencies), the trust relationships that have been established between those organizations and the originating organization may be such, that no explicit terms and conditions are required. Information systems within these organizations would not be considered external. These situations occur when, for example, there are pre-existing sharing/trust agreements (either implicit or explicit) established between federal agencies or organizations subordinate to those agencies, or when such trust agreements are specified by applicable laws, Executive Orders, directives, or policies. Authorized individuals include, for example, organizational personnel, contractors, or other individuals with authorized access to organizational information systems and over which organizations have the authority to impose rules of behavior with regard to system access. Restrictions that organizations impose on authorized individuals need not be uniform, as those restrictions may vary depending upon the trust relationships between organizations. Therefore, organizations may choose to impose different security restrictions on contractors than on state, local, or tribal governments. This control does not apply to the use of external information systems to access public interfaces to organizational information systems (e.g., individuals accessing federal information through www.usa.gov). Organizations establish terms and conditions for the use of external information systems in accordance with organizational security policies and procedures. Terms and conditions address as a minimum: types of applications that can be accessed on organizational information systems from external information systems; and the highest security category of information that can be processed, stored, or transmitted on external information systems. If terms and conditions with the owners of external information systems cannot be established, organizations may impose restrictions on organizational personnel using those external systems.

*AC - 18* WIRELESS ACCESS

Short Description: The organization *establishes usage restrictions*, *configuration/connection requirements*, and *implementation guidance* for *wireless access* and *authorizes* wireless access *prior* to allowing such connections Examples: Network admins should assist users who want to use wireless routing and establish usage agreements that users sign off on prior to getting authorization to wireless resources. Admins should also configure company owned devices like wireless routers, company owned PC's, etc based on the organizations business objectives. Evidence: Supplemental Guidance: Wireless technologies include, for example, microwave, packet radio (UHF/VHF), 802.11x, and Bluetooth. Wireless networks use authentication protocols (e.g., EAP/TLS, PEAP), which provide credential protection and mutual authentication.

*CM - 6* CONFIGURATION SETTINGS

Short Description: The organization *establishes*, *documents*, and *actively monitors* *security configuration checklists* that are consistent with the implementation of the *settings* of *hardware*, *software* or *firmware* components that affect the security posture or functionality of the system. Examples: Examples of security settings are: registry settings, account, file, directory and permission settings, functions, ports, protocols, services, and remote connections. Examples of important hardware, software, and firmware: servers, mainframe computers, and routers and switches, firewalls, wireless access points, operating systems, middleware, and applications. Middleware is - usually something that connects two applications and passes data between them (e.g. distributed caches, message queues, packet rewriter) Evidence: Security configuration checklists, hardening standards or other documented parameters for securing, automated mechanisms that implement, monitor, and/or control information system configuration settings Supplemental Guidance: Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the information system that affect the security posture and/or functionality of the system. Information technology products for which security-related configuration settings can be defined include, for example, mainframe computers, servers (e.g., database, electronic mail, authentication, web, proxy, file, domain name), workstations, input/output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security-related parameters are those parameters impacting the security state of information systems including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: (i) registry settings; (ii) account, file, directory permission settings; and (iii) settings for functions, ports, protocols, services, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific settings for information systems. The established settings become part of the systems configuration baseline. Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those information system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including, for example, information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. Common secure configurations include the United States Government Configuration Baseline (USGCB) which affects the implementation of CM-6 and other controls such as AC-19 and CM-7. The Security Content Automation Protocol (SCAP) and the defined standards within the protocol (e.g., Common Configuration Enumeration) provide an effective method to uniquely identify, track, and control configuration settings. OMB establishes federal policy on configuration requirements for federal information systems.

*IR - 3* INCIDENT RESPONSE TESTING

Short Description: The organization *tests the incident response capability* for the information system at an *org def frequency* using *org def tests* to determine the *incident response effectiveness* and *documents* the *results* Example: IR testing can include: the use of checklists, walk-through or tabletop exercises, simulations (parallel or full interrupt) and comprehensive exercises. Evidence: Incident response testing procedures, Incident response testing schedule, Incident response test results, Automated mechanisms that test the incident response capability, Evidence that the organization coordinated incident response testing with organizational elements responsible for related plans Supplemental Guidance: Organizations test incident response capabilities to determine the overall effectiveness of the capabilities and to identify potential weaknesses or deficiencies. Incident response testing includes, for example, the use of checklists, walk-through or tabletop exercises, simulations (parallel/full interrupt), and comprehensive exercises. Incident response testing can also include a determination of the effects on organizational operations (e.g., reduction in mission capabilities), organizational assets, and individuals due to incident response. What to Say:

*AC-2* ACCESS ENFORCEMENT

Short Description: The organization -- a. *Identifies and selects* the following org def information system *account types* to *support organizational objectives* b. *Assigns account managers* for information system *accounts* c. *Establishes conditions* for group and role *membership* d. *Specifies authorized users* of the information system, group and *role membership*, and access authorizations (*privileges*) and other attributes (as required) for *each account* e. Requires *approvals* by org def *personnel or roles* f. *Creates*, *enables*, *modifies*, *disables*, and *removes* information system accounts in accordance with organization defined *conditions* g. *Monitors* the use of information system *accounts* h. *Notifies* account managers: 1. When accounts are *no longer required* 2. When Users are *terminated or transferred* 3. When individual information system usage or need-to-know *changes* i. *Authorizes* access to the information system based on 1. A *valid* access authorization 2. *Intended* system *usage* 3. Other attributes as required by the org j. *Reviews* accounts for compliance with account management *requirements* k. *Establishes* a process or *reissuing* *shared/group* credentials when individuals are *removed* from the group Example: examples of account types include: individual, shared, group, system, guest, anon emergency, developer, manufacturer, vendor, temporary, and service. Account groupings (groups/roles) should have different account managers (departments) which are required to approve access. Account types/groups/roles should have established conditions that can come from job descriptions and that have a basis that directly reflects the organizations business missions and functions. Ideally the mapping should go as follows: groups/roles > specific usernames > admin, super admin, basic, etc. > rwx specifications for files and directories. This control also requires proof of procedures in the form of: account creation, modification, disabling and removal within a defined frequency, monitoring of accounts (auditing), notification account status with respect to the user, vertical continuity of access authorization, review schedule, and reissuing process of service accounts. Supplemental Guidance: Information system account types include, for example, individual, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service. Some of the account management requirements listed above can be implemented by organizational information systems. The identification of authorized users of the information system and the specification of access privileges reflects the requirements in other security controls in the security plan. Users requiring administrative privileges on information system accounts receive additional scrutiny by appropriate organizational personnel (e.g., system owner, mission/business owner, or chief information security officer) responsible for approving such accounts and privileged access. Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. Other attributes required for authorizing access include, for example, restrictions on time-of-day, day-of-week, and point-of-origin. In defining other account attributes, organizations consider system-related requirements (e.g., scheduled maintenance, system upgrades) and mission/business requirements, (e.g., time zone differences, customer requirements, remote access to support travel requirements). Failure to consider these factors could affect information system availability. Temporary and emergency accounts are accounts intended for short-term use. Organizations establish temporary accounts as a 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 (e.g., local logon accounts used for special tasks defined by organizations or when network resources are unavailable). Such accounts remain available and are not subject to automatic disabling or removal dates. Conditions for disabling or deactivating accounts include, for example: (i) when shared/group, emergency, or temporary accounts are no longer required; or (ii) when individuals are transferred or terminated. Some types of information system accounts may require specialized training. Evidence: Evidence that account managers are assigned for information system accounts, Evidence of automated mechanisms implementing account management functions, information system-generated list of temporary accounts removed or disabled, information system-generated list of emergency accounts removed or disabled, Evidence that the system automatically disables inactive accounts after the organization defined time period, evidence that the information system automatically audits AND notifies specific personnel of the following account actions: creation, modification, enabling, disabling, removal, listing of personnel hired within the last six months (assesor provided sample), tickets/evidence showing a creation, enabling, modifying, disabling and removing of information system accounts, evidence showing information system accounts are monitored, evidence showing account managers are (1) notified when accounts are no longer required, (2) users are terminated or transferred, and (3) when individual information system usage or need to know changes, evidence showing the authorizing of access based on (1) a valid access authorization, (2) intended system usage, other attributes as required by organization or associated objectives, evidence that accounts are reviewed in accordance with the organization-defined frequency, evidence of reissuing shared/group account credentials when individuals are removed from the group. What to Say: What kinds of account types do you use? How would you classify the different ways that people use the system, in relation to their access rights and job function? Who manages those different account types (not ticketing)? Do you have a position risk matrix set up? if not what are the reasons that line up with your business and mission functions with why you assign roles to users. Who approves those different accounts that you use. Now I need to see a demonstration of the creating of an account and take screenshots along the way, how are accounts monitored (AD), etc, how are managers notified when, accounts are no longer needed, terminated or transferred, when the information system changes (Key in wording with changes) can I see an access authorization through every one of it's parts (Ticketing part). Do you review accounts for compliance with all of those policies, how do you reissue group account credentials?

*PE - 2* PHYSICAL ACCESS AUTHORIZATIONS

Short Description: The organization Develops approves and maintains a list of individuals with authorized access to the facility where the information system resides, issues authorization credentials for facility access, reviews the access list detailing authorizing facility access by individuals with an organization defined frequency and removes individuals from the facility access list when access is no longer required. Example: Evidence: System-generated ACL for the badge access system administration (i.e who can change access card rights, System-generated ACL for authorized employees with access to the facility, Physical access list rules, ACL of authorized personnel with access to the onsite data center Supplemental Guidance: This control applies to organizational employees and visitors. Individuals (e.g., employees, contractors, and others) with permanent physical access authorization credentials are not considered visitors. Authorization credentials include, for example, badges, identification cards, and smart cards. Organizations determine the strength of authorization credentials needed (including level of forge-proof badges, smart cards, or identification cards) consistent with federal standards, policies, and procedures. This control only applies to areas within facilities that have not been designated as publicly accessible. What to Say:

*AC - 20(2)* USE OF EXTERNAL INFORMATION SYSTEMS | Portable Storage Devices

Short Description: The organization [Selection: restricts; prohibits] the use of organization-controlled portable storage devices by authorized individuals on external information systems. Examples: Evidence: Supplemental Guidance: Limits on the use of organization-controlled portable storage devices in external information systems include, for example, complete prohibition of the use of such devices or restrictions on how the devices may be used and under what conditions the devices may be used.

*AU - 6(3)* AUDIT GENERATION | Correlate Audit Repositories

Short Description: The organization analyzes and correlates audit records across different repositories to gain organization-wide situational awareness. Example: Evidence: Supplemental Guidance: Organization-wide situational awareness includes awareness across all three tiers of risk management (i.e., organizational, mission/business process, and information system) and supports cross-organization awareness.

*CM - 4* SECURITY IMPACT ANALYSIS

Short Description: The organization analyzes changes to the information system to determine potential security impacts prior to change implementation Example: Examples of security impact analyses include: reviewing security plans to understand security control requirements and reviewing system design documentation to understand control implementation and how specific changes may affect the controls, assessments of risk to better understand the impact of changes. Securitiy impact analyses should be conducted by members of the organization responsible for the organizations information security posture such as system admins, ISO's, System security engineers, etc. Evidence: Security Impact analysis documentation, Organizational processes for security impact analysis Supplemental Guidance: Organizational personnel with information security responsibilities (e.g., Information System Administrators, Information System Security Officers, Information System Security Managers, and Information System Security Engineers) conduct security impact analyses. Individuals conducting security impact analyses possess the necessary skills/technical expertise to analyze the changes to information systems and the associated security ramifications. Security impact analysis may include, for example, reviewing security plans to understand security control requirements and reviewing system design documentation to understand control implementation and how specific changes might affect the controls. Security impact analyses may also include assessments of risk to better understand the impact of the changes and to determine if additional security controls are required. Security impact analyses are scaled in accordance with the security categories of the information systems.

*MA - 4* NONLOCAL MAINTENANCE

Short Description: The organization approves and monitors nonlocal maintenance and diagnostic activities, allows the use of nonlocal maintenance and diagnostic tools only as consistent with organizational policy and documented in the security plan for the information system, employs strong authenticators in the establishment of nonlocal maintenance and diagnostic sessions, maintains records for nonlocal maintenance and diagnostic activities, and terminates sessions and network connections when nonlocal maintenance is completed. Example: Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network either externally (the internet) or an internal network. Authentication techniques in this control should map to the controls mentioned in IA-2. Typically strong authenticators are resistant to replay attacks and employ multi-factor authentication. Evidence: An overview of evidence of procedures used for all non-local maintenance, List of all non-local maintenance connections allowed, Example contract and/or SLA with non-local maintenance provider, Organizational processes for managing nonlocal maintenance OR automated mechanisms implementing, supporting, and/or managing nonlocal maintenance Supplemental Guidance: Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. Authentication techniques used in the establishment of nonlocal maintenance and diagnostic sessions reflect the network access requirements in IA-2. Typically, strong authentication requires authenticators that are resistant to replay attacks and employ multifactor authentication. Strong authenticators include, for example, PKI where certificates are stored on a token protected by a password, passphrase, or biometric. Enforcing requirements in MA-4 is accomplished in part by other controls. What to Say:

*AU - 9(4)* PROTECTION OF AUDIT INFORMATION

Short Description: The organization authorizes access to management of audit functionality to only [Assignment: organization-defined subset of privileged users]. Example: Evidence: Supplemental Guidance: Individuals with privileged access to an information system and who are also the subject of an audit by that system, may affect the reliability of audit information by inhibiting audit activities or modifying audit records. This control enhancement requires that privileged access be further defined between audit-related privileges and other privileges, thus limiting the users with audit-related privileges.

*MA - 3(2)* MAINTENANCE TOOLS | Inspect Media

Short Description: The organization checks media containing diagnostic and test programs for malicious code before the media are used in the information system. Example: Evidence: Supplemental Guidance: If, upon inspection of media containing maintenance diagnostic and test programs, organizations determine that the media contain malicious code, the incident is handled consistent with organizational incident handling policies and procedures. What to Say:

*CM - 7* LEAST FUNCTIONALITY

Short Description: The organization configures the information system to provide only essential capabilities, and prohibits or restricts the use of following functions, poorts, protocols, and/or services. Example: Evidence: Supplemental Guidance: Information systems can provide a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). Additionally, it is sometimes convenient to provide multiple services from single information system components, but doing so increases risk over limiting the services provided by any one component. Where feasible, organizations limit component functionality to a single function per device (e.g., email servers or web servers, but not both). Organizations review functions and services provided by information systems or individual components of information systems, to determine which functions and services are candidates for elimination (e.g., Voice Over Internet Protocol, Instant Messaging, auto-execute, and file sharing). Organizations consider disabling unused or unnecessary physical and logical ports/protocols (e.g., Universal Serial Bus, File Transfer Protocol, and Hyper Text Transfer Protocol) on information systems to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling. Organizations can utilize network scanning tools, intrusion detection and prevention systems, and end-point protections such as firewalls and host-based intrusion detection systems to identify and prevent the use of prohibited functions, ports, protocols, and services.

*PE - 5* ACCESS CONTROL FOR OUTPUT DEVICES

Short Description: The organization controls physical access to information system output devices to prevent unauthorized individuals from obtaining the output. Example: Evidence: Supplemental Guidance: Controlling physical access to output devices includes, for example, placing output devices in locked rooms or other secured areas and allowing access to authorized individuals only, and placing output devices in locations that can be monitored by organizational personnel. Monitors, printers, copiers, scanners, facsimile machines, and audio devices are examples of information system output devices. What to Say:

*AC - 22* PUBLICLY ACCESSIBLE CONTENT

Short Description: The organization designates individuals to post information onto a publicly accessible information system and trains individuals who are posting this information not to post nonpublic information. The organization should also review such information prior to posting and review the already posted information to make sure that it doesn't include nonpublic info. Examples: Web development or particularly marketing posting something private about the organization on the companies outward facing website, or social media, etc. Evidence: Procedures addressing publicly accessible content, List of users authorized to post publicly accessible content on organizational information systems, records of publicly accessible information reviews, records of response to nonpublic information on public websites, automated mechanisms implementing management of publicly accessible content. Supplemental Guidance: In accordance with federal laws, Executive Orders, directives, policies, regulations, standards, and/or guidance, the general public is not authorized access to nonpublic information (e.g., information protected under the Privacy Act and proprietary information). This control addresses information systems that are controlled by the organization and accessible to the general public, typically without identification or authentication. The posting of information on non-organization information systems is covered by organizational policy.

*CA - 2* SECURITY ASSESSMENTS

Short Description: The organization develops a security assessment plan that fully describes the scope including: 1. security controls and control enhancements that are under assessment 2. the procedures used to determine security control effectiveness, 3. assessment environment, assessment team, and the teams roles and responsibilities The organization should also assess the security controls in the information and its environment of operation at an org def frequency to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting established security requirements Also the organization should produce a security assessment report that documents the results of the assessment and provides the results of the assessment to org def individuals or roles Examples: This control seeks to address the current state of the procedures used to facilitate a security assessment plan and understand the controls and enhancements and their current and future effectiveness. This control also wants to make sure that the organization is documenting reports associated with this effort and that the appropriate roles are reviewing those documents Evidence: Security Assessment Plan, Evidence that assessors or assessment teams have organization-defined levels of independence to conduct security assessments, prior year security assessment reports, Automated mechanisms supporting security assessment development, and or security assessment reporting Supplemental Guidance: Organizations assess security controls in organizational information systems and the environments in which those systems operate as part of: (i) initial and ongoing security authorizations; (ii) FISMA annual assessments; (iii) continuous monitoring; and (iv) system development life cycle activities. Security assessments: (i) ensure that information security is built into organizational information systems; (ii) identify weaknesses and deficiencies early in the development process; (iii) provide essential information needed to make risk-based decisions as part of security authorization processes; and (iv) ensure compliance to vulnerability mitigation procedures. Assessments are conducted on the implemented security controls from Appendix F (main catalog) and Appendix G (Program Management controls) as documented in System Security Plans and Information Security Program Plans. Organizations can use other types of assessment activities such as vulnerability scanning and system monitoring to maintain the security posture of information systems during the entire life cycle. Security assessment reports document assessment results in sufficient detail as deemed necessary by organizations, to determine the accuracy and completeness of the reports and whether the security controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting security requirements. The FISMA requirement for assessing security controls at least annually does not require additional assessment activities to those activities already in place in organizational security authorization processes. Security assessment results are provided to the individuals or roles appropriate for the types of assessments being conducted. For example, assessments conducted in support of security authorization decisions are provided to authorizing officials or authorizing official designated representatives. To satisfy annual assessment requirements, organizations can use assessment results from the following sources: (i) initial or ongoing information system authorizations; (ii) continuous monitoring; or (iii) system development life cycle activities. Organizations ensure that security assessment results are current, relevant to the determination of security control effectiveness, and obtained with the appropriate level of assessor independence. Existing security control assessment results can be reused to the extent that the results are still valid and can also be supplemented with additional assessments as needed. Subsequent to initial authorizations and in accordance with OMB policy, organizations assess security controls during continuous monitoring. Organizations establish the frequency for ongoing security control assessments in accordance with organizational continuous monitoring strategies. Information Assurance Vulnerability Alerts provide useful examples of vulnerability mitigation procedures. External audits (e.g., audits by external entities such as regulatory agencies) are outside the scope of this control.

*AC - 19(5)* ACCESS CONTROL FOR MOBILE DEVICES |

Short Description: The organization employs [Selection: full-device encryption; container encryption] to protect the confidentiality and integrity of information on [Assignment: organization-defined mobile devices]. Examples: Evidence: Supplemental Guidance: Container-based encryption provides a more fine-grained approach to the encryption of data/information on mobile devices, including for example, encrypting selected data structures such as files, records, or fields.

*AU - 6(1)* AUDIT GENERATION | Process Integration

Short Description: The organization employs automated mechanisms to integrate audit review, analysis, and reporting processes to support organizational processes for investigation and response to suspicious activities. Example: Evidence: Supplemental Guidance: Organizational processes benefiting from integrated audit review, analysis, and reporting include, for example, incident response, continuous monitoring, contingency planning, and Inspector General audits.

*AC - 6 (1)* LEAST PRIVILEGE | Authorize Access To Security Functions

Short Description: The organization explicitly authorizes access to organization defined security functions deployed in hardware, software, and firmware and security relevant information Examples: Vulnerability scanning, accessing management servers, accessing radius servers, etc. Evidence: Supplemental Guidance:Security functions include, for example, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Security-relevant information includes, for example, filtering rules for routers/firewalls, cryptographic key management information, configuration parameters for security services, and access control lists. Explicitly authorized personnel include, for example, security administrators, system and network administrators, system security officers, system maintenance personnel, system programmers, and other privileged users. What to say: This control has to start with the defining of security functions, it's usually easily satisfied through Active Directory Dumps.

*AT - 2(2)* SECURITY AWARENESS TRAINING | Insider Threat

Short Description: The organization includes security awareness training on recognizing and reporting potential indicators of insider threat. Examples: Evidence: Supplemental Guidance: Potential indicators and possible precursors of insider threat can include behaviors such as inordinate, long-term job dissatisfaction, attempts to gain access to information not required for job performance, unexplained access to financial resources, bullying or sexual harassment of fellow employees, workplace violence, and other serious violations of organizational policies, procedures, directives, rules, or practices. Security awareness training includes how to communicate employee and management concerns regarding potential indicators of insider threat through appropriate organizational channels in accordance with established organizational policies and procedures.

*IA - 5* AUTHENTICATOR MANAGEMENT

Short Description: The organization manages information system authenticators by: a. *verifying* the identity, group, role, or device *receiving* the authenticator b. *Establishing initial baseline* content for org def authenticators c. Ensuring authenticators have *sufficient strength* for their intended use d. *Establishing and implementing* administrative *procedures for distributing* authenticators, for *lost*, *compromised*, or *damaged* authenticators and for authenticator *revocation* e. *Changing* the *baseline content* for authenticators f. *Establishing minimum and maximum* lifetime restrictions and *reuse conditions* for authenticators g. *changing/refreshing* authenticators for different time periods for different authenticator *types* h. *protecting* authenticator content from unauthorized *disclosure and modification* i. requiring individuals to *take*, and having *devices implement*, specific *security safeguards* to *protect* authenticators j. *changing authenticators* for group/role accounts when *membership* to those accounts *change* Examples: Individual authenticators include passwords, tokens, biometrics, PKI certificates, and key cards. Initial authenticator content is the actual content (e.g. the initial password) as opposed to requirements about authenticator content (e.g. password length). This control is particularly focused on helping to protect against well known manufacturer default passwords from being compromised. This control is also an effort to encourage organizations to set authenticator specifications (max/min, what types for what roles, baseline configs) as well as procedures to help secure the confidentiality and integrity of authenticators Evidence: List of information system authenticator types, Password configurations and associated documentation, automated mechanisms supporting and/or implementing password-based authenticator management capability, automated mechanisms employing hardware token-based authenticator for the information system, list of token quality requirements, PKI certification validation records, PKI certification revocation lists, Automated mechanisms supporting and/or implementing PKI based, authenticator management capability, registration process or receiving information system authenticators, list of authenticators requiring in-person registration, list of authenticators requiring trusted third party registration, authenticators registration documentation, change control records associated with managing information system authenticators, Automated mechanisms supporting and/or implementing authenticator management capability. Supplemental Guidance: Individual authenticators include, for example, passwords, tokens, biometrics, PKI certificates, and key cards. Initial authenticator content is the actual content (e.g., the initial password) as opposed to requirements about authenticator content (e.g., minimum password length). In many cases, developers ship information system components with factory default authentication credentials to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant security risk. The requirement to protect individual authenticators may be implemented via control PL-4 or PS-6 for authenticators in the possession of individuals and by controls AC-3, AC-6, and SC-28 for authenticators stored within organizational information systems (e.g., passwords stored in hashed or encrypted formats, files containing encrypted or hashed passwords accessible with administrator privileges). Information systems support individual authenticator management by organization-defined settings and restrictions for various authenticator characteristics including, for example, minimum password length, password composition, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication. Specific actions that can be taken to safeguard authenticators include, for example, maintaining possession of individual authenticators, not loaning or sharing individual authenticators with others, and reporting lost, stolen, or compromised authenticators immediately. Authenticator management includes issuing and revoking, when no longer needed, authenticators for temporary access such as that required for remote maintenance. Device authenticators include, for example, certificates and passwords.

*AC - 20(1)* USE OF EXTERNAL INFORMATION SYSTEMS | Limits on Authorized Use

Short Description: The organization permits authorized individuals to use an external information to access the information to process, store, or transmit organization controlled information only when the organization. Verifies the implementation of required security controls on the external system as specified in the organization�s information security policy and security plan; or Retains approved information system connection or processing agreements with the organizational entity hosting the external information system. Examples: Evidence: Supplemental Guidance: This control enhancement recognizes that there are circumstances where individuals using external information systems (e.g., contractors, coalition partners) need to access organizational information systems. In those situations, organizations need confidence that the external information systems contain the necessary security safeguards (i.e., security controls), so as not to compromise, damage, or otherwise harm organizational information systems. Verification that the required security controls have been implemented can be achieved, for example, by third-party, independent assessments, attestations, or other means, depending on the confidence level required by organizations.

*MP - 7(1)* MEDIA USE | Prohibit Use Without Owner

Short Description: The organization prohibits the use of portable storage devices in organizational information systems when such devices have no identifiable owner. Example: Evidence: Supplemental Guidance: Requiring identifiable owners (e.g., individuals, organizations, or projects) for portable storage devices reduces the risk of using such technologies by allowing organizations to assign responsibility and accountability for addressing known vulnerabilities in the devices (e.g., malicious code insertion). What to Say:

*AT - 2 SECURITY AWARENESS TRAINING*

Short Description: The organization provides basic security awareness training to information system users for: new users, when required by system changes, and at an organization defined frequency after that Example: Security awareness training is included as a part of the on boarding process, when required by changes in the system, and at an org def frequency thereafter. This control addresses the need for operations security. Practical examples can include displaying posters, offering supplies inscribed with security reminders, displaying logon messages, and conducting security awareness events. Evidence: List of all new hires from the last six months for assessor to select a sample and verify that all new hires receive basic security awareness training upon hire, Security awareness training on recognizing and reporting potential indicators of insider threat, Evidence that security awareness training is provided to users when required by system changes, List of all current employees for assessor to select a sample and verify refresher training is provided in accordance with the organization defined frequency Supplemental Guidance: Organizations determine the appropriate content of security awareness training and security awareness techniques based on the specific organizational requirements and the information systems to which personnel have authorized access. The content includes a basic understanding of the need for information security and user actions to maintain security and to respond to suspected security incidents. The content also addresses awareness of the need for operations security. Security awareness techniques can include, for example, displaying posters, offering supplies inscribed with security reminders, generating email advisories/notices from senior organizational officials, displaying logon screen messages, and conducting information security awareness events.

*AT - 3 ROLE-BASED SECURITY TRAINING*

Short Description: The organization provides role-based security training to personnel with assigned security roles and responsibilities when required by system changes and at org def freqencies thereafter Examples: this control is the same as the preceeding one but having to do with training based around specific organization defined roles Evidence: Evidence of role based training, List of all current employees for assessor to select a sample to verify refresher training is provided in accordance with organization-defined frequency Supplemental Guidance: Organizations determine the appropriate content of security awareness training and security awareness techniques based on the specific organizational requirements and the information systems to which personnel have authorized access. The content includes a basic understanding of the need for information security and user actions to maintain security and to respond to suspected security incidents. The content also addresses awareness of the need for operations security. Security awareness techniques can include, for example, displaying posters, offering supplies inscribed with security reminders, generating email advisories/notices from senior organizational officials, displaying logon screen messages, and conducting information security awareness events.

*AC - 6 (2)* LEAST PRIVILEGE | Non Privileged Access For Non Security Function

Short Description: The organization requires that users of information 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. Examples: Anything that is nonsecurity and can be executed by non-privileged Evidence: Supplemental Guidance: This control enhancement 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 both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. What to Say: This control somewhat relies on having privileged security functions. Whatever is opposite to that is what this control is asking for.

*AC - 6 (5)* LEAST PRIVILEGE | Privileged Accounts

Short Description: The organization restricts privileged accounts on the information system to [Assignment: organization-defined personnel or roles]. Examples: Evidence: Supplemental Guidance: 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. what to say: This control is very similar to the top two and will probably be satisfied by the same evidence. The distinction between the two is the mapping of a defined security function to an account explicitly mapped to perform certain functions. This control deals with only the account side, having nothing do to with defined functions.

*AU - 6* AUDIT GENERATION

Short Description: The organization reviews and analyzes information system audit records within the organization defined frequency for possible instances of org def inappropriate unusual/anomalous activity and reports that inappropriate activity to org def roles Examples: With a full understanding of the information system utilized, the organization should be able to map appropriate activity that takes place on the information system. Anything other than that would/could quality as inappropriate or anomalous. For example - third parties performing remote maintenance are attempting to view sensitive data possibly available through the application they are maintenanceing. Evidence: Listing of all authorized personnel that reviews and analyzes information system audit records, Procedures addressing investigation and response to suspicious activities, Automated mechanisms integrating audit review, analysis, and reporting processes for investigating suspicious activities and response to suspicious activities, Evidence that audit records are analyzed and correlated across different repositories, Automated mechanisms supporting analysis and correlation of audit records, Procedures for adjusting the level of audit review, analysis and reporting within the information system when there is a change in risk. Supplemental Guidance: Audit review, analysis, and reporting covers information security-related auditing performed by organizations including, for example, auditing that results from monitoring of account usage, remote access, wireless connectivity, mobile device connection, configuration settings, system component inventory, use of maintenance tools and nonlocal maintenance, physical access, temperature and humidity, equipment delivery and removal, communications at the information system boundaries, use of mobile code, and use of VoIP. Findings can be reported to organizational entities that include, for example, incident response team, help desk, information security group/department. If organizations are prohibited from reviewing and analyzing audit information or unable to conduct such activities (e.g., in certain national security applications or systems), the review/analysis may be carried out by other organizations granted such authority.

*AU - 2(3)* AUDIT EVENTS | Reviews and Updates

Short Description: The organization reviews and updates the audited events [Assignment: organization-defined frequency]. Example: Evidence: Supplemental Guidance: Over time, the events that organizations believe should be audited may change. Reviewing and updating the set of audited events periodically is necessary to ensure that the current set is still necessary and sufficient.

*AC-5* SEPARATION OF DUTIES*

Short Description: The organization separates org def duties of individuals and defines information system access authorizations to support the separation of duties Examples: Job descriptions, department descriptions, role descriptions all tied to account types Evidence: List of divisions of responsibility and separation of duties, automated mechanisms implementing separation of duties policy Supplemental Guidance: 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, for example: (i) dividing mission functions and information system support functions among different individuals and/or roles; (ii) conducting information system support functions with different individuals (e.g., system management, programming, configuration management, quality assurance and testing, and network security); and (iii) ensuring security personnel administering access control functions do not also administer audit functions. What to Say: Again keep in mind data. Data = data contained within resources = access to resources = "types of accesses" to resources = job duties = job descriptions. Roles and Responsibilities matrices are perfect. Job Descriptions with reference to the "data sources" that are necessary to complete the duties listed in the job descriptions are sufficient.

CP-9 Information System Backup

Short Description: The organization should *conduct backups* of both *user-level and system-level information* contained in the information system that are *based off backing up org def recovery point objectives* at org def *frequencies*. The organization should also take information system and *security documentation into consideration* with *plotting out backup procedures*. Backup information at storage locations should *abide by the security triad at all times as well*. Example: backup should be considered on both the user and system level as well as relevant documentation. point d is more broad but should be satisfied by the earlier controls adherence to equivelant security controls Evidence: Configuration Management Plan, Organizational processes for developing and documenting the configuration management plan OR organizational processes for identifying and managing configuration items Supplemental Guidance: Configuration management plans satisfy the requirements in configuration management policies while being tailored to individual information systems. Such plans define detailed processes and procedures for how configuration management is used to support system development life cycle activities at the information system level. Configuration management plans are typically developed during the development/acquisition phase of the system development life cycle. The plans describe how to move changes through change management processes, how to update configuration settings and baselines, how to maintain information system component inventories, how to control development, test, and operational environments, and how to develop, release, and update key documents. Organizations can employ templates to help ensure consistent and timely development and implementation of configuration management plans. Such templates can represent a master configuration management plan for the organization at large with subsets of the plan implemented on a system by system basis. Configuration management approval processes include designation of key management stakeholders responsible for reviewing and approving proposed changes to information systems, and personnel that conduct security impact analyses prior to the implementation of changes to the systems. Configuration items are the information system items (hardware, software, firmware, and documentation) to be configuration-managed. As information systems continue through the system development life cycle, new configuration items may be identified and some existing configuration items may no longer need to be under configuration control.

*CA - 5* PLAN OF ACTION AND MILESTONES

Short Description: The organization should *develop* a *plan of action and milestones* or the information system to *document* the *remedial actions* that the organization has set up to *correct weaknesses or deficiencies* noted during the assessment of the security controls and to reduce or eliminate known vulnerabilities and update the existing POAM with the org def frequency based on findings from control assessments, impact analyses and continuous monitoring activities Example: POAMS are formal documents that prioritize the procedures taken to remediate deficiencies in the current security posture of an organization. The risk identified to organization assets as well as the potential impact of certian vulnerabilities exploiting these risks help to prioritize which security controls should be put into place to either mitigate or eliminate flaws that could adversely affect the organizations assets. Plans of action and milestones are key documents in security authorization packages and are subject to federal reporting requirements established by the office of management and budget Evidence: Plan of action and Milestones, Automated Mechanisms for developing, implementing and maintaining plan of action of action and milestones Supplemental Guidance: Plans of action and milestones are key documents in security authorization packages and are subject to federal reporting requirements established by OMB.

*CM - 11* USER-INSTALLED SOFTWARE

Short Description: The organization should *establish org def policies* that *govern the installation of software* by *users* and *enforce* the *installation policies* through *org def methods* and *monitor compliance* within an org def frequency Example: If users are able to install software in organizational information systems the types of software should be monitored, restricted, or allowed according to organization defined policies. Some examples of appropriate installations that organizations include software patches, downloads from approved app stores, etc. policy enforcement methods could be procedural ( periodic examination of user accounts, automated methods (deny all downloads), or a combo of both. Evidence: Policy governing the installation of software by users, Evidence of controls in place around the use of peer-to-peer file sharing technology, Policy governing the installation of software by users, Evidence of controls to enforce software installation policies, Evidence of monitoring policy compliance Supplemental Guidance: If provided the necessary privileges, users have the ability to install software in organizational information systems. To maintain control over the types of software installed, organizations identify permitted and prohibited actions regarding software installation. Permitted software installations may include, for example, updates and security patches to existing software and downloading applications from organization-approved �app stores.� Prohibited software installations may include, for example, software with unknown or suspect pedigrees or software that organizations consider potentially malicious. The policies organizations select governing user-installed software may be organization-developed or provided by some external entity. Policy enforcement methods include procedural methods (e.g., periodic examination of user accounts), automated methods (e.g., configuration settings implemented on organizational information systems), or both.

*MA - 5* MAINTENANCE PERSONNEL

Short Description: The organization should *establishes a process* for *maintenance personnel authorization* and *maintains* a *list* of *authorized maintenance organizations or personnel*, *ensure* that *non escorted personnel* *performing maintenance* have the required *access authorizations* and *designates organizational personnel* with required *access authorizations* and *technical competence* to *supervise* the *maintenance activities* of *personnel* who *do not possess* the required *access authorizations* Example: This control applies to individuals performing either hardware or software maintenance on organizational information systems. Technical competence of supervising individuals relates to the maintenance performed on the information systems while having required access authorizations refers to maintenance on and near the systems. Individuals not previously identified as authorized personnel may require privileged access when required to conduct maintenance activities with little or no notice. Based on risk assessments organizations may issue temporary credentials that may be for one time use or for very limited time periods. Evidence: List of approved maintenance personnel, or organizations, Service provider contracts and/or Service-level agreements, Organizational processes for authorizing and managing maintenance personnel OR automated mechanisms supporting and/or implementing authorization of maintenance personnel Supplemental Guidance: This control applies to individuals performing hardware or software maintenance on organizational information systems, while PE-2 addresses physical access for individuals whose maintenance duties place them within the physical protection perimeter of the systems (e.g., custodial staff, physical plant maintenance personnel). Technical competence of supervising individuals relates to the maintenance performed on the information systems while having required access authorizations refers to maintenance on and near the systems. Individuals not previously identified as authorized maintenance personnel, such as information technology manufacturers, vendors, systems integrators, and consultants, may require privileged access to organizational information systems, for example, when required to conduct maintenance activities with little or no notice. Based on organizational assessments of risk, organizations may issue temporary credentials to these individuals. Temporary credentials may be for one-time use or for very limited time periods. What to Say:

*MP - 3* MEDIA MARKING

Short Description: The organization should *mark information system media* in accordance with *distribution limitations*, *handling caveats*, and *applicable security markings* of the information and *exempt org def types of information system media from marking* as long as the media *remains within org def areas* Example:The application of human readable security attributes. Any type of identifier that is physically printed or labeled on information system media both digital and non-digital. Examples of information system media can include, diskettes, magnetic tapes, external/removable hard disk drives, flash drives, compact disks, and digital video disks, non-digital media includes for example, paper and microfilm Evidence: Evidence of media labeling in accordance with the documented Media Protection policies, Organizational processes for marking information media OR automated mechanisms supporting and/or implementing media marking

*MP - 4* MEDIA STORAGE

Short Description: The organization should *physically control* and *secure organization defined types of digital media* within *organization defined controlled areas* and *protect information system media* *until the media are destroyed or sanitized* using *approved equipment, techniques, and procedures* Example: Includes digital and non-digital media, physically controlling media includes - conducting inventories, check in and check out policies, and generally maintaining accountability for media. secure storage includes locked drawers, cabinets or a controlled media library. The type of storage typically matches with the sensitivity of the data that it is trying to protect. Evidence: Overview of physical security of physical media, such as off-site storage provider, Media destruction policies, Organizational processes for storing information media OR automated mechanisms supporting and/or implementing secure media storage/media protection Supplemental Guidance: Information system media includes both digital and non-digital media. Digital media includes, for example, diskettes, magnetic tapes, external/removable hard disk drives, flash drives, compact disks, and digital video disks. Non-digital media includes, for example, paper and microfilm. Physically controlling information system media includes, for example, conducting inventories, ensuring procedures are in place to allow individuals to check out and return media to the media library, and maintaining accountability for all stored media. Secure storage includes, for example, a locked drawer, desk, or cabinet, or a controlled media library. The type of media storage is commensurate with the security category and/or classification of the information residing on the media. Controlled areas are areas for which organizations provide sufficient physical and procedural safeguards to meet the requirements established for protecting information and/or information systems. For media containing information determined by organizations to be in the public domain, to be publicly releasable, or to have limited or no adverse impact on organizations or individuals if accessed by other than authorized personnel, fewer safeguards may be needed. In these situations, physical access controls provide adequate protection.

*MP - 5* MEDIA TRANSPORT

Short Description: The organization should *protect and control* organization defined *types of information system media* *during transport* *outside of controlled areas* using organization defined *security safeguards*. The organization should also *maintain accountability* for information system *media* *during transport* *outside of controlled area by documenting activities related to transport* and *restrict activities associated* to *transport to authorized personnel*. Example: This control applies to all afformentioned types of digital and non digital media as well as smart phones, tablets, E-readers, etc that are transported outside of controlled areas. Controlled areas are spaces that employ safeguards. Safeguards to protect media include cryptography or locked or sealed containers. Documentation and accountability techniques include check in and check out procedures, logs that maintain check in and check outs, etc. Evidence: Overview of media transportation controls, Cryptographic mechanisms protecting information on digital media during transportation outside controlled areas, Organizational processes for storing information media OR automated mechanisms supporting and/or implementing media storage/protection Supplemental Guidance: Information system media includes both digital and non-digital media. Digital media includes, for example, diskettes, magnetic tapes, external/removable hard disk drives, flash drives, compact disks, and digital video disks. Non-digital media includes, for example, paper and microfilm. This control also applies to mobile devices with information storage capability (e.g., smart phones, tablets, E-readers), that are transported outside of controlled areas. Controlled areas are areas or spaces for which organizations provide sufficient physical and/or procedural safeguards to meet the requirements established for protecting information and/or information systems. Physical and technical safeguards for media are commensurate with the security category or classification of the information residing on the media. Safeguards to protect media during transport include, for example, locked containers and cryptography. Cryptographic mechanisms can provide confidentiality and integrity protections depending upon the mechanisms used. Activities associated with transport include the actual transport as well as those activities such as releasing media for transport and ensuring that media enters the appropriate transport processes. For the actual transport, authorized transport and courier personnel may include individuals from outside the organization (e.g., U.S. Postal Service or a commercial transport or delivery service). Maintaining accountability of media during transport includes, for example, restricting transport activities to authorized personnel, and tracking and/or obtaining explicit records of transport activities as the media moves through the transportation system to prevent and detect loss, destruction, or tampering. Organizations establish documentation requirements for activities associated with the transport of information system media in accordance with organizational assessments of risk to include the flexibility to define different record-keeping methods for the different types of media transport as part of an overall system of transport-related records.

*IR - 2* INCIDENT RESPONSE TRAINING

Short Description: The organization should *provide incident response training* to information system users *consistent with assigned roles and responsibilities* within *org def time periods* of *assuming incident response roles or responsibilities*, when the information system *changes* and then at an *org def frequency thereafter*. Example: Incident response training should be linked to roles and responsibilities. Incident response training should also include training to identify and report suspicious activities, both from external and internal sources. Evidence: Incident response training curriculum & records What to say: How do you train for incident response? what are your roles in regard to incident response? is there an incident response team? what is the team comprised of? how do you train that team? Do you have any other training after system changes? How long until retraining occurs? Supplemental Guidance: Incident response training provided by organizations is linked to the assigned roles and responsibilities of organizational personnel to ensure the appropriate content and level of detail is included in such training. For example, regular users may only need to know who to call or how to recognize an incident on the information system; system administrators may require additional training on how to handle/remediate incidents; and incident responders may receive more specific training on forensics, reporting, system recovery, and restoration. Incident response training includes user training in the identification and reporting of suspicious activities, both from external and internal sources

*MP - 2* MEDIA ACCESS

Short Description: The organization should *restrict access* to *org def types of digital or non digital media* to *org def personnel or roles* Example: Information system media can include both digital or non digital media. Examples of digital media include: diskettes, magnetic tapes, external/removable hard disk drives, flash drives, compact disks, and digital video disks. Non-digital media includes for example: paper and microfilm. Evidence: Evidence of media protection, both logical and physical, based on documented Media Protection policies and procedures, Evidence of monitoring unauthorized access attempts to media, Organizational processes for restricting information media Supplemental Guidance: Information system media includes both digital and non-digital media. Digital media includes, for example, diskettes, magnetic tapes, external/removable hard disk drives, flash drives, compact disks, and digital video disks. Non-digital media includes, for example, paper and microfilm. Restricting non-digital media access includes, for example, denying access to patient medical records in a community hospital unless the individuals seeking access to such records are authorized healthcare providers. Restricting access to digital media includes, for example, limiting access to design specifications stored on compact disks in the media library to the project leader and the individuals on the development team.

*MP - 6* MEDIA SANITATION

Short Description: The organization should *sanitize organization defined media prior* to disposal or release of organization control *using organization defined sanitization techniques and procedures* in accordance with applicable federal and organization standards and policies and *employ sanitization mechanisms with the strength and integrity that match with the security category or classification of information* Example: This control applies to digital or non digital media, sanitization processes removes information clearing, purging, cryptographic erasure, and destruction. Organization can use discretion on the employment of approved sanitization techniques and procedures based on the sensitivity of data. Some organization defined media may not require sanitization if deemed publicly accessible to the public domain. Evidence: Media sanitization records, organizational processes for media sanitization OR automated mechanisms supporting and/or implementing media sanitization

*MA - 3* MAINTENANCE TOOLS

Short Description: The organization should approve, control, and monitor information system maintenance tools Example: The control addresses security-related issues associated with maintenance tools can include hardware, software, and firmware items. Maintenance tools can potentially vehicles for transporting malicious code, either intentionally or unintentionally. Maintenance tools can include: hardware/software diagnostic test equipment and hardware/software packet sniffers. This control does not cover hardware/software components that may support information system maintenance yet are part of the system, for example software implementing ping, ls, ipconfig or the software implementing the monitoring port of a switch. Evidence: Information system maintenance tools and associated documentation, Maintenance tool inspection records, Organizational processes for inspecting maintenance tools OR automated mechanisms supporting and/or implementing inspection of maintenance tools, Organizational processes or inspecting media for malicious code OR automated mechanisms supporting and/or implementing inspection of media used for maintenance, maintenance records, Organizational processes for approving, controlling, and monitoring maintenance tools OR automated mechanisms supporting and/or implementing approval, control, and/or monitoring of maintenance tools Supplemental Guidance: This control addresses security-related issues associated with maintenance tools used specifically for diagnostic and repair actions on organizational information systems. Maintenance tools can include hardware, software, and firmware items. Maintenance tools are potential vehicles for transporting malicious code, either intentionally or unintentionally, into a facility and subsequently into organizational information systems. Maintenance tools can include, for example, hardware/software diagnostic test equipment and hardware/software packet sniffers. This control does not cover hardware/software components that may support information system maintenance, yet are a part of the system, for example, the software implementing �ping,� �ls,� �ipconfig,� or the hardware and software implementing the monitoring port of an Ethernet switch. What to Say:

*MP - 7* MEDIA USE

Short Description: The organization should either *restrict or prohibit* the use of organization defined *types of information system media* on organization defined *systems or components* using organization defined *security safeguards* Example: Includes digital and non digital media and all afformentioned examples of media. This control, in contrast to MP-2, requires a mapping of digital media access to components rather than users. Organization may restrict or prohibit based on defined security safeguards. Evidence: List of approved digital and non-digital media, Automated mechanisms prohibiting use of media on information systems or system components, Procedures addressing usage restrictions, Organizational processes for media use OR automated mechanisms restricting or prohibiting use of information system media on information systems or system components

*IR - 7* INCIDENT RESPONSE ASSISTANCE

Short Description: The organization should provide an incident response support resource, integral to the organizational incident response capability that offers advice and assistance to users of the information system for the handling and reporting of security incidents Example: incident response resources provided by organizations can include: help desks, assistance groups, and access to forensics services when required Evidence: Organizational processes for incident reporting, Automated mechanisms supporting and/or implementing incident reporting Supplemental Guidance: Incident response support resources provided by organizations include, for example, help desks, assistance groups, and access to forensics services, when required.

*IR - 6* INCIDENT REPORTING

Short Description: The organization should require personnel to report suspected security incidents to the organizational incident response capability within an org def time period to org def authorities Example: A good example of a security incident to report would be the receipt of suspicious email communications that can potentially contain malicious code. If necessary time periods and authorities should correspond to directives, executive orders, etc. Note that this control does not call for the defining of security incidents just who they should be reported to and within what amount of time Evidence: Organizational processes for incident reporting, Automated mechanisms supporting and/or implementing incident reporting Supplemental Guidance: The intent of this control is to address both specific incident reporting requirements within an organization and the formal incident reporting requirements for federal agencies and their subordinate organizations. Suspected security incidents include, for example, the receipt of suspicious email communications that can potentially contain malicious code. The types of security incidents reported, the content and timeliness of the reports, and the designated reporting authorities reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Current federal policy requires that all federal agencies (unless specifically exempted from such requirements) report security incidents to the United States Computer Emergency Readiness Team (US-CERT) within specified time frames designated in the US-CERT Concept of Operations for Federal Cyber Security Incident Handling. What to Say:

*IR - 5* INCIDENT MONITORING

Short Description: The organization should track and document information system security incidents Example: examples of documenting system security incidents include: maintaining records about each incident, the status of the incident, and other pertinent information necessary for forensics, evaluating incident details, trends and handling. Evidence: Incident monitoring capability for the organization, Automated mechanisms supporting and/or implementing tracking and documenting of system security incidents Supplemental Guidance: Documenting information system security incidents includes, for example, maintaining records about each incident, the status of the incident, and other pertinent information necessary for forensics, evaluating incident details, trends, and handling. Incident information can be obtained from a variety of sources including, for example, incident reports, incident response teams, audit monitoring, network monitoring, physical access monitoring, and user/administrator reports. What to Say:

*IR - 4* INCIDENT HANDLING

Short Description: The organization should: *implement* an *incident handling capability* for *security incidents* that *include* the particular categories of *preparation, detection and analysis, containment, eradication, and recovery*. The organization should also *coordinate incident handling activities with contingency planning activities* and *incorporate lessons learned* from ongoing incident handling activities into *incident response procedures, training, and testing*, and *implement the resulting changes* accordingly. Example: This can be simply done by implementing the exact verbiage into any in shop/custom created incident response training and supplemental materials. organizations should recognize that incident response capability is dependent on the capability of the information system in conjunction with the mission/business processes being supported by those systems. examples of IR related information can be obtained from a variety of sources including: audit monitoring, network monitoring, physical access monitoring, user/administrator reports, and reported supply chain events. Incident response should be the joint responsibility of coordinating organizational entities such as owners, authorizing officials, human resources offices, personnel security offices, legal departments, etc. Evidence: The information security incident Handling and Breach Notification Procedures, Automated mechanisms that support and/or implement the incident handling process, Incident handling capability for the organization Supplemental Guidance: Organizations recognize that incident response capability is dependent on the capabilities of organizational information systems and the mission/business processes being supported by those systems. Therefore, organizations consider incident response as part of the definition, design, and development of mission/business processes and information systems. Incident-related information can be obtained from a variety of sources including, for example, audit monitoring, network monitoring, physical access monitoring, user/administrator reports, and reported supply chain events. Effective incident handling capability includes coordination among many organizational entities including, for example, mission/business owners, information system owners, authorizing officials, human resources offices, physical and personnel security offices, legal departments, operations personnel, procurement offices, and the risk executive (function). What to say:

*MA - 2* CONTROLLED MAINTENANCE

Short Description: The organization should: a. *schedule, perform, document, and review records* of *maintenance and repair* on information system *components* in *accordance with manufacturer or vendor specifications* and/or *organizational requirements* b. *Approves and monitors* all *maintenance activities*, whether performed *on site or remotely* and particularly whether the equipment is *serviced on site* or removed to *another location* c. *Requires that org def personnel or roles approve* the *removal of components* for *off site maintenance or repairs* d. *sanitizes equipment* to *remove* all information from associated media *prior to the removal* of *components* *off site for maintenance or repairs* e. *Checks* all *potentially impacted security controls* to *verify* that the *controls* are *still functioning properly* *following maintenance or repair actions* f. *Includes* org def *maintenance information* in *maintenance records* Example: This control covers all of the logistics involving any maintenance activities regardless of who is performing said maintenance. Typically maintenance is provided by a third party and therefore measures should be put into place to appropriately ensure the confidentiality, integrity, and availability of all data associated with information system components including business data and necessary configuration and processing related data. Examples of information necessary for creating maintenance records includes: date and time of maintenance, name of individuals performing the maintenance, name of escort, description of maintenance performed and information system components removed or replaced. Evidence: Maintenance records for the last six months, Equipment and media sanitization records, Organizational processes for scheduling, performing, documenting, reviewing, approving and monitoring maintenance and repairs for the information system, Organizational processes for sanitizing information system components, Automated mechanisms supporting and/or implementing controlled maintenance, Automated mechanisms implementing sanitization of information system components Supplemental Guidance: This control addresses the information security aspects of the information system maintenance program and applies to all types of maintenance to any system component (including applications) conducted by any local or nonlocal entity (e.g., in-contract, warranty, in-house, software maintenance agreement). System maintenance also includes those components not directly associated with information processing and/or data/information retention such as scanners, copiers, and printers. Information necessary for creating effective maintenance records includes, for example: (i) date and time of maintenance; (ii) name of individuals or group performing the maintenance; (iii) name of escort, if necessary; (iv) a description of the maintenance performed; and (v) information system components/equipment removed or replaced (including identification numbers, if applicable). The level of detail included in maintenance records can be informed by the security categories of organizational information systems. Organizations consider supply chain issues associated with replacement components for information systems. What to Say:

*PE - 3* PHYSICAL ACCESS CONTROL

Short Description: The organization: a. Enforces physical access authorizations at [Assignment: organization-defined entry/exit points to the facility where the information system resides] by; 1. Verifying individual access authorizations before granting access to the facility; and 2. Controlling ingress/egress to the facility using [Selection (one or more): [Assignment: organization-defined physical access control systems/devices]; guards]; b. Maintains physical access audit logs for [Assignment: organization-defined entry/exit points]; c. Provides [Assignment: organization-defined security safeguards] to control access to areas within the facility officially designated as publicly accessible; d. Escorts visitors and monitors visitor activity [Assignment: organization-defined circumstances requiring visitor escorts and monitoring]; e. Secures keys, combinations, and other physical access devices; f. Inventories [Assignment: organization-defined physical access devices] every [Assignment: organization-defined frequency]; and g. Changes combinations and keys [Assignment: organization-defined frequency] and/or when keys are lost, combinations are compromised, or individuals are transferred or terminated. Example: Evidence: Description of the physical security system (i.e, nature and extent of the audible alarms, motion detectors, cameras, glass breakage sensors, etc.), Third party agreements for security guards and related services, if applicable, Inventory records of physical access control devices, Organizational processes for physical access control; automated mechanisms supporting and/or implementing physical access control; physical access control devices Supplemental Guidance: This control applies to organizational employees and visitors. Individuals (e.g., employees, contractors, and others) with permanent physical access authorization credentials are not considered visitors. Organizations determine the types of facility guards needed including, for example, professional physical security staff or other personnel such as administrative staff or information system users. Physical access devices include, for example, keys, locks, combinations, and card readers. Safeguards for publicly accessible areas within organizational facilities include, for example, cameras, monitoring by guards, and isolating selected information systems and/or system components in secured areas. Physical access control systems comply with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. The Federal Identity, Credential, and Access Management Program provides implementation guidance for identity, credential, and access management capabilities for physical access control systems. Organizations have flexibility in the types of audit logs employed. Audit logs can be procedural (e.g., a written log of individuals accessing the facility and when such access occurred), automated (e.g., capturing ID provided by a PIV card), or some combination thereof. Physical access points can include facility access points, interior access points to information systems and/or components requiring supplemental access controls, or both. Components of organizational information systems (e.g., workstations, terminals) may be located in areas designated as publicly accessible with organizations safeguarding access to such devices. What to Say:

*AC - 17(4)* REMOTE ACCESS | Privileged Commands / Access

Short Description: The organization: Authorizes the execution of privileged commands and access to security-relevant information via remote access only for [Assignment: organization-defined needs]; and Documents the rationale for such access in the security plan for the information system. Examples: Evidence: Supplemental Guidance: N/A

*CM - 7(4)* LEAST FUNCTIONALITY | Unauthorized Or Authorized Softweare

Short Description: The organization: Identifies [Assignment: organization-defined software programs not authorized to execute on the information system]; Employs an allow-all, deny-by-exception policy to prohibit the execution of unauthorized software programs on the information system; and Reviews and updates the list of unauthorized software programs [Assignment: organization-defined frequency]. Example: The organization Identifies [Assignment: organization-defined software programs not authorized to execute on the information system]; employs an allow-all, deny-by-exception policy to prohibit the execution of unauthorized software programs on the information system; and reviews and updates the list of unauthorized software programs [Assignment: organization-defined frequency]. Evidence: Supplemental Guidance: The process used to identify software programs that are not authorized to execute on organizational information systems is commonly referred to as blacklisting. Organizations can implement CM-7 (5) instead of this control enhancement if whitelisting (the stronger of the two policies) is the preferred approach for restricting software program execution.

*CM - 7(1)* LEAST FUNCTIONALITY | Periodic Review

Short Description: The organization: Reviews the information system [Assignment: organization-defined frequency] to identify unnecessary and/or nonsecure functions, ports, protocols, and services; and disables [Assignment: organization-defined functions, ports, protocols, and services within the information system deemed to be unnecessary and/or nonsecure]. Example: Evidence: Supplemental Guidance: The organization can either make a determination of the relative security of the function, port, protocol, and/or service or base the security decision on the assessment of other entities. Bluetooth, FTP, and peer-to-peer networking are examples of less than secure protocols.

*IA - 6* AUTHENTICATOR FEEDBACK

Short Description: the information system *obscures feedback* of *authentication information* *during the authentication process* to *protect* the information from possible *exploitation/use by unauthorized individuals*. Example: Authenticator feedback refers to any credentials that may be visible to individuals during the course of credential entering. Desktops or notebooks with relatively large screens are typically at higher risk than a mobile devices or smaller devices. Ways to mitigate this exposure include: displaying asterisks when users type in passwords, or setting time limitations for how long feedback appears, a screen cover that tints the screen from side angles, etc. Evidence: Message displayed when invalid user ID and/or password are entered for all in-scope systems, Automated mechanisms supporting and/or implementing the obscuring of feedback of authentication information during authentication Supplemental Guidance: The feedback from information systems does not provide information that would allow unauthorized individuals to compromise authentication mechanisms. For some types of information systems or system components, for example, desktops/notebooks with relatively large monitors, the threat (often referred to as shoulder surfing) may be significant. For other types of systems or components, for example, mobile devices with 2-4 inch screens, this threat may be less significant, and may need to be balanced against the increased likelihood of typographic input errors due to the small keyboards. Therefore, the means for obscuring the authenticator feedback is selected accordingly. Obscuring the feedback of authentication information includes, for example, displaying asterisks when users type passwords into input devices, or displaying feedback for a very limited time before fully obscuring it.

*AC - 11* SESSION LOCK

Short Description: the information system *prevents* further access to the system by initiating a *session lock* after a the time period of inactivity AND retains the session lock *until* the user *reestablishes* access using established identification procedures Supplemental Guidance: Session locks are temporary actions taken when users stop work and move away from the immediate vicinity of information systems but do not want to log out because of the temporary nature of their absences. Session locks are implemented where session activities can be determined. This is typically at the operating system level, but can also be at the application level. Session locks are not an acceptable substitute for logging out of information systems, for example, if organizations require users to log out at the end of workdays. Examples: Session lock settings through AD or other domain management Evidence: System configuration setting that locks the screen, Screenshot of the lock screen and screenshot of the screensaver settings (to make sure that previously visible information is no longer visible), policy that defines the time period, VPN configuration if remote over VPN, reestablishment procedures using identification and authentication procedures What to say: this control and the term "session lock" is almost always used synonymously with "inactivity timeout" and most of the time goes hand in hand with session termination. The distinction between session and termination can be garnered through this example. When users are editing a document in live time in share point, that document is being maintained by use of the session layer (Own type of encryption cipher, own osi layer). That's just one example but can apply to other applications/services.

*IA - 2* IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS)

Short Description: the information system *uniquely identifies* and *authenticates* organizational *users or processes* acting on behalf of organizational users Examples: individuals (employees, contractors, guest researchers) should have defined accesses that involve credentials (passwords, tokens, or biometrics) to authenticate uniquely user identities. Access should also be defined as local or network access. Every user or process should be able to be uniquely identified using some type of org def credential. Evidence: system generated list of user accounts on all in-scope systems, system configuration for multi factor authentication network access for privileged accounts, Evidence of PIV credentials, PIV credential authorizations, Automated mechanisms supporting and or/implementing acceptance and verification of PIV credentials, System configuration for multi-factor authentication local access for privileged accounts, Automated mechanisms supporting and/or implementing replay resistant authentication mechanisms for network access to privileged accounts, system generated list of privileged user accounts on all in-scope systems, system configuration for password requirements on all in-scope systems, Systems configuration for multi-factor authentication for Remote users, Automated mechanisms supporting and/or implementing identification and authentication capability Supplemental Guidance: Organizational users include employees or individuals that organizations deem to have equivalent status of employees (e.g., contractors, guest researchers). This control applies to all accesses other than: (i) accesses that are explicitly identified and documented in AC-14; and (ii) accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity. Organizations employ passwords, tokens, or biometrics to authenticate user identities, or in the case multifactor authentication, or some combination thereof. Access to organizational information systems is defined as either local access or network access. Local access is any access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained by direct connections without the use of networks. Network access is access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks (e.g., the Internet). Internal networks include local area networks and wide area networks. In addition, the use of encrypted virtual private networks (VPNs) for network connections between organization-controlled endpoints and non-organization controlled endpoints may be treated as internal networks from the perspective of protecting the confidentiality and integrity of information traversing the network. Organizations can satisfy the identification and authentication requirements in this control by complying with the requirements in Homeland Security Presidential Directive 12 consistent with the specific organizational implementation plans. Multifactor authentication requires the use of two or more different factors to achieve authentication. The factors are defined as: (i) something you know (e.g., password, personal identification number [PIN]); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric). Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD common access card. In addition to identifying and authenticating users at the information system level (i.e., at logon), organizations also employ identification and authentication mechanisms at the application level, when necessary, to provide increased information security. Identification and authentication requirements for other than organizational users are described in IA-8.

*AU - 7* AUDIT REDUCTION AND REPORT GENERATION

Short Description: the information system provides an audit reduction and report generation capability that supports on-demand audit review, analysis, and reporting requirements and after the fact investigations of security incidents and doesn't alter any metadata, particularly timestamp, of the log. Example: This control is often satisfied through log management software reporting capabilities. This control also requires that access to log management software is correctly configured and that the users to can access the software are responsibility or the integrity of the logs themselves and how they are reported on. Also includes the ability to keep accurate timestamps at a granular enough frequency. Not necessarily that the timestamps themselves are accurate Evidence: Evidence of audit reduction and report capability, Evidence that the information system provides the capability to process records for events of interest based on the organization-defined audit fields within audit records, Example report of the audit reduction process, Evidence of automatic audit record analysis Supplemental Guidance: Audit reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts. Audit reduction and report generation capabilities do not always emanate from the same information system or from the same organizational entities conducting auditing activities. Audit reduction capability can include, for example, modern data mining techniques with advanced data filters to identify anomalous behavior in audit records. The report generation capability provided by the information system can generate customizable reports. Time ordering of audit records can be a significant issue if the granularity of the timestamp in the record is insufficient.

*AU - 5* RESPONSE TO AUDIT PROCESSING FAILURES

Short Description: the organization org def personnel in the event of an audit processing failure; and takes org def actions to be taken in that event Example: Audit logs should be put in place to be able to handle the majority of forensic/tracing back analysis. Therefore for accomplishing organization defined triage it should be, based on pre existing plans for auditing, almost perfect. If anything were to fail in regards to audit capability, the organization should put measures into place to make the best of the situation or to at least be able to narrow the cause of either the problem, or why the cause of the problem can't be determined, down to the smallest margin of error as possible. Examples: Listing of personnel notified of an audit processing failure, Evidence of personnel notified when an audit failure occurs, Automated mechanisms implementing information system response to audit processing failures Supplemental Guidance: Audit processing failures include, for example, software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Organizations may choose to define additional actions for different audit processing failures (e.g., by type, by location, by severity, or a combination of such factors). This control applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the total audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both.

*CM - 3* CONFIGURATION CHANGE CONTROL

Short Description: the organization: a. Determines the types of changes to the information system that are configuration-controlled b. Reviews proposed configuration-controlled changes to the information system and approves c. Documents configuration change decisions associated with the information system d. implements approved configuration-controlled changes to the information system e. Retains records of configuration-controlled changes to the information system for organization defined time periods f. Audits and reviews activities associated with configuration-controlled changes to the information system f. Coordinates and provides oversight for configuration change control activities through an org def configuration change control element that convenes either during an org def frequency or in accordance to org def configuration change conditions Example: Configuration change control includes changes to baseline configuration for components and configuration items of information systems, changes to configuration settings for information technology products (e.g. operating systems, applications, firewalls, routers, and mobile devices), unscheduled/unauthorized changes, and changes made to remediate vulnerabilities. The change control process is typically executed through the usage of a ticketing and provisioning software that involves the queueing and assignment of necessary changes to system components and the acquisition and execution of these functions by authorized personnel. There also may involve a further authorization step from org def roles before tickets can be assigned or changes set into production. In some cases this process is conducted through less formal means of communication Evidence: Documented change control process if not included in the Configuration Management policies and procedures, a few sample changes showing that they were tested, validated and documented, Automated mechanisms supporting and/or implementing testing, validating, and documenting information system changes, Supplemental Guidance: Configuration change controls for organizational information systems involve the systematic proposal, justification, implementation, testing, review, and disposition of changes to the systems, including system upgrades and modifications. Configuration change control includes changes to baseline configurations for components and configuration items of information systems, changes to configuration settings for information technology products (e.g., operating systems, applications, firewalls, routers, and mobile devices), unscheduled/unauthorized changes, and changes to remediate vulnerabilities. Typical processes for managing configuration changes to information systems include, for example, Configuration Control Boards that approve proposed changes to systems. For new development information systems or systems undergoing major upgrades, organizations consider including representatives from development organizations on the Configuration Control Boards. Auditing of changes includes activities before and after changes are made to organizational information systems and the auditing activities required to implement such changes.

*MA - 3(1)* MAINTENANCE TOOLS | Inspect Tools

Short Description:T he organization inspects the maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications. Example: Evidence: Supplemental Guidance: If, upon inspection of maintenance tools, organizations determine that the tools have been modified in an improper/unauthorized manner or contain malicious code, the incident is handled consistent with organizational policies and procedures for incident handling. What to Say:

*AC - 18(1)* WIRELESS ACCESS | Authentication and Encryption

Short Description:The information system protects wireless access to the system using authentication of [Selection (one or more): users; devices] and encryption. Examples: Evidence: Supplemental Guidance: N/A