Because penetration testing can be a dangerous activity, it is imperative that a penetration test lab be completely isolated from any other network. This produces some problems, such as having no Internet connection to look up vulnerability and exploit information or to download patches, applications, and tools. However, to guarantee that nothing in your network leaks out, you must take every precaution to make sure your network does not communicate with any other network.

Admittedly, this becomes problematic when your network contains wireless appliances. In most cases, penetration testing is conducted over wired connections, but on occasion wireless networks are valid penetration testing targets. This presents a difficult question: How do you isolate a penetration test lab with wireless access from other networks? The answer: You do not; it is not necessary.

To explain what that means, we'll talk a bit about the objective of hacking a wireless access point. In a real penetration test involving a wireless network (or any network, for that matter), first the penetration test team needs to gain access to the network. It doesn't matter whether that connection is via the wireless portion of the network or a plug in the wall. All that matters is that access is established. Once the network access is accomplished, the penetration testers move on to selecting targets using techniques that work over either wireless or wired networks (it does not matter which).

So, back to the question of how you isolate a penetration test lab with wireless access: You should have two separate labs: a wireless lab where you only practice breaking into the wireless access point, and a separate lab where you conduct your system attacks. Once you feel confident you can break into the network over the wireless lab, you should move over to the wired penetration test lab and give yourself the same access to that network as what you would have by penetrating the wireless access point. That way, all future attacks are isolated and are not exposing other networks to your efforts. In addition, your activities cannot be monitored, which is not necessarily the case over a wireless network.

In situations in which multiple wireless access points are in the vicinity of your wireless lab, you must be extremely careful that you attack only your lab and no other wireless network. After scanning for wireless networks, make absolutely certain that any cracking against the access point is really performed against your intended target. It is sometimes extremely easy, especially with automated tools, to target and test an unintended target. This can have very negative consequences.

The good thing about wireless attacks is that the standard practice is to pinpoint your attacks against one access point using the Media Access Control (MAC) address unique to your lab's wireless access point. As long as you are careful, there should be no problem. However, if this is not acceptable, it is possible to shield a room from leaking out radio waves (which we will not cover in this chapter). If you or your employer decides it is important enough to do, you can create a completely isolated wireless network with enough effort and funding. Whatever you do, just understand that you will be dealing with viruses, worms, and more, which can quickly bring any network to its knees.

Just as you do with any other network, you have to secure the penetration test lab from all unauthorized access. There actually seems to be some resistance to this thought, mostly because additional physical access controls cost money. Nevertheless, you must remember that lab activities are very sensitive in nature, and the configuration information of the penetration test lab network is valuable in the wrong hands. Because the penetration test lab should mimic the customer's network as closely as possible, getting access to the penetration test lab is almost as valuable as gaining access to the production network.

Some of the things a malicious user would like to know are the IP addresses of machines, operating system versions, patch versions, configuration files, login files, startup scripts, and more. Even the data from a penetration test lab could be valuable to people trying to attack your client because you often need to use the same IP addresses as the customer. Some custom applications can sometimes be hard-coded with IP addresses for communication reasons which won't work correctly unless you use the customer's IP addresses. With this type of information in hand, a malicious user can build a better picture of what the production network is like, and what possible vulnerabilities exist.

Even though a penetration test is isolated, you must assume that just like any other network, someone (usually other employees not assigned to the penetration test team) will eventually try to break into it. In fact, most companies have at least one insider attack each year, meaning that chances are someone in your company or your client's company will violate the law and try to gather information he or she is not allowed access to. If this is information regarding a penetration test customer, your company (and those individuals on the penetration test team) could be exposed to legal action. Therefore, it becomes very important to follow security best practices. Penetration testers should be paranoid and expect mischief from all directions, even those internal to their company.

