Правила классификации и постройки морский судов № 2-020101-174 от 01.07.2024

2.2.1.1.1. Требование.  

Должна быть разработана и поддерживаться в актуальном состоянии в течение всего срока службы судна Ведомость с указанием аппаратного и программного обеспечения (включая приложения, операционные системы, если таковые имеются, микропрограммы и другие компоненты ПО) КС, входящих в область применения настоящей части, а также сетей, соединяющих такие системы друг с другом и с другими судовыми или береговыми КС.  

Ведомость судовых КС должна включать, по крайней мере, КС, указанные в 1.1.3 — 1.1.6, если они имеются на борту. 
Ведомость судовых КС должна актуализироваться в течение всего срока службы судна. В ней должны регистрироваться изменения аппаратного и программного обеспечения, которые могут привести к появлению новых уязвимостей или затрагивающие функциональные зависимости или связи между системами. 
В случае внесения в Ведомость судовых КС конфиденциальной информации (например, IP-адресов, протоколов, номеров портов) должны приниматься специальные меры для ограничения несанкционированного доступа к такой информации. 

2.2.1.1.2.1. Аппаратное обеспечение:  

2.2.1.1.2.2. Программное обеспечение (ПО): 
1) в Ведомость судовых КС должно быть включено все ПО, входящее в область применения настоящей части (например, приложения, операционные системы, микропрограммы), при этом в Ведомости, по крайней мере, должна содержаться информация, указанная в 3.2.1.1;  
2) ПО КС, входящих в область применения настоящей части, должно обслуживаться и обновляться в соответствии с процессом по управлению обслуживанием ПО и политикой обновления, описанным судовладельцем в Программе кибербезопасности и киберустойчивости судна (см. 2.3.3.1). 

О б ос н о в а н и е . Ведомость судовых КС и соответствующего ПО, используемого в OT-системах, имеет важное значение для эффективного управления киберустойчивостью судна, поскольку каждая КС потенциально содержит уязвимости. Для взлома систем злоумышленники могут использовать неучтенное и устаревшее оборудование и ПО. Кроме того, учет КС позволяет судовладельцу понять критичность каждой системы для обеспечения безопасности судна.  

2.2.1.1.3.1. Этап проектирования:  

2.2.1.1.3.2. Этап постройки: 

2.2.1.1.3.3. Этап ввода в эксплуатацию: 

1) в Программе кибербезопасности и киберустойчивости судна судовладельцем должен быть описан процесс управления изменениями для всех КС, входящих в область применения настоящей части, учитывающий как минимум следующие требования:  

2) в Программе кибербезопасности и киберустойчивости судна судовладельцем также должен быть описан процесс управления обновлениями ПО, учитывающий как минимум следующие требования: 

3) первое ежегодное освидетельствование.  
Судовладелец должен представить Регистру записи или иные задокументированные свидетельства, подтверждающие выполнение Программы кибербезопасности и киберустойчивости судна, а именно того, что: 

2.2.2.1.1. Требование: 

2) сеть(и) зоны безопасности должны быть логически и/или физически сегментированы от других зон или сетей; 

3) КС, обеспечивающие необходимую функциональную безопасность, должны быть сгруппированы в отдельные зоны безопасности и должны быть физически сегментированы от других зон безопасности; 

4) системы навигации и связи не должны находиться в той же зоне безопасности, что системы обслуживания механизмов и грузовые системы. Если системы навигации и радиосвязи одобрены в соответствии с иными эквивалентными стандартами (см. 1.1.5), то они должны находится в отдельной зоне безопасности; 

6) системы, сети и КС, не входящие в область применения настоящей части, считаются ненадежными сетями и должны быть физически сегментированы от зон безопасности, требуемых настоящим разделом. В качестве альтернативы допускается включение этих OT-систем в зону безопасности других КС, если они отвечают требованиям, установленными для этой зоны безопасности; 

7) должна обеспечиваться возможность изоляции зоны безопасности без ущерба для основной функциональности КС в этой зоне. 

1) системный интегратор должен представить Регистру Схему зон безопасности и каналов связи, а также Описание мер обеспечения кибербезопасности (см. 2.3.1.1 и 2.3.1.2); 

2) Схема зон безопасности и каналов связи должна отражать каким образом КС, входящие в область применения настоящей части, сгруппированы в зоны безопасности и включать в себя следующее: 

3) в Описание мер обеспечения кибербезопасности системным интегратором должна быть включена следующая информация: 

2.2.2.1.3.2. Этап постройки:

2.2.2.1.3.3. Этап ввода в эксплуатацию: 

1) в Программе кибербезопасности и киберустойчивости судна судовладельцем должен быть описан процесс управления оборудованием, ограничивающим зоны безопасности (например, межсетевыми экранами), учитывающий как минимум следующие требования: 

2) первое ежегодное освидетельствование. 
Судовладелец должен продемонстрировать Регистру, что Схема зон безопасности и каналов связи поддерживается в актуальном состоянии, а также представить записи или иные задокументированные свидетельства, подтверждающие выполнение Программы кибербезопасности и киберустойчивости судна, а именно того, что границы зон безопасности управляются в соответствии с вышеуказанными требованиями; 

2) должна обеспечиваться защита сетей от возникновения чрезмерного потока данных и других факторов, способных оказать негативное влияние на работу сетевых ресурсов; 

3) КС, входящие в область применения настоящей части, должны строиться в соответствии с принципом наименьшей функциональности, т.е. быть сконфигурированными на предоставление только необходимых функциональных возможностей и на запрет или ограничение использования второстепенных функций. Функции, порты, протоколы и службы, не являющиеся необходимыми, должны быть отключены или запрещены иным образом. 

2.2.2.2.2. Детализация требования. 
При проектировании сети с целью минимизации риска событий типа «отказ в обслуживании» (DoS) и сетевого шторма/высокой скорости трафика, необходимо предусмотреть средства ограничения скорости потока данных до уровня, соответствующего предполагаемому потоку данных, проходящему через сеть. При оценке скорости потока данных необходимо учитывать, как минимум, пропускную способность сети, требования к скорости передачи данных для предполагаемого приложения и формата данных. 

2.2.2.2.3.3. Этап ввода в эксплуатацию: 

