Concepts

Encyclopedia series, volumes, and collections.

Controlled cybersecurity terminology.

Application context—business function, data class, user population, environment, exposure, and identity bindings—determines why the same access or vulnerability signal means different things on different software capabilities.

First **Stream B** seed content for the Cybersecurity Encyclopedia. **Collection 001 is not the primary organizing unit** — use Knowledge Series and Editorial Seasons going forward. See editorial/EDITORIAL_MASTER_PLAN.md.

Applications gain security meaning through relationships—to assets, identities, peer applications, and attack paths—forming the ecosystem structure analysts use to scope investigations and explain blast radius.

Volume 1 is the **core analytical reasoning chain** of a security analyst. It teaches how to establish trustworthy evidence, investigate with discipline, prioritize risk with context, and use attack paths as decision support.

SER-010 synthesis and Volume 3 capstone: applications and services are decision-support context—business function, relationships, service mapping, and uncertainty—that closes the entity arc with assets and identity.

Complete educational series on evidence-based security—from definition through quality, lifecycle, correlation, validation, and audit. SentriScope appears only via authority KID references.

Applications influence investigation scope, risk rank, identity containment, attack paths, and intelligence application—connecting Volume 3 entity context to the analytical and intelligence workflows from Volumes 1–2.

Complete educational series on conducting security investigations using evidence—from lifecycle and hypothesis through quality, bias, decisions, documentation, and handoff.

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

**Risk intelligence** for analysts—how to prioritize findings using context, evidence, and threat inputs. **Not** enterprise GRC, compliance frameworks, or generic risk management.

Asset context—ownership, criticality, exposure, identity linkage, applications, and business function—determines why the same technical finding means different things on different resources.

**Attack paths as decision support**—how organizations interpret structural reachability models to prioritize action, scope investigation, and communicate impact. **Not** graph algorithms, path calculation mechanics, or product feature tours.

Volume 2 teaches how organizations turn **intelligence** — external and internal — into **actionable security decisions**. It continues the Volume 1 decision-support thread: intelligence informs judgment; it does not replace it.

Asset ownership in security decisions means accountable operational context—who can validate state, authorize change, and explain business function—not CMDB steward fields or IAM provisioning.

**Threat intelligence as decision support**—how organizations interpret external threat knowledge to prioritize action, scope investigation, and communicate urgency. **Not** feed ingestion mechanics, TI platform tours, or MITRE encyclopedias.

Assets gain security meaning through relationships—to other assets, identities, applications, and exposures—forming the structure analysts use to reason about attack paths and blast radius.

**Operational intelligence as decision support**—how organizations use **internal** operational knowledge to prioritize attention, investigations, and risk actions. **Not** SOC runbooks, SIEM query guides, or tool configuration.

**Security intelligence as decision support**—how organizations **integrate** external threat knowledge and internal operational knowledge into a **unified security decision process**. **Not** a third feed catalog, unified vendor platform tour, or autonomous SOC narrative.

Volume 3 shifts the encyclopedia from **how analysts think** (Volumes 1–2) to **what analysts think about**.

Business context—asset criticality, data sensitivity, regulatory exposure, and operational dependency—determines why one asset outranks another despite similar technical severity.

**Security assets as decision support**—how organizations use asset **context** (criticality, relationships, ownership, exposure, uncertainty) to prioritize, investigate, and communicate. **Not** CMDB administration, discovery tool configuration, or inventory completeness metrics.

Business function—the organizational purpose an application serves—determines why identical technical findings demand different prioritization, escalation, and communication than inventory labels alone can explain.

**Security identities as decision support**—how organizations use identity **context** (privilege, relationships, access, uncertainty) to prioritize, investigate, and communicate. **Not** IAM product configuration, identity governance policy encyclopedia, or directory administration workflows.

**Security applications and services as decision support**—how organizations use application **context** (business function, relationships, data class, exposure, uncertainty) to prioritize, investigate, and communicate. **Not** SDLC policy administration, application security testing tool tours, or service catalog deployment …

Volume 4 — Security Operations

Corrects durable misconceptions: applications are decision context not catalog rows, services are enrichment entities not ops noise, and application inventory completeness is not security maturity.

**Exposure as decision support**—how organizations use exposure **context**, reachability, relationships, and intelligence to prioritize reduction, scope investigation, and communicate risk. **Not** vulnerability management administration, scanner configuration, or vendor product tours.

Corrects durable misconceptions: assets are decision context not inventory rows, CMDB completeness is not security maturity, and exposure counts alone do not define risk.

**Correlation as decision support**—how organizations link isolated observations into **canonical understanding** with relationship context, and use that understanding in prioritization, investigation, risk, and communication. **Not** entity resolution algorithms, graph database administration, or platform implementation documentation.

Corrects durable misconceptions: identities are decision context not directory rows, IAM hygiene is not security maturity, and authentication alerts alone do not define blast radius.

**Security operations as continuous decision support**—how teams apply exposure reasoning, correlated understanding, and Security Intelligence to recurring operational choices. **Not** SOC runbooks, playbooks, vendor tooling, or SIEM configuration.

