Руслан Рахметов, Security Vision
Достаточно часто на профильных ИБ-ресурсах появляются новости об очередной обнаруженной уязвимости, а СМИ подхватывают сообщения об очередной новой киберугрозе. У тех, кто так или иначе связан с отраслями ИТ и ИБ, на слуху известные уязвимости, некоторым из которых даже дали запоминающиеся названия, чтобы подчеркнуть их опасность и важность: Heartbleed (CVE-2014-0160), Shellshock (CVE-2014-6271), EternalBlue (CVE-2017-0144), PrintNightmare (CVE-2021-34527), Log4Shell (CVE-2021-44228), Downfall (CVE-2022-40982) и прочие. В этой статье мы разберемся, что такое уязвимости, почему некоторым из них дают собственные названия, что означают и как присваиваются CVE-идентификаторы, рассмотрим наиболее популярные уязвимости веб-приложений, а также поговорим про выстраивание в компании грамотного процесса управления уязвимостями (vulnerability management).
Итак, для начала следует разобраться с основами и терминологией управления уязвимостями. Современные операционные системы и программы базируются на миллионах строк исходного кода: например, актуальное ядро Linux содержит почти 30 миллионов строк кода, в Windows 11 - около 50 миллионов строк кода (оценка предположительная по причине закрытости операционной системы Windows), в современных играх для ПК - в среднем несколько миллионов строк кода. Разумеется, при таком объеме разработки ПО не могут не возникать ошибки программирования - еще в 2012 году было подсчитано, что на 1000 строк исходного кода Open Source-проектов приходится в среднем 1 ошибка программирования. Таким образом, в крупных приложениях и ОС неизбежно возникают ошибки, некоторые из которых используются злоумышленниками для кибератак.
Однако, уязвимость - это не только ошибка, допущенная при разработке, это еще и недостаток средства защиты, конфигурации (настройки) информационной системы или даже организационных процессов в компании. В общем случае, уязвимость - это недостаток создания, конфигурирования, применения, защиты информационного актива, который может негативно повлиять на безопасность обрабатываемой информации. Если обратиться к нормативной документации, то, например, в стандарте ISO/IEC 27000:2018 уязвимость определяется как слабое место актива или средства контроля и управления, которое может быть проэксплуатировано (использовано) злоумышленниками. В отечественном стандарте ГОСТ Р 56546-2015 указано, что уязвимость - это недостаток программно-технического средства или информационной системы в целом, который может быть использован для реализации угроз безопасности информации.
В этом же российском стандарте приведены различные типы возможных уязвимостей:
· уязвимость кода - уязвимость, появившаяся в процессе разработки программного обеспечения;
· уязвимость конфигурации - уязвимость, появившаяся в процессе настройки программного обеспечения и технических средств;
· уязвимость архитектуры - уязвимость, появившаяся в процессе проектирования информационной системы;
· организационная уязвимость - уязвимость, связанная с недостатками организационных мер, такими как несоблюдение сотрудниками правил эксплуатации системы или требований нормативных документов;
· многофакторная уязвимость - уязвимость, появившаяся в результате комбинации нескольких уязвимостей перечисленных типов.
Каждая уязвимость характеризуется степенью опасности - сравнительной величиной, определяющей подверженность информационной системы этой уязвимости и её влияние на нарушение конфиденциальности, целостности, доступности информации в системе. Для того, чтобы учесть уязвимость, которую обнаружили разработчики ПО или исследователи безопасности, ей присваивают идентификатор с префиксом CVE (зарубежная классификация Common Vulnerabilities and Exposures организации MITRE, содержит более 220 тысяч уязвимостей и постоянно пополняется) или БДУ (банк данных угроз ФСТЭК России, содержит более 53 тысяч уязвимостей и постоянно пополняется). В результате подтвержденная уязвимость получает уникальный идентификатор CVE-YYYY-NNNNN (где YYYY - год обнаружения уязвимости, а NNNNN - её порядковый номер) или BDU:ГГГГ-ННННН (где ГГГГ - год обнаружения, а ННННН - порядковый номер уязвимости).
В рамках анализа уязвимости, помимо присвоения ей идентификатора, производится анализ её характеристик для определения опасности эксплуатации с помощью метрики CVSS (Common Vulnerability Scoring System). В настоящий момент актуальной версией является CVSS версии 4: в данной методике учитываются сложность эксплуатации, предварительные требования к системе для успешной эксплуатации уязвимости и к привилегиям, необходимым для этого атакующим, наличие готового эксплойта (вид вредоносного ПО, которое использует определенную уязвимость для последующего запуска кода или программ под контролем атакующих), свидетельства эксплуатации уязвимостей в реальных атаках (англ. "in the wild", буквально «в живой природе»), влияние уязвимости на свойства конфиденциальности, целостности, доступности информации. В результате такого расчета уязвимость получает оценку от 0 до 10, где 10 - максимальная величина опасности для конкретной уязвимости. Если какая-то уязвимость активно применяется в масштабных атаках с тяжелыми последствиями или прогнозируется такой сценарий, то исследователи, обнаружившие подобную критичную уязвимость, присваивают ей запоминающееся, звучное имя (например, Shellshock или PrintNightmare) для привлечения внимания ИБ-сообщества к данной проблеме.
Кроме этого, встречаются и такие термины, как Zero-Day (0-Day) и N-Day уязвимости:
· Zero-Day - это уязвимость, о которой еще не знают разработчики и ИБ-исследователи и для которой не выпущены исправления (обновления, патчи безопасности), но которая уже применяется хакерами в реальных атаках;
· N-Day - это уязвимость, для которой производителем ПО уже было выпущено исправление, но компании, использующие уязвимые версии ПО, пока что не успели установить это обновление (например, для установки обновления требуется перезагрузить сервер, который выполняет критичные для бизнеса задачи).
Как мы уже выяснили, уязвимость - это ошибка в коде программы, недостаток защитных мер или небезопасная настройка программы. Однако, некоторые типы уязвимостей в силу своей природы более опасны - прежде всего, это уязвимости веб-приложений. Подобное легко объяснить: для эксплуатации веб-уязвимостей атакующим не нужно преодолевать защитные периметровые системы, достаточно лишь атаковать веб-ресурс, который доступен всем из сети интернет. По причине такой доступности веб-ресурсы подвержены повышенному риску эксплуатации найденных хакерами уязвимостей, успешная эксплуатация которых может привести к утечке данных с веб-сайта (например, базы данных пользователей с логинами, паролями и персональной информацией), несанкционированному изменению внешнего вида сайта (так называемый дефейс), размещению вредоносного или мошеннического контента на сайте без ведома владельца, а также к компрометации информационных ресурсов, к которым имеет доступ веб-сервер (например, СУБД или иные смежные системы, а также внутрикорпоративные ресурсы). По причине высокой опасности веб-уязвимостей, для мониторинга и управления уязвимостями веб-приложений был создан проект OWASP (Open Worldwide Application Security Project), который с 2003 года регулярно выпускает списки из 10 наиболее распространенных веб-уязвимостей.
Последняя версия данного списка OWASP Top 10 вышла в 2021 году и содержит такие уязвимости, как:
· Сбой механизмов контроля доступа (англ. Broken Access Control);
· Ошибки в криптографии (англ. Cryptographic Failures);
· Инъекции (англ. Injection), включая XSS, SQL-инъекции, внедрение команд ОС, внедрение выражений XPath и XQuery и т.д.;
· Небезопасный дизайн (англ. Insecure Design);
· Недостатки конфигурации (англ. Security Misconfiguration);
· Уязвимые и устаревшие компоненты (англ. Vulnerable and Outdated Components);
· Ошибки в обеспечении идентификации и аутентификации (англ. Identification and Authentication Failures);
· Ошибки в обеспечении целостности ПО и данных (англ. Software and Data Integrity Failures);
· Ошибки в обеспечении логирования и мониторинга безопасности (англ. Security Logging and Monitoring Failures);
· Подделка запросов на стороне сервера (англ. Server-Side Request Forgery).
Кроме указанного выше перечня из 10 наиболее распространенных уязвимостей веб-приложений, проект OWASP выпускает также список из 10 наиболее популярных ошибок при разработке API-взаимодействия приложений. Этот список называется OWASP Top 10 API Security Risks, последняя версия вышла в 2023 году.
Далее перейдем к описанию процесса управления уязвимостями (англ. Vulnerability Management, сокращенно VM) - одному из базовых процессов ИБ. При выстраивании программы Vulnerability Management важно соблюдать основные правила процессного подхода и максимизировать использование средств автоматизации для сокращения временного окна возможностей атакующих по эксплуатации уязвимостей, для которых уже выпущены патчи или известны обходные пути (так называемые Workarounds), предполагающие либо отключение уязвимого компонента, либо его ручную перенастройку до выхода официального патча в целях недопущения эксплуатации уязвимости. При реализации процессного подхода важно обеспечить непрерывность цикла сканирования на наличие уязвимостей, анализа результатов, сопоставления критичности уязвимостей и критичности актива, на котором они обнаружены, принятие решения по снижению риска эксплуатации уязвимости (установка патча, отключение или ограничение сетевого доступа к уязвимому компоненту, применение компенсирующих мер, таких как виртуальный патчинг или особая настройка СЗИ, или же согласованное и задокументированное принятие риска в случае невозможности выполнения иных мер). После принятия решения следует автоматически формировать задачу на устранение уязвимости соответствующему подразделению (как правило, это ИТ-департамент в компании), устанавливать SLA выполнения задачи в зависимости от критичности уязвимости и свойств актива, а далее обязательно проверять результат, выполняя повторное сканирование актива.
Для формирования целостного и четкого процесса управления уязвимостями необходимо разработать и утвердить соответствующий внутренний нормативный документ (например, регламент управления уязвимостями). При его разработке можно использовать методический документ ФСТЭК России от 17 мая 2023 года «Руководство по организации процесса управления уязвимостями в органе (организации)», в котором даны подробные пояснения по реализации следующих основных этапов процесса управления уязвимостями:
· Мониторинг уязвимостей и оценка их применимости;
· Оценка уязвимостей;
· Определение методов и приоритетов устранения уязвимостей;
· Устранение уязвимостей;
· Контроль устранения уязвимостей.
Кроме указанного документа, можно использовать методический документ ФСТЭК России от 28 октября 2022 года «Методика оценки уровня критичности уязвимостей программных и программно-аппаратных средств», в котором приведена методика оценки уровня критичности и расчета временных SLA-нормативов по устранению уязвимостей в зависимости от их характеристик и свойств информационной системы, на которой они обнаружены. Следует также обеспечить интеграцию результатов работы сканеров уязвимостей с данными систем управления активами для получения обогащенной, контекстуализированной информации о состоянии защищенности инфраструктуры и для принятия взвешенных решений о том или ином способе обработки конкретной уязвимости.
При выстраивании процесса Vulnerability Management можно руководствоваться и зарубежными публикациями - например, документом NIST SP 800-40 Rev. 4 "Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology" («Руководство по планированию корпоративного управления обновлениями безопасности: Профилактическое обслуживание для ИТ»). В данной публикации описывается жизненный цикл управления уязвимостями ПО и даются практические рекомендации по разработке корпоративного плана управления уязвимостями - мы подробно рассматривали данный документ ранее. Еще одним полезным справочным ресурсом может послужить перечень уязвимостей, активно использующихся хакерами на практике: данный список ведет американская правительственная организация "Cybersecurity and Infrastructure Security Agency" (CISA), и его можно использовать для приоритизации устранения обнаруженных уязвимостей.
