1

Issue 1
1 Its time for a new kind
of defense
2 The right tool for the
job
3 Stop what no one else
can even see
3 Proven technology
from an application
security leader
4 From the Gartner Files:
Runtime Application
Self-Protection: A
Must-Have, Emerging
Security Technology

HP Application Defender provides

application self-protection
Featuring Analyst Research

Its time for a new kind of defense

8 About HP Security

Today over 80% of successful security breaches

target the application layer. Security teams have
begun to shift their focus and budgets to address
this application security challenge, but limited
resources and dynamic new attacks continue to
introduce application security risks.
Application security testing is particularly effective at
prevention - ensuring that applications dont move
into production with known vulnerabilities. This is
typically done with a combination of scanning tools,
penetration testing, and software development best
practices. However, fixing 100% of the identified
vulnerabilities may not be practical even for
organizations with the most mature application
security program. Just as software inevitably moves
into production with quality and performance bugs
no matter how sound the QA process, software
also deploys with security vulnerabilities. Many
factors play a role in this time to market pressure,
organizational risk tolerance, scarce security resources
and the developers lack of focus on and knowledge
about security. New attack methods are also
constantly identified introducing new vulnerabilities
that were unimagined during development. For those
inevitable vulnerabilities in production applications,
what do you do?

Featuring research from

You can and should fix the code. But that can
take time often weeks or months. How do you
protect yourself in the meantime?
Network security is a popular choice. Tools such
as web application firewall (WAF), monitor traffic
surrounding the application to identify anomalies
and provide some protection. But they are not
equipped to identify threats that require contextual
knowledge from within the application, and may
block a legitimate operation.
You need the ability to accurately stop attacks on
production applications. You need what Gartner
calls Runtime application self-protection.
Source: HP Security

2
The right tool for the job
Defense in Depth continues to be an important strategy. Network security remains a key element, but signaturebased defenses rely on filters to look for known exploits. Filters must have an exact match. Advanced attackers
can bypass filters and inject SQL code using comments, capital letters, or encoding, among other techniques.
In fact, you can find on the internet 100 ways to bypass a web application firewall. Network security, that
monitors the OSI layers, may only see parts of a malicious query. Only within the application is the entire query
constructed into its fully executable form.
Joseph Feiman summarizes this nicely saying, WAF is capable of taking actionsbut it lacks insight into the
code. RASP can analyze the code and does it at runtime. Moreover, it is capable of taking actions based on the
analyses results. (* Runtime Application Self-Protection: A Must-Have, Emerging Security Technology Published:
24 April 2012)
You must choose the right tool for each aspect of a layered defense.
Network security tools are best suited to monitor network traffic;
Application security scanning and testing are best suited to build security into an application;
Application self-protection is best to accurately protect production applications.

Because it fills such a crucial need, Gartner expects the Runtime Application Self-Protection category to gain
increasing adoption with the prediction that By 2017, 25% of application runtime environments will have
built-in self-protection capabilities (* Runtime Application Self-Protection: A Must-Have, Emerging Security
Technology Published: 24 April 2012)
Source: HP Security

3
Stop what no one else can even see
Gartners Feiman says, Applications can be better protected when they possess self-protection
capabilities built into their runtime environments, which have full insight into application logic,
configuration, and data and event flows.
Why is context from within the application so important? To really know what SQL query is executed, you
need to see the final and complete query that is constructed within the application. Only then can it be
accurately determined if the query is legitimate or malicious. This capability is particularly necessary
to identify second-order SQL injections which are constructed in multiple steps and tend to be more
targeted to a particular victim - and therefore potentially more damaging. Also, with visibility from inside,
you can rely on the application itself to properly decode encrypted data without decrypting it on the
network, and without adding processing to do so. In addition, for remediation, your developers need to
see the final constructed query, and the applications line of code where the vulnerability occurred. This
eliminates guessing where the problem is, making remediation more efficient and improving secure
coding practices.
Source: HP Security

Proven technology from an application security leader

HP has been using runtime analysis technology for some time now; it is used in HP WebInspect and HP
ArcSight Application View. This proven technology assesses calls to common core libraries. It does not
change the applications code, nor does it require a recompile.
Source: HP Security

