Task 2 RMF_Identification and Authentication Plan.docx

{COMMAND}

{SYSTEM NAME} {ACRONYM}

System Version: {VERSION} eMASS# {EMASS#}

Confidentiality: {CONFIDENTIALITY} Integrity: {INTEGRITY} Availability: {AVAILABILITY}

Department of the {SERVICE}

{LOGO}

Identification and Authentication Plan Document Version: 1.0.0

{DATE}

Prepared by: {ORGANIZATION}

DISTRIBUTION IS LIMITED TO U.S. GOVERNMENT AGENCIES AND THEIR CONTRACTORS.

OTHER REQUESTS FOR THIS DOCUMENT MUST BE REFERRED TO: {ORGANIZATION}

Change Record

Amplifying Guidance

i. Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 6510.01F, "Information Assurance (IA) and Support to Computer Network Defense (CND)"

ii. DoDI 8520.02, "Public Key Infrastructure (PKI) and Public Key (PK) Enabling"

iii. DoDI 8520.03, "Identity Authentication for Information Systems"

Table of Contents

Table 1 - SP-800-53v4 Compliance Matrix 1

FOR OFFICIAL USE ONLY

{ACRONYM}

IDENTIFICATION AND AUTHENTICATION PLAN {DATE}

Template developed by:

http://www.i-assure.com FOR OFFICIAL USE ONLY

1.0 OVERVIEW

Identification and Authentication of user identities is accomplished through the use of passwords, tokens, biometrics or, in the case of multifactor authentication, some combination thereof.

This document complies with the following requirements from NIST Special Publication 800-53 Revision 4, "Security and Privacy Controls for Federal Information Systems and Organizations". A detailed compliance matrix can be found in Appendix I, “Detailed Compliance Matrix”.

Table 1 - SP-800-53v4 Compliance Matrix

2.0 IDENTIFICATION AND AUTHENTICATION POLICY AND PROCEDURES

Identification and authentication policies and procedures are covered by DoD level policy. DoD annually reviews policies and procedures and provides updates as appropriate.

3.0 IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS)

Organizational users include employees or individuals that organizations deem to have equivalent status of employees (e.g., contractors, guest researchers). This control applies to all accesses other than: (i) accesses that are explicitly identified and documented in AC-14; and (ii) accesses that occur through authorized use of group authenticators without individual authentication. All organizational users must be uniquely identified.

Does {ACRONYM} uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users)?

☐ No

☐ Yes

If no, delete the following information.

{ACRONYM} is configured to uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users) through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

3.1 Multfactor Authentication

Multifactor authentication is a security system that requires more than one method of authentication from independent categories of credentials to verify the user’s identity for a login or other transaction. In most cases, the DoD utilizes PIV/CAC authentication, which is dependent on the DoD Public Key Infrastructure to meet this requirement.

Is {ACRONYM} GiG connected?

☐ No: PKI is not required.

☐ Yes

If no, delete the content of Sections 3.1.1 – 3.1.5 and replace with, “N/A, {ACRONYM} is not GiG connected, therefore DoD PKI cannot be implemented to satisfy multifactor authentication requirements”.

3.1.1 Network Access

Network access is access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses). In most cases, the authentication occurs between the end client and a Directory Server, such as Microsoft Active Directory.

Privileged Accounts Does {ACRONYM} utilize privileged accounts for network access?

☐ No

☐ Yes

If yes, is multifactor authentication for network access to privileged accounts required?

☐ No

☐ Yes

If yes, are replay-resistant authentication mechanisms for network access to privileged accounts configured?

☐ No

☐ Yes: Describe implementation, i.e. Kerberos.

Non-privileged Accounts Does {ACRONYM} utilize non-privileged accounts for network access?

☐ No

☐ Yes

If yes, is multifactor authentication for network access to non-privileged accounts required?

☐ No

☐ Yes

If yes, are replay-resistant authentication mechanisms for network access to non-privileged accounts configured?

