White Paper. Runtime Application Self Protection Making Apps Self Protecting, Self Diagnosing and Self Testing

Transcription

1 White Paper Runtime Application Self Protection April 2015

2 White Paper: Runtime Application Self Protection Making Aps Self Protecting, Self Diagnosing and Self Testing EXECUTIVE SUMMARY THE JAVA PROBLEM IS DEEP AND WIDE THE RISKS FROM THIRD-PARTY LIBRARIES CURRENT SOLUTIONS ARE NOT UP TO THE TASK LEGACY JAVA APPLICATION EXPOSURE RUNTIME APPLICATION SELF PROTECTION WARATEK, SECURING JAVA FROM THE INSIDE-OUT WARATEK APPSECURITY THE ULTIMATE IN RUNTIME PROTECTION EXAMPLE: SQL INJECTION MITIGATION EXAMPLE: STRUTS2 VULNERABILITY MITIGATION CROSS-FUNCTIONAL BENEFITS SUMMARY White Paper: Runtime Application Self Protection Page 2

3 Executive Summary Java applications in the data center or cloud are frequent targets of successful cybercriminal attacks, given their ubiquity and access to sensitive data. Solutions currently employed to counter this threat (web firewalls and application-level tools) fall short with respect to efficacy and operational efficiency, and are therefore not widely deployed. An alternative approach, which embeds security in the Java execution platform (JVM), avoids the implementation problems of current offerings, while greatly improving attack mitigation. Waratek has developed the first such solution, and sets new standards for detecting and blocking attacks against Java applications. Modern security fails to test and protect all apps. Therefore, apps must be capable of security selftesting, self-diagnostics and self-protection. It should be a CISO top priority. Gartner, Inc. Maverick* Research: Stop Protecting Your Apps; It s Time for Apps to Protect Themselves, 25th September 2014 by Joseph Feiman White Paper: Runtime Application Self Protection Page 3

4 The Java Problem is Deep and Wide The success of Java in the enterprise data center has made it a popular target for attack by cybercriminals. Java is the most heavily used application language worldwide. Perhaps half of all enterprise applications written in the last 15 years are in Java, or one of the derivative languages such as Scala or Groovy. Unfortunately the success of Java also makes it an ideal target, much in the same way that the ubiquity of Windows desktops makes Windows a choice target. In a massive critical patch update, Oracle has fixed 104 security flaws within its products. Unsurprisingly, Java is at the top of the list. Charlie Osborne for Zero Day, April 16, 2014 It is almost impossible for any large organization to totally avoid application vulnerabilities. Attackers typically try to find weaknesses in application logic to exploit. Often these take the form of exploits that leverage insecure programming to insert malicious code or extract data from backend databases, as in an SQL Injection attack. Developer training and static software analysis tools can help minimize the problem but never fully eliminate it, and offer no help against subsequent vulnerabilities arising after deployment. This is especially true in today s environment of rapid software development and frequent updates. SQL Injection attacks leverage poor input validation, and remain right at the top of the OWASP Top 10 Source: OWASP White Paper: Runtime Application Self Protection Page 4

5 The Risks from Third-Party Libraries A further area for hackers to exploit is the third-party libraries that all modern applications depend on. Developers almost always use pre-existing software libraries for commonly-needed functions (e.g. writing to a file, displaying a web page element, etc.) to avoid having to re-invent the wheel. Many of these libraries are open-sourced, meaning there s no vendor responsible for verifying the security of the library code. While using third-party libraries is a great time saver, it also means that a typical enterprise application includes many thousands of lines of software not authored internally but which may contain vulnerabilities. Source: 2014 Sonatype Open Source and Application Security Survey Perhaps the most egregious recent example of a vulnerability in a third-party library was the Heartbleed incident in early A very widely used, opensource web security library called OpenSSL was found to have a catastrophic vulnerability that allowed hackers to obtain encryption keys used for secure web communications, leaving everything from passwords to patient health records exposed to compromise. The OpenSSL library was used in countless web servers, creating a huge security hole unbeknownst to the application developers in these organizations. When one considers the huge number of applications run by major institutions, the third-party libraries included, and the frequent updates to those applications, it becomes clear that application security is an extremely challenging task indeed. Any operationally realistic solution to this problem must combine the following four attributes: White Paper: Runtime Application Self Protection Page 5

