defending the castle rwsp

Defending the Castle 1

Defending the Castle by Actively Abusing It

Jesus Oquendo

C|EH, CHFI, OSCP, CPT IACRB, SGFA, SGFE

Chief Security Architect AEON Inc.

November 18th

, 2010


Abstract

Research indicates that current trends in information security threats outpaces the security

controls that reduce and or eliminate information security vulnerabilities. This document

examines the approach of achieving maximum information security defensibility, by utilizing

effective offensive testing. Compared are the differences in the effectiveness of security testing

by performing a controlled test – referred to as “vanilla” testing, and a responsibly orchestrated

blackhat test. Contrary to popular industry belief, realistic “adversarial” testing can be

accomplished in a responsible manner without the consequences of “bringing down the house,”

contrary to popular belief. Offered, are arguments, costs associated with testing, and

counterpoints against organizational decisions that disallow certain types of testing. Blackhat

based testing is similar to what a malicious and structured attacker would perform and it is

believed that by performing “blackhat” testing, we are taking a “realistic” approach to

vulnerability testing. This is the proper route to take to ensure fully scoping the potential

vulnerabilities in a given environment in an effort to maintain proper defensibility.


Defending the Castle by Actively Abusing It.

Introduction

Between 2003 and 2006, retailer TJ Maxx suffered a breach where the data for 94

million cards were stolen. [CON09] Similarly, Heartland Payment Systems was also breached

[RAG09] yet the two given the green light for compliance from the PCI Security Standards

Council [PCI10]. Research has noted that collectively, the estimated cost of a security breach is

6.75 million as of 2009 [MESS10] and the figure continues to rise. These respective companies

under regulatory mandates from PCI were required to perform penetration testing.

Ponemon institute noted "The magnitude of the breach events, according to the study,

ranged from about 5,000 to about 101,000 lost or stolen customer records. Among the incidents

reported, the most expensive data breach cost nearly $31 million to resolve, and the least

expensive cost $750,000." Using the “least expensive cost” figure of $750,000 as a budgetary

figure, we will create a "red team" security testing team whose sole purpose is to provide

adversarial testing in the effort to defend us in a realistic fashion.

The goal is to provide the following:

gain a realistic view of our security posture

rise above the security baselines set by organizations

compare realistic testing versus vanilla / controlled testing

increase security testing effectiveness

minimize residual risks using focused, responsible and targeted testing

provide an insight into realized costs associated with testing, training versus a

compromise

Guidelines and Recommendations

Guidelines and frameworks mentioned in this document rely on standards predominantly

used in the United States of America. Other countries have their own regulatory frameworks,

guidelines and laws. For example, in Europe, there is the Council of Registered Ethical

Security Testers (CREST). Wikipedia's entry for CREST is:


CREST is a non-profit association created to provide recognised standards and

professionalism for the penetration testing industry [CRE10]

My “vanilla” testing will rely on predominantly on NIST and ISECOM's OSSTMM

structures, of which NIST heavily borrows information, concepts and testing methods and

parameters.

SP 800-15

The National Institute of Standards and Technologies (NIST) created SP 800-115

[NIS08] in 2008 which replaced 800-42. This standard laid the foundation for security testing

and assessments. Throughout those documents, an assessor is given a testing framework,

information on recommended security tools to use, rules of engagement and so forth.

OSSTMM

OSSTMM was developed by ISECOM which is a non-profit organization with a

collaborative group of security subject matter experts who have collectively laid out the “Open

Source Security Testing Methodology Manual” otherwise known as OSSTMM. From the

ISECOM website:

The Open Source Security Testing Methodology Manual (OSSTMM) is a peer-

reviewed methodology for performing security tests and metrics. The OSSTMM test cases

are divided into five channels (sections) which collectively test: information and data

controls, personnel security awareness levels, fraud and social engineering control

levels, computer and telecommunications networks, wireless devices, mobile devices,

physical security access controls, security processes, and physical locations such as

buildings, perimeters, and military bases.

The OSSTMM focuses on the technical details of exactly which items need to be

tested, what to do before, during, and after a security test, and how to measure the

results. New tests for international best practices, laws, regulations, and ethical concerns

are regularly added and updated. [ISE10]

Much information has been published by both NIST and ISECOM on the subject of

testing; how the tests are to be performed, what is to be performed during the testing phases,

