Exhibit_B_-Security_Plan.doc

FOR OFFICIAL USE ONLY

[Document classification not provided]

DHS Sample System

([project acronym not provided]) [project ID not provided] System Security Plan

(SSP)

Prepared for

17 March 2015 (Content Version – 2012-01) THE ATTACHED MATERIALS CONTAIN DEPARTMENT OF HOMELAND SECURITY INFORMATION THAT IS UNCLASSIFIED UNTIL FILLED IN (FOR OFFICIAL USE ONLY) INFORMATION REQUIRING PROTECTION AGAINST UNAUTHORIZED DISCLOSURE. THE ATTACHED MATERIALS MUST BE HANDLED AND SAFEGUARDED IN ACCORDANCE WITH PUBLIC LAW, EXECUTIVE ORDERS, DHS MANAGEMENT DIRECTIVES, AND OTHER REGULATIONS GOVERNING PROTECTION AND DISSEMINATION OF SUCH INFORMATION.

AT A MINIMUM, THE ATTACHED MATERIALS WILL BE DISSEMINATED ONLY ON A "NEED-TO-KNOW" BASIS AND WHEN UNATTENDED, MUST BE STORED IN AN APPROPRIATE MANNER AS DIRECTED BY PUBLIC LAW, EXECUTIVE ORDERS, DHS MANAGEMENT DIRECTIVES, AND OTHER REGULATIONS REGARDING PROTECTION AGAINST THEFT, COMPROMISE, INADVERTENT ACCESS, AND UNAUTHORIZED DISCLOSURE.

DOCUMENT CHANGE HISTORY

1.0

Initial Release.

Preface This system security plan (SSP) was developed by Department of Homeland Security Headquarters (DHS HQ) under the direction of the Department of Homeland Security Headquarters (DHS HQ) for use on designated National Security Systems.

This plan is based upon a review of the environment, documentation, DHS regulations/guidance, and interviews with the information system personnel conducted between dates. In addition to this plan, Risk Assessment (RA), Security Assessment Report (SAR), and Plan of Action and Milestones (POA&M)] have been developed under this task.

This SSP documents the current and planned controls for the system and addresses security concerns that may affect the system’s operating environment.

TABLE OF CONTENTS

Preface

1.0 System Identification

1.1 Definition

1.2 System Name

1.3 Information Categorization

1.4 Responsible Organization/Personnel and Contact Information

1.5 System Operation

1.5.1 System Operational Status

1.5.2 Authorization Status

1.5.3 System Operation (Government or Contractor Operation)

1.6 General Description/Mission

1.6.1 Authorization Boundary

1.6.2 System Users

1.6.3 Architecture

1.6.4 Major Applications

1.6.5 Subsystems/Minor Applications

1.6.6 Hardware/Virtual Machines/Software/Firmware Description

1.6.7 Encryption/PKI

1.6.8 Encryption Devices

1.7 System Environment

1.8 NSS Physical Environment Considerations

1.9 System Interconnection/Information Sharing

1.9.1 Information Flow

1.9.2 System Interconnections

1.9.3 Cross Domain Solutions

1.9.4 Cloud Service Layers

1.9.5 Mobile Code

1.9.6 Ports, Protocols, & Services

1.10 Privacy Considerations

1.11 Overlays

1.12 Applicable Laws/ Regulations/Policies Affecting the System

1.12.1 Sensitive Systems Laws, Regulations, and Policies

(with 800-53 Rev 4)

1.12.2 National Security Systems Laws, Regulations, and Policies

2.0 Access Control (AC)

3.0 Awareness and Training (AT)

4.0 Audit and Accountability (AU)

5.0 Security Assessment and Authorization (CA)

6.0 Configuration Management (CM)

7.0 Contingency Planning (CP)

8.0 Identification and Authentication (IA)

9.0 Incident Response (IR)

10.0 Maintenance (MA)

11.0 Media Protection (MP)

12.0 Physical and Environmental Protection (PE)

13.0 Planning (PL)

14.0 Personnel Security (PS)

15.0 Risk Assessment (RA)

16.0 System and Services Acquisition (SA)

17.0 System and Communications Protection (SC)

