Integrity. Authenticity. Confidentiality. Key Management.

Framework pillars

Why IACK

The framework is designed to support clearer research questions, repeatable testing, and stronger links between practical cybersecurity engineering and formal academic study.

ISA Learning Hub

ISA Learning Hub is the academic learning space for IACK, created to preserve the framework as a step-by-step resource for future generations of students, researchers, and practitioners. It is named for my daughter, whose advocacy for human rights and the rights of people has been a source of inspiration. This section is intended to make the framework easier to study, understand, and evolve through disciplined documentation.

The ISA Learning Hub now serves as the entry point into a structured documentation path for academic learning, reproducible study, and long-term framework stewardship.

Documentation Path

The sections below provide a step-by-step academic path through the IACK framework so that learners can move from core concepts to implementation, verification, evidence review, and disciplined release practice.

Foundations

Foundations introduces the four pillars of IACK: integrity, authenticity, confidentiality, and key management. This section should be the starting point for understanding what the framework measures and why those measurements matter.

• Define each pillar in practical and research terms.
• Explain how the pillars relate to trust, verification, and secure system design.
• Clarify how IACK differs from a generic checklist by emphasizing measurable security reasoning.

Workflow

Workflow describes the path from environment setup to framework execution, evidence capture, and documented outcomes. It should help future learners understand not only what to run, but how to think through the process in order.

• Start with installation, environment preparation, and expected prerequisites.
• Describe the framework sequence from setup to execution and review.
• Show how each workflow step contributes to repeatable research and operational clarity.

Validation

Validation explains how IACK checks whether expected security conditions are being met and whether outputs can be trusted. This section should make verification logic visible and understandable for both technical and academic audiences.

• Document what is being validated and why each validation matters.
• Explain pass, fail, warning, and exception conditions in clear language.
• Connect validation results to traceability, reproducibility, and confidence in findings.

Metrics

Metrics focuses on measurable outputs, scoring logic, and the interpretation of framework results over time. It should help learners understand how evidence is translated into useful security insight.

• Define the major metrics produced by the framework.
• Explain how scores, states, or classifications should be interpreted.
• Show how metrics support comparison, trend analysis, and formal study.

Mathematical Model

The IACK mathematical model explains how structured assessment inputs are converted into interpretable security outputs. At the center of this process is compute_iack_metrics, which transforms evidence-backed values into a repeatable set of framework results designed for validation, comparison, and research-oriented interpretation.

In practical terms, the model begins with assessment inputs that describe the observed security condition of a target environment. Those inputs are evaluated through framework logic tied to the IACK pillars: integrity, authenticity, confidentiality, and key management. The purpose of the model is not only to generate a score, but to preserve traceability between observed conditions, scoring assumptions, and final interpretation.

A useful way to think about the model is as a documented path: assessment-input.json -> compute_iack_metrics -> current-metrics.json -> cockpit interpretation. This path matters because it preserves a clear connection between what was assessed, how it was processed, and what was finally reported.

• Define each input variable in terms of evidence, source, and expected value meaning.
• Document scoring assumptions, including weighting, normalization, thresholds, and interpretation boundaries.
• Explain how validation affects confidence in the resulting metric outputs.
• Clarify which outputs are descriptive, which are comparative, and which are decision-support signals.

Over time, this section can grow into the formal reference for IACK equations, threshold definitions, and scoring revisions. That makes the mathematical layer not just a technical implementation detail, but an academic record of how the framework reasons about security conditions.

Scoring example

The example below shows how a pillar score can be expressed as a weighted interpretation of validated inputs. It is a documentation example intended to illustrate the logic path from observed condition to final score.

IACK Example: Interpreting a framework run from current-metrics.json

overallScore = 81
validationStatus = "Passed"
confidence = 0.91
openFindings = 5
pillars.integrity = 78

Illustrative interpretation path:
1. overallScore reflects the combined framework result for the assessed run.
2. validationStatus = "Passed" indicates the run met the expected validation condition.
3. confidence = 0.91 indicates strong trust in the output quality for interpretation.
4. openFindings = 5 shows unresolved review items still requiring analyst attention.
5. pillars.integrity = 78 shows the integrity-specific result inside the broader IACK assessment.

Interpretation labels:
- 80+ can be documented as a strong current framework posture.
- A passed validation state increases trust in the score interpretation.
- Open findings prevent the score from being treated as final perfection.
- Pillar-level values help analysts identify which domain needs closer review.

Variable definitions

• overallScore: the combined framework result for the current assessed run.
• validationStatus: the documented validation outcome attached to the current metric state.
• confidence: the degree of trust assigned to the current interpreted output.
• openFindings: the number of unresolved issues still requiring analyst review.
• pillars.integrity: the integrity-specific pillar result inside the broader IACK model.