what tools should be used in the testing phases, how those tools should be used and so forth.

Yet both organizations fail to accomplish obtaining a real world view of the security posture of a

network and or target system. This is primarily because of the prohibitive “controls” they

convey in the choice of wording and perhaps, unsubstantiated fears, due to a lack of

understanding that, certain parameters that can be configured with most tools to minimize risks

of inflicting damage during testing.


Overview of Security Tools

Immunity Canvas [CAN10]

Canvas is an automated exploitation program that allows its users to use existing exploits

as well as develop their own exploits. The application is written in Python and can be deployed

from Windows, Linux and OSX platforms. Currently there are over 400 reliable exploits

available in Canvas.

Metasploit Community [MET10]

Metasploit is a penetration testing framework which currently consists of 613 exploits,

306 modules, 215 different payloads and can be used on most operating systems. Metasploit can

be used in a Java-based GUI or via a command line terminal which makes it a very attractive

alternative to Canvas. Because of the structure of Metasploit, a penetration tester can get this

application deployed onto a smart phone [MOO10] which could allow for minimal physical

security detection in perhaps a controlled environment.

GFI LANGuard

GFI LANGuard is a network security scanner and vulnerability management solution. It

too relies on "known" patches to determine vulnerabilities. GFI is marketed as an application to

assist in the following areas:

Patch management

Vulnerability management

Network and software auditing

Assets inventory

Change management

Risk analysis and compliance

Acunetix Web Vulnerability Scanner

Acunetix Web Vulnerability Scanner is a web-application based scanner. It is targeted

specifically for HTTP web based servers and allows for deep analysis of applications running on

a web server. Unlike GFI LANGuard, it is capable of discovering vulnerabilities inside of an

application running on a web server whereas LANGuard cannot perform these intricate tests.


Overview of the Test Production System

My test production system consisted of a Windows 2003 Advanced Server R2 running an

open source Enterprise Resource Planning (ERP) and Customer Relationship Management

(CRM) application called OpenTaps [COM10]. In my production set-up, there were a few

Microsoft security patches that needed to be omitted in order to allow clients to connect to the

Enterprise CRM.

Networking consisted of two network interfaces, one assigned a private RFC1918

address and the other, a public address to enable remote customers and workers the ability to use

the system. Testing will include an adversarial test from the outside scope – what an attacker

would see via the public view – and an internal adversarial test – what an attacker would see if

they were an insider, or if the attacker compromised another machine inside the infrastructure

and targeted the ERP/CRM server. Using these different types of tests, we can conclusively

illustrate the discrepancies in testing and how by following the guidelines and methodologies, a

tester will yield many false positives that will skew the outcome of their tests.

Corporate Vulnerability Assessment

Many corporations lack an in-house “red team” and often solicit the services of

companies that provide these types of security tests. It is observed that in many industries,

companies dislike “real world” testing against the infrastructure. For example: "Certain kinds of

systems should almost never be subjected to live penetration testing," [CLE08]. While this may

be the case for specific industries such as SCADA [SCA10], security managers have often

followed this train of thought throughout many industries often prohibiting realistic testing. My

test begins with what I call a “vanilla” vulnerability/security test, using two commercial off the

shelf (COTS) applications found in most enterprise environments, GFI LanGuard and IBM

Rational AppScan version 7.7

Whitebox using GFI LANGuard

GFI LANguard was launched against the external IP address. Due to the placement of the

server, a firewall filtered the majority of simulated attacks which were based on signatures

available in GFI. From the outside scope – according to GFI LANGuard – we have a well

protected system as it returned no high or medium vulnerabilities. The result is rather obvious as

most firewalls are deployed with “block all” and “allow trusted” rules, with most ports being

filtered. To a security management team, there is a high likelihood this server would be flagged

as “secure” based solely on the output of this type of “vulnerability test.”


Full Scan via External IP without credentials

Full Scan via External IP without credentials


As shown in the images above, we have a false positive in the results. This statement

comes from the fact that simply running a database server (MySQL) is not a vulnerability.

While it may be improper to design a server in this method, it is not uncommon to disallow

access to the database server from external sources, but the mere fact that a database is running,

is not necessarily a vulnerability. Should the database have “known vulnerabilities” which could

be exploited, it would then be problematic.

