diff --git a/CHANGELOG.md b/CHANGELOG.md index 139803d..2923723 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -5,6 +5,56 @@ Notable changes to the ASSURED methodology and its site. The format follows follow the policy in [GOVERNANCE.md](GOVERNANCE.md). The current version is stamped in the site footer. +## [Unreleased] + +### Added + +- A "Development and evidence" page documenting the author's path into + event triage, the AUSPICED precursor, the structural redesign into + ASSURED, applied use in the Lateral Work Program, the practitioner design + loop, current evidence limits, and a concrete validation roadmap. +- Investigation Theory and Chris Sanders's public research to the + related-work map, including the derivation method behind the + Ambiguity-Driven Convergence model and the 2021 dissertation *The + Analyst Mindset*. +- A falsification section on the development page ("What would count + against ASSURED") naming the observations that would force the + teachability, phase-decomposition, depth-ladder, and generalization + claims to change. +- A plain conflict-of-interest statement and an account of how early + feedback reached the framework: no systematic log, mentoree + clarifications folded in while teaching, and daily use on the author's + own case queue. +- The program's approximate scale (around a dozen participants) and the + dated development timeline, from the October 2023 AUSPICED draft through + the 2026 releases. +- A build gate that fails when the README version badge disagrees with + package.json, plus contract pins for the corrected AUSPICED expansion + and the falsification section. + +### Changed + +- Replaced the universal absence claim in "Where ASSURED sits" with a + narrower, inspectable contribution claim: ASSURED is one open, named, + versioned operational workflow with explicit phase outputs and a + close-or-escalate boundary. +- Corrected the AUSPICED record against the surviving October 2023 draft: + the E stood for Enrichment, not Escalation, the precursor named no + escalation or risk stage, and it never reached testing; the redesign + table now maps all eight original parts. +- Strengthened the validation roadmap: the scoring rubric will be frozen + publicly before any pre/post assessment, and at least one scorer will + come from outside the program. +- Recast outcome wording in the README tagline and the introduction's + framing callout as design intent, and adopted Sanders's own + "vendor-agnostic" phrasing in the related-work map. +- Expanded the README author history and linked the public provenance and + evidence record. + +### Fixed + +- The README version badge, stale at 1.1.0 since the 1.2.0 release. + ## [1.2.0] - 2026-07-16 The assurance release: a full accuracy, accessibility, and release-assurance diff --git a/README.md b/README.md index e56ce76..dce413d 100644 --- a/README.md +++ b/README.md @@ -1,8 +1,8 @@ # ASSURED Cybersecurity Methodology -> **A structured, repeatable methodology for security analysts to triage, investigate, and document events with clarity, context, and confidence.** +> **A structured methodology designed to help security analysts triage, investigate, and document events with clarity, context, and confidence.** -[![Version](https://img.shields.io/badge/Version-1.1.0-blue.svg)](CHANGELOG.md) +[![Version](https://img.shields.io/badge/Version-1.2.0-blue.svg)](CHANGELOG.md) [![Code License: MIT](https://img.shields.io/badge/Code-MIT-yellow.svg)](LICENSE) [![Content License: CC BY 4.0](https://img.shields.io/badge/Content-CC%20BY%204.0-lightgrey.svg)](LICENSE-CONTENT) [![Documentation](https://img.shields.io/badge/Documentation-Live-blue.svg)](https://assured-methodology.vercel.app) @@ -87,9 +87,15 @@ This repository uses a dual license: The methodology is versioned: the current version is stamped in the site footer, releases are recorded in [CHANGELOG.md](CHANGELOG.md), and the bump rules (what counts as a major vs. minor change) live in [GOVERNANCE.md](GOVERNANCE.md). To cite ASSURED in training material, research, or documentation, use [CITATION.cff](CITATION.cff) (GitHub renders it as APA/BibTeX under "Cite this repository"). +## 🧭 Development and evidence + +The public [Development and evidence](https://assured-methodology.vercel.app/docs/development/) page records the framework's provenance: the author's path into event triage, the AUSPICED precursor and why it was replaced, the redesign into ASSURED, its use in a workplace lateral-development program, the limits of the evidence available today, and the observations that would count against the framework's claims. ASSURED is practice-derived and in active use; it has not yet been evaluated through a controlled or comparative study. + ## 👨‍💻 About the Author -**Timothy Zilber** is a security engineer specializing in event triage and incident response. ASSURED grew out of his experience mentoring analysts through a workplace lateral-development program: teaching event triage exposed the lack of a clear, repeatable methodology for it. Existing frameworks covered incident response at a high level but not the alert-by-alert analysis work that precedes it. ASSURED is the structured method that came out of years of iterating on that training, shared here so the gap he had to cross informally is easier for the next analyst. +**Timothy Zilber** is a security engineer specializing in event triage and incident response. After leaving the Army, he moved through IT support, network engineering in support of the Defense Information Systems Agency, and physical security systems administration before entering security operations through mentorship and an hour-a-day lateral-work arrangement. He later created a formal Lateral Work Program to make that kind of supervised opportunity available to others. + +ASSURED began during parental leave after the birth of his second child, while he was comparing incident-response literature with the alert-by-alert work of event triage. Its first form, AUSPICED, fell apart during writing and never reached use; it was replaced by the seven-phase ASSURED structure. Timothy now teaches ASSURED through the Lateral Work Program and maintains it as an open practitioner methodology. - 💼 **LinkedIn**: [timothy-zilber](https://linkedin.com/in/timothy-zilber) - 📧 **Email**: [tzilber@block.xyz](mailto:tzilber@block.xyz) diff --git a/scripts/check-content-contracts.mjs b/scripts/check-content-contracts.mjs index 929c493..2a2c236 100644 --- a/scripts/check-content-contracts.mjs +++ b/scripts/check-content-contracts.mjs @@ -26,6 +26,37 @@ const ROOT = new URL("..", import.meta.url).pathname; * ordered: [earlier, later] — both must appear, in that order. */ const CONTRACTS = [ + { + id: "development-evidence", + file: "src/content/docs/development.mdx", + why: "the provenance page must preserve the AUSPICED history, the empirical-evidence limit, and the falsification criteria", + mustContain: [ + "The first attempt was **AUSPICED**", + "has not yet been evaluated through a controlled or comparative study", + "Investigation Theory", + "What would count against ASSURED", + "The Analyst Mindset", + ], + }, + { + id: "auspiced-expansion", + file: "src/content/docs/development.mdx", + why: "per the October 2023 draft, AUSPICED's E was Enrichment; it named no escalation phase", + mustContain: ["| E | Enrichment |"], + mustNotContain: ["| E | Escalation |"], + }, + { + id: "related-work-investigation-theory", + file: "src/content/docs/positioning.mdx", + why: "the related-work map must credit Investigation Theory and avoid a universal absence claim", + mustContain: [ + "Investigation Theory and Chris Sanders's public work", + "a universal claim that no other methodology exists cannot", + ], + mustNotContain: [ + "no widely adopted, named, freely available, public methodology specific to event triage exists", + ], + }, { id: "ai-admission-gate", file: "src/content/docs/ai-triage.mdx", @@ -168,6 +199,19 @@ const CONTRACTS = [ }, ]; +// Computed contract: the README version badge must track package.json, the +// source of truth for the released version, so the repo's front door never +// misstates which methodology version is current. +const pkgVersion = JSON.parse( + readFileSync(join(ROOT, "package.json"), "utf8"), +).version; +CONTRACTS.push({ + id: "readme-version-badge", + file: "README.md", + why: `the README badge must show the released version (${pkgVersion} per package.json)`, + mustContain: [`Version-${pkgVersion}-blue.svg`], +}); + let failures = 0; for (const c of CONTRACTS) { diff --git a/src/components/Header.astro b/src/components/Header.astro index d79c6d8..d057121 100644 --- a/src/components/Header.astro +++ b/src/components/Header.astro @@ -261,7 +261,7 @@ const isActiveSection = (item: NavItem): boolean => flex-wrap: nowrap; } - /* Eleven top-level items (the five guide pages fold into the Guides + /* Eleven top-level items (the six guide pages fold into the Guides dropdown) need about 1200px of content width even at the tightest spacing with an icon-only search, so the desktop nav starts at 1240px (laptops keep it; Windows scrollbars eat ~17px of the media-query diff --git a/src/content/docs/development.mdx b/src/content/docs/development.mdx new file mode 100644 index 0000000..39e4031 --- /dev/null +++ b/src/content/docs/development.mdx @@ -0,0 +1,212 @@ +--- +title: "Development and evidence" +description: "Where ASSURED came from, how AUSPICED evolved into the current seven-phase structure, how the methodology is used today, and what its evidence does and does not establish." +--- + +import Callout from "@/components/assured/Callout.astro"; +import KeyTakeaway from "@/components/assured/KeyTakeaway.astro"; + +Frameworks should show their work. A memorable name and a polished diagram do not explain why the phases exist, whether an earlier design was rejected, where the method has been used, or how much confidence its evidence deserves. This page provides that record for ASSURED. + + +ASSURED is an open methodology authored by Timothy Zilber. The employment history below explains the experience that shaped it; it does not disclose an employer's internal security procedures or make ASSURED an official company operating standard. + + +## The path into event triage + +I did not enter cybersecurity through a direct route. After leaving the Army, I enrolled at ITT Technical Institute. I had considered studying cybersecurity, but chose to build a broader base first through an associate degree in information technology. While studying, I worked for a small trucking company as a systems administrator. The title covered work that was mostly IT support, and the limited growth path pushed me to look for a role where I could develop deeper technical skills. + +After graduating, I became a network engineer supporting the Defense Information Systems Agency through a government contract. That work strengthened the networking foundation I still use during investigations, but it offered no clear path into cybersecurity. With a child on the way, I also wanted to move away from the uncertainty of contract work. + +I joined Square as a physical security systems administrator because the role needed my network engineering background. Within my first few months, I told my manager that I wanted to move into cybersecurity. He connected me with the lead of the company's security operations team, who arranged a mentor. We met for an hour each week to work through the knowledge and habits the role required. + +I returned to school at Western Governors University because its program combined a bachelor's degree with industry certification exams. I earned the degree and about a dozen certifications. Roughly eight months before graduation, I asked the monitoring and triage lead for a more direct way to learn: let me spend one hour each workday on lower-complexity security cases. I would gain supervised experience while the team recovered time for more demanding investigations. The lead agreed. I continued that lateral work until graduation, when the team opened a position and brought me into security operations full time. + +This career history is not evidence that ASSURED works. It explains the design pressure behind it: the method was built by someone who had to cross the gap between knowing security concepts and making defensible decisions on real events, and who later wanted to make that gap easier for other analysts to cross. + +## The problem that started the framework + +ASSURED began during parental leave after the birth of my second child. I was reading books on incident response and comparing their lifecycle guidance with the alert-by-alert work I had learned on the triage desk. + +The material covered incident response well, but event triage usually appeared as a brief part of detection and analysis. That treatment left an operational problem unresolved. An analyst cannot give every alert the time and depth of a confirmed incident. The queue would stop moving. But a weak close can miss the event that should have become an incident, while a weak escalation transfers noise and incomplete work to the response team. + +The missing structure was the work between those two points: how to understand the signal, establish who or what is involved, bound the inquiry, collect enough evidence, assess the remaining risk, and make a close-or-escalate decision another person can reconstruct. + +## The first design: AUSPICED + +The first attempt was **AUSPICED**. The draft, which survives as a personal document dated October 2023, framed the space as “Identification and Response”: the triage work that runs before incident response takes ownership. It proposed eight parts: + +| Letter | Phase | +| --- | --- | +| A | Alert | +| U | User | +| S | Scope | +| P | Pattern | +| I | Investigation | +| C | Communication | +| E | Enrichment | +| D | Documentation | + +AUSPICED never reached testing. It failed during writing. I worked on the draft over a long stretch and could not get it to hold together. The document grouped the eight parts into two domains and four divisions, each part carrying its own sub-phases, and before long the structure was doing more work than the analyst. Two failures were decisive. I could not define Pattern in a way that separated it from the rest of the investigative work; in the draft, the Investigation section repeats the Pattern section's steps almost word for word. And Communication felt like an odd thing to hold as a discrete stage, because communicating matters throughout the work rather than at one point in a sequence. + +The deeper problem was that the model mixed several different kinds of things: entities to identify, broad work categories, cross-cutting practices, and supporting activities. “User” was too narrow for events centered on hosts, service accounts, applications, or cloud resources. “Investigation” was too broad to define what the analyst had to produce. Nothing in the model named the close-or-escalate decision the work exists to reach, and risk assessment had no stage of its own. + +A methodology needs more than a list of important activities. Each phase needs an anchor question, a required output, and a reason to hand the work to the next phase. AUSPICED did not meet that bar, so it was replaced rather than preserved for the acronym. The unfinished draft, placeholder notes and all, is kept as a record of what the first design got wrong. + +## The redesign into ASSURED + +ASSURED retained the parts that held up and reorganized the parts that did not: + +| AUSPICED | ASSURED | What changed | +| --- | --- | --- | +| Alert | Alert | Retained as the signal-understanding and validation phase. | +| User | Subject | Expanded beyond people to every entity acting in or affected by the event. | +| Scope | Scope | Retained, with explicit time, entity, infrastructure, and regulatory boundaries. | +| Pattern + Investigation | Uncover | Replaced two categories the draft could not keep apart with evidence collection, correlation, hypothesis testing, and reconstruction. | +| Communication | Distributed across phases | Moved into escalation protocols, handoff, and documentation, where communication produces an accountable artifact. | +| Enrichment | Folded into Alert and Uncover | Context and threat-intelligence gathering became part of understanding the signal and collecting evidence, not a separate late stage. | +| Documentation | Documentation | Retained as the durable record of evidence, uncertainty, reasoning, and outcome. | +| No distinct phase | Risk | Added an explicit assessment between evidence gathering and the final decision. | +| No distinct phase | Escalation | Added as the deliberate close-or-escalate decision. AUSPICED ended in enrichment and documentation without ever naming the decision. | + +The result was not a relabeling of the first acronym. It was a change from a collection of activities to seven linked decision stages. The first three establish what is being examined. Uncover and Risk form an investigative loop. Escalation and Documentation turn the analysis into an accountable decision and a reusable record. + +ASSURED began as a short internal write-up and expanded as the teaching and operational questions became clearer. The public site launched as version 1.0.0 in May 2026, with 1.1.0 and 1.2.0 following in July 2026; the changelog records each release. The current site adds phase deliverables, transition rules, worked examples, quizzes, a depth ladder for different queue conditions, templates, and adoption guidance. Those additions make the method more testable because a reviewer can inspect what each phase claims to produce. + +## The development method + +ASSURED was developed through a practitioner design loop, not a formal research study: + +
+
+