Protect production
applications quickly and
accurately.
1. Protection - If a
new threat arises,
unforeseen during
application testing, or if
a known vulnerability is
moved into production,
the production
application can be
immediately defended
while the code is
remediated.
2. Visibility - HP
Application Defenders
ability to see
configurations, data
and logic flows, inside
the application, allows
you to accurately
identify and defend
against threats such
as SQL injection,
XSS, data fraud and
more where network
security would only be
guessing.
3. Simplicity - A
simple three-step
deployment process
and pre-configured
rules allow you to
begin monitoring and
protecting production
applications right away.
The central cloudbased administration
portal makes it easy to
deploy and manage HP
Application Defender
throughout your
enterprise no matter
the scale.

4
From the Gartner Files:

Runtime Application Self-Protection: A Must-Have,

Emerging Security Technology
An emerging security technology enables
application self-protection, a capability built into
the application runtime environment.

Request application platform and application

security vendors to automate and simplify RASP
installation and management a critical issue
for success in RASP adoption.

Key Findings
Applications currently delegate most of
their runtime security protection to external
devices, typically to network-located firewalls
and intrusion prevention systems (IPSs) of
different kinds.
Protection capabilities of external devices
can be insufficient, because they lack insight
into application logic, configuration, and
data and event flows, which are critical for
detecting and deterring attacks with the
necessary high accuracy.
Applications can be better protected when they
possess self-protection capabilities built into
their runtime environments, which have full
insight into application logic, configuration, and
data and event flows.
Runtime application self-protection (RASP)
technology is emerging to offer these
capabilities and fulfill these demands.
Recommendations
Security professionals:
At Type A enterprises (aggressive and skillful
technology adopters), consider RASP adoption
in 2012 and 2013. At Type B and Type C
enterprises, consider RASP adoption within the
next three to five years.
Request application security vendors
especially dynamic application security
testing (DAST), static application security
testing (SAST), interactive application security
testing (IAST) and Web application firewall
(WAF) vendors to deliver RASP technology,
and make RASP an important criterion when
selecting any of these technologies.

Make sure that RASP is installed and

operational on each runtime environment that
should be protected, and tested for stability
and performance.
Use RASP, WAF or both, as they are dedicated
application protection technologies (though
with their own strengths and challenges).

What You Need to Know

Applications should not be delegating as is
done today most of their runtime protection to
external devices. Applications should be capable of
self-protection that is, have protection features
built into the application runtime environment.
These features should see all data coming in
and out of the application, all events affecting
the application, all executed instructions, and
all database access. Once RASP is deployed into
production, the application runtime environment
should be able to detect attacks and protect
applications with a high level of assurance.
Technologies that are used today for application
protection at runtime for example, IPS and
WAF are in-line network traffic and content
inspectors. They analyze traffic and/or user
sessions to and from applications, but cannot
see how that traffic is being processed within
applications. For that, their protective measures
often lack the accuracy necessary for session
termination and, therefore, are used for alerts and
log collection only.
A new type of application protection technology is
emerging RASP which resides within a to-beprotected applications runtime environment.
This research analyzes RASP essentials. For
technology details, see Runtime Application SelfProtection: Technical Capabilities.

5
Strategic Planning Assumption
By 2017, 25% of application runtime environments
will have built-in self-protection capabilities, up
from less than 1% in 2012.
Analysis
Application security technologies DAST, SAST
and IAST enable testing applications for security
vulnerabilities and providing remediation advice
how to re-engineer, reprogram and reconfigure
applications for higher security assurance.
Yet not all vulnerabilities could be detected
at programming and testing phases with high
assurance, and when the application is deployed, it
cannot itself detect attacks at runtime and protect
itself against them. At runtime, applications are
on their own or can rely on external devices,
such as WAF and IPS. These technologies can act
in real time by raising alerts, filtering attack traffic
or terminating suspected malicious user sessions.
Yet they can see only the applications traffic and
user sessions, not the applications internal logic
and data processing flows.

What Sets RASP Apart

