FOCUS

on reducing risk by leveraging security

IP from the security experts HP Fortify.

Business white paper

Who should read this paper?

Read this paper if you participate in a

security-sensitive market, are involved
in product development, product management, or product security for an
independent software vendor, or if
you are a platform-as-a-service (PaaS)
provider, and if youre interested in

itigating security risks that exist in

m
your solutions. This paper describes
specific steps you can take to reduce
the costs of product development,
increase product and customer security, expand functionality, and enter
new markets quickly.

Table of contents
Executive summary
Consequences of a security lapse
Security is essential to good software design.
Vulnerabilities of network-based defences
Prioritising remediation efforts
Fixing vulnerabilities
HP Fortify Real-Time Analyzer
Protections are defined by rules.
Event handlers define response to events.
Advantages of HP RTA
Deployment
Conclusion

3
3
4
4
5
5
5
6
6
6
7
8

Developed with input from the U.S. Air Force, and used by
companies of all sizes and in nearly every industry, Fortify
RTA is the most accurate, most automated, and most
complete solution for protecting applications at runtime.

Executive summary
HP Fortify Real-Time Analyzer (RTA) protects applications
from losing private data, leaking valuable information,
and being exposed by fraud. Unlike other technologies,
such as intrusion prevention systems (IPSs) and application
firewall appliances, Fortify RTA works inside the application. This unique approach has numerous benefits.
Its easy to get up and running, it protects every entry
point (not just HTTP); it doesnt require re-programming
when the application is updated; it has minimal effect
on performance; and it has access to the business logic
and key program data of the application, making it
extremely accurate. In addition, Fortify RTA allows a
user to quickly instil company-specific rules into any
application in order to combat fraud and other logicbased threats. Developers can easily embed security
into their applications or bundle it as a separate standalone application.

Consequences of
a security lapse
Direct hacking attempts. Fraud. Data mining. Suspicious
users. The sophistication and frequency of attacks on
your software applications and the operating systems
and programs that millions of people use every day are
increasing at an alarming rate.
Attackers take advantage of security vulnerabilities in
your software solutions to steal crucial data, such as
identities, passwords, and account information, and
sabotage computer systems or inuence processing
or functionality for prot or nefarious intent. The con
sequences are severe. The cost of recovering from even
a single data breach now averages US$6.3 million.
The Ponemon Institute, which conducted a study for
Symantec, found that the average data breach in 2010
cost US$7.2 million organisation-wide. Thats up from
2009, when a data breach cost US$6.8 million an

increase of 7 per cent.2 Seasoned attackers are also

adept at quickly converting stolen information into cash
by way of online auction-style black market websites
that cater to cyber criminals.
Despite advances in rewalls, anti-virus systems, and
other perimeter-protection solutions, attacks against
independent software vendor (ISV) applications continue to increase. Government regulations mandate
protections for certain industry sectors, while the
Payment Card Industry (PCI) Data Security Standards
(DSS) require organisations that process credit card
transactions to implement specic application security
activities. The Online Web Application Security
Consortium (OWASC) recently reported that 99 per
cent of all applications are not PCI DSS compliant.3
Additionally, in many cases the lack of integrated or
bundled security for applications has resulted in economic loss as deals become delayed or even lost until
proper security is present. Although security aws in
widely adopted operating systems grab all the headlines, much time and expense go into nding these
holes and providing solutions. The more serious danger
lies in those applications that are not on everyones
radar the thousands of customised applications and
automation software that you and your partners create
and depend on to keep business running smoothly. To
complicate matters, the type of software that is most
susceptible to attack applications that rely on Web
2.0, service-oriented architecture (SOA), and opensource development represents the fastest growing
application segment because of its low cost, exibility,
short development cycles, and ease of use. While
new technologies make more application functionality
available to a far wider range of users, their wide
adoption in less-controlled circumstances creates
enormous opportunities for exploitation.
Ponemon Institute Study, 2010 Annual Study: U.S. Cost of a Data Breach.

http://www.glooblog.com/why-a-security-audit-is-good-for-your-businessand-your-sleep-part-2/

Delivering secure software:

Clearly identify the security risk profile of your applications as it relates to the markets and target customers for your solutions: If your target
customer base uses your solution for mission-critical data, for information security, or in a regulated industry, the direct results of a negative
security analysis test or even worse, a breach, could create a significant negative impact to your business.
Integrate secure development best practices at every stage in your development lifecycle.
Generate ongoing awareness of how your software is used and the changing threat profiles to which your application(s) are subject.
Balance the resources needed to secure your application(s) with the risk analysis that you have performed, including all direct as well as indirect
potential impacts (brand image, goodwill, etc.) to your business as a result of a negative security analysis test or breach.

