Не сканированием единым, или как построить процесс управления уязвимостями за 9 шагов

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

Шаг № 1: Определите уровень зрелости процессов управления уязвимостями

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

Попробуйте ответить на базовые вопросы:

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

Шаг № 2: Обеспечьте полное покрытие инфраструктуры

Вы не можете защитить то, о чем вы не знаете. Если у вас нет полной картины того, из чего состоит ваша ИТ-инфраструктура, вы не сможете ее защищать. Современная инфраструктура сложная и постоянно меняется количественно и качественно.
Теперь ИТ-инфраструктура базируется не только на стеке классических технологий (рабочие станции, серверы, виртуальные машины), но и на относительно новых – контейнерах, микросервисах. Служба информационной безопасности всячески убегает от последних, поскольку ей очень сложно работать с ними с помощью существующих наборов инструментов, которые состоят преимущественно из сканеров. Проблема в том, что любой сканер не может покрыть всю инфраструктуру. Чтобы сканер достучался до любого узла в инфраструктуре, нужно, чтобы совпало сразу несколько факторов. Актив должен быть внутри периметра организации на момент сканирования. У сканера должны быть сетевые доступы к активам, их учетным записям, чтобы собрать полную информацию.

По нашей статистике, когда речь идет о средних или крупных организациях, примерно 15–20% инфраструктуры не захватывается сканером по тем или иным причинам: актив выехал за пределы периметра или вообще никогда не появляется в офисе. Например, ноутбук сотрудника, который работает удаленно, но при этом имеет доступ в корпоративную сеть, или же актив находится во внешних облачных сервисах типа Amazon. И сканер, скорее всего, ничего не будет знать про эти активы, так как они вне зоны его видимости.

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

Шаг № 3: Выполните категоризацию активов

Не все активы одинаково полезны. Определить, какие активы важны, а какие нет, – ваша задача. Ни один инструмент, тот же сканер, не сделает это за вас. В идеале ИБ, ИТ и бизнес вместе анализируют инфраструктуру, чтобы выделить бизнес-критичные системы. Для них они определяют допустимые метрики по доступности, целостности, конфиденциальности, RTO/RPO и пр.

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

Шаг № 4: Проведите оценку инфраструктуры

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

Шаг № 5: Настройте отчетность

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

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

Шаг № 6: Приоритезируйте

Тут можно делать следующее:

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

2. Сфокусируйте внимание на тех активах, которые критичны для бизнеса. Нет ни одной организации в мире, которая может устранить уязвимости за один прием. Процесс устранения уязвимостей долгий и даже муторный.

3. Сужение поверхности атак. Вычищайте свою инфраструктуру от ненужного ПО, сервисов, закрывайте ненужные порты. У нас был недавно случай с одной компанией, у которой на 40 тысячах устройств было найдено около 100 тысяч уязвимостей, связанных со старой версией  браузера Mozilla. Как потом выяснилось, Mozilla была внедрена в золотой образ много лет назад, ею никто не пользуется, но она источник большого количества уязвимостей. Когда удалили браузер с компьютеров (он даже стоял на каких-то серверах), эти десятки тысяч уязвимостей пропали.

4. Ранжируйте уязвимости на базе данных разведки (threat intelligence). Учитывайте не только критичность уязвимости, но и наличие публичного эксплойта, malware, патча, внешнего доступа к системе с уязвимостью. Оценивайте влияние этой уязвимости на критичные бизнес-системы: может ли она привести к потере данных, отказу в обслуживании и пр.

Шаг № 7: Cогласуйте KPI

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

Шаг № 8: Автоматизируйте

Снова вернусь к сканированию. Мы в Qualys считаем, что сканирование – это самое не важное, что может быть сегодня в процессе управления уязвимостями, и что в первую очередь нужно его максимально автоматизировать, чтобы он выполнялся без участия специалиста по ИБ. Сегодня существует много инструментов, которые позволяют это сделать. Достаточно, чтобы у них был открытый API и необходимое количество коннекторов.

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

Шаг № 9: Фокусируйтесь на главном

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

Если нужна более подробная информация о том, как построить в компании процесс управления уязвимостями, обращайтесь ко мне и моим коллегам. Буду рад помочь.

Источник: habr.com