ГОСТ Р ИСО/МЭК 27034-1—2014
b
) подбирать соответствующие заявленным требованиям меры и средства контроля и управле
ния безопасностью приложений для предложений с указанием их стоимости;
c) представлять свидетельства надлежащей реализации требуемых мер и средств контроля и
управления безопасностью приложений в предлагаемых продуктах или услугах.
0.3.6 Аудиторы
Аудиторы — лица, которые должны:
a) понимать объем и процедуры, вовлеченные в верификационные измерения в отношении соот
ветствующих мер и средств контроля и управления;
b
) обеспечивать уверенность в повторяемости результатов аудита:
c) устанавливать список верификационных измерений, создающих свидетельства того, что при
ложение достигло целевого уровня доверия, требуемого руководством:
d) применять стандартизированные процессы аудита, основанные на использовании свиде
тельств. поддающихся проверке.
0.3.7 Пользователи
Пользователи — лица, которые должны:
a) быть уверенными в том. что использование или развертывание приложения является безопас
ным;
b
) быть уверенными в том, что приложения последовательно и своевременно создают надежные
результаты;
c) быть уверенными в том. что меры и средства контроля и управления безопасностью прило
жений и соответствующие верификационные измерения установлены и функционируют надлежащим
образом.
0.4 Принципы
0.4.1 Безопасность является требованием
Требования безопасности должны быть определены и проанализированы для каждого этапа жиз
ненного цикла приложений, подробно рассмотрены и управляемы на постоянной основе.
Требования безопасности приложений (см. 6.4) должны трактоваться таким же образом, как и тре
бования функциональных возможностей, качества и удобства в эксплуатации (см. ИСО/МЭК 9126, где
представлен пример модели качества). Кроме того, должны быть введены связанные с безопасностью
требования в отношении соответствия установленным пределам остаточного риска.
Согласно ИСО/МЭК/ИИЭР 29148 требования должны быть необходимыми, обобщенными, точ
но выраженными, последовательными, полными, лаконичными, осуществимыми, прослеживаемыми и
поддающимися проверке. Эти же характеристики относятся к требованиям безопасности. В докумен
тации проектов приложений слишком часто встречаются нечеткие требования, такие как «Разработчик
должен обнаруживать все значимые риски безопасности для приложения».
0.4.2 Безопасность приложений зависит от контекста
На безопасность приложений влияет определенная целевая среда. Вид и масштаб требований
безопасности приложений определяются рисками, которым подвергается приложение. Риски же зави
сят от вида контекста. Существует три вида контекста:
a) бизнес-контекст: конкретные риски, проистекающие из сферы бизнеса организации (телефон
ная компания, транспортная компания, государственное учреждение и т. д.);
b
) регулятивный контекст: конкретные риски, проистекающие из местоположения бизнеса органи
зации (права на интеллектуальную собственность и лицензирование, ограничения на криптографиче
скую защиту, авторское право, законы и постановления, законы об обеспечении приватности и т. д.);
c) технологический контекст: конкретные риски, проистекающие из технологий, используемых
в бизнесе организации [реинжениринг, безопасность встроенных инструментальных средств, защита
исходного кода программы, использование программы, заранее скомпилированной третьей стороной,
тестирование безопасности, тестирование на проникновение, граничная проверка, проверка кода про
граммы. среда информационно-коммуникационной технологии (ИКТ). в которой работает приложение,
конфигурационные файлы и некомпилированные данные, привилегии операционной системы для ин
сталляции и/или функционирования, техническое обслуживание, безопасное распространение и т. д.].
Технологический контекст охватывает технические спецификации приложений (функциональные
возможности безопасности, безопасные компоненты, онлайновые платежи, надежные контрольные
журналы, криптография, управление полномочиями и т. д.).
VII