Федеральная служба по техническому и экспортному контролю (ФСТЭК России) совместно с заинтересованными органами власти и организациями сформировала банк данных угроз безопасности информации, доступ к которому можно получить на web-сайте http. Последние новости. «формирует перечень организаций, которые аккредитованы ФСТЭК России или имеют лицензии ФСТЭК России, осуществляют деятельность по обеспечению информационной безопасности. Документы» отражена информация об угрозах, способах их реализации, техниках и тактиках злоумышленников, выгруженная из банка данных угроз безопасности информации (БДУ) ФСТЭК. Автоматическая актуализация при изменении законодательства, реестров сертифицированных СЗИ ФСБ России и ФСТЭК России, появлении новых угроз и уязвимостей в БДУ ФСТЭК России Поддержка версионности документов.
11–13 февраля 2025
С помощью Сканера-ВС можно проводить тестирование на проникновение, сканирование уязвимостей, а также анализ конфигурации, организовать непрерывный контроль защищенности. Использование «Сканер-ВС» позволяет обеспечить непрерывный мониторинг защищенности информационных систем, а также повысить эффективность деятельности IT-подразделений и служб безопасности. Возможность работы в режиме Live USB, а также развертывания в ИТ-инфраструктуре предприятия с поддержкой одновременной удаленной работы пользователей. Формирование отчета с техническими рекомендациями по устранению обнаруженных брешей в защите.
Обновление версий возможно проводить в электронном виде самостоятельно при наличии серийного номера с кодом FST. Если серийный номер не содержит кода FST, следует обратиться в службу поддержки и получить ссылки на новые версии сертифицированных продуктов Dr. Web, необходимо, чтобы в коде продукта вашего серийного номера было сочетание FST его наличие можно проверить в Менеджере лицензий. После ввода серийного номера появится пункт «Скачать продукты Dr. Мастер скачиваний предоставит доступ только к дистрибутивам сертифицированных продуктов.
Обратите внимание на ссылку «Формуляр», с помощью которой можно загрузить формуляр в электронном виде. Компании срочно требуется начать использовать сертифицированный продукт Dr. Web, и она не может ждать поставки медиапакета. Можно ли в этом случае скачать сертифицированную версию с сайта? Предоставьте документы об оплате сертифицированного пакета. Вам будет выслана специальная ссылка для скачивания. Переустанавливать Dr. Web после получения медиапакета с DVD не придется.
Либо можно приобрести сертифицированные дистрибутивы с вариантом поставки в электронном виде. Сколько требуется приобрести медиапакетов к сертифицированному Dr. Web, если у компании несколько офисов и филиалов? Если все офисы и филиалы удалены друг от друга, удобнее купить по комплекту в каждый офис и филиал, чем пересылать один комплект для установки в каждый из них. Также при проверке со стороны регулятора в части использования сертифицированного ПО удобнее иметь сертифицированный медиапакет на месте. Какова минимальная лицензия на продукт Dr. На 1 или 2 ПК с электронным медиапакетом либо на 5 ПК и более с электронным или с физическим медиапакетом. Узнайте цены на этой странице.
Компании требуется защита сертифицированным Dr. Web более 250 рабочих станций. В конструкторе лицензий на сайте цены только до 250 ПК. Как быть? Обратитесь в службу поддержки , выбрав Помощь в выборе антивируса, или закажите обратный звонок. Будет ли образовательному учреждению предоставлена скидка для образования при покупке медиапакета? Скидка полагается только на лицензию. Некоторое время назад компания приобрела Dr.
Web сертифицированный для N-го количества ПК. Сейчас требуется дозакупка. Надо ли приобретать дополнительный медиапакет? Нет, если требуется дозакупка сертифицированного медиапакета с тем же сертификатом соответствия. Какой продукт выбрать? Есть несколько вариантов: Dr. Web Desktop Security Suite — электронная лицензия и медиапакет. Коробочный продукт «Dr.
Web Малый бизнес». Можно ли использовать Dr.
В связи с этим, новая Методика должна стать если и не панацеей, то инструментом, значительно упрощающим процесс моделирования угроз информационной безопасности. Ключевые особенности новой методики Область применения Методики Первой и одной из наиболее важных отличительных черт новой Методики является область ее применения, которая теперь не ограничивается лишь ИСПДн. Документ должен использоваться для определения угроз безопасности информации при ее обработке с использованием любых объектов, требования по защите к которым утверждены ФСТЭК. Какой-либо порядок разработки и согласования «дочерних» методик не предусмотрен, единственное требование — они не должны противоречить положениям Методики. Такой подход выглядит вполне логичным, если бы не одно «но».
Дело в том, что разнообразие «базовых и типовых моделей угроз» на сегодняшний день оставляет желать лучшего — в свободном доступе опубликован лишь один документ, попадающий под это описание, да и тот представляет собой выписку и нацелен на все те же ИСПДн. Означает ли это, что в ближайшее время после утверждения Методики стоит ожидать пополнение в рядах базовых и типовых моделей угроз? Вопрос остается открытым. Порядок моделирования угроз безопасности Обновленный порядок включает в себя пять этапов, выполняемых в определенной последовательности. Общая схема процесса, представленная в Методике, выглядит следующим образом: За определение актуальности угрозы безопасности информации отвечают этапы с первого по четвертый. В соответствии с Методикой, угроза безопасности будет являться актуальной при наличии хотя бы одного сценария ее реализации и если ее реализация приведет к каким-либо негативным последствиям для обладателя информации оператора или государства. Цель пятого этапа — определить опасность каждой из актуальных угроз.
По сути, данная характеристика носит исключительно информационный характер и не оказывает прямого влияния ни на итоговый документ, формируемый по результатам моделирования, ни на возможные варианты нейтрализации угрозы. Можно предположить, что данный параметр должен использоваться для определения очередности закрытия угрозы, однако малое число возможных значений показателя — «низкий», «средний», «высокий» — не позволяют сделать это с достаточной степенью детализации. Более того, любая из дошедших до данного шага угроз должна быть так или иначе закрыта, поэтому забыть про «неопасную» угрозу попросту не получится. Таким образом, истинная цель данного параметра остается не раскрытой в полной мере. Стоит отметить, что работы по моделированию угроз безопасности должны проводиться либо обладателем информации оператором самостоятельно, либо с привлечением лицензиатов ФСТЭК. Такой подход, в соответствии с нормативными документами регулятора, применяется и в настоящее время. Определение актуальности угроз безопасности информации Подробнее хочется остановиться непосредственно на порядке определения актуальности угроз безопасности.
Итак, на первом этапе предлагается определить все возможные негативные последствия от реализации угроз безопасности.
Для этого специалисты разработали специальные правила сканирования, позволяющие проводить мониторинг системы на наличие выявленных ошибок безопасности. Уязвимости обнаружила команда BI. Сразу после этого мы передали информацию смежным подразделениям. Сообща начали оперативную работу над правилами обнаружения уязвимостей и блокирования атак с их эксплуатацией. Мы автоматически применили созданные правила для наших клиентов еще до появления в публичном доступе информации об уязвимостях. Именно благодаря слаженной работе отделов внутри компании BI. ZONE быстро реагирует на угрозы и защищает от них клиентов.
Множественные уязвимости systemd (CVE-2022-3821, CVE-2023-7008, CVE-2023-26604, CVE-2022-4415)
Преимущественно данные записи описывают уязвимости ПО, созданного российскими компаниями, такими как, 1С или «Лаборатория Касперского» но есть и исключения из этого правила. Данное обстоятельство, а также удобный для человеческого восприятия формат и подробное описание различных аспектов уязвимости статус, наличие эксплойтов и т. Кроме того, поскольку реестр БДУ ФСТЭК России ориентирован на сбор и хранение информации об уязвимостях ПО, используемого в российских организациях и компаниях включая компании с государственным участием и бюджетные организации , отечественным производителям ПО и системным администраторам российских организаций разумно ориентироваться именно на данный реестр уязвимостей в процессах оценки информационной безопасности создаваемых программных продуктов и поддержания защищенного состояния своих компьютерных сетей. К возможным недостаткам БДУ ФСТЭК России можно отнести меньшее общее количество покрытых реестром уязвимостей в сравнении как с базами CVE List и NVD, так и с базами данных уязвимостей, созданных коммерческими компаниями , а также отсутствие какой-либо агрегации отдельных записей которая характерна для такой базы данных, как Vulnerability Notes Database. С другой стороны, следует понимать, что иностранные реестры известных уязвимостей зачастую содержат большое количество записей, мало полезных для практического применения, в частности: информацию об очень старых более 15 лет уязвимостях устаревшего ПО и информацию об уязвимостях редкого и мало распространенного как в России, так и в мире в целом программного обеспечения. Данный стандарт непосредственно определяет как формат идентификаторов и содержимого записей об отдельных обнаруженных уязвимостях, так и процесс резервирования идентификаторов для новых обнаруженных уязвимостей и пополнения соответствующих баз данных. Уже в 2000 году инициатива MITRE по созданию единого стандарта для регистрации и идентификации обнаруженных уязвимостей ПО получила широкую поддержку со стороны ведущих производителей программного обеспечения и исследовательских организаций в области информационной безопасности. В настоящее время по данным на март 2018 года поддержкой и администрированием реестра уязвимостей CVE занимается группа из 84 организаций по всему миру, в число которых входят ведущие производители программного обеспечения, телекоммуникационного оборудования и интернет-сервисов, такие как Apple, Cisco, Facebook, Google, IBM, Intel, Microsoft, Oracle и ряд компаний, специализирующихся в области информационной безопасности, например, F5 Networks, McAfee, Symantec, «Лаборатория Касперского» и др. При этом, хотя сами базы данных различаются на уровне функциональных возможностей, предоставляемых пользователям, сами списки записей об уязвимостях фактически идентичны друг другу. Формально CVE List выступает изначальным источником записей для базы данных NVD, а специалисты, отвечающие за поддержку базы NVD, производят уточненный анализ и сбор доступной информации по уязвимостям, зарегистрированным в CVE List например, собирают ссылки на сторонние источники информации об уязвимости и мерах по ее устранению или предотвращению эксплуатации.
Для каждой из обнаруженных уязвимостей запись в базе содержит краткое описание типа и причин уязвимости, уязвимые версии ПО, оценку критичности уязвимости в соответствии со стандартом CVSS Common Vulnerability Scoring System и ссылки на внешние источники с информацией об уязвимости — чаще всего, таковыми выступают информационные бюллетени на сайтах производителей программного обеспечения или исследовательских организаций. Также возможно автоматическое получение обновлений в машиночитаемом виде через специальный data feed CVE Change Log он позволяет как отслеживать появление новых идентификаторов CVE, так и изменения в записях для уже существующих. При обнаружении новой уязвимости производителем ПО или исследовательской организацией или подтверждении наличия уязвимости вендором ПО в ответ на сообщение от частных исследователей или организаций, не входящих в CVE Numbering Authorities под нее оперативно регистрируется новый идентификатор CVE и создается запись в базе, после чего происходит периодическое обновление информации. При этом уникальность регистрируемого идентификатора обеспечивается иерархической структурой CNAs как показано на рисунке , в которой корневые организации Root CNA делят и распределяют между подчиненными организациями Sub CNA диапазон доступных в этом году идентификаторов CVE. Каждая из соответствующих подчиненных организаций в свою очередь распоряжается предоставленным диапазоном идентификаторов для создания записей об обнаруженных уязвимостях в своих собственных продуктах, либо обнаруженных уязвимостях в продуктах третьей стороны, при условии, что она не является участником CVE Numbering Authorities. Рисунок 1: Иерархическая структура CNAs Сильной стороной самого стандарта CVE является его повсеместная поддержка в современных программных продуктах и сервисах, направленных на обеспечение информационной безопасности. Некоторым естественным ограничением баз данных CVE List и NVD является отсутствие в записях об уязвимостях какой-либо информации о точном месте локализации уязвимости в коде уязвимого ПО и возможных векторах атак, посредством которых возможна эксплуатация данной уязвимости. В некоторых случаях данная информация может быть найдена по ссылкам на внешние ресурсы, однако в большинстве случаев производители и вендоры ПО избегают публикации данной информации, причем не только на период разработки и внедрения патчей, закрывающих обнаруженную уязвимость, но и в последующем. Частично такая политика объясняется нежеланием участников CVE Numbering Authorities предоставлять подобную информацию потенциальным злоумышленникам, особенно в свете того, что уязвимое программное обеспечение может быть широко распространено по всему миру, а эксплуатирующие его организации часто не имеют возможностей или не придают должного значения своевременной установке обновлений.
Иным же из подобных инициатив в области информационной безопасности, например, базе данных уязвимостей OSVDB Open Sourced Vulnerability Database — повезло гораздо меньше. База OSVDB была запущена в 2004 году, по результатам конференций по компьютерной безопасности Blackhat и DEF CON и строилась вокруг ключевой идеи: организовать такой реестр уязвимостей, который содержал бы полную и подробную информацию обо всех обнаруженных уязвимостях, и поддержка которого не была бы аффилирована ни с одним из производителей программного обеспечения. Одним из косвенных результатов деятельности коллектива исследователей, причастных к развитию базы OSVDB, стало основание в 2005 году организации Open Security Foundation. Ее специалисты занимались самостоятельным поиском уязвимостей и агрегацией публично доступной из различных источников информации об обнаруженных уязвимостях или сценариях их эксплуатации. Новые уязвимости специалисты регистрировали в базе, производили их классификацию и валидацию. При этом уточнялись списки уязвимого ПО и сведения о возможных способах устранения уязвимостей. В таком виде каждая запись, снабженная соответствующими ссылками на доступные источники информации, оставалась в базе данных. Одним из возможных предназначений предлагаемого сервиса может быть риск-менеджмент и оценка уровня защищенности компьютерных сетей организаций. Secunia Advisory and Vulnerability Database Сходные услуги в области информационной безопасности предоставляются датской компанией Secunia Research, которая специализируется на исследованиях в области компьютерной и сетевой безопасности и в числе прочих сервисов предоставляет доступ к базе уязвимостей Secunia Advisory and Vulnerability Database.
МСЭ В информационной безопасности это. Федеральная служба по техническому и экспортному контролю РФ. Уязвимости банка. Банки данных угроз и уязвимостей. Федеральная служба технического и экспортного контроля. Модель угроз безопасности информации 2021 пример. ФСТЭК 2021.
ФСТЭК герб. ФСТЭК герб на прозрачном фоне. Федеральная служба России по валютному и экспортному контролю. ФСТЭК эмблема без фона. Федеральная служба по техническому и экспортному контролю логотип. Федеральная служба по валютному и экспортному контролю. Федеральная служба по техническому и экспортному контролю функции.
Федеральная служба по техническому и экспортному контролю структура.
Портал показывает историю, какие уязвимости закрываются этим патчем, а также сам вердикт на рассматриваемое программное обеспечение. Раздел результатов тестирования обновлений ПО работает в тестовом режиме. Ссылки на материалы:.
Служба отвечает за противодействие иностранным техническим разведкам на территории страны, безопасность критической информационной инфраструктуры России, защиту государственной тайны, а также за проведение экспортного контроля в частности, товаров двойного назначения. В гражданской жизни со службой чаще всего сталкиваются компании, которые разрабатывают электронные средства защиты антивирусы, межсерверные экраны или хранят и обрабатывают персональные данные сотрудников и клиентов. В первом случае ФСТЭК проверяет, насколько та или иная программа соответствует требованиям закона о персональных данных, и выдает соответствующий сертификат.
Обновлённые реестры ФСТЭК
Иконка канала Россия 1. реестр аккредитованных ФСТЭК России органов по сертификации и испытательных. Необходимость расширения полномочий ФСТЭК связана с тем, что попросту некому поручить, считает руководитель компании «Интернет-розыск» Игорь Бедеров. Идентификаторы БДУ ФСТЭК России. Разберем новый методический документ «Руководство по организации процесса управления уязвимостями в органе (организации)» от ФСТЭК0:06 область применения0:41.
Множественные уязвимости systemd (CVE-2022-3821, CVE-2023-7008, CVE-2023-26604, CVE-2022-4415)
Методика применяется для оценки угроз безопасности информации в системах и сетях, решение о создании или модернизации развитии которых принято после даты ее утверждения, а также в эксплуатируемых системах и сетях. Модели угроз безопасности информации систем и сетей, разработанные и утверждённые до утверждения Методики, продолжают действовать и подлежат изменению в соответствии с настоящей Методикой при развитии модернизации соответствующих систем и сетей.
Направление 1 деловой программы и экспозиции Форума Цифровая трансформация предприятий и органов власти Процессы цифровизации в крупных предприятиях и в госсекторе, высокая потребность в быстром создании и развитии цифровых продуктов, управлении цифровыми услугами требуют переосмысления подходов. На Форуме руководители и специалисты обсуждают стратегию и структуру внедрения технологий, состав цифровых команд, импортозамещение ключевых цифровых решений и обеспечение технологического суверенитета, практику и проекты цифровой трансформации.
Разве через понятия и определения не раскрывается их смысловое значение? В этом и есть их суть. Когда нет понятий и определений, то откуда взяться их смысловому значению и говорить о какой-то их "строгости"? Если ту же УБИ. Это к вопросу толкований и толкователей, ага... Под "семантикой" следует понимать смысловую нагрузку сообщения в целом, потому что конкретное слово вне контекста зачастую может быть воспринято некорректно как, собственно, и происходит у любителей докопаться до терминологии... Что же до моего вИдения, так, блин, все, что пишу на форуме, находится под знаком "imho".
Или меня внезапно причислили к рупорам регулятора? Спасибо, конечно, но после "Догмы" образ Метатрона вообще не импонирует... С одной стороны, "Угроза"! Короче, поглядим, что там будет в новой редакции Методики... Видимо под "смысловой нагрузкой сообщения в целом" имеется в виду "выражение законченной мысли", а, следовательно, под "семантикой" предлагается понимать "предложение". Вот почему в начале документов, как правило, приводят термины и определения сейчас понятия , чтобы через объяснение применяемых понятий широком смысле, узком смысле, каком-то уникальном смысле способствовать более точному пониманию смысла изложенного в документе текста в целом. А какие ещё бывают виды векторов кроме "базового"?
Каждой уязвимости и угрозе безопасности информации, подлежащей включению в банк данных угроз безопасности информации, присваивается идентификатор. Первая группа цифр "ХХХХ" представляет собой календарный год включения уязвимости в банк данных угроз безопасности информации.
Вторая группа цифр "ХХХХХ" является порядковым номером уязвимости в банке данных угроз безопасности информации. Идентификатор, присваиваемый угрозе безопасности информации, состоит из буквенной аббревиатуры "УБИ" и группы цифр и имеет вид: УБИ. Группа цифр "ХХХ" представляет собой порядковый номер угрозы безопасности информации в банке данных угроз безопасности информации от 001 до 999. Уязвимость подлежит включению в банк данных угроз безопасности информации, если по результатам ее анализа получена и проверена информация, как минимум, по описанию уязвимости, наименованию и версии программного обеспечения, в котором возможна уязвимость, уровню опасности уязвимости.
Банк угроз ФСТЭК: использовать нельзя игнорировать
ФСТЭК России пересмотрел административные регламенты по контролю за соблюдением лицензионных требований. Все хранящиеся в БДУ ФСТЭК России записи имеют единообразный формат и включают: текстовое описание уязвимости, дату обнаружения уязвимости, названия, версии и производителей уязвимого ПО, информацию о типе ошибки. В чисто прикладном смысле БДУ ФСТЭК содержит огромное количество различных возможных угроз. У разработчика антивирусов приостановлена лицензия Федеральной службы по техническому и экспортному контролю (ФСТЭК) для одного из ключевых продуктов за «несоответствие требованиям безопасности информации». 01.03.2024 на сайте ФСТЭК России опубликован проект национального стандарта ГОСТ Р. upd На праздниках развернул сервер с альтернативной формой БДУ ФСТЭК. ФСТЭК России организует деятельность государственной системы противодействия техническим разведкам и технической защиты информации и руководит ею.
Блеск и нищета… БДУ
| Новая методика оценки УБИ — Утверждено ФСТЭК России | Главная страница:: Новости:: Центр безопасности информации представил доклад на XIV конференции "Актуальные вопросы защиты информации", проводимой ФСТЭК России в. |
| Обновления базы уязвимостей “Сканер-ВС” | Приказ Федеральной службы по техническому и экспортному контролю от 20.06.2023 № 119 "О признании утратившим силу приказа ФСТЭК России от 24 августа 2012 г. № 100". |
| Банк угроз ФСТЭК: использовать нельзя игнорировать | Но в отличие от BDU:2024-00878, эта уязвимость затрагивает только старые версии продукта — до 2022.1.3.451 (Websoft HCM). |
| Множественные уязвимости systemd (CVE-2022-3821, CVE-2023-7008, CVE-2023-26604, CVE-2022-4415) | Идентификатор БДУ ФСТЭК России. Базовый вектор уязвимости CVSS 2.0. |
| Купить Сканер-ВС, цена лицензий, сертификат ФСТЭК | Последние новости. «формирует перечень организаций, которые аккредитованы ФСТЭК России или имеют лицензии ФСТЭК России, осуществляют деятельность по обеспечению информационной безопасности. |
Федеральная служба по техническому и экспортному контролю
Разберем новый методический документ «Руководство по организации процесса управления уязвимостями в органе (организации)» от ФСТЭК0:06 область применения0:41. • 3 класса защищенности ГИС; • Применение БДУ ФСТЭК. MITRE ATT&CK БДУ ФСТЭК Новая БДУ ФСТЭК. Аккаунт для добавления уязвимостей с банка данных угроз безопасности информации ФСТЭК России. Главная страница:: Новости:: Центр безопасности информации представил доклад на XIV конференции "Актуальные вопросы защиты информации", проводимой ФСТЭК России в рамках. б) база данных уязвимостей, содержащаяся в Банке данных угроз безопасности информации (далее – БДУ) ФСТЭК России3.
11–13 февраля 2025
Входит в реестр Российского ПО, рег. Преимущества Обширная база знаний команда экспертов Positive Technologies регулярно пополняет базу новыми данными об угрозах. Автоматизация сканирования в XSpider можно настроить автоматический запуск задач на сканирование в нужное время. После завершения сканирования системный планировщик может направить отчет по электронному адресу или сохранить его в указанную сетевую папку. Быстрая установка и настройка XSpider не требует развертывания программных модулей на узлах, все проверки проводятся удаленно.
Предусмотрена возможность установки XSpider как на аппаратную платформу, так и в виртуальной среде. Глубокий анализ систем Microsoft XSpider проводит расширенную проверку узлов под управлением Windows.
В соответствии с Методикой, угроза безопасности будет являться актуальной при наличии хотя бы одного сценария ее реализации и если ее реализация приведет к каким-либо негативным последствиям для обладателя информации оператора или государства. Цель пятого этапа — определить опасность каждой из актуальных угроз. По сути, данная характеристика носит исключительно информационный характер и не оказывает прямого влияния ни на итоговый документ, формируемый по результатам моделирования, ни на возможные варианты нейтрализации угрозы. Можно предположить, что данный параметр должен использоваться для определения очередности закрытия угрозы, однако малое число возможных значений показателя — «низкий», «средний», «высокий» — не позволяют сделать это с достаточной степенью детализации. Более того, любая из дошедших до данного шага угроз должна быть так или иначе закрыта, поэтому забыть про «неопасную» угрозу попросту не получится.
Таким образом, истинная цель данного параметра остается не раскрытой в полной мере. Стоит отметить, что работы по моделированию угроз безопасности должны проводиться либо обладателем информации оператором самостоятельно, либо с привлечением лицензиатов ФСТЭК. Такой подход, в соответствии с нормативными документами регулятора, применяется и в настоящее время. Определение актуальности угроз безопасности информации Подробнее хочется остановиться непосредственно на порядке определения актуальности угроз безопасности. Итак, на первом этапе предлагается определить все возможные негативные последствия от реализации угроз безопасности. Помогать в этом должна либо проведенная ранее оценка ущерба рисков от нарушения основных критических процессов, либо экспертная оценка, либо информация, получаемая от эксплуатирующих информационную систему подразделений. При любом выбранном подходе, необходимо определить информационные ресурсы, обеспечивающие выполнение критических процессов непосредственно информация, программно-аппаратные средства, средства защиты информации и иные и основные виды неправомерного доступа по отношению к каждому из ресурсов.
Методичка содержит перечень основных видов ресурсов и неправомерного доступа к ним, а также примеры определения возможных негативных последствий. На втором этапе необходимо определить наличие потенциальных уязвимостей и их типы, наличие недекларированных возможностей в информационных системах, а также необходимость доступа к системе для реализации каждой из угроз безопасности. В качестве основного метода выявления потенциальных уязвимостей в информационной системе на этапе ее эксплуатации является тестирование на проникновение, проводимое в том числе с учетом функциональных возможностей и настроек средств защиты. Следующим, третьим этапом является определение нарушителей безопасности и оценка их возможностей. В качестве источников угроз предлагается рассматривать как антропогенные, так и техногенные: первые рассматриваются абсолютно для всех информационных систем, тогда как вторые — только для тех систем, для которых предъявляются требования к устойчивости и надежности функционирования. Подход к определению возможных антропогенных источников угроз — нарушителей — является стандартным и заключается в выявлении конкретных видов нарушителей, их потенциала и возможностей при реализации угроз в отношении защищаемой информационной системы. Стоит отметить, что при наличии связи информационной системы с Интернетом, внешний нарушитель как минимум с низким потенциалом всегда рассматривается в качестве актуального источника угроз.
Также необходимо обратить внимание, что согласно новой Методике, нарушитель может обладать одним из четырех уровней потенциала базовый, базовый повышенный, средний и высокий , в то время как БДУ, при описании источника угроз, использует лишь 3 уровня низкий, средний, базовый.
А это, как следствие, потянет за собой переработку технической и организационно-распорядительной документации на системы защиты указанных видов ИС. Например, в случае их модернизации. Кроме того, вызывает недоумение отнесение пользователей к компонентам объектов воздействия см. Сам факт отнесения субъектов ИС к компонентам объектов воздействия не совсем корректно. Справочник объектов воздействия определяет 12 объектов, включающих 10 разных видов "инструментов", информацию и среду ее распространения. Компонентой как частью чего является пользователь: "инструмента", информации или среды распространения? Не понятно. Но это ещё пол беды.
Эти же пользователи также отнесены и к типам нарушителей см. Получается, что основная часть субъектов ИС пользователи и администраторы одновременно и объект воздействия его часть как компонента и источник угроз. Может это "недоразумение" будет как-то устранено в новой редакции методики? Как говорится "поживём - увидим"... Не больше и не меньше. Поэтому давать ей какую-либо оценку пока рано.
Включение информации в банк данных угроз безопасности информации осуществляется по мере появления получения сведений о новых уязвимостях и угрозах безопасности информации и их рассмотрения. Доступ к банку данных угроз безопасности информации осуществляется в режиме просмотра чтения информации об уязвимостях и угрозах безопасности информации. Информация, содержащаяся в банке данных угроз, является общедоступной. Заинтересованным органам государственной власти и организациям рекомендуется использовать информацию, содержащуюся в банке данных угроз безопасности информации, при организации и проведении всех видов работ по защите информации, установленных нормативными правовыми актами, методическими документами и национальными стандартами в области обеспечения информационной безопасности.
Лицам исследователям , планирующим направить информацию об уязвимостях в банк данных угроз безопасности информации через раздел "Обратная связь", необходимо учитывать, что данные фамилия и имя исследователя, выявившего уязвимость, могут быть опубликованы в банке данных угроз. Это необходимо для анализа и организации устранения уязвимостей в конкретном программном обеспечении, в ходе которого возможно потребуются взаимодействие и совместные действия со специалистами Службы и или иными организациями, включая разработчиков производителей программного обеспечения.