Compare fraud and security frameworks, understand where their concepts correspond, and see where mappings or coverage are missing.
Private sourceCrosswalk & graph catalog
FT3
A framework I created to describe fraud consistently. FT3 2.0 adds independent classifications and connects techniques to reusable detection and control knowledge.
Mixed sourceFramework · 1.0 public / 2.x by request
Compare fraud and security frameworks, understand where their concepts correspond, and see where mappings or coverage are missing.
Private source
More detailsHide details about FT3c
About the project
FT3c helps investigators and researchers compare fraud and security frameworks without losing the distinctions between them. Its crosswalk and graph catalog connects external concepts to FT3 and distinguishes reviewed mappings, proposals, gaps, and unassessed entries.
The implemented work includes mapping validation, machine-readable graph and STIX exports, and coverage reports built against specific framework versions. I lead the project’s technical direction and mapping review.
The crosswalk, export pipeline, and MCP integration are implemented.
A framework I created to describe fraud consistently. FT3 2.0 adds independent classifications and connects techniques to reusable detection and control knowledge.
Mixed source
More detailsHide details about FT3
About the project
FT3 gives fraud practitioners a shared way to describe behavior and connect that understanding to defensive work. I created the framework and continue to guide its evolution.
FT3 1.0 has publicly available source. The 2.x generation adds independent classifications and connected detection/control records; the selected catalog release is 2.1.0, dated 13 September 2026. Access to 2.x is by request.
A threat intelligence platform (TIP) for querying, enriching, and visualizing relationships in a hypergraph. Its AI shows every query it runs and cites the nodes it used.
Private source
More detailsHide details about ARC
About the project
A threat investigation platform for querying, enriching, and visualizing complex relationships in a hypergraph, with AI-assisted investigation workflows.
A CLI and library for the lifecycle of Synapse Cortex power-ups: author, validate, install, promote, and roll back.
Private source
TypeScriptPythonJavaScript+1 in details
More detailsHide details about ARC package management
About the project
Synapse Cortex power-ups have to move from a draft to an installed package, and then from one environment to another, without losing track of what was approved. ARC package management is the CLI and library for that lifecycle.
The commands cover scaffold, build, validate, publish, install, lock, drift detection, sync, promote, rollback, verify, and diagnose. Packages are stored as static JSON in a Git-backed registry, so the registry does not need its own server. A lockfile records the desired state. Builds are deterministic and checked with SHA-256. Install, promote, rollback, and sync follow the configured signature policy. If two packages request different versions of the same dependency, the install fails instead of choosing one.
Draft authoring is library-driven: a spec, a package draft, test inputs, and an author review checkpoint, then a candidate build and verification. Diagnose reads a failed candidate and its verification report and explains the failure without changing that state. Push installs go to a designated test Cortex. Updating a production Cortex means an operator installs an approved version there.
Languages & technologies
TypeScript
Python
JavaScript
Shell
Current state
The CLI, library, Git-backed registry, and library-driven authoring pipeline are in the source. Push installs are defined for a test Cortex.
A research engine supporting FT3 by identifying candidate fraud techniques, extracting grounded behavior observations, and comparing them to taxonomy coverage.
Source not disclosed
More detailsHide details about Acheron
About the project
Acheron turns fraud intelligence into additions to FT3. Agents identify the techniques described in incoming intelligence, and other agents integrate newly identified techniques into the framework. Intelligence from several sources flows to agents that identify techniques, then to agents that integrate them. New techniques appear as candidates and join the FT3 graph.
FT3 2.0 is supported by Acheron, a private, intelligence-assisted curation environment that turns raw fraud intelligence into governed, versioned knowledge while preserving provenance.
Acheron helps turn live threat intelligence into a machine-readable map of how fraud actors operate. I wrote in May that the next phase of fraud defense was making adversary language run. FT3 2.0 is that phase. Acheron, the intelligence-sourced agentic framework that now powers FT3, was the first piece to ship. The FT3 precedence record, dated April 2026, records that I shipped Acheron, the first intelligence-sourced agentic framework, powering FT3.
Current state
Architecture, decision logic, placement rules, quality controls, and operating procedures remain restricted to closed trust environments.
Instructor-led workshop materials for investigating a threat scenario with Claude Code and the Team Cymru Scout API and MCP.
Source not disclosed
More detailsHide details about Threat intelligence workflow workshop
About the project
These are the student materials for an instructor-led workshop at The Underground Economy Conference 2026. Participants use Claude Code and the Team Cymru Scout API and MCP to investigate a threat scenario, package the method they used as a reusable skill, and direct a team of agents that checks its own work.
A preflight script checks the setup on macOS, Linux, or Windows before the session. It installs dependencies, runs a build, and includes a path to confirm Scout. During the workshop, the investigation is written to a report and a findings file. A later part of the session uses that investigation to build the agent team, which writes a threat report back into the same repository.
The materials include a Team Cymru Scout API specification and an environment cheat sheet. The repository is the working copy for the workshop. It is not a published threat-intelligence service.
Current state
Student materials for The Underground Economy Conference 2026 workshop, including preflight checks and Scout reference notes.
Compliance remediation content for Red Hat Enterprise Linux: Bash, Puppet, and Ansible, organized as one script per STIG finding.
Public source
BashPuppetAnsible
More detailsHide details about Aqueduct
About the project
I created Aqueduct to share DISA STIG remediation for Red Hat Enterprise Linux. The original project, on Fedora Hosted, set out to share system configuration content and the methods for synchronizing that content to systems management tools such as Red Hat Network Satellite.
The public repository is organized by tool and finding. Bash STIG scripts for RHEL 5 and RHEL 6 each stand alone, in production, in-development, and manual-check trees, so one finding can be audited or changed without the others. Puppet modules cover the RHEL 6 STIG. An Ansible role covers RHEL 6 SCAP Security Guide hardening. An RPM spec packages the content for installation. I wrote most of the Bash scripts. Shannon Mitchell contributed some of the RHEL 5 scripts and the RPM packaging.
The work is under GPL-2.0. The repository README describes Aqueduct as a historical project from 2011 to 2014, kept so the scripts remain public.
Languages & technologies
Bash
Puppet
Ansible
Current state
Public source. Historical RHEL 5 and RHEL 6 remediation content from the Fedora Hosted project.
AI-assisted roles for essays, social posts, talks, press, and the site, with a person approving what is published.
Private source
PythonShell
More detailsHide details about Editorial agent workflows
About the project
Editorial agent workflows split the work across specialist roles instead of one general assistant. A manager routes the work and holds approvals. A strategist keeps the brief and the essay topics. A writer takes an essay from an idea to a draft ready for Sanity Studio. A reviewer reads it before it goes out. Separate roles cover LinkedIn, X, conversations on Reddit, Hacker News, news, and GitHub, conference talks, press, the health of this site, and the upkeep of the fleet itself.
The instructions live in playbooks. Each role has a short pointer skill and a profile. Scripts check the work deterministically: overlap with past posts, a LinkedIn budget, searches on Hacker News and Reddit, a site audit, routine runs, and a lint of the rules. Changing a playbook is a commit, not an application change.
A person approves what gets published. The repository holds the workflow and the checks. It is not an automated publishing service.
Languages & technologies
Python
Shell
Current state
Playbooks, role profiles, and check scripts are in the repository. Publication stays with the person who approves it.
Tools that keep field observations in structured records and build the trip report from those records.
Private source
PythonShell
More detailsHide details about Field reporting toolkit
About the project
A field trip produces notes, contacts, and a report, and those are easy to blur together. Field reporting keeps them apart. Observations go into structured records for objects, people, organizations, and the trip. The report is assembled from those records, and a second role reviews it.
Git versions the system: schemas, playbooks, scripts, and role profiles. A line-oriented log versions the facts. One append script is the only write path for a record. Other scripts create and activate a trip, validate the records, check the report, and seal an export for delivery. A dry-run trip is included so validation and sealing can be checked without a live trip.
The current design is two roles. Field Report runs the trip: notes, contacts, and the report, which is built from the records rather than from chat memory. Field Review reviews that report. Playbooks hold the instructions. The person running the toolkit is the only one who commits. The roles write files and do not.
Languages & technologies
Python
Shell
Current state
Schemas, playbooks, trip setup, validation, report checks, and export sealing are in the repository, including a dry-run fixture.
A case desk for public-source investigations: collection, resolution, verification, and a report, split across specialist roles.
Private source
PythonShell
More detailsHide details about OSINT desk toolkit
About the project
The OSINT desk toolkit gives an investigation one case record and separates who may do what. A handler coordinates the case. A collector gathers public-source material. A resolver and a verifier work the results. Playbooks describe the investigative method. Role instructions say who may write which records.
A case holds the questions, task tickets, captured artifacts, observations, entities, edges, assessments, hypotheses, and a versioned report. Scripts open a case, say which role to prompt next, claim and finalize tasks, validate the case, and seal an export. A leads index is rebuilt from sealed cases. Offline fixtures and automated tests cover correlation scenarios without calling live services.
Passive collection adapters in the repository cover keyless public sources, including registration data, historical page snapshots, and DNS. A capability inventory separates those adapters from services that still need a key, and from names that are only a catalog reference. Listing a service is not the same as having it connected. The person running the desk prompts the roles and commits the code. The roles do not commit case data.
Languages & technologies
Python
Shell
Current state
Case schema, role playbooks, desk scripts, passive adapters, and offline tests are in the repository. Keyed services stay unconnected until they are configured.
A planned evidence-compilation system for turning source reports into reviewed, traceable case files about adversary behavior.
Private source
More detailsHide details about Adversary Behavior Dossiers
About the project
Adversary Behavior Dossiers is meant to sit downstream of FT3 and FT3c. FT3 names the behavior. FT3c holds the version-pinned crosswalks. A dossier would record a real-world occurrence: the claims, the evidence locators, the chronology, and the classification assertions, with those layers kept distinct.
The design has two planes. A private compiler would acquire authorized sources, extract located claims, reconcile them into occurrences, and propose creating or updating a dossier. A person would resolve a narrow set of high-risk ambiguities and approve a release. The public plane would carry the case file, readable views, STIX 2.1 and MITRE Attack Flow exports, schemas, and a verifier. The compiler would consume a pinned FT3c release. It would not redefine FT3 or author the crosswalks. A framework edge is not evidence that an activity occurred, and a correction would be a new reviewed revision rather than a silent edit.
That pipeline is specified, not built. The repository is a documentation baseline: product requirements, architecture, an implementation plan, and the release boundary. As of the status note dated 29 August 2026, the compiler, public schemas, verifier, generated views, exports, and example dossiers were not implemented. A decision note on 11 September 2026 added an HTML page as a third planned source connector and settled the stage-0 boundary profiles. The repository still contains those documents and no compiler.
Current state
Planned. Documentation baseline only; the compiler and public outputs are specified and not implemented.
