Zero Trust Soldier

Cybersecurity is complex. Let's see if we can make it more understandable


Ukrainere mistet strømmen. Slik kunne angrepet vært stoppet.

Er du leder for en organisasjon som havner under NIS2 direktivet er sannsynligheten for målrettede angrep større enn det andre virksomheter typisk vil måtte forholde seg til. På grunn av dette er det viktig at ledelsen virkelig er fremoverlent rundt risikovurdering, spesielt i det digitale domenet, da mange suksessfulle og skadelige angrep mot kritisk infrastruktur har skjedd der.

Denne artikkelen er også en del av min matrise som sammenligner hendelser og viser hvilke tiltak som kunne avverget hendelsen.

Bildet er fra den pågående fysiske krigen og ikke direkte relevant for denne artikkelen, men det er samme krig, bare at den er multilevel.

230.000 ukrainere mistet strømmen i 2015

23. desember 2015 ble strømforsyningen til 230.000 ukrainere slått ut av et digitalt angrep. Da var det ikke mennesker ut på linjene som var viktig for å gjenopprette strømmen, men IT avdelingen måtte inn på jobb.

Se her hva som skjedde på skjermen til operatørene.

Hendelsen var et resultat av krigen mellom Russland og Ukraina. Et målrettet angrep for å gjøre skade. Angrepet startet så tidlig som våre 2015, så angriperne bruker mye tid for å nå sine mål. Men det kan være en stor fordel om man bare omstiller hjernen til å tenke sikkerhet litt annerledes.

Aktiviteten startet med phishing e-poster til tre forskjellige lokasjoner. For detaljer anbefaler jeg å lese denne Wired artikkelen.

Det ble gjort suksessfull phishing (kunne det vært stoppet i e-post sikkerheten?), det ble brukt VPN inn til systemene (det manglet nok MFA), hvordan var segmenteringen? Hvordan var rettighetene internt? Manglet det MFA internt? Hvordan var tilgangskontrollene igjennom brannmurene internt? Hvor sikkert var det i forhold til Purdue Modellen? En sårbarhet kommer sjelden alene.

Kritisk infrastruktur i Norge

I Norge har vi mange kritiske verdier som vil havne under NIS2. Man snakker da om funksjoner og tjenester samfunnet er avhengige av for å fungere. Vann. Strøm. Finans. Transport. Helse. Digital infrastruktur

Norge er store på gass og annen energi-eksport. Myndigheter følger naturligvis med på disse tingene, men om ting allikevel skjer, hjelper det lite at noen fulgte med. Så hva kan gjøres? Ledelsen må opp i ringene og ikke bare være med, men faktisk lede arbeidet med forebyggende sikkerhet for å unngå disse hendelsene. Det blir altfor enkelt, og sårbart, å hvile seg på NSM og PST.

Grunnleggende funksjoner for alle som havner under NIS2

Med høyere sannsynlighet for målrettede angrep vil logging, SIEM og SOC være av høy teknisk viktighet for alle som har noe som helst med kritisk infrastruktur å gjøre.

Hvorfor nevner jeg dette? Jo, fordi selv om mange tenker at alle i denne kategorien har dette på plass, så er ikke det alltid tilfelle, dessverre. Man MÅ anta at disse angrepene skjer, og derfor MÅ man iverksette minst disse tiltakene for å oppdage ting så raskt som mulig. Angrepet mot Ukraina i 2022 tok flere måneder før det ble skade!

Hva kunne avverget Ukraina hendelsen i 2022?

Ukraina sin kraft infrastruktur ble angrepet igjen i 2022. Mandiant har skrevet en detaljert artikkel som forklarer hva som skjedde da. Det er denne jeg bruker som underlag for å se på hva som kunne vært gjort for å forhindre hendelsen.

De beste angrepene er de som ikke skjer

De beste angrepene er de som ikke skjer, eller de som feiler. For å hindre suksessfulle hendelser må man brette opp ermene og forberede seg på nettopp angrep. Angrep skjer hele tiden, av forskjellige slag. Den desidert største trusselen på nettet er skadevare som har til hensikt å ødelegge tilgjengelighet ved hjelp av kryptering, og deretter utpressing av penger (les om ransomware hos Enisa). Dette kan være mer vilkårlige angrep, men kan også være målrettede. Disse angrepene er typisk motivert av profitt for de kriminelle. Angrepene inneholder ofte stjeling av data for senere utpressing, igjen motivert av profitt.

NotPetya angrepene mot bl.a Maersk i 2017 var skadevare tilsvarende ransomware, men motivasjonen var politisk fra Russland mot Ukraina. Skaden i form av nedetid og noen ganger uopprettelig skade, kan allikevel koste enormt mye, og få enorme konsekvenser.

