S3 Ep142: Sette X-en i X-Ops

Ingen lydspiller under? Lytte direkte på Soundcloud.

AND.  Hei alle sammen.

Velkommen til Naked Security-podcasten.

Som du kan høre, er jeg ikke Doug, jeg er Duck.

Doug er på ferie denne uken, så jeg får med meg denne episoden av min mangeårige venn og cybersikkerhetskollega, Matt Holdcroft.

Matt, du og jeg går tilbake til Sophos' tidlige dager...

…og feltet du jobber i nå er cybersikkerhetsdelen av det som er kjent som «DevSecOps».

Når det kommer til X-Ops, har du vært der for alle mulige verdier av X, kan du si.

Fortell oss noe om hvordan du kom dit du er nå, for det er en fascinerende historie.

---

MATT.  Min første jobb hos Sophos var Lotus Notes administrator og utvikler, og jeg jobbet i det daværende produksjonsrommet, så jeg var ansvarlig for å duplisere disketter.

Dette var EKTE disketter, som du faktisk kunne floppe!

---

AND.  [HØYT LATTER] Ja, 5.25"-typen ...

---

MATT.  Ja!

Den gang var det enkelt.

Vi hadde fysisk sikkerhet; du kunne se nettverket; du visste at en datamaskin var koblet til nettverket fordi det kom litt kabel ut fra baksiden.

(Selv om den sannsynligvis ikke var koblet til nettverket fordi noen hadde mistet terminatoren fra enden [av kabelen].)

Så vi hadde fine, enkle regler om hvem som kunne gå til hvor, og hvem som kunne stikke hva i hva, og livet var ganske enkelt.

---

AND.  I disse dager er det nesten omvendt, er det ikke?

Hvis en datamaskin ikke er på nettverket, kan den ikke gjøre mye i forhold til å hjelpe selskapet med å nå sine mål, og det anses nesten som umulig å administrere.

Fordi den må kunne nå skyen for å gjøre noe nyttig, og du må være i stand til å nå ut til den, som sikkerhetsoperasjonsperson, via skyen, for å være sikker på at den er opp til bunnen av.

Det er nesten en Catch-22-situasjon, er det ikke?

---

MATT.  Ja.

Det er helt snudd.

Ja, en datamaskin som ikke er tilkoblet er sikker... men den er også ubrukelig, fordi den ikke oppfyller formålet.

Det er bedre å være kontinuerlig på nett, slik at den kontinuerlig kan få de siste oppdateringene, og du kan holde et øye med den, og du kan få real-life telemetri fra den, i stedet for å ha noe du kanskje sjekker annenhver dag.

---

AND.  Som du sier, er det en ironi at det å gå på nettet er svært risikabelt, men det er også den eneste måten å håndtere den risikoen på, spesielt i et miljø der folk ikke dukker opp på kontoret hver dag.

---

MATT.  Ja, ideen om Bring Your Own Device [BYOD] ville vel ikke fly tilbake på dagen?

Men vi hadde Bygg din egen enhet da jeg begynte i Sophos.

Det ble forventet at du skulle bestille delene og bygge din første PC.

Det var en overgangsrite!

---

AND.  Det var ganske fint…

…du kunne velge innenfor rimelighetens grenser, ikke sant?

---

MATT.  [LATER] Ja!

---

AND.  Bør jeg gå for litt mindre diskplass, og da kan jeg kanskje ha [DRAMATISK STEMME] ÅTTE MEGABYTE RAM!!?!

---

MATT.  Det var epoken med 486es, disketter og fakser, da vi startet, var det ikke?

Jeg husker de første Pentiums kom inn i selskapet, og det var "Wow! Se på det!"

---

AND.  Hva er dine tre beste tips for dagens cybersikkerhetsoperatører?

Fordi de er veldig forskjellige fra de gamle, "Ååå, la oss bare se opp for skadelig programvare og så, når vi finner den, går vi og rydder opp i den."

---

MATT.  En av tingene som har endret seg så mye siden den gang, Paul, er at du hadde en infisert maskin på den tiden, og alle var desperate etter å få maskinen desinfisert.

