Least Privilege policy

Tematikk:

Dagens trusselbilde er brutalt. Internett er stort. Løsninger er kompliserte. Sårbarhetene og nulldagssårbarhetene florerer.

Dette er grunnen til min hovedoppgave ute i felten, optimalisering av sikkerhet.

Brannmuren gjør en dårlig jobb. Brannmuren gjør bare det den får beskjed om, og om design og oppsett ikke er bra, blir heller ikke sikkerheten bra. Og det er her jeg kommer inn. La oss få det beste ut av investeringen dere har gjort.

Etter mange år i bransjen med Palo Alto Networks brannmurer har det ofte frustrert meg at markedets beste brannmur i all hovedsak gjør en dårlig jobb. Dette skyldes flere ting, som bl.a en overbelastet IT avdeling som skal håndtere alle IT løsninger, der brannmuren bare er en av dem. Mange er fornøyd når den fungerer og lar det skure og gå. Veldig skummelt.

La meg hjelpe

Jeg begynte å jobbe med Palo Alto Networks brannmurer i 2012, og har jobbet utallige timer med dem siden da, både på egen løsning, men også hos flere kunder. Min misjon er å lage et så bra regelsett som overhodet mulig for å motstå dagens angrep. Dette skjer basert på et Assume Breach tankesett, som betyr at jeg antar at uvedkommende vil først og fremst prøve, og deretter lykkes med å komme seg inn i systemene. Basert på dette bruker jeg Zero Trust og Least Privilege for å bygge sikre nettverk, sammen med kunden.

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
    • Jeg lager alltid Least Privilege regler som bare tillater eksplisitt det som trengs av inngående kommunikasjon for at løsninger skal fungere. Dette er for de fleste 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 og URL-sikkerhet kan gjøre jobben sin med å stoppe misbruk av kjente sårbarheter.
    • Det å samle denne type regler gir en visibilitet som også skaper bevissthet.
  • Utgående regler for kritiske tjenester
    • Dette er “VG testen” kategorien. Jeg bruker tid på å strukturere regelsettet per source for å hviteliste hva hver enkelt enhet trenger av utgående kommunikasjon. Dette er også ganske enkelt å adressere. Med dette på plass vil det ikke være mulig å opprette utgående kommunikasjon for å laste ned skadevare, eller opprette Command & Control (C2).
  • 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. Her bruker jeg Palo Alto Networks sine Best Practice anbefalinger, sammen med IronSkillet, samtidig som jeg aktiverer AIOps som er gratis.
    • Suksessfulle hendelser skjer i tillatt trafikk! Dette er en meget viktig ting å 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 å bli mest mulig motstandsdyktig.
    • DNS sikkerhet er en litt ukjent sikkerhetsmekanisme for mange, men som man ser gjør stor forskjell.
      • Dette implementerer jeg alle steder, og jeg vet at det fungerer etter mange tester, bl.a på phishing e-poster.
      • Dette er ikke en funksjon man bare aktiverer, da man må sikre at den er satt opp i tråd med beste praksis for å stoppe alt mistenkelig. Altfor ofte opplever jeg menneskers manglende kompetanse rundt teknologi og trusselbilde som en ren trussel mot sikkerheten.
    • URL sikkerhet ville også hatt relevans i angrepene som skjedde i Danmark.
      • På lik linje som DNS sikkerheten kan URL sikkerhet f.eks stoppe aktivitet mot destinasjoner som er kategorisert som “newly-registered-domain“, som alltid sperres i mine installasjoner. Dette er enkelt og effektivt. I tillegg skal mange flere URL kategorier sperres, og mange som vanlige IT administratorer ikke tør å sperre, igjen grunnet manglende kompetanse.
      • Skulle utgående aktivitet skje uten FQDN, og da rett mot IP adresser, vil Palo Alto Networks plassere dette i kategorien “unknown”, som også er anbefalt å sperres, noe jeg gjør hos alle mine kunder.
    • IPS sikkerhet har alle brannmurer i dag.
      • IPS har eksistert i “alle” år, men kan bli en falsk trygghet uten tilstrekkelig visibilitet. For å få til dette i dagens miljøer er SSL/TLS dekryptering en nødvendighet. Dette er heldigvis enkelt å få på plass, men dessverre noe de færreste har på plass grunnet feil antagelser. Dette hjelper jeg kunder med å få på plass.
    • Logging er viktig. Det er også viktig å sikre at man har logger langt nok tilbake i tid, både fra et operasjonelt ståsted, men spesielt også fra et sikkerhets ståsted mtp hendelseshåndtering. Ser altfor ofte at dette er en svakhet med altfor lite historikk.
      • Logging til eksterne sikre kilder er også meget viktig, og noe som aktiveres

AIOps med Best Practice gir oversikt

Det er mange ting å ta tak i for optimalisering. De jeg nevner over er de jeg mener har størst proaktiv og preventiv effekt. I tillegg er det mange andre ting man kan og bør gjøre. AIOps er et gratis verktøy fra Palo Alto Networks som jeg aktiverer for kunder. Dette gir et fantastisk totalbilde og viser hvor løsningen kan ytterligere optimaliseres.

La oss ta en prat

Dette er det jeg brenner for og som jeg synes er veldig spennende å jobbe med. La oss ta en prat for å vurdere deres løsning og muligheter for optimalisering, for det er mest sannsynlig mye å hente, og det ville vært synd om noe skadelig skjer fordi løsningen kjører på 25%.

Picture of Gøran Tømte

Gøran Tømte

Gøran har jobbet i bransjen siden 1996 og trives best med ukjente utfordringer. Er utdannet høgskole ingeniør innen telematikk, og kontinuerlig selvlært innen sikkerhet basert på gode kollegaer, bransjen og generell nysgjerrighet og interesse

KONTAKT

Andre artikler

Stay Connected

More Updates

Leverandørkontroller

Viktigheten av kontroller ved tjenesteutsetting/kjøp av tjenester “Alle” tjenesteutsetter/kjøper tjenester. Men hvordan verifiseres og risikovurderes dette? Som kunde har man alltid 100% ansvar for sikkerheten,

Least Privilege policy

Facebook
Twitter
LinkedIn

More to explorer