Владимир Липаев - Очерки истории отечественной программной инженерии в 1940-е – 80-е годы

Целью требований является обеспечение соответствия объединенной системы, заданным требованиям по безопасности программного продукта при заданном уровне безопасности внешней среды и системы. Для каждой функции безопасности, в документации по аттестации должны быть указаны: использованный вариант плана аттестации; функция, проходившая аттестацию (путем анализа, экспертизы или экспериментальных испытаний) вместе со ссылками на план аттестации; инструментальные средства и оборудование, данные об их калибровке; результаты аттестации; расхождение между ожидаемыми и полученными результатами. Если обнаружены расхождения между ожидаемыми и полученными результатами, следует принять решение о том, продолжать ли аттестацию или сделать заявку на изменения и вернуться к более ранней документация, являющейся частью требований и результатов аттестации программного продукта. Программный комплекс должен быть проверен тестированием при имитации:

• входных сигналов, существующих при нормальной эксплуатации;

• ожидаемых происшествий и аномалий функционирования;

• нежелательных ситуаций, требующих вмешательства системы контроля и корректировки безопасности.

К результатам аттестации предъявляются следующие требования: испытания должны показать, что все заданные требования по безопасности программного продукта выполняются правильно, и что продукт не выполняет не предназначенных ему функций. По каждому испытанию и его результатам должна быть составлена документация для проведения последующего анализа и независимой оценки соответствия с требуемым уровнем безопасности. Выбор методов оценки не гарантирует сам по себе, что будет достигнуто соответствие комплексу требований по безопасности. Нарушения безопасности комплексов программ возникают вследствие преднамеренного использования или случайной активизации уязвимостей при применении системы по назначению. Уязвимости могут возникать вследствие недостатков:

• требований – продукт или система могут обладать требуемыми от них функциями и свойствами, но содержать уязвимости, которые делают их непригодными или неэффективными в части безопасности применения;

• проектирования – продукт или система не отвечают спецификации, и/или уязвимости, являются следствием некачественного проектирования или неправильных проектных решений;

• эксплуатации – продукт или система разработаны в полном соответствии с корректными спецификациями, но уязвимости возникают как результат неадекватного управления при эксплуатации.

Оценка, и утверждение целей функциональной безопасности требуется для демонстрации заказчику или пользователю, что установленные цели проекта адекватны проблеме его безопасности. Следует сопоставлять цели безопасности с идентифицированными угрозами, которым они противостоят, и/или с политикой и предположениями, которым они должны соответствовать. Некоторые могут зависеть от требований безопасности системы, выполняемых ее средой. В этом случае требования безопасности, относящиеся к внешней среде, необходимо оценивать в контексте требований к системе.

Руководства по безопасности определяют требования, направленные на обеспечение понятности, достаточности и законченности эксплуатационной документации, представляемой разработчиком. Эта документация, которая содержит две категории информации (для пользователей и администраторов), является важным фактором безопасной эксплуатации объекта и программного продукта. Требования к руководству пользователя должны обеспечивать возможность эксплуатировать объект безопасным способом. Руководство – основной документ, имеющийся в распоряжении разработчика, для предоставления пользователям необходимой общей и специфической информации о том, как правильно использовать функции безопасности.

Целесообразно идентифицировать компоненты или части их, критические с точки зрения безопасности, сбой в которых может привести к отказовой ситуации. Если имеется такой компонент, следует предусмотреть стратегию обеспечения его защиты. Стратегия должна гарантировать методы, при которых требования, проект, реализация и эксплуатационные процедуры, минимизируют или устраняют потенциальные нарушения безопасности программного продукта. Следует проанализировать требования контракта, относящиеся к использованию ресурсов аппаратных средств ЭВМ (например, максимально возможная производительность процессора, объем памяти, пропускная способность устройств ввода /вывода).