1. Observe the work

+

Identify the recurring decisions and constraints in event triage: limited time, incomplete telemetry, uncertain meaning, uneven analyst experience, and a consequential close-or-escalate boundary.

+
+
+

2. Make the tacit process explicit

+

Write the work as named stages so that assumptions, missing steps, and ambiguous handoffs can be seen and challenged.

+
+
+

3. Reject the weak structure

+

Write the model out in full and see whether it holds. AUSPICED failed this step before it ever reached use: the draft could not keep its own categories apart, so the structure was replaced rather than defended.

+
+
+

4. Teach and observe

+

Use ASSURED with developing analysts in a supervised lateral-work program. Watch where learners become more confident, where the language helps, and where the material still needs explanation.

+
+
+

5. Turn claims into artifacts

+

Give each phase an output, create worked cases and exercises, define closure and escalation criteria, and ship templates that make the method reviewable outside the author's head.

+
+
+

6. Publish for external challenge

+

Version the methodology, cite adjacent work, expose limitations, and use outside review to correct both the framework and its claims.

+
+
+ +Two honesty notes belong here. First, this loop is a retrospective description: I did not run the six steps against a written plan, and step 4 was not systematically logged while it happened. Second, a practitioner design loop is a legitimate source of practitioner knowledge, but it is not equivalent to empirical validation. The distinction matters. + +## Use in the Lateral Work Program + +I created the Lateral Work Program because lateral work had opened the door into cybersecurity for me. Informal access depends on finding the right manager, mentor, and team at the right time. A program can make the opportunity deliberate: participants gain supervised exposure to security work, and the receiving team can route appropriate cases to them without giving up ownership of the harder work. + +ASSURED is the methodology I teach in that program. Around a dozen participants have come through it so far. It gives participants a shared sequence for approaching tickets and a vocabulary for explaining what they examined, what they found, and why they reached a decision. I have observed participants become more confident and comfortable working and resolving tickets after learning and applying the structure. + +That observation is important because teachability is one of ASSURED's design goals. It remains qualitative practitioner observation. Confidence can improve while accuracy does not, and a program led by the framework's author is not an independent test. + +The conflict of interest deserves a plain statement. I created the framework, I co-lead the program, I judge informally how participants are doing, and I maintain this site. Every favorable observation reported here passed through the same interested person. That does not make the observations false, but it is exactly the condition that independent scoring and outside replication exist to correct. + +### How feedback reached the framework + +I did not keep a systematic log of feedback during the early teaching. I taught the method as I went, and when mentorees asked questions or needed a distinction clarified, I folded those clarifications into how I taught and wrote the material next. In parallel, I started applying the methodology to every ticket I worked myself, structuring my case notes around sections I had to fill in for Alert, Subject, Scope, and Uncover. Working my own queue with those fill-in sections also surfaced day-to-day friction. + +That history means the trail from feedback to change is thinner than it should be: I can say what the method looks like after the feedback, but not always which observation changed which part. From this release forward, substantive changes and the observations that prompted them are recorded in the public changelog so the trail no longer depends on memory. + +## What the current evidence establishes + +
+
+

