Planning and Preparing for a Penetration Test Engagement

Introduction: In this module, you will complete the following exercises: 

Exercise 1 - Explain Penetration Testing and its Importance
Exercise 2 - Use Serpico to Generate a Penetration report
Exercise 3 - Explain Penetration Testing Resources and Requirements
Exercise 4 - Explain Rules of Engagement, Contract Types, and Scoping an Engagement
Exercise 5 - Explain Different Testing Strategies
Exercise 6 - Explain Target Selection and Threat Actors
Exercise 7 - Explain Asset Categorization and Risk Assessment
Exercise 8 - Explain Compliance-based Assessments
Exercise 9 - Prepare for Penetration Test Engagement

After completing this lab, you will be able to:

Exercise 1 - Explain Penetration Testing and its Importance

Penetration testing (Pen test) is a simulated cyber-attack to exploit the vulnerabilities in a network and its systems. A person conducting the pentest can attempt to breach applications, protocols, Application Programming Interfaces (APIs), servers, firewalls, and anything that can be exploited on a network.

The core intent is to discover the vulnerabilities before an attacker from the outside world can and then exploit them to simulate the amount of damage that can be caused.

In this exercise, you will learn about Penetration Testing and its importance.

What is Penetration Testing?

Penetration testing is performed to discover the hidden vulnerabilities and then exploit them. Often the term vulnerability assessment and penetration testing are used interchangeably. However, both are not the same. Vulnerability assessment is part of penetration testing. As stated earlier, penetration testing first discovers the hidden vulnerabilities, which is vulnerability assessment.

As part of the vulnerability assessment, a pentester would find the hidden vulnerabilities and document them accordingly. The vulnerabilities are then fixed to ensure that they cannot be exploited.

Once the vulnerabilities are found, penetration testing goes one step further and exploits these vulnerabilities. The intent is to simulate an attack as an actual attacker would perform.

The PenTest Process There are several standards or frameworks that are available for penetration testing. Most common ones are:

CHECK framework Open Web Application Security Project (OWASP) Open Source Security Testing Methodology Manual (OSSTMM) Penetration Testing Execution Standard (PTES) NIST SP 800-115 Most of these frameworks and standards are similar in structure, which is shown below:

Exercise 2 - Use Serpico to Generate a Penetration report

Serpico

Ruby
cd c:\Serpico   # enter
ruby serpico.rb
https :// 192 . 168 . 0 . 4 : 8443/
  User: administrator
  Pass: Passw0rd
  Consultant Company: PLABPentest
  Consultant Name: Jack Hack
  Email: jack@hack.com
  Phone: 555-1234
  Title: Mr

Exercise 3 - Explain Penetration Testing Resources and Requirements

Different Types of Resource Documents Some of the key resource documents that a pentester will require are as follows:

Web Services Description Language (WSDL) and Web Application Description Language (WADL) The WSDL or WADL documents are XML documents that describe the SOAP-based or RESTful Web services. These documents are used to provide Web services over the Internet. For example, a client system can read the WSDL document to know the functions that are available on the server. WADL is considered to be lightweight and easy to define than WSDL. WADL provides an XML description of HTTP-based web services.

SOAP Project File The SOAP project file provides information that can be useful in testing SOAP-based Web services. The developers can create the SOAP project file from the WSDL file.

Software Development Kit (SDK) Documentation There are open-source and commercial SDKs available in the market. However, an organization can also create a custom SDK to develop an application. The pentester should have access to the SDK documentation to perform a test on the applications.

Swagger Document The Swagger document provides information about the REST API and how it works. This information can be useful to the pentester as to how the API can be tested.

XML Schema Definition (XSD) file The XSD document defines the XML elements and their attributes that appear in an XML document. This document also defines the relationship between the elements and the data that will be stored within them.

Budget Requirements Budgeting makes a great deal of impact on the scope of penetration testing. Both the parties involved, the service provider and the recipient, must come to an agreement to define the scope of the services in a defined budget. The service recipient will want to minimize the cost but increase the scope of the penetration testing. On the other side, the service provider will want to maximize the revenue and decrease the effort. In some cases, the scope of penetration testing may be reduced if an appropriate budget is not available.

