Куда я попал?
Правила № 2-020101-174 от 01.07.2024
Правила классификации и постройки морских судов часть XXI
3. Киберустойчивость систем
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
3.1.2. Киберустойчивость.
Требования к киберустойчивости, изложенные в 3.3, относятся ко всем системам, входящим в область применения настоящей части. Дополнительные требования, связанные со взаимодействием с ненадежными сетями, применяются только к системам, в которых такое взаимодействие предусмотрено. -
3.1.4.1. Компенсирующие меры могут применяться вместо или в дополнение к существующим мерам и средствам безопасности для удовлетворения одного или нескольких требований безопасности. Компенсирующие меры должны соответствовать замыслу и строгости первоначально заявленного требования, с учетом стандартов, на которые даны ссылки, а также различий между каждым требованием и соответствующими пунктами стандартов, и следовать принципам, указанным в 3.2.1.3.
-
2) должны быть описаны любые сетевые интерфейсы с другими КС, входящими в область применения настоящей части. Описание должно включать КС назначения, потоки данных и протоколы связи. В случае, если системный интегратор выделил КС назначения в другую зону безопасности, то должны быть подробно описаны компоненты, обеспечивающие защиту границы зоны безопасности (см. 2.2.2.1), если они поставляются в составе КС;
-
3) также должны быть описаны любые сетевые интерфейсы к другим системам или сетям, не входящими в область применения настоящей части (ненадежные сети). В описании должно быть указано соответствие дополнительным функциональным возможностям обеспечения безопасности, перечисленным в 3.3.2, а также содержаться соответствующие процедуры или инструкции для экипажа. Компоненты, обеспечивающие защиту границы зоны безопасности (см. 2.2.2.1), должны быть подробно описаны, если они поставляются в составе КС;
-
3.2.1.5. Руководство по конфигурации безопасности.
В документе должны быть описаны рекомендуемые параметры конфигурации функциональных возможностей обеспечения безопасности и указаны значения по умолчанию. Цель документа заключается в том, чтобы обеспечить реализацию функциональных возможностей обеспечения безопасности в соответствии с требованиями разд. 2 и любыми спецификациями системного интегратора (например, учетные записи пользователей, авторизация, политика паролей, безопасное состояние оборудования, правила брандмауэра и т.д.).
Документ должен служить основанием для проверки выполнения п. 29 табл. 3.3.1. -
3.2.1.6. Документы по жизненному циклу безопасной разработки.
Документация представляется по требованию Регистра. В документации должны быть описаны процессы и процедуры поставщика в соответствии с требованиями к жизненному циклу безопасной разработки, изложенными в 3.4. Должен быть описан процесс обновления ПО и установки патчей. Документ представляется с целью подготовки к освидетельствованию в соответствии с 3.5.3.4. -
3.2.1.7. Планы технического обслуживания и верификации КС.
Документы должны представляться по требованию Регистра, в документах должны содержаться процедуры технического обслуживания и испытаний системы, связанные с безопасностью. Документы должны содержать инструкции для пользователя по проверке работы функций безопасности системы в соответствии с требованиями п. 19 табл. 3.3.1. -
3.2.1.8. Информация для поддержки разработки планов реагирования и восстановления в случае киберинцидента.
Документ представляется по требованию Регистра, в документе должны содержаться процедуры или инструкции, позволяющие пользователю выполнить следующее:- местное независимое управление (см. 2.2.4.2);
- изоляцию сети (см. 2.2.4.3);
- расследование киберинцидента с использованием записей аудита (см. п. 13 табл. 3.3.1);
- детерминировать поток выходных сигналов (см. 2.2.4.4 и п. 20 табл. 3.3.1);
- резервирование (см. п. 26 табл. 3.3.1);
- восстановление (см. п. 27 табл. 3.3.1);
- контролируемое отключение, сброс, откат и повторный запуск (см. 2.2.5.3).
-
3.2.1.10. Протоколы испытаний.
КС, имеющие Свидетельство о типовом одобрении (СТО) РС, подтверждающее соответствие функциональных возможностей обеспечения безопасности данного раздела, могут быть освобождены от освидетельствования. Однако Регистру должны быть представлены протоколы испытаний, заверенные поставщиком и подтверждающие, что поставщик завершил проектирование, изготовление, испытания, настройку и усиление защиты, которые в случае отсутствия СТО проверяются Регистром при освидетельствовании (см. 3.5.3). -
3.3.2. Дополнительные функциональные возможности обеспечения безопасности.
Для КС с сетевым подключением к ненадежным сетям (т.е. интерфейсом к любым сетям, не входящим в область применения настоящей части) предъявляются дополнительные требования согласно табл. 3.3.2.
КС, которые взаимодействуют через границу зоны безопасности, должны также соответствовать требованиям к сегментации сети и защите границ зон, указанным в 2.2.2.1 и 2.2.2.2. -
При разработке систем или оборудования должен соблюдаться жизненный цикл безопасной разработки (secure development lifecycle (SDLC)), учитывающий аспекты безопасности на следующих этапах:
- этап анализа требований;
- этап проекта;
- этап внедрения;
- этап проверки;
- этап выпуска;
- этап технической поддержки;
- этап окончания срока службы.
Должен быть подготовлен и представлен Регистру на рассмотрение и одобрение документ, описывающий, каким образом на вышеуказанных этапах учтены аспекты безопасности и, как минимум, содержащий описание управляемых процессов, указанных в 3.4.1 — 3.4.7. -
Демонстрация соответствия требованиям безопасности в рамках конкретного проекта.
Если КС имеет СТО, подтверждающее соответствие требованиям разд. 3, то идет процесс "Одобрение документации. Сокращённый пакет документов", и завершается выдачей "Свидетельство на систему (см. 7.9.5.2.7, часть XV «Автоматизация»)".
Если КС не имеет СТО, подтверждающее соответствие требованиям разд. 3, то идет процесс "Одобрение документации. полный комплект документов", далее процесс "Освидетельствование и заводские приемосдаточные испытания (FAT)", и завершается выдачей "Свидетельство на систему (см. 7.9.5.2.7, часть X V «Автоматизация»)". -
Типовое одобрение является добровольным и применяется к КС, которые являются стандартными и изготавливаются в режиме установившегося производства. Требования к сертификации и типовому одобрению КС изложены в 7.9.5.2.4 части XV «Автоматизация».
Процессы, представленные на рис. 3.5.1-1 и 3.5.1-2, применяются также, если для навигационного оборудования и оборудования радиосвязи используются другие эквивалентные стандарты (см. 1.1.5). В таком случае:- процесс на рис. 3.5.1-1 иллюстрирует, является ли эквивалентный стандарт обязательным (вместо требований разд. 3).
- процесс на рис. 3.5.1-2 иллюстрирует, что процесс сертификации может быть сокращен, если КС имеет СТО в соответствии с эквивалентным стандартом.
-
3.5.3.1. Общие элементы освидетельствования.
Поставщик должен продемонстрировать, что проектирование, изготовление и внутренние испытания были завершены. Также должно быть продемонстрировано, что поставляемая система соответствует одобренной документации. Это должно быть сделано путем проверки системы и сравнения компонентов и расположения/архитектуры с Ведомостью КС (см. 3.2.1.1) и топологическими схемами (см. 3.2.1.2). -
3.5.3.2. Испытания функциональных возможностей обеспечения безопасности.
Поставщик должен провести испытания требуемых функциональных возможностей обеспечения безопасности поставляемой системы. Испытания должны проводиться в соответствии с одобренной программой испытаний, указанной в 3.2.1.4, в присутствии инспектора РС.
Испытания должны продемонстрировать инспектору РС, что все требования выполнены. Испытание идентичных компонентов как правило не требуется. -
3.5.3.3. Правильная конфигурации функциональных возможностей обеспечения безопасности.
Поставщик должен продемонстрировать инспектору РС, что параметры безопасности в компонентах системы сконфигурированы в соответствии с рекомендациями, приведенными в 3.2.1.5. Эта демонстрация может быть проведена совместно с проверкой функциональных возможностей обеспечения безопасности.
Параметры безопасности должны быть задокументированы в отчете, например, в руководстве по конфигурации для конкретного судна. -
3.5.3.4.2. Документация по обновлениям безопасности (см. IEC 62443-4-1:2018/SUM-2).
Поставщик должен представить документацию по системе менеджмента, подтверждающую, что в организации внедрен процесс, обеспечивающий информирование пользователей об обновлениях системы безопасности. Информация для пользователей должна включать элементы, перечисленные в 3.4.2. -
3.5.3.4.3. Документация по обновлениям безопасности зависимых компонентов (см. IEC 62443-4-1:2018/SUM-3).
Поставщик должен представить документацию по системе менеджмента в соответствии с требованиями 3.4.3, подтверждающую, что в организации внедрен процесс, гарантирующий информирование пользователей о том, совместима ли система с обновленными версиями приобретенного ПО в системе (новые версии/патчи операционной системы или микропрограммы). Информация должна касаться того, как управлять рисками, связанными с неприменением обновленного приобретенного ПО -
3.5.3.4.4. Поставка обновлений безопасности (см. IEC 62443-4-1:2018/SUM-4).
Поставщик должен представить документацию по системе менеджмента в соответствии с требованиями 3.4.4, подтверждающую, что в организации внедрен процесс, обеспечивающий доступность обновлений безопасности системы для пользователей и описывающий, как пользователь может проверить подлинность обновленного ПО. -
3.5.3.4.5. Эшелонированная защита изделия (см. IEC 62443-4-1:2018/SG-1).
Поставщик должен представить документацию по системе менеджмента в соответствии с требованиями 3.4.5, подтверждающую, что в организации внедрен процесс по документированию стратегии мер эшелонированной защиты с целью снижения угроз безопасности ПО в КС во время установки, технического обслуживания и эксплуатации.
Примерами угроз могут быть установка несанкционированного ПО, слабые места в процессе исправления, вмешательство в ПО на этапе эксплуатации судна. -
3.5.3.4.6. Меры эшелонированной защиты, в ожидаемых условиях внешней среды работы (см. IEC 62443-4-1:2018/SG-2).
Поставщик должен представить документацию по системе менеджмента в соответствии с требованиями 3.4.6, подтверждающую, что в организации внедрен процесс документирования мер эшелонированной защиты, которые, как ожидается, будут обеспечены внешней средой, таких как физическое расположение, политика и процедуры. -
3.5.3.4.7. Рекомендации по усилению безопасности (см. IEC 62443-4-1:2018/SG-3).
Поставщик должен представить документацию по системе менеджмента, в соответствии с требованиями 3.4.7, подтверждающую, что в организации внедрен процесс, гарантирующий разработку руководства по усилению безопасности системы. В руководстве должно быть указано, как уменьшить уязвимости в системе путем удаления/запрета/отключения ненужного ПО, учетных записей, служб и т.д.
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.