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

Industrial communication networks. Network and system security. Part 3. Security for industrial process measurement and control

Дата введения - 1 января 2016 г.

Введен впервые

Предисловие

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

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

3 Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 22 июня 2015 г. N 775-ст

4 Настоящий стандарт идентичен международному документу IEC/PAS 62443-3:2008 "Промышленные коммуникационные сети. Защищенность (кибербезопасность) сети и системы. Часть 3. Защищенность (кибербезопасность) промышленного процесса измерения и управления" (IEC/PAS 62443-3:2008 "Industrial communication networks - Network and system security - Part 3: Security for industrial process measurement and control").

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

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

5 Введен впервые

6 В настоящем стандарте часть его содержания может быть объектом патентных прав

Введение

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

Для прикладных систем безопасности и систем в фармацевтических или других узкоспециализированных отраслей промышленности могут быть применимы дополнительные стандарты, директивы, определения и условия. Например, МЭК 61508, GAMP (ISPE), правило 21 CFR (FDA) для соответствия GMP и Стандартный регламент Европейского агентства лекарственных средств (SOP/INSP/2003),

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

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

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

Кроме того, эксплуатационные требования, установленные в настоящем стандарте, могут быть использованы теми, кто имеет отношение к ICS, в том числе:

a) разработчики автоматизированных систем;

b) изготовители (поставщики) устройств, подсистем и систем;

c) сборщики подсистем и систем.

PAS учитывает следующие вопросы:

- постепенный перенос/эволюция существующих систем;

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

- гарантия надежности/доступности защищенных коммуникационных сервисов;

- применимость к системам любых размеров и с любыми рисками (универсальность);

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

Примечание 1 - Производственные объекты и системы могут содержать компоненты и устройства, крайне важные для безопасности. Любые компоненты, относящиеся к безопасности, могут быть сертифицированы в рамках МЭК 61508 и в соответствии с его уровнями целостности безопасности (SIL). Настоящий стандарт не гарантирует, что ее технические требования полностью или частично соответствуют или достаточны для безопасности таких компонентов и устройств, важных ДЛЯ безопасности.

Примечание 2 - Настоящий стандарт не включает в себя требований к оценке и проверке обеспечения безопасности.

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

Примечание 4 - Положения настоящего стандарта описаны языком, привычным для владельца/оператора производственного объекта.

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

Примечание 6 - Настоящий стандарт не распространяется на интеграцию компонентов и подсистем в систему

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

Примечание 8 - В рамках МЭК 62443 предусмотрена разработка трех частей, которые включают в себя большинство положений, изложенных в примечаниях 1 - 7. В приложении А приведен планируемый объем и содержание разрабатываемых стандартов.

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

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

ИСО/МЭК 15408 (все части) Информационная техника. Технологии безопасности. Критерии оценки для безопасности IT (ISO/IEC 15408 (all parts), Information technology - Security techniques - Evaluation criteria for IT security)

ИСО/МЭК 27002:2005 Информационная техника. Технологии безопасности. Свод правил для управления IT-безопасностью (ISO/IEC 27002:2005, Information technology - Security techniques - Code of practice for IT security management)

ИСО/МЭК Руководящий принцип 73:2002, Управление риском. Терминология. Директивы к использованию в стандартах (ISO/IEC Guide 73:2002, Risk management - Vocabulary - Guidelines for use in standards)

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

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

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

3.1.1 управление доступом (access control): Предупреждение о несанкционированном использовании служебного ресурса, в том числе о его использовании без авторизации.

[ИСО/МЭК 18028-2:2006, изменен]

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

[RFC 2828]

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

[ИСО/МЭК 18028-1:2006]

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

[ИСО/МЭК 13335-1:2004]

3.1.5 надежность (assurance): Характеристика соответствующих действий или процессов, дающая уверенность в том, что результат удовлетворяет требованиям безопасности.

[ИСО/МЭК/ТО 15443-1]

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

[ИСО/МЭК 18043]

3.1.7 поверхность атаки (attack surface): Совокупность ресурсов системы, которые напрямую или косвенно подвержены потенциальному риску атаки.

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

[ИСО/МЭК 18028-1]

3.1.9 проведение аутентификации, аутентификация (authenticate, authentication): Проверка заявляемой идентичности логического объекта.

[ИСО/МЭК 19792]

3.1.10 доступность (availability): Свойство быть доступным и используемым по запросу со стороны уполномоченного логического объекта.

[ИСО 7498-2]

3.1.11 коммерчески доступные продукты (Commercial off the shelf, COTS): Продукты, изготовленные и распределенные в промышленном масштабе для многократного применения и/или множества потребителей; могут быть изготовлены на заказ для специального применения.

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

3.1.12 утечка информации (compromise): Несанкционированное использование, рассекречивание, преобразование или замена в каждом из случаев - данных, программ или конфигурации системы, то есть в результате и после несанкционированного проникновения.

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

