Zero Trust Soldier

I forbindelse med en LinkedIn post jeg nettopp hadde, ble det er en del diskusjon.

De som lager moderne brannmurer leverer ikke skytjenester, og de som leverer skytjenester lager ikke moderne brannmurer. Slik er det, og det burde man ha med i tankene når man går til skyen.

I “gamledager” hadde alle en brannur i eget datasenter, og mange har jo de “gamle” datasentrene fortsatt. Med tiden oppdaterte og fornyet man brannmurene. Hvorfor? En kombinasjon av evolusjonen innen trusselbildet, OG evolusjonen innen brannmurteknologien. Men så.

Så begynte man å flytte til skyen, ofte ikke slik skyleverandørene egentlig vil med PaaS og SaaS, men med IaaS (som er det “samme” som eget datasenter) og da uten den nye og moderne brannmuren man har i sitt “gamle” datasenter. Hvorfor? Det er det store spørsmålet, og man kan snu på det, for om brannmuren hos skyleverandøren er god nok, hvorfor i alle dager skal man kjøpe en moderne brannmur i sitt “gamle” datasenter? IaaS og eget datasenter er “same same”, og da er det noe som ikke rimer når man gjør så fundamentale forskjellige valg.

Noen ganger anbefaler jeg kunder å bare installere en ruter, da det er mye billigere, og gjør samme jobben som “brannmuren” gjør i noen installasjoner.

Skyen

Hva pokkern er skyen? Det er mer enn overskyet og tåkete, det er i tillegg uvær, vind, regn, storm, torden, ulykker, usikkerhet, se inn i ei krystallkule, i tillegg til alt det rosenrøde man blir presentert. Det er klart, skyen har mye bra i seg, og det er mange gode grunner til å bevege seg dit, og jeg heier på det, for det gir uante muligheter, men… For det er noen store men her. Mange forledes til å tro at skyen er magisk, og bare fordi man kaller det sky er det liksom perfekt og sikkerhet, men det er jo ikke tilfelle, noe stadig flere får med seg.

I tillegg er det mange gamle systemer, fra 90 og tidlig 2000 tallet, fra tiden man kalte det ASP og kjørte det på Compaq maskiner og solgte det som en tjeneste. Mange av disse applikasjonene har nå blitt flyttet over på Windows maskiner i skyen, i en IaaS løsning, der IaaS står for Infrastructure as a Service. Og det er det denne artikkelen skal handle om.

Skyen har både SaaS, Software as as Service, PaaS, Platform as as Service, IDaaS, Identity as a Service, IaaS Infrastructure as a Service, og mye mer.

IaaS

IaaS er infrastruktur, der infrastrukturen eies av skyleverandøren, typisk Microsoft, Amazon eller Google. På toppen av denne infrastrukturen implementerer kunder mest typisk servere, Windows og Linux. På toppen av disse operativsystemene installeres da forskjellige applikasjoner.

Hva er forskjellen på det jeg nettopp har beskrevet og et godt “gammeldags” datasenter? I prinsippet så er det “akkurat” det samme, bare at noen andre eier teknologien i bunn, med en del forskjeller allikevel, som går på automasjon, skalerbarhet og mulighet for integrasjon typisk med PaaS. Men… I bunn så er det “likt” ditt gamle datasenter, der dere hadde lokalet, strømmen, kjølingen og switchene.

Så om vi er enige om at selve infrastrukturen er “lik”, så gjelder følgende:

