• Текст документа
  • Статус
Оглавление
Поиск в тексте
Действующий


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

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

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

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

Часть 3-3

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

Industrial communication networks. Network and system security. Part 3-3. System security requirements and security levels


     
ОКС 25.040.40;
         35.110

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

     
     
Предисловие

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

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

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

4 Настоящий стандарт идентичен международному стандарту МЭК 62443-3-3:2013* "Сети промышленной коммуникации. Безопасность сетей и систем. Часть 3-3. Требования к системной безопасности и уровни безопасности" (IEC 62443-3-3-1:2013 "Industrial communication networks - Network and system security - Part 3-3: System security requirements and security levels", IDT).
________________
     * Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке на сайт http://shop.cntd.ru. - Примечание изготовителя базы данных.
     
          
     Международный стандарт разработан Техническим комитетом МЭК ТК 65 "Измерения и управление в промышленных процессах".
     
     При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА
     

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

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

0 Введение

0.1 Обзор


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

* Вероятно, ошибка оригинала. Следует читать ГОСТ Р 56205-2014 IEC/TS 62443-1-1:2009, здесь и далее по тексту. - Примечание изготовителя базы данных.


     
     Примечание 2 - Формат настоящего стандарта соответствует требованиям ИСО/МЭК, рассмотренным в Директивах ИСО/МЭК, часть 2 [11] ГОСТ Р МЭК 62443-3-3-2016 Сети промышленной коммуникации. Безопасность сетей и систем. Часть 3-3. Требования к системной безопасности и уровни безопасности. Эти директивы регламентируют формат стандарта, а также использование терминов типа "должен", "должен по возможности" и "может". Для требований, определенных в обязательных пунктах, использованы соглашения, рассмотренные в приложении Н Директив ИСО/МЭК.
_________________
     ГОСТ Р МЭК 62443-3-3-2016 Сети промышленной коммуникации. Безопасность сетей и систем. Часть 3-3. Требования к системной безопасности и уровни безопасности Цифры в квадратных скобках относятся к элементу стандарта "Библиография".
     
     
     Организации, эксплуатирующие системы промышленной автоматизации и контроля (IACS), все чаще используют коммерчески доступные (COTS) сетевые устройства, которые имеют малую стоимость, эффективны и высокоавтоматизированы. Кроме того, из веских коммерческих соображений, системы управления все чаще взаимодействуют и с сетями, не относящимися к IACS. Эти устройства, общедоступные сетевые технологии и возросшие возможности сетевого взаимодействия расширяют возможности для кибератак на аппаратное и программное обеспечение систем управления. Эта проблема может иметь последствия, затрагивающие охрану труда, технику безопасности и охрану окружающей среды (HSE), и/или наносить финансовые убытки и/или ущерб репутации всюду, где внедряются системы управления.
     
     Организации, внедряющие бизнес-решения в сфере кибербезопасности информационных технологий (IT) для разрешения вопросов, связанных с безопасностью IACS, могут не вполне осознавать последствия такого выбора. Хотя многие коммерческие прикладные IT-объекты и решения безопасности могут быть применимы к IACS, их необходимо применять надлежащим образом для исключения непредвиденных последствий. По этой причине подход, используемый для определения системных требований, должен базироваться на комбинации функциональных требований и оценки риска и зачастую включает в себя и необходимость иметь осведомленность в вопросах эксплуатации.
     
     Меры безопасности IACS не должны иметь возможность приводить к нарушению существенных сервисов и функций, включая процедуры при нештатных ситуациях. (Часто меры безопасности IT имеют данную тенденцию.) Обеспечение безопасности IACS нацелено на работоспособность и доступность систем управления, защищенность производственных объектов, производственных процессов (хотя бы в режиме ограниченной функциональности) и времени отклика системы, где это имеет критическое значение. В рамках целей IT-безопасности этим факторам зачастую придается меньшее значение. Большее значение придается защите информации, чем защите физических объектов. Эти различные цели должны быть четко определены как цели безопасности, независимо от степени достигнутой интеграции производственного объекта. Ключевым этапом в оценке риска согласно требованиям МЭК 62443-2-1ГОСТ Р МЭК 62443-3-3-2016 Сети промышленной коммуникации. Безопасность сетей и систем. Часть 3-3. Требования к системной безопасности и уровни безопасности должна по возможности быть идентификация тех сервисов и функций, которые действительно существенны для процессов хозяйствования. (Например, на тех или иных объектах техническая поддержка может быть определена как несущественный сервис или функция.) В некоторых случаях может быть допустимо, чтобы операция безопасности провоцировала временную утрату несущественного сервиса или функции, но по возможности не сказывалась отрицательно на существенном сервисе или функции.
_________________
     ГОСТ Р МЭК 62443-3-3-2016 Сети промышленной коммуникации. Безопасность сетей и систем. Часть 3-3. Требования к системной безопасности и уровни безопасности Многие стандарты из стандартов серии МЭК 62443 в настоящее время находятся на пересмотре или доработке.
     
     
     Настоящий стандарт предполагает, что программа безопасности учреждена и управляется в соответствии с МЭК 62443-2-1. Кроме того, предполагается, что управление патчами осуществляется сообразно рекомендациям, подробно рассмотренным в МЭК/ТО 62443-2-3 [5], с соблюдением соответствующих требований и их доработок, описанных в настоящем стандарте, применительно к системам управления. Также в МЭК 62443-3-2 [8] описано, каким образом проект задает уровни безопасности (SL), основанные на риске, которые затем используются для выбора продуктов с подходящими техническими характеристиками безопасности, что подробно рассмотрено в настоящем стандарте. Ключевой исходный материал для настоящего стандарта включал в себя ИСО/МЭК 27002 [15] и NIST SP800-53, ред.3 [24] (см. раздел 2 и Библиографию, которые содержат более полный перечень первоисточников).
     
     Основная задача стандартов из стандартов серии МЭК 62443 - предоставить гибкую концепцию, которая облегчает устранение текущих и будущих уязвимостей в IACS и применение необходимых смягчающих мер в систематическом, оправданном порядке. Важно понимать, что назначение серии МЭК 62443 - сформировать расширения корпоративной безопасности, которые перенимают требования к коммерческим IT-системам и увязывают эти требования с едиными требованиями по обеспечению надежной работоспособности, необходимой в IACS.
     
     

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


     Целевая аудитория настоящего стандарта рассчитана на работников, имеющих отношение к системам IACS, и включает в себя собственников имущественных объектов, системных интеграторов, поставщиков продуктов, провайдеров сервисов и - в меру целесообразности - органы нормативно-правового регулирования. Органы нормативно-правового регулирования включают в себя правительственные агентства и регламентирующие органы, при этом нормативно-правовой орган должен осуществлять аудиты для проверки соответствия регулирующим законам и нормам.
     
     Системным интеграторам, поставщикам продуктов и провайдерам сервисов настоящий стандарт послужит для оценки того, могут ли их продукты и сервисы обеспечивать потенциал функциональной безопасности, который соответствует требованиям целевого уровня безопасности (SL-T) собственника имущественного объекта. Как и в случае с присвоением уровней SL-T, применимость системных требований (SR) к отдельно взятой системе управления и расширений к этим требованиям (RE) должна базироваться на политиках безопасности собственника объекта, регламентах и оценке риска в контексте относящегося к ним участка применения. Следует отметить, что некоторые SR содержат специальные условия для допустимых исключений, например в случае, когда соответствие SR идет вразрез с фундаментальными требованиями эксплуатации системы управления (что может спровоцировать необходимость компенсационных контрмер).
     
     Если разрабатываемая система управления должна соответствовать набору SR, привязанных к конкретным SL-T, то не требуется, чтобы каждый компонент предлагаемой системы управления соответствовал каждому системному требованию до степени, предписываемой настоящим стандартом. Могут применяться компенсационные контрмеры для придания необходимой функциональности другим подсистемам, так чтобы общие требования SL-T выполнялись на уровне системы управления. Включение в расчет компенсационных контрмер на стадии разработки следует подкреплять исчерпывающей документацией, чтобы итоговый достигнутый SL-A системы управления полностью отражал расчетные характеристики безопасности, присущие проекту. Точно так же в ходе сертификационных испытаний и/или постинсталляционных аудитов могут применяться и документироваться компенсационные контрмеры для обеспечения соответствия общему SL системы управления.
     
     В настоящем стандарте представлена не достаточно детальная информация для разработки и построения интегрированной архитектуры безопасности. Это потребовало бы дополнительного анализа на системном уровне и разработки производных требований, которые являются темой других стандартов серии МЭК 62443 (см. 0). Следует отметить, что задачей настоящего стандарта не является формирование спецификаций, достаточно детальных для построения архитектуры безопасности. Задачей является определение общего минимального набора требований для достижения соответствия все более строгим уровням безопасности. Сам проект архитектуры, удовлетворяющей этим требованиям, - это работа системных интеграторов и поставщиков продуктов. В рамках этой задачи они удерживают за собой право индивидуальных выборов, поддерживая тем самым конкуренцию и инновационную деятельность. Таким образом, в настоящем стандарте строго выдержан принцип определения функциональных требований и не рассматривается возможный порядок соответствия этим функциональным требованиям.
     
     

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


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


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

