Red Team Operations: Report structure and content

What to report

The first stage in building a Red Team report is knowing what to put in the report. Three of the most important things to discuss in the report are identified vulnerabilities, actions taken and any identified compliance gaps.

Identified vulnerabilities

Vulnerabilities identified during the Red Team engagement are the most important details to report. Hopefully, the reason that the client hired the Red Team was to learn about the potential vulnerabilities in their network and how to exploit them, and not just to check a box for compliance.

When reporting vulnerabilities, it is important to provide as much detail as possible to the client. Information that should be collected for reporting includes:

  • The details of the vulnerability
  • The severity of the vulnerability
  • How the vulnerability was discovered
  • How the vulnerability can be exploited

This information provides the customer with the information that they need to replicate the issue and also to properly prioritize remediation actions.

Actions taken

During a Red Team assessment, it is critical to record all actions taken during the engagement. This includes both digital actions (scanning, exploitation and so on) and attempts to identify and exploit physical vulnerabilities.

The log of actions taken during the assessment should be used to build a timeline of the events performed during the engagement. This timeline is useful to both the client and the Red Team.

The customer benefits from a timeline of actions taken because it is helpful in understanding the narrative of the exercise (i.e., how the Red Team went from no access to identifying and exploiting vulnerabilities) and to help explain any events that may have occurred on the network. Knowledge of the attack timeline can allow the organization’s security team to look back and identify alerts or other events that could have (Read more...)

*** This is a Security Bloggers Network syndicated blog from Infosec Resources authored by Howard Poston. Read the original post at: http://feedproxy.google.com/~r/infosecResources/~3/gaM02rgKbZk/