Дом Рихтер, сооснователь Mondoo – Серия интервью

Дом Рихтер, сооснователь Mondoo, является опытным лидером продукта с глубокими знаниями в области современного разработки программного обеспечения, дизайна продукта и руководства командой. Обладая опытом в области бэкенда, фронтенда и автоматизации, он возглавлял высокоэффективные инженерные команды, создавая культуру доверия, экспериментов и инноваций, ориентированных на результат. Его работа пересекается с ИИ, кибербезопасностью и DevOps, где он подчеркивает важность сотрудничества, непрерывного обучения и предоставления значимой ценности конечным пользователям.

Mondoo – это платформа для автоматизации безопасности и соответствия требованиям, которая позволяет организациям непрерывно оценивать, контролировать и защищать свою инфраструктуру в облачных, локальных и гибридных средах. Используя подход “политика как код” и машинное обучение, Mondoo помогает командам выявлять уязвимости, обеспечивать соблюдение стандартов и укреплять позицию в области безопасности без замедления инноваций. Платформа интегрируется без проблем в современные рабочие процессы DevOps, что делает непрерывное соответствие требованиям реальностью для предприятий любого размера.

Что вдохновило вас на создание Mondoo, и как ваш опыт в качестве хакера и лидера продукта, а также ваш опыт работы в Google (GOOGL ), Chef и ранних стартапах, сформировали миссию компании?

Когда я был в окопах, взламывая системы в рамках своей работы в качестве пентестера, я обнаружил много легко предотвратимых слабостей. В то же время безопасность часто была так сосредоточена на наводнении пользователей предупреждениями, что теряла из виду то, что действительно имело значение. Тогда я подумал: “Должна быть простая кнопка, которую можно нажать, чтобы исправить эти вещи”.

Затем я перешел на другую сторону и начал защищать системы. Я научился правильно эксплуатировать системы в масштабе, используя автоматизацию и код. Это полезно, будь то управление небольшой домашней сетью или эксплуатация крупной технологической компании. Идеи остаются одними и теми же. В конечном итоге именно это сочетание безопасности и платформенной инженерии мотивировало меня на создание Mondoo. Я хотел сделать разницу в состоянии безопасности, а не просто добавить еще один сканер, который генерирует еще больше предупреждений. Мне очень мотивирует видеть, как наши клиенты могут быстро улучшить свою позицию с помощью Mondoo после того, как они были заблокированы на годы. Несколько клиентов рассказали нам, что Mondoo снизил количество открытых уязвимостей на 60%, что является отличным результатом. Мы пытаемся увеличить этот показатель до 100% с помощью нашей агентской уязвимой системы управления.

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

Это в основном результат того, как команды безопасности и платформы организованы, особенно в крупных организациях. В течение долгого времени мы рассматривали их как отдельные сущности, каждая со своими собственными целями, инструментами и приоритетами. Но закон Конвея доказывает, что происходит: вы отправляете свою организационную структуру вместо решения проблемы. Я видел, как обе команды указывали пальцем друг на друга – часто по очень хорошим причинам.

Теперь мы наконец испытываем сдвиг в отрасли, когда компании понимают, что они хотят получить больше от безопасности. Они не хотят бизнес-блокировки. Они хотят драйвера. Благодаря дальновидным лидерам, которые сейчас появляются, чтобы расширить границы, мы наконец видим сдвиг в отрасли и в решениях.

Как организации могут преодолеть культурный разрыв между командами безопасности и DevOps, который часто замедляет исправление?

DevSecOps – это хорошая отправная точка; вам нужно привести разработчиков и команды безопасности ближе друг к другу. Вы можете нанять кросс-функциональные роли, которые могут помочь мостить разрыв, такие как инженеры SecOps или платформенные эксперты с опытом работы в области безопасности. Также физически объединение команд помогает. Очень важно, чтобы лидерство поощряло и играло роль в этом процессе. Установите общие цели и метрики и отслеживайте их.

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

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

Как лидеры, у нас есть два основных вклада в способность наших команд выполнять задачи: то, о чем мы общаемся, и то, что мы измеряем. Если лидеры только говорят о сборе результатов и указывают на другие команды как на узкие места, то их команды будут относиться к этому так же. Если они измеряют количество проблем безопасности и не их качество и принимаемые меры, то команды будут оптимизироваться для этого.

