LINEBURG


<< Пред. стр.

страница 12
(всего 26)

ОГЛАВЛЕНИЕ

След. стр. >>


7.3 Оценка безопасности разработки
7.3.1 Подвид деятельности ALC_DVS.1
7.3.1.1 Цели
Цель данного подвида деятельности – сделать заключение, являются ли меры и средства
476

контроля безопасности в среде разработки достаточными для обеспечения
конфиденциальности и целостности проекта и реализации ОО. Это необходимо для
обеспечения того, чтобы безопасная эксплуатация ОО не была скомпрометирована.
7.3.1.2 Исходные данные
Свидетельствами оценки для этого подвида деятельности являются:
477

а) ЗБ;

78
б) документация по безопасности разработки.
Кроме того, оценщику может понадобиться исследование других поставок, чтобы сделать
478

заключение о том, что меры и средства контроля безопасности полностью определены и их
применяют. В частности оценщику может понадобиться исследование документации
разработчика по УК (исходные данные подвидов деятельности ACM_CAP.4 и
ACM_SCP.2). Также требуется свидетельство, что процедуры применяются.
7.3.1.3 Действия оценщика
Этот подвид деятельности включает два элемента действий оценщика из части 3 ОК:
479

а) ALC_DVS.1.1E;
б) ALC_DVS.1.2E.
7.3.1.3.1 Действие ALC_DVS.1.1E
ALC_DVS.1.1C
Оценщик должен исследовать документацию по безопасности разработки,
ALC_DVS.1-1
чтобы сделать заключение, содержит ли она подробное описание всех
используемых в среде разработки мер безопасности, которые необходимы для
защиты конфиденциальности и целостности проекта и реализации ОО.
Оценщик определяет, какая информация из ЗБ нужна в первую очередь при вынесении
480

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

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

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


79
В документации по безопасности разработки должны быть указаны места разработки и
483

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

безопасности, которые могут применяться к различным аспектам разработки с точки зрения
их выполнения, требуемых исходных данных и выходных результатов. Например,
различные процедуры могут быть применимы к разработке различных частей ОО или к
различным стадиям процесса разработки.
Оценщик должен исследовать политики обеспечения конфиденциальности и
ALC_DVS.1-2
целостности при разработке, чтобы сделать заключение о достаточности
применявшихся мер безопасности.
Они включают политики управления следующим:
485

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

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

целостности ОО, и оценщику следует избегать частичного перекрытия с шагами
оценивания, проводимыми в рамках подвида деятельности ACM_CAP. Например,
документация УК может описывать процедуры безопасности, необходимые для контроля
ролей или лиц, которым следует предоставить доступ к среде разработки, и которые могут
модифицировать ОО.
Тогда как требования ACM_CAP зафиксированы, требования для ALC_DVS,
488

предписывающие только необходимые меры, зависят от типа ОО и от информации, которая
может быть представлена в разделе ЗБ "Среда безопасности". Например, ЗБ может
идентифицировать политику безопасности организации, в которой требуется наличие
формы допуска у персонала разработчиков ОО. Тогда оценщику в ходе выполнения
данного подвида деятельности необходимо сделать заключение, применялась ли такая
политика.
ALC_DVS.1.2C
Оценщик должен проверить документацию по безопасности разработки, чтобы
ALC_DVS.1-3
сделать заключение, формируется ли документальное свидетельство в результате
применения процедур.


80
При наличии документального свидетельства оценщик просматривает его, чтобы
489

удостовериться в его соответствии процедурам. Примерами подготовленных свидетельств
могут служить журналы регистрации входа и журналы аудита. Оценщик может
остановиться на выборочной проверке свидетельства.
Руководство по выборке см. в подразделе 10.2.
490

7.3.1.3.2Действие ALC_DVS.1.2E
Оценщик должен исследовать документацию по безопасности разработки и
ALC_DVS.1-4
связанные с ней свидетельства, чтобы сделать заключение, применяются ли меры
безопасности.
На этом шаге оценивания от оценщика требуется сделать заключение, применяются ли
491

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

применяемых мерах. Решение отказаться от такого посещения следует принимать после
консультации с органом по сертификации.
Руководство по посещению объектов см. в подразделе 10.5.
493


Оценка устранения недостатков
7.4
7.4.1 Замечания по применению
Требования семейства ALC_FLR не используются в ОУД, определенных в ОК. Поскольку в
494

ПЗ и ЗБ не обязательно ограничиваться требованиями доверия из ОУД, определенных в
ОК, то возможно привлечение и других компонентов доверия, в том числе из семейства
ALC_FLR. Это означает, что любой из компонентов ALC_FLR может использоваться как
часть ПЗ/ЗБ в сочетании с любым из пакетов доверия из ОК.
Выражение ОО означает объект оценки, но при этом обладает тем свойством, что теряет
495

смысл, как только достигнуты цели оценки. Другими словами, как только оценка объекта
завершена, он больше не является объектом для оценки. Но ОК не предлагают никакого
иного способа ссылок на ОО по завершении оценки. Требования семейства ALC_FLR, по
самой природе относящиеся к событиям "после оценки", приводят к потребности в
дополнительных терминах для периода "после оценки". Дополнительно, для подвидов
деятельности, описанных в этом документе, пришлось использовать другие термины с их
точным значением. Для этого в Приложении A определены следующие термины:
а) сертифицированный ОО;
б) релиз ОО;
в) отслеживание недостатка безопасности;

