equasiis pov, application security and global sourcing, apr 2009 (e3001)

8/14/2019 EquaSiis POV, Application Security and Global Sourcing, Apr 2009 (E3001)

1/11

The Security Imperative: New Approaches to Securing Data and Software Applications in a

Global Sourcing Environment

www.equasiis.com | 1

EquaSiis Point of ViewOp inions and Perspec tives on the G lobal Business and IT Services Ma rkets

The Security Imperative: New Approaches to Securing Dataand Software Applications in a Global Sourcing Environment

Part One Data and Application Security in an Era of Global Sourcing

Stan Lepeak, Managing Director of Global Research, EquaTerra and EquaSiis

Overview: Data and Application Security in the Overall Scheme of Corporate Risk

There is no shortage of daunting challenges, threats and risks facing organizations in todays

economic environment. Many of them are struggling and sometimes failing to simply remainsolvent and viable. Unfortunately, when their basic survival is threatened, a lot of important issues

go by the wayside and receive little or no executive or strategic attention, resources and

investment.

While ensuring that the next payroll deadline is met is an obvious priority, organizations can

jeopardize their long-term viability by ignoring other serious concerns. This holds true not just for

emerging risks, but for those that they already face or do not expect to increase in the short term.

The magnitude of these risks which often lie in wait unnoticed under the surface is growing,

driven by the same negative market forces making a more visible impact on operations. This is

especially the case when it comes to the broad, critical and often misunderstood area of

information technology (IT) security.

IT security was a major challenge for many organizations when economic times were good

today it presents an even larger problem. Difficult times create desperate employees and

competitors and opportunities for criminals. For example, security breaches instigated by

disgruntled employees are on the rise as the economy continues to weaken. Corporate and

even more so nation-state espionage is increasing. Terrorist and criminal outfits worldwide are

aggressively assessing angles to exploit gaps created as distracted governments and

corporations focus more on addressing economic issues and less on ensuring the integrity of

operational processes.

A major hurdle organizations face in successfully mitigating IT security risks and issues is the

disconnect that typically exists between those who understand the threats and those with the

authority and control over funding to address them. This is partially due to the failure of

management and technologists to communicate effectively and technologists inability to translate

their issues and needs into qualified business cases. It is also because there are no quick, simple

or easy fixes to most IT security problems. Organizations cannot fix a problem through a simple

software purchase, policy change or executive mandate.

While chief security officers (CSOs) fight for budget dollars, respect and understanding and

executives continue to pursue security lite strategies, the threat continues to grow. As Melissa
mailto:[email protected]:[email protected]


2/11




Hathaway, Acting Senior Director for Cyberspace for the National Security and Homeland Security

Councils (NSC/HSC), noted in the fall of 2008, Our government and private sector networks andinformation are being exploited at an unprecedented scale by a growing array of state and non-

state actors.

Organizations, regardless of economic conditions, must identify, prioritize and determine how best

to remain vigilant against all core strategic and operational security risks. An increasingly

international, distributed and integrated economy albeit one that is contorting in the current

downturn makes this more imperative than ever. There are no secure fortresses or impenetrable

barriers to entry in todays global markets and geopolitical environment. While IT risks, especially

those related to data and application security, are just some of many that organizations must

mitigate, they require proportionally more attention and investment than they have normally

received to date.

Defining the Scope of Data and Application Security

IT security is a very broad concept, and attempting to address it without first defining a scope is ill-

advised. There are several major components of security related to organizational and corporate

business operations.

Physical: Facilities, sensitive operations centers, and IT hardware systems housing electronic

data and applications and connected to networks all pose physical security risks.

Electronic data: Criminals can steal corporate, customer, intellectual property (IP) and

related data stored in IT applications and systems.

Physical data: Physical documents such as hard copies of corporate and IP data arevulnerable to theft.

Application: IT software applications and systems are open to intrusion and compromise.

Network: Software applications operate, data flows, and voice communications transmit over

IT networks. These networks take many forms and are increasingly converging, making them

susceptible to penetration.

Personal: Often the most vulnerable point is humans. People design, build and operate IT

applications and systems and have access to their data. They are also at risk of personal

attacks of a physical (assault and kidnapping), coercive (blackmail), or manipulative (bribery)

nature.

There are also multiple means through which an organizations security is put in jeopardy. The

most attention is commonly paid to external attacks that are carried out with specific goals in mind,

such as network hacking or corporate espionage. More often, however, threats come from internal