6 Accuracy High probability of detecting and defeating a security compromise Performance Little negative effect on application performance, up-time and end-user experience Ease of implementation Must not significantly change application development, deployment, and support life cycles Scale Ability to be deployed across thousands of applications with acceptable cost and operational efficiency. Current Solutions Are Not Up To the Task While there are multiple approaches to application security, none have yet come close to meeting the requirements detailed above. These solutions can generally be divided into two categories: Network-based: These offerings use network-based appliances to identify and block attacks. Web-application firewalls (WAF) and Intrusion Prevention Systems (IPS) are the two most widely-deployed options. While these products have the advantage of not drawing CPU cycles from the app servers, they suffer from the fatal flaw of not having enough application intelligence to reliably differentiate malicious activity from legitimate activity. As Gartner states Infrastructure and perimeter protection technologies inherently lack insight into application logic and configuration, event and data flow, executed instructions and data processing. Thus, they lack the necessary means to ensure accurate detection of application vulnerabilities and protection against application-level attacks 1 Furthermore, because of the fear that an app might be broken if legitimate network traffic is blocked, these devices need months of tuning before being put into production. Worse, they must be tuned very conservatively to ensure that they never block good traffic, as causing an app to fail is to be avoided at all costs. These solutions therefore fail the accuracy requirement, and are also difficult to scale. Application/server based: These software tools analyze applications to try to detect vulnerabilities. Dynamic and Static Application Security Testing (DAST and SAST) are the leading product sets, though they are not deployed widely. But as Gartner says Technologies and services that we use to test and diagnose our applications for security vulnerabilities fail to scale to test all applications and to test them with the necessary accuracy. There are too many apps, testing skills are scarce, and tools are too complex and inaccurate 1 Moreover, these are testing tools only, designed to 1 Gartner, Inc. Maverick* Research: Stop Protecting Your Apps; It s Time for Apps to Protect Themselves 25 th September 2014 by Joseph Feiman White Paper: Runtime Application Self Protection Page 6

7 provide recommendations back to development. Hence they are not capable of blocking attacks. So while they have their use as a development assistance and training tool, they are incapable of protecting deployed applications from compromise, and they also scale poorly given the impact they have on the development lifecycle. It must also be noted that Security teams tend to focus on network, perimeter, and end-point solutions, as they provide a degree of political and technical autonomy from the rest of the IT organization. While the very largest organizations have advanced application security teams and best practices, even here the core Security team tends to avoid recommending solutions within the server software stack. Unfortunately this does not put Security in a good position to deal with the sophistication of today s application layer attacks, nor does it fit with the best practice assumption that the perimeter has already been compromised. A completely new approach is needed: one that combines all four key attributes: accuracy, little to no performance and availability impact, transparency to development and software life cycle, and ability to scale. White Paper: Runtime Application Self Protection Page 7

8 Legacy Java Application Exposure Applications running on older, legacy versions of Java pose particular security and compliance challenges. Over the years, the Java platform has been updated many times, however there are thousands of production apps still in use that were written for legacy Java versions. Understandably, development teams are reluctant to allocate valuable resources to update these apps, especially given the potential risks to application stability that such activity entails. DAST and SAST tools are not applicable, as there is no appetite for modifying the app in any way. However, this situation leaves these applications exposed to vulnerabilities inherent in the legacy Java platforms. It also opens the door to audit and compliance findings, as the apps clearly are not being patched, and patching is often a high priority control objective. Java versions detected through enterprise endpoints 10% 19% Other 1% Java 3.x 5% Java 4.x 52% 13% Java 5.x Java SE 6 Java SE 7 Most applications are running on vulnerable, legacy Java Source: Bit9, 2013, Java Vulnerabilities, Write Once, Pwn Anyware White Paper: Runtime Application Self Protection Page 8