The budget could also be defined in a number of hours for the internal teams, which would need the allocation of time to conduct penetration testing. However, when an external team estimates the price, it would be dependent on the team size, the number of hours, scope of work, and so on. Depending on the budget available with the recipient party, the number of hours and team size could be increased or decreased. The scope of work needs to be mutually agreed between both parties.

Technical Constraints Penetration testing may be prone to technical constraints, which could be one or many. The technical constraints must be mentioned in the penetration testing plan so that the pentester is aware of them. Each organization would have different types of technical constraints. The pentester must carefully examine each one of them and come in agreement with the client.

The technical constraints can also be driven by the budget. For example, the commercial software that you require for penetration testing is too expensive for a single penetration test. Another example could be performing a test on a live Web server, which could impact the server performance.

Another example of technical constraints can include an old server that may not be able to handle penetration testing.

Exercise 4 - Explain Rules of Engagement, Contract Types, and Scoping an Engagement

Before a penetration test can be conducted by a penetration tester, you need to know about several types of contractual agreements that are available.

In this task, you will download the following sample agreements from the lab:

Penetration testing agreement - This is an agreement between the penetration tester and the company that requested the penetration test. The agreement will contain information with regards to when the penetration test will be conducted and the scope of the penetration test. The scope will entail on which components of the network the penetration test will be conducted, for example, the web servers. Statement of work (SOW) - SOW is specific to an assignment that you may take up as a pentester. SOW is created based on a set of tasks that are part of the Master service agreement. Non-disclosure agreement (NDA) - A non-disclosure agreement is signed between both parties, where each of the parties is defined clearly. It mandates that the confidential information must not be shared with a third-party.The Rules of Engagement The Rules of Engagement document defines how penetration testing will be conducted. Before writing the Rules of Engagement document, the pentester first needs to determine the type of penetration testing that needs to be performed. Some of the key components of the Rules of Engagement document are:

Timeline The timeline section should define the duration of penetration testing. It should also include the time when penetration testing will be conducted. For example, an organization would not want a web server to be impacted during peak hours. In such a scenario, the penetration testing should be scheduled at the time when there is no load on the webserver.

Targets The targets need to be clearly defined. This section must include the following:

Locations Systems Applications Third-party service providers (if any), such as Internet service providers (ISPs), Software as a Service (SaaS) providers Any type of inclusions and exclusions must also be defined in this section.

Data Handling Data handling requirements must be included as a section, which should clearly state how the confidential data must be handled during the penetration testing. It should also mention what needs to be done with the penetration testing data and its results after the engagement is contractually over.

Resources The resources section must mention the resources that are going to participate in penetration testing. Depending on the type of penetration testing performed, this section should include a list of resources. For example, if it is a black box penetration testing, then there is no time required from internal teams other than sharing the initial information, such as IP addresses. However, in the case of white box penetration testing, more time is required from various internal stakeholders.

Target Behaviors This section must include the behavior output from the targets during penetration testing. For example, what should the pentester be expecting the firewall to do when you perform an attack on it.

Communication Methods This section defines the method of communication and its timeline. Depending upon the length of the engagement, the communication timeline can be defined. For example, if it is a one-month long test, then weekly communication can work. However, if the test is going to last only one week, the pentester can simply provide the results after he or she is done with the test.

Single Point of Contact (SPOC) This section includes the person who initially engaged the pentester in this activity and is also the contact point for any issue that may arise during the penetration testing. From the penetration testing, one of the pentester is also designated as a SPOC who connects with the client SPOC in case any issue arises.

Escalation Channel An escalation channel must be defined in the Rules of Engagement document. An escalation could be related to finding something, such as a critical vulnerability, that needs immediate attention. The pentester should know whom to approach. Ideally, a decision-maker should be on the escalation channel.

Legal Concerns Any legal concern related to penetration testing must be clearly defined. It is important because a legal concern can impact not only the organization but also the pentester who is performing the testing.

Disclaimers The penetration testing plan must include the point-in-time assessment clause, which states that penetration testing and its results have a limited lifecycle. Penetration testing is performed on a specific network, servers, and application configuration. If there is a change in the smallest configuration, it could nullify the results of the penetration testing.

The disclaimers can also include the comprehensiveness clause, which should include the time frame for the validity of the results. Another disclaimer can also state every vulnerability in the network, servers, or applications that may be found.

