Dom Richter, medgrunnlegger i Mondoo – Intervju-serie

Dom Richter, medgrunnlegger i Mondoo, er en erfaren produktleder med dypt kunnskap over moderne programvareutvikling, produktutforming og teamledelse. Med en bakgrunn som omfatter backend, frontend og automatiseringsteknologi, har han ledet høytytende ingeniørteam gjennom en kultur av tillit, eksperimentering og målrettet innovasjon. Hans arbeid omfatter AI, cybersikkerhet og DevOps, der han betoner samarbeid, kontinuerlig læring og levering av meningsfull verdi til sluttbrukere.

Mondoo er en plattform for sikkerhets- og regelefterlevelse-automatisering som gir organisasjoner mulighet til kontinuerlig å vurdere, overvåke og sikre infrastrukturen over sky, på stedet og hybrid-miljøer. Ved å utnytte policy-as-code og maskinlæring-drevne innsikter, hjelper Mondoo team med å identifisere sårbarheter, påtvinge regelefterlevelsestandarder og styrke sikkerhetsposturen uten å bremse innovasjonen. Plattformen integreres sammen med moderne DevOps-arbeidsflyter, og gjør kontinuerlig regelefterlevelse til en realistisk mulighet for bedrifter av alle størrelser.

Hva inspirerte deg til å medgrunnlegge Mondoo, og hvordan har din bakgrunn som hacker og produktleder – sammen med dine erfaringer fra Google (GOOGL ), Chef og tidligere startups – formet selskapets misjon?

Da jeg var i skyttergravene og brøt inn i systemer som en del av mitt arbeid som pentester, fant jeg mange lett forebyggelige svakheter. Samtidig var sikkerheten ofte så fokusert på å flomme brukerne med varsler, at de mistet sight av hva som virkelig betydde noe. Da tenkte jeg “Det må være en enkel knapp jeg kan trykke for å fikse disse tingene”.

Jeg skiftet siden side og begynte å forsvare systemer. Jeg lærte hvordan man ordentlig opererer ting i stor skala, med automatisering og kode. Dette er nyttig enten du kjører et lite hjemmenettverk eller opererer et stort teknologiselskap. Idéene er de samme. Til slutt var det denne kombinasjonen av sikkerhet og plattform-ingeniørarbeid som motiverte meg til å medgrunnlegge Mondoo. Jeg ville gjøre en forskjell i sikkerhetens tilstand, ikke bare legge til en annen skanner som genererte flere varsler. Jeg finner det veldig motivasjonsgivende å se hvordan våre kunder kan raskt forbedre sin sikkerhetspostur med Mondoo, etter å ha vært fastlåst i årevis. Flere kunder har fortalt oss at Mondoo har redusert deres åpne sårbarheter med 60%, som er et godt resultat. Vi prøver å få dette tallet opp til 100% med vår agente sårbarhetsstyring.

Du har beskrevet remediering – prosessen med å faktisk fikse sårbarheter etter at de er oppdaget – som en myte. Hvorfor tror du at bransjen fortsatt investerer tungt i scanning og rapportering, samtidig som teamene sliter med å utføre fikseringene?

Dette er i stor grad et resultat av hvordan sikkerhets- og plattformteam er satt opp, spesielt i større organisasjoner. I lengste tid har vi behandlet dem som separate enheter, hver med sine egne mål, verktøy og prioriteringer. Men Conway’s lov viser hva som skjer: Du sender din org-chart i stedet for å løse problemet. Jeg har sett begge team peke fingre på hverandre – ofte med meget gode grunner.

Vi er nå endelig i ferd med å oppleve en skifte i bransjen, der selskaper innser at de vil ha mer ut av sikkerhet. De vil ikke ha en forretningsblokkerer. De vil ha en driver. Takk til fremtidsrettede ledere som nå dukker opp for å presse grensene, ser vi endelig en skifte i bransjen og i løsningene.

Hvordan kan organisasjoner overvinne den kulturelle kløften mellom sikkerhets- og DevOps-team som ofte bremser remediering?

DevSecOps er en god start; du må bringe utviklere og sikkerhet nærmere hverandre. Du kan ansette tverrfaglige roller som kan hjelpe med å brobygge gapet, som f.eks. SecOps-ingeniører eller plattform-eksperter med en sikkerhetsbakgrunn. Å fysisk bringe teamene sammen hjelper også. Det er avgjørende at ledelsen oppmuntre og spiller en rolle i denne prosessen. Etablere felles mål og metrikker og spore dem.

For å støtte teamene dine, vil du deretter ønske å bringe verktøy og teknologi sammen. Jeg snakker ikke bare om å dumpe sikkerhetsbilletter inn i billettsystemer. Du vil etablere en felles modell som gir begge teamene det de trenger. For eksempel fant vi at automatisering av sårbarhetsfiksering, hvor vi gir plattformteamene nok kontekst og viktigst av alt den spesifikke fikseringen de må bruke, hjelper dem med å utføre mye raskere på forespørsler. Jo mer du kombinerer dette med automatisering og skaper endringsforespørsler i automatiseringssystemer (som Terraform og Ansible), desto enklere er det. Du vil også ønske å ha en god kommunikasjonsvei tilbake, dvs. gjøre det enkelt for plattformteamene å protestere, få unntak og rapportere systemiske problemer. Alt dette oppmuntre til samarbeid og brobygger gapet.

Hva mener du ledelsen bør spille en rolle i å skape ansvar og samarbeid om å fikse sikkerhetsproblemer?

Som ledere har vi to store bidragsytere til våre teamers evne til å utføre: hva vi kommuniserer og hva vi måler. Hvis ledere bare snakker om å samle inn funn og peke på andre team som flaskenhalen, så vil deres team også behandle det på samme måte. Hvis de måler antall sikkerhetsproblemer og ikke kvaliteten og handlingene som er tatt, så vil teamene optimere for det.

