ГОСТ Р ИСО/МЭК 27034-1-2014 Информационная технология (ИТ). Методы и средства обеспечения безопасности. Безопасность приложений. Часть 1. Обзор и общие понятия

     0.4 Принципы

0.4.1 Безопасность является требованием

Требования безопасности должны быть определены и проанализированы для каждого этапа жизненного цикла приложений, подробно рассмотрены и управляемы на постоянной основе.

Требования безопасности приложений (см. 6.4) должны трактоваться таким же образом, как и требования функциональных возможностей, качества и удобства в эксплуатации (см. ИСО/МЭК 9126, где представлен пример модели качества). Кроме того, должны быть введены связанные с безопасностью требования в отношении соответствия установленным пределам остаточного риска.

Согласно ИСО/МЭК/ИИЭР 29148 требования должны быть необходимыми, обобщенными, точно выраженными, последовательными, полными, лаконичными, осуществимыми, прослеживаемыми и поддающимися проверке. Эти же характеристики относятся к требованиям безопасности. В документации проектов приложений слишком часто встречаются нечеткие требования, такие как "Разработчик должен обнаруживать все значимые риски безопасности для приложения".

0.4.2 Безопасность приложений зависит от контекста

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

a) бизнес-контекст: конкретные риски, проистекающие из сферы бизнеса организации (телефонная компания, транспортная компания, государственное учреждение и т.д.);

b) регулятивный контекст: конкретные риски, проистекающие из местоположения бизнеса организации (права на интеллектуальную собственность и лицензирование, ограничения на криптографическую защиту, авторское право, законы и постановления, законы об обеспечении приватности и т.д.);

c) технологический контекст: конкретные риски, проистекающие из технологий, используемых в бизнесе организации [реинжениринг, безопасность встроенных инструментальных средств, защита исходного кода программы, использование программы, заранее скомпилированной третьей стороной, тестирование безопасности, тестирование на проникновение, граничная проверка, проверка кода программы, среда информационно-коммуникационной технологии (ИКТ), в которой работает приложение, конфигурационные файлы и некомпилированные данные, привилегии операционной системы для инсталляции и/или функционирования, техническое обслуживание, безопасное распространение и т.д.].

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

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

0.4.3 Соответствующие инвестиции в обеспечение безопасности приложений

Затраты на применение мер и средств контроля и управления безопасностью приложений и проведение аудиторских измерений должны быть соразмерны целевому уровню доверия (см. 8.1.2.6.4), требуемого владельцем приложения или руководством.

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

0.4.4 Безопасность приложений должна демонстрироваться

Процесс аудита приложений в ИСО/МЭК 27034-1 (см. 8.5) использует поддающиеся проверке свидетельства, обеспечиваемые мерами и средствами контроля и управления безопасностью приложений (см. 8.1.2.6.5).

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