• Segmentering er viktig både i eget fysisk datasenter ved hjelp av vlan segmentering, eller mikrosegmenteringsteknologi som NSX, Cisco ACI, Nutanix Flow, OpenStack eller tilsvarende, eller i skyen, der Azure, AWS og GCP løser dette på forskjellige måter og tilbyr forskjellige ting. Noen skyleverandører tilbyr mikrosegmentering by default. Stort kudos for det, for det er det ikke alle som gjør, og det er en viktig sikkerhetsparameter.
• IP adresser er likt. En server har en IP adresse både i eget datasenter, og i IaaS.
• Tilganger fra internett. DMZ er det man typisk skal bruke for systemer som skal være tilgjengelige fra internett, men i dagens landskap med mikrosegmentering spiller det ingen rolle hva man kaller det, bare man er bevisst på hva man holder på med. Least Privilege for denne kommunikasjonen er viktig for å best mulig redusere angrepsflaten i tråd med god proaktiv og preventiv sikkerhet.Misbruk av sårbarheter skjer ofte i denne kommunikasjonen.
• Intern kommunikasjon er likt i eget datasenter og i IaaS, da det er servere som snakker sammen, IP til IP. Hvem har tilgang til hva? Skal RDP være tillatt i alle retninger for alt og alle? Er det uvedkommende på innsiden som prøver å misbruke sårbare interne systemer? Det har skjedd før, og man MÅ anta kompromittering og dermed anta av interne bevegelser skjer av uvedkommende, at RDP ikke burde være tillatt i alle retninger, og at sårbarheter kan misbrukes også internt. Print Nightmare var en sårbarhet som ble misbrukt senest i 2021, internt i nettverk.
• Utgående kommunikasjon er likt onprem og i skyen, og man må på lik måte ta kontroll på denne kommunikasjonen for å adressere KillChain #6, Command & Control, for å redusere risiko for phone home, med opplasting av informasjon for utpressing, men også nedlasting av skadevare for ransomware. Det er her viktig å anta at uvedkommende er inne i systemene og bygge proaktiv sikkerhet som bare tillater det som er nødvendig for at applikasjon og system skal fungere, og dermed forhindre muligheten for at aktørene kan lekke deres informasjon, men også laste ned skadevare som har til hensikt å kryptere.
• Servere er likt, på den måten at det er samme operativsystem, med de samme sårbarhetene. Ansvaret for patching er likt, både onprem og i skyen, og rikets tilstand er mye lik. Utdaterte systemer eksisterer begge steder, og man er “konstant” sårbar da man alltid er på etterskudd med oppdateringer (jada, det er noen som er flinke, men de fleste er rett og slett ikke flinke nok).

Brannmur

Alle brannmurer har en grunnregel som er deny, altså at all trafikk er sperret fra dag 1, eller… Det skal være slik, men det har utviklet seg til å bli noe annet, spesielt av skyleverandørene. Skummelt.

La oss spole tilbake til 1988 da den første Stateful Packet Inspection (SPI) brannmuren kom, og gjorde tilgangskontroll på IP adresse og port, OSI modell lag 3 og 4. Før dette hadde det vært rutere som gjorde jobben med pakkefilter og ACL’er, Access Control List, men det var ikke tilstrekkelig. En SPI brannmur vil da være sesjonsorientert, og er fortsatt den dag i dag grunnlaget for alle brannmurer. Problemet er bare at mange leverandører fortsatt lever i 1988 når det gjelder funksjonalitet og arkitektur, mens kunder forledes til å tro noe annet.

En skikkelig brannmur

Default deny for all trafikk, og man må lage allow regler for å tillate trafikk. I 1988 ble denne tilgangskontrollen utført med kontroll av IP adresse og portnummer. Dette blir tilgangskontroll, og man kan si at den primære funksjonen for alle brannmurer er å tillate trafikk.

Brannmurer på jobben skal beskytte både brukere, servere, OT, IoT, systemer, data og mer.

Utviklingen innen brannmur teknologi har gått langt siden 1988, og i dag gjør ikke brannmuren tilgangskontroll bare på IP og port, men også på applikasjon, brukere, URL, status på endepunkt og enhetsinformasjon. I tillegg har de moderne brannmurene hatt “deep inspection” med IPS, Anti Virus, Anti Spyware, DNS sikkerhet, URL sikkerhet, filsikkerhet,DLP og mer i mange år. Med utviklingen i trusselbildet er nesten alt på internett kryptert, og for at en NGFW skal kunne gjøre jobben sin må denne trafikken dekrypteres, noe alle moderne brannmurer kan gjøre i dag.

Alt dette er viktig i evolusjonen for å bedre adressere det moderne trusselbildet. Og det er her de store forskjellene mot sky leverandørenes brannmurer er.

Ser man på Gartner MQ er det 3 stk oppe til høyre, Palo Alto Networks, Fortinet og Check Point. Mens Microsoft og Amazon Web Services er nederst til venstre. GCP er ikke engang der.

Hjemmebrannmurer

Disse benyttes typisk for privat utstyr som telefoner, PC’er, smarthus, spillkonsoller, IoT og mer. Det som skiller en slik brannmur fra en “skikkelig” brannmur er at utgående regelsett er liberalt og tillater alt, mens inngående reglsett er strengt og sperrer alt og man må spesifikt tillate om noe skal inn. Dette er viktig for brukervennligheten. En slik brannmur krever typisk ingen til liten interaksjon fra eieren, selv om den burde oppdateres regelmessig.

Typiske brannmurer her er Zyxel, D-Link, Asus og mer. Man finner dem på Elkjøp, Komplett og lignende.

IaaS brannmurene er Zyxel brannmurer

Det som er skremmende, er at et vanlig firma, med en brannmur, vil ha dette for datasenter, IT, OT, IoT og mer. Default regelen i brannmuren er deny, i alle retninger, og man må spesifisere hva man ønsker å tillate.