However, I ran the same GFI LANGuard scan against the internal IP address along with

credentials and it yielded a variety of vulnerabilities. Performing this scan is the equivalent of an

“insider” attacker's point of view. Output from this type of scan is more critical than an external

point of view. I state this in the sense that an insider threat is more dangerous than an outsider

threat – as the insider will always have more visibility of the true security state of the system.

This (external) scan is closer to the “real world” security view of the server.

Full scan with credentials against the Internal IP


Full scan without credentials against the Internal IP

As security professionals, the need to perform the two types of testing (internal and

external) at all times is critical - as all threats need to be determined – both internally and

externally. The goal of an internal scan is to reduce the potential exploitation of a client side

attack - not necessarily to mitigate the threats from insiders who physically work inside of the

infrastructure. By relying solely on an outside “security” point of view, results will not be

accurate and a skillful attacker may exploit a client side vulnerability. Internal security risks can

allow an attacker to take complete control of a server just as outside facing risks would also give

an attacker control. However, the vulnerabilities listed on GFI LANGuard's report should be

viewed with skepticism. GFI's output relies on the availability of a port being opened, closed or

a revision number. It then correlates this information to label something as a “vulnerability.”

Simply running an application is not a vulnerability.”

This scanner and others like it will often yield both false positives and false negatives as

GFI LANGuard is not capable of validating whether or not an application or service is

exploitable. While it may be bad practice to configure servers in a certain fashion, for example:

placing a DB server publicly facing the Internet, the mere fact that a service is running does not

make that service a vulnerability. By relying on skewed information such as this (false positives

and false negatives), security managers may spend unnecessary money towards defending a

server simply because a port is opened or a service is running, yet is not exploitable.


Whitebox using Acunetix Web Vulnerability Scanner

Acunetix was configured to perform two similar assessments from the web application

side of the spectrum. The parameters chosen for the first Acunetix test was an “internal facing

web application scan” with Acunetix's “Extensive” test being chosen, and no credentials given.

Acunetix is capable of performing functions above a typical scanner in the sense that it allows

sorting out of many false positives as it is programmed to ignore and or learn about. The

application also performs SQL injection tests, parameter manipulations, Cross Site Request

Forgery (CSRF) and other port scanning tests. Our goal in performing this internal scan,

“without” credentials, is to mimic what an outside attacker may be able to access should they

use this tool. Our testing yielded no high or medium vulnerabilities.

In our first test, we simply aimed the vulnerability scanner as if we were a “drive-by”

attacker with no knowledge of the system. The goal was to re-create what a random attacker

would see in the event they stumbled onto the system. The results were negligible with no

vulnerabilities being found. In our second test, we supplied the scanner with the credentials of a

normal user. This served two purposes: the first was to determine what, was possible for a

rogue employee to access based upon a privilege escalation attack, and the second would be

similar to an attacker who had “phished” credentials, or perhaps bruteforced an account on the

system. Both tests resulted in similar reports a “Clean Bill of Security Health.”

My testing thus far has used applications currently in use in many environments. I also

followed the same “responsible” structure as alluded to in the aforementioned frameworks

(OSSTMM, NIST). Operating continued without incident on the operating system – the machine

was not “taken out” and there were no discernible performance issues with normal tasks. In

other words, the system operated transparently while the testing was performed.

Adversarial Outsider Attack

My “adversarial” outsider attack began quite differently as I sought to perform a “real

world” test without the limitations of timing variables within tools, what tools I would use and

how far I would go to get into the system. It is my belief that as a simulated attacker responsible

for the defense of the system, I need to know what an attacker can see realistically. In my

opinion, there is no real world security value to “sanitized” testing as I have explained. Some

tools report false positives and false negatives and these results can skew security metrics which

can lead to wasted security dollars and false representations of security.


It is my belief that a rogue attacker will not likely spend much money on security tools

and there are plenty of “point and click” exploitation tools available on the market - Core Impact,

Immunity Canvas; however, these tools can cost tens of thousands of dollars. The other options

available would be for an attacker to create their own tool or use “community based tools.”

These tools are usually open source based tools available for download and use within the

parameters included in the licenses when applicable.

I also must clarify that there are different types of malicious attackers. There is a typical

“drive-by” like attacker which usually searches for the “low hanging fruit” to exploit. These

attackers seem to aim random tools at random target in the hopes that something is found. The

