Work smarter, not harder, to secure your applications Featuring Analyst Research

Transcription

1 1 Issue Seismic shift needed toward application security Critical differentiator for RASP Access to the code From the Gartner Files: Maverick* Research: Stop Protecting Your Apps; It s Time for Apps to Protect Themselves About HP Security Work smarter, not harder, to secure your applications Featuring Analyst Research Seismic shift needed toward application security If you are like every other IT professional, you worry about staying out of the news for a cyber security attack. Do you know where you are most exposed? Over 80% of attacks target applications. Joseph Feiman, analyst with Gartner, urges organizations to increase the level of spending and emphasis on application security. In the featured research, he points out the ratio of spending between perimeter security and application security is 23-to-1. HP believes this need is reinforced by findings in the latest Cyber Risk Report from HP. HP Security researchers evaluate the threat landscape annually to offer their perspective on how to minimize security risk. In the most recent HP Security Research Cyber Risk Report, researchers analyzed a sample set of security audits performed by HP Fortify on Demand on 378 mobile apps, 6,504 Web apps, and 138 Sonatype reports from 113 Open Source projects. These audits include results from static, dynamic, and manual analysis. Some conclusions identified include: Vulnerabilities are still pervasive; they found that more Web and mobile apps contained discoverable vulnerabilities. Not surprisingly remediation leads to more secure software. For those applications that are following a secure software development life cycle, applications analyzed more than once had over 68 percent of their vulnerabilities resolved. It is clear that investments in scanning and testing applications can indeed have a big impact. It is a best practice and remains highly recommended. But vulnerabilities may remain in production applications due to time-to-market pressures, lack of access to the code, or lack of resources to remediate. What do you do about the 32 percent where the vulnerabilities are not resolved? Is the traditional approach to application security via scanning and testing enough? Joseph Feiman says, Modern security fails to test and protect all apps. Therefore, apps must be capable of security self-testing, self-diagnostics and self-protection. It should be a CISO top priority. Source: HP Security Featuring research from

2 2 Critical differentiator for RASP Access to the code The method you choose for application selfprotection is important. As Joseph Feiman points out, An ideal RASP implementation would be instrumentation of the runtime engine (e.g., an application server) that leaves the application code untouched, and does not require a programmer s involvement in security issues. Some solutions use an SDK approach enabling programmers to add RASP into the source code. Others instrument binary and/or bytecode by recompiling the application for execution. These approaches are viable solutions IF you have access to the source code. However, most businesses are choosing to focus on their core capabilities and offload nonstrategic enterprise applications to third parties or cloud providers. Of the dwindling number of applications that are developed in-house, a portion of those may have lost their ties to the original source code or be too fragile to update. A major oil and gas company estimates that only 10-15% of their applications are developed in-house. For the majority of the enterprise apps, this renders useless any self-protection that requires source code modification or recompiling. When considering application self-protection solutions, choose one that can address the majority of your enterprise application regardless of whether they were written in-house or by a third party. Learn more about HP Application Defender. Source: HP Security RASP can virtually patch vulnerabilities when: 1. You lack access to the code. It s impossible to fix the code if you cannot access it. 2. Your security scan just found hundreds or even thousands of app vulnerabilities and you cannot imagine how you will fix them all. 3. Your vendor told you a patch will be ready in 3 months. What do you do in the meantime? 4. You have no idea what software vulnerabilities you have. Monitor and protect them now.

