ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

СЕТИ ПРОМЫШЛЕННОЙ КОММУНИКАЦИИ

Безопасность сетей и систем

Часть 3-3

Требования к системной безопасности и уровни безопасности

(IEC 62443-3-3:2013, ЮТ)

Издание официальное

Москва

Стандартинформ

2016

Предисловие

1    ПОДГОТОВЛЕН Негосударственным образовательным частным учреждением «Новая Инженерная Школа» (НОЧУ «НИШ») на основе перевода на русский язык англоязычной версии указанного в пункте 4 стандарта, который выполнен Российской комиссией экспертов МЭК/ТК 65, и Федеральным государственным унитарным предприятием «Всероссийский научно-исследовательский институт стандартизации и сертификации в машиностроении» (ВНИИНМАШ)

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 306 «Измерения и управление в промышленных процессах»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 1 июня 2016 г. № 469-ст

4    Настоящий стандарт идентичен международному стандарту МЭК 62443-3-3: 2013 «Сети промышленной коммуникации. Безопасность сетей и систем. Часть 3-3. Требования к системной безопасности и уровни безопасности» (IEC 62443-3-3-1:2013 «Industrial communication networks — Network and system security — Part 3-3: System security requirements and security levels», IDT).

Международный стандарт разработан Техническим комитетом МЭКТК65 «Измерения и управление в промышленных процессах».

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

5    Некоторые элементы настоящего стандарта могут быть предметом патентных прав

6    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячном информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, 2016

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

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

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

Примечание — Демилитаризованные зоны (DMZ) обычно используются для исключения прямых соединений между разными зонами.

3.1.20    устройство (device):06beKT, включающий в себя один или более процессоров, способных посылать или принимать данные/управляющие команды к другому объекту или от него.

Примечание — Примеры включают в себя контроллеры, человеко-машинные интерфейсы (HMI), PLC, пульты дистанционного управления (RTU), передатчики, исполнительные механизмы, клапаны, сетевые коммутаторы и т. д.

3.1.21    среда (environment): Окружение объектов, область или обстоятельства, которые могут воздействовать на функционирование IACS и/или подвергаться воздействию со стороны IACS.

3.1.22    жизненно важная функция (essential function): Функция или характеристика, которая требуется для поддержания охраны труда, техники безопасности, охраны окружающей среды, а также работоспособности и доступности управляемого оборудования.

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

3.1.23    событие (event): Появление или изменение определенного набора обстоятельств.

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

3.1.24    пожарный вызов (firecall): Метод, учрежденный для обеспечения аварийного доступа к защищенной системе управления.

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

3.1.25    идентификатор (identifier): Символ, уникальный в пределах своего домена безопасности, обозначающий или используемый для заявления притязания субъекта на название или другую идентичность.

3.1.26    идентифицировать (identify): Операция контроля идентичности.

3.1.27    воздействие (impact): Оцененное последствие отдельно взятого события.

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

3.1.29    система промышленной автоматики и контроля; IACS (industrial automation and control system; IACS): Совокупность персонала, аппаратного и программного обеспечений и политик, задействованных в функционировании промышленного процесса и способных влиять или воздействовать иным образом на его защищенное, безопасное и надежное функционирование.

3.1.30    целостность (integrity): Свойство защиты корректности и полноты имущественных объектов.

3.1.31    минимальная привилегия (least privilege): Основополагающий принцип, который гласит, что пользователи (люди, программные процессы или устройства) должны по возможности наделяться минимальными привилегиями в соответствии с вмененными им обязанностями и функциями.

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

4

ГОСТ Р МЭК 62443-3-3-2016

3.1.32    мобильный код (mobile code): Программа, передаваемая в пределах удаленной, возможно — «недоверенной», системы через сеть или съемные носители, которая может запускаться в неизменном виде на локальной системе без явной инсталляции или запуска этой программы получателем.

Примечание — Примеры мобильного кода включают в себя JavaScript, VBScript, Java-апплеты, управляющие элементы ActiveX, Flash-анимации, видеофрагменты Shockwave и макросы Microsoft Office.

3.1.33    защита от непризнания участия (non-repudiation): Возможность подтверждения факта заявленного события или действия и породивших его субъектов.

Примечание — Целью защиты от непризнания участия является разрешение диспутов относительно факта наличия или отсутствия события или действия и причастности к нему субъектов.

3.1.34    производитель продукта (product supplier): Производитель аппаратного и/или программного продукта.

Примечание —Данное понятие используется взамен обобщенного термина «поставщик» в целях их дифференциации.

3.1.35    удаленный доступ (remote access): Доступ к системе управления со стороны любого пользователя (человека, программного процесса или устройства), осуществляемый из (вне) периметра рассматриваемой зоны.

3.1.36    роль (role): Набор взаимосвязанных характеристик, привилегий и обязательств, привязанных ко всем пользователям (людям, программным процессам или устройствам) IACS.

Примечание — Привилегии на выполнение определенных операций ставятся в соответствие конкретным ролям.

3.1.37    автоматизированная система безопасности (safety instrumented system): Система, используемая для реализации одной или более функций технологической безопасности.

3.1.38    уровень безопасности (security level): Мера достоверности того, что IACS лишена уязвимостей и функционирует надлежащим образом.

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

3.1.39    провайдер сервиса (service provider): Организация (внутренняя или внешняя организация, производитель и т. д.), согласившаяся взять на себя обязательство на предоставление того или иного сервиса поддержки, а также добывание материально-технических средств в порядке соответствующего соглашения.

Примечание — Это понятие используется взамен родового термина «поставщик» в целях их дифференциации.

3.1.40    сессия (session): Устойчивый, интерактивный, с отслеживанием состояний, обмен информацией между двумя или более коммуникационными устройствами.

Примечание — В типичном случае сессия включает в себя четко определенные процессы начала и

завершения.

3.1.41    ID сессии (session ID): Идентификатор, используемый для обозначения конкретного входа в сессию.

3.1.42    уставка (set point): Целевое значение, обозначенное внутри системы управления, которое позволяет контролировать одно или более действий в пределах системы управления.

3.1.43    системный интегратор (system integrator): Лицо или организация, которые специализируются на сведении воедино подсистем компонентов и обеспечении того, чтобы эти подсистемы функционировали в соответствии с проектными спецификациями.

