Sorry, you need to enable JavaScript to visit this website.

octo

Office of the Chief Technology Officer
 

DC Agency Top Menu

-A +A
Bookmark and Share

Identification and Authentication Policy


Approved Date – 02/22/2021
Published Date – 02/22/2021
Revised Date – 05/25/2021

1.  Purpose

To establish the requirements for the identification and authentication of users, processes, or devices accessing the District of Columbia Government’s (“District”) information system, and make sure that the security and integrity of the District data and information system are protected.

2.  Authority

DC Official Code § 1-1401 et seq., provides the Office of the Chief Technology Officer (“OCTO”) with the authority to provide information technology (IT) services, write and enforce IT policies, and secure the network and IT systems for the District. This document can be found at: https://code.dccouncil.us/dc/council/code/sections/1-1402.html.

3.  Applicability

This policy applies to all District workforce members responsible for application identity and role definition on behalf of the District, and/or any District agency/District/entity who receive enterprise services from OCTO. In addition, this policy applies to any providers and third-party entities with access to District information, networks, and applications.

4.  Policy

The District information systems must be configured to uniquely identify and authenticate all District Workforce members with access to such systems. The District agencies shall develop respective Identification and Authentication procedures in support of this policy based on the requirements defined below:

4.1.    Identification and Authentication (Organizational Users)
The District agencies must ensure that organizational users or processes acting on behalf of organizational users are uniquely identified and authenticated before they are granted access (Local, Network or Remote) to the District information systems organizational users (or processes acting on behalf of organizational users).
 
4.2.    Identification and Authentication |Multifactor Authentication To Privileged Accounts
All District agencies' information systems must implement multifactor authentication for network access to privileged accounts.
 
4.3.    Identification And Authentication |Multifactor Authentication To Non-Privileged Accounts  
The District agencies will enforce the information system implements multi-factor authentication for network access to non-privileged accounts.
 
4.4.    Identifier Management
The Districts agencies must manage information system identifiers by:

  • Receiving authorization from District workforce member’s supervisor and agency management to assign an individual, group, role, or device identifier.
  • Selecting an identifier that identifies an individual, group, role, or device.
  • Assigning the identifier to the intended individual, group, role, or device.
  • Preventing reuse of identifiers for 7 years.
  • Disabling the identifier after 6 months of inactivity.

4.5.    Authentication Management
The District agencies must have Information system authentication requirements that are developed and properly managed. Individual authenticators including passwords, tokens, biometrics, PKI certificates, and key cards must be properly secured with the establishment of a secured log-on process to minimize the risk of unauthorized access.
 
The District agencies must manage information system authenticators by:

  • Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, or device receiving the authenticator.
  • Establishing initial authenticator content for authenticators defined by the organization.
  • Ensuring that authenticators have sufficient strength of mechanism for their intended use.
  • Establishing and implementing administrative procedures for initial authenticator distribution, for lost/compromised or damaged authenticators, and for revoking authenticators.
  • Changing default content of authenticators before information system installation.
  • Establishing minimum and maximum lifetime restrictions and reuse conditions for authenticators.
  • Changing/refreshing authenticators for group or role when membership to those accounts’ changes (e.g. employee termination, transfer, etc.).
  • Protecting authenticator content from unauthorized disclosure and modification.
  • Requiring individuals to take, and having devices implement, specific security safeguards to protect authenticators.
  • Changing authenticators for group/role accounts when membership to those accounts changes.

4.6.    Authenticator Management | Password-Based Authentication
The District agencies must enforce minimum password complexity as defined in the District password policy.
 
4.7.    Authenticator Feedback  
The information system obscures feedback of authentication information during the authentication process to protect it from possible exploitation/use by unauthorized individuals.
 
4.8.    Cryptographic Module Authentication  
The District agencies must implement mechanisms for authentication to a cryptographic module (i.e. hardware or software device or component that performs cryptographic operations securely within a physical or logical boundary) that meets the requirements of applicable federal laws, executive orders, directives, policies, regulations, standards, and guidance for such authentication.
 
4.9.    Identification And Authentication (Non – Organizational Users)  
The District agencies must manage the information system that uniquely identifies and authenticates non-organizational users (or processes acting on behalf of non-organizational users).
 
4.10.    Identification And Authentication | Acceptance Of External Credentials
The District agencies must manage the information system to accept only external credentials that are certified to be compliant with the requirements of the NIST SP 800-63-3 (Digital Identity Guidelines).
 
4.11.    Re-authentication
The District agencies must require users to re-authenticate to logically access the District systems in any of the following circumstances or as determined by the agency:

  • System lock
  • Role change
  • After system upgrade/update
  • To execute privileged functions
  • To access sensitive data

5.  Exemption

Exceptions to this policy shall be requested in writing to the Agency’s CIO and the request will be escalated to the OCTO Chief Information Security Officer (“CISO”) for approval.

6.  Definitions

The definition of the terms used in this document can be found in the Policy Definitions website.

More Resources