3 3 From the Gartner Files: Maverick* Research: Stop Protecting Your Apps; It s Time for Apps to Protect Themselves 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. (Maverick research deliberately exposes unconventional thinking and may not agree with Gartner s official positions.) Key Findings 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-the-perimeter 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, consumeroriented 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. Recommendations Make application self-protection a new investment priority, ahead of perimeter and infrastructure protection. Build and buy applications, systems, and IoT devices capable of self-protection. Review existing offerings and plan for adoption. Adopt application self-testing and selfdiagnostics to increase accuracy and to scale security testing of preproduction applications and security diagnostics of production applications. Staff security divisions/teams with more application security specialists, who will be installing/maintaining/tuning self-protection/ testing/diagnostics. Strategic Planning Assumption By 2020, 25% of Web and cloud applications will become self-protecting, up from less than 1% today. Analysis *Maverick Research This is Maverick research, designed to spark new, unconventional insights. Maverick research is unconstrained by our typical broad consensusformation process to deliver breakthrough, innovative and disruptive ideas from our research incubator. We are publishing a collection of more than a dozen Maverick research lines this year, all designed for maximum value and impact. We ll explore each of these lines of research to help you be ahead of the mainstream and take advantage of trends and insights that could impact your IT strategy and your organization (see Note 1 and Note 2). We universally agree that applications (and the data they access) are, by far, our most valuable assets. We heavily invest in (what we think is) their protection, but despite that, they remain pitifully defenseless. We find daily proof of that fact when we read media reports about yet another abused system and stolen data. The existing security paradigm fails to test and diagnose all applications for security vulnerabilities, and then fails again to protect those vulnerable applications: Our application security testing strategy fails because there are too many applications, application security testing skills are too scarce, testing tools are too complex, and their accuracy is not sufficient. Our application security protection strategy fails because we mistakenly believe that we invest in application protection. In reality, instead of investing in making our applications attack-

4 4 resistant, we mainly invest in infrastructure and perimeter defenses, in strengthening protection of networks, computers and passwords. In view of the failure to test and protect our applications, the only viable solution is selftesting and self-protection. Applications must test, diagnose, and protect themselves. There s an Urgent Need to Change Security Priorities There are three areas that CISOs and security managers should re-evaluate in their organizations: 1 The level of spending on application security 2 The reporting structure and the number of application security professionals in the security organization 3 The types of technologies/tools needed to protect applications going forward Gartner estimates that in 2014, enterprises will spend $9.1 billion on firewalls and intrusion prevention systems (IPSs), and $2.4 billion for secure Web gateways, for a total of $11.5 billion. At the same time, they will spend a little more than $500 million on application security, which currently almost entirely consists of security testing (static application security testing [SAST] and dynamic application security testing [DAST]), because there is no dedicated and massively available and adopted application protection technology. The ratio of spending between perimeter security and application security is 23-to-1. Considering the ineffectiveness of perimeter protection in stopping attacks, this ratio cries for a fundamental change. An allocation of $400 million on application self-protection approximately the same budget that is spent yearly on Web application firewalls will give a strong boost to higher application security assurance. We believe that this expectation will become reality by This is not to say that perimeter defense should be abandoned. However, the amount of time and money spent on it should be re-evaluated, with a strong focus on application security. The second change should be made to the personnel reporting to chief information security officer (CISOs). Security divisions/teams should be staffed with more application security specialists. Today, these groups are largely staffed with network, infrastructure and identity and access management (IAM) specialists who do not understand applications, do not know programing languages, and lack an understanding of application methodologies. It creates a gap in application security defenses. Application security specialists should make up about 20% of the security team (considering that the remaining 80% will be staffed with network, data, endpoint and IAM specialists), up from less than 5% today. New personnel should have a strong background in application development. They will be the ones installing/maintaining/ tuning self-protection/testing/diagnostics. Due to the lack of such specialists, if they cannot be hired, they should be recruited from enterprise application development/operation divisions. They can be shared assets of the application and security divisions. Finally, security organizations need to adopt new, innovative, groundbreaking technologies/tools to better protect their applications. Adoption selfprotection is quite achievable. We believe that by 2020, 25% of Web and cloud applications will become self-protecting, up from less than 1% today. The viability of that Strategic Planning Assumption is based on the fact that most applications run on just a very few application runtime engines, which should be instrumented with runtime application self-protection (RASP) features (see Note 3). We are speaking of Java and.net runtime engines: Java Virtual Machine (JVM) and.net Common Language Runtime (CLR), and a few application servers equipped with these virtual machines (such as Tomcat, JBoss and Microsoft Internet Information Services [IIS]). These virtual machines (VMs)/ servers will be distributed by RASP or VM/server vendors, and will be equipped with RASP a reasonably simple development/delivery process. There are two capabilities that should be built into any application s runtime self-protection and self-testing/self-diagnostics. Self-Protection Technologies that we use today, with the expectation that they will protect applications for example, network firewalls, IPSs and Web application firewalls (WAFs) are network traffic and content inspectors. They analyze traffic and/or user sessions to and from applications, but cannot