Basic Guidelines for Planning Penetration Testing Before proceeding with the penetration testing, you should consider the following guidelines:

Understand your audience - each audience may have a different set of expectations, and therefore, it is critical to understand them. Identify the resources for penetration testing - you need to have them ready before proceeding with the testing. Identify the technical constraints beforehand, such as restricted access to the systems or conducting a test against a critical production server. Define and understand the Rules of Engagement. Identify the Disclaimers. SOW, MSA and NDA Other than the penetration testing skills, the pentester must know about the legal context. There are several documents that you need to know before you sign up for a penetration testing task. You must know the differences between each of these documents so that you know what you are signing. These documents are the Statement of Work (SOW), Master Service Agreement (MSA), and Non-disclosure Agreement (NDA). Each organization that uses these documents can have their own formats of these documents.

Master Service Agreement (MSA) An MSA is used typically when two parties intend to work for a long time or over multiple projects. In such a scenario, an MSA is created that broadly lists the work to be done over a period of time. The total cost of the work is defined. It is created before a Statement of Work (SOW) is created.

Statement of Work (SOW) An SOW is specific to an assignment that you may take up as a pentester. An SOW is created based on a set of tasks that are part of the MSA. The SOW details the following information:

Purpose of the work being assigned to the pentester The scope of the assignment Tasks to be performed as part of the scope Milestones for various phases of the assignment The expected deliverables at the end of the assignment The timeline or schedule for the assignment Total amount to be paid to the pentester Note: An organization may include more information or even delete some of these mentioned points. Non-disclosure Agreement (NDA) A non-disclosure agreement is signed between both parties, where each of the parties is defined clearly. It mandates that the confidential information must not be shared with a third-party. An NDA focuses on the following aspects:

Definition of Confidential Information Purpose of the NDA No Disclosure clause mentioning that the recipient should protect the information as they protect their own Duration of the agreement Severability Exclusions from the confidential information The intent of an NDA is simple - the owner of the information needs a written surety from the recipient that the information will not be shared with an unauthorized party.

Scope Creep The SOW contains the scope of penetration testing. In the scope, there are a specific set of services that are being offered, and testing is limited to a set of servers, network, or applications. There are chances that during the testing, the client may request to test an additional server, service, or application. It can also happen that you locate a service that needs to be tested but is not part of the original scope. This is known as scope creep. When a scope creep occurs, the pentester can either proceed with the original choice or provide a new estimate to the receiving party.

Scheduling a Penetration Test A clear timeline for penetration testing must be defined. It should also include, for one or many targets, when the testing needs to take place. For example, on a live public-facing web server, it would be a bad idea to perform a test during the day when the load is high on the webserver. If you attempt a vulnerability scan or run an attack, such as Distributed Denial of Service (DDoS) on the webserver, it will not be able to provide services to legitimate users. Therefore, scheduling penetration testing is a critical task, and time of the test must be thought through.

Legal Restrictions - Local and National Government There are certain legal restrictions that can impact penetration testing. These are:

Export Restrictions: Certain export restrictions may restrict the pentester to obtain a particular software or service. For example, the United States does not permit the export of certain software or services to certain countries. Similar to the United States, other countries may also impose the same restrictions. Local and National Governmental Restrictions: The local or national governmental restrictions may prevent the pentester from performing penetration testing. Certain activities like Denial of Service (DoS) might be prohibited to be performed as part of a penetration test in a production environment. Corporate Policies: Mainly medium and large organizations have corporate security policies that can include a penetration testing policy. If this exists within the organization, it must be shared with the pentester to understand that what should or should not be done. There can be components in the corporate policy that can impact the penetration testing engagement. For example, an organization, due to a compliance assessment, has vulnerability assessment and penetration testing documents. If these are shared with the pentester, then the entire engagement is likely to change because the pentester does not have to define his or her penetration testing documents. The existing documents can be re-used and align the penetration testing to the compliance assessment. Scopes in an Engagement Scoping defines the boundaries of engagement. Both parties agree on the scope and the tasks that are within the scope. Anything that is outside the scope is considered to be out of the scope. Later, the scope becomes the basis for creating a Statement of Work (SoW).