3.1.44    угроза (threat): Обстоятельство или событие, способное отрицательно отразиться на процессах хозяйствования (включая задачи, функции, имидж или репутацию), объектах, системах управления или людях посредством получения несанкционированного доступа, уничтожения, раскрытия, видоизменения данных и/или отказа в обслуживании.

5

3.1.45    доверие (trust): Уверенность в том, что на операцию, источник данных, сетевой или программный процесс можно полагаться в отношении их ожидаемого функционирования.

Примечание 1 — В общем случае может считаться, что некий субъект «доверяет» второму субъекту, если делает допущение, что второй субъект будет функционировать в соответствии с ожиданиями первого субъекта.

Примечание 2 — Это доверие может быть применимо только в отношении какой-то конкретной функции.

3.1.46    недоверенный (untrusted): Не соответствующий заданным требованиям доверия. Примечание — Субъект может быть просто объявлен недоверенным.

3.1.47    зона (zone): Совокупность логических или физических объектов, соответствующих общим требованиям безопасности.

Примечание — Зона имеет четкую границу. Политику безопасности зоны обычно составляют комбинации механизмов безопасности как на периферии зоны, так и внутри нее.

3.2 Сокращения

В настоящем стандарте применены следующие сокращения:

AES — улучшенный стандарт шифрования;

API — интерфейс программирования приложений;

ASLR — случайное размещение схем адресного пространства;

BPCS — основная система управления процессами;

СА— центр сертификации;

CIP — защита объектов жизнеобеспечения;

COTS — коммерчески доступные продукты;

CRL — перечень отзыва сертификатов;

DC — конфиденциальность данных;

DEP — предотвращение выполнения данных;

DHCP — протокол динамического конфигурирования хостов;

DMZ — демилитаризованная зона;

DNS — служба доменных имен;

DoS — отказ в обслуживании;

EICAR — Европейский институт компьютерных антивирусных исследований;

EMI — электромагнитные помехи;

FAT — заводские приемочные испытания;

FIPS — Федеральный стандарт обработки информации (NIST, США);

FR — фундаментальное требование;

FS-PLC — PLC функциональной безопасности;

FTP — протокол передачи файлов;

GLONASS — Глобальная навигационная спутниковая система (ГЛОНАСС);

GPS — система глобального позиционирования;

HMI — человеко-машинный интерфейс;

HSE — охрана труда, техника безопасности и охрана окружающей среды;

HTTP — протокол передачи гипертекста;

HTTPS — HTTP защищенный;

IAC — управление идентификацией и аутентификацией;

IACS — система(ы) промышленной автоматики и контроля;

IAMS — система управления контрольно-измерительными объектами;

ID — идентификатор;

IDS — система обнаружения несанкционированных проникновений;

6

IEC — Международная электротехническая комиссия (МЭК);

IEEE — Институт инженеров по электротехнике и электронике;

IETF — инженерный совет Интернета;

IM — система мгновенного обмена сообщениями;

IP — интернет-протокол;

IPS — система предотвращения несанкционированных проникновений;

ISA— Международная ассоциация автоматизации;

ISO — Международная организация по стандартизации (ИСО);

IT — информационная технология;

MES — система управления производственными процессами;

NERC — Североамериканская корпорация по обеспечению надежности электросистем; NIST — Национальный институт стандартов и технологий (США);

NX — запрет исполнения;

OCSP — онлайновый протокол статуса сертификата;

О WASP — открытый проект обеспечения безопасности веб-приложений;

PDF — формат переносимых документов;

PKI — инфраструктура открытых ключей;

PLC — программируемый логический контроллер;

RA— работоспособность и доступность ресурсов;

RAM — оперативное запоминающее устройство;

RDF — ограничение потока данных;

RE — расширение требований;

RFC — запрос на комментарии;

RJ — стандартный телекоммуникационный интерфейс;

RTU — пульт дистанционного управления;

SAT — приемо-сдаточные испытания;

SHA — алгоритм безопасного хеширования;

SI — целостность системы;

SIEM — управление информацией о безопасности и событиями безопасности;

SIF — функция отказа в случае возникновения опасной ситуации;

SIL — уровень целостности безопасности;

SIS — автоматизированная система безопасности;

SL — уровень безопасности;

SL-A — достигнутый уровень безопасности;

SL-C — потенциальный уровень безопасности;

SL-T — целевой уровень безопасности;

SP — специальная публикация;

SR — системное требование;

SSH — безопасная оболочка;

SuC — рассматриваемая система;

TCP — протокол управления передачей;

ТРМ — модуль доверительной платформы;

TRE — своевременный отклик на события;

UC — контроль использования;

USB — универсальная последовательная шина;

VoIP I — Р-телефония;

WEP — конфиденциальность на уровне проводных сетей;

WLAN — беспроводная локальная сеть.

3.3 Допущения

Настоящий стандарт расширяет семь FR, установленных в МЭК 62443-1-1, до серии SR. Каждое SR содержит основополагающее требование, а также может содержать одно или несколько расширений требования (RE) для ужесточения безопасности. По мере необходимости для читателя дополнительно приводятся наглядная и аргументированная методологическая основа к каждому основополагающему требованию и комментарии к любым привязанным к ним RE. Основополагающее требование и расширения RE, при их наличии, затем ставятся в соответствие одному из четырех потенциальных уровней безопасности SL-C (FR, система управления).

Все семь FR имеют определенный набор из четырех SL. Применительно к системе управления соответствие уровню 0 для отдельно взятого FR определено неявным образом как отсутствие требований. Например, постановка задачи для раздела 8, FR 4 — Конфиденциальность данных, звучит следующим образом:

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

Соответствующие четыре SL определены как:

-    SL 1 — предотвращать неавторизованное раскрытие информации посредством ее несанкционированного извлечения или случайного обнародования;

-    SL 2 — предотвращать неавторизованное раскрытие информации субъекту, активно ее ищущему с использованием простых средств, при незначительных ресурсах, посредственных навыках и низкой мотиваци;

-    SL 3 — предотвращать неавторизованное раскрытие информации субъекту, активно ее ищущему с использованием изощренных средств при умеренных ресурсах, наличии специальных познаний в IACS и умеренной мотивации;