5 5 see how that input is being processed within applications and databases. Because of that, their protective measures lack much of the accuracy necessary for the termination of malicious sessions. The accuracy of attack detection and protection will greatly advance if applications stop delegating their entire protection to external devices, and adopt self-protection. RASP Definition and Implementations RASP is designed to protect applications by adding protection features into the application runtime environment. The process of adding new features is often called instrumentation. RASP should satisfy these criteria: Be able to protect applications by detecting and blocking attacks. Have deep visibility into application logic flow and data flow, configuration, executed instructions and data processing to accurately identify attacks. Be instrumented into the application runtime environment. This instrumentation should be noninvasive or require no/minimal invasiveness into application code. Two RASP criteria are foundational: (1) the ability to protect; and (2) deep visibility into the application. However, instrumentation into runtime and degree of invasiveness in the code might vary. An ideal RASP implementation would be instrumentation of the runtime engine (e.g., an application server) that leaves the application code untouched, and does not require a programmer s involvement in security issues. Emerging RASP solutions from vendors such as HP, Waratek and Prevoty demonstrate that type of instrumentation. Nevertheless, we expect, and have begun to see, other ways of RASP implementation: Enabling programming to the RASP tool from the source code the approach that requires a developer s involvement. Prevoty demonstrates that type of instrumentation (although Prevoty s other RASP product does instrument runtime engines and does not require programming). Not touching source code at all, but instrumenting binary and/or bytecode after programming is finished, and source code is compiled into byte or binary code that is ready for execution. Instrumentation takes place at that final preproduction stage. It hardens the application, for example, by injecting special protector byte/ binary code into the application s binary/ bytecode. This instrumentation, also called application shielding, is demonstrated by vendors such as Arxan. Using RASP With Other Security Technologies The emergence of RASP does not negate the necessity for multilayered security. Perimeter and infrastructure protection technologies, as well as RASP, have their own strengths and weaknesses. Therefore, they can, and should, be used together for a multilayer security defense. For example, a WAF can serve as an early warning system for RASP, signaling suspected attacks, but RASP would be delegated to make the final decision on session termination. To minimize RASP overhead, WAF can make its own protection decisions when it has high assurance that an attack is real. Among those decisions can be termination of access from the blacklisted IP addresses and geographic locations, or termination of access by the users who were blacklisted in fraud prevention databases. Another area of interaction is between RASP and security information and event management (SIEM). In that interaction, RASP inputs its highly accurate results of detection and protection into SIEM for correlation with input from other security technologies, such as IAM and network security. This approach has been tested by HP for its RASP and SIEM tools. Such interaction will also give RASP additional context, which might enable RASP to protect against advanced attacks, for example, where credentials have been stolen and used in the attack. Interaction between multiple layers of security and correlation of their analyses is the most desirable evolution.