☐ No

☐ Yes: Describe implementation, i.e. Kerberos.

3.1.2 Remote Access

Remote access is a type of network access that involves communication through external networks (e.g., the Internet). Internal networks include local area networks and wide area networks. In addition, the use of encrypted virtual private networks (VPNs) for network connections between organization-controlled endpoints and non-organization controlled endpoints may be treated as internal networks from the perspective of protecting the confidentiality and integrity of information traversing the network.

Privileged Accounts Does {ACRONYM} utilize privileged accounts for remote access?

☐ No

☐ Yes

If yes, does the device implemented meet Federal standards for authentication such as FIPS 140-2, NIAP Certification, or NSA approval?

☐ No

☐ Yes: Describe implementation, i.e. CAC, RSA Token.

If yes, is one of the factors is provided by the device separate from the system gaining access?

☐ No

☐ Yes: Describe implementation, i.e. CAC, RSA Token.

Does {ACRONYM} utilize non-privileged accounts for remote access?

☐ No

☐ Yes

If yes, does the device implemented meet Federal standards for authentication such as FIPS 140-2, NIAP Certification, or NSA approval?

☐ No

☐ Yes: Describe implementation, i.e. CAC, RSA Token.

If yes, is one of the factors is provided by the device separate from the system gaining access?

☐ No

☐ Yes: Describe implementation, i.e. CAC, RSA Token.

3.1.2 System Access

System access is a type of access that involves a remote device authenticating to this device, e.g. hosted web server or active directory server.

Does {ACRONYM} accept authentication from other devices?

☐ No

☐ Yes

If yes, does the device accept PIV/CAC authentication?

☐ No

☐ Yes:

If yes, does the device verify PIV/CAC authentication?

☐ No

☐ Yes:

3.1.3 Local Access

Local access is any access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained by direct connections without the use of networks. While this is a requirement of SP 800-53, it is in practice impossible to meet as multifactor authentication relies on a supporting infrastructure, which would then make this type of authentication “network based”.

Privileged Accounts Does {ACRONYM} utilize privileged accounts for local access?

☐ No

☐ Yes

If yes, is multifactor authentication for local access to privileged accounts configured?

☐ No

☐ Yes: Describe implementation.

Does {ACRONYM} utilize non-privileged accounts for local access?

☐ No

☐ Yes

If yes, is multifactor authentication for local access to non-privileged accounts configured?

☐ No

☐ Yes: Describe implementation.

3.1.4 Group Authentication

Group authentication is when multiple users utilize the same identifier for access to a system.

Does {ACRONYM} utilize group authentication?

☐ No

☐ Yes

If yes, does {ACRONYM} require individuals to be authenticated with an individual authenticator when a group authenticator is employed?

☐ No

☐ Yes

{ACRONYM} is configured to require individuals to be authenticated with an individual authenticator when a group authenticator is employed through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

4.0 DEVICE IDENTIFICATION AND AUTHENTICATION

Organizational devices requiring unique device-to-device identification and authentication may be defined by type, by device, or by a combination of type/device. Information systems typically use either shared known information (e.g., Media Access Control [MAC] or Transmission Control Protocol/Internet Protocol [TCP/IP] addresses) for device identification or organizational authentication solutions (e.g., IEEE 802.1x and Extensible Authentication Protocol [EAP], Radius server with EAP-Transport Layer Security [TLS] authentication, Kerberos) to identify/authenticate devices on local and/or wide area networks.

Is {ACRONYM} GiG connected?

☐ No: Device identification and authentication is not required.

☐ Yes

If yes, does {ACRONYM} manage network devices?

☐ No: Network device identification and authentication is inherited.

☐ Yes

If yes, are devices uniquely identified?

☐ No

☐ Yes: Enter identification method

If yes, are devices uniquely authenticated?

☐ No

☐ Yes: Enter authentication method

If yes, is cryptographically based bidirectional authentication implemented?