-    SL 4 — предотвращать неавторизованное раскрытие информации субъекту, активно ее ищущему с использованием изощренных средств при обширных ресурсах, наличии специальных познаний в IACS и высокой мотивации.

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

SL-С (система управления), используемый на протяжении всего настоящего стандарта, обозначает наличие ресурсов, необходимых для соответствия конкретному SL, соотносящемуся с конкретным FR. Полное описание векторной концепции SL можно найти в приложении А.

4 Общие ограничения безопасности систем управления

4.1    Обзор

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

Примечание — Содержание данного раздела будет включено в МЭК 62443-1-1.

4.2    Поддержка жизненно важных функций

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

8

ГОСТ Р МЭК 62443-3-3-2016

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

Примечание — См. МЭК 62443-2-1, в котором приведены требования к документированию, относящиеся к оценке рисков, необходимой для обоснования случаев, когда меры безопасности могут отрицательно сказываться на жизненно важных функциях.

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

-    меры управления доступом (IAC и UC) не должны препятствовать управлению жизненно важными функциями, а именно:

-    учетные записи, используемые для жизненно важных функций, не должны блокироваться, в том числе временно (см. 5.5, SR 1.3 — Управление учетными записями, 5.6, SR 1.4 — Управление идентификаторами, 5.13, SR 1.11 — Неуспешные попытки входа в систему, и 6.7, SR 2.5 — Блокировка сессий);

-    верификация и фиксация действий операторов для укрепления защиты от непризнания участия не должны вносить существенных задержек в быстродействие системы (см. 6.14, SR 2.12 — Защита от непризнания участия);

-    для систем управления с высокой работоспособностью отказ Центра сертификации не должен вызывать сбои жизненно важных функций [см. 5.10, SR 1.8 — сертификаты Инфраструктуры открытых ключей (PKI)];

-    идентификация и аутентификация не должны препятствовать инициации SIF (см. 5.3, SR 1.1 — Идентификация и аутентификация пользователя — физического лица, и 5.4, SR 1.2 — Идентификация и аутентификация программных процессов и устройств). То же самое относится и к контролю выполнения авторизаций (см. 6.3, SR 2.1 — Контроль выполнения авторизаций);

-    записи аудитов с некорректными временными метками (см. 6.10, SR 2.8 — События, подлежащие аудиту, и 6.13, SR 2.11 — Временные метки) не должны отрицательно отражаться на жизненно важных функциях;

-    жизненно важные функции IACS должны сохраняться, если защита границ зон переходит в режим закрытия при отказе и/или островной режим (см. 9.4, SR 5.2 — Защита границ зон);

-    событие DoS в сети системы управления или в SIS не должно препятствовать срабатыванию SIF (см. 11.3, SR 7.1 —Защита от отказов в обслуживании).

4.3 Компенсационные контрмеры

Компенсационные контрмеры, раскрытые в настоящем стандарте, должны быть привязаны к директивам, приведенным в МЭК 62443-3-2.

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

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

Примечание 2 — В некоторых приложениях с высокой работоспособностью и доступностью ресурсов [высоким SL-T (RA, система управления)] потребуются компенсационные контрмеры, внешние по отношению к системе управления (например, дополнительные меры физической безопасности и/или ужесточенные проверки биографических данных персонала). В этих случаях можно встретить систему управления с SL, как правило, соответ-

9

ствующим высокой работоспособности и доступности ресурсов, при более низких SL IAC — 1 или 2, в зависимости от компенсационных контрмер. Для системы управления с SL, соответствующим очень высокой работоспособности и доступности, вероятность блокировки или утраты управления из-за мер безопасности возрастает, а не наоборот Таким образом, высокие SL не всегда «лучше», даже если расходы не являются существенным фактором.

4.4 Минимальная привилегия

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

5 FR 1 — Управление идентификацией и аутентификацией

5.1    Назначение и описания SL-C(IAC)

Идентифицировать и аутентифицировать всех пользователей (людей, программные процессы и устройства) перед предоставлением им доступа к системе управления:

-    SL 1 — идентифицировать и аутентифицировать всех пользователей (людей, программные процессы и устройства) посредством механизмов, которые препятствуют осуществлению случайного или непредумышленного доступа неаутентифицированными субъектами;

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

-    SL 3 — идентифицировать и аутентифицировать всех пользователей (людей, программные процессы и устройства) посредством механизмов, которые препятствуют осуществлению умышленного неаутентифицированного доступа субъектами с использованием изощренных средств, при умеренных ресурсах, наличии специальных познаний в IACS и умеренной мотивации;

-    SL4 — идентифицировать и аутентифицировать всех пользователей (людей, программные процессы и устройства) посредством механизмов, которые препятствуют осуществлению умышленного неаутентифицированного доступа субъектами с использованием изощренных средств, при обширных ресурсах, наличии специальных познаний в IACS и высокой мотивации.

5.2    Целесообразность

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

5.3    SR 1.1 — Идентификация и аутентификация пользователя — физического лица

5.3.1    Требование

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

5.3.2    Целесообразность и дополнительная методологическая основа

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

ГОСТ Р МЭК 62443-3-3-2016

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

Там, где пользователи — физические лица действуют как единая группа (например, операторы пульта управления), идентификация и аутентификация пользователей может быть проведена на основе ролей или групп. Применительно к некоторым системам управления критически важна возможность беспрепятственного взаимодействия между операторами. Жизненно важно, чтобы требования идентификации или аутентификации не затрудняли локальных действий в чрезвычайных ситуациях, а также не вносили ограничений в жизненно важные функции системы управления (см. раздел 4 для получения более полных сведений). Доступ к этим системам может быть сдержан соответствующими механизмами физической безопасности (см. МЭК 62443-2-1). Примером такой ситуации служит пульт управления в критических режимах, где действуют строгий контроль и мониторинг физического доступа и, в соответствии с планами работы на рабочую смену, ответственность распределяется между той и иной группой пользователей. Эти пользователи затем могут использовать персоналии одного и того же пользователя. Кроме того, по возможности должны проходить аутентификацию клиенты выделенных рабочих станций операторов (см. 5.4, SR 1.2 — Идентификация и аутентификация программных процессов и устройств), или использование этой разделенной учетной записи должно быть по возможности ограничено средой пульта управления.

