Secure Development - Secure Configuration Management

Writing secure code is the most important aspect of secure development, since this is where the proverbial rubber meets the road. However, there are many other environmental factors that contribute to your application's overall security posture. This includes the application/web server, backend systems such as databases, and of course the underlying operating systems and network infrastructure. Consider the following common vulnerabilities:

• Unpatched versions with known vulnerabilities
• Inconsistently applied settings
• Unnecessary default, backup, or sample files
• Open administrative services
• Default accounts with default passwords

The majority of enterprise web applications rely on numerous third-party packages, both commercial and open source. This is a widely accepted (and solid) practice since it eliminates "reinventing the wheel" and adds valuable features with little effort and cost. However, this can lead to security issues if these dependencies are not managed properly. As a developer, your first instinct might well be to leave these packages at their original versions (as of the time your application was released) since this eliminates extensive re-testing. Unfortunately, this inevitably leads to outdated and vulnerable code since most active software products routinely issue new releases with bug fixes and new features. Keeping up with versions is especially important if your original application build included an early release of the product, which traditionally have more issues with both functional and security bugs.

To ensure a managed, secure environment for your application, you can use the following guidelines:

1. Release Management: Many applications already have regular release cycles, but these may not include updates to third-party components. Most releases require full testing of the application: regression testing, user testing, etc.--so each release presents an opportunity to review any third-party components. In most cases, minor version upgrades of these components will not impact functionality since most vendors strive to maintain backwards compatibility, especially with APIs and other interfaces. Therefore, an application release is a free chance to apply patches and/or updates to your third-party components without having to re-test separately. For more on this topic, check out this white paper by Third Brigade (it's a bit sales-pitch-y, but has some good information).
2. System Hardening: For each type of system, develop a set of hardening guidelines to ensure you are applying security consistently across your environment. Both the vendors and many third parties (such as the NSA) provide hardening guidelines for the most common server environments, which you can use as a starting point. If no specific guidance is available for your situation, make sure that hardening includes the following items:
   1. Configure all appropriate security mechanisms
   2. Turn off all unused services, disable unused and default accounts
   3. Set up roles, permissions, and accounts
   4. Set up logging and alerts
3. Automated Configuration Management: Try to automate your configuration management as much as possible--this leads to less admin overhead, more consistency, and less training for your staff. For example, rather than providing a lengthy checklist of which options to enable and disable after a stock OS install, create a single VM image of a clean, hardened install which can then be cloned easily to spin up new servers. A VM can be cloned in several minutes, as opposed to several hours that could be spent on a fresh install and all of the associated manual configuration. To ensure a consistent build process, use tools such as Ant to precisely define the build steps and options. Finally, make sure you are using a code versioning system that meets your needs. There are many options, though SVN and git currently seem to be among the more popular ones, especially in the open source community.
4. Regular Patching: There are few professional IT organizations left who don't apply OS patches regularly. But what about all of the other software that runs on today's enterprise servers? According to recent research by SANS and Qualys, application patching lags far behind OS patching, and the bad guys are well aware of this fact. As indicated in "Release Management" above, your patch strategy should include your web applications, third-party application components, and any locally-installed software on your servers.
5. Vulnerability Scans: Even when following best practices, occasional security lapses can occur. Your best protection is to perform regular vulnerability scans of your environment, both internal and external. Depending on the size of your company, this could be performed by your in-house IT security organization, though best practices generally recommend hiring a third-party consulting firm to run these scans at least annually.

Using these techniques will ensure that your application runs in a predictable and secure environment. After all, you'd hate for an obscure third-party library from three years ago to provide back-door access to one of your critical business applications.

Next time, we will discuss one of the oldest and most universal vulnerabilities: denial-of-service, which is especially hard to defend against in a web application environment.