2.2.2.3.1. Требование. 
КС, входящие в область применения настоящей части, должны быть защищены от вредоносного кода, такого как вирусы, «черви», «троянские кони», шпионские программы и т.д. 

1) в КС, входящих в область применения настоящей части, должна быть предусмотрена защита от вредоносного ПО. На КС, работающих под операционной системой, для которой доступно и поддерживается в актуальном состоянии стандартное антивирусное и антивредоносное ПО, такое ПО должно быть установлено, обслуживаться и регулярно обновляться, если только установка такого ПО не снижает способность КС выполнять необходимые функции и обеспечивать уровень обслуживания (например, для КС категорий II и III, выполняющих задачи в режиме реального времени); 

2)  если на КС невозможно установить ПО для защиты от вредоносного ПО, такая защита должна быть реализована в виде эксплуатационных процедур, физических средств защиты или в соответствии с рекомендациями изготовителя. 

2.2.2.3.3.1. Этап проектирования: 

2.2.2.3.3.2. Этап постройки: 

2.2.2.3.3.3. Этап ввода в эксплуатацию: 

1) в Программе кибербезопасности и киберустойчивости судна судовладелец должен описать процесс управления антивредоносной защитой, учитывающий как минимум следующие требования: 

2) первое ежегодное освидетельствование. 
Судовладелец должен представить Регистру записи или иные задокументированные свидетельства, подтверждающие выполнение Программы кибербезопасности и киберустойчивости судна, а именно то, что: 

2.2.2.4.1. Требование. 
В КС и сетях, входящих в область применения настоящей части, должны быть обеспечены физические и/или логические средства для выборочного ограничения функциональности и средств для связи или иного взаимодействия с самой системой, использования системных ресурсов для обработки информации, получения сведений об информации, которую содержит система, или управления компонентами и функциями системы. Эти средства должны быть такими, чтобы не препятствовать доступу уполномоченного персонала к КС с их уровнем доступа в соответствии с принципом наименьших привилегий. 

Доступ к КС и сетям, входящим в область применения настоящей части, а также ко всей информации, хранящейся в этих системах, должен быть разрешен только уполномоченному персоналу исходя из их производственной потребности доступа к информации в рамках своих обязанностей. 

2.2.2.4.2.1. Контроль физического доступа. 
КС категорий II и III с целью предотвращения несанкционированного доступа должны располагаться в запираемых помещениях или контролируемом пространстве, или устанавливаться в запираемых шкафах или консолях. Эти места или запираемые шкафы/консоли должны быть легкодоступными для экипажа и различных заинтересованных сторон, которым необходим доступ к КС для установки, интеграции, работы, технического обслуживания, ремонта, замены, утилизации и т.д., чтобы не препятствовать эффективной и действенной эксплуатации судна. 

2.2.2.4.2.2. Контроль физического доступа для посетителей. 
Доступ к судовым КС посетителей, таких как представители власти, технические специалисты, агенты, должностные лица порта, а также представители судовладельца должен быть ограничен, например, посредством разрешения доступа только под наблюдением. 

2.2.2.4.2.3. Контроль физического доступа к точкам подключения к сети:

2) контроль доступа к судовым КС должен обеспечиваться в соответствии с политикой зоны безопасности, при этом не должно оказываться негативного влияния на работу по назначению КС. КС, требующие строгого контроля доступа, могут быть защищены с помощью надежного ключа шифрования или многофакторной аутентификации; 

3) управление привилегиями администратора должно осуществляться в соответствии с политикой контроля доступа. Полный доступ к КС должен предоставляться только уполномоченным и соответствующим образом обученным лицам, которые в рамках своих должностных обязанностей в береговых подразделениях судовладельца или на борту судна должны входить в системы с использованием этих привилегий 

1) любому пользователю – физическому лицу, допущенному к КС и сетям, входящим в область применения настоящей части, должны предоставляться только минимальные привилегии, достаточные для выполнения его функций; 

2) по умолчанию должен быть установлен минимальный уровень привилегий для всех новых учетных записей. По возможности, повышенные привилегии должны быть ограничены только теми моментами, когда они необходимы, например, с использованием только временных привилегий и учетных записей однократного использования. Должно обеспечиваться предотвращение накопления привилегий с течением времени, например, путем регулярного аудита учетных записей пользователей. 

2.2.2.4.3.1. Этап проектирования: 

2.2.2.4.3.2. Этап постройки. 
На этапе постройки судна системный интегратор должен обеспечить предотвращение несанкционированного доступа к КС. 

2.2.2.4.3.3. Этап ввода в эксплуатацию:

1) в Программе кибербезопасности и киберустойчивости судна судовладельцем должен быть описан процесс управления логическим и физическим доступом, учитывающий, как минимум, следующие требования: 

2) в Программе кибербезопасности и киберустойчивости судна судовладельцем должен быть описан процесс управления конфиденциальной информацией, учитывающий как минимум следующие требования: 

3) первое ежегодное освидетельствование. 
Судовладелец должен представить Регистру записи или иные задокументированные свидетельства, подтверждающие выполнение Программы кибербезопасности и киберустойчивости судна, т.е. того, что: 

2.2.2.5.1. Требование. 
Беспроводные сети, входящие в область применения настоящей части, должны быть спроектированы, построены и обслуживаться таким образом, чтобы:

1) для обеспечения целостности и конфиденциальности информации, передаваемой по беспроводной сети, должны применяться механизмы криптографии, такие как алгоритмы шифрования и длины ключей в соответствии с отраслевыми стандартами и передовой практикой; 

2) устройства в беспроводной сети должны обмениваться данными только в беспроводной сети (т.е. они не должны иметь двойного соединения); 

4) беспроводные точки доступа и другие устройства в сети должны быть установлены и настроены таким образом, чтобы можно было контролировать доступ к сети 

5) сетевые устройства или системы, использующие беспроводное соединение, должны обеспечивать возможность идентификации и аутентификации всех пользователей (людей, программных процессов или устройств), участвующих в этом соединении. 

2.2.2.5.3.1. Этап проектирования. 
В Описание мер обеспечения кибербезопасности системным интегратором должна быть включена следующая информация: описание беспроводных сетей, входящих в область применения настоящей части. 
Описание должно включать оборудование, ограничивающее зону безопасности, и разрешенный трафик (например, правила межсетевого экрана). 