Для поддержания политик IAC, как определено в МЭК 62443-2-1, система управления в качестве первого этапа верифицирует идентичность всех пользователей — физических лиц. На втором этапе вводятся в действие полномочия, закрепленные за идентифицированным пользователем — физическим лицом (см. 6.3, SR 2.1 — Обязательная авторизация).

5.3.3 Расширения требований

5.3.3.1    SR 1.1 RE1 —Уникальная идентификация и аутентификация

Система управления должна обеспечивать возможность уникальной идентификации и аутентификации всех пользователей — физических лиц.

5.3.3.2    SR 1.1 RE2 — Многофакторная аутентификация для недоверенных сетей

Система управления должна обеспечивать возможность применения многофакторной аутентификации для осуществления доступа пользователей — физических лиц к системе управления через недоверенную сеть (см. 5.15, SR 1.13 — Доступ через недоверенные сети).

Примечание —См. 5.7.3.5.7.3.1, SR 1.5 — Управление аутентификаторами, RE5.7.3.1 относительно расширенного управления аутентификаторами для программных процессов.

5.3.3.3    SR 1.1 RE3 — Многофакторная аутентификация для всех сетей

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

5.3.4    Уровни безопасности

Ниже приведены требования к четырем уровням SL, относящимся к SR 1.1 — Идентификация и аутентификация людей-пользователей:

-    SL-C (IAC, система управления) 1: SR 1.1;

-    SL-C (IAC, система управления) 2: SR 1.1 (1);

-    SL-C (IAC, система управления) 3: SR 1.1 (1) (2);

-    SL-C (IAC, система управления) 4: SR 1.1 (1) (2) (3).

5.4    SR 1.2 — Идентификация и аутентификация программных процессов и устройств

5.4.1    Требование

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

5.4.2    Целесообразность и дополнительная методологическая основа

Функция идентификации и аутентификации — присвоение ID неизвестному программному процессу или устройству (далее в этом подпункте упоминаются как субъект) для его выявления перед санкционированием любого обмена данными. Если допустить отправку и получение неподконтроль-

11

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

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

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

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

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

Для того чтобы поддерживать политики управления идентификацией и аутентификацией, как определено в соответствии с МЭК 62443-2-1, система управления в качестве первого этапа верифицирует идентичность всех субъектов. На втором этапе с субъектом ассоциируются полномочия, вмененные идентифицированному субъекту (см. 6.3, SR 2.1 — Обязательная авторизация).

5.4.3    Расширения требований

5.4.3.1    SR 1.2 RE1 —Уникальная идентификация и аутентификация

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

5.4.3.2    Пусто

5.4.4    Уровни безопасности

Далее приведены требования для уровней SL, относящихся к SR 1.2 — Идентификация и аутентификация программных процессов и устройств:

-    SL-C (IAC, система управления) 1: не определены;

-    SL-C (IAC, система управления) 2: SR 1.2;

-    SL-C (IAC, система управления) 3: SR 1.2 (1);

-    SL-C (IAC, система управления) 4: SR 1.2 (1).

5.5 SR 1.3 — Управление учетными записями

5.5.1    Требование

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

5.5.2    Целесообразность и дополнительная методологическая основа

Управление учетными записями может включать в себя группировку учетных записей (например, индивидуальную, на основе ролей, устройств и в привязке к системам управления), учреждение условий для членства в группах и присвоение соответствующих авторизаций. В определенных случаях, когда индивидуальные учетные записи применительно к IACS определены как ненужные в аспекте ана-12

ГОСТ Р МЭК 62443-3-3-2016

лиза рисков и/или регламентного регулирования, допустимы разделенные учетные записи при условии, что документированы и действенны адекватные компенсационные контрмеры (например, ограниченный физический доступ или организационные меры для подтверждения).

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

5.5.3    Расширения требований

5.5.3.1    SR 1.3 RE1 — Унифицированное управление учетными записями

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

5.5.3.2    Пусто

5.5.4    Уровни безопасности

Далее приведены требования для уровней SL, относящихся к SR 1.3 — Управление учетными записями:

-    SL-C (IAC, система управления) 1: SR 1.3;

-    SL-C (IAC, система управления) 2: SR 1.3;

-    SL-C (IAC, система управления) 3: SR 1.3 (1);

-    SL-C (IAC, система управления) 4: SR 1.3 (1).

5.6 SR 1.4 — Управление идентификаторами

5.6.1    Требование

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

5.6.2    Целесообразность и дополнительная методологическая основа

Идентификаторы следует отличать от привилегий, действие которых они санкционируют для субъекта в пределах управляющего домена или зоны конкретной системы управления (см. 6.3, SR 2.1 — Обязательная авторизация). Там, где пользователи — физические лица действуют как единая группа (например, операторы пульта управления), идентификация пользователей может быть на основе ролей, групп или устройств. Применительно к некоторым системам управления критически важна возможность беспрепятственного взаимодействия между операторами. Требования идентификации не должны ограничивать локальные действия в чрезвычайных ситуациях применительно к системе управления. Доступ к этим системам может быть сдержан соответствующими компенсационными контрмерами. Идентификаторы могут требоваться на участках системы управления, но не обязательно во всей системе управления. Например, беспроводные устройства обычно требуют идентификаторов, в то время как проводные устройства могут их и не требовать.

Управление идентификаторами будет определено локальными политиками и регламентами, учрежденными в соответствии с МЭК 62443-2-1.

5.6.3    Расширения требований

Отсутствуют.

5.6.4    Уровни безопасности

Далее приведены требования для уровней SL, относящихся к SR 1.4 — Управление идентификаторами:

-    SL-C (IAC, система управления) 1: SR 1.4;

-    SL-C (IAC, система управления) 2: SR 1.4;

-    SL-C (IAC, система управления) 3: SR 1.4;

-    SL-C (IAC, система управления) 4: SR 1.4.

13

ГОСТ Р МЭК 62443-3-3-2016

Содержание

1    Область применения.................................................................1

2    Нормативные ссылки.................................................................1

3    Термины, определения, сокращения, допущения..........................................2

3.1    Термины и определения...........................................................2

3.2    Сокращения ....................................................................6

3.3    Допущения......................................................................8

4    Общие ограничения безопасности систем управления.....................................8

4.1    Обзор..........................................................................8

4.2    Поддержка жизненно важных функций...............................................8

