Sunera Information Security Blog

CMS Exporer in BackTrack 5

noreply@blogger.com (Chris Sullo) — Wed, 11 May 2011 14:53:00 +0000

Just a quick note that Sunera's CMS Explorer has made its way into the BackTrack Linux version 5 (Revolution) release! So no need to download it separately, just fire it up in BackTrack when you come against one of the supported CMS systems.

You can find it on the menus (which are now aligned by the PTES and OSSTMM standards) under CMS Identification:

BackTrack -> Information Gathering -> Web Application Analysis -> CMS Identification -> cms-explorer

And note that before you use it, you may want to supply an OSVDB-API key:

If you see this message, you need to add your API key.

And just a reminder that CMS Explorer is open source Perl code, so please consider contributing to the project. Additionally, it requires the GetOpt::Long module and LibWhisker--both of which are included in the BackTrack distro.

Put your OSVDB API Key in the $osvdb_api_key variable.

Thanks to the BackTrack team for continuing to enhance the pentesting distro and adding new tools like this (and others)!

4 Tips for Safer Gaming

noreply@blogger.com (Sunera Attack and Pen Team) — Fri, 29 Apr 2011 20:26:00 +0000

Did you recently receive an e-mail from the PlayStation Network (PSN) informing you that your personal information may have been lost? If so, you're one of many victims on a growing list for this year. Many hospitals, universities, and major companies such as Epsilon and Sony have all suffered similar data breaches in the first four months of 2011. Although data breaches are spreading to new horizons such as social networking and electronic health records, console gaming and associated processing systems are target rich environments that have been overlooked. This recent PSN breach serves as a wake-up call, drawing attention to the trust consumers put into these systems.

Whether you were affected by this breach or not, if you're a gamer you're probably wondering what you can do to bolster your security while gaming online. Based on our knowledge in network security and risk management paired with our team's personal experiences in online gaming, we've written a list of four potential steps you can take to play online, but keep your personal information as safe as possible.

1) Trust No One

We are being reminded on a fairly regular basis that our assumptions of trust in the online environment are unfounded. We may use visual indicators like a visually appealing online presence, padlock icons, highlighted urls and ‘hacker safe’ logos to help justify moving forward with online transactions and information submissions, however they are no indicator of *actual* security. Every single time you submit information to anyone, via phone, web form or jamming your credit card number into your gaming console, please stop and ask yourself “What would a bad guy do with this information?” If your answer would hurt your bank accounts, credit or present issues with identity theft consider other options. Specifically concerning transactions, review the alternative payment methods below. Further, consider having non-critical email account(s) available for more trivial registrations. The idea is to limit your exposure and risk. You will never eliminate risk entirely, but taking steps to limit damage can go a long way.

2) Utilize an Alternative Payment Method (Reduce your personal risk.)

Based on the recent loss of information, you may be less apt to trust online gaming networks with your information. Although little can be done to protect your contact information, it is possible to limit the exposure of your payment card data. Rather than exposing your card number, authentication code, and expiration data, consider these alternatives. Cards with points or credit in the gaming network can be purchased at many reputable retailers. These cards can be used to purchase items, games, and add-ons in the gaming network without exposing credit card data to them. Furthermore, it may be appropriate to leverage a limited use credit card. These cards may be generated by your online banking provider for one time use. Alternatively, consider using one of the many payment cards available with very low limits or allocated funds. Many banks offer a system in which parents can give their children cards with a certain cash value on them and refill the cards when needed. These cards may be ideal for less trusted vendors.

3) Segment your home network

In many ways, a console gaming system is like a network appliance. You have very little or no control over the software deployed on the system or how it interacts with the environment. In fact, many console systems use the universal plug and play (UPnP) protocol to open your home network up; establishing communications channels and opening ports to the outside. All of this is done with your implicit consent and, if you'd like to continue to participate in first person shooter (FPS) fun, you can't restrict those features.

Systems of this sort are often trusted less than others because they cannot be controlled or secured in the same fashion as PCs. When two distinct trust levels are present on a network, segmentation should be put into place. This segmentation, or grouping, of systems will help prevent attacks which depend on being in the same logical network as other systems. These attacks include man-in-the-middle style attacks and traffic analysis. These types of attacks could be used from a gaming console to intercept sensitive information between your PC and retailers or online banking systems.

