Nasdanika Models

An Ecore micro-model of running a security program: incidents, vulnerabilities, awareness, continuity, third parties, and metrics - the operational record a CISO owns.

It is an extension, not a framework. Strategy and compliance - frameworks, requirements, policies, controls, control applications, risks, evidence, assessments, findings, waivers - come from the governance model. What can go wrong - assets, flows, trust boundaries, threats, actors, weaknesses, taxonomies - comes from the threat model. What things are comes from C4 and architecture. This model adds only what happens while the program runs: about ten classes and six enumerations.

Position in the tower

The aspect spine runs nxcore < role < iam < seal < lifecycle < decision analysis < decision binding < governance < work < requirements < architecture < threat, with accounting as a spine aspect and C4 as a thin floor above architecture. CISO sits on the C4 floor, and it is a clear illustration of why the tower is arranged the way it is: a dozen floors of inherited machinery, and a metamodel small enough to read in one sitting.

  • SecurityProgram is itself governed. It extends the governance model’s Governed, so the program that audits everything else carries risks, applied controls, and waivers of its own. The CISO function is inside the scope of the CISO function - which is what a maturity assessment, a board sub-committee, and an ISO 27001 certification audit actually examine.
  • Incident closes the threat modeling loop. realizes points at Threats and affected at Assets, which are architecture elements, which are C4 systems, containers, and components. The blast radius of an incident is a graph traversal, not a war-room whiteboard.
  • Vulnerability is the instance of a Weakness in an Asset. Three concepts most tools collapse into one “finding” stay distinct: the class of flaw (CWE), the instance in a concrete system, and the attack that exploits it.
  • Response is work; command is a role; status is a lifecycle. Containment tasks are work items on the affected elements, the incident commander is a role engagement with a start and an end, and the DETECTED -> CLOSED progression records dated sojourns through lifecycle stages rather than overwriting one field. None of that is redeclared here.
  • Need-to-know and non-repudiation are floors, not features. An incident under legal privilege restricts its timeline through IAM statements; forensic entries and post-incident reviews are signed and sealed through the seal model. An evidentiary record whose confidentiality and integrity are properties of the substrate is the difference between a model and a wiki page.
  • Treatment choices are analyzed and bound. “Patch, compensate, or accept” is an alternative evaluated in decision analysis and committed in decision binding, so a Waiver cites the record of why, not a name and a date.
  • Cost is a ledger. Accounting commodities are anything countable - dollars, hours, seats - so control spend, incident cost, and awareness budget roll up along containment instead of living in a finance spreadsheet nobody cross-references.

Competitive landscape

Security operations is the most heavily tooled domain in the enterprise, and the most thoroughly fragmented. Several camps, none of which occupies this position:

SIEM, SOAR, and incident response platforms. Splunk, Microsoft Sentinel, Google SecOps, XSOAR, Torq, Tines, and the on-call tools next to them - PagerDuty, incident.io, Jira Service Management. Superb at detection, orchestration, and the first four hours. The record they leave behind is a ticket with a free-text summary: no typed link to the threat that was modeled two years earlier, the control that was supposed to prevent it, or the architecture element it happened in. The post-incident review is a document, and the document starts rotting at export.

Vulnerability management and exposure platforms. Tenable, Qualys, Rapid7, Wiz, Orca, Snyk, DefectDojo, and the CTEM/ASPM aggregators layered on top. They produce findings at a volume no human reads, against an asset inventory that is theirs, discovered by their scanners, and reconciled with the architecture by hand. Prioritization signals - CVSS, EPSS, KEV, SSVC - are computed inside the product. Here knownExploited and due are model fields, the SLA is a rule over them, and “which of these touches a container in the payments system” is a query rather than a professional services engagement.

GRC and integrated risk management suites. Archer, ServiceNow IRM and SecOps, LogicGate, MetricStream, OneTrust, and the compliance-automation cohort - Vanta, Drata, Hyperproof, Secureframe. They do the workflow well, and their framework crosswalks are a product feature you rent. The data model is proprietary and the register is the silo: incidents in one system, the risk register in another, the CMDB in a third, and the mapping between them maintained by a person whose job title should not have to exist.

Third-party risk platforms. Prevalent, Whistic, Panorays, and the ratings services - SecurityScorecard, Bitsight, UpGuard - plus the SIG and CAIQ questionnaire libraries. An entire product category built on the premise that vendor risk is a separate discipline with its own register. ThirdParty extends Governed: a questionnaire response is Evidence on a ControlApplication, a vendor review is an Assessment, an exception is a Waiver. Third-party risk is governance pointed at an external subject, and the model needs four fields of its own to say so.

