Как стать автором
Обновить
63.56
ГК ICL
Цифровые технологии для бизнеса

Управляем уязвимостями в ИТ правильно

Время на прочтение6 мин
Количество просмотров5.6K

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

Сгенерировано с помощью ИИ
Сгенерировано с помощью ИИ

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

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

В таких случаях реакция службы информационной безопасности компаний должна быть незамедлительной. Поэтому наличие процесса управления уязвимостями является важным элементом в обеспечении ИБ. Кроме того, такой процесс необходим и с точки зрения выполнения рекомендаций по обеспечению информационной безопасности в компании (CIS TOP 18 Security Controls) и соблюдению требований регуляторов. Осуществление процесса управления уязвимостями обязательно для ГИС, объектов КИИ, а также ИС, в которых осуществляются финансовые операции и обрабатываются персональные данные.

Компоненты процесса управления уязвимостями

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

  1. Инвентаризация активов. Здесь мы обеспечиваем «видимость» всех сканируемых устройств: установить сетевые правила для обеспечения "доступности" систем в разных сетях (VLAN / LAN), настраиваем уведомления в адрес оператора средств защиты информации в адрес оператора средства защиты информации об обнаружении ранее не зарегистрированного устройства и интегрируемся с системой учета ИТ-средств.

  2. Выявление уязвимостей (White Box/ Black Box). Убеждаемся в наличии необходимых прав, так как сканирование должно осуществляться с правами администратора системы внутренних IP-адресов с доступом во все участки VLAN/LAN.

  3. Выработка рекомендаций. Это критически важный этап: здесь нужно подготовить ИТ-подразделению подробный отчет, отражающий наиболее уязвимые объекты инфраструктуры. Также нужно необходимо приоритезировать выявленные уязвимости и ИТ-активы, где эти уязвимости были выявлены, «обогатить» SIEM/IRP-системы информацией об уязвимых хостах и исключить ложноположительные (FP) срабатывания сканера, чтобы не решать проблемы там, где их нет.  

  4. Устранение уязвимостей. Согласовать время установки обновлений системы и убедиться в наличии процесса экстренного обновления систем (Emergency Patching), который необходимо проводить при выявлении уязвимостей 1 дня (1-day) которые активно используются в атаках хакерскими группами.

  5. Контроль устранения уязвимостей. Наладить совместную работу с ИТ-подразделениями по устранению уязвимостей и осуществлению последующего контроля закрытия уязвимостей путем внедрения компенсационных мер.

Выбор сканера уязвимости

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

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

  • Какие системы в организации должны непрерывно сканироваться
    Windows / Unix, СУБД, сетевое оборудование, веб-серверы, системы виртуализации, Docker / Kubernetes или ERP-системы.

  • Присутствуют ли требования со стороны регуляторов, накладывающие ограничения при выборе технического средств
    Необходимо ли наличие сертификата ФСТЭК и других документов.

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

Ключевые метрики

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

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

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

Динамика устранения уязвимостей
Динамика устранения уязвимостей
Динамика устранения уязвимостей
Впервые выявленные
Устраненные
Устраненные

Очевидно, что уровень риска для инфраструктуры можно оценивать по-разному – количеству уязвимостей и риску, который они представляют, к количеству элементов инфраструктуры. Можно группировать компоненты инфраструктуры по степени риска, который представляет их компрометация: например, выделять DMZ, АСУТП, домен контроллеры, файловые сервера, на которых работают критичные для компании приложения.

Исходя из вышеуказанных данных, пришли к выводу, что уровень риска для инфраструктуры равен 6,47.

Уровень риска для инфраструктуры
Уровень риска для инфраструктуры

Как защитить систему, не имея обновлений

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

В такой ситуации нужно учитывать рекомендации НКЦКИ по установке обновлений, а также применять технические и организационные меры.

Технические

Организационные

Ограничение USB портов

Определение порядка работы пользователей на ИТ-системах, для которых отсутствуют обновления

Отключение неиспользуемых в работе серверных ролей, сервисов, приложений

Определение списка инструментов, используемых в работе ИТ-администраторами

SRP / Selinux

Определение терминальных серверов, точек удаленного подключения

Настройка резервного копирования

Контроль подключения к сетевым устройства, изменений конфигураций

Windows Defender Firewall / IPtables

Использования критериев для принятия решений по обновлению критичного ПО, не относящегося к Open-source (НКЦКИ)

Настройка контроля доступа (мандатный, дискретный, ролевой)

Исключение средств удаленного конфигурирования (Административные общие папки, WMI, WinRM, PowerShell)

Исключение удаленного доступа с локальных УЗ

Детектирование возможной эксплуатации уязвимости

Защита хранения паролей в открытом виде

Ограничения на сетевом уровне (ACL)

Ограничения в использовании RDP / SSH

В частности, при анализе критичных уязвимостей и постановки вопроса об установки обновлений мы учитываем следующие аспекты:

  • разработчик ПО – резидент РФ,

  • уязвимость на периметре,

  • наличие POC в общем доступе,

  • уровень критичности выявленной уязвимости,

  • возможное влияние на бизнес,

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

Синтез ИТ- и ИБ-подразделений

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

Почему так важно найти компромисс:

  • Без устранения выявленных уязвимостей, процесс управления уязвимостями становится бессмысленным.

  • Установка критичных обновлений, согласование времени простоя, применение технических компенсационных мер лежит на плечах ИТ-подразделений.

  • Подразделение ИБ должно облегчить задачу ИТ-подразделениям, передавая уже переработанные отчеты от сканеров уязвимостей, в которых будет минимизировано количество ложноположительных срабатываний.

  • На встречах с руководством будут демонстрироваться положительные результаты совместной работы и совместные пути проработки возникающих сложностей.

Немного выводов

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

Теги:
Хабы:
Всего голосов 5: ↑3 и ↓2+2
Комментарии2

Публикации

Информация

Сайт
icl.ru
Дата регистрации
Дата основания
Численность
1 001–5 000 человек
Местоположение
Россия