18.0 System and Information Integrity (SI)

19.0 Program Management (PM)

20.0 Privacy

21.0 Plan Approval

Acronyms

LIST OF TABLES

Table 1‑1 System Name

Table 1‑2 Security Categorization

Table 1‑3 System Designations

Table 1‑4 Information Types

1.0 System Identification

This system security plan (SSP) provides an overview of security requirements for DHS Sample System([project acronym not provided]) and describes controls in place or planned for implementation to provide a level of security appropriate for the information processed. The SSP includes user responsibilities, roles and limitations, and general security procedures for users and security personnel. This section describes the implementation status security controls.

Security safeguards for the system shall meet the policy requirements set forth in this SSP. All systems are subject to monitoring consistent with applicable laws, regulations, agency policies, procedures, and practices.

1.1 Definition

1.2 System Name

Table 1.0‑1 System Name

FISMA ID:

1.3 Information Categorization

This section summarizes the [project acronym not provided] information security categorization levels as determined by the FIPS 199 Information Security Categorization. The [project acronym not provided] security impact levels for each of the three security objectives of confidentiality, integrity, and availability are identified in Table 1-2.

Table 1.0‑2 Security Categorization

Table 1.0‑3 System Designations

System Contains Privacy Data or PII

Table 1.0‑4 Information Types

1.4 Responsible Organization/Personnel and Contact Information The following DHS Component/Personnel are identified as the parties responsible for the system development of DHS Sample System, its software maintenance and patch management. Also identified are the roles of system owner, technical information point-of-contact, authorizing official, security control assessor, CISO/ISSM, ISSO and any other role that has a significant responsibility to ensure the system is appropriately secure. It is the functional proponent or advocate for the information system and the activity responsible for identifying the funding for system development, deployment, and maintenance throughout the system's life cycle.

Table 1-5. Responsibility/Accountability Matrix

1.5 System Operation

1.5.1 System Operational Status The information system is in the following life cycle status:

1.5.2 Authorization Status

The information system has the following authorization status:

1.5.3 System Operation (Government or Contractor Operation)

{Identify who owns the system and who operates the system. The values are Government Owned Government Operated (GOGO), Government Owned Commercially Operated (GOCO), Commercially Owned Government Operated (COGO), or Commercially Owned Commercially Operated (COCO).}

1.6 General Description/Mission

The following section provides an overview of the [project acronym not provided], and identifies the system’s mission, capabilities, users, and information data flow. It also describes the hardware, software and firmware implemented in support of [project acronym not provided].

1.6.1 Authorization Boundary

Define all computers and related equipment within the location(s), defined under the System Environment step, along with the internal and external connections (e.g., a router and all systems connected to its local-area ports). A network diagram can also be inserted in the box below. See the expanded Help page for detailed instructions for inserting an image. Images in the format of bmp, jpeg, gif and png can be inserted.

1.6.2 System Users

System Users Categories

Project Personnel User Roles

1.6.3 Architecture

The following architectural drawings of DHS Sample System provide a visual depiction of the major system hardware elements that constitute DHS Sample System.

1.6.4 Major Applications

The following table(s) identifies the major applications supported by the information system.

Table 1-6. Major Application Supported by DHS Sample System

1.6.5 Subsystems/Minor Applications

The following table(s) identify the subsystems/Minor Applications for DHS Sample System.

Table 1-7. DHS Sample System Subsystems/Minor Applications

1.6.6 Hardware/Virtual Machines/Software/Firmware Description Table 1-5.1 lists the principal system hardware elements for DHS Sample System.

Table 1-5.1. System Hardware/Virtual Machines

An entire list of the system hardware and software inventory is maintained per NIST SP 800-53 CM-2 and is available for review by contacting the system ISSO.

There is no software in the project.

1.6.7 Encryption/PKI

{This section should address the types of encryption solutions deployed for the information system.}

Table 1-6. PKI Certificates

1.6.8 Encryption Devices

{Identify any encryption devices used in the system architecture. These should be identified in the system architecture diagram included in section 1.4.5, and described in the following table:}

Table 1-10. Encryption Devices

1.7 System Environment

