Dom Richter, medgrundare på Mondoo – Intervjuserie

Dom Richter, medgrundare på Mondoo är en erfaren produktledare med djup expertis inom modern programvaruutveckling, produktdesign och teamledning. Med en bakgrund som omfattar backend, frontend och automatiseringsteknik har han lett högpresterande ingenjörsteam genom en kultur av tillit, experiment och målinriktad innovation. Hans arbete skär över AI, cybersäkerhet och DevOps, där han betonar samarbete, kontinuerligt lärande och att leverera meningsfullt värde till slutanvändare.

Mondoo är en plattform för automatiserad säkerhet och regelefterlevnad som möjliggör för organisationer att kontinuerligt utvärdera, övervaka och skydda sin infrastruktur över moln, lokala och hybridmiljöer. Genom att utnyttja policy-as-code och maskinlärningsdrivna insikter hjälper Mondoo team att identifiera sårbarheter, upprätthålla regelefterlevnad och stärka säkerhetsläget utan att bromsa innovationen. Plattformen integreras sömlöst i moderna DevOps-arbetsflöden, vilket gör kontinuerlig regelefterlevnad till en uppnåelig verklighet för företag av alla storlekar.

Vad inspirerade dig att medgrundande Mondoo, och hur har din bakgrund som hackare och produktledare – tillsammans med dina erfarenheter från Google (GOOGL ), Chef och tidigare startup-företag – format företagets mission?

När jag var i skyttegravarna och bröt mig in i system som en del av mitt jobb som pentester, hittade jag många lätt förebyggbara svagheter. Samtidigt var säkerheten ofta så fokuserad på att översvämma användare med varningar, att de förlorade sikte på vad som verkligen betydde något. Då tänkte jag “Det måste finnas en enkel knapp som jag kan trycka på för att åtgärda dessa saker”.

Jag bytte sedan sida och började försvara system. Jag lärde mig hur man ordentligt opererar saker i stor skala, med automatisering och kod. Detta är användbart oavsett om du kör ett litet hemmanätverk eller ett stort techföretag. Idéerna är desamma. Till slut var det denna kombination av säkerhet och plattformsutveckling som motiverade mig att medgrundande Mondoo. Jag ville göra en skillnad i säkerhetens tillstånd, inte bara lägga till en annan skanner som genererade fler varningar. Jag tycker det är mycket motiverande att se hur våra kunder kan snabbt förbättra sin position med Mondoo, efter att ha varit fast i år. Flera kunder har berättat för oss att Mondoo minskade deras öppna sårbarheter med 60%, vilket är ett utmärkt resultat. Vi försöker få det numret upp till 100% med vår agenterade sårbarhets hantering.

Du har beskrivit åtgärd – processen att faktiskt åtgärda sårbarheter efter att de har upptäckts – som en myt. Varför tror du att branschen fortsätter att investera kraftigt i skanning och rapportering medan team kämpar för att genomföra åtgärderna?

Detta är till stor del resultatet av hur säkerhets- och plattformsteam är uppbyggda, särskilt i större organisationer. Under lång tid har vi behandlat dem som separata enheter, var och en med sina egna mål, verktyg och prioriteringar. Men Conway’s lag bevisar vad som händer: Du skickar din organisationsstruktur i stället för att lösa problemet. Jag har sett båda teamen peka finger åt varandra – ofta av mycket goda skäl.

Vi upplever nu slutligen en förändring i branschen, där företag inser att de vill ha mer ut av säkerhet. De vill inte ha en affärsbroms. De vill ha en drivkraft. Tack vare framåtriktade ledare som nu dyker upp för att driva gränserna ser vi slutligen en förändring i branschen och i lösningarna.

Hur kan organisationer övervinna den kulturella klyftan mellan säkerhets- och DevOps-team som ofta bromsar åtgärd?

DevSecOps är en bra start; du behöver bringa utvecklare och säkerhet närmare varandra. Du kan anställa tvärfunktionella roller som kan hjälpa till att brottas över klyftan, som SecOps-ingenjörer eller plattformsexperter med en säkerhetsbakgrund. Att fysiskt bringa teamen tillsammans hjälper också. Det är avgörande att ledningen uppmuntrar och spelar en roll i denna process. Etablera gemensamma mål och mätvärden och spåra dem.

För att stödja dina team vill du sedan bringa verktyg och teknologi tillsammans. Jag talar inte om att bara dumpa säkerhetstickets i biljettsystem. Du vill etablera en gemensam modell som ger båda teamen vad de behöver. Till exempel har vi funnit att automatisering av sårbarhetsåtgärder där vi ger plattformsteam tillräckligt med sammanhang och framför allt den specifika åtgärden som de behöver tillämpa hjälper dem att utföra mycket snabbare på begäran. Ju mer du kombinerar detta med automatisering och skapar ändringsbegäranden i automatiseringssystem (som Terraform och Ansible), desto enklare är det. Du vill också ha en bra kommunikationsväg tillbaka, dvs. göra det enkelt för plattformsteam att invända, få undantag och rapportera systematiska problem. Allt detta uppmuntrar till samarbete och brottar över klyftan.

I din mening, vilken roll bör ledningen spela för att skapa ansvar och samarbete kring att åtgärda säkerhetsproblem?

Som ledare har vi två stora bidrag till våra teams förmåga att utföra: vad vi kommunicerar och vad vi mäter. Om ledare bara talar om att samla in fynd och peka på andra team som flaskhalsen, då kommer deras team att behandla det på samma sätt. Om de mäter antalet säkerhetsproblem och inte deras kvalitet och åtgärder som vidtas, då kommer teamen att optimera för det.

