Дом Ріхтер, співзасновник Mondoo – Інтерв’ю Серія

Дом Ріхтер, співзасновник Mondoo – досвідчений лідер продукту з глибокими знаннями сучасної розробки програмного забезпечення, дизайну продукту та керівництва командою. З досвідом, що охоплює бекенд, фронтенд та автоматизацію технологій, він очолював високоефективні інженерні команди через культуру довіри, експериментів та інновацій, спрямованих на досягнення мети. Його робота перетинається з AI, кібербезпекою та DevOps, де він підкреслює співробітництво, безперервне навчання та надання значущої цінності кінцевим користувачам.

Mondoo – це платформа автоматизації безпеки та відповідності, яка дозволяє організаціям безперервно оцінювати, моніторити та захищати свою інфраструктуру в хмарі, на місці та гібридних середовищах. Використовуючи політику як код і знання, отримані за допомогою машинного навчання, Mondoo допомагає командам виявляти уразливості, забезпечувати відповідність стандартам та посилювати безпеку без сповільнення інновацій. Платформа безшовно інтегрується в сучасні робочі процеси DevOps, роблячи безперервну відповідність реальністю для підприємств усіх розмірів.

Що надихнуло вас на співзаснування Mondoo, і як ваш досвід як хакера та лідера продукту, а також ваш досвід у Google (GOOGL ), Chef та раніше стартапах, сформував місію компанії?

Коли я був у траншеях, проникаючи в системи як частина своєї роботи як penetратор, я знайшов багато легко запобіжних слабкостей. Водночас безпека часто була так зосереджена на надсиланні користувачам великої кількості сповіщень, що втрачала з виду те, що було важливо. Тоді я подумав: “Має бути проста кнопка, яку я можу натиснути, щоб виправити ці речі”.

Потім я перейшов на іншу сторону і почав захищати системи. Я навчився належним чином експлуатувати речі в масштабі, за допомогою автоматизації та коду. Це корисно, незалежно від того, чи керуєте ви малим домашнім мережевим середовищем чи великою технологічною компанією. Ідеї однакові. В кінцевому підсумку це поєднання безпеки та платформної інженерії мотивувало мене на співзаснування Mondoo. Я хотів зробити різницю в стані безпеки, а не просто додати ще один сканер, який генерує ще більше сповіщень. Мене дуже мотивує бачити, як наші клієнти можуть швидко покращити свою позицію з Mondoo після років застрягання. Декілька клієнтів повідомили нам, що Mondoo знизила кількість відкритих уразливостей на 60%, що є хорошим результатом. Ми намагаємось підвищити цей показник до 100% за допомогою нашої агентської системи управління уразливостями.

Ви описали виправлення – процес фактичного виправлення уразливостей після їх виявлення – як міф. Чому, на вашу думку, галузь продовжує вкладати великі кошти в сканування та звітність, залишаючи команди боротьби з виправленнями?

Це в основному результат того, як команди безпеки та платформної інженерії створені, особливо в великих організаціях. Протягом найдовшого часу ми ставили їх окремими сутностями, кожна з яких мала свої власні цілі, інструменти та пріоритети. Але закон Конвея доводить, що відбувається: Ви відправляєте свою організаційну схему замість вирішення проблеми. Я бачив, як обидві команди вказують пальцем одна на одну – часто з дуже добрими причинами.

Тепер ми нарешті переживаємо зміну в галузі, коли компанії розуміють, що вони хочуть більше від безпеки. Вони не хочуть бізнес-блокувальника. Вони хочуть драйвера. Завдяки лідерам, які тепер з’являються, щоб розширити межі, ми нарешті бачимо зміну в галузі та в рішеннях.

Як організації можуть подолати культурний розрив між командами безпеки та DevOps, який часто сповільнює виправлення?

DevSecOps – це хороший початок; вам потрібно привести розробників та команди безпеки ближче. Ви можете найняти ролі, які можуть допомогти звузити розрив, наприклад інженерів SecOps або платформних експертів з безпековим прошарком. Також фізично приведення команд разом допомагає. Для цього важливо, щоб лідерство заохочувало та брало участь у цьому процесі. Встановіть спільні цілі та метрики та відстежуйте їх.

Для підтримки ваших команд ви потім хочете привести інструменти та технології разом. Я не говорю про те, щоб просто скинути безпекові квитки в системи обліку. Ви хочете встановити спільну модель, яка дає обом командам те, що їм потрібно. Наприклад, ми виявили, що автоматизація виправлень уразливостей, коли ми даємо платформним командам достатній контекст і, що найважливіше, конкретне виправлення, яке вони повинні застосувати, допомагає їм виконувати набагато швидше запити. Чим більше ви поєднуєте це з автоматизацією та створюєте запити на зміну в автоматизованих системах (наприклад, Terraform та Ansible), тим легше це робиться. Ви також хочете мати добрий шлях зв’язку назад, тобто зробити легко для платформних команд об’єктивувати, отримувати винятки та повідомляти про системні проблеми. Все це заохочує співробітництво та звужує розрив.

Якою, на вашу думку, повинна бути роль лідерства у створенні відповідальності та співробітництва щодо виправлення проблем безпеки?

Як лідери, ми маємо два великих внески у здатність наших команд виконувати завдання: те, про що ми спілкуємося, і те, що ми вимірюємо. Якщо лідери говорять лише про збір висновків і вказують на інші команди як на瓶ешку, то їхні команди будуть ставитись до цього так само. Якщо вони вимірюють кількість проблем безпеки та не їхню якість і дії, прийняті щодо них, то команди будуть оптимізувати це.

