What Is Operational Information Security? (Threat Models)

Operational information security is the day-to-day work of protecting information, systems, and access paths from realistic threats. A threat model makes that work specific: it identifies what matters, who could attack it, how an attack might work, and which safeguards reduce the risk. Teams then test those safeguards, record what remains, and update the model as systems change.

Treat threat modeling as an investment in sound security decisions. It helps you spend time and money on risks that fit your systems, rather than assuming a firewall or multifactor authentication (MFA) solves every problem. I use it to connect business needs to concrete attack paths, control owners, and tests. The result should guide daily operations, not sit untouched in a project folder.

Planning: Define Assets, Scope, and Threat Assumptions

Planning sets the boundaries for a useful risk assessment. It names the system, its owner, the information and services that matter, and the assumptions behind the analysis. A clear scope keeps the work focused while making exclusions visible, so teams do not mistake an unexamined dependency for a safe one.

NIST SP 800-30 Rev. 1 organizes risk assessment into four steps: prepare, conduct, communicate results, and maintain the assessment. Start by naming the system boundary and business owner. Include the people, services, devices, data stores, and suppliers that support the system or can affect its security.

Inventory assets by their purpose and impact, not just by product name. Consider sensitive records, credentials, critical business processes, backups, and the systems needed to restore service. Record assumptions, such as which users have access or which supplier services are in scope. Mark uncertain details for follow-up rather than treating them as facts.

A threat model should answer four practical prompts, reflected in OWASP’s threat-modeling guidance:

• What are we building or protecting?
• What can go wrong?
• What will we do about it?
• Did we do a good job?

Those prompts apply to a new system and to an existing one. For example, an account portal may depend on a cloud identity provider, a support desk, and a recovery email service. If the assessment covers only the portal, it may miss ways an attacker could take over an account through recovery.

NIST SP 800-37 Rev. 2 places risk work within a wider Risk Management Framework (RMF). Its seven steps are prepare, categorize, select, implement, assess, authorize, and monitor. The RMF helps connect a threat assessment to system controls and ongoing oversight; it does not replace analysis of specific attack paths.

Access and Clearances: Map Trust Boundaries and Data Flows

A trust boundary is a point where information or control passes between areas with different levels of trust. Mapping boundaries and data flows shows where an attacker, error, or weak control could affect a system. Include people and recovery routes as well as servers and network links.

Draw the system in a way that lets another person follow the important flows. Show users, applications, data stores, external services, administrative interfaces, and connections between them. Mark where sensitive data moves and where identities gain privileges. The diagram can be simple, but it must reflect the system as used, including support and recovery paths.

For each connection, ask what crosses the boundary and what checks it. A login flow may involve a user device, an identity service, an application, and a session token. An administrator may use a separate management interface. A supplier may hold data or have remote access. Capture these routes, even if they sit outside the team’s direct control.

Account recovery deserves special attention. A strong MFA check at login may not protect an easier reset process. Include password resets, recovery email and phone numbers, help-desk overrides, API tokens, and privileged break-glass accounts. For each route, identify who can use it, what proof they must provide, what gets logged, and how access is removed afterward.

Use the map to find hidden dependencies. A vendor connection, backup service, or shared administrator account can become part of an attack path. A network perimeter or internal firewall may reduce exposure, but neither proves that trusted users, suppliers, recovery workflows, or privileged accounts are safe.

Execution: Analyze Attack Paths and Apply Controls

Attack-path analysis links a possible threat to an asset, a route into the system, and an outcome. It helps teams judge likelihood and impact in context, then assign safeguards and owners. Use a method such as STRIDE to prompt questions, not as a substitute for evidence about the system.

First, describe plausible actors and their capabilities. They might include an external attacker, a malicious insider, a compromised supplier, or an ordinary user who makes a mistake. Avoid assuming every actor has the same access or skill. Then trace how that actor could reach an asset and what barriers stand in the way.

STRIDE provides six categories for checking how a system could fail:

• Spoofing: Could someone pretend to be a user, service, or device?
• Tampering: Could data or system settings be changed without approval?
• Repudiation: Could a person deny an action because records are missing or weak?
• Information disclosure: Could someone view information they should not see?
• Denial of service: Could a system or service be made unavailable?
• Elevation of privilege: Could someone gain more access than they should have?

For each plausible path, estimate likelihood and impact using a scale your organization defines. Likelihood should reflect exposure, attacker capability, existing safeguards, and available evidence. Impact should reflect harm to people, operations, legal duties, finances, or trust. There is no universal numeric cutoff that turns a score into an objective fact.