Målrettede angrep bruker ofte mange av de samme teknikkene, selv om noen av dem er enda mer sofistikerte. Et angrep skjer i flere faser som gjør at man kan oppdage og stoppe det flere steder.

Hva skjedde teknisk i Ukraina i 2022?

Mandiant er fantastiske på å utgi detaljerte rapporter etter hendelser de har vært involvert i. Det har de gjort også denne gangen, og dette danner grunnlag for læring. For man må lære, hele tiden. Hva skjedde, og hva kunne vært gjort for å unngå den skadelige hendelsen?

OT-level living off the land (LotL) techniques

Ofte benytter angrep seg av skadevare som kan oppdages med sikkerhetsteknologi. LotL benytter eksisterende og legitime verktøy som allerede er på plass i infrastrukturen, og dermed typisk vil være vanskeligere å oppdage. Det er derfor veldig viktig å være bevisst på tilganger og rettigheter, spesielt innen kritisk infrastruktur.

Zero Trust med Assume Breach har en sentral og viktig plass for å adressere dette.

Webshell

Hvilken leder har hørt ordet? Hvilken leder trenger å kunne noe som helst om dette teknologiske begrepet? Artikkelen fra Mandiant viser at dette ble brukt/misbrukt i den tidlige fasen av angrepet. Vil ikke forklare i detalj hvordan alle teknikkene fungere da denne artikkelen vil bli altfor lang, men heller fokusere på hva som kunne vært gjort for å avverge selve teknikken.

Man må ta god kontroll på inngående kommunikasjon fra internett. Hvor kunne tiltak ha stoppet første fase av angrepet? Sikre at disse tingene er på plass i deres infrastruktur.

  • Server og aplikasjon sikkerhet. Sårbarhetsscanning av alle komponenter sammen med gode rutiner for oppdatering.
  • Logging, SIEM og SOC. En kritisk nødvendighet for alle med kritisk infrastruktur.
  • Least Privilege på regelsettet som tillater trafikk fra internett sammen med dekryptering reduserer angrepsflaten. Å bruke threat loggene for innstramming av tilganger er anbefalt. Hvem trenger tilgang, fra hvor, til hva, på hvilken måte? Ha med FQDN/URL i regel for tilgang. Alt dette bidrar til å redusere angrepsflate, men også synlighet på feilede forsøk som kan trigge en reaksjon.
  • Dekryptering av kommunikasjonen er viktig for sikkerhetsfunksjoner som f.eks IPS. Dette vil i dag typisk gjelde din Next Generation Firewall. Denne type dekryptering er enkel å sette opp, er lite ressurskrevende for teknologien, og vil gi en synlighet for inspeksjon og logging du vanskelig kunne fått ellers.
  • IPS satt opp etter god praksis for å stoppe skadelig aktivitet. Å stoppe er bra. Det er enda bedre om man i tillegg også rapporterer dette til noen som vil reagere. Logging til en SIEM som overvåkes av en SOC er en nødvendighet for alle med kritisk infrastruktur.

Command and control (C2)

Artikkelen fra Mandiant sier at 1 måned etter etablering og misbruk av webshell ble det opprettet kommunikasjon tilbake til de kriminelle. Hvordan kunne dette være mulig? Jo, fordi mennesker i alle år har tenkt sikkerhet utenfra og inn, men ikke innenfra og ut i like stor grad. Derfor er VG testen så veldig viktig å utføre og adressere for alle foretak med kritisk infrastruktur. Servere, OT maskiner og ellers all teknologi innen kritisk infrastruktur er relevante for VG testen. Les mer om denne her for å se hva dette er, og hvilke tiltak som må innføres.

Hva kunne vært gjort for å unngå C2?

  • Spørsmål #1 er: Hva trenger webserveren av kommunikasjon ut mot internett? Dette er typisk veldig lite, og deretter må man lage et Least Privilege regelsett utgående basert på applikasjon, port, URL og IP informasjon. Når dette er på plass vil etablering av C2 være nærmest umulig den veien.
  • Ta kontroll på DNS kommunikasjonen fra serveren for å sikre at denne kun går mot betrodde kilder.

Persistence på server

Når aktørene har etablert C2 er det viktig at denne vedvarer slik at kommunikasjon kan opprettholdes over lang tid. Hva kunne vært gjort for å unngå dette?

  • Hardning av servere er et begrep som har eksistert lenge, men dessverre i altfor liten grad utføres. Dette handler om å gjøre servere, eller andre komponenter, så robuste som mulig for å best mulig motstå uønsket aktivitet. CIS Bechmarks er et sted man kan finne gode hjelpemidler for dette. Kunne aktørene klart å etablere dette dersom serveren hadde vært strammet inn i tråd med Least Privilege? Mest sannsynlig ikke.