Security is essential to
good software design.
To be the most effective and to provide the greatest
value, application security should be developed in conjunction with your software solutions. Ideally, security
is inseparable from product quality requirements and
your organisation has the policy that nothing is released
to production until minimum security standards are met.
Unfortunately, this security-aware approach is rare.
Few enterprises have the resources or processes necessary to ensure that security is given the status it deserves
in the secure not software development life cycle.
ISVs must overcome numerous challenges to create
this level of security. Foremost among these are: identifying as many potential vulnerabilities as feasible before
launching the software; prioritising development efforts
to determine which vulnerabilities pose the greatest risks;
and xing post-release security aws rapidly and costeffectively with minimal impact on business productivity.

Vulnerabilities of
network-based defences
Much time, effort, and cost have gone into network
hardening solutions designed to prevent attacks
against applications. However, very little attention has
been paid to actually hardening the applications these
measures are designed to protect. Cyber criminals know
this and are taking advantage. For example, while
spending on perimeter-only strategies continues to grow,
reported application breaches are still the number one
cause of all attacks. Its easy to understand why: To
compromise a piece of software, an attacker merely
needs to nd a single route past network defenses
for example, by gaining access to a Web-based
application through an open Web portal or by luring
unsuspecting users through content spoong. A far
more effective approach to prevent attacks entails closing the security gaps that exist within the applications
themselves. Once applications become impervious to
attack, they cannot be compromised, even after a network breach. This is true for network-based defences
in highly virtualised environments as well. Virtualised
instances of Web applications need security checking
just as much as physical ones.

One of the core tenets of information security best

practices is the concept of defence in depth. The
power of this concept comes in the awareness that no
single layer of security, whether a firewall, an IDS/IPS,
or user authentication, will ever be sufficient in and of
itself to block all significant attacks, especially those
instigated by a determined attacker. As such, even if
your end customers have firewalls, IDS/IPS solutions,
and other security measures in place, those solutions
do not provide all of the protection necessary for your
customers: internal application security becomes necessary to provide stability for your application in the field.
In order to resolve security aws in applications,
organisations must be able to identify the broadest
possible array of potentially exploitable vulnerabilities.
There are two p
rimary methods to accomplish this:
static analysis and dynamic analysis.
Static analysis. This is the most widely used technique
for detecting vulnerabilities. It involves applying automated tools to analyse an applications source code.
Automated static analysers can locate more types of
vulnerabilities than any other method. Indeed, the
sheer number of vulnerabilities they identify can be
difficult for IT staffs to handle effectively.
Dynamic analysis. Some categories of v ulnerabilities
become manifest only while code is being executed,
such as those involving an applications conguration
and environment. Automated dynamic analysis tools
are used to locate these vulnerabilities during runtime,
for example, during testing. Indeed, dynamic analysis
that can be applied in tandem with an organisations
existing testing protocols is particularly effective.
However, it is important to note that dynamic analysis can examine only those portions of code that are
being executed; it cannot nd vulnerabilities in areas
of the system that are not running. As a consequence,
the results from dynamic analysis reect only the
amount of code that has been covered. This carries
important implications for testing.

ISV organisations that are under constant pressure to

meet release dates tend to concentrate only on the
most important bits of application code the high
trafc areas, leaving less critical aspects to be dealt
with after deployment. Knowing this, insidious attackers seek out remote areas of a system that are often
not well used, because they have received less scrutiny during the development and testing phases and
therefore have a higher probability of containing
vulnerabilities. To stay ahead of attackers, software
development teams should employ dynamic analysis,
not only during testing, but also throughout development and after deployment. Dynamic analysis applied
to real-world deployments can identify potentially
exploitable vulnerabilities in low trafc areas of
code the ripe targets for attack and make remediation before any damage can occur.

