Куда я попал?
Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении (Выписка)
Страна: Россия
Методическая документация ФСТЭК
4.1.2.2
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
Испытательной лабораторией самостоятельно собираются и анализируются материалы из общедоступных источников (публикации разработчика, пользователей и исследователей об ОО и его заимствованных компонентах, базы данных уязвимостей, сведения о типовых уязвимостях и ошибках, тематические информационные ресурсы) о недостатках (слабостях) и уязвимостях как самого ОО, так и аналогичного по архитектуре программного обеспечения в дополнение к исходным данным, предоставленным разработчиком ОО. В качестве источников информации о типовых недостатках (слабостях) и уязвимостях следует использовать в том числе:а) банк данных угроз безопасности информации ФСТЭК России, а также иные отечественные базы уязвимостей;б) зарубежные базы данных уязвимостей и недостатков (слабостей) (Common Vulnerabilities and Exposures, Common Weakness Enumeration и иные), а также общий перечень шаблонов атак (Common Attack Pattern Enumeration and Classification);в) публикации и форумы, содержащие отзывы пользователей;г) результаты исследований, полученные сторонними исследователями, как в отношении ОО, так и в отношении программных продуктов, аналогичных по архитектуре исследуемому ОО.
-
В ходе исследований оцениваются исходные данные согласно пункту 3.1 и пункту 2.3 настоящей Методики на соответствие требованиям проводимого исследования в целях использования в исследованиях ОО результатов, полученных разработчиком:а) перечни программных компонентов и иные результаты композиционного анализа в части поиска известных уязвимостей заимствованных компонентов в составе ОО (в том числе в составе образов контейнеров) в публично доступных базах уязвимостей;б) результаты автоматизированного анализа конфигурации ОО и составляющих ОО отдельных модулей, направленного на выявление уязвимостей конфигурации ОО, применение для контроля настроек ОО инструментальных средства анализа конфигураций при наличии таковых средств;в) учет в архитектуре ОО требований безопасности, результатов композиционного анализа и анализа конфигураций.
-
Проводится оценка соответствия конфигураций запуска отдельных контейнеров и групп (сетей) контейнеров, составляющих ОО в контейнерном исполнении, публично доступным рекомендациям по безопасности и минимизации полномочий (например, рекомендации ФСТЭК России, CIS, Kubernetes Security Best Practices и другие рекомендации), в том числе:а) для ОО в контейнерном исполнении обеспечивается запуск контейнеров с полномочиями, минимально необходимыми для функционирования ОО, на уровне процессов хостовой операционной системы;б) для ОО в контейнерном исполнении, находящегося под управлением оркестратора контейнеров, обеспечивается в соответствии с заданными разработчиком средства правилами управление доступом между компонентами ОО (контейнерами, микросервисами, иными ресурсами, характерными для выбранного типа оркестратора), компонентами среды функционирования, внешними по отношению к ОО компонентами в соответствии с пунктом 2.3 настоящей Методики.Избыточные полномочия компонентов ОО и избыточные разрешающие правила доступа к компонентам ОО рассматриваются в качестве недостатков безопасности ОО.
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.