[ИСО/МЭК 13335-3]

3.1.14 регистрационные данные (credentials): Средство подтверждения того, что нечто или некто является тем, за кого себя выдает, причем такое абстрактное средство может представлять собой учетные IT-данные доступа к информационному сервису или ресурсу.

[ИСО/МЭК 24760]

3.1.15 демилитаризованная зона (demilitarized zone, DMZ): Хост безопасности или небольшая сеть (называемая также защищенной подсетью), располагаемые между сетями в качестве "нейтральной зоны".

[ИСО/МЭК 18028-3]

Примечание - Данная зона образует буферную зону безопасности (ИСО/МЭК 18028-3).

3.1.16 отказ в обслуживании (атака) [denial of service (attack)]: Атака на систему, направленная на ограничение ее доступности.

[ИСО/МЭК 18028-4]

3.1.17 событие (event): Событие в системе, относящееся к ее безопасности.

[RFC 2828, изменен]

3.1.18 незащищенный, незащищенность (exposed, exposure): Состояние уязвимости и отсутствия защиты против атаки.

3.1.19 внешний (external): Находящийся за пределами либо на внешней границе периметра безопасности промышленной сети управления (ICN), то есть относящийся к внешней организационной или общедоступной сети.

3.1.20 шлюз внешних подключений (external connectivity gateway; ECG): Специальный шлюз безопасности (SGW) на внешней границе периметра безопасности ICN, как правило, с дополнительными функциями для выполнения специальных запросов, то есть для подключения внешних устройств.

3.1.21 внешняя сеть (external network; EN): Сеть, внешняя по отношению к ICN, либо входящая в состав организации, к которой принадлежит ICN, либо принадлежащая третьей стороне, либо общедоступная, т.е. Интернет.

3.1.22 экспертиза (forensic): Действия по объяснению прошедшего события в официальном порядке и с возможностью перепроверки для возложения ответственности последовательным и логичным образом.

3.1.23 шлюз, шлюз безопасности (gateway, security gateway; SGW): Точка соединения между сетями или сети с подсетями и внешними сетями, предназначенная для защиты сети или подсети в соответствии с установленной политикой безопасности.

[ИСО/МЭК 18028-3, изменен]

Примечание - Шлюз безопасности включает в себя не только межсетевые экраны. Термин охватывает также маршрутизаторы и переключатели, которые обеспечивают функции управления доступом и при необходимости - шифрования (ИСО/МЭК 18028-3).

3.1.24 усилять защиту, усиление защиты (harden, hardening): Удаление ненужных функций для уменьшения физических, логических и/или организационных уязвимостей.

3.1.25 человеко-машинный интерфейс (human-machine-interface; HMI): Функция оборудования, направленная на предоставление выходной информации оператору и прием вводимой информации от оператора, в результате чего человек, например, оператор, становится неотъемлемой частью процесса.

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

3.1.27 промышленная сеть управления (industrial control network; ICN): Сеть, связывающая между собой оборудование промышленной системы управления (ICS). На территории одного и того же завода могут иметься различные ICN, которые могут быть связаны с удаленным оборудованием и ресурсами, находящимися за пределами завода.

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

Примечание - В рамках настоящего стандарта термин ICS обозначает автоматизированные системы в целом, включая системы диспетчерского контроля и сбора данных (SCADA).

3.1.29 инсайдер, в пределах, внутренний (insider, inside, internal): Логический объект находящийся в пределах периметра безопасности; инсайдер - это логический объект, уполномоченный на доступ к ресурсам системы.

Примечание - Атака инсайдером относится к использованию ресурсов системы на несанкционированной основе.

3.1.30 целостность (integrity): Гарантия точности и полноты информации и методов обработки информации.

[ИСО/МЭК 21827]

Примечание - Целостность может относиться непосредственно к данным (целостность данных) или к действующей ICS (целостность системы).

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

3.1.32 несанкционированное проникновение (intrusion): Инцидент, при котором неуполномоченный логический объект, то есть злоумышленник, получает или явно пытается получить доступ к служебным ресурсам системы.

[RFC 2828, изменен]

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

[RFC 2828]

3.1.34 криптографический или физический ключ [(cryptographic or physical) key]: Устройство, носитель информации или открытый текст, связанные с методами аутентификации или криптографии, а также привилегиями управления доступом.

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

[ИСО/МЭК 18028-1]

3.1.36 вредоносные программы (malware): Вредоносное программное обеспечение, такое как вирус или троянский конь, созданное специально для повреждения системы или вывода ее из строя.

[ИСО/МЭК 18028-1]

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

[RFC 2828]

3.1.38 сообщение (message): Упорядоченная последовательность октетов (или бит), служащая для передачи информации.

