Bring Your Own Role (BYOR) - Deep Dive
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
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."