Application Security
8/17/2015
01:15 PM
Mark Carrizosa
Mark Carrizosa
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

RASP: A False Sense of Security For Apps & Data

Betting on a single runtime tool like RASP is not the solution for eliminating application security risk.

Reports about data breaches have become so common that we no longer react with shock or outrage, we merely treat them as business as usual. Whether it be a hack at the Office of Personnel Management, UCLA, the Army National Guard or countless smaller breaches, we have become indifferent and desensitized to these violations - unless it impacts us personally.

Web-based applications have been, and will continue to be, a primary target for attackers seeking a means to penetrate organizations’ networks. What’s worse, hackers are finding easier openings when security takes a back seat to achieving faster development and deployment cycles. A number of technologies have been introduced to help secure apps, while fostering faster development. But are they really all they’re cracked up to be?

Let’s consider one technology that’s getting a lot of buzz these days: runtime application self-protection (RASP). The idea behind using RASP for security, according to Joseph Feiman, a research vice president and fellow at Gartner, is that applications can be better protected when self-protection capabilities are built into their runtime environments. This provides security and development teams with full insight into application logic, configuration, and data and event flows. And, because RASP operates in the runtime environment, it is able to control application execution, and detect/prevent attacks in real-time, as opposed to a more reactive model that is more focused on minimizing impact. 

RASP clearly offers a number of benefits, such as a granular approach to combatting attack vectors and better scalability minus the additional hardware costs. Because RASP has that direct connection to the self-protected app, it has a clear sense of what that app needs to remain secure. When the application is executed, RASP enables it to monitor itself, detect malicious or errant behaviors, and alert IT to problems.

RASP is growing in popularity because it eliminates a lot of the time and effort that organizations would typically take to build security checks into their processes. But in many ways, I see such handy shortcuts could foreshadow serious problems with the quality of the underlying code.

This is not speculation; there is a reason why SQLi/XSS are consistently on the Open Web Application Security Project (OWASP) Top 10. The concern is that the reliance on this solution can mask a developer’s tendency to let software security best practices take a back seat to new capabilities, particularly with increasingly aggressive go-to-market timelines and continuous delivery models.

Unintended Consequences

Though RASP’s goals are noble, it could also have unintended consequences rendering it unusable. Introducing a re-write of software execution at the last minute could be very risky from a support/incident response perspective, particularly as applications are modularized and supported by numerous teams. Expect there to be a fair amount of contention and finger pointing should there be any type of operational issue (regardless of relevance).

More often than not, checks could be paused, alarms silenced, and anything causing these issues could take a back seat to revenue generation as a company essentially accepts a high level of risk out of sheer annoyance (similarly to WAF implementations). Certainly this is not the most effective way of responding to security issues.

RASP also could have a negative impact on service level agreements (SLAs). Allowing RASP to stop code running in production in the midst of an attack certainly paves the way for a pretty effective self-imposed Denial of Service (DoS) engine. In today’s high-performing environments, where availability is expected at four or five 9s, downtime could have a serious impact to SLA’s and subsequently result in lost revenue and impact the company brand.

Having been on the frontlines of building security into solutions and development code for high-profile retailers, including Walmart and PetSmart, I believe there are a number of red flags surrounding RASP that must be considered. It is still a nascent technology, as less than 1 percent of all web and cloud applications are leveraging RASP for self-protection today. If companies experience security breaches as a result of their reliance on RASP, they’re not likely to fess up to it publicly. Hence, we don’t know, and won’t know, how effective it is.

Without a doubt, RASP can be a valuable addition in development, QA and testing environments, where it can serve as another element of due diligence and allow you to go back and fix security bugs before they are introduced to a production build. But to truly mitigate these attack vectors, we need to look to properly secure what is at the core of the businesses, the application code itself. Betting on a single runtime tool - like RASP - to magically eliminate risk is not the answer.

Mark Carrizosa is the vice president of Security at Soha Systems, a cloud-based application security provider for enterprises and SaaS providers. Carrizosa joined Soha Systems in 2015 from Walmart where, as principal security architect, he developed and implemented the ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Darkman9812
50%
50%
Darkman9812,
User Rank: Apprentice
8/24/2015 | 8:38:19 AM
In my opinion...
In my opinion, this article was written by a person who's "Cloud Application Security" business would be greatly impacted, in an  adverse way, if companies were to adopt the use of RASP, so take it for what it's worth.
mcarrizosa
50%
50%
mcarrizosa,
User Rank: Author
8/19/2015 | 1:02:59 PM
Re: Testing
Clearly, the title posed a question intended to shed light on a hot topic to provoke a discussion from all angles...mission accomplished I suppose.

As for your second point, you are correct in that reliance on any single technology (security or otherwise) carries some level of risk and are considered as such by any security professional, hence the term "Defense In Depth"; though when considering the difference between detective and preventative security measures I'd say it's only half true.

What is unique about this particular topic is that there is conflicting information with regards to how compliance efforts are approached. We've all seen shops utilize compliance as a checkbox, as opposed to part of a robust security program. I've had (as recently as 2 weeks ago) conversations with teams who are looking to use WAF to eliminate the need of source code review for PCI. While not entirely accurate, PCI DSS 3.1 Section 6.6 may help in perpetuating some of the confusion by allowing organizations to rely on a preventative control vs actual testing.

