Утвержден и введен в действие
Приказом Федерального
агентства по техническому
регулированию и метрологии
от 1 июня 2016 г. N 469-ст
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
СЕТИ ПРОМЫШЛЕННОЙ КОММУНИКАЦИИ
БЕЗОПАСНОСТЬ СЕТЕЙ И СИСТЕМ
ЧАСТЬ 3-3
ТРЕБОВАНИЯ К СИСТЕМНОЙ БЕЗОПАСНОСТИ И УРОВНИ БЕЗОПАСНОСТИ
Industrial communication networks. Network and system
security. Part 3-3. System security requirements
and security levels
(IEC 62443-3-3:2013, IDT)
ГОСТ Р МЭК 62443-3-3-2016
ОКС 25.040.40;
35.110
Дата введения
1 апреля 2017 года
Предисловие
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).
Международный стандарт разработан Техническим комитетом МЭК ТК 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).
Примечание 2 - Формат настоящего стандарта соответствует требованиям ИСО/МЭК, рассмотренным в Директивах ИСО/МЭК, часть 2 [11] <1>. Эти директивы регламентируют формат стандарта, а также использование терминов типа "должен", "должен по возможности" и "может". Для требований, определенных в обязательных пунктах, использованы соглашения, рассмотренные в приложении H Директив ИСО/МЭК.
--------------------------------
<1> Цифры в квадратных скобках относятся к элементу стандарта "Библиография".
Организации, эксплуатирующие системы промышленной автоматизации и контроля (IACS), все чаще используют коммерчески доступные (COTS) сетевые устройства, которые имеют малую стоимость, эффективны и высокоавтоматизированы. Кроме того, из веских коммерческих соображений, системы управления все чаще взаимодействуют и с сетями, не относящимися к IACS. Эти устройства, общедоступные сетевые технологии и возросшие возможности сетевого взаимодействия расширяют возможности для кибератак на аппаратное и программное обеспечение систем управления. Эта проблема может иметь последствия, затрагивающие охрану труда, технику безопасности и охрану окружающей среды (HSE), и/или наносить финансовые убытки и/или ущерб репутации всюду, где внедряются системы управления.
Организации, внедряющие бизнес-решения в сфере кибербезопасности информационных технологий (IT) для разрешения вопросов, связанных с безопасностью IACS, могут не вполне осознавать последствия такого выбора. Хотя многие коммерческие прикладные IT-объекты и решения безопасности могут быть применимы к IACS, их необходимо применять надлежащим образом для исключения непредвиденных последствий. По этой причине подход, используемый для определения системных требований, должен базироваться на комбинации функциональных требований и оценки риска и зачастую включает в себя и необходимость иметь осведомленность в вопросах эксплуатации.
Меры безопасности IACS не должны иметь возможность приводить к нарушению существенных сервисов и функций, включая процедуры при нештатных ситуациях. (Часто меры безопасности IT имеют данную тенденцию.) Обеспечение безопасности IACS нацелено на работоспособность и доступность систем управления, защищенность производственных объектов, производственных процессов (хотя бы в режиме ограниченной функциональности) и времени отклика системы, где это имеет критическое значение. В рамках целей IT-безопасности этим факторам зачастую придается меньшее значение. значение придается защите информации, чем защите физических объектов. Эти различные цели должны быть четко определены как цели безопасности, независимо от степени достигнутой интеграции производственного объекта. Ключевым этапом в оценке риска согласно требованиям МЭК 62443-2-1 <2> должна по возможности быть идентификация тех сервисов и функций, которые действительно существенны для процессов хозяйствования. (Например, на тех или иных объектах техническая поддержка может быть определена как несущественный сервис или функция.) В некоторых случаях может быть допустимо, чтобы операция безопасности провоцировала временную утрату несущественного сервиса или функции, но по возможности не сказывалась отрицательно на существенном сервисе или функции.
--------------------------------
<2> Многие стандарты из стандартов серии МЭК 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-1-3 [2] используются фундаментальные требования (FR), SR, RE и им присваиваются уровни SL-C в виде стандартизированного перечня для
Для просмотра документа целиком скачайте его >>>
