ГОСТ Р МЭК 62443-2-1—2015
Риски для традиционных информационных имущественных объектов ориентированы на конфиденциаль
ность. целостность и доступность информации. Риски в IACS отличаются, так как системы управления больше
ориентированы на факторы охраны труда, техники безопасности и охраны окружающей среды и эксплуатационную
надежность, помимо традиционной защиты конфиденциальности, целостности идоступности информации. В IACS
приоритеты обычно изменены с акцентом на доступность, целостность и конфиденциальность (именно в таком
порядке). Это означает, что оценка риска информационной безопасности для IACS должна быть согласована с
физической безопасностью иохраной труда, техникой безопасности и охраной окружающей среды, когда это целе
сообразно. Некоторые организации полностью объединяют работу по оценке рисков во всех этих областях. Риски с
использованием аутсорсинга, сторонних подрядчиков идругих партнеров в цепочке создания производственной
стоимости включают в себя конфиденциальную информацию, которая передается, хранится и обрабатывается.
Объединение этих бизнес-партнеров в деятельности организации потенциально предоставляет непреднамерен
ный доступ к системам компании.
Практически во всех этих случаях производственные операции, относящиеся к безопасности, и технологии,
разработанные для классических IT-приложений, не применялись для IACS частично из-за невежества, а частично в
связи с действительно существующими ограничениями, которых не существует в классических 1Т-приложениях.
Целью настоящего стандарта является решение обоих вопросов.
А.2.3.3 Процесс оценки рисков
А.2.3.3.1 Общие положения
Обзор рисков требуется для подготовки экономического обоснования для CSMS. Более детально приори
теты. рассматриваемые этой системой, определяются на основании методики систематическою рассмотрения
рисков на более высоком уровне детализации по сравнению с уровнем оценкидля составления начального эконо
мического обоснования.
А.2.3.3.2 Оценка рисков и уязвимости
В общей литературе термины «оценка уязвимости» и «оценка рисков» иногда используются как синонимы.
Эти два вида анализа можно разграничить всоответствии с определениями «оценка уязвимости» и «оценка риска»
в настоящем стандарте. Напомним, что «уязвимость» определяется как недостаток или слабость в конструкции,
реализации или эксплуатации и управлении системой, которые могут быть использованы для нарушения целост
ности системы или политики безопасности (см. IEC/TS 62443-1-1). Например, наблюдение о том. что пароли в
центре управления редко меняются, является примером уязвимости, которая будет рассматриваться в оценке
уязвимости. С этой уязвимостью может быть связано несколько рисков, например:
- низкая вероятность того, что пароль станет хорошо известен на предприятии с течением времени и работ
ник. не прошедший обучение для работы в системе управления, использует пароль, чтобы решить проблему, что
приведет к производственным потерям на несколько часов из-за ошибки ввода:
- низкая вероятность того, что недовольный бывший сотрудник успешно взломает корпоративный брандма
уэр для получения удаленного доступа к сети системы управления, войдет в систему HMI и намеренно совершит
действия, которые могут привести к производственным потерям на несколько дней.
Так как эти термины используются в настоящем стандарте, результатом оценки рисков является набор ри
сков. а результатом оценки уязвимости — набор уязвимостей, которые еще не были проанализированы с точки
зрения рисков, которые онисоздают. Таким образом, оценка уязвимости является основой для оценки рисков. Сле
дует иметь в виду, что некоторые существующие методики под названием «методы оценки уязвимости»
включают концепции рисков, а другие нет.
При обращении к приведенному выше примеру с паролем диспетчерской становится ясно, что существуют
также риски, связанные с периодическим изменением пароля системы управления, например, низкая вероятность
того, что оператор не сможет запомнить новый пароль в чрезвычайной ситуации и не сможет войти в систему,
чтобы разрешить ситуацию, что приведет к дополнительному серьезному экологическому ущербу. Компромисс
между риском, снижаемым путем применения контрмеры, и риском, возникающим при применении контрмеры,
как в данном случав, рассматривается в элементе «Управление рисками и принятие мер» настоящего стандарта
(см. А.3.4.2).
А.2.3.3.3 Предварительная идетальная оценка рисков
Оценка рисков может осуществляться на нескольких уровнях. Настоящий стандарт устанавливает необ
ходимость проведения оценки рисков на двух уровнях детализации — предварительную и детальную оценку
рисков.
При предварительной оценке рисков рассматривается влияние общих типов уязвимостей информационной
безопасности и вероятность того, что угроза может включать в себя эти уязвимости, но не учитывать конкретные
случаи этих уязвимостей или связанные с ними контрмеры, которые уже были приняты. Таким образом, примеры
рисков, выявляемых при предварительной оценке рисков, включают в себя:
- среднюю вероятность того, что произойдет вредоносное заражение, которое вызовет перегрузку сети
управления и. следовательно, отсутствие информации о статусе производственного процесса в диспетчерской,
что потенциально может привести к аварийному отключению и связанным с ним расходам;
- низкую вероятность того, что подрядчик с криминальными связями и с физическим доступом к сетевым
средствам системы несанкционированно подключится к этим средствам и успешно изменит команды управления
таким образом, чтобы обьект был поврежден.
36