A simple local scale can support discussion. For example, a team might rate likelihood and impact from 1 to 5, then use their product to sort work. That score is a prioritization aid, not a probability or a NIST-mandated formula. Define what each rating means, document uncertainty, and set decision thresholds with the people authorized to accept risk.

Example path	Threat prompt	Possible treatment	Evidence to check
Account recovery through support	Could an attacker impersonate a user?	Verify identity, limit overrides, alert on resets	Sample reset records and test the workflow
Supplier access to business data	Could a supplier account expose records?	Restrict access, review accounts, set notice duties	Access list, contract terms, review record
Shared administrator credential	Could one compromise affect many systems?	Use named accounts and limit privilege	Account inventory and access logs

These are example scenarios, not claims about a particular incident. In the first, a team would trace how a reset request is approved and whether the route bypasses MFA. In the second, it would identify what the supplier can reach and how access is removed. In the third, it would check whether actions can be tied to a person and whether the credential is still needed.

MITRE ATT&CK can help describe adversary goals and methods. Tactics describe what an adversary is trying to achieve; techniques describe methods used to pursue that goal. Map only techniques that fit the system and scenario. A technique match does not establish that an attack is likely; likelihood still depends on exposure, controls, and context.

Choose treatments that address the path, then name an owner and a way to verify each one. Controls may prevent an attack, detect it, limit its impact, or support recovery. Record residual risk, meaning the risk that remains after controls are applied. The proper authority should decide whether that risk is acceptable.

Verification: Test Mitigations and Track Residual Risk

Verification checks whether safeguards work as intended and whether the threat model still reflects the system. A control written in a policy is not proof that it works in practice. Test important paths, record the results, assign fixes, and reassess when system design, access, or threats change.

Choose tests that match the risk. For account recovery, walk through an approved reset test and check identity checks, alerts, and records. For privileged access, review the account list and confirm that access matches current duties. For a supplier connection, check its scope and verify that removal procedures exist. Use authorized testing and avoid disrupting live services.

Record results in a form another team can review. For each threat, capture:

• The affected asset and attack path.
• The likelihood and impact ratings, with reasons.
• The safeguards in place and evidence checked.
• The remaining risk, control owner, and next review date.
• The person or role authorized to accept remaining risk.

Communicate findings to people who can act on them. Leaders may need a short view of major risks and decisions, while system owners need the path details and test steps. Keep the underlying assumptions and evidence available so a later reviewer can tell what changed and why.

Maintain the assessment after material changes, such as a new external service, altered access, a new recovery process, or a change in threat conditions. NIST SP 800-30 calls for maintaining the assessment, while the RMF’s monitor step supports ongoing oversight. A threat model is therefore a working record, not a one-time checklist.

The practical measure of success is not the number of threats listed. It is whether the team can explain its important attack paths, show which safeguards address them, and state who owns any remaining risk. Review the model when the system or its access routes change.

FAQ: Operational Information Security and Threat Models

These answers clarify how operational security and threat modeling fit together. They focus on practical assessment decisions: what to map, which methods to use, how to judge risk, and when to revisit the work. Use them as a starting point, then follow your organization’s policies and risk-acceptance rules.

What does operational information security mean?
It is the ongoing work of protecting information and systems through risk assessment, controls, monitoring, and response.

What is a threat model?
It is a structured description of important assets, likely threats, attack paths, safeguards, and remaining risks.

Is a threat model the same as a risk assessment?
Not exactly. A threat model helps describe threats and paths. A risk assessment also evaluates likelihood and impact and communicates results.

Which standard guides a risk assessment?
NIST SP 800-30 Rev. 1 describes preparation, assessment, communication of results, and maintenance.

What is the NIST RMF?
NIST SP 800-37 Rev. 2 describes seven steps for managing system risk: prepare, categorize, select, implement, assess, authorize, and monitor.

Should every STRIDE category apply to every system?
No. Use the six categories as prompts, then record only threats that fit the system and its use.

Does an ATT&CK technique match prove high risk?
No. A match describes a relevant method, not its likelihood. Assess exposure, capability, controls, and impact.

Can MFA make account recovery safe?
Not by itself. Model resets, help-desk overrides, recovery contacts, tokens, and break-glass accounts as separate access paths.

How often should a threat model be updated?
Review it after material changes to architecture, access, dependencies, recovery, or threat conditions, and follow your organization’s review schedule.

How do I know whether a risk is acceptable?
Use defined rating criteria and have the authorized risk owner make and document the decision.

(This article was written by one of our staff writers, Garrett Vance. Visit our Meet the Team page.)