ГОСТ Р МЭК 62443-3-3-2016 Сети промышленной коммуникации. Безопасность сетей и систем. Часть 3-3. Требования к системной безопасности и уровни безопасности


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


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

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


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

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

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

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

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

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

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

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

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

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


     В настоящем стандарте использованы нормативные ссылки на следующие стандарты*. Для датированных ссылок применяют только указанное издание ссылочного документа. Для недатированных ссылок применяют последнее издание ссылочного документа (включая все его изменения).
_______________
     * Таблицу соответствия национальных стандартов международным см. по ссылке. - Примечание изготовителя базы данных.     

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

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

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


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

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

3.1.2 собственник объекта (asset owner): Лицо или организация, отвечающие за один или более IACS.
     
     Примечание 1 - Термин "собственник объекта" используется взамен родового термина "конечный пользователь" в целях их дифференциации.
     
     Примечание 2 - Это определение распространяется на компоненты, являющиеся частью IACS.
     
     Примечание 3 - В контексте настоящего стандарта собственник объекта включает в себя также оператора IACS.
     
     

3.1.3 атака (attack): Посягательство на систему, являющееся следствием рациональной угрозы.
     
     Примечание 1 - Например, осмысленное действие, представляющее собой продуманную попытку (особенно в плане метода или стратегии) обойти сервисы безопасности и нарушить политику безопасности системы.
     
     Примечание 2 - Существуют различные общепризнанные типы атак:
     
     - "активная атака" имеет целью преобразовать ресурсы системы или воздействовать на их работу;
     
     - "пассивная атака" имеет целью заполучить или использовать информацию системы без воздействия на ресурсы системы;
     
     - "внутренняя атака" - атака, инициированная субъектом в пределах периметра безопасности ("инсайдером") - т.е. субъектом, который наделен правами на получение доступа к ресурсам системы, но использует их в целях, не одобренных теми, кто предоставил эти права;
     
     - "внешняя атака" - атака, инициированная за пределами периметра безопасности неавторизованным или неуполномоченным пользователем системы (им может быть и инсайдер, атакующий за пределами периметра безопасности). Потенциальными злоумышленниками, осуществляющими внешнюю атаку, могут быть как простые любители пошутить, так и организованные преступные группы, международные террористы и враждебные правительства.
     

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1.32 мобильный код (mobile code): Программа, передаваемая в пределах удаленной, возможно - "недоверенной", системы через сеть или съемные носители, которая может запускаться в неизменном виде на локальной системе без явной инсталляции или запуска этой программы получателем.
     
     Примечание - Примеры мобильного кода включают в себя JavaScript, VBScript, Java-апплеты, управляющие элементы ActiveX, Flash-анимации, видеофрагменты Shockwave и макросы Microsoft Office.
     
     

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

3.1.34 производитель продукта (product supplier): Производитель аппаратного и/или программного продукта.
     
     Примечание - Данное понятие используется взамен обобщенного термина "поставщик" в целях их дифференциации.
     
     

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

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

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

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

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

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

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

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

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

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

3.1.45 доверие (trust): Уверенность в том, что на операцию, источник данных, сетевой или программный процесс можно полагаться в отношении их ожидаемого функционирования.
     
     Примечание 1 - В общем случае может считаться, что некий субъект "доверяет" второму субъекту, если делает допущение, что второй субъект будет функционировать в соответствии с ожиданиями первого субъекта.
     
     Примечание 2 - Это доверие может быть применимо только в отношении какой-то конкретной функции.
     
     

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

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

3.2 Сокращения


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

AES

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

API

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

ASLR

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

BPCS

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

СА

- центр сертификации;

CIP

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

COTS

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

CRL

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

DC

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

DEP

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

DHCP

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

DMZ

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

DNS

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

DoS

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

EICAR

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

EMI

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

FAT

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

FIPS

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

FR

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

FS-PLC

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

FTP

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

GLONASS

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

GPS

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

HMI

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

HSE

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

HTTP

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

HTTPS

- HTTP защищенный;

IAC

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

IACS

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

IAMS

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

ID

- идентификатор;

IDS

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

IЕС

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

IEEE

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

IETF

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

IM

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

IP

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

IPS

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

ISA

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

ISO

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

IT

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

MES

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

NERC

- Североамериканская корпорация по обеспечению надежности электросистем;

NIST

- Национальный институт стандартов и технологий (США);

NX

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

OCSP

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

OWASP

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

PDF

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

PKI

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

PLC

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

RA

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

RAM

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

RDF

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

RE

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

RFC

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

RJ

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

RTU

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

SAT

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

SHA

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

SI

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

SIEM

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

SIF

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

SIL

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

SIS

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

SL

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

SL-A

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

SL-C

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

SL-T

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

SP

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

SR

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

SSH

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

SuC

- рассматриваемая система;

TCP

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

ТРМ

- модуль доверительной платформы;

TRE

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

UC

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

USB

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

VoIP I

- Р-телефония;

WEP

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

WLAN

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

3.3 Допущения


     Настоящий стандарт расширяет семь FR, установленных в МЭК 62443-1-1, до серии SR. Каждое SR содержит основополагающее требование, а также может содержать одно или несколько расширений требования (RE) для ужесточения безопасности. По мере необходимости для читателя дополнительно приводятся наглядная и аргументированная методологическая основа к каждому основополагающему требованию и комментарии к любым привязанным к ним RE. Основополагающее требование и расширения RE, при их наличии, затем ставятся в соответствие одному из четырех потенциальных уровней безопасности SL-C (FR, система управления).
     
     Все семь FR имеют определенный набор из четырех SL. Применительно к системе управления соответствие уровню 0 для отдельно взятого FR определено неявным образом как отсутствие требований. Например, постановка задачи для раздела 8, FR 4 - Конфиденциальность данных, звучит следующим образом:
     
     Обеспечивать конфиденциальность информации на коммуникационных каналах и в хранилищах данных для предотвращения их неавторизованного раскрытия.
     
     Соответствующие четыре SL определены как:
     
     - SL 1 - предотвращать неавторизованное раскрытие информации посредством ее несанкционированного извлечения или случайного обнародования;
     
     - SL 2 - предотвращать неавторизованное раскрытие информации субъекту, активно ее ищущему с использованием простых средств, при незначительных ресурсах, посредственных навыках и низкой мотивации;
     
     - SL 3 - предотвращать неавторизованное раскрытие информации субъекту, активно ее ищущему с использованием изощренных средств при умеренных ресурсах, наличии специальных познаний в IACS и умеренной мотивации;
     
     - SL 4 - предотвращать неавторизованное раскрытие информации субъекту, активно ее ищущему с использованием изощренных средств при обширных ресурсах, наличии специальных познаний в IACS и высокой мотивации.
     
     Таким образом, выдвижение отдельных SR и RE основано на ступенчатом повышении общей безопасности системы управления для данного конкретного FR.
     
     SL-C (система управления), используемый на протяжении всего настоящего стандарта, обозначает наличие ресурсов, необходимых для соответствия конкретному SL, соотносящемуся с конкретным FR. Полное описание векторной концепции SL можно найти в приложении А.
     
     

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

