ГОСТ Р М ЭК 62443-2-1— 2015
f)определение формальной методики принятия риска, включая соответствующееодобрение на уровне руко
водства. разработанной на основе сферы применения и документации:
д) внедрение политик, процедур, инструментов ит. п. способом, позволяющим минимизировать администра
тивные накладные расходы и расходы конечного пользователя без ущерба для эффективности. В хорошо спроек
тированных средствах контроля часто остается фактор аудита, которым можно пользоваться в дальнейшем для
выполнения верификации;
h) документирование причин, по которым были выбраны или не выбраны определенные контрмеры безопас
ности. и риски, для которых они предназначены в соответствии с положением о применимости контрмер (SoA).
Хорошо составленная документация о средствах контроля действий по снижению рисков может быть использова на
в процессе принятия решений и информирования о таких решениях, а также является основной для обучения
персонала по вопросам реагирования на инциденты и угрозы и для самостоятельной оценки или аудитов на пред
мет соответствия контрмерам.
А.3.4.2.6.2 Дополнительные практические методы
Примечание 1 — В IEC/TR 62443-3-1 [6] и МЭК 62443-3-3 [8] будут рассматриваться соответствующие
практики, как только работа над этими стандартами будет завершена.
Примечание 2 — Разработчики настоящего стандарта принимают во внимание, что имеется много раз
личных видов доступных контрмер. Они также принимают во внимание, что если сюда включить перечень раз
личных контрмер, то пользователь столкнется со слишком большим объемом информации для понимания, кото
рая будет приведена недостаточно подробно для того, чтобы пользователь мог с точностью применять средства
контроля в отношении LACS. Поэтому разработчики приняли решение о том. что вопрос рассмотрения дополни
тельных практик безопасности 1ACS. связанных с контрмерами, должен изучаться в рамках других документов, в
которых пользователи смогут ознакомиться с более глубоким анализом различных контрмер и способов их пра
вильного применения к среде IACS.
А.3.4.2.7 Использованные ресурсы
Данный элемент частично основан на материалах [23]. [24]. [27]. [28]. [29]. [30]. [31]. [33].
А.3.4.3 Элемент «Разработка и поддержка системы»
А.3.4.3.1 Описание элемента
Элемент «Разработка и поддержка системы» представляет собой вспомогательные методы, необходимые
для разработки и поддержки информационных систем 1ACS. которые влияют на CSMS и сами являются объектом
воздействия CSMS. В нем рассмотрены такие аспекты информационной безопасности, как документы, касающие ся
требований, проектирования, закупки, тестирования, управления изменениями, управления патчами, процессов
резервирования и восстановления.
В основном, этот элемент дает представление, каким образом такие методы необходимо применять с точки
зрения обеспечения информационной безопасности. Этот подход используется не для того, что воспроизвести до
кументацию. в которой описаны основные положения таких методов, а для того, чтобы объяснить, почему вопросы
безопасности являются неотъемлемой частью процессов разработки и поддержки системы. Вопросам безопасно
сти необходимо уделять внимание входе нормальной реализации всех процессов разработки и поддержки систем.
А.3.4.3.2 Документы, касающиеся требований
ВА.3.4.2 приведена концепция целевогоуровня безопасности (целевогоSL). Понятие «требования» относит
ся к возможностям и/или характеристикам данной системы или устройства. Требования могут быть связаны с раз
личными характеристиками в различных контекстах: требования к системам или ПО. продуктам или промышлен
ной эксплуатации, функциональные или нефункциональные требования. Но для целей данного элемента понятие
«Требования к системе» определяется как характеристики целевого SL. а понятие «Требования к устройству» —
как характеристики контрмер, необходимых для устройств в пределах зоны для достижения нужного целевого SL.
Учитывая, что требования ксистеме определяют целевой SL. их можноустанавливать на этапе управления риском
и принятия мер. Эти требования к системе часто называются требованиями высокого уровня. Требования к устрой
ству могут изменяться в зависимости от результатов этапа проектирования.
Например, требование к системе для зоны управления может заключаться в ограничении всего сетевого
трафика до аутентичного трафика управления и автоматизации. Требование к устройству для панели управления
может заключаться вдеактивации всех неиспользуемых протоколов сетевого взаимодействия и передачи данных. В
этом случав такое требование к устройству может лишь частично достигать требование уровня системы. Для
выполнения требований к системе может потребоваться несколько требований к устройству.
Детально проработанный и доступный к проверке комплекс требований к системе и устройству служит ос
новой методов тестирования, верификации и валидации процессов проектирования, закупки, управления изме
нениями и управления патчами. Крайне сложно схазать. будет ли нарушение целевого SL с точки зрения про
ектирования. закупки, изменений в системе или патчей, если не будут определены специфические возможности,
необходимые для достижения такого уровня.
А.3.4.3.3 Проектирование
Информационная безопасность должка встраиваться в LACS на этапе проектирования. Такую цель необхо
димо учитывать при поставке и разработке системы, а также на этапе ее поддержки. Имеются многочисленные
98