Et kjørbart virus ville infisere *alle* de kjørbare filene på datamaskinen, og å få det tilbake til en "god" tilstand var virkelig tilfeldig, for hvis du gikk glipp av en infeksjon (forutsatt at du kunne desinfisere), ville du være tilbake til start som så snart filen ble påkalt.

Og vi hadde ikke, slik vi har nå, digitale signaturer og manifester og så videre hvor du kunne komme tilbake til en kjent tilstand.

---

AND.  Det er som om skadevare var hoveddelen av problemet, fordi folk forventet at du skulle rydde opp i det, og i utgangspunktet fjerne fluen fra salven, og deretter gi krukken med salve tilbake og si: «Det er trygt å bruke nå, folkens ."

---

MATT.  Motivasjonen har endret seg, for den gang ønsket virusforfatterne å infisere så mange filer som mulig, generelt, og de gjorde det ofte bare "for moro skyld".

Mens de i disse dager ønsker å fange et system.

Så de er ikke interessert i å infisere alle kjørbare filer.

De vil bare ha kontroll over den datamaskinen, uansett formål.

---

AND.  Faktisk er det kanskje ikke engang noen infiserte filer under angrepet.

De kan bryte seg inn fordi de har kjøpt et passord fra noen, og så, når de kommer inn, i stedet for å si: "Hei, la oss slippe et virus løs som vil utløse alle slags alarmer"...

… de vil si: "La oss bare finne hvilke utspekulerte systemadministratorverktøy som allerede er der som vi kan bruke på måter som en ekte systemadministrator aldri ville gjort."

---

MATT.  På mange måter var det egentlig ikke ondsinnet før...

…Jeg husker at jeg ble forskrekket da jeg leste beskrivelsen av et spesielt virus kalt "Ripper".

I stedet for bare å infisere filer, ville det gå rundt og svirre biter på systemet ditt stille.

Så over tid kan enhver fil eller sektor på disken din bli subtilt korrupt.

Seks måneder senere kan du plutselig oppdage at systemet ditt var ubrukelig, og du ville ikke ha noen anelse om hvilke endringer som var gjort.

Jeg husker det var ganske sjokkerende for meg, for før da hadde virus vært irriterende; noen hadde politiske motiver; og noen var bare folk som eksperimenterte og «hadde det gøy».

De første virusene ble skrevet som en intellektuell øvelse.

Og jeg husker, tilbake på dagen, at vi egentlig ikke kunne se noen måte å tjene penger på infeksjoner, selv om de var irriterende, fordi du hadde det problemet med "Betal det til denne bankkontoen" eller "La pengene stå under denne steinen i den lokale parken"...

…som alltid var utsatt for å bli plukket opp av myndighetene.

Så kom selvfølgelig Bitcoin. [LATTER]

Det gjorde hele skadevaresaken kommersielt levedyktig, noe det inntil da ikke var.

---

AND.  Så la oss gå tilbake til de beste tipsene, Matt!

Hva anbefaler du som de tre tingene cybersikkerhetsoperatører kan gjøre som gir dem, hvis du vil, det største bandet for pengene?

---

MATT.  OK.

Alle har hørt dette før: patching.

Du må lappe, og du må lappe ofte.

Jo lenger du lar lappe... det er som å ikke gå til tannlegen: jo lenger du lar det være, jo verre kommer det til å bli.

Det er mer sannsynlig at du treffer en brytende endring.

Men hvis du patcher ofte, selv om du treffer et problem, kan du sannsynligvis takle det, og over tid vil du uansett gjøre applikasjonene dine bedre.

---

AND.  Det er faktisk mye, mye enklere å oppgradere fra for eksempel OpenSSL 3.0 til 3.1 enn det er å oppgradere fra OpenSSL 1.0.2 til OpenSSL 3.1.

---

MATT.  Og hvis noen undersøker miljøet ditt og de kan se at du ikke holder deg oppdatert på oppdateringen din... er det vel, "Hva annet er det vi kan utnytte? Det er verdt en titt!"

Mens noen som er fullstendig lappet ... de er sannsynligvis mer på toppen av ting.