While scoping the depth of the penetration test, you must consider the following:

Type of test to be performed Targets - internal or external Targets - onsite or offsite Hosted internally or externally to a third-party provider Hosted as infrastructure or cloud, such as SaaS Applications and services that are running Databases This is not an exhaustive list, but some of the key pointers must be considered while defining the scope. The larger the scope, the more the time and resources it will require to complete the penetration test. It is quite obvious that with the larger scope, the cost of the test also goes up. Therefore, the organization, if working with a fixed budget, may decide to limit the scope by focusing only on a few targets.

Discuss End Goals and Deliverables Before the scoping can be defined, the organization must identify the reason for the penetration testing to take place. For example, is the penetration testing required to meet a compliance standard, or is it simply to identify vulnerabilities and exploit in network security. There could be various reasons due to which penetration testing is required. However, the organization must have the reason clearly defined.

The end goal is to find the vulnerabilities, exploit them, and then close them as required. Penetration testing report is the final deliverable. It should highlight the following:

Type of test performed Vulnerabilities that are identified Vulnerabilities that are exploited Mitigation suggested It needs to include the Executive Summary section that should explain the risk and business impact of the security concerns as discovered in penetration testing. This section should be non-technical and in simple English.

Needless to state that the report should be actionable and should have included items that need to be closed after the penetration test.

Exercise 5 - Explain Different Testing Strategies

Difference between Black box vs. White box vs. Gray box After the scope of penetration testing is defined, it needs to be decided on the type of penetration testing to be performed. There are essentially three types of penetration testing:

Black box White box Gray box Black Box A black box test is also known as Zero Knowledge penetration testing. In the black box, the pentester does not have any information about the network except for an IP range. The pentester is typically an external entity who needs to exploit the network or systems to the fullest. The pentester is expected to gather information on his own, discover vulnerabilities, and then exploit them. A black box penetration testing takes more time as the pentester does not know anything about the network. However, it is more realistic because the pentester can provide an accurate assessment of the security of the network.

White Box The white box penetration testing is the complete opposite of a black box. It is also known as Full Knowledge Penetration Testing. The pentester will have all the information that is required to perform penetration testing. For example, the pentester will have the following information:

Network diagrams List of systems with their IP address IP ranges User credentials to log on to the systems The white box penetration testing takes less time than the black box testing because the pentester has the required information, to begin with. However, it may not provide accurate results as it does not visualize the attacks as an external attacker would.

Gray Box The gray box testing is a combination of the black box and white box. The pentester has limited information, to begin with, but generally does not have user credentials or the configuration details. For example, you may share the application name and its IP address with the pentester but not provide the application version or the services that it is running.

Exercise 6 - Explain Target Selection and Threat Actors

Types of Targets When defining the scope of penetration testing, you need to consider the types of targets that need to be involved. There are multiple types of target, which are as follows:

Internal The internal targets are located within the organization. An insider attack is common on the internal targets. An external malicious attacker can gain access to the internal target using social engineering or phishing attacks. The external attacker only needs access to the internal network, and then using methods like privilege escalation can cause damage to the internal systems.

On-site The on-site target is where the attack is being conducted. However, depending on the number of security controls implemented, the attacks can be prevented on the on-site targets. If the site is large enough, then there can be various entry points for the attacker to gain access to the targets.

Off-site The off-site target is not located within the organization premises to which it provides services. For example, the targets may be located at a branch office or a remote office that is linked with the head office using remote connectivity. If there are not enough security controls at the remote offices, then they may be the medium for a backdoor into the head office.

External The external targets are not present within the organization and are located on the Internet. The examples of external targets could be a Website or Web application.

First-party hosted First-party targets are hosted within the organization and can be an easy target. One of the common attacks could be zero-day vulnerability exploitation. A zero-day attack exploits an unknown vulnerability. Third-party targets can be difficult to penetrate, specifically if they are with a large organization, which can have multiple layers of security controls. Smaller organizations’ targets can be easy to penetrate.

Third-party hosted Third-party targets are either hosted at a vendor site or by a partner organization. Third-party targets can be difficult to penetrate, specifically if they are with a large organization, which can have multiple layers of security controls. Smaller organizations’ targets can be easy to penetrate.