Resilience and continuity tooling. Fusion Risk Management, Castellan, Archer Business Continuity, and the BIA spreadsheets underneath most of them - now with DORA and operational resilience regimes driving a compliance rush. ContinuityPlan states RTO and RPO over Assets that are the real architecture elements, and Exercise points at the governance Assessment that judged it. A plan whose scope is a list of system names in a Word table cannot be checked against reality; one whose scope is a reference can.

Security awareness vendors. KnowBe4, Proofpoint, Hoxhunt, Ninjio, SANS Security Awareness, and every LMS with a compliance module. Treated on its own below, because that is where this model has the most to say.

Standards, catalogs, and interchange formats. NIST CSF 2.0 and SP 800-61, ISO/IEC 27001, 27002, 27005 and 27035, ISO 22301, CIS Controls, OCSF, STIX/TAXII, CSAF and VEX, OSCAL, and the reporting regimes - SEC Item 1.05, GDPR Art. 33, NIS2, DORA. Sources and export targets rather than competitors. Frameworks load as Framework/Requirement catalogs in the floor below: adding CSF 2.0 is authoring, not a metamodel change.

And the actual competitor, as everywhere in the tower: an incident log in Confluence, a risk register in Excel, a vendor tracker in a second Excel, a BIA in Word, an awareness completion report exported as PDF, and a board deck assembled by hand the week before the meeting - six artifacts that are already inconsistent with each other on the day they are filed.

What a typed model adds

The incident tells the threat model it was wrong. Incident.realizes is a reference to modeled threats, so an incident closed with an empty realizes is not a data entry omission - it is a finding about the threat modeling program, and a validation rule can say so out loud. Run it the other direction and you get the number no security organization can currently produce: what fraction of incidents did we predict? SecurityMetric makes it a first-class target with a direction and a query behind it.

Post-mortems strengthen the catalog. correctiveActions points at governance Controls and elevates at Risks. The lesson learned lands in the control catalog the compliance program already runs on, instead of in a slide that is never opened again. Next quarter’s audit sees it without anyone remembering to mention it.

Risk acceptance requires a waiver. VulnerabilityStatus.ACCEPTED is not self-service: it references a governance Waiver, which has an owner, a rationale, and an expiry. A status field alone is not risk acceptance, and a model that lets you pretend otherwise is a comfort object.

Metrics are telemetry as code. SecurityMetric stores unit, target, direction, and the URI of the producing query - never the value. Mean time to detect, patch latency against SLA, phish click rate, and control coverage are read from the systems that already know them. Board reporting becomes a generated view over one source, which is why the CISO deck and the audit pack cannot disagree.

Honest defaults, everywhere. Waivers expire. discovered, due, contained, and closed are dates you either have or visibly do not. reportable is a boolean somebody has to decide, before a regulator decides it for them.

Security literacy: awareness as a modeled asset

Every organization runs security awareness, and almost every organization runs it as an annual compliance ritual whose only artifact is a completion percentage. AwarenessCampaign - training, phishing simulation, or communication, with an audience, a window, and outcomes pointing at metrics - sits deliberately in the same container as incidents and vulnerabilities. The human layer is part of the control catalog, and this model treats it that way.

The economics nobody writes down

The interesting thing about awareness is not the content; it is that the alternatives have radically different cost structures, and the choice between them is almost always made without comparing them:

Alternative Money Time Specificity Freshness
Public courses, conferences, certifications High per head Days per head, off the job Generic - teaches phishing, not your SSO flow Ages slowly, revised yearly
Awareness platform subscription (LMS plus phishing simulation) Per seat, recurring ~1 hour per head per year Generic library, localized at best Vendor maintained
Bespoke company course High one-time authoring Days to produce, hours to consume High - names your systems Stale within two quarters
Model-anchored micro-wiki content Near zero marginal - authored alongside the model Minutes, at the point of need Exact - attached to the element in question Moves with the model

The first three rows are what the market sells. The fourth is what the tower makes possible - and the comparison itself is a modeled artifact rather than a hallway argument: criteria (cost per head, time to competence, specificity, decay rate, evidence quality), alternatives, expert judgments, and a computed result in the decision analysis model, committed through decision binding so the awareness budget line traces to the record of why. Spend and hours land in the accounting ledger as commodities, so cost per avoided click is arithmetic rather than rhetoric.

