Security Operations

The Security Operations module governs the posture of your security-operations capability. It is the governance layer above the SIEM, the SOC tooling, and the incident-response runtime. Where your SOC team works alerts in real time, this module captures the governed records: which log sources you depend on, which detection rules you’ve defined, what threat signals you’ve evaluated, which alerts you’ve responded to, what log preservation orders are active, and what forensic cases are in progress.

This module does not own the live alerts, the raw log storage, or the incident response runtime. It owns the register and posture of the security-operations capability so an auditor, regulator, or customer can examine the discipline behind the work.

When you would reach for this

You set up security operations governance when:

• A regulator or framework expects a documented security-operations capability with reviewable posture.
• Log sources need an inventoried register with retention and clock-sync posture.
• Detection rules need governed records: what’s the rule, who tuned it, when, why.
• Alerts and their triage outcomes need to be reviewable beyond the SOC’s own tooling.
• Log preservation orders (legal hold equivalents for log data) need formal records.
• Forensic cases need an audit-grade case file.

You don’t reach for this for the live alert handling, the SIEM tuning console, or the incident response runtime. Those are the SOC’s working environment. This module is the governed record that surrounds them.

What lives in the module

Six record types:

• Log source captures one source of security-relevant log data: its kind, retention, clock-sync posture, owner.
• Detection rule captures the governed record of one detection rule: scope, intent, tuning history, owner.
• Threat signal captures a signal under evaluation that may or may not become an alert.
• Alert captures an alert raised and the triage outcome (with link to incident response if it escalated).
• Log preservation record captures a preservation order on log data tied to a matter or investigation.
• Forensic case captures a forensic investigation file with its scope, custody chain of evidence, and outcomes.

A worked example: a sports betting operator governs its 24/7 security operations

A sports betting operator runs a 24/7 platform across web and mobile. Its security operations capability watches for fraud, account takeover, exploit attempts against the platform, and unusual activity around major events. The SOC operates around the clock; the security operations governance lead, Adeola, sets up Security Operations like this.

Step 1: inventory log sources. Each significant log source becomes a record: the application logs, the WAF logs, the IAM logs, the payment-processor webhooks, the fraud-detection service signals, the customer-support tool, the network flow logs. Each has its kind, retention policy, clock-sync posture, owner, and the SOC tooling that consumes it.

Step 2: detection rules with governance. The SOC writes hundreds of detection rules in its SIEM. The most important ones (high-impact rules, regulatory must-haves) get governed records: the rule’s intent, its scope, who last tuned it, the false-positive rate, the runbook for triage. Less critical rules live only in the SIEM.

Step 3: threat signals queue. When the SOC sees an unusual pattern that’s not yet a confirmed alert, it records the signal. Each signal is triaged: dismissed (not a threat), promoted to an alert, or kept watching.

Step 4: alert records for high-impact alerts. Every high-impact alert (not every alert; the SOC handles thousands) gets a governed alert record with the triage outcome: false positive, contained internally, escalated to incident response. Escalations link to the incident management record.

Step 5: log preservation when matters arise. When a legal matter or investigation needs log data preserved beyond normal retention, a log preservation record is created. The record names the matter, the scope of preservation, the start date, the expected duration. Underlying retention systems honor the preservation.

Step 6: forensic cases. When a confirmed event requires forensic investigation, a forensic case is opened. The case file captures: scope, the evidence collected (with custody chain), the analysis performed, the conclusions, the recommendations.

After a year:

• Log sources are inventoried; gaps in coverage are visible.
• High-impact detection rules have governed tuning history.
• High-impact alerts have governed triage outcomes.
• Log preservation tied to live matters is tracked.
• Forensic cases have audit-grade files.

What you’ll see in the product

Security Operations lives under Governance → Security Operations in the workspace.

Six top-level tabs: Log Sources, Detection Rules, Threat Signals, Alerts, Log Preservation, Forensic Cases.

Every change is captured in the workspace Audit Log.

Common workflows

Inventorying log sources

1. Log Sources → New. Source kind, retention, clock-sync, owner.
2. Review periodically as new systems come online.

Governing a high-impact detection rule

1. Detection Rules → New. Capture the rule’s intent, scope, tuning rationale.
2. Update the record when the rule is retuned.
3. Trend the false-positive rate over time.

Triaging a threat signal

1. Threat Signals → New. Capture what was observed.
2. Triage: dismiss, promote to alert, watch.
3. If promoted, link to the resulting alert record.

Opening a forensic case

1. Forensic Cases → New. Capture scope, intent, evidence-collection plan.
2. As evidence is collected, record custody.
3. Conclude with documented findings and recommendations.

Related

• Incidents - alerts that escalate become incidents.
• Findings - investigation outcomes that need remediation become findings.
• Retention - log preservation interacts with retention rules.
• Risks - patterns surfaced by security operations may become risks.