Rule Sets

A rule set (or rule pack) is a ready-made bundle of alert rules you can install in one click. Because every obserae deployment names its hosts and services differently, a rule written against your names can’t be shared with anyone else. Rule sets fix that by adding a small standard vocabulary to your cartography — zones, environments, host roles and service purposes — and shipping rules written against that vocabulary, so they work anywhere.

obserae ships with the std.community rule set: a vendor-neutral starter pack of 72 detections (cleartext protocols, exposed RDP, DNS hygiene, database access from the user zone, …) — see The std.community rule set.

How it works in three steps

1. Install a rule set. Go to Rule Sets, upload the pack file (or import the bundled std.community). obserae checks its dependencies and tells you exactly what it will add.
2. Complete and apply the vocabulary. Use Network → Vocabulary for deployment-specific values, then open a network, host or service and pick one from the dropdown — for example mark your user LAN as zone: user, your jump host as role: security.bastion.
3. Enable the rules you want. The rule set’s rules appear on the Rules page (read-only, marked as pack-owned). Toggle them on, or enable/disable the whole pack at once from the Rule Sets page.

That’s it — the rules now fire against your traffic, using your tags.

The standard attributes

Local vocabulary

The Network → Vocabulary page lists all four attribute types and shows where every value came from. Values supplied by a rule set are read-only and carry that rule set’s id. Operators with cartography:write can add local zones, environments, roles and service purposes for deployment-specific terms. A local service purpose includes at least one port/protocol pair.

Local names use lowercase letters, digits, dots, dashes and underscores. The std. prefix is reserved for vocabulary embedded in obserae; use a namespace you control, such as acme.production or acme.payments-api. Local values are durable until explicitly deleted. Before deletion the page lists cartography assignments that will be cleared.

You assign attributes the same way you edit anything else in the cartography — in the GUI editor, or in your cartography YAML:

networks:
  - name: office-lan
    cidr: 10.10.0.0/16
    zone: user
    environment: production
hosts:
  - name: jump01
    role: security.bastion
    services:
      - name: ssh
        protocol: TCP
        port: 22
        purpose: std.ssh

Your cartography is never broken by a rule set. If you import a cartography that uses a value a rule set hasn’t defined, obserae simply ignores that one tag and warns you — it never refuses the import. If you later remove a rule set, the tags it provided are cleared from your entities (you’re shown exactly which, first) and nothing else changes.

Using attributes in NFQL

Once tagged, the standard attributes work in NFQL just like groups:

FROM flows | LAST 300 | WHERE src_addr == "role:workstation" and dst_addr == "internet4"

FROM flows | LAST 300 | WHERE zone:dmz and port_proto == "purpose:std.https"

• zone:, environment:, role: match an address against the set of IPs carrying that tag.
• purpose: matches a port + protocol. Compare it against port_proto (either side of a flow), or server_port_proto / client_port_proto on sessions. For example server_port_proto == "purpose:std.dns" matches traffic to a DNS service (port 53 over UDP or TCP).

A purpose: match is robust to your real deployment. It catches two things at once:

• the purpose’s standard ports anywhere (e.g. any postgres on 5432);
• the actual port of any service you tagged with that purpose, scoped to that service’s own host. So if you tag a postgres service that runs on a non-standard 6666/tcp, purpose:std.postgres detects it — and because the match follows your cartography live, changing the service’s port is reflected immediately, with nothing to recompile. (Tip: when you pick a purpose in the service form, its standard port pre-fills automatically; override it if your service uses a different one.)

Attribute values can contain dots, e.g. purpose:std.dns.

Rule tags and the compliance mapping

Every rule carries a list of tags — free-form labels you can filter and search by on the Rules and Anomaly Detection pages. Tags are stored lower-cased, trimmed and de-duplicated, and the pack’s own id is always added as a tag automatically (so std.anomaly rules are all findable by that tag).

The shipped packs (std.enterprise is the reference, and std.anomaly follows it) use a small, consistent tag vocabulary so you can slice the rule set by threat, behaviour or compliance obligation. Three groups:

• Topic tags — what the rule is about: exfiltration, lateral-movement, scanning, recon, c2, brute-force, credential-access, egress, segmentation, exposure, dns, sweep, …
• Behaviour markers — how the rule works: behavioral (a statistical / baseline detector), heuristic, tuning-required, requires-enrichment, requires-flow-matrix, compliance-evidence (the rule is intended as audit evidence for a framework).
• Framework tags — the mapping to security frameworks, each a lower-case framework-code (a hyphen, never a colon, and dots are allowed in the code):

  Framework	Tag format	Example
  MITRE ATT&CK	attack-<technique>	attack-t1041, attack-t1595.001
  CIS Controls v8	cis-<control>	cis-13, cis-13.6
  SOC 2 (Trust Services Criteria)	soc2-<criterion>	soc2-cc7.2, soc2-cc6.1
  ISO/IEC 27001 (Annex A)	iso27001-<control>	iso27001-a8.16
  NIS2	nis2-<article>	nis2-art21
  DORA	dora-<article>	dora-art10

For example, the std.anomaly detectors all carry behavioral, compliance-evidence, nis2-art21 and dora-art10 (they are anomaly-detection mechanisms), plus their specific attack-…, cis-… and soc2-… tags — so a filter like soc2-cc7.2 or attack-t1046 pulls up exactly the rules that answer that control or technique. When you write your own rules, reuse the same conventions so your pack composes with the shipped ones.

Managing rule sets

On the Rule Sets page you can:

• Install a pack from a file, with a dry-run that shows added attributes, rules and any dependency or conflict before you commit.
• Upgrade a pack by installing a newer version — your enable/disable choices are preserved.
• Enable / disable a whole pack at once.
• Delete a pack — obserae first shows you which cartography tags will be cleared, and refuses if another installed pack depends on it.

Business, Business+, and Enterprise licenses include the shipped std.enterprise and std.anomaly packs. In Community they remain installed and visible, but their rules are skipped by the evaluator and the packs cannot be changed. std.community and custom rule sets continue to work. Renewal reactivates the preserved professional packs without an import or reinstall.

A rule set’s rules are read-only: you can enable, disable or duplicate them (to make your own editable copy), but you can’t edit the originals — the pack file is their source of truth.

Dependencies and versions

A rule set can require another one (for shared attributes), with a version constraint:

package:
  id: yourorg.baseline
  version: 1.0.0
  requirements:
    - std.community>=0.1.0

obserae won’t install a pack until its dependencies are present at a compatible version, and won’t let you delete a pack that another installed pack still needs.

Backup & restore

When you export your configuration, obserae records the local vocabulary, which rule sets are installed and which of their rules are enabled — but not uploaded pack contents themselves. Local values include service-purpose ports and are restored before cartography, so their assignments survive a move to a blank instance. Per-rule enable/disable choices are then re-applied.

If a referenced pack isn’t installed yet:

• the bundled std.community pack is installed automatically during the import, so restoring a configuration no longer means installing it by hand first;
• a pack you uploaded yourself is not in the config bundle, so you still get a reminder to upload its file.

Older configuration files (from before rule sets existed) still import without any changes.

Writing your own rule set

A rule set is a single YAML file. The Writing a rule set guide is the exhaustive reference — the file format, every field, the requirement (dependency) notation, versioning, the vocabulary and the rule syntax. See the NFQL guide for the query language. The minimal shape:

package:
  maintainer: your org
  version: 1.0.0
  id: yourorg.baseline
attributes:
  purpose:
    - name: yourorg.https
      comment: HTTP over TLS
      ports: [443/tcp]
rules:
  https-from-guest-zone:
    description: Guest devices reaching internal HTTPS services.
    query: 'FROM flows | LAST 300 | WHERE src_addr == "zone:guest" and dst_addr == "zone:server" and port_proto == "purpose:yourorg.https"'
    condition: presence
    severity: medium
    cadence: 1h
    cooldown: 1h
    tags: [segmentation]