What exists today

+ +
+
+

What is not established yet

+ +
+
+ + +ASSURED is practice-derived, teachable, and in active use. It has not yet been evaluated through a controlled or comparative study. The site's worked examples test whether the framework can express varied cases; they do not prove that it improves real-world outcomes or outperforms another approach. + + +## Relationship to Investigation Theory + +This page exists because of a public critique. In July 2026, shortly after ASSURED's 1.2.0 release, Chris Sanders pointed out that the project's related-work claims omitted his prior work and that the site said nothing about how ASSURED was created or tested. He was right on both counts. The reading that prompted ASSURED was not a systematic literature review, and it missed important public work by Sanders and collaborators. The omission has been corrected in the related-work map, and this page is the answer to the second criticism. + +Sanders's Investigation Theory directly addresses tool-independent security investigation, the difficulty of transferring tacit analyst knowledge, evidence selection, investigative questions, decisions, bias, and reporting. His public books, papers, and presentations cover analyst cognition and mental models in depth. + +The 2019 paper Creative Choices, written with Stef Rand, also demonstrates the kind of derivation record a framework should provide. The authors used a mixed-method, grounded theory and survey-based approach. Sixteen analysts completed interviews and scenario work, and the resulting observations formed the Ambiguity-Driven Convergence model. + +Sanders's 2021 doctoral dissertation, The Analyst Mindset: A Cognitive Skills Assessment of Digital Forensic Analysts (Baylor University), extends that record. It used cognitive task analysis interviews with practicing analysts to model diagnostic inquiry, the questioning process an investigator uses to move from a signal to an explanation. That is the standard of documented derivation this page works toward. + +ASSURED was not derived from Investigation Theory, but independent development does not make adjacent work irrelevant. The two overlap on evidence, questions, bias, and the goal of making analyst reasoning teachable. Investigation Theory goes deeper into how investigators think and learn. ASSURED contributes a narrower operational workflow for carrying one security event from its initial alert to a documented close or an incident-response handoff. + +## What would count against ASSURED + +A framework that cannot say what would disprove it is a brand, not a methodology. These are the observations that would force specific claims to change: + +- If scenario work scored before and after instruction, by reviewers who did not teach the participant, shows no improvement in decision quality, the teachability claim fails as stated and the training material needs redesign or the claim needs withdrawal. +- If experienced analysts routinely skip or reorder Subject and Scope with no measurable loss of decision or documentation quality, the seven-phase decomposition is wrong about where the load-bearing boundaries sit, and the phase structure should change. +- If Level 0 pattern closes show higher reopen or missed-incident rates than full-arc closes on comparable alerts, the depth ladder is miscalibrated and its eligibility gate is too permissive. +- If independent teams that adopt ASSURED find the phase outputs do not fit their queue without major restructuring, the claim that the workflow generalizes beyond its home environment fails. + +If any of these are observed, the changelog will record the observation and the change it forced. + +## The validation work ahead + +The next stage is to convert practitioner observation into evidence that others can inspect: + +1. Publish exact learner counts, cohorts, and instructional periods, using aggregate data that does not expose employees or investigations. +2. Assess the same scenarios before and after instruction with the rubric already used in the teaching guide, and freeze that rubric publicly before the assessment begins so it cannot drift to fit the results. +3. Have reviewers who did not teach the participant score the work, including at least one scorer from outside the program. +4. Measure decision quality and documentation alongside speed. The adoption guide already defines escalation acceptance, reopen rate, missed incidents, handoff rework, time-in-phase, pattern-library health, and close-note quality. +5. Compare ASSURED-guided work with the team's prior process or another explicit approach. +6. Invite independent teams to reproduce the training and publish both positive and negative findings. +7. Record substantive changes and the evidence that prompted them in the public changelog. + +Until that work exists, ASSURED's claims should remain proportionate: it is an open, structured, versioned, and teachable practitioner methodology with promising applied use, not a proven universal standard. + +ASSURED came from an observed operating problem, survived the replacement of an earlier design, and is now used to teach developing analysts. That history establishes provenance and practical relevance. It does not substitute for outcome measurement, comparison, independent replication, or peer review; those are the next stage of the work. + +
+ ← Where ASSURED sits + Start the methodology: Alert → +
+ + diff --git a/src/content/docs/intro.mdx b/src/content/docs/intro.mdx index 068bbbf..298303c 100644 --- a/src/content/docs/intro.mdx +++ b/src/content/docs/intro.mdx @@ -24,7 +24,7 @@ import { timeBudgets, timeBudgetTotals } from "@/data/time-budgets"; - frameworks like NIST 800-61 and SANS PICERL describe what to do once you already know what you are looking at, and knowledge bases like catalog adversary behavior once you know which behavior you are looking for. is the work before both, and most analysts learn it informally on the job. The gap is widening, not closing: NIST's 2025 revision of 800-61 (r3) reframes incident response around the CSF 2.0 functions and deliberately drops r2's step-by-step analysis guidance, leaving the *how* of alert analysis to each organization. ASSURED gives that informal craft a structure that scales: scaffolding for newer analysts, a checklist for experienced ones (the printable one-page reference), and a shared vocabulary for handoff and review. The full related-work map, where each neighboring framework helps and where the gap sits, is on Where ASSURED sits. + frameworks like NIST 800-61 and SANS PICERL describe what to do once you already know what you are looking at, and knowledge bases like catalog adversary behavior once you know which behavior you are looking for. is the work before both, and most analysts learn it informally on the job. The gap is widening, not closing: NIST's 2025 revision of 800-61 (r3) reframes incident response around the CSF 2.0 functions and deliberately drops r2's step-by-step analysis guidance, leaving the *how* of alert analysis to each organization. ASSURED is designed to give that informal craft a structure that scales: scaffolding for newer analysts, a checklist for experienced ones (the printable one-page reference), and a shared vocabulary for handoff and review. See Where ASSURED sits for the related-work map, and Development and evidence for the framework's origin, rejected precursor, applied use, and current validation limits. diff --git a/src/content/docs/positioning.mdx b/src/content/docs/positioning.mdx index 22c40a6..26c6638 100644 --- a/src/content/docs/positioning.mdx +++ b/src/content/docs/positioning.mdx @@ -1,6 +1,6 @@ --- title: "Where ASSURED sits" -description: "Honest positioning against NIST 800-61r3, SANS PICERL and SEC450, the SOC books, and the analyst's thinking tools (OODA, ACH, the Diamond Model, OSCAR)." +description: "Honest positioning against Investigation Theory, NIST 800-61r3, SANS PICERL and SEC450, the SOC books, and the analyst's thinking tools." --- import Callout from "@/components/assured/Callout.astro"; @@ -10,7 +10,9 @@ ASSURED did not invent triage, and the field around it is full of work worth rea ## The claim, stated carefully -The defensible claim is narrow: **no widely adopted, named, freely available, public methodology specific to event triage exists.** The incident-response lifecycles assume you already know what you are looking at. The strongest triage training is commercial courseware. The best books are books: static, unversioned, not citable as a shared standard. Vendor triage guides are locked to their tools. ASSURED's bid is to be the open, named, versioned, teachable standard for the work between an alert firing and the close-or-escalate decision. That is the whole claim; everything below is credit where it is due. +ASSURED does not claim that event triage was undocumented, unstudied, or unteachable before this project. Investigation Theory directly teaches vendor-agnostic investigation and alert-triage skills. Incident-response standards, books, courses, research, and thinking tools cover substantial parts of the work. + +The defensible contribution is narrower and concrete: **ASSURED publishes one open, named, versioned operational workflow for the work between an alert firing and the documented close-or-escalate decision.** Its seven phases have explicit questions, deliverables, transitions, and depth rules. Its templates, exercises, teaching guide, adoption guide, version history, and citation record are public. That positive contribution can be inspected; a universal claim that no other methodology exists cannot. ## The lifecycles and standards @@ -35,6 +37,11 @@ The defensible claim is narrow: **no widely adopted, named, freely available, pu ## The training and the books
+
+

