Red Team Infrastructure
Build red team infrastructure: command & control systems, payload delivery, operational security, and infrastructure automation.
What is Red Team Infrastructure?
Red team infrastructure is the temporary, authorized platform used to coordinate a security exercise, enforce its boundaries, and preserve evidence. It gives operators a controlled way to run approved simulations while security teams observe how people, processes, and technology respond.
Its most important invariant is simple: every action must be attributable to an approved engagement, constrained to approved targets, observable, and stoppable. A platform that is reliable but cannot enforce scope or produce trustworthy evidence is not production-ready.
This lesson focuses on architecture and operations for sanctioned exercises. It does not cover gaining access, hiding activity, or bypassing third-party controls. Review red teaming fundamentals first if scope, rules of engagement, and exercise safety are unfamiliar.
Think of this platform as a short-lived internal service with unusually strict safety requirements: strong identity, explicit policy, isolated networks, complete audit records, an exercised stop path, and provable teardown.
Separate control, exercise, and evidence responsibilities
A red team platform coordinates people, policy, temporary services, and records. The architecture is easier to reason about when control decisions, exercise traffic, and evidence storage have separate owners and failure behavior.
Authorize
Control plane
Authenticates operators, issues short-lived access, evaluates the current target allowlist, records approvals, and exposes the emergency stop control.
Execute
Exercise plane
Hosts only the temporary coordination services required by the approved exercise. It has no implicit route to unrelated production networks.
Observe
Evidence plane
Collects identity, policy decisions, service events, and timestamps into a protected store that operators cannot silently rewrite.
An authorized action crosses explicit gates
The same engagement ID and operator identity should be present at every boundary so responders can reconstruct intent and outcome.
1. Identify
Operator device
Uses managed access and a named human identity.
2. Authenticate
Access gateway
Issues short-lived, least-privilege credentials.
3. Authorize
Scope policy
Checks target, time window, technique class, and engagement status.
4. Coordinate
Exercise service
Runs the approved simulation workflow without owning policy.
5. Exercise
Approved target
Receives only traffic allowed by the current engagement.
6. Record
Evidence pipeline
Persists the actor, decision, action, result, and correlated timestamps.
The policy check belongs on the execution path, not only in a ticket or operator runbook. Human approval starts the engagement; machine-enforced policy keeps each action inside it.
Size from observable work, not server count
Capacity planning starts with the event stream the exercise must preserve. For a first estimate, multiply active targets by events per target per minute. Apply a measured peak factor, then compare that rate with healthy collector capacity after one expected failure.
For example, 80 active targets at 8 events per minute produce about 10.7 events per second on average. A 3x burst is 32 events per second. Two collectors that each sustain 45 events per second provide 90 events per second before a failure, but only 45 after one collector is lost.
80
Active targets
Explicitly approved systems
10.7/s
Average events
80 x 8 / 60
32/s
Modeled peak
Average x 3 burst factor
45/s
Failure capacity
One surviving collector
The estimate is a test plan, not a guarantee. Benchmark serialization, transport, validation, storage acknowledgements, and query load together. Preserve enough headroom for replay and incident investigation instead of sizing only for steady state.
Loading the operating model
The lesson is loading its engagement limits and failure assumptions.
Loading lab data...
Make safety controls independent of operator memory
Production depth comes from explicit contracts at each boundary. Convenience should not allow one credential, host, or service failure to remove both execution and safety controls.
Named, short-lived identity
Use individual accounts, managed devices, just-in-time roles, and session expiry. Shared credentials prevent attribution and make revocation too broad.
Machine-enforced scope
Compile the approved targets, time window, and action classes into policy. Default to deny when the request cannot be matched to a current engagement.
Network containment
Give each engagement dedicated segments and egress rules. Management, exercise, and evidence paths should not share an unrestricted flat network.
Managed secrets
Keep credentials outside images and source files. Issue them for one role and engagement, rotate them during incidents, and revoke them at teardown.
Tamper-evident evidence
Separate evidence writers from readers and retention administrators. Record clock health and immutable object versions so a timeline can be defended later.
Independent stop path
An authorized controller outside the exercise plane must be able to disable new work, revoke access, and isolate services even when the main console is unavailable.
At minimum, every event should carry an engagement ID, operator ID, target ID, policy decision, action category, event time, receipt time, and correlation ID. Sensitive payload content should be minimized or redacted; an audit trail does not justify collecting unrelated secrets or personal data.
Design failure behavior before the exercise starts
A failure is not only an availability problem. It can create unscoped activity, unattributed actions, missing evidence, or an inability to stop. Decide which paths fail closed, which may buffer safely, and who can authorize recovery.
Loading the operating model
The lesson is loading its engagement limits and failure assumptions.
Loading lab data...
Use these default responses:
- Scope policy unavailable: block new actions. Availability is less important than preventing unvalidated work.
- Operator credential exposed: revoke the affected identity, stop its sessions, rotate dependent secrets, and preserve the evidence timeline.
- Collector unavailable: continue only while a bounded, encrypted buffer can retain all required evidence; otherwise pause before creating an audit gap.
- Evidence store unavailable: buffer locally with a size and time limit. Reconcile sequence numbers after recovery and treat any gap as an incident.
- Emergency stop invoked: deny new work first, then isolate services, preserve records, and verify target-side activity has ended.
Redundancy does not replace a stop policy. Extra instances can keep an unsafe workflow running just as effectively as a safe one.
Operate the platform as a short-lived production system
The platform lifecycle begins before deployment and ends only when access, resources, and evidence have been reconciled. Automate the repeatable controls, while retaining a named human owner for authorization and incident decisions.
1 Approve
Authorize the envelope
Record owner, targets, exclusions, time window, allowed activity, data handling, stop conditions, and responder contacts in a versioned manifest.
2 Build
Provision isolation
Create engagement-specific accounts, network segments, secrets, policy, collectors, and evidence storage from reviewed templates.
3 Validate
Prove controls
Test an allowed target, a denied target, credential expiry, clock synchronization, evidence delivery, alert routing, and the emergency stop path.
4 Operate
Run with telemetry
Watch policy denials, active identities, collector lag, buffer occupancy, target health, and changes to the approved manifest.
5 Respond
Contain deviations
Pause on scope ambiguity, revoke exposed credentials, preserve evidence, notify the agreed contacts, and resume only through documented authorization.
6 Close
Reconcile and destroy
Stop activity, export evidence, revoke access, remove routes and resources, verify the inventory is empty, and retain only approved records.
Useful service-level indicators include policy-decision latency, denied-action count, collector queue depth, oldest unshipped event age, evidence write errors, clock offset, credential age, emergency-stop completion time, and teardown exceptions. Every alert needs an owner and a specific response.
Encode authorization and evidence limits
Small dependency-free tools make the operating contract reviewable in CI and during preflight. The first example validates that an engagement manifest has bounded time, named owners, valid network ranges, explicit exclusions, and a stop contact.
The second example calculates how many events a degraded collector path must buffer. Run it with expected rates and outage duration, then test the same envelope against the real pipeline before relying on the result.
Both examples model controls; they do not initiate network activity. In production, sign manifests, store approvals separately from the exercise plane, and export metrics to the organization responsible for oversight.
Review trade-offs with the safety invariant intact
Architecture choices can change cost and convenience, but not the requirement that work remains attributable, in scope, observable, and stoppable.
Shared platform vs. per engagement
A shared control plane reduces operational duplication. Engagement-specific identities, policy, networks, and storage prefixes still limit cross-exercise blast radius.
Availability vs. fail closed
Control-plane unavailability may pause work. That is usually the correct trade when continuing would remove scope or identity guarantees.
Evidence depth vs. privacy
More data can improve reconstruction but increases exposure and review cost. Collect the minimum fields needed for safety, attribution, and agreed learning goals.
Automation vs. independent approval
Automate provisioning, validation, and teardown. Keep authorization changes and resume decisions under separate, named approval.
Before declaring the platform ready, require evidence that:
- an out-of-scope target is denied at the execution boundary;
- a disabled operator loses active and future access within the stated objective;
- one collector or evidence-store outage does not silently lose required events;
- the stop path works without the primary operator console;
- clocks and correlation IDs produce one defensible timeline;
- target owners can distinguish approved exercise activity from a real incident;
- teardown finds no active identities, routes, compute, domains, secrets, or queues;
- retained evidence has an owner, expiry policy, access log, and deletion proof.