Er Cortex XDR konfigurert til å ignorere uønsket aktivitet hos deg?

Forfatter:

Erik Wie

[email protected]

Erik er "all-in” på logging. Dette fordi logger gir unike muligheter til å skjerpe sikkerheten, når bedre prosesser skal etableres, og for å sanke verdifull innsikt når nye tjenester skal skapes. I en hybrid verden er Splunk særlig viktig for å sikre den beste ressursutnyttelsen på tvers av skyer.

Det er fort gjort å gjøre graverende feil

Når jeg er ute på oppdrag hos kunder for å bistå med incident handling og etterforskning i Cortex XDR, så tar jeg alltid en liten titt på regelsettet for Alert Exclutions. Her finner jeg ofte regler som ikke er helt gunstig designet. Denne artikkelen tar for seg et konkret eksempel jeg oppdaget tidligere i år.
Jeg oppdaget da en regel for en server som umiddelbart tok oppmerksomheten min. Regelen hadde et beskrivende navn og anga at det var en regel for diverse aktiviteter. Her er altså tanken at det skal være en regel som omfavner flere unntak i en og samme regel, noe som ikke er noe problem. Problemet er at regelen som var laget inneholdt kun 2 kriterier, navnet på server og IP adresse. Ved andre ord så kunne denne serveren utføre hva den ville i nettverket uten at Cortex XDR ville trigge på noe av aktiviteten.

Hvordan kan dette skje

Det er sikkert mange grunner til at denne regelen har blitt laget slik som den ble. En bevisst handling kan ikke utelukkes, men er lite sannsynlig. Manglede kunnskap er mer sannsynlig. Vi kan heller ikke utelukke systemsvikt eller menneskelig svik, hvor ofte opplever en ikke å sitte dypt konsentrert om en oppgave også blir en forstyrret av en telefon eller noen som kommer innom på kontoret. Det kan være fort gjort at en endring ikke ble lagret.

Hvorfor lager vi unntaks regler?

Cortex XDR bruker blant annet Identicator of compromise (IOC) og Behavioral indicator of compromise (BIOC). Dersom Cortex XDR oppdager aktivitet som stemmer med f.eks. en IOC/BIOC regel så lages det en alert. Noen ganger er denne aktiviteten faktisk den ønskede aktiviteten, og du får da en del falske positive alerts. F.eks. vil en sårbarhets scanning trigge en alert. Men siden du ikke vil slutte med sårbarhetsanalyser og du ikke vil fjerne IPC/BIOC reglene, så lager du et unntak basert på alerts du allerede har sett og Cortex XDR vil da automatisk avslutte alle alerts som passer med regelen.

Hvordan praktisere best practise for unntaksregler

Den generelle anbefalingen jeg vil gi for unntaksregler i Cortex XDR er å skrive reglene så granulerte som du kan. Ikke vær redd for å lage store regelsett og utnytt muligheten til å bruke OR til å sette samme uavhengige kriteriesett til en samlet regel. Dersom du opplever at det blir vanskelig å holde oversikt på store regelsett, så kan hvert av OR kriteriesettene lages som egne regler.
La oss se på den overnevnte regelen og se hvordan vi endte med en regel på 54 kriterier fordelt på 4 kriteriesett.

Når du skriver eller redigerer på en unntaksregel, viser Cortex XDR deg alle alerts som passer med kriteriene du har lagt inn. Siden den opprinnelige regelen bare inneholdt feltene «host» og «host IP» vises alle alerts som gjelder denne serveren. Dette ga meg informasjon om antall alerts og det forteller meg hva slags alerts som er blitt skapt av denne serveren til nå.

Jeg ser da at det dreier seg om 2 kategorier, hver med et par varianter under seg. Jeg ser også at jeg ikke kan dekke alle med ett og samme kriteriesett. Jeg noterer meg hvilke kategorier og hvilke alert name som det skal lages regel for før jeg definerer de første kriteriene.

Når det første kriteriesettet er ferdig designet består det av følgende felter for å påse at det ikke kan utføres andre funksjoner på denne regelen enn det som er tiltenkt. “Host, Host IP, Alert Source, Action, Category, Alert Name, Initiated By, CGO SHA256, CGO Name, CGO path, CGO signature, CGO signer, Mitre ATT&CK Tactic, Mitra ATT&CK Technique.”
Dette kriteriesettet tar høyde for at serveren må ha riktig navn og IP, alerts må trigger samme kilde, handling og kategori. I dette tilfellet er det en prosess som tillates å kjøre, der er det spesifisert hvilken prosess ved filnavn, filsti, fil hash og signatur for å være helt sikker på at det ikke er blitt infisert en ondsinnet fil med samme navn og eventuell filplassering. I tillegg gir denne prosessen treff i Mitre ATT&CK rammeverket, derfor spesifiseres både Mitre ATT&CK taktikk og teknikk i kriteriesettet.

Et av de andre kriteriesettene ble slik. “Host, Host IP, Alert Source, Action, Category, Alert Name, Event Type, Remote IP, Mitre ATT&CK Tactic, Mitre ATT&CK Technique, Source Zone Name, Destination Zone Name, FW Rule Name.“
Dette kriteriesettet gjelder for nettverkstrafikk. Kriteriesettet starter med de samme feltene som det forrige, ved å spesifisere hva slags event type dette er, hvilke IP ‘er trafikken får lov til å gå mot, Mitre informasjon, vi spesifiserer til og fra zoner og brannmursregel fra Palo Alto Networks NGFW brannmuren. Om trafikken plutselig går mot en annen IP enn tidligere, det gjøres endringer i brannmuroppsettet slik at trafikken treffer en annen regel eller navn på regel endres vil ikke lenger alertene automatisk bli lukket og du vil få varsler i Cortex XDR på dette.

Når du har laget ferdig alle kriteriesettene og fortsatt står i redigering av regelen, er det viktig at du kontrollerer at antallet alerts som vises i listen under regelen stemmer med det antallet som ble notert før du spesifiserte mer enn bare servernavn. Dette vil verifisere at du har fått med deg alt.

Slik kan du opprettholde kontroll på regelsettene

Det er viktig at alle eksklusjons regler du har i Cortex XDR blir gjennomgått regelmessig. Slik kan du oppdage regler som ikke gjør som tiltenkt. I eksemplet her var det snakk om en feil konfigurert regel. Det kan være at reglen ikke ble lagret i arbeidsprosessen på grunn av systemsvikt eller menneskelig feil. Men regler på utstyr som er avviklet/fjernet og gjenbruk av IP ’er til annet formål kan begge gi manglende alarmer og falsk trygghet, som gir grunnlag for feilkilder og mulig kritiske konsekvenser

I en gjennomgang må en gå igjennom alle regler, alle kriterier og reglene må sees i sammenheng med alertene de påvirker. Gjennomgangen kan være tidkrevende hvis det er mange regler. Da kan det være lurt å dele det opp og f.eks. ta litt hver uke eller måned. Dokumenter det som er utført så finnes historikk ved neste gjennomgang av reglene.

Trenger du bistand med gjennomgang av regler kan vi hjelpe deg med dette.