Penetration Testing in Action: A Step-by-Step Guide to Get It Right

We are only human. Our efforts to protect information resources will have gaps that we missed or have arisen due to emerging threats.  Penetration tests help organizations identify weaknesses in the controls framework.  The test results enable managing associated risk.   

There are many penetration test methodologies, but they all generally perform the same activities with the same results.  This article is based on the Open Source Security Testing Methodology 3Opens a new window (OSSTM) with additional content from other frameworks.

How Penetration Testing Works

Penetration testing, or pen testing, attempts to follow the threat actor attack paths to compromise a target system.  While moving along the attack paths, testers seek vulnerabilities they can exploit.  The capability of threat actors to move unseen across resources is also assessed.

The pen test steps in Figure 1 represent how to approach a pen test.  In general, the test is planned, management approves the test, the test is executed, and the organization then assesses and manages the risks associated with the reported test results.  

Note that the testing team is not responsible for mitigating risk.  The testing and remediation teams might be the same, but this is not always the case.  This is especially true when a third party performs the test.

Figure 1: Pen Test Steps

Planning and Approval for Pen Testing

Teams do not simply jump in and start testing.  A pen test is a well-planned effort that can easily be performed via a project plan.  The plan includes what is to be tested and how.

Select what to test

The first step in test scheduling is to understand what information assets exist and their classification.  This videoOpens a new window on Asset Classification explains how to classify identified assets.  The classification of each asset helps determine what and how often to pen test it.  Consequently, deciding what to test and when depends on

• The value to various types of threat actors
• The sensitivity and classification of the data processed on, passing through, or stored
• The difficulty and risk associated with conducting the test

The first two items are directly related to risk.  What is the probability that an attacker will target the system, and what is the associated business impact?

The third point is applicable when you can perform the test.  Will the test interrupt business processes?  Do we have the skills in-house to perform the tests, or do we have to engage a third party?  Engaging third-party testers results in additional costs that might prohibit frequent pen tests.

Learn more: Coding and Code Security Go Hand-in-Hand: How Can Developers Manage Both?

Determine test scope

Information systems do not exist in a vacuum.  They are installed amid other resources and surrounded by physical, technical, and administrative controls.  Systems can also run multiple applications and usually interact with other internal and external systems.  Finally, attack paths to the system vary and include attacks across the perimeter and attacks via user devices.

The test scope clearly defines what elements of the system’s operating environment are included and how the team will test each.  This enables the team to identify the tools and required skills.

Describe expected results

The team should also understand management’s expectations for the documented test results.  This is closely related to what is being tested and why.  Three common questions a test should answer are:

1. How do current operations work, and how are they protected?
2. How is number 1 different from what management expects?
3. What are the security gaps that need attention?

Define boundaries

Threat actors often intend to disrupt business functions.  Pen testing teams are usually not allowed to do that, so management sets test boundaries.  These boundaries define what is and is not permitted in the testing process.  

For example, the team might exploit a system vulnerability, but doing so might take the system down.  Depending on when the test is happening and the criticality of the affected business functions, management will likely deny performing any testing activities that might cause business interruptions.

Another boundary is what the testing team can access.  If the team can compromise a database server, for example, is the team allowed to go so far as to see the data?  Is the team permitted to try to crack passwords?

Management approval

The final step in planning is gaining management’s approval of the test plan.  This is especially true of the test boundaries and reporting expectations.  No pen test should ever be conducted on systems in production without management approval.

Learn more: Is Application Performance Monitoring Key To Protecting Critical Infrastructure Against Cyberattacks?

Test Execution

The actual test consists of 10 steps, as shown in Figure 2.

Figure 2: Pen Test Execution Steps

Step 1 in the test process is the collection of passive information.  Passive information includes OSINT and any other information readily available to understand both the target system and the target organization.  This activity also looks at how software runs during production.  It includes examining the system’s overall operating environment.

The activities performed in Step 1 are often known under different names: discovery, reconnaissance, scanning, probing or enumeration. Regardless of the labels, these activities collect everything needed to understand a system, potential vulnerabilities, and its associated attack paths.  

