This content is part of the Essential Guide: How to craft an application security strategy that's airtight

Application development security requires forethought

Enterprises push for short development cycles to meet delivery deadlines. Expert Michael Cobb explains how to incorporate application development security into the process.

To stay ahead of the competition, enterprises need to be able to turn an Internet-based business idea into a fully functioning service in double-quick time. The pressure to get software applications ready for market in the shortest time possible has spawned numerous application development philosophies, ranging from sequential design, such as the Waterfall model, to SWAT Team and Agile software development process models. Proponents of each different method hail them as revolutionizing the software application development process, and many development teams rush to embrace the latest time-saving approach in the hope of being able to finally meet delivery deadlines.

Sadly, none of these methodologies really have software security testing at their core, though there are various initiatives and technologies that do aim to reduce the number of security flaws that make it into the final release. SAST, or static application security testing, has been around since 1999, and dynamic application security testing (DAST) and interactive application security testing (IAST) are also widely used by teams that are conscious about application development security. Microsoft possibly initiated the biggest change to application development security with its presentation in 2004 of its Trustworthy Computing Security Development Lifecycle, which puts secure coding at the heart of software creation while aiming to reduce development costs. However, given the daily announcement of successful attacks against applications developed and managed by the world's biggest businesses, it's clear that real-life methods for developing robust and secure applications are still failing.

RASP closes app security testing gap

This may be why a very different tactic to tackling application development security is attracting a growing number of followers. RASP, or runtime application self-protection, was first championed by Joseph Feiman in 2012. It aims to close the gap left by application security testing and network perimeter controls, neither of which have enough insight into real-time data and event flows to either prevent vulnerabilities slipping through the review process or block new threats that were unforeseen during development.

RASP technology is built or linked into an application or its runtime environment so that it has the capability to control application execution. For example, HP's Application Defender monitors an application's API calls to common core libraries. This enables it to analyze application flow and spot potentially malicious events, such as cross-site scripting and code injection. Arxan Technologies offers RASP features for Java applications. Web application firewalls are also dedicated application protection technologies and go some way towards providing context when filtering application requests, such as blocking access to certain functions at certain times of day, but unlike RASP technologies they don't have the benefit of context from within the application.

This extra insight means RASP-protected applications rely less on external devices like firewalls to provide runtime security protection; so if perimeter defenses fail to spot malicious traffic and the development team failed to implement proper validation checks on data input by a user, the application can still protect itself. For example, only by seeing a complete database query, constructed within the application, can it be accurately determined if it's legitimate or malicious. Enabling an application to continuously run security checks on itself and respond to live attacks provides a further level of protection, as it is can terminate a malicious user's session if an attack is detected and alert monitoring systems to what has happened.

If RASP technologies can really deliver "self-protection," then applications sitting on the Internet will be far more robust and able to repel attacks. My concern, though, is that when new technologies or methodologies come along, development teams tend to let slip application development security best practices, relying instead on their new solution to do security for them. Commercial pressures mean developers are made to focus on frequent releases in short development cycles in order to introduce new features more quickly. This means security is often overlooked even though integrating security into the software development lifecycle has been shown to result in more secure software.

Define security requirements at the beginning

Whichever method of software design and testing is used, developers should not depend on an elaborate network of defenses and other security controls to cover for poor practices. Defining minimum security requirements for a project during the design and architecture stages is essential, as it allows developers to plan and integrate security controls far more effectively than trying to bolt them on as an afterthought. Development teams must understand the concepts of secure design and topics such as threat modeling, secure coding and security testing, and have clear policies and standards to follow. Security must be seen by developers as a feature that will be tested just like any other feature or requirement. SANS has long maintained that one of the primary causes of computer security vulnerability is "assigning untrained people to maintain security and providing neither the training nor the time to make it possible to learn and do the job." Code will never be 100% bug-free, but the same vulnerabilities should not keep appearing on the OWASP Top 10 and SANS Top 25 dangerous programing errors.

Implementing a structured software development lifecycle for software developers to work with will provide assurance that code has passed inspection and testing, and ensure controls are validated before being used in a production environment. Using methods such as static and dynamic code analysis throughout the development process can substantially reduce the time spent looking for bugs, improve developer efficiency and cut costs spent on dealing with flaws later on. Scanners and code reviews won't find every bug but can dramatically improve the overall security of application. Early and regular testing not only reduces the overall cost of software development and maintenance but improves product reliability, profits and reputation.

Adding RASP as another layer of security to protect live applications certainly makes sense, but there are no quick fixes when it comes to security. One approach alone will never be sufficient, so don't forget the importance of maintaining application development security best practices when management rushes to embrace the latest acronym in the pursuit of a faster approach.

Next Steps

Find out what IT admins and developers need to know about back-end application development

Explore the choice between top-down and bottom-up application development strategies

Learn about continuous application development in the cloud

This was last published in May 2016

Dig Deeper on Secure software development