БИБЛИОТЕКА НОРМАТИВНЫХ ДОКУМЕНТОВ

ГОСТ Р 56498-2015/IEC/PAS 62443-3:2008. Национальный стандарт Российской Федерации. Сети коммуникационные промышленные. Защищенность (кибербезопасность) сети и системы. Часть 3. Защищенность (кибербезопасность) промышленного процесса измерения и управления

8.2 Управление целостностью

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

Примечание - Предполагается, что целостность переданных данных (то есть что данные ICS переданы и приняты неизмененными между конечными точками сессии) обеспечивается промышленными связными протоколами.

 

8.2.1 Конфигурации аппаратных устройств и интерфейсов должны быть уменьшены до минимально необходимых (усиление защищенности).

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

Правила реализации политики приведены в 8.2.1.1 и 8.2.1.2.

8.2.1.1 Неиспользуемые оператором интерфейсы ввода-вывода, периферийные устройства, устройства связи и хранения данных должны быть удалены или иным способом сделаны постоянно неработоспособными.

8.2.1.2 Шкафы и слоты, доступные снаружи, которые не могут быть удалены, должны быть защищены, то есть заперты.

8.2.2 Необходимо уменьшить до минимально необходимого уровня число приложений, а также служб и утилит O/S (усиление защиты).

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

Правила реализации политики приведены в 8.2.2.1 - 8.2.2.4

8.2.2.1 Должны документироваться список и конфигурация приложений, служб и утилит O/S, требуемых для эксплуатации ICS.

Примечание - Наборы разрешенных средств связи могут зависеть от формального оперативного состояния завода или участка, например "нормальная эксплуатация", объявленная "эксплуатация в аварийных условиях" либо операции по вводу в эксплуатацию или выводу из эксплуатации.

 

8.2.2.2 Должны документироваться все параметры сетевых служб, требуемых на хостах, для входящих и исходящих потоков данных при обмене ими с другими хостами и устройствами ICN.

8.2.2.3 Приложения, службы и утилиты O/S, не требуемые для эксплуатации ICS, должны быть удалены из конфигураций и их резервных копий.

Примечание 1 - Службы приема непосредственного вещания должны быть удалены.

Примечание 2 - Если службы и утилиты O/S, не требуемые для эксплуатации ICS, не могут быть удалены, они должны быть выполнены постоянно недоступными любым пользователям.

Примечание 3 - Шлюз SGW на базе хоста (также называемый персональный SGW) делает неработоспособной или блокирует связь, предназначенную для некоторых служб, но не удаляет код.

 

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

Примечание - Имеются наилучшие практические способы усиления защиты для различных операционных систем (см., например, представленные в NIST, NSA, SANS, CISecurity).

 

8.2.3 Должны корректно поддерживаться уникальность и подлинность созданных конфигураций.

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

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

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

- уменьшения потерь в безопасности, обусловленных ошибками операторов и администраторов из-за сложности конфигурирования.

Может оказаться невозможным изменить настройки, введенные, например, изготовителями на старом оборудовании.

Правила реализации политики приведены в 8.2.3.1 - 8.2.3.3.

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

8.2.3.2 Изменение настроек должно быть документировано. Настройки должны быть прозрачны для пользователя и защищены от изменения.

8.2.3.3 Уникальные настройки, созданные владельцем/оператором, могут быть восстановлены после установки пакетов исправления.

Примечание - Пакеты исправлений могут восстановить заданные до этого настройки, выбираемые по умолчанию.

 

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

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

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

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

Очевидно, что изготовитель системы автоматизации не способен протестировать обновление или пакет исправлений на каждом возможном варианте системы, в частности на конкретной реализации ICS.

Правила реализации политики приведены в 8.2.4.1 - 8.2.4.6.

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

8.2.4.2 Реестр компонентов системы и оперативное состояние должны сохраняться, а также должны создаваться их резервные копии и архивы, и их целостность должна быть защищена.

8.2.4.3 Обновления и пакеты исправлений безопасности должны рассматриваться только после утверждения их изготовителем соответствующего устройства или системы.

8.2.4.4 Утвержденные изготовителем обновления и пакеты исправлений безопасности должны устанавливаться только после дополнительного тестирования на ICS.

Примечание - Если возможно, при тестировании на заводе должны выполняться: разработка систем, резервное копирование и тренинги.

 

8.2.4.5 Перед установкой на ICS новые приложения, службы и пакеты исправлений должны быть подписаны.

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

Примечание 1 - Должен существовать процесс разрешения возникающих проблем, включающий откат к последнему надежному и функционально корректному состоянию.

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

 

8.2.5 Должно осуществляться управление исполняемыми образами, основной и резервной копией O/S, информацией о состоянии и производственной информацией.

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

Правила реализации политики приведены в 8.2.5.1 - 8.2.5.4.

8.2.5.1 Должны регулярно выполняться резервное копирование и надежная архивация, резервные копии должны тестироваться и выполняться подтверждение их подлинности.

8.2.5.2 Резервная копия должна содержать в себе все параметры функционала безопасности, производственного функционала и оперативно требуемые параметры функционала для быстрого восстановления.

8.2.5.3 Должны быть установлены и доступны утилиты, проверяющие целостность файловой системы O/S, позволяющие обнаружить изменения. Должны быть доступны процедуры и инструменты для точного восстановления в требуемое состояние.

8.2.5.4 Должны предотвращаться неразрешенные изменения конфигурации, например, с помощью вредоносного программного обеспечения или заражения вирусами. Если это все же произошло, должен быть выдан сигнал тревоги, и после соответствующего реагирования должны быть приняты меры по исправлению ситуации.

Примечание 1 - Ресурсы ICS могут сильно перегружаться при сканировании. См. управление доступностью ресурсов в настоящем стандарте.

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

Примечание 3 - Сканеры должны быть развернуты и сконфигурированы только таким образом, как указано изготовителем системы автоматизации, и сканировать только обозначенное оборудование.

Примечание 4 - Сканеры и подписи для хостов и устройств COTS, не являющихся критичными, могут быть установлены владельцем/оператором на свой риск, при этом следует обеспечить, чтобы сканирование не нарушало критичных границ, например, сетевых устройств.

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

 

8.2.6 Управление целостностью должно включать мониторинг, протоколирование, процедуры эскалации аварий.

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

8.2.6.1 Должен осуществляться централизованный мониторинг всех шлюзов SGW.

Примечание - См. протоколирование в 7.3.4.2.