ГОСТ Р ИСО/МЭК 27034-7-2020 Информационные технологии (ИТ). Безопасность приложений. Часть 7. Основы прогнозирования доверия.
ГОСТ Р ИСО/МЭК 27034-7-2020
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Информационные технологии
БЕЗОПАСНОСТЬ ПРИЛОЖЕНИЙ
Часть 7
Основы прогнозирования доверия
Information technology. Application security. Part 7. Assurance prediction framework
ОКС 35.020
Дата введения 2021-06-01
Предисловие
1 ПОДГОТОВЛЕН Федеральным государственным учреждением "Федеральный исследовательский центр "Информатика и управление" Российской академии наук" (ФИЦ ИУ РАН) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ
4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 27034-7:2018* "Информационные технологии. Безопасность приложений. Часть 7. Основы прогнозирования доверия" (ISO/IEC 27034-7:2018 "Information technology - Application security - Part 7: Assurance prediction framework", IDT).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном
5 ВВЕДЕН ВПЕРВЫЕ
Правила применения настоящего стандарта установлены в ". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
Введение
ИСО (Международная организация по стандартизации) и МЭК (Международная электротехническая комиссия) образуют специализированную систему Всемирной стандартизации. Национальные органы, которые являются членами ИСО или МЭК, участвуют в развитии международных стандартов посредством технических комитетов, учрежденных соответствующей организацией для рассмотрения конкретных областей технической деятельности. Технические комитеты ИСО и МЭК сотрудничают в областях, представляющих взаимный интерес. Правительственные и неправительственные организации в сотрудничестве с ИСО и МЭК также принимают участие в работе. В области информационных технологий ИСО и МЭК учредили совместный технический комитет ИСО/МЭК СТК 1.
Процедуры, использованные для разработки настоящего стандарта и предназначенные для его дальнейшего сопровождения, описаны в части 1 директив ИСО/МЭК. В частности, следует отметить различные правила утверждения различных типов документов. Настоящий стандарт подготовлен в соответствии с редакционными правилами, приведенными в части 2 директив ИСО/МЭК (см. www.iso.org/directives).
Следует обратить внимание на возможность того, что некоторые элементы настоящего стандарта могут быть объектами патентных прав. ИСО и МЭК не несут ответственности за выявление каких-либо патентных прав. Подробная информация о любых патентных правах, выявленных в ходе разработки стандарта, содержится во введении и/или в списке полученных патентных деклараций ИСО (см. www.iso.org/patents).
Наименование любой торговой марки, используемое в настоящем стандарте, предоставляется в информационных целях для удобства пользователей и не является рекомендацией.
Для разъяснения значения конкретных терминов и выражений ИСО, связанных с оценкой соответствия, а также информации о приверженности ИСО принципам ВТО в области технических барьеров в торговле (ТБТ) - см. следующий веб-сайт: www.iso.org/iso/foreword.html.
ИСО/МЭК 27034-7 был подготовлен совместным техническим комитетом ИСО/МЭК СТК 1 "Информационные технологии (ИТ)", подкомитетом SC 27 "Методы обеспечения информационной безопасности ИТ". Подробности по серии ИСО/МЭК 27034 можно найти на веб-сайте ИСО.
0.1 Базовый прогноз
Проектная группа объявляет приложение безопасным, если подтверждающее доказательство демонстрирует достижение целевого уровня доверия (ИСО/МЭК 27034-1:2011, 0.4.4). Прогнозирование имеет место, когда проектная группа использует подтверждающее доказательство из предыдущей версии приложения и предоставляет обоснование того, почему подтверждающее доказательство все еще актуально для последующего приложения. Основы прогнозирования безопасности представляют собой процесс, посредством которого организации, использующие серию стандартов ИСО/МЭК 27034, выполняют анализ рисков и документируют принятое решение в соответствии с мерами обеспечения безопасности приложений (МОБП), которые реализованы в предыдущей версии приложения, но не реализованы в текущей версии.
В настоящее время физические лица и организации нередко переносят свое доверие в требованиях к безопасности между различными версиями приложений без какого-либо серьезного обоснования, поддерживающего этот перенос. Прогноз безопасности для последующего приложения без какого-либо объяснения или обоснования является порочной практикой. Чтобы исправить такую ситуацию, в настоящем стандарте установлены некоторые основы для создания прогнозов безопасности между версиями приложений путем систематизации требований к прогнозированию.
Настоящий стандарт фокусируется на прогнозах или передаче заявлений, связанных с последующими версиями одного и того же приложения.
0.2 Цель
Целью настоящего стандарта является оказание помощи организациям в разработке и использовании прогнозных обоснований безопасности приложения (ПОБП), в распространении информации о степени безопасности нескольких версий одного и того же приложения путем:
а) предоставления дополнительных рекомендаций группам нормативной структуры организации (НСО), чтобы они могли устанавливать соответствующие методики в отношении того, когда прогнозы являются, а когда не являются приемлемыми для их организаций;
b) предоставления результатов анализа риска, содержащего обоснование того, почему изменения в последующем приложении не являются существенными;
c) применения к проектам нормативной структуры приложений (НСП);
d) указания фактического уровня доверия к исходному и последующим приложениям;
e) указания ожидаемого уровня доверия для исходного (при условии его использования) и последующих приложений;
f) предоставления обоснования тому, почему анализ рисков, прогнозы для индивидуальных МОБП и фактический уровень доверия вместе создают ожидаемый уровень доверия;
g) верификации ПОБП, когда аудитор принимает решение повторно выполнить соответствующие действия по верификации МОБП.
Настоящий стандарт не содержит рекомендаций в отношении того:
a) что является и что не является допустимым риском;
b) что является и что не является существенным изменением;
c) когда владелец приложения должен или не должен принимать на себя определенный риск или
d) когда приобретающая сторона должна или не должна принимать ожидаемый уровень доверия.
0.3 Целевая аудитория
0.3.1 Общие положения
Настоящий стандарт полезен для следующих групп лиц при осуществлении своих ролей в организации:
a) руководители;
b) группы НСО;
c) проектные группы (группы подготовки к работе и эксплуатации);
d) профильные эксперты в проблемной области;
e) аудиторы;
f) владельцы приложений;
g) приобретающие стороны.
0.3.2 Руководители
Роли руководителей приведены в ИСО/МЭК 27034-1:2011 (пункт 0.3.2).
0.3.3 Группы НСО
Как описано в ИСО/МЭК 27034-1:2011 (подраздел 3.17), группа НСО отвечает за управление внедрением и обслуживанием компонентов и процессов, связанных с безопасностью приложений в нормативной базе организации. Группа НСО:
a) предоставляет рекомендации проектным группам относительно того, что является и что не является существенными изменениями;
b) оценивает и документирует в МОБП риск в части выбора ПОБП помимо обычных действий с МОБП;
c) рассматривает каждый компонент МОБП и определяет, авторизованы ли прогнозы и, если авторизованы, при каких обстоятельствах они приемлемы;
d) документирует определение прогноза для каждого компонента МОБП в НСО;
e) информирует владельца приложения при создании НСП о предполагаемом риске в части использования ПОБП;
f) отвечает на запросы проектных групп об изменении методик по прогнозированию для конкретных МОБП.
0.3.4 Группа подготовки и эксплуатации
Как описано в ИСО/МЭК 27034-1:2011 (пункт 0.3.3), члены групп подготовки к работе и эксплуатации (известных в совокупности как проектная группа) - это лица, участвующие в проектировании, разработке и обслуживании приложения на протяжении всего его жизненного цикла. Руководитель проекта отвечает за управление НСП.
Проектная группа:
a) выполняет анализ рисков по предлагаемым изменениям для приложения, чтобы определить, являются ли изменения существенными;
b) делает прогнозное обоснование безопасности приложений (как определено в 3.2) для каждого компонента МОБП, для которого прогноз уместен;
c) формирует отчет об ожидаемом уровне доверия.
0.3.5 Профильные эксперты в проблемной области
Профильный эксперт в проблемной области - это человек, который является экспертом в определенной сфере, области или теме, который обладает специфическими знаниями или опытом для проектной группы. Этот эксперт:
a) оказывает помощь проектной группе в проведении корректной оценки рисков;
b) оказывает помощь проектной группе в определении того, являются ли изменения в приложении существенными.
0.3.6 Аудиторы
Как описано в ИСО/МЭК 27034-1:2011 (пункт 0.3.6), аудиторами являются сотрудники, выполняющие функции в процессе аудита, которые участвуют в верификации приложений.
0.3.7 Владельцы приложений
В соответствии с определением, содержащимся в ИСО/МЭК 27034-1:2011 (подраздел 3.6), владельцем приложения является представитель организации, который несет ответственность за безопасность и защиту приложения. Владельцы приложений принимают окончательные решения по:
a) принятию проведенного проектной группой анализа рисков, связанных с тем, что изменения в приложении не являются существенными;
b) утверждению набора компонентов МОБП, для которых проектная группа делает прогнозное обоснование безопасности;
c) принятию ожидаемого уровня доверия.
0.3.8 Приобретающая сторона
Приобретающая сторона включает в себя всех лиц, участвующих в приобретении продукции или услуги. Приобретающие стороны:
a) выполняют действия в соответствии с ИСО/МЭК 27034-1:2011 (пункт 0.3.4);
b) оценивают, является ли фактический уровень доверия к исходному приложению приемлемым для снижения рисков приобретающей стороны при использовании приложения в предполагаемых условиях;
c) оценивают, является ли ожидаемый уровень доверия для последующего приложения соответствующим тому уровню рисков, который приобретающая сторона ожидает для использования приложения в предполагаемых условиях;
d) оценивают обоснование того, являются ли изменения в последующих приложениях существенными, и, если существенность изменений не согласуется с обоснованием, определяют, необходима ли дополнительная верификация.
1 Область применения
Настоящий стандарт устанавливает минимальные требования, при которых действия, определенные мерами по обеспечению безопасности приложения, заменяются прогнозным обоснованием безопасности приложения. Меры обеспечения безопасности приложений (МОБП), сопоставленные с прогнозным обоснованием безопасности приложений (ПОБП), определяют ожидаемый уровень доверия для последующего приложения. В контексте ожидаемого уровня доверия всегда существует исходное приложение, для которого проектная группа выполняла действия с использованием МОБП для достижения фактического уровня доверия.
Использование ПОБП, определенного в настоящем стандарте, применимо для проектных групп, которые имеют определенную нормативную структуру приложений и исходное приложение с фактическим уровнем доверия.
Прогнозы относительно объединения нескольких компонентов или истории разработчика по отношению к другим приложениям выходят за рамки настоящего стандарта.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты [для датированных ссылок применяют только указанное издание ссылочного стандарта, для недатированных - последнее издание (включая все изменения к нему)]:
ISO/IEC 27000, Information technology - Security techniques - Information security management systems - Overview and vocabulary (Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Общий обзор и терминология)
ISO/IEC 27034-1, Information technology - Security techniques - Application security - Part 1: Overview and concepts (Информационная технология. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 1. Обзор и общие понятия)
3 Термины и определения
В настоящем стандарте применены термины по ИСО/МЭК 27000, ИСО/МЭК 27034-1, а также следующие термины с соответствующими определениями:
ИСО и МЭК ведут терминологические базы данных для использования в стандартизации по следующим адресам:
- просмотр ISO Online: доступ по адресу https://www.iso.org/obp;
- IEC Electropedia: доступно по адресу http://www.electropedia.org/.
3.1 прогноз (prediction): Утверждение или оценка того, что специфическое нечто (ситуация, событие, результат, факт) произойдет в будущем или будет следствием чего-то.
Примечание - Использование настоящего термина в настоящем стандарте отражает ожидание того, что при выполнении мер по обеспечению безопасности и верификационным измерениям прогнозные результаты будут соответствовать результатам из исходного приложения.
3.2 основы прогнозирования (prediction framework): Процесс, в котором выполняется анализ рисков, устанавливается ожидаемый уровень доверия (3.8), назначается прогнозное обоснование безопасности приложения (3.7) и в итоге создается отчет об ожидаемом уровне доверия (3.9).
3.3 исходное приложение (original application): Приложение, которое устанавливает базовую линию фактического уровня доверия.
Примечание - Исходное приложение не обязательно является версией 1.0 и, следовательно, может иметь соответствующий ожидаемый уровень доверия.
3.4 последующее приложение (subsequent application): Приложение, связанное с исходным приложением (3.3) через управление версиями.
Пример - От версии 1.0 до версии 1.1.
3.5 прогнозируемая безопасность (predictive security): Доверие к требованиям безопасности (3.6) для исходного приложения (3.3), переносимое на требования безопасности для последующего приложения (3.4).
3.6 требование безопасности (security claim): Особое утверждение о том, какие свойства безопасности должны присутствовать в приложении.
Примечания
1 В соответствии с основами серии стандартов ИСО/МЭК 27034 имеют место требования, нацеленные на то, чтобы процедуры МОБП снижали конкретные риски безопасности до допустимого уровня.
2 В контексте ПОБП утверждается, что верификация действий с МОБП, которые были промоделированы с использованием ПОБП, приведет к тем же результатам, что и в случае выполнения действий с использованием МОБП.
3.7 прогнозное обоснование безопасности приложения; ПОБП (Prediction Application Security Rationale; PASR): Обоснование для прогноза (3.1), поддержанное документами по анализу рисков, утвержденными владельцем приложения, объясняющими, что выполнение действий по верификации конкретных мер обеспечения безопасности приложений не является необходимым.
Примечание - Использование ПОБП требует утверждения владельца приложения и включения методик ПОБП в меры по безопасности приложений группой нормативной структуры организации.
3.8 ожидаемый уровень доверия (expected level of trust): Уровень доверия, определяемый в нормативной базе организации, где действия с некоторыми мерами обеспечения безопасности приложений полагаются удовлетворительными посредством моделирования с использованием ПОБП (3.7).
Примечание - В настоящем стандарте указаны минимальные требования, применимые к МОБП, используемым при ожидаемом уровне доверия для последующего приложения (3.4). В контексте ожидаемого уровня доверия всегда существует исходное приложение (3.3), для которого проектная группа выполняла действия с указанными МОБП.
3.9 отчет об ожидаемом уровне доверия (expected level of trust report): Документ, представляющий и поддерживающий анализ рисков в прогнозах (3.1), сделанных для последующих приложений.
3.10 прогнозируемые меры обеспечения безопасности приложений; прогнозируемые МОБП (predicted Application Security Control; predicted ASC): Меры обеспечения безопасности приложений, для которых их действия по обеспечению безопасности моделируются с использованием ПОБП (3.7).
3.11 потребитель прогноза (prediction consumer): Кто-либо, кто полагается на ожидаемый уровень доверия (3.8).
Примечание - Потребителями прогноза в основном являются потребители приложений, приобретающие стороны и владельцы приложений.
3.12 инициатор прогнозирования (prediction initiator): Субъект, который выбирает ожидаемый уровень доверия (3.8) для приложения.
Примечание - Как правило, это проектная группа по согласованию с владельцем приложения.
3.13 верификационные измерения (verification measurement): Действия, обеспечиваемые с использованием МОБП для верификации того, что их процедуры были корректно применены и показали ожидаемую работоспособность с предоставлением необходимых доказательств/результатов.
3.14 существенное изменение (substantial change): Изменение, которое оказывает значительное воздействие на оценку риска, такое, что владелец приложения возражает против использования прогнозируемых МОБП (3.10), в результате чего проектная группа выполняет необходимые действия с МОБП, ориентируясь на фактический уровень доверия.
3.15 регрессионное тестирование (regression testing): Тестирование, необходимое для определения того, что изменение системного компонента не оказало отрицательного влияния на функциональность, надежность или производительность и не привело к дополнительным дефектам.
4 Сокращения
В настоящем стандарте использованы следующие сокращения:
МОБП - меры обеспечения безопасности приложений;
НСП - нормативная структура приложений;
НСО - нормативная структура организации;
ПОБП - прогнозное обоснование безопасности приложения.
5 Общие положения по прогнозированию
5.1 Цель прогнозирования
Прогнозирование безопасности происходит ежедневно. Цель настоящего стандарта - сделать прогнозы безопасности приложений ясными (а не подразумеваемыми) и обеспечить постоянное документирование прогнозов. Когда прогнозы содержательны и правильно задокументированы в виде отчета об ожидаемом уровне доверия, потребители прогнозов имеют гораздо более совершенную поддержку в принятии решений о рисках. Все прогнозы оперируют с неопределенностями, и точность прогноза не ожидается более высокой, чем наименее достоверные исходные данные для прогнозирования.
Прогнозы безопасности приложений базируются на рисках, которые существуют как для исходной, так и для последующих версий приложения. Прогноз выглядит следующим образом: инициатор прогнозирования полагает, что последующее приложение имеет эквивалентный уровень доверия к исходному приложению, даже если некоторые из действий с использованием МОБП, оцененных уровнем доверия, не завершены проектной группой. Вместо этого процедуры МОБП моделируются с использованием ПОБП. Без прогнозов единственный способ полагать, что эквивалентные уровни доверия присутствуют в двух приложениях (исходном и последующем), состоит в физическом исполнении всех действий с использованием всех МОБП, определенных уровнем доверия.
Основы прогнозирования формируют один из подходов к обеспечению доверия к приложению. Он должен рассматриваться целостно с другими подходами к достижению доверия, например такого, как регрессионное тестирование, как оно определено в ИСО/МЭК/ИИЭР 29119-1 [1] и ИСО/МЭК 90003 [2]. Настоящий стандарт обеспечивает эффективность в обеспечении доверия к безопасности приложения. Эффективность достигается за счет снижения затрат, поскольку в ожидаемом уровне доверия происходит замена действий некоторых из определенных МОБП на ПОБП. Владелец приложения должен знать об этом снижении затрат и должен, используя рекомендации группы НСО, принять соответствующее решение относительно риска принятия ПОБП.
С точки зрения безопасности без каких-либо методик от группы НСО и утверждения владельцем приложения использование ПОБП не допускается. Без прогнозирования единственный способ получить уверенность в эквивалентности уровней доверия между исходными и последующими приложениями - это сделать фактический уровень доверия одинаковым для обоих этих приложений.
Примечание - В приложении А приведен пример обеспечения ожидаемого уровня доверия, а в приложении В дано сравнение между процедурами МОБП и ПОБП.
5.2 Основы прогнозирования
Как определено в ИСО/МЭК 27034-1, приложение безопасно, когда фактический уровень доверия эквивалентен целевому уровню доверия. Основы прогнозирования не могут и не должны изменять определенный фактический уровень доверия. Прогнозирование добавляет ожидаемый уровень доверия в качестве некоторого механизма в отношении свойств безопасности последующего приложения.
Основы прогнозирования включают в себя следующие понятия:
a) исходное приложение, в котором фактический уровень доверия был равен целевому уровню доверия, что привело (согласно определению ИСО/МЭК 27034-1) к безопасному приложению;
b) последующее приложение, в котором целевой уровень доверия охватывает подмножество исходных приложений с фактическим уровнем доверия;
c) анализ риска, изложенный в ПОБП, относительно случая, когда последующее приложение не имеет существенных изменений и возможности МОБП будут приводить к тому же результату, что и при выполнении действий по обеспечению безопасности и верификационных измерениях для исходного приложения;
d) для последующего приложения - утверждение о том, что приложение имеет фактический уровень доверия и что ожидаемый уровень доверия последующих приложений эквивалентен фактическому уровню доверия исходных приложений.
5.3 Ожидаемый уровень доверия
5.3.1 Общие положения
Настоящий стандарт добавляет определение ожидаемого уровня доверия. Оно не указывает конкретно на то, что проектная группа не выполняет действия с конкретными МОБП, а дает прогноз того, что если проектная группа выполнит действия с использованием МОБП, то результаты будут соответствовать результатам, характерным для исходного приложения.
Рисунок 1 иллюстрирует основы ожидаемого уровня доверия.
|
 |
