Yeti: Old Dog, New Tricks

The two incident responders explain how Yeti began around 2014 as a way to store and make sense of indicators from network captures and malware samples. Early versions combined a feed ingestor, a MongoDB store and a visualiser called Malcolm, and organised data into observables, indicators and entities linked through tags. Licensing conflicts with AGPL dependencies and aging code eventually pushed the team to rewrite the project more than once.

The current rewrite moves to Apache 2.0 licensing, uses ArangoDB as a graph database alongside Redis, and runs on Python 3.10 with FastAPI and Pydantic. The API is self-documenting and can generate client libraries, and the team says it is deliberately narrowing scope, favouring simple code and adding tests. The bigger change is a move from pure threat intelligence toward digital forensics intelligence. Instead of only flagging known bad artifacts, the platform would suggest what to examine, using classification rules over benign items such as binaries, SQLite databases and Run keys, and combining forensic artifact definitions with filters to narrow large log sets.

The roadmap covers tighter integration with forensic artifact definitions and Turbinia, better graph visualisation, MISP connections, and a Docker Compose setup for quick trials. The closing takeaway is that Yeti aims to become a reusable forensic knowledge base that helps analysts slice their data. In the question period, an audience member with a STIX background encouraged the team to share forensic data models through a standard rather than building one-off integrations.