The Rules of Engagement: Pentesting and helping your clients understand
By Austin Miller
Pentesting is a necessary service that a growing number of businesses are starting to make use of, but that tendency isn’t universal. For some business leaders, it seems like an unnecessary cost. For others, they simply don’t understand what pentesting is and why it is useful. If you’re an aspiring penetration expert, it is a difficult problem to overcome. How can you possibly provide potential clients with exactly what they’ll receive?
Well, that’s easy – with a Rules of Engagement document. Much like the battles of old, establishing rules for any conflict is necessary to determine what is honourable, err, I mean included in the service. For anyone who is breaking out to start their own pentesting business, just like any freelancer, you need to say what you are willing to offer, what the client is expecting to receive, and what they can’t include for free at the last minute!
The five basic principles of the rules of engagement
When you put together your document to explain what you will cover, you need to consider five key principles and make them clear.
- The type and scope of testing
- Client contact details
- Client IT team notifications
- Sensitive data handling
- Status meeting and reports
The type and scope of testing
Are you a black hat or a white hat tester? That’s an important decision to make with your client at an early stage. Clients and pentesters gain different things through black box testing and white box testing, so establishing what the client wants to find out is important for determining how you will approach the situation.
Although anyone can load basic pentesting tools such as Burp, the amount of information you are supplied before you get started is key.
Black box testing requires the testing team to be external to the organization and working with as little internal information as possible. This is good for dry-running attacks made by outsiders who do not have the clearest understanding of a company. It is best for identifying weaknesses in defense mechanisms and internet-facing websites or services.
White box testing is the opposite – the attack has all the information they need to understand the target network. This is usually done to avoid wasting time on reconnaissance, scanning, and profile building for social engineering.
Of course, you don’t have to be at one of these extremes – grey box testing is a combination of the two and combines elements of both types to meet the requirements of the client. A lot of testing is truly grey box testing, so establishing what your client needs and what is necessary for you to obtain – network maps, code, employee information, etc. – is an important step in creating the rules of engagement document.
Client contact details
Sometimes, pentesting will set off built-in defenses for the wrong thing. Although this is a good thing in a way (the defenses are working!), it means that other defenses aren’t tested and other vulnerabilities are not rooted out. For example, if you testing a system for a Log4Shell vulnerability and the network defenses identify your attack as a potential Denial of Service (DoS), you’re not getting the results you want to see.
Communicate with the IT team to get systems back online when they go down.
Client IT team notifications
Depending on your approach, testing the IT teams response ability and time is a necessary step. Planned tests should have a clear plan that is shared with the security specialists ahead of time to help them avoid letting a genuine malicious attack slide past. For unplanned tests, you should know the necessary action you should take if an automated defense mechanism stops your investigation.
Sensitive data handling
Personally Identifiable Information (PII) and Protected Health Information (PHI) are hot topics for any cybersecurity position. That includes pentesters who will potentially gain temporary access to the data.
When carrying out a pentest, you should be aware of proper information security practices in not leaving PII/PHI exposed to genuine malicious actors. Storage and communication must be secure, usually via full disk encryption or through encrypted emails. Any existing regulatory laws should also be followed to the letter.
Status meeting and reports
Obviously, a post-investigation report is what you’re getting paid for. But thorough documentation of process and actions taken by all pentesters should be logged to create an environment that is useful for the client and open in sharing what was done and what should be done. Security teams on the defensive side are still on your team – give them all the information that you can!
How do I know if my rules of engagement are clear?
As previously stated, your documents should clearly show the five basic principles of the rules of engagement – the type and scope of testing, client contact details, client IT team notifications, sensitive data handling, and status meeting and reports – and any legal requirements that are necessary for the country/state you are living in.
Clarifying these tenets in person and having the client sign off on each part of the rules of engagement is always a good idea as well, just to make sure no one gets a nasty surprise!
Want to find out more about pentesting and the rules of engagement?
Take a look at Gilberto Najera-Gutierrez and Juned Ahmed Ansari’s book, Web penetration testing with Kali Linux – Third Edition. This book covers a wide range of topics that are useful for penetration testers and offers practical advice on establishing the ground rules, how to set up a lab, and explanations for how the most famous pentesting techniques work.
If you are subscribed to the SecPro Weekly Insider, you can claim this as part of our weekly survey, completely free. If you want to find out how to automate offensive techniques or how to exploit vulnerabilities in a web application, the book offers the basics in getting you up to scratch.