4.1 Обзор


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

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


     Как определено в 3.1.22, жизненно важная функция - это функция или возможность, необходимая для обеспечения охраны труда, техники безопасности и охраны окружающей среды, а также работоспособности и доступности управляемого оборудования.
     
     Меры безопасности не должны отрицательно сказываться на существенных функциях IACS с высокой работоспособностью, за исключением случаев, оправданных с точки зрения оценки рисков.
     
     Примечание - См. МЭК 62443-2-1, в котором приведены требования к документированию, относящиеся к оценке рисков, необходимой для обоснования случаев, когда меры безопасности могут отрицательно сказываться на жизненно важных функциях.
     
     
     В ходе ознакомления, определения и реализации SR, описанных в настоящем стандарте, и реализации мер безопасности по возможности не должны утрачиваться защищенность, управление, возможность отслеживания или другие жизненно важные функции. После анализа рисков может оказаться, что те или иные технические средства обуславливают определенные типы мер безопасности, которые могут вызвать сбои в непрерывных процессах, однако меры безопасности не должны приводить к утрате защищенности, способной отразиться на охране труда, технике безопасности и охране окружающей среды (HSE). Вот некоторые специальные ограничения:
     
     - меры управления доступом (IAC и UC) не должны препятствовать управлению жизненно важными функциями, а именно:
     
     - учетные записи, используемые для жизненно важных функций, не должны блокироваться, в том числе временно (см. 5.5, SR 1.3 - Управление учетными записями, 5.6, SR 1.4 - Управление идентификаторами, 5.13, SR 1.11 - Неуспешные попытки входа в систему, и 6.7, SR 2.5 - Блокировка сессий);
     
     - верификация и фиксация действий операторов для укрепления защиты от непризнания участия не должны вносить существенных задержек в быстродействие системы (см. 6.14, SR 2.12 - Защита от непризнания участия);
     
     - для систем управления с высокой работоспособностью отказ Центра сертификации не должен вызывать сбои жизненно важных функций [см. 5.10, SR 1.8 - сертификаты Инфраструктуры открытых ключей (PKI)];
     
     - идентификация и аутентификация не должны препятствовать инициации SIF (см. 5.3, SR 1.1 - Идентификация и аутентификация пользователя - физического лица, и 5.4, SR 1.2 - Идентификация и аутентификация программных процессов и устройств). То же самое относится и к контролю выполнения авторизации (см. 6.3, SR 2.1 - Контроль выполнения авторизации);
     
     - записи аудитов с некорректными временными метками (см. 6.10, SR 2.8 - События, подлежащие аудиту, и 6.13, SR 2.11 - Временные метки) не должны отрицательно отражаться на жизненно важных функциях;
     
     - жизненно важные функции IACS должны сохраняться, если защита границ зон переходит в режим закрытия при отказе и/или островной режим (см. 9.4, SR 5.2 - Защита границ зон);
     
     - событие DoS в сети системы управления или в SIS не должно препятствовать срабатыванию SIF (см. 11.3, SR 7.1 - Защита от отказов в обслуживании).
     
     

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


     Компенсационные контрмеры, раскрытые в настоящем стандарте, должны быть привязаны к директивам, приведенным в МЭК 62443-3-2.
     
     В настоящем стандарте в порядке нормативов SR говорится, что "система управления должна обеспечивать возможность..." поддержания того или иного требования безопасности. Система управления должна обеспечивать возможность, но она может реализовываться с помощью внешнего компонента. В этом случае система управления должна образовывать "интерфейс" к этому внешнему компоненту. Некоторые примеры компенсационных контрмер включают в себя идентификацию пользователей (в том числе централизованную в противоположность распределенной), повышение надежности паролей, проверку достоверности подписей, выявление корреляций событий безопасности и списание устройств (сохранность информации).
     
     Примечание 1 - Требования безопасности систем управления, детально раскрытые в настоящем стандарте, касаются всех технических функций, имеющих отношение к системе управления, включая ее инструменты и приложения. Однако, как отмечается здесь, некоторые из этих функций могут управляться посредством внешнего ресурса.
     
     Примечание 2 - В некоторых приложениях с высокой работоспособностью и доступностью ресурсов [высоким SL-T (RA, система управления)] потребуются компенсационные контрмеры, внешние по отношению к системе управления (например, дополнительные меры физической безопасности и/или ужесточенные проверки биографических данных персонала). В этих случаях можно встретить систему управления с SL, как правило, соответствующим высокой работоспособности и доступности ресурсов, при более низких SL IAC - 1 или 2, в зависимости от компенсационных контрмер. Для системы управления с SL, соответствующим очень высокой работоспособности и доступности, вероятность блокировки или утраты управления из-за мер безопасности возрастает, а не наоборот. Таким образом, высокие SL не всегда "лучше", даже если расходы не являются существенным фактором.
     
     

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


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

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

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


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

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


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

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

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

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

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

5.3.3.1 SR 1.1 RE1 - Уникальная идентификация и аутентификация
     
     Система управления должна обеспечивать возможность уникальной идентификации и аутентификации всех пользователей - физических лиц.
     

5.3.3.2 SR 1.1 RE2 - Многофакторная аутентификация для недоверенных сетей
     
     Система управления должна обеспечивать возможность применения многофакторной аутентификации для осуществления доступа пользователей - физических лиц к системе управления через недоверенную сеть (см. 5.15, SR 1.13 - Доступ через недоверенные сети).
     
     Примечание - См. 5.7.3.5.7.3.1, SR 1.5 - Управление аутентификаторами, RE5.7.3.1 относительно расширенного управления аутентификаторами для программных процессов.
     
     

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

5.3.4 Уровни безопасности
     
     Ниже приведены требования к четырем уровням SL, относящимся к SR 1.1 - Идентификация и аутентификация людей-пользователей:
     
     - SL-C (IAC, система управления) 1: SR 1.1;
     
     - SL-C (IAC, система управления) 2: SR 1.1 (1);
     
     - SL-C (IAC, система управления) 3: SR 1.1 (1) (2);
     
     - SL-C (IAC, система управления) 4: SR 1.1 (1) (2) (3).
     
     

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

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

5.4.2 Целесообразность и дополнительная методологическая основа
     
     Функция идентификации и аутентификации - присвоение ID неизвестному программному процессу или устройству (далее в этом подпункте упоминаются как субъект) для его выявления перед санкционированием любого обмена данными. Если допустить отправку и получение неподконтрольными субъектами данных, относящихся к системам управления, то можно спровоцировать нештатное поведение легитимной системы управления.
     
     Все субъекты должны быть идентифицированы и аутентифицированы при получении любого доступа к системе управления. Аутентификация идентичности таких субъектов должна по возможности осуществляться с использованием таких методов, как пароли, токены или местонахождение (физическое или логическое). Это требование должно быть по возможности применимо и к локальному, и к удаленному доступу к системе управления. Однако в некоторых сценариях, когда одиночные субъекты используются в подключении к различным конечным системам (например, к удаленной поддержке поставщиков), может быть технически невозможно присвоить одному субъекту более одной персоналии. В этих случаях должны применяться компенсационные контрмеры.
     
     Механизмы идентификации и аутентификации всех субъектов необходимы для обеспечения защиты от атак, таких как "человек посередине" или спуфинг сообщений. В некоторых случаях эти механизмы могут затрагивать более одного программного процесса, функционирующего на одном и том же физическом сервере, причем каждый процесс имеет свою собственную идентичность. В других случаях идентичность может быть привязана к физическому устройству, например когда все процессы функционируют на некотором конкретном PLC.
     
     Следует уделять особое внимание идентификации и аутентификации портативных и подвижных устройств. Устройства этого типа являют собой известный способ внесения нежелательного сетевого трафика, вредоносного программного обеспечения и/или раскрытия информации, относящейся к системам управления, включая изолированные в обычных случаях сети.
     
     Там, где субъекты действуют как единая группа, идентификация и аутентификация могут быть на основе ролей, групп или субъектов, при этом жизненно важно, чтобы требования идентификации или аутентификации не ограничивали локальные действия в чрезвычайных ситуациях, а также жизненно важные функции систем управления (см. раздел 4 для получения более полных сведений). Например, в рамках общих схем защиты и управления устройства из некой группы совместно исполняют функции защиты и осуществляют коммуникацию многоадресными сообщениями между устройствами в составе группы. В этих случаях обычно используется групповая аутентификация на основе разделенных учетных записей или разделенных симметричных ключей.
     
     Для того чтобы поддерживать политики управления идентификацией и аутентификацией, как определено в соответствии с МЭК 62443-2-1, система управления в качестве первого этапа верифицирует идентичность всех субъектов. На втором этапе с субъектом ассоциируются полномочия, вмененные идентифицированному субъекту (см. 6.3, SR 2.1 - Обязательная авторизация).
     

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

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

