Dom Richter, współzałożyciel Mondoo – seria wywiadów

Dom Richter, współzałożyciel Mondoo, to doświadczony lider produktowy z głęboką wiedzą na temat nowoczesnego rozwoju oprogramowania, projektowania produktów i zarządzania zespołem. Z wykształcenia obejmującym technologie backend, frontend i automatykę, prowadził wysoko wydajne zespoły inżynierskie poprzez kulturę zaufania, eksperymentowania i innowacji ukierunkowanych na cel. Jego praca łączy się z AI, cyberbezpieczeństwem i DevOps, gdzie podkreśla współpracę, ciągłe uczenie się i dostarczanie wartości dla użytkowników końcowych.

Mondoo to platforma automatyzacji bezpieczeństwa i zgodności, która umożliwia organizacjom ciągłe ocenianie, monitorowanie i zabezpieczanie ich infrastruktury w środowiskach chmurowych, lokalnych i hybrydowych. Wykorzystując podejście policy-as-code i machine learning, Mondoo pomaga zespołom identyfikować słabości, egzekwować standardy zgodności i wzmacniać postawę bezpieczeństwa bez spowalniania innowacji. Platforma integruje się bezproblemowo z nowoczesnymi procesami DevOps, czyniąc ciągłą zgodność osiągalną dla przedsiębiorstw wszystkich rozmiarów.

Czym skłoniło Cię do współzałożenia Mondoo, i jak Twoje doświadczenie jako hakera i lidera produktowego, a także Twoje doświadczenia w Google (GOOGL ), Chef i wcześniejszych startupach, ukształtowały misję firmy?

Kiedy byłem w okopach, łamiąc systemy jako część mojej pracy jako pentester, znalazłem wiele słabości, które można było łatwo zapobiec. W tym samym czasie bezpieczeństwo często było tak skoncentrowane na zalewaniu użytkowników alertami, że straciło z oczu to, co było najważniejsze. Wtedy pomyślałem “Muszę mieć prosty przycisk, którym mogę to naprawić”.

Następnie przeszedłem na drugą stronę i zacząłem bronić systemów. Nauczyłem się, jak właściwie operować nimi w skali, z automatyką i kodem. To jest przydatne, czy prowadzisz małą sieć domową, czy dużą firmę technologiczną. Pomysły są takie same. Ostatecznie to połączenie bezpieczeństwa i inżynierii platformy motywowało mnie do współzałożenia Mondoo. Chciałem zrobić różnicę w stanie bezpieczeństwa, a nie dodać kolejnego skanera, który generuje więcej alertów. Uważam, że jest bardzo motywujące widzieć, jak nasi klienci są w stanie szybko poprawić swoją postawę z Mondoo, po tym, jak przez lata byli zablokowani. Kilku klientów powiedziało nam, że Mondoo zmniejszył liczbę otwartych słabości o 60%, co jest świetnym wynikiem. Staramy się, aby ten wynik wyniósł 100% dzięki naszemu zarządzaniu słabościami.

Dlaczego, według Ciebie, branża nadal inwestuje dużo w skanowanie i raportowanie, pozostawiając zespoły, które walczą z wprowadzaniem napraw?

To w dużej mierze wynik tego, jak zespoły bezpieczeństwa i platformowe są ustawione, szczególnie w większych organizacjach. Przez najdłuższy czas traktowaliśmy je jako oddzielne jednostki, każda z własnymi celami, narzędziami i priorytetami. Ale prawo Conwaya dowodzi, co się dzieje: wysyłasz swój wykres organizacyjny zamiast rozwiązywać problem. Widziałem oba zespoły, które wskazują palcem na siebie – często z bardzo dobrych powodów.

Teraz w końcu doświadczamy zmiany w branży, gdzie firmy rozumieją, że chcą więcej od bezpieczeństwa. Nie chcą bloku biznesowego. Chcą kierowcę. Dzięki przyszłościowym liderom, którzy teraz pojawiają się, aby pchnąć granice, w końcu widzimy zmianę w branży i w rozwiązaniach.

Jak organizacje mogą pokonać kulturową przepaść między zespołami bezpieczeństwa i DevOps, która często spowalnia naprawę?

