Доля атак, где злоумышленники эксплуатируют уязвимости ПО, неуклонно растет. Однако количество компаний, грамотно построивших процесс управления уязвимостями, по-прежнему остается небольшим.
Терминология. Что такое уязвимость?
Являются ли неверные конфигурации уязвимостями, а контроль за конфигурациями – частью процесса управления уязвимостями? Ответ на этот вопрос зависит от того, что именно понимается под управлением уязвимостями.
Уязвимости могут возникать на разных этапах жизненного цикла информационных систем:
На этапе проектирования возникают уязвимости проектирования, которые крайне сложно (а иногда и невозможно) устранить на следующих этапах жизненного цикла;
На этапе реализации возникают уязвимости реализации, например уязвимости в коде приложения. Их сложно выявить и устранить на последующих этапах жизненного цикла;
На этапе эксплуатации возникают уязвимости конфигурации, которые относительно просто выявить и устранить даже в ходе промышленной эксплуатации информационной системы. Допуская ошибки в конфигурации, мы создаем потенциальную возможность их эксплуатировать, поэтому это можно считать уязвимостями. Их выявление и устранение находится в области ответственности эксплуатанта программного обеспечения.
Однако вопрос, всякая, ли небезопасная настройка приводит к появлению уязвимости, является предметом споров среди экспертов. Есть, к примеру CIS benchmarks, которые содержат стандартные настройки, отсутствие которых можно считать слабостью (weakness), однако практическая их эксплуатируемость под вопросом, более того, некоторые из них (отсутствие баннера на входе в систему) вообще невозможно эксплуатировать. Однако определить это заранее достаточно сложно, и то, что изначально было определено как не являющееся уязвимостью, в комбинации с другими факторами может привести, к примеру, к уязвимости нулевого дня. Сложности добавляет неясность методики добавления или не добавления конкретных ошибок конфигурации в стандарты.
Одним из подходов к решению это проблемы может быть ориентация на практическую реализуемость той или иной уязвимости, аргументируя это тем, что устранение остальных попросту нецелесообразно с точки зрения риска и ресурсов. В пользу этого подхода говорит и то, что применение конфигурационного стандарта «в лоб» без возможности объяснить целесообразность изменения той или иной настройки часто приводит либо к неработоспособности системы (точнее, к невозможности ее практической эксплуатации), либо к снижению репутации специалиста по информационной безопасности, который не в состоянии обосновать применение тех или иных мер, и отказу от применения вообще любых мер по улучшению защищенности. Каждая уязвимость должна пройти оценку реализуемости в конкретной среде.
Какие трендовые уязвимости злоумышленники эксплуатировали в последнее время?
По данным обзора Palo Alto, компании взламывали чаще всего через:
55% - MS Exchange proxy shell
14% - Log4J
7% - SonicWall
5% - MS Exchange proxyLogon
Получается, что большая часть – уязвимости Exchange (поскольку он везде используется и «смотрит» наружу) и уязвимости в сетевом оборудовании, которое тоже «смотрит» наружу и при этом недостаточно часто патчится.
В этот список можно добавить уязвимости web-приложений. При этом эксперты отмечают, что основной уязвимостью по-прежнему остается человеческий фактор, а методом эксплуатации – социальная инженерия: до 80% инцидентов начинаются с этого.
В целом результаты очень сильно зависят от метода сбора статистики и даже географического распределения. Самыми популярными будут уязвимости, являющиеся самыми простыми с точки зрения применения атакующим и самыми доступными с точки зрения получения атакующих средств.
Стандарты безопасного конфигурирования системного и прикладного ПО
Предположим, приоритетные уязвимости конфигурации для одной системы можно определить, но что делать, если этих систем в инфраструктуре десятки, а то и сотни? А если добавить требования регуляторов? А как учесть тот факт, что стандартные «хорошие» конфигурации есть на самые распространенные системы, однако последнее время на рынке РФ начинают широко распространяться отечественные решения, которые тоже надо как-то безопасно конфигурировать?
Стандарты безопасного конфигурирования – явление не новое, они как раз и говорят о том, такое безопасность конфигураций, как она выглядит и что такое управление ею:
Проведение сканирования на уязвимости;
Проведение тесов на проникновение;
Своевременное устранение уязвимостей;
Установка обновлений безопасности;
Разработка и применение стандартов безопасной конфигурации.
Самих стандартов безопасного конфигурирования много, они достаточно разнообразны: NIST CSF, PCI DSS, ISO/IEC 27001, NIST SP 800-53, СТО БР ИББС-1.0, приказы ФСТЭК №21, 31, 17, ГОСТ Р 57580.1 – 2017, Постановление ЦБ РФ №382-П, и прочие другие. Однако опять, применение их «в лоб» приводит к чрезмерной трате ресурсов, они иногда противоречат друг другу, иногда – приводят к бесполезности защищаемой системы.
Все ли уязвимости следует устранять?
Подход к устранению вообще всех уязвимостей вряд ли стоит рассматривать как практически целесообразный, т. к. это потребует огромного количества ресурсов, может привести к неработоспособности систем и потребует слишком много времени. Практически реализуемым является подход, когда определяются наиболее критичные с точки зрения векторов проникновения уязвимости и устраняются именно они в расчете помешать потенциальному злоумышленнику, и сосредоточить силы на обнаружении и ликвидации последствий при их наступлении.
Впрочем, есть альтернативные мнения экспертов, считающих, что если к вендору ПО есть доверие, то необходимо устанавливать все доступные патчи, закрывающие все уязвимости, потому что для адекватной приоритезации по общедоступным данных попросту недостаточно информации. Приоритезация в этом случае является компромиссным вариантом, который можно принять только в том случае, когда устранение всех уязвимостей на практике невозможно.
Устранять все подряд уязвимости в серийном ПО относительно несложно, в то время как редкое и устаревшее патчить не всегда возможно в принципе, и приходится применять какие-либо компенсирующие меры. Противодействие уязвимости можно организовать разными мерами, и патчинг – только одна из них. Проблема только в том, что эти решения зачастую нетиражируемые и требуют гораздо больше ресурсов.
Приоритезация по CVSS score не даст достоверных результатов, необходимо оценивать последствия, к которым может привести эксплуатация уязвимости. Это непростой процесс, и чтобы снизить нагрузку, можно сначала приоритезировать сами системы, уделив внимание наиболее критичным, оценивая, к чему приведет эксплуатация уязвимостей на них.
Однако этот процесс возможен только на инфраструктуре среднего размера, при очень большом количестве хостов (10000+) даже просто анализ отчет от сканера уязвимостей займет слишком много времени. Выход – автоматизация процесса тестирования и установки патчей.
Взаимодействие IT и ИБ: конфликт или сотрудничество?
Главная задача – сделать все сервисы удобными и безопасными. Традиционно, за безопасность отвечает ИБ, за удобство – IT.
Позиция IT в этом процессе заключается в следующем:
Требования ИБ несут риски нарушения доступности систем
Служба ИБ выполняет работу руками IT и добавляет рабочих обязанностей
Недоверие к службе ИБ в вопросах требований по настройке систем
С позиции ИБ – разработка требований по безопасной настройке – это отдельный трудоемкий процесс, на который не всегда хватает времени и ресурсов; возможность проверки внедрения стандартов весьма ограничена; контролировать соответствие ресурсов выработанной политике сложно.
Задачей IT является интерпретация и применение требований бизнеса по доступности и удобству в инфраструктуре, задачей ИБ – интерпретация и применение требований безопасности к этой же инфраструктуре. Исходя из этого, функционального конфликта здесь нет, тема конфликта несколько искусственна.
Автоматизация процессов управления уязвимостями конфигурации
Полностью автоматизировать процесс управления конфигурациями опасно, это приводит к рискам выхода из строя значительной части инфраструктуры компании. Однако без централизованного автоматизированного внедрения изменений его скорость становится настолько низкой, что не успевает за потребностями бизнеса.
Проблемой еще является принципиальная невозможность автоматизации (скриптами, например) конфигураций на некоторых, не столь широко распространенных платформах. В добавок к этому механизмы конфигурирования у платформ разные, и плохо совместимые.
Отправной точкой управления конфигурациями является управление активами (asset management). Зачастую эти функции сочетаются в рамках одного продукта, но хорошей практикой является возможность подключения к внешним asset management-системам, которые могут обладать более полной информацией и являются, вообще говоря, сферой ответственности IT.
В некоторых случаях допустима полная автоматизация:
Когда компания обладает квалифицированными в области конфигурирования систем администраторами;
У нее относительно небольшая инфраструктура;
Есть в наличии тестовые среды.
Наиболее перспективный вариант – частичная автоматизация, когда администраторам предоставляется:
необходимый набор скриптов и другие инструменты;
в соответствие приводятся отдельные параметры или группы параметров;
в соответствие приводятся немногочисленные группы хостов;
в соответствие приводятся некритичные для бизнеса хосты.
Какими вендорами представлен рынок управления уязвимостей сейчас в РФ?
Для управления уязвимостями внутри инфраструктуры:
Red Check (АЛТЭКС-СОФТ)
Сканирование периметра:
Vulners, включая базы уязвимостей
Compliance Control:
Важно смотреть список поддерживаемых вендором систем, чтобы в дополнение к коробочному продукту не приходилось строить кастомизированные решения.
Q&A
Как рассчитать вероятность реализации уязвимости?
– Практически – никак. Нужно оценивать не вероятность, а возможные последствия от реализации угрозы через уязвимость. На практике вероятность зависит от желания злоумышленника ее проэксплуатировать, а не является функцией уязвимости.
Как рассчитать критичность и возможное влияние при принятии решения о патчинге систем вендоров, которые ушли с рынка?
– По рекомендациям НКЦКИ, либо оценить, что будет более критично – получить и установить «испорченный» патч или быть взломанным. В любом случае это субъективная оценка.
Какие шаги по применению безопасной конфигурации на основе CIS?
– Предварительно стоит разобраться, что означает каждый из параметров, как работает система, какую атаку закрывает каждая настройка. Затем можно взять стандарты от разных вендоров и сравнить их между собой, выделив основные, например, на основе анализа актуальных техник MITRE ATT&CK и недостатков конфигурации, позволяющих их применять. Это позволит выделить наиболее важные.
Резюме
В идеале патчить нужно все уязвимости. В реальности приходится идти на компромиссы, потому что как минимум всегда есть софт, который сканерами не поддерживается, но уязвимости имеет.
Ни vulnerability management, ни patch management полностью не защитят. У этих процессов есть предел эффективности, поэтому
Нужны средства обнаружения атак и готовность на уровне алгоритмов действий в той или иной ситуации.