Physical The pentester can test out physical security. One of the easiest methods can be piggybacking or shoulder surfing. Both are easy to perform. Piggybacking is a method in which the first person authorizes himself to enter a restricted area, and the second person enters the door quickly without authorization. In the shoulder surfing method, one person overlooks the shoulders of another person to read through the information on the mobile or a system.

Keyloggers are another thing that should be checked. Keyloggers capture the keystrokes and send them to a remote entity who controls the keylogger.

Users The pentester can also target the users as they are the easiest target. The pentester can use the social engineering method. Many users are likely to be the victim of a social engineering attack.

SSIDs A wireless network is accessed using an SSID, which is the name of the wireless network. An SSID may be visible or hidden. However, the pentester can use tools like Kismet to find hidden SSIDs. When an SSID of the wireless network is known, the pentester can attempt to connect to the wireless network. The pentester, in the simplest means, can capture the wireless traffic and find the SSID of the wireless network and MAC address of the access point. Various types of wireless attacks can be performed by the pentester. One such attack is cloning the access point using a tool named airbase-ng.

Applications Applications can be a primary target for penetration testing. Several Web applications have E-commerce capabilities, which must be tested and secured appropriately if vulnerabilities are found. Even if the Web application does not have E-commerce capability but runs the user context, then it is a good target to penetrate and perform remote code execution.

Types of Threat Actors Threat actors are any entity behind a threat, which is a potential danger to an asset. A threat actor can be largely categorized into three categories:

Internal Threat (e.g., a rogue employee) External Threat (e.g., a criminal gang) Natural Threat (e.g., hurricane or tsunami) Threat actors look for vulnerabilities, which are weaknesses that can be exploited. When a vulnerability is present in the network, server, or application, there is a risk that the threat actor may exploit it.

Hackers Hackers can come in different disguises. There are three types: black hat, gray hat, and white hat. Black Hat Hackers break into systems with malicious intent. They are usually either hired or contracted by organizations to evaluate their security parameters. The grey hat hackers are a combination of white hat and black hat hackers. They break into systems without seeking permission. They want to demonstrate their skills, but their intentions are not malicious, such as stealing valuable information or destroying data. Their actions are considered to be illegal because they do not seek permission to perform their actions.

Script Kiddies A script kiddie is someone who does not have the expertise of a hacker but relies on ready-made tools as they cannot write their own code. Due to a lack of expertise, their attacks are not sophisticated.

Hacktivists Hacktivists are threat actors who are hackers with a specific mission, which could be political or social. They are not after the money but have a cause that needs to be fulfilled. One of the most common attacks they use is a Distributed Denial of Service (DDoS). They are determined to fulfill their cause and can work in groups with like-minded hackers.

Nation States/State Sponsored These threat actors are well-funded and well-organized cyber espionage entities that commit their activities with the backing of governments or similar large entities. State-sponsored attackers typically focus on infiltrating larger organizations with the intent to steal massive amounts of mission-critical and other sensitive data.

Insider Threats These threat actors are internal to an organization and can carry out a malicious activity intentionally or unintentionally. Some of the activities they perform are handing out confidential or sensitive information to others unintentionally or selling the information to another threat actor who wants to misuse the information.

It is very difficult to detect an insider threat as the person is part of the system. He would have access to the data along with the knowledge of internal operations and processes. Since they are inside the network, their actions are difficult to track by tools like a firewall.

Exercise 7 - Explain Asset Categorization and Risk Assessment

Assets are critical for an organization. Depending on the type of asset, it will have certain risks associated with it.

In this exercise, you will learn about asset categorization and risk assessment.

Types of Assets Before understanding the types of assets, it is important to understand what an asset is. It is anything that has value to an organization. It could be servers, software, devices, the information in any format, services, people, or even intangibles, such as reputation or brand.

The assets typically have owners and custodians. The owner performs the asset management and is responsible for handling, disclosure, and destruction of the asset. He decides the need-to-know purpose for the asset.

The custodian, on the other hand, is responsible for protecting the data as per security requirements. The custodian provides accessibility of the asset to end-users. He is also responsible for quality assurance and data validation of the asset.

Types of assets in an organization are:

People: Includes employees, customers, and partners Hardware: Includes servers, desktops, laptops, and any devices that are being owned by the organization Software: Includes operating systems and applications that are used for business purposes Data: Includes business and employee information Physical environment: Includes the physical infrastructure, which includes the business premises Processes: Includes the processes and procedures that enable an organization to run its business Third-parties: Includes partners Asset Inventories

Asset inventories are critical when figuring out what to protect and how much to spend protecting it. Asset inventories should be checked periodically to verify accuracy. Inventories should track details necessary for the following reasons:

Asset identification Date of acquisition Security Classification Descriptive details Asset Location Information necessary for backup and restore, disaster recovery Asset owner and custodial information Different Types of Risk Responses There can be four types of risk responses, namely:

Risk reduction - Controls are used to reduce the likelihood/impact of the risk or minimize loss. Risk avoidance - Removing the threat by using alternate behavior to end the exposure. Risk transfer - Pass risk onto 3rd party such as an insurance company. Risk retention/acceptance - accepting the risk outcome as necessary to continuing the business goals and confirming monetary funds are available if required. The controls are classified as Directive, deterrent, preventive, compensating, detective, corrective, recovery. Example of which include:

Technical controls - Authentication, access control, encryption, etc. Procedural controls - Security awareness, training, etc. Physical controls - Fences, doors, fire suppression, etc. Legal, regulatory and compliance - Security policies, regulations, etc. Tolerance to Impact Penetration Testing is likely to impact network performance. When conducting penetration testing, one must ensure that the servers or network devices are able to continue with their normal business operations without being impacted. Therefore, it is critical for the organization to identify the network devices and servers that are in scope or out of scope.

For example, an internally hosted live Web server can be brought down during penetration testing. It will impact its availability to the public that is accessing the Website hosted on the Web server. Therefore, the organizations, when defining the scope of penetration testing, must clearly understand the risk tolerance levels. For example, to ensure that the users are not impacted, the organization may decide to conduct the test at night or on the weekend. It will not increase the risk tolerance level for the Web server.

Risk Appetite Risk appetite refers to the number of risks that an organization can tolerate. It is the acceptance of the risks by the organizations keeping in mind the business objectives. The tolerance of risks should be weighed with the cost of closing the risk. If the cost of closing the risk is more than the risk itself, then the organization can choose to tolerate the risk.

Exercise 8 - Explain Compliance-based Assessments

Compliance-based assessments are designed to meet the requirements of a specific law or standard. In most scenarios, the organization must be tested and certified by an authorized agency against the defined compliance-based assessment. Not every organization needs to obtain a compliance-based certification or pass the assessments. Many organizations define their own security policies that they use to ensure their infrastructure security.

In this exercise, you will learn about compliance-based assessments.

Key Aspects of Compliance-based Assessments and their Limitations There are various compliance-based assessments that are available. Compliance is assured through implementing various types of security controls, which can be administrative, technical, physical, and operational. Each type of assessment defines the criteria that must be passed for completing the assessment. Penetration testing can be used to validate security controls.

It is not necessary that every organization needs to opt for each of these assessments. Each one is designed with a specific purpose. Purpose of each assessment is as follows:

Payment Card Industry Data Security Standard (PCI-DSS) PCI-DSS assessment is applicable to organizations that deal with credit, debit, and cash card transactions. It is intended to protect the cardholders so that their personal information cannot be misused. It defines strict parameters for the organizations so that the cardholders’ information can be protected.

Health Insurance Portability and Accountability Act (HIPAA) HIPAA applies to health care providers and organizations. It is designed to ensure the confidentiality of protected health information (PHI). HIPAA is divided into several major standards that are:

Privacy Rule Security Rule Transactions and Code Sets (TCS) Rule Unique Identifiers Rule Breach Notification Rule Omnibus Final Rule HITECH Act SOX In the United States, all public companies, financial and IT, must comply with the SOX assessments. It requires all business transactions to be saved for not less than five years. Even though it does not define how the information should be stored, but it defines which information must be stored.

Gramm-Leach-Bliley Act (GLBA) GLBA is also known as the Financial Modernization Act of 1999. It is applicable to financial organizations and mandates them to define and explain how the customer’s private information is protected and shared. This act also mandates the organizations to inform customers about sharing their personal information, provide the customer with the option to opt-out if he or she does not want their personal information to be shared with a third-party, and implement security controls to ensure that the customer’s information is secured.

