Recommended resources
The freely available resources this lesson will direct you to.
Hello. In the last lesson, you turned reported adversary behavior into a bounded threat profile and separated what is interesting to test from what the rules of engagement actually permit. That profile describes the scenario. It does not yet describe the risks created by running the exercise itself.
This lesson builds an operational-security (OPSEC) risk register for the hypothetical finance-workflow exercise: a supplied test account, an approved path to a seeded marker, and no permission to change accounts, collect real records, or impair security controls. By the end, you will have a way to record risks to identities, infrastructure, communications, and evidence—and to decide what must be checked before activity begins.
OPSEC protects the exercise, not just its secrecy
An authorized red-team operation creates information of its own: who is participating, which systems belong to the exercise, what actions are planned, and what evidence has been collected. An unintended disclosure can compromise the test. A more serious failure could expose sensitive material, let an outsider misuse team infrastructure, or prevent the control team from distinguishing exercise traffic from a real intrusion.
The five-step OPSEC image gives a useful starting structure.
For this exercise, critical information includes the test credential, the control team's contact route, infrastructure identifiers, and the location of any evidence. A threat might be an external attacker who discovers an exposed administrative service; a vulnerability might be insufficient access restriction on that service. Those are different things. Risk emerges when you describe how the threat could act through the condition and what would happen as a result.
Watch Michael Allen’s short planning discussion in Black Hills Information Security’s OPSEC Fundamentals for Remote Red Teams. Focus on the questions he asks before choosing a safeguard, rather than on any particular offensive technique.
BHIS | OPSEC Fundamentals for Remote Red Teams - Michael Allen - 1-Hour
In OPSEC Fundamentals for Remote Red Teams, Michael Allen describes a practical review of planned actions and the information they might disclose.
Watch the planning process: identify anticipated activity, consider what it could reveal and to whom, assess the consequences, then adjust the plan. Notice that identifying a possible disclosure is only the beginning; the decision depends on how it could be used.
The image presents steps in sequence, but a live register is iterative. A new tool, a changed infrastructure path, or an unexpected record in a screenshot can require a fresh assessment.
There is also an important boundary to OPSEC here: a defender observing the authorized test is not automatically an OPSEC failure. Detection may be the very outcome being measured. Protect the exercise's credentials, approvals, infrastructure, and evidence without suppressing legitimate telemetry or treating concealment as permission to exceed the rules of engagement.
Write a risk scenario that someone can act on
A useful register entry is more specific than “infrastructure exposure.” It states a condition and a consequence: If the exercise's administrative interface is reachable by unauthorized parties, an outsider could access operational records and disrupt the test. That sentence tells a reviewer what needs checking.
NIST SP 800-221 explains risk scenarios and the fields of a notional risk register. Read the relevant part of Section 3.2.5 before examining the example below.
[PDF] NIST Special Publication NIST SP 800-221
Read NIST's discussion to see how a scenario becomes a trackable risk, with an assessment, response, owner, and status.
In Section 3.2.5, “Risk Register” (pp. 26–28), read risk scenarios. Then use the description of Figure 5 and Table 4 to read register fields. On p. 28, still within Section 3.2.5, read the detail record; stop before Section 3.3. Focus on which information belongs in a concise register and which could be kept in a linked detail record.
NIST's template is adaptable. For a small engagement, a workable entry needs an ID, domain, cause-and-effect scenario, likelihood and impact, owner, planned response, status, and reassessment point. Add a trigger and an immediate action because this register must help people make decisions during the exercise, not only describe concerns beforehand.
Use a consistent, modest rating scale. In the example below, likelihood is unlikely, possible, or likely; impact is minor, moderate, or severe. “Severe” covers consequences such as unauthorized access to exercise material, disclosure of real records, or an inability to distinguish exercise activity from a genuine incident. For illustration, possible plus severe is high priority, while possible plus moderate or unlikely plus severe is moderate priority. These are planning judgments, not measured probabilities or a NIST-mandated formula. Record why you chose them and change them when evidence changes.
A planned safeguard does not lower a risk merely because it appears in a document. Keep the current assessment separate from the anticipated residual assessment—the risk expected after the safeguard has been implemented and verified.
Apply the register to the four OPSEC domains
The TIBER-EU test-plan guidance supplies engagement-specific context for this work. It discusses secure communications and approvals, sharing exercise indicators for deconfliction, securing team infrastructure, and handling operational records. Its procedures are guidance to adapt within an engagement's own governance, not permission to expand this exercise's scope.
TIBER-EU RED Team Test Plan Guidance
Read the European Central Bank's guidance for the safeguards and coordination a red-team plan should account for. Compare its requirements with the narrower hypothetical exercise used here.
On p. 6, read Sections 3.3.1, “Code name,” and 3.3.2, “Communication channels,” from codename and channels. On p. 7, read Section 3.4, “Risk management,” from deconfliction and infrastructure. Continue in the same section from records and cleanup. Pay particular attention to who must receive exercise identifiers, how approvals are preserved, and what happens to sensitive artifacts after delivery.
Consider what each domain protects in the finance-workflow exercise:
Identity covers both the supplied test credential and the ability to attribute actions to approved operators. If everyone uses one untracked credential, a suspicious action may be impossible to assign to a person—or distinguish from misuse. The solution cannot simply be “create more accounts”: account changes are prohibited in this scenario. Instead, use individually attributable operator access where it already exists and is approved, keep a protected assignment record, and agree with the control team how use of the supplied test account will be logged.
Infrastructure covers workstations, hosted services, and their administrative access. Even a short exercise needs to know whether an unauthorized party could reach its management interfaces or operational data. Record infrastructure identifiers through the agreed control-team channel so exercise activity can be deconflicted from a genuine attack. This disclosure to the control team is intentional; exposing the same details publicly is not.
Communications covers decisions as well as messages. A verbal “go ahead” that cannot later be verified creates a different risk from a leaked status update, but both may lead to unauthorized activity. Agree on a secure primary channel, an authenticated fallback, the people permitted to approve a change, and a durable record of approvals. A codename can reduce casual disclosure; it does not replace secure channels or access controls.
Evidence handling begins before collection. Here, success requires observing a seeded marker, not copying real finance records. A screenshot can still capture unrelated personal or business information. Plan to minimize what is captured, restrict access to retained material, preserve the evidence needed to support findings, and follow the agreed retention and deletion process. If real data appears unexpectedly, do not silently erase the event: stop further collection and use the escalation path to agree on containment and disposition.
A worked OPSEC risk register
The following is a pre-operation example, not a claim that these weaknesses have been found. Every row is conditional. Its “current” ratings assume the relevant safeguard has not yet been verified, so each owner must replace that assumption with evidence before the exercise starts.
| ID and domain | Cause-and-effect risk scenario | Current likelihood / impact; priority | Risk owner |
|---|---|---|---|
| RI-01 · Identity | If use of the supplied test credential cannot be tied to an approved operator and time, unexpected activity could be misattributed or go unresolved. | Possible / moderate; moderate | Red-team lead |
| RI-02 · Infrastructure | If an exercise management interface is accessible to unauthorized parties, an outsider could obtain operational records or interfere with the test. | Possible / severe; high | Infrastructure custodian |
| RI-03 · Communications | If approvals or urgent notices use an unverified channel, a team member could act on an unauthenticated instruction or continue without a valid decision. | Possible / severe; high | Control-team liaison |
| RI-04 · Evidence | If a record containing real finance data is captured and stored outside the approved evidence process, sensitive information could be disclosed or retained improperly. | Possible / severe; high | Evidence custodian |
The scenario column makes each row testable. RI-02 is not a claim that an interface is currently exposed; it identifies what the infrastructure custodian must establish. RI-04 describes both an unwanted collection event and the condition that could make its consequences worse. If inspection shows an interface cannot be reached by unauthorized parties, or capture is technically limited to the marker, revise the relevant assessment rather than leaving a stale “possible” rating in place.
A second, linked view keeps the response operational without making the scenario table difficult to read:
| ID | Planned response and evidence of completion | Trigger and immediate action | Anticipated residual risk; status |
|---|---|---|---|
| RI-01 | Record approved operators and test-account assignment periods; confirm activity records can be reconciled without creating prohibited accounts. | Unexplained credential use: pause use of that credential and notify the agreed control contact. | Unlikely / moderate; pending verification |
| RI-02 | Restrict administrative access and check that only approved operators can reach it; provide exercise infrastructure identifiers to the control team through the agreed channel. | Unexpected access or loss of control: stop using affected infrastructure and escalate for deconfliction. | Unlikely / severe; pending verification |
| RI-03 | Confirm the secure primary and fallback channels, approvers, and a retained approval record with the control team. | Channel failure or conflicting instruction: do not advance to the next action until authority is confirmed. | Unlikely / severe; pending verification |
| RI-04 | Limit capture to the seeded marker; restrict evidence access and document the approved retention process. Check a sample capture for unrelated data. | Real records appear: stop collection, protect the material already captured, and escalate its handling. | Unlikely / severe; pending verification |
The residual entries are targets, not achieved results. Even if RI-04's controls make accidental capture unlikely, its impact remains severe if it occurs. “Pending verification” therefore matters as much as the rating. A high-priority row that remains unverified at the readiness review is a reason to defer the affected activity, not to relabel it low risk.
Keep detailed configuration, contact details, and sensitive evidence locations in a restricted detail record, not in a broadly shared summary register. The shared register can identify an owner and refer to that protected record. This follows the distinction NIST makes between a concise register and a more granular risk detail record.
Keep the register useful as the plan changes
Review the register at three natural decision points:
- Before execution: confirm each planned safeguard and record the evidence for changing a row from “pending” to “verified.” Confirm that the control team has what it needs to distinguish exercise activity from a real incident.
- When conditions change: reassess the affected row if an operator, infrastructure component, channel, or evidence requirement changes. Add a new row if the change creates a different cause-and-effect scenario.
- After an incident or at closeout: record what occurred, who authorized the response, and whether retained evidence and sensitive artifacts were handled according to the agreed process.
An incident does not always mean the same response. Defender detection of permitted activity may be useful exercise evidence. An unknown party accessing team infrastructure is a security event requiring escalation. A communication failure may require a pause even though no information has leaked. The register helps distinguish these cases by connecting an observable trigger to a pre-agreed action and an accountable owner.
Conclusion
An OPSEC risk register turns general concern into explicit decisions. For each identity, infrastructure, communications, and evidence risk, describe the condition and consequence, assess it consistently, name an owner, specify a safeguard that can be verified, and state what happens if the risk materializes. Keep planned residual risk separate from risk that has actually been reduced.
You now have the risk inputs needed for the next lesson. There, you will build a phased operation plan with decision points, deconfliction procedures, and contingency actions—using this register to decide when the exercise can proceed, pause, or change course.