Pre-engagement

This phase defines all the pre-engagement activities and scope definitions.
The following image depicts the current main nodes on the mindmap:

Scoping

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.

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.

Scoping is specifically tied to what you are going to test. This is very different from covering how you are going to test. We will be covering How To Test in the rules of engagement section.

How to Scope

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.

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.

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

Remember, in many cases the scoping meeting will happen after the contract has been signed. There 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 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.

A good resource for effective meetings can be found here:

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 test. However, 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

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 hock basis, legal ramifications. Many ad hock 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.

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.

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

"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?
4. During business hours?
5. After business hours?
6. On the weekends?
7. How many total IP addresses are being tested?
8. How many internal IP addresses, if applicable?
9. How many external IP addresses, if applicable?
10. 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?
11. In the case that a system is penetrated, should we:

Perform a local vulnerability assessment 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

1. How many web applications are being assessed?
2. How many login systems are being assessed?
3. How many static pages are being assessed? (approximately)
4. How many dymanic pages are being assessed? (approximately)
5. Will the source code be readily for viewing?
6. Will we be performing static analysis on this application?
7. Does the client want us to perform fuzzing against this application?

Wireless Network Penetration Test

1. How many wireless networks are in place?
2. Is a guest wireless network used? If so:
3. Does the guest network require authentication?
4. What type of encryption is used on the wireless networks?
5. What is the square footage of coverage?
6. Will we be enumerating rogue devices?
7. Will we be assessing wireless attacks against clients?
8. 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:
3. How many floors are in scope?
4. Which floors are in scope?
5. Are there any security guards that will need to be bypass? If so:
6. Are the security guards employed through a 3rd party?
7. How many entrances are there into the building?

I#s the use of lock picks or bump keys allowed? (this will be dependant upon state law)

1. Will we be performing a physical penetration test to verify compliance with existing policies and procedures or just performing an audit?
2. What is the square footage of the area in scope?
3. Are all physical security measures documented?
4. Are video cameras being used? If so and they are client owned:
5. Does the client want us to attempt to gain access to where the video camera data is stored?
6. Is there an armed alarm system being used? If so:
7. Is the alarm a silent alarm?
8. Is the alarm triggered by motion?
9. Is the alarm triggered by opening of doors and windows?

Social Engineering

1. Will the client provide e-mail addresses of personnel that we can attempt to social engineer?
2. Will the client provide phone numbers of personnel that we can attempt to social engineer?
3. Will we be attempting to social engineer physical access, if so:
4. 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, feel free to use the following questions as a guide.

Questions for Business Unit Managers

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.

1. Do you know a test is about to be preformed?
2. What is the main datum that would create the greatest risk to the organization if exposed?
3. Do you have testing and validation procedures to verify your business applications are functioning properly?
4. Do you have your Quality Assurance testing procedures from when the application was first developed?
5. 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.

1. Can you identify your fragile systems?
2. Do you have Change Management procedures in place?
3. What is the mean time to repair systems outages
4. Do you have any systems monitoring software in place?
5. What are your most critical servers and applications?
6. Do you test backups on a regular basis?
7. When was the last time your restored from backup?

Scope Creep

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 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, acutely 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.

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:

justin@orion:~$ whois pauldotcom.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: PAULDOTCOM.COM
   Registrar: REGISTER.COM, INC.
   Whois Server: whois.register.com
   Referral URL: http://www.register.com
   Name Server: NS1.PAULDOTCOM.COM
   Name Server: NS3.PAULDOTCOM.COM
   Status: clientTransferProhibited
   Updated Date: 17-mar-2009
   Creation Date: 05-mar-2000
   Expiration Date: 05-mar-2016

…

   Registrant:
      Domain Discreet
      ATTN: pauldotcom.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
   Registrar Whois...: whois.register.com
   Registrar Homepage: www.register.com

   Domain Name: pauldotcom.com
      Created on..............: 2000-03-05
      Expires on..............: 2016-03-05

   Administrative Contact:
      Domain Discreet
      ATTN: pauldotcom.com
      Rua Dr. Brito Camara, n 20, 1
      Funchal, Madeira 9000-039
      PT
      Phone: 1-902-7495331
      Email: 940fe48a0a16123337ca6a1281067070@domaindiscreet.com


   Technical  Contact:
      Domain Discreet
      ATTN: pauldotcom.com
      Rua Dr. Brito Camara, n 20, 1
      Funchal, Madeira 9000-039
      PT
      Phone: 1-902-7495331
      Email: 940fe48d0a16123339c7eef67f34a73d@domaindiscreet.com


   DNS Servers:
      ns1.pauldotcom.com
      ns3.pauldotcom.com

Dealing with Third Parties

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.

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 that can impact the other cloud customers.

This may seem like an onerous amount of approval for testing, however the risks are to great to the tester otherwise.

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.

Define Acceptable Social Engineering Pretexts

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 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.

Goals

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.

Primary

The primary goal of a test should not be driven by compliance. There are a number of different reasons 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.

Secondary

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.

Think of it like this: secondary goals mean something for compliance and IT. Primary goals get the attention of the C-O’s.

Business Analysis

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 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. 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

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.

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: 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.

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:

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.

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:

1. PGP/GPG can be used to both communicate over e-mail and to encrypt the final report
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

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 ridged 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.

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.

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. We generally see our meetings cover three very simple things: plans, progress and problems.

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.

For progress you should inform what you have completed since the previous meeting.

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.

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.

Time of the Day to Test

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.

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

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.

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.

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.