Zero Trust Soldier

Angrepene i Danmark hadde vært avverget umiddelbart med mitt oppsett!

Vi leser om angrep på infrastruktur og systemer hver eneste dag, noen mer alvorlig enn andre. Og majoriteten av dem kunne med ganske enkle grep vært avverget. Og det er her jeg kommer inn. Angrepene i Danmark skulle aldri kommet så langt de kom med grunnleggende konfigurasjon.

Bildet er fra rapporten til SektorCERT i Danmark. Kritisk infrastruktur i Danmark ble angrepet i mai 2023, og litt flaks og meget godt arbeid gjorde at dette ikke ble en katastrofe. SektorCERT har i etterkant utgitt den meget detaljerte rapporten som alle burde lese for å lære. I sum så er det veldig få tekniske ting som egentlig skjer, men alle tingene burde vært avverget på et mye tidligere stadie.

Dette gjør jeg hver dag

Mye av årsaken til at jeg startet for meg selv 1. januar 2023 var fordi jeg etter mange år i bransjen med Palo Alto Networks, som jeg naturligvis mener er markedets beste brannmur, var frustrert over alle de dårlige installasjonene jeg så. Jeg visste hva produktet var kapabelt til, og ikke minst hvorfor det er så viktig med en god installasjon.

Jeg vet at det er mange der ute med Palo Alto Networks brannmurer som trenger hjelp. Noen vet det, mens andre kanskje ikke er så klar over det. Jeg tør påstå at 99% av de med brannmurer generelt trenger hjelp. I en hektisk hverdag er brannmur bare en av teknologiene en IT avdeling skal håndtere og administrere, og så lenge den fungerer får den gjerne lite oppmerksomhet. Med dagens trusselbilde er ikke det å fungere tilstrekkelig.

Se på det jeg holder på med opp mot SektorCERT sin rapport

Selve kjernen i det jeg gjør baseres seg på forståelse og respekt for trusselbildet. Zero Trust antar det verste. Derfor må tiltak på plass for å adressere nettopp det. Dette handler mer om mennesker enn teknologi.

Lagvis sikkerhet og Kill Chain tankesett ligger til grunn.

Det første jeg gjør hos kunder er å strukturere regelsettet. Dette gir en oversikt og kontroll som gir stor verdi, og er noe jeg nærmest aldri ser kunder har på plass før jeg kommer inn.

Dette er rekkefølgen jeg setter opp ting etter:

• Generelle deny regler med dynamiske adresselister øverst som har til hensikt å sperre all kommunikasjon med kjente skadelige og mistenkelige IP adresser, inkludert TOR adresser.
• Inngående regler fra internett
  • Ser man på rapporten fra SektorCERT var første steg i angrepene misbruk av en sårbarhet på IKE. For en kunde med kritisk infrastruktur, og for den del de fleste andre, lager jeg alltid Least Privilege regler som bare tillater IKE fra kjente source adresser. Når dette er på plass kunne ikke sårbarheten blitt misbrukt fordi kommunikasjonen hadde blitt stoppet på et nivå før.
  • Jeg lager Least Privilege baserte inngående regler på alt som trengs inngående, og for de fleste er ikke det veldig mye, så denne oppgaven er som oftest veldig enkel.
  • Ved å kjøre Least Privilege på inngående regelsett, sammen med SSL dekryptering, begrenses angrepsflaten dramatisk, samt at sikkerhetsfunksjoner som IPS kan gjøre jobben med å stoppe misbruk av kjente sårbarheter. Dette ville hjulpet i Danmark dersom Least Privilege ikke hadde vært på plass på tilstrekkelig måte.
  • Det å samle denne type regler gir en visibilitet som også skaper bevissthet.
• Utgående regler for kritiske tjenester
  • Dette er “VG testen” kategorien. Steg 2 av angrepene i Danmark var at brannmurene kommuniserte utgående med nettverket til aktørene for å laste ned konfigurasjoner, etablere bakdører og hente kommandoer. De inngående reglene skulle hindret første del, og man skulle ikke havnet her. Men skulle første del ikke være på plass, ville steg 2 vært stoppet med adressering av VG testen. Jeg bruker tid på å strukturere regelsettet per source for å hviteliste hva hver enkelt enhet trenger av utgående kommunikasjon. Med dette på plass kunne ikke aktørene lyktes med å laste ned de filene de hentet. Dette er også ganske enkelt å adressere.