Lateral Movement to SCADA Hypervisor and OT Attack Execution

Det er en kjent ting at aktører kommer inn på et sted som ikke nødvendigvs er det endelige målet. Det viktigste for dem er å komme inn, for mennesker har i alle år typisk vært dårlige på å bygge interne forsvar, da man ikke har tatt høyde for suksessfulle innbrudd. Dette er en av hovedårsakene til at Zero Trust ble et begrep, og senere har blitt en viktig sikkerhetsstrategi. Man MÅ anta at uvedkommende er på innsiden og deretter bygge sikkerhet basert på denne situasjonen.

Å bevege seg mellom maskiner og enheter er enkelt om segmentering er manglende, systemer ikke er godt nok oppdatert (fordi de ikke er tilgjengelig fra internett), ei heller hardnet. En veldig viktig ting alle må ha med seg er at alt er tilgjengelig fra internett og sikkerhet må utøves deretter.

Hva kunne vært gjort for å unngå interne bevegelser?

  • Segmentering. Dette er nevnt i mange år, men det krever. Det krever at man setter seg ned, får oversikt over eiendeler og verdier, og jobber prioritert basert på risikovudering. Segmenter og isloer de mest kritiske komponentene, og legg på Least Privilege regelsett i deres Next Generation Firewall for kommunikasjon inn OG ut av det nye segmentet basert på applikasjon, bruker, IP, port og gjerne URL om det er relevant.
  • Dekryptering er like viktig her som når kommunikasjonen skjer direkte fra internett, er like enkel å sette opp og like lite ressurskrevende for teknologien. Man kaller ofte dette “SSL Inbound Inspection” og skal ikke forveksles med “tradisjonell” dekryptering av kommunikasjon for klienter mot internett. Dette skjer på en annen måte, er enklere og mindre ressurskrevende.
  • Sikre at alle regler er satt opp etter beste praksis med full inspeksjon etter spor av virus, misbruk av sårbarheter og mer for å på best mulig måte kunne stoppe og/eller oppdage forsøk på misbruk.

Vil denne typs aktivitet unngås med disse tiltakene? Man vil aldri være helt sikker, men sannsynligheten vil gå ned dramatisk. Flere av disse tiltakene mangler typisk der ute, fordi det er mennesker som i sin tid har satt opp teknologien basert på et trusselbilde som var noe helt annet for 10-20-30 år siden. Mennesker må ta til seg dagens trusselbilde og oppdatere sikkerheten deretter.

End-of-Life (EOL) MicroSCADA control system

Utdaterte systemer er alltid en utfordring som altfor ofte eksisterer. Å bytte disse ut kan være enorme prosjekter innen kritisk infrastruktur. Det er derfor meget viktig å ta høyde for nettopp dette med bl.a tiltak som nevnt ovenfor, med segmentering og Least Privilege. I tillegg kan enda mer gjøres innen OT og Scada systemer:

  • IoT sikkerhet er et relativt nytt begrep. Dette har blitt relevant grunnet all ny IoT ( Internet of Things) teknologi som blir stadig mer kritisk og samtidig sårbar. Det er viktig å sikre at disse bare gjør det de skal gjøre, og ikke misbrukes til uønskede ting. OT (Operational Technology) og IIoT (Industrial Internet of Things) kan beskyttes med tilsvarende løsninger, typisk tilgjengelig i deres Next Generation Firewall. Dette muliggjør tilgangskotroll ned på mac-adresser og intelligens om spesifikt hva disse enheten holder på med og skal gjør. Man kan styre dette ned på kommandoer, som å lese, å endre en verdi osv.

Uansett om systemet er nytt, gammelt, oppdatert eller sårbart er det viktig å begrense hva som er mulig å gjøre på utstyret for å hindre uønskede hendelser.

Misbruk av Hypervisor

Aktørene misbrukte hypervisoren til å spinne opp en maskin ved hjelp av et ISO image som kunne kjøre på en virtuell CD-rom. Her er det mange ting man kunne gjort for å avverge hendelsen.

  • Segmentering med Least Privilege. Hvem trengte egentlig tilgang til hypervisor i daglig virke? Hvordan skulle denne tilgangen skje? Var management interface isolert i et eget segment sammen med Least Privilege tilgangskontroll?
  • FIDO2 basert MFA for administratorer. Var det MFA på plass for administratorer til hypervisoren? Det står ikke noe om at en sårbarhet ble utnyttet til denne operasjonen.
  • Hardning av hypervisoren. Var hypervosoren hardnet sammen med rettighetskontroll? Skulle aktørene egentlig ha rettigheter til å kunne gjøre det de gjorde? Det skrives at CD rom installasjon skulle vært forhindret i konfigurasjon.

