Вопрос: Требования к безопасной разработке ПО ЗОКИИ (п. 29.3 приказа ФСТЭК России № 239): существует ли нормативно-методическая база, стандарты по безопасной разработке ПО, оценке выполнения требований к безопасной разработке в рамках п. 29.4?
Ответ: Ответ: существует ряд стандартов и методических документов, устанавливающих требования к безопасной разработке программного обеспечения (далее – ПО) и смежным направлениям:
  
  		  ГОСТ Р ИСО/МЭК 15408-1-2012 «Критерии оценки безопасности информационных технологий. Введение и общая модель», 
  		 ГОСТ Р ИСО/МЭК 15408-2-2013 «Критерии оценки безопасности информационных технологий. Функциональные компоненты безопасности», ГОСТ Р ИСО/МЭК 15408-3-2013 «Критерии оценки безопасности информационных технологий. Компоненты доверия 
  		 к безопасности» - в части основных понятий и требований, а также терминологии в области обеспечения безопасности ПО;
  	
  		 ГОСТ Р ИСО/МЭК 12207-2010 «Системная и программная инженерия. Процессы жизненного цикла программных средств» - 
  		 в части требований, предъявляемых к организации процесса жизненного цикла разработки ПО, и типовых процессов;
  	
  		 ГОСТ Р 56939-2016 «Разработка безопасного программного обеспечения. Общие требования» - в части мер по разработке безопасного ПО;
  	
  		 ГОСТ Р 58412-2019 «Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения» - в части анализа угроз безопасности, которые могут возникнуть в процессе разработки ПО.
  	
  	 Также рекомендуется использовать методические документы и нормативные правовые акты, утвержденные контролирующими органами в соответствии с зонами их ответственности и устанавливающие требования по безопасности программных средств:
  
  		 Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий, утвержденные приказом ФСТЭК России от 02.06.2020 № 76.
  	
  		 Требования по безопасности информации к средствам виртуализации, утвержденные приказом ФСТЭК России от 27.10.2022 № 187.
  	
  		 Требования по безопасности информации к средствам контейнеризации, утвержденные приказом ФСТЭК России от 04.07.2022 № 118.
  	
  		 Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении, утвержденная ФСТЭК России от 25.12.2020.
  	
  		 Профили защиты операционных систем, утвержденные ФСТЭК России и ранжированные по классам защиты.
  	
  		  Профиль защиты прикладного ПО автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций, утвержденный Центральным банком Российской Федерации.
  	
  	 Стоит отметить, что на 2023 год техническим комитетом
  	 по стандартизации «Защита информации» (ТК362) запланированы работы
  	 по формированию проектов национальных стандартов по разработке безопасного ПО и смежным направлениям. В частности, планируется разработка и актуализация следующих проектов национальных стандартов:
  
  		 ГОСТ Р «Защита информации. Разработка безопасного программного обеспечения. Руководство по оценке безопасности разработки программного обеспечения».
  	
  		 ОСТ Р «Защита информации. Разработка безопасного программного обеспечения. Руководство по проведению статического анализа программного обеспечения».
  	
  		 ГОСТ Р «Защита информации. Разработка безопасного программного обеспечения. Доверенный компилятор языков Си/Си++. Общие требования».
  	
  		 ГОСТ Р «Информационная технология. Методология разработки доверенных систем. Конструктивная информационная безопасность».
  	
  		 ГОСТ Р «Защита информации. Разработка безопасного программного обеспечения. Управление безопасностью программного обеспечения при использовании заимствованных и привлекаемых компонентов».
  	
  		 ГОСТ Р 56939-2016 «Защита информации. Разработка безопасного программного обеспечения. Общие требования».
  	
  		 Стандарты серии ГОСТ Р ИСО/МЭК 15408.