Det er som det gamle Hitchhikers Guide to the Galaxy: så lenge du har håndkleet ditt, antar de at du har alt annet.

Så hvis du er fullstendig lappet, er du sannsynligvis på toppen av alt annet.

---

AND.  Så, vi lapper.

Hva er det andre vi må gjøre?

---

MATT.  Du kan bare lappe det du vet om.

Så den andre tingen er: Overvåking.

Du må kjenne eiendommen din.

Når det gjelder å vite hva som kjører på maskinene dine, har det vært lagt ned mye innsats i det siste med SBOM-er, Programvareliste.

Fordi folk har forstått at det er hele kjeden...

---

AND.  Nøyaktig!

---

MATT.  Det hjelper ikke å få et varsel som sier: "Det er en sårbarhet i et slikt og et bibliotek," og svaret ditt er: "OK, hva skal jeg gjøre med den kunnskapen?"

Å vite hvilke maskiner som kjører, og hva som kjører på disse maskinene...

…og bringer det tilbake til oppdatering, "Har de faktisk installert oppdateringene?"

---

AND.  Eller har en kjeltring sneket seg inn og gått, «Aha! De tror de er lappet, så hvis de ikke dobbeltsjekker at de har holdt seg lappet, kan jeg kanskje nedgradere et av disse systemene og åpne meg en bakdør for alltid mer, fordi de tror de har problemet sortert."

Så jeg antar at klisjeen er: "Mål alltid, anta aldri."

Nå tror jeg at jeg vet hva det tredje tipset ditt er, og jeg mistenker at det kommer til å bli det vanskeligste/mest kontroversielle.

Så la meg se om jeg har rett ... hva er det?

---

MATT.  Jeg vil si det er: Drepe. (Eller Cull.)

Over tid samler systemene seg... de er designet og bygget, og folk går videre.

---

AND.  [LATER] Akkret! [HØYERE LATTER]

Litt som forkalkning...

---

MATT.  Eller fjellknaller...

---

AND.  Ja! [LATTER]

---

MATT.  Barnacles på det store skipet til selskapet ditt.

De kan gjøre nyttig arbeid, men de kan gjøre det med teknologi som var på moten for fem år siden eller for ti år siden da systemet ble designet.

Vi vet alle hvordan utviklere elsker et nytt verktøysett eller et nytt språk.

Når du overvåker, må du holde et øye med disse tingene, og hvis det systemet blir langt i tannen, må du ta den vanskelige avgjørelsen og drepe den.

Og igjen, det samme som med patching, jo lenger du lar det være, jo mer sannsynlig er det at du snur deg og sier: "Hva gjør det systemet til og med?"

Det er veldig viktig å alltid tenke på Livssyklus når du implementerer et nytt system.

Tenk på "OK, dette er min versjon 1, men hvordan skal jeg drepe den? Når skal den dø?"

Sett noen forventninger til virksomheten, til dine interne kunder, og det samme gjelder for eksterne kunder.

---

AND.  Så, Matt, hva er ditt råd for det jeg er klar over kan være en veldig vanskelig jobb for noen som er i sikkerhetsteamet (vanligvis blir dette vanskeligere etter hvert som selskapet blir større) for å hjelpe dem med å selge ideen?

For eksempel, "Du har ikke lenger lov til å kode med OpenSSL 1. Du må flytte til versjon 3. Jeg bryr meg ikke om hvor vanskelig det er!"

Hvordan får du frem det budskapet når alle andre i selskapet presser deg tilbake?

---

MATT.  Først av alt... du kan ikke diktere.

Du må gi klare standarder, og de må forklares.

Salget du fikk fordi vi sendte tidlig uten å fikse et problem?

Det vil bli overskygget av den dårlige publisiteten om at vi hadde en sårbarhet eller at vi sendte med en sårbarhet.

Det er alltid bedre å forebygge enn å fikse.

---

AND.  Absolutt!

---

MATT.  Jeg forstår, fra begge sider, at det er vanskelig.

Men jo lenger du lar det være, jo vanskeligere er det å endre.