[ИСО/МЭК 2382, изменен]

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

[ИСО/МЭК 13888-1, изменен]

3.1.40 защита от непризнания участия (non-repudiation): Свойство действия, допускающее многократную последующую проверку того, что это действие было выполнено данным участником или исходило от него.

[RFC 2828, изменен]

3.1.41 владелец/оператор (owner/operator): Хозяйствующий субъект, отвечающий за эксплуатацию системы ICS или SCADA.

3.1.42 сегмент, сегментирование (partition, partitioning): Ограниченная физическая или логическая зона, в которой предоставление доступа к ресурсам или отказ в данном доступе регулируются правилами доступа и механизмами контроля.

[ССОРР v0.5, изменен]

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

3.1.43 периметр (perimeter): Границы сегмента или зоны сети, обычно защищаемые механизмами в соответствии с политикой безопасности или принятым регламентом на управление доступом.

3.1.44 ворота физического доступа (physical access gate; PAG): Точка физического доступа, предназначенная для управления авторизацией, например, персонала и оборудования при их проникновении внутрь периметра безопасности завода и/или физического сегмента ICS, или покидании пределов указанного периметра.

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

[RFC 2828, изменен]

3.1.46 завод (plant): Производственное помещение, которое обычно имеет физически защищенный периметр и на территории которого осуществляется физический процесс и расположены ICS и ее ICN.

3.1.47 привилегия (privilege): Право или разрешение, предоставляемые в явной форме отдельным пользователям или устройствам, а также определенной группе пользователей или устройств, на выполнение определенных действий, входящих в состав должностных обязанностей и объединенных между собой по отличительным признакам.

3.1.48 прокси (сервер) [proxy (server)]: Компьютерный процесс, который перенаправляет протокол между клиентской и серверной компьютерными системами, представляясь клиенту от имени сервера, а серверу - от имени клиента.

[RFC 2828, изменен]

3.1.49 в режиме реального времени (real-time): Относящийся к времени реагирования вычислительных устройств, которое настолько мало, что реагирование кажется мгновенным и без задержек.

3.1.50 резервирование (redundancy): Дублирование важнейших компонентов безопасности системы с целью повышения ее доступности.

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

3.1.51 остаточный риск (residual risk): Риск, сохраняющийся после реализации контрмер.

[RFC 2828]

3.1.52 риск (risk): Сочетание вероятности события и его последствия, где вероятность - это количественная оценка возможности того, что это событие произойдет.

[ИСО/МЭК Руководство 73:2002]

Примечание - Последствием называется ущерб для имущественных объектов.

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

[ИСО/МЭК/ТО 15443-1]

3.1.54 центр безопасности (security centre): Надежный ресурс для мониторинга, исправления, обновления, обработки подписей и оповещения в рамках обеспечения безопасности ICN. Внешний центр безопасности расположен за пределами периметра безопасности ICN.

3.1.55 система управления (информационной) безопасностью [(information) security management system (ISMS)]: Часть общей системы управления, основанной на концепции делового риска, для создания, внедрения, эксплуатации, мониторинга, анализа, поддержки и улучшения организационной безопасности.

[ИСО/МЭК 27001, изменен]

3.1.56 мера безопасности (security measure): Мера защиты против возможного нарушения безопасности защищенной системы.

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

[RFC 2828]

3.1.58 значимость для безопасности/значимый для безопасности (security relevance/relevant); Отдельное явление, то есть действие или событие, способное нарушить безопасность.

3.1.59 нарушение безопасности (security violation): Акт или событие, которое приводит к нарушению или иному несоблюдению политики безопасности.

[RFC 2828]

3.1.60 эффективность функции (strength of function): Качество функции безопасности, отражающее минимальные усилия, которые предположительно необходимы для преодоления ее ожидаемых характеристик безопасности путем непосредственной атаки на базовые механизмы безопасности,

[ИСО/МЭК 15408-1, изменен]

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

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

[RFC 2828]

3.1.63 пользователь (user): Лицо, организационная единица или автоматический процесс, получающие доступ в систему как на санкционированной, так и несанкционированной основе.

[RFC 2828]

3.2 Сокращения

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

COTS - коммерчески доступные продукты (Commercial off the shelf);

DMZ - демилитаризованная зона (Demilitarized zone);

ECG - шлюз внешних подключений (External connectivity gateway);

EN - внешняя сеть (External network);

GPH - универсальный хост (General purpose host);

HMI - человеко-машинный интерфейс (Human machine Interface)

ICS - промышленная система управления (Industrial control system);

IDS - система обнаружения вторжений (Intrusion detection system);

ISMS - система управления (информационной) безопасностью [(Information) security management system];

O/S - операционная система (Operating system);

PAG - ворота физического доступа (Physical access gate);

ICN - промышленная сеть управления (Industrial control network);