• Utgående regler for servere og andre verdier
  • Man kan si dette er akkurat det samme som kategorien før, men det er for å skille det litt. Servere, applikasjoner, databaser, domenekontroller, backupløsninger, OT maskiner, osv. Skape oversikt, strukturere og hviteliste utgående kommunikasjon basert på applikasjon, URL og eventuelt IP adresser. Dette vil gjøre det nærmest umulig for de kriminelle å etablere bakdører og laste ned skadevare.
• Og resten
  • Etter de første nivåene kommer det mange oppgaver, som å strukturere videre regelsett. Dette struktureres etter Zero Trust mindset basert på verdier, og det hvitelistes etter Least Privilege prinsippene.
• Optimalisering av policy og regler
  • En Palo Alto Networks Next Generation Firewall har mange sikkerhetsfunksjoner som må optimaliseres for at sikkerheten skal bli så bra som mulig.
  • Suksessfulle hendelser skjer i tillatt trafikk! Med all verdens Least Privilege må trafikk allikevel flyte, og i denne kan skadelige hendelser skje. Dette er meget viktig å være klar over, og er derfor jeg bruker tid på å sikre at alle sikkerhetsprofiler eksisterer på absolutt alle regler, og at de er satt opp etter beste praksis for å være mest mulig motstandsdyktig.
  • DNS sikkerhet er en litt ukjent sikkerhetsmekanisme for mange, men som man ser gjør stor forskjell.
    • Ser man på rapporten fra SektorCERT for hendelsen i Danmark ble det utført kommunikasjon mot [www].joshan[.]pro som på det tidspunktet var 3 uker gammelt. DNS sikkerhet i Palo Alto Networks ville med høy sannsynlighet ha stoppet dette på DNS nivå, da domener som er under 32 dager gamle alltid havner i kategorien “newly-registered-domain” og anbefalt policy er å sperre disse. Dette implementerer jeg alle steder, og jeg vet at det fungerer etter mange tester, bl.a på phishing e-poster.
  • URL sikkerhet ville også hatt relevans i angrepene som skjedde i Danmark.
    • På lik linje som DNS sikkerheten ville URL sikkerheten stoppet kommunikasjon med [www].joshan[.]pro som av Palo Alto Networks ville havnet i “newly-registered-domain“, som også sperres i mine installasjoner.
    • Alle de andre nedlastingene fra brannmurene skjedde mot IP adresser uten bruk av FQDN, og disse ville av Palo Alto Networks havnet i kategorien “unknown”, som også er anbefalt å sperres, noe jeg gjør hos alle mine kunder.
  • IPS sikkerhet har alle brannmurer i dag.
    • Sårbarhetene som ble misbrukt i Danmark var kjent over 2 uker før hendelsene startet, og brannmurene skulle vært oppgradert på det tidspunktet. Ettersom brannmurene ikke var oppgradert var de også sårbare og ble misbrukt. Signaturer for disse sårbarhetene vil som oftest eksistere og være automatisk oppdatert i IPS teknologien på brannmuren, så misbruk av sårbarhetene burde kunne stoppes på dette punktet selv på den sårbare brannmuren. Dette fordrer at brannmuren er satt opp etter beste praksis. Dette sikrer jeg at er på plass hos alle mine kunder.

Threat loggene er en gullgruve for optimalisering

Jeg bruker aktivt threat loggene som viser forsøk på misbruk av sårbarheter. Ved å følge med på disse blir man ofte oppmerksom på unødvendige åpninger i regelsettet og kan stramme inn regelsettet enda mer, redusere angrepsflaten og dermed sårbarhetene.

Konklusjon

Første del av angrepet i Danmark skulle ikke ha skjedd fordi en Least Privilege policy ville forhindret det.

Andre del av angrepet i Danmark skulle ikke ha skjedd fordi adressering av VG testen skulle hindret det.

Hadde ikke de 2 anbefalingene over vært på plass skulle NGFW sikkerhet som DNS sikkerhet, URL sikkerhet og IPS stoppet det sammen med SSL dekryptering.

Har du Palo Alto Networks brannmur, la oss ta en prat, for dette er kjernen av grunnen til at jeg startet for meg selv.