sources, often with little planning or forethought. This is slowly changing, though criminals

propensity for internal attacks is not declining. Increasingly, organized crime or terrorist groups


3/11




and rouge and not-so-rouge nation-states are targeting organizations and even individuals for

external assaults.

There are threats to organizational security that are proactive and calculated and those that occur

by accident as a result of unintended circumstances. Breaking and entering and accessing a

network via a software backdoor that was intentionally left open is an example of a deliberate,

premeditated attack. Leaving a buildings back door to the street open while going for a smoke or

unintentionally exposing a network to penetration via a forgotten software backdoor are examples

of threats created by chance.

The Discipline and Rigor of Risk Management

While there are many unique characteristics and nuances associated with data and application

security, organizations are advised to address them in the context of established risk management

frameworks. These models are the same ones they should employ to address the overall risks

associated with global sourcing efforts. Organizations must keep in mind that managing sourcing

risk is a formal and disciplined process. Enforcing this discipline is critical to ensuring

vulnerabilities are not overlooked or underemphasized.

Just as there are different components to security, there are different categories of overall risk.

Human: personal, societal, cultural and political

Operational: process, organization, communication, performance and financial

Technology: interoperability, resilience and recoverability

Legal: statutes, regulations, self-regulation and liability

Economic: inflation, currency, and tax and tariff

Geographic: climate, geology and time Geopolitical: war, terrorism and nationalization

There are qualitative and quantitative aspects to each of these categories related to complexity,

volume and maturity. Organizations involved in any sort of major sourcing effort must identify the

threats that exist in each of these categories, which can impact the level and severity of risks to

data and applications.

These risks are by no means static. Organizations must consider and assess them across the

entire sourcing life cycle, from strategy through renewal and replacement. Similarly, they must

address data and application security risks across their entire business life cycle. At each stage

the risks are different in nature and severity. The bottom line is that while new tools and

techniques are needed to better address data and application security, organizations must alsorigorously apply defined and tested processes to deploy these new capabilities.

Keeping in mind the need to maintain rigor and discipline, the balance of this paper will

focus on security threats to electronic datathat is created and manipulated by IT software

applicationsand enabled both covertly and overtly by people and personnel. It will lay out

new means and techniques that organizations have at their disposal to combat data and


4/11




application security threats. These are not panaceas or quick fixes, but combined with other tools,

techniques and processes they can enable organizations to potentially regain more of an upperhand in the IT security battle.

The Pervasiveness of the Data Threat

The reason for the increase in the magnitude and volume of threats to organizational and

corporate data and applications is straightforward. There is simply much more stored data today,

and it is accessible intentionally or otherwise via a burgeoning array of interconnected global

networks. Most of the time, this is a good thing. There is no need to sing the praises of the Internet

and near-real-time worldwide communications. It is important to recognize, however, that sensitive

data is often closer to the other side of the world and the nefarious characters lurking there than

many individuals, at least those in management, understand.

If documents were stolen from an executives wall safe in the not-so-distant past, there was no

way that thousands of copies of the information could instantaneously make their way around the

world. Similarly, stealing the combination to a bank safe might lead to riches, but nowhere near

the level of return garnered by hacking into a credit card processors multimillion-record customer

database via an open backdoor.

Much emphasis has been placed on securing networks the routes into and out of an

organization. While this is critical, the focus is often just on the spot where internal and external

networks meet. However, in most cases this is not the only point of entry. Applications that are

perceived as existing safely behind a firewall are often vulnerable, even if the firewall is not

breached. There are two main reasons for this. One is that organizations need to link multiple

internal and external data stores and applications to perform core business activities. If an

application opens the firewall door to legitimately pass data to the outside but does not close the

door properly, it creates a risk that the firewall often cannot address. The other issue is the ever-

growing complexity of the software applications that use and manipulate data and the varied

sources from which organizations procure said applications.

While organizations can often do a better job of walling off sensitive data and applications from

external or high-risk sources of penetration, their efforts can only go so far before they begin to

diminish the value and usefulness of the data and applications. Walling off data and applications

from external threats also does nothing to address internal threats. A more far-reaching approach

is to address the security vulnerabilities in the software applications themselves.

The goal of writing good code from a security perspective is nothing new, but practically speaking

it is an impossible task to achieve. This is in part because most code is still developed by humanswho are inherently imperfect and occasionally operating with ulterior motives. The other challenge

is that, given the tens or hundreds of millions of lines of software code that support any