{This section should discuss the physical environment of the information system including any special circumstances that may increase the risk of the operating the system - For example: The system does not not reside in a DHS Datacenter (DC1 or DC2).

This section should also detail any system elements, hardware or software that mitigates the security risks of operating the system. }

1.8 NSS Physical Environment Considerations

{This section should address the types of encryption solutions deployed for the information system.}

Table 1-11 NSS Physical Environment Considerations

Who authorized or approved the facility?

Provide date and location of approval letter.

1.9 System Interconnection/Information Sharing

1.9.1 Information Flow

{This section should discuss how data flows across each interconnection listed in the tables above as well as describe the flow of data across key internal system boundaries.}

1.9.2 System Interconnections

There is no system interconnection/information sharing associated with your project.

1.9.3 Cross Domain Solutions

{Is there a Cross Domain Solution associated with the system? A CDS is required for any information that crosses a security domain electronically. Manual (i.e., sneaker-net) transfers must also be identified. If there is a cross domain system associated with the system a table like the one below should be completed. } Table 1-13: Cross Domain Solutions

1.9.4 Cloud Service Layers

Information systems, particularly those based on cloud architecture models, are made up of different service layers. The layers of the DHS Sample System that are defined in this SSP, and are not leveraged by any other Provisional Authorizations, are indicated in the table that follows.

Table 1-14: Cloud Service Layers Represented in this SSP

Service Provider Architecture Layers

1.9.5 Mobile Code

{This section should declare the use and approval of any mobile code deployed within the boundaries of the information system.}

1.9.6 Ports, Protocols, & Services

Table 1-8. Ports, Protocols, and Services

1.10 Privacy Considerations

{Section 208 of the E-Government Act of 2002 and Section 522 of the Consolidated Appropriations Act of 2005 require that when developing or procuring IT systems or projects that collect, use, store, and/or disclose information in identifiable form from or about members of the public or organization employees (the latter prescribed by sect. 522), to identify potential privacy risks and implement appropriate privacy controls and compliance requirements. Insert the system "does" or "does not" contain privacy information. Determine and document if the Privacy Act applies to this system. If the Privacy Act applies and the system contains privacy information, insert a reference to privacy-related documentation (e.g., A Privacy Impact Assessment (PIA), Privacy Threshold Analysis (PTA) was conducted as part of the current authorization process), and the date the documentation was submitted.}

1.11 Overlays

{This section provides a listing of any applicable overlays applied to the NSS. An applied overlay should be used to complement the security control baselines and parameter values, and provides a specification of security controls and supporting guidance that may be more stringent or less stringent than the security controls and guidance complemented.

CNSSI 1253 Appendix K provides additional guidance on overlays.

The below format is a suggested way to capture those overlays that may be applied to an NSS, and should be a comprehensive listing of all applied overlays. If no overlays applied to this NSS, include a statement in this section along to the effect of, "No overlays apply to this NSS."

[Name of Overlay applicable to NSS, if any] [Name of Overlay applicable to NSS, if any]}

{For DHS sensitive systems, use "No overlays apply to this system."}

1.12 Applicable Laws/ Regulations/Policies Affecting the System

1.12.1 Sensitive Systems Laws, Regulations, and Policies

Following are the laws and regulations that affect the system:

· Federal Information Security Management Act of 2002 (FISMA), 44 USC 3541 et seq., enacted as Title III of the E-Government Act of 2002, Pub L 107-347, 116 Stat 2899

· Office of Management and Budget (OMB) Circular A-130, "Management of Federal Information Resources," revised, November 30, 2000

· DHS Management Directive MD 140-01, "Information Technology Systems Security," July 31, 2007

· National Institute of Standards and Technology (NIST) Federal Information Processing Standard FIPS 200, "Minimum Security Requirements for Federal Information and Information Systems," March 2006

· NIST SP 800-53, Rev 4, "Recommended Security Controls for Federal Information Systems and Organizations," August 2009, with updated errata May 01, 2010

· DHS Sensitive Systems Policy Directive 4300A

· DHS Sensitive Systems Handbook 4300A

Component and System Specific Laws/Regulations/Policies:

