IAIA-1

IAIA-1 Individual Identification and Authentication

Overview

DoD information system access is gained through the presentation of an individual identifier (e.g., a unique token or user login ID) and password. For systems utilizing a logon ID as the individual identifier, passwords are, at a minimum, a case sensitive 8-character mix of upper case letters, lower case letters, numbers, and special characters, including at least one of each (e.g., emPagd2!). At least four characters must be changed when a new password is created. Deployed/tactical systems with limited data input capabilities implement the password to the extent possible. Registration to receive a user ID and password includes authorization by a supervisor, and is done in person before a designated registration authority. Additionally, to the extent system capabilities permit, system mechanisms are implemented to enforce automatic expiration of passwords and to prevent password reuse. All factory set, default or standard-user IDs and passwords are removed or changed. Authenticators are protected commensurate with the classification or sensitivity of the information accessed; they are not shared; and they are not embedded in access scripts or stored on function keys. Passwords are encrypted both for storage and for transmission.

MAC / CONF	Impact	Subject Area
SENSITIVE	High	Identification and Authentication

Details

Threat
Access to DoD information sytems must be protected commensurate with the sensitivity of the information the systems process. For this reason it is mandatory that each individual who is authorized access to DoD information systems be provided with a unique individual identifier in the form of either a DoD PKI certificate, CAC card, or username and password. Failure to require an individual I&A mechanism leaves DoD information resources vulnerable to theft, exploitation, unauthorized modification, or destruction.

Threat

Access to DoD information sytems must be protected commensurate with the sensitivity of the information the systems process. For this reason it is mandatory that each individual who is authorized access to DoD information systems be provided with a unique individual identifier in the form of either a DoD PKI certificate, CAC card, or username and password. Failure to require an individual I&A mechanism leaves DoD information resources vulnerable to theft, exploitation, unauthorized modification, or destruction.

Guidance
This implementation guidance is designed for use by Information Assurance Managers, System Administrators, or individual Subject Matter Experts (SMEs) tasked with implementation of I&A mechanisms. The following general implementation guidelines apply: 1. To ensure compliance with (DoD PKI policy), DoD PKI is to be the primary mechanism of individual identification and authentication for all DoD systems wherever possible. For DoD PKI infrastructure implementation guidance, refer to DoDI 8520.2, Enclosure 3 (01 Apr 04). 2. For systems that have not yet implemented, or are unable to implement DoD PKI, ensure that individual user accounts are set up in accordance with guidance provided in implementation guidance for IAAC-1 and ECLP-1. 3. When setting up user accounts on workstations, servers, databases, or individual applications, system administrators shall set password configuration parameters to ensure that password structure conforms to the following standards: · Passwords must be a minimum of eight (8) characters in length. · Passwords must contain a case-sensitive mixture of letters, digits, and special characters (e.g., punctuation marks, etc.) such as the example (emPagd2!). - Whenever a password is changed (by the user or system administrator), at least four characters must be changed from the previous password (e.g., [emPagd2!] becomes [0LP&gd2?]). · Password aging must be enabled to ensure that passwords must be changed at least every ninety (90) days for classified and SBU systems and no more frequently than every seven (7) days for both types of system. · System administrators shall configure system accounts to maintain a password history for a period of at least one (1) year. Additionally, users shall not be allowed to use any of their ten (10) previously used passwords. 4. Ensure that the process for registering new users on the system and providing user ID and password conform to practices outlined in IAAC-1. 5. System Administrators (or other SMEs involved in Independent Verification and Validation of password features) shall test the robustness of user passwords on systems processing classified or SBU information by employing a DoD-approved password policy enforcement tool (e.g., Anixis PPE). 6. System Administrators are to ensure that all default, factory-set, or standard-user accounts and associated default passwords are disabled and, to the extent that the OS or application permits, removed completely. Refer to OS, system, or application-specific STIGs, configuration standards, or vendor’s configuration guidance for specific steps on how do disable and/or remove default user accounts, IDs, and passwords. 7. Authenticators/user IDs/passwords shall be protected in the following manner: · Access to system files containing user account information and passwords shall be restricted to system administrators · Files containing authenticator information shall be classified at the level of information for which the accounts and passwords are assigned to protect. · Passwords shall be shadowed. If password characters display in clear text while being entered into the password acceptance field, check the configuration of the application to ensure that the shadowing feature is enabled. · System security policy, rules of behavior, or other applicable system user policy shall be written in a manner that specifically prohibits the sharing of passwords among users. · Review any and all scripts used for automated boot processes or application access shall be reviewed to ensure that they contain no password automation or access features. 8. User passwords shall be encrypted, both at rest and in transit through the network using robust (i.e., 128-bit or stronger) encryption through a DoD-approved algorithm (e.g., RC4, RC5, IDEA, Blowfish) and through such robust means of secure transit as SSH and SSL-3.