other type of attacker is the “structured” attacker. This can be a foreign government, a

competitor, a former employee or former partner. Whomever the “structured attacker” is, there

is a likelihood that they would be the attackers, who with a budget, and or more information

available, would perform a targeted attack. They are likely to be the more successful and covert

attacker.

My goal is to test as both a random attacker and a “structured attacker.” My goal is to

infiltrate the infrastructure no matter what the cost. I performed this phase of testing both

recklessly and responsibly for a few reasons. First, this allows me to test incident response if any

is in place. During the course of an attack, bells should be ringing and alarms should be

sounding. Secondly, from a real world perspective, if any system is unstable, there is an

altogether different issue that would obviously need to be addressed. Any attacker will not care

whether or not a service is rendered inoperable. An attacker would aim their tools at a target and

try their best to get in.

Furthermore, in real world testing, I prefer performing real world adversarial tests and I

almost always choose not to give notification to anyone outside of a “need to know” basis. This

enables me – the tester - to perform a realistic test without the possibility of an administrator

trying to tidy up prior to my testing. It has been observed that security assessments and auditing

bring connotations of “pointing a finger.” Administrators and operators of systems can feel as if

there will be some form of repercussion if a vulnerability is found. This attitude and or

confusion often leads to an administrator or operator trying to defend against the tester. If

successful at defending against the tester, the operator then in turn creates an even bigger

security issue. The tester is blocked but perhaps an attacker isn't.

Adversarial using Metasploit

Metasploit was launched against the ERP/CRM server using a module called “autopwn.”

Autpwn is an automated exploitation module that works by associating available exploits with

open ports. Unlike the commercial tools, metasploit doesn't necessarily rely on credentials. With

or without them, the tool's core value consists of many publicly available exploits which are used


by “real” attackers in compromising systems. It is a very refined tool with cutting edge exploits

updated by a community.

I performed the same parameters for testing, from inside the perimeter and outside the

perimeter. This type of testing always yields different results, yet the bottom line is the same,

exploitation from within the network should not be viewed differently from exploitation outside

of the network.

The initial launch of metasploit occurred from an internal address aimed at the ERP/CRM

system:

msf > db_driver sqlite3

[*] Using database driver sqlite3

msf > db_connect opentaps

[*] Creating a new database instance...

[*] Successfully connected to the database

[*] File: opentaps

msf > db_nmap -P0 -sV -O -sS 10.4.4.67