Prioritising remediation
efforts
Protecting security is critical for any software development organisation; but you cant let it come at the
expense of lost productivity and business delays. Most
ISVs are under constant pressure to create more unique
features every release cycle in a hyper-competitive
environment that has little forgiveness for functionality
bugs, let alone security vulnerabilities. As development
teams have additional mission-critical priorities, they
typically can allocate just a certain amount of time to
x security issues. At the same time, the sheer numbers
of vulnerabilities that static and dynamic analysis can
uncover can be staggering. Its estimated that their
density can range from hundreds to tens of thousands
of vulnerabilities per million lines of code, depending
on technology and programming practices. With such
a daunting number of potential vulnerabilities and
limited time and resources, prioritisation becomes
essential. Not all vulnerabilities are equal; some are
extremely critical, others become more important in the
presence of other security aws, while still others present
no exploitable threat at all. Determining which ones
need to be addressed in what order can only be done
effectively through prioritisation, a key capability that
many of todays automation tools lack. Once vulner
abilities are discovered the common requirement is to
remediate, taking many weeks and months to fix core
issues in the code.

Fixing vulnerabilities
For ISVs, development groups are usually the respon
sible parties for determining and evaluating each
applications risk profile, identifying real threats and
assuring that exploitable vulnerabilities are repaired.
Unfortunately, developers are also the ones tasked
with actually xing any discovered security issues all
the while continuing to implement features and standard
bug fixes at a breakneck pace. The consequences of
even a single serious vulnerability can be devastating.
When it comes to closing security gaps in software,
time is of the essence. To deal rapidly and effectively
with evolving application security threats, security and
development personnel must work together collaboratively and in close partnership. Automation is critical
to maximising the effectiveness of both parties and
shortening response times required to remedy urgent
vulnerabilities.

HP Fortify Real-Time
Analyzer
HP Fortify Real-Time Analyzer (RTA) is a software solution that works inside an application to actively protect
against directed attacks, fraud, data mining, and other
potential threats posed against an application and the
data behind it. Fortify RTA automatically identifies
every critical application programming interface (API)
inside the application and actively monitors these locations. When the application runs, Fortify RTA can
respond to attacks in a variety of ways, including
blocking the user entirely, posing a challenge response
question, alerting a key administrator, or performing
more sophisticated actions, such as communicating
with a router to delay the users requests.
Fortify RTA protects programs running under a supported
Java virtual machine (JVM) or .NET common language
runtime (CLR). The program can be a Web application
container or any other Java or .NET program.
RTA defends against evolving logic-based attacks,
including fraud, hacking, and data mining that can
threaten applications once theyve been deployed.
Uniquely positioned inside an application, RTA provides a real-time view into how a deployed application
is being attacked in the real world. At any point in
time, IT personnel can see who is attacking (based on
IP address and domain name), how the attack is being
conducted, and what part of the application is being
attacked, down to the exact line of code.

Key benefits:
Provides true application-layer insight and can make
use of application logic to make decisions
Provides results in real time, including email alerts
Accurately distinguishes between an actual attack
and a legitimate request, improving the end-user
experience while greatly boosting protection
Can accommodate additional logic- and behaviouralbased rules that address specific threats for individual
Web applications

The Fortify RTA solution will:

Monitor applications and provide data on actual attacks, probes, or anomalous behaviour, such as: who is attacking,
how each attack is attempted down to the line of exposed code, and the timing of the attack.
Protect deployed applications from the most prevalent Web hacking techniques, such as SQL injection, cross-site
scripting, and cross-site request forgery.
Allow for customised responses to different attacks. A user can customise Fortify RTA to respond with a challenge
response question, as opposed to just allowing or blocking a request.
Enable organisations to create more advanced protections, such as anomaly detection for fraud prevention and
customised actions based on the threats each company faces.

Protections are defined

by rules.
Fortify RTA protections are defined by rules. A Rulepack
serves as a container for one or more rules. Fortify
supplies an RTA Rulepack for protecting against common
types of attacks. You can also create your own custom
Rulepacks. A single rule specifies one or more program
points that declare where to monitor a target program
and one or more monitors that define what to watch
for at a given program point. When a monitor detects
the specified behaviour in the target program, it creates
an event.

Event handlers define

response to events.
An event is a collection of attributes. Attributes provide
information such as a category of problem that has
been detected and the location in the code where the
problem was detected. Fortify RTA evaluates the ongoing stream of events with a set of event handlers. An
event handler matches against event attributes and
specifies the way Fortify RTA should respond. A response
might include a passive activity such as logging the
event or sending out a syslog notification, or it might
include an action: a change to the state of the target
program. An action could throw an exception or display
a special error message to the user.
Event handlers are organised in an event handler chain.
By default, Fortify RTA stops evaluating the event handler chain after it finds the first matching event handler.
The event handler chain enables the security designer to
organise event handlers into a sequence that provides
the optimal action to take to protect the target program.
HP Fortify RTA has two modes of operation: Standalone
Mode and Federated Mode. In standalone mode Fortify
RTA reads its configuration (including rules, event handlers, and other settings) from disk. In Federated Mode
multiple computers running Fortify RTA work in concert.
They use the network to share a common source of configuration information and common event repository.

