How RASP Works in a DevOps Environment
Runtime Application Self-Protection (RASP) technology allows web applications to protect themselves, blocking attacks as they happen. So, what does this mean for DevOps? For one thing, it takes some of the manual effort out of web application security efforts, making them more seamless with the rest of development.
Join the DZone community and get the full member experience.Join For Free
Even if your organization has mastered the principles of DevOps, empowering developers and operations professionals to collaborate as effectively as possible, there’s still security to consider. Orchestrating seamless transitions across the planning, coding, building, testing, deployment, and monitoring phases of the software development lifecycle is one of the main goals of DevOps. Once you’ve reached this point, it makes sense to consider how to make your web applications as secure as they can be.
The embrace of DevOps is driven by the inescapable reality that software development has to keep pace with market demands. As release cycles speed up, the shortcomings of traditional security tools such as SAST, DAST, and pen testing become more apparent. With these solutions, organizations can detect vulnerabilities before deployment—but they don’t address what happens at runtime. Attackers understand this vulnerability all too well, and organizations are paying the price in data breaches, financial losses, theft of intellectual property, and more.
RASP Lets Web Applications Protect Themselves
One way to address this problem is for web applications to protect themselves, blocking attacks as they happen. Runtime Application Self-Protection (RASP) technology allows them to do this. RASP runs on a server, continuously analyzing the behavior of apps once they begin to run, and automatically mitigating threats in real time. It intercepts calls from the app along with validating data requests inside the app to head off malicious behaviors.
What does this mean for organizations working in DevOps? For one thing, it takes some of the manual effort out of web application security efforts, making them more seamless with the rest of development. As Gartner points out in its July 2016 Hype Cycle for Application Security:
“As IT development and operations processes become more agile (including shifts to DevOps operating models), security must not be an afterthought and should be integrated into agile development processes.”
Like DevOps, RASP Is About Increased Efficiencies Through Automation
With DevOps, organizations hope to streamline the processes of application and service development, scaling, and monitoring, as well as to improve application quality, reliability, and performance. By deploying RASP solutions, they can gain deep insights into application logic, configuration, and event flows. Threats such as SQL injections can be stopped in their tracks. Like traditional firewalls, RASPs can automatically terminate sessions. But firewalls can’t stop attacks that occur inside the perimeter, and they’re useless against direct threats to applications.
And with cloud computing and the increasing use of mobile devices, more and more attacks successfully breach network perimeters, reducing the effectiveness of both traditional firewalls and web application firewalls (WAFs).
Also, given their insights into application logic, RASPs have fewer false positives than other solutions, allowing security teams to spend more time addressing genuine threats than chasing false leads.
Making DevOps More Effective, and Web Apps More Secure
There’s no question that adding automated solutions such as RASP into an organization’s security infrastructure helps development organizations save time and work more efficiently. By embracing DevOps principles and making web application security a priority, organizations can improve the quality of their apps and make their overall IT operations more effective than ever before.
Published at DZone with permission of Mike Milner, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.