This type of threat does not always end up being malicious. Sometimes it is simple over exuberance on the part of employees. An example of this would be performing a software stress test. The point of the test could be to see if the software quit working when too much traffic was thrown at it. Assume, however, that during the test an exploitable bug was found. Naturally, the software engineers would be excited because it was something new for them to watch and learn. But what would the impact be if they accidently shared this information with one of the company's clients before a patch is developed?

In some cases, you cannot prevent information regarding the penetration lab from being disclosed. The casual observer will probably be able to read the appliance label on a device; logos such as those for Cisco and Sun are easy to identify. This means things such as router and firewall types are difficult to conceal, unless the lab is located in a secure room with no windows.

But for servers, it is easier to hide what is loaded on the inside. A person cannot tell whether you are using IIS or Apache strictly by looking at the server, unless you leave the install disks lying around the lab for all to see. This leads into another security practice most people ignore: proper storage of software.

In a penetration test lab, you will use many different types of operating systems and software applications. It is important to store these disks in a secure manner, for two reasons. First, disks grow invisible legs and tend to walk out of your lab (intentionally or not). Second, you have to ensure the integrity of the disks you work with.

With regard to install disks “walking out,” anyone who has had to support a network finds himself short of disks. Sometimes it is because people borrow them, or sometimes the network administrators forget and leave disks in CD trays. You can prevent this by enforcing detailed procedures. However, the issue of install disk integrity is a more serious matter. Some operating system and patch disks are delivered through well-defined and secure channels (e.g., the Microsoft MSDN subscription will mail updates). However, more often than not, patches and updates are downloaded over the Internet. How does a person who downloads software over the Internet know that what he is downloading is a true copy of the file, and not corrupted or maliciously altered? Through hashes.

Although few people do this, all applications and software downloaded for use in a penetration test lab should be verified using a hash function. The most popular is MD5, and for those security-conscious people and companies that provide downloads, a published MD5 value is usually associated with each download. Once the pen-test team has downloaded a file, they must verify that they have a true copy of the file by conducting an MD5 hash against it, and comparing it to the file author's published value. Then they should record the value somewhere for future reference, such as a binder stored in a safe.

You should run MD5 hashes against the install disks regularly, especially before you use them in the pen-test lab. This assures the penetration test team that they are using a true copy of the file. Verifying the hash can often provide defense against someone using the wrong version of the intended application. By comparing the MD5 hash of an application against a printed list, you will quickly know whether you have the wrong disk or file. This extra validation is a valuable safeguard against innocent mistakes that can ruin weeks' worth of work, if the wrong software is used by accident. Explaining to a boss that you have to repeat a two-week penetration test effort because you used a wrong software version can have a nasty result, especially during your next performance review.

Once you have completely isolated your lab network from other networks, you need to design a safe way to bring data into the network. If you need to bring any patches, code, or files onto the lab network, you must do so in a manner that prohibits any data on the lab network from escaping.

Imagine the following scenario; you recently attempted to break into a target using a virus that conducts a buffer overflow attack. Let's also pretend that once successful, the virus tries to find other vulnerable systems on the network to spread itself. However, you did not realize that this virus, when successful, also attempts to replicate itself through USB devices by dropping itself on the device and modifying the autorun file.

Now imagine you are trying to upgrade the server using a thumb drive, which immediately becomes infected. You eject that thumb drive from the pen-test network, take it back to your non-lab Internet-connected work computer, and plug it in. The Autorun feature kicks off the virus, and the next thing you know, the IT department is calling you, asking you what you did to the network.

The only safe way to transfer data is to use read-only media such as CDs or DVDs. However, even these can be dangerous if you do not use them properly. One feature that is present with most CD and DVD writers is the ability to not close the disk when finished. This feature allows additional data to be copied to the disk later. Although there is no known virus or worm that copies itself to CD-ROM disks as a means of propagating itself, it's possible that someone will develop such a thing (remember, paranoia is a virtue in this field).

