Да, часто бывает, что тот или иной класс продуктов смешивают с дерьмом, потому что у того, кто его смешивает, нет своего такого же решения. И поэтому он и обливает грязью решения конкурентов, попутно предлагая свой собственный класс решений. Ну тут все как в учебниках маркетинга. Если не можешь быть лидером в какой-то нише, создай себе свою нишу и будь лидером в ней.
Но мне понравился термин и самое главное, что в нем есть определенный смысл. Авторы считают, что то, что многие компании полагаются на решения класса 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-х обязательных и, самое главное, взаимоувязанных элементов:
- средства мониторинга и управления площадью атаки
- программа тестирования защищенности
- средства анализа защищенности
- навыки и квалификация персонала.
Интересно, что у нас (даже несмотря на уход многих зарубежных вендоров) есть почти все нужные компоненты для обеспечения сопротивляемости атакам. Дело за малым — выстроить целостную программу, которая бы объединяла все нужные компоненты. Правда, с этим как раз проблемы. По отдельности мы еще умеем реализовывать описанные выше компоненты, но вот собрать из отдельных кирпичиков красивое и прочное здание?..
Заметка
От управления площадью атаки к управлению сопротивляемостью атакам была впервые опубликована на Бизнес без опасности .
