From The Penetration Testing Execution Standard
Jump to: navigation, search
m (Cleanup & some edits based on Wendy Nather's review from a year ago.)
 
Line 1: Line 1:
This phase defines all the pre-engagement activities and scope definitions.<br />
+
= Overview =
The following image depicts the current main nodes on the mindmap:<br />
+
The aim of this section of the PTES is to present and explain the tools and techniques available which aid in a successful pre-engagement step of a penetration test. The information within this section is the result of the many years of combined experience of some of the most successful penetration testers in the world.  
[[image:pre-engagement.png]]
 
  
 +
If you are a customer looking for penetration test we strongly recommend going to the General Questions section of this document. It covers the major questions that should be answered before a test begins. Remember, a penetration test should not be confrontational. It should not be an activity to see if the tester can "hack" you. It should be about identifying the business risk associated with and attack.
  
= Scoping =
+
To get maximum value, make sure the questions in this document are covered. Further, as the Scoping activity progresses, a good testing firm will start to ask additional questions tailored to your organization.
  
Scoping is arguably one of the more important and often overlooked components of a penetration test.  Sure, there are lots of books written about the different tools and techniques that can be used for gaining access to a network.  However, there is very little on the topic of how to prepare for a test. This can lead to troubles for the testers in areas like Scope Creep, legal issues and disgruntled customers that will never have you back.  
+
= Introduction to Scope =
 +
Defining scope is arguably one of the most important components of a penetration test, yet it is also one of the most overlooked. While many volumes have been written about the different tools and techniques which can be utilized to gain access to a network, very little has been written on the topic which precedes the penetration: preparation. Neglecting to properly complete pre-engagement activities has the potential to open the penetration tester (or his firm) to a number of headaches including scope creep, unsatisfied customers, and even legal troubles.  
 +
The scope of a project specifically defines what is to be tested. How each aspect of the test will be conducted will be covered in the Rules of Engagement section.
  
The goal of this section is to give you the tools and techniques to avoid these pitfalls. Much of the information contained in this section is the result of the experiences of the testers who wrote it.   Many of the lessons are ones which we have learned the hard way.  
+
One key component of scoping an engagement is outlining how the testers should spend their time. As an example, a customer requests that one hundred IP addresses be tested for the price of $100,000. This means that the customer is offering $1,000 per IP address tested.  However, this cost structure only remains effective at that volume.  A common trap some testers fall into is maintaining linear costs throughout the testing process. If the customer had only asked for one business-critical application to be tested at the same pricing structure ($1,000), while the tester will still be only attacking a single IP, the volume of work has increased dramatically.  It is important to vary costs based on work done. Otherwise a firm can easily find themselves undercharging for their services, which motivates them to do a less than complete job.  
  
Scoping is specifically tied to what you are going to testThis is very different from covering how you are going to test.  We will be covering How To Test in the rules of engagement section.
+
Despite having a solid pricing structure, the process is not all black and white.  It is not uncommon for a client to be completely unaware of exactly what it is they need testedIt is also possible the client will not know how to communicate effectively what they’re expecting from the test.  It is important in the Pre-Engagement phase that the tester is able to serve as a guide through what may be uncharted territory for a customer.  The tester must understand the difference between a test which focuses on a single application with severe intensity and a test where the client provides a wide range of IP addresses to test and the goal is to simply find a way in.  
  
If you are a customer looking for penetration test we strongly recommend going to the General Questions section of this documentIt covers the major questions that should be answered before a test begins.  Remember, a penetration test should not be confrontationalIt should not be an activity to see if the tester can "hack" you.  It should be about identifying the business risk associated with and attack.  To get maximum value, make sure the questions in this document are coveredFurther, as the Scoping activity progresses, a good testing firm will start to ask additional questions tailored to your organization.  
+
= Metrics for Time Estimation =
 +
Time estimations are directly tied to the experience of a tester in a certain areaIf a tester has significant experience in a certain test, he will likely innately be able to determine how long a test will takeIf the tester has less experience in the area, re-reading emails and scan logs from previous similar tests the firm has done is a great way to estimate the time requirement for the current engagementOnce the time to test is determined, it is a prudent practice to add 20% to the time.  
  
= How to Scope=
+
The extra 20% on the back end of the time value is called padding. Outside of consultant circles, this is also referred to as consultant overhead. The padding is an absolute necessity for any test.  It provides a cushion should any interruptions occur in the testing.  There are many events which commonly occur and hinder the testing process. For example, a network segment may go down, or a significant vulnerability may be found which requires many meetings with many levels of management to address. Both of these events are time consuming and would significantly impact the original time estimate if the padding was not in place.
  
One of the key components for scoping an engagement is trying to figure out exactly how you as a tester are going to spend your time. For example, a customer could want you to test 100 IP addresses and only want to pay you $100,000 for the effort.  This roughly breaks down to $1K per IP.  Now, would that cost structure hold true if they had one mission critical application they wanted you to test?  Some testers fall into this trap when interacting with a customer to scope a test.  Unfortunately, there is going to be some customer education in the process.  We are not Wal-Mart.  Our costs are not linear.  
+
What happens if the 20% padding ends up not being necessary?  Billing the client for time not worked would be extremely unethical, so it is up to the testers to provide additional value that may not normally have been provided if the engagement time limit had been hit. Examples include walking the company security team through the steps taken to exploit the vulnerability, provide an executive summary if it was not part of the original deliverable list, or spend some additional time trying to crack a vulnerability that was elusive during the initial testing.
  
So, with that being said, there will be some engagements where you will have a wide canvas of IP addresses to test and choose from to try and access a network as part of a test.  There will also be highly focused tests where you will spend weeks (if not months) on one specific application.  The key is knowing the difference.  To have that level of understanding you will have to know what it is the customer is looking for, even when they don't know exactly how to phrase it.
+
Another component of the metrics of time and testing is that every project needs to have a definitive drop dead date. All good projects have a well-defined beginning and end. You will need to have a signed statement of work specifying the work and the hours required if you’ve reached the specific date the testing is to end, or if any additional testing or work is requested of you after that date.  
 
+
Some testers have a difficult time doing this because they feel they are being too much of a pain when it comes to cost and hours. However, it has been the experience of the author that if you provide exceptional value for the main test the customer will not balk at paying you for additional work.  
= Metrics for Time Estimation=
 
 
 
So, now we get to the issue of metrics.  Much of this will be based upon your experience in the area you are going to test.  For example, have you ever done a full, in-depth test of an application?  Have you ever tested a wide range of IP addresses?  Go back and review your emails and your scan logs for that engagement.  Write that number down somewhere.  Now, add at least 20% to the time value. 
 
 
 
Wait? Why add 20% to the time value?  We call this padding.  Outside of consultant circles this can sometimes be referred to as consultant overhead.  The reason this is required is because every engagement can have small interruptions to the testing.  For example, a network segment may go down (hopefully not due to your testing activities).  The time spent not testing does in fact cost you the tester money.  Another example is meeting creep. There are often times where you will find a tremendous vulnerability in a system and share it with the customer.  The customer will then require you to have a meeting with upper management.  There should be no doubt that you will attend.  However, that meeting will take away from your overall testing time.
 
 
 
What happens if you do not need the 20% overhead?  It would be incredibly unethical to simply pocket the cash.  Rather, find ways to provide the customer with additional value for the test.  Walk the company’s security team through the steps you took to exploit the vulnerability, provide an executive summary if it was not part of the original deliverable list, or spend some additional time trying to crack the vulnerability that was elusive during the initial testing.
 
 
 
Another component of the metrics of time and testing is that your project has to have a definitive drop dead dates. All good projects have a beginning and an end. Your test should as well.  You will need to have a signed Statement of Work specifying the work and the hours required if you’ve reached the specific date the testing is to end, or if any additional testing or work is requested of you after that date.  
 
 
 
Some testers have a difficult time doing this because they feel they are being too much of a pain when it comes to cost and hours. However, it has been the experience of the author that if you provide exceptional value for the main test the customer will not balk at paying you for additional work.
 
  
 
= Scoping Meeting =
 
= Scoping Meeting =
 +
In many cases the scoping meeting will occur after the contract has been signed. Situations do occur wherein many of the scope-related topics can be discussed before contract signing, but they are few and far between. For those situations it is recommended that a non-disclosure agreement be signed before any in-depth scoping discussions occur.
  
Remember, in many cases the scoping meeting will happen after the contract has been signedThere are some blissful scenarios where you can cover many of the topics relating to scope before a contract is signed.  We would recommend that for those situations an NDA be signed before any in-depth scoping discussions occur.
+
The goal of the scoping meeting is to discuss what will be tested. Rules of engagement and costs will not be covered in this meeting. Each of these subjects should be handled in meetings where each piece is the focus of that meetingThis is done because discussions can easily become confused and muddled if focus is not explicitly stated. It is important to act as moderator and keep the discussions on-topic, preventing tangents and declaring certain topics more suited for off-line discussion when necessary.  
  
The goal of the scoping meeting is to discuss what it is you are to test. It is not to cover Rules of Engagement. It is also not to cover costs.  We find that it is better to break these different aspects of pre-engagement into separate meetings and sections. The reason for this level of separation is that discussions can get muddled if the focus is not explicitly established.  This is all part of owning and driving a meeting so it does not get bogged down in conversations that are not relevant to the topic at hand or go off track into conversations that can easily be handled by specific individuals “off line” or on a one on one ad-hoc basis.
+
Now that a Rough Order of Magnitude (ROM) value has been established for the project it is time to have a meeting with the customer to validate assumptions. First, it needs to be established explicitly what IP ranges are in scope for the engagement. It is not uncommon for a client to be resistant and assume that it is the prerogative of the tester to identify their network and attack it, to make the test as realistic as possible. This would indeed be an ideal circumstance, however, possible legal ramifications must be considered above all else. Because of this, it is the responsibility of the tester to convey to a client these concerns and to impart upon them the importance of implicit scoping. For example, in the meeting, it should be verified that the customer owns all of the target environments including: the DNS server, the email server, the actual hardware their web servers run on and their firewall/IDS/IPS solution. There are a number of companies which will outsource the management of these devices to third parties.
  
A good resource for effective meetings can be found here:
+
Additionally, the countries, provinces, and states in which the target environments operate in must be identified. Laws vary from region to region and the testing may very well be impacted by these lawsFor instance, countries belonging to the European Union are well known to have very stringent laws surrounding the privacy of individuals, which can significantly change the manner in which a social engineering engagement would be executed.  
 
 
http://www.businessandthegeek.com/?p=112
 
 
 
Now that you have a rough idea on the Rough Order of Magnitude (ROM) for the project it is time to have a meeting with the customer to validate some assumptions.  First, you are going to need to ask them explicitly what IP ranges are in scope for the engagement. Some customers will push back and say that it is up to you to identify their network and attack it... Just like the bad guys would.  This would be great if there were no legal considerations surrounding the testHowever, as testers we need to go through great lengths to ensure that we are testing and attacking the right systems.  For example, in the meeting ask the customer if they own the target environments: DNS server, email server, the actual hardware their web servers run on and their firewall/IDS/IPS solution.  There are a number of companies that will outsource the management of these devices to third parties.  It is in the scoping meeting that we need to confirm what is explicitly in scope and what is not. 
 
 
 
Further, we need to identify which countries the target environment operates in.  There can be some very stringent laws in the EU surrounding the privacy of individuals.  This could have an impact on the social engineering aspect of your engagement.  
 
  
 
= Additional Support Based on Hourly Rate =
 
= Additional Support Based on Hourly Rate =
 +
Anything that is not explicitly covered within the scope of the engagement should be handled very carefully. The first reason for this is scope creep. As the scope expands, resources are consumed, cutting into the profits for the tester and may even create confusion and anger on the part of the customer. There is another issue that many testers do not think of when taking on additional work on an ad-hoc basis: legal ramifications. Many ad-hoc requests are not properly documented so it can be difficult to determine who said what in the event of a dispute or legal action. Further, the contract is a legal document specifying the work that is to be done. It should be tightly tied to the permission to test memo.
  
Anything that is not explicitly covered within the scope of the engagement should be handled very carefully.  There are a couple of reasons for this.  The first reason is scope creep.  These tasks can easily eat the profits of your engagement and create confusion and anger with the customer.  There is another issue that many testers do not think of when taking on additional work on an ad-hoc basis, legal ramifications.  Many ad-hoc requests are not properly documented so it can be difficult to determine who said what in the event of a dispute or legal action.  Further, your contract is a legal document specifying the work that is to be done.  This should be tightly tied to the permission to test memo.
+
Any requests outside of the original scope should be documented in the form of a statement of work that clearly identifies the work to be done. We also recommend that it be clearly stated in the contract that additional work will be done for a flat fee per hour and explicitly state that additional work can not be completed until a signed and counter-signed SOW is in place.  
 
 
What we recommend is that any additional requests be documented in the form of a Statement of Work that clearly identifies the work to be done. We also recommend that it be clearly stated in the contract that additional work will be done for a flat fee per hour and explicitly state that additional work can not be completed until a signed and counter-signed SOW is in place.
 
 
 
= Questionnaires =
 
  
When you first start communicating with the customer there will be a set of questions that you will need answered before you can accurately scope the penetration test engagement. These questions are critical to ask and should give you a better understanding of what the client is looking to gain out of the penetration test, why the client is looking to have a penetration test performed against their environment, and whether or not they want certain types of tests performed during the penetration test.
+
= Questionnaires =
 
+
During initial communications with the customer there are several questions which the client will have to answer in order for the engagement scope can be properly estimated. These questions are designed to provide a better understanding of what the client is looking to gain out of the penetration test, why the client is looking to have a penetration test performed against their environment, and whether or not they want certain types of tests performed during the penetration test. The following are sample questions which may be asked during this phase.
The following are some sample questions that may need to be answered before you can even accurately quote how much the engagement is going to cost the customer:
 
  
 
= General Questions =
 
= General Questions =
 +
== Network Penetration Test ==
 +
# Why is the customer having the penetration test performed against their environment?
 +
# Is the penetration test required for a specific compliance requirement?
 +
# When does the customer want the active portions (scanning, enumeration, exploitation, etc...) of the penetration test conducted?
 +
## During business hours?
 +
## After business hours?
 +
## On the weekends?
 +
# How many total IP addresses are being tested?
 +
## How many internal IP addresses, if applicable?
 +
## How many external IP addresses, if applicable?
 +
# Are there any devices in place that may impact the results of a penetration test such as a firewall, intrusion detection/prevention system, web application firewall, or load balancer?
 +
# In the case that a system is penetrated, how should the testing team proceed?
 +
## Perform a local vulnerability assessment on the compromised machine?
 +
## Attempt to gain the highest privileges (root on Unix machines, SYSTEM or Administrator on Windows machines) on the compromised machine?
 +
## Perform no, minimal, dictionary, or exhaustive password attacks against local password hashes obtained (for example, /etc/shadow on Unix machines)?
  
'''"Network Penetration Test"'''
+
== Web Application Penetration Test ==
#Why is the customer having the penetration test performed against their environment?
+
# How many web applications are being assessed?  
#Is the penetration test required for a specific compliance requirement?
+
# How many login systems are being assessed?  
#When does the customer want the active portions (scanning, enumeration, exploitation, etc...) of the penetration test conducted?
+
# How many static pages are being assessed? (approximate)  
#During business hours?
+
# How many dynamic pages are being assessed? (approximate)  
#After business hours?
+
# Will the source code be made readily available?  
#On the weekends?
+
# Will there be any kind of documentation?
#How many total IP addresses are being tested?
+
## If yes, what kind of documentation?  
#How many internal IP addresses, if applicable?
+
# Will static analysis be performed on this application?  
#How many external IP addresses, if applicable?
+
# Does the client want fuzzing performed against this application?  
#Are there any devices in place that may impact the results of a penetration test such as a firewall, intrusion detection/prevention system, web application firewall, or load balancer?
+
# Does the client want role-based testing performed against this application?  
#In the case that a system is penetrated, should we:
+
# Does the client want credentialed scans of web applications performed?  
Perform a local vulnerability assessment on the compromised machine?
 
Attempt to gain the highest privileges (root on unix machines, SYSTEM or Administrator on Windows machines) on the compromised machine?
 
Perform no, minimal, dictionary, or exhaustive password attacks against local password hashes obtained (for example, /etc/shadow on unix machines)?
 
 
 
 
 
'''Web Application Penetration Test'''
 
#How many web applications are being assessed?
 
#How many login systems are being assessed?
 
#How many static pages are being assessed? (approximately)
 
#How many dymanic pages are being assessed? (approximately)
 
#Will the source code be readily for viewing?
 
#Will there be any kind of documentation, and if yes what kind of documentation?
 
#Will we be performing static analysis on this application?
 
#Does the client want us to perform fuzzing against this application?
 
#Does the client want us to perform role-based testing?
 
#Does the client want us to perform credentialed scans of web applications?
 
 
 
 
 
'''Wireless Network Penetration Test'''
 
#How many wireless networks are in place?
 
#Is a guest wireless network used? If so:
 
#Does the guest network require authentication?
 
#What type of encryption is used on the wireless networks?
 
#What is the square footage of coverage?
 
#Will we be enumerating rogue devices?
 
#Will we be assessing wireless attacks against clients?
 
#Approximately how many clients will be using the wireless network?
 
  
 +
== Wireless Network Penetration Test ==
 +
# How many wireless networks are in place?
 +
# Is a guest wireless network used? If so:
 +
## Does the guest network require authentication?
 +
## What type of encryption is used on the wireless networks?
 +
## What is the square footage of coverage?
 +
## Will enumeration of rogue devices be necessary?
 +
## Will the team be assessing wireless attacks against clients?
 +
## Approximately how many clients will be using the wireless network?
  
'''Physical Penetration Test'''
+
== Physical Penetration Test ==
#How many locations are being assessed?
+
#How many locations are being assessed?  
#Is this physical location a shared facility? If so:
+
# Is this physical location a shared facility? If so:
#How many floors are in scope?
+
## How many floors are in scope?  
#Which floors are in scope?
+
## Which floors are in scope?  
#Are there any security guards that will need to be bypass? If so:
+
# Are there any security guards that will need to be bypassed? If so:  
#Are the security guards employed through a 3rd party? Are they armed? Are they allowed to use force?
+
## Are the security guards employed through a 3rd party?
#How many entrances are there into the building?
+
## Are they armed?
#Is the use of lock picks or bump keys allowed? (this will be dependant upon state law)
+
## Are they allowed to use force?  
#Will we be performing a physical penetration test to verify compliance with existing policies and procedures or just performing an audit?
+
# How many entrances are there into the building?  
#What is the square footage of the area in scope?
+
# Is the use of lock picks or bump keys allowed? (also consider local laws)
#Are all physical security measures documented?
+
# Is the purpose of this test to verify compliance with existing policies and procedures or for performing an audit?  
#Are video cameras being used? If so and they are client owned:
+
# What is the square footage of the area in scope?  
#Does the client want us to attempt to gain access to where the video camera data is stored?
+
# Are all physical security measures documented?  
#Is there an armed alarm system being used? If so:
+
# Are video cameras being used?
#Is the alarm a silent alarm?
+
## Are the cameras client-owned? If so:
#Is the alarm triggered by motion?
+
### Should the team attempt to gain access to where the video camera data is stored?  
#Is the alarm triggered by opening of doors and windows?
+
# Is there an armed alarm system being used? If so:  
 +
## Is the alarm a silent alarm?  
 +
## Is the alarm triggered by motion?  
 +
## Is the alarm triggered by opening of doors and windows?  
  
 +
== Social Engineering ==
 +
# Does the client have a list of email addresses they would like a Social Engineering attack to be performed against?
 +
# Does the client have a list of phone numbers they would like a Social Engineering attack to be performed against?
 +
# Is Social Engineering for the purpose of gaining unauthorized physical access approved? If so:
 +
## How many people will be targeted?
  
'''Social Engineering'''
+
It should be noted that as part of different levels of testing, the questions for Business Unit Managers, Systems Administrators, and Help Desk Personnel may not be required. However, in the case these questions are necessary, some sample questions can be found below.
#Will the client provide e-mail addresses of personnel that we can attempt to social engineer?
 
#Will the client provide phone numbers of personnel that we can attempt to social engineer?
 
#Will we be attempting to social engineer physical access, if so:
 
#How many people will be targeted?
 
  
 +
== Questions for Business Unit Managers ==
 +
# Is the manager aware that a test is about to be performed?
 +
# What is the main datum that would create the greatest risk to the organization if exposed, corrupted, or deleted?
 +
# Are testing and validation procedures to verify that business applications are functioning properly in place?
 +
# Will the testers have access to the Quality Assurance testing procedures from when the application was first developed?
 +
# Are Disaster Recovery Procedures in place for the application data?
  
It should be noted that as part of different levels of testing the questions for  business unit managers systems administrators and help desk personnel may not be required.  However, feel free to use the following questions as a guide.
+
== Questions for Systems Administrators ==
 
+
# Are there any systems which could be characterized as fragile? (systems with tendencies to crash, older operating systems, or which are unpatched)  
 
+
# Are there systems on the network which the client does not own, that may require additional approval to test?  
'''Questions for Business Unit Managers'''
+
# Are Change Management procedures in place?  
 
+
# What is the mean time to repair systems outages?  
We cannot ignore the business unit managers when a test is being preformed.  These tend to be the individuals who would be most impacted if a DoS condition occurred. 
+
# Is any system monitoring software in place?  
 
+
# What are the most critical servers and applications?  
#Do you know a test is about to be performed?
+
# Are backups tested on a regular basis?  
#What is the main datum that would create the greatest risk to the organization if exposed, corrupted or deleted?
+
# When was the last time the backups were restored?  
#Do you have testing and validation procedures to verify your business applications are functioning properly?
 
#Do you have your Quality Assurance testing procedures from when the application was first developed?
 
#Do you have Disaster Recovery Procedures for your application data?
 
 
 
 
 
'''Questions for Systems Administrators'''
 
 
 
We cannot ignore the power of systems administrators in security and for penetration testing.  They know their systems far better than any one else in their organizations and if something goes wrong they are most likely going to be the people on the front lines to restore operations.  May of the questions below are based on the concept of Visible Operations.
 
 
 
#Can you identify your fragile systems? (Ask about systems with tendencies to crash, have older operating systems, or are not patched for any reason)
 
#Are there systems on the network that IT does not own, that may require additional approval to test?
 
#Do you have Change Management procedures in place?
 
#What is the mean time to repair systems outages?
 
#Do you have any systems monitoring software in place?
 
#What are your most critical servers and applications?
 
#Do you test backups on a regular basis?
 
#When was the last time your restored from backup?
 
  
 
= Scope Creep =
 
= Scope Creep =
 +
Scope creep is one of the most efficient ways to put a penetration testing firm out of business. The issue is that many companies and managers have little to no idea how to identify it, or how to react to it when it happens.
  
Scope creep will kill you.  It is often one of the most effective ways that a penetration  testing company can cease to exist.  The issue is that many companies and managers have little to no idea how to identify it, or how to react to it when it happens. 
+
There are a couple of things to remember when battling scope creep. First, if a customer is pleased with the work done on a particular engagement, it is very common for them to request additional work. Take this as a compliment, and do not hesitate to ask for additional funding to compensate for the extra time spent. If a customer refuses to pay for the extra work, it is almost never worth staying on to do that work.
 
 
There are a couple of things to remember when battling scope creep.   First, if you have done a great job it is very common for a customer to request additional work. This is a good thing.  If a customer drops you because you asked for additional funding to do additional work, they were looking to use you.  You did not want to stay on that contract anyway. 
 
 
 
The second point is even more critical.  Do not gouge your existing customers when they ask for additional work.  Yes, you can afford to drop your prices. You did not have to hunt the work. You did not have to go through a formal RFP process.  Giving the customer a 10% discount is not going to kill you.  Further, your best source for future work is through your existing customers.  Treat them well and they will return.
 
 
 
'''Specify Start and End Dates'''
 
 
 
Another key component defeating scope creep is specifying start and end dates.  This allows the project to have definite end.  There is one area where testers get burnt, retesting.  Retesting sounds like a good idea when you are going after a contract.  It shows that you care and you actually want to make sure the customer is secure.  However, many times testers forget that they will not get paid until all of the work is complete.  This includes retesting.  An example on how to deal with this is to put in the contract that retesting must happen within 30 days of the final report delivery.  Then, you need to take the lead on getting the retest scheduled.  If the customer requests an extension, allow it under the condition that you be paid within the time specified in the contract.  Then, and this is the most important part, accurately do the retest.  Remember, the best source for future work is your existing customer base.
 
 
 
= Specify IP Ranges and Domains =
 
 
 
Before you start a penetration test you must know what the targets you will be attempting to penetrate are. These targets should be obtained from the customer during the initial questionnaire phase. Targets can be given in the form of specific IP addresses, network ranges, or domain names by the customer. In some instances, the only target the customer gives you is the organization’s name and expects you to figure the rest out for yourself. It is important to define if systems like firewalls and IDS/IPS or networking equipment that are between the tester and the final target are also part of the scope.
 
 
 
'''Validate Ranges'''
 
 
 
It is imperative that before you start to attack the targets you validate that they are in fact owned by the customer you are performing the test against. Think of the legal consequences you may run into if you start attacking a machine and successfully penetrate it only to find out later down the line that the machine actually belongs to another organization (such as a hospital or government agency).
 
 
 
To verify that the targets actually belongs to your customer, you can perform a whois against the targets. To perform a whois against the target you can either use a whois tool on the web such as Internic or a tool on your computer like the following:
 
 
 
<pre>
 
 
 
user@unix:~$ whois example.com
 
 
 
Whois Server Version 2.0
 
 
 
Domain names in the .com and .net domains can now be registered
 
with many different competing registrars. Go to http://www.internic.net
 
for detailed information.
 
 
 
  Domain Name: example.COM
 
  Registrar: REGISTER.COM, INC.
 
  Whois Server: whois.register.com
 
  Referral URL: http://www.register.com
 
  Name Server: NS1.EXAMPLE.COM
 
  Name Server: NS3.EXAMPLE.COM
 
  Status: clientTransferProhibited
 
  Updated Date: 17-mar-2009
 
  Creation Date: 05-mar-2000
 
  Expiration Date: 05-mar-2016
 
 
 
 
 
 
  Registrant:
 
      Domain Discreet
 
      ATTN: example.com
 
      Rua Dr. Brito Camara, n 20, 1
 
      Funchal, Madeira 9000-039
 
      PT
 
      Phone: 1-902-7495331
 
      Email: 940fe48d0a16123306dddf8a5a4c2069@domaindiscreet.com
 
 
 
 
 
  
  Registrar Name....: Register.com
+
The second point is even more critical. When dealing with existing customers, take care to keep the prices lower. Taking advantage of a good situation by price gouging is a sure way to drive away repeat business. Take into consideration that  prices can be lowered since the firm avoided the costs of acquiring the customer such as the formal RFP process and hunting for the customer itself. Further, the best source for future work is through existing customers. Treat them well and they will return.  
  Registrar Whois...: whois.register.com
 
  Registrar Homepage: www.register.com
 
  
  Domain Name: example.com
+
= Specify Start and End Dates =
      Created on..............: 2000-03-05
+
Another key component defeating scope creep is explicitly stating start and end dates. This allows the project to have definite end. One of the most common areas in which scope creep occurs is during retesting. Retesting always sounds like a good idea when going after a contract. It shows that the firm is caring and diligent, trying to make ensure that the customer is secure as possible. The problem begins when it is forgotten that the work is not paid for until it is completed. This includes retesting.
      Expires on..............: 2016-03-05
 
  
  Administrative Contact:
+
To mitigate this risk, add a simple statement to the contract which mentions that all retesting must be done within a certain timeframe after the final report delivery. It then becomes the responsibility of the testers to spearhead the retesting effort. If the customer requests an extension, always allow this with the condition that payment be fulfilled at the originally specified date. Finally, and most importantly, perform a quality retest. Remember, the best source for future work is your existing customer base.  
      Domain Discreet
 
      ATTN: example.com
 
      Rua Dr. Brito Camara, n 20, 1
 
      Funchal, Madeira 9000-039
 
      PT
 
      Phone: 1-902-7495331
 
      Email: 940fe48a0a16123337ca6a1281067070@domaindiscreet.com
 
  
 +
= Specify IP Ranges and Domains =
 +
Before starting a penetration test, all targets must be identified. These targets should be obtained from the customer during the initial questionnaire phase. Targets can be given in the form of specific IP addresses, network ranges, or domain names by the customer. In some instances, the only target the customer provides is the name of the organization and expects the testers be able to identify the rest on their own. It is important to define if systems like firewalls and IDS/IPS or networking equipment that are between the tester and the final target are also part of the scope. Additional elements such as upstream providers, and other 3rd party providers should be identified and defined whether they are in scope or not.
  
  Technical  Contact:
+
== Validate Ranges ==
      Domain Discreet
+
It is imperative that before you start to attack the targets you validate that they are in fact owned by the customer you are performing the test against. Think of the legal consequences you may run into if you start attacking a machine and successfully penetrate it only to find out later down the line that the machine actually belongs to another organization (such as a hospital or government agency).  
      ATTN: example.com
 
      Rua Dr. Brito Camara, n 20, 1
 
      Funchal, Madeira 9000-039
 
      PT
 
      Phone: 1-902-7495331
 
      Email: 940fe48d0a16123339c7eef67f34a73d@domaindiscreet.com
 
 
 
 
 
  DNS Servers:
 
      ns1.example.com
 
      ns3.example.com
 
</pre>
 
  
 
= Dealing with Third Parties =
 
= Dealing with Third Parties =
 +
There are a number of situations where an engagement will include testing a service or an application that is being hosted by a third party. This has become more prevalent in recent years as “cloud” services have become more popular. The most important thing to remember is that while permission may have been granted by the client, they do not speak for their third party providers.  Thus, permission must be obtained from them as well in order to test the hosted systems. Failing to obtain the proper permissions brings with it, as always, the possibility of violating the law, which can cause endless headaches.
  
There are a number of situations where you will be asked to test a service or an application that is being hosted by a third party. This will become more and more prevalent as “cloud” services are utilized more by organizations. The important thing to remember is that you may have permission to test from your customer, you also need to receive permission from the third party as well.  At best, you may anger the hosting party.  At worst, you may run afoul of a number of international laws. Some enterprises may not even know that they are using cloud services, or may have forgotten that something is hosted elsewhere.  Be prepared to break the news to them when you test, or put a clause in the SOW that covers undisclosed usage of 3rd party resources.
+
== Cloud Services ==
 +
The single biggest issue with testing cloud service is there is data from multiple different organizations stored on one physical medium. Often the security between these different data domains is very lax. The cloud services provider needs to be alerted to the testing and needs to acknowledge that the test is occurring and grant the testing organization permission to test. Further, there needs to be a direct security contact within the cloud service provider that can be contacted in the event that a security vulnerability is discovered which may impact the other cloud customers. Some cloud providers have specific procedures for penetration testers to follow, and may require request forms, scheduling or explicit permission from them before testing can begin.  
  
'''Cloud Services'''
+
== ISP ==
 +
Verify the ISP terms of service with the customer. In many commercial situations the ISP will have specific provisions for testing. Review these terms carefully before launching an attack. There are situations where ISPs will shun and block certain traffic which is considered malicious. The customer may approve this risk, but it must always be clearly communicated before beginning.
 +
Web Hosting
 +
As with all other third parties, the scope and timing of the test needs to be clearly communicated with the web hosting provider. Also, when communicating with the client, be sure to clearly articulate the test will only be in search of web vulnerabilities. The test will not uncover vulnerabilities in the underlying infrastructure which may still provide an avenue to compromise the application.
  
The single biggest issue with testing cloud service is there is data from multiple different organizations stored on one physical medium.  Often the security between these different data domains is very lax.  The cloud services provider needs to be alerted to the testing and needs to acknowledge that the test is occurring and grant the testing organization permission to test.  Further, there needs to be a direct security contact within the cloud service provider that can be contacted in the event that a security vulnerability is discovered that can impact the other cloud customers. Some cloud providers have specific procedures for penetration testers to follow, and may require request forms, scheduling or explicit permission from them before testing can begin.
+
== MSSPs ==
 
+
Managed Security Service Providers also may need to be notified of testing. Specifically, they will need to be notified when the systems and services that they own are to be tested.  
This may seem like an onerous amount of approval for testing, however the risks are to great to the tester otherwise.
+
However, there are circumstances under which the MSSP would not be notified. If determining the actual response time of the MSSP is part of the test, it is certainly not in the best interest of the integrity of the test for the MSSP to be notified.
 
+
As a general rule of thumb, any time a device or service explicitly owned by the MSSP is being tested they will need to be notified.  
'''ISP'''
 
 
 
Verify the ISP terms of service with the customer.  In many commercial situations the ISP will have specific provisions for testing.  Review these terms carefully before launching an attack.  There are situations where ISPs will shun and block certain traffic that is deemed to be “malicious.”  This may be acceptable to the customer, it may not.  Either way it needs to be clearly communicated with the customer prior to testing.
 
 
 
'''Web Hosting'''
 
 
 
This is the same as the other tests, the scope and timing of the test needs to be clearly communicated with the web hosting provider.  Also, when communicating with the direct customer you need to clearly articulate you are only testing for web vulnerabilities.  You will not be testing for vulnerabilities that can lead to a compromise of the underlying OS infrastructure.
 
 
 
'''MSSPs'''
 
 
 
Managed Security Service Providers also may need to be notified of testing. Specifically, you will need to notify the provider when you are testing systems and services that they own.
 
 
 
However, there are times when you would not notify the MSSP. It may not be in the best interests of the test to notify the MSSP when you are testing the response time of the MSSP.
 
 
 
As a general rule of thumb, any time a device or services explicitly owned by the MSSP is being tested they need to be notified.
 
 
 
'''Countries Where Servers are Hosted'''
 
 
 
It is also in the best interests of the tester to verify the countries where servers are being housed.  After you have validated the country, review the laws of the specific country before beginning testing. 
 
 
 
Do not assume your company’s legal team will do this for you.  Do not assume they will do it in a fashion that will be complete. Do not, under any circumstances, assume the company will take responsibility for your actions should international laws be violated.  Verify the laws yourself.  Remember, if someone goes to jail, it will most likely be the tester who violated the law.
 
  
 +
== Countries Where Servers are Hosted ==
 +
It is also in the best interests of the tester to verify the countries where servers are being housed. After you have validated the country, review the laws of the specific country before beginning testing.
 +
It should not be assumed that the firm’s legal team will provide a complete synopsis of local laws for the testers. It should also not be assumed that the firm will take legal responsibility for any laws violated by its testers. It is the responsibility of each tester to verify the laws for each region they are testing in before they begin testing because it will be the tester who ultimately will have to answer for any transgressions.
  
 
= Define Acceptable Social Engineering Pretexts =
 
= Define Acceptable Social Engineering Pretexts =
 +
Many organizations will want their security posture tested in a way which is aligned with current attacks. Social engineering and spear-phishing attacks are currently widely used by many attackers today. While most of the successful attacks use pretexts like sex, drugs, and rock and roll (porn, Viagra, and free iPods respectively) some of these pretexts may not be acceptable in a corporate environment. Be sure that any pretexts chosen for the test are approved in writing before testing is to begin.
  
Many organizations want you to test their security posture in such a way that is aligned with current attacks.  Social engineering and spear-phishing attacks are currently widely used by many attackers today.  While most of the successful attacks use pretexts like sex, drugs and rock and roll (porn, Viagra and free iPods respectively) some of these pretexts may not be acceptable in a cooperate environment.  Be sure that any pretexts chosen by your company for the test are approved in writing before testing is to begin.
+
= DoS Testing =
 
+
Stress testing or Denial of Service testing should be discussed before the engagement begins. It can be a topic that many organizations are uncomfortable with due to the potentially damaging nature of the testing. If an organization is only worried about the confidentiality or integrity of their data, stress testing may not be necessary; however, if the organization is also worried about the availability of their services, then the stress testing should be conducted in a non-production environment which is identical to the production environment.  
= DoS Testing =  
 
 
 
Stress testing or Denial of Service testing should be discussed before you start your engagement. It can be one of those topics that many organizations are uncomfortable with due to the potentially damaging nature of the testing. If an organization is only worried about the confidentiality or integrity of their data, stress testing may not be necessary; however, if the organization is also worried about the availability of their services, then the stress testing should be conducted in a non-production environment that is identical to their production environment.  
 
 
 
= Payment Terms =
 
 
 
 
 
Another aspect of preparing for a test that many testers completely forget about is how they should be paid.  Just like contract dates there should be specific dates and terms for payments.  It is not uncommon for larger organizations to put off paying you for testing services for as long as possible.
 
 
 
Below are a few options on how you can be paid.  Remember, these are just options. You can develop a structure and plan that fits your company and your customers needs.  The important thing is that you have something defined before work begins.
 
 
 
 
 
'''Net 30'''
 
 
 
The total amount is due within 30 days of the delivery of the final report.  This is usually associated with a per month percentage penalty for non-payment.  This can be any number of days you wish to grant your customers (i.e. 45, or 60).
 
 
 
'''Half Upfront'''
 
 
 
It is not uncommon to require half of the total bill upfront before testing begins.  This is very common for longer-term engagements.
 
 
 
'''Recurring'''
 
  
You can also have a recurring payment schedule.  This is more of a long-term engagement. For example, you may have a contract with a company that is going to span a year or two.  It is not at all uncommon to have the customer pay you in regular installments throughout the year.
+
= Payment Terms =
 +
Another aspect of preparing for a test that many testers completely forget about is how they should be paid. Just like contract dates there should be specific dates and terms for payments. It is not uncommon for larger organizations to delay payment for as long as possible.
 +
Below are a few common payment methods. These are simply examples.  It is definitely recommended that each organization create and tweak their own pricing structure to more aptly suit the needs of their clients and themselves.  The important thing is that some sort of structure be in place before testing begins.  
  
= Goals =  
+
== Net 30 ==
 +
The total amount is due within 30 days of the delivery of the final report. This is usually associated with a per month percentage penalty for non-payment. This can be any number of days you wish to grant your customers (i.e. 45, or 60).
  
Every penetration test should be goal oriented.  This is to say we are testing to identify specific vulnerabilities that lead to a compromise of the business or mission objectives of the customer. It is not about finding un-patched systems.  It is about identifying risk that will adversely impact the organization.  
+
== Half Upfront ==
 +
It is not uncommon to require half of the total bill upfront before testing begins. This is very common for longer-term engagements.  
  
'''Primary'''
+
== Recurring ==
 +
A recurring payment schedule is more commonly used for long-term engagements. For example, some engagements may span as far as a year or two. It is not at all uncommon to have the customer pay in regular installments throughout the year.
  
The primary goal of a test should not be driven by compliance. There are a number of different justifications for this reasoning.  First, compliance does not equal security.  While it should be understood that many organizations undergo testing because of compliance it should not be the main goal of the test.  For example, you may be hired to test as part of a PCI requirement. There are many companies that process credit card information. However, the traits that make your target organization unique and viable in a competitive market would have the greatest impact to the target organization if they were compromised.  Compromising credit cards would be bad.  Compromising the email addresses and credit card numbers of all the target organizations customers would be catastrophic.
+
= Goals =
 +
Every penetration test should be goal-oriented. This is to say that the purpose of the test is to identify specific vulnerabilities that lead to a compromise of the business or mission objectives of the customer. It is not about finding un-patched systems. It is about identifying risk that will adversely impact the organization.
  
'''Secondary'''
+
== Primary ==
 +
The primary goal of a test should not be driven by compliance. There are a number of different justifications for this reasoning. First, compliance does not equal security. While it should be understood that many organizations undergo testing because of compliance it should not be the main goal of the test. For example, a firm may be hired to complete a penetration test as part of PCI-DSS requirements.
  
The secondary goals are the ones that are directly related to compliance.  Usually these are tied to the primary goals very tightly. For example, getting the credit cards is the secondary goal. Tying that breach of data to the business or mission drivers of the organization is the primary goal.
+
There is no shortage of companies which process credit card information. However, the traits which make the target organization unique and viable in a competitive market will have the greatest impact if compromised. Credit card systems being compromised would certainly be a serious issue, but credit cards numbers, along with all of the associated customer data being leaked would be catastrophic.  
  
Think of it like this: secondary goals mean something for compliance and IT. Primary goals get the attention of the C-O’s.
+
== Secondary ==
 +
The secondary goals are directly related to compliance. It is not uncommon for primary and secondary goals to be very closely related. For example, in the example of the PCI-DSS driven test, getting the credit cards is the secondary goal. Tying that breach of data to the business or mission drivers of the organization is the primary goal. Secondary goals mean something for compliance and/or IT. Primary goals get the attention of upper management.
  
 +
== Business Analysis ==
 +
Before performing a penetration test it is beneficial to determine the maturity level of the client’s security posture. There are a number of organizations which choose to jump directly into a penetration test first assessing this maturity level. For customers with a very immature security program, it is often a good idea to perform a vulnerability analysis first.
  
'''Business Analysis'''
+
Some testers believe there is a stigma surrounding Vulnerability Analysis (VA) work. Those testers have forgotten that the goal is to identify risks in the target organization, not about pursuing the so-called “rockstar” lifestyle. If a company is not ready for a full penetration test, they will get far more value out of a good VA than a penetration test.
  
Before preforming a penetration test it is a good idea to define what level of security maturity your customer is at.  There are a number of organizations that choose to jump directly into a penetration test without any level of security maturity.  For these customers it is often a good idea to preform a vulnerability analysis first.  There is absolutely no shame in doing Vulnerability Analysis (VA) work.  Remember, the goal is identifying risks to your target organization.  It is not about being a l33t tester.  If a company is not ready for a full penetration test, they will most likely get far more value out of a good VA than a penetration test. Establish with the customer what information about the systems they want you to know in advance. You may also want to ask them for information about vulnerabilities they already know about; this will save you time and save them money if you don't have to re-discover and report on what they already knew. A full or partial white-box test may bring the customer more value than a black-box test, if it isn't absolutely required by compliance.
+
Establish with the customer in advance what information about the systems they will be providing. It may also be helpful to ask for information about vulnerabilities which are already documented. This will save the testers time and save the client money by not overlapping testing discoveries with known issues. Likewise, a full or partial white-box test may bring the customer more value than a black-box test, if it isn't absolutely required by compliance.
 
 
If you are asked to pentest an internal network (and you really should be -- assume the attacker started on the inside or is already there), you will need to gather more information about scope.  
 
  
 
= Establish Lines of Communication =
 
= Establish Lines of Communication =
 
+
One of the most important aspects of any penetration test is communication with the customer. How often you interact with the customer, and the manner in which you approach them, can make a huge difference in their feeling of satisfaction. Below is a communication framework that will aid in making the customer feel comfortable about the test activities.  
One of the most important aspects of any penetration test is communication with the customer. How often you interact with the customer, and the manner in which you approach them, can make a huge difference in their feeling of satisfaction. You don’t need to be a smooth talker, either.  Here, we will define a communication framework that will assist you and make the customer feel good about the test activities.
 
  
 
= Emergency Contact Information =
 
= Emergency Contact Information =
 +
Obviously, being able to get in touch with the customer or target organization in an emergency is vital. Emergencies may arise, and a point of contact must have been established in order to handle them.
 +
Create an emergency contact list. This list should include contact information for all parties in the scope of testing. Once created, the emergency contact list should be shared with all those on the list. Keep in mind, the target organization may not be the customer.
  
Obviously, being able to get in touch with the customer or target organization in an emergency is vital.  Emergencies may arise, both expected and unexpected, and you need to know who to contact.
+
Gather the following information about each emergency contact:  
 
+
# Full name  
Create an emergency contact list.  This list should include contact information for all parties in the scope of testing.  Once created, the emergency contact list should be shared with all those on the list.  Keep in mind, the target organization may not be the customer.
+
# Title and operational responsibility  
 
+
# Authorization to discuss details of the testing activities, if not already specified  
Gather the following information about each emergency contact:
+
# Two forms of 24/7 immediate contact, such as cell phone, pager, or home phone, if possible  
 
+
# One form of secure bulk data transfer, such as SFTP or encrypted email  
# Full name
+
Note: The number for a group such as the help desk or operations center can replace one emergency contact, but only if it is staffed 24/7.  
# Title and operational responsibility
+
The nature of each penetration test influences who should be on the emergency contact list. Not only will contact information for the customer and targets need to be made available, but they may also need to contact the testers in an emergency. The list should preferably include the following people:  
# Authorization to discuss details of the testing activities, if not already specified
+
# All penetration testers in the test group for the engagement  
# Two forms of 24/7 immediate contact, such as cell phone, pager, or home phone, if possible
+
# The manager of the test group  
# One form of secure bulk data transfer, such as SFTP or encrypted email
+
# Two technical contacts at each target organization  
 
+
# Two technical contacts at the customer  
Note: You may be given the name and phone number for a group like a help desk or operations center.  This can replace one emergency contact, but only if it is staffed 24/7.
+
# One upper management or business contact at the customer  
 
+
It is possible that there will be some overlap in the above list. For instance, the target organization may be the customer, the test group’s manager may also be performing the penetration test, or a customer’s technical contact may be in upper management. It is also recommended to define a single contact person per involved party who leads it and takes responsibility on behalf of it.  
The nature of penetration testing influences who should be on the emergency contact list. Not only do you need contact information for the customer and targets, but they may need to contact you in an emergency also. The list should preferably include the following people:
 
 
 
# All penetration testers in the test group for the engagement
 
# The manager of the test group
 
# Two technical contacts at each target organization
 
# Two technical contacts at the customer
 
# One upper management or business contact at the customer
 
 
 
It is possible that there will be some overlap in the above list. For instance, the target organization may be the customer, the test group’s manager may also be performing the penetration test, or a customer’s technical contact may be in upper management. It is also recommended to define a single contact person per involved party who leads it and takes responsibility on behalf of it.
 
 
 
'''Incident Reporting Process'''
 
 
 
Discussing the organization’s current incident response capabilities is important to do before an engagement for several reasons. Part of a penetration test is not only testing the security an organization has in place, but also what their incident response capabilities are. If you go from start to finish in your engagement and the organization never realized you were there, you’ve clearly identified a major gap in their security posture. You also want to make sure that before you start testing, that someone at their organization is aware of when the tests are being conducted so the incident response team does not start to call every member of the C-team in the middle of the night because they thought they were under attack or compromised.
 
 
 
'''Incident Definition'''
 
 
 
NIST defines an incident very well: “A computer security incident is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.” (Computer Security Incident Handling Guide - Special Publication 800-61 Rev 1). Now think about this in more than just a computer sense; an incident can also occur physically by someone trying to break into an organization. The organization you are testing should have different categories and levels for different types of incidents.
 
 
 
'''Status Report Frequency'''
 
 
 
The frequency of status reporting can vary widely.  Factors that influence the reporting schedule include the overall length of the test, the test scope, the target’s security maturity, etc.  You should agree on a schedule that allows the customer to feel engaged.  An ignored customer is a former customer.
 
 
 
Once you have set the frequency and schedule of status reports, stick to it!  This is one of those appearances that matter.  Postponing or delaying a status report may be necessary, but it should not become chronic--ask the client to agree on a new schedule if necessary.  Skipping a status report altogether is unprofessional and should be avoided.
 
 
 
'''PGP and other alternatives (Encryption is not an "option")'''
 
 
 
Communication with the customer is an absolutely necessary part of any penetration testing engagement and due to the sensitive nature of the engagement, communications of sensitive information should be encrypted, especially the final report.
 
 
 
Before you begin conducting your tests, establish a means of secure communication with the client. Several common means of encryption are as follows:
 
 
 
 
 
# PGP/GPG can be used to both communicate over e-mail and to encrypt the final report (remember that subject lines are passed through in plaintext though)
 
# A secure mailbox hosted on the customer’s network
 
# Telephone
 
# Face to face meetings
 
# To deliver the final report, you can also store the report in an AES encrypted archive file, but make sure that your archive utility supports AES encryption using CBC.
 
#Also ask what kinds of information can be put in writing and which should be communicated only verbally.  Whether you agree with it or not, some organizations have very good reasons for limiting what security information is transmitted to them in writing.
 
 
 
 
 
It is important that a means of secure communication is established with the customer beforehand and also that the customer is capable and comfortable with these means of communication.
 
 
 
= Rules of Engagement =
 
 
 
While the scope defines what it is you are supposed to test, the rules of engagement defines how testing is to occur. These are two different aspects that need to be handled independently from each other.
 
 
 
'''Timeline'''
 
 
 
You should have a clear timeline for your test.  While in scope you defined start and end times, now it is time to define everything in between.  We understand that the timeline will change as the test progresses. However, having a rigid timeline is not the goal of creating a timeline.  Rather, a timeline at the beginning of a test will allow you and your customer to more clearly identify the work that is to be done and the people that will be responsible for the work.  We often use GANTT charts and Work breakdown structure to define the work and the amount of time that each specific section of the work will take.  Seeing the schedule broken down like this helps you identify the resources that need to be allocated and it helps the customer identify possible roadblocks that many be encountered during testing.
 
 
 
There are a number of free GANTT chart tools available on the Internet.  find one that works best for you and use it heavily when developing a testing road map.  If nothing else, many mangers resonate with these tools and it may be an excellent medium for communicating with the upper management of a target organization.
 
 
 
'''Locations'''
 
 
 
It is also important to discuss with the customer where the locations are that they will need you to travel to for testing.  This could be something as simple as identifying local hotels.  And, it may be something as complex as identifying the laws of a specific target country.
 
 
 
Sometimes an organization has multiple locations and you will need to identify a few sample locations for testing.  In these situations try to avoid having to travel to all customer locations.  Many times there are VPN connections available for testing.
 
 
 
'''Disclosure of Sensitive Information'''
 
 
 
While one of your goals may be to gain access to sensitive information, you may not actually want to view it or download it.  This seems odd to newer testers, however, there are a number of situations where you do not want the target data on your system.  For example, PHI.  Under HIPAA this data needs to be protected.  In may situations your testing system may not have a firewall or AV running on it.  This would be a good situation where you would not want PII anywhere near your computer.
 
 
 
So the question becomes “how can I prove I had access without getting the data?”  There are a number of different ways you can prove access without showing data.  For example, you can display a database schema, you can show permissions of systems you have accessed, you can show the files without showing the content. 
 
 
 
The level of paranoia you want to employ for your tests is something you will need to decide with your customer.  Either way you will want to scrub your test machine of results in between tests.  This also applies to the report templates you use as well.
 
  
As a special side note, if you encounter illegal data (i.e. child porn) immediately notify law enforcement, then your customer in that order.  Do not notify the customer and take direction from them.  Simply viewing child pornography is a crime.
+
== Incident Reporting Process ==
 +
Discussing the organization’s current incident response capabilities is important to do before an engagement for several reasons. Part of a penetration test is not only testing the security an organization has in place, but also their incident response capabilities.
  
'''Evidence Handling'''
+
If an entire engagement can be completed without the target’s internal security teams ever noticing, a major gap in security posture has been identified. It is also important to ensure that before testing begins, someone at the target organization is aware of when the tests are being conducted so the incident response team does not start to call every member of upper management in the middle of the night because they thought they were under attack or compromised.
  
When handling evidence of a test and the differing stages of the report it is incredibly important to take extreme care with the data.  Always use encryption and sanitize your test machine between tests.  Never hand out USB sticks with test reports out at security conferences. And whatever you do, don't re-use a report from another customer engagement as a template! It's very unprofessional to leave references to another organization in your document.
+
== Incident Definition ==
 +
The National Institute of Standards and Technology (NIST) defines an incident as follows: “a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.” (Computer Security Incident Handling Guide - Special Publication 800-61 Rev 1). An incident can also occur on a physical level, wherein a person gain unauthorized physical access to an area by any means. The target organization should have different categories and levels for different types of incidents.  
  
'''Regular Status Meetings'''
+
== Status Report Frequency ==
 +
The frequency of status reporting can vary widely. Some factors which influence the reporting schedule include the overall length of the test, the test scope, and the target’s security maturity. An effective schedule allows the customer to feel engaged. An ignored customer is a former customer.
  
Throughout the testing process it is critical to have regular meetings with the customer informing them of the overall progress of the testThese meetings should be held daily and should be as short as possible.  We generally see our meetings cover three very simple things: plans, progress and problems.  
+
Once frequency and schedule of status reports has been set, it must be fulfilled. Postponing or delaying a status report may be necessary, but it should not become chronicThe client may be asked to agree to a new schedule if necessary. Skipping a status report altogether is unprofessional and should be avoided if at all possible.  
  
For plans you should describe what it is you are planning on doing that day. The reason for this is to make sure you will not be testing during a change or an outage.
+
== PGP and Other Alternatives ==
 +
Encryption is not optional. Communication with the customer is an absolutely necessary part of any penetration testing engagement and due to the sensitive nature of the engagement, communications of sensitive information must be encrypted, especially the final report.
 +
Before the testing begins, a means of secure communication must be established with the client. Several common means of encryption are as follows:
 +
# PGP/GPG can be used to both communicate over e-mail and to encrypt the final report (remember that subject lines are passed through in plaintext)
 +
# A secure mailbox hosted on the customer’s network
 +
# Telephone
 +
# Face to face meetings
 +
# To deliver the final report, you can also store the report in an AES encrypted archive file, but make sure that your archive utility supports AES encryption using CBC.
 +
Also ask what kinds of information can be put in writing and which should be communicated only verbally. Some organizations have very good reasons for limiting what security information is transmitted to them in writing.  
  
For progress you should inform what you have completed since the previous meeting.
+
= Rules of Engagement =
 +
While the scope defines what will be tested, the rules of engagement defines how that testing is to occur. These are two different aspects which need to be handled independently from each other.  
  
For problems you should communicate with the customer any issues that will impact the overall timing of the test. If there are specific people identified to rectify the situation you should not discuss the solution to the problem during the status meeting.  Take the conversation offline.
+
== Timeline ==
 +
A clear timeline should be established for the engagement. While scope defines the start and the end of an engagement, the rules of engagement define everything in between. It should be understood that the timeline will change as the test progresses. However, having a rigid timeline is not the goal of creating one. Rather, having a timeline in place at the beginning of a test will allow everyone involved to more clearly identify the work that is to be done and the people who will be responsible for said work. GANTT Charts and Work Breakdown Structures are often used to define the work and the amount of time that each specific piece of the work will take. Seeing the schedule broken down in this manner aids those involved in identifying where resources need to be applied and it helps the customer identify possible roadblocks which many be encountered during testing.
  
The goal of the status meeting is to have a 30 minute or less meeting and take any longer conversations offline with only the specific individuals required to solve the issue.
+
There are a number of free GANTT Chart tools available on the Internet. Many mangers identify closely with these tools.  Because of this, they are an excellent medium for communicating with the upper management of a target organization.
  
'''Time of the Day to Test'''
+
== Locations ==
 +
Another parameter of any given engagement which is important to establish with the customer ahead of time is any destinations to which the testers will need to travel during the test. This could be as simple as identifying local hotels, or complex as identifying the applicable laws of a specific target country.
  
There are better times of the day for testing than others for many customers. Unfortunately, this can mean many late nights for the penetration testers.  Be sure that times of testing are clearly communicated with the customer before testing begins.
+
It is not uncommon for an organization to operate in multiple locations and regions and a few select sites will need to be chosen for testing. In these situations, travel to every customer location should be avoided, instead, it should be determined if VPN connections to the sites are available for remote testing.  
 +
Disclosure of Sensitive Information
  
'''Dealing with Shunning'''
+
While one of the goals of a given engagement may be to gain access to sensitive information, certain information should not actually be viewed or downloaded. This seems odd to newer testers, however, there are a number of situations where the testers should not have the target data in their possession.  For example Personal Health Information (PHI), under the Health Insurance Portability and Accountability Act (HIPAA), this data must be protected. In some situations, the target system may not have a firewall or anti-virus (AV) protecting it. In this sort of situation, the testers being in possession of any and all Personally Identifiable Information (PII) should be absolutely avoided.
  
There are times where shunning is perfectly acceptable and there are times where it may not fit the spirit of the test. For example, if your test is to be a full black-box test where you are testing not only the technology, but the capabilities of the target organization’s security team, shunning would be perfectly fine.  However, when you are testing a large number of systems in coordination with the target organization's security team it may not be in the best interests of the test to shun your attacks.
+
However, if the data cannot be physically or virtually obtained, how can it be proved that the testers indeed obtained access to the information? This problem has been solved in a number of ways. There are ways to prove that the vault door was opened without taking any of the money. For instance, a screenshot of database schema and file permissions can be taken, or the files themselves can be displayed without opening them to displaying the content, as long as no PII is visible in the filenames themselves.
  
'''Permission to Test'''
+
How cautious the testers should be on a given engagement is a parameter which needs to be discussed with the client, but the firm doing the testing should always be sure to protect themselves in a legal sense regardless of client opinion.  Regardless of supposed exposure to sensitive data, all report templates and tester machines should be sufficiently scrubbed following each engagement.
 +
As a special side note, if illegal data (i.e. child pornography) is discovered by the testers, proper law enforcement officials should be notified immediately, followed by the customer. Do not take direction from the customer.
  
This is quite possibly the single most important document you can receive when testing.  This documents the scope and it is where the customer signs off on the fact that they are going to be tested for security vulnerabilities and their systems may be compromised. Further, it should clearly state that testing can lead to system instability and all due care will be given by the tester to not crash systems in the process.  However, because testing can lead to instability the customer shall not hold the tester liable for any system instability or crashes.
+
== Evidence Handling ==
 +
When handling evidence of a test and the differing stages of the report it is incredibly important to take extreme care with the data. Always use encryption and sanitize your test machine between tests. Never hand out USB sticks with test reports out at security conferences. And whatever you do, don't re-use a report from another customer engagement as a template! It's very unprofessional to leave references to another organization in your document.  
  
It is critical that testing does not begin until this document is signed by the customer.
+
== Regular Status Meetings ==
 +
Throughout the testing process it is critical to have regular meetings with the customer informing them of the overall progress of the test. These meetings should be held daily and should be as short as possible. Meetings should be kept to three concepts: plans, progress and problems.  
  
In addition, some service providers require advance notice and/or separate permission prior to testing their systems. For example, Amazon has an online request form that must be completed, and the request must be approved before scanning any hosts on their cloud.
+
Plans are generally discussed so that testing is not conducted during a major unscheduled change or an outage.  Progress is simply an update to the customer on what has been completed so far. Problems should also be discussed in this meeting, but in the interest of brevity, conversations concerning solutions should almost always be taken offline.  
  
'''Legal Considerations'''
+
== Time of the Day to Test ==
 +
Certain customers require all testing to be done outside of business hours.  This can mean late nights for most testers.  The time of day requirements should be well established with the customer before testing begins.
  
Some activities common in penetration tests may violate local laws. For this reason, it is advised to check the legality of common pentest tasks in the location where the work is to be performed. For example,any VOIP calls captured in the course of the penetration test may be considered wiretapping in some areas.
+
== Dealing with Shunning ==
 +
There are times where shunning is perfectly acceptable and there are times where it may not fit the spirit of the test. For example, if your test is to be a full black-box test where you are testing not only the technology, but the capabilities of the target organization’s security team, shunning would be perfectly fine. However, when you are testing a large number of systems in coordination with the target organization's security team it may not be in the best interests of the test to shun your attacks.  
  
= Capabilities and Technology in Place =
+
== Permission to Test ==
 +
One of the most important documents which need to be obtained for a penetration test is the Permission to Test document. This document states the scope and contains a signature which acknowledges awareness of the activities of the testers. Further, it should clearly state that testing can lead to system instability and all due care will be given by the tester to not crash systems in the process. However, because testing can lead to instability the customer shall not hold the tester liable for any system instability or crashes.
 +
It is critical that testing does not begin until this document is signed by the customer.
  
Good penetration tests do not simply check for un-patched systems. They also test the capabilities of the target organization. To that end, below is a list of things that you can benchmark while testing.
+
In addition, some service providers require advance notice and/or separate permission prior to testing their systems. For example, Amazon has an online request form that must be completed, and the request must be approved before scanning any hosts on their cloud. If this is required, it should be part of the document.  
  
# Ability to detect and respond to information gathering
+
== Legal Considerations ==
# Ability to detect and respond to foot printing
+
Some activities common in penetration tests may violate local laws. For this reason, it is advised to check the legality of common pentest tasks in the location where the work is to be performed. For example,any VOIP calls captured in the course of the penetration test may be considered wiretapping in some areas.
# Ability to detect and respond to scanning and vuln analysis
 
# Ability to detect and respond to infiltration (attacks)
 
# Ability to detect and respond to data aggregation
 
# Ability to detect and respond to data ex-filtration
 
  
When tracking this information be sure to collect time information. For example, if a scan is detected you should be notified and note what level of scan you were preforming at the time.
+
= Capabilities and Technology in Place =
 +
Good penetration tests do not simply check for un-patched systems. They also test the capabilities of the target organization. To that end, below is a list of things that you can benchmark while testing.
 +
# Ability to detect and respond to information gathering
 +
# Ability to detect and respond to foot printing
 +
# Ability to detect and respond to scanning and vuln analysis
 +
# Ability to detect and respond to infiltration (attacks)
 +
# Ability to detect and respond to data aggregation
 +
# Ability to detect and respond to data ex-filtration
 +
When tracking this information be sure to collect time information. For example, if a scan is detected you should be notified and note what level of scan you were preforming at the time.

Latest revision as of 18:13, 16 August 2014

Overview

The aim of this section of the PTES is to present and explain the tools and techniques available which aid in a successful pre-engagement step of a penetration test. The information within this section is the result of the many years of combined experience of some of the most successful penetration testers in the world.

If you are a customer looking for penetration test we strongly recommend going to the General Questions section of this document. It covers the major questions that should be answered before a test begins. Remember, a penetration test should not be confrontational. It should not be an activity to see if the tester can "hack" you. It should be about identifying the business risk associated with and attack.

To get maximum value, make sure the questions in this document are covered. Further, as the Scoping activity progresses, a good testing firm will start to ask additional questions tailored to your organization.

Introduction to Scope

Defining scope is arguably one of the most important components of a penetration test, yet it is also one of the most overlooked. While many volumes have been written about the different tools and techniques which can be utilized to gain access to a network, very little has been written on the topic which precedes the penetration: preparation. Neglecting to properly complete pre-engagement activities has the potential to open the penetration tester (or his firm) to a number of headaches including scope creep, unsatisfied customers, and even legal troubles. The scope of a project specifically defines what is to be tested. How each aspect of the test will be conducted will be covered in the Rules of Engagement section.

One key component of scoping an engagement is outlining how the testers should spend their time. As an example, a customer requests that one hundred IP addresses be tested for the price of $100,000. This means that the customer is offering $1,000 per IP address tested. However, this cost structure only remains effective at that volume. A common trap some testers fall into is maintaining linear costs throughout the testing process. If the customer had only asked for one business-critical application to be tested at the same pricing structure ($1,000), while the tester will still be only attacking a single IP, the volume of work has increased dramatically. It is important to vary costs based on work done. Otherwise a firm can easily find themselves undercharging for their services, which motivates them to do a less than complete job.

Despite having a solid pricing structure, the process is not all black and white. It is not uncommon for a client to be completely unaware of exactly what it is they need tested. It is also possible the client will not know how to communicate effectively what they’re expecting from the test. It is important in the Pre-Engagement phase that the tester is able to serve as a guide through what may be uncharted territory for a customer. The tester must understand the difference between a test which focuses on a single application with severe intensity and a test where the client provides a wide range of IP addresses to test and the goal is to simply find a way in.

Metrics for Time Estimation

Time estimations are directly tied to the experience of a tester in a certain area. If a tester has significant experience in a certain test, he will likely innately be able to determine how long a test will take. If the tester has less experience in the area, re-reading emails and scan logs from previous similar tests the firm has done is a great way to estimate the time requirement for the current engagement. Once the time to test is determined, it is a prudent practice to add 20% to the time.

The extra 20% on the back end of the time value is called padding. Outside of consultant circles, this is also referred to as consultant overhead. The padding is an absolute necessity for any test. It provides a cushion should any interruptions occur in the testing. There are many events which commonly occur and hinder the testing process. For example, a network segment may go down, or a significant vulnerability may be found which requires many meetings with many levels of management to address. Both of these events are time consuming and would significantly impact the original time estimate if the padding was not in place.

What happens if the 20% padding ends up not being necessary? Billing the client for time not worked would be extremely unethical, so it is up to the testers to provide additional value that may not normally have been provided if the engagement time limit had been hit. Examples include walking the company security team through the steps taken to exploit the vulnerability, provide an executive summary if it was not part of the original deliverable list, or spend some additional time trying to crack a vulnerability that was elusive during the initial testing.

Another component of the metrics of time and testing is that every project needs to have a definitive drop dead date. All good projects have a well-defined beginning and end. You will need to have a signed statement of work specifying the work and the hours required if you’ve reached the specific date the testing is to end, or if any additional testing or work is requested of you after that date. Some testers have a difficult time doing this because they feel they are being too much of a pain when it comes to cost and hours. However, it has been the experience of the author that if you provide exceptional value for the main test the customer will not balk at paying you for additional work.

Scoping Meeting

In many cases the scoping meeting will occur after the contract has been signed. Situations do occur wherein many of the scope-related topics can be discussed before contract signing, but they are few and far between. For those situations it is recommended that a non-disclosure agreement be signed before any in-depth scoping discussions occur.

The goal of the scoping meeting is to discuss what will be tested. Rules of engagement and costs will not be covered in this meeting. Each of these subjects should be handled in meetings where each piece is the focus of that meeting. This is done because discussions can easily become confused and muddled if focus is not explicitly stated. It is important to act as moderator and keep the discussions on-topic, preventing tangents and declaring certain topics more suited for off-line discussion when necessary.

Now that a Rough Order of Magnitude (ROM) value has been established for the project it is time to have a meeting with the customer to validate assumptions. First, it needs to be established explicitly what IP ranges are in scope for the engagement. It is not uncommon for a client to be resistant and assume that it is the prerogative of the tester to identify their network and attack it, to make the test as realistic as possible. This would indeed be an ideal circumstance, however, possible legal ramifications must be considered above all else. Because of this, it is the responsibility of the tester to convey to a client these concerns and to impart upon them the importance of implicit scoping. For example, in the meeting, it should be verified that the customer owns all of the target environments including: the DNS server, the email server, the actual hardware their web servers run on and their firewall/IDS/IPS solution. There are a number of companies which will outsource the management of these devices to third parties.

Additionally, the countries, provinces, and states in which the target environments operate in must be identified. Laws vary from region to region and the testing may very well be impacted by these laws. For instance, countries belonging to the European Union are well known to have very stringent laws surrounding the privacy of individuals, which can significantly change the manner in which a social engineering engagement would be executed.

Additional Support Based on Hourly Rate

Anything that is not explicitly covered within the scope of the engagement should be handled very carefully. The first reason for this is scope creep. As the scope expands, resources are consumed, cutting into the profits for the tester and may even create confusion and anger on the part of the customer. There is another issue that many testers do not think of when taking on additional work on an ad-hoc basis: legal ramifications. Many ad-hoc requests are not properly documented so it can be difficult to determine who said what in the event of a dispute or legal action. Further, the contract is a legal document specifying the work that is to be done. It should be tightly tied to the permission to test memo.

Any requests outside of the original scope should be documented in the form of a statement of work that clearly identifies the work to be done. We also recommend that it be clearly stated in the contract that additional work will be done for a flat fee per hour and explicitly state that additional work can not be completed until a signed and counter-signed SOW is in place.

Questionnaires

During initial communications with the customer there are several questions which the client will have to answer in order for the engagement scope can be properly estimated. These questions are designed to provide a better understanding of what the client is looking to gain out of the penetration test, why the client is looking to have a penetration test performed against their environment, and whether or not they want certain types of tests performed during the penetration test. The following are sample questions which may be asked during this phase.

General Questions

Network Penetration Test

  1. Why is the customer having the penetration test performed against their environment?
  2. Is the penetration test required for a specific compliance requirement?
  3. When does the customer want the active portions (scanning, enumeration, exploitation, etc...) of the penetration test conducted?
    1. During business hours?
    2. After business hours?
    3. On the weekends?
  4. How many total IP addresses are being tested?
    1. How many internal IP addresses, if applicable?
    2. How many external IP addresses, if applicable?
  5. Are there any devices in place that may impact the results of a penetration test such as a firewall, intrusion detection/prevention system, web application firewall, or load balancer?
  6. In the case that a system is penetrated, how should the testing team proceed?
    1. Perform a local vulnerability assessment on the compromised machine?
    2. Attempt to gain the highest privileges (root on Unix machines, SYSTEM or Administrator on Windows machines) on the compromised machine?
    3. Perform no, minimal, dictionary, or exhaustive password attacks against local password hashes obtained (for example, /etc/shadow on Unix machines)?

Web Application Penetration Test

  1. How many web applications are being assessed?
  2. How many login systems are being assessed?
  3. How many static pages are being assessed? (approximate)
  4. How many dynamic pages are being assessed? (approximate)
  5. Will the source code be made readily available?
  6. Will there be any kind of documentation?
    1. If yes, what kind of documentation?
  7. Will static analysis be performed on this application?
  8. Does the client want fuzzing performed against this application?
  9. Does the client want role-based testing performed against this application?
  10. Does the client want credentialed scans of web applications performed?

Wireless Network Penetration Test

  1. How many wireless networks are in place?
  2. Is a guest wireless network used? If so:
    1. Does the guest network require authentication?
    2. What type of encryption is used on the wireless networks?
    3. What is the square footage of coverage?
    4. Will enumeration of rogue devices be necessary?
    5. Will the team be assessing wireless attacks against clients?
    6. Approximately how many clients will be using the wireless network?

Physical Penetration Test

  1. How many locations are being assessed?
  2. Is this physical location a shared facility? If so:
    1. How many floors are in scope?
    2. Which floors are in scope?
  3. Are there any security guards that will need to be bypassed? If so:
    1. Are the security guards employed through a 3rd party?
    2. Are they armed?
    3. Are they allowed to use force?
  4. How many entrances are there into the building?
  5. Is the use of lock picks or bump keys allowed? (also consider local laws)
  6. Is the purpose of this test to verify compliance with existing policies and procedures or for performing an audit?
  7. What is the square footage of the area in scope?
  8. Are all physical security measures documented?
  9. Are video cameras being used?
    1. Are the cameras client-owned? If so:
      1. Should the team attempt to gain access to where the video camera data is stored?
  10. Is there an armed alarm system being used? If so:
    1. Is the alarm a silent alarm?
    2. Is the alarm triggered by motion?
    3. Is the alarm triggered by opening of doors and windows?

Social Engineering

  1. Does the client have a list of email addresses they would like a Social Engineering attack to be performed against?
  2. Does the client have a list of phone numbers they would like a Social Engineering attack to be performed against?
  3. Is Social Engineering for the purpose of gaining unauthorized physical access approved? If so:
    1. How many people will be targeted?

It should be noted that as part of different levels of testing, the questions for Business Unit Managers, Systems Administrators, and Help Desk Personnel may not be required. However, in the case these questions are necessary, some sample questions can be found below.

Questions for Business Unit Managers

  1. Is the manager aware that a test is about to be performed?
  2. What is the main datum that would create the greatest risk to the organization if exposed, corrupted, or deleted?
  3. Are testing and validation procedures to verify that business applications are functioning properly in place?
  4. Will the testers have access to the Quality Assurance testing procedures from when the application was first developed?
  5. Are Disaster Recovery Procedures in place for the application data?

Questions for Systems Administrators

  1. Are there any systems which could be characterized as fragile? (systems with tendencies to crash, older operating systems, or which are unpatched)
  2. Are there systems on the network which the client does not own, that may require additional approval to test?
  3. Are Change Management procedures in place?
  4. What is the mean time to repair systems outages?
  5. Is any system monitoring software in place?
  6. What are the most critical servers and applications?
  7. Are backups tested on a regular basis?
  8. When was the last time the backups were restored?

Scope Creep

Scope creep is one of the most efficient ways to put a penetration testing firm out of business. The issue is that many companies and managers have little to no idea how to identify it, or how to react to it when it happens.

There are a couple of things to remember when battling scope creep. First, if a customer is pleased with the work done on a particular engagement, it is very common for them to request additional work. Take this as a compliment, and do not hesitate to ask for additional funding to compensate for the extra time spent. If a customer refuses to pay for the extra work, it is almost never worth staying on to do that work.

The second point is even more critical. When dealing with existing customers, take care to keep the prices lower. Taking advantage of a good situation by price gouging is a sure way to drive away repeat business. Take into consideration that prices can be lowered since the firm avoided the costs of acquiring the customer such as the formal RFP process and hunting for the customer itself. Further, the best source for future work is through existing customers. Treat them well and they will return.

Specify Start and End Dates

Another key component defeating scope creep is explicitly stating start and end dates. This allows the project to have definite end. One of the most common areas in which scope creep occurs is during retesting. Retesting always sounds like a good idea when going after a contract. It shows that the firm is caring and diligent, trying to make ensure that the customer is secure as possible. The problem begins when it is forgotten that the work is not paid for until it is completed. This includes retesting.

To mitigate this risk, add a simple statement to the contract which mentions that all retesting must be done within a certain timeframe after the final report delivery. It then becomes the responsibility of the testers to spearhead the retesting effort. If the customer requests an extension, always allow this with the condition that payment be fulfilled at the originally specified date. Finally, and most importantly, perform a quality retest. Remember, the best source for future work is your existing customer base.

Specify IP Ranges and Domains

Before starting a penetration test, all targets must be identified. These targets should be obtained from the customer during the initial questionnaire phase. Targets can be given in the form of specific IP addresses, network ranges, or domain names by the customer. In some instances, the only target the customer provides is the name of the organization and expects the testers be able to identify the rest on their own. It is important to define if systems like firewalls and IDS/IPS or networking equipment that are between the tester and the final target are also part of the scope. Additional elements such as upstream providers, and other 3rd party providers should be identified and defined whether they are in scope or not.

Validate Ranges

It is imperative that before you start to attack the targets you validate that they are in fact owned by the customer you are performing the test against. Think of the legal consequences you may run into if you start attacking a machine and successfully penetrate it only to find out later down the line that the machine actually belongs to another organization (such as a hospital or government agency).

Dealing with Third Parties

There are a number of situations where an engagement will include testing a service or an application that is being hosted by a third party. This has become more prevalent in recent years as “cloud” services have become more popular. The most important thing to remember is that while permission may have been granted by the client, they do not speak for their third party providers. Thus, permission must be obtained from them as well in order to test the hosted systems. Failing to obtain the proper permissions brings with it, as always, the possibility of violating the law, which can cause endless headaches.

Cloud Services

The single biggest issue with testing cloud service is there is data from multiple different organizations stored on one physical medium. Often the security between these different data domains is very lax. The cloud services provider needs to be alerted to the testing and needs to acknowledge that the test is occurring and grant the testing organization permission to test. Further, there needs to be a direct security contact within the cloud service provider that can be contacted in the event that a security vulnerability is discovered which may impact the other cloud customers. Some cloud providers have specific procedures for penetration testers to follow, and may require request forms, scheduling or explicit permission from them before testing can begin.

ISP

Verify the ISP terms of service with the customer. In many commercial situations the ISP will have specific provisions for testing. Review these terms carefully before launching an attack. There are situations where ISPs will shun and block certain traffic which is considered malicious. The customer may approve this risk, but it must always be clearly communicated before beginning. Web Hosting As with all other third parties, the scope and timing of the test needs to be clearly communicated with the web hosting provider. Also, when communicating with the client, be sure to clearly articulate the test will only be in search of web vulnerabilities. The test will not uncover vulnerabilities in the underlying infrastructure which may still provide an avenue to compromise the application.

MSSPs

Managed Security Service Providers also may need to be notified of testing. Specifically, they will need to be notified when the systems and services that they own are to be tested. However, there are circumstances under which the MSSP would not be notified. If determining the actual response time of the MSSP is part of the test, it is certainly not in the best interest of the integrity of the test for the MSSP to be notified. As a general rule of thumb, any time a device or service explicitly owned by the MSSP is being tested they will need to be notified.

Countries Where Servers are Hosted

It is also in the best interests of the tester to verify the countries where servers are being housed. After you have validated the country, review the laws of the specific country before beginning testing. It should not be assumed that the firm’s legal team will provide a complete synopsis of local laws for the testers. It should also not be assumed that the firm will take legal responsibility for any laws violated by its testers. It is the responsibility of each tester to verify the laws for each region they are testing in before they begin testing because it will be the tester who ultimately will have to answer for any transgressions.

Define Acceptable Social Engineering Pretexts

Many organizations will want their security posture tested in a way which is aligned with current attacks. Social engineering and spear-phishing attacks are currently widely used by many attackers today. While most of the successful attacks use pretexts like sex, drugs, and rock and roll (porn, Viagra, and free iPods respectively) some of these pretexts may not be acceptable in a corporate environment. Be sure that any pretexts chosen for the test are approved in writing before testing is to begin.

DoS Testing

Stress testing or Denial of Service testing should be discussed before the engagement begins. It can be a topic that many organizations are uncomfortable with due to the potentially damaging nature of the testing. If an organization is only worried about the confidentiality or integrity of their data, stress testing may not be necessary; however, if the organization is also worried about the availability of their services, then the stress testing should be conducted in a non-production environment which is identical to the production environment.

Payment Terms

Another aspect of preparing for a test that many testers completely forget about is how they should be paid. Just like contract dates there should be specific dates and terms for payments. It is not uncommon for larger organizations to delay payment for as long as possible. Below are a few common payment methods. These are simply examples. It is definitely recommended that each organization create and tweak their own pricing structure to more aptly suit the needs of their clients and themselves. The important thing is that some sort of structure be in place before testing begins.

Net 30

The total amount is due within 30 days of the delivery of the final report. This is usually associated with a per month percentage penalty for non-payment. This can be any number of days you wish to grant your customers (i.e. 45, or 60).

Half Upfront

It is not uncommon to require half of the total bill upfront before testing begins. This is very common for longer-term engagements.

Recurring

A recurring payment schedule is more commonly used for long-term engagements. For example, some engagements may span as far as a year or two. It is not at all uncommon to have the customer pay in regular installments throughout the year.

Goals

Every penetration test should be goal-oriented. This is to say that the purpose of the test is to identify specific vulnerabilities that lead to a compromise of the business or mission objectives of the customer. It is not about finding un-patched systems. It is about identifying risk that will adversely impact the organization.

Primary

The primary goal of a test should not be driven by compliance. There are a number of different justifications for this reasoning. First, compliance does not equal security. While it should be understood that many organizations undergo testing because of compliance it should not be the main goal of the test. For example, a firm may be hired to complete a penetration test as part of PCI-DSS requirements.

There is no shortage of companies which process credit card information. However, the traits which make the target organization unique and viable in a competitive market will have the greatest impact if compromised. Credit card systems being compromised would certainly be a serious issue, but credit cards numbers, along with all of the associated customer data being leaked would be catastrophic.

Secondary

The secondary goals are directly related to compliance. It is not uncommon for primary and secondary goals to be very closely related. For example, in the example of the PCI-DSS driven test, getting the credit cards is the secondary goal. Tying that breach of data to the business or mission drivers of the organization is the primary goal. Secondary goals mean something for compliance and/or IT. Primary goals get the attention of upper management.

Business Analysis

Before performing a penetration test it is beneficial to determine the maturity level of the client’s security posture. There are a number of organizations which choose to jump directly into a penetration test first assessing this maturity level. For customers with a very immature security program, it is often a good idea to perform a vulnerability analysis first.

Some testers believe there is a stigma surrounding Vulnerability Analysis (VA) work. Those testers have forgotten that the goal is to identify risks in the target organization, not about pursuing the so-called “rockstar” lifestyle. If a company is not ready for a full penetration test, they will get far more value out of a good VA than a penetration test.

Establish with the customer in advance what information about the systems they will be providing. It may also be helpful to ask for information about vulnerabilities which are already documented. This will save the testers time and save the client money by not overlapping testing discoveries with known issues. Likewise, a full or partial white-box test may bring the customer more value than a black-box test, if it isn't absolutely required by compliance.

Establish Lines of Communication

One of the most important aspects of any penetration test is communication with the customer. How often you interact with the customer, and the manner in which you approach them, can make a huge difference in their feeling of satisfaction. Below is a communication framework that will aid in making the customer feel comfortable about the test activities.

Emergency Contact Information

Obviously, being able to get in touch with the customer or target organization in an emergency is vital. Emergencies may arise, and a point of contact must have been established in order to handle them. Create an emergency contact list. This list should include contact information for all parties in the scope of testing. Once created, the emergency contact list should be shared with all those on the list. Keep in mind, the target organization may not be the customer.

Gather the following information about each emergency contact:

  1. Full name
  2. Title and operational responsibility
  3. Authorization to discuss details of the testing activities, if not already specified
  4. Two forms of 24/7 immediate contact, such as cell phone, pager, or home phone, if possible
  5. One form of secure bulk data transfer, such as SFTP or encrypted email

Note: The number for a group such as the help desk or operations center can replace one emergency contact, but only if it is staffed 24/7. The nature of each penetration test influences who should be on the emergency contact list. Not only will contact information for the customer and targets need to be made available, but they may also need to contact the testers in an emergency. The list should preferably include the following people:

  1. All penetration testers in the test group for the engagement
  2. The manager of the test group
  3. Two technical contacts at each target organization
  4. Two technical contacts at the customer
  5. One upper management or business contact at the customer

It is possible that there will be some overlap in the above list. For instance, the target organization may be the customer, the test group’s manager may also be performing the penetration test, or a customer’s technical contact may be in upper management. It is also recommended to define a single contact person per involved party who leads it and takes responsibility on behalf of it.

Incident Reporting Process

Discussing the organization’s current incident response capabilities is important to do before an engagement for several reasons. Part of a penetration test is not only testing the security an organization has in place, but also their incident response capabilities.

If an entire engagement can be completed without the target’s internal security teams ever noticing, a major gap in security posture has been identified. It is also important to ensure that before testing begins, someone at the target organization is aware of when the tests are being conducted so the incident response team does not start to call every member of upper management in the middle of the night because they thought they were under attack or compromised.

Incident Definition

The National Institute of Standards and Technology (NIST) defines an incident as follows: “a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.” (Computer Security Incident Handling Guide - Special Publication 800-61 Rev 1). An incident can also occur on a physical level, wherein a person gain unauthorized physical access to an area by any means. The target organization should have different categories and levels for different types of incidents.

Status Report Frequency

The frequency of status reporting can vary widely. Some factors which influence the reporting schedule include the overall length of the test, the test scope, and the target’s security maturity. An effective schedule allows the customer to feel engaged. An ignored customer is a former customer.

Once frequency and schedule of status reports has been set, it must be fulfilled. Postponing or delaying a status report may be necessary, but it should not become chronic. The client may be asked to agree to a new schedule if necessary. Skipping a status report altogether is unprofessional and should be avoided if at all possible.

PGP and Other Alternatives

Encryption is not optional. Communication with the customer is an absolutely necessary part of any penetration testing engagement and due to the sensitive nature of the engagement, communications of sensitive information must be encrypted, especially the final report. Before the testing begins, a means of secure communication must be established with the client. Several common means of encryption are as follows:

  1. PGP/GPG can be used to both communicate over e-mail and to encrypt the final report (remember that subject lines are passed through in plaintext)
  2. A secure mailbox hosted on the customer’s network
  3. Telephone
  4. Face to face meetings
  5. To deliver the final report, you can also store the report in an AES encrypted archive file, but make sure that your archive utility supports AES encryption using CBC.

Also ask what kinds of information can be put in writing and which should be communicated only verbally. Some organizations have very good reasons for limiting what security information is transmitted to them in writing.

Rules of Engagement

While the scope defines what will be tested, the rules of engagement defines how that testing is to occur. These are two different aspects which need to be handled independently from each other.

Timeline

A clear timeline should be established for the engagement. While scope defines the start and the end of an engagement, the rules of engagement define everything in between. It should be understood that the timeline will change as the test progresses. However, having a rigid timeline is not the goal of creating one. Rather, having a timeline in place at the beginning of a test will allow everyone involved to more clearly identify the work that is to be done and the people who will be responsible for said work. GANTT Charts and Work Breakdown Structures are often used to define the work and the amount of time that each specific piece of the work will take. Seeing the schedule broken down in this manner aids those involved in identifying where resources need to be applied and it helps the customer identify possible roadblocks which many be encountered during testing.

There are a number of free GANTT Chart tools available on the Internet. Many mangers identify closely with these tools. Because of this, they are an excellent medium for communicating with the upper management of a target organization.

Locations

Another parameter of any given engagement which is important to establish with the customer ahead of time is any destinations to which the testers will need to travel during the test. This could be as simple as identifying local hotels, or complex as identifying the applicable laws of a specific target country.

It is not uncommon for an organization to operate in multiple locations and regions and a few select sites will need to be chosen for testing. In these situations, travel to every customer location should be avoided, instead, it should be determined if VPN connections to the sites are available for remote testing. Disclosure of Sensitive Information

While one of the goals of a given engagement may be to gain access to sensitive information, certain information should not actually be viewed or downloaded. This seems odd to newer testers, however, there are a number of situations where the testers should not have the target data in their possession. For example Personal Health Information (PHI), under the Health Insurance Portability and Accountability Act (HIPAA), this data must be protected. In some situations, the target system may not have a firewall or anti-virus (AV) protecting it. In this sort of situation, the testers being in possession of any and all Personally Identifiable Information (PII) should be absolutely avoided.

However, if the data cannot be physically or virtually obtained, how can it be proved that the testers indeed obtained access to the information? This problem has been solved in a number of ways. There are ways to prove that the vault door was opened without taking any of the money. For instance, a screenshot of database schema and file permissions can be taken, or the files themselves can be displayed without opening them to displaying the content, as long as no PII is visible in the filenames themselves.

How cautious the testers should be on a given engagement is a parameter which needs to be discussed with the client, but the firm doing the testing should always be sure to protect themselves in a legal sense regardless of client opinion. Regardless of supposed exposure to sensitive data, all report templates and tester machines should be sufficiently scrubbed following each engagement. As a special side note, if illegal data (i.e. child pornography) is discovered by the testers, proper law enforcement officials should be notified immediately, followed by the customer. Do not take direction from the customer.

Evidence Handling

When handling evidence of a test and the differing stages of the report it is incredibly important to take extreme care with the data. Always use encryption and sanitize your test machine between tests. Never hand out USB sticks with test reports out at security conferences. And whatever you do, don't re-use a report from another customer engagement as a template! It's very unprofessional to leave references to another organization in your document.

Regular Status Meetings

Throughout the testing process it is critical to have regular meetings with the customer informing them of the overall progress of the test. These meetings should be held daily and should be as short as possible. Meetings should be kept to three concepts: plans, progress and problems.

Plans are generally discussed so that testing is not conducted during a major unscheduled change or an outage. Progress is simply an update to the customer on what has been completed so far. Problems should also be discussed in this meeting, but in the interest of brevity, conversations concerning solutions should almost always be taken offline.

Time of the Day to Test

Certain customers require all testing to be done outside of business hours. This can mean late nights for most testers. The time of day requirements should be well established with the customer before testing begins.

Dealing with Shunning

There are times where shunning is perfectly acceptable and there are times where it may not fit the spirit of the test. For example, if your test is to be a full black-box test where you are testing not only the technology, but the capabilities of the target organization’s security team, shunning would be perfectly fine. However, when you are testing a large number of systems in coordination with the target organization's security team it may not be in the best interests of the test to shun your attacks.

Permission to Test

One of the most important documents which need to be obtained for a penetration test is the Permission to Test document. This document states the scope and contains a signature which acknowledges awareness of the activities of the testers. Further, it should clearly state that testing can lead to system instability and all due care will be given by the tester to not crash systems in the process. However, because testing can lead to instability the customer shall not hold the tester liable for any system instability or crashes. It is critical that testing does not begin until this document is signed by the customer.

In addition, some service providers require advance notice and/or separate permission prior to testing their systems. For example, Amazon has an online request form that must be completed, and the request must be approved before scanning any hosts on their cloud. If this is required, it should be part of the document.

Legal Considerations

Some activities common in penetration tests may violate local laws. For this reason, it is advised to check the legality of common pentest tasks in the location where the work is to be performed. For example,any VOIP calls captured in the course of the penetration test may be considered wiretapping in some areas.

Capabilities and Technology in Place

Good penetration tests do not simply check for un-patched systems. They also test the capabilities of the target organization. To that end, below is a list of things that you can benchmark while testing.

  1. Ability to detect and respond to information gathering
  2. Ability to detect and respond to foot printing
  3. Ability to detect and respond to scanning and vuln analysis
  4. Ability to detect and respond to infiltration (attacks)
  5. Ability to detect and respond to data aggregation
  6. Ability to detect and respond to data ex-filtration

When tracking this information be sure to collect time information. For example, if a scan is detected you should be notified and note what level of scan you were preforming at the time.