Methodologies and frameworks

As Pete wrote in the Open Source Security Testing Methodology Manual (OSSTMM) [14], “A security methodology is not a simple thing. It is the back-end of a process or solution which defines what or who is tested as well as when and where”. It has to contain a lot of information, processes, steps, and what needs to be done. There are many valuable methodologies in security testing. What is needed is to know them all and to be able to combine them correctly, taking cues and inspiration.

Let’s first look at the primary methodologies and then explore how to blend them effectively.

NIST SP 800-115

The 800-115 special publication is a technical guide from the US National Institute for Standards and Technologies (NIST), entitled Technical Guide to Information Security Testing and Assessment. It was last updated in 2008. The process is as follows:

Figure 1.2 – The SP 800-115 process

Skipping the organizational aspects, such as Planning and Reporting, Execution starts with an initial Discovery phase, divided into steps. The first one is Information Gathering – for web applications. It involves understanding the web server and mapping the hosted applications, the various pages for each application, and the input entry points. The second step is related to Vulnerability Analysis.

The Attack phase we are most interested in is Gaining Access when we effectively execute the exploits. The other steps, such as Escalating Privileges, System Browsing, and Installing Additional Tools, are often outside the pure web scope (even if uploading a web shell can be a good idea).

Appendix C contains some helpful information for application testing. It also describes three testing techniques we have already discussed: white box (static analysis), black box (analyzing up-and-running code), and gray box (a mix of the two).

White box techniques are cost-effective but limited because verifying an application’s interactions with other components is impossible. It recommends black box techniques, at least for critical components, as they help analyze the interactions between an application and other components.

Penetration Testing Execution Standard (PTES)

PTES was published in 2014 by several security practitioners. This process, which we previously discussed, is shown here:

Figure 1.3 – PTES technical process

While similar to NIST SP 800-115, PTES goes deeper into the technical aspects and clearly defines a Threat Modeling phase that helps us better understand potential threats. This methodology also includes management steps such as pre-engagement interactions and reporting.

Focusing on the technical components, we can see elements such as Intelligence Gathering, Threat Modeling, Vulnerability Analysis, and finally, the culminating Exploitation phase.

The Vulnerability Analysis phase is notable because it involves active and passive identification of vulnerabilities and a validation part, where we compare the data we collect. Perhaps the most exciting aspect is the private research phase. This involves recreating the environment and hunting for vulnerabilities by fuzzing, reading, or decompiling code.

Finally, although this often serves as a new starting point, we have the comprehensive Post-Exploitation phase. This reminds us that we can use the compromised system as a pivot point within the network.

OWASP's WSTG

OWASP is an independent organization dedicated to spreading an application security culture. One of the primary documents for a security test is the WSTG.

The Top 10 is also produced, which is used to make the general public aware of the most critical risks.

The WSTG, currently at version 4.2, was published in 2020, and it is structured into several parts:

• The first and second parts provide an introduction to application security
• The third part describes how to perform the various tests during the life cycle of an application
• The fourth part contains one of the most comprehensive lists of the various tests that can be performed, divided by category
• The fifth part provides an example of reporting

What interests us most in this context is the fourth part, which contains the test categories that we often use as an operational checklist of what to look for when faced with an application:

Figure 1.4 – OWASP WSTG sections

During a penetration test, the following steps are usually taken:

1. First, start with Information Gathering, Configuration, Deployment Management, and Weak Cryptography in the system configuration to understand the general situation of applying its context.
2. Then, carry out an analysis of the Authentication part, including the elements of Authorization, Identity, and Session Management.
3. We then continue with the “pure” fuzzing part, with Input Validation, Client-Side Testing, and API Testing, always looking at errors, how we are answered, or the absence of an answer.
4. This then concludes by verifying the application’s Business Logic, which often requires manual intervention.

It is important to remember that the WSTG focuses on the application level, so it lacks all the elements of privilege escalation that may accompany the attack, but other guides cover them.

ISECOM's OSSTMM

The Institute for Security and Open Methodologies (ISECOM) is a research community that produces resources, tools, and certifications in security. One of the primary documents we can refer to is the OSSTMM. Now in its third version in 2010, it began in late 2000 and early 2001, and it was one of the first methodologies published. It is currently one of the most inclusive methodologies and is structured as follows:

• The first five chapters describe a meta-model for security testing
• The sixth chapter describes the workflow to be used
• Chapters 7 to 11 contain the test “channels” – human, physical, wireless, telecommunications, and data networks
• The last chapters contain information on compliance and reporting

Unfortunately, version 4 – which contains a particular chapter for the application “channel” – has not yet been released in the public domain. However, its first version had a “web bug analysis” section.

The OSSTMM focuses not on attacks or exploitation but on the broader concept of security testing. It is still helpful to figure out which tests to run and map out the various workflow steps (as shown in the following figure) when testing a web application. It is a must-read. It will change how you approach testing, just as it did for us.

Figure 1.5 – The OSSTMM process

The recipe

We have created a recipe incorporating NIST SP 800-115, PTES, OWASP's WSTG, and The OSSTMM.

The PTES sections form the foundation of the process. We employ testing techniques outlined in NIST SP 800-115 during the Vulnerability Analysis and Exploitation phases. Throughout all phases, we refer to the WSTG as a task checklist. The approach is built upon the OSSTMM and its philosophy, which is the backbone:

• Information gathering: Finding helpful information for the subsequent phases, such as the applications installed and web server information:
  • PTES: Intelligence gathering
  • SP 800-115: Discovery (information gathering and scanning)
  • WSTG: Information gathering, configuration, deployment management testing, and weak cryptography for the system part (from Chapter 4)
• Threat modeling: To understand which kind of attacks and vulnerabilities can be helpful considering the application, its technical aspect, and the interest of a threat actor:
  • PTES: Threat modeling
  • WSTG: Threat modeling from Chapter 2, which considers the tests from Chapter 4
• Vulnerability analysis: We use testing techniques to identify and look at the vulnerabilities list:
  • PTES: Vulnerability analysis.
  • SP 800-115: Discovery (vulnerability analysis), looking for known vulnerabilities and using the testing techniques (white, black, and gray boxes) to find new vulnerabilities.
  • WSTG: In general, the entire process is both iterative and incremental. Understanding the initial objectives derived from threat modeling and intelligence gathering begins. Typically, we begin the process with an unauthenticated preliminary analysis, looking for low-hanging fruits. Then, we continue with the complete tests/attacks.
• Exploitation: Where we can execute attacks and exploits. Once we are “in”, we have the initial access.
  • PTES: Exploitation.
  • SP 800-115: Attack (gaining access). Successfully exploiting an application can sometimes mean gaining access to an operating system. Often, the process is more complex.
• Post-exploitation: When inside a system where we escalate our privileges and gain visibility, we gather more information. If it aligns with our goals, we extract the data we need. This process may further enable us to establish persistence or even initiate a pivot (a lateral movement). This phase, in which we seek to understand the different paths attackers take, is where the MITRE ATT&CK framework comes into play:
  • PTES: Post-exploitation
  • SP 800-115: Attack (gaining access)

We can take further inspiration from the Application Security Verification Standard (ASVS) [15] and OWASP, which contains over 250 application security requirements.

There are also specific methodologies, such as the PCI-DSS [16], for compliance requirements on payment systems and the NESCOR Guide for Industrial Control Systems (ICS).

Finally, we can use the MITRE ATT&CK [18] framework to create and analyze wide-ranging attacks, such as a sophisticated operation against an organization. As noted, a web attack often represents a tiny, though crucial, tactic for initial access.