organizations operations, there is no way humans can manually or through the use of traditional

testing techniques identify and remediate all or even most security risks. This is exacerbated by

the fact that software comes from many sources, including internal developers, third-party

commercial vendors and, increasingly, open-source code. Most mission-critical software is


5/11




developed by third parties, and users typically do not have authorized or practical access to the

source code to perform the necessary testing.

Beyond Source Code Testing

There are two keys to improving the security integrity of software code developed by third parties

and, by definition, the data that it processes. The first is to improve the testing process itself by

automating it as much as possible and providing a means to test third-party code without having

direct access to it. Organizations can apply this first approach against internally-developed

software as well. Second, given the fact that users are dealing with third-party software obtained

through commercial transactions and contractual relationships, the terms and conditions of these

purchases must evolve to better define, address and mandate improved levels of application

security.

There are now solutions available that enable automated testing of application binary code. Binary

code is software code at the layer below the source code. It uses the binary number system;

numbers and letters are translated into signals that a computer reads as sequences of ones and

zeros called bits. Any organization that possesses software code can access and test the binary

code, regardless of the source of said code.

Veracode (www.veracode.com), a software security services vendor, pioneered the

commercialization of automated binary code testing. EquaTerra and EquaSiis have entered into a

nonexclusive business alliance with Veracode to further extend the reach of its testing services

with particular emphasis on applying it against software code developed by third parties, such as

that obtained through application development outsourcing efforts. The second half of this paper

describes in more detail how the Veracode technology and service operates.

While organizations can uses services like Veracodes to test third-party binary code or use

more traditional testing tools and techniques to test third-party source code indentifying potential

security vulnerabilities is only the first step. They must then work with the codes developers to fix

the identified problems. This can create additional issues.

Who pays for these fixes, the buyer or the service provider?

Do any of the problems identified imply a breach of any original contracted service levels or

application acceptance criteria?

To what degree is it practically and legally possible to codify more rigorous testing standards

in service level agreements (SLAs) and contracts going forward?

What is the appropriate level of application security to request and define in an SLA? What are

the industry standards and benchmarks? Once the problems are fixed, what can be done to ensure that they do not reoccur in the

future?

Buyers may initially get significant push back from service providers on any demands that are out

of the scope of the original agreement and incur additional costs for the provider. There are

challenges inherent in defining appropriate service levels, which will vary depending on the
http://www.veracode.com/http://www.veracode.com/


6/11




application and sensitivity of the data that it processes. However, the fact that these and other

complexities exist does not mean buyers should not pursue much greater levels of data andapplication security testing for their third-party software.

All contractual agreements with third parties to develop software applications include some sort of

testing and acceptance requirements. Typically, application security requirements are weak given

the historical limitations of testing programs and also because third parties often perform their own

testing. However, the tide is shifting as progressive buyer organizations institute more rigorous

testing and acceptance programs and bake them into contracts and service levels. The market

has reached an inflection point, and now is the time given both increased testing capabilities like

those provided by Veracodes solution and growing threat levels to make these more thorough

and contractually-enforced testing regimes the industry standard and not the exception to the

norm.

Part Two Anatomy of an Application Assurance Requirements Program

Matthew Moynahan, Chief Executive Officer (CEO), Veracode

Application Assurance Requirements

The assurance requirements of an application are determined by their business criticality and

dictate the security requirements or benchmark required for an application to be suitable for its

purpose. These security requirements are a balance between the security quality and acceptable

risk levels for the business. Security requirements include both presence of security features and

absence of vulnerabilities as specified through a requirements process and tested during an

acceptance process. These requirements are often gathered from government or industry

standards or best practices and include data encryption, logging and access control.Vulnerabilities in an application can render the required security features ineffective, so testing for

the absence of vulnerabilities is as crucial as testing for the presence of the security features.

To reduce the time and resources required to build an application, the security requirements are

proportional to the assurance level. Higher assurance software such as the software controlling

physical systems or high-value financial transactions have more security features than low

assurance applications where the loss of confidentiality, integrity or availability would cause little or

no damage. The quantity and severity of vulnerabilities tolerated in an application should likewise

be proportional to the assurance level as time and resources are required to both test for and

remediate vulnerabilities. A good resource that lists many of the most important vulnerabilities is

the SANS Top 251

or the OWASP Top 102.

Security Rating Process

The security rating process measures whether or not an application is suitable for its purpose. It

can be used for a single application in an acceptance testing process or can be used to rank a set