4.3    Компенсационные контрмеры......................................................9

4.4    Минимальная привилегия.........................................................10

5    FR 1 —Управление идентификацией и аутентификацией..................................10

5.1    Назначение и описания SL-C(IAC)..................................................10

5.2    Целесообразность...............................................................10

5.3    SR 1.1 — Идентификация и аутентификация пользователя — физического лица...........10

5.4    SR 1.2 — Идентификация и аутентификация программных процессов и устройств.........11

5.5    SR 1.3 — Управление учетными записями...........................................12

5.6    SR 1.4 — Управление идентификаторами...........................................13

5.7    SR 1.5 — Управление аутентификаторами...........................................14

5.8    SR 1.6 — Управление беспроводным доступом.......................................15

5.9    SR 1.7 — Надежность аутентификации по паролю....................................15

5.10    SR 1.8 — Сертификаты инфраструктуры открытых ключей (PKI)........................16

5.11    SR 1.9 — Надежность аутентификации по открытому ключу...........................17

5.12    SR 1.10 — Обратная связь при аутентификации.....................................18

5.13    SR 1.11 — Неудачные попытки входа в систему......................................18

5.14    SR 1.12 — Уведомление об использовании системы..................................19

5.15    SR 1.13 — Доступ через недоверенные сети........................................20

6    FR 2 — Контроль использования......................................................20

6.1    Назначение и описания SL-C(UC)..................................................20

6.2    Целесообразность...............................................................20

6.3    SR 2.1 — Контроль выполнения авторизаций.........................................21

6.4    SR 2.2 — Контроль беспроводного использования....................................22

6.5    SR 2.3 — Контроль использования портативных и подвижных устройств..................23

6.6    SR 2.4 — Мобильный код.........................................................23

6.7    SR 2.5 — Блокировка сеанса......................................................24

6.8    SR 2.6 — Прерывание удаленных сеансов...........................................24

6.9    SR 2.7 — Контроль параллельных сеансов..........................................25

6.10    SR 2.8 — События, подлежащие аудиту............................................25

6.11    SR 2.9 — Емкость систем хранения данных аудита...................................26

6.12    Ответные действия в случае сбоев обработки данных аудита..........................26

6.13    SR 2.11 — Временные метки.....................................................27

6.14    SR 2.12 — Защита от непризнания участия.........................................27

7    FR 3 — Целостность системы.........................................................28

III

5.7 SR 1.5 — Управление аутентификаторами

5.7.1    Требование

Система управления должна обеспечивать возможность:

a)    инициализации содержания аутентификатора;

b)    изменения всех аутентификаторов, заданных по умолчанию, после инсталляции системы управления;

c)    изменения/обновления всех аутентификаторов; и

d)    защиты всех аутентификаторов от неавторизованного раскрытия и изменения в ходе их ввода и передачи.

5.7.2    Целесообразность и дополнительная методологическая основа

Наряду с идентификатором (см. 5.6, SR 1.4 — Управление идентификаторами) аутентификатор необходим для подтверждения идентичности. Аутентификаторы систем управления включают в себя, но не ограничиваются этим, токены, симметричные ключи, секретные ключи (часть пары из открытого/ секретного ключа), биометрические признаки, пароли, физические ключи и карточки с ключом. Пользователи — физические лица должны по возможности принимать разумные меры для обеспечения безопасности аутентификаторов, в том числе хранить при себе личные аутентификаторы, не одалживать и не использовать аутентификаторы совместно и немедленно сообщать об утрате или нарушении безопасности аутентификаторов.

Аутентификаторы имеют жизненный цикл. Когда создается учетная запись, то автоматически должен быть создан новый аутентификатор, чтобы можно было аутентифицировать держателя учетной записи. Например, в системе на основе паролей учетная запись содержит привязанный к ней пароль. Определение начального содержания аутентификатора может быть интерпретировано как определение администратором начального пароля, который система управления учетными записями устанавливает для всех новых учетных записей. Возможность конфигурации этих начальных символов усложняет для злоумышленника разгадывание пароля, установленного между созданием учетной записи и первым использованием учетной записи (что должно предполагать задание нового пароля держателем учетной записи). Некоторые системы управления инсталлируются с помощью автоматических инсталляторов, которые создают все необходимые учетные записи с паролями, устанавливаемыми по умолчанию, а некоторые встраиваемые устройства поставляются с паролями, установленными по умолчанию. Зачастую со временем эти пароли становятся всеобщим достоянием и фиксируются в Интернете. Возможность изменения паролей, оставленных по умолчанию, позволяет защитить систему от неавторизованных пользователей, которые используют пароли, оставленные по умолчанию, для получения доступа. Пароли могут быть заполучены из памяти данных или в ходе передачи данных в процессе сетевой аутентификации. Сложность этого может быть повышена посредством криптографических защит, например шифрования или хеширования, или протоколов квитирования, которые не требуют передачи пароля вообще. И все же пароли могут быть объектом атак, например, подбором методом полного перебора (методом «грубой силы») или взломом криптографической защиты паролей в момент их передачи или хранения. Окно возможности можно сузить посредством периодической смены/обновления паролей. Аналогичные соображения применимы к системам аутентификации на основе криптографических ключей. Можно добиться улучшенной защиты посредством аппаратных механизмов, например аппаратных модулей безопасности, таких как доверенные платформенные модули (ТРМ).

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

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

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

ГОСТ Р МЭК 62443-3-3-2016

7.1    Назначение и описания SL-C(SI)...................................................28

7.2    Целесообразность...............................................................28

7.3    SR 3.1 — Целостность коммуникации...............................................28

7.4    SR 3.2 — Защита от вредоносного кода.............................................30

7.5    SR 3.3 — Верификация функциональности безопасности..............................30

7.6    SR 3.4 — Целостность программного обеспечения и информации.......................31

7.7    SR 3.5 — Валидация входных данных...............................................32

7.8    SR 3.6 — Детерминированный поток выходных сигналов...............................32

7.9    SR 3.7 — Обработка ошибок......................................................33

7.10    SR 3.8 — Целостность сеанса....................................................33

7.11    SR 3.9 — Защита информации аудита.............................................34

8    FR 4 — Конфиденциальность данных..................................................35

8.1    Назначение и описания SL-C(DC)..................................................35

8.2    Целесообразность...............................................................35

