Press Release
The penetration testing methodology is as important as the tester’s abilities to achieving a successful result. Before you engage a third party service, be sure to gather all the details about their penetration testing methodology.
Following is an outline of the penetration testing methodology that we use at Pivot Point Security. Feel free to use this as a baseline to help you understand what to look for.
To define the scope of penetration test activities, we need to understand your specific goals and needs, as well as any special considerations. We generally get this information by interviewing your team over the phone.
The first step to a successful penetration test is to understand specifically why you want one. The most common reasons for a penetration test are:
- You need to understand your true security posture
- You need to prove to management that there is a problem so you can gain funding to remedy it
- You need to demonstrate compliance with a regulation or standard
- You need to prove to a customer or other third party you network is secure
- Depending on your objective(s), related information to identify during this preliminary phase can include:
- Legal requirements for the entity and jurisdiction
- Attestation and reporting requirements
Once we understand your testing objectives, we’ll discuss any special considerations for the test. For example, are there testing windows (timeframes) we must adhere to, or systems that should not be touched?
- Key considerations to identify often include:
- IP scope (the range of IP addresses to test)
- Active Defense identification and avoidance
- Test window
End of Test/Win conditions (the conditions that, when met, conclude testing)
Out of Scope hosts and applications. For example, scanning older versions of Cisco Call Manager result in all phones rebooting. If this happens after hours, it may be acceptable. If this happens at any time in a 911 call center, it’s potentially life-threatening and must therefore be avoided.
By default, we approach penetration testing from a “Do No Harm” perspective. In our tests, at no point will a Pivot Point Security penetration tester purposefully cause a disruption to business operations (with very limited exceptions). However, several valid methods of attack may unintentionally (or, in rare cases, by design) cause a temporary service interruption. For example, the tester may stop a service on a target host in order to capture the credentials of the administrator who logs in to address the stopped service. However, if there is any chance one could be used we will discuss these attack methods with you and get your documented approval beforehand.
Similarly, there are various testing approaches that are out of scope by default, unless you request them for specific business reasons. These include:
- Denial of Service attacks.
- Brute Force attacks.
- Man-in-the-Middle attacks from an external perspective.
The first step to a successful penetration test is to understand specifically why you want one. The most common reasons for a penetration test are:
- You need to understand your true security posture
- You need to prove to management that there is a problem so you can gain funding to remedy it
- You need to demonstrate compliance with a regulation or standard
- You need to prove to a customer or other third party you network is secure
- Depending on your objective(s), related information to identify during this preliminary phase can include:
- Legal requirements for the entity and jurisdiction
- Attestation and reporting requirements
Once we understand your testing objectives, we’ll discuss any special considerations for the test. For example, are there testing windows (timeframes) we must adhere to, or systems that should not be touched?
- Key considerations to identify often include:
- IP scope (the range of IP addresses to test)
- Active Defense identification and avoidance
- Test window
End of Test/Win conditions (the conditions that, when met, conclude testing)
Out of Scope hosts and applications. For example, scanning older versions of Cisco Call Manager result in all phones rebooting. If this happens after hours, it may be acceptable. If this happens at any time in a 911 call center, it’s potentially life-threatening and must therefore be avoided.
By default, we approach penetration testing from a “Do No Harm” perspective. In our tests, at no point will a Pivot Point Security penetration tester purposefully cause a disruption to business operations (with very limited exceptions). However, several valid methods of attack may unintentionally (or, in rare cases, by design) cause a temporary service interruption. For example, the tester may stop a service on a target host in order to capture the credentials of the administrator who logs in to address the stopped service. However, if there is any chance one could be used we will discuss these attack methods with you and get your documented approval beforehand.
Similarly, there are various testing approaches that are out of scope by default, unless you request them for specific business reasons. These include:
- Denial of Service attacks.
- Brute Force attacks.
- Man-in-the-Middle attacks from an external perspective.
Once we understand your testing objectives, we’ll discuss any special considerations for the test. For example, are there testing windows (timeframes) we must adhere to, or systems that should not be touched?
- Key considerations to identify often include:
- IP scope (the range of IP addresses to test)
- Active Defense identification and avoidance
- Test window
End of Test/Win conditions (the conditions that, when met, conclude testing)
Out of Scope hosts and applications. For example, scanning older versions of Cisco Call Manager result in all phones rebooting. If this happens after hours, it may be acceptable. If this happens at any time in a 911 call center, it’s potentially life-threatening and must therefore be avoided.
By default, we approach penetration testing from a “Do No Harm” perspective. In our tests, at no point will a Pivot Point Security penetration tester purposefully cause a disruption to business operations (with very limited exceptions). However, several valid methods of attack may unintentionally (or, in rare cases, by design) cause a temporary service interruption. For example, the tester may stop a service on a target host in order to capture the credentials of the administrator who logs in to address the stopped service. However, if there is any chance one could be used we will discuss these attack methods with you and get your documented approval beforehand.
Similarly, there are various testing approaches that are out of scope by default, unless you request them for specific business reasons. These include:
- Denial of Service attacks.
- Brute Force attacks.
- Man-in-the-Middle attacks from an external perspective.
As penetration testing is as much art as science, each tester will have his or her own approach. Our testers certainly adhere to a validated, third party attested methodology (CREST), but testers need some flexibility to leverage their own expertise and experience to return the best results.
- Our penetration tests follow this general plan:
- Ensure we have a clean testing platform (revert snapshot/wipe and rebuild, etc.).
- Notify you that testing will start in 30 minutes.
- Enumerate the environment. This will, at a minimum, generate a list of live hosts and open services. Ideally, this will also identify the version of the services and the operating system.
- Analyze the services in the environment. The goal here is to identify potential routes of entry and points of exploitation. This could involve any of the following:
- Vulnerability scanning
- Configuration review
- General information gathering (i.e., shares, error messages, network traffic, etc.)
- Identify hosts and services of interest.
- Build and execute the attack plan. We methodically document the test plan (what is to be tested, how and why). This generally includes multiple actionable plans of attack; e.g.:
- Vulnerability identified (this could be anything from a missing patch to seeing LM hashes on the network)
- Exploit type/avenue of attack
- Expected result
- Upon executing an attack plan, we document the actual results. We continue until an End of Test condition is met.
- Collect evidence and clean up any testing remnants on the network. If we cannot safely clean up a testing artifact, we alert all the people we identified in the kickoff step above.
- Notify you that all testing has concluded.
- Ensure all documentation and evidence is contained within the reporting system.
- Remove any of your data from our testing platform. We are careful to wipe not only collected evidence, but also tool logs that could contain your data.
A comprehensive well-written and easy-to-understand report is essential for the full value of a penetration test to be realized.
You are paying for an expert’s knowledge, observations and opinions. The report you receive should convey these clearly.
The report will contain a narrative of the test plan execution, including any evidence collected. Our standard procedure is to include sensitive information. Confidential information will be visibly redacted if it must be included.
In addition, it’s crucial reports cover all three of these areas:
-
- High reliability and accuracy. Our quality assurance (QA) process is extremely rigorous. No report is sent out until it validated by at least two subject matter experts who did not participate in creating it.
- Easy-to-read. Your report will be written so that someone non-technical, possibly in an upper management role, can understand it easily.
- Provides actionable guidance. Your report will contain clearly defined steps that explain how to close the security gaps discovered during the testing
.
To ensure the report meets your needs, we will review the report with you in person or via a screen share. This ensure that you understand what was discovered, and if and how we reached an End of Test condition; and to assist in planning any recommended remediation.
Contact us to speak with an expert about our penetration testing methodology and how we can address your testing needs.
After understanding objectives and identifying key considerations, there is still some logistical work to be done before testing can begin.
Additional preparatory steps to help ensure a quality penetration test include:
- Ironing out roles and exchange of contact information. This may seem like overkill, but we do not want our penetration tester asking questions or sending the final report to the wrong person (or people). We therefore take the time to identify:
- The main point of contact (POC) on the client side
- The main POC on the assessment team’s side
- The escalation path if the people involved need more support
- Who should have access to the ongoing and final documentation?
- How to treat confidential information we may uncover
- Reviewing the agreed upon work item by item to ensure that nothing has changed between when the engagement scope is agreed to and when testing actually begins. This is why we always reconfirm the details. In particular:
- It is important to reiterate all standard caveats (i.e., No Denial of Service attacks) as well as any agreed upon stipulations (i.e., All testing will be performed after hours; Man-in-the-Middle attacks are in play for all web-based applications except for the Exchange server, etc.)
- We always walk through the test schedule to ensure you know what to expect.