AppSec: RASP is Dead in the Water



Runtime Application Self Protection (RASP) is a term coined in a 2012 Gartner article titled “Runtime Application Self-Protection: A Must-Have, Emerging Security Technology“. Joe Feiman has been reviving this concept recently, as shown by his comments at a June 2014 Gartner event that RASP is a way to protect the application in an age where “The Firewall has Failed”.

Here is a rundown on what RASP is, or isn’t, and who is playing on this field.

  • HP call their offering HP Fortify Runtime and is usually offered as part of a bundle of HP security products. They initially gave the acronym RASP their own spin, calling it “runtime application security protection”. Let’s see if that lasts.
    HP are certainly upping their game in the application security world, acquiring and then shotgun marrying smaller companies before rolling them into their Fortify suite.
  • A Los Angeles company is offering a product named “Prevoty Enterprise“.
  • Waratek Ltd, from Ireland, have a product named “Waratek Application Security for Java“.

The basic premise of RASP is to provide additional security to applications. This new layer is located within “the runtime”, that is, in the same execution space as the application itself. Moreover, this new layer can be provisioned and leveraged entirely without the effort, cooperation or help of the software developers who created the application. The assumptions are clear: the developers need not be involved, and so security can indeed be added later, like icing on the cake.

Beyond simply being a new technology, RASP is positioned as providing an answer to a supposedly increasing problem in application security: the insecure network perimeter. This problem statement goes along the lines of this argument: “The network perimeter, protected by the firewall, is no longer controllable. Insider threats, and weaknesses in the supply chain, coupled with more sophisticated attacks all increasingly make the idea of a hardened network shell unworkable and ineffective. Therefore security controls need to be pulled back from the perimeter and applied to the host”. This argument may perhaps have merit, certainly i have experienced ineffective perimeter controls. But is RASP really the best, or even a suitable, control as a replacement or corrective for ineffective firewalls?

Let’s take a look at some weaknesses which I think are inherent to RASP – and to a large part also to Web Application Firewall (WAF) technologies.

* 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 behavior into a system, but this behavior 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 behavior becomes part of the application runtime behavior 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. 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.

* With RASP years of license fees for the compensating control now necessary, a new cost is introduced. From a total cost perspective, the analysis which potential implementors need to perform is a cost/benefit one. How much would it cost to license RASP technologies for the application’s entire lifetime, vs the cost of asking one of the members of the original development team to fix the weakness right away?

* RASP is per definition a “Runtime” control. What exactly this means is unclear, most authors seem to have a fuzzy idea of how to define “Runtime” in this context. In many ways, firewalls, WAFs, IDS and IPS tools are also runtime, vs design time or compile time, or deploy time controls. From looking at the products on offer however, it appears that the vendors define “Runtime” as a synonym to “Application Server”. That is, RASP technologies are hosted within the same JVM or .NET runtime environment as the application being protected. Therefore current RASP tools are limited to JAVA and .NET technologies. The absence of a runtime in PHP, Python, RUBY and other popular web frameworks precludes the use of current RASP tools.

* Does RASP introduce new vulnerabilities? It is certainly theoretically possible that RASP software contains security weaknesses in much the same way that almost all software contains weaknesses or defects. The question then becomes one of ensuring that the security tool itself does not introduce a new vulnerability not originally present in the application. Do vendor’s of RASP tools accept liability for security deficits in their products? It would surprise me greatly if they did, but I think customers would be wise to consider requesting liability guarantees from RASP vendors.

* RASP tools bypass the development team: they are introduced to fulfill user’s security requirements, but are not implemented by the developers, but by the server operators. Superficially this distinction is irrelevant, so long as the security requirement is being fulfilled. However the long term consequences can be disastrous. A world in which the development team is no longer held accountable for non-functional requirements is one in which the idea of “building security in” has been seen to fail. I don’t think we should give up on this idea yet.

On the whole, I am very skeptical of RASP. I doubt that it will provide the benefits that potential customers need. Unlike WAF technologies, i would not even consider using RASP as a temporary measure until the application’s security vulnerabilities are patched. I urge strong caution to those who are considering introducing RASP tools.


Security Risks in BYOD