These variables make the model easier to read as a formal system because each output can be traced to a named concept, an interpretation rule, and a place in the broader framework workflow.

Cockpit

Cockpit explains how the IACK Cockpit presents framework outputs in a reviewable and operationally useful form. This section should connect raw framework activity with visibility, evidence surfaces, and informed decision-making.

• Describe the role of the cockpit as an interpretation and monitoring layer.
• Explain how users read outputs, states, and evidence artifacts.
• Connect cockpit views to both operational usage and academic demonstration.

Architecture

The IACK architecture is organized as a traceable workflow that connects assessment intake, metric generation, validation history, evidence publication, and cockpit presentation. Its structure is intended to support clarity, repeatability, and long-term extension without losing visibility into how outputs were produced.

At the workflow level, the framework can be understood as an orchestrated pipeline driven by run-iack-pipeline.ps1. That orchestration layer can execute Python-based metric generation, update current-metrics.json, append validation history, optionally record formula changes, and complete a publish-ready Git workflow when needed.

The architectural flow can be described as: input capture -> metric computation -> validation and history update -> artifact publication -> cockpit consumption. This design is strong because each stage has a distinct responsibility while still contributing to a single evidence-backed narrative.

• Document the purpose of each component, script, data artifact, and review surface.
• Explain how evidence moves from assessment intake to published metric outputs.
• Clarify how validation history and formula changes preserve traceability over time.
• Show how the cockpit serves as a consumption layer rather than the source of truth itself.

This architecture also prepares IACK for later expansion, including stronger automation, external integrations, MITRE ATT&CK mapping, and eventually cloud-based deployment patterns. By documenting the architecture explicitly, the framework becomes easier to study, maintain, explain, and extend without weakening its research discipline.

Architecture flow example

The following diagram shows the high-level evidence and publication path used by the framework. It gives learners a direct view of how assessment inputs become cockpit-visible outputs.

Artifact glossary

• assessment-input.json: the structured entry artifact describing the assessed conditions for a run.
• current-metrics.json: the current published metric state used for review, reporting, and cockpit display.
• validation-history.json: the historical record of validation outcomes and traceable review changes over time.
• formula-changelog.json: the record of model or scoring changes that affect interpretation across versions.

Together these artifacts make the framework easier to audit because they separate input conditions, metric output, validation history, and formula evolution into explicit evidence layers.

MITRE ATT&CK mapping

A future IACK extension should map framework metrics and validation outputs to relevant MITRE ATT&CK techniques so that model results can be connected to recognized adversary behavior categories and practical defensive decision-making.

• Tactic alignment: relate IACK findings to attacker objectives such as execution, persistence, privilege escalation, or defense evasion.
• Technique linkage: connect validation outcomes or evidence patterns to specific ATT&CK techniques where appropriate.
• Defensive response: use mapped outputs to inform control selection, integration priorities, and follow-on review actions.

This mapping should be treated as a documented roadmap extension rather than a finished claim, preserving the academic discipline of the current release while showing how IACK can grow into a stronger operational research reference.

Concrete ATT&CK example

One practical starting example is to map an IACK authentication-related validation concern to T1078 Valid Accounts. In ATT&CK, this technique covers the abuse of legitimate credentials, which makes it a useful reference point when IACK outputs suggest elevated trust risk around account use, authentication anomalies, or evidence that a valid account may be operating outside expected patterns.

• Tactic context: valid-account abuse can support initial access, persistence, privilege escalation, or defense evasion depending on how the account is used.
• IACK interpretation: if validation shows trusted account activity with unresolved findings or weak confidence, the framework can flag that condition for closer review.
• Defensive implication: the next action may be tighter log review, privileged-account scrutiny, authentication hardening, or stronger anomaly detection around account behavior.

JSON evidence example

{
  "assessmentId": "iack-2026-06-26-001",
  "overallScore": 81,
  "validationStatus": "Passed",
  "confidence": 0.91,
  "openFindings": 5,
  "pillars": {
    "integrity": 78,
    "authenticity": 83,
    "confidentiality": 80,
    "keyManagement": 84
  },
  "changeSummary": [
    "Integrity score dropped 3 points after artifact drift detection.",
    "Validation coverage improved after metric test alignment."
  ]
}

This small artifact example makes the documentation more tangible because readers can see how a real metric object supports interpretation, validation discussion, and future ATT&CK alignment without needing to leave the Learning Hub.

Release Discipline

Release Discipline documents how framework changes are prepared, reviewed, versioned, and published responsibly. This section helps preserve the long-term integrity of IACK as both a technical framework and a learning resource.

• Record release expectations, version updates, and evidence requirements.
• Explain how roadmap progress connects to stable publication practices.
• Show why disciplined release management supports trust, continuity, and future academic use.

Quick install

pip install iack-framework

Project links

• Repository
• Roadmap
• PyPI package