PSM - портативный носитель данных (Portable storage medium);

SED - автономное внешнее устройство (Stand-alone external device);

SGW - шлюз безопасности (Security gateway).

4 Введение и нормативно-правовое соответствие

Использование методик и стандартов IT-безопасности стало обычным явлением в офисной среде и выражено в форме повсеместного свода правил для управления информационной безопасностью (ИСО/МЭК 27002, ранее известный как ИСО/МЭК 17799), для эксплуатационной безопасности, а также в форме критериев оценки IT-безопасности (ИСО/МЭК 15408) при разработке продуктов.

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

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

Однако методики и стандарты из офисной среды не могут быть непосредственно применены к автоматизированным системам. Исследование, проведенное EWICS [15] показало, что широко применяемый ИСО/МЭК 27002 необходимо значительно расширить, чтобы он был применим к системам управления, используемым в промышленности. Несмотря на то, что 189-и пунктам в указанном исследовании была дана оценка от применимых до абсолютно применимых, 85% или 45% были признаны как требующие дополнительной методологической основы.

Настоящий стандарт содержит рекомендуемые нормы, установленные специалистами-практиками на основе практического опыта, но разработанные независимо от ИСО/МЭК 27002.

Примечание - Несмотря на то, что желательно было бы согласовать структуру и терминологию настоящего стандарта с ИСО/МЭК 27002, на данный момент этого не сделано.

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

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

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

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

5 Принципы и базовые модели

5.1 Общие положения

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

В настоящем пункте описаны соответствующие базовые модели.

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

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

5.2 Модель угроз-рисков

5.2.1 Обзор

На рисунке 1 приведена общая модель угроз-рисков, относящаяся к безопасности. Из рисунка следует:

- угрозы используют уязвимости ICS;

- без контрмер они могут представлять недопустимый риск (для имущественных объектов);

- в общем случае для минимизации риска (для имущественных объектов) необходимы контрмеры.

"Рисунок 1 - Взаимосвязь угроз-рисков"

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

Настоящий стандарт предусматривает контрмеры в виде методик, оформленных в предлагаемую политику.

5.2.2 Угрозы

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

- атаки вандалов и террористов;

- сбой в ICS, за которым следует событие безопасности;

- атаки типа "отказ в обслуживании";

- нарушение конфиденциальности, например, утечка производственной информации;

- нарушение законодательных норм;

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

Возможны и другие события, которые могут быть характерны для конкретной организации.

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

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

5.2.3 Риск

В ИСО/МЭК Guide 73 риск определен как "комбинация вероятности события и его последствий", то есть как ущерб или последствие инцидента безопасности. Наступление инцидента может привести к одному или более последствиям, а также спровоцировать другие события.

Ущерб, который может быть понесен в ICS, включает в себя:

- потерю дохода;

- непредвиденные расходы;

- невозможность частичного или полного ведения финансово-хозяйственной деятельности;

- потерю денежной стоимости зданий и содержимого;

- инцидент безопасности;

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

- последствия из-за нарушения нормативно-правовых требований, таких как стандарты GAM0;

- неудовлетворенность клиента;

- негативное освещение в прессе;

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

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

Риск для объектов ICS требует фиксации ценности объектов и их уязвимости перед атакой. Как правило, это очень трудно и субъективно, например, если рассматривать в качестве последствия потерю репутации организации.

5.2.4 Анализ угроз-рисков

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

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

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

В связи с изложенным в настоящем стандарте методы TRA не представлены.

5.2.5 Обработка, принятие и информирование о рисках

После анализа рисков их, как правило, могут счесть неприемлемыми без обработки.

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

Меры безопасности должны быть по возможности:

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

- прогнозируемыми в отношении прилагаемых усилий для их учреждения;

- простыми во внедрении и применении;

- лишены обратного эффекта в отношении существующего процесса производства;

- не требовать сопровождения.

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

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

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

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

Примечание - Ранее действующие и настоящий стандарт не затрагивают формальное установление доверия, требующее оценки безопасности с помощью признанных критериев и методологии, например. ИСО/МЭК 15408 и/или ИСО/МЭК 27001.

5.3 Жизненный цикл безопасности

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

При обеспечении безопасности ICS необходимо учитывать следующие категории угроз и контрмер:

- социальные и организационные угрозы и меры, то есть злоумышленники-инсайдеры и несоответствующий мониторинг персонала;

- физические и естественные угрозы и меры, то есть злоумышленники-аутсайдеры и управление физическим доступом;

- электронные и логические угрозы и меры, то есть электронная почта и антивирусные программы.

"Рисунок 2 - Жизненный цикл безопасности"

В настоящем стандарте приведены, в основном, электронные и логические категории, что отмечено на рисунке 2 крупными галочками.

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

Модель предполагает четыре сферы особого внимания:

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

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

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

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

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

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

5.4 Политика

