This covers how applications process and authenticate user identities. Several lengthy requirements are listed in the DISA checklist, but they boil down to the following requirements:
- The application must use valid, standards-based strong encryption for authentication. For most organizations, this means that the application uses a certificate signed by an approved certificate authority. The certificate must not be expired, revoked, or otherwise invalid.
- An adequate client authentication process must be supported. This might take shape in a variety of ways. An obvious example would be a simple login form, but a less common case could be a web server becoming a client when connecting to a database server on the back end. Authentication processes may include a password, a certificate or key, and/or a biometric. If passwords are used, the application must support a minimum set of complexity requirements (for example, at least 9 characters of mixed alphanumeric and special characters and a set expiration). An application that allows access with only a username, does not support password complexity, or does not properly enforce controls that it claims to support would fail this requirement.
- If applicable, the client should authenticate the server. For example, a web browser connecting to an SSL-enabled web server would validate the SSL certificate. In this case, it should validate that the certificate was signed by a trust certificate authority, is not expired, and matches the URL of the page.
The DISA guide only contains one requirement in this section, but there are potentially many more concerns. For example, how does the application manage user accounts? Are administrative accounts carefully protected? A proper application certification thoroughly checks the user account protection mechanisms.
- User IDs should be unique. Duplicate user IDs can lead to overlooked privileges or weak passwords.
- The application must authenticate to a centralized authentication system. Most organizations have a centralized user account directory, such as Active Directory, OpenLDAP, or Red Hat Directory Server. To minimize the number of accounts and passwords that users must remember, the application should support at least LDAP authentication.
- Shared accounts must be prohibited. This is a central requirement of some regulations, such as HIPAA. Accounts should be tied to an individual Ė particularly administrative accounts.
- Access requests should follow a standard request procedure. This should be tracked and reported against on a regular basis.
Requirements in this area are common in regulations and standards such as the Payment Card Industry Data Security Standard. Permissions and cryptography should be used to protect data when stored on disk and in transit.
- Sensitive data should be protected by file permissions at rest. On disk, files should only be accessible by administrators and by the processes that need access (for example, the operating system, database service, or application processes). If backups or duplicates of the data exist, they should also be examined.
- Authentication credentials should be encrypted at rest. Furthermore, non-privileged accounts should not have access to the keys that encrypt data.
- All sensitive data in transit should be encrypted with FIPS 140-2 validated cryptography. This can be accomplished in a variety of ways, such as by using technologies such as stunnel, SSL-enabled HTTP, or LDAPS.
- All cryptographic modules should be FIPS 140-2 validated. The check can be performed at csrc.nist.gov/groups/STM. In particular, be especially wary of applications that use proprietary, in-house developed encryption.