2.2.2.5.3.2. Этап постройки. 
На этапе постройки судна системный интегратор должен обеспечить предотвращение несанкционированного доступа к беспроводным сетям. 

2.2.2.5.3.3. Этап ввода в эксплуатацию: 

2.2.2.5.3.4. Этап эксплуатации:

2.2.2.6.1. Требование.
КС, входящие в область применения настоящей части, должны быть защищены от несанкционированного доступа и других киберугроз, исходящих из ненадежных сетей.

2.2.2.6.2.1. Проектирование. 
КС, входящие в область применения данного раздела, должны: 

1) должна представляться документация, описывающая как происходят соединение и интеграция с береговым участком; 

2) перед установкой патчи безопасности и обновления должны тестироваться и оцениваться, чтобы убедиться в их эффективности и отсутствии недопустимых побочных эффектов или появления киберсобытий. Перед проведением удаленного обновления должен быть получен соответствующий отчет от поставщика ПО; 

4) при проведении удаленного технического обслуживания уполномоченный персонал на борту судна в любое время должен иметь возможность прервать сеанс, отменить работу и вернуться к предыдущей безопасной конфигурации КС и затрагиваемых систем; 

5) любой доступ к КС пользователей из ненадежных сетей должен предоставляться с использованием многофакторной аутентификации; 

6) после настраиваемого количества неудачных попыток получения удаленного доступа следующая попытка должна блокироваться на заранее определенный период времени; 

7) если по какой-либо причине при удаленном обслуживании происходит прерывание соединения, доступ к системе должен быть прекращен функцией автоматического выхода из системы. 

2.2.2.6.3.1. Этап проектирования: 

2.2.2.6.3.3. Этап ввода в эксплуатацию: 

1) в Программе кибербезопасности и киберустойчивости судна судовладельцем должен быть описан процесс управления удаленным доступом и взаимодействия с ненадежными сетями, учитывающий как минимум следующие требования: 

2) первое ежегодное освидетельствование. 
Судовладелец должен представить Регистру записи или иные задокументированные свидетельства, подтверждающие выполнение Программы кибербезопасности и киберустойчивости судна, т.е. того, что: 

2.2.2.7.3.1. Этап проектирования: 

2.2.2.7.3.2. Этап постройки.

1) в Программе кибербезопасности и киберустойчивости судна судовладельцем должен быть описан процесс управления носимыми и переносными устройствами, учитывающий, как минимум, следующие требования: 

2) первое ежегодное освидетельствование. 
Судовладелец должен представить Регистру записи или иные задокументированные свидетельства, подтверждающие выполнение Программы кибербезопасности и киберустойчивости судна, т.е. того, что: 

2.2.3.1.1. Требование. 
Сети, входящие в область применения настоящей части, должны постоянно контролироваться, и в случае возникновения неисправностей или снижения/ухудшения пропускной способности должны срабатывать сигналы тревоги. 

1) средства мониторинга сетей, входящих в область применения настоящей части, должны обеспечивать: 

2) при соблюдении нижеследующих условий допускается использование системы обнаружения вторжений (IDS): 

О б о с н о в а н и е . Кибератаки становятся все более изощренными, и атаки, направленные на уязвимые места, которые были неизвестны на момент постройки судна, могут привести к инцидентам, при которых судно окажется плохо подготовленным к угрозе. Для раннего реагирования на атаки, направленные на эти типы неизвестных уязвимостей, необходима технология, способная обнаруживать нестандартные события. Система мониторинга, способная обнаруживать аномалии в сетях и проводить анализ после инцидента, обеспечивает возможность надлежащего реагирования и дальнейшего восстановления после киберсобытия. 

1) системный интегратор должен включить проверку средств мониторинга и защиты сети в Программу испытаний киберустойчивости судна, а также продемонстрировать Регистру, что: 

2) любая система обнаружения вторжений (IDS) в КС, входящих в область применения настоящей части, подлежит техническому наблюдению Регистра. Соответствующая документация должна быть представлена на одобрение Регистру с последующим освидетельствованием на борту судна. 

1) в Программе кибербезопасности и киберустойчивости судна судовладельцем должны быть описаны мероприятия по определению аномалий в КС и сетях, учитывающие как минимум следующие требования: 

2) первое ежегодное освидетельствование. 
Судовладелец должен представить Регистру записи или иные задокументированные свидетельства, подтверждающие выполнение Программы кибербезопасности и киберустойчивости судна, т.е. того, что: 

2.2.3.2.1. Требование. 
КС и сети, входящие в область применения настоящей части, должны обеспечивать контроль работоспособности и исправности функций безопасности, требуемых настоящим разделом. Функции диагностики должны обеспечивать пользователю достаточную информацию о состоянии и целостности КС, а также средства поддержания собственной работоспособности для обеспечения безопасной эксплуатации судна. 

2.2.3.2.2. Детализация требования:

О б о с н о в а н и е . Для обеспечения управления киберустойчивостью в течение всего срока службы судна важную роль играет возможность проверки работы функций безопасности. Диагностические инструменты могут включать в себя автоматические или ручные средства, такие как средства самодиагностики каждого устройства, или инструменты для мониторинга сети (например, ping, traceroute, ipconfig, netstat, nslookup, Wireshark, nmap и т.д.). 
Однако следует отметить, что выполнение диагностических функций может иногда влиять на эксплуатационные характеристики КС. 

2.2.3.2.3.3. Этап ввода в эксплуатацию: 

1) в Программе кибербезопасности и киберустойчивости судна судовладельцем должны быть описаны мероприятия по проверке правильности работы функций безопасности КС и сетей, учитывающие, как минимум, следующие требования: 

2) первое ежегодное освидетельствование. 
Судовладелец должен представить Регистру записи или иные задокументированные свидетельства, подтверждающие выполнение Программы кибербезопасности и киберустойчивости судна, т.е. того, что: 

2.2.4.1.1. Требование.
Судовладельцем должен быть разработан план действий в случае киберинцидента, охватывающий соответствующие нештатные ситуации и определяющий порядок реагирования на киберинциденты. В Плане действий в случае киберинцидента должен быть задокументирован заранее определенный набор инструкций или процедур по обнаружению, реагированию и ограничению последствий инцидентов, направленных против КС, входящих в область применения данного раздела. 