81
г) пользователь ОО;
д) руководства ОО;
е) недостаток безопасности.
Устранение недостатков безопасности выполняется для тех недостатков, которые
496

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

среде ОО; но не за их исправление. Например, разработчик доверенного приложения, как
правило, идентифицирует базовую операционную систему как среду ИТ. О недостатках,
найденных в приложении, разработчик сообщает, а также отслеживает и исправляет их. О
недостатках, обнаруженных в операционной системе, разработчику необходимо только
сообщить (возможно, в самом кратком виде: "данное приложение не выполняется в такой-
то операционной системе"). Тогда пользователям ОО, узнавшим, что операционная система
больше не отвечает требованиям, предъявляемым к среде ОО, или предположениям о ней,
понадобится другая операционная система, отвечающая упомянутым
требованиям/предположениям, на то время, пока недостатки операционной системы не
исправлены ее разработчиком. Приведенный сценарий подчеркивает важность
осведомленности пользователей ОО о сочетании объектов оценки разных разработчиков.
Следует отметить, что процедуры устранения недостатков из этого подвида деятельности
498

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

лишь "предполагаемый" до того времени, пока исследование не завершится заключением:
или это не недостаток безопасности (тогда его не требуется далее отслеживать), или это
недостаток безопасности (тогда его требуется отслеживать вплоть до момента
исправления).
7.4.2 Подвид деятельности ALC_FLR.1
7.4.2.1 Цели
Цель данного подвида деятельности – сделать заключение, установил ли разработчик
500

процедуры устранения недостатков, которые описывают отслеживание недостатков
безопасности, идентификацию действий по их исправлению и доведение информации об
этих действиях до пользователей ОО.
7.4.2.2 Исходные данные
Свидетельством оценки для этого подвида деятельности является документация процедур
501

устранения недостатков.
7.4.2.3 Действия оценщика
Этот подвид деятельности включает один элемент действий оценщика из части 3 ОК:
502

а) ALC_FLR.1.1E.

82
7.4.2.3.1 Действие ALC_FLR.1.1E
ALC_FLR.1.1C
Оценщик должен исследовать документацию процедур устранения недостатков,
ALC_FLR.1-1
чтобы сделать заключение, описывает ли она процедуры по отслеживанию всех
ставших известными недостатков безопасности в каждом релизе ОО.
Процедуры описывают действия, которые предпринимаются разработчиком с момента
503

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

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

пользователей ОО о недостатках безопасности, они обязывают, чтобы все недостатки
безопасности, о которых уже имеется сообщение, отслеживались. Т.е. недостаток
безопасности, о котором имеется сообщение, не может игнорироваться просто потому, что
оно поступило не из организации разработчика.
ALC_FLR.1.2C
Оценщик должен исследовать процедуры устранения недостатков, чтобы
ALC_FLR.1-2
сделать заключение, сопровождается ли применение этих процедур описанием
каждого недостатка безопасности с точки зрения его сути и последствий.
Процедуры идентифицируют действия, которые приняты разработчиком для достаточно
506

детального описания сути и последствий каждого недостатка безопасности, дающего
возможность его воспроизведения. Описание сути недостатка безопасности раскрывает,
является ли он ошибкой в документации, недостатком в проекте ФБО, недостатком в
реализации ФБО и т.д. Описание последствий недостатка безопасности идентифицирует
фрагменты реализации ФБО, подвергаемые воздействию, и результаты воздействия на эти
фрагменты. Например, недостаток безопасности в реализации может быть в том, что он
влияет на идентификацию и аутентификацию, осуществляемую ФБО, разрешая
аутентификацию с паролем "ТАЙНЫЙВХОД".
Оценщик должен исследовать процедуры устранения недостатков, чтобы
ALC_FLR.1-3
сделать заключение, будет ли идентифицирован при применении этих процедур
статус завершения исправления каждого недостатка безопасности.
Процедуры устранения недостатков идентифицируют различные стадии недостатков
507

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



83
ALC_FLR.1.3C
Оценщик должен проверить процедуры устранения недостатков, чтобы сделать
ALC_FLR.1-4
заключение, будут ли идентифицированы при применении этих процедур
действия по исправлению каждого недостатка безопасности.
Действия по исправлению могут заключаться как в коррекции аппаратных средств,
508

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

по исправлению сводятся к обновлению соответствующего руководства ОО. Если действия
по исправлению являются процедурной мерой, то эта мера будет включать обновление
соответствующего руководства ОО для отражения этих корректирующих процедур.
ALC_FLR.1.4C
Оценщик должен исследовать документацию процедур устранения недостатков,
ALC_FLR.1-5
чтобы сделать заключение, содержит ли она описание методов, используемых для
предоставления пользователям ОО необходимой информации о каждом
недостатке безопасности.
Необходимая информация о каждом недостатке безопасности состоит из его описания (не
510

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

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

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



84
7.4.3 Подвид деятельности ALC_FLR.2
7.4.3.1 Цели
Цель данного подвида деятельности – сделать заключение, установил ли разработчик
513

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

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

<< Пред. стр.

страница 12
(всего 26)

ОГЛАВЛЕНИЕ

След. стр. >>

Copyright © Design by: Sunlight webdesign