As the title says, in the rules of engagement I have my scope, used method, etc. but I've been wondering if I should also include a list of tools (such as NMAP, Dirb/Ffuf, etc.) that might be used.
And if not, how should I be transparent with the client about the way I'm going to perform the pentest?
My concern is that management will not understand the tools I'd like including in the RoE, even with a small description trying to explain the purpose of the tool.
You should explain your methodology, but a full list of tools usually isn't included for several reasons:
Management don't need to know and understand all of the tools. When they get a builder in to build them a new office, they don't ask for a list of every tool that they're going to use. They hire a professional, and leave those decisions up to them.
If the client asks, you can give them a list at the end of the engagement (or an indicative list before you start). But it's not something I would do as standard.
There is no rule, but in addition to the executive summary you will normally submit a more technical report with your findings.
The executives usually don't have a clue about tech, but there is usually an IT team, who will look at your report too, and assess the results. Quite probably they will take part in remediation of the flaws, possibly with assistance of the pentesters. So they deserve some insight. In fact there may even be a fully-fledged network security team on site. If you defeat their defenses, they will want to know the details, and they should get them.
I personally like to provide technical appendices, that includes not only the tools used, but sometimes, the exact commands that were typed. You can easily record the output of a terminal session (for example using GNU screen) and then do copy-paste into your report.
What's the point? The point is to provide commands or attack scenarios that can be reproduced by the technical team later, in order to verify that the flaws have indeed been patched. And it's something they could run anytime, for example after making configuration changes or adding infrastructure components.
Even a simple nmap command is useful and worth quoting, if it's been instrumental in locating a vulnerable endpoint. No need to quote every tool you know or you've used, but rather quote the tools that actually helped you during that assignment.
If you find a flaw, you've done a good job, congratulations. But if you explain the methodology this is even better because the readers are going to learn a thing or two, and perhaps they will be able to incorporate the methodology in their own business process.
As the saying goes, don't just give a man fish - teach him how to fish (or phish).