1) для разработки Плана действий в случае киберинцидента, различные заинтересованные стороны, участвующие в этапах проектирования и постройки судна, должны предоставить судовладельцу необходимую информацию. Во время первого ежегодного освидетельствования План действий в случае киберинцидента должен быть на борту судна. План действий в случае киберинцидента должен постоянно поддерживаться в актуальном состоянии (например, после технического обслуживания) в течение всего срока эксплуатации судна; 

2) в Плане действий в случае киберинцидента должны быть описаны процедуры уведомления соответствующих должностных лиц о произошедших киберинцидентах, с сообщением принятых мер по реагированию на киберинцидент и ограничению распространения киберинцидента на другие сегменты сети; 

3) План действий в случае киберинцидента должен содержать, как минимум, следующую информацию: 

4) План действий в случае киберинцидента должен храниться в твердой копии и быть доступным в случае полной потери электронных устройств. 

1) в Программе кибербезопасности и киберустойчивости судна судовладельцем должен быть описан План действий в случае киберинцидента, учитывающий, как минимум, следующие требования: 

2) первое ежегодное освидетельствование. 
Судовладелец должен представить Регистру записи или иные задокументированные свидетельства, подтверждающие выполнение Программы кибербезопасности и киберустойчивости судна, т.е. того, что: 

2.2.4.2.1. Требование. 
Любая КС, необходимая для местного управления, требуемого 2.3.4 части XV «Автоматизация», должна быть независимой от основной системы управления. Это также относится к человеко-машинному интерфейсу (HMI), необходимому для работы местного управления. 

1) КС для местного управления и контроля должны быть автономными и работать по прямому назначению независимо от связей с другими КС; 

4) КС для местного управления и контроля должны также соответствовать другим требованиям настоящей части. 

2.2.4.2.3.1. Этап проектирования:

2.2.4.2.3.3. Этап ввода в эксплуатацию: 

2.2.4.3.1. Требование. 
Должна быть обеспечена возможность прерывания сетевого соединения с зоной безопасности. 

1) если План действий в случае киберинцидента предписывает выполнить изоляцию сети, должна обеспечиваться возможность изоляции зон безопасности по соответствующей процедуре, например, с помощью физического переключателя «ВКЛ/ВЫКЛ» на сетевом устройстве, отсоединением кабеля от маршрутизатора/брандмауэра или других аналогичных действий. Должны быть доступны инструкции и четкая маркировка на оборудовании, позволяющая экипажу эффективно изолировать сеть; 

2) необходимо определить зависимости отдельных систем от данных, которые могут повлиять на функциональность и штатную работу, включая безопасность, с четким указанием, где необходимо предусмотреть меры резервирования данных или функциональных входов, в случае изоляции сегмента сети во время непредвиденной ситуации. 

2.2.4.3.3.1. Этап проектирования:

2.2.4.3.3.3. Этап ввода в эксплуатацию:

2.2.4.4.1. Требование. 
В случае киберинцидента, затрагивающего способность КС или сети, входящих в область применения настоящей части, выполнять требуемые функции по назначению, система или сеть должна обеспечивать возможность перехода в состояние минимального риска, т.е. привести себя в стабильное, безопасное состояние. 

1) при обнаружении киберинцидента, затрагивающего КС или сеть и ставящего под угрозу способность системы выполнять требуемые функции по назначению, система незамедлительно должна быть переведена в приемлемое безопасное состояние. Действия по возврату в безопасное состояние могут включать: 

2) возврат к состоянию минимального риска должен происходить в течение времени, достаточного для поддержания судна в безопасном состоянии; 

3) способность системы возвращаться в состояние минимального риска должна быть учтена на этапе проектирования поставщиком и системным интегратором. 

2.2.4.4.3.1. Этап проектирования: 

2.2.4.4.3.3. Этап ввода в эксплуатацию:

2.2.5.1.1. Требование. 
Судовладелец должен разработать План восстановления для возвращения рабочего состояния КС, входящих в область применения настоящей части, после сбоя, вызванного киберинцидентом. План восстановления должен включать в себя подробную информацию о том, где и кем может быть оказана поддержка. 

1) различные заинтересованные стороны, участвующие в проектировании и постройке судна, должны представить судовладельцу информацию для разработки Плана восстановления, который должен быть на борту во время первого ежегодного освидетельствования. План восстановления должен поддерживаться в актуальном состоянии (например, после технического обслуживания) в течение всего срока эксплуатации судна; 

2) План восстановления должен быть понятным для экипажа и берегового персонала и должен включать в себя основные инструкции и процедуры для обеспечения восстановления отказавшей системы, а также, в случае необходимости, способы получения внешней поддержки с берега. Кроме того, на борту должны быть доступны средства или инструменты для восстановления; 

3) при разработке Плана восстановления должны быть указаны различные задействованные системы и подсистемы. Также должны быть определены следующие цели восстановления: 

4) после определения целей восстановления должен быть составлен список потенциальных киберинцидентов, а также разработана и описана процедура восстановления; 

5) План восстановления должен включать следующую информацию или же ссылки на нее: 

6) КС, необходимые для управления судном и навигации, должны иметь приоритет в Плане восстановления для обеспечения безопасности экипажа судна; 

7) План восстановления в твердой копии должен быть доступен экипажу и береговому персоналу, ответственному за кибербезопасность и отвечающему за оказание помощи при киберинцидентах. 

2.2.5.1.3.3. Этап ввода в эксплуатацию: 

1) в Программе кибербезопасности и киберустойчивости судна судовладельцем должны быть описаны планы восстановления всех КС, входящих в область применения настоящей части, учитывающие, как минимум, следующие требования: 

2) первое ежегодное освидетельствование. 
Судовладелец должен представить Регистру записи или иные задокументированные свидетельства, подтверждающие выполнение Программы кибербезопасности и киберустойчивости судна, а именно то, что: 

2.2.5.2.1. Требование. 
КС и сети, входящие в область применения настоящей части, должны поддерживать возможность резервного копирования и восстановления своевременным, полным и безопасным образом. Резервные копии должны регулярно обновляться и проверяться. 