This means that you should close all CDs and DVDs after transferring the desired data to the disks and before moving them into the pen-test environment. In some cases, the amount of data being copied onto the disk is very small—perhaps just a few kilobytes—whereas a CD can hold 650–900 MB. This is a necessary expense, and it requires some additional planning before you create any CD. Try to anticipate additional files you might need, and add them to the disk as well.

Nothing is more frustrating than picking up a non-labeled CD and trying to guess what might be on it. If that CD has malicious software on it and someone who is not on the penetration test team picks it up, the results could be a nightmare. What is worse is if computer systems or devices that you have been using in your lab are transferred temporarily to another group because they need the equipment for some reason. Whatever virus existed on that equipment just got a free ride to wreak havoc on a new and possibly defenseless network. That is where labeling comes in.

All media, appliances, systems, and devices that touch the pen-test lab must be labeled. In the case of hardware, this should be done with indelible ink, on stickers that are affixed. This does not mean sticky notes; it means something that will stay on the device until someone removes it intentionally, with great effort. Hopefully, these labels will make people think about the consequences of transferring hardware from one network to another without proper sanitization procedures.

As for media, once you have burned the data onto the CDs or DVDs, you should use a marker or printer to apply a label to the media. This should include detailed information regarding the contents, as well as a warning concerning the dangers of the contents.

In addition, you should make clear that the lab area is off-limits to unauthorized personnel. The best scenario is to have a separate room with locks to contain the lab, along with posted warnings regarding the nature of the lab.

Another critical topic when securing non-lab networks from exposure to hostile attacks is to have a firm and comprehensive plan in place to deal with all the extra CDs and DVDs floating around. In addition, eventually the equipment in your lab will be replaced or removed. The last thing you would want is to have someone plug an infected server into a production network without the server first being completely cleaned of any potential hazard.

In a lot of ways, proper disposal and sanitization of anything touching your lab is easier to grasp if you imagine that computer viruses and worms are biohazards, instead of just IT hazards. Just like in a doctor's office, you should have a trash receptacle labeled with a hazardous waste sticker in your lab, and you should shred (not just trash) the contents of the receptacle.

All CDs that touch any system on the pen-test lab should go straight to this designated trash bin as soon as they are no longer being used or needed. CDs should not sit in any disk trays, in case they are forgotten and accidentally used later. All hard drives and reusable media need to be properly degaussed before use outside the pen-test lab. In addition, a procedure should be in place to record what was done and how it was done for each piece of equipment removed from the lab network. The information recorded should include the device serial number, what method of sanitation was used, who sanitized the device, and who it was given to afterward. These records should be maintained in a secure area as well.

Although it may seem that this is excessive and bordering on the paranoid (which is encouraged in this job), if a production system gets infected later, whoever was responsible for that infection will be looking for a scapegoat. If the infected system uses a hard drive that came from the penetration test lab, fingers will quickly be pointed in that direction, deflecting responsibility from the real culprit. However, by having a record of how and when the drive was sanitized before moving into the production environment, the penetration test team can rightly avoid the blame.

