Application Security: People, Process, and Technology

Most organizations have worked feverishly to secure the network infrastructure, including executing rigorous operating system patch and configuration management processes.  They’ve done such a good job, attackers are turning to applications as the next avenue of attack.  This includes both commercial and proprietary solutions.

In this article, we’ll look at the challenges facing managers as they implement commercial applications and applications developed in-house.  And we’ll explore ways to begin the process of hardening those applications.

The Challenges 

According to the results of a Princeton University research study, many commercial applications actually weaken operating system security (Govindavajhala and Appel, 2006).  Services or other components introduced into a computing environment might operate at higher permission/right levels than the user who is logged in.  This opens the system for potential compromise, even if the network administrator conscientiously enforces least privilege.  In addition to authorization issues, programming flaws that allow buffer overflows or other popular attacker portals are still common. 

Proprietary applications, or applications written by corporate in-house developers, can also present significant risk.  In many cases, security is an afterthought.  By the time vulnerabilities are identified, the product is often nearly complete.  The cost of integrating security safeguards into the application at this point is too expensive.  So the risk is either accepted, or the security team is expected to work its magic to protect the flaws inherent in the software.

At special risk are in-house web applications running on a company Intranet.  Web services and applications tend to be at odds with secure computing.  They open environments for easy access to data.  Further, web applications and services are by design loosely coupled.  Loose coupling, while a productive development practice, can provide many points of access into an organization’s information infrastructure (Exler, 2004).

According to Ron Exler, Director of Research for the Robert Francis Group, the following is a list of the top ten most critical web application security vulnerabilities (2004):

  1. Broken access control
  2. Broken account and session management
  3. Buffer overflows
  4. Command injection flaws
  5. Cross-site scripting (XSS) flaws
  6. Error handling problems
  7. Insecure use of Cryptography
  8. Remote administration flaws
  9. Unvalidated parameters
  10. Web and application server misconfiguration

Facing these challenges, managers must proactively manage the secure introduction of commercial applications into the enterprise, and a secure system development lifecyle for in-house development.

The Solution

Application security assurance requires focus on people, process, and technology.  In the people category, awareness training for developers is critical for a successful, secure development effort.  Developers won’t integrate security into their applications if they are not aware of what secure coding means, or if the organization’s culture does not value secure application design.  Technical awareness training and management support of the company security program are typically required before in-house applications are consistently built with security in mind.

Processes provide consistent results.  So if an organization expects to consistently produce secure applications, it must develop a system development lifecycle process that specifies when the security team should be involved.  The security team should work with the assigned developers to review each application requirement before application design begins.  In this way, potential security vulnerabilities can be designed out of the final product. 

During the testing phase, organizations should employ formal testing processes and tools to identify software vulnerabilities before approval is given to move an application to production.  If new vulnerabilities are found, or if vulnerabilities identified during the requirements definition phase were not adequately addressed, management must assess the level of risk presented to the enterprise if the application is not sent back to design for security improvements.

Commercial applications should be subject to the same people, process, and technology requirements as those imposed upon the internal development teams.  Managers must ask the right questions and ensure contract wording to ensure third party applications do not inadvertently neutralize in-house security efforts.

Conclusion

As security teams harden operating systems and other infrastructure components, softer application environments provide attractive targets for attackers.  Managers must review and modify training, development, and software acquisition policies and processes to ensure they close this gap.  

Author:  Tom Olzak 

Sources

Exler, R.  (2004, November).  Security and the application development process.   Retrieved February 8, 2006 from http://www.csoonline.com/analyst/report3068.html

Govindavajhala, S. & Appel, A. (2006, January).  Windows access control demystified.  Retrieved February 8, 2006 from http://www.cs.princeton.edu/~sudhakar/papers/winval.pdf

 

Leave a Reply

You must be logged in to post a comment.