Starting Nmap 5.00 ( http://nmap.org ) at 2010-11-17 16:29 EST

Interesting ports on 10.4.4.67:

Not shown: 988 closed ports

PORT STATE SERVICE VERSION

80/tcp open http Microsoft IIS httpd

135/tcp open msrpc Microsoft Windows RPC

139/tcp open netbios-ssn

445/tcp open microsoft-ds Microsoft Windows 2003 microsoft-ds

1025/tcp open msrpc Microsoft Windows RPC

1057/tcp open unknown



3389/tcp open microsoft-rdp Microsoft Terminal Service

8009/tcp open ajp13?

8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1

8443/tcp open https-alt?

Device type: general purpose

Running: Microsoft Windows 2003

OS details: Microsoft Windows Server 2003 SP1 or SP2

Network Distance: 1 hop

Service Info: OS: Windows

OS and Service detection performed. Please report any incorrect results at

http://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 107.67 seconds

msf > db_autopwn -p -t -e -r

--> OUTPUT OMMITTED

[*] (342/342 [0 sessions]): Waiting on 7 launched modules to finish

execution.


Metasploit was unable to compromise our system. This is a bonus on the defensive side

of our security aspects, it is not an easy target being that Metasploit has hundreds of security

experts constantly submitting valuable exploits against all types of applications and operating

systems. One of the benefits of testing with Metasploit versus commercial tools is that there

seems to be more effort placed into creating exploits as well as the amount of exploits available

versus commercial systems.

Commercially written “vulnerability” tools will always stress the need for structure,

reliability and the need to “not bring down the house.” The mechanisms used to develop the

signatures in commercial tools tend to search for known exploits that have been assigned a

“CVE” number from the MITRE Corporation. CVE from their website is explained as: “a

dictionary of publicly known information security vulnerabilities and exposures.” [CVE10]

Common logic dictates that an attacker is not going to wait for a CVE number in order to use a

specific attack, attack methodology, etc., but rather, attack a system in an effort to gain a

foothold.

Metasploit was then run from “outside the perimeter” and was unable to get past the

filtered ports due to a firewall in place. From a security management and risk assessment

perspective, the system so far seems to have a clean security bill of health.

Adversarial using CANVAS

My secondary test mimics a “structured” attacker that is focused on compromising an

infrastructure. An attacker who may have the financial capability of purchasing professional

grade exploitation tools. The tool of choice was Canvas for its ease of use, functionality, speed

and its programming capabilities.

Canvas is a commercially developed exploitation application written by a company that

focuses strictly on exploitation. Personal experience demonstrate that these types of companies

that have a sole purpose, often put out the most rigorous and accurate tools. It is their prime

source of revenue, and the Canvas' authors are some of the most prominent experts at developing

exploits that target unique applications and operating systems.

One of the main differences between a tool like Canvas and Metasploit is the target

audience. Metasploit's community edition was originally tailored for security engineers, security


hobbyists and security testers. While this approach is clever in the sense that many can engage is

proactive exploit development, it also leads to many exploits for programs that may not be used

in an enterprise environment. Canvas' authors seem to focus on “high value” targets. By this we

mean, a vast majority of the exploits found in Canvas are often geared to exploit enterprise

software; e.g. SAP, Microsoft, Apple, IBM, etc.

Canvas was launched under the premise of a focused attacker intent on gaining access.

Our test also was two-fold; internal and external security postures. Our external testing results

were similar to all other tools. Any assessor would give the ERP/CRM a clean security bill of

health. Were I to provide CVE scoring in comparison to the realities of vulnerabilities

discovered, the numbers may as well be zeroed out. To date, nothing aimed at the ERP/CRM

seemed to be capable of compromising the server. Internally targeting the server however, was

an entirely different case. Not only was Canvas capable of compromising the server, it did so in

a whopping 20 seconds.

Canvas was completely transparent to the normal operations of the server. Had I

managed to get a hook inside of the network, I can conclusively state that the “clean bill of

health,” given by all other security tools and testing was “not so clean” after all. This in itself

poses a dilemma. If an attacker can't get in, there is no potential to compromise a server, device,

etc.. While a tester, manager, assessor, et al, post the same argument, the reality is that with

the rise of “client side attacks” all avenues of risk must be assessed.


Canvas via External Test

Canvas Internal Exploitation


Conclusions

We can gather a few conclusions about the variances in tests and the effects of

performing multiple tests. By solely relying on the output of “vanilla based” testing from the

commercial offerings, one can never obtain valuable security metrics. Many assessors rely on

this kind of output when creating a risk based score, in fact many PCI assessors choose to rely

on the output of an “external scan” which we have shown cannot detail true exposure. In my

tests, I used the same commercial grade tools cherished for their “security prowess.” All of the

tools tested, both commercial and open source, effectively performed as they were programmed

to. Not one tool in my testing disrupted the server in any shape form or fashion. Not one tool

“brought down the house.”

Reliance on a single sided point of view – the external security posture – must never be

used as the de-facto guideline for an organization. The results always differ and the testing

should differ in order to reflect the true nature of all security risks. These security risks will not

come solely from a wandering “drive-by” attacker, but they may also come from an insider.

Whether this insider is physically an insider, or an insider who was subjected to a client side

attack.

Performing “blackhat” like testing does not always lead to “bringing down the house.”

On the contrary, skillful attackers have been careful in their exploits programming that they

often try to code exploits that avoid “crashing the system.” An attacker is going after a

compromise, access to a system for whatever purpose; corporate espionage, data exfiltration,

etc. Risking detection by way of or via a system crashing, through the use an unreliable exploit,

is something attackers are steadily crafting. Against this can the comparison of a bank robber

throwing a brick through a window. Why would they risk it after all the reconnaissance,

planning, etc.? It makes more sense for an attacker to use validated exploits to gain a foothold,

than it would be to use tools that set off bells and whistles.

Exploit developers have an interesting way of modifying code and are almost always

implementing changes that make exploits more lethal the longer the exploits are around. For

example, a comment from “Linux 2.6.30+/SELinux/RHEL5 Test Kernel Local Root Exploit

0day” states: “A vulnerability which, when viewed at the source level, is unexploitable! But

which thanks to gcc optimizations becomes exploitable.” [EXP10] Along with explanations of

exploits from the commercial vendors:


MICROSOFT WINDOWS PRINT SPOOLER OVERFLOW

ARCH: [['Windows', '2000']]

MSADV: MS09-022

SITE: Remote

TYPE: Exploit

CVE NAME: CVE-2009-0228

VENDOR: Microsoft

REPEATABILITY: One shot

NOTE: A string is non-zero terminated after a wcsncpy(), ending up in a

miscalculation before a wcsncat(). This is kind of like an uninitialized

variable issue, and thus reliable code execution depends on the content

of the stack. This version of the exploit triggers the bug, but will not be

extremely reliable. This exploit requires “root” privileges since it starts a

fake SMB server on TCP port 445. There is a 4-byte difference in the stack layout if

MS08-062 is not installed, making the exploit fail.

The theory that “tools that cause chaos” and “will bring down the house” should be

reviewed on a case by case basis. Organizations must learn to educate and trust their security

staff enough so that their testers can use realistic tools in a responsible fashion. This includes

their staff fully understanding what functions the tools perform, how they perform their tasks

and what are the potential outcomes of running the tools. Most exploit developers categorize

tools which render systems useless as “denial of service” tools. Commenting inside of most code

explains what a particular tool can do and many times there will be mentions of the reliability of

most tools. However, it is ultimately up to the tester to perform their due diligence by

performing not only responsible testing, but accurate testing. Any other “scaled down” testing

will always be inaccurate.

Our dual method of testing (internally and externally) provided four distinct sets of

results. All of which must be addressed as there is real risk associated from two distinct sides of

the spectrum; the internal threat and the external threat.


COTS Based Testing

Internal Vanilla Test

(no credential)

GFI LanGuard 1 Warning 0 vulnerabilities

Internal Vanilla Test

(no credential)

Acunetix Web Vulnerability Scanner 0 Warnings 0 vulnerabilities

External Vanilla Test

(low level credential)

GFI LanGuard 5 vulnerabilities (1 critical)

3 potential vulnerabilities

External Vanilla Test

(low level credential)

Acunetix Web Vulnerability Scanner 4 warnings 0 vulnerabilities

Red Team Test No Restrictions

Internal Compromise

Metasploit Community Edition

No vulnerabilities exploited

External Compromise

Metasploit Community Edition


Internal Compromise

Immunity Canvas

Compromise in 20 seconds

External Compromise

Immunity Canvas


Organizations face an uphill battle defending against attackers and perhaps this is due to a

lack of understanding of the nature of an attacker. An attacker will use many different tools and

while I theorize that a “drive by” attacker will not having the financial backing to purchase

“professional grade” exploitation applications such as Core Impact or Immunity Canvas, the

threat should not be minimized.

As a drive by attacker without the financial backing, there are no available, plausible,

metrics to discuss; this kind of attacker will use whatever tool is available and functions. They

will not care whether or not a tool crashes an application, they will stay aim at the target. Often

after the fact, there will come the realization of a compromise but by then, it may be too late.

Something to ponder as an attacker “didn't bring down the house” yet successfully managed to

compromise an infrastructure. Structured attackers may have the financial backing to purchase

high end tools and most often will as the benefits of those tools outweigh their costs. There is no

logical reason that a company should not do the same. Organizations should have and utilize the

same tools as not only the hobbyist, but of those used by the professionals.


The realized cost of purchasing Core Impact, Immunity Canvas, GFI LANGuard and

Acunetix for the testing is far lower than the cost of a compromise. Some vendors listed do not

provide pricing on their websites however, I have listed the prices that were disclosed to me in

discussions. Along with the pricing for applications, I have also included a base salary for two

full time security testers and the pricing on constant training for the employees.

Applications

Tool Pricing

Immunity

Canvas

$3,500.00 (estimated) No IP restrictions

GFI

LANGuard

$32.00 main price 10-24 IP addresses [GFP10]

Core Impact (take note, pricing

is based off a quote

from 2008)

$9,000.00 per quarter (unrestricted license)

$10,000.00 per year per 8 IP's (single installation)

Acunetix

WVS

$4,995.00 perpetual license

Total $17,527.00 (with Core's per quarter license)

$18,527.00 (with Core's per year license)

Salaries

$173,418.00 Two full-time Penetration Testers (highest available salary): [PAY10]

Training (provided for both employees)

$8,738.00 SANS GPEN Training (onDemand) ($3,870 training, $499.00 exam x 2

employees)

$7,000.00 IACRB Advanced Penetration Testing

$4,000.00 Peak Security Real World Security Professional training

My estimated pricing totals $211,683.00 for two employees and provides them with

cutting edge applications and training. Managers may view the numbers initially and scoff at the

high price however, the costs associated with a compromise as mentioned in the beginning are

much greater: “$31 million to resolve, and the least expensive cost $750,000”

Addressing security can be costly. But we have proven that security can be achieved

effectively from a cost perspective, provide realistic based attack capabilities, and finally,

testing can be accomplised without bringing down the house. I abused my ERP/CRM server no


differently than a real world attacker would using the same tools and methods. In fact, I went a

step beyond and attempted to abuse the system with the information of an “insider” attacker –

someone authorized to work on the server attempting to abuse the system. At no time was the

system degraded and ultimately the results show a need to perform multiple tests from differing

aspects of an attackability perspective.


References

[CON09] "TJ Maxx Settles Data Breach Charges." June 23, 2009. URL:

http://www.consumeraffairs.com/news04/2009/06/tjx_settlement.html

[RAG09] Ragan, Steve. "Does the Heartland breach prove PCI useless?" Jan 26, 2009. URL:

http://www.thetechherald.com/article.php/200905/2849/Does-the-Heartland-breach-prove-PCI-

useless

[PCI10] PCI Security Standards Council. URL:

https://www.pcisecuritystandards.org/

[MES10] Messmer, Ellen. “Data breach costs top $200 per customer record” Jan 25, 2010. URL:

http://www.networkworld.com/news/2010/012510-data-breach-costs.html

[MOO07] Moore, HD. “A rootshell in my pocket (and maybe yours).” Sept 25, 2007. URL:

http://blog.metasploit.com/2007/09/root-shell-in-my-pocket-and-maybe-yours.html

[COM10] Compiere

http://www.compiere.com/

[CLE08] Clem, John. “Red Team Versus Blue Team: How to Run an Effective Simulation”

http://www.csoonline.com/article/221695/red-team-versus-blue-team-how-to-run-an-effective-

simulation?page=1

[SCA10] “Supervisory Control And Data Acquisition”

http://en.wikipedia.org/wiki/SCADA

[NIS08] “Technical Guide to Information Security Testing and Assessment”

http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf

[ISE10] “Open Source Security Testing Methodology Manual”

http://www.isecom.org/osstmm/

[CVE10] “Common Vulnerabilities and Exposure”

http://cve.mitre.org/

[EXP10]

http://www.exploit-db.com/exploits/9191/

[GFP10] LANGuard Pricing

http://www.gfi.com/products/gfi-languard/pricing

[PAY10] “Salary Snapshot for Penetration Tester Jobs”

http://www.payscale.com/research/US/Job=Penetration_Tester/Salary

[HON10] “Client Side Attacks”

http://www.honeynet.org/node/157

http://www.consumeraffairs.com/news04/2009/06/tjx_settlement.html

http://www.thetechherald.com/article.php/200905/2849/Does-the-Heartland-breach-prove-PCI-useless

http://www.thetechherald.com/article.php/200905/2849/Does-the-Heartland-breach-prove-PCI-useless

https://www.pcisecuritystandards.org/

http://www.networkworld.com/news/2010/012510-data-breach-costs.html

http://blog.metasploit.com/2007/09/root-shell-in-my-pocket-and-maybe-yours.html

http://www.compiere.com/

http://www.csoonline.com/article/221695/red-team-versus-blue-team-how-to-run-an-effective-simulation?page=1

http://www.csoonline.com/article/221695/red-team-versus-blue-team-how-to-run-an-effective-simulation?page=1

http://en.wikipedia.org/wiki/SCADA

http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf

http://www.isecom.org/osstmm/

http://cve.mitre.org/

http://www.exploit-db.com/exploits/9191/

http://www.gfi.com/products/gfi-languard/pricing

http://www.payscale.com/research/US/Job=Penetration_Tester/Salary

http://www.honeynet.org/node/157

defending the castle rwsp

Documents