Federal Information Processing Standard (FIPS) 140-2 FIPS 140-2 is applicable to the hardware, software, and firmware solutions. Any of these that use cryptography must pass FIPS 140-2. This assessment is designed to ensure high security for the customers.

Limitations

Even though the compliance-based assessments are designed for a specific purpose, they do bring in certain limitations. These limitations are listed below:

The compliance standard defines the rule and the guidelines to complete the assessment. The organization must adhere to the rules and guidelines if it needs to complete the assessment. For example, as per the compliance standard, you may have to conduct penetration testing on the internal and public-facing network. Data isolation is critical and should be separated from the rest of the network. The scope needs to only test the environment, excluding the data, such as the cardholder’s data. If using cryptography, then the FIPS 140-2 must be adhered to. Storage and network must be segregated and provide limited access during penetration testing. If adhering to more than one standard, then the operations and data must be segregated carefully. For example, if an organization is seeking compliance with PCI-DSS and HIPAA, then the operations and data must be segregated so that there is no overlap. Using this strategy, the organization can have one standard for one environment and the other one for the second environment. Each standard has its own requirements, and therefore, each one may require the organization to hire external consultants to meet them, hence, increasing the cost.

Exercise 9 - Prepare for Penetration Test Engagement

After scoping the penetration testing and planning the engagement with the client, there are various activities that need to be performed. These activities are crucial to streamline the overall penetration testing project and, therefore, must be planned carefully. Some of the key activities that must be performed before the penetration test are preparing the team, activity assignment, and contingency planning.

In this exercise, you will learn about preparation for penetration testing engagement. Team Preparation Preparing the team for penetration testing is a critical task. The correct skill set must be selected for the penetration test. For example, in a live penetration testing for a large client, you would not want to get a fresher involved in penetration testing. It would be ideal to have a more experienced team member front-end the entire project. There are certain key pointers that must be followed when preparing the team for penetration testing:

The team must be clear of the scope of penetration testing. The team members must ensure that they know in-scope and out of scope activities. If there are certain limitations that the client has made you aware of, then the team members must be informed of them. Each team member must be clear with the end objective of penetration testing. Each one of them should know what they need to achieve, and every team member should have a common goal to achieve the end objective. The end objective, at the end of the penetration testing, must be achieved and translated into the actionable report. Ensure the team documents all actions and outcomes. The documents must be available in a central repository and must be accessible to the team members. The escalation path must be clear and known to the team members. The team must have authorization for the penetration test. The immediate supervisor’s contact information must be available with each one of the team members. A team member should be able to reach out to the other team members in case of any trouble. The team must be capable of restoring the original environment in case anything goes wrong during penetration testing. The team lead or supervisor must be made aware of anything that goes wrong. Similar to preparing the team for penetration testing, the client must also be prepared for this task. There are certain guidelines that you should adhere to when preparing the client for this task:

You must have the technical contact point of information from the client side. This information must be available throughout the lifecycle of penetration testing. You must ensure that the client has appraised the internal IT and Security teams about penetration testing. You must inform the client to take the necessary backups of the critical systems. In case any system fails during the penetration testing, the client must have the required backups to restore the system at the earliest. You need to ensure that the client does not make security control changes just before the penetration testing. If this happens, then you will not be able to provide a true picture of their environment. The idea is to test the current IT environment in the as-is state. Data Collection and Documentation Data collection and documentation is a critical task in penetration testing. There are some guidelines that one must follow:

Every activity and its outcome must be documented. The documentation must be stored in a central repository with access to all team members. The penetration tests must be aligned to the defined objectives, and each test must meet the client requirements. Each piece of documentation must be written in a clear and concise manner. Each and every step to perform a task must be captured properly. This is critical because if the results or outcomes need to be reproduced, you should be able to do it with the steps. Only focus on documenting the in-scope activities. Anything that is out of scope must be escalated to the authorized person in the penetration testing team. However, you must not capture any steps or outcome of the out of scope activity. You should focus on capturing every detail in a test. More information captured in a test is likely to give insights. You should ensure that the original test data and documents are preserved securely.