Micro-wikis: depth behind a click

The micro-wikis concept is the synergy that makes the fourth row viable. Every model element anchors its own documentation space; the model generates the site map; the landing page stays short and depth sits behind a click.

Applied to a security program: a Control links to the three-minute video explaining why it exists, a Threat links to the write-up of the attack it describes, a C4 Container links to the runbook for the system it names, a Weakness links to the CWE entry and to the internal page about why this one keeps recurring, and an Incident links to the post-mortem recording in full rather than to a lessonsLearned field that had to be kept short.

Three consequences follow, and they are exactly what generic training cannot buy:

  • Learning is situated. The engineer working on the payments container reads the material attached to that container’s threats and controls - not a module that mentions payments in the abstract. Specificity, the expensive column in the table above, comes from placement rather than from authoring.
  • Audience is a query. Because engagement is typed in the role model, “who is engaged with elements carrying unmitigated threats of this category” is answerable, and a campaign’s audience narrows from everyone, annually to these people, now, about this. AwarenessCampaign.outcomes then measures a population that was chosen for a reason.
  • Content federates like the model. Micro-wikis ship as Maven artifacts alongside the micro-models, so internal pages sit next to the tower’s own documentation and cross-reference it. Third-party material - a vendor course, a conference talk, a CISA advisory - is a link on the element it explains, carrying nxcore provenance and a date, so stale content is detectable rather than merely suspected.

A campaign, in other words, stops being a content purchase and becomes a view: this audience, these elements, this material, these outcome metrics. The vendor library still has a place in it - nobody should author their own explanation of business email compromise - but it is cited from the model rather than substituting for one.

Completion is evidence of capability

The other half of awareness is the record it leaves. Today that record is a row in an LMS export: name, course, date, 100%. In the tower it is something considerably more useful, and it costs nothing extra to produce.

A person is a CapabilityProvider in the capability model - the branch that starts one floor down, whose canonical standalone use is a resume. What they can do are ProvidedCapability records, and what grounds each claim is Evidence: in that model’s own words, for humans it can be a diploma or a certification or a project. A completed course, a passed certification, a phishing simulation survived, an incident actually commanded are all evidence of the same shape. So the output of an AwarenessCampaign is not a completion percentage; it is a set of dated, evidenced capability claims that outlive the campaign.

Four things follow that a training dashboard cannot do:

  • Evidence expires. ProvidedCapability and Evidence are dated periods, so “trained in secure coding” backed by a 2021 certificate is visibly stale rather than quietly counted. “Who currently holds valid evidence of X” is a query, and re-training is scheduled by the state of the model instead of by the anniversary of a hire date.
  • Demand is typed, so the audience is computed. RequiredCapability states what an engagement or an element needs - an incident commander role, a container handling cardholder data, a team that owns a system with unmitigated threats of a given category. The gap between required capabilities and provided ones with valid evidence is the campaign audience. “Who needs this training” stops being answered with “everyone, annually”.
  • Evidence quality is distinguishable. A video watched, an assessment passed, a simulated phish not clicked, and a real incident handled are different records, and the model can tell them apart. Behavioral evidence from a PHISHING_SIMULATION campaign is worth more than a completion tick, and pretending otherwise is the central dishonesty of the awareness industry.
  • Skills inventory and audit pack are the same data. A directive control - annual secure coding training for engineers on payment systems - has a ControlApplication whose Evidence is exactly these records. The compliance exercise stops being parallel bookkeeping over a spreadsheet exported from a portal.

It also resolves the asymmetry hiding in the cost table above. A public course produces portable, generic evidence that the person keeps and can put on a resume; bespoke and model-anchored material produces exact, non-portable competence that the organization keeps. Both are legitimate purchases and they are not substitutes, which is precisely why they should be chosen as a portfolio in a recorded analysis rather than one at a time by whoever holds the budget. And the training an employer pays for landing in the individual’s own machine-readable capability record is a cheap, fair thing to hand back.

Files in a repository, thin UI on top

