4 июля мы проводили большой семинар по управлению уязвимостями. Сегодня мы публикуем расшифровку выступления Андрея Новикова из Qualys. Он расскажет, какие этапы нужно пройти, чтобы выстроить рабочий процесс управления уязвимостями. Спойлер: до сканирования мы доберемся только к середине пути.
В самом начале нужно понять, на какой ступени находится ваша организация с точки зрения зрелости процессов управления уязвимостями. Только после этого вы сможете понять, куда вам двигаться и какие шаги необходимо предпринять. Прежде чем пускаться в сканирования и прочие мероприятия, организациям нужно провести внутреннюю работу и понять, как устроены ваши текущие процессы с точки зрения ИТ и с точки зрения информационной безопасности.
Попробуйте ответить на базовые вопросы:
Вы не можете защитить то, о чем вы не знаете. Если у вас нет полной картины того, из чего состоит ваша ИТ-инфраструктура, вы не сможете ее защищать. Современная инфраструктура сложная и постоянно меняется количественно и качественно.
Теперь ИТ-инфраструктура базируется не только на стеке классических технологий (рабочие станции, серверы, виртуальные машины), но и на относительно новых – контейнерах, микросервисах. Служба информационной безопасности всячески убегает от последних, поскольку ей очень сложно работать с ними с помощью существующих наборов инструментов, которые состоят преимущественно из сканеров. Проблема в том, что любой сканер не может покрыть всю инфраструктуру. Чтобы сканер достучался до любого узла в инфраструктуре, нужно, чтобы совпало сразу несколько факторов. Актив должен быть внутри периметра организации на момент сканирования. У сканера должны быть сетевые доступы к активам, их учетным записям, чтобы собрать полную информацию.
По нашей статистике, когда речь идет о средних или крупных организациях, примерно 15–20% инфраструктуры не захватывается сканером по тем или иным причинам: актив выехал за пределы периметра или вообще никогда не появляется в офисе. Например, ноутбук сотрудника, который работает удаленно, но при этом имеет доступ в корпоративную сеть, или же актив находится во внешних облачных сервисах типа Amazon. И сканер, скорее всего, ничего не будет знать про эти активы, так как они вне зоны его видимости.
Чтобы покрыть всю инфраструктуру, нужно использовать не только сканеры, а целый набор сенсоров, включая технологии пассивного прослушивания трафика для обнаружения новых устройств в вашей инфраструктуре, агентский метод сбора данных, чтобы получать информацию, – позволяет получать данные онлайн, без необходимости сканирования, без выделения учетных данных.
Не все активы одинаково полезны. Определить, какие активы важны, а какие нет, – ваша задача. Ни один инструмент, тот же сканер, не сделает это за вас. В идеале ИБ, ИТ и бизнес вместе анализируют инфраструктуру, чтобы выделить бизнес-критичные системы. Для них они определяют допустимые метрики по доступности, целостности, конфиденциальности, RTO/RPO и пр.
Это поможет определить приоритеты в процессе управления уязвимостями. Когда ваши специалисты будут получать данные об уязвимостях, это будет не простыня с тысячами уязвимостей по всей инфраструктуре, а гранулированная информация с учетом критичности систем.
И вот только на четвертом шаге мы приходим к оценке инфраструктуры с точки зрения уязвимостей. Рекомендуем вам на этом этапе уделять внимание не только уязвимостям в ПО, но и ошибкам в конфигурациях, которые тоже могут быть уязвимостью. Здесь мы рекомендуем агентский метод сбора информации. Сканеры можно и нужно использовать для оценки безопасности периметра. Если вы используете ресурсы облачных провайдеров, то оттуда тоже нужно собирать информацию по активам и конфигурациям. Отдельное внимание уделите анализу уязвимостей в инфраструктурах с использованием Docker-контейнеров.
Это один из важных элементов внутри процесса управления уязвимостями.
Первый момент: никто не будет работать с многостраничными отчетами с беспорядочным списком уязвимостей и описанием по их устранению. Нужно в первую очередь общаться с коллегами и выяснять, что должно быть в отчете и как им удобнее получать данные. Например, какому-то администратору не нужно подробное описание уязвимости и нужна лишь информация о патче и ссылка на него. Другому специалисту важны только уязвимости, найденные в сетевой инфраструктуре.
Второй момент: под отчетностью я понимаю не только бумажные отчеты. Это устаревший формат получения информации и статичная история. Человек получает отчет и никак не может повлиять на то, как в этом отчете будут представлены данные. Чтобы получить отчет в нужном виде, ИТ-специалист должен связаться со специалистом по ИБ и попросить его перестроить отчет. Время идет, появляются новые уязвимости. Вместо того, чтобы перебрасывать отчеты из отдела в отдел, специалисты обоих направлений должны иметь возможность наблюдать за данными онлайн и видеть одну и ту же картину. Поэтому в своей платформе мы используем динамические отчеты в виде настраиваемых дашбордов.
Тут можно делать следующее:
1. Создание репозитория с золотыми образами систем. Работайте с золотыми образами, проверяйте их на уязвимости и корректность конфигурации на постоянной основе. Сделать это можно с помощью агентов, которые автоматически будут сообщать о появлении нового актива и предоставлять информацию о его уязвимостях.
2. Сфокусируйте внимание на тех активах, которые критичны для бизнеса. Нет ни одной организации в мире, которая может устранить уязвимости за один прием. Процесс устранения уязвимостей долгий и даже муторный.
3. Сужение поверхности атак. Вычищайте свою инфраструктуру от ненужного ПО, сервисов, закрывайте ненужные порты. У нас был недавно случай с одной компанией, у которой на 40 тысячах устройств было найдено около 100 тысяч уязвимостей, связанных со старой версией браузера Mozilla. Как потом выяснилось, Mozilla была внедрена в золотой образ много лет назад, ею никто не пользуется, но она источник большого количества уязвимостей. Когда удалили браузер с компьютеров (он даже стоял на каких-то серверах), эти десятки тысяч уязвимостей пропали.
4. Ранжируйте уязвимости на базе данных разведки (threat intelligence). Учитывайте не только критичность уязвимости, но и наличие публичного эксплойта, malware, патча, внешнего доступа к системе с уязвимостью. Оценивайте влияние этой уязвимости на критичные бизнес-системы: может ли она привести к потере данных, отказу в обслуживании и пр.
Не сканируйте для того, чтобы сканировать. Если с найденными уязвимостями ничего не происходит, то это сканирование превращается в бесполезную операцию. Чтобы работа с уязвимостями не превратилась в формальность, продумайте, как вы будете оценивать ее результаты. ИБ и ИТ должны договориться, каким образом будет построена работа по устранению уязвимостей, как часто будут проводиться сканирования, установка патчей и т.д.
На слайде вы видите примеры возможных KPI. Есть и расширенный список, который мы рекомендуем своим клиентам. Если будет интересно, обращайтесь, я этой информацией с вами поделюсь.
Снова вернусь к сканированию. Мы в Qualys считаем, что сканирование – это самое не важное, что может быть сегодня в процессе управления уязвимостями, и что в первую очередь нужно его максимально автоматизировать, чтобы он выполнялся без участия специалиста по ИБ. Сегодня существует много инструментов, которые позволяют это сделать. Достаточно, чтобы у них был открытый API и необходимое количество коннекторов.
Пример, который я люблю приводить, – это DevOps. Если вы будете внедрять туда сканер уязвимости, то можно просто забыть про DevOps. Со старыми технологиями, которым является классический сканер, вас просто не пустят в эти процессы. Разработчики не будут ждать, пока вы просканируете и отдадите им многостраничный неудобный отчет. Разработчики ждут, что информация об уязвимостях будет попадать в виде информации о багах в их системы сборки кода. Безопасность должна быть бесшовно встроена в эти процессы, и она должна быть всего лишь функцией, которая автоматически вызывается системой, используемой вашими разработчиками.
Фокусируйтесь на том, что приносит реальную пользу вашей компании. Сканирования могут быть автоматическими, отчеты могут рассылаться тоже автоматически.
Фокусируйтесь на улучшении процессов, чтобы они были более гибкими и удобными для всех участников. Фокусируйтесь на том, чтобы безопасность была внедрена во все контракты с вашими контрагентами, которые, например, разрабатывают для вас веб-приложения.
Если нужна более подробная информация о том, как построить в компании процесс управления уязвимостями, обращайтесь ко мне и моим коллегам. Буду рад помочь.
Шаг № 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: Фокусируйтесь на главном
Фокусируйтесь на том, что приносит реальную пользу вашей компании. Сканирования могут быть автоматическими, отчеты могут рассылаться тоже автоматически.
Фокусируйтесь на улучшении процессов, чтобы они были более гибкими и удобными для всех участников. Фокусируйтесь на том, чтобы безопасность была внедрена во все контракты с вашими контрагентами, которые, например, разрабатывают для вас веб-приложения.
Если нужна более подробная информация о том, как построить в компании процесс управления уязвимостями, обращайтесь ко мне и моим коллегам. Буду рад помочь.
