Making the Case for Cybersecurity
As with attack characterization, the key to scalable automation is semantic structure. By aligning system-specific vulnerabilities with shared vocabularies and modeling them as part of a formal risk argument, organizations can move from patchwork detection to predictive, contextualized defense, at the speed and scale demanded by modern cyber environments.
6 SECURITY ARGUMENT AS THE ORCHESTRATOR IN RISK-CENTRIC DEVSECOPS
Having extended the DevSecOps pipelines to continuously inference risk subclaims, how can we guarantee that a change in the mission model or a threat intelligence update will result in delivering the right risk information to each stakeholder?
6.1 ARGUMENT-DRIVEN AUTOMATION OF CYBERSECURITY PIPELINES
The orchestration follows the structure of risk claim, outlined in Figure 6-1. It begins with collecting foundational mission, system facts— defined in SysML and enriched through the SPECTRA profile. From there, attacks are enumerated and tailored to the system model. Independently, assets are enumerated and tailored to the system, then undesired events are enumerated. Then risk clusters are assembled.
Security controls( e. g. from NIST 800-53) are added as subclaims and evaluated in terms of their ability to mitigate relevant attack paths. Vulnerability conditions are enumerated as profiles of attacks to proactively identify imbalances between feasible attacks and available defenses. The“ wave” of inferences, triggered by an incremental change in the system model or the threat environment of the deployed system, culminates in updated risk measurements and recalculating risk distributions.
What distinguishes this framework is that each step is driven by the argument itself. When the argument asserts that a particular interface exposes an asset, it triggers inference logic to build data objects, tailor generic knowledge, if necessary, tailor the associated subclaims and update the argument’ s state. The assurance case becomes an active reasoning loop— continuously acquiring, interpreting, and integrating knowledge.
6.2 EXAMPLE: ASSET CLAIMS AND PIPELINE ORCHESTRATION
In a structured risk argument, assets are not just data objects— they are subclaims at the base of the risk claim structure. As depicted in Figure 6-1, assets are represented as tuples of the form ⟨ asset category, impactful element ⟩— for example, ⟨ information asset, datatype(" 07 ", " current position ")⟩.
Each identified asset Ai is first represented by a basic existence claim:“ Asset Ai exists within the system of interest.” This claim is further supported by a traceability claim:“ Asset Ai is traceably derived from the system or mission model.” This ensures that the asset is not arbitrarily declared but is anchored in engineering artifacts, providing defensibility and model consistency. However, for this to support a valid risk model, a second layer of justification is needed as a viability
Journal of Innovation 51