zsazsa CTI

zsazsa is a CTI program management and production platform built around MISP. It links collection, triage, analyst workflows, requirement management, publishing and stakeholder delivery in one place, for teams that want to run threat intelligence as an operational capability rather than as loose documents and disconnected scripts.

To set zsazsa up, follow the quickstart: install it with Docker or next to MISP, configure it with the setup wizard, and publish a first briefing. INSTALL.md has the installation in full. If you are upgrading, read CHANGELOG.md first.

This README has two parts. The first describes what zsazsa does and how analysts work with it. The second, the reference, has the details.

Using zsazsa: Intelligence flow · Intelligence products · Reviewing and publishing · Distribution · What the analyser does · Newsletters

Reference: The analyser in detail · Indicator feed URLs and caching · Newsletter import in detail · Configuration · MISP model

zsazsa is developed with the support of AI.

Overview

Intelligence flow

zsazsa follows the daily CTI workflow, from collection through triage and analysis to publishing and feedback. The main areas are:

• Dashboard: active PIRs and GIRs, stakeholders, analyser status and products waiting for review.
• Stakeholders: who receives your output, with role, organisation, TLP, product subscriptions and notification channels.
• Requirements (PIR and GIR): the intelligence questions that drive collection, with their scope, ownership and distribution.
• RFIs: one-off requests from intake to closure, with an SLA, an owner and a linked PIR or GIR.
• Data collection: the cached view of every source, where you triage events, enrich them, summarise them with AI and start a product.
• The analyser: reads what you collected and drafts the daily threat briefing, flash intel alerts and vulnerability advisories for an analyst to review.
• Products: flash intel alerts, vulnerability advisories, daily threat briefings, threat landscape reports, indicator feeds, threat actor profiles and detection engineering requests.
• Statistics: pipeline and program metrics, scope coverage, and a CTI-CMM maturity panel.
• Background jobs and the Pipeline page: what is running, and afterwards what became of each event.

Audit trail in MISP

zsazsa keeps its data in MISP as events, objects, attributes and event reports, so teams can review the raw records directly in MISP. The MISP event history is an audit trail of every change to a product, stakeholder or requirement.

Dashboard

The dashboard gives an operational overview: pipeline state, active requirements, stakeholders and recent analyser results. Products to review shows, per product type, how many wait for a review or are drafts.

Stakeholders

A stakeholder is linked to an organisation and has an internal or external role, contact details, a TLP clearance, product subscriptions and delivery preferences. Stakeholders own PIRs and GIRs or are in their distribution, and the list can be exported as Markdown. A stakeholder's page puts the scope items of those PIRs and GIRs beside the focus points, each a link to its line in the scope and focus points statistics.

On the stakeholder matrix you record each stakeholder's power over your CTI program and their interest in its output.

Requirements

PIR

A PIR holds the intelligence question, the decision it supports, its intelligence level, priority and sub-questions. Give it scope items, such as a geography, sector, threat actor, technique, vendor and product, or a campaign, and data collection highlights the events that match.

Triage acknowledges, approves, defers, rejects or merges a submitted PIR.

The PIR detail page combines scope, sub-questions, ownership, distribution and collection mapping.

GIR

A GIR records intelligence needs over longer cycles, with a review cadence, scope and expected outputs. A PIR can be linked to the GIRs it falls under.

RFI

An RFI goes from intake to closure with a priority, SLA, owner, linked requirement and response tracking. Its detail page holds notes, attachments and the requester's feedback.

Data collection

Data collection is the central place for the daily work: a cached view of every source you set up, the MISP scraper, other MISP servers, and the manual and newsletter sources, with filters for source, tags and context.

CTI evaluation scores an event's relevance and confidence during triage.

An event you do not want to see again is set aside. On your own MISP it is rejected (workflow:state="rejected"); an event from another MISP server is dismissed with the local tag zsazsa:event="dismiss".

An analyst can enrich an event with scope from the MISP galaxies: geography, sector, threat actor and techniques.

This is the beginning of the README. Read the rest at the original. Read the full README ↗