IaaS inneholder forretnings kritiske servere og systemer, og i utgangspunktet ingen klienter (joda, man kan ha VDI, Citrix og annet). Med tanke på at IaaS i all hovedsak inneholder forretningskritiske systemer er det skremmende at leverandørene ofte benytter Zyxel regelsett, med alt tillatt utgående. Hvordan er dette i forbindelse med Killchain punkt 6 Command & Control, og adressering av VG testen? Bare dette punktet er skremmende, at leverandørene faktisk leverer et produkt som er ment for hjemmekontor. Neida. Joda. Huff. Jada, så klart man kan konfigurere om dette, men bare det at det er slik fra dag 1 sier litt om hvor skummel skyen er, og hvor lite brannmur tankegang det er hos sky leverandørene. Jeg kunne stoppet her, men jeg må fortsette.

Hvordan er det med dekryptering av trafikken for innsyn i forbindelse med IPS?

Trusselbildet

Man kan si mye om trusselbildet, men ser man på fakta, og da viser jeg til Enisa Threat Landscape rapportene som hvert år analyserer siste års hendelser og viser hva som er trendene. De siste årene har ikke overraskende ransomware vært på topp, så la oss se på denne trusselen. Jeg har skrevet litt om hvordan jeg ville adressert denne trusselen i denne artikkelen, med fokus på 4 steg:

• Inngående kommunikasjon
  • Phisning
  • Misbruk av liberale tilgang typisk uten MFA
  • Misbruk av software sårbarheter
• Intern kommunikasjon
• Utgående kommunikasjon
• Kryptering

La oss bruke ransomware som et eksempel når vi forklarer hvorfor man burde ha en NGFW også i skyen.

Hvorfor NGFW i IaaS?

La oss huske på trussel nummer 1 ransomware, de 4 stegene:

Steg 1, inngående kommunikasjon

Jeg hjelper kunder, både onprem og i skyen, med Palo Alto Networks brannmurer, og andre NGFW’er.

Dekryptering er standard i dette oppsettet, da dette er viktig for full synlighet.

Vi lager Least Privilege regelsett som gjør tilgangskontroll basert på source country, destination IP, applikasjon og URL . Dette bidrar sterkt til å redusere angrepsflaten, og er noe man umiddelbart ser et resultat av i IPS loggene. Kundene wow’er når de ser den umiddelbare effekten. Dette gjelder både onprem og i skyen, da jeg også gjør dette for kunder med Palo Alto Networks i Azure.

IPS funksjonen er også fullt utnyttet da kommunikasjonen er dekryptert og full inspeksjon er mulig med kontinuerlig oppdaterte sikkerhets signaturer, noe som er veldig viktig i det dynamiske bildet med sårbarheter og trusler.

Ser man tilbake på flere hendelser med f.eks Exchange servere som er misbrukt fordi de ikke var patchet, kunne dette vært forhindet med et slikt oppsett med dynamisk oppdaterte signaturer og dekryptering.

Kunder er alltid på etterskudd med patching, og da er det viktig med dette laget med sikkerhet for mindre stress og å kunne sove bedre om natta.

Steg 2, intern kommunikasjon

Assume Compromise. Anta at uvedkommende er på innsiden. Sikre god segmentering, onprem og i skyen. Sikre god synlighet, god tilgangskontroll og god inspeksjon av dataene.

Dekryptering er like viktig her, spesielt for å utnytte de dynamiske IPS signaturene, men også for å gjøre best mulig Least Privilege med full URL synlighet, samt ssynlighet på filtyper. Anti Virus og beskyttelse mot nulldagssårbarheter er også viktig.

Least Privilege regelsett basert på source og destination IP, applikasjon og URL, gjerne knyttet mot IaaS orkestreringsløsningen. Denne granulæriteten bidrar til at hvitelisting er enkelt, og RDP tilgang vil være enkelt å adressere.

Stag 3, utgående kommunikasjon

Når uvedkommende har kommet seg på innsiden, er det mange ting de ønsker å gjøre utgående:

• Etablere en permanent bakdør
• Lekke data
• Laste ned skadevare

For å beskytte seg mot disse tre elementene er det viktig å på forhånd hviteliste hva enhver server trenger mot internett. Dette er å adressere VG testen, ved at man kontrollerer hvilke applikasjoner og URL’er en server skal kommunisere med. Er dette arbeidet gjort skikkelig, vil uvedkommende få en vanskelig dag på jobben da de ikke burde klare å etablere en bakdør, de burde ikke klare å nå sine servere for å kunne lekke data, og de skal ikke klare å nå sine servere for å kunne laste ned skadevare.