RASP is a new technology that combines the
features of two quite different technologies IAST
and WAF a scanner and a real-time monitor, a
detection technology, and a protection technology,
one technology that analyzes application
execution and another technology that analyzes
traffic. Per security intelligence (SI), interactions
of technologies often enable the emergence of
new technologies with features impossible in the
isolated technologies and this is the case with
RASP. IAST was the next step in application security
testings evolution. Typically, IAST instruments
the application runtime environment (for example,
a Java Virtual Machine [JVM] or .NET Common
Language Runtime [CLR]), so that IAST becomes part
of it and can see logic and data flows induced by
the attack, simulated by the IAST tester.
RASP borrows from IAST instrumentation, which
gives it insight into application execution, and
RASP borrows from WAF a capability to act in
real time by terminating sessions and/or raising
alerts. Software implementations of WAF
installed as application server plug-ins existed
before, though they have not been as popular as
appliance WAFs. Yet these software WAFs were
not instrumentations of the application runtime
environment (for example, of a JVM or .NET CLR)
and, thus, could not have insight into internal
application execution logic and data flows.

RASP Techniques
RASPs detection and protection techniques are
based on the vulnerability and attack patterns
that were designed on the results of the analyses
conducted by one, some or all SAST, DAST, IAST
and WAF technologies. These technologies are the
source of the logic that RASP uses; they ensure the
accuracy of RASP. These technologies have their
specific strengths, but also weaknesses, which
RASP is able to mitigate. For example, SAST can
suspect vulnerability in a particular line of code,
yet it cannot analyze that application at runtime
to confirm exploitability. DAST does its testing
in the real execution environment, yet it cannot
see into the code to determine the segment of
the code that caused the exploit. Neither DAST
nor SAST can stop an attack. WAF is capable of
taking actions for example, session termination
to stop an attack but it lacks insight into the
code. RASP learns from all these technologies, and
balances their weaknesses with their strengths.
RASP can analyze the code and does it at runtime.
Moreover, it is capable of taking actions based
on the analyses results.
RASP is a result of the evolution of the applicationshielding market. Application shielding refers
to a set of technologies used to inject security
functionality within applications specifically, for
the detection and prevention of application-level
intrusions. One of the branches of the applicationshielding market deals primarily with antitampering, typically by instrumenting application
code with controls that can prevent inspection and
modification of the code that hackers get access
to for example, by downloading. It aims at
antipiracy and intellectual property protection. The
other market branch which gave birth to RASP
is a technology that is built into applications
runtime environments, which have full insight into
the application logic, configuration, and data and
event flows.

Use the Complete Stack of Application

Security Technologies
Emergence of RASP does not negate the necessity
for multilayered security. Applications code and
user interfaces should still be tested for security
vulnerabilities with SAST, DAST and IAST tools,
and corrected before deployment. Network access
should still be defended with firewalls and IPSs
of different kinds. Identities of those accessing
applications should still be checked with identity

6
and access management (IAM) technologies,
databases access should be controlled by
database audit and protection (DAP) and so on.
Yet applications should also become capable of
protecting themselves from runtime attacks. RASP
is a new, critical addition to this stack.
RASP borrowed from WAF a capability to act in real
time by terminating sessions and/or raising alerts.
Both WAF and RASP have their own strengths and
weaknesses (see the detailed comparison between
RASP and WAF in Runtime Application SelfProtection: Technical Capabilities).
WAF and RASP should be used for a two-layer
security defense. Together, they make it both
broad and precise:
WAF Broader than RASP, yet less precise
RASP Narrower than WAF, yet more precise
WAF can serve as an early warning system for
RASP, signaling suspected attacks, but delegate
to RASP to make the final session termination
decision. To minimize RASP overhead on the
application runtime environment, RASP can react
only to the attacks suspected by WAF. WAF can
also make its own protection decisions without
delegating them to RASP. Among them 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.
Interaction between RASP and WAF, and
correlation of their analyses, is the most desirable
way of evolution. It highlights the necessity
of a close partnership between WAF and RASP
vendors, including a situation when the same
vendors offer both RASP and WAF, and provide
their out-of-the-box interaction capabilities.
Currently, when security professionals consider the
substantial maturity of WAF technology and the
immature, emerging status of RASP, WAF could
be the primary starting point for enterprises, with
RASP as a secondary option. This prioritization
is likely to become balanced with the maturity
of RASP and the increased automation of RASP
installation into application runtime environments,
thus enabling enterprises to adopt RASP
simultaneously with WAF or ahead of WAF.

