В 2015 году ФСТЭК России совместно с заинтересованными органами власти и организациями сформировала банк данных угроз безопасности информации (БДУ).
Банк данных угроз находится в свободном доступе на сайте http://www.bdu.fstec.ru/.
БДУ включает в себя базу данных уязвимостей программного обеспечения и описание угроз, характерных, в первую очередь, для государственных информационных систем и автоматизированных систем управления производственными и технологическими процессами критически важных объектов.
Целью создания данного банка является повышение информированности заинтересованных лиц о существующих угрозах безопасности информации в информационных (автоматизированных) системах. Банк данных предназначен для:
По состоянию на сентябрь 2017 года банк данных угроз содержит 205 угроз и 17369 уязвимостей.
Любой желающий может сообщить об обнаруженной уязвимости с помощью формы обратной связи.
В качестве фильтров для поиска угроз можно выбрать:
| a. внутренний нарушитель с низким потенциалом |
| b. внутренний нарушитель со средним потенциалом |
| c. внутренний нарушитель с высоким потенциалом |
| d. внешний нарушитель с низким потенциалом |
| e. внешний нарушитель со средним потенциалом |
| f. внешний нарушитель с высоким потенциалом |
| a. нарушение конфиденциальности |
| b. нарушение целостности |
| c. нарушение доступности |
Также доступен контекстный поиск по названию угрозы.
Описание угрозы выглядит следующим образом - рис 8.1.
(рис 8.1) Пример описания угрозы из БДУ
В паспорте каждой угрозы есть ее наименование, уникальный идентификатор, описание, источники угрозы (минимальные возможности внешнего или внутреннего нарушителя, необходимые для реализации угрозы), объекты воздействия и последствия реализации угрозы (рис 8.2).
(рис 8.2) Схема описания угрозы в БДУ
Последствия реализации угрозы категорированы в соответствии с тремя основными свойствами информации с точки зрения информационной безопасности-конфиденциальностью, доступностью и целостностью, рассмотренными в лекции №1.
Для поиска уязвимостей программного обеспечения доступны следующие фильтры:
В качестве дополнительных параметров поиска:
Описание уязвимости выглядит как показано на рис 8.3.
(рис 8.3) Пример описания уязвимости в БДУ
Стоит отметить особую ценность БДУ с точки зрения описания уязвимостей в отечественном программном обеспечении и средствах защиты информации. ФСТЭК взаимодействует с ведущими вендорами в области информационной безопасности, учебными заведениями и другими заинтересованными организациями (Digital Security, Институт системного программирования Российской академии наук, АО "НПО РусБИТех" и прочими) для пополнения банка угроз информационной безопасности.
Проанализировать вручную 17369 уязвимостей и решить, актуальны ли они для конкретного случая, видится весьма сложной задачей. В настоящее время при построении модели угроз безопасности информации и для анализа защищенности можно использовать готовые программные продукты.
Например, сканер безопасности RedCheck 1.4 от компании "Алтекс-Софт" использует собственную базу данных уязвимостей OVALdb. Уязвимости, хранящиеся в OVALdb, были сопоставлены с банком уязвимостей ФСТЭК, что обеспечило обнаружение сканером уязвимостей, описанных в БДУ.
Сетевые сканеры "Ревизор сети" версия 3.0 от ЦБИ и Сканер-ВС от Информационного центра также умеют искать уязвимости, описанные в БДУ.
Приведем некоторую статистику использования БДУ. По состоянию на 15.05.2017 г. статистика посещений:
В разделе "Инфографика" БДУ можно ознакомиться с некоторой статистикой по распределению угроз.
Количество уязвимостей ПО различных производителей (рис 8.4):
(рис 8.4) Количество уязвимостей в ПО различных производителей
По состоянию на октябрь 2017 года среди TOP-15 вендоров на первых трех местах по количеству уязвимостей в программном обеспечении оказались:
Распределение уязвимостей по типу программного обеспечения показывает, что на первом месте по количеству уязвимостей находятся операционные системы (рис 8.5).
(рис 8.5) Распределение уязвимостей по типу программного обеспечения
(рис 8.6) Распределение уязвимостей по уровням опасности
БДУ может использоваться для формирования модели угроз (и последующей оценки защищенности) - рис 8.7.
(рис 8.7) Создание частной модели угроз на основе БДУ
Стоит отметить, что ФСТЭК постоянно стремится к улучшению сервиса, в том числе публикует доклады о состоянии сервиса и планах его развития. В частности, планируется создать базу данных ошибок и ошибочных ситуаций, которые могут привести к возникновению уязвимости, с учетом международного опыта. Не так давно была добавлена возможность скачивания сведений об угрозах и уязвимостях в форматах XML и XLSX.
В мире существует международные базы данных уязвимостей, которые позволяют разработчикам программного обеспечения и его пользователям обмениваться информацией с целью устранения выявленных уязвимостей и минимизации рисков их использования со стороны злоумышленников. Базы данных уязвимостей разрабатываются государственными, международными и коммерческими организациями. Наиболее известными являются:
В данной лекции будет рассмотрена база данных уязвимостей CVE.
Common Vulnerabilities and Exposures (CVE) - это список стандартных идентификаторов (IDs) для общеизвестных уязвимостей информационной безопасности. Основная задача создания CVE - объединение различных баз данных уязвимостей и унификация их описания.
Идентификаторы CVE (также известные как "CVE IDs," "CVE entries," "CVE names," "CVE numbers," и "CVEs") - это уникальные общепринятые идентификаторы для известных уязвимостей информационной безопасности.
CVE был основан в 1999 г., когда большинство средств безопасности использовали собственные базы данных уязвимостей. Часто одна и та же уязвимость описывалась по-разному, и не было технических возможностей объединить накопленные знания и практики. Результатом стала низкая интероперабельность (от. Англ. interoperability - способность к взаимодействию) между разрозненными базами данных. Помимо этого каждый вендор программного обеспечения использовал собственные метрики для подсчета количества обнаруженных уязвимостей и эксплойтов. Для решения этих проблем был создан CVE, который в настоящее время является отраслевым стандартом. Идентификаторы CVE служат единым языком для эффективного обмена данными.
Каждый ID CVE включает в себя:
Процесс создания CVE ID начинается с обнаружения потенциальной уязвимости. Затем CVE Numbering Authority (CNA) присваивает информации CVE ID и публикует в списке CVE на веб-сайте Primary CNA.
.
Primary CNA - это самый главный CNA и им является некоммерческая компания MITRE Corporation, управляющая несколькими научно-исследовательскими центрами и курирующая CVE.
Синтаксис идентификационного номера CVE ID:
Префикс CVE + год + порядковый номер
Порядковый номер - это 4 и более цифр. Синтаксис идентификатора был изменен в 2015 году. Изначально в качестве порядкового номера использовалось только 4 цифры, то есть максимальное значение 9999 уязвимостей, обнаруживаемых в год. Сейчас обычно используется 7 цифр.
Рассмотрим пример. В 2014 году в протоколе SSL 3.0 была выявлена уязвимость, названная POODLE. Она позволяет осуществить атаку "человек посередине"( Man-in-the-Middle ) на соединение, защищенное с помощью SSL 3.0. Ей был присвоен идентификационный номер CVE-2014-3566. То, как описание уязвимости выглядит в CVE, показано на рис 8.8:
(рис 8.8) Пример описание уязвимости в CVE
Стоит отметить, что ранее в CVE использовались разные статусы идентификаторов - CVE-кандидат(candidate) и CVE-запись(entry). Идентификаторы со статусом кандидата имели префикс CAN (например, "CAN-1999-0067"), а идентификаторы записи - префикс CVE (например, "CVE-1999-0067"). Пока уязвимость не была подтверждена, она имела идентификатор CVE-кандидата. Когда получала подтверждение - тип идентификатора менялся на CVE-запись. После изменения отдельных идентификаторов и смены их статуса организации, которые используют CVE, должны были обновлять у себя информацию. Так как количество обнаруживаемых уязвимостей с 1999 года экспоненциально выросло, MITRE Corporation по просьбе сообщества с 2005 года использует только префикс CVE.
The Common Vulnerability Scoring System (CVSS) - это открытый отраслевой стандарт, используемый для оценки уязвимостей. В 2005 году состоялась публикация первой версии стандарта, в разработке которой участвовали эксперты различных организаций (CERT/CC, Cisco, DHS/MITRE, eBay, IBM Internet Security Systems, Microsoft, Qualys, Symantec). Далее стандарт стал поддерживаться в рамках проекта FIRST (Forum of Incident Response and Security Teams). В 2007 году вышла вторая версия стандарта, в июне 2015 года - третья CVSSv3 - текущая версия.
Использование CVSS для оценки уязвимостей закреплено в различных стандартах, в том числе в PCI DSS.
Для оценки уязвимости CVSS использует три группы метрик (рис 8.9):
Каждой метрике присваивается значение (например, "высокое"), которое затем соотносится с числовым значением (оценкой) в соответствии с таблицей.
(рис 8.9) Группы метрик CVSS v.3.0
Вектор атаки (Attack Vector (AV)) - отражает удаленность злоумышленника для использования уязвимости. Числовое значение метрики будет тем больше, чем дальше может находиться злоумышленник, так как в этом случае количество потенциальных злоумышленников возрастает. Метрика может принимать значения: сетевой (можно использовать уязвимость удаленно), соседняя сеть (то есть сеть, которая имеет общую среду передачи с атакуемой сетью), локальный (для эксплуатации злоумышленнику требуется локальная сессия или определенные действия со стороны легитимного пользователя), физический (злоумышленнику требуется физический доступ к уязвимой подсистеме).
Сложность доступа (Access Complexity (AC)) - отражает сложность реализации атаки. Чем легче эксплуатировать уязвимость, тем выше оценка. Значение метрики - высокое, среднее, низкое. Например, уязвимость протокола SSL 3.0 имеет низкую сложность доступа, так как не зависит от конфигурации, используемого ПО и бдительности пользователя. Если для использования уязвимости злоумышленнику нужно собрать какую-то информацию, например, с помощью сниффера - метрика примет среднее значение. Если для использования уязвимости злоумышленнику нужны права администратора в атакуемой системе - метрика примет высокое значение.
Требуемые привилегии (Privileges Required (PR)) - отражает уровень привилегий, которыми должен обладать злоумышленник для использования уязвимости, то есть требуется ли аутентификация и с какими правами. Значение метрики - высокое, среднее, низкое. Чем ниже требуемые привилегии, тем выше будет оценка метрики. Например, для атаки, которая требует для злоумышленника административных прав на атакуемом компьютере, метрика примет высокое значение и низкую оценку.
Взаимодействие с пользователем (User Interaction (UI)) - отражает, может ли злоумышленник использовать уязвимость только по своему желанию или необходимы какие-то действия со стороны пользователя (скачивание программы, переход по ссылке, запуск процесса и т.п.). Метрика принимает значения "нет" и "требуется". Соответственно, если для реализации атаки не требуется участие пользователя, оценка метрики будет высокой.
Масштаб(Scope) - нововведение CVSS v3.0. Метрика показывает, могут ли отличаться уязвимый и атакуемый компоненты, то есть позволяет ли эксплуатация уязвимости нарушить конфиденциальность, целостность и доступность какого-либо другого компонента системы, кроме уязвимого.
Уязвимый компонент (vulnerable component) - тот компонент информационной системы, который содержит уязвимость и подвержен эксплуатации.
Атакуемый компонент (impacted component) - тот, конфиденциальность, целостность и доступность которого могут пострадать при успешной реализации атаки.
В большинстве случаев уязвимый и атакуемый компоненты совпадают, но есть и целые классы уязвимостей, для которых это не так[78].
Например, уязвимость на виртуальной машине, которая позволяет злоумышленнику удалять файлы на ОС хоста (возможно, даже на собственную виртуальную машину). Эта уязвимость затрагивает две области полномочий - одна определяет привилегии для виртуальной машины и ее пользователей, вторая область делает то же самое для хоста. Уязвимость виртуальной машины дает злоумышленнику возможность управлять обеими областями. Метрика принимает значения "неизменяемый" и "изменяемый". Соответственно, для рассмотренного примера она примет значение изменяемый, так как масштаб уязвимости расширяется.
Каждая из трех метрик может принимать значения "отсутствует", "среднее", "высокое" в зависимости от того, насколько сильно в случае успешного использования уязвимости пострадает конфиденциальность, доступность и целостность атакуемого объекта.
Контекстные метрики отражают характеристики уязвимости в зависимости от среды, в которой она используется. Они являются необязательными, соответственно, не влияют на базовую оценку уязвимости. Применяются только в тех случаях, когда аналитик хочет уточнить оценку уязвимости исходя из инфраструктуры и других параметров конкретной организации.
Требования к безопасности (требования к конфиденциальности/доступности/целостности) - метрики позволяют "настраивать" оценку CVSS в зависимости от важности ИТ-ресурса, который затрагивает уязвимость, с точки зрения нарушения его конфиденциальности, доступности или целостности. То есть, если ИТ-объект поддерживает бизнес-функцию, для которой доступность является наиболее важной, аналитик может присвоить большую ценность доступности по отношению к конфиденциальности и целостности. Каждое требование безопасности имеет три возможных значения: низкий, средний или высокий. Контекстные метрики требования к безопасности влияют на базовые метрики влияния (влияние на конфиденциальность/целостность/доступность). Например, значение метрики "влияние на конфиденциальность" увеличивается, если значение "требование к конфиденциальности" высокое. Соответственно, значение метрики "влияние на конфиденциальность" уменьшается, если значение метрики "требование к конфиденциальности" низкое. По сути аналитик может создавать измененные базовые метрики в зависимости от конкретного контекста. Например, конфигурация по умолчанию для уязвимого компонента может заключаться в том, чтобы запустить службу прослушивания с правами администратора. При этом в базовых метриках влияние на доступность, конфиденциальность и целостность обозначено как "высокое". Тем не менее, в среде аналитика такой же Интернет-сервис может работать со сниженными привилегиями. Тогда в этом конкретном случае модифицированные метрики влияния на конфиденциальность, доступность и целостность примут значение "низкое".
После того, как базовые метрики определены, с помощью базовой формулы вычисляется оценка угрозы - от 0 до 10 и создается вектор как показано на рис 8.10:
(рис 8.10) Формирование вектора уязвимости
Вектор - это текстовая строка, отражающая значения каждой метрики для уязвимости. Векторная строка v3.0 начинается с метки "CVSS:" и числового представления текущей версии "3.0". Метрическая информация следует в виде набора показателей, каждой метрике предшествует косая черта "/", действующая как разделитель. Каждая метрика - это метрическое имя в сокращенной форме, двоеточие ":" и связанное с ним значение показателя в сокращенной форме. Все базовые метрики обязательно включаются в вектор (рис 8.8).
Например, вектор уязвимости с базовыми метрическими значениями "Attack Vector: Network, Attack Complexity: Low, Privileges Required: High, User Interaction: None, Scope: Unchanged, Confidentiality: Low, Integrity: Low, Availability: None" и отсутствующими временными и контекстными метриками:
CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N
Вектор публикуется всегда вместе с оценкой, чтобы показать, как она была получена. При необходимости оценку можно скорректировать с помощью временных и контекстных меток, но это не обязательно. Обычно базовые и временные метрики определяются аналитиками бюллетеней уязвимостей, производителями программного обеспечения. Контекстные, так как они зависят от конкретного объекта защиты, - пользователями (людьми, имеющими представление о конкретном объекте защиты).
После создания вектора итоговая оценка уязвимости складывается из оценок каждой метрики. Соответствие значений метрик и их оценок можно посмотреть в таблице по ссылке: https://www.first.org/cvss/specification-document
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.