The Purpose and Value of Penetration Testing

What comes to mind when you hear the word cybersecurity?

Take a moment and think to yourself.

If you instantly thought of some individual hacking some sort of mainframe like we see in Hollywood, you're not alone.

There is a gigantic market for seasoned professionals who can understand the defined rules of engagement, identify vulnerabilities in these systems and architectures, and then write a high-quality, detailed report of how it was done while relating the activities to risk and providing recommendations for remediation.

It's incredibly valuable, but what most people don't know is that the majority of cybersecurity roles do not fall within this domain. Most security roles fall under defense (blue) and governance.

From our call center representatives or data protection officers to the Chief Information Security Officer (CISO), all of our roles typically fall under the protection of assets and sensitive information.

It simply depends on how far into the incident response plan your role is.

I don't mean to diminish one side or the other, everyone's part is vital in this space and we're all in this together.

For a frame of reference, the penetration testing market size is expected to grow from an estimated value of 1.4 billion USD in 2022 according to marketsandmarkets.

Image provided by Data Bridge

But I want to know more about penetration testing.

Let's delve into the topic.

At its core, penetration testing is a simulated cyberattack conducted by specialized cybersecurity professionals known as ethical hackers.

These experts utilize a variety of techniques and tools to mimic the tactics of real-world hackers, aiming to uncover vulnerabilities that could compromise systems, data, assets, and reputation.

There are several types of penetration tests, from practitioners focusing on systems such as web applications, specific cloud infrastructure, networks, and IoT (mobile phones and hospital equipment, etc.) to performing social engineering techniques.

Keep in mind, that a penetration test is the act of identifying a vulnerability, and then exploiting that vulnerability to realize new controlled risks and provide recommendations. With that layman's definition, consider that a door into a building is a vulnerability. It is an access point that allows a means to leave and enter an environment to access assets.

But how helpful is it? Consider this, you wouldn't plan, build, and architect a boat and instantly take it out to sea before testing for tight seals and functionality, would you?

Likewise, penetration testers perform checks during reconnaissance for information that can be used to identify vulnerabilities, such as system or server information, using the open source intelligence (OSINT) framework, and tools such as Recon-ng and Maltego are applications and frameworks that link and streamline information about the target's assets for additional insights into an optimal approach.

After passive research is done, the specialists move onto more active recon such as passive or active scanning using tools like Nikto, Nexpose or OpenVAS. The chosen tool is selected based on the type of target being analyzed, whether it be a web server, a web applications API (Application Programming Interface) to network scans checking for unpatched or misconfigured and vulnerable IT infrastructure such as firewalls, Palo Alto and Cisco L2 or 3 Switches to exposed ports and services across subnets and vlans.

Once vulnerabilities and attack vectors have been identified, achieving access to the system is the next objective, which is typically done as a means of exploitation.

In any given method of attack (simulated or non-simulated), the workflow of using tools to pivot from one system to another may vary wildly. My suggestion is to reference the MITRE ATT&CK Framework to have a better understanding of the most common variable paths that attacks go through.

This is piquing my interest, but how much value can I offer to companies looking for this talent?

By performing these tests, companies can identify weak points in their architecture configuration and then mitigate the risks by correcting or hardening these attack vectors. The frequency of performing penetration tests should be directly tied to risk. I cannot make a blanket recommendation for performing penetrations annually, especially without performing a targeted risk analysis and understanding the data that needs to be protected.

For example, the PCI DSS (4.0) in Requirement 11.4.6 states that service providers (entities that are directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity) must perform a penetration test at least once every 6 months and after any significant changes.

Image taken from personal notes.

The methodology used for these and other penetration tests throughout Requirement 11 should be established beforehand. The requirement above will typically involve network penetration testing when network segmentation controls need to be tested, such as firewalls, gateways, microsegmentation, etc.

Other methodologies may focus on web application security, which includes testing for the latest OWASP Top 10, including tactics such as Cross-Site Scripting (XSS), SQL Injection, exploiting IDORs or Indirect Object References, etc.

The list of potential vulnerabilities is incredibly extensive, though I'll provide additional resources that can cover more ground later in this post.

Pass or Fail?

So you have a penetration test with a cybersecurity firm, and everything is planned out, from the defined testing methodology and rules of engagement to SLA's (service level agreements) being reviewed and accepted.

Now it's time for the test.

But what if the test results come back with findings of failed architecture design and security controls? Does this mean we failed?

While some may perceive it this way, this result is pretty typical. In fact, I would suggest that if the test did not result in significant findings, the test may not have been as extensive as it could or should have been.

From a business perspective, companies desire to understand their security posture through testing to refine and better configure the environment. You can think of it sort of like a golden image in the DevOps CI/CD process (refining a product over multiple sprints). Without performing these tests, unidentified risks may compound to present a highly vulnerable system.

This post is getting quite long, so I'll wrap it up here- But, If you are interested in learning more about penetration testing, there are some fantastic free resources and tools that you can use to become more familiar with the process from end to end.

Here are some that I find particularly useful:

This definitely won't be my last post on the topic, but I wanted to provide a baseline to get readers up to speed, from introducing the topic from a different perspective to providing context and tools for those interested in becoming more hands-on.

One of the topics in a future post that I plan to go over is API security, as I feel the subject could use more exposure, especially the OWASP API Top 10.

If you would like more information or tools to help advance your cybersecurity efforts, let's connect on LinkedIn or leave a message on the Contact Page.

"Testing is not just about what you're testing, but how you're testing it."

- Michael Bolton