None of this requires a platform. The record is text:

  • Records live in version control. Capability and evidence records are YAML, JSON or Groovy files, one per person or team, changed through pull requests. The merge is the approval, the commit is the provenance - nxcore markers give every claim a permalink back to the line and commit that asserted it - and a seal Signature upgrades an attestation that needs to carry weight (a manager’s confirmation, a certification body’s assertion). IAM statements decide whose record is visible to whom, which is the part a shared spreadsheet gets wrong immediately.
  • A thin UI covers self-service. A form that writes YAML and opens a pull request is a weekend of work, not a procurement. Reviewers see a diff; the generated site shows the person’s page, the team’s coverage, and the gaps.
  • Existing learning systems become feeds, not systems of record. LMS and xAPI completion records, Open Badges and Credly assertions, certification registries, phishing simulation results, conference attendance - all load as Evidence with provenance, the same loader posture the rest of the tower takes toward Jira, Maven, and Excel. An organization that already owns an awareness platform keeps it and stops mistaking its dashboard for the record.

The bar to start is a text file, which is the point: the record exists before any purchase, and the purchase later becomes one more input to it.

The model itself is study material

The CISO domain is taught as a pile of acronyms - CSF, KEV, EPSS, SSVC, RTO, RPO, BIA, TPRM, MTTD - whose relationships are left to the reader. A metamodel is the relationships: a Weakness is a class of flaw, a Vulnerability is its instance in an asset, a Threat is the attack that exploits it, an Incident is a threat that materialized, a Control is what should have stopped it, a Waiver is what honesty looks like when it did not, and an Exercise is how you find out before an adversary does. The enumerations are the syllabus in condensed form: six incident statuses, five vulnerability statuses, four exercise kinds, three campaign kinds, each with a one-line definition, in a structure that shows how they connect.

The vocabulary tracks what the bodies of knowledge cover - CISSP and CISM domains, NIST CSF functions, the SP 800-61 lifecycle - so the generated documentation site doubles as study material. And the most instructive exercise remains instantiation: take one fictional estate, model it in C4, threat-model it, stand up a security program over it, run an incident through the timeline, accept one vulnerability with a waiver, exercise a continuity plan, and report the metrics. The fields you cannot honestly fill in are the lesson.

Applications

Security literacy and onboarding. Awareness content anchored to the elements it is about, campaigns aimed at populations selected by query, effectiveness measured by metrics read from telemetry. New joiners navigate the estate and its risks through one generated site instead of a folder of decks.

An evidenced security skills inventory. Course completions, certifications, simulation results, and incident experience recorded as capability evidence in version control: who can currently do what, with what proving it and until when. The staffing question, the training plan, and the auditor’s training-control evidence come out of the same records.

Program documentation generation. Control catalogs, risk registers with inherent and residual heat maps, incident records, vulnerability queues with SLA aging, vendor tiers, continuity plans and exercise results, board summaries - views over one source, so they cannot drift apart.

Regulatory reporting. reportable plus the timeline is the raw material for SEC Item 1.05 materiality determinations, GDPR Art. 33 notifications, and NIS2 and DORA incident reports. The narrative is generated from the record rather than reconstructed from Slack scrollback at hour sixty.

Continuous exposure management. Because assets are architecture elements, an estate change is a model diff, and a model diff against known weaknesses and default threats is a list of newly exposed elements. The CTEM promise without a second inventory.

Third-party due diligence, in both directions. Answer the customer’s questionnaire from the model; assess the vendor with the same machinery. criticality, access, and contractExpires drive assessment depth and cadence as a rule rather than a calendar reminder.

Composition with the rest of the tower. Agents, tools, and MCP servers from the agent and MCP models are assets; AI systems bring their own controls and incident obligations; a Maven dependency graph supplies the software estate a vulnerability lands in; the capability and org design models supply the people, their evidenced skills, and the units accountable for them. The security program governs what the other models describe, without describing it a second time.

Export and interoperability. OCSF and STIX incident shapes, CSAF/VEX vulnerability statements, OSCAL assessment results, TMBOM: generated views. Interoperate with the platforms without living in them.

Model overview

Area Types
Program SecurityProgram
Incident response Incident, IncidentStatus, TimelineEntry
Vulnerability management Vulnerability, VulnerabilityStatus
Awareness AwarenessCampaign, CampaignKind
Resilience ContinuityPlan, Exercise, ExerciseKind
Third parties ThirdParty
Metrics SecurityMetric, TargetDirection
Inherited threat Asset, Threat, Weakness; governance GovernanceProgram, Governed, Control, Risk, Waiver, Assessment, Evidence, Level; work Workable; C4 and architecture elements; role, lifecycle, IAM, seal, and accounting aspects

Resources