Help the Client to Make Decisions
When presented with the test results, the client will ask themselves the following questions:
What do I need to do to correct these vulnerabilities?
In which order should I tackle them? Which ones are acceptable in the short term?
How much is it going to cost to fix them?
We have two goals at the closing meeting:
To support the client in making the right choices by providing as much factual and cost-related information as possible.
To explain our expertise in layman’s terms, so that the client is aware of the implications of the various recommendations.
If the client is already performing risk management work in other areas (social, financial, environmental, etc.), then you can ask them for the indicators they use and apply them to your analysis and report. This makes it easier for them to understand. It’s their deliverable, after all!
If it’s not something they normally do, then you can use your own indicators, which you’ll have defined upfront. The important thing is that the indicators are consistent, evidence-based, and comparable!
For the recommendations, you can use a number of factors to rank them, such as priority, cost, complexity, and required workload.
I personally classify priorities as short term (less than one month), medium term (one to six months), and long term (six months or more). What constitutes “short term” will vary widely from one company to another. We could even add a “very short term” category for very urgent recommendations.
But how do we decide on the priority without resorting to guesswork?
We decide based on the vulnerability it corrects and on the risk it reduces or mitigates.
If, for example, we find a preauthentication RCE (Remote Code Execution) vulnerability in the application (the most dangerous kind of vulnerability), there’s a good chance that the client will need to fix this first. And this is true regardless of the cost or complexity of the recommendation.
How do we guide the client when there are recommendations with the same priority?
Cost, complexity, and workload can be confusing to those who don’t use your indicators on a regular basis. If you end up bringing in external consultants to do the work, is that a cost or is it time? Or both?
Okay, so if there’s a lot of work involved, it must be complex and therefore costly, right?
In my opinion, there’s no correct answer, which is why you have to make a choice and then make it clear in the indicators. This is how I see it:
The cost represents the necessary financial investment (e.g., purchase of hardware or a software license for a tool).
The workload is always difficult to assess, as it is highly dependent on how responsive the client is. We measure it in person-days.
A change to the server configuration is relatively quick to do.
Correcting all the queries that are vulnerable to SQL injections will take a little time, but it is still manageable.
Completely changing processes that are vulnerable by design, on the other hand, is likely to take a considerable amount of time.
Complexity is even harder to assess because it’s not easy to decide what qualifies as complex. I would consider it complex to migrate a rather old application to a new server because the current server is obsolete, even though the software vendor no longer supports that version of the application or, worse, has gone out of business. All this will not only take time, but it could also cause many other problems.
Of course, these indicators are just that—indicative—because there may be more than one solution for each recommendation!
Let’s imagine, for example, that one of your recommendations is to install a WAF solution. This recommendation is so far-reaching that it requires a project to identify needs, benchmark potential solutions, and finally implement the chosen solution. It then requires regular operational maintenance to keep it running smoothly. Alternatively, a client might simply decide to set up an Apache reverse proxy with a few filtering rules, which won’t cost them much. Although the result won’t be the same. You see how difficult this is?
Make It Easy to Implement Your Recommendations
The more you make life easier for your client and their teams, the higher the perceived quality and the greater the satisfaction. Far too often, I’ve heard clients make remarks (referring to someone else’s report, of course) or seen comments on Twitter that go something like this: “The recommendations are not clear,” “They don’t work for our business,” or “They’re not realistic.”
As well as including the recommendation’s priority and other factors in your action plan, I think it’s relevant and useful to include the teams to which each recommendation applies: system, network, development, business, etc.
In the example.com application, we found a number of XSS vulnerabilities, so we need to tell the client what to do.
At the very least, the how and where are missing.
A more detailed recommendation for correcting XSS vulnerabilities might read:
“To correct the Cross-Site Scripting (XSS) vulnerabilities, you need to encode any user inputs that are redisplayed in the body of the page. In PHP, you can use the
htmlspecialchars()function to perform this encoding automatically. Our testing identified the following vulnerable fields:
aaa on page bbb
ccc on page ddd
However, we strongly recommended that you perform a full code review to correct any vulnerable fields that we did not manage to identify in the time available for testing.”
With all this, our client’s technical and business teams should have everything they need to fix the vulnerabilities we’ve found!
Over to You!
Instructions
I’ve shown you one example of a recommendation. Now it’s your turn to tackle the others!
Here’s the list of 16 vulnerabilities we found during our penetration test on example.com (in Excel or Open Document format).
Can you write the associated recommendations?
Solution
Let’s Recap!
The action plan you draw up is a proposal to help the client prioritize their actions.
Your action plan is not a document of irrefutable truth that’s set in stone.
The action plan must be immediately actionable by your client. With the exception of some complex recommendations that may require separate projects, your client should be able to begin implementing most corrective actions right away.
To be actionable, recommendations must be prioritized and include as many useful details as possible: estimated cost, time required, lead team, etc.
You should make your recommendations as detailed as possible to reduce the possibility of questions and misunderstanding. If you can refer to official documentation (e.g., from the manufacturer or software vendor, for the programming language, etc.), add it!