Vi skapar de rätta förutsättningarna genom att arbeta med andra ledare över gränserna, erkänna den gemensamma naturen i detta område och fokusera på gemensamma resultat i stället för isolerade mått. Tid och tid igen ser vi att när ledare tacklar det gemensamma problemet tillsammans, uppnår de mer för sina enskilda team och mer för företaget, eftersom de driver de resultat som betyder något.

Riskpoäng används i stor utsträckning men saknar ofta sammanhang, och varningsutmattning överväldigar många team. Hur bör organisationer omdefiniera prioritering så att rätt problem åtgärdas?

För effektiv prioritering behöver du affärssammanhang och tekniskt sammanhang. Affärssammanhang inkluderar att veta vilka digitala tillgångar som håller lamporna tända i ditt företag och som behöver skyddas för att upprätthålla din goda rykte. Till exempel är databasen som innehåller användarnas privata bilder eller grindarna som bearbetar all webbtrafik av högre prioritet än testsystem som inte är anslutna till internet. När vi tittar på säkerhetsfynd, måste vi veta affärssammanhanget. Om du visar “kritisk” på ett lågt prioritetsfynd, kommer dina team att bli desensibiliserade och inte ta det på allvar. Om ett problem verkligen är kritiskt, måste du tydligt visa varför.

Nästa är tekniskt sammanhang. Detta innebär att veta systemet, dess konfiguration, plats, taggar, appar, paket och användare. Men det är inte allt. Du måste höja din vy. Du måste förstå hur ett säkerhetsproblem kan exponera dina kritiska system, hur de är anslutna och integrerade, genom att inte bara titta på ett eller två enskilda system, utan genom att titta på dem som en kluster. Vi måste också veta hur dessa system är automatiserade och byggda för att snabbt kunna berätta för människor var de ska titta och hur de ska åtgärda problemet i dess rot.

Som angripare alltmer använder AI, hur kan försvarare använda AI på ett ansvarsfullt sätt för att hålla sig före utan att skapa nya risker?

Att använda AI multiplicerar kraftigt din förmåga att åtgärda sårbarheter och göra det i maskinens hastighet. Men om AI-system inte är säkra, kan de potentiellt introducera nya risker i miljön. När du distribuerar AI-drivna system är det viktigt att se till att de använder en säker och transparent arkitektur, och möjliggör omfattande loggning och händelseövervakning. Genom att begränsa agentbehörigheter till endast vad som är nödvändigt för att slutföra tilldelade uppgifter, kan risker minimeras. Ytterligare skydd, som att tillåta användare att avbryta eller stänga av AI-system när som helst, och genomföra regelbundna revisioner av agenterna och deras åtgärder, är också något som jag skulle starkt rekommendera.

Vilka skyddsanordningar tror du är essentiella när du ger automatisering möjlighet att åtgärda i produktionsmiljöer?

För varje åtgärd som en automatisering kan vidta, behöver du skyddsanordningar på plats för att se till att den agerar inom dess förväntade omfång. Om du skapar en AI-agent och ger den fri tillgång till hela din infrastruktur, kommer den att bryta saker tidigare eller senare.

Luckligtvis förstår vi skyddsanordningar riktigt bra tack vare det outtröttliga arbetet inom plattformsautomatisering under de senaste två decennierna. Moderna automatiseringssystem har begränsningar på plats som kontrollerar vilka åtgärder som kan vidtas. Hos Mondoo kombinerar vi AI-drivna åtgärder med motstridiga policyramverk som kontrollerar deras åtgärder. Varje åtgärd skapas i kod, kan testas, verifieras och framför allt begränsas när som helst.

Hur ser du på balansen mellan människodriven och maskindriven åtgärd utvecklas under de närmaste fem åren?

Liknande självkörande bilar, kommer vi att se team anta maskindriven automatisering i allt fler områden, ett steg i taget. De kommer att börja med att fokusera på en undergrupp av säkerhetsområdet, såsom lågprioriterade system, och introducera agenterad automatisering för det, skapa mått och spåra mål, och sedan gradvis rulla ut det. När detta är automatiserat, expanderar du till andra områden.

Till slut bör fokus på automatisering ligga på områden som är stora i skala med många likheter. Dessa områden kommer att dra nytta av den konsekvens som automatiseringen medför. Jag tror att om fem år kommer alla stora åtgärdsåtgärder att vara maskindrivna och systemen kommer att vara tätt integrerade mellan säkerhet och plattformsdrift.

Vad är din långsiktiga vision för hur sårbarhetshantering bör se ut i slutet av detta decennium?

I slutet av decenniet kommer sårbarhetshantering att ha ett mycket starkare fokus på automatisering och åtgärd. Vårt jobb som säkerhetsspecialister kommer att vara mer fokuserat på att utveckla denna automatisering, arbeta med plattformsteam på att säkra deras utvecklande IT-miljöer. Dessa system kommer att vara mer nära integrerade, med hjälp av plattformsautomatisering och agenterad AI för att vidta åtgärder i skala, samtidigt som de är säkra och förutsägbara.    

För mindre säkerhetsteam med begränsade resurser, vilka praktiska första steg kan de ta för att förbättra åtgärd och motståndskraft?

Börja med patch-automatisering. Introducera automatisering tidigt – särskilt när du har begränsade resurser – och integrera säkerhet i den från början. Detta är det enklaste steget som redan minskar exponeringen för de automatiserade skanningar som angripare använder.

Tack för den underbara intervjun, läsare som vill lära sig mer kan besöka Mondoo.