The porter sits at the company gate and monitors people entering and leaving the company premises. But how is he supposed to know that a burglar is standing in the CEO's office and welding open the safe? The situation is similar with traditional firewalls: although they monitor incoming and outgoing data traffic, they cannot gain any insight into the inner workings of systems - an information deficit that makes it difficult to defend against attacks.

If the firewall is a gatekeeper, then Runtime Application Self-Protection (RASP) is something like plant security. The latter patrols the site and knows every corner of the important buildings. RASP works in a similar way: systems are not only defended at the perimeter, but also protected at the application level. This makes it easier to detect and report attacks.

RASP as digital plant protection offers the next generation of web application protection. It can also secure the chain of evidence in the event of attacks much more precisely than previous web application security mechanisms.

© iStock_Portra

Especially in the age of Industry 4.0, such an additional 'protective shield' for industrial applications is becoming increasingly important. This is because companies are creating ever more closely meshed digital networks and highly complex software controls and coordinates machines and production systems, with administration often taking place via web applications and backend systems. The challenges here: firstly, fault tolerance in increasingly complex environments is anything but high. If one cog fails, the entire system is often down. Secondly, there is a threat from an area that was not even considered in the analog age: Cyber criminals are increasingly threatening the infrastructure of industrial companies. They steal data, spy on company secrets and hijack machines to blackmail companies. If a system is under their control, they can cause millions in damage. Web applications and higher-level systems that are used to administer or automate operational processes are particularly at risk.

To make matters worse, industrial systems are generally not designed by IT experts, but by plant and mechanical engineers in accordance with their purpose. Aspects of cyber security are therefore rarely taken into account during development. To avoid costly interruptions to operations, security updates are also only possible during planned downtimes. Consequently, the self-protection of applications is rarely sufficient to ensure an adequate level of security. Companies must therefore establish mechanisms such as RASP to take over this task.

How does RASP work?

The flowchart shows how the direct integration of RASP into the application uses the request and response history to validate the data and protect the application from malicious attacks.

© Veracode

To understand how RASP works, let's use the comparison with a gatekeeper: Conventional firewalls act like a gatekeeper - they control incoming and outgoing data traffic. Intrusion detection systems (IDS) and intrusion prevention systems (IPS) can detect and prevent attacks on the system, but only on the basis of information filtered out of the data traffic. This is often not enough to make an unambiguous judgment. The devil is in the detail: even a single smuggled-in function character can be enough to let an SQL query get out of hand. Breaking into a system is then child's play.

RASP provides better protection by monitoring the entire functionality of applications. In other words, it builds a protective wall and takes a look into the inner workings of the applications themselves. SQL injection as a classic attack scenario provides an illustrative example: IDS/IPS systems and web application firewalls at best check user input for suspicious character strings in an attempt to identify attack patterns. RASP, on the other hand, not only evaluates user input, but is also aware of the processes at application level: What does the query resulting from the input look like? What result does the database deliver? What manipulations are carried out and what potentially critical data is output to the user? The answers to these questions are taken into account when RASP attempts to differentiate between SQL injections and legitimate database access.

The integration of RASP into existing systems and software is extremely simple. Developers can leave the program code of their applications untouched - a one-line change in the server settings is sufficient. For Java applications, for example, a JAR file must be specified in the Tomcat configuration, which is then executed together with the application. Each agent running on a server is configured centrally via the console. This step can take place during the development of an application, but also when it is already in use. In an emergency, RASP takes control and takes measures that a user has previously defined for the respective attack scenario.

On the one hand, RASP can block the request by terminating either the user session or the application itself. On the other hand, it is possible to filter user input, allow queries to run empty or prevent the execution of problematic JavaScript (XSS). As RASP can directly inspect the program flow, it is less dependent on pattern-based checks. There is therefore no need to regularly update pattern lists. RASP can do without constant updates, as is the case with antivirus software, for example.

Powerful but not omnipotent!

RASP is therefore a powerful tool, but it should not be misunderstood as omnipotent. The technology is currently in the early adopter stage and is only available for Java Virtual Machine. Additional implementations are not expected until the next few years. In the past, RASP has also been objected to on the grounds that it removes responsibility from developers to a certain extent. The underlying dilemma has been known since the early days of IT security: Back then, the collective decision was made to draw high walls around systems and defend the perimeter. A pragmatic decision, but one that condemned us to work with insecure applications. After all, why secure my code if the firewall protects me? In reality, however, this neglect of duty is not the fault of the technology, but of the staff. In short: RASP does not provide excuses for developers, but additional protection at application level - i.e. exactly where it is needed. Third-party products and legacy software can also be secured more reliably in this way.

The more important cloud computing and mobile connectivity become, the more the boundaries between systems become blurred. Especially when deploying software on mobile devices, it should not be automatically assumed that the operating system will fulfill the protection function. Companies that embrace concepts such as Bring-Your-Own-Device (BYOD) or Corporate Owned Personally Enabled (COPE) are gaining flexibility, but are also developing a new need for security. A key strength of RASP is that it provides protection even when a device does not or cannot provide it itself.

Although providers of security solutions have now recognized the potential of RASP, only a few companies have so far adopted the new technology. Industry analysts at Gartner, for example, estimate that only 1% of all web applications are protected by RASP today. It therefore remains to be seen whether this technology will be as much a natural part of security concepts in a few years' time as the classic firewall is today.

Author:
Julian Totzek-Hallhuber is Solution Architect at Veracode.