Glossary

Asset criticality is the business and security significance of an asset that changes how findings, vulnerabilities, and incidents are prioritized—not merely inventory classification.

Attack surface is the aggregate of reachable, exposure-relevant entry points—interfaces, services, identities, and paths—an organization must reason about when prioritizing reduction.

Blast radius is the scope of potential impact if a compromise succeeds—systems, users, data, or services affected downstream of an entry point or path step.

Canonical understanding is shared, explainable security meaning built from normalized observations and relationships—enabling correlation and decisions without relying on any single tool's view.

Chain of custody is the chronological record of who collected, handled, transferred, and stored security evidence—supporting integrity and legal defensibility.

Controlled vocabulary for the Cybersecurity Encyclopedia. Glossary entries are **term authorities** (is_authority: true). Future documents reference **KIDs**, not ad hoc definitions.

Decision support provides structured context—such as attack paths or risk analysis—to help practitioners choose actions; it informs judgment rather than replacing it.

Disposition is the recorded handling outcome for an alert or finding—distinct from the investigation outcome or final security conclusion.

A security application is the analyst's decision object for business capability at risk; a security service is the exposed technical unit that delivers it—related but not interchangeable when scoping investigations.

Applications become decision support when context—business function, relationships, and provenance—helps explain why findings rank differently and where attention should go across services and integrations.

No—a larger asset inventory does not imply stronger security; decision quality depends on context, criticality, and how assets inform prioritization.

Explain risk to executives with business impact, recommended action, confidence level, and top prioritized items—avoid raw CVE counts and severity-only dashboards.

Lead with the decision required, integrated rationale, confidence level, evidence status, and residual risk—not raw feeds or IoC lists.

Analysts evaluate alerts by scoping context, validating signals, converting validated observations to evidence, and deciding with explicit confidence—not by severity label alone.

Prioritize vulnerabilities by enriching findings with risk context, validating evidence, combining threat signals, and documenting explainable rank rationale—not CVSS sort alone.

An account is often a technical credential or login record; a security identity is the decision lens that combines accounts, roles, and context so analysts can judge access and blast radius.

Unknown applications exist in activity or integration sources but lack enough context for confident security decisions—uncertainty about business function and ownership, not simply a missing catalog entry.

Unknown assets exist in the environment but lack enough context for confident prioritization—uncertainty about role and impact, not simply a missing inventory record.

Unknown identities appear in logs or directories but lack enough context for confident prioritization—uncertainty about role, ownership, or privilege, not simply an unmapped username.

A security application is the software capability that delivers a business function and anchors findings, access, and investigations—not a catalog row or deployment name alone.

A security asset is a resource relevant to protection and investigation—servers, endpoints, cloud workloads, and similar—enriched with context that changes how findings are interpreted.

A security identity is a user or service account that anchors access, activity, and investigations—enriched with context about privilege and relationships that changes how findings are interpreted.

Canonical understanding is the shared, explainable security picture built from normalized observations and correlated stories—what teams defend in daily decisions.

Operational feedback is structured learning from daily security decisions—outcomes and rank changes—that improves future prioritization without replacing investigation or audit.

Risk context is the environmental information—exposure, asset role, identity, controls, threat, and business impact—that determines whether a finding creates meaningful risk in your organization.

Security context is the environmental and relational information—asset role, exposure, identity privilege, business impact, threat relevance—that determines whether a finding actually matters.

Assets become decision support when context—criticality, relationships, and provenance—helps explain why findings rank differently and where attention should go.

Business function—the organizational purpose an application serves—determines escalation paths, stakeholder communication, and why identical technical findings demand different security responses.

CVSS describes vulnerability attributes in isolation—it does not include your exposure, asset criticality, controls, or threat activity required for operational risk prioritization.

Operational prioritization changes when context, intelligence, exposure, or capacity shifts—rank is a living judgment, not a fixed severity sort.

Identities are central because most attacks pivot through credentials and access—identity context determines blast radius, investigation scope, and explainable prioritization across assets and applications.

Security operations is continuous because exposure, intelligence, and organizational context change constantly—decisions must repeat, not stop after incidents close.

The same CVE ranks differently because asset context—criticality, exposure, dependencies, and environment—changes the decision, not because severity scores are wrong.

A security investigation hypothesis is an explicit, testable statement of what may be true— including what evidence would confirm or refute it.

Identity privilege is the security significance of elevated access an identity holds—admin rights, broad roles, or sensitive scopes—that amplifies blast radius when that identity is compromised or misused.

Intelligence confidence expresses how much trust practitioners should place in a threat assessment—based on source quality, corroboration, freshness, and relevance—not on classification alone.

Operational context is the live internal state—assets, controls, coverage, queue pressure—that shapes how operational intelligence ranks attention at a point in time.

An operational decision is a recurring security judgment—prioritize, defer, escalate, or coordinate—made under uncertainty using Security Intelligence, not a one-time incident command or tool default.

Operational feedback is structured learning from daily security decisions—outcomes, deferrals, and rank changes—that improves future prioritization and intelligence use without replacing investigation or audit.

An operational signal is a normalized internal security observation—alert, finding, or state change—that feeds operational intelligence; it is input, not prioritized intelligence itself.

A security relationship is a decision-relevant link between entities—asset, identity, application, exposure, or path—that changes how observations should be interpreted, prioritized, or investigated.

Residual risk is the remaining exposure after remediation, compensating controls, or explicit risk acceptance—requiring monitoring because it changes over time.

A security application is the software or workload boundary analysts use to reason about business function, data, and risk in security decisions—not a repo, deployment unit, or catalog row alone.

A security service is an exposed capability or API endpoint that carries security significance distinct from the hosting application—often the technical unit logs and scanners name, enriched and mapped to application scope.

A threat indicator is an observable artifact associated with threat activity—such as a hash, domain, or IP—used as decision-support input after contextual validation, not as standalone proof of compromise.

An unknown asset exists in the environment but lacks sufficient context for confident security decisions—uncertainty about significance, not merely a missing CMDB row.

An unknown identity exists in activity or directory sources but lacks sufficient context for confident security decisions—uncertainty about role, ownership, or privilege, not merely an unmapped account name.