Corrects durable misconceptions: operations is continuous decision support not alert closure, SIEM administration, or incident response alone.

Stakeholder communication translates integrated intelligence into decisions, confidence levels, and residual risk—not raw feeds, IoC lists, or technical jargon.

Practitioners should prioritize findings by security context—exposure, asset role, identity privilege, and threat relevance—not generic severity scores alone such as CVSS in isolation.

Security relationships supply decision context—reachability, privilege, dependency, and path structure—so correlated observations change rank and scope based on how entities connect, not in isolation.

Security decisions never pause—exposure, intelligence, and context change constantly, so operational judgment repeats rather than stopping when incidents close.

Mature programs convert alerts into decisions through normalization, context enrichment, investigation, and governed approval—not through automatic closure or score sorting alone.

Analyst fatigue drops when teams share defined terms, repeatable investigation patterns, explainable prioritization, and preserved context—not when they merely add more detection tools.

Identity context—privilege, role, access scope, and lifecycle state—determines why the same authentication signal means different things for different actors.

Privilege determines how far a compromised identity can reach; blast radius translates that reach into explainable scope for prioritization, investigation, and containment.

Identities gain security meaning through relationships—to assets, applications, sessions, and attack paths—forming the structure analysts use to scope investigations and containment.

A security identity is the analyst's decision object for who can act; an account record is the operational artifact in a directory or cloud IAM—related but not interchangeable.

Operational coordination aligns judgment across shifts and functions—handing off rationale, not tickets alone—when exposure, identity, and intelligence context span team boundaries.

Operational decision cycles repeat observe-reason-decide-act-learn—applying Security Intelligence to queues that refill, not a linear incident timeline.

Operational prioritization orders daily work using exposure, intelligence, and capacity—not frozen severity scores or tool defaults alone.

Risk acceptance is a documented decision to defer or tolerate residual risk—with explicit owner, rationale, evidence basis, and review date—not silent neglect or ticket closure alone.

Risk communication translates explainable prioritization into stakeholder language—impact, context, confidence, and recommended action—without jargon dumps or raw severity counts.

Risk context is the environmental and operational information that determines whether a finding matters in your organization—exposure, asset role, identity, controls, and threat relevance.

Risk prioritization in practice combines validated evidence, context layers, and threat signals into an explainable ranked queue—not severity sorting or tool defaults alone.

SER-008 synthesis: security assets are decision-support context—identity, criticality, relationships, ownership, and exposure—that makes prioritization and investigation explainable, not inventory administration.

SER-009 synthesis: security identities are decision-support context—context, privilege, relationships, access paths, and uncertainty—that makes prioritization, investigation, and containment explainable, not IAM administration.

Volume 4 capstone: SER-011 exposure, SER-012 correlation, and SER-013 continuous operations together operationalize Foundation Edition as daily decision support—not SOC tooling or runbooks.

A security service is the technical delivery unit analysts enrich and map to applications—not a deployment artifact alone—because logs, findings, and paths often attach to services before business capability is resolved.

A security application is the decision object for what business capability can be harmed or abused—not a repo, deployment unit, or catalog row alone, but the anchor that connects findings to organizational impact.

A security asset is the entity every finding, exposure, investigation, and risk decision ultimately attaches to—not an inventory row, but the anchor that makes prioritization meaningful.

Security context combines asset role, identity privilege, exposure, business impact, controls, and threat relevance—the lens that turns raw findings into actionable priority.

A security identity is the actor every authentication event, access decision, investigation pivot, and attack-path step can attach to—not a directory row alone, but the anchor that explains who or what could cause harm.

Unknown applications are decision uncertainty—not merely missing catalog rows—because shadow SaaS, unattributed APIs, and unresolved business linkages weaken prioritization, investigation scope, and containment confidence.

Unknown assets are decision uncertainty—not merely missing inventory rows—because unattributed findings, shadow resources, and unresolved entities weaken prioritization, investigation scope, and path confidence.

Unknown identities are decision uncertainty—not merely missing directory rows—because stale, orphaned, and unattributed service accounts weaken prioritization, investigation scope, and containment confidence.

Risk is not static—exposure, threat activity, asset role, control changes, and evidence freshness all require re-prioritization and review of accepted residual risk.

Daily operational judgment has limits—escalate to investigation depth, declared incident response, or risk acceptance when uncertainty, stakes, or evidence gaps exceed what cycles can resolve.

Operational decisions change when internal context—asset state, control effectiveness, queue pressure, identity posture—shifts; OI makes that context explicit for prioritization.

Two identical CVE records can warrant opposite remediation urgency because risk depends on asset exposure, identity pathways, controls, and business context—not the CVE identifier alone.

High finding volume comes from overlapping scanners, broad detection rules, missing deduplication, and lack of contextual prioritization—not necessarily from worsening security posture.

Severity scores such as CVSS describe isolated finding attributes—they do not encode exposure, asset criticality, threat exploitation, or evidence state required for operational risk prioritization.

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.