In Federated mode, an instance of Fortify RTA:

Operates as a Host member of a Fortify RTA
Federation
Receives its configuration from a Federation Controller
Transmits security events to its Federation Controller
After a Fortify RTA Host receives a configuration from
its Federation Controller, the Host caches the configuration. The Host uses that cached configuration until
the Federation Controller sends a new configuration.
The Host preserves the most recent cached configuration across program restart. This enables a Fortify RTA
Host running in Federated Mode to resume operation
without waiting for the Federation Controller to re-send
the Hosts configuration.

Advantages of HP RTA
Ease of installation and management
Typical IPSs and application firewalls require fitting a
hardware device into your environment and then conducting at least two weeks of extensive testing where
the device tries to model good behaviour. If the application is ever updated, the device often requires more
testing and modelling. Fortify RTA is easy to install
and maintain. Rather than taking days and weeks,
Fortify RTA can be set up in minutes. In addition, when
the application is modified, Fortify RTA dynamically
reconfigures it the next time the application is run,
meaning no additional work is needed. RTA may be
distributed in an embedded form, inside your software,
completely invisible to the end user. Another option is
to deploy RTA as an add-on option bundled with your
applications upon customer demand.

Accuracy
Because the protections run inside the deployed application, they can make very accurate assessments of
whether or not data entering a function is a threat.
Solutions that operate outside the application can
never have precise context of the application and the
semantic interpretation of the data.

Consider the following example. From a software security perspective, a string containing an apostrophe can
be either benign or decidedly lethal. For instance, an
apostrophe entered in an input field by a probing bot
has the theoretical potential to manipulate a SQL query
command. Chances are this input in any particular
field will never reach a SQL query. However, if that
malicious string were to find its way to a SQL query
command, only then would private data be at risk.
If you are sitting outside an application, watching data
go by, you would be hard pressed to determine whether
that command will actually reach the SQL function.
Your only choice is to collect enough bits to recognise
it, and then make a binary decision as to whether to
block that string or not. This both induces delays and
results in a high false positive rate. On the other hand,
if you were sitting right at the SQL command, you
would know immediately, and, with precision, whether
the string was harmful. You could make virtually 100
per cent-accurate decisions as to whether the string
should be blocked. With this approach, you do not
induce a noticeable delay, and you have an extremely
low false positive rate. Think of this capability as a
function-level firewall: keeping bad things out, right at
the point where you can best judge whether or not
theyre malicious.

Defence in depth
Fortify RTA protects all entry points into the application,
not just HTTP. This means that HP Fortify RTA can protect against attacks coming from internal sources, such
as Web services and network sockets.

Logical-based protections for fraud

and other malicious behaviour
Traditionally, if an organisation wants to instil fraud
protection into its application, it needs to go back to
development and rewrite the application. Fortify RTA
offers the ability to quickly and easily deploy fraud
and custom protections to an application.

Enables potential new services

In addition to providing proactive protection against
known and unknown security attacks, the HP RTA
solution also tracks attacks in progress, in real time,
providing substantial real-time application security attack
awareness and threat profile visibility. Your customers
can feed information from HP RTA into their existing
security analysis tool, such as HP ArcSight or Attachmate
(NetIQ) Security Manager. This reporting and awareness provide you the ability to create additional add-on
services; satisfying customer needs while providing
your organisation with a new top-line revenue stream.

Low overhead
Since Fortify RTA is in the code, and is being invoked
only when an attack or suspicious behaviour comes
through, it has a minimal effect on performance.