☐ No

☐ Yes: Enter authentication method

5.0 IDENTIFIER MANAGEMENT

Common device identifiers include, for example, media access control (MAC), Internet protocol (IP) addresses, or device-unique token identifiers. Typically, individual identifiers are the user names of the information system accounts assigned to those individuals. In such instances, the account management activities of AC-2 use account names provided by IA-4. This section addresses individual identifiers not necessarily associated with information system accounts (e.g., identifiers used in physical security control databases accessed by badge reader systems for access to information systems).

5.1 Identifier Uniqueness

All {ACRONYM} identifiers are required to be unique (group accounts are discussed in a later section). Identifiers must also distinguish between contractor, government and nationality. This is configured through the format of identifiers are described below:

· Contractor – must contain “.ctr” within the identifier

· Foreign Nationals – must contain country prefix, i.e. “uk” within the identifier

· Government – no extension. All accounts without an extension are considered Government employees Note: Contractors who are also foreign nationals are identified as both, e.g., john.smith.ctr.uk@army.mil Do {ACRONYM} identifiers differentiate between contractor, government and nationality?

☐ No

☐ Yes

Does {ACRONYM} contain an email server?

☐ No

☐ Yes

If yes, do all email addresses differentiate between contractor, government and nationality?

☐ No

☐ Yes

If yes, are automatic signature blocks configured to differentiate between contractor, government and nationality?

☐ No

☐ Yes

5.2 Identifier Management

Prior to an identifier being distributed to the end user, it must be authorized by at least the ISSO or IIS. {ACRONYM} follows the System Access Authorization Request (SAAR) form to create identifiers.

Are SAAR forms on file for all {ACRONYM} identifiers?

☐ No

☐ Yes

When identifiers are created for non-user accounts, e.g. a group, role, or device, the identifier will note the differentiation. Identifiers assigned to Users are not permitted to be reused for one year after last use.

5.3 Identifier Configuration

{ACRONYM} is configured to disable identifiers after 35 days of inactivity through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

6.0 AUTHENTICATOR MANAGEMENT

Authenticator management includes issuing and revoking, when no longer needed, authenticators for temporary access such as that required for remote maintenance.

6.1 Password Complexity

Password complexity settings help ensure passwords cannot be easily guessed or cracked using brute force methods.

{ACRONYM} utilizes the following tools to check password strength: Enter tool name, i.e. SCAP.

6.1.1 Upper Case Characters

Is {ACRONYM} configured to enforce password complexity by the minimum number of upper case characters used?

☐ No

☐ Yes

If no, delete following section.

{ACRONYM} is configured to enforce password complexity by the minimum number of upper case characters used through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

6.1.2 Lower Case Characters

Is {ACRONYM} configured to enforce password complexity by the minimum number of lower case characters used?

☐ No

☐ Yes

{ACRONYM} is configured to enforce password complexity by the minimum number of lower case characters used through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

6.1.3 Numeric Characters

Is {ACRONYM} configured to enforce password complexity by the minimum number of numeric characters used?

☐ No

☐ Yes

{ACRONYM} is configured to enforce password complexity by the minimum number of numeric characters used through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

6.1.4 Password Length

Is {ACRONYM} configured to enforce password complexity by enforcing minimum password length?

☐ No

☐ Yes

{ACRONYM} is configured to enforce minimum password length through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

6.1.5 Special Characters

Is {ACRONYM} configured to enforce password complexity by enforcing minimum number of special characters used?

☐ No

☐ Yes

{ACRONYM} is configured to enforce minimum number of special characters used through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS

6.1.6 Change Percentage

Is {ACRONYM} configured to enforce password complexity by enforcing that at least 50% of the minimum password length is changed?

☐ No

☐ Yes

{ACRONYM} is configured to enforce that at least 50% of the minimum password length is changed through implementation of the following STIG/SRG requirements:

DELETE N/A STIGS