Comments
Oldest First | Newest First | Threaded View
RASP is the new WAF
Thanks Brian,
That is a really insightful article. I don't agree with your conclusion, however. Runtime Application Self Protection (RASP) is in many cases not the answer to many team's problems.
* RASP only covers a small class of web application vulnerabilities, such as XSS and SQLi. These are trivially easy to fix by developers, and existing WAF technologies already do a good job here for those teams without the resources to effect a fix.
* RASP is promised to work out of the box, yet prudent implementors should really have a dedicated in house monitoring staff to ensure that false-positives are being corrected and important business transactions are not being prevented.
* RASP intentionally introduces new behaviour into a system, but this behaviour and the heuristics applied are proprietary to the vendor - a black box. Certification and validation activities for some of the systems using RASP may need to consider this additional complexity. The new behaviour becomes part of the application runtime behaviour and therefore must also be validatable.
* RASP (and in many ways WAF technologies, too) never actually correct the underlying vulnerability, instead they perform the role of a compensating control. Whilst the compensation is in place, risk from the threat of the vulnerability being exploited is indeed effectively mitigated, but a strong dependency is introduced: without the compensating control, the system becomes vulnerable immediately.
* With RASP not only are years of licence fees for the compensating control now necessary, a new risk is introduced. If the dependency is not clearly documented and service managers not continually trained on this dependency, it may simply be forgotten. You see, removing the control will lead the system to fail-open.
RASP is certainly an exciting technology with much potential ahead of it, but managers should consider the potential downsides before chasing the next new shiny thing.
Again, thanks for the article it provided me with food for thought!
That is a really insightful article. I don't agree with your conclusion, however. Runtime Application Self Protection (RASP) is in many cases not the answer to many team's problems.
* RASP only covers a small class of web application vulnerabilities, such as XSS and SQLi. These are trivially easy to fix by developers, and existing WAF technologies already do a good job here for those teams without the resources to effect a fix.
* RASP is promised to work out of the box, yet prudent implementors should really have a dedicated in house monitoring staff to ensure that false-positives are being corrected and important business transactions are not being prevented.
* RASP intentionally introduces new behaviour into a system, but this behaviour and the heuristics applied are proprietary to the vendor - a black box. Certification and validation activities for some of the systems using RASP may need to consider this additional complexity. The new behaviour becomes part of the application runtime behaviour and therefore must also be validatable.
* RASP (and in many ways WAF technologies, too) never actually correct the underlying vulnerability, instead they perform the role of a compensating control. Whilst the compensation is in place, risk from the threat of the vulnerability being exploited is indeed effectively mitigated, but a strong dependency is introduced: without the compensating control, the system becomes vulnerable immediately.
* With RASP not only are years of licence fees for the compensating control now necessary, a new risk is introduced. If the dependency is not clearly documented and service managers not continually trained on this dependency, it may simply be forgotten. You see, removing the control will lead the system to fail-open.
RASP is certainly an exciting technology with much potential ahead of it, but managers should consider the potential downsides before chasing the next new shiny thing.
Again, thanks for the article it provided me with food for thought!
Re: 6. Captain Phillips is drunk on the bridge:
Security policies are only part of the battle, as you point out. Many companies have secure coding policies that their developers never read (and some are not even aware the policy exists). Financial firms need to make sure that their finely worded policy is more than a piece of paper that sits on a shelf. There needs to be oversight and enforcement of the policy to make sure it is actually being followed.
Re: Getting seasick ...
In some of the Senate hearings on cyber security this year that was exactly what companies testified the givernment shouldn't do: set specific standards. The push was for broader guidlines.
Re: Getting seasick ...
Banks (and probably all other businesses) generally think they can set their own policieis -- hence, the pushback on Dodd Frank, and the pushback on stricter security standards. In many cases, this probalby is true, but we've also seen that there isn't a great track record of self-policing. So it behooves all banks to set very strict security standards/policies and to rigidly enforce them, because all it will take is one more high-profile card or records breach in financial services for the politicians and regulators to pile on and impose security-related regulation. It's probably inevitable.
Re: Getting seasick ...
Regulation of security for financial institutions is reminiscent of the debate on risk management and capital adequacy over the past decade. Lengthy debates ultimately gave way to a mix of increased regulation for all, together with significantly more sophisticated methodologies being adopted by the leading international players.
The collapse of Lehman and financial meltdown in 2008 has led to significantly increased and more specific regulatory requirements. A serious cyber security breach at a major financial institution would probably have a similar effect.
The collapse of Lehman and financial meltdown in 2008 has led to significantly increased and more specific regulatory requirements. A serious cyber security breach at a major financial institution would probably have a similar effect.
Re: RASP is the new WAF
Thanks Richard for the detailed reply. A few comments in return:
1 - RASP is a new security mitigation technology. As it is non-correlated with other cyber defenses it will inevitably increase the overall security effectiveness of your portfolio.
2 – Running an application in a secure virtual container creates a new option for the administrator. If you have a choice between running your app in a secure or non-secure container which should you choose?
3 – It is true that running apps in secure containers remediate security vulnerabilities without fixing the underlying code. This is highly beneficial in a number of scenarios. For example the remediation is done immediately whereas the code fixing and go live cycle in a major institution takes 3 months or more. Even if the code is going to be fixed, it makes sense to use the run time protection in the interim, until such time as the amended code can be put into production. Secondly it will protect against security weaknesses in the code that have not yet been identified. Thirdly it can defeat unknown zero day exploits.
4 – The comments regarding the necessity to continue to run the app in the secure container is well taken. As the IT world increasingly moves around application workloads in virtual and cloud environments, the fact the application is in a secure container may be a significant advantage. Where security is based on physical defenses, such as WAF, these physical defenses cannot move with a virtual application across the virtual infrastructure or cloud.
5 – Despite the comment that SQLi and XSS are trivial to fix, the unfortunate reality is that these two exploits still account for the vast majority of cyber security breaches as evidenced by OWASP and other leading reports.
1 - RASP is a new security mitigation technology. As it is non-correlated with other cyber defenses it will inevitably increase the overall security effectiveness of your portfolio.
2 – Running an application in a secure virtual container creates a new option for the administrator. If you have a choice between running your app in a secure or non-secure container which should you choose?
3 – It is true that running apps in secure containers remediate security vulnerabilities without fixing the underlying code. This is highly beneficial in a number of scenarios. For example the remediation is done immediately whereas the code fixing and go live cycle in a major institution takes 3 months or more. Even if the code is going to be fixed, it makes sense to use the run time protection in the interim, until such time as the amended code can be put into production. Secondly it will protect against security weaknesses in the code that have not yet been identified. Thirdly it can defeat unknown zero day exploits.
4 – The comments regarding the necessity to continue to run the app in the secure container is well taken. As the IT world increasingly moves around application workloads in virtual and cloud environments, the fact the application is in a secure container may be a significant advantage. Where security is based on physical defenses, such as WAF, these physical defenses cannot move with a virtual application across the virtual infrastructure or cloud.
5 – Despite the comment that SQLi and XSS are trivial to fix, the unfortunate reality is that these two exploits still account for the vast majority of cyber security breaches as evidenced by OWASP and other leading reports.
Re: Getting seasick ...
Yes, a breach could prompt a plethora of well meaning, but not so useful, regulations aimed at making the industry safer. Some of the regulations will be useful, while others will simply create more work.
Hopefully security procedures and safeguards can stay a step ahead of the hackers.
Hopefully security procedures and safeguards can stay a step ahead of the hackers.
Re: Getting seasick ...
I agree. It's almost for sure going to happen one way or another. Banks can lead or follow here.
Re: Getting seasick ...
Thanks for your replies to the comments Brian. It would be very scary to see that a breach of that magnitude against a bank. It would certainly send the message to the public that their money isn't safe at the bank, which could have dire consequences, as Lehman did. At that point further regulations would be needed just to restore trust in the industry, even if the regulations themselves weren't very effective.
Archived Audio Interviews
Join Bank Systems & Technology Associate Editor Bryan Yurcan, and guests Karen Massey and Jerry Silva from IDC Financial Insights, for a conversation about the firm's 11th annual FinTech rankings.
Tweet This
User Rank: Author
8/20/2014 | 2:58:15 PM