· Department of Homeland Security Department of Homeland Security Sensitive Systems Policy Directive 4300A Version 10 (with 800-53 Rev 4) 20 May 2014

(with 800-53 Rev 4)

1.12.2 National Security Systems Laws, Regulations, and Policies For laws, regulations, and policies that apply to DHS national security systems, refer to 4300B.108-1.

2.0 Access Control (AC)

Control: Access Control Policy and Procedures The organization:

(a) Develops, documents, and disseminates to personnel and roles as defined in DHS 4300A Policy:

(1) An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and,

(2) Procedures to facilitate the implementation of the access control policy and associated access controls.

(b) Reviews and updates the current:

(1) Access control policy Annually; and,

(2) Access control procedures Annually.

Supplemental Guidance

This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the AC family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures.

Related control: PM-9.

References: NIST Special Publications 800-12, 800-100.

Implementation: This control may be partially inherited by designated systems.

[DHS has assigned an annual frequency for this control]

(a) Automated systems are vulnerable to fraudulent or malicious activity by individuals who have the authority or capability to access information not required to perform their job-related duties. To ensure the Department of Homeland Security reduces the risk to DHS enterprise from individuals engaging in fraudulent or malicious behavior, DHS has developed and documented a formal Access Control Policy. The policy addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance. DHS has implemented the Access Control Policy through the publication of the 4300A Sensitive Systems Policy Directive. Details on the Access Control policy can be found in section 5.2 Access Control of the 4300A Sensitive Systems Policy Directive. The 4300A Sensitive Systems Policy Directive is disseminated via the DHS extranet and is available on DHS Connect portal at the CISO website. The 4300A Sensitive Systems Policy is reviewed or updated on an annual basis by the DHS Security Policy and Support division.

(b) It is the responsibility of the Consumer to develop and document system procedures based on the CISO policies and guidelines including local implementation of AC-1 as necessary. Consumer is responsible for defining the frequency of access control procedure reviews/updates; reviews/updates access control procedures in accordance with organization-defined frequency.

Responsible Entities: (a) DHS CISO

(b) Consumer

Control: Sharing of Personal Passwords DHS users shall not share personal passwords.

Related control: IA-5.

References: None.

Implementation: Not Provided Responsible Entities:

Control: Account Management

(a) Identifies and selects the following types of information system accounts to support organizational missions/business functions: [Assignment: organization-defined information system account types];