Vi skaper de riktige betingelsene ved å arbeide med andre ledere over grensene, anerkjenne den felles naturen i dette området og fokusere på felles resultater i stedet for silo-målinger. Gang på gang ser vi at når ledere løser det felles problemet sammen, oppnår de mer for sine enkelte team og mer for bedriften, fordi de driver resultater som betyr noe.

Risikopoeng er bredt brukt, men mangler ofte kontekst, og varslingstrøtighet overvelder mange team. Hvordan bør organisasjoner omtenke prioritering så at de riktige problemene fikses?

For effektiv prioritering trenger du forretningskontekst og teknisk kontekst. Forretningskontekst inkluderer å kjenne til hvilke digitale aktiver holder lyset på hos ditt selskap og må beskyttes for å opprettholde din gode omdømme. For eksempel er databasen som inneholder brukernes private bilder eller portalene som prosesserer all netttrafikk, av høyere prioritet enn testsystemer som ikke er koblet til internettet. Når vi ser på sikkerhetsfunn, må vi kjenne til forretningskonteksten. Hvis du viser “kritisk” på et lavt prioritetsfunn, vil ditt team bli desensibilisert og ikke ta det alvorlig. Hvis et problem virkelig er kritisk, må du tydelig vise hvorfor.

Neste er teknisk kontekst. Dette betyr å kjenne systemet, dens konfigurasjon, plassering, tagger, apper, pakker og brukere. Men det er ikke alt. Du må heve din synsvinkel. Du må forstå hvordan et sikkerhetsproblem kan eksponere dine kritiske systemer, hvordan de er koblet sammen og integrert, ikke bare ved å se på ett eller to enkelt system, men ved å se på dem som en klasse. Vi må også vite hvordan disse systemene er automatisert og bygget for å kunne fortelle folk hvor de skal se og hvordan de skal fikse problemet ved roten.

Hvordan kan forsvarerne bruke AI på en ansvarlig måte for å holde seg foran uten å skape nye risikoer?

Å bruke AI gjør det mulig å fikse sårbarheter mye raskere, og gjøre det i maskinens hastighet. Men hvis AI-systemer ikke er sikre, kan de potensielt introdusere nye risikoer til miljøet. Når du deployer AI-drevne systemer, er det viktig å sikre at de bruker en sikker og gjennomsiktig arkitektur, og muliggjør grundig logging og hendelsesovervåking. Ved å begrense agenttillatelser til bare det som er nødvendig for å fullføre oppgavene, kan risikoene holdes til et minimum. Ytterligere sikkerhetsforanstaltninger, som å tillate brukerne å avbryte eller stenge ned AI-systemer når det er nødvendig, og å gjennomføre regelmessige auditorier av agentene og deres handlinger, er også noe jeg ville anbefale sterkt.

Hva mener du er essensielle sikkerhetsforanstaltninger når du gir automatisering mulighet til å fikse i produksjonsmiljøer?

For hver handling som en automatisering kan utføre, trenger du sikkerhetsforanstaltninger på plass for å sikre at den handler innenfor dens forventede område. Hvis du skaper en AI-agent og gir den fritt-roende tilgang til hele infrastrukturen, vil den bryte ting tidlig eller senere.

Lykkeligvis forstår vi sikkerhetsforanstaltninger godt takket være det uforbeholdne arbeidet i plattform-automatisering over de siste to tiårene. Moderne automatiseringssystemer har begrensninger på plass som kontrollerer hvilke handlinger som kan utføres. Hos Mondoo kombinerer vi AI-drevne fikseringer med motstridende politiske rammer som sjekker deres handlinger. Enhver fiksering skapes i kode, kan testes, verifiseres og viktigst av alt, begrenses når det er nødvendig.

Hvordan ser du på balansen mellom menneske-drevet og maskin-drevet fiksering i de neste fem årene?

Lignende selvkjørende biler, vil vi se team adoptere maskin-drevet automatisering i flere og flere områder, ett skritt av gangen. De vil starte med å fokusere på en undergruppe av sikkerhetsskopet, som f.eks. lavere prioritetssystemer, og introdusere agent-automatisering for det, skape metrikker og mål, og deretter rulle det ut. Når dette er automatisert, utvider du til andre områder.

Til slutt bør fokuset på automatisering ligge på områder som er store i skala med mange likheter. Disse områdene nyter mest av konsistensen som automatisering bringer. Jeg tror at om fem år vil alle større fikseringshandlinger være maskin-drevne og systemene vil være tett integrert mellom sikkerhets- og plattform-operasjoner.

Hva er din langsiktige visjon for hvordan sårbarhetsstyring bør se ut ved slutten av dette tiåret?

Ved slutten av tiåret, vil sårbarhetsstyring ha en mye sterkere fokus på automatisering og fiksering. Vår jobb som sikkerhetsspesialister vil være mer fokusert på å utvikle denne automatiseringen, arbeide med plattformteam på å sikre deres utviklende IT-miljøer. Disse systemene vil være mer tett integrert, bruke plattform-automatisering og agent-AI for å utføre handlinger i skala mens de er trygge og forutsigbare.

For mindre sikkerhetsteam med begrensede ressurser, hva praktiske første skritt kan de ta for å forbedre fiksering og motstandskraft?

Start med patch-automatisering. Introduser automatisering tidlig – spesielt når du har begrensede ressurser – og integrer sikkerhet i det fra starten. Dette er det enkleste skrittet som allerede reduserer eksponeringen til de automatiske skanningene som angriperne bruker.

Takk for det flotte intervjuet, lesere som ønsker å lære mer, kan besøke Mondoo.