Цитаты из НПА: {"02.06.2020 № 76": ["Разработка документации по безопасной разработке средства, соответствующего 4 уровню доверия, наряду с требованиями, установленными пунктом 15.1 настоящих Требований, должна предусматривать разработку документации по безопасной разработке аппаратной платформы средства, которая должна включать описание организационных и технических мер безопасности, применяемых в среде разработки аппаратной платформы средства для защиты целостности проектной документации и аппаратной платформы средства.", "Проектная (программная) документация средства, соответствующего 6 уровню доверия, должна включать: проект на уровне подсистем средства (эскизный проект); проект на уровне модулей средства (технический проект). Эскизный проект должен включать: описание структуры средства на уровне подсистем средства; описание всех подсистем средства; сопоставление функций средства и интерфейсов, описанных в функциональной спецификации, с подсистемами средства; описание взаимодействия подсистем средства между собой.", "устранение недостатков средства путем доработки средства или его отдельных компонентов, принятие иных мер, снижающих возможность эксплуатации уязвимостей; тестирование (испытания) доработанного средства или его отдельных компонентов на предмет устранения влияния обновлений средства на его функции безопасности, подтверждения устранения уязвимостей, невнесения новых уязвимостей в средство.", "Для дифференциации требований по безопасности информации к средствам устанавливается  6  уровней  доверия. Самый  низкий  уровень  –  шестой,  самый  высокий – первый.", "На средство, соответствующее 6 уровню доверия, должна быть разработана документация по безопасной разработке средства, которая должна включать: описание всех физических, процедурных, организационных и других мер безопасности, применяемых в среде разработки средства для защиты конфиденциальности и целостности проектной документации и реализации средства; применяемые меры безопасности, направленные на снижение вероятности возникновения в средстве уязвимостей и иных недостатков, и их обоснование.", "При проведении тестирования средства проводится оценка влияния на подсистемы средства, реализующие функции безопасности, иных подсистем средства.", "Устранение недостатков средства, соответствующего 5 уровню доверия, наряду с требованиями, установленными пунктом 22.1 настоящих Требований, должно предусматривать: разработку компенсирующих мер по защите информации или ограничений по применению средства, а также доведение информации о недостатках и указанных мерах и ограничениях до потребителей не позднее 72 часов с момента выявления недостатка; доработку средства, в том числе разработку обновлений программного обеспечения средства, или разработку мер по защите информации, нейтрализующих недостаток, в срок не более 60 дней с момента выявления недостатка.", "разработку компенсирующих мер по защите информации или ограничений по применению средства, а также доведение информации о таких мерах и ограничениях до потребителей в срок не более 48 часов с момента выявления недостатка; доведение информации о недостатках средства, а также о компенсирующих мерах по защите информации или ограничениях по применению до каждого потребителя сертифицированного средства путем отправки сообщений на электронные адреса потребителей или за счет применения компонента средства, обеспечивающего доведение указанной информации до потребителя автоматически.", "Разработка функциональной спецификации средства, соответствующего 6 уровню доверия, должна предусматривать: разработку описания назначения и способов использования каждого интерфейса функций безопасности; идентификацию параметров, связанных с каждым интерфейсом функций безопасности; идентификацию интерфейсов средства, не влияющих на функции безопасности средства.", "Средство должно обеспечиваться поддержкой безопасности средства, предусматривающей: 1) устранение недостатков и дефектов средства, в том числе устранение уязвимостей и недекларированных возможностей средства (далее – устранение недостатков средства); 2) информирование потребителей об обновлении программного обеспечения средства и доведение до потребителей обновлений программного обеспечения средства, а также изменений в эксплуатационную документацию (далее – обновление средства); 3) документирование процедур устранения недостатков и обновления средства; 4) информирование об окончании производства и (или) поддержки безопасности средства.", "Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий.", "При проведении сертификации средства защиты информации должно быть подтверждено соответствие средства настоящим Требованиям. Устанавливается следующее соответствие классов средств защиты информации и средств вычислительной техники уровням доверия: средства защиты информации 6 класса должны соответствовать 6 уровню доверия; средства защиты информации 5 класса должны соответствовать 5 уровню доверия; средства защиты информации 4 класса и средства вычислительной техники 5 класса должны соответствовать 4 уровню доверия.", "Настоящие Требования являются обязательными требованиями в области технического регулирования к продукции (работам, услугам), используемой в целях защиты сведений, составляющих государственную тайну или относимых к охраняемой в соответствии с законодательством Российской Федерации иной информации ограниченного доступа (далее – требования по безопасности информации), применяются к программным и программно-техническим средствам технической защиты информации, средствам обеспечения безопасности информационных технологий, включая защищенные средства обработки информации (далее – средства), и устанавливают уровни, характеризующие безопасность применения средств для обработки и защиты информации, содержащей сведения, составляющие государственную тайну, иной информации ограниченного доступа, а также для обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации (далее – уровни доверия)."], "27.10.2022 № 187": ["9. К доверенной загрузке виртуальных машин предъявляются следующие требования:", "9.1. Средство виртуализации 6, 5 классов защиты должно блокировать запуск виртуальной машины при выявлении нарушения целостности конфигурации виртуального оборудования данной виртуальной машины. 9.2. Средство виртуализации 4 класса защиты наряду с требованиями, установленными подпунктом 9.1 пункта 9 настоящих Требований, дополнительно должно блокировать запуск виртуальной машины при выявлении нарушения целостности файлов виртуальной базовой системы ввода-вывода (первичного загрузчика виртуальной машины) и (или) исполняемых файлов гостевой операционной системы.", "10.3. Средство виртуализации 4 класса защиты наряду с требованиями, установленными подпунктами 10.1 и 10.2 пункта 10 настоящих Требований, дополнительно должно обеспечивать целостность сведений о событиях безопасности. 11. К регистрации событий безопасности в средстве виртуализации предъявляются следующие требования: 11.1. Средство виртуализации 6, 5 классов защиты должно: обеспечивать регистрацию событий безопасности, связанных с функционированием средства виртуализации; оповещать администратора безопасности средства виртуализации о событиях безопасности; выполнять действия, являющиеся реакцией на события безопасности самостоятельно или с применением сертифицированных средств защиты информации; осуществлять сбор и хранение записей в журнале событий безопасности, которые позволяют определить, когда и какие действия происходили.", "12. В средстве виртуализации 6, 5, 4 класса защиты должен быть реализован ролевой метод управления доступом с четырьмя ролями пользователей: разработчик виртуальной машины, администратор безопасности средства виртуализации, администратор средства виртуализации, администратор виртуальной машины.", "Настоящие Требования применяются к средствам виртуализации, реализующим функциональные возможности по созданию образов виртуальных машин, формированию среды выполнения виртуальных машин, запуску виртуальных машин и управлению ими, по идентификации и аутентификации пользователей в средстве виртуализации и централизованному управлению образами виртуальных машин, виртуальными машинами и организацией взаимодействия между виртуальными машинами.", "Средство виртуализации 6 класса защиты должно: контролировать целостность в процессе загрузки и динамически в процессе функционирования средства виртуализации объектов контроля самостоятельно или с применением сертифицированных хостовой операционной системы или средства доверенной загрузки; информировать администратора безопасности средства виртуализации о нарушении целостности объектов контроля; контролировать целостность конфигурации виртуального оборудования виртуальных машин.", "В случае функционирования средства виртуализации в среде хостовой операционной системы, хостовая операционная система должна быть сертифицирована на соответствие Требованиям в области технического регулирования к продукции, используемой в целях защиты сведений, составляющих государственную тайну или относимых к охраняемой в соответствии с законодательством Российской Федерации иной информации ограниченного доступа (требованиям безопасности информации к операционным системам), утвержденным приказом ФСТЭК России от 19 августа 2016 г.", "15. Средство виртуализации 6, 5, 4 классов защиты должно обеспечивать управление потоками информации между виртуальными машинами и информационными (автоматизированными) системами на канальном и сетевом уровнях самостоятельно или с применением сертифицированных средств управления потоками информации (коммутаторов, маршрутизаторов) и (или) межсетевых экранов, а также контроль взаимодействия виртуальных машин между собой.", "4. Для дифференциации требований по безопасности информации к средствам виртуализации устанавливается 6 классов защиты.", "Средство виртуализации 6, 5, 4 классов защиты должно: очищать остаточную информацию в памяти средства вычислительной техники при ее освобождении (распределении) или блокирование доступа субъектов к остаточной информации; удалять объекты файловой системы, используемые средством виртуализации, путем перезаписи уничтожаемых (стираемых) объектов файловой системы случайной битовой последовательностью; размещать код средства виртуализации в области памяти, не доступной одновременно для записи и исполнения; изолировать области памяти виртуальных машин.", "Устанавливается следующее соответствие классов защиты средств виртуализации уровням доверия: средства виртуализации 6 класса защиты должны соответствовать 6 уровню доверия; средства виртуализации 5 класса защиты должны соответствовать 5 уровню доверия; средства виртуализации 4 класса защиты должны соответствовать 4 уровню доверия.", "Выполнение настоящих Требований является обязательным при проведении работ по оценке соответствия (включая работы по сертификации) средств технической защиты информации и средств обеспечения безопасности информационных технологий, организуемых ФСТЭК России в пределах своих полномочий в соответствии с Положением о системе сертификации средств защиты информации, утвержденным приказом ФСТЭК России от 3 апреля 2018 г."], "04.07.2022 № 118": ["Средство контейнеризации 6 класса защиты должно функционировать в среде хостовой операционной системы, соответствующей 6 классу защиты и 6 уровню доверия.", "Устанавливается следующее соответствие классов защиты средств контейнеризации уровням доверия: средства контейнеризации 6 класса защиты должны соответствовать 6 уровню доверия; средства контейнеризации 5 класса защиты должны соответствовать 5 уровню доверия; средства контейнеризации 4 класса защиты должны соответствовать 4 уровню доверия;", "Средство контейнеризации 5 и 4 классов защиты наряду с требованиями, установленными подпунктом 10.1 пункта 10 настоящих Требований, должно запрещать создание образов контейнеров, содержащих известные уязвимости критического и высокого уровня опасности. Средство контейнеризации 5 и 4 классов защиты должно осуществлять выявление известных уязвимостей образов контейнеров не реже одного раза в неделю.", "Средство контейнеризации 6 класса защиты должно: выявлять известные уязвимости при создании, установке образа контейнера в информационной (автоматизированной) системе и хранении образов контейнеров во взаимодействии с сертифицированным средством контроля и анализа защищенности на основе сведений, содержащихся в банке данных угроз безопасности информации, ведение которого осуществляется ФСТЭК России в соответствии с подпунктом 21 пункта 8 Положения о Федеральной службе по техническому и экспортному контролю.", "Средство контейнеризации 6 класса защиты должно осуществлять выявление известных уязвимостей образов контейнеров не реже одного раза в месяц.", "Средство контейнеризации 6 класса защиты должно: регистрировать события, относящиеся к инцидентам безопасности средства контейнеризации, связанные с попытками осуществления несанкционированного доступа к средству контейнеризации; оповещать администратора безопасности средства контейнеризации и администратора информационной (автоматизированной) системы об инцидентах безопасности; выполнять действия, являющиеся реакцией на инциденты безопасности; осуществлять сбор и хранение записей в журнале событий безопасности, которые позволяют определить, когда и какие действия происходили.", "Настоящие Требования применяются к средствам контейнеризации, реализующим функциональные возможности по созданию образов контейнеров, формированию среды выполнения контейнеров и обеспечения выполнения их процессов, запуску контейнера и управление данным контейнером, а также дополнительные функциональные возможности по централизованному управлению контейнерами, организации взаимодействия между ними и распространению образов контейнеров.", "Средство контейнеризации 6 класса защиты должно: контролировать самостоятельно или с применением средств контроля целостности хостовой операционной системы и иных сертифицированных средств защиты информации целостность образов контейнеров и исполняемых файлов контейнеров; информировать администратора информационной (автоматизированной) системы и администратора безопасности средства контейнеризации о нарушении целостности объектов контроля.", "Хостовая операционная система, в среде которой функционирует средство контейнеризации, должна быть сертифицирована на соответствие Требованиям в области технического регулирования к продукции, используемой в целях защиты сведений, составляющих государственную тайну или относимых к охраняемой в соответствии с законодательством Российской Федерации иной информации ограниченного доступа (требованиям безопасности информации к операционным системам), утвержденным приказом ФСТЭК России от 19 августа 2016 г."]}
full_text: {"02.06.2020 № 76": "УТВЕРЖДЕНЫ\nприказом ФСТЭК России\nот 2 июня 2020 г. № 76\nТребования по безопасности информации, устанавливающие уровни доверия к\nсредствам технической защиты информации и средствам обеспечения\nбезопасности информационных технологий\n(выписка)\nI. Общие положения\n1. Настоящие Требования являются обязательными требованиями в области\nтехнического регулирования к продукции (работам, услугам), используемой в целях\nзащиты  сведений,  составляющих  государственную  тайну  или  относимых  к\nохраняемой  в  соответствии  с  законодательством  Российской  Федерации  иной\nинформации  ограниченного  доступа  (далее  –  требования  по  безопасности\nинформации), применяются к программным и программно-техническим средствам\nтехнической  защиты  информации,\nсредствам  обеспечения  безопасности\nинформационных  технологий,  включая  защищенные  средства  обработки\nинформации  (далее  – средства),  и  устанавливают  уровни,  характеризующие\nбезопасность  применения  средств  для  обработки  и  защиты  информации,\nсодержащей сведения, составляющие государственную  тайну, иной информации\nограниченного доступа, а также для обеспечения безопасности значимых объектов\nкритической  информационной  инфраструктуры  Российской  Федерации  (далее  –\nуровни доверия). 2. Настоящие  Требования  разработаны  в  соответствии  с  постановлением\nПравительства Российской Федерации от 26 июня 1995 г. № 608 «О сертификации\nсредств защиты информации» (Собрание законодательства Российской Федерации,\n1995,  № 27,  ст. 2579;  2010,  № 18,  ст. 2238),  постановлением  Правительства\nРоссийской  Федерации  от  15  мая  2010  г. № 330  «Об  особенностях  оценки\nсоответствия продукции (работ, услуг), используемой в целях защиты сведений,\nотносимых  к  охраняемой  в  соответствии  с  законодательством  Российской\nФедерации  информации  ограниченного  доступа,  не  содержащей  сведения,\nсоставляющие  государственную  тайну,  а  также  процессов  ее  проектирования\n(включая  изыскания),  производства,  строительства,  монтажа,  наладки,\nэксплуатации,  хранения,  перевозки,  реализации,  утилизации  и  захоронения»,\nприказом ФСТЭК России от 3 апреля 2018 г. № 55 «Об утверждении Положения о\nсистеме сертификации средств защиты информации» (зарегистрирован Минюстом\nРоссии 11 мая 2018 г., регистрационный № 51063; официальный интернет-портал\nправовой информации http://www.pravo.gov.ru, 14 мая 2018 г.). 3. Выполнение настоящих Требований является обязательным при проведении\nработ  по  оценке  соответствия  (включая  работы  по  сертификации) средств\nтехнической  защиты  информации  и  средств\nобеспечения  безопасности\n2\nинформационных  технологий,  организуемых  ФСТЭК  России  в  пределах  своих\nполномочий в соответствии с Положением о системе сертификации средств защиты\nинформации, утвержденным приказом ФСТЭК России от 3 апреля 2018 г. № 55 «Об\nутверждении Положения о системе сертификации средств защиты информации». II. Общие требования по безопасности информации\n4. Для дифференциации требований по безопасности информации к средствам\nустанавливается  6  уровней  доверия. Самый  низкий  уровень  –  шестой,  самый\nвысокий – первый. Средства,  соответствующие  6  уровню  доверия,  применяются  в  значимых\nобъектах  критической  информационной  инфраструктуры  3  категории1,  в\nгосударственных  информационных  системах  3  класса  защищенности**,  в\nавтоматизированных системах управления производственными и технологическими\nпроцессами 3 класса защищенности***, в информационных системах персональных\nданных при необходимости обеспечения 3 и 4 уровня защищенности персональных\nданных****. Средства,  соответствующие  5  уровню  доверия,  применяются  в  значимых\nобъектах  критической  информационной  инфраструктуры  2  категории*,  в\nгосударственных  информационных  системах  2  класса  защищенности**,  в\nавтоматизированных системах управления производственными и технологическими\nпроцессами 2 класса защищенности***, в информационных системах персональных\nданных  при необходимости  обеспечения  2 уровня  защищенности персональных\nданных****. Средства,  соответствующие  4  уровню  доверия,  применяются  в  значимых\nобъектах  критической  информационной  инфраструктуры  1  категории*,  в\nгосударственных  информационных  системах  1  класса  защищенности**,  в\nавтоматизированных системах управления производственными и технологическими\nпроцессами 1 класса защищенности***, в информационных системах персональных\n1 Cтатья 7 Федерального закона от 26 июля 2017 г. № 187-ФЗ «О безопасности критической информационной инфраструктуры\nРоссийской  Федерации»  (Собрание  законодательства  Российской  Федерации,  2017,  № 31,  ст. 4736), Правила  категорирования\nобъектов  критической  информационной  инфраструктуры  Российской  Федерации,  а  также  перечень  показателей  критериев\nзначимости  объектов  критической  информационной  инфраструктуры  Российской  Федерации,  утвержденные  постановлением\nПравительства Российской Федерации от 8 февраля 2018 г. № 127 (Собрание законодательства Российской Федерации, 2018, № 8,\nст. 1204; 2019, № 16, ст. 1955). **** Требования  о  защите  информации,  не  составляющей  государственную  тайну,  содержащейся  в  государственных\nинформационных  системах, утвержденные приказом ФСТЭК России от 11 февраля 2013 г. № 17 (зарегистрирован Минюстом\nРоссии 31 мая 2013 г., регистрационный № 28608) (с изменениями, внесенными приказом ФСТЭК России от 15 февраля 2017 г. № 27 (зарегистрирован Минюстом России 14 марта 2017 г., регистрационный № 45933) и приказом ФСТЭК России от 28 мая 2019\nг. № 106 (зарегистрирован Минюстом России 13 сентября 2019 г., регистрационный № 55924). ****** Требования  к  обеспечению  защиты  информации  в  автоматизированных  системах  управления  производственными  и\nтехнологическими  процессами  на  критически  важных  объектах,  потенциально  опасных  объектах,  а  также  объектах,\nпредставляющих  повышенную  опасность для жизни и здоровья  людей и для окружающей природной среды, утвержденные\nприказом ФСТЭК  России  от 14 марта 2014 г. № 31 (зарегистрирован  Минюстом  России 30 июня  2014 г., регистрационный\n№ 32919) (с изменениями, внесенными приказом ФСТЭК России от 23 марта 2017 г. № 49 (зарегистрирован Минюстом России\n30 июня 2017 г., регистрационный № 32919) и приказом ФСТЭК России от 9 августа 2018 г. № 138 (зарегистрирован Минюстом\nРоссии 5 сентября 2018 г., регистрационный № 52071). ******** Требования  к защите  персональных  данных  при  их  обработке  в информационных  системах  персональных  данных,\nутвержденные  постановлением  Правительства  Российской  Федерации  от  1 ноября 2012 г. № 1119  (Собрание законодательства\nРоссийской Федерации, 2012, № 45, ст. 6257). 3\nданных  при необходимости  обеспечения  1 уровня  защищенности персональных\nданных****, в информационных системах общего пользования II класса 2*****. 5. При проведении сертификации средства защиты информации должно быть\nподтверждено соответствие средства настоящим Требованиям. Устанавливается  следующее  соответствие  классов  средств  защиты\nинформации и средств вычислительной техники уровням доверия:\nсредства защиты информации 6 класса должны соответствовать 6 уровню\nдоверия;\nсредства защиты информации 5 класса должны соответствовать 5 уровню\nдоверия;\nсредства защиты информации 4 класса и средства вычислительной техники\n5 класса должны соответствовать 4 уровню доверия. 6. Средство  соответствует  уровню  доверия,  если  оно  удовлетворяет\nтребованиям  к  разработке  и  производству  средства,  проведению  испытаний\nсредства, поддержке безопасности средства, приведенным в таблице 1. Таблица 1\n№\nп/п\nНаименование требования к уровню доверия\nУровень доверия\n6\n5\n4\n1. Требования к разработке и производству средства:\n1.1. требования к разработке модели безопасности\nсредства\n+\n1.2. требования к проектированию архитектуры\nбезопасности средства\n+\n=\n=\n1.3. требования к разработке функциональной\nспецификации средства\n+\n+\n+\n1.4. требования к проектированию средства\n+\n=\n=\n1.5. требования к разработке проектной (программной)\n+\n+\n+\n2* Cтатья 7 Федерального закона от 26 июля 2017 г. № 187-ФЗ «О безопасности критической информационной инфраструктуры\nРоссийской  Федерации»  (Собрание  законодательства  Российской  Федерации,  2017,  № 31,  ст. 4736), Правила  категорирования\nобъектов  критической  информационной  инфраструктуры  Российской  Федерации,  а  также  перечень  показателей  критериев\nзначимости  объектов  критической  информационной  инфраструктуры  Российской  Федерации,  утвержденные  постановлением\nПравительства Российской Федерации от 8 февраля 2018 г. № 127 (Собрание законодательства Российской Федерации, 2018, № 8,\nст. 1204; 2019, № 16, ст. 1955). ** Требования  о  защите  информации,  не  составляющей  государственную  тайну,  содержащейся  в  государственных\nинформационных  системах, утвержденные приказом ФСТЭК России от 11 февраля 2013 г. № 17 (зарегистрирован Минюстом\nРоссии 31 мая 2013 г., регистрационный № 28608) (с изменениями, внесенными приказом ФСТЭК России от 15 февраля 2017 г. № 27 (зарегистрирован Минюстом России 14 марта 2017 г., регистрационный № 45933) и приказом ФСТЭК России от 28 мая 2019\nг. № 106 (зарегистрирован Минюстом России 13 сентября 2019 г., регистрационный № 55924). *** Требования  к  обеспечению  защиты  информации  в  автоматизированных  системах  управления  производственными  и\nтехнологическими  процессами  на  критически  важных  объектах,  потенциально  опасных  объектах,  а  также  объектах,\nпредставляющих  повышенную  опасность для жизни и здоровья  людей и для окружающей природной среды, утвержденные\nприказом ФСТЭК  России  от 14 марта 2014 г. № 31 (зарегистрирован  Минюстом  России 30 июня  2014 г., регистрационный\n№ 32919) (с изменениями, внесенными приказом ФСТЭК России от 23 марта 2017 г. № 49 (зарегистрирован Минюстом России\n30 июня 2017 г., регистрационный № 32919) и приказом ФСТЭК России от 9 августа 2018 г. № 138 (зарегистрирован Минюстом\nРоссии 5 сентября 2018 г., регистрационный № 52071). **** Требования  к  защите  персональных  данных  при  их  обработке  в  информационных  системах  персональных  данных,\nутвержденные  постановлением  Правительства  Российской  Федерации  от  1 ноября 2012 г. № 1119  (Собрание законодательства\nРоссийской Федерации, 2012, № 45, ст. 6257). ***** Требования о защите информации, содержащейся в информационных системах общего пользования, утвержденные приказом\nФСБ  России  и  ФСТЭК  России  от  31 августа 2010 г. № 416/489  (зарегистрирован  Минюстом  России  13  октября  2010  г.,\nрегистрационный № 18704). 4\nдокументации\n1.6. требования к средствам разработки, применяемым для\nсоздания средства\n+\n=\n=\n1.7. требования к управлению конфигурацией средства\n+\n+\n+\n1.8. требования к разработке документации по безопасной\nразработке средства\n+\n=\n+\n1.9. требования к разработке эксплуатационной\nдокументации\n+\n=\n=\n2. Требования к проведению испытаний средства:\n2.1. требования к тестированию средства\n+\n+\n+\n2.2. требования к испытаниям по выявлению уязвимостей\nи недекларированных возможностей средства\n+\n+\n+\n2.3. требования к проведению анализа скрытых каналов в\nсредстве\n+\n3. Требования к поддержке безопасности средства:\n3.1. требования к устранению недостатков средства\n+\n+\n+\n3.2. требования к обновлению средства\n+\n+\n+\n3.3. требования к документированию процедур устранения\nнедостатков и обновления средства\n+\n=\n=\n3.4. требования  к  информированию  об  окончании\nпроизводства  и  (или)  поддержки  безопасности\nсредства\n+\n=\n=\nОбозначение «+» в строке требования к уровню доверия указывает на наличие\nтребований, предъявляемых к соответствующему уровню доверия. Обозначение «=» означает, что требования к уровню доверия совпадают с\nтребованиями, предъявляемыми к предыдущему уровню доверия. Отсутствие  обозначения  «+»  или «=» означает,  что  требования  к уровню\nдоверия не предъявляются. III. Требования к разработке и производству средства\n7. При  разработке  средства  разработчиком  должны  быть  выполнены\nпроцедуры, предусматривающие:\n1) разработку модели безопасности средства;\n2) проектирование архитектуры безопасности средства;\n3) разработку функциональной спецификации средства;\n4) проектирование средства;\n5) разработку проектной (программной) документации;\n6) выбор средств разработки, применяемых для создания средства;\n7) управление конфигурацией средства;\n8) разработку документации по безопасной разработке средства;\n9) разработку эксплуатационной документации. 8. К  разработке  модели  безопасности  средства  предъявляются  следующие\nтребования:\n5\n8.1. Требования\nк  разработке\nмодели  безопасности\nсредства,\nсоответствующего 6 и 5 уровням доверия, не предъявляются. 8.2. При  разработке  модели  безопасности  средства,  соответствующего  4\nуровню доверия, должны быть указаны следующие сведения:\nреализуемые  политики  управления  доступом  (для  средств,  в  которых\nпредусмотрена функция разграничения доступа);\nреализуемые политики фильтрации информационных потоков (для средств, в\nкоторых предусмотрена функция фильтрации информационных потоков). Модель безопасности средства, соответствующего 4 уровню доверия, должна\nвключать  описание  условий  безопасности,  выполнение  которых  указывает  на\nреализацию  политик. Выполнение  условий  безопасности  должно  быть  доказано\nформальным (математическим) способом. Для условий безопасности неформально\n(нематематически)  должна  быть  показана  их  взаимосвязь  с  режимами\nфункционирования  средства. Язык  описания  модели  безопасности  должен  быть\nматематическим  или формализованным  (машиночитаемым)  и допускать полную\nнезависимую от разработчика модели проверку корректности её описания, заданных\nв ней условий безопасности, а также всех выполненных в модели доказательств. 9. К  проектированию  архитектуры  безопасности  средства  предъявляются\nследующие требования:\n9.1. Архитектура безопасности средства, соответствующего 6 уровню доверия,\nдолжна обеспечивать:\nневозможность обхода функций безопасности средства;\nзащиту функций безопасности средства от несанкционированного доступа к\nним. На средство должно быть разработано описание архитектуры безопасности\nсредства с обоснованием:\nбезопасности процесса инициализации средства;\nобеспечения собственной защиты средства от несанкционированного доступа;\nневозможности обхода функций безопасности средства. 9.2. Требования  к  проектированию  архитектуры  безопасности  средства,\nсоответствующего  5  и  4  уровням  доверия,  соответствуют  требованиям  к\nпроектированию архитектуры безопасности средства, соответствующего 6 уровню\nдоверия. 10. К  разработке  функциональной  спецификации  средства  предъявляются\nследующие требования:\n10.1. Разработка функциональной спецификации средства, соответствующего\n6 уровню доверия, должна предусматривать:\nразработку  описания  назначения  и  способов  использования  каждого\nинтерфейса функций безопасности;\nидентификацию  параметров,  связанных  с  каждым  интерфейсом  функций\nбезопасности;\nидентификацию  интерфейсов  средства,  не  влияющих  на  функции\nбезопасности средства. 6\nФункциональная спецификация средства должна включать:\nперечень  всех  функций  средства,  включая  функции  безопасности,\nреализуемые программным обеспечением и аппаратной платформой средства;\nописание назначения и способов использования каждого интерфейса функций\nбезопасности и иных функций средства;\nописание  параметров,  связанных  с  каждым  интерфейсом  функций\nбезопасности и иных функций средства;\nперечень интерфейсов, не влияющих на функции безопасности средства. Функциональная  спецификация  аппаратной  платформы  средства  должна\nвключать  описание  назначения  и  способов  использования  каждого  интерфейса\nаппаратной платформы средства. 10.2. При\nразработке\nфункциональной\nспецификации\nсредства,\nсоответствующего  5  уровню  доверия,  наряду  с  требованиями,  установленными\nпунктом 10.1 настоящих Требований, должны быть разработаны и включены в\nспецификацию описания:\nдействий с каждым интерфейсом функций безопасности;\nсообщений  о  возможных  ошибках,  связанных  с  выполнением  функций\nбезопасности. 10.3. При\nразработке\nфункциональной\nспецификации\nсредства,\nсоответствующего  4  уровню  доверия,  наряду  с  требованиями,  установленными\nпунктами 10.1 и 10.2 настоящих Требований, должны быть разработаны и включены\nв спецификацию описания:\nдействий с каждым интерфейсом функций безопасности, не влияющим на\nвыполнение требований, предъявляемых к средству;\nсообщений об ошибках, которые могут возникнуть при выполнении функций\nбезопасности и вызове каждого интерфейса функций безопасности;\nпараметров,  связанных  с  каждым  интерфейсом  функций  безопасности\nаппаратной платформы средства;\nинтерфейсов, не влияющих на функции безопасности аппаратной платформы\nсредства;\nвсех функций безопасности, реализуемых аппаратной платформой средства. 11. К проектированию средства предъявляются следующие требования:\n11.1. Проектирование средства, соответствующего 6 уровню доверия, должно\nпредусматривать:\nопределение  перечня  подсистем,  реализующих  функции  безопасности\nсредства;\nопределение  перечня  подсистем,  поддерживающих  выполнение  функций\nбезопасности;\nопределение  перечня  подсистем,  не  влияющих  на  выполнение  функций\nбезопасности;\nпроектирование подсистем, реализующих функции безопасности средства;\nпроектирование иных подсистем  таким  образом,  чтобы  они не оказывали\nвлияния на выполнение функций безопасности средства;\n7\nопределение  способов  взаимодействия  подсистем,  реализующих  функции\nбезопасности, с иными подсистемами, обеспечивающих невозможность влияния на\nвыполнение функций безопасности средства;\nопределение  и  проектирование  для  каждой  подсистемы,  реализующей\nфункции безопасности, перечня входящих в ее состав модулей, осуществляющих\nвыполнение функций безопасности;\nопределение  способов  взаимодействия  модулей,  осуществляющих\nвыполнение  функций  безопасности,  с  иными  модулями,  обеспечивающих\nневозможность влияния на выполнение функций безопасности средства. 11.2. Требования  к  проектированию  средства,  соответствующего  5  и  4\nуровням  доверия,  соответствуют  требованиям  к  проектированию  средства,\nсоответствующего 6 уровню доверия. 12. К  разработке  проектной  (программной)  документации  средства\nпредъявляются следующие требования:\n12.1. Проектная (программная) документация средства, соответствующего 6\nуровню доверия, должна включать:\nпроект на уровне подсистем средства (эскизный проект);\nпроект на уровне модулей средства (технический проект). Эскизный проект должен включать:\nописание структуры средства на уровне подсистем средства;\nописание всех подсистем средства;\nсопоставление  функций  средства  и  интерфейсов,  описанных  в\nфункциональной спецификации, с подсистемами средства;\nописание взаимодействия подсистем средства между собой. Технический проект должен включать:\nописание структуры средства на уровне модулей;\nописание  всех  модулей  средства  (для  модулей  средства,  реализующих\nфункции безопасности, – описание интерфейсов, возвращаемых ими в ответ на\nзапросы  значений,  взаимодействий  с  другими  модулями  и  вызываемыми\nинтерфейсами этих модулей; для модулей средства, не влияющих на выполнение\nфункций  безопасности,  –  описание  назначения  и  взаимодействия  с  другими\nмодулями);\nсопоставление  подсистем  средства,  описанных  в  эскизном  проекте,  с\nмодулями. Положения  эскизного  и технического  проектов могут быть  объединены  в\nодном документе. Для аппаратной платформы средства должен быть разработан (представлен)\nперечень  аппаратных  устройств  (микросхем),  которые  влияют  на  выполнение\nфункций безопасности  и (или)  могут  быть  использованы для реализации угроз\nбезопасности информации. 12.2. Проектная (программная) документация средства, соответствующего 5\nуровню доверия, наряду с требованиями, установленными пунктом 12.1 настоящих\nТребований, должна включать:\n8\nдля аппаратной платформы средства – структурную и функциональную схемы\nаппаратной платформы средства;\nдля  программного  обеспечения  –  исходные  тексты  программного\nобеспечения, входящего в состав средства, с указанием значений контрольных сумм\nфайлов  с  исходными  текстами  программного  обеспечения,  за  исключением\nпрограммного  обеспечения,  заимствованного  у  сторонних  изготовителей,  не\nреализующего  функции  безопасности  и  не  влияющего  на  реализацию  функций\nбезопасности. Документация на средство должна содержать информацию о соответствии\nуказанных сведений модулям, описанным в проектной документации. В  случае  отсутствия  сведений  о  заимствованных  компонентах  средства\nдолжны быть спроектированы, реализованы и описаны в документации на средство\nмеры  защиты  информации,  направленные  на  блокирование  эксплуатации\nвозможных  уязвимостей  и  реализуемых  заимствованными  элементами\n(компонентами) потенциально опасных возможностей. Отсутствующие сведения о заимствованных компонентах средства могут быть\nполучены  путем  использования  методов  обратной  разработки  (реверс-\nинжиниринга). Способы  и  методы  получения  отсутствующих  сведений  о\nзаимствованных элементах должны быть описаны в документации на средство,\nпредставляемой  на  испытания,  и  могут  быть  использованы  при  проведении\nиспытаний. Сведения  об  аппаратной  платформе  средства  должны  быть  включены  в\nединый реестр российской радиоэлектронной продукции. 12.3. Проектная (программная) документация средства, соответствующего 4\nуровню доверия, наряду с требованиями, установленными пунктами 12.1 и 12.2\nнастоящих Требований, для аппаратной платформы средства должна включать:\nструктурные  и  функциональные  схемы,  техническую  документацию\nаппаратных средств, входящих в аппаратную платформу;\nпредставление (код) на языке описания аппаратных средств;\nописание потенциально опасных элементов (компонентов), входящих в состав\nаппаратной  платформы  средства,  которые  влияют  на  выполнение  функций\nбезопасности и (или) могут быть использованы для реализации угроз безопасности\nинформации. Сведения  о  процессорах  или  микросхемах,  выполняющих  функции\nпроцессоров (микроконтроллеры), элементах памяти, сетевых картах, графических\nадаптерах аппаратной платформы средства должны быть включены в единый реестр\nроссийской радиоэлектронной продукции. 13. К  средствам  разработки,  применяемым  для  создания  средства,\nпредъявляются следующие требования:\nПравила  формирования  и  ведения  единого  реестра  российской  радиоэлектронной  продукции  утверждены  постановлением\nПравительства Российской Федерации от 10 июля 2019 г. № 878  (Собрание законодательства Российской Федерации, 2019, № 29,\nст. 4023; № 29, ст. 4023). 9\n13.1. На выбранные средства разработки, применяемые для создания средства,\nсоответствующего  6  уровню  доверия,  должна  быть  разработана  документация,\nвключающая описания:\nсредств разработки, применяемых для создания средства;\nиспользованных  опций  средств  разработки,  применяемых  для  создания\nсредства. 13.2. Требования  к  средствам  разработки,  применяемым  для  создания\nсредства, соответствующего 5 и 4 уровням доверия, соответствуют требованиям к\nсредствам разработки, применяемым для создания средства, соответствующего 6\nуровню доверия. 14. К  управлению  конфигурацией  средства  предъявляются  следующие\nтребования:\n14.1. Управление  конфигурацией  средства,  соответствующего  6  уровню\nдоверия,  должно  предусматривать  управление  изменениями  средства  и\nдокументации и обеспечение их уникальной маркировки. Документация по управлению конфигурацией средства должна включать:\nописание уникальной маркировки средства;\nсписок  элементов  конфигурации  средства,  включающий  в  том  числе\nдокументацию;\nпорядок управления изменениями средства и документации. 14.2. Управление  конфигурацией  средства,  соответствующего  5  уровню\nдоверия,  наряду  с  требованиями,  установленными  пунктом  14.1  настоящих\nТребований, должно предусматривать:\nуправление изменениями частей (элементов, компонентов) средства;\nобеспечение уникальной идентификации всех элементов конфигурации. Документация по управлению конфигурацией средства дополнительно должна\nвключать:\nописание метода, используемого для уникальной идентификации элементов\nконфигурации;\nописание уникальных идентификаторов всех элементов конфигурации;\nчасти (элементы, компоненты) средства в списке элементов конфигурации. Для  каждого  элемента  конфигурации  в  списке  элементов  конфигурации\nдолжен быть указан разработчик. 14.3. Управление  конфигурацией  средства,  соответствующего  4  уровню\nдоверия, наряду с требованиями, установленными пунктами 14.1 и 14.2 настоящих\nТребований, должно предусматривать:\nуправление  изменениями  средства,  в  том  числе  изменениями  исходных\nтекстов программного обеспечения и аппаратной платформы средства;\nприменение автоматизированных мер контроля, обеспечивающих внесение в\nэлементы конфигурации только санкционированных изменений;\nорганизацию  процедур  приемки  модифицированных  или  вновь  созданных\nэлементов конфигурации. 10\nДокументация по управлению конфигурацией средства дополнительно должна\nвключать:\nсведения о составе средства, в том числе сведения об исходных текстах и\nаппаратной платформе средства, в списке элементов конфигурации;\nописание  автоматизированных  мер  контроля,  которые  применяются  для\nобеспечения  внесения  в  элементы  конфигурации  только  санкционированных\nизменений;\nплан  управления  конфигурацией,  содержащий  описание  процедур,\nиспользуемых для приемки модифицированных или вновь созданных элементов\nконфигурации. Управление  конфигурацией  (настройкой)  аппаратной  платформы  средства\nдолжно  предусматривать  изменение  конфигурации  (настройки)  аппаратной\nплатформы средства, её документации, обеспечение их уникальной маркировки. Документация  по  изменению  конфигурации  (настройки)  аппаратной\nплатформы средства должна включать:\nописание уникальной маркировки аппаратной платформы средства;\nсписок элементов конфигурации (настройки) средства;\nпорядок  управления  изменениями  аппаратной  платформы  средства  и\nдокументации. 15. К  разработке  документации  по  безопасной  разработке  средства\nпредъявляются следующие требования:\n15.1. На  средство,  соответствующее  6  уровню  доверия,  должна  быть\nразработана  документация  по  безопасной  разработке  средства,  которая  должна\nвключать:\nописание  всех  физических,  процедурных,  организационных  и  других  мер\nбезопасности,  применяемых  в  среде  разработки  средства  для  защиты\nконфиденциальности  и  целостности  проектной  документации  и  реализации\nсредства;\nприменяемые  меры  безопасности,  направленные  на  снижение  вероятности\nвозникновения в средстве уязвимостей и иных недостатков, и их обоснование. 15.2. Требования  к  разработке  документации  по  безопасной  разработке\nсредства,  соответствующего  5  уровню  доверия,  соответствуют  требованиям  к\nразработке документации по безопасной разработке средства, соответствующего 6\nуровню доверия. 15.3. Разработка  документации  по  безопасной  разработке  средства,\nсоответствующего  4  уровню  доверия,  наряду  с  требованиями,  установленными\nпунктом  15.1  настоящих  Требований,  должна  предусматривать  разработку\nдокументации по безопасной разработке аппаратной платформы средства, которая\nдолжна  включать  описание  организационных  и  технических  мер  безопасности,\nприменяемых  в  среде  разработки  аппаратной  платформы  средства  для  защиты\nцелостности проектной документации и аппаратной платформы средства. 16. К разработке эксплуатационной документации предъявляются следующие\nтребования:\n11\n16.1. На  средство,  соответствующее  6  уровню  доверия,  включая  его\nаппаратную  платформу,  должна  быть  разработана  следующая  эксплуатационная\nдокументация:\nформуляр средства;\nруководство пользователя средства;\nруководство администратора средства. Формуляр средства должен содержать контрольные суммы дистрибутива и\nисполняемых файлов программного обеспечения, которые должны уточняться при\nобновлении средства в соответствии с настоящими Требованиями, а также состав\nаппаратной платформы средства. Руководство пользователя средства должно содержать описание:\nрежимов работы средства;\nпринципов безопасной работы средства;\nфункций  и  интерфейсов  функций  средства,  доступных  каждой  роли\nпользователей;\nпараметров  (настроек)  безопасности  средства,  доступных  каждой  роли\nпользователей, и их безопасных значений;\nтипов  событий  безопасности,  связанных  с  доступными  пользователю\nфункциями средства;\nдействий после сбоев и ошибок эксплуатации средства. Руководство администратора средства должно содержать описание:\nдействий по приемке поставленного средства;\nдействий по безопасной установке и настройке средства;\nдействий  по  реализации  функций  безопасности  среды  функционирования\nсредства. 16.2. Требования  к  разработке  эксплуатационной  документации  средства,\nсоответствующего 5 и 4 уровням доверия, соответствуют требованиям к разработке\nэксплуатационной документации средства, соответствующего 6 уровню доверия. IV. Требования к проведению испытаний средства\n17. В  отношении  средства  должны  быть  проведены  испытания,\nпредусматривающие:\n1) тестирование средства;\n2) испытания по выявлению уязвимостей и недекларированных возможностей\nсредства;\n3) проведение анализа скрытых каналов в средстве. Тестирование  и  анализ  скрытых  каналов  проводятся  только  для  средств\nзащиты информации. Тестирование, испытания по выявлению уязвимостей и недекларированных\nвозможностей, а также анализ скрытых каналов проводятся изготовителем в ходе\nприемочных  испытаний  средства  и  испытательной  лабораторией  в  ходе\nсертификационных испытаний средства. 12\n18. К тестированию средства предъявляются следующие требования:\n18.1. Тестовая документация на средство, соответствующее 6 уровню доверия,\nдолжна включать:\nплан  тестирования,  содержащий  тесты,  которые  необходимо  выполнить,\nописание  сценариев  проведения  каждого  теста,  учитывающее  зависимости\nпоследовательности  выполнения  тестов  от  результатов  других  тестов,  описание\nресурсов, необходимых для проведения тестирования;\nописание  сопоставления  тестов  с  интерфейсами  функций  безопасности\nсредства,  описанными  в  функциональной  спецификации,  демонстрирующее  их\nполное покрытие тестами;\nописание  ожидаемых  результатов  тестирования,  свидетельствующих  об\nуспешности выполнения тестов;\nописание  фактических  результатов  тестирования,  их  сопоставление  с\nожидаемыми результатами тестирования и на его основе – выводы об успешности\nтестов. 18.2. Тестовая документация на средство, соответствующее 5 уровню доверия,\nнаряду  с  требованиями,  установленными  пунктом  18.1  настоящих  Требований,\nдолжна  включать  описание  сопоставления  тестов  с  подсистемами  средства,\nописанными в эскизном проекте, демонстрирующее их полное покрытие тестами. При  проведении  тестирования  средства  проводится  оценка  влияния  на\nподсистемы  средства,  реализующие  функции  безопасности,  иных  подсистем\nсредства. 18.3. Тестовая документация на средство, соответствующее 4 уровню доверия,\nнаряду  с  требованиями,  установленными  пунктами  18.1  и  18.2  настоящих\nТребований, должна включать описание сопоставления тестов с модулями средства,\nреализующими  функции  безопасности  и  описанными  в  техническом  проекте,\nдемонстрирующее полное покрытие тестами функций безопасности. При проведении тестирования средства проводится оценка влияния на модули\nсредства, реализующие функции безопасности, иных модулей средства. 19. К  испытаниям  по  выявлению  уязвимостей  и  недекларированных\nвозможностей средства предъявляются следующие требования:\n19.1. Испытания  программного  обеспечения  средства,  соответствующего  6\nуровню доверия, должны быть проведены по 6 уровню контроля. Для аппаратной платформы программно-технического средства должна быть\nвыполнена проверка перечня аппаратных устройств (микросхем), которые влияют\nна  выполнение  функций  безопасности  и  (или)  могут  быть  использованы  для\nреализации угроз безопасности информации. 19.2. Испытания  программного  обеспечения  средства,  соответствующего  5\nуровню доверия, должны быть проведены по 5 уровню контроля. Для  аппаратной  платформы  программно-технического  средства  наряду  с\nтребованиями, установленными пунктом 19.1 настоящих Требований, должна быть\nвыполнена  проверка  соответствия  аппаратной  платформы  её  структурной  и\nфункциональной схемам, а также сведениям, приведенным в формуляре средства. 13\n19.3. Испытания  программного  обеспечения  средства,  соответствующего  4\nуровню доверия, должны быть проведены по 4 уровню контроля. Для  аппаратной  платформы  программно-технического  средства  наряду  с\nтребованиями,  установленными  пунктами  19.1  и  19.2  настоящих  Требований,\nдолжна быть выполнена проверка:\nсоответствия элементов (компонентов) аппаратной платформы структурной и\nфункциональной схеме элементов (компонентов) аппаратной платформы средства;\nпотенциально  опасных  элементов  (компонентов),  входящих  в  состав\nаппаратной платформы, которые влияют на выполнение функций безопасности и\n(или) могут быть использованы для реализации угроз безопасности информации. 20. К  проведению  анализа  скрытых  каналов  в  средстве  предъявляются\nследующие требования:\n20.1. Требования  к  проведению  анализа  скрытых  каналов  в  средстве,\nсоответствующем 6 и 5 уровню доверия, не предъявляются. 20.2. В  средстве,  соответствующем  4  уровню  доверия,  должны  быть\nпроведены идентификация и анализ скрытых каналов по памяти, основанных на\nиспользовании ресурсов памяти, в которые записывается защищаемая информация\n(сокрытие информации в структурированных и неструктурированных данных) и\nкоторые  не  учитываются  разработчиками  системы  защиты  информации\nинформационной (автоматизированной) системы и не выявляются применяемыми\nсредствами защиты информации. Анализ идентифицированных типов скрытых каналов должен включать:\nоценку  потенциальной  пропускной  способности  идентифицированных\nскрытых  каналов  с  использованием  формальных (математических),  технических\nметодов и (или) методов моделирования;\nразработку  требований  для  среды  функционирования  средства  с  целью\nограничения,\nмониторинга,\nполного\nили\nчастичного\nустранения\nидентифицированных  скрытых  каналов,  которые  могут  возникнуть  в\nинформационных (автоматизированных) системах вследствие использования в них\nсредства. Документация анализа скрытых каналов должна включать:\nидентификацию скрытых каналов (если скрытые каналы выявлены);\nоценку пропускной способности идентифицированных скрытых каналов (если\nскрытые каналы выявлены);\nописание  процедур,  использованных  для  вынесения  заключения  о\nсуществовании  и  (или)  отсутствии  скрытых  каналов,  и  информацию,\nиспользованную при анализе скрытых каналов;\nописание  предположений  (быстродействие  процессора,  системная\nконфигурация,  объем  памяти  и  (или)  иных),  сделанных  при  анализе  скрытых\nканалов;\nописание  способа,  использованного  для  оценки  пропускной  способности\nканала для наиболее опасного сценария (если скрытые каналы выявлены);\n14\nописание  наиболее  опасного  сценария  использования  каждого\nидентифицированного скрытого канала (если скрытые каналы выявлены);\nсведения о включении в функциональную спецификацию и эскизный проект\nописания механизмов средства, направленных на ограничение, мониторинг, полное\nили частичное устранение идентифицированных скрытых каналов, которые могут\nвозникнуть  в  информационных  (автоматизированных)  системах  вследствие\nиспользования  в  них  средства  (если  скрытые  каналы  выявлены  и  требуются\nсоответствующие механизмы средства);\nсведения о включении в руководство администратора и (или) руководство\nпользователя  требований  для  среды  функционирования  средства  с  целью\nограничения,\nмониторинга,\nполного\nили\nчастичного\nустранения\nидентифицированных  скрытых  каналов,  которые  могут  возникнуть  в\nинформационных (автоматизированных) системах вследствие использования в них\nсредства (если скрытые каналы выявлены). V. Требования к поддержке безопасности средства\n21. Средство  должно  обеспечиваться  поддержкой  безопасности  средства,\nпредусматривающей:\n1) устранение  недостатков  и  дефектов  средства,  в  том  числе  устранение\nуязвимостей  и  недекларированных  возможностей  средства  (далее  –  устранение\nнедостатков средства);\n2) информирование потребителей об обновлении программного обеспечения\nсредства  и  доведение  до  потребителей  обновлений  программного  обеспечения\nсредства,  а  также  изменений  в  эксплуатационную  документацию  (далее  –\nобновление средства);\n3) документирование  процедур  устранения  недостатков  и  обновления\nсредства;\n4) информирование  об  окончании  производства  и  (или)  поддержки\nбезопасности средства. Поддержка  безопасности  средства  обеспечивается  заявителем  на\nосуществление сертификации средства с привлечением разработчика и изготовителя\nсредства. 22. К  устранению  недостатков  средства  предъявляются  следующие\nтребования:\n22.1. Устранение недостатков средства, соответствующего 6 уровню доверия,\nдолжно предусматривать:\nпоиск в доступных источниках информации о недостатках средства, в том\nчисле  о  недостатках  в  компонентах  средства,  заимствованных  у  сторонних\nизготовителей;\nполучение сведений о недостатках средства от потребителей средства;\nпроведение испытаний средства по выявлению недостатков в средстве, в том\nчисле по выявлению уязвимостей и недекларированных возможностей средства;\n15\nразработку компенсирующих мер по защите информации или ограничений по\nприменению  средства,  снижающих  возможность  эксплуатации  недостатков\n(уязвимостей);\nдоведение информации о недостатках средства, а также о компенсирующих\nмерах  по  защите  информации  или  ограничений  по  применению  средства  до\nпотребителей  средства,  ФСТЭК  России  и  банка  данных  угроз  безопасности\nинформации, ведение которого осуществляется ФСТЭК России в соответствии с\nподпунктом 21 пункта 8 Положения о Федеральной службе по техническому и\nэкспортному контролю, утвержденного Указом Президента Российской Федерации\nот 16 августа 2004 г. № 1085 (Собрание законодательства Российской Федерации,\n2004, № 34, ст. 3541; 2018, № 20, ст. 2818);\nустранение недостатков средства путем доработки средства или его отдельных\nкомпонентов,  принятие  иных  мер,  снижающих  возможность  эксплуатации\nуязвимостей;\nтестирование  (испытания)  доработанного  средства  или  его  отдельных\nкомпонентов на предмет устранения влияния обновлений средства на его функции\nбезопасности,  подтверждения  устранения  уязвимостей,  невнесения  новых\nуязвимостей в средство. 22.2. Устранение недостатков средства, соответствующего 5 уровню доверия,\nнаряду  с  требованиями,  установленными  пунктом  22.1  настоящих  Требований,\nдолжно предусматривать:\nразработку компенсирующих мер по защите информации или ограничений по\nприменению средства, а также доведение информации о недостатках и указанных\nмерах и ограничениях до потребителей не позднее 72 часов с момента выявления\nнедостатка;\nдоработку  средства,  в  том  числе  разработку  обновлений  программного\nобеспечения средства, или разработку мер по защите информации, нейтрализующих\nнедостаток, в срок не более 60 дней с момента выявления недостатка. 22.3. Устранение недостатков средства, соответствующего 4 уровню доверия,\nнаряду  с  требованиями,  установленными  пунктами  22.1  и  22.2  настоящих\nТребований, должно предусматривать:\nразработку компенсирующих мер по защите информации или ограничений по\nприменению  средства,  а  также  доведение  информации  о  таких  мерах  и\nограничениях  до потребителей в срок не более 48 часов с момента выявления\nнедостатка;\nдоведение информации о недостатках средства, а также о компенсирующих\nмерах  по  защите  информации  или  ограничениях  по  применению  до  каждого\nпотребителя  сертифицированного  средства  путем  отправки  сообщений  на\nэлектронные адреса потребителей или за счет применения компонента средства,\nобеспечивающего доведение указанной информации до потребителя автоматически. 23. К обновлению средства предъявляются следующие требования:\n23.1. Обновление  средства,  соответствующего  6  уровню  доверия,  должно\nпредусматривать:\n16\nинформирование потребителей средства о выпуске обновлений;\nобеспечение  возможности  получения  обновления  средства  способами,\nобеспечивающими его целостность. 23.2. Наряду  с  требованиями,  установленными  пунктом  23.1  настоящих\nТребований,  к  обновлению  средства,  соответствующего  5  уровню  доверия,\nпредъявляются следующие требования:\nв случае получения обновления средства по сетям связи средство должно\nполучать такие обновления с информационного ресурса заявителя;\nпри доведении обновлений средства до потребителей должны обеспечиваться\nподлинность и целостность обновлений за счет применения электронной цифровой\nподписи. 23.3. Наряду  с  требованиями,  установленными  пунктами  23.1  и  23.2\nнастоящих Требований, доведение информации о выпуске обновлений средства,\nсоответствующего  4  уровню  доверия,  должно  осуществляться  до  каждого\nпотребителя  сертифицированного  средства  путем  отправки  сообщений  на\nэлектронные адреса потребителей или за счет применения компонента средства,\nобеспечивающего доведение указанной информации до потребителя автоматически. 24. К  документированию  процедур  устранения  недостатков  и  обновления\nсредства предъявляются следующие требования:\n24.1. Документирование  процедур  устранения  недостатков  и  обновления\nсредства, соответствующего 6 уровню доверия, должно предусматривать:\nвключение в программную и конструкторскую документацию на средство\nпроцедур устранения недостатков;\nразработку  регламента  обновления  средства  потребителем,  включающего\nпорядок  получения,  установки  и  контроля  установки  обновления  программного\nобеспечения средства. 24.2. Требования  к документированию процедур устранения недостатков  и\nобновления  средства,  соответствующего  5  и  4  уровням  доверия,  соответствуют\nтребованиям к документированию процедур устранения недостатков и обновления\nсредства, соответствующего 6 уровню доверия. 25. К  информированию  об  окончании  производства  и  (или)  поддержки\nбезопасности средства предъявляются следующие требования:\n25.1. Об окончании производства и (или) поддержки безопасности средства,\nсоответствующего 6 уровню доверия, потребители и ФСТЭК России должны быть\nпроинформированы не позднее чем за 1 год до окончания производства и (или)\nподдержки безопасности средства. 25.2. Требования  к  информированию  об  окончании  производства  и  (или)\nподдержки  безопасности  средства,  соответствующего  5  и  4  уровням  доверия,\nсоответствуют требованиям к информированию об окончании производства и (или)\nподдержки безопасности средства, соответствующего 6 уровню доверия. _____________________\n17\nПримечание\nВ соответствии с приказом ФСТЭК России от 2 июня 2020 г. № 76 настоящие\nТребования вступают в силу с 1 января 2021 г., за исключением:\nабзаца седьмого пункта 12.2, который вступает в силу с 1 января 2022 г.;\nабзаца пятого пункта 12.3, который вступает в силу с 1 января 2028 г. Приказ  ФСТЭК  России  от  30  июля  2018  г. № 131  «Об  утверждении\nТребований  по  безопасности  информации,  устанавливающих  уровни  доверия  к\nсредствам технической защиты информации и средствам обеспечения безопасности\nинформационных  технологий»\n(зарегистрирован  Министерством  юстиции\nРоссийской Федерации 14 ноября 2018 г., регистрационный № 52686) признается\nутратившим силу с 1 января 2021 г..", "27.10.2022 № 187": "УТВЕРЖДЕНЫ\nприказом ФСТЭК России\nот « 27 » октября 2022 г. № 187\nЗарегистрирован Минюстом России\n« 22 » декабря 2022 г. № 71774\nТребования по безопасности информации к средствам виртуализации\n(выписка)\n1. Настоящие Требования являются обязательными требованиями в области\nтехнического регулирования к продукции, используемой в целях защиты\nсведений, составляющих государственную тайну или относимых\nк охраняемой в соответствии с законодательством Российской Федерации\nиной информации ограниченного доступа[1] (далее – требования по\nбезопасности информации), предъявляемыми к программным средствам,\nобеспечивающим создание и функционирование изолированных программных\nсред, состоящих из виртуального оборудования, гостевых операционных\nсистем и прикладного программного обеспечения (далее – виртуальные\nмашины), в информационной (автоматизированной) системе (далее –\nсредства виртуализации). 2. Выполнение настоящих Требований является обязательным при\nпроведении работ по оценке соответствия (включая работы по\nсертификации) средств технической защиты информации и средств\nобеспечения безопасности информационных технологий, организуемых ФСТЭК\nРоссии в пределах своих полномочий в соответствии с Положением о\nсистеме сертификации средств защиты информации, утвержденным приказом\nФСТЭК России от 3 апреля\n2018 г. № 55 (зарегистрирован Минюстом России 11 мая 2018 г.,\nрегистрационный № 51063) (с изменениями, внесенными приказом\nФСТЭК России от 5 августа 2021 г. № 121 (зарегистрирован Минюстом\nРоссии 27 октября 2021 г., регистрационный № 65594) и приказом ФСТЭК\nРоссии\nот 19 сентября 2022 г. № 172 (зарегистрирован Минюстом России\n19 октября 2022 г., регистрационный № 70614). 3. Настоящие Требования применяются к средствам виртуализации,\nреализующим функциональные возможности по созданию образов виртуальных\nмашин, формированию среды выполнения виртуальных машин, запуску\nвиртуальных машин и управлению ими, по идентификации и аутентификации\nпользователей в средстве виртуализации и централизованному управлению\nобразами виртуальных машин, виртуальными машинами и организацией\nвзаимодействия между виртуальными машинами. 4. Для дифференциации требований по безопасности информации\nк средствам виртуализации устанавливается 6 классов защиты. Самый\nнизкий класс – шестой, самый высокий – первый. Средства виртуализации, соответствующие 6 классу защиты, применяются в\nзначимых объектах критической информационной инфраструктуры 3\nкатегории значимости[2], в государственных информационных системах 3\nкласса защищенности[3], в автоматизированных системах управления\nпроизводственными и технологическими процессами 3 класса\nзащищенности[4], в информационных системах персональных данных при\nнеобходимости обеспечения 3 и 4 уровня защищенности персональных\nданных[5]. Средства виртуализации, соответствующие 5 классу защиты, применяются в\nзначимых объектах критической информационной инфраструктуры 2\nкатегории значимости, в государственных информационных системах 2\nкласса защищенности, в автоматизированных системах управления\nпроизводственными и технологическими процессами 2 класса защищенности,\nв информационных системах персональных данных при необходимости\nобеспечения 2 уровня защищенности персональных данных. Средства виртуализации, соответствующие 4 классу защиты, применяются в\nзначимых объектах критической информационной инфраструктуры 1\nкатегории значимости, в государственных информационных системах 1\nкласса защищенности, в автоматизированных системах управления\nпроизводственными и технологическими процессами 1 класса защищенности,\nв информационных системах персональных данных при необходимости\nобеспечения 1 уровня защищенности персональных данных,\nв информационных системах общего пользования II класса[6]. 5. Настоящие Требования включают требования по безопасности\nинформации, предъявляемые к:\nуровню доверия средства виртуализации;\nхостовой операционной системе, в среде которой функционирует средство\nвиртуализации (далее – хостовая операционная система);\nсоставу функций безопасности средства виртуализации;\nдоверенной загрузке виртуальных машин;\nконтролю целостности в средстве виртуализации;\nрегистрации событий безопасности в средстве виртуализации;\nуправлению доступом в средстве виртуализации;\nуправлению потоками информации в средстве виртуализации;\nзащите памяти;\nограничению программной среды;\nрезервному копированию виртуальных машин;\nидентификации и аутентификации пользователей в средстве виртуализации;\nцентрализованному управлению образами виртуальных машин и виртуальными\nмашинами. 6. Средство виртуализации должно соответствовать Требованиям\nпо безопасности информации, устанавливающим уровни доверия к средствам\nтехнической защиты информации и средствам обеспечения безопасности\nинформационных технологий, утвержденным приказом ФСТЭК России\nот 2 июня 2020 г. № 76 (зарегистрирован Минюстом России 11 сентября\n2020 г., регистрационный № 59772) (с изменениями, внесенными приказом\nФСТЭК России от 18 апреля 2022 г. № 68 (зарегистрирован Минюстом\nРоссии 20 июля 2022 г., регистрационный № 69318). Устанавливается следующее соответствие классов защиты средств\nвиртуализации уровням доверия:\nсредства виртуализации 6 класса защиты должны соответствовать\n6 уровню доверия;\nсредства виртуализации 5 класса защиты должны соответствовать\n5 уровню доверия;\nсредства виртуализации 4 класса защиты должны соответствовать\n4 уровню доверия. 7. В случае функционирования средства виртуализации в среде хостовой\nоперационной системы, хостовая операционная система должна быть\nсертифицирована на соответствие Требованиям в области технического\nрегулирования к продукции, используемой в целях защиты сведений,\nсоставляющих государственную тайну или относимых к охраняемой\nв соответствии с законодательством Российской Федерации иной\nинформации ограниченного доступа (требованиям безопасности информации\nк операционным системам), утвержденным приказом ФСТЭК России\nот 19 августа 2016 г. № 119 (зарегистрирован Минюстом России\n19 сентября 2016 г., регистрационный № 43691), и Требованиям по\nбезопасности информации, устанавливающим уровни доверия к средствам\nтехнической защиты информации и средствам обеспечения безопасности\nинформационных технологий, утвержденным приказом ФСТЭК России от 2\nиюня 2020 г. № 76. Средство виртуализации 6 класса защиты должно функционировать в среде\nхостовой операционной системы, соответствующей 6 классу защиты\nи 6 уровню доверия. Средство виртуализации 5 класса защиты должно функционировать в среде\nхостовой операционной системы, соответствующей 5 классу защиты\nи 5 уровню доверия. Средство виртуализации 4 класса защиты должно функционировать в среде\nхостовой операционной системы, соответствующей 4 классу защиты\nи 4 уровню доверия. 8. В средстве виртуализации должны быть реализованы следующие функции\nбезопасности:\nдоверенная загрузка виртуальных машин;\nконтроль целостности;\nрегистрация событий безопасности;\nуправление доступом;\nрезервное копирование;\nуправление потоками информации;\nзащита памяти;\nограничение программной среды;\nидентификация и аутентификация пользователей. централизованное управление образами виртуальных машин и виртуальными\nмашинами. 9. К доверенной загрузке виртуальных машин предъявляются следующие\nтребования:\n9.1. Средство виртуализации 6, 5 классов защиты должно блокировать\nзапуск виртуальной машины при выявлении нарушения целостности\nконфигурации виртуального оборудования данной виртуальной машины. 9.2. Средство виртуализации 4 класса защиты наряду с требованиями,\nустановленными подпунктом 9.1 пункта 9 настоящих Требований,\nдополнительно должно блокировать запуск виртуальной машины при\nвыявлении нарушения целостности файлов виртуальной базовой системы\nввода-вывода (первичного загрузчика виртуальной машины) и (или)\nисполняемых файлов гостевой операционной системы. 10. К контролю целостности в средстве виртуализации предъявляются\nследующие требования:\n10.1. Средство виртуализации 6 класса защиты должно:\nконтролировать целостность в процессе загрузки и динамически\nв процессе функционирования средства виртуализации объектов контроля\nсамостоятельно или с применением сертифицированных хостовой\nоперационной системы или средства доверенной загрузки;\nинформировать администратора безопасности средства виртуализации\nо нарушении целостности объектов контроля;\nконтролировать целостность конфигурации виртуального оборудования\nвиртуальных машин. 10.2. Средство виртуализации 5 класса защиты наряду с требованиями,\nустановленными подпунктом 10.1 пункта 10 настоящих Требований,\nдополнительно должно контролировать целостность исполняемых файлов\nи параметров настройки средства виртуализации. 10.3. Средство виртуализации 4 класса защиты наряду с требованиями,\nустановленными подпунктами 10.1 и 10.2 пункта 10 настоящих Требований,\nдополнительно должно обеспечивать целостность сведений о событиях\nбезопасности. 11. К регистрации событий безопасности в средстве виртуализации\nпредъявляются следующие требования:\n11.1. Средство виртуализации 6, 5 классов защиты должно:\nобеспечивать регистрацию событий безопасности, связанных\nс функционированием средства виртуализации;\nоповещать администратора безопасности средства виртуализации\nо событиях безопасности;\nвыполнять действия, являющиеся реакцией на события безопасности\nсамостоятельно или с применением сертифицированных средств защиты\nинформации;\nосуществлять сбор и хранение записей в журнале событий безопасности,\nкоторые позволяют определить, когда и какие действия происходили. Регистрация событий безопасности в средстве виртуализации должна\nосуществляться с учетом разделов 3 - 6 ГОСТ Р 59548-2022 «Защита\nинформации. Регистрация событий безопасности. Требования к\nрегистрируемой информации»[7]. Для каждой функции безопасности в средстве виртуализации должен быть\nопределен перечень событий, необходимых для регистрации и учета. Для регистрируемых событий безопасности в каждой записи журнала\nсобытий безопасности должны регистрироваться номер (уникальный\nидентификатор) события, дата, время, тип события безопасности. Записи журнала событий безопасности должны представляться\nв структурированном виде и содержать время события безопасности,\nвзятое из аппаратной платформы или хостовой операционной системы. Журнал событий безопасности средства виртуализации должен быть\nдоступен только для чтения. При исчерпании области памяти, отведенной\nпод журнал событий безопасности средства виртуализации, должно\nосуществляться архивирование журнала с последующей очисткой\nвысвобождаемой области памяти. Регистрации подлежат как минимум следующие события безопасности:\nуспешные и неуспешные попытки аутентификации пользователей средства\nвиртуализации;\nдоступ пользователей средства виртуализации к виртуальным машинам;\nсоздание и удаление виртуальных машин;\nзапуск и остановка средства виртуализации с указанием причины\nостановки;\nзапуск и остановка виртуальных машин с указанием причины остановки;\nизменение ролевой модели;\nизменение конфигурации средства виртуализации;\nизменение конфигураций виртуальных машин;\nфакты нарушения целостности объектов контроля. 11.2. В средстве виртуализации 4 класса защиты наряду с требованиями,\nустановленными подпунктом 11.1 пункта 11 настоящих Требований, для\nрегистрируемых событий безопасности в каждой записи журнала событий\nбезопасности дополнительно должно регистрироваться описание события\nбезопасности, включающее сведения о его важности. 12. В средстве виртуализации 6, 5, 4 класса защиты должен быть\nреализован ролевой метод управления доступом с четырьмя ролями\nпользователей: разработчик виртуальной машины, администратор\nбезопасности средства виртуализации, администратор средства\nвиртуализации, администратор виртуальной машины. 12.1 Роль разработчика виртуальной машины должна позволять:\nсоздавать виртуальные машины;\nизменять конфигурации виртуальных машин. 12.2 Роль администратора безопасности средства виртуализации должна\nпозволять:\nиметь доступ на чтение к журналу событий безопасности средства\nвиртуализации;\nформировать отчеты с учетом заданных критериев отбора, выгрузку\n(экспорт) данных из журнала событий безопасности средства\nвиртуализации. 12.3 Роль администратора средства виртуализации должна позволять:\nсоздавать учетные записи пользователей средства виртуализации;\nуправлять учетными записями пользователей средства виртуализации;\nназначать права доступа пользователям средства виртуализации\nк виртуальным машинам;\nсоздавать и удалять виртуальное оборудование средства виртуализации;\nизменять конфигурации виртуального оборудования средства\nвиртуализации;\nуправлять доступом виртуальных машин к физическому и виртуальному\nоборудованию;\nуправлять квотами доступа виртуальных машин к физическому\nи виртуальному оборудованию;\nуправлять перемещением виртуальных машин;\nудалять виртуальные машины;\nзапускать и останавливать виртуальные машины;\nсоздавать снимки состояния виртуальных машин, включающих файл\nконфигурации виртуальной машины, образа виртуальной машины и образа\nпамяти виртуальной машины. 12.4 Роль администратора виртуальной машины должна позволять\nосуществлять доступ пользователя средства виртуализации к виртуальной\nмашине посредством интерфейса средства виртуализации. 12.5 Средство виртуализации должно обеспечивать возможность\nопределения полномочий для пользователей средства виртуализации\nв пределах назначенных им ролей. 12.6 В целях обеспечения удаленного доступа пользователей\nс использованием сетей связи общего пользования к средству\nвиртуализации должны применяться средства криптографической защиты\nинформации, прошедшие процедуру оценки соответствия в соответствии\nс законодательством Российской Федерации. 13. К резервному копированию в средстве виртуализации предъявляются\nследующие требования:\n13.1. В средстве виртуализации 6 класса защиты должно обеспечиваться\nрезервное копирование образов виртуальных машин и конфигурации\nвиртуального оборудования виртуальных машин самостоятельно или\nс применением хостовой операционной системы или сертифицированных\nсредств резервного копирования. 13.2. В средстве виртуализации 5 класса защиты наряду с требованиями,\nустановленными подпунктом 13.1 пункта 13 настоящих Требований,\nдополнительно должно обеспечиваться резервное копирование параметров\nнастройки средства виртуализации. 13.3. В средстве виртуализации 4 класса защиты наряду с требованиями,\nустановленными подпунктами 13.1 и 13.2 пункта 13 настоящих Требований,\nдополнительно должно обеспечиваться резервное копирование сведений о\nсобытиях безопасности. 14. К ограничению программной среды в средстве виртуализации\nпредъявляются следующие требования:\n14.1. Средство виртуализации 6, 5 класса защиты самостоятельно или\nс привлечением хостовой операционной системы должно осуществлять\nконтроль за запуском компонентов программного обеспечения,\nобеспечивающий выявление и блокировку запуска компонентов программного\nобеспечения, не включенных в перечень (список) компонентов,\nразрешенных для запуска. 14.2. Средство виртуализации 4 класса защиты наряду с требованиями,\nустановленными подпунктом 14.1 пункта 14 настоящих Требований,\nдополнительно должно осуществлять контроль за запуском компонентов\nпрограммного обеспечения, обеспечивающий:\nвыявление и блокировку запуска компонентов программного обеспечения,\nцелостность которого нарушена;\nблокировку запуска компонентов программного обеспечения, не прошедших\nаутентификацию с использованием свидетельств подлинности модулей (в\nтом числе цифровых сигнатур производителя или иных свидетельств\nподлинности модулей). 15. Средство виртуализации 6, 5, 4 классов защиты должно обеспечивать\nуправление потоками информации между виртуальными машинами и\nинформационными (автоматизированными) системами на канальном и сетевом\nуровнях самостоятельно или с применением сертифицированных средств\nуправления потоками информации (коммутаторов, маршрутизаторов) и (или)\nмежсетевых экранов, а также контроль взаимодействия виртуальных машин\nмежду собой. 16. К защите памяти средством виртуализации предъявляются следующие\nтребования:\n16.1. Средство виртуализации 6, 5, 4 классов защиты должно:\nочищать остаточную информацию в памяти средства вычислительной техники\nпри ее освобождении (распределении) или блокирование доступа субъектов\nк остаточной информации;\nудалять объекты файловой системы, используемые средством\nвиртуализации, путем перезаписи уничтожаемых (стираемых) объектов\nфайловой системы случайной битовой последовательностью;\nразмещать код средства виртуализации в области памяти, не доступной\nодновременно для записи и исполнения;\nизолировать области памяти виртуальных машин. 17. При реализации средством виртуализации функций безопасности\nпо идентификации и аутентификации пользователей к средству\nвиртуализации предъявляются следующие требования:\n17.1. Первичная идентификация пользователей средства виртуализации\n6 класса защиты должна осуществляться администратором средства\nвиртуализации. Идентификация и аутентификация пользователей в средстве виртуализации\nосуществляется с учетом требований разделов 4 – 7 ГОСТ Р 58833–2020\n«Защита информации. Идентификация и аутентификация. Общие\nположения»[8]. В случае неуспешной идентификации и аутентификации пользователей\nв средстве виртуализации их доступ должен быть заблокирован. Средство виртуализации должно осуществлять аутентификацию\nпользователей при предъявлении идентификатора и пароля пользователя. Пароль пользователя для первичной аутентификации должен\nустанавливаться администратором средства виртуализации. Средство виртуализации должно обеспечивать возможность смены\nустановленного администратором средства виртуализации пароля\nпользователя средства виртуализации после его первичной\nаутентификации. Средство виртуализации должно обеспечивать невозможность установления\nодинаковых идентификаторов и паролей для разных пользователей. При попытке ввода неправильного значения идентификатора или пароля\nпользователя должно выводиться сообщение с приглашением ввести\nправильный идентификатор и пароль еще раз. При исчерпании установленного максимального количества неуспешных\nпопыток ввода неправильного пароля учетная запись пользователя\nсредства виртуализации должна быть заблокирована с возможностью\nразблокировки администратором средства виртуализации или с\nвозможностью автоматической разблокировки по истечении временного\nинтервала, устанавливаемого администратором средства виртуализации. Защита пароля пользователя средства виртуализации должна\nобеспечиваться при его вводе за счет отображения вводимых символов\nусловными знаками. Пароль пользователя средства виртуализации 6 класса защиты должен\nсодержать не менее 6 символов при алфавите пароля не менее 60\nсимволов. Максимальное количество неуспешных попыток аутентификации\n(ввода неправильного пароля) до блокировки – 10. Средство виртуализации должно обеспечивать хранение аутентификационной\nинформации пользователя средства виртуализации в защищенном формате\nили в защищенном хранилище. 17.2. Пароль пользователя средства виртуализации 5 класса защиты\nнаряду с требованиями, установленными подпунктом 17.1 пункта 17\nнастоящих Требований, дополнительно должен содержать не менее 6\nсимволов при алфавите пароля не менее 70 символов. Максимальное\nколичество неуспешных попыток аутентификации (ввода неправильного\nпароля) до блокировки – 8. Средство виртуализации 5 класса защиты должно обеспечивать взаимную\nидентификацию и аутентификацию пользователей и средства виртуализации\nпри удаленном доступе с использованием сетей связи общего пользования. 17.3. Пароль пользователя средства виртуализации 4 класса защиты\nнаряду с требованиями, установленными подпунктами 17.1 и 17.2 пункта\n17 настоящих Требований, дополнительно должен содержать не менее\n8 символов при алфавите пароля не менее 70 символов. Максимальное\nколичество неуспешных попыток аутентификации (ввода неправильного\nпароля) до блокировки – 4. 18. При реализации средством виртуализации функций безопасности\nпо централизованному управлению образами виртуальных машин\nи виртуальными машинами к средству виртуализации предъявляются\nследующие требования:\n18.1. Средство виртуализации 6 класса защиты должно:\nсоздавать, модифицировать, хранить, получать и удалять образы\nвиртуальных машин в информационной (автоматизированной) системе;\nобеспечивать чтение записей о событиях безопасности, формирование\nотчетов с учетом заданных критериев отбора, выгрузку (экспорт) данных\nиз журнала событий безопасности средства виртуализации. 18.2. Средство виртуализации 5, 4 классов защиты должно наряду с\nтребованиями, установленными подпунктом 18.1 пункта 18 настоящих\nТребований, дополнительно обеспечивать управление размещением\nи перемещением виртуальных машин и их образов с возможностью\nсохранения их конфигурации и настроек. [1]  Статья 5 Федерального закона от 27 декабря 2002 г. № 184-ФЗ «О\nтехническом регулировании» (Собрание законодательства Российской\nФедерации, 2002, № 52, ст. 5140; 2007, № 19, ст. 2293; 2011, № 49, ст. 7025; 2016, № 15, ст. 2066). [2]  Статья 7 Федерального закона от 26 июля 2017 г. № 187-ФЗ «О\nбезопасности критической информационной инфраструктуры Российской\nФедерации» (Собрание законодательства Российской Федерации, 2017, № 31,\nст. 4736), Правила категорирования объектов критической информационной\nинфраструктуры Российской Федерации, утвержденные постановлением\nПравительства Российской Федерации от 8 февраля 2018 г. № 127 (Собрание\nзаконодательства Российской Федерации, 2018, № 8, ст. 1204; 2019, № 16,\nст. 1955). [3]  Требования о защите информации, не составляющей государственную\nтайну, содержащейся в государственных информационных системах,\nутвержденные приказом ФСТЭК России от 11 февраля 2013 г. № 17\n(зарегистрирован Минюстом России 31 мая 2013 г., регистрационный\n№ 28608) (с изменениями, внесенными приказом ФСТЭК России от 15 февраля\n2017 г. № 27 (зарегистрирован Минюстом России 14 марта 2017 г.,\nрегистрационный № 45933) и приказом ФСТЭК России от 28 мая 2019 г. № 106\n(зарегистрирован Минюстом России 13 сентября 2019 г., регистрационный\n№ 55924). [4]  Требования к обеспечению защиты информации в автоматизированных\nсистемах управления производственными и технологическими процессами на\nкритически важных объектах, потенциально опасных объектах, а также\nобъектах, представляющих повышенную опасность для жизни и здоровья людей\nи для окружающей природной среды, утвержденные приказом ФСТЭК России от\n14 марта 2014 г. № 31 (зарегистрирован Минюстом России 30 июня 2014 г.,\nрегистрационный № 32919) (с изменениями, внесенными приказом ФСТЭК\nРоссии от 23 марта 2017 г. № 49 (зарегистрирован Минюстом России\n25 апреля 2017 г., регистрационный № 46487), приказом ФСТЭК России\nот 9 августа 2018 г. № 138 (зарегистрирован Минюстом России 5 сентября\n2018 г., регистрационный № 52071) и приказом ФСТЭК России от 15 марта\n2021 г. № 46 (зарегистрирован Минюстом России 1 июля 2021 г.,\nрегистрационный № 64063). [5]  Требования к защите персональных данных при их обработке в\nинформационных системах персональных данных, утвержденные постановлением\nПравительства Российской Федерации от 1 ноября 2012 г. № 1119 (Собрание\nзаконодательства Российской Федерации, 2012, № 45, ст. 6257). [6]  Требования о защите информации, содержащейся в информационных\nсистемах общего пользования, утвержденные приказом ФСБ России и ФСТЭК\nРоссии от 31 августа 2010 г. № 416/489 (зарегистрирован Минюстом России\n13 октября 2010 г., регистрационный № 18704). [7]  Утвержден и введен в действие приказом Федерального агентства по\nтехническому регулированию и метрологии от 13 января 2022 г. № 2-ст (М., «Стандартинформ», 2022). [8]  Утвержден и введен в действие приказом Федерального агентства по\nтехническому регулированию и метрологии от 10 апреля 2020 г. № 159-ст\n(М., «Стандартинформ», 2020).", "04.07.2022 № 118": "УТВЕРЖДЕНЫ приказом ФСТЭК России от 4 июля 2022 г. № 118\nТребования по безопасности информации к средствам контейнеризации\n(выписка)\n0. Настоящие Требования являются обязательными требованиями в области\nтехнического регулирования к продукции, используемой в целях\nзащиты сведений, составляющих государственную тайну или относимых\nк охраняемой в соответствии с законодательством Российской\nФедерации иной информации ограниченного доступа^([1]) (далее –\nтребования по безопасности информации), предъявляемыми к\nпрограммным средствам, обеспечивающим создание и функционирование\nизолированных программных сред на основе ядра хостовой\nоперационной системы (далее – контейнеры) в информационной\n(автоматизированной) системе (далее – средства контейнеризации). 1. Выполнение настоящих Требований является обязательным при\nпроведении работ по оценке соответствия (включая работы по\nсертификации) средств технической защиты информации и средств\nобеспечения безопасности информационных технологий, организуемых\nФСТЭК России в пределах своих полномочий в соответствии с\nПоложением о системе сертификации средств защиты информации,\nутвержденным приказом ФСТЭК России от 3 апреля 2018 г. № 55\n(зарегистрирован Минюстом России 11 мая 2018 г., регистрационный\n№ 51063) (с изменениями, внесенными приказом ФСТЭК России от 5\nавгуста 2021 г. № 121 (зарегистрирован Минюстом России 27 октября\n2021 г., регистрационный № 65594). 2. Настоящие Требования применяются к средствам контейнеризации,\nреализующим функциональные возможности по созданию образов\nконтейнеров, формированию среды выполнения контейнеров и\nобеспечения выполнения их процессов, запуску контейнера и\nуправление данным контейнером, а также дополнительные\nфункциональные возможности по централизованному управлению\nконтейнерами, организации взаимодействия между ними и\nраспространению образов контейнеров. 3. Для дифференциации требований по безопасности информации к\nсредствам контейнеризации устанавливается 6 классов защиты. Самый\nнизкий класс – шестой, самый высокий – первый. Средства контейнеризации, соответствующие 6 классу защиты, применяются\nв значимых объектах критической информационной инфраструктуры 3\nкатегории значимости^([2]), в государственных информационных системах\n3 класса защищенности^([3]), в автоматизированных системах управления\nпроизводственными и технологическими процессами 3 класса\nзащищенности^([4]), в информационных системах персональных данных при\nнеобходимости обеспечения 3 и 4 уровня защищенности персональных\nданных^([5]). Средства контейнеризации, соответствующие 5 классу защиты, применяются\nв значимых объектах критической информационной инфраструктуры 2\nкатегории значимости, в государственных информационных системах 2\nкласса защищенности, в автоматизированных системах управления\nпроизводственными и технологическими процессами 2 класса защищенности,\nв информационных системах персональных данных при необходимости\nобеспечения 2 уровня защищенности персональных данных. Средства контейнеризации, соответствующие 4 классу защиты, применяются\nв значимых объектах критической информационной инфраструктуры 1\nкатегории значимости, в государственных информационных системах 1\nкласса защищенности, в автоматизированных системах управления\nпроизводственными и технологическими процессами 1 класса защищенности,\nв информационных системах персональных данных при необходимости\nобеспечения 1 уровня защищенности персональных данных, в\nинформационных системах общего пользования II класса^([6]). 4. Настоящие Требования включают требования по безопасности\nинформации, предъявляемые к:\nуровню доверия средства контейнеризации;\nхостовой операционной системе, в среде которой функционирует\nсредство контейнеризации; составу функций безопасности средства\nконтейнеризации; изоляции контейнеров средством контейнеризации;\nвыявлению уязвимостей в образах контейнеров;\nпроверке корректности конфигурации контейнеров;\nконтролю целостности контейнеров и их образов в средстве\nконтейнеризации; регистрации событий безопасности в средстве\nконтейнеризации;\nуправлению доступом в средстве контейнеризации;\nидентификации и аутентификации пользователей в средстве\nконтейнеризации; централизованному управлению образами контейнеров и\nконтейнерами в\nсредстве контейнеризации. 6. Средство контейнеризации должно соответствовать Требованиям по\nбезопасности информации, устанавливающим уровни доверия к средствам\nтехнической защиты информации и средствам обеспечения безопасности\nинформационных технологий, утвержденным приказом ФСТЭК России от 2\nиюня 2020 г. № 76 (зарегистрирован Минюстом России 11 сентября 2020\nг., регистрационный № 59772) (с изменениями, внесенными приказом ФСТЭК\nРоссии от 18 апреля 2022 г. № 68 (зарегистрирован Минюстом России 20\nиюля 2022 г., регистрационный № 69318). Устанавливается следующее соответствие классов защиты средств\nконтейнеризации уровням доверия:\nсредства контейнеризации 6 класса защиты должны соответствовать\n6 уровню доверия; средства контейнеризации 5 класса защиты должны\nсоответствовать\n5 уровню доверия; средства контейнеризации 4 класса защиты должны\nсоответствовать 4 уровню доверия;\n5. 7. Хостовая операционная система, в среде которой функционирует\nсредство контейнеризации, должна быть сертифицирована на\nсоответствие Требованиям в области технического регулирования\nк продукции, используемой в целях защиты сведений,\nсоставляющих государственную тайну или относимых к охраняемой\nв соответствии с законодательством Российской Федерации иной\nинформации ограниченного доступа (требованиям безопасности\nинформации к операционным системам), утвержденным приказом\nФСТЭК России от 19 августа 2016 г. № 119 (зарегистрирован\nМинюстом России 19 сентября 2016 г., регистрационный № 43691),\nи Требованиям по безопасности информации, устанавливающим\nуровни доверия к средствам технической защиты информации и\nсредствам обеспечения безопасности информационных технологий,\nутвержденным приказом ФСТЭК России от 2 июня 2020 г. № 76. Средство контейнеризации 6 класса защиты должно функционировать в\nсреде хостовой операционной системы, соответствующей 6 классу защиты и\n6 уровню доверия. Средство контейнеризации 5 класса защиты должно функционировать в\nсреде хостовой операционной системы, соответствующей 5 классу защиты и\n5 уровню доверия. Средство контейнеризации 4 класса защиты должно функционировать в\nсреде хостовой операционной системы, соответствующей 4 классу защиты и\n4 уровню доверия. 6. 7. В средстве контейнеризации должны быть реализованы следующие\nфункции безопасности:\nизоляция контейнеров; выявление уязвимостей в образах контейнеров;\nпроверка корректности конфигурации контейнеров; контроль целостности\nконтейнеров и их образов; регистрация событий безопасности. В средстве контейнеризации дополнительно могут быть реализованы\nследующие функции безопасности:\nуправление доступом;\nидентификация и аутентификация пользователей; централизованное\nуправление образами контейнеров и контейнерами. 7. 7. К изоляции контейнеров средством контейнеризации предъявляются\nследующие требования:\n9.1. Средство контейнеризации 6 класса защиты должно реализовывать\nмеханизмы изоляции контейнеров. Способы реализации изоляции\nконтейнеров устанавливаются разработчиком средства контейнеризации. 9.2. Средство контейнеризации 5 и 4 классов защиты наряду с\nтребованиями, установленными подпунктом 9.1 пункта 9 настоящих\nТребований, дополнительно должно реализовывать следующие механизмы:\nизоляция пространств идентификаторов процессов контейнеров; изоляция\nпространств имен для межпроцессного взаимодействия\nконтейнеров; изоляция пространств имен для пользователей и групп\nконтейнеров; изоляция пространств имен хостов и доменов контейнеров;\nизоляция сетевых пространств имен контейнеров; изоляция пространств\nимен для иерархии каталогов контейнеров. 10. К выявлению уязвимостей в образах контейнеров предъявляются\nследующие требования:\n10.1. Средство контейнеризации 6 класса защиты должно:\nвыявлять известные уязвимости при создании, установке образа\nконтейнера в информационной (автоматизированной) системе и хранении\nобразов контейнеров во взаимодействии с сертифицированным средством\nконтроля и анализа защищенности на основе сведений, содержащихся в\nбанке данных угроз безопасности информации, ведение которого\nосуществляется ФСТЭК России в соответствии с подпунктом 21 пункта 8\nПоложения о Федеральной службе по техническому и экспортному контролю,\nутвержденного Указом Президента Российской Федерации от 16 августа\n2004 г. № 1085 (Собрание законодательства Российской Федерации, 2004,\n№ 34, ст. 3541), а также в иных источниках, содержащих сведения об\nизвестных уязвимостях; оповещать о выявленных уязвимостях в образах\nконтейнеров разработчика образов контейнеров и администратора\nбезопасности информационной (автоматизированной) системы. Средство контейнеризации 6 класса защиты должно осуществлять выявление\nизвестных уязвимостей образов контейнеров не реже одного раза в месяц. 10.2. Средство контейнеризации 5 и 4 классов защиты наряду с\nтребованиями, установленными подпунктом 10.1 пункта 10 настоящих\nТребований, должно запрещать создание образов контейнеров, содержащих\nизвестные уязвимости критического и высокого уровня опасности. Средство контейнеризации 5 и 4 классов защиты должно осуществлять\nвыявление известных уязвимостей образов контейнеров не реже одного\nраза в неделю. 11. К проверке корректности конфигурации контейнеров в средстве\nконтейнеризации предъявляются следующие требования:\nСредство контейнеризации 6, 5 и 4 классов защиты должно обеспечивать:\nограничение прав прикладного программного обеспечения, выполняемого\nвнутри контейнера, на использование периферийных устройств, устройств\nхранения данных и съемных машинных носителей информации (блочных\nустройств), входящих в состав информационной\n(автоматизированной) системы;\nограничение прав прикладного программного обеспечения, выполняемого\nвнутри контейнера, на использование вычислительных ресурсов\n(оперативной памяти, операций ввода-вывода за период времени) хостовой\nоперационной системы; монтирование корневой файловой системы хостовой\nоперационной\nсистемы в режиме «только для чтения». 8. К контролю целостности контейнеров и их образов в средстве\nконтейнеризации предъявляются следующие требования:\n11. Средство контейнеризации 6 класса защиты должно:\nконтролировать самостоятельно или с применением средств\nконтроля целостности хостовой операционной системы и иных\nсертифицированных средств защиты информации целостность\nобразов контейнеров и исполняемых файлов контейнеров;\nинформировать администратора информационной\n(автоматизированной) системы и администратора безопасности\nсредства контейнеризации о нарушении целостности объектов\nконтроля. 12. Средство контейнеризации 5 класса защиты наряду с\nтребованиями, установленными подпунктом 12.1 пункта 12\nнастоящих Требований, должно контролировать целостность\nпараметров настройки средства контейнеризации. 13. Средство контейнеризации 4 класса защиты наряду с\nтребованиями, установленными подпунктами 12.1 и 12.2 пункта 12\nнастоящих Требований, должно:\nконтролировать целостность сведений о событиях безопасности\nсамостоятельно или во взаимодействии с хостовой операционной системой\nи иными сертифицированными средствами защиты информации;\nконтролировать целостность образов контейнеров и параметров настройки\nсредства контейнеризации при установке образа контейнера в\nинформационной (автоматизированной) системе и далее периодически за\nсчет применения цифровой подписи самостоятельно или во взаимодействии\nс хостовой операционной системой и иными сертифицированными средствами\nзащиты информации; блокировать запуск образа контейнера при нарушении\nего целостности. 9. К регистрации событий безопасности в средстве контейнеризации\nпредъявляются следующие требования:\n15. Средство контейнеризации 6 класса защиты должно:\nрегистрировать события, относящиеся к инцидентам безопасности средства\nконтейнеризации, связанные с попытками осуществления\nнесанкционированного доступа к средству контейнеризации;\nоповещать администратора безопасности средства контейнеризации и\nадминистратора информационной (автоматизированной) системы об\nинцидентах безопасности; выполнять действия, являющиеся реакцией на\nинциденты безопасности; осуществлять сбор и хранение записей в журнале\nсобытий безопасности,\nкоторые позволяют определить, когда и какие действия происходили. Регистрация событий безопасности в средстве контейнеризации должна\nосуществляться с учетом требований разделов 5-6 ГОСТ Р 59548-2022\n«Защита информации. Регистрация событий безопасности. Требования к\nрегистрируемой информации»^([7]). Для каждой функции безопасности в средстве контейнеризации должен быть\nопределен перечень событий, необходимых для регистрации и учета. Для регистрируемых событий безопасности в каждой записи журнала\nсобытий безопасности должны указываться номер (уникальный\nидентификатор) события, дата, время, тип события безопасности. Записи журнала событий безопасности должны представляться в\nструктурированном виде и содержать информацию о времени события\nбезопасности, взятую из хостовой операционной системы. Средство контейнеризации должно осуществлять запись событий\nбезопасности контейнеров в журнал событий безопасности информационной\n(автоматизированной) системы с указанием идентификатора контейнера. Журнал событий безопасности средства контейнеризации должен быть\nдоступен только для чтения. При исчерпании области памяти, отведенной\nпод журнал событий безопасности средства контейнеризации, средство\nконтейнеризации должно осуществлять архивирование журнала с\nпоследующей очисткой указанного журнала. Регистрации подлежат как минимум следующие события безопасности:\nнеуспешные попытки аутентификации пользователей средства\nконтейнеризации; создание, модификация и удаление образов контейнеров;\nполучение доступа к образам контейнеров; запуск и остановка\nконтейнеров с указанием причины остановки. изменение ролевой модели;\nмодификация запускаемых контейнеров. 13.2. Средство контейнеризации 5 класса защиты наряду с требованиями,\nустановленными подпунктом 13.1 пункта 13 настоящих Требований, должно\nрегистрировать следующие события безопасности:\nвыявление известных уязвимостей в образах контейнеров и\nнекорректности конфигурации; факты нарушения целостности объектов\nконтроля. Для каждого события безопасности должны регистрироваться: описание\nсобытия безопасности; сведения о критичности события безопасности. 13.3. Средство контейнеризации 4 класса защиты наряду с требованиями,\nустановленными подпунктами 13.1 и 13.2 пункта 13 настоящих Требований,\nдолжно обеспечивать запись событий безопасности контейнеров в журнал\nсобытий безопасности информационной (автоматизированной) системы с\nуказанием идентификатора пользователя хостовой операционной системы,\nот имени которого был запущен контейнер. 10. В средстве контейнеризации 6, 5 и 4 классов защиты должен быть\nреализован ролевой метод управления доступом с тремя ролями\nпользователей:\nразработчик образов контейнеров; администратор безопасности средства\nконтейнеризации; администратор информационной (автоматизированной)\nсистемы. 11. 1. Роль разработчика образов контейнеров должна позволять:\nменять установленный администратором безопасности средства\nконтейнеризации для разработчика пароль; создавать, модифицировать и\nудалять образы контейнеров. 12. 1. Роль администратора информационной (автоматизированной)\nсистемы должна позволять:\nменять установленный администратором безопасности средства\nконтейнеризации для администратора информационной (автоматизированной)\nсистемы пароль; запускать и останавливать контейнеры. 13. 1. Роль администратора безопасности средства контейнеризации\nдолжна позволять: назначать права доступа пользователям\nсредства контейнеризации к\nобразам контейнеров; создавать учетные записи пользователей средства\nконтейнеризации; управлять учетными записями пользователей средства\nконтейнеризации; иметь доступ на чтение к журналу событий безопасности\nсредства\nконтейнеризации; формировать отчеты с учетом заданных критериев\nотбора, выгрузку (экспорт) данных из журнала событий безопасности\nсредства контейнеризации. 14. К идентификации и аутентификации пользователей в средстве\nконтейнеризации предъявляются следующие требования:\n3. Первичная идентификация пользователей средства контейнеризации\n6 класса защиты должна осуществляться администратором\nбезопасности средства контейнеризации. Идентификация и аутентификация пользователей в средстве\nконтейнеризации осуществляется с учетом требований разделов 4-7 ГОСТ Р\n58833-2020 «Защита информации. Идентификация и аутентификация. Общие\nположения»^([8]). Средство контейнеризации должно осуществлять аутентификацию\nпользователей при предъявлении пароля пользователя. Пароль пользователя должен устанавливаться администратором\nбезопасности средства контейнеризации. Средство контейнеризации должно обеспечивать возможность смены\nустановленного администратором безопасности средства контейнеризации\nпароля пользователя после его первичной аутентификации. При попытке ввода неправильного значения пароля пользователя должно\nвыводиться соответствующее сообщение с приглашением ввести правильный\nпароль еще раз. При исчерпании установленного максимального количества неуспешных\nпопыток ввода неправильного пароля учетная запись пользователя\nсредства контейнеризации должна быть заблокирована средством\nконтейнеризации с возможностью разблокировки администратором\nбезопасности средства контейнеризации. Защита пароля пользователя должна обеспечиваться при его вводе за счет\nотображения вводимых символов условными знаками. Пароль пользователя средства контейнеризации 6 класса защиты должен\nсодержать не менее 6 символов при алфавите пароля не менее 60\nсимволов. Максимальное количество неуспешных попыток аутентификации\n(ввода неправильного пароля) до блокировки – 10. Средство контейнеризации должно обеспечивать хранение\nаутентификационной информации пользователя средства контейнеризации в\nзащищенном формате или в защищенном хранилище. 15.2. Пароль пользователя средства контейнеризации 5 класса защиты\nдолжен содержать не менее 6 символов при алфавите пароля не менее 70\nсимволов. Максимальное количество неуспешных попыток аутентификации\n(ввода неправильного пароля) до блокировки – 8. 15.3. Средство контейнеризации 4 класса защиты наряду с требованиями,\nустановленными подпунктом 15.1 пункта 15 не должно запускать процессы\nв хостовой операционной системе, обладающие привилегиями\nадминистратора информационной (автоматизированной) системы и\nадминистратора безопасности информационной (автоматизированной)\nсистемы. Пароль пользователя средства контейнеризации 4 класса защиты должен\nсодержать не менее 8 символов при алфавите пароля не менее 70\nсимволов. Максимальное количество неуспешных попыток аутентификации\n(ввода неправильного пароля) до блокировки – 4. 15. К централизованному управлению образами контейнеров и контейнерами\nв средстве контейнеризации предъявляются следующие требования:\n5. Средство контейнеризации 6 класса защиты должно:\nсоздавать, модифицировать, хранить, получать и удалять образы\nконтейнеров в информационной (автоматизированной) системе; обновлять\nобразы контейнеров;\nобеспечивать чтение, удаление записей о событиях безопасности,\nформирование отчетов с учетом заданных критериев отбора, выгрузку\n(экспорт) данных из журнала событий безопасности средства\nконтейнеризации. 16. 1. Средство контейнеризации 5 и 4 классов защиты наряду с\nтребованиями, установленными подпунктом 16.1 пункта 16\nнастоящих Требований, должно: анализировать возникающие\nсобытия безопасности в целях выявления\nинцидентов безопасности; оповещать администратора безопасности\nсредства контейнеризации о\nсобытиях безопасности; формировать отчеты. [1]  Статья 5 Федерального закона от 27 декабря 2002 г. № 184-ФЗ «О\nтехническом регулировании» (Собрание законодательства Российской\nФедерации, 2002, № 52, ст. 5140; 2007, № 19, ст. 2293; 2011, № 49, ст. 7025; 2016, № 15, ст. 2066). [2]  Статья 7 Федерального закона от 26 июля 2017 г. № 187-ФЗ «О\nбезопасности критической информационной инфраструктуры Российской\nФедерации» (Собрание законодательства Российской Федерации, 2017, № 31,\nст. 4736), Правила категорирования объектов критической информационной\nинфраструктуры Российской Федерации, утвержденные постановлением\nПравительства Российской Федерации от 8 февраля 2018 г. № 127 (Собрание\nзаконодательства Российской Федерации, 2018, № 8, ст. 1204; 2019, № 16,\nст. 1955). [3]  Требования о защите информации, не составляющей государственную\nтайну, содержащейся в государственных информационных системах,\nутвержденные приказом ФСТЭК России от 11 февраля 2013 г. № 17\n(зарегистрирован Минюстом России 31 мая 2013 г., регистрационный №\n28608) (с изменениями, внесенными приказом ФСТЭК России от 15 февраля\n2017 г. № 27 (зарегистрирован Минюстом России 14 марта 2017 г.,\nрегистрационный № 45933) и приказом ФСТЭК России от 28 мая 2019 г. № 106\n(зарегистрирован Минюстом России 13 сентября 2019 г., регистрационный №\n55924). [4]  Требования к обеспечению защиты информации в автоматизированных\nсистемах управления производственными и технологическими процессами на\nкритически важных объектах, потенциально опасных объектах, а также\nобъектах, представляющих повышенную опасность для жизни и здоровья людей\nи для окружающей природной среды, утвержденные приказом ФСТЭК России от\n14 марта 2014 г. № 31 (зарегистрирован Минюстом России 30 июня 2014 г.,\nрегистрационный № 32919) (с изменениями, внесенными приказом ФСТЭК\nРоссии от 23 марта 2017 г. № 49 (зарегистрирован Минюстом России 25\nапреля 2017 г., регистрационный № 46487), приказом ФСТЭК России от 9\nавгуста 2018 г. № 138 (зарегистрирован Минюстом России 5 сентября 2018\nг., регистрационный № 52071) и приказом ФСТЭК России от 15 марта 2021 г. № 46 (зарегистрирован Минюстом России 1 июля 2021 г., регистрационный №\n64063). [5]  Требования к защите персональных данных при их обработке в\nинформационных системах персональных данных, утвержденные постановлением\nПравительства Российской Федерации от 1 ноября 2012 г. № 1119 (Собрание\nзаконодательства Российской Федерации, 2012, № 45, ст. 6257). [6]  Требования о защите информации, содержащейся в информационных\nсистемах общего пользования, утвержденные приказом ФСБ России и ФСТЭК\nРоссии от 31 августа 2010 г. № 416/489 (зарегистрирован Минюстом России\n13 октября 2010 г., регистрационный № 18704). [7]  Утвержден и введен в действие приказом Федерального агентства по\nтехническому регулированию и метрологии от 13 января 2022 г. № 2-ст (М.,\n«Стандартинформ», 2022). [8]  Утвержден и введен в действие приказом Федерального агентства по\nтехническому регулированию и метрологии от 10 апреля 2020 г. № 159-ст\n(М., «Стандартинформ», 2020)."}