Deteksjonsutvikling med Sigma: Fra regel til produksjon

De fleste SOC-team drukner i alarmer — men fanger likevel ikke de ekte truslene. Problemet er sjelden verktøyene. Det er deteksjonsreglene. Generiske, leverandørleverte regler gir støy. Skreddersydde regler bygget for ditt miljø gir faktisk sikkerhet.

Hva er Sigma?

Sigma er et åpent, plattformuavhengig format for å skrive deteksjonsregler. Tenk på det som YARA for loggdata. Du skriver regelen én gang i YAML, og konverterer den til KQL (Sentinel), SPL (Splunk), Lucene (Elastic) eller andre SIEM-formater.

Eksempel: Oppdage Kerberoasting

Kerberoasting er en vanlig teknikk for å stjele service account-passord fra Active Directory. Slik ser en Sigma-regel ut:

```yaml title: Kerberoasting Activity Detected status: stable logsource: product: windows service: security detection: selection: EventID: 4769 TicketEncryptionType: '0x17' TicketOptions: '0x40810000' filter: ServiceName|endswith: '$' condition: selection and not filter level: high tags:

• attack.credential_access
• attack.t1558.003

```

Denne regelen fanger TGS-forespørsler med RC4-kryptering (0x17) som ikke er rettet mot maskinkontoer — et klassisk Kerberoasting-mønster.

Detection-as-Code

Deteksjonsregler bør behandles som kode:

• Versjonskontroll — Alle regler i Git med pull requests og code review
• Testing — Valider regler mot kjente angrepsscenarier før produksjon
• CI/CD — Automatisk konvertering og deploy til SIEM ved merge
• Dokumentasjon — Hver regel har en tydelig beskrivelse, MITRE ATT&CK-mapping og respons-playbook

Slik bygger du et deteksjonsprogram

1. Kartlegg trusselbildet

Start med MITRE ATT&CK og identifiser teknikker relevante for din bransje og infrastruktur. Ikke prøv å dekke alt — prioriter basert på risiko.

2. Inventar loggkildene

Du kan bare detektere det du logger. Kartlegg hvilke loggkilder dere har (Windows Event Log, Sysmon, firewall, proxy, AD) og identifiser hull.

3. Skriv målrettede regler

Fokuser på høy-fidelity deteksjoner som har lav false positive-rate. Én god regel som fanger ekte angrep er bedre enn hundre som genererer støy.

4. Tune kontinuerlig

Etter deploy, overvåk alarmer og juster terskler. Whitelist kjente prosesser. Mål detection rate og mean time to detect (MTTD).

5. Trusseljakt

Bruk hypotesedrevet trusseljakt for å finne det reglene ikke fanger. Funn fra trusseljakt blir nye deteksjonsregler — en kontinuerlig forbedringssyklus.

Vanlige feil

• For brede regler — gir alarmrtretthet og SOC-analytikere som ignorerer alarmer
• Manglende kontekst — i alarmer — analytikeren vet ikke hva de skal gjøre
• Ingen testing — — regler som aldri ble validert mot ekte angrep
• Statiske regler — — trusselbildet endrer seg, men reglene gjør det ikke

ForSec bygger deteksjonsprogrammer fra grunnen — fra loggkartlegging og regelutvikling til CI/CD-pipelines og kontinuerlig tuning. Ta kontakt for å diskutere hvordan vi kan styrke deteksjonskapabiliteten din.