As we all know, there are no official penetration testing standards defined; however, our security community has introduced a few standards for all security personnel to follow. Some of the commonly known standards are the Open Source Security Testing Methodology Manual (OSSTMM), the Penetration Testing Execution Standard (PTES), and the Information Systems Security Assessment Framework (ISSAF). Most of them follow the same methodology, but their phases have been named differently. We will take a look at each of them in the following sections and cover PTES in detail.

The definition of the OSSTMM is mentioned on their official website, at https://www.isecom.org/OSSTMM.3.pdf:

Using the OSSTMM, an audit will provide a precise estimation of security at an operational level that clears out assumptions and unreliable evidence. It is used for thorough security testing and is designed to be consistent and repeatable. As an open source project, it is open to contributions from all security testers, encouraging increasingly accurate, actionable, and productive security tests.

OSSTMM includes the following key sections:

• Operational security metrics
• Trust analysis
• Human security testing
• Physical security testing
• Wireless security testing
• Telecommunications security testing
• Data network security testing
• Compliance regulations
• Reporting with the Security Test Audit Report (STAR)

This part of the OSSTMM section deals with what needs to be protected and how much the attack surface is exposed. This can be measured by creating an RAV (an unbiased factual description of the attack surface).

In operational security, trust is measured as the interactions between targets within the scope that can be exploited by any person with malicious intent. To quantify trust, we need to understand and perform analysis to make more rational and logical decisions.

Human Security (HUMSEC) is a subsection of Physical Security (PHYSSEC) and incorporates Psychological Operations (PSYOPS). Testing this aspect of security requires communication with individuals who have physical access to the protected assets—for example, a gatekeeper.

Physical Security (PHYSSEC) refers to material security inside the physical domain. Testing this channel requires noncommunicative interaction with barriers and humans (gatekeepers) placed within the assets.

Spectrum Security (SPECSEC) is the security classification that includes Electronics Security (ELSEC), Signals Security (SIGSEC), and Emanations Security (EMSEC). Testing this channel requires the analyst to be within the vicinity of the target.

Telecommunications Security is a subset of ELSEC, which describes the organization's telecommunication over wires. Testing this channel covers the interaction between the analyst and the targets.

Tests regarding the Data Network Security (Communications Security [COMSEC]) aspect of security requires interaction with the individuals who have access to the operational data that is used to control access to the property.

The kind of compliance required depends on the locale and currently ruling government, industry and business types, and supporting legislation. In a nutshell, compliance is a set of general policies that are defined by the legislation or the industry, and these policies are compulsory.

The purpose of a Security Test Audit Report (STAR) is to serve as an executive summary, stating the attack surface of the targets tested within a particular scope.

OSSTMM divides the testing types into six broad categories based on the amount of information known to the tester:

• Blind: In this test, the analyst has no knowledge of the target, but the target knows about the audit and has all the details of the analyst. This can be considered a test of the analyst's knowledge.
• Double-Blind: In this test, the analyst has no knowledge of the target, its defenses, assets, and so on. The target is also not notified of the audit. This test is used to check the knowledge and skills of the analyst as well as the preparedness of the target against unknown threats. This is also known as a black box test.
• Gray Box: In this test, the analyst has limited knowledge of the defenses of the target, but has complete knowledge of the assets and workings of the target. The target, in this case, is fully prepared for the audit and knows its full details. This test is also referred to as a Vulnerability Test.
• Double Gray Box: This is also known as the white box test. The target has advance knowledge of the scope and timeframe but has no knowledge of the payloads and test vectors.
• Tandem: This is also referred to as an in-house audit or crystal ball test. In this test, both the target and the analyst know the full details of the audit, but this test does not check the preparedness of the target against unknown variables or vectors.
• Reversal: In this test, an attacker engages with full knowledge of its target's processes and operational security, but the target doesn't know anything about when or how the audit will happen. This is also referred to as a red team exercise.

Here are these types represented in a graph:

Now that we have read through the different OSSTMM test types, let's look at ISSAF.

The ISSAF is not very active, but the guide they have provided is quite comprehensive. It aims to evaluate information security policy and an organization's compliance with IT industry standards, laws, and regulatory requirements. The current version of ISSAF is 0.2.

It covers the following stages:

• Project management
• Guidelines and best practices—pre-assessment, assessment, and post-assessment
• Assessment methodology
• Review of information security policy and security organization
• Evaluation of risk assessment methodology
• Technical control assessment
• Technical control assessment—methodology
• Password security

• Password cracking strategies
• Unix /Linux system security assessment
• Windows system security assessment
• Novell netware security assessment
• Database security assessment
• Wireless security assessment
• Switch security assessment
• Router security assessment
• Firewall security assessment
• Intrusion detection system security assessment
• VPN security assessment
• Anti-virus system security assessment and management strategy
• Web application security assessment
• Storage area network (SAN) security
• Internet user security
• As 400 security
• Source code auditing
• Binary auditing
• Social engineering
• Physical security assessment
• Incident analysis
• Review of logging/monitoring and auditing processes
• Business continuity planning and disaster recovery
• Security awareness and training
• Outsourcing security concerns
• Knowledge base
• Legal aspects of security assessment projects
• Non-disclosure agreement (NDA)
• Security assessment contract
• Request for Proposal Template
• Desktop security checklist—windows
• Linux security checklist
• Solaris operating system security checklist
• Default ports—firewall
• Default ports—IDS/IPS

This standard is the most widely used standard and covers almost everything related to the pen test.

PTES is divided into seven phases:

• Pre-engagement interactions
• Intelligence gathering
• Threat modeling
• Vulnerability analysis
• Exploitation
• Post exploitation
• Reporting

Let’s take a brief look at what each of these phases involves.

Pre-engagement interactions are carried out before an activity kicks off, such as defining the scope of the activity, which usually involves mapping the network IPs, web applications, wireless networks, and so on.

Once the scoping is done, lines of communication are established across both the vendors and the incident reporting process is finalized. These interactions also include status updates, calls, legal processes, and the start and end date of the project.

Intelligence gathering is a process that is used to gather as much information as possible on the target. This is the most critical part of pen testing as the more information we have, the more attack vectors we can use to perform the activity. In case of a white box activity, all this information is already provided to the testing team.

Threat modeling is a process by which potential threats can be identified and enumerated and mitigations can be prioritized. Threat modeling depends on the amount and quality of information gathered; with this information, the activity can be broken down into stages and then performed using automated tools and logical attacks.

The following is a mind map of a threat model:

Let's now have a look at vulnerability analysis.

Vulnerability analysis is a process of discovering flaws that can be used by an attacker. These flaws can be anything ranging from open ports and service misconfigurations to an SQL injection. There are lots of tools available that can help in performing a vulnerability analysis—for example, Nmap, Acunetix, and Burp Suite. New tools are currently being released every few weeks.

Exploitation is the process of gaining access to the system by evading the protection mechanism based on the vulnerability assessment. Exploits can be public or zero-day.

Post-exploitation is the stage where the goal is to determine the criticality of the compromise and then maintain access for future use. This phase must always follow the rules of engagement that protect the client and protect ourselves (covering the tracks as per the requirements of the activity).

Reporting is one of the most important phases, as patching all the issues wholly depends on the details presented in your report. The report must contain three key elements:

• The criticality of the bug
• The steps needed to reproduce the bug
• Patch suggestions

In summary, the pen test life cycle phases can be presented in the following way:

In the next section, we will talk about the Common Weakness Enumeration (CWE) and the two top CWEs.