5.4.3.2 Пусто
     

5.4.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 1.2 - Идентификация и аутентификация программных процессов и устройств:
     
     - SL-C (IAC, система управления) 1: не определены;
     
     - SL-C (IAC, система управления) 2: SR 1.2;
     
     - SL-C (IAC, система управления) 3: SR 1.2 (1);
     
     - SL-C (IAC, система управления) 4: SR 1.2 (1).
     
     

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

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

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

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

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

5.5.3.2 Пусто
     

5.5.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 1.3 - Управление учетными записями:
     
     - SL-C (IAC, система управления) 1: SR 1.3;
     
     - SL-C (IAC, система управления) 2: SR 1.3;
     
     - SL-C (IAC, система управления) 3: SR 1.3 (1);
     
     - SL-C (IAC, система управления) 4: SR 1.3 (1).
     
     

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

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

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

5.6.3 Расширения требований
     
     Отсутствуют.
     

5.6.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 1.4 - Управление идентификаторами:
     
     - SL-C (IAC, система управления) 1: SR 1.4;
     
     - SL-C (IAC, система управления) 2: SR 1.4;
     
     - SL-C (IAC, система управления) 3: SR 1.4;
     
     - SL-C (IAC, система управления) 4: SR 1.4.
     
     

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

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

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

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

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

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

5.7.2 Целесообразность и дополнительная методологическая основа
     
     Наряду с идентификатором (см. 5.6, SR 1.4 - Управление идентификаторами) аутентификатор необходим для подтверждения идентичности. Аутентификаторы систем управления включают в себя, но не ограничиваются этим, токены, симметричные ключи, секретные ключи (часть пары из открытого/секретного ключа), биометрические признаки, пароли, физические ключи и карточки с ключом. Пользователи - физические лица должны по возможности принимать разумные меры для обеспечения безопасности аутентификаторов, в том числе хранить при себе личные аутентификаторы, не одалживать и не использовать аутентификаторы совместно и немедленно сообщать об утрате или нарушении безопасности аутентификаторов.
     
     Аутентификаторы имеют жизненный цикл. Когда создается учетная запись, то автоматически должен быть создан новый аутентификатор, чтобы можно было аутентифицировать держателя учетной записи. Например, в системе на основе паролей учетная запись содержит привязанный к ней пароль. Определение начального содержания аутентификатора может быть интерпретировано как определение администратором начального пароля, который система управления учетными записями устанавливает для всех новых учетных записей. Возможность конфигурации этих начальных символов усложняет для злоумышленника разгадывание пароля, установленного между созданием учетной записи и первым использованием учетной записи (что должно предполагать задание нового пароля держателем учетной записи). Некоторые системы управления инсталлируются с помощью автоматических инсталляторов, которые создают все необходимые учетные записи с паролями, устанавливаемыми по умолчанию, а некоторые встраиваемые устройства поставляются с паролями, установленными по умолчанию. Зачастую со временем эти пароли становятся всеобщим достоянием и фиксируются в Интернете. Возможность изменения паролей, оставленных по умолчанию, позволяет защитить систему от неавторизованных пользователей, которые используют пароли, оставленные по умолчанию, для получения доступа. Пароли могут быть заполучены из памяти данных или в ходе передачи данных в процессе сетевой аутентификации. Сложность этого может быть повышена посредством криптографических защит, например шифрования или хеширования, или протоколов квитирования, которые не требуют передачи пароля вообще. И все же пароли могут быть объектом атак, например, подбором методом полного перебора (методом "грубой силы") или взломом криптографической защиты паролей в момент их передачи или хранения. Окно возможности можно сузить посредством периодической смены/обновления паролей. Аналогичные соображения применимы к системам аутентификации на основе криптографических ключей. Можно добиться улучшенной защиты посредством аппаратных механизмов, например аппаратных модулей безопасности, таких как доверенные платформенные модули (ТРМ).
     
     Управление аутентификаторами следует подробно документировать в действующих политиках и регламентах безопасности, например с указанием ограничений на изменение аутентификаторов, установленных по умолчанию, периодичности обновлений, детализацией защиты аутентификаторов или процедур пожарных вызовов (см. 3.1.24).
     
     Блокирование или утрата управления вследствие мер безопасности недопустимы. Если система управления должна иметь высокий уровень работоспособности и доступности, то следует принять меры по поддержанию этого высокого уровня работоспособности и доступности (например, компенсационные физические контрмеры, дублирование ключей и обеспечение приоритетности диспетчерского управления).
     
     Надежность механизма аутентификации зависит не только от характеристик управления аутентификаторами, определенных в настоящем требовании, но и от надежности выбранного аутентификатора (например, сложности пароля или длины ключа при аутентификации по открытому ключу) и политик валидации аутентификатора в процессе аутентификации (например, длительности действия пароля или проверок, выполняемых при валидации сертификата открытого ключа). Для наиболее простых механизмов аутентификации аутентификация по паролю и открытому ключу (5.9, SR 1.7 - Надежность аутентификации по паролю, 5.10, SR 1.8 - Сертификаты инфраструктуры открытых ключей (PKI), и 5.11, SR 1.9 - Надежность аутентификации по открытому ключу) предусматривает дополнительные требования.
     

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

5.7.3.1 SR 1.5 RE1 - Аппаратная безопасность для регистрационных данных идентичности программных процессов
     
     Для пользователей программных процессов и устройств система управления должна обеспечивать возможность защиты значимых аутентификаторов посредством аппаратных механизмов.
     

5.7.3.2 Пусто
     

5.7.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 1.5 - Управление аутентификаторами:
     
     - SL-C (IAC, система управления) 1: SR 1.5;
     
     - SL-C (IAC, система управления) 2: SR 1.5;
     
     - SL-C (IAC, система управления) 3: SR 1.5 (1);
     
     - SL-C (IAC, система управления) 4: SR 1.5 (1).
     
     

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

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

5.8.2 Целесообразность и дополнительная методологическая основа
     
     Любую беспроводную технологию можно и в большинстве случаев следует рассматривать как очередную опцию протокола передачи данных, а значит, подчиняющуюся тем же требованиям безопасности IACS, что и любой другой тип коммуникации, используемой IACS. Однако с точки зрения безопасности имеется по меньшей мере одно существенное различие между проводными и беспроводными коммуникациями: контрмеры физической безопасности обычно менее эффективны при использовании беспроводной связи. По этой и, возможно, другим причинам (например, различиям в регламентном регулировании) анализ рисков может естественным образом обусловить более высокий SL-T (IAC, система управления) для беспроводных коммуникаций в противоположность SL-T для проводных протоколов, используемых в идентичных случаях.
     
     Беспроводные технологии включают в себя, но не ограничиваются этим, микроволновую, спутниковую связь, пакетную радиосвязь, технологии Института инженеров по электротехнике и электронике (IEEE) - IEEE 802.11х, IEEE 802.15.4 (ZigBee, МЭК 62591 - WirelessHART®, ISA-100.11a), IEEE 802.15.1 (Bluetooth), мобильные маршрутизаторы беспроводных ЛВС, мобильные телефоны с тетерингом и различные технологии связи в инфракрасном диапазоне.
     

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

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

5.8.3.2 Пусто
     

5.8.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 1.6 - Управление беспроводным доступом:
     
     - SL-C (IAC, система управления) 1: SR 1.6;
     
     - SL-C (IAC, система управления) 2: SR 1.6 (1);
     
     - SL-C (IAC, система управления) 3: SR 1.6 (1);
     
     - SL-C (IAC, система управления) 4: SR 1.6 (1).
     
     

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

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