Deployment
Fortify RTA can be used in a number of ways, and
rolled out incrementally, in the same way you deploy
any other new application into your server farm.
Because Fortify RTA runs inside the protected application, you need not reconfigure the application server or
operating system. Nothing changes in the deployment
environment. In addition, you need no extra hardware
boxes to sit on the network in front of the application.
Some users prefer to deploy Fortify RTA in monitor
mode initially, using its advanced capabilities to capture
security events in real time and providing insightful
management security reports. This information provides
unique visibility into the specific security events to which
the application is being subjected. This is useful in two
ways. In staging, application behaviour can be monitored during testing. In deployment, real-life data is
available so that you can anticipate security-related
activities and assess risk.
Other users prefer to deploy Fortify RTA in protect
mode. In this mode, active counter measures are
activated when security events occur. These counter
measures are defined by either out-of-the-box rules or
by custom rules written to provide customised responses
to security events.
Fortify RTA can be applied to every instance of an
application or to just a subset of them. It can be used
in monitor or in protect mode selectively for each
instance. Both J2EE and ASP.NET applications can be
monitored by a single Fortify RTA 360 Server. This provides unparalleled flexibility in process and deployment.

Compliance requirements
Compliance concerns are increasingly relevant to IT
and ISVs. Emerging standards, such as the Payment
Card Industry Data Security Standards, are putting a
lot of pressure on businesses and ISVs to take responsibility for security vulnerabilities. Unfortunately, one of
the most difficult challenges in remaining compliant is
keeping Web applications secure from both hackers
and malicious insiders. Thats a tall order. Few organisations have the resources to remediate application
security concerns quickly and comprehensively.
Fortify RTA offers a broad set of capabilities that
address compliance requirements.

OWASP Top Ten

In addition to supplying free and open availability of
an extensive classification of software security errors to
the Open Web Application Security Project (OWASP)
organisation (www.owasp.org), Fortify RTA automates
securing Web applications from vulnerabilities identified
in the OWASP Top Ten (www.owasp.org/index.php/
OWASPTopTenProject). These protections alone make
Fortify RTA well worth considering for any application
that has the chance of being vulnerable to these flaws.

Real-world example

The HP Fortify RTA solution has found significant success with ISVs already.
Problem:

Solution:

Benefits:

Military customer needed certificate

of net worthiness in order to bid on
a large contract.

HP Fortify RTA was quickly loaded into

the application.

Application security and compliance are

built into the software.

Military needed to scan the application

being considered.

Integration was complete within two weeks.

Implementation is fast.

Military rescanned application.

Win more business.

Application had 700 known vulnerabilities.

Approximate remediation time was eight
to 12 months.

Application vendor passed net worthiness

and won the contract.

Payment Card Industry Data Security

Standards (PCI DSS)
Although PCI DSS covers the full security spectrum,
the majority of exploits today are occurring at the
application layer. This is a difficult area of the PCI DSS
specification and is one that requires both a specialised
skill set and the very latest technology to assess and
remediate.
Two demanding sections of the PCI DSS standard that
are specifically addressed include:
Requirement 3: Protect stored cardholder data
Requirement 6: Develop and maintain secure systems
and applications

Health Insurance Portability and

Accountability Act (HIPAA)
Virtually every U.S. citizen is affected by how well
applications meet HIPAA requirements to safeguard
private data. Unfortunately, private data is commonly
written to log files without being encrypted or displayed
on screens without being masked. Health insurancerelated applications are no more secure than other
enterprise or commercial Web applications.

Conclusion
Every indication is that hackers, organised crime, and
nations with malicious intent are greatly increasing
their efforts to target thousands of applications around
the globe. The potential cost in terms of lost revenue,
customer trust, and brand integrity of even one signi
cant security breach can be devastating. Accordingly,
company security policies and government mandates
are placing growing pressure on IT organisations to
bolster the security of the applications they create,
procure, manage, and deploy.
HP Fortify RTA is unique because it operates inside the
application. This innovative approach yields several
key benefits.
Fortify RTA:
Is more accurate (i.e., has fewer false positives)
Protects the application from all input sources, not
just HTTP-based input; examples, Web services, file
systems, and back-end APIs
Installs more quickly and requires less ongoing
administration
Provides an immediate solution for PCI compliance
Adds active defencive countermeasures to the
application
Empowers a security group to instil fraud protection
or customised business logic into an application in
a short period of time
Learn how Fortify RTA can provide a quick, robust, and
accurate solution to securing your applications. Visit us
at https://www.fortify.com/products/fortify360/realtime-analyzer.html.

Get connected
www.hp.com/go/getconnected

Share with colleagues

Get the insider view on tech trends, alerts, and

HP solutions for better business outcomes

Copyright 2011 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The
only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services.
Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions
contained herein.
Java is a registered trademark of Oracle and/or its affiliates.
4AA3-6731EEW, Created October 2011