ГОСТ Р МЭК 62443-3-3—2016
нового техобслуживания. Эти функции безопасности должны включать в себя все те функции, которые
необходимы для поддержания требований безопасности, определенных в настоящем стандарте.
7.5.2 Целесообразность и дополнительная методологическая основа
Поставщик продуктов и/или системный интегратор по возможности должны предоставлять мето
дологическую основу на предмет того, как тестировать разработанные элементы управления безопас
ностью. Собственники объектов должны быть осведомлены о возможных последствиях проведения
этих верификационных тестов во время штатных операций. Подробности реализации этих верифика
ций должны быть определены с тщательным учетом требований непрерывности операций (например,
планирования или предварительного уведомления).
Примеры функций верификации безопасности включают в себя:
- верификацию антивирусных мер посредством тестирования файловой системы системы управ
ления с помощью тестового файла EICAR. Антивирусное программное обеспечение по возможности
должно обнаружить этот файл, и по возможности должны быть инициированы соответствующие про
цедуры обработки инцидентов;
- верификацию мер идентификации, аутентификации и мер контроля использования посред
ством осуществления попыток доступа с неавторизованной учетной записью (для некоторой функцио
нальности это может быть автоматизировано),
- верификацию систем IDS как элемента управления безопасностью посредством включения
определенного правила в IDS. которое срабатывает при регистрации нестандартного, но известно го
невредоносного трафика. После этого может быть проведен тест посредством внесения трафика,
который инициирует это правило и соответствующие процедуры IDS по отслеживанию и обработке
инцидентов;
- подтверждение того, что регистрация аудита происходит в соответствии с требованиями поли
тик и регламентов безопасности и не деактивирована внутренним или внешним субъектом.
7.5.3 Расширения требований
7.5.3.1 SR 3.3 RE 1— Автоматизированные механизмы верификации функциональности безопас
ности
Система управления должна обеспечивать возможность применения автоматизированных меха
низмов для поддержания управления верификацией безопасности во время FAT. SAT и планового тех
обслуживания.
7.5.3.2 SR 3.3 RE 2 — Верификация функциональности безопасности во время штатной работы
Система управления должна обеспечивать возможность поддержания верификации предполага
емого действия функций безопасности во время штатных операций.
П р и м е ч а н и е — Общепринятой практикой является точная реализация данного требования во избежа
ние отрицательных последствий. Зачастую данное требование считается неподходящим для систем, связанных с
физической безопасностью.
7.5.4 Уровни безопасности
Далее приведены требования для уровней SL. относящихся к SR 3.3 — Верификация функцио
нальности безопасности:
- SL-C (SI, система управления) 1: SR 3.3;
- SL-C (SI. система управления) 2: SR 3.3;
- SL-C (SI, система управления) 3. SR 3.3 (1):
- SL-C (SI, система управления) 4: SR 3.3 (1) (2).
7.6 SR 3.4 — Целостность программного обеспечения и информации
7.6.1 Тробованио
Система управления должна обеспечивать возможность обнаружения, фиксации, противодей
ствия и сообщения о неавторизованных изменениях программного обеспечения и информации во вре мя
их хранения.
7.6.2 Целесообразность и дополнительная методологическая основа
Неавторизованные изменения — это изменения, на которые субъект, предпринимающий попытку
изменения, не имеет необходимых полномочий. Данное SR дополняет родственные SR из FR 1 и 2. FR
1 и 2 распространяются на установление ролей, привилегий и шаблонов использования в соот
ветствии с проектом. Методы верификации целостности применяются для обнаружения, фиксации,
противодействия и сообщения о нарушениях целостности программного обеспечения и информации,
31