to 5 p.m.)
After work hours (for example, 6 p.m. to 6 a.m.)
On weekends (for example, 8 a.m. to 12 a.m.)
When preparing the budget, be sure to have a schedule set up for how long it will take to perform the penetration test. Table 2-1 illustrates a sample schedule, but know that the schedule will vary depending on the size of the organization being assessed and the number of resources you have available to perform the penetration test.
TABLE 2-1 A Sample Pentest Schedule
| Activity | Activity Name | Duration(Days) |
|---|---|---|
| 1 | Initial preparation | 3 |
| 2 | Planning and scoping | 3 |
| 3 | Kick-off meeting | 1 |
| 4 | Initial assessment of environment | 3 |
| 5 | Information gathering | 5 |
| 6 | Vulnerability assessment | 5 |
| 7 | Exploitation of systems | 5 |
| 8 | Physical security assessment | 3 |
| 9 | Wireless security assessment | 3 |
| 10 | Post-exploitation | 3 |
| 11 | Clean-up | 3 |
| 12 | Report preparation | 5 |
| 13 | Report delivery and project closing | 1 |
Scope creep
An important discussion to have during the planning and scoping phase of the penetration test is how to handle scope creep. Scope creep occurs when the size of the project — in this case the penetration test — continues to change or grow as the project continues. As the consulting pentester, scope creep is a nightmare, as you have given a quote to the customer on the cost to perform the penetration test based on how long you estimate the pentest will take. The length of time is dependent on the number of targets defined for the project, and if that changes while the penetration test is occurring, the cost will go up! Increased costs typically do not sit well with the customer, so be very clear at the start that the cost is for the targets that have been defined within the scope of the project and that any newly discovered targets that arise while the penetration test is occurring will be an additional cost. Make sure the pentest team knows who to contact when a new target has been discovered during the pentest that was not specified in the scope of the project so that you can determine how to continue.
Conducting Compliance-based Assessments
If the organization for which you are performing a penetration test is conducting a pentest to be in compliance with industry regulations, you may need to meet strict requirements when performing the assessment. It is important as a penetration tester to become familiar with the requirements of a compliance-based assessment. Know that the requirements are different in every industry, as they depend on the laws or regulations that govern each industry. Following are examples of industry-specific laws or regulations an organization must follow based on the industry the organization operates in:
Health Insurance Portability and Accountability Act (HIPAA), which controls the handling of health records.
Family Educational Rights and Privacy Act (FERPA), which allows parents access to educational records of their child.
Payment Card Industry Data Security Standard (PCI DSS), which secures debit and credit card information.
General Data Protection Regulation (GDPR), which is a regulation that covers the collection and protection of personal data in the European Union (EU). GDPR is also a regulation that includes laws surrounding the transfer of personal data to areas outside of Europe.
Considerations with compliance-based assessments
Following are some limitations and caveats to keep in mind with regard to compliance-based assessments:
Rules to complete the assessment: Each regulation or standard has strict rules on how the penetration test is to be performed and what to look for in the assessment. For example, the PCI DSS includes strict requirements on the use of firewalls to restrict communication with data-holder equipment, and encryption requirements for transferring credit card data across public networks.
Password policies: To be compliant, an organization may have to follow strict requirements on passwords and password policies. For example, you may need to assess the company’s password policy and ensure that the company employees use strong passwords, change passwords frequently, and cannot use a password they used previously.
Data isolation: Due to laws or regulations you may need to ensure that certain types of data are separated from other types of data. For example, with PCI DSS, a company must ensure that credit and debit card data is isolated from the rest of the company data. As another example, in a bring-your-own-device (BYOD) environment, you may need to ensure that mobile devices partition personal data from business data so that business data can be remotely wiped if needed.
Key management: You may need to assess the use and storage of encryption keys as well as assess the company’s backup policies or the archival of encryption keys to allow recovery of sensitive data.
Limitations: You may need to assess for limitations placed on resources such as systems, devices, and data. For example, there may be strict limitations on certain types of systems not being accessible from the Internet.
Limited network access: You may need to ensure that the network is