ГОСТ Р МЭК 62443-2-1—2015
А.3.4.2.5.2 Исправления в устройствах IACS с помощью патчей
Нарисунке А. 18приведен укрупненный анализ того, каким образом корректировка при помощи патчей встра
ивается е этап поддержания модели жизненного цикла обеспечения безопасности. Положения настоящего подпун
кта не должны восприниматься как комплексное обсуждение всех аспектов, связанных с патчами. Его целью яв
ляется иллюстрация итеративного аспекта проверки состояния SL (достигнуто) зоны и необходимости принимать
комплексные решения относительно того, какие патчи должны быть использованы и когда их следует применять.
Разработчики устройств и приложений IACS разделяют ответственность с пользователями за решение за
дач. связанных с устранением рисков безопасности. Пользователям необходимы разработчики, чтобы понимать
внутренние механизмы приложений IACS. чтобы определять применимость патча и выполнять сквозное автома
тизированное регрессивное тестирование совместимости приложения IACS с патчами операционной системы и
основными обновлениями. Поскольку при инсталляции патчей возможно вмешательство в нормальную работу
программного приложения IACS. пользователямнужен максимум гарантий того, что инсталляция обновленного ПО
не приведет к неисправности устройства управления.
На рисунке А. 18 показано, что тестирование совместимости разработчика является первым шагом много
этапного плана тестирования до проведения масштабной инсталляции патчей в работающей IACS. Необходимо
проводить дополнительное тестирование с целевой средой устройства. Идеальные результаты будут получены
при тестировании офлайнового устройства, идентичного рабочей IACS. Если это невозможно, необходимо рассмо
треть альтернативные подходы, которые включают в себя тестирование в виртуальной среде или в контролируе
мом развертывании патча для работающей IACS.
Имея данные об уязвимостях, полученные от разработчика операционной системы, данные о совместимо
сти патчей от разработчика IACS. данные о совместимости от разработчика IACS. информацию об использовании
устройства IACS и. наконец, о тестировании пользователей, пользователь принимает решение о полевом развер
тывании патча.
А.3.4.2.5.3 Использованиедополнительных контрмер
Для решения задач, связанных с неустраненными уязвимостями от патчей или уязвимостями, появивши
мися в результате изменений в промышленных операциях, могут потребоваться дополнительные контрмеры. По
требность в таких контрмерах определяется путем оценки SL (достигнутый) и его сравнения с SL (цель) для зоны.
В некоторых случаях бизнес-риск, с которым связана работа по повышению SL (достигнутый), в краткосроч
ной или долгосрочной перспективе может привести к существенным затратам. В этом случав лица, принимающее
техническое решение, должны документально представить:
- риски;
- использованные контрмеры;
- контрмеры, рассматриваемые и отклоненные, и соответствующие причины;
- рекомендации для бизнес-лидеров по принятию риска на определенный период времени до того момента,
когда (ложно будет установить, протестировать и внедрить наиболее приемлемую контрмеру или решение в об
ласти обеспечения безопасности.
Бизнес-лидерыдолжныофициально ивписьменном виде оформитьсогласие на принятиеданной стратегии.
А.3.4.2.5.4 Плановый контроль защищенности
Комплексная CSMS включает в себя компонент соответствия, в который входит периодическая оценка ис
пользования защитных практик и контрмер, определенных в корпоративной политике безопасности и стандартах, и
их эффективности в снижении риска и достижения SL (цель). Это еще один инициирующий фактор для этапа
поддержки модели жизненного цикла обеспечения безопасности.
В ходе аудита безопасности измеряется степень соответствия определенным политикам и стандартам, что
позволяет получить данные, необходимые для поддержания безопасности. Кроме проверки соответствия требуе
мым практикам организация периодически (и с учетом инициирующих факторов, указанных на рисунке А. 18) долж на
проводить анализ того, вкакой степени SL (достигнутый) соответствует или превосходит SL (цель) в зонах IACS.
А.3.4.2.6 Вспомогательные практические методы
А.3.4.2.6.1 Основные практические методы
Косновным практическим методам относятся следующие действия:
a) определение и подтверждение правильности политик безопасности. В детальных положениях политик
безопасности определяется цель операционного уровня по снижению каждого из рисков безопасности во время
оценки риска;
b
) разработка процедур с подробным описанием действий, необходимыхдля предупреждения, обнаружения
и реагирования на угрозы;
c) адаптация стандартов международных организаций в сфере информационной безопасности для исполь
зования в среде IACS организации;
d) разработка сервисов для защиты образов операционной системы и общих приложений для обеспечения
безопасной работы IACS;
e) определение инструментов и продуктов безопасности для внедрения компонентов политики безопасно
сти. Несмотря на то, что инструменты и продукты безопасности, такие как файерволы и VPN-соединения, могут
применяться в средах IT и LACS, регламенты и применение таких типов инструментов и продуктов могут суще
ственно отличаться из-за различных рисков, связанных с такими средами;
97