Рисунок 1 - Ожидаемый уровень доверия
Для версии 1.0 целевой уровень доверия был "синим", и приложение успешно реализовало шесть МОБП, поэтому фактический уровень доверия также был "синим". Поскольку это была первая версия приложения (версия 1.0), то и не было никаких прогнозов и ожидаемого уровня доверия.
Для версии 1.1 проектная группа успешно реализовала три МОБП (с 4-го по 6-й), поэтому фактический уровень доверия для них является "красным". Ожидаемый уровень доверия для них будет "синим", так как группа прогнозирует, что действие этих трех МОБП не является необходимым для версии 1.1. Далее проектная группа может констатировать, что приложение защищено на "красном" уровне доверия, и группа полагает, что приложение лишь тогда будет защищено на "синем" уровне доверия, когда действие остальных МОБП будет промоделировано с использованием соответствующего ПОБП.
Ожидаемый уровень доверия включает в себя фактический уровень доверия, который является подмножеством ожидаемого уровня доверия. МОБП, не содержащиеся в фактическом уровне доверия, имеют соответствующее прогнозное обоснование безопасного приложения. В результате это прогнозное обоснование дополняет определение "безопасного приложения".
5.3.2 Ожидаемый уровень доверия в нормативной структуре организации
Группа нормативной структуры организации (НСО) устанавливает методики в отношении того, когда ПОБП подходит для каждой из мер обеспечения безопасности приложений, находящихся в библиотеке МОБП. Рисунок 2 отображает НСО, которая содержит три уровня доверия и является источником уровней доверия, приведенных на рисунке 1.
|
 |