8.3    SR 4.1 — Конфиденциальность информации.........................................35

8.4    SR 4.2 — Сохранность информации................................................36

8.5    SR 4.3 — Использование криптографии.............................................37

9    FR 5 — Ограничение потока данных....................................................37

9.1    Назначение и описания SL-C(RDF).................................................37

9.2    Целесообразность...............................................................38

9.3    SR 5.1 — Сегментация сети.......................................................38

9.4    SR 5.2 — Защита границ зоны.....................................................39

9.5    SR 5.3 — Ограничения на передачу общецелевой информации «абонент — абонент»......40

9.6    SR 5.4 — Разбиение приложений..................................................40

10    FR 6 — Своевременный отклик на события.............................................41

10.1    Назначение и описания SL-C(TRE)................................................41

10.2    Целесообразность..............................................................41

10.3    SR 6.1 —Доступность файлов регистрации аудита...................................41

10.4    SR 6.2 — Непрерывный мониторинг...............................................42

11    FR 7 — Работоспособность и доступность ресурсов......................................42

11.1    Назначение и описания SL-C(RA).................................................42

11.2    Целесообразность..............................................................43

11.3    SR 7.1 — Защита от отказа в обслуживании.........................................43

11.4    SR 7.2 — Управление ресурсами..................................................43

11.5    SR 7.3 — Резервирование в системе управления....................................44

11.6    SR 7.4 — Восстановление и воссоздание системы управления.........................44

11.7    SR 7.5 — Аварийное питание.....................................................45

11.8    SR 7.6 — Параметры конфигурации сети и безопасности..............................45

11.9    SR 7.7 — Минимальная функциональность.........................................46

11.10    SR 7.8 — Инвентаризация компонентов системы управления.........................46

Приложение А (справочное) Описание вектора SL..........................................47

Приложение В (справочное) Соотнесение SR и RE с уровнями SL 1 — 4 FR....................54

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

ссылочным национальным стандартам Российской Федерации.................58

Библиография.......................................................................59

ГОСТ Р МЭК 62443-3-3-2016

0 Введение

0.1 Обзор

Примечание 1 — Настоящий стандарт представляет собой часть серии стандартов, посвященной вопросам безопасности систем промышленной автоматизации и контроля (IACS). Он разработан рабочей группой 4 исследовательской группы 2 комитета МЭК 99 в сотрудничестве с МЭКТК65/РГ10. Настоящий документ регламентирует требования безопасности для систем управления, соотносящиеся с семью фундаментальными требованиями, определенными в МЭК 62443-1-1, и устанавливает уровни безопасности (SL) для рассматриваемой системы (PC).

Примечание 2 — Формат настоящего стандарта соответствует требованиям ИСО/МЭК, рассмотренным в Директивах ИСО/МЭК, часть 2 [II]¹). Эти директивы регламентируют формат стандарта, а также использование терминов типа «должен», «должен по возможности» и «может». Для требований, определенных в обязательных пунктах, использованы соглашения, рассмотренные в приложении Н Директив ИСО/МЭК.

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

Организации, внедряющие бизнес-решения в сфере кибербезопасности информационных технологий (IT) для разрешения вопросов, связанных с безопасностью IACS, могут не вполне осознавать последствия такого выбора. Хотя многие коммерческие прикладные IT-объекты и решения безопасности могут быть применимы к IACS, их необходимо применять надлежащим образом для исключения непредвиденных последствий. По этой причине подход, используемый для определения системных требований, должен базироваться на комбинации функциональных требований и оценки риска и зачастую включает в себя и необходимость иметь осведомленность в вопросах эксплуатации.

Меры безопасности IACS не должны иметь возможность приводить к нарушению существенных сервисов и функций, включая процедуры при нештатных ситуациях. (Часто меры безопасности IT имеют данную тенденцию.) Обеспечение безопасности IACS нацелено на работоспособность и доступность систем управления, защищенность производственных объектов, производственных процессов (хотя бы в режиме ограниченной функциональности) и времени отклика системы, где это имеет критическое значение. В рамках целей IT-безопасности этим факторам зачастую придается меньшее значение. Большее значение придается защите информации, чем защите физических объектов. Эти различные цели должны быть четко определены как цели безопасности, независимо от степени достигнутой интеграции производственного объекта. Ключевым этапом в оценке риска согласно требованиям МЭК 62443-2-1²) должна по возможности быть идентификация тех сервисов и функций, которые действительно существенны для процессов хозяйствования. (Например, на тех или иных объектах техническая поддержка может быть определена как несущественный сервис или функция.) В некоторых случаях может быть допустимо, чтобы операция безопасности провоцировала временную утрату несущественного сервиса или функции, но по возможности не сказывалась отрицательно на существенном сервисе или функции.

Настоящий стандарт предполагает, что программа безопасности учреждена и управляется в соответствии с МЭК 62443-2-1. Кроме того, предполагается, что управление патчами осуществляется сообразно рекомендациям, подробно рассмотренным в МЭКЯО 62443-2-3 [5], с соблюдением соответствующих требований и их доработок, описанных в настоящем стандарте, применительно к системам управления. Также в МЭК 62443-3-2 [8] описано, каким образом проект задает уровни безопасности (SL), основанные на риске, которые затем используются для выбора продуктов с подходящими техническими характеристиками безопасности, что подробно рассмотрено в настоящем стандарте. Ключевой

исходный материал для настоящего стандарта включал в себя ИСО/МЭК 27002 [15] и NIST SP800-53, ред. 3 [24] (см. раздел 2 и Библиографию, которые содержат более полный перечень первоисточников).

Основная задача стандартов из стандартов серии МЭК 62443 — предоставить гибкую концепцию, которая облегчает устранение текущих и будущих уязвимостей в IACS и применение необходимых смягчающих мер в систематическом, оправданном порядке. Важно понимать, что назначение серии МЭК 62443 — сформировать расширения корпоративной безопасности, которые перенимают требования к коммерческим IT-системам и увязывают эти требования с едиными требованиями по обеспечению надежной работоспособности, необходимой в IACS.

0.2 Назначение и целевая аудитория

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

