From f7d910cd604002729ec8491cd59650523504c193 Mon Sep 17 00:00:00 2001 From: Timothy Zilber Date: Fri, 24 Jul 2026 11:33:55 -0500 Subject: [PATCH 1/2] Document ASSURED development and evidence --- CHANGELOG.md | 21 ++++ README.md | 8 +- scripts/check-content-contracts.mjs | 22 ++++ src/components/Header.astro | 2 +- src/content/docs/development.mdx | 187 ++++++++++++++++++++++++++++ src/content/docs/intro.mdx | 2 +- src/content/docs/positioning.mdx | 15 ++- src/data/navigation.ts | 6 + 8 files changed, 256 insertions(+), 7 deletions(-) create mode 100644 src/content/docs/development.mdx diff --git a/CHANGELOG.md b/CHANGELOG.md index 139803d..ea8a42d 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -5,6 +5,27 @@ 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. + +### 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. +- Expanded the README author history and linked the public provenance and + evidence record. + ## [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..94673e6 100644 --- a/README.md +++ b/README.md @@ -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, and the limits of the evidence available today. 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, did not hold up as a complete workflow and 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..7ce5138 100644 --- a/scripts/check-content-contracts.mjs +++ b/scripts/check-content-contracts.mjs @@ -26,6 +26,28 @@ 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 both the AUSPICED history and the empirical-evidence limit", + mustContain: [ + "The first attempt was **AUSPICED**", + "has not yet been evaluated through a controlled or comparative study", + "Investigation Theory", + ], + }, + { + 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", 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..beffe4c --- /dev/null +++ b/src/content/docs/development.mdx @@ -0,0 +1,187 @@ +--- +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**: + +| Letter | Phase | +| --- | --- | +| A | Alert | +| U | User | +| S | Scope | +| P | Pattern | +| I | Investigation | +| C | Communication | +| E | Escalation | +| D | Documentation | + +Writing AUSPICED out and trying to use it as a complete flow exposed structural problems. It mixed several different kinds of things: entities to identify, broad work categories, cross-cutting practices, and an outcome. ā€œUserā€ was too narrow for events centered on hosts, service accounts, applications, or cloud resources. ā€œPatternā€ described one way of interpreting activity, while ā€œInvestigationā€ was too broad to define what the analyst had to produce. Communication mattered throughout the work rather than at one isolated point. The model named escalation but did not give risk assessment its own decision stage. + +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 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 uneven categories with evidence collection, correlation, hypothesis testing, and reconstruction. | +| No distinct phase | Risk | Added an explicit assessment between evidence gathering and the final decision. | +| Communication | Distributed across phases | Moved into escalation protocols, handoff, and documentation, where communication produces an accountable artifact. | +| Escalation | Escalation | Defined as the deliberate close-or-escalate decision, not a presumption that every case transfers. | +| Documentation | Documentation | Retained as the durable record of evidence, uncertainty, reasoning, and outcome. | + +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 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

+

Try the model as a complete workflow. AUSPICED did not provide a coherent enough path, so its 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.

+
+
+ +This process 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. 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. + +## What the current evidence establishes + +
+
+

What exists today

+
    +
  • A documented precursor that was set aside after it did not hold up as a complete workflow.
    • +
  • Use of the revised method in a supervised workplace learning program.
    • +
  • Observed growth in learner confidence and comfort resolving tickets.
    • +
  • Worked examples, exercises, answer keys, phase deliverables, and copy-ready records.
    • +
  • A public version history and an open channel for outside review.
    • +
+
+
+

What is not established yet

+
    +
  • Published participant counts, cohort details, or pre-training baselines.
    • +
  • A measured improvement in decision accuracy, investigation time, or documentation quality.
    • +
  • A comparison with another methodology or with unstructured triage.
    • +
  • Independent replication in other organizations or tool environments.
    • +
  • A controlled, peer-reviewed evaluation of the seven-phase model.
    • +
+
+
+ + +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 + +The reading that prompted ASSURED was not a systematic literature review, and it missed important public work by Chris Sanders and collaborators. That omission has been corrected in the related-work map. + +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. + +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. + +## The validation work ahead + +The next stage is to convert practitioner observation into evidence that others can inspect: + +1. Publish the number of learners, 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. +3. Have reviewers who did not teach the participant score the work. +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..717f5ac 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 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. 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..6e113f2 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-independent 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-independent training centered on the mental models used by investigators: 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.

+

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 ā†’