От управления площадью атаки к управлению сопротивляемостью атакам

SecOps

Раз уж вчера я обозрел один отчет сокращающей свой персонал HackerOne, то сегодня решил обратить свое внимание на другой их отчет; мало ли, вдруг больше ничего не выпустят. Новый отчет посвящен достаточно интересному и новому понятию — «сопротивляемость атакам» (attack resistance). HackerOne его ввел непросто так — они его использовали для продвижения своих продуктов и услуг.

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

Но мне понравился термин и самое главное, что в нем есть определенный смысл. Авторы считают, что то, что многие компании полагаются на решения класса Attack Surface Management (ASM) является нелучшей практикой, так как создает иллюзию защищенности и ложное чувство знания всех активов и слабых мест в инфраструктуре. И вот почему:

  • Неполное знание о площади атаки из-за ее динамичной природы — микросервисы, контейнеры, виртуалки, API, все это затрудняет составление полного и актуального перечня активов, которые могут быть атакованы.
  • Частота тестирования не соответствует частоте обновлений приложений. По статистике только один из трех сервисов или приложений тестируются чаще одного раза в год. То есть в отношении оставшихся 2/3 приложений мы даже не знаем, есть ли в них уязвимости или нет.
  • Не самые лучшие сканеры безопасности, но самое главное, неумение интерпретировать результаты даже тех инструментов, что есть в компаниях.
  • Отсутствие персонала, который понимает в современных технологиях типа Kubernetes, облака, JavaScript, различные API, а также legacy приложения.

Эти 4 компонента в совокупности и составляют так называемый разрыв в сопротивляемости атакам, который появляется, когда мы излишне полагаемся на средства класса ASM и тем более иные, более традиционные средства защиты.

Первое, с чего надо начать, пытаясь преодолеть этот разрыв, — это расширить вопросы ИБ на новые области контроля:

  • разработку, в рамках которой создаются приложения, фиксятся обнаруживаемые уязвимости и выпускаются новые версии,
  • операции, в рамках которых приложения устанавливаются в разных фрагментах инфраструктуры, включая облака и АСУ ТП, и которые могут быть некорректно сконфигурированы
  • ИТ, которые устраняют уязвимости в приложениях.

И, конечно, кибербезопасность, которая должна следить за безопасностью кода, архитектуры и технологий, используемых в компании. Вроде ничего нового; про безопасную разработку говорят уже давно. Про ИБ АСУ ТП или включение темы ИБ в ИТ тоже. Вопрос тут в объединении всех компонентов вместе с курирующей ролью ИБ.

Согласно статистике одна треть крупных предприятий считает, что отслеживает менее 75% площади атаки на свою инфраструктуру. Почти 20% компаний думают, что более 50% их площади атаки неизвестна или неконтролируема!

Частота тестирования инфраструктуры на уязвимость — это еще одна колоссальная проблема, которая мешает эффективной ИБ. Меня всегда удивляло то, какое количество облачных приложений, используется крупными предприятиями. По разной статистике это число крутится вокруг значения в 1200. Еще 100 приложений SaaS и около 500 своих приложений (мобильные приложения, обновляемые раз в неделю или раз в месяц, — вообще отдельная тема). И все это постоянно обновляется, но адекватным образом не тестируется.

Сколько у вас средств анализа защищенности? Сканеры уязвимости приложений? Сканеры SAST/DAST/IAST? Решения класса SCA? Инструменты для тестирования контейнером и микросервисов?

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

При этом уровень квалификации персонала, использующего средства анализа защищенности, далек от идеала. Нет взаимодействия между разными подразделениями, отсутствие покрытия нужных компонентов инфраструктуры (например, облаков и контейнеров или нужных языков программирования и фреймворков), много «шума», непонимание результатов сканирования…

Про кадры писать ничего не буду. Ситуация с ними и так понятна — это общемировая проблема.

Соответственно для того, чтобы описанный разрыв закрыть и предлагается использовать подход по управлению сопротивляемостью к атакам, который состоит из 4-х обязательных и, самое главное, взаимоувязанных элементов:

  • средства мониторинга и управления площадью атаки
  • программа тестирования защищенности
  • средства анализа защищенности
  • навыки и квалификация персонала.

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

Оцените статью
Бизнес без опасности
Есть что добавить? Добавьте!

Нажимая кнопку "Отправить", я даю свое согласие на обработку персональных данных (если вдруг они указаны в комментарии) в соответствие с политикой конфиденциальности. Также я соглашаюсь с тем, что в своем комментарии не раскрываю никаких сведений, составляющих государственную тайну, а также никакой иной информации, охраняемой законом (для этого используйте иные способы :-) ), если это не разрешено ее владельцем. Ваш комментарий может появиться не сразу, а после модерации (так бывает не всегда, но бывает).

  1. xpomob

    шепотом: _антихрупкость_

    Ответить
  2. xpomob

    даешь антихрупкость

    Ответить
    1. Алексей Лукацкий автор

      Хороший термин 🙂

      Ответить