6 6 Self-Protection Maturity Timeline and Adoption Drivers In terms of Gartner s Hype Cycle methodology, we estimate RASP maturity to be Emerging, and expect that it will take RASP up to 10 years to reach the Plateau of Productivity. Time is required to address the technical complexities and stability of this new technology. We address some RASP strengths and challenges in the Runtime Application Self-Protection: Technical Capabilities. We expect that cloud computing and virtualization will contribute to the adoption of RASP. Cloud providers (such as Amazon, Rackspace, salesforce. com, Microsoft Azure and Heroku) have, more or less, full control of the application runtime environment running the cloud applications. Thus, they can establish the process of installing and maintaining RASPs on their VMs/servers. Implementing RASP will increase cloud providers defenses, and enable them to address cloud users security concerns (which are one of the main obstacles to broader cloud adoption). Another driver for increased RASP adoption would be partnerships between RASP and application runtime environment vendors for example, between a RASP vendor and a JVM vendor, such as IBM or Oracle, or a.net CLR vendor, such as Microsoft. The latter will find it beneficial to work on the simplification and safety of installation, testing, and maintenance of the interfaces with RASP. Yet another driver for RASP adoption could be the penetration of the Internet of Things (IoT). Equipping IoT systems with self-protection capabilities seems to be a most viable solution, considering the fact that the IoT will function in homes, household devices (thermostats, sprinklers, etc.), where the use of perimeter protection technologies has limited applicability. Self-Testing/Diagnostics The adoption of application security testing (AST) has begun with the adoption of SAST and/or DAST tools. Soon, most enterprises have come to the realization that they lack the skills, budget and focus to be effective operators of AST tools. In response to their problems, AST vendors have begun offering AST as a service, where DAST and SAST have been conducted by AST vendors from those vendors cloud platforms. However, the use of tools and/or cloud services very often cannot address security testing of the entire (or a large part) of an organization s portfolio of apps, because testing is expensive and time-consuming. Moreover, the turnaround time between a request for a test and return of the test results often cannot meet the requirements of the agile development. The accuracy of a test by DAST and SAST also suffers from high false-positive and false-negative rates. Self-Testing Definition and Implementations The solution to these problems is in application self-testing with interactive application security testing (IAST) technology. An IAST tool consists of two parts agent and inducer. The agent resides inside the application server or application VM (such as JVM,.NET CLR, or on servers such as Apache, Tomcat and IIS). It observes the test, establishes whether it exploits vulnerabilities, and determines where in the code vulnerabilities are located. The inducer simulates attacks on an application (whose application s server is instrumented with an agent). The inducer can be implemented in several ways. In some implementations, a DAST tool is the inducer. In some other implementations, the test is initiated by a special generator of potentially malicious conditions or by a sequence of quality assurance test scenarios. The latter IAST implementation is a self-testing case. A QA test serves as an inducer for IAST. A recording of possible attack scenarios, or a generator of potentially malicious conditions (built into the IAST tool), serves as additional inducers. In that case, each application executed on the test machine automatically undergoes a security test (that is a test runs itself whenever the application runs). Examples of self-testing come from such vendors as Contrast Security and Quotium. IAST technology is also provided by such vendors as Acunetix, HP and IBM.

7 7 Self-Diagnostics A special case of self-testing is production-time self-diagnostics. If an IAST agent is installed on a production server, it can report vulnerabilities and attacks without disrupting the application (on the contrary, DAST can be disruptive when used to test production apps). In that case, an inducer is not required, because the production application s execution becomes that inducer. The same self-diagnostics can be provided by RASP, if RASP turns off its protection feature, and uses only real-time alert and log collection features. It makes sense to mention that server-side RASP and IAST have a great deal of similarity. Serverside RASP, generally speaking, is an IAST with added protection features. IAST instruments test application servers; RASP instruments a production server. IAST produces a report with vulnerabilities found at the test phase; RASP stops execution of exploits detected at the operation phase. Using Self-Testing With Other Security Testing Technologies IAST can be used along with SAST and DAST. SAST can be used earlier in the life cycle, at programming phase, while IAST can be used only when the application runs (which typically starts at test phase). IAST and DAST integration is also possible. One of the IAST implementations is when DAST serves as an inducer for an IAST agent that resides in the application server. Several vendors (e.g., IBM and HP) offer that version of IAST/DAST integration. Self-Testing Maturity Timeline and Adoption Drivers IAST is at the adolescent phase of Gartner s application security Hype Cycle. We expect that it will take more than five years for it to reach the Plateau of Productivity. Self-testing, as a use case of IAST, will mature accordingly. Note 1 Roots of the Word Maverick Derived from the name of Texas rancher Samuel Maverick and his steadfast refusal to brand his cattle, maverick connotes someone who willfully takes an independent and frequently disruptive or unorthodox stand against prevailing modes of thought and action. Note 2 New Ground Broken This research breaks new ground. It introduces a new approach to high-assured application security detection and protection based on enabling applications to test, diagnose and protect themselves.