О б о с н о в а н и е . Целью стратегии резервного копирования и восстановления является защита данных и восстановление данных в случае потери. Как правило, задачи администрирования резервного копирования включают: 

2.2.5.2.2.1. Способность к восстановлению: 

2.2.5.2.2.2. Резервное копирование: 
1) КС и сети, входящие в область применения настоящей части, должны обеспечивать резервное копирование данных. Для повышения устойчивости к вредоносному ПО, поражающему онлайн-устройства резервного копирования, должно быть предусмотрено использование автономных резервных копий; 
2) должны быть разработаны планы резервного копирования, с указанием состава резервируемой информации, способа и периодичности создания резервных копий, носителя, а также срока хранения резервных копий. 

2.2.5.2.3.3. Этап ввода в эксплуатацию:

2.2.5.3.1. Требование. 
КС и сети, входящие в область применения настоящей части, для обеспечения быстрого и безопасного восстановления после возникновения неисправности, вызванной киберинцидентом, должны быть способны осуществлять контролируемое отключение, сброс в первоначальное состояние, возврат в безопасное состояние, а также запуск в безопасном режиме из выключенного состояния. 
Документация, описывающая выполнение вышеупомянутых операций, должна храниться на борту судна. 

1) КС и сети, входящие в область применения настоящей части, должны обеспечивать: 

2) экипажу судна должна быть доступна документация, описывающая порядок осуществления вышеупомянутых операций в случае, если система повреждена в результате киберинцидента. 

О б о с н о в а н и е . Контролируемое отключение заключается в выключении КС или сети с помощью программной функции, позволяющей другим подключенным системам завершить/откатить ожидающие транзакции, завершить процессы, закрыть соединения и т.д., оставляя всю интегрированную систему в безопасном и известном состоянии. Контролируемое отключение противоположно неконтролируемому отключению, которое происходит, например, когда компьютер принудительно выключается из-за прерывания питания. 
Несмотря на то что в случае некоторых киберинцидентов неконтролируемое отключение может расцениваться как мера предосторожности, в случае интегрированных систем контролируемое отключение предпочтительнее для поддержания их в устойчивом и известном состоянии с предсказуемым поведением. Если стандартные процедуры отключения не выполняются, может произойти повреждение данных или файлов программ и операционной системы. В случае ОТ-систем результатом повреждения могут быть нестабильность, неправильная работа или невозможность работы по назначению. 
Операция сброса обычно запускает программно-управляемую загрузку, предписывая системе пройти процесс выключения, очистки памяти и возврата устройств в их первоначальное состояние. В зависимости от рассматриваемой системы операция сброса может иметь различные последствия. 
Откат — это операция, которая возвращает систему в некое предыдущее состояние. Откаты важны для целостности данных и системы, поскольку они означают, что данные и программы системы могут быть восстановлены до чистой копии даже после выполнения ошибочных операций. Откаты имеют решающее значение для восстановления после аварий и киберинцидентов, возвращая систему в устойчивое состояние. 
Перезапуск системы и повторная загрузка нового образа всего ПО и данных (например, после операции отката) из источника, доступного только для чтения, является эффективным подходом для восстановления после неожиданных сбоев или киберинцидентов. Однако операции перезапуска должны контролироваться, особенно для интегрированных систем, где неожиданный перезапуск отдельного компонента может привести к неустойчивому состоянию системы или ее непредсказуемому поведению. 

2.2.5.3.3.1. Этап проектирования. 
В Описание мер обеспечения кибербезопасности системным интегратором должна быть включена следующая информация: 

2.2.5.3.3.3. Этап ввода в эксплуатацию: 

Перед передачей судна в эксплуатацию системный интегратор должен: 

4) Программа испытаний киберустойчивости судна должна обеспечивать возможность регистрации и обновления результатов испытаний, а также содержать следующую информацию:

5) перед тем как направить в Регистр Программу испытаний киберустойчивости судна, системный интегратор должен удостовериться в том, что: 

Программа испытаний киберустойчивости судна приведена в соответствие с последними конфигурациями КС и сетей, соединяющими КС как между собой на борту судна, так и с другими КС, не находящимися на борту (например, на берегу); 

6) системный интегратор должен задокументировать контрольные испытания или оценку мер и средств безопасности на полностью сопряженных КС, включая управление изменениями конфигураций и отмечая в задокументированных результатах испытаний те случаи, когда на безопасное состояние судна могут негативно повлиять конкретные обстоятельства или отказы, указанные в Программе испытаний киберустойчивости судна; 

7) испытания киберустойчивости судна проводятся только после завершения всех остальных пусконаладочных мероприятий КС; 

Судовладелец должен принять технические и организационные меры обеспечения безопасности, перечисленные в настоящем разделе. 
Внесение изменений в КС, входящих в область применения настоящей части, должно выполняться в соответствии с требованиями к управлению изменениями (см. 7.9.7.12.1 части XV «Автоматизация»). Это включает в себя поддержание документации КС в актуальном состоянии. 
Судовладелец при содействии поставщиков должен поддерживать в актуальном состоянии Программу испытаний киберустойчивости судна в соответствии с судовыми КС и сетями, соединяющими КС как между собой на борту судна, так и с другими КС, не находящимися на борту (например, на берегу). Судовладелец должен обновлять Программу испытаний киберустойчивости судна, учитывая изменения в судовых КС и сетях, появление возможных рисков, вызванных этими изменениями, новых угроз и уязвимостей, а также других возможных изменений эксплуатационных условий судна. 
Судовладелец должен разработать и внедрить организационные процедуры, обеспечить периодическую подготовку и проведение обучения для экипажа судна и соответствующего берегового персонала, с целью их ознакомления с судовыми КС и сетями, соединяющими КС как между собой на борту судна, так и с другими КС, не находящимися на борту (например, на берегу) и надлежащим управлением мерами и средствами, принятыми для выполнения требований настоящей части. 
Судовладелец при содействии поставщиков должен поддерживать в актуальном состоянии меры и средства, принятые для выполнения требований настоящей части. 
Судовладелец должен хранить на борту копию результатов испытаний и актуальную Программу испытаний киберустойчивости судна, а также представлять эти документы Регистру.
В случае смены судовладельца, требуется проверка Программы кибербезопасности и киберустойчивости судна в объеме первого ежегодного освидетельствования. 

2.3.3.2. Последующие ежегодные освидетельствования. 
При последующих ежегодных освидетельствованиях по требованию Регистра судовладелец должен представить записи или иные задокументированные свидетельства, подтверждающие выполнение Программы кибербезопасности и киберустойчивости судна. 

1) на этапе проектирования и постройки судна оценка риска должна проводиться и обновляться системным интегратором с учетом возможных изменений первоначального проекта и вновь обнаруженных угроз и/или уязвимостей, о которых изначально не было известно; 

2) в процессе эксплуатации судна судовладелец должен обновлять оценку риска с учетом изменений киберрисков и обнаружения новых уязвимостей КС. В случае выявления новых рисков судовладелец должен обновить существующие или внедрить новые меры по их снижению; 

3) если в результате изменений уровень риска, связанного с оцениваемыми КС, превысит порог приемлемого, то судовладелец должен представить обновленную оценку риска Регистру на рассмотрение; 

4) для определения вероятности возникновения киберинцидентов и воздействий, которые они могут оказать на безопасность людей, безопасность судна и/или окружающую среду, в оценке риска с учетом категории КС должен проводится анализ предполагаемых условий эксплуатации оцениваемых КС. Должен быть проведен анализ поверхности атаки с учетом степени взаимодействия КС, интерфейсов для портативных устройств, логических ограничений доступа и т.д.; 

5) также должны быть выявлены возникающие риски, связанные с конкретной конфигурацией оцениваемой КС. При оценке риска должно учитываться следующее: 

2) при оценке приемлемости уровня риска должны быть соблюдены следующие критерии: 

3) при оценке приемлемости уровня риска должны дополнительно учитываться следующие критерии: 

3.1.1. Системы и оборудование. 

3.1.3.1. Меры безопасности системы ответственного назначения не должны отрицательно влиять на ее работоспособность. 

3.1.3.2. Внедрение мер безопасности не должно приводить к потере функциональной безопасности, функций управления и контроля, а также других функций, которые могут привести к отрицательным последствиям для человека, судна и/или окружающей среды. 

3.1.3.3. Система должна быть спроектирована таким образом, чтобы при эксплуатации судна обеспечивались конфиденциальность, целостность и доступность данных, необходимых для безопасности судна, его систем, экипажа и груза. 

3.1.4. Компенсирующие меры. 

1) перечень аппаратных компонентов (например, хост-устройства, встроенные устройства, сетевые устройства) с указанием следующего: наименование;

2) перечень программных компонентов (например, прикладное ПО, служебное ПО) с указанием следующего: 

1) схема физической топологии должна отражать физическую архитектуру системы. На схеме физической топологи должно быть возможно определить аппаратные компоненты, указанные в Ведомости КС. На схеме физической топологии должны быть отражены:

2) схема логической топологии должна отражать потоки данных между компонентами системы. На схеме логической топологии должны быть отражены: 

4) каждому требованию должна быть отведена отдельная глава. Описание должно включать в себя все аппаратные и программные компоненты системы, если необходимо; 

5) если какое-либо требование выполняется не полностью, то это указывается в описании и предлагаются компенсирующие меры. Компенсирующие меры должны: 

6) в описании должны быть указаны ссылки на любые подтверждающие документы (например, информация об изготовителе), необходимые для проверки соответствия требованиям. 

2) Программа испытаний функциональных возможностей обеспечения безопасности должна включать в себя отдельную главу для каждого применимого требования и содержать следующую информацию: 

3) Программа испытаний функциональных возможностей обеспечения безопасности также должна обеспечивать возможность регистрации и обновления результатов испытаний. 

3.2.1.8. Информация для поддержки разработки планов реагирования и восстановления в случае киберинцидента. 
Документ представляется по требованию Регистра, в документе должны содержаться процедуры или инструкции, позволяющие пользователю выполнить следующее: 

1) Задача: Идентификация и аутентификация пользователя – физического лица 
Требование: КС должна обеспечивать возможность идентификации и аутентификации всех пользователей – физических лиц, которые могут получить доступ к системе напрямую или через интерфейсы. 
(См. IEC 62443-3-3:2013/SR 1.1) 

2) Задача: Управление учетными записями 
Требование: КС должна обеспечивать возможность управления всеми учетными записями авторизованных пользователей, включая добавление, активацию, изменение, деактивацию и удаление учетных записей. 
(См. IEC 62443-3-3:2013/SR 1.3) 

3) Задача: Управление идентификаторами 
Требования: КС должна обеспечивать возможность управления идентификаторами по пользователям, группам и ролям. 
(См. IEC 62443-3-3:2013/SR 1.4) 

4) Задача: Управление аутентификаторами 
Требование: КС должна обеспечивать возможность: инициализации содержания аутентификатора; изменения всех аутентификаторов, заданных по умолчанию, после инсталляции системы управления; изменения/обновления всех аутентификаторов; и защиты всех аутентификаторов от неавторизованного раскрытия и изменения в ходе их ввода и передачи. 
(См. IEC 62443-3-3:2013/SR 1.5) 

5) Задача: Управление беспроводным доступом 
Требование: КС должна обеспечивать возможность идентификации и аутентификации всех пользователей (физических лиц, программных процессов или устройств), участвующих в беспроводной коммуникации. 
(См. IEC 62443-3-3:2013/SR 1.6) 

6) Задача: Надежность аутентификации по паролю 
Требование: КС должна обеспечивать настраиваемую надежность конфигурируемых паролей на основе минимальной длины и разнотипности символов. 
(См. IEC 62443-3-3:2013/SR 1.7) 

7) Задача: Обратная связь при аутентификации 
Требование: КС должна обеспечивать скрытность в ходе процесса аутентификации. 
(См. IEC 62443-3-3:2013/SR 1.10) 

8) Задача: Контроль выполнения авторизаций 
Требование: Пользователям – физическим лицам должна быть назначена авторизация на всех интерфейсах в соответствии с принципами разделения полномочий и минимальных привилегий.
(См. IEC 62443-3-3:2013/SR 2.1) 