Мы создаем правильные условия, работая с другими лидерами через границы, признавая общую природу этой области, и фокусируясь на общих результатах, а не на изолированных метриках. Время от времени мы видим, что когда лидеры решают общую проблему вместе, они достигают большего для своих отдельных команд и для бизнеса, поскольку они стимулируют результаты, которые имеют значение.

Риски широко используются, но часто не имеют контекста, и усталость от предупреждений перегружает многие команды. Как организации должны пересмотреть приоритизацию, чтобы исправить правильные проблемы?

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

Далее идет технический контекст. Это означает знание системы, ее конфигурации, местоположения, тегов, приложений, пакетов и пользователей. Но это не все. Вам нужно повысить уровень вашего взгляда. Вам необходимо понять, как проблема безопасности может раскрыть ваши критические системы, как они связаны и интегрированы, не только глядя на одну или две отдельные системы, но и глядя на них как на кластер. Нам также необходимо знать, как эти системы автоматизированы и построены, чтобы быстро сказать людям, где посмотреть и как исправить проблему у ее корня.

Как защитники могут использовать ИИ ответственно, чтобы оставаться впереди, не создавая новых рисков, учитывая, что атакующие все чаще используют ИИ?

Использование ИИ во много раз увеличивает вашу способность исправлять уязвимости и делать это с машинной скоростью. Однако, если системы ИИ не являются безопасными, они могут потенциально ввести новые риски в среду. При развертывании систем, основанных на ИИ, важно обеспечить, чтобы они использовали безопасную и прозрачную архитектуру, и обеспечивали тщательное ведение журналов и мониторинг событий. Ограничивая разрешения агентов только тем, что необходимо для выполнения назначенных задач, риски можно свести к минимуму. Дополнительные ограничители, такие как разрешение пользователям прерывать или отключать системы ИИ, когда это необходимо, и проведение регулярных аудитов агентов и их действий, также являются чем-то, что я бы очень рекомендовал.

Какие ограничители, по вашему мнению, являются необходимыми при предоставлении автоматизации возможности исправлять в производственных средах?

Для каждого действия, которое может выполнить автоматизация, вам нужны ограничители, чтобы обеспечить, что она действует в пределах ожидаемого объема. Если вы создаете агент ИИ и даете ему свободный доступ ко всей вашей инфраструктуре, он рано или поздно сломает что-то.

К счастью, мы хорошо понимаем ограничители благодаря неустанной работе в области платформенной автоматизации за последние два десятилетия. Современные системы автоматизации имеют ограничения, которые контролируют действия, которые можно выполнить. В Mondoo мы объединяем исправления, основанные на ИИ, с противостоящими политическими框ами, которые проверяют их действия. Любое исправление создается в коде, может быть протестировано, проверено и, самое главное, ограничено при необходимости.

Как вы видите эволюцию баланса между человеко-ориентированным и машинным исправлением в течение следующих пяти лет?

Аналогично самоходным автомобилям, мы увидим, как команды принимают машинную автоматизацию в все больше и больше областей, шаг за шагом. Они начнут сначала фокусироваться на подмножестве области безопасности, таком как системы низкого приоритета, и вводить агентскую автоматизацию для этого, создавая метрики и отслеживая цели, и затем постепенно развертывать ее. Как только это будет автоматизировано, вы расширяете до других областей.

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

Каково ваше долгосрочное видение того, как должно выглядеть управление уязвимостями к концу этого десятилетия?

К концу десятилетия управление уязвимостями будет иметь гораздо больший фокус на автоматизации и исправлении. Наша работа в качестве специалистов по безопасности будет более сосредоточена на эволюции этой автоматизации, работе с платформенными командами над безопасностью их развивающихся ИТ-сред, и этих системах будет более тесно интегрировано, используя платформенную автоматизацию и агентский ИИ для выполнения действий в масштабе, оставаясь при этом безопасными и предсказуемыми.

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

Начните с автоматизации исправления. Введите автоматизацию рано – особенно когда у вас ограниченные ресурсы – и интегрируйте безопасность в нее с самого начала. Это самый простой шаг, который уже значительно снижает уязвимость к автоматическим сканированиям, которые используют атакующие.

Спасибо за отличное интервью. Читателям, которые хотят узнать больше, рекомендуется посетить Mondoo.