5.9.2 Целесообразность и дополнительная методологическая основа
     
     Аутентификация пользователей по имени пользователя и секретному паролю - весьма распространенный механизм. Многие атаки на такие механизмы нацелены на разгадывание пароля (например, атаки перебором по словарю или целенаправленная социальная инженерия) или взлом криптографической защиты отображения хранимого пароля (например, посредством радужных таблиц или грубого подбора хеш-коллизии).
     
     Увеличение размера набора действительных паролей за счет увеличения количества допустимых символов затрудняет такие атаки, но лишь в том случае, если увеличенный размер набора действительно используется (обычно пользователи не склонны включать в состав пароля специальные символы, поскольку они сложны для восприятия и труднее запоминаются). Ограничение срока действия пароля сужает окно возможности для злоумышленника в плане выявления секрета, лежащего в основе отдельно взятого пароля. Для того чтобы пользователи не могли обойти эту директиву, сменив однажды свой пароль на новый и затем сразу же заменив его прежним, обычно, помимо всего прочего, устанавливается минимальный срок действия пароля. Уведомление о необходимости смены пароля до истечения срока его действия позволяет пользователю сменить пароль в удобное время с учетом рабочей обстановки.
     
     Эта защита может быть дополнительно усилена посредством ограничения повторного использования паролей (запрещения малых наборов чередующихся паролей), что дополнительно снижает практическую пользу однократно взломанного пароля. Многофакторная аутентификация позволяет добиться дополнительной защиты, выходящей за рамки механизмов на основе паролей (см. 5.3, SR 1.1 - Идентификация и аутентификация пользователей - физических лиц, и 5.4, SR 1.2 - Идентификация и аутентификация программных процессов и устройств).
     

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

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

5.9.3.2 SR 1.7 RE2 - Ограничения сроков действия паролей для всех пользователей
     
     Система управления должна обеспечивать возможность установления ограничений минимального и максимального сроков действия паролей для всех пользователей.
     

5.9.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 1.7 - Надежность аутентификации по паролю:
     
     - SL-C (IAC, система управления) 1: SR 1.7;
     
     - SL-C (IAC, система управления) 2: SR 1.7;
     
     - SL-C (IAC, система управления) 3: SR 1.7 (1);
     
     - SL-C (IAC, система управления) 4: SR 1.7 (1) (2).
     
     

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

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

5.10.2 Целесообразность и дополнительная методологическая основа
     
     Регистрация для получения сертификата открытого ключа должна включать в себя авторизацию диспетчера или ответственного должностного лица и осуществляться посредством надежной технологии, в рамках которой верифицируется идентичность держателя сертификата и обеспечивается выдача сертификата надлежащей стороне. Любые задержки, спровоцированные использованием сертификатов открытых ключей, по возможности не должны ухудшать эксплуатационные характеристики системы управления.
     
     Выбор подходящей PKI должен по возможности учитывать сертификационную политику организаций, которая должна по возможности базироваться на риске, соотносящемся с уязвимостью в конфиденциальности защищаемой информации. Методологическую основу к определению политики можно найти в общепризнанных стандартах и директивах, например в Запросе на комментарии (RFC) 3647 [29] Инженерного совета Интернета (IETF) для PKI на основе Х.509. Например, соответствующее местонахождение центра сертификации (СА), будь то в пределах системы управления или в Интернете, и перечень доверенных СА должны по возможности быть учтены в политике и зависят от архитектуры сети (см. также МЭК 62443-2-1).
     

5.10.3 Расширения требований
     
     Отсутствуют.
     

5.10.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 1.8 - Сертификаты инфраструктуры открытых ключей (PKI):
     
     - SL-C (IAC, система управления) 1: не определены;
     
     - SL-C (IAC, система управления) 2: SR 1.8;
     
     - SL-C (IAC, система управления) 3: SR 1.8;
     
     - SL-C (IAC, система управления) 4: SR 1.8.
     
     

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

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

a) валидации сертификатов посредством проверки действительности подписи того или иного сертификата;
     

b) валидации сертификатов посредством создания пути сертификации к общепризнанному СА или, в случае самозаверенных сертификатов, посредством проверки "листовых" сертификатов ко всем хостам, поддерживающим коммуникацию с субъектом, для которого выдан сертификат;
     

c) валидации сертификатов посредством проверки того или иного сертификата на предмет аннулированности;
     

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

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

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

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

5.11.3.1 SR 1.9 RE1 - Безопасность аппаратного обеспечения при аутентификации по открытому ключу
     
     Система управления должна обеспечивать возможность защиты соответствующих частных ключей посредством аппаратных механизмов в соответствии с общепризнанными практиками и рекомендациями индустрии безопасности.
     

5.11.3.2 Пусто
     

5.11.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 1.9 - Надежность аутентификации по открытому ключу:
     
     - SL-C (IAC, система управления) 1: не определены;
     
     - SL-C (IAC, система управления) 2: SR 1.9;
     
     - SL-C (IAC, система управления) 3: SR 1.9 (1);
     
     - SL-C (IAC, система управления) 4: SR 1.9 (1).
     
     

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

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

5.12.2 Целесообразность и дополнительная методологическая основа
     
     Сокрытие обратной связи препятствует возможному использованию информации неавторизованными лицами; например, отображение звездочек или других случайных символов, когда пользователь - физическое лицо печатает пароль, скрывает обратную связь в передаче аутентификационной информации. Другие примеры включают в себя ввод ключей по алгоритму WEP, ввод токена по протоколу безопасной оболочки (SSH) и одноразовые пароли по RSA. Аутентифицирующий субъект по возможности не должен давать какие-либо подсказки, например, в случае неудачной аутентификации, такие как "неизвестное имя пользователя".
     

5.12.3 Расширения требований
     
     Отсутствуют.
     

5.12.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 1.10 - Обратная связь при аутентификации:
     
     - SL-C (IAC, система управления) 1: SR 1.10;
     
     - SL-C (IAC, система управления) 2: SR 1.10;
     
     - SL-C (IAC, система управления) 3: SR 1.10;
     
     - SL-C (IAC, система управления) 4: SR 1.10.
     
     

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

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

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

5.13.3 Расширения требований
     
     Отсутствуют.
     

5.13.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 1.11 - Неудачные попытки получения доступа:
     
     - SL-C (IAC, система управления) 1: SR 1.11;
     
     - SL-C (IAC, система управления) 2: SR 1.11;
     
     - SL-C (IAC, система управления) 3: SR 1.11;
     
     - SL-C (IAC, система управления) 4: SR 1.11.
     
     

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

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

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

a) то, что пользователь получает доступ к специализированной системе управления;
     

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

c) то, что несанкционированное использование системы запрещено и влечет уголовные и/или административные санкции; и
     

d) то, что использование системы означает согласие на мониторинг и фиксацию.
     

5.14.3 Расширения требований
     
     Отсутствуют.
     

5.14.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 1.12 - Уведомление об использовании системы:
     
     - SL-C (IAC, система управления) 1: SR 1.12;
     
     - SL-C (IAC, система управления) 2: SR 1.12;
     
     - SL-C (IAC, система управления) 3: SR 1.12;
     
     - SL-C (IAC, система управления) 4: SR 1.12.
     
     

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

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

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

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

5.15.3.1 SR 1.13 RE1 - Принятие явного запроса на доступ
     
     Система управления должна обеспечивать возможность отклонения запросов на доступ через недоверенные сети, если только это не допустимо в рамках установленной роли.
     

5.15.3.2 Пусто
     

5.15.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 1.13 - Доступ через недоверенные сети:
     
     - SL-C (IAC, система управления) 1: SR 1.13;
     
     - SL-C (IAC, система управления) 2: SR 1.13 (1);
     
     - SL-C (IAC, система управления) 3: SR 1.13 (1);
     
     - SL-C (IAC, система управления) 4: SR 1.13 (1).
     
     

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

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


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

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


     Как только пользователь идентифицирован и аутентифицирован, система управления должна разграничить допустимые действия по авторизованному использованию системы управления. Собственники имущественных объектов и системные интеграторы должны будут установить для каждого пользователя (физического лица, программного процесса или устройства), группы, роли и т.д. (см. 5.6, SR 1.4 - Управление идентификаторами) привилегии, определяющие авторизованное использование IACS. Цель контроля использования - предотвращение неавторизованных действий с ресурсами систем управления посредством проверки факта наделения пользователя необходимыми привилегиями до санкционирования выполнения пользователем действий. Примерами действий являются считывание или запись данных, загрузка программ и задание конфигураций. Рекомендации и директивы должны по возможности включать в себя механизмы, которые будут функционировать в смешанных режимах. Например, одни ресурсы системы управления требуют надежной защиты контролем их использования, например ограничительных привилегий, а другие - нет. Что касается расширений, требования к контролю использования должны затрагивать и данные в местах их хранения. Привилегии пользователей могут варьироваться с учетом времени суток/даты, места и средств осуществления доступа.
     
     

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

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

