scope agreements The rules of engagement define the scope, limitations, and conditions under which a penetration test is conducted.
Rules of Engagement (RoE) for penetration testing are comprehensive, pre-approved documents defining the scope, constraints, and operational guidelines for security assessments. They include target systems (IPs/URLs), authorized testing times, methodologies, emergency contacts, and, importantly, a “kill switch” for stopping tests if systems are compromised. This document ensures legal compliance and sets communication protocols for handling critical findings
Testing Window: This specifies the time frame during which the penetration testing activities are authorized to occur. It is a crucial part of the rules of engagement to ensure the testing does not disrupt business operations and is conducted within agreed-upon hours.
What is Included in RoE for Pentesting (Key Components) Scope and Limitations: Explicit definition of in-scope assets (IPs, domains, applications) and specifically restricted/out-of-scope systems. Timing and Scheduling: Specific dates, times, and windows during which testing is allowed, often to avoid peak business hours. Authorization and Legal Permissions: Written, signed approval from the client that authorizes the testers to perform actions, minimizing legal risk. Communication Plan: Contact information for both technical and management staff, including emergency contacts for immediate, real-time communication during testing. Methodologies and Tools: Description of the techniques (e.g., social engineering, web app scanning) and specific tools to be used or avoided. Handling of Findings: Protocols for reporting critical, high-impact vulnerabilities immediately, along with procedures for handling sensitive data. “Kill Switch” Policy: Procedures for halting tests immediately if something goes wrong, such as a production system going down.
The rules of engagement define the guidelines and boundaries of a PenTest to ensure the testing activities are conducted safely, effectively, and in alignment with the organization’s objectives. This includes specifying what is out of scope (exclusions), detailing the specific test cases and techniques to be employed, establishing the process for escalating and reporting critical findings, and setting the testing window to minimize disruption to business operations. Clear rules of engagement help manage risks, ensure compliance, and facilitate effective communication between the PenTesting team and the organization.
All parties should be encouraged to keep the lines of communication open and clarify any unresolved issues. For example, the stakeholders may ask questions such as the following:
- Will the PenTesting team agree to work with an in-house staff member designated as a monitor?
- Can we suspend testing activities at any time?
- Is the PenTesting team willing to communicate with the Internet Service Provider (ISP) about the large number of external scans they might do during testing?
When sitting down with the stakeholders, the team should ask open-ended questions that will remove any ambiguity as to the mode and methods used to test the systems. No detail is too small. Some information may be considered more critical. For example, the stakeholders might share that they have had a breach in the past or that they feel there may be an advanced persistent threat (APT)within the network.
Establishing an escalation process can help define how issues discovered during the test are communicated and managed, especially if critical vulnerabilities or disruptions are identified. Escalation process topics may include the following:
-
Communication protocol: Explains the hierarchy of contacts and backup contacts in case the primary contact is unavailable. Determines the method of communication for reporting findings, such as secure email or phone call.
-
Immediate reporting: Criteria for what constitutes a critical finding that would require immediate reporting, such as evidence of an existing breach or vulnerabilities that could cause a severe business impact.
-
Remediation coordination: Procedures for coordinating with the client’s IT and security teams for remediation of critical issues.
Adhering to a Timeline
A timeline represents a series of events that transpire within a set testing window. The testing window specifies the time frame during which the penetration testing activities will take place. When determining the testing window for a PenTest, it is important to verify the specific dates and times that testing will be allowed and get confirmation from all relevant stakeholders. Procedures for adjusting the testing window if needed should also be discussed.
So that the organization understands the procedure for PenTesting, it’s best to sit down with the stakeholders and outline how the team will proceed with the test.
When scheduling, the team will explain to the stakeholders how testing during normal business hours will help assess the organization’s reaction to attacks. However, there may also be time-of-day restrictions when no testing is allowed, as it may impact potential services and cause an outage.
After the timeline restrictions are discussed, they may be defined in the contract as follows:
Testing for 515web.net will be conducted from 8:00 a.m. to 6:00 p.m. U.S. Eastern Time, Monday through Friday unless otherwise stated within the individual test plan.
The team should discuss the general methodology and realistic estimation of time needed for each of the tasks that need to be conducted. In addition, the timeline should indicate the individuals or teams responsible for performing those tasks. The team should also establish procedures for adjusting the testing window if necessary. Once complete, the team will share the timeline with the stakeholders for their confirmation.
Professional PenTesters are expected to know how to conduct tests in a quick and efficient way. Using good time management skills will increase the team’s productivity and efficiency.
One of the team’s goals should be to build a long-lasting relationship with the client. To do so, the team should always act in a professional manner. Some suggestions include the following:
- Focus on the task at hand.
- Avoid distractions.
- Adhere to the timeline.
- Keep status meetings short and to the point.
Each team member should know when to ask for help and should not spend hours on a single task that should only take 45 minutes.
Understanding the Restrictions
Once the main objectives are outlined, the team will want to review other variables that relate to testing so that they can understand the restrictions that can impact the process. These may include the following:
- Determine allowable tests: To further define the scope, the team will need to determine exactly what is being tested and what is not. Identify acceptable actions during tests such as social engineering and physical PenTesting.
- Adhere to the scope: The legal documents will define what locations, systems, applications, or other potential targets are to be included or excluded. If asked if they could test another subnetwork, the team member should explain that if the test is not included in the scope, they cannot legally do the test.
- Recognize other restriction: There may be other restrictions such as possible technical or location constraints. For example, there may be a legacy system that has had several issues with automated scanning.
- Limit invasiveness based on scope: What is being tested, and what is not? Define the acceptable actions, such as social engineering and physical security tasks. In addition, if planning an invasive attack such as a denial-of-service (DoS) attack as part of the testing, have the stakeholder define any restrictions that might impact fragile systems.
- Limit the use of tools to a particular engagement: The use of tools may be defined by a governing body that outlines specifically what the team is to use when conducting the test. In that case, the team will be presented with a list of tools that can be used for a particular engagement.
The team should address any other variables that will impact testing. For example, if there is an installation in a different country that needs to be included in the test, is there technology available to access the remote location? If an on-site visit is required, the parties should agree to the travel needed to conduct the PenTest at the remote location.
Sample documentation that defines acceptable tools is as follows:
The following list includes all 515support.com approved vulnerability assessment, penetration testing and network monitoring tools that are commercial, noncommercial, or custom built. If additional tools are needed for a specific test, the team must submit a rationale for using the tool, along with a request for approval. Approval must be granted prior to using the tool on the production network.
Usually, everyone will have considered all possible variables. However, in some cases, once testing begins, the stakeholders may identify a prohibited system, specific time of day, or IP address range that is to be excluded from testing. If that happens, the stakeholders will need to notify the team and request a change to the terms of the contract.
At some point, the team will need to plan a strategy for conducting the PenTest. The strategy will include the rationale for the test and whether they will operate in a known or unknown environment during testing. It also may be beneficial to include test cases, which will help provide a structured approach to the PenTest by breaking down the overall test into specific, manageable scenarios. Each test case outlines the methodology, tools, and expected outcomes for a specific test to ensure that the PenTesting process is systematic, thorough, and aligned with the agreed-upon scope defined in the rules of engagement and that every aspect of the target system’s security is assessed methodically.