Bring Your Own Device (BYOD) – to work – is a reality of the modern information worker’s workplace. In fact, for 50 Million Americans, “The Internet” is already synonymous with the usage of their mobile device.

Irrespective of whether their employer has an effective BYOD policy at their workplace, people will bring their cell phones, their ipods, their ipads and tablets with them to work, even if only to be used during the commute and left in the perimeter locker at high security facilities. These devices are almost universally network accessible. Many of them, including smartphones and 3G tablets have multiple network interfaces which can be simultaneously used.

These devices are, in essence, highly portable network routing and tunneling devices, allowing the network and perimeter security of almost every IT infrastructure to be effortlessly breached. All it takes is for the user to enable wifi / bluetooth / USB / NFC tethering on their device and access it from their corporate device. A few rules in the local routing table and the user is ready to go, a BYOD network breach. A network breach is always bad, but one which essentially allows the entire internet access to a corporate machine with only minimally configured security policies on the router has to be every network administrator’s worst nightmare.

How can organizations effectively counteract this risk?

  1. Electromagnetic shielding of sensitive buildings.
  2. Disabling users ability to create additional network interfaces or routes on their local machines
  3. User training, and effective policies and controls
  4. Monitoring of unauthorized WiFi access points
  5. Monitoring of the activation of unauthorized network interfaces on corporate machines

Have you seen this kind of compromise in your organization?


IT Infrastructure Security Weakening


, ,

The concept of information technology security hardening is hardly new. The basic idea is take a stock piece of infrastructure (machine, software, electricity generator or other utility) and make it more resistant to attack by reducing its attack surface, implementing physical or logical restrictions to its accessibility or some other process or technology to reduce the likelihood of it being maliciously compromised.

As such, security hardening is a standard tool in protecting IT assets. Security weakening, however, takes the opposite approach.

An attacker wishes to reduce the level of protection in place guarding IT assets, as a precursor to an attack. The attacker chooses an indirect approach, one designed to exhaust the targets defensive capability and deny the target the ability to prevent the ensuing attacks. Peter O’Toole pulled this off in the 60’s film “How to Steal a Million“. In order to steal a statue, he repeatedly triggers the alarms, causing what appears to be false positives for the security team. Eventually, they disable the alarms, allowing the robbery to be performed more effectively.

The general characteristics of security weakening are:

  1. Intent to disable or weaken existing security measures as a precursor to an attack
  2. Intent to hide the weakening phase, preventing identification of a larger attack strategy
  3. Intent to trick the target into intentionally remove controls in an effort to reduce operational disruption due to activation of restrictive security mechanisms

An example security weakening phase on a web application might involve:

  1. Overwhelming security staff’s ability to recognize positive attack signatures by triggering them in seemingly innocuous payloads. This weakening may be extended by security or administrator staff to encompass IDS / IPS systems.
  2. Reducing the security level of the authorization process by denying access to large numbers of legitimate users through misuse of account lockout policies. That is, applications which enforce mandatory account lockouts on a predefined number of failures can be turned on themselves if an attacker can cause a large number of users, or a small number of influential users to be repeatedly negatively affected.

These two weakening activities can be achieved relatively painlessly over a period of weeks, perhaps including an intentional peak in malicious false positive security events on the target to coincide with expected major traffic spikes. Which online retailer would risk Black Friday sales to an evidently over-zealous security policy which anyway had never been loved or accepted by any one but “those annoying security guys”.

Security weakening is relatively inexpensive and easily accomplished by an attacker and can be used in parallel to other activities such as reconnaissance. It can be difficult to detect, and even more difficult to correctly identify as part of a larger, impending security attack. Some ways organizations might be able to defend against security weakening strategies:

  1. Treat an increase in the incidence of what might appear to be false positive security control violations as suspicious. This presupposes the target’s ability to identify, evaluate and measure the rate of event notifications.
  2. Carefully evaluate any proposed weakening of a security policy in order to identify a potential hidden actor at play as part of a directed weakening effort.
  3. Include weakening strategies in your attack scenarios and exercises to see if you can actively use these strategies to remove, disable, circumvent or generally weaken your control mechanisms.

Your comments and improvements are welcome!