To make the job more tangible, the security team should have a checklist of requirements for new application installations. Major version upgrades of existing software should follow a similar, or identical, procedure. The checklist can be broken into categories such as authentication, logging and auditing, encryption, networking, and so on. It may also make sense to include items such as backups and monitoring that are not solely security related.

To simplify the process, a standard, universally accepted checklist can be used as the basis for the certification process. One such guide is the DISA Application Security Checklist, available at iase.disa.mil/stigs. It provides an excellent, if overly wordy, guide for application security requirements. Although the document is aimed primarily at U.S. Department of Defense entities, it is easily adapted to any organization.


Using the DISA document as a template, we can quickly formulate our own set of application security requirements. For convenience, we’ll split them into logical sections, just as is done in the checklist.

Identification and authentication

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.

User account management

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.