Note: BYOR is specific to Mitigant CAE (Cloud Attack Emulation)

‍

What exactly is BYOR?

‍

Bring Your Own Role (BYOR) is Mitigant CAE's unique approach to access control that puts you in complete command:

The Concept:

• Instead of granting Mitigant broad, vendor-defined permissions, you create your own IAM role
• You define exactly what Mitigant CAE can and cannot access
• The role you provide during onboarding becomes the absolute security boundary
• Mitigant CAE operates only within the constraints you establish

‍

Why This Matters:

• Zero trust: You don't have to trust Mitigant's permission design—you control it
• Regulatory compliance: Demonstrate to auditors that you maintain strict access control
• Risk management: Limit blast radius according to your organization's risk appetite
• Flexibility: Start narrow, expand gradually as confidence builds
• Transparency: No hidden permissions or vendor lock-in

‍

Learn more : BYOR Release Blog Post

‍

‍

How do I configure BYOR for different use cases?

‍

Scenario 1: Initial Evaluation (Ultra-Conservative)

Goal: Assess platform capabilities, no attack emulationApproach: Read-only access to non-production accountPermissions: Describe, List, Get operations onlyRestrictions: No write operations, no production accounts

‍

Scenario 2: Pre-Production Attack Testing

Goal: Run full attack scenarios in test environmentsApproach: Read + write access scoped to test resourcesPermissions: Full EC2, S3, IAM within test boundariesRestrictions: Resource tags (environment:test), specific VPCs, test account only

‍

Scenario 3: Production Validation (Conservative)

Goal: Limited production testing on non-critical workloadsApproach: Read-only plus specific write operationsPermissions: Describe all, modify only tagged resourcesRestrictions: Explicit deny on production databases, customer data stores

‍

Scenario 4: Comprehensive Production Testing

Goal: Full validation of production security controlsApproach: Broad access with specific high-value exclusionsPermissions: Wide range of operations across servicesRestrictions: Deny access to customer PII, financial data, specific critical systems

‍

Scenario 5: Compliance Testing

Goal: Generate evidence for auditorsApproach: Focused permissions for specific compliance requirementsPermissions: Aligned with compliance framework requirementsRestrictions: Time-based access during audit windows only

‍

‍

‍

‍

‍

Can I change the role permissions after onboarding?

‍

Yes, absolutely. BYOR is dynamic:

Expansion: Add permissions as you build confidence

• Start with read-only for assessment
• Add write permissions for specific services
• Gradually expand to production scope

‍

Contraction: Reduce permissions if needed

• Remove access to services you're not testing
• Narrow scope after completing specific tests
• Implement temporary restrictions during high-risk periods

‍

Rotation: Update credentials on your schedule

• No dependency on Mitigant-managed secrets
• Follow your standard credential rotation policies

‍

Revocation: Remove access entirely anytime

• Delete the role to immediately terminate access
• No vendor dependency or lock-in

‍

The platform adapts to whatever permissions are currently available—no disruption when you modify the role.

‍

‍

‍

‍

What happens if Mitigant CAE tries to exceed the role's permissions?

‍

Simple: The cloud provider blocks it.

‍

Cloud-Native Enforcement:

• AWS IAM, Azure RBAC, enforce your policies
• Mitigant CAE cannot override or bypass these controls
• Failed operations are logged in CloudTrail/Azure Activity Logs
• You receive visibility into any attempted actions

‍

Graceful Handling:

• Mitigant CAE detects permission boundaries and recommends appropriate attacks
• Attacks that require unavailable permissions are automatically filtered
• Clear feedback when operations fail due to insufficient permissions
• No disruption to other platform functionality

‍

Example: If your role doesn't include rds:* permissions, Mitigant CAE simply won't recommend or attempt RDS-related attacks. It works within the boundaries you've set.

‍

‍

‍

‍

How does BYOR compare to other security tools' access models?

‍

Most cloud security tools use one of these approaches:

Vendor-Managed Roles (Common with CSPM/CNAPP):

• Vendor defines a role with broad permissions
• You grant access using vendor's template
• Less control, more trust required
• Permissions may exceed what you need

‍

Cross-Account Roles (Traditional Model):

• Pre-defined trust relationship
• Fixed permission set
• Difficult to customize
• Often overly permissive for compatibility

‍

Mitigant's BYOR (Customer-First Model):

• You define everything
• Start minimal, expand as needed
• Matches your risk tolerance exactly
• No vendor lock-in

‍

The Difference: BYOR inverts the control model. Instead of "trust us with these permissions," it's "we'll work with whatever permissions you're comfortable granting."

‍