Системным интеграторам, поставщикам продуктов и провайдерам сервисов настоящий стандарт послужит для оценки того, могут ли их продукты и сервисы обеспечивать потенциал функциональной безопасности, который соответствует требованиям целевого уровня безопасности (SL-T) собственника имущественного объекта. Как и в случае с присвоением уровней SL-T, применимость системных требований (SR) к отдельно взятой системе управления и расширений к этим требованиям (RE) должна базироваться на политиках безопасности собственника объекта, регламентах и оценке риска в контексте относящегося к ним участка применения. Следует отметить, что некоторые SR содержат специальные условия для допустимых исключений, например в случае, когда соответствие SR идет вразрез с фундаментальными требованиями эксплуатации системы управления (что может спровоцировать необходимость компенсационных контрмер).

Если разрабатываемая система управления должна соответствовать набору SR, привязанных к конкретным SL-T, то не требуется, чтобы каждый компонент предлагаемой системы управления соответствовал каждому системному требованию до степени, предписываемой настоящим стандартом. Могут применяться компенсационные контрмеры для придания необходимой функциональности другим подсистемам, так чтобы общие требования SL-T выполнялись на уровне системы управления. Включение в расчет компенсационных контрмер на стадии разработки следует подкреплять исчерпывающей документацией, чтобы итоговый достигнутый SL-A системы управления полностью отражал расчетные характеристики безопасности, присущие проекту. Точно так же в ходе сертификационных испытаний и/или постинсталляционных аудитов могут применяться и документироваться компенсационные контрмеры для обеспечения соответствия общему SL системы управления.

В настоящем стандарте представлена не достаточно детальная информация для разработки и построения интегрированной архитектуры безопасности. Это потребовало бы дополнительного анализа на системном уровне и разработки производных требований, которые являются темой других стандартов серии МЭК 62443 (см. 0). Следует отметить, что задачей настоящего стандарта не является формирование спецификаций, достаточно детальных для построения архитектуры безопасности. Задачей является определение общего минимального набора требований для достижения соответствия все более строгим уровням безопасности. Сам проект архитектуры, удовлетворяющей этим требованиям, — это работа системных интеграторов и поставщиков продуктов. В рамках этой задачи они удерживают за собой право индивидуальных выборов, поддерживая тем самым конкуренцию и инновационную деятельность. Таким образом, в настоящем стандарте строго выдержан принцип определения функциональных требований и не рассматривается возможный порядок соответствия этим функциональным требованиям.

0.3 Применимость в контексте других частей серии МЭК 62443

На рисунке 1 графически представлена структура стандартов серии МЭК 62443 на момент разработки настоящего стандарта.

В МЭК 62443-3-2 SR и RE приводятся в виде стандартизированного перечня. После того как рассматриваемая система (SuC) описана в плане зон и трактов и данным зонам и трактам присвоены конкретные целевые SL, в указанном стандарте SR и RE, а также присвоение им потенциальных SL (SL-C) VI

ГОСТ Р МЭК 62443-3-3-2016

использованы для составления перечня требований, которому должен соответствовать проект системы управления. Отдельно взятый проект системы управления может быть затем проверен на полноту, и определен достигнутый уровень безопасности (SL-A).

^Mgggiggi

Система показателей соответствия безопасности системы

I    *

5

ф

Р

и

S

О

в
Требования разработчиков продукции		Технические требования безопасности компонентов IACS

Рисунок 1 — Структура стандартов серии МЭК 62443

В МЭК/ТС 62443-1-3 [2] используются фундаментальные требования (FR), SR, RE и им присваиваются уровни SL-C в виде стандартизированного перечня для проверки полноты спецификации количественной системы показателей. Количественные системы показателей безопасности привязаны к контексту. Как и в МЭК 62443-3-3-2, присваиваемые собственником объекта SL-T преобразованы в количественную систему показателей, которая может использоваться при разработке архитектуры безопасности и служить для планирования сравнительных исследований, а также в качестве опоры для системного анализа.

В МЭК 62443-4-1 [9] рассмотрены общие требования к процессу разработки продуктов. В связи с этим МЭК 62443-4-1 ориентирован на поставщиков продуктов. Требования к безопасности продуктов являются производными перечня основополагающих требований и РТ, определенных в настоящем стандарте. Нормативы качества, определенные в МЭК 62443-4-1, будут использоваться при разработке характеристик этих продуктов.

МЭК 62443-4-2 [10] содержит наборы производных требований, которые обеспечивают детальное присвоение SR, определенных в этом стандарте, подсистемам и компонентам SuC. На момент разработки настоящего стандарта в МЭК 62443-4-2 рассматривались следующие категории компонентов: встраиваемые устройства, главные устройства, сетевые устройства и приложения. В связи с этим МЭК 62443-4-2 ориентирован на поставщика (поставщиков продуктов и провайдеров сервисов). Сначала выведены требования безопасности продуктов из перечня основополагающих требований и RE, определенных в данном стандарте. Требования безопасности и системы показателей из МЭК 62443-3-2 и МЭК/ТС 62443-1-3 использованы для уточнения этих производных нормативных требований.

VII

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

СЕТИ ПРОМЫШЛЕННОЙ КОММУНИКАЦИИ Безопасность сетей и систем Часть 3-3

Требования к системной безопасности и уровни безопасности

Industrial communication networks. Network and system security.

Part 3-3. System security requirements and security levels

Дата введения — 2017—04—01

1 Область применения

В настоящем стандарте сформулированы детальные системные требования (SR) к техническим системам управления, привязанные к семи фундаментальным требованиям (FR), описанным в МЭК 62443-1-1, который включает в себя определение требований к потенциальным уровням безопасности (SL-C) (система управления). Работники, имеющие отношение к системам промышленной автоматики и контроля (IACS), смогут использовать данные требования вместе с информацией о зонах и трактах, определенных для рассматриваемой системы (SuC), в ходе разработки целевого уровня, SL-T (система управления) соответствующей системы управления, применительно к конкретному объекту.

Как определено в МЭК 62443-1-1, существует семь FR:

a)    управление идентификацией и аутентификацией (IAC);

b)    контроль использования (UC);

c)    целостность системы (SI);

d)    конфиденциальность данных (DC);

e)    ограничение потока данных (RDF);

f)    своевременный отклик на события (TRE);

д) работоспособность и доступность ресурсов (RA).

