Application security best practices help meet compliance objectives

Most enterprises have defined processes for software development. These processes are put in place to help managers control functionality, quality and developer productivity. Unfortunately, when building these processes enterprises rarely place much emphasis on security or compliance objectives. However, building security into the software development life cycle (SDLC) is critically important for both compliance and development productivity. Doing so will help companies comply with increasing regulations and industry standards, and can even reduce software development costs.

Aligning application security best practices and compliance objectives can be easier than most organizations think -- with the right knowledge and planning.

Enterprises have gone to great lengths to improve information security and document compliance by adhering to regulations and industry standards like Sarbanes-Oxley and PCI DSS. Despite this trend, one critical area has only recently come into the equation: application security. Enterprises are beginning to realize that applications are the biggest source of data breaches -- some researchers have estimated that 90% of security vulnerabilities exist at the application layer. This is why regulators and industry standards bodies are adding requirements related to application development practices.

For example, the Health Insurance Portability and Accountability Act states that, “[Covered entities must] conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of electronic protected health information held by the covered entity.” 

With a few application security best practices in place, an organization will easily be able to meet this industry regulation. When building an application, a company should first describe how hackers might choose targets, locate entry points and conduct attacks on the application. This will give developers a better idea of what specific application defenses the attacker would face. Building out a possible attack scenario will not only allow the company to comply with the regulation, but it will also better prepare that company for any potential real-life attacks that may occur.

Another example of a compliance standard that can be easily met with simple application security best practices is a PCI DSS standard for security testing. Under PCI DSS, “[organizations must review] public-facing Web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes [unless those applications are protected by a Web-application firewall].”

Some best practices to comply with this standard include rigorously testing the application components that process confidential information, validating inputs, parsing file formats, authenticating users, checking for sensitive information exposed in memory and in temporary files, maintaining a unit test library, and conducting extensive penetration testing. It’s also important to have developers cross check each other’s code. If a company were to have these best practices already in place to ensure proper security testing, compliance with the above regulation would be met.

Of course, not every application security best practice can be adopted -- at least, not all at once. Organizations need to identify which development activities are most important to them based on corporate governance and priorities, and decide which practices to adopt first and in what sequence to introduce the rest in the future.

Other benefits of application security best practices

There are additional benefits to following application security best practices beyond simply compliance. By building application security into the SDLC, companies are being proactive about security. There is strong evidence that addressing security issues early can dramatically reduce software development costs and improve delivery schedules.

Enterprises are beginning to realize that applications are the biggest source of data breaches -- some researchers have estimated that 90% of security vulnerabilities exist at the application layer.

Missing or inadequate security features are defects. Industry experts have determined that preventing defects in the design phase -- directly before the development phase -- requires one-tenth the effort of catching and fixing those defects at the system test phase that occurs after the application has already been developed.

At the Gartner IT Security Summit in London in 2004, Victor Wheatman, managing vice president of security at Gartner, estimated that removing 50% of software vulnerabilities prior to applications being put into production can reduce configuration management and incident response costs by 75%.

Bottom line: Do what’s right for your company

For some enterprises, a “find and fix” approach using vulnerability scanners may suffice until they mature their SDLC. Organizations with legacy applications may determine that the best use of their time is to plug a few gaping vulnerability holes instead of taking the time and effort to re-architect the application. Conversely, companies with hundreds of small, internally facing applications might determine that an integrated automated daily code scan upon check-in is the best use of their time for these constantly changing applications, and only complete annual deep penetration testing.

The bottom line is that an enterprise needs to understand the inherent risk level of the applications it builds and deploys. Applications need to be examined in terms of factors such as applicable compliance requirements, source (internal or outside third party), age, language (especially if written in an old or vulnerable language) and the environment in which they will be deployed -- as well as the type and amount of sensitive information processed, stored and transmitted. The enterprise then needs to decide what activities in the software development lifecycle will have the greatest impact on reducing risk and improving compliance, then create an action plan for tackling these activities.

This plan may include the use of tools or other partners that will make creating secure applications easier and can be used to accelerate or outsource tasks like training, threat modeling, analyzing requirements, reviewing code, penetration testing and developing secure coding practices.

Most importantly, after these application security best practices are in place, a company must continue to measure progress relative to security and compliance objectives and requirements. These factors are always adjusting the roadmap as corporate priorities, threat patterns and compliance standards change. By following these few simple steps, your company will be well on its way to aligning application security best practices and compliance objectives.

Ed Adams is CEO of Security Innovation Inc., a software security and cryptography firm in Boston. Let us know what you think about the story; email Ben Cole, Associate Editor.