Red Team Operations: Providing recommendations

The importance of recommendations

The Red Team’s final report is the most valuable part of the entire exercise for the client. In many cases, a Red Team is secretly hired by an organization’s executives to test the effectiveness of their security team. If the assessment is performed correctly, the final briefing and report are the first and only direct contact between the Red Team and the customer’s internal security team.

The goal of the Red Team’s report is to provide a comprehensive narrative of the Red Team’s actions and experiences while testing the customer’s security. This includes describing what the Red Team tried and what didn’t work, as well as identified vulnerabilities that need to be closed to improve the customer’s security.

Some members of the customer’s organization will have the technical knowledge, time and interest or requirement to read and understand the full report. A description of the vulnerabilities discovered during the assessment may be enough for the organization to understand them and fix them effectively.

Recommendations from the Red Team can help if this isn’t the case. In most cases, the Red Team members are the ones who best understand the identified vulnerabilities and how they can be corrected. Providing a checklist of recommended actions can help less technically adept security teams fix the holes in their defenses.

A recommendations list is also useful to the team when discussing the assessment with management. Being able to point to a list of discovered vulnerabilities allows the security team to demonstrate that they’ve materially benefitted from the Red Team assessment and closed all discovered holes within the organization’s defenses.

Tips for recommendations

The recommendations section of a Red Team report is fairly straightforward. After identifying a vulnerability in a customer’s security, the Red Team recommends methods of correcting it. However, (Read more...)

*** This is a Security Bloggers Network syndicated blog from Infosec Resources authored by Howard Poston. Read the original post at: