ГОСТ Р МЭК 62443-2-1—2015
Политикидля CSMS и процедуры, разработанные организацией, должны давать персоналу четкое представ
ление о его роли и обязанностях по сохранению имущественных обьектов организации.
А.3.2.6.2 Разработка политики безопасности
Разработка политики безопасности для организации не должна рассматриваться как линейная задача. По
сле завершения первоначальной стадии разработки политики организации необходимо изучить и проанализиро
вать эффективность этой политики и внести в нее необходимые изменения. Политика недолжна разрабатываться
отдельно от других систем управления рисками в организации.
Разработка и реализация политики безопасности подразумевает участие высшего руководства, задейство
ванного во всех сферах деятельности организации и несущего ответственность за такие типы систем. Выработав
и утвердив политику безопасности, высшее руководство может продемонстрировать стремление к непрерывному
совершенствованию. Обязательство руководства, относящееся к политике безопасности, подразумевает призна
ние руководством политики безопасности ответственностью бизнеса, которая разделяется между всеми участника
ми команды руководителей, а также признание ее политикой, имеющей физические и киберкомпоненты. Процеду
ры безопасности должны быть интегрированы в общие бизнес-стратегии и пользоваться поддержкой руководства.
Многие организации с IACS внедряют политики для таких систем, как техника безопасности, физическая
безопасность IT. а также для поведения работников. В начале процесса разработки CSMS необходимо попытаться
внедрить политики кибербезопасности в систему с существующими политиками и процедурами. Это зачастую тре
бует изменения политики вразличных системах управления рисками. Например, в существующих системах управ
ления рисками риски уже могут быть охарактеризованы и могут быть установлены границы допустимости рисков,
которые должны учитываться при разработке новой CSMS. Пояснения по объединению политик и систем управ
ления рисками приведены в IEC/TS 62443-1-1 (подпункт 5.6). Политики безопасности, относящиеся крискам IACS.
также рассматривают широкий диапазон вопросов от организационных требований к руководству до технически
детальных требований к конфигурации системы. Рекомендуется, чтобы эти политики были выделены в отдельные
подгруппы, чтобы пользователи, интересующиеся конкретными темами, могли легко их найти.
Во многих обстоятельствах политики и процедуры безопасности могут считаться контрмерами, снижающими
риск. Они могут принимать несколько форм от административных процедур до автоматизированных средств безо
пасности. Необходимо стремиться ктому, чтобы общая стоимость реализации контрмер была меньше совокупного
влияния риска. Уменьшение стоимости реализации контрмер при сохранении уровня снижения риска является бо
лее ценным для организации. В случаях, когда существует эффект масштаба, управление технологиями будетосу
ществлять IT-дисциллина в случаях, когда масштаб гложетбыть выгодно использован. Таким образок», подробные
политики безопасности IT-дисциплины должны быть проверены на предмет возможного использования для 1ACS.
При разработке политик кибербвзопасности важно учитывать требования по соответствию стандарту, а так
же процесс аудита. Поскольку IACS необходимо оценить на соответствие политике безопасности, необходимо
убедиться, что выработанные политики не противоречат друг другу, и что более важно — политикам управления
рисками. Например, политика безопасности на конкретном атомном предприятии требует, чтобы все стационар
ные компьютеры были защищены паролем. Эта политика также требует, чтобы все операторские станции были
защищены паролем, но они должны быть открыты в соответствии с нормами техники безопасности. Соблюдение
политики защиты паролемстационарных компьютеров приведет к несоблюдению политик по охране труда, технике
безопасности и охране окружающей среды. Политика кибербезопасности должна была быть изначально создана с
учетом влияния, которое она окажет на все системы предприятия. Более удачным подходом будет создание поли
тики. которая предписывает защищать стационарные компьютеры от несанкционированного использования, а за
тем составить процедуры, которые могут потребовать защиты паролем в некоторых случаях, а вдругих ситуациях
необходимо просто обеспечивать физическую изоляцию.
А.3.2.6.3 Определение границдопустимости рисков для организации
Организация должна выработать политику определения границ допустимости рисков, относящуюся к уров
ням риска, соответствующим определенным комбинациям вероятности и последствий. Эта политика может быть
основана на качественной оценке рисков, включающей перечень имущественных обьектов или сценариев с ран
жированием общей вероятности и последствий, которые были определены и присвоены в рамках процесса оценки
рисков организации (см. А.2.3).
На типичной шкале уровней риска, приведенной в таблице А.З, вероятность и последствия разбиты на три
уровня. Уровень риска также разбит на три уровня. Уровни риска в каждом блоке (высокий, средний и низкий) соот
ветствуют конкретной комбинации вероятности и последствий. Организация вырабатывает политику определения
границ допустимости рисков, относящуюся к определенному уровню корпоративной реакции на риск. Например,
риски в категории «Высокий» могут являться допустимыми в течение 6 месяцев; риски из категории «Низкий» не
стоят усилий, затраченных на них; средний уровень риска заслуживает средних усилий. Другими словами органи
зация установила, что она может допускать высокий уровень риска не более 6 мес.
А.3.2.6.4 Анализ и пересмотр политики кибербезопасности
Политики кибербезопасности должны регулярно анализироваться, утверждаться для подтверждения их ак
туальности и выполнения и пересматриваться, что требуется для того, чтобы они оставались актуальными. Когда
политика кибербвзопасности имеет более высокий уровень, она не должна актуализироваться такчасто, поскольку
она описывает «что», а не «как». Процедуры, описывающие способы действия, могут изменяться при появлении
новых угроз или технологий, нообоснование защиты системы останется неизменным.
64