Exploitation

As the final active part of your assessment, you may want to consider exploiting some of the vulnerabilities you have uncovered during the exercise. Assessments that include exploitation are normally referred to as penetration tests.

The big advantage to including exploits in your assessment is that they demonstrate, in a powerful way, the existence and impact of the vulnerabilities you have discovered. There are no false positives from a successful exploitation. If the exploit worked, you know there was a vulnerability. In addition, there is something much more compelling about having your proprietary data handed to you by a tester than reading a report that states that a vulnerability could potentially expose your organization to information exposures. Simply put, penetration tests can bring home the seriousness of vulnerabilities, in a way that other methods cannot.

The downside to penetration testing is that it is considerably more dangerous than vulnerability scans. It is not uncommon to have an exploit attempt crash its target. This can mean downtimeor worse, lost data. These tests can also take long amounts of time to perform properly, raising the cost of the assessment.

Careful planning precedes any penetration test. Systems that will be targeted should be recently backed up, and the administrators who manage the systems need to be readily accessible to resolve any problems that come up during the exercise. You should also plan to conduct the test during periods of low utilization. Taking down the order-entry system the week before Christmas would not make anyone happy with you!

You will also need to assemble your toolkit of exploitation software. Many sources of exploits are available on the Internet, some of them more reliable (and safe) than others. Good sites to start with are http://www.securityfocus.com/bid and http://packetstorm.widexs.nl. Keep in mind that it is common for Trojan code and other types of malicious software to masquerade as testing software. Be careful where you acquire your exploits. If source code is available, it should be examined, line by line, to ensure the tool only does what you expect it to. In addition, you should test each exploit in a lab setting prior to using it.

If you do not want to go through the trouble of assembling your own exploitation library, you can look into commercial products. One of these is Canvas (http://www.immunitysec.com/products-canvas.shtml). Canvas currently supports a library of over 50 exploits and is relatively inexpensive compared to other tools in this category. Another tool you may want to examine is Core Impact (http://www.coresecurity.com/products/coreimpact/index.php). Core Impact maintains a large library of exploitation methods. It also supports a robust logging system. Every action taken with Core Impact is logged, making it easy to document exactly what you did within the test. An open source alternative to both of these products is Metasploit (http://www.metasploit.com). Although Metasploit is not nearly as comprehensive as any of the commercial products, it's hard to beat the price.

The steps necessary to actually perform a penetration test can be complicated. Penetration testing by its nature is iterative. You will launch exploits that may increase your knowledge of a system or increase your access to a system. In both cases, this may lead to more exploits, which lead to more access and knowledge, and so on. Eventually, you will reach a point where no further exploits are possible or you completely control the systems you are testing. To focus this process, you may want to establish goal states for the test. For instance, you may want to specify that your goal is to reach administrative-level access on your payroll system. In this way, you can definitely determine when the test should end.

At the end of a penetration test, you will examine how far you got into the network and what information and access you were able to gain. In addition, you should go back and see what your server and intrusion detection logs recorded. Were your test efforts noticed? Did administrators take appropriate steps to respond to your intrusion attempts? This information is equally important to your documentation of the vulnerabilities you successfully exploited.

The quality of your documentation is at least as important as the work you have performed. You will need to keep careful records of what you did, when you did it, and what you observed. This is true of penetration tests as well as the overall assessment. In the next section, we will describe how to develop and organize the results of your efforts.