9 Runtime Application Self Protection In recognition of the lack of effective solutions for application security, Joseph Feiman, Gartner Analyst and Fellow, introduced the concept of Runtime Application Self-Protection or RASP. Feiman envisions and recommends a combination of application self-testing technology with the blocking capabilities of web application firewalls, all implemented within or tightly coupled to the application. Crucially, the solution is active during the actual runtime execution of the application, giving it the ability to analyze and act on the actions of the application itself, not its predicted behavior. Runtime Application Self Protection (RASP) is designed to protect applications by adding protection features into the application runtime environment Gartner, Inc. Maverick* Research: Stop Protecting Your Apps; It s Time for Apps to Protect Themselves, 25th September 2014 by Joseph Feiman In 2014 Joseph Feiman s report Stop Protecting Apps, It s Time For Apps To Protect Themselves was given Maverick Status by Gartner Analysts. In this report he identified that: Modern security fails to test and protect all apps. Therefore, apps must be capable of security selftesting, self-diagnostics and self-protection. It should be a CISO top priority. White Paper: Runtime Application Self Protection Page 9

10 Key Findings from this report: Infrastructure and perimeter protection technologies inherently lack insight into application logic and configuration, event and data flow, executed instructions and data processing. Thus, they lack the necessary means to ensure accurate detection of application vulnerabilities and protection against application-level attacks. Perimeter protection technologies cannot protect against behind-theperimeter insider attacks, which are as devastating as outsider attacks. Perimeter protection technologies cannot protect what ceases to exist the perimeter, which dissipates in the mobile, consumer-oriented and cloud-oriented world. Technologies and services that we use to test and diagnose our applications for security vulnerabilities fail to scale to test all applications and to test them with the necessary accuracy. There are too many apps, testing skills are scarce, and tools are too complex and inaccurate. One of the recommendations of this report is to: Make application self-protection a new investment priority, ahead of perimeter and infrastructure protection. Access the Gartner report at: White Paper: Runtime Application Self Protection Page 10

11 Waratek, Securing Java from the Inside-Out The Waratek team of Java experts has researched the issue of application security and concluded that the best place to implement runtime application self-protection is in the Java Virtual Machine (JVM). The JVM sits beneath the actual application and above the operating system or hypervisor on the data center server. The JVM can be thought of as the execution container in which Java apps run. Crucially, the JVM does much more than blindly execute application instructions. As a complete run-time execution environment, the JVM performs just in time compilation, which means that it is continuously evaluating the running program and determining exactly what the server hardware should be instructed to do to run the program. It can actually modify the application s execution behavior on the fly, and is therefore extremely powerful and flexible. The JVM sits beneath the Application and above the operating system White Paper: Runtime Application Self Protection Page 11

12 The JVM is the ideal platform for Java security for four key reasons: Because the JVM is the execution container in which Java apps run, it has complete visibility of application execution characteristics. However, no code changes to the actual application are required. Any external access to and from the Java app is actually performed by the JVM on behalf of the app, including file, network and database access. Key functions such as process forking are also performed by the JVM on behalf of the application. So the JVM can monitor all critical internal and external activity, and block unauthorized actions if needed. The JVM includes security capabilities that can be invoked to make sure that user-provided data is not used for data access without proper validation. Known as taint-tracking, the JVM tracks user input through program execution, and can restrict the use of such input when needed. For example, SQL Injection attacks succeed when the application sends mal-formed user input to the back end database without proper input validation. These types of attacks can be stopped using taint tracking, without the need for any prior knowledge or signature of the attack. The JVM can gracefully block execution of compromised code. The Java programming environment ensures that sufficient error handling exists in the app. The JVM can leverage this fact to block compromised code, and rely on the error handling routines to gracefully handle the block. This is in stark contrast with a network solution, which can do no more than terminate a network connection when it blocks traffic. Gartner recognizes the advantage of this approach, commenting Make application self-protection a new investment priority, ahead of perimeter and infrastructure protection. Gartner, Inc. Maverick* Research: Stop Protecting Your Apps; It s Time for Apps to Protect Themselves, 25th September 2014 by Joseph Feiman White Paper: Runtime Application Self Protection Page 12

