быстрое определение уязвимостей: выявление уязвимостей по версиям установленного ПО, база уязвимостей, включающая данные из БДУ ФСТЭК России, NIST NVD, а также баз уязвимостей ОС Debian, Red Hat, Arch, Ubuntu, Windows, Astra Linux и др. Еженедельно обновляемая база уязвимостей, совместимая с банком данных угроз безопасности информации (БДУ) ФСТЭК России.
UDV DATAPK Industrial Kit
Новости БДУ ФСТЭК России Download Telegram. Главные новости об организации ФСТЭК России на Решения «Лаборатории Касперского» имеют сертификаты соответствия ФСТЭК и ФСБ России, но не все знают для чего они требуются. фстэк россии опубликовала инструмент под названием scanoval, предназначенный для автоматического обнаружения уязвимостей в по серверов и. • 3 класса защищенности ГИС; • Применение БДУ ФСТЭК. MITRE ATT&CK БДУ ФСТЭК Новая БДУ ФСТЭК.
ScanOVAL для Astra Linux 1.6 Бесплатный анализ на наличие уязвимостей Linux БДУ ФСТЭК
и ИБ-департаменты в российских компаниях и учреждениях. и ИБ-департаменты в российских компаниях и учреждениях. Все хранящиеся в БДУ ФСТЭК России записи имеют единообразный формат и включают: текстовое описание уязвимости, дату обнаружения уязвимости, названия, версии и производителей уязвимого ПО, информацию о типе ошибки. В 2015 году ФСТЭК России совместно с заинтересованными органами власти и организациями сформировала банк данных угроз безопасности информации (БДУ). Все хранящиеся в БДУ ФСТЭК России записи имеют единообразный формат и включают: текстовое описание уязвимости, дату обнаружения уязвимости, названия, версии и производителей уязвимого ПО, информацию о типе ошибки.
ФСТЭК РФ БДУ и организации, системы, технологии, персоны:
- Пользоваться, нельзя игнорировать
- Федеральная служба по техническому и экспортному контролю (ФСТЭК)
- 11–13 февраля 2025
- Анализ уязвимостей и оценка соответствия по ОУД4
Новый раздел на сайте БДУ - Форум по вопросам информационной безопасности
Ситуация получается очень похожей на басню Крылова правда, немного в другой коннотации : «Вертит Очками так и сяк: То к темю их прижмёт, то их на хвост нанижет, То их понюхает, то их полижет; Очки не действуют никак». И происходит это по банальной причине: нет связи между угрозами и мерами. Вот давайте посмотрим на раздел банка угроз, связанного с уязвимостями. Там есть не только привязка уязвимости к конкретному ПО и его версии, что позволяет однозначно определить необходимость принятия мер, но и такие замечательные рубрики, как «Возможные меры по устранению уязвимости» и «Способ устранения». А это уже прямое руководство к действию. Поэтому этот раздел оказывается весьма полезным в практической деятельности ибэшников. К сожалению, этого нельзя сказать про раздел угроз безопасности информации. Правда, некоторые специалисты пытаются составить таблицы соответствия угроз и мер защиты [2], но, честно говоря, это всё-таки самоделки.
Здесь нужен системный подход,чёткая проработка и соответствующие разделы в банке угроз. Вот тогда-то модель угроз станет действенным инструментом при выборе мер защиты и не потребуется заставлять бизнес разрабатывать формальную модель угроз «документ ради документа» , он сам почувствует её необходимость, так как это будет экономить деньги. А ещё лучше, если угрозы будут увязаны не только с мерами защиты, но и с необходимыми функциями безопасности, которые реализуются средствами защиты читай классами средств защиты. Тогда модель угроз станет бесценной. Не всё, что в банке угроз названо угрозами, является таковым. Просто кое-что, отнесённое к классу угроз, не вписывается в классическое определение угроз. Частенько идёт подмена понятий.
Кстати, об определении. Как сказал классик, «прежде чем объединяться и для того, чтобы объединиться, мы должны сначала решительно и определённо размежеваться». В нашем случае объединяться — это составить банк угроз, а размежеваться — чётко определить те сущности, которые мы собираемся объединять. Попробуем «размежеваться». И главное здесь, конечно, — понятие угрозы. Глупо полагать, что обеспечением безопасности информации занимаются только для того, чтобы поддержать соответствующие службы и производителей средств защиты. Эгоизм правит миром, и поэтому любая деятельность по обеспечению безопасности информации направлена только на то, чтобы не допустить ущерба обладателю от нарушений полезных свойств информации.
Поэтому примем за аксиому, что угроза — это некие негативные действия, угрожающие интересам субъекта обладателя информации. А отсюда следует, что угроза может быть только тогда, когда есть субъект, которому может быть причинён ущерб. Поэтому «угрозы информации» быть не может в силу того, что информация является объектом отношений, а не субъектом. Может быть только «угроза безопасности информации», то есть угроза состоянию защищённости информации. Действительно, даже если будут в силу каких-то обстоятельств нарушены полезные свойства информации конфиденциальность, целостность, доступность , это не причинит никакого вреда, если нет субъекта, заинтересованного в обеспечении сохранности этих полезных свойств. Любые негативные действия могут быть совершены только при наличии каких-нибудь слабых мест уязвимостей , ведь если, к примеру, кто-нибудь захочет проникнуть за кирпичную стену и будет биться в неё головой, то, скорее всего, у него ничего не получится, однако наличие в стене деревянной калитки уже значительно повышает шансы на успех его героических попыток.
Эгоизм правит миром, и поэтому любая деятельность по обеспечению безопасности информации направлена только на то, чтобы не допустить ущерба обладателю от нарушений полезных свойств информации. Поэтому примем за аксиому, что угроза — это некие негативные действия, угрожающие интересам субъекта обладателя информации. А отсюда следует, что угроза может быть только тогда, когда есть субъект, которому может быть причинён ущерб.
Поэтому «угрозы информации» быть не может в силу того, что информация является объектом отношений, а не субъектом. Может быть только «угроза безопасности информации», то есть угроза состоянию защищённости информации. Действительно, даже если будут в силу каких-то обстоятельств нарушены полезные свойства информации конфиденциальность, целостность, доступность , это не причинит никакого вреда, если нет субъекта, заинтересованного в обеспечении сохранности этих полезных свойств. Любые негативные действия могут быть совершены только при наличии каких-нибудь слабых мест уязвимостей , ведь если, к примеру, кто-нибудь захочет проникнуть за кирпичную стену и будет биться в неё головой, то, скорее всего, у него ничего не получится, однако наличие в стене деревянной калитки уже значительно повышает шансы на успех его героических попыток. И уж, конечно, если есть какие-то негативные действия, то их кто-то или что-то должен совершать. И мы вроде бы пришли к классическому определению угрозы безопасности информации — совокупность условий и факторов, создающих потенциальную или реально существующую опасность нарушения безопасности информации [3]. Это можно выразить формулой: Но такое представление угрозы всё-таки будет не совсем точным. Обратим внимание, что в определении «условия» и «факторы» даны во множественном числе. Поэтому правильнее будет так: Одна и та же угроза может быть реализована различными источниками угроз, различными способами и с использованием различных факторов.
Совокупность условий и факторов, определяющих конкретную угрозу, будет определяться множеством всех возможных вариантов комбинаций реализации данной угрозы различными источниками с использованием различных методов и факторов. Давайте посмотрим это «на яблоках». Положим, у кого-то есть сейф, в котором лежит бриллиантовое колье, а Некто задумал это колье экспроприировать. В нашем случае в качестве Некто может быть: а тривиальный вор внешний нарушитель , б любимый сын внутренний нарушитель , в случайный сантехник посетитель. В этом случае угрозой можно считать кражу колье. Тогда источники — вор, сын, сантехник; уязвимости факторы — ошибки хранения, слабый сейф, тонкий металл; методы — вскрытие, взлом, резка. И всё это может быть в разных комбинациях. Получается, что угроза — одна, а реализаций — много. В существующем банке угроз, к сожалению, всё смешано в кучу: и угрозы и их реализации.
Описать угрозы — можно, это всегда конечный перечень. Описать все возможные реализации угроз — задача благородная, но практически не реализуемая в силу большого разнообразия сущностей, её составляющих. Ну а если ещё идёт смешение сущностей — получается «Бородино». Нужна какая-то система. И тут на сцену выходит дедушка Карл Николиус Линней со своей таксономией [4]. И чем так привлекателен для нас «отец систематики» Карл Линней? Наверное, самое важное — это то, что он нашёл тот самый критерий или признак, который, с одной стороны, является общим для всех систематизируемых сущностей, а с другой — индивидуален для каждой такой сущности.
Общая схема процесса, представленная в Методике, выглядит следующим образом: За определение актуальности угрозы безопасности информации отвечают этапы с первого по четвертый.
В соответствии с Методикой, угроза безопасности будет являться актуальной при наличии хотя бы одного сценария ее реализации и если ее реализация приведет к каким-либо негативным последствиям для обладателя информации оператора или государства. Цель пятого этапа — определить опасность каждой из актуальных угроз. По сути, данная характеристика носит исключительно информационный характер и не оказывает прямого влияния ни на итоговый документ, формируемый по результатам моделирования, ни на возможные варианты нейтрализации угрозы. Можно предположить, что данный параметр должен использоваться для определения очередности закрытия угрозы, однако малое число возможных значений показателя — «низкий», «средний», «высокий» — не позволяют сделать это с достаточной степенью детализации. Более того, любая из дошедших до данного шага угроз должна быть так или иначе закрыта, поэтому забыть про «неопасную» угрозу попросту не получится. Таким образом, истинная цель данного параметра остается не раскрытой в полной мере. Стоит отметить, что работы по моделированию угроз безопасности должны проводиться либо обладателем информации оператором самостоятельно, либо с привлечением лицензиатов ФСТЭК. Такой подход, в соответствии с нормативными документами регулятора, применяется и в настоящее время.
Определение актуальности угроз безопасности информации Подробнее хочется остановиться непосредственно на порядке определения актуальности угроз безопасности. Итак, на первом этапе предлагается определить все возможные негативные последствия от реализации угроз безопасности. Помогать в этом должна либо проведенная ранее оценка ущерба рисков от нарушения основных критических процессов, либо экспертная оценка, либо информация, получаемая от эксплуатирующих информационную систему подразделений. При любом выбранном подходе, необходимо определить информационные ресурсы, обеспечивающие выполнение критических процессов непосредственно информация, программно-аппаратные средства, средства защиты информации и иные и основные виды неправомерного доступа по отношению к каждому из ресурсов. Методичка содержит перечень основных видов ресурсов и неправомерного доступа к ним, а также примеры определения возможных негативных последствий. На втором этапе необходимо определить наличие потенциальных уязвимостей и их типы, наличие недекларированных возможностей в информационных системах, а также необходимость доступа к системе для реализации каждой из угроз безопасности. В качестве основного метода выявления потенциальных уязвимостей в информационной системе на этапе ее эксплуатации является тестирование на проникновение, проводимое в том числе с учетом функциональных возможностей и настроек средств защиты. Следующим, третьим этапом является определение нарушителей безопасности и оценка их возможностей.
В качестве источников угроз предлагается рассматривать как антропогенные, так и техногенные: первые рассматриваются абсолютно для всех информационных систем, тогда как вторые — только для тех систем, для которых предъявляются требования к устойчивости и надежности функционирования. Подход к определению возможных антропогенных источников угроз — нарушителей — является стандартным и заключается в выявлении конкретных видов нарушителей, их потенциала и возможностей при реализации угроз в отношении защищаемой информационной системы. Стоит отметить, что при наличии связи информационной системы с Интернетом, внешний нарушитель как минимум с низким потенциалом всегда рассматривается в качестве актуального источника угроз.
Эксплуатация уязвимости может позволить нарушителю, действующему удаленно, выполнить произвольный код путём отправки специально сформированного HTTP-запроса CVE-2023-39367 Установка обновлений из доверенных источников. В связи со сложившейся обстановкой и введенными санкциями против Российской Федерации рекомендуется устанавливать обновления программного обеспечения только после оценки всех сопутствующих рисков.
Сергей Борисов
Рисунок 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.
Бюллетени формируются на основе собственных исследований специалистов Secunia Research и агрегации информации об уязвимостях, полученных из иных публичных источников. Как и в случае с базой VulnDB, бюллетени в базе данных Secunia зачастую публикуются еще до того, как соответствующие записи появляются в базе CVE List, и уже впоследствии размечаются ссылками на соответствующие CVE-идентификаторы. По своей структуре записи в базе Secunia сходны с содержимым баз CVE List и NVD и содержат дату регистрации уязвимости, тип и краткую классификацию уязвимости, критичность уязвимости описывается с помощью перечислимого типа Secunia Research Criticality Rating вместо скалярной оценки по стандарту CVSS , списки уязвимого ПО и его версий, ссылки на внешние источники информации и рекомендации по устранению угрозы как правило, установку патчей от производителя ПО или апгрейд уязвимого ПО до безопасной версии — в этом случае бюллетень содержит упоминание минимального номера безопасной версии. Характерно, что в бюллетенях Secunia Advisories принято агрегировать в одной записи информацию о множестве отдельных уязвимостей, одновременно обнаруженных в одном и том же программном обеспечении.
Это означает, что одной записи из базы данных Secunia может соответствовать множество различных CVE-идентификаторов. В настоящее время база данных Secunia Research содержит приблизительно 75 тысяч записей об уязвимостях, обнаруженных начиная с 2003 года. Бесплатный доступ к Secunia Advisories производится только на условиях некоммерческого использования предоставленной информации и только в формате html по всей видимости, это делается для того, чтобы затруднить автоматизированное извлечение информации из базы. Для коммерческого использования доступ к базе данных от Secunia Research предоставляется посредством специализированного средства Software Vulnerability Manager и соответствующей подписки на сервис компании Flexera, которой и принадлежит с 2015 года Secunia Research.
Каждая запись в базе VND агрегирует информацию о множестве сходных уязвимостей для какого-либо конкретного ПО, ссылаясь на множество соответствующих CVE идентификаторов. Данные характеристики базы VND относятся к числу ее сильных сторон и дополняются разрешением на бесплатное использование всех материалов базы для любых целей и возможностью полного скачивания всех записей базы в формате JSON с помощью специального бесплатно предоставляемого программного обеспечения. Недостатками базы VND являются редкие обновления единицы раз в месяц и слабый охват всех существующих уязвимостей в том числе даже зарегистрированных в CVE List , что существенно ограничивают полезность данного каталога уязвимостей для оперативного реагирования на новые уязвимости ПО. В частности, в настоящий момент в базе зарегистрировано лишь около 3,5 тысяч записей, и по состоянию на март 2018 года было опубликовано лишь пять новых записей.
Exploit Database Альтернативным подходом к каталогизации информации об обнаруженных уязвимостях ПО является регистрация не самих уязвимостей, а сценариев их эксплуатации эксплойтов, exploits или примеров эксплуатации уязвимости Proof of Concept. База Exploit Database на настоящий момент содержит порядка 39 тысяч записей, разбитых на различные категории эксплойты для веб-приложений, удаленной и локальной эксплуатации уязвимостей, примеры атак Denial of Service и исполнимые фрагменты кода shellcode для различных уязвимостей переполнения стека или доступа к памяти. Данные записи покрывают множество уязвимостей, обнаруженных с 2000 года по настоящее время.
Подберет пароли Проверяет протоколы электронной почты и удаленного управления, служб передачи файлов и баз данных. Также проверит веб-приложения собственной разработки. Проинформирует об угрозах По каждой обнаруженной уязвимости XSpider предоставит подробное описание, инструкцию по исправлению, ссылки на общедоступные источники и выставит базовую и временную оценку по вектору CVSS v2 и v3. Сформирует отчеты XSpider выдаст в структурированном виде данные о результатах сканирования.
Можно фильтровать данные, сравнивать результаты различных сканирований и получать общие оценки состояния системы. Автоматизирует контроль защищенности XSpider позволяет выстроить процесс выявления уязвимостей: настроить автоматический запуск задач на сканирование в нужное время. Благодаря этому отпадает необходимость в ручной проверке каждого отдельного компонента информационной системы.
Еще одно полномочие службы в соответствии с указом президента от 8 ноября — оперативное информирование органов власти, местного самоуправления и организаций об угрозах безопасности информации и уязвимостях информационных систем и иных объектов КИИ, а также о мерах по технической защите от этих угроз и уязвимостей. Также ФСТЭК будет разрабатывать процессы управления технической защитой информации и обеспечением безопасности значимых объектов КИИ, учитывающие отраслевую специфику данных объектов за исключением процессов обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы РФ и организовывать внедрение этих процессов. Кроме того, президент наделил службу полномочиями по организации взаимодействия органов власти, местного самоуправления и организаций при реализации ими мер по повышению уровня технической защищенности информации и обеспечения безопасности значимых объектов КИИ. Наконец, ФСТЭК теперь будет организовывать и проводить оценку эффективности деятельности госорганов по технической защите информации и обеспечению безопасности значимых объектов КИИ. Отсюда мнение о том, что опираться нужно на аппарат государственных служащих.
В настоящий момент идет тестовая эксплуатация нового формата раздела угроз на платформе. Он дает возможность сформировать персонализированный перечень угроз под конкретную инфраструктуру. С ее помощью удобно корректировать политику информационной безопасности. Некоторые обновления создают новые дыры в безопасности, на исправление которых нужны новые доработки. Информационная инфраструктура развивается и меняется непрерывно. Но для полной безопасности ими ограничиваться не стоит. Например, в части описаний. Текст, написанный техническим языком, с добавлением свойственных любому государственному органу канцеляризмов — это существенная преграда для понимания и эффективного использования. Другой аспект — это вовлечение российских специалистов в работу над платформой. Когда речь идет о практических инструментах «для людей», делать их без оглядки на исполнителей и потребителей — это неэффективный путь. Сергей Вихорев Советник генерального директора ГК «ИТ-Экспертиза», эксперт по информационной безопасности Стоит открыть любой документ ФСТЭК России, касающийся требований к мерам защиты информации, и увидим: «Требования к системе защиты информации информационной системы определяются в зависимости от... И далее: «В качестве исходных данных для определения угроз безопасности информации должен использоваться банк данных угроз безопасности информации bdu.
Обзор продукта
- Обзор проекта новой методики моделирования угроз безопасности информации / Хабр
- Блеск и нищета… БДУ
- Сергей Борисов
- Оценка по ОУД4
- Блеск и нищета… БДУ
11–13 февраля 2025
Главные новости об организации ФСТЭК России на В чисто прикладном смысле БДУ ФСТЭК содержит огромное количество различных возможных угроз. Раздел тестирования обновлений БДУ ФСТЭК России Сведения о результатах тестирований в описаниях уязвимостей. Разберем новый методический документ «Руководство по организации процесса управления уязвимостями в органе (организации)» от ФСТЭК0:06 область применения0:41.