SIEM Operations SOP

SIEM Operations SOP

Role note: The CISO role is currently pending formal appointment. Until then the CTO acts as interim CISO for sign-offs referenced in this SOP.

1. Purpose

Procedures for operating Wealthy’s Security Information and Event Management (SIEM) platform — detection, triage, response, rule tuning, and evidence generation for regulatory audits.

2. Scope

Applies to all security-monitoring activities across:

• GKE cluster (security namespace)
• GCP audit logs (all projects)
• AWS CloudWatch (integrated accounts)
• Employee endpoints (Mac, Windows, GCP Linux VMs) via Wazuh agents
• GitHub org audit events
• External threat intelligence feeds (OTX + AbuseIPDB)

3. Stack

Wealthy’s SIEM is Wazuh 4.14.4, self-hosted on GKE in the security namespace.

4. Daily Operations

Owner: SRE on-call Time: ~15 min each morning (start of IST business hours)

4.1 Dashboard walk-through

Open https://wazuh.wealthy.systems and review:

4.2 Agent health

1kubectl exec -n security wazuh-manager-master-0 -- /var/ossec/bin/agent_control -ls

• All agents expected to be Active
• Any Disconnected agent older than 24h → ping the employee on Slack to reconnect

4.3 Threat intel freshness

1kubectl exec -n security wazuh-manager-master-0 -c wazuh-manager -- \
2  wc -l /var/ossec/etc/lists/malicious-ioc/*

• Expected: ~10k IPs, ~1.2k domains, ~1.2k hashes
• If counts are 0 → check threatintel-sync s6 service; possibly OTX/AbuseIPDB API key expired

4.4 GitHub Issues triage queue

1gh issue list --repo wealthy/security --label threat-alert --state open --limit 20

Walk through open threat-alert issues:

• True positive → relabel incident, follow Incident Response SOP (SOP-004)
• False positive → close with false-positive label + comment explaining; queue rule tuning (§6)
• Duplicate → close with reference to the open parent issue

5. Alert Response

Trigger: Wazuh emits alert at level ≥ 10 → custom-ai invokes automatically.

Wazuh alert
  └─▶ custom-ai binary
        ├─ Dedup check (rule+IP or rule+agent+desc, 6h window) — skip Gemini if duplicate
        ├─ Gemini Flash — returns priority (noise/low/medium/high/critical) + summary + recommended actions
        ├─ Write to OpenSearch (wazuh-ai-analysis-*)
        ├─ Create/comment GitHub Issue (medium+) — wealthy/security repo
        └─ Notify Telegram + Slack (non-noise)

5.1 Response SLA

5.2 CERT-In reportable check

For every critical / high alert, also check: does this fall under one of CERT-In’s 20 reportable incident categories? If yes — the 6-hour reporting clock starts at detection. See CERT-In Compliance (SOP-002).

6. Rule Tuning

6.1 When to tune

6.2 Where rules live

6.3 Deploying rule changes

1# From wealthy/security repo
2kubectl apply -f wazuh/manager/<changed-configmap>.yaml
3kubectl rollout restart statefulset/wazuh-manager-master -n security

Validate with /var/ossec/bin/wazuh-logtest inside the manager pod before committing to master.

7. Playbooks

7.1 SSH brute force

1. Rule 5763 / fury 100105 fires → level 10 alert → AI triage → GitHub Issue + Telegram + Slack
2. On-call:
   • Confirm source IP on Threat Map dashboard
   • Block source IP at Kong gateway (or Cloudflare WAF if web-facing)
   • Check whether any login succeeded from that IP (search rule.groups: authentication_success)
   • If success → escalate to incident, begin Incident Response SOP (SOP-004)

7.2 Fury auth brute force + known-bad IP

1. Rule 100202 fires (level 13, auto-elevated because IP matches threat intel)
2. Treat as critical by default — this is almost certainly an attack, not user error
3. Block at Kong + Cloudflare immediately
4. Investigate whether the targeted account username has been leaked elsewhere (pwned passwords check)

7.3 GCP IAM anomaly

1. GCP Security dashboard shows spike from a single principal
2. Check gcloud logging read for the raw events
3. If principal is a service account → possible key compromise
   • Rotate the SA key immediately
   • Check for unauthorized resource creation/modification
   • Begin Incident Response SOP (SOP-004) if evidence of compromise

7.4 Threat intel IOC match

1. Rules 100200-100205 or native 99901-99908 fire → AI triage categorizes
2. If IOC is on AbuseIPDB (confidence ≥ 90) → block the IP
3. If IOC is on OTX (named campaign) → investigate whether related indicators (domains, hashes) are also present
4. Add context to the GitHub Issue: which pulse/campaign matched

7.5 Vulnerability detector CVE

1. Wazuh vuln detector creates alert; custom-ai opens GitHub Issue
2. Verify the affected package + version is genuinely installed (Wazuh has version-parsing quirks — e.g. Hoppscotch 26.3.1 vs 2026.3.1)
3. If real: check upstream vendor advisory, identify affected agents, schedule patch per Patch Management SOP (SOP-005)
4. If false positive: document in the GitHub Issue, add rule suppression if recurring

7.6 Repeated noise / tuning needed

1. Same rule firing frequently without actionable signal → tune
2. Label GitHub Issue false-positive and link to rule change PR
3. Measure FP rate for Annexure-N metrics (§8)

8. Metrics for Annexure-N (SEBI half-yearly)

Tracked metrics feeding the SOC Functional Efficacy Report:

Half-yearly: export the above → fill in Annexure-N template → ISRMC sign-off → SEBI submission.

9. Access Control

Account creation / change via OpenSearch Security API — see wazuh/README.md in the security repo. Access reviewed quarterly per Quarterly Access Review.

10. Log Retention

No cold / archive tier. All logs are directly queryable for the full retention window — no restore-from-glacier hop, no tiered lookup. GCP Cloud Logging’s Logs Explorer returns any event within the 2-year window in seconds.

Canonical long-term audit trail lives in GCP (satisfies IRDAI/SEBI/CERT-In retention). Wazuh indexer holds a 30-day rolling window for fast security-specific queries; the full 2-year archive is in GCP.

11. Incident Reporting Evidence

Every incident produces a GitHub Issue in wealthy/security:

Auditor query: gh issue list --repo wealthy/security --label incident --state closed --limit 100

12. Escalation Matrix

13. Related Documents

• Incident Response SOP (SOP-004) — once an alert becomes an incident
• CERT-In Compliance (SOP-002) — regulatory timelines
• Patch Management SOP (SOP-005) — fixing vulnerabilities detected by Wazuh
• Vulnerability Management SOP (SOP-009) — broader vuln handling
• Information Logging Standard (STD-011) — logging requirements
• Log Management Standard (STD-012) — retention and access
• Security repo: wazuh/README.md, docs/wazuh/ — detailed operator reference

14. Review

Reviewed quarterly by the CTO (interim CISO) + SRE Lead. Changes recorded in ISRMC minutes. Next scheduled review: Q3 2026.

Contact: security@wealthy.in