- Because the application was developed about a year ago, it was certified by the vendor against the operating system patches available at that time. Too busy developing the next version to certify new patches, the installation checklist explicitly disallows the more recent patches.
- After completing the database software installation, the widely accessible database administrator account password is left at the default - blank.
- Several application administrator accounts with simple passwords were created during the testing phase and are not removed prior to the production deployment.
- The application has auditing capabilities, but the required module was not purchased during the contracting phase and subsequently was not installed.
- The vendor supports only Telnet for remote support, and was given a generic account with a shared password for ongoing maintenance.
- The web front end is deployed without the use of SSL encryption.
First, security should be part of the process from the beginning. If all customers wrote security requirements into the RFP, for example, vendors would start to take it more seriously. At the very least, management would be aware of some of the risks inherent in selecting a particular vendor simply by reviewing responses to the requirements. Measures could be taken to mitigate any risks during the implementation, or the risk could be accepted and documented.
In step 2 of the project cycle, an important resource was not included in the team: the security team representative. This individual will watch out for, and hopefully mitigate, just the sort of weaknesses that were discovered after the fact. The security team should have a template (discussed below) for securing applications, but individually they will also be thinking outside of the box to proactively resolve non-standard problems as well.
Itís a rare organization that has documented security findings for each application in the environment. Adding a security sign-off in addition to the more common business acceptance procedure will show auditors that the company takes security seriously.
The security representative certainly has her work cut out for her. Convincing the vendor, management, and the rest of the project team that the security changes are implementation requirements is no simple task, and it takes creative technical thinking and attention to detail to resolve many of the technical issues.
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.