Объем данных для хранения и обработки растет с устрашающей скоростью – к 2025 году он может достичь 163 зеттабайт (1 зеттабайт = 1 трлн гигабайт). Вместе с ним увеличивается и число уязвимостей, которые становится все сложнее найти и уж тем более управлять ими. Добавьте к этому нехватку финансирования и квалифицированных кадров, и уже понятно, что одним сканером уязвимостей и пачкой pdf-отчетов тут не обойтись. В этом посте мы описываем основные проблемы в процессах Vulnerability Management (VM) и ищем способы их решения.

Поиск уязвимостей с ML

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

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

Также следует подружить технологию обработки больших данных с отчетами со сканера. По нашей практике, наиболее удобный формат для работы с отчетами – Excel. В этой статье мы объясняем, почему стоит отказаться от формата PDF. Но у Excel есть ограничение – 1 млн строк на листе. Даже для не самых больших инфраструктур (менее 3 тыс. узлов) такое количество уязвимостей, детектируемых современными сканерами, не редкость. В рамках нашего VM-сервиса мы эффективно обрабатываем большое количество уязвимостей за счет сегментации исследуемой сети, проводимой вместе с заказчиком, и приоритезации результатов сканирования на основе собственной экспертизы.

О противоречиях риск-моделей

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

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

В основу риск-моделей в большинстве случаев входит оценка критичности уязвимостей, и тут также нужен единый знаменатель – оценка сканера, CVSS v2 или v3, или другая, более продвинутая метрика.  Например, в своей отчетности мы применяем наиболее подходящую доступную метрику (CVSS v2 или v3).

Важна и инвентаризация (Asset Management) – без нее не получится произвести классификацию активов (BIA, Business Impact Analysis), которая при устранении уязвимостей позволяет обрабатывать важные для бизнеса сегменты в приоритетном порядке.

Устраняем хаос в действиях по исправлению уязвимостей

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

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

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

И да, опять не забываем регулярно обучать сотрудников и помогать им обмениваться опытом – это улучшит качество исправления уязвимостей.

Неточности в отчетах по исправлению уязвимостей

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

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

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

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

Регламент VM как итог решенных проблем

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

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

А в основе процесса будет лежать инвентаризация активов (Asset Management), которая является фундаментом и для многих других смежных IT-процессов. К сожалению, это не только основа, но и зачастую серьезная проблема и камень преткновения – на плохом фундаменте эффективных и работающих процессов не построить.

 Автор:

Юрий Брежнев, аналитик группы эксплуатации сервисных платформ ГК "Солар"