A Red Team Maturity Model

A model for building and improving your internal Red Team

A model to reference when gauging Red Team maturity, setting goals, and providing guidance when building internal Red Teams.

The Matrix - This is the core of the model.

The Questions - Questions that need to be answered and understood at each level of maturity.

Meta - These are bits of wisdom that aren’t covered in a standard maturity model, but will play a large role in the success of a Red Team.

Contributors - This model wouldn't be here today without the help and input from several individuals and organizations.

Feedback, Comments, Questions? Use the Notion link below to access the model. There, you can add comments for public discussion.

The Red Team Maturity Model is proudly sponsored by Adversis, a boutique cyber security firm specializing in holistic business cyber security services.

RTMM is sponsored by Adversis

The Matrix

Program

Strategy

Level 1 - Defined

• Vision, Mission, and Objectives defined • Red Team properly defined and differentiated • Standard Operation Classes defined

Level 2 - Managed

• Vision, Mission, and Objectives socialized to broader security org • Key operation classes implemented

Level 3 - Optimized

•Vision, Mission, and Objectives socialized to all stakeholders • All operation classes implemented and reviewed - revisited annually

Measurements & Results

Level 1 - Defined

• Program Level roadmap reporting • Ongoing tracking/reporting of red team operation status based on annual plans • Findings formally tracked to completion

Level 2 - Managed

• Red Team operations consistently lead to tactical improvements • Metrics gathered per operation, such as mean time to (detect|respond|eradicate) • Feedback is collected from stakeholders post Red Team interaction

Level 3 - Optimized

• Red Team operations lead to measurable organizational improvements such as influencing strategic security decisions and strengthening blue team capabilities

People

Team

Level 1 - Defined

• Meets regularly to discuss operations and program initiatives • Defined team structure, roles and responsibilities (Lead, Senior, Junior) • All operations performed by external services out of necessity

Level 2 - Managed

• Operators considered SME’s in targeted tech stacks and processes.  (eg, cloud, finance, payment processing) • Some operations performed by external services out of necessity

Level 3 - Optimized

• Dedicated developers, operators, leads, etc. • Ability to leverage target technology SMEs (cloud, devops, finance, domain tech) • Ability to augment operations with external parties

Partnership

Level 1 - Defined

• Strong Blue Team and Physical Security leadership support • Strong integration with Legal and Risk

Level 2 - Managed

• Strong LOB leadership support • Strong partnership with CTI and LOB stakeholders

Level 3 - Optimized

• Organizational leadership support for Red Team • Strong partnership with Crisis related teams

Development

Level 1 - Defined

• Defined capabilities per RT operator • Training classes and time available as pertains to strengths/weaknesses of Red Team

Level 2 - Managed

• Strengths, weaknesses and operator capabilities regularly evaluated • Internal professional development program (eg, opportunities to strengthen RT skills)

Level 3 - Optimized

• Job shadow opportunities defined for red/blue/remediation, etc.

Processes

Planning

Level 1 - Defined

• Basic knowledge of the organization’s business/technical env • Ad hoc operations and goals • Technology focused ops • Annual program-level retrospectives

Level 2 - Managed

• Advanced knowledge of the organization’s business/technical env •Proactively planned operations

Level 3 - Optimized

• Strong understanding of company threat landscape • Operations planned and chosen in context based on top business risks and threats and modeled after threat actor motives and TTP’s • Regular Red Team self-reflection and improvement cycles

Operational Processes

Level 1 - Defined

• Defined Rules of Engagement and deconfliction • Defined reporting processes and templates • Standardized risk definitions • Defined services, intake, and output processes • Deliverables go through a quality assurance process (eg. Reports go through a gauntlet)

Level 2 - Managed

• Legal interwoven into RT processes • Findings integrated into GRC processes and intakes or dedicated remediation personnel • Risk scoring consistent with GRC, rest of organizations’ risk scoring procedures

Level 3 - Optimized

• Defined processes and support for publishing and contributing open source tooling or knowledge • Operations and Reporting mapped to common frameworks (MITRE ATT&CK)

Technology

Tooling

Level 1 - Defined

• Open source only capabilities (tools, vulns, exploits, c2’s)

Level 2 - Managed

• Custom tools and scripts • Automation/validation of TTP’s and blue controls • Automated infrastructure deployment • Automated logging from attack infrastructure

Level 3 - Optimized

• Custom C2 and implant capabilities • 0 or N-day exploit capabilities  • Automated reporting capabilities • Ability to adapt technology maturity based on threat actor emulation and organizational needs

Labs

Level 1 - Defined

• Manual infrastructure • Manual logging

Level 2 - Managed

• Wiki/Knowledge Base with runbooks for common TTP’s • Internal source code repository for shared code, tools, and script

Level 3 - Optimized

• Lab with target environment tech/security stack • Automated lab deployment

The Questions

The Questions are sets of questions that need to be answered at a given maturity level. The answers are highly dynamic and should be reviewed frequently.

Base Questions

What does blue assume about their own abilities?Who/What is targeting your organization? What are your organizations crown jewels?Where are the strengths and weaknesses of the blue team?How do employees gain and lose authorization to access data and systems?What assets are important?What does the perimeter look like? What is the risk appetite of the organization?

Advanced Questions

Where does the critical data live, and how is it transferred between systems?Who has access to the critical data? Who is supposed to have access to it?What processes are critical?What supply chains have the greatest impact on the org?How does the company function? This is a loaded question, it includes culture, salary, hiring techniques, etc. 

Contributors

These are the folks that make this thing valuable through the continuous nurturing of the project.

Jordan Potti

Jordan is the Attack Surface Lead at Rivian. Jordan created this model because he was sick of hearing the definition of what a Red Team is. In his words, "who cares what you call it, as long as it moves the security needle in the right direction".

Noah Potti

Noah is a Staff Adversarial Emulation Engineer at Okta. In addition to Bishop Fox, Noah has conducted Red Team operations for multiple Fortune 500's, including Symantec, where he led the Red Team function after leaving Capital One.

Trevin Edgeworth

Trevin is the Red Team Practice Director at Bishop Fox. Not only was Trevin's approach to building Red Teams the sole driver of this project, he also continues to iterate and improve on this model directly and indirectly as his influence is felt across the industry.