Step 2 is the active testing of the target system’s attack paths within the boundaries specified in the planning documents.  Active testing includes both static and dynamic analysis.  Static testing includes scanning code and the system overall to identify security vulnerabilities.  

Active testing stresses the system to see how it behaves outside its normal operating conditions.  System stresses include attempts to bypass controls (including users) and denial of service attacks.

In Step 3, the team analyzes the testing data collected.  The results of this analysis help understand attack paths and how system elements might be compromised.

Step 4 contributes to vulnerability analysis by including all interactions with other elements of the system’s operating environment.  These elements are identified in Steps 1 through 3.  Interaction analysis should look at the types of connections, how they are secured, and the data shared.

The correlation of the information collected from all previous steps happens in Step 5.  This aggregation and reconciliation build a clear picture of the system, its operation, and its operating environment.

Steps 6 through 9 map the system within its environment and create metrics to measure current and future states.  The state at which the system should safely operate is either created or reviewed.  

Step 10 is a gap analysis between how the system should operate and be protected and its current state.  

Reporting

The gap analysis is combined with any successful simulated attacks to create the report.  The report should consist of a section for management and one for the technical team.  The management report contains potential impacts based on what is found.  It uses language that is meaningful to a business manager.

The technical report includes detailed data from the tests and attacks.  It must help in assessing risk and determining how to block threat actors from following identified attack paths.

Learn more: Black Hat USA: Supply Chain Security Remains a Key Puzzle That’s Tough to Crack

Four Point Process

The 10 steps are not etched in stone, and the activities in each vary based on test planning and approach.  Regardless of the method, the following outcomes are needed.  OSSTM calls them the Four Point Process.

• Induction establishes “principle truths” about the target system.  These truths include the architecture and operation of the system, and they map out the system’s operating environment.  

• Inquest investigates the system’s interactions with its operating environment.

• Interaction determines how the target system responds to internal and external stimuli.  This includes attempts to exploit vulnerabilities.
• Intervention changes how the target system interacts with its operating environment to measure the robustness and security of the system.  In other words, how well does it do if faced with anomalous internal and external behavior?

Manage Risk

The test report is used to conduct risk assessments.  Assessments are needed because not every weakness identified presents a high risk.  Further, threat modeling can identify the vulnerabilities that provide the most significant risk reduction when managed.

The NIST Risk Management FrameworkOpens a new window and the video Vulnerability Management and the CVSS CalculatorOpens a new window are good resources for managing vulnerability risk.

Types of Pen Tests

There are three types of pen tests: black box, white box, and gray box.  In a black-box test, the testing team has no knowledge or information about the target system.  This can require significant effort in Execute Step 1.

In a white box test, the team has in-depth knowledge or information about the system.  Most, or all, of the information gathered in Execute Step 1 are already identified.  This information may include open ports, applications running, and interactions with other systems.  The team must perform an information system gap analysis to determine the scope of Execute Step 1.

A gray box test is a hybrid of a black box and a white box test.  The testing team has some but insufficient information about the target system.  As in the white box test, the team must perform a gap analysis to determine what information-gathering activities are still needed.

Because the OSSTM approach described in this article works for both pen and general security testing, it easily fits into any of these test types.  For example, it enables intensive security testing of a system before it moves to production. Pre-production testing is an excellent example of white-box testing.

Final Thoughts

System security testing helps an organization understand the current system and associated internal/network controls:

1. Are working as expected to prevent, detect, and respond as expected
2. Are effective against new threats

Testing requires following the attack paths threat actors use to achieve objectives.  Is each node on the attack path (routers, firewalls, switches and users) configured to block path progress?

White box testing is a good approach for pre-production pen tests.  However, black-box tests are better if an organization wants to see how hard it is for a threat actor to gather sufficient information effectively to launch an attack.

There are many approaches to conducting pen tests.  It does not matter which method is selected; it only matters that the intermediate and final objectives described in this article are achieved.

Do you think penetration testing is complex and requires a well thought out strategy? Comment below or let us know on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We would love to hear from you!