ГОСТ Р МЭК 62443-2-1—2015
документы, в которых описаны надежные процессы проектирования систем. Однако стоит иметь в виду, что важ
нейшим аспектом процесса проектирования является необходимость привязки специфических контрмер к каждому
из требований к системе, что позволяет гарантировать, что устройства и системы как единое целое соответствуют
целевому SL.
Процесс проектирования охватывает не только подготовку спецификации проекта, но также включает в себя
планирование подхода к осуществлению контроля и первоначальный контроль, позволяющий убедиться в том.
что проект отвечает заявленным требованиям. Первоначальная проверка может выполняться на этапе анализа
документов. Окончательная проверка выполняется входе тестирования системы.
Следует принимать во внимание, что новые проекты открываются и реализуются постоянно. Чтобы не было
оснований для последующей доработки, когда такие новые проекты будут завершены и введены в эксплуатацию,
операционные группы и разработчики, отвечающие за реализацию проектов, должны владеть информацией о при
менимых отраслевых стандартах вобласти информационной безопасности, а также о соответствующих корпора
тивных политиках и процедурах.
А.3.4.3.4 Закупка
Процесс закупки имеет особо важное значение длядостижения желательного целевого SL. При описании но
вого или обновленного оборудования разработчику важно включать требования к информационной безопасности.
Если есть специфические требования к устройству, необходимые для выполнения требований к системе, то о них
нужно открыто заявлять в процессе закупки таких устройств. Также может потребоваться оговорить такие требо
вания к устройству, в соответствии с которыми разработчик или специалист-интегратор не имеет права совершать
определенные действия. Имеется несколько стандартных практик для разработчиков устройств или интеграторов,
которые они могут реализовать в своих устройствах, в результате чего могут появиться нежелательные слабые
места в системе безопасности и система может не достигнуть целевого SL. Например, разработчики в своих про
дуктах предусматривали способы входа (лазейки), облегчающие работу по устранению неисправностей и
позво ляющие сократить время реагирования на клиентские запросы. Такие неофициальные способы входа
являются уязвимостью, которыми могут воспользоваться злоумышленники. Торговый представитель может даже и
не иметь представления о том. что в продукте предусмотрены такие возможности, которые не должны
допускаться, кроме случаев, когда они открыто включаются втребования к закупке.
Темаописания процесса закупки в рамках информационной безопасности слишком обширна для того, чтобы
ее рассматривать в настоящем стандарте. Ею занимаются другие группы, которые могут предоставить более под
робную информацию по этому вопросу (например. (58)).
А.3.4.3.5 Тестирование
А.3.4.3.5.1 Общие положения
Программа тестирования проводится с целью, чтобы гарантировать выполнение системой заявленных тре
бований по проекту. В случае правильно спроектированной системы необходимо предусмотреть выполнение опе
рационных требований и требований к безопасности. Одним из самых первых решений при разработке программы
тестирования является степень обеспечения гарантии, требуемой от разработчиков и интеграторов, относительно
информационной безопасности устройств или систем. Степень обеспечения гарантии, требуемая для конкрет
ного устройства или системы, будет определять вид необходимого тестирования. Разработчик может руковод
ствоваться рекомендованной стратегией тестирования для конкретного устройства или системы, но пользователь
должен определить, достаточна ли такая стратегия тестирования для подтверждения правильности требований к
безопасности.
В идеале, система проходит тестирование во всех возможных состояниях, что позволяет гарантировать, что
выполнено каждое условие безопасности или хотя бы известен остаточный риск. Несмотря на то. что полное тести
рование системы теоретически возможно, для большинства спецификаций это недостижимо ввиду финансовых и
кадровых ограничений. В связи с этим задача заключается в том. чтобы определить допустимый уровень риска и
затем выполнить достаточное тестирование, сопоставимое сдопустимым риском.
После первоначального планирования тестирования для каждого этапа тестирования необходимо подгото
вить письменные планы и процедуры. В них должны быть определены планы и ожидаемые результаты, а также
должна входить конфигурация системы, входные и выходные параметры системы, допустимые диапазоны погреш
ностей. Во время тестирования важно выполнять хотя бы поверхностную проверку результатов, позволяющую
убедиться втом. что они соответствуют ожиданиям или определить, требуется ли предпринять какое-либо коррек
тирующее действие. После завершения каждого этапа тестирования требуется выполнить оценку результатов. По
сле валидационного испытания системы составляется окончательный отчет, в котором анализируются результаты
всех тестов и делаются выводы.
А.3.4.3.5.2 Типы тестирования
Тестирование информационной безопасности, как и тестирование в отношении других аспектов, включает
в себя верификационные и валидационные тесты. В соответствии с моделью зрелости процессов разработки ПО
(39): яВерификация позволяет подтвердить, что рабочие продукты надлежащим образом отражают требо
вания. предъявляемых к ним. Другими словами, она гарантирует, что «вы все сделали правильно». Валидация
подтверждает, что продукт в поставленном виде будет выполнять свое предназначение. Другими словами.
она гарантирует, что «вы создали правильный продукт». В итоге, верификация определяет, насколько реали
зация удовлетворяет требования спецификации, а валидация — насколько спецификация отвечает требованиям.
99