What Makes a Successful Pentest?

What are the components of a pentest?

Let’s start this off with the basics. What are the major components of a pentest? Well, we know that a pentest is used to provide a security assessment of the controls in place for an application or network environment. Additionally, these tests will help in identifying potential security holes to fix. But that is the obvious part so what are the key components of success?

Scoping

Unsurprisingly one of the keys to success is proper planning just like the 6 P’s of performance emphasize.

So how do we ensure that we plan, or scope, our engagement correctly? A few of the main considerations are:

Getting the appropriate stakeholders involved
Confirming the best targets for the testing based on compliance need, versions to test, preventing disruption, etc
Setting aside time for testing where changes will not be made
Identifying ALL features, functions, and special interest targets in the application or network

With this in mind as part of our process at MCS when planning an engagement with a client we like to ask some fairly standard questions such as those below. This can help ensure that the right people are engaged in the conversation, directly or indirectly, and also provide us, the testers, with the best information on the goals, motivations, and areas of focus for our client.

Application Testing:

What is the purpose of the application?
What kind of data does the application store or process?
How is the application accessed? (e.g., public internet, private network)
What technologies does the application use? (e.g., programming languages, frameworks, libraries)
What are the critical functions or features of the application?
What security controls are in place to protect the application? (e.g., WAF, AD Accounts, MFA)
What is the expected outcome/goals of the pentest? (e.g., identify vulnerabilities, assess overall security posture)
Are there any specific compliance requirements or regulations that the application needs to adhere to?
Who are the stakeholders of the application, and what are their roles?

Network Testing:

What is the nature of the target network? (e.g., internal, external, DMZ)
What is the network topology? (e.g., flat, segmented, hybrid cloud/on prem)
What are the critical assets on the network? (e.g., servers, databases, workstations)
What are the biggest concerns for your business in an assumed compromise? (e.g., loss of IP, destruction of data, reputational damage)
What are the existing security controls on the network? (e.g., firewalls, intrusion detection/prevention systems, access controls)
What is the expected outcome/goals of the pentest? (e.g., identify vulnerabilities, assess overall security posture)
What are the compliance requirements or regulations that the network needs to adhere to?
Who are the stakeholders of the network, and what are their roles?

These are not an exhaustive list, but give a good idea of the sorts of questions to help in planning your engagement for success.

Execution

The next major component of pentesting is of course to do the actual testing itself. This could be a multitude of posts in itself, but in a brief summary the key elements to this include:

Spending the allotted time well. (e.g., use automation where it makes sense, use information gained in scoping to target critical targets and outcomes)
Collecting evidence of work performed and potential and confirmed issues throughout testing. This will save time during reporting meaning more time can be dedicated to the test period.
Returning to recon throughout testing using new information to take a second look at previous areas. This is more important than one may initially think, just don’t spend ALL of your time on recon.
Mindfully push for deeper results on all issues. Just remember sometimes it is of more benefit to the client to move on and find MORE issues than to see just how far one can go when it will be recommended for fix as is.

Reporting

Finally, we arrive at the reporting phase. While this is usually not anyone’s favorite part it is of the utmost importance for our clients to show what we have performed for them, and detail any issues identified and recommendations to remediate them. At MCS we provide reports that contain a key details that are not always seen in other reports we have seen such as:

Screenshots showcasing important information of exploits or discoveries.
Code blocks showing commands used, requests and responses, etc. as appropriate for more context.
Advice on remediation which includes references to vendor patches and documentation, as well as other relevant information such as OWASP cheatsheets.
Steps to reproduce findings including payloads used, commands run, or other descriptions of how to reach the proper area for the exploit.

The reports of course also contain other information such as how risk ranking is performed, the scope of the engagement, and other details around the methodology of testing.

And last but not least!

Lessons Learned/Follow Up

At MCS we believe that in addition to typical report readout we should be available for additional questions and follow up whether that is explaining a finding, or offering some additional guidance in remediation. In addition, we grow as testers with each engagement as well and taking those experiences forward benefits all of our clients. This is a key component to success in our mind because our client’s security gains are our success as well! Most importantly to us at MCS our partnership with a client does not end at report delivery. We are here to help grow your security practices with you.

Are you looking for a security assessment for your network or applications? Send us an email at info@mccormackcyber.com