Although it would be nice to implement a full featured firewall between your PCs and the gaming systems, an alternative type of segmentation is possible with many home routers. New routers often include segmentation features such as VLANs. You can assign the gaming console(s) in your environment to a VLAN separate from the rest of your systems. This will limit inadvertent exposure of PCs using gaming ports and keep gaming consoles on their own network. Of course, the underlying assumption here is your gaming console is not used as a media center requiring internal network communication - in which case more advanced preparation and setup may be required.

The following is a list of major, consumer-grade router manufacturers. Consult their website to determine whether or not your router supports network segmentation features, such as multiple VLANs:

DLink
Belkin
Cisco / Linksys
If your router does not support VLANs in vendor provided firmware, a custom firmware may be available which will enable this feature. If you are comfortable applying custom firmware (CFW) to your router, consider applying OpenWRT or DD-WRT to enable advanced features.

4) Consider the source of software

At the heart of a gaming console is a computer, one which has been optimized for accomplishing a single purpose, but a computer nonetheless. As a result, we should treat consoles more like our PCs. If a website were offering a custom version of a popular operating system, such as Windows or OS X, wouldn't you be wary of applying that to your computer? We should apply the same logic to custom firmware and console gaming software available on the internet. A common attack against PCs is to backdoor pirated software or video games and then make the software available on peer-to-peer networks. This attack vector would be highly effective against console gaming systems by deploying malicious game software or CFW.

Be wary of this software, evaluating and vetting software as much as possible before deploying it. CFW is not a bad thing and should be respected for the capabilities it provides consumers, but it should also be considered carefully by consumers as these CFWs become system level objects on gaming consoles when they are applied. This means that they have control over all aspects of the system.

Confirm the hash values of software against known, good values where possible to ensure that the software has not been changed or corrupted. Try to gather software from reputable sources as applicable.

The simplest answer to securing your information in this venue is to stop gaming online, but what fun is that? Keep these five things in mind to game safer and protect your personal information using a risk based approach.

When Distros (Sneak) Attack

noreply@blogger.com (Steve Tornio) — Thu, 10 Feb 2011 17:43:00 +0000

I was re-testing a list of findings from a prior engagement yesterday and eventually worked my way down to the "SSLv2" enabled list. These are pretty much the universal findings, since seemingly few people disable SSLv2 or weak ciphers when standing up a web server. Also, applying the recommended registry fix in Windows isn't always executed to perfection, so SSLv2 tends to linger.

For quick checks like this, I use OpenSSL from the command line:



steve@swt-work:~$ openssl s_client -ssl2 -host some.ssl.host -port 443

If you get a bunch of certificate information back, the site supports SSLv2. If you get an error, it doesn't. Simple, right? Maybe not. I got errors on the first seven or so sites, and that got my spidey sense tingling. Maybe they actually removed SSLv2 successfully on all these systems, but I remain suspicious. So, I tracked down some hosts known to use SSLv2 and all of them reported the same error.



19669:error:140A90C4:SSL routines:SSL_CTX_new:null ssl method passed:ssl_lib.c:1453:

It didn't seem to be an issue with OpenSSL itself, because connections to SSLv3 sites worked as expected. After a few moments of troubleshooting, I turned to Google. No definitive answer was forthcoming, but I did come across a mail list post that indicated that Ubuntu entirely removed SSLv2 from OpenSSL. I jumped onto another Linux distribution and did some parallel testing. OpenSSL in Ubuntu does not support SSLv2, and "null ssl method" is the only message you get. We reviewed the changelog and verified the change.



openssl (0.9.8o-1ubuntu3) maverick; urgency=low



* debian/patches/no-sslv2.patch: disable SSLv2 to match NSS and GnuTLS.

The protocol is unsafe and extremely deprecated. (Debian bug 589706)



-- Kees Cook   Tue, 20 Jul 2010 08:24:13 -0700

At this point, I was upset with Ubuntu for wasting my time, and fired off a tweet to that effect. Since I had another distribution available, I moved on with my auditing from there.

Then one of my co-workers wondered if Nessus SSLv2 scans worked on Ubuntu hosts. After some brief testing on other distributions, lo and behold, Nessus plugin 20007 (SSLv2 Enabled) does not recognize SSLv2-enabled servers. Anyone that has been using Nessus on Ubuntu 10.10 since July 2010 for scanning has been unable to detect SSLv2-enabled servers. That's an issue.