Sikkerhet på Scada systemet

Her er jeg ikke ekspert, men er helt sikker på at flere ting kunne vært gjort mtp Least Privilege, uten å kunne si noe mer detaljert.

According to Hitachi Energy’s documentation, SCIL is a high level programming language designed for MicroSCADA control systems and can operate the system and its features (Figure 9). SCIL programs are generally text-based statements that can be composed of commands, objects, variables, calls to predefined functions, and expressions. There are several methods in which SCIL programs can execute, such as an engineer/operator clicking a button or image within the MicroSCADA system, scheduled or process derived changes, or in this case manual execution.

Segmentering i OT miljøet

Neste steg her var kommunikasjon med RTU’ene. En sterk anbefaling for OT miljøer er å følge Purdue Modellen, som handler om segmentering og rettigheter, i tråd med Least Privilege. Hva skulle være mulig å gjøre innen OT nettet, og skulle det være mulig å gjøre det som skjedde i dette steget?

The SCIL commands would have caused the MicroSCADA server to relay the commands to the substation RTUs via either the IEC-60870-5-104 protocol for TCP/IP connections or the IEC-60870-5-101 protocol for serial connections.

  • Purdue modellen. Opererer man kritisk infrastruktur med OT og IIoT må man lese seg opp på dette for å forstå sone begrepene og etablere dette for å motså uønsket aktivitet.
  • Benytte Next Generation Firewall med IoT sikkerhet for å kontrollere IEC-60870-5-104 kommunikasjon. Her eksisterer det stor granulæritet for tilgangskontroll.

CADDYWIPER

Aktørene sikret seg at alle spor skulle slettes. Dette gjorde de ved å distribuere en skadevare som hadde dette til oppgave. Dette skjedde inn i IT miljøet.

TANKTRAP. NEARMISS. SDELETE. PARTYTICKET. CADDYWIPER

  • Ikke velg endepunktsikkerhet “tilfeldig”. Å bruke pris som en stor faktor her kan koste dyrt. MITRE ATT&CK må nesten brukes når man skal gå til innkjøp av slik teknologi, da de har til hensikt å identifisere alle angrepsmetoder, og deretter synliggjøre hvordan forskjellige endepunktsløsninger klarer seg mot alle disse. Her er det store forskjeller, og jeg anbefaler å lese artikkelen jeg linker til.
  • Segmentering er relevant også her. Kommunikasjon mellom forskjellige kritikalitetsnivåer må skje via en sikkerhetskontroll, typisk en Next Generation Firewall. Hva skal være lov? Fra hvor, til hvor? På hvilken måte? Osv.

Domenekontrolleren

Også her var domenekontrolleren sentral i angrepet. Aktørene fikk tilgang til denne, og kunne da spre skadevare via GPO’er. Var domenekontrolleren segmentert ut? Hvem hadde administrator rettigheter? Måtte man kjøre via en PAM løsning? Var det FIDO2 basert MFA?

  • Segmentering. Domene kontrollere må stå i egne soner. Alene ikke nødvendigvis nok sikkerhet, men da hever man muligheten for bedre kontroll, inspeksjon og dermed sikkerhet
  • FIDO2 basert MFA. Ha så få administratorer som mulig, og sikre at disse kun kan snakke via en PAM løsning med FIDO2. Vi snakker her om kritisk infrastruktur.
  • Endepunktsikkerhet. Ha state of the art sikkerhet på serveren. Verifiser opp om Mitre ATT&CK.
  • Hardning av domenekontrolleren. En soleklar oppgave alle må gjøre, spesielt innen kritisk infrastruktur. Hva skal en administrator få lov til å gjøre?

Konklusjon

En sårbarhet kommer sjelden alene. Leser man seg opp på hendelsen i Mandiant artikkelen vil man forstå at dette angrepet kunne vært avverget. Man må anta at uvedkommende er på innsiden og bygge sikkerhet deretter. Man må forstå Cyber Kill Chain konseptet, og at angrept har flere faser og steg, og at det ofte tar lang tid, spesielt disse typer angrep.

Artikkelen til Mandian har noen avsluttende Appendix som tar for seg hvilke tiltak som burde vært utført, samt IoC’er, bevis og spor på hendelser.

Sukessfulle hendelser skjer i tillatt trafikk. Det er viktig å ta kontroll på hva man tillater, alltid, og spesielt innen kritisk infrastruktur, for å redusere angrepsflate og risiko.



Leave a Reply

Discover more from Zero Trust Soldier

Subscribe now to keep reading and get access to the full archive.

Continue reading