DevSecOps to dobra rozpiska; musisz przybliżyć developerów i zespoły bezpieczeństwa. Możesz zatrudnić role wielofunkcyjne, które mogą pomóc w przejściu między zespołami, takimi jak inżynierowie SecOps lub eksperci platformowi z doświadczeniem w zakresie bezpieczeństwa. Również fizyczne zbliżenie zespołów pomaga. Jest to kluczowe, aby kierownictwo zachęcało i brało udział w tym procesie. Ustal wspólne cele i metryki i śledź je.

Aby wesprzeć Twoje zespoły, chcesz następnie połączyć tooling i technologię. Nie mówię tylko o zrzucaniu biletów bezpieczeństwa do systemów ticketowych. Chcesz ustanowić wspólny model, który daje obu zespołom to, czego potrzebują. Na przykład, stwierdziliśmy, że automatyzacja napraw słabości, gdzie dajemy zespołom platformowym wystarczający kontekst i najważniejsze, konkretną naprawę, którą muszą zastosować, pomaga im wykonywać dużo szybciej na wnioski. Im więcej łączysz to z automatyką i tworzysz wnioski o zmiany w systemach automatyki (jak Terraform i Ansible), tym łatwiej jest. Chcesz również mieć dobry kanał komunikacji wstecz, tzn. ułatwić zespołom platformowym sprzeciw, uzyskać wyjątki i zgłosić systemowe problemy. To wszystko zachęca do współpracy i przełamuje przepaść.

Jaką rolę, według Ciebie, powinno odegrać kierownictwo w tworzeniu odpowiedzialności i współpracy wokół naprawy problemów bezpieczeństwa?

Jako liderzy mamy dwa główne wkłady w możliwość wykonania naszych zespołów: to, co komunikujemy, i to, co mierzymy. Jeśli liderzy mówią tylko o zbieraniu ustaleń i wskazywaniu na inne zespoły jako na wąskie gardło, to ich zespoły będą traktować to w ten sam sposób. Jeśli mierzą liczbę problemów bezpieczeństwa i nie ich jakości i podjętych działań, to zespoły zoptymalizują to.

Tworzymy odpowiednie warunki, pracując z innymi liderami przez granice, uznając wspólny charakter tej dziedziny i koncentrując się na wspólnych wynikach, a nie na metrykach w izolacji. Raz za razem widzimy, że gdy liderzy podejmują wspólne problemy razem, osiągają więcej dla swoich poszczególnych zespołów i więcej dla biznesu, ponieważ napędzają wyniki, które mają znaczenie.

Jak powinny organizacje przemyśleć priorytetyzację, aby naprawiać odpowiednie problemy?

Dla skutecznej priorytetyzacji potrzebujesz kontekstu biznesowego i technicznego. Kontekst biznesowy obejmuje wiedzę, które cyfrowe aktywa utrzymują światła w Twojej firmie i muszą być chronione, aby utrzymać dobrą reputację. Na przykład, baza danych zawierająca prywatne zdjęcia użytkowników lub bramy, które przetwarzają cały ruch sieciowy, są ważniejsze niż systemy testowe, które nie są połączone z Internetem. Gdy spoglądasz na ustalenia bezpieczeństwa, musisz wiedzieć, jaki jest kontekst biznesowy. Jeśli pokażesz “krytyczne” na niskim priorytecie, Twoje zespoły zostaną zdesensytyzowane i nie wezmą tego poważnie. Jeśli problem jest naprawdę krytyczny, musisz wyraźnie pokazać, dlaczego.

Następnie jest kontekst techniczny. Oznacza to wiedzę o systemie, jego konfiguracji, lokalizacji, tagach, aplikacjach, pakietach i użytkownikach. Ale to nie wszystko. Musisz podnieść swój punkt widzenia. Musisz zrozumieć, jak problem bezpieczeństwa może narażać Twoje krytyczne systemy, jak są one połączone i zintegrowane, nie tylko patrząc na jeden lub dwa systemy, ale patrząc na nie jako na klaster. Musisz również wiedzieć, jak te systemy są zautomatyzowane i zbudowane, aby szybko powiedzieć ludziom, gdzie szukać i jak naprawić problem u jego źródła.