I took to the Nessus discussion forums for some guidance, since those guys are so quick to respond. It took all of 20 minutes for Renaud Deraison to reply:

I really like when vendors think they know better -- if a program wants to use SSLv2 they should not get in the way and decide it's bad, without looking at the context.

This probably means that in the not-so-long term, Nessus will ship with its own version of OpenSSL (as we do on Windows and in the "generic" builds).

So, the good news was that Tenable was planning to work around this distro nannyism by shipping their own SSL. The bad news was that we needed a fix in the interim, or our Nessus scans would be suspect.

I then noticed that Kees Cook came across my tweet and responded. After a brief exchange about the removal of SSLv2, he posted a step-by-step guide to reversing the no-ssl2 patch.



$ sudo apt-get install build-essential devscripts

...

$ sudo apt-get build-dep openssl

...

$ apt-get source openssl

$ cd openssl-*

$ quilt pop -a

...

$ sed -i '/no-sslv2.patch/d' debian/patches/series

$ quilt push -a

...

$ dch -n 'Allow dangerous v2 protocol'

$ debuild -uc -us

...

$ ls ../*ssl*.deb

Most of the instructions were familiar, but I hadn't used 'quilt' before. In this case, 'quilt pop -a' removes all patches, and the 'quilt push -a' adds all the patches in debian/patches/series once the "no-sslv2.patch" entry has been deleted. Then the debs are built and easily installed using the 'dpkg -i' command.

Nessus and the openssl s_client were once again able to connect using SSLv2 with the custom debs installed. I reported this back to the Nessus discussion forum thread, and Renaud once again responded with lightning speed.

Nessus 4.4.1 for Ubuntu 10.10 will ship with its own OpenSSL 0.9.8r. ETA is "very soon". Your solution is fine in the meantime, but it's a hack. In the long term, as distributions start to decide they know best about their users needs, we'll probably start shipping OpenSSL with more and more builds

So, in the long run, this will not be an issue for Nessus users on Ubuntu. In the short term, there is a workaround, but system updates will require extra attention, as OpenSSL needs to be rebuilt after every update.

Stuxnet and Cablegate - Harry Palmer wins again.

noreply@blogger.com (Joseph Schorr) — Thu, 20 Jan 2011 13:54:00 +0000

The two biggest data security stories of 2010 (and arguably of all time) are the weaponization of a computer virus targeted at a nuclear plant and the massive, unprecedented theft and disclosure of national security secrets from a secured military network. Under close examination, neither of these; Stuxnet nor Wikileaks/Cablegate, used a particularly exotic attack vector.

They happened because of the failure, again, of the organic component of information security. They happened because a disgruntled PFC, a high school dropout with apparently unfettered access to SIPRNET, brought writable CDs to work and proceeded to copy everything he could lay his mouse on. They happened because some nameless Russian contractor working for Atomstroyexport jammed a USB stick loaded with a worm into an Iranian PC. Yes, the worm was incredibly sophisticated. The method of delivery? Not so much.

Air gap? Meet 'the bridge'.

PFC Manning and 'Ivan Doe' have shown in big glaring headlines, that the best defenses can be defeated by The Gray Man. Harry Palmer, the 'Anti-Bond' spy and prototypical Gray Man, was perhaps the best fictitious example of this, the most dangerous of threats. Harry did not rely on gadgets from Q Branch or Parkour acrobatics, but used the best weapons available to an intelligence operative; he had the ability to blend in and possessed a cold, singular focus.

In retrospect, PFC Manning was the ultimate disgruntled employee. He was ticked off, had recently broken up with his boyfriend and was newly demoted. But he found himself sitting (along with over 3,000,000 other users with his clearance level, yikes!) at a job he hated and staring at the crown jewels of American information security. The unknown contractor was working at one of the most scrutinized construction projects on Earth - the Bushehr nuclear plant. But given an environment where the host nation had to rely almost entirely on foreign nationals to build their facility, it was most likely child's play to bring in an autorun-capable thumbdrive loaded with a viral weapon and find a nice open USB slot or slots to infect.

The successes of Stuxnet and Cablegate are not surprising, nor is the attack vector. Anyone who has done any Social Engineering testing can tell you a myriad of ways to contravene physical and logical security measures. Most of the those techniques involve blending in with the rest of the sheep and taking advantage of the fact that once you get past the perimeter and are a 'trusted' member of the flock, you pretty much have free rein.

It takes a thief...

The way to combat disgruntled employees or hostile intruders from stealing or corrupting your confidential data is by following the old tried and true methods: concrete, realistic security policies and user/employee awareness training. But this needs to be reinforced with something that not enough organizations implement - Regular, unannounced Red Team penetration testing. Penetration testing with a strong social engineering component serves two purposes:

It demonstrates your vulnerability to new, current attack profiles and exploits. That's good, not bad! An experienced and effective Red Team will most likely find holes you never knew existed and will provide you with a detailed After Action Report complete with remediation advice.
It serves as an awareness reinforcement tool for you employees. If they've experienced Red Team attacks, have seen the repercussions and know they are going to be hit again at random times, it tends to make them take all that training a lot more seriously.

Is there is a silver lining to be seen in all of this? Perhaps. Perhaps the high-profile nature of the exploits will finally result in attention being paid to that most dangerous of threats: your very own Harry Palmer wandering around your building.

Free Online Cyber Security Awareness Training

noreply@blogger.com (Joe Sechman) — Thu, 08 Jul 2010 18:17:00 +0000

As a consultant, I find it extremely difficult to meet continuing professional education (CPE) requirements by carving out time to attend instructor-lead training courses. While there are many different ways to earn CPE's, I prefer self-paced, on-line training. As luck would have it, I became aware of several *free* on-line training courses offered by the Texas Engineering Extension Service (TEEX) at http://www.teex.org. They have a large selection of free courses delivered using an intuitive Adobe Flash interface.

In the area of cybercrime, a relatively new course catalog has been added that covers topics such as secure programming, information security basics, business continuity, and digital forensics, among other titles.

A few nice features of the training delivery include:

A pre-assessment quiz to measure your current mastery of the topic. Subsequent to the quiz, you receive your score and know where you need to focus your training efforts to fill any knowledge gaps.
Free-flowing modules that allow you to skip around to areas you want to tackle first.
Copious references for further study.
Useful material that is both relevant and pertinent in today's environment.
You receive an official PDF certificate for your records so you can submit as proof of course completion.
Most importantly, it's both on-line and FREE!

In addition, there are other subjects relating to domestic security and threat awareness that are both offered on-line and during scheduled, instructor-lead courses.

I hope you find it as useful as I did, and hopefully this makes it a bit easier to stay current with your CPE's.

More on WebDAV Testing

noreply@blogger.com (Chris Sullo) — Tue, 04 May 2010 15:55:00 +0000

Since the release of DAVTest, there have been two developments which seemed worth mentioning here:

Ryan Linn released a Metasploit module based on the DAVTest idea. Like DAVTest, it attempts to use mathematical operations to determine if code can execute on the web server.

Chris Gates posted a good article titled "More with Metasploit and WebDAV," which gives a nice tutorial on how to exploit misconfigured web servers using Ryan Linn's module with Metasploit. It also points out a nice ~~trick~~ feature with IIS/ASP.

I'm glad the idea of using simple/standard operations is spreading to other tools, as it's a really efficient way to determine what you can and can't do remotely via WebDAV. What we need are simple tests (and back-doors) in more server-side languages.

I'm going to try and whip up a new release of DAVTest in the next week or so, incorporating a few ideas from these guys, as well as a bit of housekeeping and other updates.

If you have suggestions for the next release or tests for more languages, reply here or send me an email.

DAVTest: Quickly Test & Exploit WebDAV Servers

noreply@blogger.com (Chris Sullo) — Tue, 27 Apr 2010 19:11:00 +0000

When facing off against a WebDAV enabled server during a penetration test, there are two main things to find out: can you upload files, and if so, can you upload executable files?

Testing this can be a little tricky depending on the server configuration--what extensions are you allowed to upload, can you use MOVE, and what about MKCOL?

DAVTest attempts help answer those questions, as well as enable the pentester to quickly gain access to the host. DAVTest tries to upload test files of various extension types (e.g., ".php" or ".txt"), checks if those files were uploaded successfully, and then if they can execute on the server. It also allows for uploading of the files as plain text files and then trying to use the MOVE command to rename them to an executable.

Assuming you can upload an executable, a test file does you no good--so DAVTest can automatically upload a fully functional shell or back-door. It ships with shells for PHP, ASP, ASPX, CFM, JSP, CGI, and PL, and dropping a file in the right directory will let you upload any back-door you like.

DAVTest is written in PERL and licensed under the GNU GPLv3.

Project files, Docs and Wiki: DAVTest at Google Code
Download: davtest-1.0.tar.bz2 or davtest-1.0.zip

CMS Explorer (or: what's that CMS running?)

noreply@blogger.com (Chris Sullo) — Wed, 31 Mar 2010 13:47:00 +0000

As a developer, as well as a penetration tester, it's often helpful to know what components a site uses to turn it from a vanilla content management system (CMS) into a more useful site. Besides Mediawiki, I'm not aware of any CMS which publicly lists installed components--so the only way you can figure it out is manually or through small clues on the site.

CMS Explorer is an attempt to automate this component discovery. By brute-force requesting directory names for plugins and themes (and with "normal" HTTP responses--at least for now), we can determine which directories exist, and thus which components are installed. The end result is a list of installed items:

What makes CMS Explorer powerful for penetration testing is what happens next. If you use the -explore option with Drupal or Wordpress, the program will pull a list of potentially-existing files directly from the respective CMS code repositories, and then request those files from your target

And just to make it a little more useful (especially "explore" mode), you can also specify a "bootstrap" proxy. If defined, any found file will be requested a second time using this proxy--so you can prime up your favorite proxy (such as Burp or Paros) for doing actual security testing of those files. This proxy is distinct for found items rather than your main scanning proxy, in case you have one of those setups.

And lastly, if you supply an OSVDB.org API key, it can search and report back a list of potential issues in the installed component.

CMS Explorer is currently set up to test Drupal, Wordpress and Joomla!/Mambo, with exploration support for Drupal and Wordpress. It is written in PERL and licensed under the GNU GPLv3.

Project files and wiki: CMS-Explorer at Google Code
Download: cms-explorer-1.0.tar.bz2 or cms-explorer-1.0.zip

New MasterCard Rules for PCI

noreply@blogger.com (Christie Verscharen) — Tue, 26 Jan 2010 17:04:00 +0000

As many of you are already aware, MasterCard announced in early 2009, changes to Merchant PCI DSS validation requirements under its Site Data Protection (SDP) program. These changes were primarily related to 1) the ability for Merchants to utilize Internal Audit (IA) to conduct the annual onsite assessment and 2) the imposition of more stringent validation requirements for Level 2 Merchants.

In recent weeks, MasterCard has again updated its merchant validation requirements.

http://www.mastercard.com/us/sdp/merchants/merchant_levels.html

To summarize the updated MasterCard requirements:

- Level 1 Merchants may continue to utilize IA to perform the annual onsite assessment, as long as (effective June 30, 2011) the IA staff engaged in validating PCI DSS compliance attend PCI SSC-offered Merchant training programs and pass any PCI SSC associated accreditation program annually.

- Level 2 Merchants are permitted to continue to complete an annual onsite self assessment questionnaire. Alternatively, Level 2 Merchants may, at their discretion, complete an annual onsite assessment conducted by a PCI SSC approved QSA rather than complete an annual self-assessment questionnaire.

- Level 2 Merchants that choose to complete an annual self-assessment questionnaire must ensure that (effective June 30, 2011) staff engaged in the self-assessment attend PCI SSC-offered merchant training programs and pass any associated PCI SSC accreditation program annually.

We are working with our merchant clients to help them navigate the often complex and dynamic requirements associated with maintaining continued compliance with the PCI DSS.

Physical Breach Assessments: Creating IMPACT

noreply@blogger.com (Chris Patten) — Thu, 17 Dec 2009 22:08:00 +0000

The new year finds me refining methodologies and frameworks with a revived ambition to perform more physical security breach assessments. What is a breach assessment and why would anyone want to exceed the regulatory requirements of a logical penetration test? Answer...because some organizations take security a bit more seriously than others. Specifically, certain organizations need the extra assurance that they are less susceptible and more adequately protected from prevalent ailments that plague unfortunate news-worthy groups.

A breach assessment can incorporate a magnitude of test scenarios; however, the analysis is still fundamentally the essence of deriving effective and defective physical security controls in an attempt to assess the level of skill and effort necessary to breach security. For instance, a skilled lock-pick can bypass a relatively sophisticated physical access control much easier than a less experienced individual. Alternatively, the less experienced person may not bother with locks when they could just card the door or remove it altogether. Both of these scenarios are permissible and should be evaluated as part of a comprehensive breach assessment.

A breach assessment can simply test the effectiveness of physical security, or incorporate the logical penetration testing frameworks. As a result, this scenario often provides the insight into the specific infosec resources an intruder can leverage during the breach/penetration study. These opportunities may present themselves within the reconnaissance or planning phase as prepared email solicitations for a fabricated on-site visit. Alternatively, an opportunity to compromise a "not so" closed circuit IP based camera system may provide the needed leverage to circumvent physical detection during the testing phase.

Overall; and potentially the most important factor, is the ability to illustrate the requirement for more secure access controls through the use of impact. Upper "C-Level" management typically does not require nor do they need intricate details concerning the technical and/or procedural methods produced during the engagement. However, if the facts are consolidated and presented in a manner that portrays the most critical breach scenarios, then the organization is more inclined to obtain support and funding for remediation efforts.

The statement, "The server is prone to SQL injection attacks which could lead to compromise of PCI data" is far less effective than "The test team was able to enter the processing center from the loading dock and grabbed all the credit card numbers from our database". The second statement should have grabbed the executives attention.

In conclusion, a penetration test is a worthy effort to effectively assess an organizations logical security posture; however, a physical breach assessment can provide additional insight when performed in conjunction. The easiest choice in not always the most appropriate, so weigh the estimated value of compromise to your organization and choose the most appropriate approach.

--Chris Patten

Vulnerability Assessment or Penetration Test: How do I decide

noreply@blogger.com (Chris Patten) — Thu, 17 Dec 2009 21:35:00 +0000

Many organizations may be reeling from the decision on whether to perform a vulnerability assessment or a comprehensive penetration test, and rightfully so. These are difficult decisions and often require knowledge of specific industry regulations and mandates. Maybe an organization feels that they have too much at risk and would like to leverage an unbiased outsider's expertise regarding how to provide the necessary level of infosec protection, or may have unfortunately been a victim of compromise. Let us provide some some assistance with this decision.

Requirements gathering for manual/automated penetration should be based on a multitude of items. This is extremely important as many businesses are different and their requirements may not necessitate a complete penetration assessment. Some of these requirements may be:

Sensitivity classification associated with the resident system/app data
What environment does the system/app currently reside
What are the requirements for service availability
Security reviews as an integral step of the SDLC process
Impact to the business (reputation/revenue) if compromised

These are just a small number of the questions that should be asked when performing the initial determination of the organization's next steps. As a result, answers should lead to questions, which should lead to hypothetical scenarios that may be documented via threat modeling exercises; however, this may be performed as a precursory step to a complete penetration test.

The important item to note is that vulnerability assessments and penetration tests are very different but are still very dependent on each other. For instance, before a penetration test can be executed, some level of information and vulnerability gathering is necessary. This typically, comes in the way of a vulnerability assessment. The goal is to document/map application and system vulnerabilities back to industry security standards that may be used for overall remediation. The vulnerability assessment can stop there and the outcome may be for an organization to remediate the findings ranked by severity. It is worth noting that my personal opinion, and that is all it is, leans towards the fact that any mention of an automated penetration test is simply a vulnerability assessment as much of the human intervention, observation, and extrapolation is removed from the process. Although for quick hit items like vulnerable services at a network level (eg. exposed SNMP, mgmt interfaces, defaults, etc...), this may be an adequate solution. The security issues identified within this process, along with manually derived vulnerabilities, will be investigated further during the penetration testing phase if authorized by the business.

The Penetration test should, if performed correctly, identify items that a vulnerability assessment (aka. 1-click pen test) typically cannot find. This is most prevalent within web application testing, for instance. Items like concurrent session management, advanced cookie/token vulnerabilities, vertical/horizontal privilege escalation, decompilation issues, and second order injection will not be caught by automated solutions. Additionally, many of the more severe vulnerabilities should be documented to illustrate proof of concepts used to provide exploit root cause and potential impact scenarios to management.

In conclusion, it is my opinion that a penetration test should be used when the data or system imposes a level of risk that the business is not willing to accept and needs to ensure detective, preventative, and corrective controls are in place to safeguard the asset. This may be performed on both test and production systems and typically on an annual basis, but may be driven by regulatory requirements. The vulnerability assessment should be used as more of a detection method to provide insight into the effectiveness of simple organizational patch and configuration management standards and procedures. By no means, am I discounting the necessity of both a vulnerability assessment and a penetration test. Obviously, both have their place and should be an integral part of organizational policies.

--Chris Patten