5.4.1 Обзор

Политика - это свод основополагающих принципов и мер безопасности. Меры группируются по аспектам безопасности, которые привязаны к общепризнанным концепциям безопасности.

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

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

"Рисунок 3 - Уровни политики"

5.4.2 Руководящая политика безопасности

Политика на самом верхнем уровне организации санкционирует программу безопасности и обозначает направление. Она устанавливает общие цели безопасности организации.

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

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

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

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

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

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

Данный уровень политики безопасности ICS приведен в разделе 7.

5.4.3 Оперативная политика

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

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

Регламенты должны по возможности затрагивать все необходимые этапы жизненного цикла программы безопасности с точки зрения отдельно взятой организационной единицы:

- разработку системы;

- материально-техническое снабжение;

- технологический процесс;

- сопровождение системы;

- персонал;

- аудит.

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

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

Соответствующий уровень политики безопасности ICS отражен в 7.3.5, который затрагивает следующие сферы управления:

- целостностью;

- логическим доступом;

- физическим доступом;

- сегментами;

- доступностью;

- администрированием, аудитом и нештатными ситуациями;

- внешним доступом.

5.4.4 Рабочие регламенты

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

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

Политику на этом уровне пересматривают каждый раз при утверждении, корректировке или отклонении оперативной политики.

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

Примечание - Регламенты содержат также информацию о порядке изменения других регламентов.

5.4.5 Рабочая методика

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

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

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

5.5 Типовые эталонные конфигурации

5.5.1 Промышленная система управления (ICS)

ICS обычно состоит из электронного оборудования, то есть хостов и устройств, и может включать в себя сети, подсети и соединения "один к одному", как показано на рисунке 4. Как правило, система включает в себя ICN и соединенные с ней оборудование и подсети, а во многих случаях - еще и внешние хосты и устройства внешних сетей, подключенные к данной сети через средства сетевого взаимодействия.

"Рисунок 4 - Промышленная система управления (ICS)"

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

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

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

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

Внешние коммуникации могут служить для соединения ICN с системами, хостами и устройствами, такими как:

- внешний(е) центр(ы) безопасности;

- внешняя(ие) система(ы) поддержки изготовления и управления;

- обособленное(ые) стационарное(ые) устройство(а);

- интерактивный(е) пульт(ы)/хост(ы) интерактивного удаленного доступа;

- пульт(ы)/центр(ы) удаленного доступа;

- портативная(ые) рабочая(ие) станция(и) инженера;

- портативный(е) носитель(и) информации.

5.5.2 Промышленная сеть управления (ICN)

ICN может быть образована путем интегрирования устройств со значительным разнообразием, включая:

- хосты, прокси-серверы, шлюзы, концентраторы, маршрутизаторы;

- периферийное 1Т-оборудование;

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

Хосты ICN могут функционировать как серверы приложений, серверы управления и другие специальные HMI.

ICN соединена непосредственно или опосредованно с выделенными сетями, то есть автоматизированными ячейками и/или сетями периферийных устройств.

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

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

5.5.3 Универсальный хост (GPH) промышленной системы управления

Настоящий стандарт применяют к хостам, которые могут быть аналогичны GPH ICS. Конфигурация GPH, представленная на рисунке 5, иллюстрирует его ключевые компоненты:

- центральный процессор с его неотъемлемыми компонентами, такими как накопитель большой емкости и интерфейсы;

- пульт оператора с устройствами ввода и отображения данных;

- интерфейс/накопитель для считывания информации с внешних носителей данных, таких как USB-накопители и гибкие магнитные диски;

- интерфейс и кабели связи с устройством управления/периферийным устройством;

- интерфейс связи с ICN.

GPH может представлять собой также простую ICS, не содержащую ICN. Такая система может быть впоследствии соединена:

- с внешней общедоступной сетью, такой как Интернет;

- с внешней организационной сетью.

Эталонная конфигурация GPH, приведенная на рисунке 5, даст представление:

- о простейшей ICS без ICN;

- об отдельных хостах в составе ICS как обособленных элементах;

- о любом программируемом/программном устройстве как компоненте ICS в целом;

- об интерфейсе и кабелях связи с внешней сетью, такой как Интернет или корпоративная сеть.

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

"Рисунок 5 - Эталонная конфигурация GPH - GPH ICS с внешними устройствами"

5.6 Модели защиты

5.6.1 Целостность и защита доступа

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

Зоны защиты применительно kGPH представлены на рисунке 6.

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

"Рисунок 6 - Защита устройства - усиление защиты и управление доступом"

Логическая граница вокруг GPH может быть создана мерами по обеспечению целостности - усилением защиты за счет конфигурирования O/S, приложений и служб (на рисунке 6 соответствующие компоненты помещены в круги, обозначенные пунктиром).

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

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