1SANS Top 25, http://www.sans.org/top25errors/

2OWASP Top 10, http://www.owasp.org/index.php/Top_10_2007
mailto:[email protected]://www.sans.org/top25errors/http://www.sans.org/top25errors/http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.sans.org/top25errors/mailto:[email protected]


7/11




of applications, much like Consumer Reportsdoes. This is often done in a multi-vendor bake off.

It consists of the following steps:

1. Setting the assurance level

2. Performing assessments

3. Rating the application

4. Using ratings to determine mitigation

5. Monitoring rating on a regular basis

1. Setting the Assurance Level

The first step in determining if an application is suitable for its purpose is to determine its

assurance level. The assurance level helps measure impact caused by a system failure. For

simplicity, assurance levels are set on a five point scale, where AL5 is the highest assurance level

and AL1 is the lowest. If an organization has its own custom scale for system risk it can be

mapped to the Veracode scale of AL1 through AL5. Veracode provides an assurance level

mapping based on the process the U.S. Office of Management and Budget has specified in

memorandum M-04-043

for all U.S. Government agencies. The following six potential impacts of

an application failure are rated with their likelihood as Low, Moderate or High.

Inconvenience, distress, or damage to standing or reputation

Financial loss or organization liability

Harm to organization programs or public interests

Unauthorized release of sensitive information

Personal safety

Civil or criminal violations

On the table below, circle the likelihood for each impact category. Detailed definitions of Low,

Moderate and High can be found in the document listed in footnote 1. The assurance level is

specified by the header of the rightmost column with a circle selected.

Potential Impact Categories

AL2

(Low)

AL3

(Medium)

AL4

(High)

AL5

(Very High)

Inconvenience, distress, or damage to

standing or reputation

Low Mod Mod High

Financial loss or organization liability Low Mod Mod High

Harm to organization programs or public

interests

N/A Low Mod High

Unauthorized release of sensitive

information

N/A Low Mod High

Personal safety N/A N/A Low Mod or High

Civil or criminal violations N/A Low Mod High

3Executive Office of the President, Office of Management and Budget, M-04-04,

http://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdf
http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.owasp.org/index.php/Top_10_2007http://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdf


8/11




Example

A large financial company has an Internet-facing application where customers can apply for loans.

A compromise of this application will lead to the following impacts as described in M-04-04:

1. Inconvenience, distress, or damage to standing or reputation Mod

2. Financial loss or agency liability Low

3. Harm to organization programs or public interests Low

4. Unauthorized release of sensitive information Mod

5. Personal safety N/A

6. Civil or criminal violations Low

There are two impacts for this application that are Moderate that would put this application in the

AL4 (High) assurance level.

2. Performing Assessments

The next step is to perform one or more of the following types of security testing based on the

assurance level of the application:

Automated static analysis testing

Automated dynamic analysis testing

Manual penetration testing

The higher the assurance level the more analysis techniques need to be performed. This adds to

cost but is required since there is less tolerance for testing errors as assurance levels rise. The

following table lists the required and recommended tests to be performed for an application for

each assurance level.

Assurance

Level

Automated Static

Testing

Automated Dynamic

Testing

Manual Penetration

Testing

AL5 (Very High) Required Required Required

AL4 (High) Required Required Recommended

AL3 (Medium) Required Recommended

AL2 (Low) Recommended

3. Rating the Application

The security flaws found during testing are categorized by the Common Weakness Enumeration4

(CWE) ID and assigned a severity using the base score of the Common Vulnerability ScoringSystem

5(CVSS). The severity of the flaws detected is aggregated using a formula where higher

severity flaws count more than lower severity flaws. The score is then normalized from 0 to 100

where 100 is a perfect application with no flaws detected.

4MITRE Common Weakness Enumeration, http://cwe.mitre.org

5FIRST.ORG Common Vulnerability Scoring System, http://www.first.org/cvss/
http://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdfhttp://cwe.mitre.org/http://cwe.mitre.org/http://www.first.org/cvss/http://www.first.org/cvss/http://www.first.org/cvss/http://cwe.mitre.org/


9/11




An example of a very high (5) severity flaw would be a backdoor passwordor command injection

vulnerability, which would allow an attacker to have full control of the application. An example of alow (2) severity flaw is information leakage, where an error message displayed to an attacker

could give information that would help them attack the system.

Application Security Ratings

The assurance level dictates the amount of security testing to be performed. It also specifies the

security quality score, which is generated during testing, that must be obtained for an application