Also, after each penetration test project, the lab should be completely sanitized. This means all drives should be formatted and all sectors overwritten with meaningless data. In fact, if the hard drives can be sanitized to Department of Defense standards per their publication 5220.22-M (available at http://www.dtic.mil/whs/directives/corres/pdf/522022m.pdf), all the better. Remember, the data on the drives is sensitive in nature, and the more cautionary your team is, the better. In addition, you do not want data or scripts from a previous penetration test project corrupting your new test environment.

Penetration testing is not all fun. At the end of any test, you need to document all the findings. You must be careful to write, transport, and archive this information in a secure manner. All other security efforts are meaningless if a malicious person can acquire the final penetration test report with all the glaring deficiencies and exploitable vulnerabilities, summarized with pretty pictures and specific steps needed to bring the target network to its knees.

As a best practice, all computers need to have safeguards at least equal to the value of the data that resides on them. For the computer on which you write your report of findings, protections need to be in place to ensure that the report does not end up in the wrong hands. Your corporate policy should outline the minimum level of effort needed to secure your system. However, it is almost always acceptable to go beyond this minimum level. So, in cases where it does not seem that the corporate policy is sufficient, here are some suggestions that can improve your protection:

Often, during the course of a penetration test, exploitable vulnerabilities are discovered. These vulnerabilities might not have an immediate solution to prevent the exploit. This means if someone discovers that vulnerability, he just might have complete and unfettered access to the customer network, and all the data that resides on it. Lack of security of the penetration test lab can have a huge negative impact on the business objectives of your organization and/or customer. If the vulnerabilities are leaked to the public or to your customer's competitors, you might quickly find yourself being escorted off company property carrying a cardboard box with all your stuff in it, and the company you work for could end up trying to protect itself in a court of law.

Because of the sensitivity of the information used and discovered during a pen-test project, you should use and review at least annually industry-recognized best practices. After all, the penetration test team is part of an overall security strategy, and if IT security members do not follow security best practices, who should?

If you are just starting out learning how to conduct penetration testing, the best lab is a simple one. The smallest you could make it would be to have one system with virtualization software that can emulate multiple operating systems. Although this can actually be a very useful technique, it does not reflect the real-world network in today's corporate environment. However, if you are simply concerned with attacking a system and not worried about navigating through a network, a virtual penetration test lab provides a wealth of possibilities.

Virtualization software has become quite complex and versatile in the past few years. Also, different types of virtualization software are available, from the simple (designed for the desktop) to the complex (designed to house multiple systems for large corporations). In most cases, the less complex virtual machines are quite sufficient for the task at hand. However, if you need to set up complex scenarios, you might want to look into obtaining something designed for corporate use.

We should point out some problems regarding a virtual penetration test lab. Some of today's more sophisticated viruses check for virtualization before launching their malicious payload. This means that if you are using one of these viruses to attack a virtual server, you will not get the results you might expect.

Viruses are checking for virtualization because nearly all anti-virus researchers run new viruses within a virtual environment. They do this because it is much easier to contain a virus within a virtual network, and it is easy to return the virtual server back to a pristine and uninfected state. A lot of advances have been made to hide the use of virtualization software from viruses, but the state of this war between virus and virtualization writers is constantly in fluctuation. In addition, to be fair, it is not really the job of virtualization software manufacturers to be fighting this fight. Their main goal is to sell their software to all potential customers, not just to anti-virus companies. It is best to assume that if you use virtualization software, viruses and worms will not work properly.

Most beginner labs consist of two systems connected through a router. One system is the target, the second system is the penetration tester's machine, and the router is there to provide network services, such as DNS and DHCP. This setup, although simple, actually simulates most internal penetration tests because in the “real world,” the penetration tester is given internal network access in these situations anyway. The objective of internal penetration tests is to see exactly what vulnerabilities exist on the corporate network, not to see whether someone can break into the network. It is usually assumed, when tasked with an internal penetration test project, that someone who has enough time on his hands will eventually succeed in getting into the network (which is a very valid argument, especially considering how many attacks are from employees). With an internal penetration test, you can find out exactly what he might grab once he is in.

Although having two systems and a router is pretty simple, the internal penetration test lab can get quite crowded, depending on what you are trying to accomplish. By adding intrusion detection/prevention systems, proxies, syslog servers, and database servers, you can create a complicated network quite quickly. However, these add-ons are required only if you have a specific reason to have them. Usually, if the goal is to learn how to hack into a web server, you need only one server. Often, you can reduce the complexity of a more complicated scenario into something more manageable. For instance, take a scenario that involves a remote MySQL server with load balancing systems. In this case, you could default back to the “two systems and one router” scenario, and just load the web server and MySQL onto the target system. If the object is to break into the web server from the web portal, it does not make sense to reconstruct the more complex setup if there is only one “port of entry”: the web interface.

As with anything, you should keep things as simple as possible. Unless it is necessary, try to limit the number of machines in your lab. This will save you money and time in the long run.

The external penetration test lab follows the principle of “defense in depth.” You must make sure you build an external penetration test lab to reflect this concept. That means you need to include a firewall as a bare minimum. Designed to keep the bad guys out, a firewall can be a difficult boundary to get past. However, as with most things in life, there are exceptions. Often, it becomes necessary for firewall administrators to create gaps in the firewall, allowing traffic to enter and leave the network unfettered. There is usually a business reason for having the hole opened, but sometimes holes are left open by accident, or because there is an expectation of future need.

In external penetration tests, the object is to see whether there is a way to penetrate past various obstacles in the network, and gain access to a system behind these defenses. This is a much more difficult scenario, but one that you need to practice mostly because, even though it is difficult, it is still possible to achieve and knowing how to achieve this will give you the ability to prevent it in the future.

Other defenses include the use of a Demilitarized Zone (DMZ), proxies, the Network Address Translation (NAT) mechanism, network intrusion detection systems, and more. Naturally, the more defenses you include in this lab, the closer you get to mimicking real-world corporate networks.

Although this type of network is very realistic, it can also be the most daunting for the uninitiated. For those penetration test teams that have access to network design architects, it would be extremely beneficial to solicit their advice before building this type of lab.

Sometimes a project comes along in which you must create an exact replica of the target network. This might be necessary because the production network is so sensitive (e.g., makes too much money to mess with) that management cannot risk any downtime. In this case, the penetration test team needs access to the same equipment as what is available in the target network. These types of labs are rarely built due to the large expense, but they do exist. In most cases, however, a test lab (used to test patches and updates) is used instead. This has some cost savings, but unless the test lab is secured to the safety requirements mentioned in the Safety First section of this chapter for a penetration test lab, this multi-use function of the test lab can pose some security problems that you need to address before commencing any penetration tests.

Extreme attention to detail is required when building a project-specific lab. As mentioned, you must use the same brand of equipment, but it does not stop there. You need to use the same model hardware with the same chip set, the same operating system version, the same patches, and even the same cabling.

Although this may seem a bit excessive, in the past manufacturers have changed chip suppliers in the middle of production without changing the model number, making one version act differently than another under penetration testing. In addition, different operating systems and patches have dramatically different vulnerabilities. Even network cables can alter the speed of an attack, changing the results (a slower network might not show that a server is susceptible to a denial-of-service attack). In other words, if you do not replicate the lab down to the smallest detail, you might get invalid test results.

This lab grows more on whim than need. Often, this type of lab is used to test one specific thing on a server; perhaps a new patch (that affects only one service on the server) needs to be tested, or traffic needs to be sniffed to see whether there are any changes to what is being sent. In these cases, it really does not make sense to go through the hassle of setting up a penetration test lab that mirrors the network housing the server in question. It is justifiably easier to just throw something together for a quick look.

Although this is usually never done, for optimal results a formal process should exist to determine exactly which type of lab is needed for each penetration test project. However, often a lab type is picked not on what is best for the project, but on what is already “set up” and in place. Rather than tear down a lab, it is easier to simply reuse one that is currently in place. Even though it may be easier, it can also be the wrong decision.

When a formal process is in place to determine which lab should be used for each project, the team's project manager has one more tool at his disposal to determine project priorities and time lines. If additional resources need to be brought into the labs, the project manager can group together those projects that require that additional resource, better utilizing corporate assets. In short, the choice of how to set up your lab is an important consideration and should be part of a formal decision process.

Regardless of our personal backgrounds, it is important to focus on what is really happening in the corporate world. For example, a penetration tester may have experience (and prefer) Solaris of AIX-based systems, but many organizations choose to use Microsoft on x86 processor chips. Therefore when building your penetration test lab, you should ensure that your hardware supports what is commonly used in the corporate world, not your personal preferences.

Most penetration test teams are made up of people with different skill sets and backgrounds, with networking and system administration being the two primary skill sets. Sometimes the group's experience will dictate the decision of what hardware to purchase. If everyone on the team is familiar with x86, this commonality forces the issue; otherwise, hardware sits around unused.

In some cases, a pen-test team will have a particular mission. Perhaps it is to conduct primarily web-based attacks, in which case the focus needs to be on firewalls, proxy servers, and web servers. If a team is mostly concerned with network architecture vulnerabilities, hardware appliances such as routers, switches, intrusion detection systems, and firewalls become important.

Another approach for determining the use of a particular architecture is to look at how many exploitable vulnerabilities exist. If you want to put together a penetration test that has a higher level of successful penetrations, take a look at sites such as http://www.securityfocus.com/bid and see which platform has the greatest number of available exploits.

This may be a bit obvious, but if your clients use a particular architecture, your penetration test lab should probably have the same thing. This has a drawback, though. All new clients that you contract with need to have the same type of equipment as well, or else you will end up buying extra equipment every time you get a new customer. This can have a limiting effect on expanding your business.

There is a drawback in selecting only one architecture on which to run penetration test projects; by limiting your architecture, you are limiting who your customers can be. This is not always bad, though. If your team focuses on a niche target, such as supervisory control and data acquisition (SCADA) systems, your penetration test team could have more work available than they can handle. Nevertheless, by using only the equipment that your clients use, your team will be able to focus their energies and knowledge better, while also keeping costs down.

Often, by using what your clients use, you run into a situation in which nobody on your team is a subject expert, especially in a niche market. This has the unwanted effect that the money you save (by not buying all the possible equipment combinations available) can get diverted into hiring expensive subject-matter experts. Often, hiring a subject-matter expert is just not in the budget. If this situation is familiar to your penetration test team, the team members end up needing training. This is great for the team members because they get to improve their skills, but these training costs are not always expected by management and can cause poor results in actual penetration test projects if not committed to. Remember, niche training (and penetration testing is a niche training field) is much more expensive than the more common ones, something management may not be happy with, or accustomed to.

If you purchase a Cisco PIX firewall, you are only going to use it as a firewall. However, if you decide to use a software-based firewall on an x86 system, you can use that same system later for an intrusion detection system, a web server, a syslog, or other server. Versatility becomes important when purchasing budgets are tight.

Other hardware concerns include external devices, such as tape backups, monitors, external hard drives, and the like. Internal storage devices, such as secondary hard drives and tape storage, tend to be underutilized. It is often better to purchase the more expensive external versions of these devices that will get a lot more use in the long run than to purchase the cheaper internal versions.

A favorite among system administrators is the KVM switch, which allows multiple computer systems to use the same keyboard, video monitor, and mouse. Not only does it save on the purchase of additional monitors, but also the electricity savings can be quite noticeable.

Again, planning becomes important in building your penetration test lab. Hardware can be a significant expense, and can quickly become obsolete. With the right approach, you can build a penetration test lab in a fiscally sensible manner that is appropriate to your business needs.

Naturally, there is a disadvantage to using dual-use equipment. If you need to imitate a customer's network and they use a Cisco firewall, just dropping a software-based firewall into your penetration test lab will not work. However, if your goal is to train or test on as many different scenarios as possible, dual-use systems are definitely the way to go.

In Chapter 1, we talked about open source toolkits and we've discussed a huge number of tools throughout the other chapters in this book. This book provides a wealth of information about open source penetration testing applications which, considering the title, is probably for the best. In many penetration test labs, the majority of the tools used are open source.

It is also beneficial to remember what types of tools malicious users have available to them. Typically, it won't be expensive commercial software; it will be the same open source tools and techniques discussed in this book. The positive side of this is by becoming familiar with these tools and using them during your penetration testing, you will develop the perspective of a malicious hacker and see things that you might not have, had you strictly used some of the commercial tools that do most of the work for you. The negative side to using the open source tools concerns time. It often takes longer to use open source tools than commercial tools, simply because the commercial tools try to be as automated as possible.

There are some other disadvantages to using open source tools, with one of those being application support. The major commercial tools tend to have a support staff that will quickly respond to your questions and problems. This is generally part of the maintenance agreement with the vendor. Open source tools do not usually have this type of support. Rather, users have to search through wiki pages for the answers to most problems pages, or search various forums strewn about the Internet.

The last disadvantage open source tools have is obsolescence. It is not unusual to see tools become outdated or obsolete. However, the community tends to push and support those tools that provide the best potential and functionality and more often than not, you will see obsolete tools replaced by something better. That is why even books such as this need to be updated regularly.

The commercial tools available tend to be very expensive. It is often difficult to convince upper management of the need of some of these types of tools, especially with their yearly maintenance fees. The advantage of these tools is that a lot of them speed up the penetration test. The penetration test team probably could achieve the same results without these commercial tools, but management may feel the additional time it takes may be too costly.

A disadvantage to using commercial tools is that they are so automated that the user does not learn how to perform the same process independently. Teams that rely heavily on these commercial automated tools don't get the experience they might obtain by using open source tools. Often they involve simply clicking on a button and coming back in a couple of hours to see what to click on next.

For companies that are truly interested in improving the skill of their penetration test team, commercial applications can be detrimental to this goal. However, for companies simply interested in producing large numbers of penetration test projects, commercial tools are very effective and support the bottom line. Do not expect to sustain effective penetration test projects over the long term, though, unless your team has a solid grounding in penetration testing, which is what working with open source applications can give them.

A middle-of-the-road approach of using both commercial and open source tools can work, but you might find that members of the penetration test team gravitate initially toward using only commercial tools due to their ease of use and support. You also must guard against this, and management should monitor team member use of these commercial tools. Again, use of open source tools improves the skills of those who use them.

Finding the balance between using primarily open source or commercial tools is a tough (but critical) call for management to make. Using the tools discussed in this book (instead of trying to acquire commercial tools) will pay dividends in the long run and make you a better penetration tester, which is one of the reasons this book was written in the first place.

The Open Source Security Testing Methodology Manual (available at http://www.isecom.org/osstmm/) is a peer-reviewed effort intended to provide a comprehensive methodology specific to penetration testing. The OSSTMM groups management concerns (such as rules of engagement) alongside actual penetration testing steps, and covers how to put together the reporting of findings. With regard to actual penetration testing, the OSSTMM focuses on Internet technology security, communications security, wireless security, and physical security.

The OSSTMM has a huge following in the industry, and is updated roughly every six months. Access to the latest version, however, is restricted to monetary subscribers. For those who need the latest version, the subscription may be worth the money; but for those willing to wait, the earlier releases have quite a lot to offer as well. The OSSTMM is copyrighted under the Creative Commons 2.5 Attribution-NonCommercial-NoDerivs license.

If you work for a U.S. government agency conducting penetration testing, this National Institute of Standards and Technology (NIST) special publication will be quite familiar to you. Although this publication does not really fall under the open source tag, it is freely available to use. NIST is a U.S. federal agency that publishes multiple documents, which are free to download and use. Therefore, although not open source, the NIST SP 800-115 is freely available at http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.

The goal of the NIST SP 800-115 is to provide a varying level of guidance on how to conduct network security testing. Although intended for government systems, the publication is very useful for all networks. It tries to provide an overall picture of what system and network security is about, how attacks work, and how security should be employed in the system development life cycle. The publication also covers security testing techniques and deployment strategies for systems and networks.

A very useful penetration testing framework is available from http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html. This framework is more or less an outline of a penetration test which lists associated tools and results in each section of the test. Included are links to additional information on many tools as well as example results and reports.

One advantage of this particular framework is that it is constantly evolving as new tools are developed and new techniques are used for penetration testing. However, due to that same dynamic feature, you may see a different layout of the framework each time you visit the site. This is somewhat helped by maintaining the framework version number with each update.