By Dan Featherman   /   Aug 11th, 2020

A Pentest is Just the Beginning

Have you been involved in a pentest in the past? Did you know what was going to be required of you and what you were going to get out of it (i.e. the “net value”)? In this blog, I’ll touch on a few points for maximizing the value of penetration tests and red team assessments. (You can also read: Getting the Most Out of Your Red Team Test.)

Let’s start by looking at what these types of assessments are designed to identify, and more importantly, what they are not. The purpose of a pentest is to identify exploitable vulnerabilities in a system or application, and to the extent possible, qualify the associated risk. Penetration tests and red team assessments should NOT be mistaken for a vulnerability assessment!

What’s Involved in a Pentest

Generally, penetration tests and red team assessments are not going to produce a laundry list of vulnerabilities. If your organization’s annual pentest did, you may want to inquire with the vendor and ensure that you were not simply sold a glorified vulnerability scan. Further, a pentest is not the finish line, it is more like an annual check-up. You wouldn’t go to the dentist once and consider that life task complete, would you? No! You should come away with an understanding of areas for improvement, a plan for making those improvements, and an appointment for your next checkup!

It’s important to note that a pentest is not a point-in-time assessment, but it should identify known vulnerabilities affecting the target(s) at the time of the assessment. In this sense, they should help to establish a benchmark that can be improved upon. Security is an iterative process. There is no element of “future proofing” here folks. The threat landscape is constantly changing, and new vulnerabilities are being identified every day. This means that security practices should follow suit by promoting diligence, proactiveness, and evolution. Let’s use patching as an example – if you know that you have a pentest next week, are you spending extra time this week applying those patches that you’ve been meaning to roll out for weeks or months?

Going back to our dental analogy – do you really think you are going to fool anyone by flossing for a couple of days prior to your visit? Probably not. Sure, applying those patches will improve your security posture briefly, but unless the systemic patching issue is addressed, the organization may once again be vulnerable in a short period of time. Malicious actors are not going to wait for you to apply patches before attacking. This kind of last-minute security culture could result in a pentest creating a false sense of security and is really doing the organization a disservice.

Don’t Pull an All-Nighter Before Your Test

Unfortunately, we see this a lot – “remediation catchup” is performed at a sprinter’s pace immediately before the annual pentest (loads of patches are applied, new GPOs are created, systems are decommissioned, ACLs are changed, etc.). And although this may result in fewer findings, it does not address or help to highlight underlying systemic issues. Of course, we always recommend performing a pentest after any major network or system change, that does not mean altering normal procedures to apply Band-Aids or “quick fixes.” My goal as a pentester is not to identify IT negligence, though that is sometimes a byproduct, it is to identify vulnerabilities that can be remediated or aspects of security that can be improved.

A Pentest Report Can Help Document Your IT Budget Needs

A pentest can identify cybersecurity or process gaps. For many organizations, budget restrictions may limit needed cybersecurity updates, most frequently in the form of time and staffing, so help your pentesters help you by communicating security concerns in advance. Take some time before the engagement to outline specific goals, or to define areas of concern (resources like MITRE’s ATT&CK framework are great for this). Work with your pentesters to architect the engagement around these areas. Let them validate the risk, qualify it in business terms, and provide their unbiased opinion. Furthermore, third party validation and recommendations may bear more weight with decision makers.

How are Your Monitoring & Alerting Capabilities?

Are you using a SOC? Do you have a SIEM? Use your pentests to train your analysts or further tune your monitoring and alerting capabilities. Collaborate with your pentesters and ensure you are getting regular status updates. If a vulnerability is exploited, but you only find out in a status update, then you have identified a gap in your monitoring and/or alerting. Request the relevant details (such as time, scope of targets, attack vector, etc.), write new alert triggers, and ask your penetration tester to retest that finding. If an alert was generated from your SOC, was it within the predefined thresholds for that event type? Pentests are often good exercises for confirming that SLAs are being met.

A pentest should be a positive experience and organizations should see more value in them than simply checking a box. Hopefully the recommendations contained in this blog post will help you to architect your next pentest in a way that optimizes the value for your organization.

Contact us if you have not had a pentest in the last year; our expert team will be happy to help!

About the Author

Dan Featherman

Dan is the Chief Product Officer and Principal Consultant at LMG Security. He came to LMG in 2014 from Garlington, Lohn and Robinson where he served as Network Administrator and IT Manager for 7 years. Dan graduated with high honors from the University of Montana with a degree in Applied Science. Dan’s current certifications include CISSP, GIAC GPEN, OSCP, CompTIA IT Operations Specialist (CIOS), Secure Infrastructure Specialist (CSIS), A+, Net+, Security+, CCENT, Metasploit Pro Certified Specialist (MPCS), and Nexpose Certified Administrator (NCA). Dan is also a member of the GIAC GPEN advisory board, in addition to the University of Montana Computer Science advisory board, and served several years as the Montana State Representative for the International Legal Technology Association.