Investigation Theory and Chris Sanders's public work course and research

+

What it is: Investigation Theory is vendor-agnostic training centered on the mental models used by investigators: diagnostic inquiry, evidence, questions, decisions, data transformation, playbooks, bias, and reporting. Sanders's publications and presentations extend that work into analyst cognition and education. The 2019 Creative Choices study with Stef Rand used interviews, investigation scenarios, and quantitative self-report measures to derive a model of divergent and convergent analyst thinking, and his 2021 doctoral dissertation, The Analyst Mindset: A Cognitive Skills Assessment of Digital Forensic Analysts (Baylor University), used cognitive task analysis with practicing analysts to model how diagnostic inquiry works in investigations.

+

How it relates: the overlap is real: both projects try to make tacit investigative reasoning teachable, and both cover evidence selection, questions, bias, and decisions. Investigation Theory goes deeper into cognition and the transferable craft of investigation. ASSURED is narrower and more procedural: it defines the sequence and required artifacts for carrying one event from alert to close or incident-response handoff. ASSURED was not derived from Investigation Theory, but the earlier omission of this work made the related-work map incomplete. See Development and evidence for the provenance record.

+

SANS SEC450 commercial course

What it is: Blue Team Fundamentals: Security Operations and Analysis, SANS's SOC-analyst course, and the closest neighbor to ASSURED in intent: structured, bias-aware alert triage, prioritization, and analysis under pressure.

@@ -86,11 +93,11 @@ The defensible claim is narrow: **no widely adopted, named, freely available, pu The UK's National Cyber Security Centre operates "Assured" schemes: NCSC-assured services, consultancies, and training marks. This ASSURED methodology has no affiliation with the NCSC or its assurance schemes; the shared word is coincidence. When searching, "ASSURED triage" or "ASSURED methodology" finds this project. -The field has excellent IR lifecycles, excellent commercial training, excellent books, and excellent thinking tools. What it did not have is an open, named, versioned methodology for the triage work specifically, and 800-61r3's deliberate retreat from operational detail widened that gap rather than closing it. ASSURED claims the gap, not the field. +The field already contains strong investigation training, research, IR lifecycles, books, and thinking tools. ASSURED does not claim to originate investigative reasoning. It contributes a specific open operational workflow: seven linked phases, explicit deliverables, a close-or-escalate boundary, and public material a team can teach, adopt, review, and revise.
← The introduction - Start the methodology: Alert → + Development and evidence →