ГОСТ Р М ЭК 62443-2-1— 2015
Вид того или иного тестирования будет зависеть от уровня требуемого теста, компонента или системы, про
ходящей тестирование, а также от вида тестирования, требуемого для системы или компонента. Тестирование
информационной безопасности обычно выполняется в три этапа: тестирование компонента, интеграционное те
стирование и тестирование системы. Верификационное тестирование проводится на этапе тестирования компо
нентов и интеграции, но и валидационный тест также может пригодиться. Оба теста проводятся на этапе тестиро
вания системы.
А.3.4.3.5.3 Тестирование компонентов
Тестирование компонентов должно проводиться разработчиками и проверяться владельцем системы. Ком
понентом может быть ПО. аппаратное обеспечение, встроенное ПО или любые их комбинации. Компонент должен
пройти тестирование, позволяющее установить, насколько он отвечает специфическим операционным требова
ниям и требованиям к безопасности. Тестирование компонента обычно проводится в рабочей среде и требуется с
целью получения гарантии того, что когда компоненты будут собраны е систему, каждый отдельный компонент
будет функционировать, как и предполагается.
А.3.4.3.5.4 Интеграционное тестирование
Интеграционное тестирование проводится специалистом-интегратором и проверяется владельцем системы.
Такое тестирование включает в себя операционное тестирование и тестирование с точки зрения безопасности
различных компонентов, возможно от различных разработчиков, собранными воедино в рабочей среде или на
вспомогательном тестовом стенде с целью получения гарантии того, что все компоненты будут функционировать
правильно до того, как будут помещены в среду IACS. Интеграционное тестирование может включать использова
ние дополнительных тестовых инструментов, например, инструменты сетевого управления и администрирования,
которые не требовались на этапе тестирования компонентов.
В редких случаях тестовый стенд будет иметь точную конфигурацию системы управления, действующей
на рабочем объекте. В основном для этапа тестирования компонентов и интеграционного тестирования при раз
работке или лабораторной настройке лучше всего подходит упрощенная система или ее копия. Интеграционные
тесты должны разрабатываться с учетом особенностей такого тестового стенда. Необходимо учитывать различия
между условиями проведения интеграционного теста исредой 1ACS, а также любые дополнительные инструменты,
которые могут потребоваться для того, чтобы продукт, который не прошел полное интеграционное тестирование,
прошел такое тестирование на этапе тестирования системы. По этой причине, особенно на этапе интеграционного
тестирования, полезно размещать упрощенную систему или ее копию рядом с площадкой, на которой установлена
OS.
В некоторых случаях допускается выполнить непроизводственное интеграционное тестирование, позволяю
щее установить, насколько хорошо контрмеры безопасности будут работать в комплексе и как они будут взаимо
действовать с операционными свойствами. Например, контрмеры безопасности, состоящие из дискретных аппа-
ратных/программных средств, могут подключаться через лабораторную сеть тестового стенда. В других случаях
такая интеграция невозможна. План интеграционного тестирования должен разрабатываться с учетом плюсовых
особенностей схемы тестового стенда, конфигурация которого может быть разработана таким образом, что позво
ляет тестировать комбинации рабочих условий, присутствующих в операционной системе.
А.3.4.3.5.5 Тестирование системы
Верификационное и валидационное тестирование системы должен проводить владелец системы. Валида-
ционное тестирование проводится с применением соответствующих техник, процедур и процедурных изменений
(по мере необходимости) с целью демонстрации того, что управление, операционные и технические контрмеры
IACS внедряются правильно, эффективны в своем применении и гарантируют, что новые защитные контрмеры
системы в поставленном виде и после ее установки отвечают необходимым требованиям.
Тестирование системы может включать в себя тест на возможность проникновения в систему, позволяю
щий гарантировать, что компоненты безопасности могут защищать систему от различных угроз в соответствии с
требованиями обеспечения уровня защищенности для каждой зоны. Такое тестирование позволяет определить,
где именно известное лицо пытается обойти защитные механизмы и попасть в систему при поиске слабых мест и
уязвимостей, которыми можно воспользоваться либо для получения доступа, либо для контроля системы. Многие
компании специализируются в тестировании на возможность проникновения в традиционные IT-системы. Может
быть намного сложнее найти группу, которая понимает особые требования IACS.
Для проведения фактического тестирования имеется большое количество разнообразных тестовых инстру
ментов. например, сценарии тестирования, базы данных переменных значений, базовые конфигурации с предпо
лагаемой датой начала тестирования, метрические показатели и калибровочные инструменты. Также в распоря
жении имеются коммерческие и свободно распространяемые инструменты с заранее заданной конфигурацией,
позволяющей выполнять диагностические операции и симулировать шлюзы и подключенные устройства.
При проведении тестов на возможность проникновения в систему, помимо результатов теста необходимо
фиксировать производительность системы во время таких тестов. Скорее всего будет отмечаться некоторое ухуд
шение производительности системы или компонентов из-за проводимого теста. Эти изменения необходимо реги
стрировать для дальнейшего использования.
Следует отметить, что к контрмерам безопасности также могут относиться специалисты, работающие с по
литиками и процедурами, и неавтоматизированные проверки безопасности. Например, контрмера может включать
100