6.3.2 Целесообразность и дополнительная методологическая основа
     
     Политики контроля использования (например, политики на основе идентичности, политики на основе ролей и политики на основе правил) и привязанные к ним механизмы контроля осуществления доступа к считыванию/записи данных (например, списки контроля осуществления доступа, матрицы контроля осуществления доступа и криптография) применяются для контроля обращения между пользователями (физическими лицами, программными процессами и устройствами) и объектами (например, устройствами, файлами, записями, программными процессами, программами и доменами).
     
     После того как система управления верифицировала идентичность пользователя (физического лица, программного процесса или устройства) (см. 5.3, SR 1.1 - Идентификация и аутентификация пользователей - физических лиц, и 5.4, SR 1.2 - Идентификация и аутентификация программных процессов и устройств), она должна также верифицировать правомерность запрашиваемой операции в рамках установленных политик и регламентов безопасности. Например, в случае политики управления доступом на основе ролей система управления проверит, какие роли закреплены за верифицированным пользователем или объектом и какие привилегии приписаны этим ролям: если полномочия распространяются на запрашиваемую операцию, то она выполняется, в противном случае запрос отклоняется. Это позволяет контролировать соблюдение ранжирования обязанностей и минимальных привилегий. По возможности не должно допускаться, чтобы механизмы контроля выполнения обращений отрицательно воздействовали на эксплуатационные характеристики системы управления.
     
     Плановые или внеплановые изменения в компонентах системы управления могут существенно отражаться на общей безопасности системы управления. Поэтому желательно, чтобы только квалифицированные и авторизованные лица получали доступ к использованию компонентов системы управления с целью инициирования изменений, включая модернизацию и модификацию.
     

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

6.3.3.1 SR 2.1 RE1 - Контроль выполнения авторизаций для всех пользователей
     
     На всех интерфейсах система управления должна обеспечивать возможность выполнения обязательных авторизации применительно ко всем пользователям (физическим лицам, программным процессам и устройствам) в целях контроля использования системы управления с поддержанием ранжирования обязанностей и минимальной привилегии.
     

6.3.3.2 SR 2.1 RE2 - Соотнесение полномочий с ролями
     
     Система управления должна обеспечивать возможность для того или иного авторизованного пользователя или роли определять и корректировать соответствия полномочий ролям применительно ко всем пользователям - физическим лицам.
     
     Примечание 1 - В соответствии с общепризнанной практикой роли не сводятся к фиксированным разветвленным иерархиям, при которых роль более высокого уровня включает в себя как подмножества менее привилегированные роли. Например, на системного администратора вполне могут не распространяться привилегии оператора.
     
     Примечание 2 - Это RE применимо в равной мере к программным процессам и устройствам.
     
     

6.3.3.3 SR 2.1 RE3 - Приоритетность диспетчерского управления
     
     Система управления должна поддерживать обеспечение приоритетности ручного диспетчерского управления текущими авторизациями пользователей - физических лиц для конфигурируемого момента времени или последовательности событий.
     
     Примечание - Зачастую необходима реализация управляемой и аудируемой приоритетности ручного управления автоматизированными механизмами в случае события из разряда аварийных или других серьезных событий. Благодаря этому диспетчер может позволить оператору быстро среагировать на нештатные обстоятельства без закрытия текущего сеанса и открытия нового от имени пользователя - физического лица с более высокой привилегией.
     
     

6.3.3.4 SR 2.1 RE 4 - Двойное подтверждение
     
     Система управления должна поддерживать двойное подтверждение на случай, если то или иное действие может серьезно отразиться на производственном процессе.
     
     Примечание - Общепринятой практикой является ограничение двойного подтверждения в пользу действий, требующих очень высокого уровня достоверности, что они будут выполнены надежно и корректно. Требование двойного подтверждения подчеркивает серьезность последствий в случае неуспешного, но корректного действия. Примером ситуации, при которой требуется двойное подтверждение, является смена уставки для критически важного промышленного процесса. Общепризнанной практикой является отказ от применения механизмов двойного подтверждения в случае, если требуется мгновенная реакция для предупреждения последствий, относящихся к HSE, например аварийной остановки промышленного процесса.
     
     

6.3.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 2.1 - Контроль выполнения авторизаций:
     
     - SL-C (UC, система управления) 1: SR 2.1;
     
     - SL-C (UC, система управления) 2: SR 2.1 (1) (2);
     
     - SL-C (UC, система управления) 3: SR 2.1 (1) (2) (3);
     
     - SL-C (UC, система управления) 4: SR 2.1 (1) (2) (3) (4).
     
     

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

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

6.4.2 Целесообразность и дополнительная методологическая основа
     
     Любая беспроводная технология может и в большинстве случаев должна по возможности рассматриваться как еще одна опция протокола передачи данных, а значит, она подчиняется тем же требованиям безопасности IACS, что и любой другой тип коммуникации, используемый IACS. Однако, по результатам анализа рисков, может потребоваться, чтобы беспроводные компоненты IACS поддерживали более широкие возможности контроля использования, чем те, которые обычно требуются от проводных систем для того же случая применения и SL-T. Различия в регламенте также могут обуславливать различия в требуемых возможностях между проводными и беспроводными коммуникациями.
     
     Как отмечено в 5.8, SR 1.6 - Управление беспроводным доступом, беспроводные технологии включают в себя, но не ограничиваются этим, микроволновую, спутниковую связь, пакетную радиосвязь, технологии IEEE 802.11х, IEEE 802.15.4 (ZigBee, МЭК 62591 - WirelessHARTГОСТ Р МЭК 62443-3-3-2016 Сети промышленной коммуникации. Безопасность сетей и систем. Часть 3-3. Требования к системной безопасности и уровни безопасности, ISA-100.11a), IEEE 802.15.1 (Bluetooth), мобильные маршрутизаторы беспроводных ЛВС, мобильные телефоны с тетерингом и различные технологии связи в инфракрасном диапазоне.
     

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

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

6.4.3.2 Пусто
     

6.4.4 Уровни безопасности
     
     Далее приведены требования для четырех уровней SL, относящихся к SR 2.2 - Контроль беспроводного использования:
     
     - SL-C (UC, система управления) 1: SR 2.2;
     
     - SL-C (UC, система управления) 2: SR 2.2;
     
     - SL-C (UC, система управления) 3: SR 2.2 (1);
     
     - SL-C (UC, система управления) 4: SR 2.1 (1).
     
     

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

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

a) запрет на использование портативных и мобильных устройств;
     

b) требование авторизации, обусловленной контекстом; и
     

c) ограничение на передачу кодов и данных от/на портативные и мобильные устройства.
     

6.5.2 Целесообразность и дополнительная методологическая основа
     
     Портативные и мобильные устройства могут вносить нежелательный сетевой трафик, вредоносное программное обеспечение и/или провоцировать раскрытие информации, поэтому следует предусмотреть специальный контроль, связанный с их применением в типичной среде систем управления. Политики и регламенты безопасности могут не допускать те или иные функции или операции, выполняемые посредством портативных и/или подвижных устройств. В МЭК 62443-2-1 приведена методологическая основа на предмет того, когда и где следует допускать обращения с участием портативных и подвижных устройств.
     
     Защита информации, базирующейся на портативных и мобильных устройствах (например, применение криптографических механизмов защиты конфиденциальности и целостности информации в момент ее хранения и передачи за пределами контролируемых участков) освещена в других фрагментах (см. раздел 8, FR 4 - Конфиденциальность данных).
     

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

6.5.3.1 SR 2.3 RE 1 - Ужесточение статуса безопасности портативных и подвижных устройств
     
     Система управления должна обеспечивать возможность проверки того, что портативные или мобильные устройства, пытающиеся соединиться с зоной, соответствуют требованиям безопасности этой зоны.
     

6.5.3.2 Пусто
     

6.5.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 2.3 - Контроль использования портативных и мобильных устройств:
     
     - SL-C (UC, система управления) 1: SR 2.3;
     
     - SL-C (UC, система управления) 2: SR 2.3;
     
     - SL-C (UC, система управления) 3: SR 2.3 (1);
     

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