- для операторов и внутренних устройств ICS может быть необходимо подключение к ICN;

- сеть ICN подключена к другим сетям ICN и/или подсетям.

5.6.2 Защита сегментов

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

Рассмотрение сегментов в основном выполняется для:

- самой сети ICN;

- сегментов подсети ICN;

- специальных сегментов сети ICN, например, шлюзов SGW в конфигурации DMZ.

Примечание - ICN определена таким образом, что фактически сама не содержит сегментов внешней сети EN. Ее общая защита от внешних устройств и/или сетей обеспечивается шлюзами внешних подключений (ECG).

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

- самого хоста или устройства от угроз ICN;

- ядра операционной системы и сетевых служб от приложений и инструментов;

- критичных приложений от менее критичных;

- мониторинга безопасности и приложений администрирования от приложений управления.

Основными мерами защиты для сетей с высокой безопасностью являются:

а) иерархическая или ступенчатая структура сегментов;

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

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

Примечание - Для сети или сегментов сети, связанных с приложениями эксплуатационной безопасности, в соответствии с МЭК 61508 (МЭК 61511). особое внимание следует уделять соответствию приложений мониторинга излучений требованиям действующего местного законодательства и приложений контроля качества действующим в промышленности соглашениям, таким, как GAMP 0. В этом случае эта сеть или сегмент сети могут считаться сетью с высокой безопасностью.

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

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

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

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

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

"Рисунок 7 - Эшелонированная оборона за счет использования сегментации"

Внутри сети ICN любой сегмент подсети защищен шлюзом SGW на ее границе. Подобно этому устройства защищены некоторым функционалом безопасности, который показан на рисунке 7 (круги вокруг устройств, выделенные пунктиром).

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

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

Применение принципа эшелонированной обороны, приведенного на рисунке 7, например сценария (адаптированного из рисунка 4), показывает пример сегментации ICS, представленный на рисунке 8.

"Рисунок 8 - Пример - сегментация ICS"

В этой модели защиты периметр ICN защищен шлюзом внешних подключений (ECG) и воротами физического доступа (PAG).

Шлюз ECG является выделенным шлюзом безопасности (SGW) с дополнительным функционалом, удовлетворяющим требованиям конкретной политики, например, для внешних устройств.

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

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

Примеры

- защищенный хост сети управления;

- принцип управления сетью на верхнем/нижнем уровне;

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

- конкретные устройства с усиленной защитой (например, хосты), для которых сегмент соответствует одному устройству. Данные устройства формируют защитный периметр.

5.6.3 Общие меры защиты внешнего доступа

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

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

Внутри ICS имеется два компонента, которые могут реагировать или отвечать на общий внешний доступ (см. рисунок 9):

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

- соответствующее внутреннее оборудование и приложения внутри ICS.

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

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

Примечание - Общий внешний доступ не включает в себя специальных внешних промышленных клиентов управления, которые рассмотрены в 5.6.4.

Установленный общий внешний доступ и новые запросы этого типа соединений должны быть рассмотрены в целях безопасности, например, является ли абсолютно необходимым общий web-доступ внутри ICN.

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

5.6.4 Защита внешнего клиента

Если для работы с ICS требуется связь с удаленными (внешними) клиентами, связь с внешними сетями должна быть защищена. Внешние сети EN с точки зрения ICS являются ненадежными (см. 5.6.3). Безопасность должна быть распространена на архитектуру, реализацию и работу соединения.

Меры по защите внешнего клиента применяются на общих основаниях к сценариям, при которых:

- операторы и внутренние устройства ICS могут нуждаться в доступе к внешним ресурсам, например, для обновления или для получения информации управления;

- внешние операторы и устройства ICS могут получать доступ к ICN, например, для целей диагностики, обслуживания и/или управления.

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

"Рисунок 9 - Общие внешние соединения"

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

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

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

Повышение требований безопасности может потребовать связи с оборудованием ICS для транзита через прокси-сервер приложений внутри ICN, так как использование прокси-серверов существенно улучшает безопасность.

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

6 Политика безопасности промышленной системы управления - основные сведения

Хосты ICS, сеть ICN, внутренние устройства, внешние хосты или устройства должны быть безопасными, вместе с их клиентами, каналами доступа, используемыми хостами клиентов и устройствами для связи с ними.

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

Примечание 1 - Политика также учитывает исключения, допуская управление ими и анализ рисков отклонения от политики.

Предлагаемые меры политики безопасности ICS сгруппированы по подпунктам соответствующего содержания:

- принципы, описывающие политику, представляют собой общие положения, применимые ко всем мерам безопасности, принимаемым в расчет для IC3 и ее ICN, в том числе к предварительным условиям безопасности и заданным исключениям из политики, например, к требованиям безопасности, связанным с безопасностью эксплуатации:

- управление доступностью, как специфическая проблема сетей реального времени, нечасто встречающаяся в общем IT (см. 8.1);

- управление целостностью, включая требования для:

- защиты от вирусов и другого вредоносного программного обеспечения;

- обновления и исправления ошибок программного обеспечения и фирменного программного обеспечения;

- резервного копирования;

- целостности файлов и файловой системы;

- усиления защиты аппаратных средств, операционной системы и приложений;

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

- идентификации пользователя;

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

- шифрования;

- управления всем вышеперечисленным.

Примечание - Эта категория мер неразрывно связана с правилами, управляющими работой шлюзов безопасности;

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

- идентификации пользователя;

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

- управления всем вышеперечисленным;

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

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

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

- управления исключениями;

- протоколирования и мониторинга;

- реагирования на опасные условия.

7 Политика безопасности промышленной системы управления - принципы и допущения

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

7.1 Политика безопасности промышленной системы управления - принципы

7.1.1 Политика безопасности ICS превалирует над подчиненными политиками, за исключением случаев, когда явно выражено иное.

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

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

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

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

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

Дополнительная информация относительно безопасности приведена в соглашениях со сторонними организациями в соответствии с ИСО/МЭК 27002.

7.1.2 Политика безопасности ICS подчиняется политике безопасности организации и дополняет ее. При возникновении конфликта политика безопасности организации является приоритетной.

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

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

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

Дополнительная информация - по ИСО/МЭК 27002.

7.1.3 Политика безопасности ICS подчинена функциональной политике безопасности, связанной с безопасностью эксплуатации.

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

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

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

7.1.4 Политика безопасности ICS дополняет требования местного или национального законодательства. При возникновении противоречий приоритет имеют требования местного или национального законодательства.

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

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

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

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

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

Примечание - В соответствии с требованиями эксплуатационной безопасности, установленными в МЭК 61508 и МЭК 61511, приложения, осуществляющие мониторинг, излучений должны соответствовать требованиям действующего местного законодательства и требованиям к приложениям контроля качества, изложенным в GAMP [16]. Они могут подпадать под действие этого положения.

7.2 Политика безопасности промышленной системы управления - допущения и исключения

7.2.1 Политика безопасности ICS не обеспечивает доступности данных функционирования и целостности этих данных.

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

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

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

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

7.2.2 Политика безопасности ICS не является всеобъемлющей политикой безопасности.

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

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

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

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

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

Дополнительная информация - по ИСО/МЭК 27002.

7.2.3 Политика безопасности ICS не распространяется на закупки.

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

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

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

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

Дополнительная информация - по [16].

Примечание - В настоящее время нет единой точки зрения или установившейся практики по дальнейшим рекомендациям обеспечения безопасности и тестирования безопасности соответствующего оборудования и устройств ICS.

7.2.4 Политика безопасности ICS не обеспечивает всестороннего оперативного управления безопасностью.

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

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

Дополнительная информация - по ISO/IEC 27002.

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

Это обосновано тем, что в случае, когда штатная политика определяет эксплуатационную безопасность, и/или в случае, когда используются общепринятые практические способы, например GAMP [16], такая политика, практические способы и меры имеют приоритет над политикой безопасности, рассматриваемой в настоящем стандарте.

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

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

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

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

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

Примечание - Меры по резервированию для достижения доступности в типичном случае приводят к увеличению незащищенности данных и к повышению связанных с этим рисков.

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

7.2.6 Политика безопасности ICS не распространяется на доступность сети ICN и ее подсетей, а также на реагирование в реальном времени для любых каналов EN.

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

Примечание - Это означает, что эксплуатация ICS в реальном времени не может базироваться на EN. ICN или подсетях ICN. В частности, центры удаленного управления могут реагировать неудовлетворительно.

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

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

Пример - Ячейка автоматизации AC (automation cell) в типичном случае будет защищена на своей границе шлюзом SGW с требуемой защитой. Физический доступ будет разрешен только уполномоченному персоналу. Вся связь внутри ячейки считается надежной.

7.2.7 Политика безопасности ICS не распространяется на эксплуатацию завода в опасных условиях.

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

Примечание - Это означает, что эксплуатация ICS в опасных условиях не может базироваться на EN, ICN или подсетях ICN. В частности, может оказаться невозможным использовать центры удаленного управления.

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

7.3 Политика безопасности промышленной системы управления - организация и управление

Процедуры и методы управления, необходимые для эксплуатации и аудита политики безопасности.

7.3.1 Ответственность за разработку, реализацию, соблюдение, проверку и изменение политики безопасности ICS несет администрация ICS.

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

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

7.3.1.1 Оперативная ответственность за соблюдение политики безопасности ICS должна быть возложена на менеджера по безопасности, который должен быть оперативно независим от ICS и эксплуатации завода.