Considering the increasing risk to any application exposed to the Internet these days, it is worth bringing this point of view to light to hopefully drive security organizations to think about all angles as they implement more effective programs and reduce the amount of overall breaches.
planetlevel
50%
50%
planetlevel,
User Rank: Author
8/19/2015 | 12:20:21 PM
Re: Testing
If that's what you really think, then what's with a title like "RASP: A False Sense of Security For Apps & Data?  Clickbait?  Why wouldn't any single security technology give the same false sense of security?
mcarrizosa
50%
50%
mcarrizosa,
User Rank: Author
8/19/2015 | 12:15:41 PM
Re: Testing
There is no doubt that RASP has the potential to be used as part of a multi-pronged approach to securing applications. However, as with any new technology, careful consideration must be given to the manner in which it is implemented and how it will affect the overall effort. As the "latest and greatest" innovations break into the industry, the marketing machine has a way of promoting something that has potential to add great value to a more loftier "magic bullet" status. With all the hype, deserving or otherwise, organizations are feeeling pressure to plug the leaks quickly to focus on features & function and may do so at the risk of skirting solid appsec fundamentals.

This is not to say developers do not care about security, I would argue that they have more insight to how to protect an application than a potion of security professionals. The issue at hand is that they receive requirements from multiple sources and must prioritize (sometimes according to who screams the loudest). Over the last 10+ years i've seen, more often than I would care to admit, security requirements are given priority when there is some external driving force (i.e. audits, breaches, etc.) as opposed to becoming ingrained as part of the development culture.

Tools like IAST, DAST, and even RASP are just that, tools. They can be extremely effective to help mitigate risk throughout the SDLC, but they must be used effectively and efficiently and in combination with training and awareness programs to ensure the quality code is released consistently. My point being, that reliance on a single tool is a bit short-sided and can have some pretty serious repercussions if other critical practices are de-prioritized.

As I mentioned, as of a recent study less than 1% reported using RASP within their production environments. With such little adoption (not unexpected at this stage of the game), it is impossible to predict just how effective or dispruptive the technology will be. What is clear so far is that caution and due dilligence should be priorities as organizations look to explore methods which operate within a run-time environment, particularly those that have the potential to affect functionality if not configured optimally and managed throughout the change cycle.
planetlevel
50%
50%
planetlevel,
User Rank: Author
8/18/2015 | 10:16:28 AM
Re: Testing
This is a big advantage of RASP. You can have it in place during development and security testing, to be sure that everything works. I think of RASP as just part of the application that provides attack detection and prevention.  It deploys along with the application into production fully tested.
planetlevel
50%
50%
planetlevel,
User Rank: Author
8/18/2015 | 10:13:12 AM
Are there any real criticisms here?
I think it's important to recognize that there are many critical use cases that RASP performs far better than any alternative. Every organization needs to have the ability to respond quickly to security events without a full development cycle.

* measure attacks traffic for threat intelligence
* block attacks against custom code and libraries
* issue virtual patches

So RASP isn't a "handy shortcut." It's part of a well-balanced application security strategy. When integrated with IAST, you get unified application security command and control throughout the entire SLC.  You claim RASP...

* "can mask a developer's...security best practices"
* "could have unintended consequences"
* "could be paused"
* "could have a negative impact on SLAs"

These are strawmen with no evidence or substantiation. That's the essence of the fear, uncertainty, and doubt that plagues our industry. If you think there is a chance that RASP could cause a DoS, then spell out the scenario. But remember that RASP is different than a WAF, it operates within the context of the running application, and can be extremely surgical in how it responds to attacks.

It's not my experience that developers just throw in the towel and not try to develop secure code anymore when new technologies are added. Actually, RASP will provide the data to help prioritize fixes on the vulnerabilities that are actually being attacked.

 
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
8/17/2015 | 2:44:10 PM
Testing
This is why the testing phase is imperative. Even in the context of RASP. I would imagine like any of technology there are ways to set exclusions for genuine traffic. During the testing phase you need to discern what regular traffic looks like and remove it from the prevent phase. As "regular" is subject to change RASP would need to be updateable. This is all in an effort to not prevent genuine traffic. Like anything else, if you skip through this phase you are going to run into problems.
Register for Dark Reading Newsletters
Dark Reading Live EVENTS
INsecurity - For the Defenders of Enterprise Security
A Dark Reading Conference
While red team conferences focus primarily on new vulnerabilities and security researchers, INsecurity puts security execution, protection, and operations center stage. The primary speakers will be CISOs and leaders in security defense; the blue team will be the focus.
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: No, no, no! Have a Unix CRON do the pop-up reminders!
Current Issue
Security Vulnerabilities: The Next Wave
Just when you thought it was safe, researchers have unveiled a new round of IT security flaws. Is your enterprise ready?
Flash Poll
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
Enterprises are spending more of their IT budgets on cybersecurity technology. How do your organization's security plans and strategies compare to what others are doing? Here's an in-depth look.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.