13 Waratek AppSecurity The Ultimate in Runtime Protection Waratek has developed the industry s first secure Java Virtual Machine. Building upon the standard Oracle HotSpot JVM, the Waratek JVM is certified to be compatible with the Java Platform. Waratek have added a security rules engine that allows enterprises, PaaS and SaaS cloud providers to protect business critical applications without application changes. The rules engine supports fine grained monitoring and control of all key application behaviors, including file, database and network access as well as Java language facilities such as classloading, reflection or method invocation. Waratek is the first solution to leverage the power of the JVM for Runtime Application Self-Protection. Waratek can be used for application security monitoring, real-time attack mitigation, and as a developer s aid to identify vulnerable code. Four use cases are supported: Security Monitoring: Waratek can monitor a wide range of application activities that suggest compromise, and report on them in real time. These events can also be sent to a centralized security event system (SIEM/SIM) for correlation with other suspicious activity. The report data can be provided to application developers to help them identify application or 3 rd party library vulnerabilities during the development and testing phase, when they are relatively easy to address. Attack Mitigation: The Waratek rules engine can detect or block unauthorized application activity, or reject un-validated user input indicative of an SQL Injection attack. Zero Day Attack Mitigation: Default Waratek policies can in many cases defeat a Zero-Day Attack one that has never been seen and for which there is therefore no information. These best practices policies will alert or block the specific actions malware attempts to execute, with no staff intervention. In addition, since security rules can be deployed in real time without taking down the application, it is possible to add a policy to a running app to thwart the attack as soon as its behavior is understood. This allows the organization to react immediately as threat intelligence becomes available, rather than waiting for a patch to be created, validated, distributed, and applied. Legacy Java: Waratek can protect legacy applications. It is possible for a legacy Java application to be run on the Waratek platform, and Waratek will protect the application from exploits that would otherwise succeed. This is done using default policies that defeat exploitation of vulnerabilities in legacy Java versions, all without any modifications to the application itself. White Paper: Runtime Application Self Protection Page 13

14 Waratek AppSecurity traps both network attacks and unauthorized application behavior White Paper: Runtime Application Self Protection Page 14

15 Example: SQL Injection Mitigation Mitigating SQL injection attacks inside the JVM is a highly effective and efficient way to achieve protection for legacy or third party applications without necessitating complex and time-consuming application code changes. SQL Injection is consistently rated as one of the highest priority web application security risks on forums such as the OWASP Top 10 and SANS 25. Waratek efficiently mitigates SQLi attacks by adding "variable taint tracking" to untrusted data. The Waratek JVM can add meta-data to untrusted user input (coming from an HTTP query string for example) and can track the use of this data through any string manipulations through to the point at which it is used to construct an SQL request to a database. Unlike a Web Application Firewall that has to rely on an analysis of a partial SQL statement to try and identify suspicious data, Waratek sees a complete SQL statement at the point at which it is passed to a database. It can then accurately determine if user-supplied data contains functional statements that will change the meaning of a request, a sure sign of an attack. Once an SQL injection attack is identified, the JVM can then apply a mitigation action with little to no risk of false positives. Most importantly, all of this is accomplished with no application changes or significant performance impact. Diagram: Showing how Waratek can see the complete SQL statement and therefore make the correct diagnosis of an attack. White Paper: Runtime Application Self Protection Page 15

