Основные направления развития системы защиты информации на 2023 год от ФСТЭК России. Новости из мира информационной безопасности за октябрь 2023 год. Новые угрозы в БДУ ФСТЭК.
Блеск и нищета… БДУ
Теперь крупные компании могут использовать наше ПО для построения отказоустойчивых высоконагруженных систем в чувствительных к безопасности проектах Александр Виноградов Руководитель Tarantool Tarantool — ПО для хранения и обработки данных, которое ускоряет цифровые сервисы и снижает нагрузку на ключевые системы. Сочетает в себе сервер приложений, базу данных с гибкой схемой данных и мощные средства масштабирования для построения отказоустойчивых сервисов.
Определение угроз безопасности для инфраструктуры, размещаемой на внешних хостингах Особое внимание уделяется вопросу разделения ответственности при моделировании угроз для информационных систем, размещаемых во внешних ЦОД и облачных сервисах. Определение актуальных угроз безопасности в рассматриваемой ситуации должно осуществляться владельцем информации совместно с используемым хостингом. В общем случае хостинг определяет актуальные угрозы безопасности для предоставляемой им инфраструктуры и доводит эти сведения до своего клиента — обладателя информации оператора. Например, границы моделирования угроз безопасности при аренде виртуальной инфраструктуры выглядят следующим образом: В случае, если владелец хостинга не выполняет моделирование угроз, Методика не рекомендует использование его услуг. С учетом того, что такая рекомендательная мера далеко не всегда будет соблюдаться, остается открытым вопрос о том, как быть владельцу информации, если он решится на использование услуг такого хостинга. Поддержание модели угроз в актуальном состояние Результаты моделирования угроз оформляются в виде документа по форме, представленной в приложении к Методике, и утверждается руководителем обладателя информации оператора. Стоит отметить, что предлагаемая к использованию форма документа имеет достаточно стандартную структуру, повторяющую основные разделы Методики, при этом в ней отсутствует раздел с указанием выводов или какой-либо иной информации, объясняющей, что же с этими угрозами делать дальше. Такой подход, к сожалению, создает впечатление неоконченного документа, описывающего мероприятие, вырванное из общего контекста.
Но перейдем к дальнейшим этапам жизненного цикла модели угроз. Подразумевается, что в течение всего периода эксплуатации информационной системы, модель угроз должна актуализироваться с учетом изменения требований законодательства, изменения архитектуры и условий функционирования системы, выявления новых угроз безопасности информации. С учетом того, что внесение изменений в БДУ событие относительно частое от 1 до 3 раз в год, в соответствии с представленной в базе информацией , возвращаться к вопросу актуализации модели угроз придется регулярно. Вместе с тем стоит отметить, что поддерживать в актуальном состоянии модель угроз можно и в виде электронного документа. Необходимо ли в этом случае утверждать такой документ у руководителя и если да, то каким именно образом — пока неясно. Удалась ли новая Методика? Опубликованный проект документа демонстрирует, что в вопросах обеспечения безопасности информационных систем регулятор старается идти в ногу со временем и вместе с тем учитывать пожелания владельцев таких систем. Из очевидных плюсов обновленной Методики стоит отметить: ее универсальность и, следовательно, возможность использования для различных типов информационных систем; структурированный и понятный подход к определению актуальности угроз безопасности; зависимость актуальности угроз от действительно важных факторов — наличия потенциальных негативных последствий от реализации угрозы и сценариев ее реализации. Вместе с тем, при прочтении Методики отчетливо ощущается, что это лишь проект, а не финальная версия методического документа: неоднократное упоминание БДУ в контексте функций, которая она в настоящий момент не реализует; ссылки на фактически отсутствующие для большинства типов информационных систем базовых и типовых моделей угроз; форма документа по результатам моделирования угроз, требующая доработки и иные мелкие недочеты.
И что же дальше? Новый вариант Методики значительно отличается от действующей в настоящее время. В случае утверждения этого документа а пока не видно ни одной действительно значимой причины, почему это может не произойти , перед владельцами информационных систем встанет вопрос о том, нужно ли им актуализировать имеющиеся модели угроз и если да, то как и в какой срок необходимо это осуществить.
Общие положения 1. Настоящее руководство по управлению уязвимостями в органе организации далее - Руководство разработано в соответствии с подпунктом 4 пункта 8 Положения о Федеральной службе по техническому и экспортному контролю, утверждённого Указом Президента Российской Федерации от 16 августа 2004 г. N 1085. Руководство определяет состав и содержание работ по анализу и устранению уязвимостей далее - управление уязвимостями , выявленных в программных, программно-аппаратных средствах информационных систем, информационно-телекоммуникационных сетей, автоматизированных систем управления, информационно-телекоммуникационных инфраструктурах центров обработки данных, на базе которых функционируют эти системы и сети далее - информационные системы. Настоящее Руководство подлежит применению государственными органами, организациями, в том числе субъектами критической информационной инфраструктуры Российской Федерации, являющимися операторами информационных автоматизированных систем далее - органы организации при принятии ими мер по устранению уязвимостей программных, программно-аппаратных средств информационных систем в соответствии с требованиями о защите информации, содержащейся в государственных информационных системах, требованиями по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации, а также иными нормативными правовыми актами и методическими документами ФСТЭК России. Задачами Руководства являются создание основы для разработки детальных регламентов и стандартов по управлению уязвимостями с учетом особенностей функционирования органов организаций и организация взаимодействия между структурными подразделениями органов организаций по вопросам устранения уязвимостей. Управление уязвимостями сертифицированных программных, программно-аппаратных средств защиты информации обеспечивается с учетом эксплуатационной документации на них, а также рекомендаций разработчиков. Уязвимости информационных систем.
Однако, есть оборотная сторона — низкий уровень дохода государственного служащего провоцирует его низкий профессионализм, текучку, а также высокий уровень коррупции», — говорит Бедеров. Объекты КИИ до сих пор не все прошли даже категорирование, напоминает эксперт: срок категорирования несколько раз продлевали и пока что окончательного решения по вопросу нет. В целом же указ президента предусматривает создание централизованной базы данных, с помощью которой будет легче контролировать субъекты и объекты КИИ, считает президент Ассоциации малых операторов России АМОР Дмитрий Галушко. Она даст возможность контроля и наказания нарушителей, указывает он. Статья 13.
БДУ ФСТЭК РОССИИ Telegram канал
| Множественные уязвимости systemd (CVE-2022-3821, CVE-2023-7008, CVE-2023-26604, CVE-2022-4415) | АИС «Налог-3» Информационная система ФНС России. |
| Новинка: Сканер-ВС 6 - сканирование на уязвимости никогда не было таким быстрым! | БДУ) ФСТЭК России. |
Особенности банка данных угроз ФСТЭК России
- Новый раздел на сайте БДУ - Форум по вопросам информационной безопасности
- база данных уязвимостей фстэк россии | Дзен
- Новая методика оценки УБИ - Утверждено ФСТЭК России - НПП СВК
- Наши проекты
- Сергей Борисов
- Сканеры уязвимостей — обзор мирового и российского рынков
ScanOVAL для Astra Linux 1.6 Бесплатный анализ на наличие уязвимостей Linux БДУ ФСТЭК
Данный раздел поможет в обеспечении безопасности патч-менеджмента, который является частью процесса управления уязвимостями vulnerability management. Запущенный ресурс поможет упростить процессы патч-менеджмента в любой компании, а патч-менеджмент непосредственно связан с процессом vulnerability management. Это позволит уменьшить трудозатраты специалистов и снизить число случаев, когда имеющееся в компании иностранное ПО перестает работать.
Найдет уязвимости Выявит сетевые уязвимости с помощью, безопасных инвентаризационных и баннерных проверок, фаззинга. Подберет пароли Проверяет протоколы электронной почты и удаленного управления, служб передачи файлов и баз данных. Также проверит веб-приложения собственной разработки. Проинформирует об угрозах По каждой обнаруженной уязвимости XSpider предоставит подробное описание, инструкцию по исправлению, ссылки на общедоступные источники и выставит базовую и временную оценку по вектору CVSS v2 и v3. Сформирует отчеты XSpider выдаст в структурированном виде данные о результатах сканирования. Можно фильтровать данные, сравнивать результаты различных сканирований и получать общие оценки состояния системы. Автоматизирует контроль защищенности XSpider позволяет выстроить процесс выявления уязвимостей: настроить автоматический запуск задач на сканирование в нужное время.
Только не подумайте, что я против модели угроз как таковой! Может быть, повторюсь, но считаю, что сама идея — использовать модель угроз при выборе мер защиты — абсолютно верная. Однако, не отрицая важности самого процесса оценки угроз безопасности информации при выборе адекватных мер защиты, необходимо отметить, что многолетняя практика моделирования угроз для каждого конкретного объекта показывает свою НЕэффективность. Ситуация получается очень похожей на басню Крылова правда, немного в другой коннотации : «Вертит Очками так и сяк: То к темю их прижмёт, то их на хвост нанижет, То их понюхает, то их полижет; Очки не действуют никак». И происходит это по банальной причине: нет связи между угрозами и мерами. Вот давайте посмотрим на раздел банка угроз, связанного с уязвимостями. Там есть не только привязка уязвимости к конкретному ПО и его версии, что позволяет однозначно определить необходимость принятия мер, но и такие замечательные рубрики, как «Возможные меры по устранению уязвимости» и «Способ устранения». А это уже прямое руководство к действию. Поэтому этот раздел оказывается весьма полезным в практической деятельности ибэшников. К сожалению, этого нельзя сказать про раздел угроз безопасности информации. Правда, некоторые специалисты пытаются составить таблицы соответствия угроз и мер защиты [2], но, честно говоря, это всё-таки самоделки. Здесь нужен системный подход,чёткая проработка и соответствующие разделы в банке угроз. Вот тогда-то модель угроз станет действенным инструментом при выборе мер защиты и не потребуется заставлять бизнес разрабатывать формальную модель угроз «документ ради документа» , он сам почувствует её необходимость, так как это будет экономить деньги. А ещё лучше, если угрозы будут увязаны не только с мерами защиты, но и с необходимыми функциями безопасности, которые реализуются средствами защиты читай классами средств защиты. Тогда модель угроз станет бесценной. Не всё, что в банке угроз названо угрозами, является таковым. Просто кое-что, отнесённое к классу угроз, не вписывается в классическое определение угроз. Частенько идёт подмена понятий. Кстати, об определении. Как сказал классик, «прежде чем объединяться и для того, чтобы объединиться, мы должны сначала решительно и определённо размежеваться». В нашем случае объединяться — это составить банк угроз, а размежеваться — чётко определить те сущности, которые мы собираемся объединять. Попробуем «размежеваться». И главное здесь, конечно, — понятие угрозы. Глупо полагать, что обеспечением безопасности информации занимаются только для того, чтобы поддержать соответствующие службы и производителей средств защиты. Эгоизм правит миром, и поэтому любая деятельность по обеспечению безопасности информации направлена только на то, чтобы не допустить ущерба обладателю от нарушений полезных свойств информации. Поэтому примем за аксиому, что угроза — это некие негативные действия, угрожающие интересам субъекта обладателя информации. А отсюда следует, что угроза может быть только тогда, когда есть субъект, которому может быть причинён ущерб. Поэтому «угрозы информации» быть не может в силу того, что информация является объектом отношений, а не субъектом.
Сочетает в себе сервер приложений, базу данных с гибкой схемой данных и мощные средства масштабирования для построения отказоустойчивых сервисов.
Сканеры уязвимостей — обзор мирового и российского рынков
Лицам исследователям , планирующим направить информацию об уязвимостях в банк данных угроз безопасности информации через раздел "Обратная связь", необходимо учитывать, что данные фамилия и имя исследователя, выявившего уязвимость, могут быть опубликованы в банке данных угроз. Это необходимо для анализа и организации устранения уязвимостей в конкретном программном обеспечении, в ходе которого возможно потребуются взаимодействие и совместные действия со специалистами Службы и или иными организациями, включая разработчиков производителей программного обеспечения. В течение 2015 года ФСТЭК России планирует осуществлять мониторинг и анализ функционирования банка данных угроз безопасности, а также отработку процедур взаимодействия заинтересованных органов государственной власти и организаций по выявлению, анализу и устранению уязвимостей. По результатам указанной работы будут определены направления совершенствования и расширения функциональности банка данных угроз безопасности информации. Начальник 2 управления.
Во втором случае — аттестует компанию, которая хранит персональные данные например, биометрические. ФСТЭК также разрабатывает и согласовывает стандарты и правила в области информационной безопасности, проводит обучение и сертификацию специалистов в этой сфере.
С 2020 года и до сих пор в БДУ есть всего 222 угрозы. Шесть из них добавлены в конце 2020 года и касаются машинного обучения и искусственного интеллекта. БДУ хранит не только угрозы, но и уязвимости. Эта база растет достаточно быстро — на сегодняшний день в ней более 45 000 уязвимостей. Это не так много по сравнению с крупными международными базами уязвимостями такими как CVE, например , которые существуют более 20 лет и в несколько раз больше чем БДУ, появившегося 8 лет назад. С другой стороны в отечественном банке меньше уязвимостей устаревшего и не используемого программного обеспечения. Сайт bdu. Для этого предусмотрены формы обратной связи. Кстати достаточно много угроз и уязвимостей из банка были обнаруженными именно частными лицами. Также на сайте можно найти раздел с терминологией по информационной безопасности из различных ГОСТов, законов и иных нормативных документов.
Кстати достаточно много угроз и уязвимостей из банка были обнаруженными именно частными лицами. Также на сайте можно найти раздел с терминологией по информационной безопасности из различных ГОСТов, законов и иных нормативных документов. Это значительно облегчает работу: не нужно выискивать нужный термин и его определение, достаточно просто воспользоваться этой веб-страницей. Итак, каждая угроза в БДУ содержит описание и перечень источников. Последнее — это злоумышленники внешние или внутренние , техногенные или природные стихийные источники не рассматриваются. В старом разделе БДУ нарушители делятся на три категории: с низким, средним и высоким потенциалом. Эта классификация отличается от используемой для моделирования угроз в соответствии с методикой ФСТЭК России от 5 февраля 2021 года. В ней сказано, что нарушители внешние и внутренние бывают четырех категорий: с базовыми возможностями, базовыми повышенными, средними и высокими. Как мы видим, есть некое совпадение между тем, как представлена информация об источниках угроз в БДУ, и тем, как мы должны определять их по новой методике. Также в БДУ указывается объект воздействия, на который направлена угроза, и перечисляются последствия этого воздействия.
БДУ ФСТЭК создал раздел с результатами тестирования обновлений: комментарии Руслана Рахметова
| Купить Сканер-ВС, цена лицензий, сертификат ФСТЭК | Поддержка БДУ ФСТЭК России и других сторонних баз уязвимостей. |
| 11–13 февраля 2025 | ФАУ «ГНИИИ ПТЗИ ФСТЭК России». |
| ФСТЭК РФ БДУ - Банк данных угроз Федеральной службы технико-экспортного контроля - CNews | быстрое определение уязвимостей: выявление уязвимостей по версиям установленного ПО, база уязвимостей, включающая данные из БДУ ФСТЭК России, NIST NVD, а также баз уязвимостей ОС Debian, Red Hat, Arch, Ubuntu, Windows, Astra Linux и др. |
11–13 февраля 2025
Вторая группа цифр "ХХХХХ" является порядковым номером уязвимости в банке данных угроз безопасности информации. Идентификатор, присваиваемый угрозе безопасности информации, состоит из буквенной аббревиатуры "УБИ" и группы цифр и имеет вид: УБИ. Группа цифр "ХХХ" представляет собой порядковый номер угрозы безопасности информации в банке данных угроз безопасности информации от 001 до 999. Уязвимость подлежит включению в банк данных угроз безопасности информации, если по результатам ее анализа получена и проверена информация, как минимум, по описанию уязвимости, наименованию и версии программного обеспечения, в котором возможна уязвимость, уровню опасности уязвимости. Угроза безопасности информации подлежит включению в банк данных угроз безопасности информации, если по результатам ее анализа и проверки получена вся необходимая информация. Включение информации в банк данных угроз безопасности информации осуществляется по мере появления получения сведений о новых уязвимостях и угрозах безопасности информации и их рассмотрения.
В связи с утверждением настоящего методического документа не применяются для оценки угроз безопасности информации Методика определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных ФСТЭК России, 2008 г.
Проведение аудита парольной политики и подбор паролей. Инвентаризация сети для получения детальной информации об аппаратных и программных средствах. Контроль целостности с выбором алгоритма контрольного суммирования. Контроль изменений в системе. Управление обновлениями для общесистемного ПО. Рисунок 3. Схема работы сканера защищённости RedCheck Ещё одной ключевой особенностью сканера RedCheck является его работа с унифицированным SCAP-контентом обновления, уязвимости, конфигурации, политики безопасности , получаемым из собственного репозитория OVALdb. Это — один из крупнейших международных банков контента по безопасности, позволяющий формировать оценку защищённости информационных систем. Сканер представлен в нескольких редакциях, включая вариант «Enterprise». Модульная компоновка позволяет масштабировать систему и использовать её в территориально распределённых сетях и ЦОД. Техническая поддержка оказывается до 23. Больше сведений о данном сканере можно найти на сайте RedCheck. Рисунок 4. Выявление уязвимостей производится следующим образом: состояние системных параметров сканируемого программного обеспечения системного и прикладного сравнивается с базой уязвимостей, представленной в виде описаний, которые разработаны в соответствии со спецификацией OVAL. Сканер позволяет выявлять одиночные и множественные бреши. XSpider Сканер защищённости XSpider компании Positive Technologies впервые появился на рынке ещё в 2002 году — причём в это же время была основана сама компания. XSpider предназначен для компаний с количеством узлов до 10 000. Задачи по проверке парольной политики также решаются XSpider, при этом будет задействован брутфорс с использованием базы паролей, которые наиболее распространены или применяются по умолчанию. Рисунок 5. Более подробно об этом сканере можно узнать в посвящённом ему разделе сайта производителя. Также данный сканер осуществляет поиск брешей, содержащихся в международных базах cve. Кроме того, «Ревизор сети» может импортировать в состав своих отчётов результаты, полученные при использовании сетевого сканера Nmap в части определения типов операционных систем и выявления сетевых сервисов на открытых TCP- и UDP-портах. Основными особенностями «Ревизора сети» являются: проверки уязвимостей ОС семейств Windows и Linux, СУБД, средств виртуализации, общесистемного и прикладного ПО с использованием регулярно обновляемых баз данных; проверка наличия неустановленных обновлений ОС семейства Windows; проверки учётных записей для узлов сети, подбор паролей; определение открытых TCP- и UDP-портов на узлах проверяемой сети с верификацией сервисов, поиск уязвимостей; определение NetBIOS- и DNS-имён проверяемых узлов сети; проверки наличия и доступности общих сетевых ресурсов на узлах сети; сбор дополнительной информации об ОС семейства Windows. Рисунок 6. Окно для просмотра задач сканирования в «Ревизоре сети 3. Сканер уязвимости «Ревизор сети» версии 3. С более подробной информацией о сканере можно ознакомиться на странице разработчика. Также данный сканер может проводить тесты на проникновение и осуществлять анализ конфигурации различных узлов. Рисунок 7. Главное меню системы «Сканер-ВС» Помимо этого можно отметить наличие следующих возможностей: Инвентаризация ресурсов сети. Сканирование на наличие уязвимостей как с учётной записью администратора, так и без неё. Сетевой и локальный анализ стойкости паролей. Поиск подходящих эксплойтов на основе собранной информации об узле. Перехват и анализ сетевого трафика, а также реализация атак типа MitM Man in the Middle, «внедрённый посредник». Анализ беспроводных сетей. Создание отчёта с техническими рекомендациями по устранению обнаруженных уязвимостей. Также «Сканер-ВС» предлагает проведение контроля целостности — подсчёт контрольных сумм заданных папок и файлов по 13 алгоритмам. Больше информации о данном сканере размещено на сайте данного продукта. Обзор зарубежных сканеров уязвимостей F-Secure Radar Этот сканер уязвимостей является продуктом компании F-Secure, которая активно работает на рынке антивирусов. Radar — облачное решение, для полноценной работы которого необходима установка агентов. На данный момент поддерживается совместимость с ОС семейств Windows и Linux. F-Secure Radar представляет собой не только сканер уязвимостей, но и платформу для управления уязвимостями и активами. Он обладает возможностями по обнаружению ИТ-активов, их инвентаризации и идентификации. Рисунок 8. Окно центра управления в F-Secure Radar Помимо этого Radar предлагает следующие возможности: Централизованное управление уязвимостями, оповещениями по безопасности и расследованием инцидентов. Обнаружение фактов незаконного использования товарного знака и попыток мошенничества под фирменным наименованием от третьих лиц. Предотвращение атак с помощью выявления неправильной настройки программного обеспечения в службах, операционных системах и сетевых устройствах.
Среди «плюсов», как минимум, можно выделить следующие: отказ от неудобных в использовании и далеко не всегда корректных параметров исходной защищенности информационной системы и вероятности реализации угрозы, используемых в методике 2008 года; зависимость актуальности угроз безопасности от действительно значимых для информационной безопасности параметров, таких как потенциальный ущерб от реализации угрозы и сценарии ее реализации; большой акцент на мероприятиях, позволяющих корректно и точно определить, от чего необходимо защищаться — оценка рисков, проведение тестирования на проникновение, использование источников о тактиках и техниках реализации угроз; предусмотрены различные варианты выполнения мероприятий при определении актуальности угроз, например, определение потенциальных последствий от реализации угрозы тремя разными способами; предоставление исходных данных и примеров выполнения для каждого из мероприятий, выполняемых для определения актуальности угроз. Таким образом, мероприятия по определению актуальности угроз безопасности являются целостным и структурированным процессом, способным учитывать особенности функционирования различных типов информационных систем. Вместе с тем стоит отметить тот факт, что модернизация подхода к определению актуальности угроз сделал его значительно более трудоемким. От исполнителя или, вероятнее, группы исполнителей требуются глубокие знания как об инфраструктуре системы, так и различных областях ИБ, начиная от законодательных норм, заканчивая пониманием и, желательно, наличием практических навыков по реализации различных типов атак. Определение угроз безопасности для инфраструктуры, размещаемой на внешних хостингах Особое внимание уделяется вопросу разделения ответственности при моделировании угроз для информационных систем, размещаемых во внешних ЦОД и облачных сервисах. Определение актуальных угроз безопасности в рассматриваемой ситуации должно осуществляться владельцем информации совместно с используемым хостингом. В общем случае хостинг определяет актуальные угрозы безопасности для предоставляемой им инфраструктуры и доводит эти сведения до своего клиента — обладателя информации оператора. Например, границы моделирования угроз безопасности при аренде виртуальной инфраструктуры выглядят следующим образом: В случае, если владелец хостинга не выполняет моделирование угроз, Методика не рекомендует использование его услуг. С учетом того, что такая рекомендательная мера далеко не всегда будет соблюдаться, остается открытым вопрос о том, как быть владельцу информации, если он решится на использование услуг такого хостинга. Поддержание модели угроз в актуальном состояние Результаты моделирования угроз оформляются в виде документа по форме, представленной в приложении к Методике, и утверждается руководителем обладателя информации оператора. Стоит отметить, что предлагаемая к использованию форма документа имеет достаточно стандартную структуру, повторяющую основные разделы Методики, при этом в ней отсутствует раздел с указанием выводов или какой-либо иной информации, объясняющей, что же с этими угрозами делать дальше. Такой подход, к сожалению, создает впечатление неоконченного документа, описывающего мероприятие, вырванное из общего контекста. Но перейдем к дальнейшим этапам жизненного цикла модели угроз. Подразумевается, что в течение всего периода эксплуатации информационной системы, модель угроз должна актуализироваться с учетом изменения требований законодательства, изменения архитектуры и условий функционирования системы, выявления новых угроз безопасности информации. С учетом того, что внесение изменений в БДУ событие относительно частое от 1 до 3 раз в год, в соответствии с представленной в базе информацией , возвращаться к вопросу актуализации модели угроз придется регулярно. Вместе с тем стоит отметить, что поддерживать в актуальном состоянии модель угроз можно и в виде электронного документа. Необходимо ли в этом случае утверждать такой документ у руководителя и если да, то каким именно образом — пока неясно. Удалась ли новая Методика? Опубликованный проект документа демонстрирует, что в вопросах обеспечения безопасности информационных систем регулятор старается идти в ногу со временем и вместе с тем учитывать пожелания владельцев таких систем. Из очевидных плюсов обновленной Методики стоит отметить: ее универсальность и, следовательно, возможность использования для различных типов информационных систем; структурированный и понятный подход к определению актуальности угроз безопасности; зависимость актуальности угроз от действительно важных факторов — наличия потенциальных негативных последствий от реализации угрозы и сценариев ее реализации.
Сетевая Безопасность
- Федеральная служба по техническому и экспортному контролю
- БДУ ФСТЭК РОССИИ Telegram канал из рубрики #Наука и технологии
- ФСТЭК РФ БДУ - Банк данных угроз Федеральной службы технико-экспортного контроля - CNews
- Сергей Борисов - exclusive content on Boosty
- Купить Сканер-ВС, цена лицензий, сертификат ФСТЭК
- Новости Форума и анонсы деловой программы
ScanOVAL для Astra Linux 1.6 Бесплатный анализ на наличие уязвимостей Linux БДУ ФСТЭК
Формирование отчета с техническими рекомендациями по устранению обнаруженных брешей в защите. В комплексе предустановлены словари, содержащие самые распространенные пароли имена, числовые, клавиатурные последовательности и т. Подбор эксплойтов — поиск подходящих эксплойтов на основе собранной информации об узле. Перехват и анализ сетевого трафика — перехват и анализ трафика, фильтрация содержимого передаваемых данных, а также реализация атак типа MITM Man In The Middle, «Человек посередине».
В такой ситуации обладателям информации операторам приходится импровизировать, самостоятельно «дорабатывая» документ для собственных нужд. Такой подход, во-первых, не является абсолютно легальным в своих приказах ФСТЭК настаивает на использование разработанных ими методических документов для определения угроз безопасности , а во-вторых, представляет весьма нетривиальную задачу, особенно при отсутствии соответствующего опыта у исполнителя. В связи с этим, новая Методика должна стать если и не панацеей, то инструментом, значительно упрощающим процесс моделирования угроз информационной безопасности.
Ключевые особенности новой методики Область применения Методики Первой и одной из наиболее важных отличительных черт новой Методики является область ее применения, которая теперь не ограничивается лишь ИСПДн. Документ должен использоваться для определения угроз безопасности информации при ее обработке с использованием любых объектов, требования по защите к которым утверждены ФСТЭК. Какой-либо порядок разработки и согласования «дочерних» методик не предусмотрен, единственное требование — они не должны противоречить положениям Методики. Такой подход выглядит вполне логичным, если бы не одно «но». Дело в том, что разнообразие «базовых и типовых моделей угроз» на сегодняшний день оставляет желать лучшего — в свободном доступе опубликован лишь один документ, попадающий под это описание, да и тот представляет собой выписку и нацелен на все те же ИСПДн. Означает ли это, что в ближайшее время после утверждения Методики стоит ожидать пополнение в рядах базовых и типовых моделей угроз?
Вопрос остается открытым. Порядок моделирования угроз безопасности Обновленный порядок включает в себя пять этапов, выполняемых в определенной последовательности. Общая схема процесса, представленная в Методике, выглядит следующим образом: За определение актуальности угрозы безопасности информации отвечают этапы с первого по четвертый. В соответствии с Методикой, угроза безопасности будет являться актуальной при наличии хотя бы одного сценария ее реализации и если ее реализация приведет к каким-либо негативным последствиям для обладателя информации оператора или государства. Цель пятого этапа — определить опасность каждой из актуальных угроз. По сути, данная характеристика носит исключительно информационный характер и не оказывает прямого влияния ни на итоговый документ, формируемый по результатам моделирования, ни на возможные варианты нейтрализации угрозы.
Можно предположить, что данный параметр должен использоваться для определения очередности закрытия угрозы, однако малое число возможных значений показателя — «низкий», «средний», «высокий» — не позволяют сделать это с достаточной степенью детализации. Более того, любая из дошедших до данного шага угроз должна быть так или иначе закрыта, поэтому забыть про «неопасную» угрозу попросту не получится. Таким образом, истинная цель данного параметра остается не раскрытой в полной мере. Стоит отметить, что работы по моделированию угроз безопасности должны проводиться либо обладателем информации оператором самостоятельно, либо с привлечением лицензиатов ФСТЭК. Такой подход, в соответствии с нормативными документами регулятора, применяется и в настоящее время.
Любой желающий может сообщить об обнаруженной уязвимости с помощью формы обратной связи. В качестве фильтров для поиска угроз можно выбрать: источник угрозы - тип нарушителя и его минимально необходимый функционал a.
Как правило, для связи источника угрозы и существа самой угрозы. И приведенное вами описание яркий тому пример. Если под "семантикой" понимается "смысловое значение понятий и определений", то зачем их противопоставлять друг другу? Разве через понятия и определения не раскрывается их смысловое значение? В этом и есть их суть. Когда нет понятий и определений, то откуда взяться их смысловому значению и говорить о какой-то их "строгости"? Если ту же УБИ. Это к вопросу толкований и толкователей, ага... Под "семантикой" следует понимать смысловую нагрузку сообщения в целом, потому что конкретное слово вне контекста зачастую может быть воспринято некорректно как, собственно, и происходит у любителей докопаться до терминологии... Что же до моего вИдения, так, блин, все, что пишу на форуме, находится под знаком "imho". Или меня внезапно причислили к рупорам регулятора? Спасибо, конечно, но после "Догмы" образ Метатрона вообще не импонирует... С одной стороны, "Угроза"! Короче, поглядим, что там будет в новой редакции Методики...
Новый раздел на сайте БДУ - Форум по вопросам информационной безопасности
- Множественные уязвимости systemd (CVE-2022-3821, CVE-2023-7008, CVE-2023-26604, CVE-2022-4415)
- Банк угроз ФСТЭК: использовать нельзя игнорировать
- Банк данных угроз безопасности информации
- Особенности банка данных угроз ФСТЭК России
Блеск и нищета… БДУ
Расширение полномочий ФСТЭК россии. «формирует перечень организаций, которые аккредитованы ФСТЭК России или имеют лицензии ФСТЭК России, осуществляют деятельность по обеспечению информационной безопасности. еженедельно обновляемая база уязвимостей, совместимая с банком данных угроз безопасности информации (БДУ) ФСТЭК России, содержит более 45 000 проверок. Сертификат соответствия ФСТЭК РФ № 3509 на Enterprise Security Suite. Поддержка БДУ ФСТЭК России и других сторонних баз уязвимостей.
UDV DATAPK Industrial Kit
В чисто прикладном смысле БДУ ФСТЭК содержит огромное количество различных возможных угроз. реестр аккредитованных ФСТЭК России органов по сертификации и испытательных. Поддержка БДУ ФСТЭК России и других сторонних баз уязвимостей.
Сергей Борисов
О банке данных угроз безопасности информации ФСТЭК России регулярно пишут разные авторы. быстрое определение уязвимостей: выявление уязвимостей по версиям установленного ПО, база уязвимостей, включающая данные из БДУ ФСТЭК России, NIST NVD, а также баз уязвимостей ОС Debian, Red Hat, Arch, Ubuntu, Windows, Astra Linux и др. Сертификат соответствия ФСТЭК РФ № 3509 на Enterprise Security Suite. Идентификатор БДУ ФСТЭК России. Базовый вектор уязвимости CVSS 2.0. Продлен сертификат соответствия ФСТЭК России №3509 на Enterprise Security Suite.