8 8 Note 3 Sample RASP Implementations Currently, RASP for Web applications is the most developed type of RASP. We have seen its implementation by vendors such as HP (within its Fortify portfolio), Prevoty and Waratek. RASP implementation offered by HP instruments the application server. In other words, it extends the functionality by additional functionality namely, security detection and protection. For example, it can be implemented as an extension of the Java debugger interface or.net CLR profiler, or extends the functionality of Apache Tomcat or JBoss application servers. Thus, it becomes an integral part of an application runtime environment. RASP monitors the execution of an application, gets control when specified security conditions are met and takes the respective protection measures. Those conditions could be an execution of instructions that access a database (which might potentially cause an SQL injection exploit), an attempt to write an excessive volume of data into the application runtime memory (which can cause a buffer overflow exploit) and so on. Taken actions could include user session termination, application termination (without bringing down other applications on the server), an alert sent to security personnel or a warning sent to the user. A different type of server-side RASP is offered by Waratek. Its RASP technology Waratek Application Security for Java is implemented as instrumentation to JVM (and is for Java applications only). It creates a secure Java Virtual Container inside the JVM that acts like an independent, regular JVM. It provides administrators with a rule-based interface to manage and mitigate specific application security problems. Waratek rules can be configured for any kind of instruction, operation, action or event (not just for networking). It uses JVM taint-tracking to validate user input. Waratek rules can be updated live without restarting an application or shutting it down. Prevoty implements its RASP as a filter of the data input into an application. It is programmed as a Java servlet for Java applications or HTTP module for.net applications. This filter gets installed in the application s directory on the server, and analyzes the entire input into the application. The filter s logic is a programmatic expression of the attack s detection and remediation techniques, and it does not need any repository of attack signatures or patterns. Protection consists of actions such as sanitization of the content, and it does not drop connections with the application s users, whose sessions have been sanitized. This offering does not require any changes in the application code, or any developer efforts. It gets installed with prebuilt protection techniques. No customization is required, but each application can have its own custom configuration. Another Prevoty offering is based on using a software development kit (SDK), which enables programming to the Prevoty RASP tool. SDK calls are recommended for programming at the application s code location that receives data input from the outside the application, where Prevoty RASP will sanitize malicious input. The use of SDK enables detail customization of the RASP protection conditions. Currently, both Prevoty offerings protect against persisted and reflected crosssite scripting (XSS) attacks, cross-site request forgery (XSRF) attacks, and input validation exploits. Prevoty also offers protection against SQL Injection attacks from its SDK offering, with the Java and.net filters under development. Prevoty RASP is implemented as a code located in the application s server directory, or as a cloud-based product (in this case an application calls to RASP from its onpremises location). Most of the existing RASP implementations are for Web application protection, although we are watching what can become RASP for mobile from such vendors as Arxan, Bluebox Security, Lacoon Mobile Security and Prevoty. Source: Gartner Research G , Joseph Feiman, 25 September 2014

9 9 About HP Security Today, a global threat marketplace collaborates and innovates to attack our organizations 24/7. It s time to think like a bad guy. HP draws on decades of security experience to take the fight to adversaries before they attack. We can help you predict and disrupt threats, manage risk and compliance, and extend your own security team. The world relies on HP for a smarter approach to enterprise security: #1 in identifying security vulnerabilities and threats Over 10,000 customers worldwide including 9 out of 10 of the largest banks with over $9 trillion in transactions every day 8 security operations centers with over 5000 credentialed security professionals worldwide Get started Learn more about HP s approach to security. HP Enterprise Security Services can help you with your security strategy, planning, and implementation. Explore HP security and compliance software and hardware including TippingPoint, ArcSight, and Fortify. Learn more about HP Application Defender. Work smarter, not harder, to secure your applications published by HP Security. Editorial content supplied by HP Security is independent of Gartner analysis. All Gartner research is used with Gartner s permission, and was originally published as part of Gartner s syndicated research service available to all entitled Gartner clients Gartner, Inc. and/or its affiliates. All rights reserved. The use of Gartner research in this publication does not indicate Gartner s endorsement of HP Security s products and/or strategies. Reproduction or distribution of this publication in any form without Gartner s prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. The opinions expressed herein are subject to change without notice. Although Gartner research may include a discussion of related legal issues, Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner is a public company, and its shareholders may include firms and funds that have financial interests in entities covered in Gartner research. Gartner s Board of Directors may include senior managers of these firms or funds. Gartner research is produced independently by its research organization without input or influence from these firms, funds or their managers. For further information on the independence and integrity of Gartner research, see Guiding Principles on Independence and Objectivity on its website,