Guidance

This implementation guidance is designed for use by Information Assurance Managers, System Administrators, or individual Subject Matter Experts (SMEs) tasked with implementation of I&A mechanisms. The following general implementation guidelines apply:

1. To ensure compliance with (DoD PKI policy), DoD PKI is to be the primary mechanism of individual identification and authentication for all DoD systems wherever possible. For DoD PKI infrastructure implementation guidance, refer to DoDI 8520.2, Enclosure 3 (01 Apr 04).
2. For systems that have not yet implemented, or are unable to implement DoD PKI, ensure that individual user accounts are set up in accordance with guidance provided in implementation guidance for IAAC-1 and ECLP-1.
3. When setting up user accounts on workstations, servers, databases, or individual applications, system administrators shall set password configuration parameters to ensure that password structure conforms to the following standards:
  · Passwords must be a minimum of eight (8) characters in length.
  · Passwords must contain a case-sensitive mixture of letters, digits, and special characters (e.g., punctuation marks, etc.) such as the example (emPagd2!).      - Whenever a password is changed (by the user or system administrator), at least four characters must be changed from the previous password (e.g., [emPagd2!] becomes [0LP&gd2?]).
  · Password aging must be enabled to ensure that passwords must be changed at least every ninety (90) days for classified and SBU systems and no more frequently than every seven (7) days for both types of system.
  · System administrators shall configure system accounts to maintain a password history for a period of at least one (1) year. Additionally, users shall not be allowed to use any of their ten (10) previously used passwords.
4. Ensure that the process for registering new users on the system and providing user ID and password conform to practices outlined in IAAC-1.
5. System Administrators (or other SMEs involved in Independent Verification and Validation of password features) shall test the robustness of user passwords on systems processing classified or SBU information by employing a DoD-approved password policy enforcement tool (e.g., Anixis PPE).
6. System Administrators are to ensure that all default, factory-set, or standard-user accounts and associated default passwords are disabled and, to the extent that the OS or application permits, removed completely. Refer to OS, system, or application-specific STIGs, configuration standards, or vendor’s configuration guidance for specific steps on how do disable and/or remove default user accounts, IDs, and passwords.
7. Authenticators/user IDs/passwords shall be protected in the following manner:
  · Access to system files containing user account information and passwords shall be restricted to system administrators
  · Files containing authenticator information shall be classified at the level of information for which the accounts and passwords are assigned to protect.
  · Passwords shall be shadowed. If password characters display in clear text while being entered into the password acceptance field, check the configuration of the application to ensure that the shadowing feature is enabled.
  · System security policy, rules of behavior, or other applicable system user policy shall be written in a manner that specifically prohibits the sharing of passwords among users.
  · Review any and all scripts used for automated boot processes or application access shall be reviewed to ensure that they contain no password automation or access features.
8. User passwords shall be encrypted, both at rest and in transit through the network using robust (i.e., 128-bit or stronger) encryption through a DoD-approved algorithm (e.g., RC4, RC5, IDEA, Blowfish) and through such robust means of secure transit as SSH and SSL-3.

References

DoDI 8520.2 “Public Key Infrastructure (PKI) and Public Key (PK) Enabling”, Enclosure 3, 01 April 2004
CJCSI 6510.01 Defense in Depth: Information Assurance (IA) and Computer Network Defense (CND)” Change 1, Enclosure C, Appendix A; and Appendix H, Enclosure C, August 2004
DISA Enterprise System Management STIG, Version 1, Release 0, Section 3.3, 29 October 2004
DISA Network STIG, Version 5, Release 2, Sections 3.4.1, 3.5.4, and 3.13, 29 September 2003
DISA Database STIG, Version 7, Release 1, Section 3.1, 29 October 2004
Secure Remote Computing STIG, Version 1, Release 1, Section 5.5 and 5.6, 14 February 2003
Department of Transportation Solaris Secure Baseline Configuration Standards, Section 2.0, 20 January 2004
UNIX STIG, Version 4, Release 4, Section 3, paragraphs 3.1 and 3.1.1, 3.2, 3.2.1, and 9.4, 15 September 2003
Windows NT STIG, Version 4.2, Chapter 13, 18 September 2001
Addendum to Windows NT STIG, Version 3, Release 1, paragraph 4.5.3; Section 5; Appendix E, 24 November 2002
Windows XP STIG Version 1, Release 8, Section 6.1, 03 December 2002
Windows NT/XP/2000 Addendum Version 4, Release 1 – STIG, Section 4.5.3, 26 February 2004
Department of Transportation Windows 2000 Secure Baseline Configuration Standards, Section 1, 20 January 2004