Sette disse tingene ut med, "Jeg skal bruke denne versjonen og så skal jeg sette-og-glemme"?

Nei!

Du må se på kodebasen din, og vite hva som er i kodebasen din, og si: «Jeg er avhengig av disse bibliotekene; Jeg er avhengig av disse verktøyene,” og så videre.

Og du må si: "Du må være klar over at alle disse tingene kan endres, og møte det."

---

AND.  Så det høres ut som om du sier at enten loven begynner å fortelle programvareleverandører at de må levere en programvareliste (en SBOM, som du nevnte tidligere), eller ikke...

…du virkelig trenger å opprettholde en slik ting i organisasjonen din uansett, bare slik at du kan måle hvor du står på et cybersikkerhetsfot.

---

MATT.  Du kan ikke være reaktiv om disse tingene.

Det er ikke godt å si: «Den sårbarheten som ble sprutet over hele pressen for en måned siden? Vi har nå konkludert med at vi er trygge.»

[LATER] Det er ikke bra! [MER LATTER]

Realiteten er at alle kommer til å bli truffet av disse gale kampene for å fikse sårbarheter.

Det er noen store i horisonten, potensielt, med ting som kryptering.

En dag kan NIST kunngjøre: "Vi stoler ikke lenger på noe som har med RSA å gjøre."

Og alle kommer til å være i samme båt; alle kommer til å måtte kjempe for å implementere ny, kvantesikker kryptografi.

På det tidspunktet kommer det til å være: "Hvor raskt kan du få fikset ut?"

Alle kommer til å gjøre det samme.

Hvis du er forberedt på det; hvis du vet hva du skal gjøre; hvis du har en god forståelse av infrastrukturen og koden din...

…hvis du kan komme ut i spissen for flokken og si: "Vi gjorde det på dager i stedet for uker"?

Det er en kommersiell fordel, i tillegg til at det er den rette tingen å gjøre.

---

AND.  Så la meg oppsummere de tre beste tipsene dine til det jeg tror har blitt fire, og se om jeg har fått dem riktig.

Tips 1 er godt gammelt Patch tidlig; lapp ofte.

Å vente i to måneder, som folk gjorde i Wannacry-dagene … det var ikke tilfredsstillende for seks år siden, og det er absolutt altfor lenge i 2023.

Selv to uker er for lenge; du må tenke: "Hvis jeg trenger å gjøre dette om to dager, hvordan kan jeg gjøre det?"

Tips 2 er Observere, eller med mine klisje-ord: "Mål alltid, anta aldri."

På den måten kan du forsikre deg om at lappene som skal være der virkelig er, og slik at du faktisk kan finne ut om de "serverne i skapet under trappa" som noen har glemt.

Tips 3 er Drep/Kull, betyr at du bygger en kultur der du er i stand til å avhende produkter som ikke lenger er egnet til formålet.

Og et slags hjelpetips 4 er Vær kvikk, slik at når det Kill/Cull-øyeblikket kommer, kan du faktisk gjøre det raskere enn alle andre.

For det er bra for kundene dine, og det gir deg også (som du sa) en kommersiell fordel.

Har det rett?

---

MATT.  Høres ut som det!

---

AND.  [TRIUMPHANT] Fire enkle ting å gjøre i ettermiddag. [LATTER]

---

MATT.  Ja! [MER LATTER]

---

AND.  Som cybsecurity generelt, er de reiser, er de ikke, snarere enn destinasjoner?

---

MATT.  Ja!

Og ikke la «bedre» være fienden til «bedre». (Eller "bra".)

Så…

Lapp.

Følge.

Drepe. (Eller Cull.)

Og: Vær kvikk… vær klar for endring.

---

AND.  Matt, det er en fin måte å avslutte.

Tusen takk for at du stiller opp til mikrofonen på kort varsel.

Som alltid, for lytterne våre, hvis du har kommentarer, kan du legge dem igjen på Naked Security-siden, eller kontakte oss på sosialt: @nakedsecurity.

Nå gjenstår det bare for meg å si, som vanlig: Til neste gang...

---

BÅDE.  Hold deg trygg!

[MUSIKK MODEM]