Securing homegrown applications for the data center

Enterprise data centers often contain a lot of “homegrown” applications and application components. Whether these are entire applications or small, business-logic fragments running on an application server, they are often part of large, complex and mission-critical systems. Although security experts often criticize the vulnerabilities of operating systems and proprietary applications, these homegrown applications are also vulnerable.

Unlike commercial products, these applications do not receive scrutiny from a very wide audience. This is a mixed blessing: broader use of commercial applications will expose more bugs that lead to broad-based exploits such as worms. Homegrown applications are less likely to contain easily discoverable bugs, but can be the target of a much more dangerous type of attack, a directed and deliberate attack against just one enterprise: yours.

Bugs lurking in a privately developed application can remain unnoticed for years with no ill effect. Unfortunately, these bugs are exposed when the application is delivered outside the company’s perimeter, to partners or clients (or the public). Your development team may be unique, but the programming errors they make lead to all-too-common security vulnerabilities. Even commercial applications that are very heavily tested are still plagued with vulnerabilities, like buffer overflows, that arise from just a handful of bad programming habits.

You can protect your enterprise applications by laying on firewalls, intrusion detection systems, host intrusion detection systems and other security controls, but this can be a very expensive and often ineffective approach. As with commercial applications, security starts at, or before, the design stage of the software development lifecycle. In a recent study by Nemertes Research, we found that IT executives expend 80% or more of their efforts on security before deploying applications. Here are some of the things that your peers are doing to secure applications during development:

* Picking the most secure platform for the job. At the requirements stage, you can choose what platform your application will run on – operating system, application server, virtual machine, programming language, compiler. All of these choices can influence how secure the final product is.

* Getting security specialists involved in design. Several studies have shown that “secure by design” applications are up to an order of magnitude cheaper to secure than applications that have security “bolted-on” later. A security specialist should have input or direct participation in the design team.

* Balancing features against security. It is tempting to keep adding features to an application, but each new feature creates additional security risks. One of the most fundamental design choices your team can make is finding the right balance between features and security. Some operating system vendors have yet to find this balance despite efforts to increase security.

* Pre-built security libraries: Your software development team will often need to use certain security functions, such as user authentication or password storage. If you create a well-tested and carefully written library of secure software components for such tasks, you can avoid many of the most common programming errors.

Bottom line: Security is much less expensive to apply if it is included at the earliest stages of software development. With proper training and good software engineering practices, you can avoid many common programming errors that lead to insecure applications.