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 GFI LanGuard 1 Warning 0 vulnerabilities
(no credential)
Internal Vanilla Test Acunetix Web Vulnerability Scanner 0 Warnings 0 vulnerabilities
(no credential)
External Vanilla Test GFI LanGuard 5 vulnerabilities (1 critical)
(low level credential) 3 potential vulnerabilities
External Vanilla Test Acunetix Web Vulnerability Scanner 4 warnings 0 vulnerabilities
(low level credential)

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 $3,500.00 (estimated) No IP restrictions
Canvas
GFI $32.00 main price 10-24 IP addresses [GFP10]
LANGuard
Core Impact $9,000.00 per quarter (unrestricted license)
(take note, pricing $10,000.00 per year per 8 IP's (single installation)
is based off a quote
from 2008)

Acunetix $4,995.00 perpetual license
WVS
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

Defending The Castle Rwsp

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (13)

Similar to Defending The Castle Rwsp

Similar to Defending The Castle Rwsp (20)

Defending The Castle Rwsp