Attack Surface Analysis Part 2: Penetration Testing

Last updated at Tue, 27 Aug 2024 16:04:47 GMT

In this three-part series, we’ll explore key considerations and strategies for choosing an attack surface analysis strategy, and the ways it can be used to increase awareness of both technical and process-related risks.

This is the second installment in our 2021 series around attack surface analysis. In part one I offered a description and the value and challenge of vulnerability assessment. In this installment I’ll explore a different analysis technique: penetration testing.

To further expand the lexicon we’re building I’ll point to the definition given by NIST for this particular area:

“Penetration testing often involves issuing real attacks on real systems and data, using the same tools and techniques used by actual attackers. Most penetration tests involve looking for combinations of vulnerabilities on a single system or multiple systems that can be used to gain more access than could be achieved through a single vulnerability.”

(Source: https://csrc.nist.gov/glossary/term/penetration_testing)

So, why would you want to perform a penetration test? There are a myriad of different reasons to partake in this particular form of analysis, but for the sake of brevity I’ll limit it to five in this post:

1. Stay compliant. If you’re in a regulated environment and have to follow standards such as PCI or HITRUST, then you’re probably familiar with the requirement to have technical controls which validate the security of your systems. The most common control to validate is (usually)... drumroll please... a penetration test!
2. Find vulnerabilities. While a vulnerability assessment will help discover issues with exploitable software and possible misconfiguration, a penetration test will go much deeper and will highlight issues such as password reuse, weak passwords, account permission issues, issues with trust relationships, and more.
3. Inform decision-makers about prioritization of resources. By validating that a vulnerability or misconfiguration can be exploited, and what the effects of said compromise are, it gives decision-makers a clearer picture of where to use the resources they have to make the biggest impact (bang for the buck if you will).
4. Offer evidence instead of conjecture. This is my favorite reason out of the bunch. Why? I can almost guarantee that a portion of us out there have been in a room discussing a security issue and have heard one of two phrases: “that’s just your opinion” or “prove it.” A penetration test provides a thorough, non-biased test / analysis of your environment from an attacker point of view. To paraphrase a line from Ghostbusters, “there is no opinion, only data.”

If you’ve come to the conclusion that “hey, this seems pretty useful,” like I hope you have, you might also want a little more detail about what a pentest actually looks like in practice. When it comes to strategy for conducting the testing, pentests come in 3 flavors, like neapolitan ice cream: black box, grey box, and white (or crystal) box testing.

Black box testing is most comparable to the average “breach” scenario—a hacker (or in this case, the tester) gets access into your environment with no knowledge of the internal layout. They’ll go through the typical lifecycle of reconnaissance, enumeration, exploitation, etc., with the ultimate goal being up to you! Don’t worry, we’ll go over goals and outcomes for pentests a little later.

Grey box testing is different from black box in that the tester is normally provided with a regular user account and similar knowledge about the network that any other employee would have. The goal of this style of testing is to provide an efficient engagement more focused on systems which pose the greatest risk, as opposed to spending time discovering those during the engagement.

Lastly, in a white (or crystal) box test, the pentester is given full access to architecture information, source code, documentation, etc. While this makes white box testing the most comprehensive form of testing, it is also the slowest, as the tester often has to sift through a lot of data in order to determine potential weak points.

Another important factor when looking at conducting a pentest is the methodology that your tester will be using. While I can’t make the argument that one is “better” than another, what I can say is they are each tailored to providing a specific style of deliverable. Some of the methodologies being used in the wild are:

1. Open Source Security Testing Methodology Manual (OSSTMM)—focused on maximum business value.
2. Pen Testing Execution Standard (PTES)—focused on a defined set of activities, aka an understandable, repeatable framework.
3. NIST SP 800-115—highly attuned to “business need.”
4. Open Web Application Security Project (OWASP) Testing Guide—focused on web application security testing.
5. Penetration Testing Framework—focused on network tests with deep, technical guidance.

Now that you know the different strategies and methodologies for penetration tests, it’s time to look at what you should and should not expect out of the engagement. The first step is to find a partner to conduct the test. How you determine the partner of your choice will partially depend on the style of testing you wish to conduct, but to assist in the interview process I like to ask a variety of questions based on the typical life cycle of an engagement. The outline below should give you an idea of the types of things to consider and discuss:

Establish testing parameters:

1. Communication strategies
   a. Contact information for your team and theirs
   b. Preferred communication methods
   —i. Regular communication
   —ii. Emergency escalations
   c. Daily debriefing
   —i. What the team has done
   —ii. Significant issues
   —iii. Testing detected?
2. Discuss threats and business concerns
   a. Threats: Harvested credentials, phishing, malware, etc.
   b. Business Concerns: Downtime due to disruption of services, data exfiltration, insider threat, etc.
3. Discuss the rules of engagement
   a. Start / end date
   b. Announced vs unannounced test
4. Scoping
   a. What’s your biggest concern? Keep focused (avoid scope creep)
   b. What to test
   —i. Domain names, address ranges, hosts, applications
   —ii. Systems to avoid
   —iii. Third-party systems
   —iv. Test or production environment
   c. How testing is performed
   —i. Internal / external access
   —ii. Level of testing (ping sweep / port scanning, vulnerability scanning, inclusion of client-side software..)
   —iii. “Dangerous” exploits. If your potential partner says “there’s no chance of a system crashing” during testing—run. Run fast. Run far, far away.

Testing is conducted

Review detailed analysis and possible retesting:

1. No cut and paste vulnerability scanner output
2. Analysis—minimum required sections
   a. Executive summary (important conclusions explained via business impact, aka risk)
   b. Introduction (high level description, i.e. “who what where when why”)
   c. Methodology (Detailed description of “what”)
   d. Findings (what was found, with a detailed technical description, sorted so significant issues presented first). Includes System details (hostname, IP), risk level, ease of exploitation, summary, description (technical), remediation recommendations, validation/verification details
   e. Conclusion (summary, recommendations for future tests)
   f. Appendices (screenshots, command output, etc.)

Report delivery

Lastly, I would be remiss if I didn’t bring up some of the challenges associated with penetration testing. The first challenge is that a pentest is a point in time assessment, meaning that they’re great at finding the “big ticket” items that need to be fixed “today.” But networks, like the organizations they belong to, are dynamic in nature, and the  vulnerabilities that existed last month may have been patched or replaced with different issues (patch Tuesday / zero-day Wednesday should ring a bell). I generally recommend starting with annual pentests to start, but moving to quarterly (and even more frequent, targeted tests) as you knock out the low-hanging fruit and your posture and capabilities mature.

The second challenge would be the issue of depth vs. breadth. If you’re only testing once a year then the scope will be larger and the depth of testing (or how many vulnerabilities can be found and how many ways can they be exploited) will be shallower. Performing more frequent penetration testing will allow you to perform more focused and exhaustive testing, but comes with the tradeoff of having to either spend more money on engagements with a partner or standing up an internal penetration testing program. Lastly, while one of the questions posed in the list above was “was the testing detected,” a penetration test is not focused on a capabilities assessment of your processes, technology, or people. The goal of a pentest is ultimately gaining oversight of vulnerabilities. If you’re looking for a capability assessment, or wish to test the resilience of your program against realistic attacks, you’re looking for a red team engagement. Funnily enough, and this may come as a surprise, that’s exactly what we’re going to cover in the next part of this series!

I hope the information above is helpful as you determine which analysis strategy makes sense for you! Check out the other posts in this series for more information on additional analysis techniques to take your program to the next level:

Part 1: Vulnerability Scanning

Part 3: Red and Purple Teaming