Jak obrońcy mogą odpowiedzialnie używać AI, aby pozostać na czele, nie tworząc nowych ryzyk?

Używanie AI wielokrotnie zwiększa Twoją zdolność do naprawy słabości i robienia tego z prędkością maszyny. Jednak jeśli systemy AI nie są bezpieczne, mogą potencjalnie wprowadzić nowe ryzyka do środowiska. Podczas wdrożenia systemów AI, ważne jest, aby upewnić się, że używają one bezpiecznej i przejrzystej architektury, oraz umożliwiają dokładne logowanie i monitorowanie zdarzeń. Ograniczając uprawnienia agentów do tego, co jest niezbędne do wykonania przypisanych zadań, ryzyko można zminimalizować. Dodatkowe barierki, takie jak umożliwienie użytkownikom przerwania lub wyłączenia systemów AI, gdy jest to konieczne, oraz przeprowadzanie regularnych audytów agentów i ich działań, jest również czymś, co bardzo polecam.

Jakie barierki, według Ciebie, są niezbędne, gdy przyznaje się automatyce możliwość naprawy w środowiskach produkcyjnych?

Dla każdej akcji, którą automatyka może podjąć, musisz mieć barierki, aby upewnić się, że działa w ramach oczekiwanego zakresu. Jeśli utworzysz agenta AI i dasz mu swobodny dostęp do całej infrastruktury, to prędzej czy później coś złamie.

Szczęśliwie dobrze rozumiemy barierki dzięki nieustannym pracom w automatyce platformy w ciągu ostatnich dwóch dekad. Nowoczesne systemy automatyki mają ograniczenia, które kontrolują możliwe akcje. W Mondoo łączymy naprawy AI z ramami polityki przeciwnika, które sprawdzają ich akcje. Każda naprawa jest tworzona w kodzie, może być przetestowana, zweryfikowana i najważniejsze, ograniczona, gdy jest to konieczne.

Jak widzisz ewolucję balansu między naprawą prowadzoną przez ludzi a naprawą napędzaną przez maszynę w ciągu najbliższych pięciu lat?

Podobnie jak samochody autonomiczne, zobaczymy, jak zespoły przyjmują automatykę napędzaną przez maszynę w coraz większej liczbie obszarów, stopniowo. Zaczną od skupienia się na podziale zakresu bezpieczeństwa, takim jak systemy o niższym priorytecie, i wprowadzeniu automatyki agenckiej do tego, tworząc metryki i cele, a następnie stopniowo wdrażając ją. Gdy jest to zautomatyzowane, rozszerzasz to na inne obszary.

Ostatecznie, focus automatyki powinien być skierowany na obszary, które są duże w skali i mają wiele podobieństw. Te korzystają najbardziej z konsekwencji, jaką zapewnia automatyka. Uważam, że za pięć lat wszystkie główne akcje naprawy będą napędzane przez maszynę, a systemy będą ściśle zintegrowane między bezpieczeństwem a operacjami platformy.

Jaki jest Twój długoterminowy cel dla zarządzania słabościami, który powinien być osiągnięty do końca tej dekady?

Do końca dekady zarządzanie słabościami będzie miało znacznie silniejszy focus na automatyce i naprawie. Nasza praca jako specjalistów ds. bezpieczeństwa będzie bardziej ukierunkowana na rozwój tej automatyki, pracę z zespołami platformowymi nad zabezpieczaniem ich ewoluujących środowisk IT. Te systemy będą bardziej ściśle zintegrowane, wykorzystując automatykę platformy i AI, aby podejmować akcje w skali, przy jednoczesnym zachowaniu bezpieczeństwa i przewidywalności.    

Dla mniejszych zespołów bezpieczeństwa z ograniczonymi zasobami, jakie praktyczne pierwsze kroki mogą one podjąć, aby poprawić naprawę i odporność?

Zacznij od automatyzacji łatania. Wprowadź automatykę wcześnie – szczególnie, gdy masz ograniczone zasoby – i zintegruj bezpieczeństwo z nią od samego początku. To jest najprostszy krok, który już znacznie zmniejsza narażenie na automatyczne skany, których używają atakujący.

Dziękuję za wspaniały wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić Mondoo.