Before we commence with testing, there are requirements that must be taken into consideration. You will need to determine the proper scoping of the test, timeframes and restrictions, the type of testing (Whitebox, Blackbox), and how to deal with third-party equipment and IP space. The Penetration Testing Execution Standard (PTES) lists these scoping items as part of the "Pre-Engagement Interaction" stage. I highly recommend that you review this phase at: http://www.pentest-standard.org/index.php/Pre-engagement.
Note
Although this book does not follow the PTES directly, I will attempt to point out the sections of the PTES where the material relates.
Before you can accurately determine the scope of the test, you will need to gather as much information as possible. It is critical that the following is fully understood prior to starting testing procedures:
Who has the authority to authorize testing?
What is the purpose of the test?
What is the proposed timeframe for the testing? Are there any restrictions as to when the testing can be performed?
Does your customer understand the difference between a vulnerability assessment and a penetration test?
Will you be conducting this test with, or without cooperation of the IT Security Operations Team? Are you testing their effectiveness?
Is social engineering permitted? How about Denial of Service attacks?
Are you able to test physical security measures used to secure servers, critical data storage, or anything else that requires physical access? For example, lock picking, impersonating an employee to gain entry into a building, or just generally walking into areas that the average unaffiliated person should not have access to.
Are you allowed to see the network documentation or to be informed of the network architecture prior to testing to speed things along? (Not necessarily recommended as this may instill doubt for the value of your findings. Most businesses do not expect this to be easy information to determine on your own.)
What are the IP ranges that you are allowed to test against? There are laws against scanning and testing systems without proper permissions. Be extremely diligent when ensuring that these devices and ranges actually belong to your client or you may be in danger of facing legal ramifications.
What are the physical locations of the company? This is more valuable to you as a tester if social engineering is permitted because it ensures that you are at the sanctioned buildings when testing. If time permits, you should let your clients know if you were able to access any of this information publicly in case they were under the impression that their locations were secret or difficult to find.
What to do if there is a problem or if the initial goal of the test has been reached. Will you continue to test to find more entries or is the testing over? This part is critical and ties into the question of why the customer wants a penetration test in the first place.
Are there legal implications that you need to be aware of such as systems that are in different countries, and so on? Not all countries have the same laws when it comes to penetration testing.
Will additional permission be required once a vulnerability has been exploited? This is important when performing test on segmented networks. The client may not be aware that you can use internal systems as pivot points to delve deeper within their network.
How are databases to be handled? Are you allowed to add records, users, and so on?
This listing is not all-inclusive and you may need to add items to the list depending on the requirements of your clients. Much of this data can be gathered directly from the client, but some will have to be handled by your team.
If there are legal concerns, it is recommended that you seek legal counsel to ensure you fully understand the implications of your testing. It is better to have too much information than not enough, once the time comes to begin testing. In any case, you should always verify for yourself that the information you have been given is accurate. You do not want to find out that the systems you have been accessing do not actually fall under the authority of the client!
Note
It is of utmost importance to gain proper authorization in writing before accessing any of your clients systems. Failure to do so may result in legal action and possibly jail. Use proper judgement! You should also consider that Errors and Omissions insurance is a necessity when performing penetration testing.
Setting proper limitations is essential if you want to be successful at performing penetration testing. Your clients need to understand the full ramifications involved, and should be made aware of any residual costs incurred if additional services beyond those listed within the contract are needed.
Be sure to set defined start and end dates for your services. Clearly define the rules of engagement and include IP ranges, buildings, hours, and so on, that may need to be tested. If it is not in your rules of engagement documentation, it should not be tested. Meetings should be predefined prior to the start of testing, and the customer should know exactly what your deliverables will be.
Every penetration test will need to start with a rules of engagement document that all involved parties must have. This document should at minimum cover several items:
Proper permissions by appropriate personnel.
Begin and end dates for your testing.
The type of testing that will be performed.
Limitations of testing.
What type of testing is permitted? DDOS? Full Penetration? Social Engineering? These questions need to be addressed in detail.
Can intrusive tests as well as unobtrusive testing be performed?
Does your client expect cleanup to be performed afterwards or is this a stage environment that will be completely rebuilt after testing has been completed?
IP ranges and physical locations to be tested.
How the report will be transmitted at the end of the test. (Use secure means of transmission!)
Which tools will be used during the test? Do not limit yourself to only one specific tool; it may be beneficial to provide a list of the primary toolset to avoid confusion in the future. For example, we will use the tools found in the most recent edition of the BackTrack Suite.
Let your client know how any illegal data that is found during testing would be handled: Law enforcement should be contacted prior to the client. Please be sure to understand fully the laws in this regard before conducting your test.
How sensitive information will be handled: You should not be downloading sensitive customer information; there are other methods of proving that the clients' data is not secured. This is especially important when regulated data is a concern.
Important contact information for both your team and for the key employees of the company you are testing.
An agreement of what you will do to ensure the customer's system information does not remain on unsecured laptops and desktops used during testing. Will you need to properly scrub your machine after this testing? What do you plan to do with the information you gathered? Is it to be kept somewhere for future testing? Make sure this has been addressed before you start testing, not after.
The rules of engagement should contain all the details that are needed to determine the scope of the assessment. Any questions should have been answered prior to drafting your rules of engagement to ensure there are no misunderstandings once the time comes to test. Your team members need to keep a copy of this signed document on their person at all times when performing the test.
Imagine you have been hired to assert the security posture of a client's wireless network and you are stealthily creeping along the parking lot on private property with your gigantic directional Wi-Fi antenna and a laptop. If someone witnesses you in this act, they will probably be concerned and call the authorities. You will need to have something on you that documents you have a legitimate reason to be there. This is one time where having the contact information of the business leaders that hired you will come in extremely handy!