6.6 SR 2.4 - Мобильный код

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

a) запрещение выполнения мобильного кода;
     

b) запрос соответствующей аутентификации и авторизации для источника кода;
     

c) ограничение передачи мобильного кода к системе управления и от нее; и
     

d) отслеживание использования мобильного кода.
     

6.6.2 Целесообразность и дополнительная методологическая основа
     
     Технологии на основе мобильных кодов включают в себя, но не ограничиваются этим, Java, JavaScript, ActiveX, формат переносимых документов (PDF), Postscript видеофрагменты Shockwave, Flash-анимации и VBScript. Ограничения на обращения относятся как к выбору и использованию мобильного кода, инсталлируемого на серверах, так и к выбору и использованию мобильного кода, загружаемого и выполняемого на отдельных рабочих станциях. Регламенты управления по возможности должны запрещать разработку, принятие или внесение недопустимого мобильного кода в пределах системы управления. Например, могут быть запрещены передачи мобильных кодов непосредственно к системе управления, но разрешены в контролируемой смежной среде, обслуживаемой персоналом IACS.
     

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

6.6.3.1 SR 2.4 RE 1 - Проверка целостности мобильного кода
     
     Система управления должна обеспечивать возможность верификации целостности мобильного кода до разрешения выполнения кода.
     

6.6.3.2 Пусто
     

6.6.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 2.4 - Мобильный код:
     
     - SL-C (UC, система управления) 1: SR 2.4;
     
     - SL-C (UC, система управления) 2: SR 2.4;
     
     - SL-C (UC, система управления) 3: SR 2.4 (1);
     
     - SL-C (UC, система управления) 4: SR 2.4 (1).
     
     

6.7 SR 2.5 - Блокировка сеанса

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

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

6.7.3 Расширения требований
     
     Отсутствуют.
     

6.7.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 2.5 - Блокировка сеансов:
     
     - SL-C (UC, система управления) 1: SR 2.5;
     
     - SL-C (UC, система управления) 2: SR 2.5;
     
     - SL-C (UC, система управления) 3: SR 2.5;
     
     - SL-C (UC, система управления) 4: SR 2.5.
     
     

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

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

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

6.8.3 Расширения требований
     
     Отсутствуют.
     

6.8.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 2.6 - Прерывание удаленных сеансов:
     
     - SL-C (UC, система управления) 1: не определено;
     
     - SL-C (UC, система управления) 2: SR 2.6;
     
     - SL-C (UC, система управления) 3: SR 2.6;
     
     - SL-C (UC, система управления) 4: SR 2.6.
     
     

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

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

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

6.9.3 Расширения требований
     
     Отсутствуют.
     

6.9.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 2.7 - Контроль параллельных сеансов:
     
     - SL-C (UC, система управления) 1: не определено;
     
     - SL-C (UC, система управления) 2: не определено;
     
     - SL-C (UC, система управления) 3: SR 2.7;
     
     - SL-C (UC, система управления) 4: SR 2.7.
     
     

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

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

6.10.2 Целесообразность и дополнительная методологическая основа
     
     Цель этого требования - фиксация наступления важных событий, которые необходимо подвергать аудиту как существенные и значимые для безопасности системы управления. Аудит активности пользователей может отражаться на функционировании систем управления. Функцию аудита безопасности обычно координируют с функцией мониторинга работоспособности и состояния сети, которая может быть реализована и принадлежать другой зоне безопасности. При составлении перечня событий, подлежащих аудиту, следует учитывать общепризнанные и одобренные формы и руководства по конфигурированию. Политики и регламенты безопасности по возможности должны определять те события, подлежащие аудиту, которые допускают поддержание исследований постфактум инцидентов безопасности. Кроме того, желательно, чтобы записей аудита было достаточно для отслеживания эффективности и корректного функционирования механизмов безопасности, применяемых для обеспечения соответствия требованиям настоящего стандарта.
     
     Следует отметить, что требование фиксации событий применимо в контексте функциональности конкретной системы, точнее, в контексте требований безопасности конкретной системы для отдельно взятого уровня. Например, требование фиксации событий аутентификации (в категории управления доступом) в системе с SL 1 применимо только к уровню функциональности аутентификации, требуемому для SL 1 в соответствии с требованиями раздела 5. События могут наступать в любом компоненте системы управления (например, события входа в систему) или отслеживаться посредством специализированных мониторов. Например, сканирование портов может быть зафиксировано системой обнаружения несанкционированных проникновений (IDS) или системой предотвращения несанкционированных проникновений (IPS).
     

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

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

6.10.3.2 Пусто
     

6.10.4 Уровни безопасности
     
     Далее приведены требования для четырех уровней SL, относящихся к SR 2.8 - События, подлежащие аудиту:
     
     - SL-C (UC, система управления) 1: SR 2.8;
     
     - SL-C (UC, система управления) 2: SR 2.8;
     
     - SL-C (UC, система управления) 3: SR 2.8 (1);
     
     - SL-C (UC, система управления) 4: SR 2.8 (1).
     
     

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

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

6.11.2 Целесообразность и дополнительная методологическая основа
     
     Система управления по возможности должна обеспечивать емкость носителя данных аудита, достаточную с учетом политики хранения, выполняемого аудита и требований онлайн-обработки данных аудита. Директивы, подлежащие учету, могут включать в себя NIST Special Publication (SP) 800-92 [27]. Емкость носителя данных аудита по возможности должна быть достаточной для сохранения файлов регистрации в течение периода времени, обусловленного действующими политиками и нормами или бизнес-требованиями.
     

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

6.11.3.1 Т 2.9 RE 1 - Предупреждение при достижении порога емкости носителя записей аудита
     
     Система управления должна обеспечивать возможность подачи предупредительного сигнала, когда выделенный объем носителя данных для записей аудита достиг заданного (конфигурируемого) процента от максимальной емкости носителя записей аудита.
     

6.11.3.2 Пусто
     

6.11.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 2.9 - Емкость носителя данных аудита:
     
     - SL-C (UC, система управления) 1: SR 2.9;
     
     - SL-C (UC, система управления) 2: SR 2.9;
     
     - SL-C (UC, система управления) 3: SR 2.9 (1);
     
     - SL-C (UC, система управления) 4: SR 2.9 (1).
     
     

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

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

6.12.2 Целесообразность и дополнительная методологическая основа
     
     Инициация аудита обычно происходит на источнике события. Обработка данных аудита включает в себя пересылку записей аудита, возможное снабжение записей дополнительной информацией (например, добавление временной метки) и передачу записей на постоянное хранение. Сбои обработки данных аудита включают в себя, например, программные или аппаратные ошибки, сбои в механизмах сбора данных аудита и заполнение или превышение емкости носителя данных аудита. Руководящие материалы, которые следует учитывать при разработке соответствующих ответных действий, могут включать в себя требования NIST SP800-92. Следует отметить, что перезапись самых первых записей аудита или приостановка генерации файлов регистрации аудита являются возможными ответными действиями в случае превышения емкости носителя данных аудита, однако эти действия влекут потерю потенциально существенной информации для экспертного анализа.
     

6.12.3 Расширения требований
     
     Отсутствуют.
     

6.12.4 Уровни безопасности
     
     Далее приведены требования для четырех уровней SL, относящихся к SR 2.10 - Ответные действия в случае сбоев обработки данных аудита:
     
     - SL-C (UC, система управления) 1: SR 2.10;
     
     - SL-C (UC, система управления) 2: SR 2.10;
     
     - SL-C (UC, система управления) 3: SR 2.10;
     
     - SL-C (UC, система управления) 4: SR 2.10.
     
     

6.13 SR 2.11 - Временные метки

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

6.13.2 Целесообразность и дополнительная методологическая основа
     
     Временные метки (включающие в себя дату и время) записей аудита должны по возможности генерироваться с использованием внутрисистемных тактовых генераторов. При отсутствии системной синхронизации времени (что типично для многих установок), потребуются известные события в качестве точки отсчета при анализе последовательности событий. Кроме того, синхронизация сгенерированных системой записей аудита с внешними событиями, скорее всего, потребует синхронизации с общеизвестным внешним источником синхросигналов (таким, как GPS, ГЛОНАСС и Галилео). Источник синхросигналов по возможности должен быть защищен от неавторизованного изменения.
     

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

