07 December 2020

If you clicked to read this blog post, my guess is that you're expecting a tale about how our security research team discovered a CVE in our reporting software. Sadly, that's not the case. But we had to get you to click somehow.

In the offensive security community, we love to talk about new tools, exploits and tactics. After all, keeping our skillsets on the cutting edge enables us to provide the best value to our clients. If there's one aspect of offensive security work that is bound to bore and result in no one reading a blog post, it's reporting. It's simply not the most exciting part of offensive security work, but if we're honest with ourselves, that's the product we're selling. Sure, we need to "hack" well, but at the end of the day, we're selling a report.

If you're with me so far, you likely enjoy or at least tolerate report writing. After all, it is fun to document our attacks and call out problem areas for our clients to address. If you're anything like us, you'll write a report in a format similar to this:

1. Executive Summary
2. Findings
3. Technical Walkthrough
4. Appendices

Sections 2 and 3 form the bulk of the work. After we're done meticulously documenting our screenshots and technical summaries, we then spend as little time as possible creating a "high-level" overview of the assessment in the executive summary section. In the past, FortyNorth's executive summaries looked something like this:

• Logistics overview (dates, assessment type, points of contact)
• Assessment explanation (what the purpose of the test is)
• Assessment goals
• A table depicting the quantity of findings by severity
• Overview of the client's strengths and weaknesses

It was a pretty decent executive summary. We zoomed out from our technical work and provided a high-level snapshot. But something about the structure of the executive summary didn't sit with me. It didn't feel sufficiently "executive".

The CVE

A couple months ago, a client reviewed one of our reports and made an interesting comment about our executive summary. They said something to the effect of, "This is an operational summary." I smiled. That perfectly summarized what I had been feeling about our executive summaries.

To be fair, there was absolutely nothing wrong with our old executive summaries; they were written clear of grammatical errors and tech jargon and always remained factually accurate. But they were just summaries of the operation; they described the goals, methods and results of the assessment operations. Our "executive" summaries were just "operational" summaries.

We met as a full company to discuss how to shift from an operational report to an executive report and we landed on the following executive summary structure:

• (Very) brief assessment introduction
• C-Suite relevant risk summary
• Attack narrative
• Attack impact
• Client's technical strengths and weaknesses

Here's a brief explanation of each section.

Assessment Introduction

This section is super short and literally introduces what the assessment was and what the goals were. One sentence and a table of client-specific goals.

C-Suite Relevant Risks (Resulting from Security Findings)

You likely found some interesting security vulnerabilities. Maybe there's a high/critical finding, or maybe it's a bunch of low-medium vulnerabilities. Step back from your role as an offensive security engineer and think holistically about the client's organization. What, if any, risk(s) result from those vulnerabilities? Are there operational impacts? What about vulnerability to regulatory actions? Is their IP at risk for theft?

Summarize the risk a malicious actor creates if they act on the security vulnerabilities. A few sentences and a table of the quantity of security vulnerabilities by severity level.

Attack Narrative

This section is tricky. It is a short (1-2 paragraph) overview of how you technically accomplished your assessment objectives, without using tech jargon. For example, terms like "kerberoasting" would be replaced with "password cracking".

Bonus points for a nice chart showing how you conducted your attack.
Ex: Phished to Gain Internal Network Access -> Stole Credentials from Password Manager -> Added User to Administrators Group

Attack Impact

My favorite section– this is where you think about the systemic risks to the organization. These risks often don't involve IT concepts.  Here are a few examples:

• Data Loss / Operational Downtime from Ransomware Attacks
• Theft of Legal Strategies
• Regulatory Actions from Exposed PII

The idea is to consider your client's business, industry and regulatory environment and then suggest the potential impact of your security findings. This is similar to the risks section above, but this is where you can dedicate a little more time to outlining the types of risk and how they are related to specific attacks.

Overview of Client's Strengths and Weaknesses

What did they do well? Where did they fail? These are just top-line technical strengths and weaknesses free from jargon and with a few sentences of explanation.

A New Approach

We shifted from an "operational" summary filled with a discussion of our assessment to an "executive" summary that focuses on systemic risk to the client in a way that does not require any technical knowledge.

In the course of working on security assessments, we often read "old" reports. A lot of them read like our previous executive summary. We'd love for our industry to shift toward "executive" summaries and away from "operational" summaries.

If you've read this far, please send us feedback and let us know what you think about our new format. Where could we improve? If you're reading this and already write your executive summaries focusing fully on executive-level systemic risk, you're awesome.