ГОСТ Р МЭК 62443-3-3—2016
которые могут происходить в случае преодоления других механизмов защиты {таких, как обязательная
авторизация). Система управления по возможности должна использовать формализованные или реко
мендованные механизмы обеспечения целостности (такие, как криптографические хеши). Например,
такие механизмы могут использоваться для мониторинга периферийных устройств на предмет послед
ней информации об их конфигурациях, чтобы обнаружить бреши в защите (включая неавторизованные
изменения).
7.6.3 Расширения требований
7.6.3.1 SR 3.4 RE 1 — Автоматизированное уведомление о злоумышленных нарушениях целост
ности
Система управления должна обеспечивать возможность использования автоматизированных ин
струментов. которые предоставляют уведомления для конфигурируемой совокупности получателей по
сле обнаружения несоответствий в ходе верификации целостности.
7.6.3.2 Пусто
7.6.4 Уровни безопасности
Далее приведены требования для уровней SL. относящихся к SR 3.4 — Целостность программно
го обеспечения и информации:
- SL-C (SI. система управления) 1: SR 3.4;
- SL-C (SI, система управления) 2: SR 3.4;
- SL-C (SI, система управления) 3: SR 3.4 (1);
- SL-C (SI. система управления) 4: SR 3.4 (1).
7.7 SR 3.5 — Валидация входных данных
7.7.1 Требование
Система управления должна выполнять валидацию синтаксической структуры и содержания лю
бых входных данных, которые служат входными данными управления производственными процессами
или входными данными, непосредственно воздействующими на работу системы управления.
7.7.2 Целесообразность и дополнительная методологическая основа
Должны по возможности действовать правила проверки актуальности синтаксической структуры
входных данных системы управления, например уставок, для верификации того факта, что эта инфор
мация не была искажена и согласуется со спецификацией. Входные данные, поступившие к интерпре
таторам. по возможности должны проходить предварительную проверку для предотвращения случай
ной интерпретации содержания как команд. Следует отметить, что это — SR безопасности и потому не
учитывает человеческий фактор, например подачу правомерного целого числа, которое лежит вне
ожидаемого диапазона.
Общепринятые промышленные практики для валидации входных данных распространяются на
значения вне допустимого диапазона для определенного типа поля, недопустимые символы в полях
данных, отсутствующие или неполные данные и переполнение буферов. Другие примеры, когда недо
пустимые входные данные провоцируют проблемы безопасности систем, включают в себя атаки с вне
дрением SQL-кода. межсайтовый скриптинг или искаженные пакеты (обычно генерируемые тестерами
протоколов (protocol fuzzers)). Руководящие материалы, которые следует учитывать, могут включать в
себя требования Open Web Application Security Project (OWASP) (31] Code Review Guide.
7.7.3 Расширения требований
Отсутствуют.
7.7.4 Уровни безопасности
Далее приведены требования для уровней SL. относящихся к SR 3.5 — Валидация входных дан
ных:
- SL-C (SI, система управления) 1: SR 3.5;
- SL-C (SI. система управления) 2: SR 3.5:
- SL-C (SI, система управления) 3: SR 3.5;
- SL-C (SI, система управления) 4: SR 3.5.
7.8 SR 3.6 — Детерминированный поток выходных сигналов
7.8.1 Требование
Система управления должна обеспечивать возможность приведения потоков выходных сигналов
к заданному режиму, если в результате атаки не может поддерживаться штатное функционирование.
32