9) Задача: Контроль беспроводного использования 
Требование: КС должна обеспечивать возможность авторизации, отслеживания и установления ограничений на беспроводное подключение к системе в соответствии с общепринятыми практиками индустрии безопасности. 
(См. IEC 62443-3-3:2013/SR 2.2) 

10) Задача:  Контроль использования носимых и переносных устройств
Требование: Если КС поддерживает использование носимых и переносных устройств, система должна обеспечивать возможность:

П р и м е ч а н и е . Для отдельных систем могут быть допущены ограничители/блокираторы (в том числе силикон) портов. 
(См. IEC 62443-3-3:2013/SR 2.3) 

11) Задача: Мобильный код 
Требование: КС должна контролировать использование мобильного кода, такого как java-скрипты, ActiveX и PDF. 
(См. IEC 62443-3-3:2013/SR 2.4) 

12) Задача: Блокировка сеанса 
Требование: КС должна блокировать дальнейший доступ по истечении заданного времени в случае отсутствия активности или после ручной активации блокировки сеанса. 
(См. IEC 62443-3-3:2013/SR 2.5) 

13) Задача: События, подлежащие аудиту 
Требование: КС должна регистрировать, по крайней мере, следующие события, относящиеся к безопасности: управление доступом, события операционной системы, события резервного копирования и восстановления, изменения конфигурации, потеря связи. 
(См. IEC 62443-3-3:2013/SR 2.8) 

14) Задача: Емкость систем хранения данных аудита 
Требование: КС должна выделять достаточную емкость для системы хранения записей аудита в соответствии с общепризнанными рекомендациями по управлению файлами регистрации и конфигурированию систем. Система управления должна предусматривать такие механизмы аудита, которые снижают вероятность переполнения хранилища. 
(См. IEC 62443-3-3:2013/SR 2.9) 

15) Задача: Ответные действия в случае сбоев обработки данных аудита 
Требование: В случае сбоя при проведении аудита, КС должна предотвратить потерю ответственных сервисов и функций. 
(См. IEC 62443-3-3:2013/SR 2.10) 

16) Задача: Временные метки 
Требование: КС должна проставлять временные метки в записях аудита. 
(См. IEC 62443-3-3:2013/SR 2.11) 

17) Задача: Целостность коммуникации 
Требование: КС должна защищать целостность передаваемой информации. 
П р и м е ч а н и е . В беспроводных сетях должны использоваться криптографические механизмы. 
(См. IEC 62443-3-3:2013/SR 3.1) 

18) Задача: Защита от вредоносного кода 
Требование: КС должна обеспечивать возможность применения защитных мер для предотвращения, обнаружения и уменьшения воздействий вредоносного кода или неавторизованного ПО. КС должна обеспечивать возможность обновления защитных мер. 
(См. IEC 62443-3-3:2013/SR 3.2) 

19) Задача: Верификация функций безопасности 
Требование: КС должна обеспечивать возможность проверки предполагаемой работы функций безопасности и сообщать о возникновении аномалий во время технического обслуживания. 
(См. IEC 62443-3-3:2013/SR 3.3) 

20) Задача: Детерминированный поток выходных сигналов 
Требование: КС должна обеспечивать возможность приведения выходов в заранее определенное состояние, если в результате атаки не может поддерживаться штатная работа. Заранее определенное состояние может быть следующим:

(См. IEC 62443-3-3:2013/SR 3.6) 

21) Задача: Конфиденциальность информации 
Требование: КС должна обеспечивать возможность защиты конфиденциальности информации, чтение которой подлежит авторизации, будь то хранящаяся или передаваемая информация. 
П р и м е ч а н и е . Для беспроводной сети должны использоваться криптографические механизмы для защиты конфиденциальности всей передаваемой информации. 
(См. IEC 62443-3-3:2013/SR 4.1) 

22) Задача: Использование криптографии 
Требование: В случае использования криптографии КС должна использовать криптографические алгоритмы, размеры ключей и механизмы в соответствии с общепринятой в индустрии безопасности практикой и рекомендациями. 
(См. IEC 62443-3-3:2013/SR 4.3) 

23) Задача: Доступность журнала аудита 
Требование: КС должна обеспечить доступность журнала аудита в режиме «только чтение» авторизованным физическим лицам и/или инструментам. 
(См. IEC 62443-3-3:2013/SR 6.1) 

24) Задача: Защита от отказа в обслуживании 
Требование: КС должна обеспечивать минимальные возможности для поддержки основных функций во время событий типа «отказ в обслуживании» (DoS). 
П р и м е ч а н и е . Допускается, что КС может работать в ухудшенном режиме при возникновении событий DoS, но она не должна выходить из строя таким образом, который может привести к опасным ситуациям. Следует учитывать события DoS, основанные на перегрузке, т.е. когда предпринимается попытка переполнения пропускной способности сети и когда предпринимается попытка использования ресурсов компьютера. 
(См. IEC 62443-3-3:2013/SR 7.1) 

25) Задача: Управление ресурсами 
Требование: Функции безопасности КС должны обеспечивать возможность ограничения использования ресурсов для предотвращения их истощения. 
(См. IEC 62443-3-3:2013/SR 7.2) 

26) Задача: Резервирование системы 
Требование: Идентификация и расположение критически важных файлов, а также возможность создания резервных копий информации на уровне пользователя и системы (включая информацию о состоянии системы) должны поддерживаться КС, не влияя на нормальную работу. 
(См. IEC 62443-3-3:2013/SR 7.3) 

27) Задача: Восстановление системы 
Требование: После сбоя или отказа КС должна обеспечивать возможность своего восстановления до известного безопасного состояния. 
(См. IEC 62443-3-3:2013/SR 7.4) 

28) Задача: Альтернативный источник питания 
Требование: КС должна обеспечивать возможность переключения на альтернативный источник питания и обратно без влияния на существующий уровень безопасности или наличие предусмотренного и задокументированного режима ограниченной функциональности. 
(См. IEC 62443-3-3:2013/SR 7.5) 

29) Задача: Параметры конфигурации сети и безопасности 
Требование: КС должна обеспечивать возможность своего конфигурирования в соответствии с рекомендованными конфигурациями сети и безопасности, как описано в документации изготовителя. КС должна обеспечивать интерфейс для текущих параметров конфигурации сети и безопасности. 
(См. IEC 62443-3-3:2013/SR 7.6) 