to be suitable for its purpose. Veracode uses a rating system of the letters A, B, C, D and F where

A means the application has obtained a good enough security quality score so that it may be

deemed suitable for its purpose.

The scoring system is designed such that the higher assurance applications must be free of higher

severity flaws. The following table illustrates which severity flaws are an acceptable risk to remainin an application and still meet its security quality suitability.

Assurance

Level

Example Severity 5

(Very

High)

Severity 4

(High)

Severity 3

(Medium)

Severity 2

(Low)

Required

Score

for A

Rating

AL5 (Very

High)

Life or limb at risk

or organization

mission critical

None None None Some 90

AL4 (High) Financial

transactions or PII

at risk

None None Some Some 80

AL3 (Medium) Back office

department critical

None Some Some Some 70

AL2 (Low) Back office Some Some Some Some 60

4. Using Ratings to Determine Migration

The application security rating can be used during an acceptance testing to determine if an

application is suitable. During acceptance testing the application is submitted to Veracode for

testing. Veracode produces a COTS report which specifies a letter rating for the application. If the

application receives an A rating then it can be accepted. If the application receives an B or C

rating the application should be accepted contingent on the application vendor following the

Veracode remediation roadmap, resubmitting the remediated application, and receiving an Arating within a three-month period of time. If the application receives an D or F rating it is likely the

vendor will not be able to produce an A rating within the three-month period and there is too much

risk in the application to deploy it on even a temporary basis.


10/11




About Veracode

Veracode is the worlds leader for on-demand application security testing solutions. Veracode

SecurityReview is the industrys first solution to use patented binary code analysis and dynamic

web analysis to uniquely assess any application security threats, including vulnerabilities such as

cross-site scripting (XSS), SQL injection, buffer overflows and malicious code. SecurityReview

performs the only complete and independent security audit across any internally developed

applications, third-party commercial off-the-shelf software and offshore code without exposing a

companys source code. Delivered as an on-demand service, Veracode delivers the simplest and

most-cost effective way to implement security best practices, reduce operational cost and achieve

regulatory requirements such as PCI compliance without requiring any hardware, software or

training.

Veracode has established a position as the market visionary and leader with awards that include

recognition as a Gartner Cool Vendor 2008, Info Security Product Guides Tomorrows

Technology Today Award 2008, Information Security Readers Choice Award 2008, AlwaysOn

Northeast's "Top 100 Private Company 2008", NetworkWorld Top 10 Security Company to Watch

2007, and Dark Readings Top 10 Hot Security Startups 2007.

Based in Burlington, Mass., Veracode is backed by .406 Ventures, Atlas Venture and Polaris

Venture Partners. For more information, visit www.veracode.com.

###

Media Contact:

Linsey Krauss

Lois Paul & Partners+1 512 638 5316

[email protected]
http://www.veracode.com/security/xsshttp://www.veracode.com/security/sql-injectionhttp://www.veracode.com/solutions/pci-compliance.htmlhttp://www.veracode.com/mailto:[email protected]:[email protected]:[email protected]://www.veracode.com/http://www.veracode.com/solutions/pci-compliance.htmlhttp://www.veracode.com/security/sql-injectionhttp://www.veracode.com/security/xss


11/11




About EquaSiisEquaSiis, an EquaTerra company, provides software and services that

improve the business support services lifestyle for shared services,

outsourcing practitioners and service providers. The software,

EquaSiis Workbench and EquaSiis Enterprise, is a framework for

collaboration used during the service delivery assessment and

sourcing process to assist in analysis and decision making for shared

services or outsourcing. EquaSiis provides intelligence and

optimization for the delivery of business support services across the

entire organization. The company also offers service providers market

intelligence, research, customer satisfaction and trending data through

its Insights group. For more details about EquaSiis research offerings,

please contact Stan Lepeak, [email protected].

www.equasiis.com

Media ContactsRon Walker, EquaSiis

+1 858 486 6035

[email protected]

Lee Ann Moore, EquaTerra

+1 713 669 9292

[email protected]

Copyright EquaTerra 2009. All rights reserved. The prior written permission of EquaTerra is required to reproduce

all or any part of this document, in any form whether physical or electronic, for any purpose.
mailto:[email protected]://www.equasiis.com/mailto:[email protected]:[email protected]:[email protected]:[email protected]://www.equasiis.com/mailto:[email protected]

equasiis pov, application security and global sourcing, apr 2009 (e3001)

Documents