Tommi - Fotolia

Get started Bring yourself up to speed with our introductory content.

RASP is latest grasp at secure software delivery

Runtime application self-protection could provide more secure software applications after delivery, but you need to recognize its limitations.

This article can also be found in the Premium Editorial Download: null: Is RASP the answer to secure software delivery?:

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 timesaving 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; dynamic application security testing (DAST) and interactive application security testing (IAST) are also widely used by security-conscious development teams. Microsoft possibly initiated the biggest change to secure application development with its 2004 presentation 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 failing.

Then came RASP

This may be why a very different tactic to tackling application 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 protection features for Java applications. Web application firewalls are also dedicated application protection technologies and go some way toward 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 and respond to live attacks provides a further level of protection as it 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 development best practices slip, 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 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.

Security as a feature

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. Developers must see security 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 a 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 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 on dealing with flaws later. Scanners and code reviews won't find every bug but they can dramatically improve the overall security of your applications. Early and regular testing not only reduces the overall cost of software development and maintenance, but improves product reliability and will help protect your organization's 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 best practices when management rushes to embrace the latest acronym in the pursuit of a faster, maybe more secure, approach to software development.

Next Steps

Learn more about software testing methodologies.

See what Michael Cobb has to say about RASP precursors, DAST and SAST

Follow the discussion on whether to try RASP

This was last published in April 2015

Dig Deeper on Secure software development

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Read this instead and avoid the hype machine >> http://bit.ly/alphbet
Cancel

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly.com

Close