Adresserer man VG testen vil ikke TeamViewer fungere om dette ikke spesfikt er tillatt, og det samme er det for andre fjernaksessløsninger som ofte misbrukes i angrep.

Konklusjon

Dette ble en lengre artikkel enn jeg i utgangspunktet hadde tenkt, men dette er noe jeg brenner sterkt for, så da blir det fort slik.

Når jeg ser altfor mange ikke gir dette nok fokus, og når uhellet først er ute og jeg ser at brannmuren kunne hindret det med godt proaktivt arbeid, med riktig teknologi, blir jeg giret. For bryter man ting ned og bygger det opp stegvis, vil man få en ganske robust sikkerhet. Ja, så klart man trenger mer, som endepunktsikkerhet, god tilgangskontroll, logging, overvåking og mye mer, men jeg mener det ikke er mye som slår god proaktiv og preventiv sikkerhet. Lagvis sikkerhet er smart og viktig, og en moderne brannmur med bra oppsett vil være en elementær komponent i denne strategien.

NGFW vs IaaS brannmur

En IaaS brannmur baserer seg i hovedsak på 1988 basert SPI tankesett, med noen tilleggsfunksjoner, og et Zyxel regetsett som tillater alt utgående by default (her er det forskjell på leverandørene, men Azure har et Zyxel regelsett, og har nå kommet med lovnad om å endre dette om noen år!!!! Hvorfor vente?). Dekryptering er for meg ukjent innen IaaS, men sist jeg sjekket var ikke dette tilgjengelig .

Hvordan adressere ransomware? Inngående Least Privilege regelsett basert på applikasjon og URL, med dekryptering og IPS vil bidra til å redusere angrepsflaten og begrense sannsynligheten for innbrudd og misbruk av sårbarheter, inkludert nulldagssårbarheter. Jeg vet ikke om det er mulig i IaaS. Sist jeg sjekket var ikke dette mulig. Arrester meg om jeg tar feil.

Hvordan adressere god intern Least Privilege tilgangskontroll, med dekryptering og IPS i IaaS? Tilgangskontroll med IP adresser og porter tilhører 1988, og med dagens trusselbilde har infrastruktur sikkerheten kommet langt, men kanskje ikke så langt hos IaaS’ene. Sist jeg sjekket var ikke dette mulig å adressere på en god trussel orientert måte i infrastrukturen.

Hvordan adressere VG testen med en IaaS brannmur? Dette er viktig i dagens trusselbilde og vil adressere KillChain punkt 6, Command & Control. Proaktiv og preventiv sikkerhet med applikasjon og URL basert hvitelisting utgående for servere, samt dekryptering for inspeksjon og beskyttelse med IPS, DNS og flere lag med sikkerhet, er veldig viktig for å redusere angrepsflaten og risikoen, og er noe jeg ikke vet om IaaS brannmurene faktisk kan gjøre. Sist jeg sjekket kunne de ikke dette.

Mange store IaaS kunder bruker tredjepart NGFW

Jeg jobber med noen, og kjenner flere, Azure, GCP og AWS kunder som kjører Palo Alto Networks i sine IaaS løsninger, fordi IaaS løsningene for dem ikke er tilstrekkelige. En fugl har hvisket meg i øret at til og med IaaS leverandørene bruker tredjepart NGFW i sine IaaS løsninger….

Det er vel heller ingen hemmelighet at en av drivkreftene til at Azure kom til Norge kjører Palo Alto Networks NGFW i nettopp Azure. Say no more.

Always-On VPN

Denne er litt på siden, men i dagens trusselbilde er det fornuftig å anse alle klienter for kompromitterte og derfor “kaste” dem ut av nettverket på kontoret. Alle klienter burde anses som usikre og untrust, og det vil være fornuftig å sikre disse ytterligere ved å behandle de likt alle steder de måtte befinne seg ved at de alltid er på internett og må kommunisere via en NGFW basert Always-On VPN med dekryptering og flere lag med sikkerhet inkludert DNS og URL sikkerhet.

Grunnen til at jeg nevner dette er fordi flere kunder nettopp flytter sine datasenter til skyen, og de som bruker en NGFW der (der jeg jobber benyttes Palo Alto Networks for både datasenter sikkerhet og Always-On VPN) vil kunne adressere dette med samme teknologi og løsning ved å slå to fluer i en smekk med tilgang til systemer og sterkere motstand mot phishing angrep.

Flytt gjerne til skyen

Det er mange gode grunner til å flytte til skyen, så gjør det veldig gjerne, men vær våken på ferden, samtidig som kritikeren på skulderen må få være med, for alt er IKKE gull og grønne skoger der. Det er bra på mye, men absolutt ikke på alt. Start med risikovurdering.