Данные требования лежат в основе потенциальных SL, SL-C (система управления) систем управления. Цель и задача настоящего стандарта — определение потенциальной безопасности на уровне системы управления в противоположность целевым SL, SL-T или достигнутым SL, SL-A, которые выходят за рамки настоящего стандарта.

См. МЭК 62443-2-1, в котором представлен эквивалентный набор нетехнических, относящихся к программам потенциальных SL, необходимых для полного достижения целевого SL системы управления.

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты. Для датированных ссылок применяют только указанное издание ссылочного документа. Для недатированных ссылок применяют последнее издание ссылочного документа (включая все его изменения).

Издание официальное

МЭК 62443-1-1:2009 Сети промышленной коммуникации. Безопасность сетей и систем. Часть 1-1. Терминология, концепции и модели (IEC 62443-1-1:2009, «Industrial communication networks — Network and system security — Part 1-1: Terminology, concepts and models», IDT)

МЭК 62443-2-1 Сети промышленной коммуникации. Безопасность сетей и систем. Часть 2-1. Учреждение программы безопасности систем промышленной автоматизации и контроля (IEC 62443-2-1, «Industrial communication networks — Network and system security — Part 2-1: Establishing an industrial automation and control system security program», IDT)

3 Термины, определения, сокращения, допущения

3.1    Термины и определения

В настоящем стандарте применены термины и определения по МЭК 62443-1-1 и МЭК 62443-2-1, а также следующие термины с соответствующими определениями:

Примечание — Многие из нижеследующих терминов и определений изначально базируются на соответствующих источниках Международной организации по стандартизации (ИСО), Международной электротехнической комиссии (МЭК) или Национального института стандартов и технологий (NIST) (США), при этом изредка делаются незначительные поправки для лучшей применимости терминов и определений при определении требований к безопасности систем управления.

3.1.1    имущественный объект (объект, актив) (asset): Физический или логический объект, который представляет для IACS ощущаемую или реальную ценность.

Примечание — В настоящем стандарте имущественный объект — это любая единица, которую следует защищать в рамках системы управления безопасностью IACS.

3.1.2    собственник объекта (asset owner): Лицо или организация, отвечающие за один или более

IACS.

Примечание 1 — Термин «собственник объекта» используется взамен родового термина «конечный пользователь» в целях их дифференциации.

Примечание 2 — Это определение распространяется на компоненты, являющиеся частью IACS.

Примечание 3 — В контексте настоящего стандарта собственник объекта включает в себя также оператора IACS.

3.1.3    атака (attack): Посягательство на систему, являющееся следствием рациональной угрозы.

Примечание 1 — Например, осмысленное действие, представляющее собой продуманную попытку (особенно в плане метода или стратегии) обойти сервисы безопасности и нарушить политику безопасности системы.

Примечание 2 — Существуют различные общепризнанные типы атак:

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

-    «пассивная атака» имеет целью заполучить или использовать информацию системы без воздействия на ресурсы системы;

-    «внутренняя атака» — атака, инициированная субъектом в пределах периметра безопасности («инсайдером») — т. е. субъектом, который наделен правами на получение доступа к ресурсам системы, но использует их в целях, не одобренных теми, кто предоставил эти права;

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

3.1.4    аутентификация (authentication): Обеспечение уверенности в том, что заявляемая характеристика идентичности корректна.

Примечание —Аутентификация обычно — необходимое предварительное условие предоставления доступа к ресурсам в системе управления.

3.1.5    аутентификатор (authenticator): Средство, используемое для подтверждения идентичности пользователя (человека, программного процесса или устройства).

Примечание — Например, в качестве аутентификатора могут использоваться пароль или токен.

2

ГОСТ Р МЭК 62443-3-3-2016

3.1.6    аутентичность (authenticity): Свойство соответствия субъекта тому, за кого или за что он себя выдает.

Примечание —Аутентичность обычно употребляется в контексте достоверности идентичности субъекта или правомерности передачи сообщения, самого сообщения или его источника.

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

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

3.1.9    канал связи (communication channel): Особая линия логической или физической связи между субъектами.

Примечание — Канал облегчает установление соединения.

3.1.10    компенсационная контрмера (compensating countermeasure): Контрмера, применяемая взамен или в дополнение к встроенным или рекомендованным мерам безопасности для обеспечения более полного соответствия требованиям безопасности.

Примечание — Примеры включают в себя следующие компенсационные меры:

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

-    (уровня системы управления/зоны): средства управления физическим доступом (охрана, ворота и ружья) для защиты пульта управления с целью ограничения доступа к группе известного персонала, что позволяет компенсировать техническое требование, согласно которому персонал должен уникально идентифицироваться IACS; и

-    (уровня компонентов): программируемый логический контроллер (PLC) поставщика не может соответствовать характеристикам управления доступом, определенным конечным пользователем, в результате чего поставщик устанавливает межсетевой экран перед PLC и продает их как одну систему.

3.1.11    орган нормативно-правового регулирования (compliance authority): Субъект с правовой юрисдикцией определять корректности оценки безопасности, ее реализации или эффективности, регламентированных в руководящем документе.

3.1.12    тракт (conduit): Логическое объединение каналов связи, связывающее между собой две или более зоны, для которых действуют общие требования безопасности.

Примечание — Допустимо пересечение трактом зоны при условии, что эта зона не влияет на безопасность каналов, содержащихся в тракте.

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

Примечание — При употреблении в контексте IACS термин относится к защите данных и информации, относящихся к IACS, от неавторизованного доступа.

3.1.14    соединение (connection): Связь, установленная между двумя или более оконечными точками, которая поддерживает установление сессии.

3.1.15    последствие (consequence): Состояние или условие, которое является логическим или естественным следствием события.

3.1.16    система управления (control system): Компоненты аппаратного и программного обеспечения IACS.

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

Примечание — В некоторых контекстах для описания этого понятия используется также термин «управление». Применительно к настоящему стандарту выбран термин «контрмера» во избежание путаницы с термином «управление» в контексте «управление процессами».

3.1.18    режим ограниченной функциональности (degraded mode): Режим функционирования при наличии неполадок, которые были приняты в расчет в проекте системы управления.

3

1

)) Цифры в квадратных скобках относятся к элементу стандарта «Библиография».

2

) Многие стандарты из стандартов серии МЭК 62443 в настоящее время находятся на пересмотре или доработке.

V