Примечание 1 - Разделение ответственности за реализацию усиления безопасности и поддержание политики безопасности иногда рекомендуется регуляторами. Это снижает риски безопасности.

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

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

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

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

Примечание 3 - Администрирование безопасности и сетевого оборудования должно быть выполнимо даже в случае атаки или при реагировании на атаку. Должны иметься также каналы для передачи производственного трафика.

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

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

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

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

7.3.1.7 Должны проводиться проверки политики как периодические, так и после инцидентов.

7.3.2 Управление рисками угроз

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

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

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

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

7.3.2.2 Среда угрозы должна непрерывно контролироваться и оцениваться.

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

Примечание 1 - Методы криптографии должны периодически корректироваться в целях соответствия развитию технологий.

Примечание 2 - Изменения, например в правилах SGW и ECG, учитывающие виды и уровни угроз, должны приводить к изменению конфигураций, технологий, добавлению дополнительных мер и оборудования и т.д.

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

7.3.3 Политика эксплуатационной безопасности ICS и ее изменения должны быть скоординированы с политикой безопасности ICS.

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

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

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

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

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

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

7.3.3.4 Не должно быть исключений, которые удаляют исключения, утвержденные двумя ответственными.

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

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

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

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

7.3.4.2 Все события системы, существенные для безопасности, должны быть запротоколированы.

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

7.3.4.4 Все протоколы и информация аудита должны непрерывно контролироваться, периодически проверяться, надежно храниться и архивироваться.

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

7.3.4.6 Действия по управлению протоколами также должны протоколироваться. Только аудитор службы безопасности должен иметь право удалять или изменять протоколы.

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

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

Примечание - Если безопасность нарушена, сетевое соединение между удаленным и локальным центром управления должно быть прервано до восстановления надежности соединения. Локальный центр управления должен осуществлять безопасную эксплуатацию ICS. Для подтверждения восстановления надежности соединения должен быть выполнен аудит безопасности.

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

Пример

Могут протоколироваться следующие данные:

- событие, например ошибка аутентификации, нарушение доступа;

- срочность, например авария, сигнал тревоги, предупреждение;

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

- хост источника, например IP-адрес, имя хоста;

- назначение, например IP-адрес, имя хоста, URL;

- идентификатор пользователя;

- дата и время начала;

- дата и время окончания.

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

7.3.5 Должен проводиться аудит соответствия политики безопасности ICS.

Это обосновано тем, что для контроля характеристик управления политикой ICS необходим аудит.

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

7.3.5.1 Аудит соответствия политики ICS должен выполняться периодически и, если необходимо, приводить к принятию обоснованных корректирующих мер,

7.3.5.2 Аудиты могут включать тестирование безопасности.

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

7.3.5.3 Ответственность за аудит безопасности предпочтительно возложить на квалифицированного менеджера по безопасности, не участвующего в эксплуатации, возможно, на стороннего специалиста.

7.3.5.4 Если возможно, следует разделить должности аудитора и администратора, отвечающих за меры безопасности.

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

7.3.6 Должно осуществляться управление исключениями и их документирование для обеспечения необходимой отчетности по сотрудникам и устройствам с использованием управления рисками ad hoc (для данной конкретной цели - лат.).

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

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

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

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

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

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

7.3.6.3 Не должно быть исключений, исключающих управление.

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

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

Правила реализации политик приведены в 7.3.7.1 - 7.3.7.10,

7.3.7.1 Должны быть установлены планы действий в непредвиденных ситуациях. Они должны периодически обновляться,

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

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

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

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

Примечание 1 - В некоторых старых приложениях для доступа к устройствам ICS или удаленным клиентам используется протокол с открытым текстом сертификата (например, Telnet, FTP]. В этом случае доступ должен использовать надежный протокол туннелирования во избежание раскрытия сертификатов на любой части маршрута, раскрываемой общедоступными внешними сетями ЕN.

Примечание 2 - Должно осуществляться управление исключениями и их документирование.

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

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

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

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

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

7.3.7.10 Вызванные инцидентами безопасности катастрофы требуют планов восстановления после катастроф и аварий, а также соответствующей контактной информации и информации по восстановлению,

Примечание - Об использовании и мониторинге системы доступа см. ИСО/МЭК 27002.

8 Политика безопасности промышленной системы управления - меры

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

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

8.1 Управление доступностью

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

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

8.1.1 Доступность ICN и подсетей ICN должна быть гарантирована для требований эксплуатации ICS в критических условиях.

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

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

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

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

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

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

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

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

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

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

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

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

- специальных собственных средств связи;

- существующих собственных механизмов эксплуатационной безопасности;

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

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

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

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

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

8.1.2.5 В случае конфликта приоритет должен иметь функционал управления критичным промышленным оборудованием.

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

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

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

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

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

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

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

8.1.3.1 Если установка, изменение или удаление привели к ожидаемым из