Too many incidents continue to occur, and in fact are increasingly occurring, because the applications are not secure; they allow bad thing to happen. For example, web applications too often allow for mistakes to happen, such as having personally identifiable information (PII) "inadvertently posted" as the University of Pittsburgh Medical Center experienced last month.

The more software you have, the more systems you have, and the more options that are available for client machines to communicate with your software, the less secure your networks and data. Increased software and systems increases complexity. Increasing complexity inherently increases vulnerabilities.

Applications security can be most successfully addressed systematically throughout the entire software and systems development life cycle (SDLC). I have talked often about the need to incorporate security and privacy into the entire SDLC, such as here and discuss this within a 2-day seminar, "Handling Complex and Difficult Privacy and Information Security Issues".

During the SDLC process, the software engineers and developers must engineer the application to minimize access to data and network resources using built-in granular controls to maximize application security.

There are generally two methods currently used to defend against all types of application server attacks; the negative security model and the positive security model.

Very basically the negative security model is an "allow everything, and block those actions known to be bad" type of approach. This approach identifies and disallows the specific types of traffic and access attempts already known to be threatening while allowing all other requests and access attempts. Any of you familiar with the RACF security model for mainframe applications will recognize this as the model being used.

The positive security model utilizes granular access controls to application capabilities. Access controls can be made on a very specific level to any user, program, or process that requests permission to data or tries to perform specific business process activities. This is generally a "block everything and allow only specific actions" type of approach. Again, with reference to mainframe security, this is the model used by Top Secret and ACF2.

The concept of using granular access controls can also be used to restrict the capabilities of applications that will result in improved security. For example, you can restrict access to Internet-facing applications by screening all access requests through a tightly configured application gateway.

I just posted a paper, "Reducing Attack Exposure for Internet-Facing Applications" that discusses these and other associated issues in detail.

If you get a chance, please read it and let me know what you think and if you have other issues to add to what I covered.

I look forward to your feedback!