16 Example: Struts2 Vulnerability Mitigation The power of the JVM approach can best be demonstrated by considering how it can mitigate an actual attack. We will use the Struts2 vulnerability as our example. Apache Struts 2 is an open-source web application framework for developing Java web applications. Recently, a number of critical vulnerabilities have been identified in Struts2 that allow attackers to obtain complete remote access and control of an affected server. One of the more recent vulnerabilities is designated CVE (Common Vulnerabilities and Exposures the industry standard for specifying publicly known security vulnerabilities). This particular CVE has an extremely high criticality score, indicating complete compromise of an affected system. Vulnerabilities in the Struts2 library are easily defeated by Waratek using either proactive or reactive methods. Proactively, exploitation of the vulnerability can be mitigated by preventing the protected application from executing external applications on the server filesystem. Most enterprise Java applications are self contained and do not require this capability. By disabling the execution of external applications, an exploit payload cannot be executed. This best practices approach will defeat an entire class of malware with a single simple proactive rule. Struts2 exploitation can also be stopped by Waratek through a specific rule, one that prevents execution of the particular method (function) containing the vulnerability. That function also happens to be rarely used, and in fact the official patch to eliminate the Struts2 vulnerability simply deleted the method altogether. But instead of waiting for the patch, testing it and then deploying it, users of Waratek could simply write a single line rule to disable the method and immediately eliminate the risk from this attack vector. White Paper: Runtime Application Self Protection Page 16

17 Cross-Functional Benefits A significant advantage of Waratek is the range of benefits it provides to the rest of the IT organization. All security and compliance solutions must balance protection with operational considerations. A product or control activity is useless if it has a major detrimental effect on application availability or operational efficiency. But with Waratek, not only are the side effects minimal, but the server and applications development and operations teams actually gain significant advantages, especially when compared to alternative strategies for Java security: Vulnerability Visibility Waratek provides detailed and specific information on vulnerabilities in software and libraries. This decreases dependency on code reviews and static analysis to locate flaws; Process Efficiency There is no disruption to the existing software development and deployment lifecycle. This makes it easy to adopt the solution with minimum disruption; Availability No software agents on production hosts need be deployed and managed; Performance Using the JVM layer provides for efficient placement of security function with sufficient application visibility; Density Waratek can optionally run multiple Java apps on a single host operating system instance, greatly increasing application density. Virtual Patching The JVM approach allows applications to be virtually patched. That is, the application is protected from exploitation of a vulnerability via a rule inserted at the JVM layer, rather than an actual patch being applied to the app. This not only allows faster response to threats, but it also relieves the application teams from having to deal with constant patches and upgrades to critical software components. Patch testing and application can be scheduled with greater flexibility while still maintaining rapid response to vulnerabilities. White Paper: Runtime Application Self Protection Page 17

18 Summary Every week seems to bring news of yet another breach or compromise of confidential data from a major company or organization. This is not surprising considering the vast amount of internally-developed and third-party code in the typical enterprise, much of it in Java. Clearly current solutions are not sufficient, as they either require application modifications, or act at the network level, with too little knowledge of the application logic. This situation has led to the emergence of a new category of solutions known as real-time application selfprotection, or RASP. As the first RASP offering based on the Java Virtual Machine, Waratek shows great promise in detecting and blocking application level attacks that current approaches continue to miss. About Waratek: Waratek makes Java enterprise applications more secure and easier to manage. Waratek AppSecurity for Java and Waratek Locker provide transparent, runtime application self-protection against business logic and network layer threats in datacenter and cloud environments, respectively. Waratek CloudVM enables multiple Java apps to be deployed on a single server for dramatically reduced operating costs. Waratek was voted Top Security Innovator 2015 at RSAC Innovation Sandbox and Computer Technology Review Most Valuable Security Product. The company is headquartered in Dublin, Ireland with offices in London, New York, Sydney, Tokyo, Shanghai, Taipei and Seoul. For further information please visit Waratek Head Office: Waratek UK Ltd: Waratek New York: Level 3, 8 Harcourt Street, Dublin, 2, Ireland Longcroft House, 2/8 Victoria Avenue, London EC2M 4NS 45 Rockefeller Plaza, New York, 10111, USA info@waratek.com White Paper: Runtime Application Self Protection Page Waratek Limited All rights reserved