Telemetry Contract Builder
Decide what a new system must log before it ships. Pick its type and get the OCSF events and fields, the ATT&CK techniques they make detectable, the SigmaHQ rules that apply, retention and personal-data flags. Then check real log lines against it.
Sample logs you validate stay in this tab. The share link carries only the contract settings.
Export the contract
Validate sample logs
Generated from the contract. Every user, IP and ID in it is made up.
Next steps in the workbench
How the contract is built
Each event is one OCSF 1.9.0 class and activity, with the fields a detection needs. Every event also carries the OCSF core: time, class, activity, type and severity IDs, metadata version, product, a unique ID, and metadata.event_code naming the contract event. Attributes that an OCSF class or object requires, such as file.type_id under File or algorithm_id under a hash, are added for you and marked OCSF. Data with no OCSF attribute, such as payout amounts or EDI control numbers, goes under unmapped.
Each technique on an event names the fields its detection keys on. Switch a field or an event off and the techniques that depend on it drop out of the score. SigmaHQ matches come from rules for comparable log sources that tag the same technique, checked field by field through a crosswalk from native names (verb, eventName, objectRef.resource) to OCSF paths.
Telemetry contract FAQ
What is a telemetry contract?
A written list of the events a system must log, the fields in each event and their types, agreed before the system ships. Detection engineers use it to make sure the data their rules need exists on day one, and developers use it as an acceptance test for logging.
Why OCSF?
The Open Cybersecurity Schema Framework is an open, vendor-neutral event schema with classes such as Authentication (3002) and API Activity (6003). Writing the contract in OCSF terms means the logs map cleanly into SIEMs and data lakes that speak it. The page uses the OCSF 1.9.0 schema, snapshotted from the OCSF schema server.
How is the coverage score worked out?
Each event lists the ATT&CK techniques it makes detectable and the fields each detection needs. A technique counts as enabled when one switched-on event carries every field it needs. The score is enabled techniques divided by all techniques the chosen system type could cover. Dropping an event or a field shows what you lose.
What do the SigmaHQ matches mean?
For each event the page lists SigmaHQ rules from comparable log sources, such as Kubernetes audit or Okta, that tag one of the event's techniques. It then checks whether the contract carries every field the rule's detection block uses, through a crosswalk from the native field names to OCSF paths. A rule that fits is a ready template for your own log source.
Are my sample logs uploaded?
No. Validation runs in JavaScript on this page. The share link holds only the contract settings, never log lines.
OCSF 1.9.0 schema from schema.ocsf.io, MITRE ATT&CK Enterprise v19.2, SigmaHQ rules at commit 8a48134. Event choices, technique mappings, the Sigma field crosswalk and retention tiers are this tool's own and are suggestions. Sample data on this page is generated and fictional.