Module 19: Fortifying Access and Operator Discipline
Table of Contents
← Return to the Red Team Course
Fortifying access means making the assessment reliable without expanding privilege or hiding uncontrolled dependencies. Longer polling intervals, multiple channels, or a trusted account do not automatically make operations safe or invisible.
This module creates an access and failover plan. You will map dependencies, choose least-privilege access, define expiry, and evaluate a failure without claiming redundancy unsupported by the evidence.
Allow 30–45 minutes. Difficulty: intermediate. The plan uses a synthetic mission environment.
Learning Outcomes
- Define least privilege, dependency, expiry, and failover.
- Explain why redundancy shares a common failure.
- Compare access designs by scope, owner, and recovery cost.
- Evaluate an access change against the mission objective.
- Create a bounded access and failover plan.
Start With the Objective
An access decision begins with the mission question. If the objective is to validate a single web control, a broad domain credential adds risk without adding evidence. If the objective requires a scheduled callback, the owner needs an expiry and recovery plan before any channel is enabled.
| Requirement | Smallest access candidate |
|---|---|
| Read one application | Named account and application role |
| Inspect one host | Time-limited management path |
| Validate a domain control | Approved lab identity and controller |
| Observe a scheduled task | Owner-approved task and window |
Map Shared Dependencies
Failover is useful only when its dependencies are genuinely independent
Redundancy fails when supposedly separate paths share DNS, credentials, cloud control planes, certificates, or a single operator device. Draw dependencies before adding a second channel. A longer beacon interval changes traffic frequency, not the visibility or reliability of the whole system.
| Dependency | Failure it shares |
|---|---|
| DNS provider | Name resolution outage |
| Credential store | Account lockout or secret loss |
| Certificate authority | TLS identity failure |
| Cloud control plane | Provider or tenant outage |
| Operator workstation | Local access and evidence loss |
Fallback should be a tested alternative with an owner, trigger, and recovery step. A second hostname on the same provider is a different route in configuration, but it is not independent infrastructure.
Set Expiry and Ownership
Each credential, certificate, route, and scheduled action needs an owner and an end time. Record who revokes it, how revocation is verified, and what happens if the engagement ends early. Avoid shared credentials when a named account or role meets the objective.
| Field | Example decision |
|---|---|
| Owner | Customer identity team |
| Scope | One lab host and one operation |
| Start | Approved maintenance window |
| Expiry | End of window plus review buffer |
| Revocation | Disable account and verify access failure |
| Evidence | Ticket, event record, and owner sign-off |
Watch a Defensive Context
Compass Security’s purple-team presentation adds context for coordinating offensive observations with defensive owners. Use it to ask which telemetry, escalation path, and decision record a live exercise needs. Watch the presentation on YouTube .
**The video does not replace the engagement rules. Your plan should identify the actual customer owner, evidence location, and approval boundary.
Evaluate a Channel Choice
Compare access designs by need, scope, dependency, telemetry, and recovery. A channel with fewer packets might still use a sensitive identity or leave a long-lived credential. A redundant channel might add more accounts and more revocation work.
| Design | Strength | Trade-off |
|---|---|---|
| Single named path | Simple ownership and rollback | One dependency stops work |
| Two independent paths | Better continuity | More access and evidence to manage |
| Shared emergency account | Quick handoff | Weak attribution and revocation |
| Expiring role | Clear scope and owner | Needs tested renewal process |
Justify the smallest design answering the objective. Add a second path only when its independent dependency and recovery value are documented.
Work a Failure Case
**Assume the primary control path uses ops.corp.example and a named assessment account. A second hostname points to the same provider and uses the same account. The provider has an outage during the approved window.
The correct analysis is a shared dependency failure. Changing the hostname does not supply the missing provider or credential. The next action is the documented out-of-band contact or an owner-approved independent path, not an improvised account or channel.
| Observation | Supported conclusion |
|---|---|
| Two hostnames | Two configured names |
| Same provider | Shared infrastructure dependency |
| Same account | Shared credential dependency |
| Provider outage | Both paths might fail |
| Emergency account request | New access needs owner approval |
Create the Access Plan
Produce an access and failover plan for the failure case. Include the primary path, independent dependency, expiry, revocation, evidence, and a rule for stopping when no approved path remains.
Mission objective:
Primary identity, route, and owner:
Shared dependencies:
Independent fallback and its owner:
Start, expiry, and revocation checks:
Expected telemetry and review location:
Failure trigger and approved next action:
Stopping condition:
Completion standard: Another operator uses the plan without inventing credentials, scope, or recovery actions. The plan states when work stops.
Self-Check and Answers
| Question | Expected reasoning |
|---|---|
| Does a longer interval make access invisible? | No, it changes timing while other telemetry remains |
| Are two hostnames independent? | Only if their provider, identity, and route dependencies differ |
| Why name an owner? | Revocation and failure decisions need authority |
| What makes least privilege practical? | A named operation, resource, time window, and review |
| When should an operator stop? | When no approved path or recovery action remains |
| What proves revocation? | Owner action plus a scoped access-failure check |
Next Steps
Carry the access and failover plan into Module 20: Mission Objectives and Reporting . The final module turns the plan, evidence, and limits into a report another team uses.
Return to the Red Team Course for the complete sequence.