30) Задача: Минимальная функциональность 
Требование: Установка, доступность и права доступа к следующим элементам должны быть строго ограничены потребностями функций, выполняемых КС:

(См. IEC 62443-3-3:2013/SR 7.7) 

31) Задача: Многофакторная аутентификация для пользователей – физических лиц 
Требование: В случае предоставления доступа к КС пользователям – физическим лицам из ненадежной сети или через нее, требуется многофакторная аутентификация. 
(См. IEC 62443-3-3:2013/SR 1.1, RE 2) 

32) Задача: Идентификация и аутентификация программных процессов и устройств 
Требование: КС должна идентифицировать и аутентифицировать программные процессы и устройства. 
(См. IEC 62443-3-3:2013/SR 1.2) 

33) Задача: Неудачные попытки входа в систему 
Требование: КС должна обеспечивать ограничение количества последовательных неудачных попыток входа в систему из ненадежных сетей в течение определенного периода времени. 
(См. IEC 62443-3-3:2013/SR 1.11) 

34) Задача: Уведомление об использовании системы 
Требование: КС должна обеспечивать возможность отображения сообщения об использовании системы перед аутентификацией. Должна быть предусмотрена возможность конфигурирования этого сообщения уполномоченным персоналом. 
(См. IEC 62443-3-3:2013/SR 1.12) 

35) Задача: Доступ через ненадежные сети 
Требование: Любой доступ к КС из ненадежных сетей или через них должен отслеживаться и контролироваться. 
(См. IEC 62443-3-3:2013/SR 1.13) 

36) Задача: Принятие явного запроса на доступ 
Требование: КС должна отклонить доступ из ненадежных сетей или через них, за исключением случаев, когда это явно одобрено уполномоченным экипажем на борту судна. 
(См. IEC 62443-3-3:2013/SR 1.13, RE1) 

37) Задача: Завершение удаленного сеанса 
Требование: КС должна обеспечивать возможность завершения удаленного сеанса либо автоматически после настраиваемого периода времени неактивности, либо вручную пользователем, инициировавшим сеанс. 
(См. IEC 62443-3-3:2013/SR 2.6) 

38) Задача: Защита целостности средствами криптографии 
Требование: КС должна использовать криптографические механизмы для выявления изменений информации во время связи с ненадежными сетями или через них.
(См. IEC 62443-3-3:2013/SR 3.1, RE1) 

39) Задача: Валидация входных данных 
Требование: КС должна проверять синтаксис, длину и содержание любых входных данных из ненадежных сетей, которые служат входными данными для управления процессом или являются входными данными, непосредственно влияющими на работу КС. 
(См. IEC 62443-3-3:2013/SR 3.5) 

40) Задача: Целостность сеанса 
Требование: КС должна защищать целостность сеансов. Недействительные идентификаторы сеансов должны быть отклонены. 
(См. IEC 62443-3-3:2013/SR 3.8) 

41) Задача: Аннулирование идентификаторов сеанса после завершения сеанса 
Требование: Система должна аннулировать идентификаторы сеансов при выходе пользователя из системы или другом завершении сеанса (включая сеансы браузера). 
(См. IEC 62443-3-3:2013/SR 3.8, RE1) 

3.4.1. Изготовитель должен иметь процедурные и технические средства контроля для защиты закрытых ключей, используемых для написания кода, от несанкционированного доступа или модификации, если применимо (см. IEC 62443-4-1:2018/SM-8). 

3.4.2. Должен быть внедрен процесс, обеспечивающий доступ пользователей к документации об обновлениях безопасности изделия (что может быть осуществлено путем установления контактного лица по кибербезопасности или при помощи периодических публикаций, к которым пользователь может получить доступ), включающей в себя следующее, но не ограничиваясь этим (см. IEC 62443-4-1:2018/SUM-2): 

3.4.3. Должен быть внедрен процесс, обеспечивающий предоставление пользователям документации об обновлениях безопасности зависимых компонентов или операционной системы, включающей в себя следующее, но не ограничиваясь этим (см. IEC 62443-4-1:2018/SUM-3): 

3.4.4. Должен быть внедрен процесс, обеспечивающий предоставление пользователям обновлений безопасности для всех поддерживаемых изделий и версий изделий таким образом, чтобы облегчить проверку подлинности патча безопасности (см. IEC 62443-4-1:2018/SUM-4). 
Изготовитель должен иметь процедуру контроля качества для проверки обновления перед выпуском. 

3.4.5. Должен быть внедрен процесс разработки документации на изделие, содержащей описание стратегии эшелонированной защиты изделия для поддержки установки, эксплуатации и технического обслуживания и включающей в себя следующее (см. IEC 62443-4-1:2018/SG-1):

3.4.6. Должен быть внедрен процесс разработки пользовательской документации, описывающей меры обеспечения эшелонированной защиты в ожидаемых условиях внешней среды работы изделия (см. IEC 62443-4-1:2018/SG-2). 

3.4.7. Должен быть внедрен процесс разработки документации пользователя изделия, которая включает в себя руководство по усилению защиты изделия при его установке и обслуживании (см. IEC 62443-4-1:2018/SG-3). Руководство должно включать, помимо прочего, инструкции, обоснование и рекомендации в отношении следующего: 

3.5.3.4.1. Средства управления закрытыми ключами (см. IEC 62443-4-1:2018/SM-8). 
Это требование применяется, если система включает в себя ПО, имеющее цифровую подпись с целью предоставления пользователю возможности проверить его подлинность. 
Поставщик должен представить документацию по системе менеджмента, подтверждающую наличие политик, процедур и технических средств контроля для защиты от несанкционированного доступа создания, хранения и использования закрытых ключей, используемых для написания кода. 
Политики и процедуры должны определять роли, обязанности и рабочие процессы. Технический контроль должен включать, например, ограничение физического доступа и криптографическое оборудование (например, аппаратный модуль безопасности) для хранения закрытого ключа. 

Резервное копирование и восстановление (см. 2.2.5.2): 

Краткие сведения о документах, которые поставщик должен представить регистру