Talon Studio measures ATT&CK coverage from the telemetry you already collect, authors detections as code and ships them to your SIEM through Git — validated before anything reaches production.
ATT&CK coverage from the telemetry you have, and detections shipped through Git.
EVERY PAGEThe product's own sidebar. Press any of the thirteen sections, or any page inside one.
NON-BLOCKINGOpen change requests only turn it amber.
LANDEDGreen once a target holds an app, a push or an export.
CLAW PROPOSESCoverage gaps, new KEVs and failed validations queue here, each with the agent that would take it on.
HANDOFFSAn agent that needs another's skills hands the card on, and writes down why.
LINKED TO THE WORKA card links what it is about: the gap, detection, CVE, case or change request, and the request's state.
DEPLOYMENT STATUSEach workspace's deploy state, and the share of them that is live in a SIEM.
PORTFOLIO ACTIVITYChange requests opened and detections deployed each day, across every workspace.
SIEM DISTRIBUTIONWhere each workspace deploys: Splunk, Sentinel, Elastic or Chronicle.
NEW WORKSPACEA name, the SIEMs it deploys to, the first one its default, and an optional description.
DEPLOY STATEThe rocket and the bar above it: green once deployed or ready, red when blocked, amber while in progress or empty.
PACKAGE ON SPLUNK ONLYSplunk ships the workspace as one app. Sentinel, Elastic and Chronicle push each detection live, and their pipeline has no Package step.
CONNECTION TOPOLOGYEvery SIEM and pipeline the workspace reaches, each line in its vendor's colour and each dot in its health.
CONNECTION DETAILSEach connection's endpoint, last sync and state. One in error shows what it last returned.
CONNECT A SIEMSplunk, Sentinel, Elastic or Chronicle. A connection reads, deploys, or both, and a Splunk one can also be a test target.
ONE CARD PER SIEMIts deploy target shares the card and its one status. Check tests the target with tokens used for that request and never stored.
ADD A SOURCEGitHub, GitLab, Gitea, Azure DevOps or a public repository, read as Sigma, Talon, Splunk, Sentinel, Elastic or Chronicle rules.
ONE CARD PER REPOSITORYIts format, branch and the commit it last read. Open it to list what it imported and fork a rule into the workspace.
THE WORKSPACE'S REMOTEOne per workspace, on GitHub, GitLab, Gitea or Azure DevOps: the workspace's detections, as the YAML files in its own Git repository.
ADD AN INTEGRATIONCribl, Vector or Logstash pipelines, CrowdStrike or Defender XDR, VirusTotal lookups, or a ServiceNow CMDB.
READ-ONLYTalon pulls the pipelines, routes, sources, destinations and health. The secret is encrypted at rest and never shown again.
COVERAGE THAT MATTERSMeasured against the exploited CVEs your threat profile makes relevant, not the whole catalogue.
THE WHOLE CATALOGUEEvery CVE CISA lists as known exploited, by severity and ransomware use, and the share you cover.
WEIGHTED BY PRIORITYThreats count by priority: in full once live, half while a rule waits to deploy.
TWO KINDS OF GAPNo telemetry: a library rule can't run on your data. Uncovered: no rule names it.
FIND A TECHNIQUEType an ID or a name and the matrix narrows to the techniques that match.
OVERLAY AN ADVERSARYPick an ATT&CK threat group or campaign and only the techniques it uses stay on the matrix.
DEPLOYED COVERAGEThe Command overview's covered share, beside NIST 800-53 controls covered and library rules ready to deploy.
ATT&CK COVERAGEThe share of techniques you cover, every tactic ranked weakest first.
MITRE ATT&CK MAPA bar per technique: saved, recommended for your telemetry, or in the library.
BY SOURCEThe library by where it came from, beside the rules your workspaces wrote.
ONE LIBRARYSplunk, Sigma, Sentinel KQL, YARA-L and FalconFriday rules, synced and searched together.
DEPLOYABLE NOWLibrary rules this workspace's SIEM has the data to run, less any already enabled there.
ON SIEMEvery rule the last sync found on the SIEM, matched to library rules by name.
ANALYTIC STORIESSplunk's threat-based bundles from its security content. The sidebar lists this page only for a workspace on Splunk.
DETECTIONS MAPPEDEvery story's library rules added up, so a rule in three stories counts three times.
THE TELEMETRY CATALOGEvery data source in Splunk's security content. The sidebar lists this page only for a workspace on Splunk.
REQUIRED BY A DETECTIONThe data sources at least one library rule names as the telemetry it needs to fire.
REPLAY HEALTHPass rate, share replayed and drift-free, then every run in the window by result.
RECENT REPLAY RUNSEach run's events matched out of events tested. A failure carries a button to hand it to Claw.
ENVIRONMENT READINESSCan each detection run in the connected SIEM: its indexes, sourcetypes, CIM data models, macros and lookups. A failure never blocks a deploy.
SIMULATION BONUSDid the detection fire on replayed attack telemetry? Merging a change request replays its detections against the workspace's Splunk test target.
OPEN ALERTSAlerts your deployed detections raised that no one has worked yet.
CRITICAL / HIGHHow many of those alerts are critical or high, on a card of their own.
RESOLVED CASESCases closed, and how many of them were false positives.
PENDING ALERTSAlerts waiting on a decision across every SOC workspace you can reach.
MAPPED TO A DETECTIONAlerts traced to the Talon detection that fired them.
CRITICAL / HIGHThe critical and high alerts, which also sort to the top of the table.
EVERY CASE, BY STATUSEvery case you can see. The filters narrow the table, not these counts.
ACTIVE NOWAnalysts with any action in the audit log in the last eight hours: a stand-in for presence, not a live online status.
ASSIGNED OPEN CASESOpen and investigating cases assigned to anyone on the roster, across every SOC workspace you can see.
TRUE POSITIVE RATETrue positives as a share of the cases given a disposition.
TIME TO RESOLVEThe mean time from a case opening to its closing, across the cases closed in the period.
AUTOMATIONS BY TRIGGERWhat starts each automation, from a schedule or a webhook to someone pressing Run.
RECENT RUN STATUSHow this workspace's recent automation runs ended: succeeded, still running, or failed.
SWARM ACTIVITYAgent runs started each day in this workspace, over the last 7, 14 or 30 days.
TOKEN CONSUMPTIONTokens in and out across the organisation over 30 days, chat included, and the models that served them.
BUILD YOUR OWNA new agent gets its own prompt, tools, skills, automations and model, and is propose-only like the rest.
ORGANISATION CONTEXTGuidance every agent and the assistant follow, under each agent's own prompt. It cannot grant tools.
BY DAYConversations sit under Today, Yesterday, the previous 7 and 30 days, then by month.
@ AN AGENTTyping @ addresses the next message to one agent, and the message keeps its badge.
HOUSE SKILLSYour own playbooks list first, each for the whole organisation or one workspace.
WRITE ONENew skill opens a Markdown playbook with its sections laid out, for agents to search and pin.
THREE VIEWSGraph, Chain and Neural draw the same organisation, and a selection follows you between them.
WHAT IS OWEDHow many agents, the functions the seven departments owe, and how many no enabled agent does.
UNPRICED IS NOT FREESelf-hosted models and the subscription engines are counted and marked unpriced, so the total reads as a floor.
THE CACHE SHAREHow much input was read from the prompt cache, the biggest lever on what a run costs.
FALLBACK CHAINThe first enabled global provider answers; the ones after it are its fallbacks.
PER WORKSPACEA provider scoped to one workspace overrides the global one there.
ACCOUNT AT A GLANCESign-in method, two-factor state, workspaces and detection changes, and how long since your last recorded activity.
TWO-FACTOR, SET HEREA password account adds an authenticator app on this page. An SSO account takes its two-factor policy from the identity provider.
CONFIGURATION AS CODESettings, users, roles, teams and agents, as YAML files in the org's git repository.
NO SECRETS IN GITAPI keys, tokens and password hashes stay in the database, never in these files.
TWO-FACTORPassword users must add an authenticator app first; SSO is exempt.
NO SEAT CAPActive users against the licence's limit, ∞ on Enterprise.
THREE PROVIDERSGitHub, Google or Microsoft Entra ID, each set up once. Add provider offers only the ones not yet configured.
SELF-REGISTRATIONOn, a first sign-in from a verified email creates the account at the provider's default role, within the seat cap. Off, only existing users get in.
NO OWNERSHIP CLAIMEDStudio indexes third-party detection libraries for coverage mapping, recommendations and validation, and says it does not own their rules.
SLACK, TEAMS OR EMAILA destination is an incoming webhook or an SMTP server, with its own pick of 15 event types and a minimum severity.
STATUS FROM THE LAST SENDConnected or Failed is the result of the last test or delivery, and Last test is when it happened.
BEARER TOKENS ONLYEvery /api/v1 call carries an API token in a Bearer header. Session cookies are never accepted there.
THE SPEC ITSELFThe reference is drawn from the OpenAPI 3.1 document the instance serves at /api/v1/openapi.json.
Ask Talon ClawClawacme-detectionsmainSplunkDEPLOYED
All thirteen sections, sixty-eight pages, open from the sidebar. Illustrative: the layout, labels and states are Talon Studio's own; the numbers are made up.
Illustrative data — the layout, labels and states are Talon Studio's own.
Author a detection once, in Sigma or your SIEM's own query language. Studio converts it with pySigma on deploy and ships it to any of the four, and the rule stays in your Git as a change request — reviewed before it goes out, with one-click rollback if a deploy misbehaves.
splunkSigma→SPL
Microsoft SentinelSigma→KQL
elasticSigma→EQL
Google ChronicleSigma→YARA-L
The Community Edition connects 1 SIEM and deploys to 1 target; several at once is Enterprise. The four targets
root_login.yml
title:AWS Root Console Login
logsource:
product:aws
service:cloudtrail
detection:
selection:
eventName:ConsoleLogin
userIdentity.type:Root
condition:selection
level:high
Converted on deploy — author once, ship to every connected SIEM.
The security team: seven departments, the work each one owes, and whether an agent is doing it.How it works
All
24 FUNCTIONS · 7 DEPARTMENTS · 10 AGENTS · 26 TOOLS · STATES ILLUSTRATIVEEvery department lists the work it owes, and who owns each piece.Each piece of work is running, idle, can’t reach or unowned — or kept with a person.Agents propose. This work stays with a person by design.The work an agent owns, and the tools that work cannot be done without.
The whole workspace24 functions
Seven departments, each with the agents staffed into it, the work they own and the tools that work needs. In the middle, the work kept with a person and the tools more than one department uses. Pick a department, or step through them under the stage.