6.13.3.1 SR 2.11 RE 1 - Внутрисистемная синхронизация времени
     
     Система управления должна обеспечивать возможность синхронизации внутрисистемного тактового генератора на конфигурируемой частоте.
     

6.13.3.2 SR 2.11 RE 2 - Защита целостности источника синхроимпульсов
     
     Источник синхроимпульсов должен быть защищен от неавторизованного изменения и инициировать событие аудита при его изменении.
     

6.13.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 2.11 - Временные метки:
     
     - SL-C (UC, система управления) 1: не определено;
     
     - SL-C (UC, система управления) 2: SR 2.11;
     
     - SL-C (UC, система управления) 3: SR 2.11 (1);
     
     - SL-C (UC, система управления) 4: SR 2.11 (1) (2).
     
     

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

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

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

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

6.14.3.1 SR 2.12 RE 1 - Защита от непризнания участия для всех пользователей
     
     Система управления должна обеспечивать возможность выявления факта совершения тем или иным пользователем (физическим лицом, программным процессом или устройством) конкретного действия.
     

6.14.3.2 Пусто
     

6.14.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 2.12 - Защита от непризнания участия:
     
     - SL-C (UC, система управления) 1: не определено;
     
     - SL-C (UC, система управления) 2: не определено;
     
     - SL-C (UC, система управления) 3: SR 2.12;
     
     - SL-C (UC, система управления) 4: SR 2.12 (1).
     
     

7 FR 3 - Целостность системы

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


     Обеспечивать целостность IACS для предотвращения неавторизованных манипуляций:
     
     - SL 1 - защищать целостность IACS посредством предотвращения случайных или непреднамеренных манипуляций;
     
     - SL 2 - защищать целостность IACS посредством предотвращения манипуляций со стороны кого-либо, кто использует простые средства, имеет незначительные ресурсы, посредственные навыки и низкую мотивацию;
     
     - SL 3 - защищать целостность IACS посредством предотвращения манипуляций со стороны кого-либо, кто использует изощренные средства, имеет умеренные ресурсы, специальные познания в IACS и умеренную мотивацию;
     
     - SL 4 - защищать целостность IACS посредством предотвращения манипуляций со стороны кого-либо, кто использует изощренные средства и имеет обширные ресурсы, специальные познания в IACS и высокую мотивацию.
     
     

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


     IACS зачастую проходят множество циклов испытаний (тестирование на уровне модулей, FAT, SAT, сертификацию, пуско-наладку и т.д.) для удостоверения того, что системы будут функционировать надлежащим образом еще до их запуска. Как только объекты введены в эксплуатацию, их собственники отвечают за поддержание целостности IACS. Используя собственную методологию оценки рисков, собственники объектов могут устанавливать различные уровни защиты целостности для различных систем, коммуникационных каналов и информации в их IACS. Целостность физических объектов следует поддерживать как в условиях их эксплуатации, так и в случае их пребывания в нерабочем состоянии, например, во время производства, в ходе хранения или в продолжение остановки на техобслуживание. Целостность логических объектов следует поддерживать в ходе их передачи или хранения, например в ходе пересылки объектов по сети или их хранения в хранилище данных.
     
     

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

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

7.3.2 Целесообразность и дополнительная методологическая основа
     
     Многие типичные сетевые атаки основаны на манипуляциях с данными в момент их передачи, например на манипуляциях с сетевыми пакетами. Коммутируемые или маршрутизируемые сети открывают дополнительные возможности для злоумышленников в плане манипуляций с пакетами, поскольку осуществить незаметный доступ к этим сетям обычно проще, а сами механизмы коммутации и маршрутизации также могут подвергаться манипуляциям для получения дополнительного доступа к передаваемой информации. Манипуляции в контексте системы управления могут включать в себя изменение измеренных значений, передаваемых от датчика к приемнику, или изменение параметров команд, пересылаемых от управляющего приложения к исполнительному механизму.
     
     Допустимые и целесообразные механизмы будут варьироваться в зависимости от контекста (например, передачи в пределах сегмента локальной сети или передачи через недоверенные сети) и типа сети, используемого при передаче (например, TCP/IP или локальных последовательных линий связи). В малой сети с непосредственными связями (точка - точка) защиты физического доступа ко всем узлам может быть достаточно при низких SL, если целостность конечной точки защищена в той же степени (см. 7.6, SR 3.4 - Целостность программного обеспечения и информации), в то время как в сети, рассредоточенной на участках с регулярным физическим присутствием персонала, или в глобальной вычислительной сети физический доступ, скорее всего, неосуществим. Если для обеспечения коммуникационных сервисов используется коммерческая служба как отдельный продукт, нежели полностью выделенная служба (например, выделенная линия вместо Т1-тракта), то может быть труднее получить необходимые гарантии относительно реализации необходимых элементов управления безопасностью для целостности коммуникации (например, из-за нормативно-правовых ограничений). Если невозможно или нецелесообразно обеспечить соответствие необходимым требованиям безопасности, то может быть целесообразно реализовать соответствующие компенсационные контрмеры или явно принять дополнительный риск.
     
     Промышленное оборудование часто бывает подвержено воздействиям окружающей среды, что может приводить к нарушениям целостности и/или инцидентам сложноположительными срабатываниями. Как это часто бывает, окружающая среда - источник взвешенных частиц, влаги, вибрации, газов, радиации и электромагнитных помех, которые могут вызывать условия, отражающиеся на целостности проводки и сигналов коммуникационной связи. Сетевую инфраструктуру следует разрабатывать с целью минимизации этих физических/внешних воздействий на целостность коммуникации. Например, если взвеси, влага и/или газы являют собой проблему, то может быть необходимо использовать изолированное стандартное гнездо 45 (RJ-45) или разъем М12 вместо привычного разъема RJ-45 проводки. Сам провод может требовать использования другой оболочки, которая рассчитана, среди прочего, на взаимодействие с взвешенными частицами, влагой и/или газом. В случаях, когда проблему являет собой вибрация, могут потребоваться разъемы М12 во избежание отсоединения пружинных штырей на разъеме RJ-45. В случаях, когда проблему являют собой радиация и/или электромагнитные помехи, может потребоваться использование экранированной витой пары или волоконных кабелей для предотвращения любых воздействий на сигналы связи. Может потребоваться также проведение анализа спектра беспроводных сигналов на этих участках, если запланировано беспроводное сетевое взаимодействие, для удостоверения целесообразности этого решения.
     

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

7.3.3.1 SR 3.1 RE 1 - Защита целостности средствами криптографии
     
     Система управления должна обеспечивать возможность применения криптографических механизмов для выявления изменений в информации, произошедших в ходе ее передачи.
     
     Примечание - Общепринятой практикой является определение должного использования криптографических механизмов для аутентификации и обеспечения целостности сообщений после тщательного анализа нужд безопасности и потенциальных последствий для функционирования системы и возможности восстановления после системного сбоя.
     
     

7.3.3.2 Пусто
     

7.3.4 Уровни безопасности
     
     Далее приведены требования для уровней SL, относящихся к SR 3.1 - Целостность коммуникации:
     
     - SL-C (SI, система управления) 1: SR 3.1;
     
     - SL-C (SI, система управления) 2: SR 3.1;
     
     - SL-C (SI, система управления) 3: SR 3.1 (1);
     
     - SL-C (SI, система управления) 4: SR 3.1 (1).
     
     

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

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

ГОСТ Р МЭК 62443-3-3-2016 Сети промышленной коммуникации. Безопасность сетей и систем. Часть 3-3. Требования к системной безопасности и уровни безопасности

Название документа: ГОСТ Р МЭК 62443-3-3-2016 Сети промышленной коммуникации. Безопасность сетей и систем. Часть 3-3. Требования к системной безопасности и уровни безопасности

Номер документа: МЭК 62443-3-3-2016

Вид документа: ГОСТ Р

Принявший орган: Росстандарт

Статус: Действующий

Опубликован: Официальное издание. М.: Стандартинформ, 2016 год
Дата принятия: 01 июня 2016

Дата начала действия: 01 апреля 2017
Информация о данном документе содержится в профессиональных справочных системах «Кодекс» и «Техэксперт»
Узнать больше о системах