13.8 Вид деятельности «Поддержка жизненного цикла»

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

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

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

Использование полностью определенных инструментальных средств разработки помогает удостовериться в том, что уязвимости не были непреднамеренно внесены в процессе уточнения ФБО.

13.8.1 Оценка безопасности разработки (ALC_DVS.1)

13.8.1.1 Цели

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

13.8.1.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности являются:

a) ЗБ;

b) документация по безопасности разработки.

Кроме того, оценщику может понадобиться исследование других поставок, чтобы сделать заключение о том, что меры и средства контроля безопасности полностью определены и их применяют. В частности, оценщику может понадобиться исследование документации разработчика по управлению конфигурацией (исходные данные подвидов деятельности ACM_CAP.4 «Поддержка генерации, процедуры приемки» и ACM_SCP.2 «Охват УК отслеживания проблем»). Также требуется свидетельство применения процедур.

13.8.1.3 Действие ALC_DVS.1.1E

13.8.1.3.1 Шаг оценивания 4:ALC_DVS.1-1

ИСО/МЭК 15408-3 ALC_DVS.1.1C: Документация по безопасности разработки должна содержать описание всех физических, процедурных, относящихся к персоналу и других мер безопасности, которые необходимы для защиты конфиденциальности и целостности проекта ОО и его реализации в среде разработки.

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

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

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

При исследовании документации оценщик рассматривает следующие типы мер безопасности:

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

b) процедурные, например распространяющиеся:

- на предоставление доступа к среде разработки или к конкретным объектам среды, таким как оборудование разработки,

- на отмену прав доступа лиц при их исключении из состава разработчиков,

- на передачу защищаемого материала из среды разработки,

- на встречу и сопровождение посетителей среды разработки,

- на роли и обязанности по обеспечению непрерывного применения мер безопасности и обнаружения нарушений безопасности;

c) относящиеся к персоналу разработчиков, например средства контроля или проверки, позволяющие установить, заслуживают ли доверия принимаемые на работу;

d) прочие меры безопасности, например средства логической защиты оборудования разработки.

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

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

13.8.1.3.2 Шаг оценивания 4:ALC_DVS.1-2

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

При рассмотрении политик учитывают следующее:

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

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

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

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

Тогда как требования АСМ_САР зафиксированы, требования для ALC_DVS «Безопасность разработки», предписывающие только необходимые меры, зависят от типа ОО и от информации, которая может быть представлена в разделе ЗБ «Среда безопасности». Например, ЗБ может идентифицировать политику безопасности организации, в которой требуется наличие формы допуска у персонала разработчиков ОО. Тогда оценщику в ходе выполнения данного подвида деятельности необходимо сделать заключение, была ли применена такая политика.

13.8.1.3.3 Шаг оценивания 4:ALC_DVS.1-3

ИСО/МЭК 15408-3 ALC_DVS.1.2C: Документация по безопасности разработки должна предоставить свидетельство, что необходимые меры безопасности соблюдаются во время разработки и сопровождения ОО.

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

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

Руководство по выборке см. в А.2 «Выборка» (приложение А).

13.8.1.4 Действие ALC_DVS.1.2E

13.8.1.4.1 Шаг оценивания 4:ALC_DVS.1-4

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

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

a) наблюдать применение мер безопасности (например, физических мер);

b) исследовать документальные свидетельства применения процедур;

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

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

Руководство по посещению объектов см. в А.5 «Посещение объектов» (приложение А).

13.8.2 Оценка определения жизненного цикла (ALC_LCD.1)

13.8.2.1 Цели

Цель данного подвида деятельности — сделать заключение, использовал ли разработчик задокументированную модель жизненного цикла ОО.

13.8.2.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности являются:

a) ЗБ;

b) документация определения жизненного цикла.

13.8.2.3 Действие ALC_LCD.1.1E

13.8.2.3.1 Шаг оценивания 4:ALC_LCD.1-1

ИСО/МЭК 15408-3 ALC_LCD.1.1C: Документация по определению жизненного цикла должна содержать описание модели, применяемой при разработке и сопровождении ОО.

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

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

13.8.2.3.2 Шаг оценивания 4:ALC_LCD.1-2

ИСО/МЭК 15408-3 ALC_LCD.1.2C: Модель жизненного цикла должна обеспечить необходимый контроль за разработкой и сопровождением ОО.

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

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

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

13.8.3 Оценка инструментальных средств и методов (ALC_TAT.1)

13.8.3.1 Цели

Цель данного подвида деятельности — сделать заключение, использовал ли разработчик полностью определенные инструментальные средства разработки [например, языки программирования или системы автоматизированного проектирования (САПР)], которые дают непротиворечивые и предсказуемые результаты.

13.8.3.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности являются:

a) документация инструментальных средств разработки;

b) подмножество представления реализации.

13.8.3.3 Замечания по применению

Эта работа может быть выполнена в сочетании с подвидом деятельности ADV_IMP.1 «Подмножество реализации ФБО», а именно, в части, касающейся определения используемых характеристик инструментальных средств, которые влияют на объектный код (например, опции компиляции).

13.8.3.4 Действие ALC_TAT.1.1E

13.8.3.4.1 Шаг оценивания 4:ALC_TAT.1-1

ИСО/МЭК 15408-3 ALC_TAT.1.1C: Все инструментальные средства разработки, используемые для реализации, должны быть полностью определены.

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

Например, полностью определенными можно считать те языки, компиляторы или САПР, которые соответствуют общепризнанным стандартам, таким как стандарты ИСО. Полностью определенным языком является тот, для которого имеется четкое и полное описание его синтаксиса и детальное описание семантики каждой из его конструкций.

13.8.3.4.2 Шаг оценивания 4:ALC_TAT.1-2

ИСО/МЭК 15408-3 ALC_TAT.1.2C: Документация инструментальных средств разработки должна однозначно определить значения всех конструкций языка, используемых в реализации.

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

В документации инструментальных средств разработки (например, в спецификациях языка программирования и в руководствах пользователя) должны быть охвачены все конструкции, используемые в представлении реализации ОО, и для каждой такой конструкции предоставлено четкое и однозначное определение предназначения и результата выполнения этой конструкции. Эта работа может быть выполнена в сочетании с исследованием оценщиком представления реализации, выполняемого в рамках подвида деятельности ADV_IMP.1 «Подмножество реализации ФБО». Главные усилия оценщика должны быть направлены на выяснение того, действительно ли документация достаточно ясна для понимания представления реализации. Например, в документации не следует предполагать, что пользователь является экспертом по примененному языку программирования.

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

Важная проверка состоит в том, может пи оценщик понять исходный код ОО при выполнении анализа исходного кода, включенного в подвид деятельности «Представление реализации» (ADV_IMP).

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

a) на естественном языке такие фразы, как «цель данной конструкции не определена» и такие термины, как «зависит от реализации» или «ошибочный» могут указывать на плохо определенные области;

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

c) обработка исключительных событий (например, что должно происходить после исчерпания свободной памяти или переполнения стека) часто плохо определена.

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

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

13.8.3.4.3 Шаг оценивания 4:ALC_TAT.1-3

ИСО/МЭК 15408-3 ALC_TAT.1.3C: Документация инструментальных средств разработки должна однозначно определить значения всех опций, обусловленных реализацией.

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

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

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

Далее >>>