Оценка уязвимостей информационной инфраструктуры (VA)

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

Оценка уязвимостей: мониторинг и система управления

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

Управления уязвимостями и, как следствие, их оценки – требуют не только понимание в сфере ИБ, но и знание нормативно-правовых актов, таких как приказы ФСТЭК, ГОСТ 57580 и проч.

Оценка проводится как в рамках постоянного мониторинга уязвимостей, так и в рамках однократного аудита (в том числе пентеста).

Чем оценка уязвимостей отличается от сканирования и пентеста

Сканирование уязвимостей и их оценка – это соседние этапы в процессе управления уязвимостями. Также они сопровождают друг друга и в рамках пентеста.

В обоих случаях для выявленной уязвимости определяется ее значимость исходя из потенциала реализации и тяжести возможных последствий.

Как проходит оценка уязвимостей

Инвентаризация активов (составление списка систем)

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

Автоматическое сканирование

Затем в рамках заданной области осуществляется сканирование (VS), по результатам которого выявляются конкретные потенциальные уязвимости на конкретных хостах сети.

Ручная проверка и валидация результатов

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

Анализ рисков и классификация

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

Отчёт и рекомендации по устранению

При проведении разовых работ, в особенности подрядной организацией, требуется не просто присвоение уязвимости уровня критичности, но и обоснование этого уровня.

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

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

• Обновление ПО
• Перенастройка ПО
• Применение наложенных средств защиты
• Удаление ПО

Объекты оценки уязвимостей

При оценке уязвимостей исходными данными являются идентифицированные уязвимости из баз данных, таких как БДУ ФСТЭК РФ (более структурированная и направленная на отечественное ПО, но менее полная) и CVE NIST US (самая объемная, но хуже структурированная).

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

Примером могут служить:

• Сети и серверы
• Рабочие станции и мобильные устройства
• Веб-приложения и API
• Базы данных и инфраструктурные сервисы
• Сетевое оборудование

Для сканирования уязвимостей на объектах различных типов, как правило, требуются разные сканеры. А вот оценку лучше вести применяя единый подход.

Результат оценки безопасности и формат отчётности

Поскольку для устранения уязвимостей требуются значительные ресурсы (и не всегда только материальные), зачастую ставится задача формирования отчетности для руководства. Цель такого отчета – обосновать выделение ресурсов.

Отчет не должен быть перегружен технической информацией (в общем и целом нет даже необходимости указывать конкретные CVE или БДУ). Он должен содержать уязвимые системы, критичность уязвимостей (обычно берется по максимальной), количество уязвимостей и риски, которые они могут вызывать.

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

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

Ну и, разумеется, как было сказано выше – оценивать уязвимость обязательно необходимо в связке с ценностью ресурса, на котором она обнаружена.

Методики и стандарты оценки уязвимостей

Самым распространенным способом оценки критичности уязвимости в отрыве от ценности актива, на котором она обнаружена, является Common Vulnerability Scoring System (CVSS).

Актуальной на сегодняшний день является четвертая версия (2023 год), но далеко не все уязвимости имеют оценку по ней, поэтому регулярно применяется также и CVSS 3 (2015).

Как часто нужно проводить оценку безопасности?

Оценку уязвимостей, как и их обнаружение и устранение, необходимо проводить постоянно. Выявляются новые уязвимости в старом ПО, устанавливаются новые системы, меняются средства защиты – все это требует не отдельных «разовых» работ, а постоянного процесса.

О периодичности можно говорить в части привлечения сторонней организации для пентеста – в этом случае желательно проводить работы не реже одного раза в год.

Безопасна ли оценка уязвимостей для бизнеса?

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

Однако в 99% случаев можно обойтись и без эксплуатации, а при крайней необходимости – провести ее в нерабочее время. По этой причине процесс оценки наиболее безопасен для бизнес-процессов.

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