(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 (i.e., privileges) and other attributes (as required) for each account;

(e) Requires approvals by [Assignment: organization-defined personnel or roles] for requests to create information system accounts;

(f) Creates, enables, modifies, disables, and removes information system accounts in accordance with [Assignment: organization-defined procedures or 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; and

(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; and

(3) Other attributes as required by the organization or associated missions/business functions;

(j) Reviews accounts for compliance with account management requirements Annually; and

(k) Establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group.

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.

Related controls: AC-3, AC-4, AC-5, AC-6, AC-10, AC-17, AC-19, AC-20, AU-9, IA-2, IA-4, IA-5, IA-8, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PL-4, SC-13.

Implementation: Not Provided

Control: Automated System Account Management The organization employs automated mechanisms to support the management of information system accounts.

Supplemental Guidance

The use of automated mechanisms can include, for example: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using telephonic notification to report atypical system account usage.

Related control: None.

Implementation: Not Provided

Control: Removal Of Temporary / Emergency Accounts The information system automatically [Selection: removes; disables] temporary and emergency accounts after The time period specified by the Component CISO/ISSM.

Supplemental Guidance

This control enhancement requires the removal of both temporary and emergency accounts automatically after a predefined period of time has elapsed, rather than at the convenience of the systems administrator.

Implementation: Not Provided

Control: Disable Inactive Accounts The information system automatically disables inactive accounts after [Assignment: organization-defined time period].

Supplemental Guidance

None.

Implementation: Not Provided

Control: Automated Audit Actions The information system automatically audits account creation, modification, enabling, disabling, and removal actions and notifies, as required, [Assignment: organization-defined personnel or roles].

Supplemental Guidance

None.

Related controls: AU-2, AU-12.

Implementation: Not Provided

Control: Inactivity Logout The organization requires that users log out when Logoff after 15 minutes of user inactivity (optional).

Supplemental Guidance

None.

Related control: SC-23.

Implementation: Not Provided

Control: Usage Conditions The information system enforces [Assignment: organization-defined circumstances and/or usage conditions] for [Assignment: organization-defined information system accounts].

Supplemental Guidance

Organizations can describe the specific conditions or circumstances under which information system accounts can be used, for example, by restricting usage to certain days of the week, time of day, or specific durations of time.

Implementation: Not Provided

Control: Access Enforcement The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies.

Supplemental Guidance

Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access 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.

Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PE-3.

Implementation: Not Provided

Control: Use of group passwords Use of group passwords is limited to situations dictated by operational necessity or critical for mission accomplishment. Use of a group User ID and password shall be approved by the appropriate Authorizing Official (AO).

Related control: IA-4.

Implementation: Not Provided

Control: Information Flow Enforcement The information system enforces approved authorizations for controlling the flow of information within the system and between interconnected systems based on [Assignment: organization-defined information flow control policies].

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.

Related controls: AC-17, AC-19, AC-21, CM-6, CM-7, SA-8, SC-2, SC-5, SC-7, SC-18.

References: Web: ucdmo.gov.

Implementation: Not Provided

Control: Separation of Duties

(a) Separates Components shall divide and separate duties and responsibilities of critical information system functions among different individuals to minimize the possibility of any one individual having the necessary authority or system access to be able to engage in fraudulent or criminal activity.;

(b) Documents separation of duties of individuals; and

(c) Defines information system access authorizations to support separation of duties.

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.

Related controls: AC-3, AC-6, PE-3, PE-4, PS-2.

Implementation: Not Provided

Control: Least Privilege The organization employs the concept of least privilege, allowing only authorized accesses for users (and processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions.

Supplemental Guidance

Organizations employ least privilege for specific duties and information systems. The concept 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.

Related controls: AC-2, AC-3, AC-5, CM-6, CM-7, PL-2.

Implementation: Not Provided

Control: Authorize Access To Security Functions The organization explicitly authorizes access to [Assignment: organization-defined security functions (deployed in hardware, software, and firmware) and security-relevant information].

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.

Related controls: AC-17, AC-18, AC-19.

Implementation: Not Provided

Control: Non-Privileged Access For Nonsecurity Functions 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 non-security functions.

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.

Related control: PL-4.

Implementation: Not Provided

Control: Network Access To Privileged Commands The organization authorizes network access to [Assignment: organization-defined privileged commands] only for [Assignment: organization-defined compelling operational needs] and documents the rationale for such access in the security plan for the information system.

Supplemental Guidance

Network access is any access across a network connection in lieu of local access (i.e., user being physically present at the device).

Related control: AC-17.

Implementation: Not Provided

Control: Privileged Accounts The organization restricts privileged accounts on the information system to Individuals requiring administrator privileges.

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.

Related control: CM-6.

Implementation: Not Provided

Control: Auditing Use Of Privileged Functions The information system audits the execution of privileged functions.

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).

Related control: AU-2.

Implementation: Not Provided

Control: Prohibit Non-Privileged Users From Executing Privileged Functions The information system prevents non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures.

Supplemental Guidance

Privileged functions include, for example, establishing information system accounts, performing system integrity checks, or administering cryptographic key management activities. Circumventing intrusion detection and prevention mechanisms or malicious code protection mechanisms are examples of privileged functions that require protection from non-privileged users.

Implementation: Not Provided

Control: Unsuccessful Logon Attempts The information system:

(a) Enforces a limit of 3 consecutive invalid logon attempts by a user during a 20; and

(b) Automatically [Selection: locks the account/node for an [Assignment: organization-defined time period]; locks the account/node until released by an administrator; delays next logon prompt according to [Assignment: organization-defined delay algorithm]] when the maximum number of unsuccessful attempts is exceeded.

Supplemental Guidance

This control applies regardless of whether the logon occurs via a local or network connection. Due to the potential for denial of service, automatic lockouts initiated by information systems are usually temporary and automatically release after a predetermined time period established by organizations. If a delay algorithm is selected, organizations may choose to employ different algorithms for different information system components based on the capabilities of those components. Responses to unsuccessful logon attempts may be implemented at both the operating system and the application levels.

Related controls: AC-2, AC-9, AC-14, IA-5.

Implementation: Not Provided

Control: System Use Notification

(a) Displays to users [Assignment: organization-defined system use notification message or banner] before granting access to the system that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance and states that:

(1) Users are accessing a U.S. Government information system;

(2) Information system usage may be monitored, recorded, and subject to audit;

(3) Unauthorized use of the information system is prohibited and subject to criminal and civil penalties; and

(4) Use of the information system indicates consent to monitoring and recording;

(b) Retains the notification message or banner on the screen until users acknowledge the usage conditions and take explicit actions to log on to or further access the information system; and

(c) For publicly accessible systems:

(1) Displays system use information [Assignment: organization-defined conditions], before granting further access;

(2) Displays references, if any, to monitoring, recording, or auditing that are consistent with privacy accommodations for such systems that generally prohibit those activities; and

(3) Includes a description of the authorized uses of the system.

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.

Implementation: Not Provided

Control: Governement Funded Office Equipment The use of Government office equipment and DHS systems/computers constitutes consent to monitoring and auditing of the equipment/systems at all times. Monitoring includes the tracking of internal transactions and external transactions such as Internet access. It also includes auditing of stored data on local and network storage devices as well as removable media.

Related control: AC-8.

Implementation: Not Provided

Control: Concurrent Session Control The information system limits the number of concurrent sessions for each One (1) concurrent login per account unless strong authentication is used. to each account type.

Supplemental Guidance

Organizations may define the maximum number of concurrent sessions for information system accounts globally, by account type (e.g., privileged user, non-privileged user, domain, specific application), by account, or a combination. For example, organizations may limit the number of concurrent sessions for system administrators or individuals working in particularly sensitive domains or mission-critical applications. This control addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts.

Implementation: Not Provided

Control: Session Lock

(a) Prevents further access to the system by initiating a session lock after 20 minutes of inactivity or upon receiving a request from a user; and

(b) Retains the session lock until the user reestablishes access using established identification and authentication 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.

Related control: AC-7.

References: OMB Memorandum 06-16.

Implementation: Not Provided

Control: Pattern-Hiding Displays The information system conceals information previously visible on the display with a publicly viewable image.

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.

References: OMB Memorandum 06-16.

Implementation: Not Provided

Control: Session Termination The information system automatically terminates a user session after 60 minutes of 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.

Related controls: SC-10, SC-23.

Implementation: Not Provided

Control: Permitted Actions without Identification or Authentication

(a) Identifies [Assignment: organization-defined user actions] that can be performed on the information system without identification or authentication consistent with organizational missions/business functions; and

(b) Documents and provides supporting rationale in the security plan for the information system, user actions not requiring identification or authentication.

Supplemental Guidance

This control addresses situations in which organizations determine that no identification or authentication is required in organizational information systems. Organizations may allow a limited number of user actions without identification or authentication including, for example, when individuals access public websites or other publicly accessible federal information systems, when individuals use mobile phones to receive calls, or when facsimiles are received. Organizations also identify actions that normally require identification or authentication but may under certain circumstances (e.g., emergencies), allow identification or authentication mechanisms to be bypassed. Such bypasses may occur, for example, via a software-readable physical switch that commands bypass of the logon functionality and is protected from accidental or unmonitored use. This control does not apply to situations where identification and authentication have already occurred and are not repeated, but rather to situations where identification and authentication have not yet occurred. Organizations may decide that there are no user actions that can be performed on organizational information systems without identification and authentication and thus, the values for assignment statements can be none.

Related controls: CP-2, IA-2.

Implementation: Not Provided

Control: Remote Access

(a) Establishes usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed; and

(b) Authorizes remote access to the information system prior to allowing such connections.

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 virtual private networks (VPN) to enhance confidentiality and integrity over remote connections. The use of VPNs, does not technically make the access non-remote; however, the use of VPNs, when adequately provisioned with appropriate security controls 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 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.