Рисунок 2 - Нормативная структура организации
"Зеленый" и "красный" уровни доверия содержат отдельные МОБП, в то время как "синий" уровень доверия является комбинацией "красного" и "зеленого".
Специальный ожидаемый уровень доверия отсутствует. Как показано на рисунке 1, для версии 1.0 целевой и фактический уровни доверия были "синими", а для версии 1.1 ожидаемый уровень доверия - тоже "синий". Это делается намеренно, поскольку использование одинаковых уровней доверия позволяет приобретающей стороне сравнивать для одного и того же приложения разные версии, имеющие одинаковые уровни доверия. Разница заключается в том, что, если две версии имеют одинаковый фактический уровень доверия, приобретающая сторона знает, что версии эквивалентны в силу того, что обе комплектуются одними и теми же МОБП. Если последующая версия использует ожидаемый уровень доверия, приобретающая сторона знает, что инициатор прогнозирования считает две версии эквивалентными, но доказательством этой эквивалентности является результат обоснования.
5.3.3 Ожидаемый уровень доверия в нормативной структуре приложений
После того, как оценка риска в области безопасности приложений показывает, что прогнозы являются приемлемыми, и владелец приложения разрешает использование прогнозов, проектная группа устанавливает нормативную структуру приложений. Рисунок 3 иллюстрирует НСП как для версии 1.0, так и для версии 1.1.
Для версии 1.0 целевые и фактические уровни доверия в НСП являются "синими". Для версии 1.1 целевой уровень доверия - "красный", фактический - "красный", а ожидаемый - "синий".
Все МОБП, определенные в ожидаемом уровне доверия, включая те, которые обоснованы с использованием ПОБП, могут быть проверены во время верификации безопасности приложения с использованием аудита безопасности приложения.
|
 |
Рисунок 3 - Нормативная структура приложений
5.3.4 Данные МОБП в нормативной структуре приложений
Нормативная структура приложений является хранилищем всех данных, связанных с ожидаемым уровнем доверия к приложению.
Без каких-либо указаний от владельца приложения все процедуры МОБП должны выполняться по умолчанию, прогнозирование не допускается.
Когда проектная группа выполняет действия с МОБП, в НСП есть данные, которые ссылаются на МОБП и позволяют проводить верификацию и аудит выполнения действий проектной группы. При прогнозировании с использованием ПОБП процедуры МОБП не осуществляются (они заменяются на моделирование с использованием ПОБП), но есть связанные данные, которые ссылаются на МОБП в НСП.
На рисунке 4 приведены оба типа данных.
|
 |
Рисунок 4 - Данные МОБП
Для версии 1.0 каждые МОБП имеют данные о процедурах, связанных с МОБП, хранящихся в НСП. Для версии 1.1 проектная группа выполняет только процедуры МОБП4, 5 и 6, следовательно, только эти МОБП имеют связанные результаты. Для МОБП1, 2 и 3 проектная группа использует модели с использованием ПОБП. Каждое ПОБП содержит обоснование того, почему задействование МОБП не является необходимым для поддержания ожидаемого уровня доверия. ПОБП также содержит ссылку на НСП версии 1.0 и результаты выполнения проектной группой действий с МОБП.
Ссылка из ПОБП на предыдущий результат является обязательной. Если ссылка отсутствует, аудиторская группа не может верифицировать ожидаемые результаты МОБП при выполнении верификации или аудита. Это требование иметь ссылку является основной причиной, по которой проектная группа не может использовать прогнозное обоснование для МОБП, которые никогда не создавались в одной из предыдущих версий.
Примечание - Вместо ссылки на исходное приложение НСП группа НСО может потребовать от проектной группы скопировать в последующее приложение НСП данные о результатах применения МОБП. В этом случае нет необходимости ссылаться на исходное приложение в нормативной структуре приложений.
5.3.5 Ожидаемый уровень доверия к последовательности версий приложения
5.3.5.1 Несколько версий
В предыдущих примерах рассматривались только две версии приложения, но большинство приложений имеют гораздо больше двух версий. Следующий вариант охватывает различные уровни доверия, используемые проектной группой.
Проектная группа использует НСО из рисунка 2. В этом случае предполагается, что проектная группа всегда успешно выполняет все действия, назначенные для целевого уровня доверия, и, следовательно, все приложения являются безопасными, так как фактический уровень равен целевому.
Чтобы распознавать различные версии приложения, приложению требуется уникальный идентификатор. Существует множество схем идентификации и тиражирования идентификационных данных. Идентификаторы для программных средств рассмотрены в ИСО/МЭК 19770-5 [3] и ИСО/МЭК 19770-2 [4], а для аппаратных средств - в ИСО/МЭК 20009-1 [5].
5.3.5.2 История версий
В 5.3.5 описывается вариант использования, обсуждаются выборы, сделанные проектной группой, и утверждение владельцем приложения. Для иллюстрации всех версий приложения используют таблицу 1.
Таблица 1 - История версий и уровней доверия
|
 |
