| Слушать на Google Podcasts | Слушать на Mave | Слушать на Яндекс Музыке |
Руслан Рахметов, Security Vision
Рассмотрев в предыдущей публикации основные типы нарушителей как источников угроз, далее следует перейти к анализу того, как именно угрозы могут быть реализованы злоумышленниками.
С логической точки зрения, не может существовать идеально защищенных и безопасных информационных систем, которые при этом не находятся в изолированном пространстве, а выполняют свою бизнес-функцию. Злоумышленники используют (эксплуатируют) уязвимости в самом активе или его защите для осуществления вредоносных действий, т.е. реализации угрозы.
Стандарт ISO/IEC 27000:2018 определяет уязвимость как слабое место актива или средства контроля и управления, которое может быть использовано злоумышленниками.
В соответствии с ГОСТ Р 56546-2015, уязвимость - это недостаток программно-технического средства или информационной системы в целом, который может быть использован для реализации угроз безопасности информации.
Можно также говорить об уязвимости как о дефекте безопасности, т.е. недостатке создания/конфигурирования/использования программно-технического средства или IT-системы, который может потенциально негативно повлиять на обеспечение информационной безопасности обслуживаемого актива.
Стандарт ГОСТ Р 56546-2015 выделяет следующие возможные типы уязвимостей:
-
уязвимость кода - уязвимость, появившаяся в процессе разработки программного обеспечения;
-
уязвимость конфигурации - уязвимость, появившаяся в процессе настройки программного обеспечения и технических средств;
-
уязвимость архитектуры - уязвимость, появившаяся в процессе проектирования информационной системы;
-
организационная уязвимость - уязвимость, связанная с недостатками организационных мер, такими как несоблюдение сотрудниками правил эксплуатации системы или требований нормативных документов;
-
многофакторная уязвимость - уязвимость, появившаяся в результате комбинации нескольких уязвимостей перечисленных типов.
Данный стандарт указывает и на потенциальные места возникновения уязвимостей:
-
уязвимости в общесистемном ПО - в операционных системах, СУБД, файловых системах, драйверах;
-
уязвимости в прикладном ПО - во всех тех программах, которые может установить и запускать пользователь;
-
уязвимости в специальном ПО - в программах, разработанных для решения специфических задач данной системой;
-
уязвимости в технических средствах - в прошивках, BIOS, микроконтроллерах;
-
уязвимости в портативных технических средствах - в мобильных устройствах и приложениях для них, а также в аппаратном обеспечении данных устройств;
-
уязвимости в сетевом оборудовании - в маршрутизаторах, коммутаторах, модемах и т.д.;
-
уязвимости в средствах защиты информации.
Уязвимость характеризуется степенью своей опасности, которая стандартом ГОСТ Р 56546-2015 определяется как сравнительная величина, характеризующая подверженность информационной системы уязвимости и ее влияние на нарушение свойств безопасности информации (конфиденциальность, целостность, доступность).
Общепринятым способом расчета опасности уязвимости в количественном выражении является использование метрики CVSS (Common Vulnerability Scoring System) американского Национального института стандартов и технологий (NIST, National Institute of Standards and Technology). Данная метрика позволяет описать основные особенности уязвимости и количественно (с помощью формулы) оценить её опасность в зависимости от сложности эксплуатации, влияния на свойства безопасности актива, наличия готового эксплойта и его доступности для злоумышленника, возможности устранить уязвимость, уровня достоверности сообщения о наличии уязвимости, а также в привязке к конкретной среде эксплуатации уязвимой системы.
Указанные характеристики уязвимости описываются в трех группах метрик:
-
базовые метрики, не изменяющиеся со временем и не зависящие от среды функционирования системы, которые подразделяются на метрики эксплуатации (учитываются способ получения доступа, сложность получения доступа, уровень аутентификации в уязвимой системе, степень вовлечения пользователя системы, влияние на другие компоненты той же системы) и на метрики влияния на свойства информационной безопасности актива (уровень влияния на конфиденциальность, целостность, доступность);
-
временные метрики, изменяющиеся со временем по факту появления дополнительной информации об уязвимости, которые учитывают возможность эксплуатации (например, наличие готового эксплойта), уровень устранения уязвимости (например, наличие официального исправления от разработчика), а также степень достоверности отчета об уязвимости (например, подтверждение от вендора);
-
контекстные метрики, учитывающие конкретную среду функционирования уязвимой системы, которые позволяют модифицировать рассчитанные базовые метрики в привязке к конкретной организации или системе, а также указать требования к свойствам информационной безопасности конкретного актива (его конфиденциальность, целостность, доступность).
Таким образом, уязвимость получает оценку от 0 до 10, где 10 - максимальная величина опасности. В настоящее время используются две версии метрики CVSS (v2 и v3), при этом версия v3 позволяет более точно описать уязвимость, однако ФСТЭК России опирается на значения, рассчитанные в соответствии с CVSSv2.
Идея централизованно регистрировать и классифицировать уязвимости нашла свою реализацию в нескольких официальных реестрах уязвимостей, таких как MITRE CVE (Common Vulnerabilities and Exposures), БДУ ФСТЭК России (Банк данных угроз безопасности информации), NIST NVD (National Vulnerability Database), CERT/CC VND (Vulnerability Notes Database).
Реестр CVE организации MITRE ведется с 1999 года, и за это время в нем были сохранены данные о более чем 115 тысячах уязвимостей. Информацию в данный реестр вносят CNA (CVE Numbering Authorities) - зарегистрированные организации (такие как государственные CERT'ы), компании-производители ПО, а также независимые исследователи безопасности, которые имеют полномочия присваивать обнаруженным уязвимостям идентификатор вида CVE-YYYY-NNNN, где YYYY - год обнаружения уязвимости, а NNNN - её порядковый номер. В настоящий момент в списке CNA присутствуют 98 организаций и лиц, среди которых две российских компании - Яндекс и Лаборатория Касперского.
Российский реестр БДУ находится в ведении ФСТЭК России и ГНИИИ ПТЗИ. С 2015 года он пополнился информацией о более чем 21 тысяче уязвимостей, имеющих идентификаторы вида BDU:ГГГГ-ННННН, где ГГГГ - год обнаружения, а ННННН - порядковый номер уязвимости. Данный реестр характерен тем, что содержит уникальную информацию об уязвимостях в ПО российской разработки, которая не представлена в других реестрах, а также позволяет разработчикам отечественных средств защиты информации получать актуальные данные об уязвимостях из надежного государственного источника. Любой нашедший уязвимость гражданин или организация могут отправить информацию о ней через веб-форму или по электронной почте непосредственно во ФСТЭК России.
Кроме описанных официальных, существует и большое количество альтернативных реестров уязвимостей и эксплойтов, которые ведутся как разработчиками ПО (например, Microsoft, Cisco, Oracle, IBM, Red Hat, Ubuntu, VMware и прочие), так и отдельными организациями и энтузиастами:
Причиной возникновения уязвимости может быть ошибка, допущенная при разработке или настройке ПО. Американский Национальный институт стандартов и технологий классифицирует 124 типа ошибок в своем перечне CWE (Common Weakness Enumeration), среди которых присутствуют такие, как ошибки аутентификации или её отсутствие, ошибки работы с буфером памяти, возможность внедрения стороннего кода или команд, недостатки конфигурирования, некорректное применение криптографических алгоритмов, отсутствие проверки вводимых данных, ошибки вычисления, возникновение «состояния гонки», возможность подделки запросов, некорректное расходование выделенных ресурсов, использование заложенных в код программы статичных учетных данных и прочие. Разработчикам и администраторам будет полезно также ознакомиться с диаграммой взаимосвязей различных типов ошибок, которая схематично отображает возможные причины и следствия типичных недостатков разработки и настройки систем.
Более того, для каждой из приведенных ошибок на сайте организации MITRE приведено её подробное описание с примерами уязвимого кода, указаниями по обнаружению и устранению подобных ошибок с привязкой к стадиями разработки ПО, а также со ссылками на зарегистрированные уязвимости CVE (Common Vulnerabilities and Exposures), которые были вызваны данной ошибкой, и на шаблоны атак CAPEC (Common Attack Pattern Enumeration and Classification), связывающие ошибку и возможные атаки. Например, ошибка с идентификатором CWE-79 называется «Некорректная фильтрация вводимых данных при отображении веб-страницы» и говорит об ошибках, приводящих к уязвимостям XSS (Cross-site Scripting, межсайтинговый скриптинг). Данная ошибка привела к появлению XSS-уязвимости с идентификатором CVE-2017-9764, найденной в PHP-модуле MetInfo версии 5.3.17, и используется при реализации XSS-атак с идентификатором CAPEC-63. Проект MITRE CAPEC описывает на настоящий момент 519 шаблонов атак и тесно связан с проектом описания методик атак MITRE ATT&CK, о котором речь пойдет далее.
ФСТЭК России создала реестр угроз безопасности информации в качестве отечественной альтернативы классификатору MITRE CAPEC. Данный реестр на текущий день содержит 213 типов угроз, при этом каждый тип угрозы имеет свой уникальный идентификатор (вида УБИ.***), описание угрозы, источника, объекта воздействия и последствий от её реализации. Доступен поиск по названию, источнику или последствиям реализации угрозы. При этом в реестре содержатся не только чисто технические угрозы, но и организационные, такие как, например, УБИ.040 (Угроза конфликта юрисдикций различных стран), УБИ.056 (Угроза некачественного переноса инфраструктуры в облако) или УБИ.134 (Угроза потери доверия к поставщику облачных услуг).
Кроме двух вышеуказанных реестров существуют и иные, классифицирующие угрозы безопасности, например OWASP (Open Web Application Security Project, посвящен атакам на веб-приложения и известен своим перечнем наиболее опасных категорий атак OWASP TOP-10), Microsoft STRIDE (позволяет использовать инструмент моделирования угроз Microsoft Threat Modeling Tool), WASC (Web Application Security Consortium).
Формализация процесса идентификации и классификации уязвимостей и атак вкупе с соответствующими стандартами (например, SCAP - Security Content Automation Protocol и OVAL - Open Vulnerability and Assessment Language) привели к возможности построения зрелых и всеобъемлющих процессов управления уязвимостями (vulnerability management).
В рамках выстраивания процесса управления уязвимостями организации проходят, как правило, этапы инвентаризации, классификации и приоритизации активов, анализа текущей защищенности, поиска уязвимостей и их обработки (устранение/минимизация/изоляция/принятие) в соответствии с их критичностью, последующей проверки и оценки эффективности пройденных шагов. Следует обеспечить средства документальной поддержки данного процесса: разработать процедуры и регламенты анализа защищенности, тестирования и установки обновлений, непрерывного контроля соответствия, а также документально закрепить согласованные целевые показатели защищенности систем компании. Не стоит забывать и о стандартах информационной безопасности для аппаратного и программного обеспечения, регламентирующих наборы устанавливаемых и поддерживаемых программно-технических средств. С технической точки зрения следует обеспечить непрерывное обнаружение неизвестных/неуправляемых хостов и сервисов в сети компании, систем без установленных обновлений и средств защиты, не соответствующих утвержденным политикам безопасности в части разрешенного ПО и версионности ОС. Логичным продолжением выстроенного процесса управления уязвимостями будет его включение в карту ситуационной осведомленности (situational awareness) для руководителей компании.
Однако, несмотря на заманчивую доступность формализации процесса обработки уязвимостей с использованием метрик, таких как CVSS, не стоит забывать о том, что цепочка последовательной эксплуатации нескольких казалось бы некритичных уязвимостей может привести к реализации разрушительной атаки. Именно поэтому к процессу управления уязвимостями не стоит подходить формально, при этом ручной труд специалистов следует максимально автоматизировать. Наш продукт Security Vision Security Governance, Risk Management and Compliance оснащен модулем «Управление уязвимостями», который призван помочь Заказчикам выстроить автоматизированный процесс управления уязвимостями, включающий в себя постановку задач на устранение уязвимостей, маршрутизацию задач исполнителям, контроль качества и сроков устранения уязвимостей.
