This familiar IT project life cycle leaves a security guru feeling unquestionably queasy. How could this seemingly straightforward installation increase risk to the organization? Here are just a few vulnerabilities that were overlooked.

• 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.

This is an extremely common result of many application deployments at organizations such as ACME. Most vendors simply do not have the time, resources, or expertise to develop applications securely, and the customers may not see security as a key requirement of the project. What can be done to increase security when deploying new applications or migrating from old software?

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.