5.3.5.3 Исходное приложение - версия 1.0
Для исходного приложения целевой уровень доверия установлен как "синий", и после выполнения МОБП фактический уровень доверия "синий". Ожидаемый уровень доверия не определен.
НСП содержит результаты процедур МОБП для всех МОБП, определенных "синим" уровнем доверия. Проектная группа утверждает, что версия 1.0 является безопасным приложением в соответствии с "синим" уровнем доверия.
5.3.5.4 Версия 1.1
Для версии 1.1 проектная группа, проведя анализ рисков в области безопасности приложений, определяет, что в области, охватываемой "красным" уровнем доверия МОБП, произошли существенные изменения. Проектная группа также определяет, что для других МОБП внутри "синей" области существенных изменений нет. Проектная группа хочет заявить, что уровень доверия версии 1.1 эквивалентен уровню доверия версии 1.0, поэтому проектная группа устанавливает ожидаемый уровень доверия как "синий".
НСП содержит результаты для "красного" уровня доверия МОБП и ПОБП для остальных МОБП, отмеченных как "синий". ПОБП содержат ссылки на НСП версии 1.0, так что результаты прогнозируемых МОБП связаны и доступны.
Проектная группа утверждает, что версия 1.1 защищена в соответствии с "красным" уровнем доверия, и она считает ее эквивалентной версии 1.0 и "синему" уровню доверия.
5.3.5.5 Версия 1.2
Предположим, что версия 1.2 является ответом на ошибку в версии 1.1. Анализ риска в области безопасности приложений показывает, что исправление ошибки однозначно является существенным изменением для МОБП, которые составляют "зеленый" уровень доверия. Проектная группа хочет заявить, что уровень доверия для версии 1.2 эквивалентен версии 1.1 и версии 1.0. Поэтому проектная группа устанавливает ожидаемый уровень доверия как "синий".
НСП содержит результаты для "зеленого" уровня доверия МОБП и ПОБП для остальных МОБП, обозначенных как "синий". ПОБП содержат ссылки на НСП версии 1.1 и косвенно на НСП версии 1.0, так что результаты прогнозируемых МОБП связаны и доступны.
Проектная группа утверждает, что версия 1.2 безопасна в соответствии с "зеленым" уровнем доверия, и она считает ее эквивалентной версии 1.0 и "синему" уровню доверия.
5.3.5.6 Версия 1.3
Предположим, что версия 1.3 - это быстрый ответ на ошибку в версии 1.2. Анализ риска в области безопасности приложений показывает, что исправление ошибки снова является существенным изменением для МОБП, которые составляют "зеленый" уровень доверия. Проектная группа хочет заявить, что уровень доверия для версии 1.3 эквивалентен предыдущим версиям, поэтому проектная группа устанавливает ожидаемый уровень доверия как "синий".
НСП содержит результаты для "зеленого" уровня доверия МОБП и ПОБП для остальных МОБП, обозначенных как "синий". ПОБП содержат ссылки на НСП версии 1.1, так что результаты прогнозируемых МОБП связаны и доступны. Важно отметить, что ПОБП ссылается на версию 1.1, а не на версию 1.2. Ссылка может быть как явной, так и неявной, следуя ссылкам версии 1.1. В любом случае все дело в том, что в последний раз процедуры МОБП были завершены в версии 1.1.
Проектная группа утверждает, что версия 1.3 защищена в соответствии с "зеленым" уровнем доверия, и она считает ее эквивалентной версии 1.0 и "синему" уровню доверия.
5.3.5.7 Версия 2.0
Предположим, что версия 2.0 - это переписывание архитектурной инфраструктуры приложения. Оценка риска в области безопасности приложений указывает на то, что имеются многочисленные существенные изменения и никакие прогнозы невозможны. Как и для версии 1.0, проектная группа устанавливает для версии 2.0 целевой уровень доверия как "синий" и не использует никаких прогнозов, поэтому ожидаемый уровень доверия отсутствует ("Не определено").
НСП содержит результаты процедур МОБП для всех МОБП, определенных "синим" уровнем доверия. Проектная группа утверждает, что версия 2.0 является безопасным приложением в соответствии с "синим" уровнем доверия.
5.4 Принципы
5.4.1 Принципы ИСО/МЭК 27034-1
ИСО/МЭК 27034-1 определяет два важных принципа, а именно: приемлемость соответствующих инвестиций в обеспечение безопасности приложений, соразмерных с целевым уровнем доверия (ИСО/МЭК 27034-1:2011, пункт 0.4.3) и необходимость демонстрации безопасности приложений (ИСО/МЭК 27034-1:2011, пункт 0.4.4). Прогнозы не могут нарушать эти принципы.
5.4.2 Принцип приемлемости инвестиций для безопасности приложений
ПОБП не нарушают принцип инвестирования, поскольку владелец приложения после проведения оценки риска в области безопасности приложений определяет, что повторное выполнение процедур МОБП не требуется. Осуществление этих процедур после определения того, что в них нет необходимости и что это скорее может привести к излишним затратам ресурсов, является прямым нарушением принципа приемлемости инвестиций.
Наличие проектной группы, предоставляющей результат оценки риска в области безопасности приложений и соответствующего прогнозного обоснования, позволяет владельцу приложения или приобретающей стороне:
a) оценить риски в области безопасности приложений;
b) присвоить приложению ожидаемый уровень доверия;
c) оценить перечень МОБП, имеющих ПОБП;
d) оценить приемлемость ожидаемого уровня доверия для предполагаемого использования приложения.
5.4.3 Принцип необходимости демонстрации безопасности приложений
ПОБП не нарушает принцип демонстрации безопасности, поскольку есть доказательства принятых мер. Когда проектная группа выполняет действия с МОБП, результатом является проверочное измерение, которое аудитор рассматривает на 5-м шаге процесса менеджмента безопасности приложений (ИСО/МЭК 27034-1:2011, пункт 7.3.6). Процесс аудита рассматривает верификационные измерения и определяет наличие ожидаемого результата.
При работе с прогнозом аудитор выполняет один и тот же тип операций, а именно:
a) анализирует ПОБП и определяет, что использование ПОБП соответствует методикам, установленным группой НСО;
b) проводит аудит ПОБП, чтобы убедиться, что:
1) ПОБП ссылается на МОБП из исходного приложения;
2) ожидаемые результаты исходного применения МОБП, полученные в ходе реализации исходного приложения, фактически существуют;
3) в ПОБП включается утверждение прогнозного обоснования, как указано в 9.3.2.
5.5 Утверждение прогноза
5.5.1 Ответственность за прогнозирование
Прогнозы требуют двух авторизации: первая - от группы НСО, вторая - от владельца приложения:
a) первая авторизация: группа НСО должна установить основные правила для каждых МОБП в библиотеке МОБП организации, уточнив, при каких обстоятельствах прогнозирование допустимо. Группа НСО рассматривает на постоянной основе наряду со всеми другими мероприятиями и результатами МОБП методики по прогнозированию безопасности приложений. В ходе анализа группа НСО убеждается в том, что методики по-прежнему отражают соответствующие руководства по рискам. Без руководства по основным правилам прогнозирования, действующего в НСО, существующие прогнозы относительно МОБП по умолчанию недопустимы;
b) вторая авторизация: владелец приложения, используя методики по прогнозированию безопасности приложений, установленные группой НСО, после соответствующей оценки риска в области безопасности приложений определяет, что ожидаемый уровень доверия является приемлемым.
Для каждых МОБП, для которых проектная группа создает ПОБП вместо выполнения действий с МОБП, проектная группа верифицирует оценку риска в области безопасности приложений, чтобы убедиться, что ПОБП пригодно для идентифицированного риска.
5.5.2 Принудительная авторизация
Ни группа НСО, ни владелец приложения не могут заставить один другого принять к использованию прогнозы.
Группа НСО не может заставить владельца приложения не осуществлять выполнение действий с МОБП. Владелец приложения устанавливает целевой уровень доверия, который включает МОБП, выполнение действий с ними и достижение фактического уровня доверия. Если проектная группа выполнила необходимые действия с МОБП, никакой прогноз не осуществляется.
Владелец приложения не может заставить группу НСО принимать прогнозы, выходящие за рамки принятых методик. Владелец приложения может запросить обновленные методики, но если методики не меняются, а проектная группа не выполняет действия с МОБП, то группа НСО не позволяет использовать ожидаемый уровень доверия.
5.6 Требования относительно фактического уровня доверия
Проектная группа, передавая исходное приложение приобретающей стороне, может предъявлять требования, связанные с обеспечением безопасности, относительно исходного приложения. Одна из целей прогнозирования заключается в том, чтобы помочь проектной группе связать требования к исходному приложению с требованиями к последующему приложению, даже если последующее приложение имеет другой фактический уровень доверия.
Исходное приложение может иметь дополнительные требования к обеспечению безопасности, основанные на дополнительных механизмах. Если в исходном приложении предусматриваются дополнительные механизмы, проектная группа может попытаться отразить передачу дополнительного механизма в последующее приложение на основе ожидаемого уровня доверия. Эффективность этой передачи выходит за рамки настоящего стандарта, и она зависит от конкретики.
Аспекты, которые могут приводить к дополнительным требованиям к безопасности, рассмотрены (но не ограничиваются этими стандартами):
a) в ИСО/МЭК 15408 (во всех частях) [6];
b) в ИСО/МЭК 15026 (во всех частях) [7].
6 Прогнозы
6.1 Инициатор прогнозирования
Инициатором прогнозирования, как правило, является проектная группа под руководством владельца приложения. Группа, предоставляя оценку риска владельцу приложения (ИСО/МЭК 27034-1:2011, пункт 7.3.3), указывает, что последующее приложение не должно выполнять определенные процедуры МОБП. После рассмотрения методик, установленных для прогнозирования действий с МОБП, принятых группой НСО, владелец приложения утверждает:
- фактический уровень доверия, который не содержит прогнозируемые МОБП;
- использование ожидаемого уровня доверия, который содержит прогнозируемые МОБП.
6.2 Обстоятельства прогнозирования
6.2.1 Обычное обстоятельство
Обстоятельство является причиной, по которой существует последующее приложение. Аспект обстоятельства является основным фактором в оценке риска. Обстоятельства для последующих приложений разнообразны, они включают (но не ограничиваются этим):
a) новую функциональность. Добавление новых функциональных возможностей (в зависимости от архитектуры приложения) может привести к созданию большого набора приложений, которые не нуждаются в верификации. Если отсутствует повторение верификации, то прогнозы могут оказаться альтернативой;
b) исправление ошибок:
1) исправление ошибок обычно сосредоточено на изменениях во многих функциях приложения, не требующих повторной верификации. Если отсутствует повторение верификации, то прогнозы могут оказаться альтернативой. Расширяются целевые контексты;
2) функциональность приложения остается прежней, но типы угроз и поддерживаемых сред расширяются. Этот тип изменений в приложении может представлять собой несущественное изменение или наоборот - масштабное переписывание существенных частей приложения.
6.2.2 Отношение к уровню доверия
Предположение, сделанное как инициатором прогнозирования, так и потребителем прогноза, заключается в том, что уровень доверия согласован между версиями приложения. Обычно находятся обстоятельства, при которых возникает желание изменить уровень доверия между версиями. В следующих примерах приводятся рекомендации относительно того, как проектная группа может реагировать на изменение уровня доверия.
Например, уровень доверия версии 1.0 недостаточен для нейтрализации выявленных угроз.
Первым ответом проектной группы будет выбор нового уровня доверия, который имеет дополнительные меры, нейтрализующие выявленные угрозы. Для каждой из новых МОБП нет возможности осуществлять прогнозирование, поскольку нет никаких предыдущих результатов для ссылки в ПОБП. Следовательно, проектная группа выполняет реальные действия со всеми новыми МОБП.
Вполне вероятно, что новый уровень доверия содержит такие МОБП, которые находятся на предыдущем уровне доверия. Проектные группы, следуя оценке риска в области безопасности приложений, могут определить, что прогнозы подходят для тех МОБП, которые исполнены в исходном приложении. В результате МОБП будет иметь такое прогнозное обоснование, которое ссылается на действия с исходными приложениями НСП.
Эта ситуация аналогична обнаружению уязвимости в исходном приложении. Ответ заключается в изменении МОБП для нейтрализации уязвимости. Если приложение никогда не применяло новые МОБП, прогнозы невозможны. Для последующего приложения проектная группа выполняет новые действия с МОБП.
6.3 Потребитель прогноза
В то время, как инициатор прогнозирования может предъявить любое требование относительно безопасности, главным лицом, принимающим решение, является потребитель прогноза. Если потребитель прогноза принимает отчет об ожидаемом уровне доверия, то он становится лицом, принимающим оценку риска относительно изменений, и соглашается с проектной группой, что изменения в последующем приложении не являются существенными.
Инициатор прогнозирования не может вынудить потребителя прогноза принять отчет об ожидаемом уровне доверия. Потребитель прогноза на основе своего собственного решения о собственном риске с использованием предоставленных обоснований может принять только фактический уровень доверия. Это означает, что любые прогнозные утверждения, сделанные относительно исходного приложения, не передаются в последующее приложение в соответствии с решением потребителя прогноза.
Чтобы принять отчет об ожидаемом уровне доверия, некоторым потребителям прогнозов могут потребоваться дополнительные доказательства, различные основания для обоснования или множество других видов анализа. После того, как владелец приложения утвердит использование прогнозов, эти дополнительные требования потребителей прогнозов будут скорее всего неожиданными. Поэтому потребители прогнозов часто упускают критическую точку, до которой возможен учет их решения по рискам относительно ожидаемого уровня доверия. Несмотря на стремление проектной группы предоставить недостающие данные, может оказаться невозможным их подготовить, пока разработка приложения не будет завершена. В связи с этим потребители прогнозов, у которых есть особые требования, должны сделать эти требования доступными для своих поставщиков приложений таким образом, чтобы инициаторы прогнозов смогли подготовить данные, необходимые для этих потребителей прогнозов, и в итоге - чтобы иметь достаточную уверенность в ожидаемом уровне доверия.
7 Существенные изменения
7.1 Рассмотрение определения
Согласно 3.14 существенное изменение - это изменение, которое оказывает значительное воздействие на оценку риска, такое, что владелец приложения возражает против использования прогнозируемых МОБП (3.10), в результате чего проектная группа выполняет необходимые действия с МОБП, ориентируясь на фактический уровень доверия. Особое внимание уделяется оценке рисков. Дополнительные детали в определении учитывают аспекты, связанные с отраслью промышленности, продавцом, самим приложением, культурными и географическими различиями. То, что существенно для одного, не является существенным для другого. Определение возлагает на владельца приложения ответственность за оценку риска и определение результата для последующего применения, основанного на текущих обстоятельствах.
Если бы каждая версия приложения была независима от всех предыдущих версий, то не было бы основания для прогноза. Дело не в этом, версия 1.1 тесно связана с версией 1.0. Что более важно: те, кто используют различные версии приложения, ожидают устойчивости в пределах некоторого небольшого диапазона или набора свойств для приложения. Владелец приложения может установить различный целевой уровень доверия для разных версий. В отсутствие каких-либо специальных пояснений от проектной группы ожидание со стороны приобретающей стороны заключается в том, что версия 1.1 эквивалентна версии 1.0.
7.2 Методические указания по анализу рисков для существенных изменений
7.2.1 Общие положения
Поскольку определение существенности изменения является результатом оценки риска, то простого объяснения того, какое изменение является существенным, а какое не является, - нет. Владелец приложения должен вовремя определить, какие изменения являются существенными, а какие не являются. В настоящих методических указаниях проиллюстрировано, что может быть приемлемым или неприемлемым для определения существенности изменений при проведении оценки риска.
Одним из аспектов определения существенности изменений является тип действия с МОБП. Некоторые действия имеют решающее значение независимо от того, какие изменения происходят. Другие могут зависеть от конкретной ситуации. Нижеследующие рекомендации являются лишь примерами, и каждый владелец приложения должен дать свои собственные соответствующие обоснования.
7.2.2 Изменение кода и статический анализ
В этом примере для рассматриваемых МОБП требуется статический анализ всего измененного кода. Группа НСО придерживается мнения, что применительно к статическому анализу МОБП прогнозы недопустимы. Любое изменение кода требует статического анализа.
Если владелец приложения разрешает осуществить прогнозирование и не выполнять статический анализ, то обоснование безопасности приложения должно содержать убедительные причины для пропуска этого действия с МОБП. Вполне вероятно, что даже при наличии убедительного обоснования потребители приложения не согласятся с этим обоснованием. Таким образом, вопреки мнениям владельца приложения и проектной группы, которые считают, что у них есть веская причина пропустить статический анализ МОБП, именно потребитель прогноза принимает окончательное решение о принятии риска, если ожидаемый при этом уровень доверия является для него приемлемым.
7.2.3 Анализ архитектуры
В этом примере процедура МОБП представляет собой анализ архитектуры безопасности. Группа НСО считает, что прогнозы приемлемы, если проектная группа обоснует отсутствие влияния изменений на архитектуру. Настоящие рекомендации включают примеры того, что изменение размера буфера данных обычно не приводит к изменению архитектуры безопасности.
После соответствующей верификации владелец приложения определяет, что никаких изменений в архитектуре безопасности не происходит и целевой уровень доверия не включает анализа МОБП касательно архитектуры безопасности. Проектная группа разрабатывает обоснование безопасности приложения и в ходе аудита подтверждает его наличие. Учитывая, что все МОБП сформированы, в этом случае фактический уровень доверия соответствует целевому уровню, а ожидаемый уровень доверия предусматривает анализ МОБП касательно архитектуры безопасности. Этот анализ архитектуры безопасности характеризует прогнозируемые МОБП.
7.2.4 Устаревание тестов со временем
При оценке существенности изменения проводимая оценка риска будет включать в себя анализ наборов тестов, используемых для получения доказательств применительно к действиям с МОБП. Методики, используемые для проверки действий с МОБП, меняются с течением времени. Эти методики адаптируются к усовершенствованиям, осуществляемым с использованием методов и знаний, полученных в ходе предыдущего тестирования. В результате из-за изменений в устаревших методиках для МОБП, протестированных ранее, могут возникать ошибки на обновленных методиках.
Проектная группа в своем анализе рисков относительно существенности изменений должна учитывать возможность обновления методик тестирования. Это особенно важно учитывать, когда проектная группа использует ПОБП для нескольких поколений приложения. Чтобы помочь проектным группам и владельцу приложений, для специальных МОБП группа НСО может установить максимальные ограничения на использование последующего ПОБП.
8 Уверенность
8.1 Пояснения к формированию уверенности
Смысл доверия состоит в формировании уверенности в чем-то с помощью "кого-то". В настоящем стандарте речь идет об уверенности в результатах анализа риска того, что изменение не является существенным. Этот анализ выполняется проектной группой. В качестве "кого-то" выступает потребитель прогноза. Потребитель прогноза должен быть уверен в проектной группе и их анализе риска в такой степени, чтобы полагать, что свойства исходного приложения присутствуют в последующем приложении.
Уверенность в переносе свойств из исходного приложения в последующее не имеет никакого отношения к функциональности ни того, ни другого приложения. Доверие к функциональности вытекает из других механизмов, и настоящий стандарт не имеет отношения к этому доверию.
8.2 Установление уверенности
Уверенность в ожидаемом уровне доверия возрастает благодаря двум основным механизмам: доказательству и истории. Для прогнозов доказательством является обоснование безопасности приложения, а историей - последовательность версий приложения вместе с утверждениями и опытом, связанными с этой последовательностью.
Уверенность - это отличительная черта потребителя прогноза. Его опыт работы с последовательностью приложений повышает или понижает его уверенность в определенном ожидаемом уровне доверия для конкретного приложения. Последовательность приложения, требующая постоянного обновления из-за проблем с обновлением, снижает уверенность потребителей в том, что присутствует определенный ожидаемый уровень доверия.
Факты свидетельствуют о том, что обретение уверенности возникает непосредственно в результате содержательных действий по прогнозированию, а также косвенно в результате других действий - таких как регрессионное тестирование, которое часто выполняют прикладные группы при верификации или валидации того, что возможности программных средств не скомпрометированы какими-либо изменениями.
9 Прогнозное обоснование безопасности приложения
9.1 Связь с мерами обеспечения безопасности приложений
Прогнозное обоснование безопасности приложения напрямую связано с МОБП, принадлежащими НСП. Привязка может быть прямой и заключаться в том, что хранилище для МОБП также содержит ПОБП, или связь может быть установлена через ссылки, которые указывают место хранения ПОБП.
9.2 Компоненты
Независимо от того, как проектная группа связывает ПОБП с МОБП, в ПОБП представляется следующая информация:
a) идентификаторы:
1) идентификатор МОБП, связанный с этим прогнозом;
2) идентификатор исходного приложения;
3) идентификатор последующего приложения;
4) идентификаторы в этом контексте могут быть текстовыми строками, уникальными идентификаторами объектов или другими структурированными идентификаторами;
b) действующие субъекты:
1) инициатор прогнозирования - обычно это проектная группа. Другие заинтересованные стороны также могут инициировать прогнозирование, но только проектная группа способна заменить процедуры МОБП на модель с использованием ПОБП;
2) владелец приложения - физическое лицо, ответственное за безопасность приложения данного проекта и утверждающее предлагаемый прогноз для конкретного МОБП;
3) потребитель прогноза - сторона, приобретающая приложение, другие подразделения внутри организации, использующие приложение или продукцию, включающую приложение в качестве компонента. Потребитель прогноза рассматривает прогнозное обоснование при принятии решения о риске, чтобы определить, является ли обновленное приложение приемлемым для использования;
c) обстоятельства прогнозирования:
1) основные причины для создания последующего приложения;
2) при каких обстоятельствах прогнозы скорее всего окажутся верными;
3) при каких обстоятельствах прогнозы могут оказаться ложными;
d) само прогнозное обоснование:
1) анализ рисков для выявленных МОБП на предмет того, почему указанные в МОБП виды действий не являются необходимыми для последующего применения;
2) уверенность в прогнозе:
i) насколько инициатор прогнозирования уверен в том, что прогноз верный;
ii) проектная группа может повысить уверенность в прогнозе, получив дополнительные доказательства. Такие доказательства могут быть получены в результате верификации на основе таких методов, как регрессионное тестирование и повторное тестирование. См. ИСО/МЭК/ИИЭР 29119-1 [1] для получения подробной информации о методах тестирования;
3) утверждение о том, что изменение в последующем приложении не является существенным и нет необходимости выполнять действия с МОБП;
e) результаты процедур МОБП для исходного приложения:
1) верификационные измерения для оценки риска или ПОБП, связанные с МОБП;
2) если МОБП отсутствуют в исходном приложении, то прогнозирование недопустимо;
f) вспомогательные критерии для прогнозирования, включая обоснование от владельца приложения относительно того, почему анализ рисков поддерживает исключение процедур МОБП для приложения.
9.3 Формат
9.3.1 Идентификаторы, действующие субъекты, результаты действий с МОБП
Форматы описания идентификаторов, действующих субъектов и предыдущих результатов процедур МОБП являются присущими конкретной нормативной структуре организации. Группа НСО определяет, что является достаточным для их организации, и устанавливает необходимые форматы.
9.3.2 Обоснование
Обоснование - это утверждения в свободной форме представления, которые содержат анализ, обстоятельства и формируют уверенность. Вполне вероятно, что анализ повторяется применительно к нескольким МОБП в НСП. Это приемлемо, так как обстоятельства не меняются для отдельного МОБП внутри НСП. Цель отдельных положений обоснования относительно МОБП состоит в том, чтобы объединить их в отчет об ожидаемом уровне доверия. Требования к тому, чтобы отдельные утверждения относительно МОБП повторяли уже скомплектованную информацию, не предъявляются. В обосновании может приводиться ссылка на то место, где один и тот же текст является общедоступным.
9.3.3 Дублирование информации
Отдельное ПОБП предоставляет информацию, которая помогает сформировать отчет об ожидаемом уровне доверия. Может оказаться, что в отчете идентификаторы, действующие субъекты и обстоятельства прогнозирования для каждого ПОБП являются одними и теми же. Предполагается, что в отдельном ПОБП делается ссылка на общую информацию в отчете об ожидаемом уровне доверия без ее дублирования в ПОБП.
9.3.4 Случаи доверия
Поскольку отчет об ожидаемом уровне доверия содержит утверждения, сделанные специалистами по приложению, предпочтительно использование формата, помогающего количественно оценить эти утверждения. В приложении В приводится пример использования случаев доверия из ИСО/МЭК 15026-2 [7].
9.4 Согласование с группой нормативной структуры организации
Группа НСО устанавливает руководство по прогнозированию и использованию ПОБП для каждого из МОБП. У группы НСО есть три варианта:
a) не осуществлять никаких прогнозов:
1) группа НСО определяет, что процедуры МОБП имеют решающее значение для всех приложений. Ни одна НСП не может выбрать использование ПОБП при формировании этих МОБП;
2) случаи полного отказа могут включать использование статического анализа для всего измененного кода или резервного копирования кода приложения;
b) осуществлять прогнозы с условиями:
1) условия, которые утверждает группа НСО, будут характерны для самой НСО. Условия могут быть определены как в положительной форме, когда можно спрогнозировать данную гипотезу при конкретном условии, так и в отрицательной форме, когда ее нельзя спрогнозировать при конкретном условии. Определение существования условий является функцией НСП;
2) примерами этих условий могут быть следующие:
i) после 5 версий приложения с прогнозом группа должна выполнить действия с МОБП;
ii) группы реагирования на инциденты всегда могут спрогнозировать эти МОБП;
iii) если эта функция НСП изменяется, выполнение прогнозирования невозможно;
c) действовать без ограничений: группа НСО определяет, что нет необходимости ограничивать прогнозы для МОБП, и НСП всегда может использовать прогнозирование для МОБП.
9.5 Использование схемы "Ответственность, подотчетность, консультирование, информирование" для описания действий, ролей и обязанностей
Настоящий стандарт использует коды схемы "Ответственность, подотчетность, консультирование, информирование" (ОПКИ) для обозначения ролей и обязанностей при выполнении действий в процессах. Такие коды определяют субъектов действий - ответственных, подотчетных, консультирующих или информирующих. В таблице 2 перечислены коды, используемые для описания роли ответственного лица при осуществлении действий.
Таблица 2 - Коды, используемые для обозначений в схеме ОПКИ
|
|
Код | Обязанности |
О | Ответственность за осуществление действий |
П | Подотчетность за осуществление действий |
К | Консультации в ходе осуществления действий |
И | Информирование об осуществлении действий |
10 Аудит прогнозного обоснования безопасности приложений
10.1 Связь с проведением аудита
Аудит является объектом ИСО/МЭК 27034-1:2011, пункт 7.3.6.
Цель аудита - удостовериться в том, что целевой уровень доверия соответствует фактическому уровню доверия. Аудитор анализирует данные оценок верификации, предоставленные для МОБП, и соответствующие специальные требования, предоставленные проектной группой для фактического уровня доверия.
10.2 Аудит фактического уровня доверия
Действия аудиторов в отношении действий с МОБП, отражающих фактический уровень доверия, неизменны. Аудитор проверяет данные оценок верификации и, если они соответствуют специальным требованиям проектной группы, констатирует достижение фактического уровня доверия.
10.3 Аудит ожидаемого уровня доверия
Аудитор верифицирует сам факт того, что проектная группа предоставляет ПОБП для прогнозируемых МОБП. Если ПОБП отвечает предъявляемым требованиям, аудитор может констатировать, что проектная группа достигла ожидаемого уровня доверия.
С точки зрения аудитора, его действия одинаковы как для данных оценок верификации действий с МОБП, так и для ПОБП. Аудитор проверяет наличие данных и их соответствие требованиям руководств НСО.
10.4 Качество прогнозного обоснования безопасности приложения
Аудитор не изучает качество ПОБП, которое проявляется при валидации. Аудитор подтверждает, что форма и содержание ПОБП имеют место в реальности и соответствуют методикам, определенным группой НСО.
11 Верификация прогнозного обоснования безопасности приложения
11.1 Валидация
Аудиторской группе следует осуществить валидацию ПОБП для определения ожидаемого уровня доверия путем исследования качества каждого из его компонентов (как указано в 9.2) и проверки их соответствия руководству, используемому группой НСО (см. 9.4). Аудиторской группе следует осуществлять консультации с группой НСО для получения необходимой экспертизы по техническим вопросам.
11.2 Верификация
Верификация является базовым понятием ИСО/МЭК 27034-1. Аудиторская группа при выполнении шага 5 (см. ИСО/МЭК 27034-1:2011, пункт 7.3.6) может повторно выполнить некоторые действия с МОБП. Аудиторская группа может выбрать любое количество МОБП для повторного выполнения - от полного набора мер до отдельных выборок из них (например, статистических, основанных на рисках и т.д.). Методы работы аудитора неизменны как при работе с прогнозами, так и со специальными ПОБП. Аудиторская группа может выбрать отдельный набор мер, а затем выполнить действия с использованием МОБП.
Использование понятия ожидаемого уровня доверия не требует от аудиторской группы применения какого-либо иного механизма при установлении статистической выборки МОБП для проведения аудита. Если аудиторская группа использует какой-то другой механизм для проведения выборочной верификации фактического уровня доверия по сравнению с механизмом для ожидаемого уровня доверия, она должна документировать различия между этими двумя механизмами выбора.
11.3 Ожидаемые результаты
Прогнозирование обусловлено тем, что отсутствует необходимость выполнять реальные действия с МОБП, поскольку изменение в последующем приложении не является существенным, и, следовательно, реальные процедуры МОБП не добавят чего-либо к ожидаемым свойствам безопасности приложения. Если аудиторская группа подбирает какой-нибудь экземпляр МОБП для демонстрации правильности действий, она выполняет действия строго так, как того требует этот экземпляр МОБП. Ожидаемый при этом результат заключается в том, что группа может получать правильные верификационные измерения так же, как если бы проектная группа выполняла действия с МОБП.
11.4 Пропущенные положения
11.4.1 Невозможность получения верификационных измерений
Может оказаться, что возможность повторного выполнения процедур МОБП отсутствует. К примеру, возможны редкие случаи, при которых обстоятельства и инфраструктура, необходимые для выполнения действий с МОБП, больше не доступны. Если такие условия возникают, аудиторская группа либо принимает ПОБП, либо находит другой способ получения верификационных измерений.
11.4.2 Пример
Например, рассматриваемый МОБП требует моделирования определенного набора операций, а верификационное измерение является результатом моделирования. Предположим, что моделирование выполнялось примерно за год до появления аппаратного обеспечения и занимало более трех недель. Проектная группа не выполняет численное моделирование. Аудиторская группа имеет прогноз (полученный с использованием проведенного ранее моделирования), но не может повторить моделирование, потому что:
a) среда моделирования больше не поддерживает последующее приложение. Операции или тестовые наборы не являются актуальными в среде моделирования;
b) недостаточно времени, необходимого для запуска среды моделирования, так как:
1) применимая модель полностью занята в другом проекте;
2) аудитор и проектная группа не могут ждать три недели для получения верификационных измерений.
В этом случае у аудиторской группы есть выбор: принять ПОБП или искать другие способы получения верификационных измерений. Принятие ПОБП может оказаться целесообразным. Но снова рассмотрим содержание примера: тесты выполняются на модели. В проектах, выполняющих моделирование, обычно связанное действие выполняет те же тесты на результирующем аппаратном обеспечении. Аудиторская группа может пропустить моделирование и выполнить соответствующие тесты на реальном аппаратном обеспечении. Несмотря на то, что тестирование в процессе моделирования не осуществляется, демонстрация того, что последующее приложение пройдет проверку аудита, возможна.
12 Осуществление прогнозного обоснования безопасности приложения
12.1 Основы прогнозирования
Шаги, определенные в 12.2, являются основными в прогнозировании. Их осуществление обеспечивает создание ожидаемого уровня доверия, который соответствует предыдущему фактическому уровню доверия безопасности приложения, а затем создание ПОБП для одного или нескольких МОБП, заменяя их выполнение прогнозированием.
12.2 Шаги по осуществлению прогнозного обоснования безопасности приложения
12.2.1 Общие положения:
a) группа НСО устанавливает методики:
1) по каждой мере из библиотеки МОБП организации группа НСО определяет обстоятельства, при которых прогнозы являются приемлемыми и неприемлемыми. Группа НСО сохраняет эти методики в библиотеке МОБП как часть определенных МОБП;
2) в таблице 3 определены обязанности по осуществлению ПОБП с использованием кодов ОПКИ;
b) проектная группа выполняет анализ рисков для последующего приложения (в соответствии с ИСО/МЭК 27034-1, шаг 2) и по мере необходимости обновляет целевой уровень доверия приложения;
c) проектная группа выбирает множество МОБП для НСП. Выбор МОБП следует за соответствующим процессом, определенным в ИСО/МЭК 27034-1;
d) проектная группа проводит дальнейший анализ рисков для определения существенных изменений;
e) проектная группа уточняет целевой уровень доверия на основе анализа существенных изменений и создает ожидаемый уровень доверия;
f) владелец приложения утверждает целесообразность прогнозирования с использованием ПОБП, а также ожидаемый уровень доверия;
g) проектная группа разрабатывает последующее приложение, связанное с НСП, и выполняет действия, связанные с каждой мерой из НСП, включая выполнение верификационных измерений или получение МОБП;
h) аудиторская группа проверяет приложение на наличие верификационных измерений или ПОБП для каждой меры из НСП;
i) если все верификационные измерения МОБП были успешно выполнены и все ПОБП были приняты, то для последующих приложений ожидаемый уровень доверия считается сформированным;
j) проектная группа формирует отчет об ожидаемом уровне доверия.
12.2.2 Обязанности для действующих субъектов
В таблице 3 представлены коды ОПКИ для процесса "осуществления ПОБП".
Таблица 3 - Коды ОПКИ для процесса "осуществления ПОБП"
|
|
|
|
|
|
Действия по реализации | Группа НСО | Владелец приложения | Проектная группа | Группа по верификации | Аудиторская группа |
a) Установка методик | П/О | И | И |
| И |
b) Анализ рисков |
| П | О | И | И |
с) Выбор НСП | И | П | О | К | И |
d) Внесение или определение существенных изменений |
| П | О | К | И |
e) Создание ожидаемого уровня доверия | И | П | О | К | И |
f) Утверждение ожидаемого уровня доверия | И | П | О | К | И |
g) Разработка приложения |
| П | О | И | И |
h) Верификация МОБП |
| П | К | О | И |
i) Верификация фактического уровня доверия и ожидаемого уровня доверия |
| П | К | К | О |
j) Создание отчета по ожидаемому уровню доверия | И | П | О | К | К |
12.3 Обратная связь с нормативной структурой организации
Проектная группа может столкнуться с проблемами, связанными с определением конкретных МОБП, особенно в связи с методиками относительно того, когда допустимо использовать прогнозирование. Как и во всех вопросах определения МОБП, проектная группа находится на связи с группой НСО, пытаясь уточнить или изменить МОБП (ИСО/МЭК 27034-1:2011, пункт 8.1.3.2, перечисление f). Относительно ПОБП процесс тот же самый. Поскольку методики ПОБП являются частью МОБП, обратная связь с группой НСО использует тот же механизм.
Вполне вероятно, что проектные группы захотят получить быстрый ответ от группы НСО, особенно когда это касается реакции на уязвимости приложения. В этих случаях механизм обратной связи НСП с НСО должен предусматривать быстрое решение проблем.
13 Отчет об ожидаемом уровне доверия
13.1 Цель
Основной целью отчета об ожидаемом уровне доверия является предоставление стороне, приобретающей последующее приложение, возможности принимать решения по рискам на основе анализа рисков проектной группы. Содержание отчета представляет аргументированные данные о том, что анализ рисков проектной группы выполнен с обоснованной точностью, а усовершенствование нецелесообразно из-за возможных отклонений при прогнозировании.
13.2 Компоненты
Отчет об ожидаемом уровне доверия должен содержать следующее:
a) идентификаторы:
1) идентификатор исходного приложения;
2) идентификатор последующего приложения;
3) идентификаторы приложений должны быть уникальными, чтобы не возникало двусмысленности относительно того, к какой версии приложения относится ожидаемый уровень доверия в отчете. Управление версиями приложений - это форма управления активами, ИСО/ МЭК 19770-5 [3] предоставляет руководство по управлению активами в области информационных технологий;
b) действующие субъекты:
1) инициатор прогнозирования - обычно это проектная группа, но другие заинтересованные стороны также могут инициировать прогнозирование;
2) владелец приложения - определяет заинтересованную сторону, утверждающую прогноз;
c) обстоятельства прогнозирования - это основные причины для создания последующего приложения;
d) уровни доверия:
1) фактический уровень доверия для исходного приложения;
2) ожидаемый уровень доверия для исходного приложения (если используется);
3) фактический уровень доверия для последующего приложения;
4) ожидаемый уровень доверия для последующего приложения;
e) прогнозируемые МОБП:
1) перечень МОБП, относительно которого осуществляется прогнозирование. В то время как можно создать заново такой перечень, сравнивая ожидаемый уровень доверия с фактическим уровнем доверия, начальный перечень делает его более понятным для потребителей прогноза;
2) для каждой меры из прогнозируемых МОБП - прогнозное обоснование безопасности приложения;
f) обоснование - обстоятельства и набор прогнозируемых МОБП с указанием того, почему эти МОБП соответствуют ожидаемым уровням доверия.
13.3 Формат
Отчет представляет собой текст в свободной форме. Потребитель прогноза будет читать и принимать решения о риске на основе изложенной информации. Какая-либо необходимость в машиночитаемом форматировании отчета об ожидаемом уровне доверия отсутствует.
13.4 История, предположения и социальные аспекты
Компоненты отчета содержат большую часть истории между исходными и последующими приложениями. Когда потребитель прогноза принимает решение о риске, эта дополнительная информация может оказаться важной для принятия решения. Трудно определить, какая дополнительная информация необходима. Нижеследующие пункты представляют собой лишь примеры, а индивидуальные потребители прогноза имеют свои специфические требования:
a) история:
1) вполне вероятно, что исходные и последующие приложения не являются версией 1 и версией 1.1, может существовать более обширная история версий. Доверие и опыт каждой версии влияют на решение потребителей о риске;
2) отчет об ожидаемом уровне доверия может содержать информацию относительно всех предыдущих версий приложения;
b) предположения:
1) инициатор прогнозирования делает предположения насчет последующего применения приложения относительно условий, используемой платформы, цепочек поставок и многих других факторов. Использование приложения вне этих предположений может повлиять на решение потребителей о риске;
2) отчет об ожидаемом уровне доверия может содержать информацию относительно предположений, которые делает инициатор прогнозирования;
c) социальная история:
1) может быть большое количество комментариев относительно приложения из источников, не связанных с разработчиком приложения. Эти комментарии могут быть положительными и отрицательными, объективными или субъективными. Потребители прогнозов могут использовать эту информацию при принятии решения о риске;
2) прикрепление ссылок или выдержек из обзоров относительно версий приложения может помочь потребителю прогноза. Именно потребитель прогноза несет ответственность за определение достоверности и степени предвзятости при использовании информации социальной истории относительно последующих приложений при принятии решения о риске.
Приложение А
(справочное)
Вариант обеспечения ожидаемого уровня доверия
А.1 Рекомендация по формату
Поскольку в отчете об ожидаемом уровне доверия утверждается, что ожидаемый уровень доверия для последующего приложения имеет отношение к фактическому и/или ожидаемому уровню доверия в исходном приложении, рекомендуется использовать ИСО/МЭК 15026-3 [7] для документирования требования.
А.2 Требование к прогнозу
А.2.1 Контекст
Требование инициатора прогнозирования заключается в том, чтобы последующее приложение имело похожие свойства безопасности, что и исходное приложение.
Последующее приложение - это последующая версия исходного приложения (т е. оригинальная версия 1.0, а последующая версия 1.1). Требование заключается в том, чтобы свойства исходного приложения по безопасности присутствовали в последующем приложении.
А.2.2 Соответствующие последствия
Следствием взаимосвязи между исходным и последующим приложениями является то, что приобретающие стороны могут проводить оценки соответствующих рисков на основе уровней доверия.
А.2.3 Свойство и ограничения на его значения
Основой для прогнозирования является то, что исходное приложение в какой-то момент в цепи версий выполняло действия с МОБП. Если ни одна из предыдущих версий приложения не выполняла действия с МОБП, то прогнозирование невозможно - это ограничение.
А.2.4 Условия и ограничения по применимости
Проектная группа при выполнении оценки риска последующего приложения создает определение существенности изменения. После утверждения владельцем приложения это определение позволяет осуществлять ПОБП для тех МОБП, где изменение не является существенным.
При утверждении в соответствующем обосновании должно быть указано, что изменения не являются существенными и прогнозы являются приемлемыми.
А.2.5 Продолжительность
С продолжительностью прогнозирования не возникает проблем, если исходное приложение уже выполняло действия с МОБП, а для последующего приложения делается прогноз. Проблемы с продолжительностью возникают, когда и исходное приложение использовало прогноз, и последующее приложение использует прогноз. Насколько существенно может измениться прогноз? Ответ исходит от группы НСО и является частью методик, установленных для прогнозов с использованием НСО.
А.2.6 Ограничения, связанные с неопределенностью
Несмотря на то, что для приложений используются одни и те же меры обеспечения безопасности, незначительные изменения в архитектуре, проекте или реализации могут привести к появлению новых и непредвиденных уязвимостей. Это верно и для исходного приложения. Нет никаких гарантий, что следование процессу для исходного приложения не привело к непредвиденным уязвимостям. Процесс обеспечивает доверие, а не гарантию того, что разработчик следовал определенному процессу разработки и что процесс не привел к уязвимостям. Одним из примеров подобного рода доверия без гарантий является процесс устранения недостатков в рамках общих критериев.
А.2.7 Аргументация
Существует степень уверенности в том, что ожидаемый уровень доверия для последующего приложения соответствует фактическому или ожидаемому уровню доверия для исходного приложения вследствие применения проектной группой мер обеспечения безопасности и анализа рисков.
Последующее приложение достигло верифицированного фактического уровня доверия, используя те же элементы управления, которые применялись для исходного приложения. Прогнозы о том, что МОБП, перечисленные в ожидаемом уровне доверия, также применимы, обеспечили аргументацию для утверждения о соответствии требованиям как исходного, так и последующего приложений.
А.2.8 Обоснование
Организационные меры обеспечения безопасности, создавшие исходное приложение, при их использовании для создания последующего приложения приводят к удовлетворению тех же требований безопасности для последующего приложения, что были использованы для исходного приложения. По существу, поддерживая один и тот же процесс, архитектуру, проект и реализацию, поставщик может распространить обоснования по требованиям безопасности для исходного приложения на последующее приложение.
А.2.9 Доказательства
Доказательства включают в себя компоненты, перечисленные в 13.2 настоящего стандарта.
А.2.10 Объективные критерии
Объективность связана с анализом рисков, который показывает, что изменения в последующем приложении не являются существенными.
Приложение В
(справочное)
Сравнение мер обеспечения безопасности приложений с прогнозным обоснованием безопасности приложений
В приложении приводится сравнение МОБП с ПОБП. В то время как МОБП полностью содержат обоснование безопасности приложения, есть некоторые различия. В таблице В.1 подчеркнуты сходства и различия.
Таблица В.1 - Сравнение МОБП с ПОБП
|
|
|
| Прогнозируемые меры обеспечения безопасности приложений (МОБП) | Прогнозное обоснование безопасности приложений (ПОБП) |
Определение | МОБП - это меры по обеспечению безопасности и измерениям при верификации, используемые для снижения риска в области безопасности приложений до утвержденного допустимого уровня, способные к демонстрации своих возможностей | ПОБП - это обоснование, используемое для оправдания того, почему проектная группа приложения решила не выполнять снова верификационные измерения конкретных МОБП.
Примечание - ПОБП может использоваться только для МОБП, действия с которыми для обеспечения безопасности уже выполнялись
|
Цель | a) Учесть требования по безопасности для приложения.
b) Обеспечить адекватное снижение неприемлемых рисков в области безопасности приложений.
c) Предоставить поддающиеся верификации доказательства в поддержку утверждения о том, что приложение является безопасным | a) Снизить стоимость реализации и верификации безопасности для приложений.
b) Ускорить реализацию безопасности для приложений.
c) Предоставить обоснование в поддержку утверждения о том, что последующая версия приложения ожидается безопасной |
Процессы разработки | Способ построения МОБП (описано в ИСО/МЭК 27034-2).
Этот процесс, являясь частью процесса управления НСО:
a) определяет процесс обеспечения безопасности для приложения/компонента, реализуемого в МОБП, предоставляя:
- обоснование, подтверждающее, что действия, предусмотренные этими МОБП, осуществимы, обеспечивают получение конкретных результатов для удовлетворения конкретного требования и действительно снижают связанные с этим риски;
- обоснование того, что результаты действий по обеспечению безопасности поддаются верификации, когда и каким образом они должны быть измерены, верифицированы и проведено их сравнение с ожидаемыми результатами; | Процесс отчетности ПОБП (описано в настоящем стандарте):
a) определяет основание для оправдания того, почему не являются необходимыми реальные процедуры МОБП (т.е. не нужно ждать их реализации или верификации) и эти действия заменяются моделью с использованием данного ПОБП. Обоснование того, почему конкретные МОБП не нуждаются в реализации и верификации в соответствии с тремя принципами, представленными в настоящем стандарте;
b) обеспечивает утверждение этого обоснования в качестве допустимого способа обхода реализации/верификации МОБП и поддержки "прогнозного уровня доверия", эквивалентного целевому уровню доверия, поскольку организация считает, что:
- реализация этого ПОБП не влияет на требования к |
| b) обеспечивает принятие этого обоснования;
c) обеспечивает назначение этим МОБП одного или нескольких уровней доверия в библиотеке МОБП организации, определяя владельца и даты, такие, например, когда эти МОБП должны быть распространены для обучения, реализации и соблюдения сроков действия.
Примечание - Необходимо обратить внимание на то, что знания и критерии [в том числе ожидаемые результаты, подтверждающие утверждение, что в МОБП правильно учтены конкретные требования безопасности приложений (почему правильно) и адекватно снижены риски, связанные с безопасностью приложений, до допустимого уровня] непосредственно включены в этот раздел МОБП экспертами по предметной области, которые разрабатывают, проводят валидацию и верификацию этого обоснования/стратегии до создания самих МОБП
| безопасности приложений;
- риск в области безопасности приложений все еще на допустимом уровне.
Примечание - Знания и критерии, поддерживающие утверждение, что ПОБП может заместить МОБП, напрямую встроены в этот раздел ПОБП экспертами по предметной области (которые разрабатывают, проводят валидацию и верификацию этого обоснования/стратегии в течение разработки ПОБП). |
Действия по обеспечению безопасности для снижения рисков | а) Определяется процесс/компонент безопасности приложения, реализованный в данных МОБП, с указанием:
- какие действия выполняются;
- как выполняются эти действия (например, лучшие практики, библиотеки, инструментарии, параметры), включая ожидаемые результаты;
- где эти действия выполняются (например, в процессе, у действующего субъекта, внутри компонента, путем разработки нового компонента, такого как мониторинг);
- кто выполняет эти виды действий (например, действующий субъект с указанием его обязанностей и требуемой квалификации, если это необходимо, для каждого вида действий);
- когда эти действия выполняются (до, во время или после определенного множества каких-то действий);
- сколько стоит выполнение этих работ.
Примечания
1 Знания и критерии для правильной реализации действия безопасности непосредственно включены в этот раздел МОБП по предметной области (которые разрабатывают, проводят валидацию и верификацию этого перед развертыванием МОБП).
2 Действия по обеспечению безопасности МОБП можно рассматривать как шаблон реализации приложений для удовлетворения конкретных требований безопасности приложений и адекватного снижения рисков в области безопасности приложений до ожидаемого/утвержденного допустимого уровня
| Отсутствуют.
Примечания
1 Исходные МОБП, замененные с использованием этого ПОБП, не нуждаются в повторной реализации или повторной верификации.
2 Воздействие заключается в том, что риски безопасности приложений, рассматриваемые для МОБП, замененных моделью с использованием ПОБП, возможно, окажутся неснижаемыми до ожидаемого уровня |
Действия, связанные с верификационными измерениями для снижения рисков | a) Определяется процесс верификационных измерений для подтверждения правильности выполнения действий по обеспечению безопасности с указанием:
- какие действия выполняются;
- как осуществляются эти действия, включая ожидаемые результаты;
- где эти действия выполняются;
- кто выполняет эти виды действий (например, действующий субъект с указанием его обязанностей и требуемой квалификации, если это необходимо, для каждого вида действий);
- когда эти действия выполняются (до, во время или после определенного множества каких-то действий);
- сколько стоит выполнение этих работ.
b) Проводится валидация определенных МОБП и тестирование/верификация их реализации, а также назначенный МОБП уровень доверия.
c) Получается окончательное утверждение от группы НСО на интеграцию этих МОБП в библиотеку МОБП для обучения и реализации. | Отсутствует.
Примечания
1 Исходное действие по верификационным измерениям, замененным моделью с использованием этого ПОБП, выполнять не требуется.
2 Воздействие основано на применении рисков в области безопасности приложений от МОБП, замененных моделью с использованием ПОБП (возможно, риски окажутся неснижаемыми до ожидаемого уровня) |
| Примечания
1 Знания и критерии для правильной верификации действия безопасности непосредственно включены в этот раздел МОБП экспертами в данной сфере, которые разрабатывают, проводят его валидацию и верификацию перед развертыванием МОБП.
2 Действия по верификации измерений МОБП можно рассматривать как шаблон проектирования верификации безопасности приложения для конкретных МОБП
|
|
Процесс верификации | Процесс реализации и верификации МОБП описан в ИСО/МЭК 27034-3.
Реализация и верификация МОБП выполняются в процессе управления НСП и включают:
a) действия по обеспечению безопасности, описанные в МОБП, которые осуществляются в соответствии с их описанием (что, как, где, кто, когда);
b) действия по верификационным измерениям, описанные в МОБП, которые осуществляются в соответствии с их описанием (что, как, где, кто, когда) с учетом критериев и результатов, полученных в результате действий по обеспечению безопасности | Процесс осуществления ПОБП описан в настоящем стандарте. Осуществление ПОБП означает написание его в соответствии с правилами ПОБП и методиками, установленными группой НСО:
a) специальное обоснование готовится, чтобы поддержать предложения о том, что процедуры МОБП не должны выполняться снова для текущей версии приложения;
b) это обоснование (ПОБП) предоставляется аудитору или владельцу приложения для оправдания того, почему не являются необходимыми реальные действия с МОБП |
Процесс аудита | Процесс аудита МОБП описан в ИСО/МЭК 27034-4. Этот процесс может быть выполнен в любое время при выполнении процесса менеджмента безопасности приложений:
a) определяются критерии и параметры аудита безопасности приложений;
b) аудит проводится по запросу в соответствии с принятыми критериями:
- аудитор проверяет, существуют ли соответствующие результаты, полученные в результате реализации/верификации МОБП, для проверяемого приложения;
- аудитор повторно выполняет некоторые верификационные измерения МОБП (например, 10% измерений, выбранных случайным образом) и сравнивает результаты с результатами, зарегистрированными организацией, чтобы обнаружить подделку результатов | Способ аудита ПОБП описан в настоящем стандарте. Этот процесс может быть выполнен в любое время при выполнении процесса менеджмента безопасности приложений:
a) определяются/предоставляются критерии аудита безопасности приложений;
b) аудит проводится по запросу в соответствии с принятыми критериями:
- аудитор проверяет, существуют ли соответствующие результаты, полученные в результате реализации/верификации МОБП, для проверяемого приложения;
- аудитор проверяет ПОБП, представленное вместо результатов, полученных в ходе реализации/верификации МОБП, в соответствии с правилами ПОБП и методиками, установленными группой НСО;
- аудитор повторно выполняет некоторые верификационные измерения МОБП (например, 10% измерений, выбранных случайным образом) и сравнивает результаты с результатами, зарегистрированными организацией, чтобы обнаружить подделку результатов |
Приложение ДА
(справочное)
Сведения о соответствии ссылочных международных стандартов национальным и межгосударственным стандартам
Таблица ДА.1
|
|
|
Обозначение ссылочного международного стандарта | Степень соответствия | Обозначение и наименование соответствующего национального, межгосударственного стандарта |
ISO/IEC 27000 | IDT | "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Общий обзор и терминология" |
ISO/IEC 27034-1 | IDT | "Информационная технология. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 1. Обзор и общие понятия" |
Примечание - В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов:
- IDT - идентичные стандарты. | ||
Библиография
|
|
[1] | ISO/IEC/IEEE 29119-1, Software and systems engineering - Software testing - Part 1: Concepts and definitions |
[2] | ISO/IEC 90003, Software engineering - Guidelines for the application of ISO 9001:2008 to computer software |
[3] | ISO/IEC 19770-5, Information technology - IT asset management - Part 5: Over-view and vocabulary |
[4] | ISO/IEC 19770-2, Information technology - Software asset management - Part 2: Software identification tag |
[5] | ISO/IEC 20009-1, Information technology - Security techniques - Anonymous entity authentication - Part 1: General |
[6] | ISO/IEC 15408 (all parts), Information technology - Security techniques - Evaluation criteria for IT security |
[7] | ISO/IEC 15026 (all parts), System and software engineering - Systems and soft-ware assurance |
[8] | ISO/IEC 27000, Information technology - Security techniques - Information security management systems - Overview and vocabulary |
|
|
УДК 006.34:004.056:004.056.5:004.056.53:006.354 | ОКС 35.020 |
| |
Ключевые слова: информационные технологии, безопасность приложения, доверие, риск, уверенность, управление | |