[rokdownload menuitem="441" downloaditem="6" direct_download="true"]Click here to Download this Article[/rokdownload]

Defending the Castle by Actively Abusing It

Jesus Oquendo

C|EH, CHFI, OSCP, CPT IACRB, SGFA, SGFE
Chief Security Architect AEON Inc.

November 18^th, 2010

Abstract

Research indicates that current trends in information security threats outpace 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:

l gain a realistic view of our security posture

l rise above the security baselines set by organizations

l compare realistic testing versus vanilla / controlled testing

l increase security testing effectiveness

l minimize residual risks using focused, responsible and targeted testing

l 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:

l Patch management

l Vulnerability management

l Network and software auditing

l Assets inventory

l Change management

l 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

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 brute-forced 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.” Autopwn 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

1061/tcp open unknown

1099/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

No vulnerabilities exploited

Internal Compromise

Immunity Canvas

Compromise in 20 seconds

External Compromise

Immunity Canvas

No vulnerabilities exploited

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 accomplished 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.