RASP Evolution Timeline

We are expecting that, by 2017, 25% of
applications will use runtime security selfprotection features an increase from practically
none today. Time is required to address the
technical complexities and safety of this new
technology implementation. However, even
more time is required to broaden the adoption
of this technology, which requires modifications
to applications runtime environments and
enterprises are always worried that such
modifications might impact the applications
functionality, stability and performance.
One of the factors contributing to RASP adoption
is that the application-shielding market is evolving
from instrumentation of applications own code to,
also, instrumentation of the application runtime
environment. This approach has lower chances to
negatively impact applications functionality than
instrumentation of the applications own code.
Cloud computing might contribute to the adoption
of RASP, as well. In many cloud environments,
cloud providers and/or cloud customers have,
more or less, full control of the application runtime
environment running the cloud application (while
they do not have such control over networks used
by the clients accessing their cloud systems).
Thus, they can establish the process of installing
and maintaining RASPs. Implementing RASP will
increase cloud providers defenses, and enable
them to address cloud prospects or 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 a 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. We
expect that, by 2017, 40% of application runtime
environments will offer integration with selfprotection capabilities as an option: They will be
equipped with already instrumented, though not
activated RASP. Activation might require a special
license and installation of a pack of detection and
protection rules.

7
Evidence
HP offers its RASP technology called HP Fortify
Real-Time Analyzer (RTA) implemented as a
programmatic extension of a Java VM debugger or
.NET CLR profiler. RTA detects and deters attacks.
It is applicable for runtime self-protection of Java
and .NET applications.
HPs RASP technology does not make changes to
the applications code an important consideration
for the applications owners, always concerned
about changes to the code, which might change the
applications logic. HPs tool uses a pack of rules
defining how and when RTA acts. RTA watches all
JVM-executed (or CLR-executed) instructions, but
starts acting when a particular security condition
is met for example, when JVM is executing a
sequence of instructions that would lead to data
retrieval from a database (to prevent a possible
SQL injection attack). Currently, RTA reacts to
approximately 25 conditions that might be exploited
by attackers. HP RTA has about 12 customers.

HP has recently introduced Application Security

Monitor (AppSM) a detection-only version of
RTA, which monitors application execution, detects
attacks, and inputs this information into the
ArcSight ESM tool for further analysis by security
information and event management (SIEM) means.
This input will serve as an additional context for
analysis. For example, SIEM could correlate it with
user identity or with global positioning of the user;
it could correlate it with different blacklists and
whitelists; or it could correlate with reputational
services. Input from RASP should be used in SIEM
with special attention, because it represents
information about confirmed attacks, thus raising
the accuracy of SIEMs contextual analyses.
HP, IBM and Quotium have IAST tools (Fortify
SecurityScope, Glassbox and Seeker, respectively)
implemented as application runtime environment
instrumentations. IAST conducts runtime analysis of
the application code, memory and data flow, based
on the instrumentation of the executed code. As
a result, with increased accuracy, IAST determines
whether vulnerability is exploitable and where in the
code it is located. Due to their design, these tools
could be evolved into RASP technologies. In addition,
or instead of reporting the results of their analysis,
they could be evolved to take protective actions.
Source: Gartner Research G00229122, J. Feiman, 19 May 2014

8
About HP Security
Today, a global threat marketplace collaborates and innovates to attack our
organizations 24/7. Its 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 HPs 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

HP Application Defender provides application self-protection published by HP Security. Editorial content supplied by HP Security is independent of Gartner analysis. All Gartner
research is used with Gartners permission, and was originally published as part of Gartners syndicated research service available to all entitled Gartner clients. 2014 Gartner,
Inc. and/or its affiliates. All rights reserved. The use of Gartner research in this publication does not indicate Gartners endorsement of HP Securitys products and/or strategies.
Reproduction or distribution of this publication in any form without Gartners 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.
Gartners 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, http://www.gartner.com/technology/about/ombudsman/omb_guide2.jsp.