Читать онлайн «Очерки истории отечественной программной инженерии в 1940-е – 80-е годы». Страница 48

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В 1950-е – 60-е годы к созданию программ для ЭВМ исторически подходили, как к «искусству и художественному творчеству» отдельных специалистов или небольших групп. При этом считалось, что невозможно применять, какие-либо экономические характеристики для определения стоимости и результатов такого творчества, и они оценивались только с позиции качества выполняемых функций и «эстетики» их реализации. Такие программы создавались преимущественно для получения конкретных результатов исследований или для анализа относительно простых процессов обработки информации. Они не предназначены для массового тиражирования и распространения как программный продукт на рынке, их оценивали качественно и интуитивно, преимущественно как «художественные произведения». При этом, как правило, не было конкретного заказчика-потребителя, определяющего требования к программам и их финансирование, программы не ограничивали допустимой стоимостью, трудоемкостью и сроками их создания, требованиями обеспечения заданного качества и документирования. Их разработчики не применяли регламентирующих, нормативных документов, вследствие чего жизненный цикл таких изделий имел не предсказуемый характер по качеству и стоимости основных результатов «творчества».