Rules of Engagement - Paiet/SEC-335 GitHub Wiki

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.