Ми створюємо правильні умови, працюючи з іншими лідерами через межі, визнаючи спільну природу цієї області, і фокусуючись на спільних результатах, а не на ізольованих метриках. Час від часу ми бачимо, що коли лідери разом вирішують спільну проблему, вони досягають більшого для своїх індивідуальних команд і більшого для бізнесу, оскільки вони рухають ті результати, які мають значення.

Ризикові оцінки широко використовуються, але часто не мають контексту, а втома від сповіщень перевантажує багато команд. Як організації повинні переосмислити пріоритезацію, щоб виправити правильні проблеми?

Для ефективної пріоритезації вам потрібно бізнес-контекст і технічний контекст. Бізнес-контекст включає знання про те, які цифрові активи утримують світло в вашій компанії та повинні бути захищені для підтримання вашої хорошої репутації. Наприклад, база даних, яка містить приватні зображення користувачів, або шлюзи, які обробляють весь трафік веб-сайту, мають вищу пріоритетність, ніж тести системи, які не підключені до Інтернету. Коли ми дивимося на висновки безпеки, ми повинні знати бізнес-контекст. Якщо ви показуєте “критичний” на низькопріоритетному висновку, ваші команди будуть звикати до цього і не будуть його сприймати серйозно. Якщо проблема дійсно критична, вам потрібно чітко показати, чому.

Далі йде технічний контекст. Це означає знання системи, її конфігурації, місця, тегів, застосунків, пакетів та користувачів. Але це не все. Вам потрібно підвищити свій погляд. Вам потрібно зрозуміти, як проблема безпеки може викрити ваші критичні системи, як вони пов’язані та інтегровані, не лише дивлячись на одну чи дві окремі системи, а розглядаючи їх як кластер. Ми також повинні знати, як ці системи автоматизовані та побудовані, щоб швидко сказати людям, куди дивитися та як виправити проблему в її основі.

Як захисники можуть використовувати AI відповідально, щоб залишатися попереду без створення нових ризиків, коли атакувальники все частіше використовують AI?

Використання AI значно збільшує вашу здатність виправляти уразливості та робити це з швидкістю машини. Однак, якщо системи AI не безпечні, вони можуть потенційно вводити нові ризики в середовище. При розгортанні систем, що працюють на основі AI, важливо забезпечити, щоб вони використовували безпечну та прозору архітектуру, а також забезпечували повне протоколювання та моніторинг подій. Обмежуючи дозволи агентів лише тим, що необхідно для виконання призначених завдань, ризики можна мінімізувати. Додаткові периметри безпеки, такі як дозволяючи користувачам перервати або зупинити агентські системи AI, коли це необхідно, а також проведення регулярних аудитів агентів та їхніх дій,也是 те, що я високо рекомендую.

Які периметри безпеки, на вашу думку, є необхідними при наданні автоматизації можливості виправляти в середовищах виробництва?

Для кожної дії, яку може виконати автоматизація, вам потрібно встановити периметри безпеки, щоб забезпечити виконання дій у передбаченому обсязі. Якщо ви створюєте агентський AI і надаєте йому вільний доступ до всієї вашої інфраструктури, він рано чи пізно щось зламає.

На щастя, ми добре розуміємо периметри безпеки завдяки наполегливій роботі в галузі платформної автоматизації за останні два десятиліття. Сучасні системи автоматизації мають обмеження, які контролюють дії, які можна виконувати. У Mondoo ми поєднуємо агентські виправлення, що працюють на основі AI, з протидією політичної інфраструктури, яка перевіряє їхні дії. Будь-яке виправлення створюється в коді, може бути протестовано, верифіковано та, що найважливіше, обмежено, коли це необхідно.

Як ви бачите розвиток балансу між людьми, що очолюють, та машинами, що керують виправленнями, протягом наступних п’яти років?

Аналогічно до самохідних автомобілів, ми побачимо, як команди приймуть машинну автоматизацію в усе більшій кількості областей, крок за кроком. Вони почнуть з підмножини області безпеки, введення агентської автоматизації для неї, створення метрик та відстежування цілей, а потім поступово розгортатимуть її далі. Як тільки це буде автоматизовано, ви розширите до інших областей.

У кінцевому підсумку, фокус автоматизації повинен бути на областях, які великі за масштабом та мають багато подібностей. Ці області найбільше виграють від консистентності, яку приносить автоматизація. Я вважаю, що за п’ять років всі основні дії з виправлення будуть машинними, а системи будуть тісно інтегровані між безпекою та платформними операціями.

Яка ваша довгострокова бачення того, яким повинно бути управління уразливостями до кінця цього десятиліття?

До кінця десятиліття управління уразливостями матиме значно більший фокус на автоматизації та виправленні. Наша робота як спеціалістів з безпеки буде більш зосереджена на розвитку цієї автоматизації, роботі з платформними командами над безпечними ІТ-середовищами. Ці системи будуть більш тісно інтегровані, використовуючи платформну автоматизацію та агентський AI для виконання дій у масштабі, залишаючись при цьому безпечними та передбачуваними.    

Для менших команд безпеки з обмеженими ресурсами які практичні перші кроки вони можуть зробити для покращення виправлення та стійкості?

Почніть з автоматизації патчів. Введіть автоматизацію рано – особливо коли у вас обмежені ресурси – і інтегруйте безпеку з самого початку. Це найпростіший крок, який вже значно знижує вразливість до автоматичних сканувань, які використовують атакувальники.

Дякуємо за велике інтерв’ю. Читачам, які хочуть дізнатися більше, рекомендуємо відвідати Mondoo.