Attachment C- System Security Plan TEMPLATE.pdf

FOR OFFICIAL USE ONLY

Blank

([project acronym not provided])

[project ID not provided]

System Security Plan

(SSP)

Prepared for

14 January 2016

(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

Version Date Author Description

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 Blank([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-1 System Name

FISMA ID:

System Name: Blank

System Abbreviation: [project acronym not provided]

Version: [project version not provided]

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-2 Security Categorization

Confidentiality Impact Level: Moderate

Integrity Impact Level: Moderate

Availability Impact Level: Moderate

Table 1-3 System Designations

Chief Financial Officer (CFO) Designated Financial System No

System Contains Privacy Data or PII

Classification or Sensitivity Level UNCLASSIFIED//FOUO

Mission Essential System No

Table 1-4 Information Types

Information Type Highest Data

Classification

Confidentiality impact

Integrity impact

Availability impact

Justification

1.4 Responsible Organization/Personnel and Contact Information

The following DHS Component/Personnel are identified as the parties responsible for the system development of

Blank, 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

Responsible

Organization

Organization POC

Name (Include sub-component/department name)

Name Address Phone Email

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

{This section should include a description, in text, detailing the external boundary of the information system. The description should address applicable environments other than the primary production environment (i.e., maintenance, testing/development or backup environments). Where required the description should detail lines of responsibility demarcation that exist for any controls inherited from other information systems.}

1.6.2 System Users

System Users Categories

Category

Name

Minimum

Clearance/Investigation

Foreign

Nationals Category Description

Security

Administrator Confidential

Not

Allowed

Security Administrators are similar to master administrators, but they have read-only access to everything except the application’s Audit page

(Administration > Audit). Only security administrators and master administrators can view, export and clear the Audit.

Audit/Executive Confidential Not

Allowed

Auditor/Executive accounts are similar to administrators, but have read-only access.

Executive accounts are intended for managers who need to monitor progress, compliance, and risk levels.

User Confidential Not

Allowed

User accounts are typically given to analysts who will require basic access to the system. Users typically must be assigned to a project in order to access it. Users do not have administrative rights over their projects.

Master

Administrator Confidential

Not

Allowed

A master administrator has full access to the entire application and is able to create additional master administrators as well as all other account types.

Only master administrators have access to all of the application’s administrative tools.

Administrator Confidential Not

Allowed

Administrators have permission to view and edit any information to which they have access.

Administrator accounts should be given to those who have a need to access, edit, or configure your organization’s projects, continuous assessment settings, and reports.

There are no project personnel roles assigned to your system.

1.6.3 Architecture

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

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 Blank

Application

Name Function

Type of

Information

FISMA ID

Confidentiality

Impact Level

Integrity Impact

Level

Availability

Impact Level

1.6.5 Subsystems/Minor Applications

The following table(s) identify the subsystems/Minor Applications for Blank.

Table 1-7. Blank Subsystems/Minor Applications

Application Name Function Type of Information FISMA ID Location

1.6.6 Hardware/Virtual Machines/Software/Firmware Description

There is no hardware associated with the project.

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

Certificate Name Certificate Type Certificate Issuer Expiration Date Cryptography

Algorithm Supported

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

Hostname MFR Model Version Location

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

Is the secure facility authorized or approved to process and store information at the level covered by this SSP?

[ ]Yes [ ] No

Who authorized or approved the facility?

Provide date and location of approval letter.

State the classification and level approved for the facility.

[ ] Secret [ ] Top Secret [ ] Others (Please

Specify)

Is the system approved for unattended processing? [ ]Yes [ ] No

Is the facility approved for 24-hour operation? [ ]Yes [ ] No

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

Hostname MFR Model Version Ticket No. Location

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 Blank 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

[ ] Software as a Service (SaaS) Major Application

[ ] Platform as a Service (PaaS) Major Application

[ ] Infrastructure as a Service (IaaS) General Support System

[ ] Other Explain:

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

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)

2.1 Access Control Policy and Procedures AC-1

Control: Access Control Policy and Procedures

The organization:

(a) Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:

(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 [Assignment: organization-defined frequency]; and,

(2) Access control procedures [Assignment: organization-defined frequency].

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.

Status:

Implementation: Not Provided

Responsible Entitles:

2.2 Access Control Policy and Procedures AC-1 (DHS-5.1.1.c)

Control: Sharing of Personal Passwords

DHS users shall not share personal passwords.

Related control: IA-5.

References: None.

2.3 Account Management AC-2

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 [Assignment: organization-defined frequency]; and

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

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.

2.4 Account Management AC-2 (1)

Control: Automated System Account Management

The organization employs automated mechanisms to support the management of information system accounts.

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

Related control: None.

2.5 Account Management AC-2 (2)

Control: Removal Of Temporary / Emergency Accounts

The information system automatically [Selection: removes; disables] temporary and emergency accounts after

[Assignment: organization-defined time period for each type of account].

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

2.6 Account Management AC-2 (3)

Control: Disable Inactive Accounts

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

None.

2.7 Account Management AC-2 (4)

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

Related controls: AU-2, AU-12.

2.8 Access Enforcement AC-3

Control: Access Enforcement

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

Access control policies (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.

2.9 Access Enforcement AC-3 (DHS-5.1.1.d)

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.

2.10 Information Flow Enforcement AC-4

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

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.

2.11 Separation of Duties AC-5

Control: Separation of Duties

(a) Separates [Assignment: organization-defined duties of individuals];

(b) Documents separation of duties of individuals; and

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

Separation of duties addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion. Separation of duties includes, 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.

2.12 Least Privilege AC-6

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.

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.

2.13 Least Privilege AC-6 (1)

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

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.

2.14 Least Privilege AC-6 (2)

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.

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.

2.15 Least Privilege AC-6 (5)

Control: Privileged Accounts

The organization restricts privileged accounts on the information system to [Assignment: organization-defined personnel or roles].

Privileged accounts, including super user accounts, are typically described as system administrator for various types of commercial off-the-shelf operating systems. Restricting privileged accounts to specific personnel or roles prevents day-to-day users from having access to privileged information/functions. Organizations may differentiate in the application of this control enhancement between allowed privileges for local accounts and for domain accounts provided organizations retain the ability to control information system configurations for key security parameters and as otherwise necessary to sufficiently mitigate risk.

Related control: CM-6.

2.16 Least Privilege AC-6 (9)

Control: Auditing Use Of Privileged Functions

The information system audits the execution of privileged functions.

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.

2.17 Least Privilege AC-6 (10)

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.

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.

2.18 Unsuccessful Logon Attempts AC-7

Control: Unsuccessful Logon Attempts

The information system:

(a) Enforces a limit of [Assignment: organization-defined number] consecutive invalid logon attempts by a user during a [Assignment: organization-defined time period]; and

(b) Automatically [Selection: 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.

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.

2.19 System Use Notification AC-8

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.

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.

2.20 System Use Notification AC-8 (DHS-4.8.5.d)

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.

2.21 Session Lock AC-11

Control: Session Lock

(a) Prevents further access to the system by initiating a session lock after [Assignment: organization-defined time period] 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.

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.

2.22 Session Lock AC-11 (1)

Control: Pattern-Hiding Displays

The information system conceals information previously visible on the display with a publicly viewable image.

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.

2.23 Session Termination AC-12

Control: Session Termination

The information system automatically terminates a user session after [Assignment: organization-defined conditions or trigger events requiring session disconnect].

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.

2.24 Permitted Actions without Identification or Authentication AC-14

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.

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.

2.25 Remote Access AC-17

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.

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. Enforcing access restrictions for remote connections is addressed in AC-3.

Related controls: AC-2, AC-3, AC-18, AC-19, AC-20, CA-3, CA-7, CM-8, IA-2, IA-3, IA-8, MA-4, PE-17, PL-4, SC-10, SI-4.

References: NIST Special Publications 800-46, 800-77, 800-113, 800-114, 800-121.

2.26 Remote Access AC-17 (1)

Control: Automated Monitoring / Control

The information system monitors and controls remote access methods.

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

Related controls: AU-2, AU-12.

2.27 Remote Access AC-17 (2)

Control: Protection Of Confidentiality / Integrity Using Encryption

The information system implements cryptographic mechanisms to protect the confidentiality and integrity of remote access sessions.

The encryption strength of mechanism is selected based on the security categorization of the information.

Related controls: SC-8, SC-12, SC-13.

2.28 Remote Access AC-17 (3)

Control: Managed Access Control Points

The information system routes all remote accesses through [Assignment: organization-defined number] managed network access control points.

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.

Related control: SC-7.

2.29 Remote Access AC-17 (4)

Control: Privileged Commands / Access

(a) Authorizes the execution of privileged commands and access to security-relevant information via remote access only for [Assignment: organization-defined needs]; and

(b) Documents the rationale for such access in the security plan for the information system.

Supplemental Guidance: Related control: AC-6.

2.30 Remote Access AC-17 (DHS-5.4.1.b)

Control: Remote Access Connection Management

Components shall centrally manage all remote access and dial-in connections to their systems and shall ensure that remote access and approved dial-in capabilities provide strong two-factor authentication, audit capabilities, and protection for sensitive information throughout transmission. DHS has an immediate goal that remote access shall only be allowed with two-factor authentication where one of the factors is provided by a device separate from the computer gaining access. Any two-factor authentication shall be based on Department-controlled certificates or hardware tokens issued directly to each authorized user. Remote access solutions shall comply with the encryption requirements of FIPS 140-2, Security Requirements for Cryptographic Modules.

See Section 3.14 of this Policy Directive, “Privacy and Data Security” for additional requirements involving remote access of PII.

Related Controls: AC-4, AC-17, AU-2 SC-7, SC-8, and SC-9.

2.31 Remote Access AC-17 (DHS-5.4.1.c)

Control: Remote Access of PII

Remote access of PII shall comply with all DHS requirements for sensitive systems, including strong authentication. Strong authentication shall be accomplished by means of virtual private network (VPN) or equivalent encryption and two-factor authentication. The Risk Assessment and Security Plan (SP) shall document any remote access of PII, and the remote access shall be approved by the AO prior to implementation.

Related controls: AC-4, AC-17, AU-2 SC-7, SC-8, and SC-9.

2.32 Wireless Access AC-18

Control: Wireless Access

(a) Establishes usage restrictions, configuration/connection requirements, and implementation guidance for wireless access; and

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

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.

Related controls: AC-2, AC-3, AC-17, AC-19, CA-3, CA-7, CM-8, IA-2, IA-3, IA-8, PL-4, SI-4.

References: NIST Special Publications 800-48, 800-94, 800-97.

2.33 Wireless Access AC-18 (1)

Control: Authentication And Encryption

The information system protects wireless access to the system using authentication of [Selection (one or more):

users; devices] and encryption.

Related controls: SC-8, SC-13.

References: NIST Special Publications 800-48, 800-94, 800-97.

2.34 Access Control for Mobile Devices AC-19

Control: Access Control for Mobile Devices

(a) Establishes usage restrictions, configuration/connection requirements, and implementation guidance for organization-controlled mobile devices; and

(b) Authorizes connection of mobile devices to organizational information systems.

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…