TEAMING AND ATTACK STRUCTURE

No matter the structure of the attack, an operational protocol is crucial to the success of the test. As with any test there must exist procedures outside the direct experiment to ensure stability, safety, and accuracy of the results. There are risks that must be planned for to address the uncertainties that lie within the test itself.

TABLE 7.1

Pros and Cons of Multi-Phased Attacks (Parallel)

Type Pros Cons Indicators for Use Challenges

Parallel Shared the use of different testers for each group

• Collects a plethora of security exploiting all (or as many as possible)

• Focused on specific groups without

The existence of a sound operational plan and controlled communication pro-tocol between all parties helps a great deal to protect each organization and add value to the test. Following is a very simple teaming framework for establishing a project management protocol, which assists in dealing with unexpected events in the engagement—Red, White, and Blue—external, control, and internal, respectively.

RED TEAM

The Red Team performs the test. Based on the type of test and the level of knowledge their client is willing to provide, they may be involved in the establishment of the engagement with the White Team to make certain expectations, guidelines, and

TABLE 7.2

Pros and Cons of Multi-Phased Attacks (Serial)

Type Pros Cons Indicators for Use Challenges

Serial Shared

• More attention on each phase (i.e.,

• Desire more control over the evolution of the test’s threat model

procedures are well communicated. The goal of the Red Team is relatively simple:

to attack the target firm within the established scope of the engagement and com-municate to the White Team any critical issues that may represent a risk to the target organization. For example, if during a test, a critical vulnerability is identified that could lead to an excessive impact on the target, the Red Team should communicate this to the White Team to express the volatility of the situation and gain permission before exploiting and possibly causing excessive damage or downtime of their customer’s network or systems.

In some cases, when faced with the alternatives, there are situations where the engagement is temporarily halted to assist the client in mitigating the vulnerability. This type of redirection can be complicated from a logistical perspective. For example, stopping and assisting in the correction of a critical vulnerability may be beyond the original scope and complicate billing and timing issues influencing the availability of resources or other nuances that may disrupt the engagement. However, the breadth of the vulnerability could render the rest of the test insignificant because the depth of the exposure is so encompassing. It is necessary for the Red Team to provide the following information: vulnerability explanation, testing focus, and mitigation.

• Vulnerability Explanation. Detail the vulnerability and the impact that could result from exploitation. This can include characteristics such as downtime, exposure of critical business systems such as billing or trans-action systems, customer impact, partner exposure, or the inadvertent disclosure of private or proprietary information previously defined as beyond the scope of the engagement. In many cases, the vulnerability represents a threat the customer intentionally made clear was something he was not prepared to include in the overall test.

• Testing Focus. Beyond detailing the extent the proposed attack could have, it is necessary to explain what would be the disadvantages of not per-forming the test. Penetration testing is a layered approach founded on an initial vulnerability that usually leads to more opportunities to gain greater access. Without exploiting the identified vulnerability there may exist a cascade of other related exposures that cannot be tested. It is necessary for the customer to make a decision to accept the risk of the potential impact to obtain greater insight as to other weaknesses or forgo the test and accept the possibility of other unidentified exposures within the environment.

• Mitigation. Finally, for the client to fully weigh the options compared to risk and cost, the Red Team should provide a collection of high-level recommendations for repairing the hole. The details of the recommenda-tions will be limited because it is simply the perspective based on the external representation of the vulnerability.

What may seem like a simple fix from the outside view could result in wide costly modification to the customer’s environment. It is at this point where the two companies must address the issue of impact. If the test was being performed with zero knowledge and the client requests help in supporting assessing the required procedures to eliminate the vulnerability, further insight into the customer’s network

may be required by the Red Team to provide a comprehensive solution. Therefore, if the engagement is paused and the client wishes to address the vulnerability based on the potential risk, the information provided to the Red Team may render the entire engagement ineffectual based on the original intent and structure of the test.

To avoid the situation of providing information to the Red Team and influencing the scope of the engagement, the White Team has the opportunity to identify other security resources outside the Red Team to collect the information and work directly with the company to address the vulnerability. In some cases, this allows the Red Team to continue other avenues of attack, for example, on a completely different location, to maintain continuity of the project.