Many barriers to good decisions exist. Sometimes the barrier’s an inherent, individual bias; sometimes it’s a group pathology; sometimes it’s the complexity of the situation or the subtlety of the opponent’s deception plan; and sometimes it’s a combination of many factors. Regardless, it appears to be relatively easy to identify the factors that lead to poor decisions. Cognitive scientists, psychologists, and intelligence analysts are all familiar with the canonical lists of these biases and factors. Less common are lists of factors that contribute to good decisions. Is it simply because we can characterize these latter factors as simply the lack of the former, or is there something more that contributes to success? If so, what are the factors that characterize successful decisions? Similarly, what factors characterize successful red teaming?
{ 13 comments }
Deus ex machina 07.29.09 at 9:36 am
Here’s one factor: good PowerPoint!
Ray Roth 07.29.09 at 11:29 am
Good questions. I found building a red team of subject matter experts (SME) is critical. Each topic that a team considers should be broken down into related issues. They might entail geographical, functional, social, economic or a myraid of other issues. No one individual is an expert in all issues related to a problem, but an individual may have expertise in one issue. Identifying theissues, assemblying SME in each issue, and knowing critical questions to ask of the team members builds a synergy effect. That is to say, each SME has a piece of the puzzle but it is the team as a whole that assembles the overall picture for decision-makers to make decisions.
One final note, SMEs should be separate from the organization mindset having interest in the problem that is before the red team. This allows unbiased thinking for exploring alternative perspectives and avoids “group think”.
Mark Mateski 07.29.09 at 12:06 pm
Ray,
I like your approach of not applying the SME’s view to the whole problem but making synthesis a team function. I think we are all sometimes susceptible to allowing the strong opinion of an expert carry too much weight. It’s probably worth quoting Ephraim Kam: ” … experts have weaknesses, seldom do they know everything. There is no reason to believe that the thinking process of experts is significantly different from that of lay people.”
Phil Ridderhof 07.30.09 at 9:08 am
From a planning and operations standpoint, I’d say that a successful red team effort needs to be built on credibility. Speaking from the “BlueFor” side, planners and strategists are normally well aware of the complexities and constraints on our own actions (logistics being a big one). If planning is done correctly, our actions must be thought through in enough detail to demonstrate feasibility.
This is where I’ve seen a Red Team lose credibility in its engagement. While there are good ideas, they are not given the depth of thought on required specifics. This diminishes their credibility when they are presented. The Red Team should be built and required to put the required “meat on the bones,” to achieve credibility.
Mark Mateski 07.30.09 at 12:26 pm
Phil: That’s a great insight. I’ve seen it many times in games but can’t recall hearing anyone articulate it so directly before. From what I’ve seen, it’s less of a problem with dedicated red team assessments.
Rex Brynen 07.30.09 at 5:56 pm
I think its important not simply to construct a Red Team of SMEs on the various component of the issue, but to also construct a Red Team that can draw upon a range of different organizational, operational, culture, and even life experiences. A group of SMEs from the same box may tend to still think within that same box, even if they all highlight different parts of the puzzle.
This relates, in turn, to the point that Phil Ridderhof makes about the credibility of engagement. Effective engagement requires Red Team members who understand who they are engaging with, and how to package their analysis. They may not be the same as the team members who do most of the generating of alternative analysis.
Guile 07.31.09 at 3:45 pm
I’ll focus my comment on the question, “What factors contribute to successful red teaming?” In my experience conducting red team assessments, planning and preparation comprise the bigger part of the foundation for success. Reviewing lessons learned prior to conducting the assessment helps me avoid making mistakes I or others have made previously. Developing proper scoping and rules of engagement (where applicable) support proper assessment focus. Reliable communication with my sponsor and team helps keep things from deviating off the path to success. Yes, we need to make sure our own thinking is not in a box we have unwittingly created. Additional sanity checks – where possible – can be helpful (e.g., reviewing plans and progress with other trusted people who have an independent view and experience in the problem area can yield relevant insights and feedback). I am sure I can think of still more, but I’ll leave it at this.
Ray Parks 08.03.09 at 5:47 pm
Our experience with the Information Design Assurance Red Team (IDART) methodology onfirms the concepts of diversity and expressing attacks. We believe that a diverse team can best discover the attacks that a real adversary will use – whether against cyber systems or in response to an occupation policy. Each of the Subject Matter Experts (SMEs) researches the system (people, processes, and technology) in the area in which they are expert. The SMEs then generate “views” of the system that reflect their research and their special knowledge. In many cases, they literally use the tools of their profession to express those views. When the entire team brainstorms, we prime that activity with the views from all the SMEs. We don’t ask the team to develop end to end attacks, initially. Instead, each SME and other participants points out particular attack steps they know would work. Some obviously lead from an access point (we call them BGSPs for Bad Guy Starting Point) and others obviously reach an adversary goal. However, many are somewhere in between those two ends of the attacks. This leads to the maximum diversity and creativity – far more than a single individual or even similiar individuals in a team. I agree with Rex that background and experience can play a part in group-think. I tend to include a few outsiders who I think have relevant but not direct experience to contribute. For example, when I formed a red team to look at Security Event Correlation Engines (now known as SE/IMs), I invited a couple of folks from Sandia’s Nuclear Detection departments. As I thought, they had interesting insights into how to fool correlation engines from their experiences – two attacks came from those insights.
@Phil – I agree that the red team needs to show credibility. Just because a red team can perform a single, sometimes devastating, attack step does not mean that the attack is possible. The IDART brainstorming process usually creates a large attack space, with each attack more or less spanning the path from BGSP to goal. However, the raw attack diagram needs refinement and filtering. We express attacks through attack diagrams during brainstorming and to customers, but two other forms are necessary to establish credibility. One form is a state-analysis form expressed in our in-house tool, GAME. GAME expresses the attack steps as edges in a graph – and the nodes are the different states of the system under attack. GAME helps normalize attacks (SMEs don’t all think at the same level of detail) and ensure that there is a succession of system states leading from the BGSP to the goal. The other way IDART expresses attacks is in the form of an attack tree. Attack trees are easier to analyze for performing the capability filter (attack metric vs adversary metric) and (Thanks to Mark) for the adversary attractiveness filter. The logistics issues that you mention are encompassed in the attack metrics (what does it take to perform a particular attack step) and the adversary metrics (what can the adversary do). If anyone involved in the process has qualms about a particular attack step, we can divert from the main red-team process into a little penetration test red teaming to characterize the attack metrics.
Michael Skroch 08.04.09 at 10:58 am
It seems your question is best distilled to “What factors characterize successful Red Teaming” because it is the most specific of your questions. From my experience, here’s what I think without much thought:
I believe the first factor for successful red teaming is sound detailed methodology and process that leads to results that are as complete, accurate, adaptable, and measurable. This leads to a sustainable red team that can improve over time. This includes the ability to transfer knowledge to future generations of red teams. Without this we will not improve and be limited to grey beards and unknowingly unsound and non-measurable practices that are the best we can obtain. While I write this (4Aug09), I am sitting in RTCON09 in Kansas City, and the primary message of the keynote, Lt Gen Jon Koziol is talking about the importance of professionalizing red teaming, and formalizing the process of red teaming in the DoD.
As Mark knows, Sandia developed the Red Teaming for Program Managers (RT4PM) methodology, which distilled many years of red teaming experience on how to define what kind of red teaming is needed in a particular situation, how to define it, and how to find the right red team (or create one) to implement what you need. Answers to Mark’s primary question are imbedded within RT4PM. Note that RT4PM is about how to define and specify red teaming, not how to perform the details.
A second factor is to have the right knowledge about the system being assessed and capability to parallel means of an adversary. This knowledge is critical to obtain a complete red team result. How this knowledge is gathered is varied. One already mentioned in this discussion is having knowledgeable SMEs, yet this traditional thinking about red teaming. We know that a sharp red team can do better than one that is not informed or as bright. The right intelligence gathered from wide sources is another method. Accurate models of systems being assessed is another source of knowledge. I would also include out-of-the-box thinking in this factor.
A third factor is that on top of whatever knowledge that is gained, a red team should limit its abilities and outlook to the adversary, type of adversary, or class of adversary being recreated. It should also expand its approach to red teaming based upon the mindset and culture of the modeled adversary. These together constitute adversarial modeling. While we want our red teams to know everything, an omniscient red team result can be useless if it always determines a good system can be defeated no matter what. That’s not what we need to know because we have no idea where to improve the system. You might also include access to this category. The red team will need the same or similar access to information and systems as the modeled adversary. Many times access is related to legal issues and authority of various government agencies. The category of the above items is probably the least-addressed factor in most red teams today.
A fourth factor is independence, bias, and conflict of interest (COI). These issues must be addressed to have a successful red teaming. Independences follows from integrity and protection from undue external influence. Bias and COI can jeopardize red team credibility and therefore how well results are accepted by decision makers.
A fifth factor is the ability to convey useful actionable results. This includes considering policy, providing quantifiable results in a form that can be digested by decision makers, and informing the appropriate level of detail about why a vulnerability was exploited, not just that a system was penetrated.
Mark Mateski 08.04.09 at 11:09 am
Guile, Rex, Ray, and Mike–Thanks for adding to the discussion. My guess is that if we added your years of work in this area, we’d have a few decades of experience. And, if we were to pool your comments, I think we have a pretty good first cut at the fundamental guidelines of red teaming.
Thanks for the update on RTCON09, Mike. I was hoping to make it for at least a day, but couldn’t circumvent previous commitments.
James Montgomery 08.05.09 at 11:04 am
If I may add a short comment to this growing thread. Mike’s comment on COI and baises speaks to what I spend most of my time on. I see successful Red Teaming (at the tactical level) being mostly about decision support.
One of the most important mantras that a red teamer can take with them into a decision cycle is that the decision is not being made by the red team. Decision support personnel do not own the results. They merely contribute to the outcome.
Although this might seem like common sense, it’s quite easy for red teams to become obsessed with proving that a system/plan can fail. Keeping feet planted in both red and blue worlds with the knowledge that good red teaming will contribute to mission success is about the best you can hope for.
Finally, it’s been said more than a few times in this thread that the results must be measurable. I frankly have been having a hard time with this concept. Red team support in the planning process can be somewhat hard to assess after the action. How do you tell if the dogs aren’t barking because of what you’ve done?
Michael Skroch 08.06.09 at 9:26 am
A couple more things…
I forgot to mention a sixth item, or an item that might be folded into one of the others, trust. I would think it is an independent item because it is so crucial. That item is trust. Not all red teams obtain information freely from their target, but doing so is a technique to save a lot of time and money. In such cases trust is critical to obtain the right information and all the information. The trust surrounds the target belief that the red team is there to help and will share information only with the target or agreed upon entities.
Trust is also built upon reputation, so the red team will loose credibility if it tries to make itself look good by finding and disclosing vulnerabilities at the expense of the target. Self promotion will kill a red team. Trust is essential. There are exceptions where an items is found that is so critical that others must be informed, but those are likely rare and are definitely not done in self interest, and should be disclosed only to the circle with some need to know and correct the problem.
On James’ last comment on measurable results, I think some things can be measured well, others not so well, and perhaps some things not at all. Measuring completeness of security vulnerability coverage is an example. How can you know what you don’t know? Part of this can be answered by considering depth of coverage on a red team–how deeply in detail and technique did you go? It costs a lot to go deep. Part of that measurement is part of the red team makeup–how sophisticated of an adversary can the red team portray. Sometimes you need a sophisticated red team while other times you don’t. There definitely are things that are hard to measure or cannot be measured, and that should be conveyed by the red team so the customer knows the bounds of the assessment. This gets into a discussion of subjective/objective and quantitative/qualitative metrics and how to move between them. We had intial process on this in IDART/IORTA.
Chris Flaherty 08.14.09 at 6:05 am
The main issue is that the individual opinion work of the Subject Matter Experts (SMEs) are integrated into a common voice that translates into the language of the decision makers using the red team product at the end of the process. I think, failure to do this is one of the common detractions from successful red teaming? The ultimate responsibility is that of the project manager leading the team in the first place.
Comments on this entry are closed.