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

Раз уж вчера я обозрел один отчет сокращающей свой персонал 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-х обязательных и, самое главное, взаимоувязанных элементов:

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

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