Последнее обновление: 19.04.2024
Законодательная база Российской Федерации
8 (800) 350-23-61
Бесплатная горячая линия юридической помощи
- Главная
- "МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. Часть 3. ТРЕБОВАНИЯ ДОВЕРИЯ К БЕЗОПАСНОСТИ. ГОСТ Р ИСО/МЭК 15408-3-2008" (утв. Приказом Ростехрегулирования от 18.12.2008 N 521-ст)
16 Класс ALC. Поддержка жизненного цикла
Поддержка жизненного цикла является аспектом установления дисциплины и контроля в процессе уточнения ОО во время его разработки и сопровождения. Уверенность в соответствии ОО требованиям безопасности к ОО будет больше, если анализ безопасности и формирование свидетельств проводятся на регулярной основе как неотъемлемая часть деятельности при разработке и сопровождении.
Декомпозиция класса ALC "Поддержка жизненного цикла" на составляющие его семейства и иерархия компонентов этил: семейств показаны на рисунке 13.
16.1.1 Цели
Безопасность разработки связана с физическими, процедурными, относящимися к. персоналу и другими мерами безопасности, которые могут применяться в среде разработки для зашиты ОО. Безопасность разработки включает в себя физическую безопасность места разработки и любые процедуры, связанные с отбором персонала разработчиков.
16.1.2 Ранжирование компонентов
Компоненты в данном семействе ранжированы на основе наличия логического обоснования достаточности мер безопасности.
16.1.3 Замечания по применению
Семейство ALC_DVS связано с мерами по устранению или ослаблению угроз, существующих в месте разработки. Напротив, угрозы, противостоять которым необходимо по месту эксплуатации ОО, обычно учитывают в разделе "Среда безопасности" ПЗ или ЗБ.
Оценщику следует сделать заключение, необходимо ли ему посетить место разработки для подтверждения выполнения требований этого семейства.
Известно, что конфиденциальность не всегда может включаться в задачи защиты ОО в среде его разработки. Использование слова "необходимый" в ALC_DVS.1.1C и ALC_DVS.2.1C предусматривает возможность выбора соответствующих мер защиты.
16.1.4 ALC_DVS.1 Идентификация мер безопасности
Зависимости: нет зависимостей.
16.7.4.1 Элементы действий разработчика
16.1.4.1.1 ALC_DVS.1.1D
Разработчик должен разработать документацию по безопасности разработки.
16.1.4.2 Элементы содержания и представления свидетельств
16.1.4.2.1 ALC_DVS.1.1С
Документация по безопасности разработки должна содержать описание всех физических, процедурных, относящихся к персоналу и другим мер безопасности, которые необходимы для защиты конфиденциальности и целостности проекта ОО и его реализации в среде разработки,
Документация по безопасности разработки должна предоставить свидетельство, что необходимые меры безопасности соблюдаются во время разработки и сопровождения ОО.
16.1.4.3 Элементы действий оценщика
16.1.4.3.1 ALC_DVS.1.1 Е
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
16.1.4.3.2 ALC_DVS.1.2E
Оценщик должен подтвердить применение мер безопасности.
16.1.5. ALC_DVS.2 Достаточность мер безопасности
Зависимости: нет зависимостей.
16.1.5.1 Элементы действий разработчика
16.1.5.1.1 ALC_DVS.2.1D
Разработчик должен разработать документацию по безопасности разработки.
16.1.5.2 Элементы содержания и представления свидетельств
16.1.5.2.1 ALC_DVS.2.1С
Документация по безопасности разработки должна содержать описание всех физических, процедурных, относящихся к персоналу и других мер безопасности, которые необходимы для защиты конфиденциальности и целостности проекта ОО и его реализации в среде разработки.
16.1.5.2.2 ALC_DVS.2.2С
Документация по безопасности разработки должна предоставить свидетельство того, что необходимые меры безопасности соблюдаются во время разработки и сопровождения ОО.
16.1.5.2.3 ALC_DVS.2.3С
Свидетельство должно содержать логическое обоснование того, что меры безопасности обеспечивают необходимый уровень защиты конфиденциальности и целостности ОО.
16.1.5.3 Элементы действий оценщика
16.1.5.3.1 ALC_DVS.2.1E
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
16.1.5.3.2 ALC_DVS.2.2E Оценщик должен подтвердить применение мер безопасности.
16.2 Устранение недостатков (ALC_FLR)Семейство ALC_FLR содержит требование, чтобы обнаруженные недостатки безопасности были отслежены и исправлены разработчиком. Хотя при оценке ОО не может быть сделано заключение о его соответствии процедурам устранения недостатков в будущем, можно оценить политики и процедуры, которые предусмотрены разработчиком для отслеживания и исправления недостатков, а также распространения информации о недостатках и их исправлении.
16.2.2 Ранжирование компонентов
Компоненты в этом семействе ранжированы на основе расширения области применения процедур устранения недостатков и повышения строгости политик устранения недостатков.
16.2.3 Замечания по применению
Данное семейство обеспечивает доверие к сопровождению и поддержке ОО в будущем, требуя от разработчика ОО отслеживать и исправлять недостатки в ОО. Кроме того, имеются требования по распространению сведений об исправлениях недостатков. Однако данное семейство не налагает требований, выходящих за рамки текущей оценки.
Пользователь ОО считается основным лицом в организации, ответственным за получение и применение исправлений недостатков безопасности. Таким лицом необязательно должен являться отдельный пользователь, им может быть представитель организации, ответственный за обработку недостатков безопасности. Использование термина "пользователь ОО" предполагает, что в различных организациях имеются различные процедуры обработки сообщений о недостатках, которые могут выполняться пользователями индивидуально либо централизовано административным лицом.
В процедурах устранения недостатков следует описать методы реагирования на все типы встречающихся недостатков. Некоторые недостатки не могут быть исправлены немедленно. Об этих недостатках могут сообщить разработчик ОО, пользователи ОО, другие стороны, знакомые с ОО. Не исключено, что недостаток вообще не может быть исправлен, и необходимо применить другие (например, процедурные) меры. Представленная документация должна охватывать процедуры по обеспечению исправлений в местах эксплуатации, а также предоставление информации о недостатках, для которых исправление отложено (и что делать в этой ситуации) или невозможно.
После того как оценка ОО завершена, он больше не является объектом оценки. Более того, любые изменения, вносимые в оцененный ОО, приводят к тому, что первоначальные результаты оценки не являются больше применимыми к измененной версии. Поэтому термин "релиз ОО", используемый в данном семействе, относится к версии продукта или системы, являющейся релизом сертифицированного ОО, в который были внесены изменения.
16.2.4. ALC_FLR.1 Базовое устранение недостатков Зависимости: нет зависимостей.
16.2.4.1 Элементы действии разработчика
16.2.4.1.1 ALC_FLR.1.1D
Разработчик должен предоставить процедуры устранения недостатков, предназначенные для разработчиков ОО.
16.2.4.2 Элементы содержания и представления свидетельств
16.2.4.2.1 ALC_FLR.1.1С
Документация процедур устранения недостатков должна содержать описание процедур по отслеживанию всех ставших известными недостатков безопасности в каждом релизе ОО.
16.2.4.2.2 ALC_FLR.1.2С
Процедуры устранения недостатков должны содержать требование представления описания сути и последствий каждого недостатка безопасности, а также статуса процесса исправления этого недостатка.
16.2.4.2.3 ALC_FLR.1.3C
Процедуры устранения недостатков должны содержать требование, чтобы действия по исправлению были идентифицированы для каждого недостатка безопасности.
16.2.4.2.4 ALC_FLR.1.4С
Документация процедур устранения недостатков должна содержать описание методов, используемых для предоставления пользователям ОО информации о недостатках, материалов исправлений и руководства по внесению исправлений.
16.2.4.3 Элементы действий оценщика
16.2.4.3.1 ALC_FLR.1.1E
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
16.2.5 ALC_FLR.2 Процедуры сообщений о недостатках
Зависимости: нет зависимостей.
16.2.5.1 Цели
Для того чтобы разработчик имел возможность соответствующим образом реагировать на сообщения пользователей ОО о недостатках безопасности и знал, кому посылать исправления, пользователям ОО необходимо иметь представление о том, каким образом представлять сообщения о недостатках безопасности разработчику. Руководство по исправлению недостатков, предоставляемое разработчиком пользователям ОО, обеспечивает знание пользователями ОО этой важной информации.
16.2.5.2 Элементы действий разработчика
Разработчик должен предоставить процедуры устранения недостатков, предназначенные для разработчиков ОO.
16.2.5.2.2 ALC_FLR.2.2D
Разработчик должен установить процедуру приема и отработки всех сообщений пользователей о недостатках безопасности и запросов на их исправление,
16.2.5.2.3 ALC_FLR.2.3D
Разработчик должен предоставить руководство по устранению недостатков, предназначенное для пользователей ОО.
16.2.5.3 Элементы содержания и представления свидетельств
16.2.5.3.1 ALC_FLR.2.1C
Документация процедур устранения недостатков должна содержать описание процедур по отслеживанию всех ставших известными недостатков безопасности в каждом релизе ОО.
16.2.5.3.2 ALC_FLR.2.2C
Процедуры устранения недостатков должны содержать требование представления описания сути и последствий каждого недостатка безопасности, а также статуса процесса исправления этого недостатка.
16.2.5.3.3 ALC_FLR.2.3C
Процедуры устранения недостатков должны содержать требование, чтобы действия по исправлению были идентифицированы для каждого недостатка безопасности.
16.2.5.3.4 ALC_FLR.2.4C
Документация процедур устранения недостатков должна содержать описание методов, используемых, для предоставления пользователям ОО информации о недостатках, материалов исправлений и руководства по внесению исправлений.
16.2.5.3.5 ALC_FLR.2.5C
Процедуры устранения недостатков должны описывать средства, с помощью которых разработчик получает от пользователей ОО сообщения и запросы о предполагаемых недостатках безопасности в ОО.
16.2.5.3.6 ALC_FLR.2.6C
Процедуры обработки ставших известными недостатков безопасности должны обеспечить, чтобы любые ставшие известными недостатки были исправлены, а для пользователей ОО выпущены исправления.
Процедуры обработки ставших известными недостатков безопасности должны обеспечить такие защитные меры, чтобы любые исправления этих недостатков не приводили к появлению новых.
16.2.5.3.8 ALC_FLR.2.6C
Руководство по устранению недостатков должно описывать средства, с помощью которых пользователи ОО могут сообщать разработчикам о любых предполагаемых недостатках безопасности в ОО.
16.2.5.4 Элементы действий оценщика
16.2.5.4.1 ALC_FLR.2.1E
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
16.2.6 ALC_FLR.3 Систематическое устранение недостатков
Зависимости: нет зависимостей.
16.2.6.1 Цели
Для того чтобы разработчик имел возможность соответствующим образом реагировать на сообщения от пользователей ОО о недостатках безопасности и знал, кому посылать исправления, пользователям ОО необходимо иметь представление о том, каким образом представлять сообщения о недостатках безопасности на рассмотрение разработчику и каким образом регистрироваться у разработчика для того, чтобы получать исправления. Руководство по исправлению недостатков, предоставляемое разработчиком пользователям ОО, обеспечивает знание пользователями ОО этой важной информации.
16.2.6.2 Элементы действий разработчика
16.2.6.2.1 ALC_FLR.3.1D
Разработчик должен предоставить процедуры устранения недостатков, предназначенные для разработчиков ОО.
16.2.6.2.2 ALC_FLR.3.2D
Разработчик должен установить процедуру приема и отработки всех сообщений пользователей о недостатках безопасности и запросов на исправление этих недостатков.
16.2.6.2.3 ALC_FLR.3.3D
Разработчик должен предоставить руководство по устранению недостатков, предназначенное для пользователей ОО,
16.2.6.3 Элементы содержания и представления свидетельств
16.2.6.3.1 ALC_FLR.3.1C
Документация процедур устранения недостатков должна содержать описание процедур по отслеживанию всех ставших известными недостатков безопасности в каждом релизе ОО.
16.2.6.3.2 ALC_FLR.3.2C
Процедуры устранения недостатков должны содержать требование представления описания сути и последствий каждого недостатка безопасности, а также статуса процесса исправления этого недостатка.
16.2.6.3.3 ALC_FLR.3.3С
Процедуры устранения недостатков должны содержать требование, чтобы действия по исправлению были идентифицированы для каждого недостатка безопасности.
16.2.6.3.4 ALC_FLR.3.4C
Документация процедур устранения недостатков должна содержать описание методов, используемых для предоставления пользователям ОО информации о недостатках, материалов исправлений и руководства по внесению исправлений.
16.2.6.3.5 ALC_FLR.3.5C
Процедуры устранения недостатков должны описывать средства, с помощью которым разработчик получает от пользователей ОО сообщения и запросы о предполагаемый недостатках безопасности в ОО.
16.2.6.3.6 ALC_FLR.3.6C
Процедуры обработки ставших известными недостатков безопасности должны обеспечить, чтобы любые ставшие известными недостатки были исправлены, а для пользователей ОО выпущены исправления.
16.2.6.3.7 ALC_FLR.3.7C
Процедуры обработки ставших известными недостатков безопасности должны обеспечить такие защитные меры, чтобы любые исправления этих недостатков не приводили к появлению новых.
16.2.6.3.8 ALC_FLR.3.8C
Руководство по устранению недостатков должно описывать средства, с помощью которых пользователи ОО могут сообщать разработчикам о любых предполагаемых недостаткам безопасности в ОО.
16.2.6.3.9 ALC_FLR.3.9C
Процедуры устранения недостатков должны включать в себя процедуру своевременного реагирования для автоматического распространения сообщений о недостатках безопасности и материалов по их исправлению зарегистрированным пользователям, для которых эти недостатки могут иметь последствия,
16.2.6.3.10 ALC_FLR.3.10C
Руководство по устранению недостатков должно описывать средства, с помощью которых пользователи ОО могут регистрироваться у разработчика, чтобы иметь право получать сообщения о недостатках безопасности и исправления.
16.2.6.3.11 ALC_FLR.3.11C
В руководстве по устранению недостатков должна быть идентифицирована контактная информация для всех сообщений и запросов по вопросам безопасности, связанных с ОО.
16.2.6.4 Элементы действий оценщика
16.2.6.4.1 ALC_FLR.3.1E
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
16.3 Определение жизненного цикла (ALC_LCD)16.3.1 Цели
Плохо управляемые разработка и сопровождение ОО могут приводить к неправильной реализации ОО (или к ОО, который отвечает не всем требованиям безопасности). Это, в свою очередь, приводит к нарушениям безопасности. Поэтому важно, чтобы в жизненном цикле ОО была как можно раньше установлена модель разработки и сопровождения ОО.
Использование модели разработки и сопровождения ОО не гарантирует, что ОО не будет содержать недостатки и будет отвечать всем функциональным требованиям безопасности. Может оказаться, что выбранная модель будет недостаточной или неадекватной, и поэтому выигрыш в качестве ОО не будет заметен. Использование модели жизненного цикла, одобренной некоторой группой экспертов (например, специалистами - теоретиками, органами стандартизации), повышает вероятность, что модель разработки и сопровождения будет содействовать достижению требуемого качества ОО.
16.3.2 Ранжирование компонентов
Компоненты в данном семействе ранжированы на основе повышения требований к стандартности и измеримости модели жизненного цикла, а также к согласованности с этой моделью.
16.3.3 Замечания по применению
Модель жизненного цикла объединяет процедуры, инструментальные средства и методы, используемые для разработки и сопровождения ОО. Аспекты процесса, которые могут быть охвачены такой моделью, включают в себя методы проектирования, процедуры проверки, средства управления проектом, процедуры контроля изменений, методы тестирования и процедуры приемки. Эффективная модель жизненного цикла позволяет включить аспекты процесса разработки и сопровождения в общую структуру управления, которая устанавливает обязанности и контролирует развитие.
Оценка аспектов сопровождения ОО повышает доверие к ОО за счет анализа информации о жизненном цикле ОО, представленной во время оценки до начала сопровождения.
Стандартизованная модель жизненного цикла - это модель, которая была одобрена некоторой группой экспертов (например, специалистами-теоретиками, органами стандартизации).
Измеримая модель жизненного цикла - это модель с количественными параметрами и/или метриками, используемыми для измерение характеристик разработки ОО (например, метрикой сложности исходного текста).
Модель жизненного цикла обеспечивает необходимый контроль за разработкой и сопровождением ОО, если разработчик может предоставить информацию, которая показала бы, что модель приемлемым образом минимизирует риск нарушений безопасности в ОО. При определении модели: для части жизненного цикла после поставки ОО может быть полезна информация о предполагаемой среде ОО и целях безопасности ОО, приведенная в ЗБ.
16.3.4 ALC_LCD.1 Определение модели жизненного цикла разработчиком
Зависимости: нет зависимостей.
16.3.4.1 Элементы действий разработчика
16.3.4.1.1 ALC_LCD.1.1D
Разработчик должен установить модель жизненного цикла, используемую при разработке и сопровождении ОО.
16.3.4.1.2 ALC_LCD.1.2D
Разработчик должен представить документацию по определению жизненного цикла.
16.3.4.2 Элементы содержания и представления свидетельств
16.3.4.2.1 ALC_LCD.1.1С
Документация по определению жизненного цикла должна содержать, описание модели, применяемой при разработке и сопровождении ОО.
16.3.4.2.2 ALC_LCD.1.2С
Модель жизненного цикла должна обеспечить необходимый контроль за разработкой и сопровождением ОО.
16.3.4.3 Элементы действий оценщика
16.3.4.3.1 ALC_LCD.1.1E
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
16.3.5 ALC_LCD.2 Стандартизованная модель жизненного цикла
Зависимости: нет зависимостей.
16.3.5.1 Элементы действий разработчика
16.3.5.1.1 ALC_LCD 2.1D
Разработчик должен установить модель жизненного цикла, используемую при разработке и сопровождении ОО.
16.3.5 1.2 ALC_LCD.2.2D
Разработчик должен представить документацию по определению жизненного цикла.
16.3.5.1.3 ALC_LCD 2.3D
Разработчик должен использовать стандартизованную модель жизненного цикла для разработки и сопровождения ОО.
16.3.5.2 Элементы содержания и представления свидетельств
16.3.5.2.1 ALC_LCD.2.1С
Документация по определению жизненного цикла должна содержать описание модели, применяемой при разработке и сопровождении ОО.
16.3.5.2.2ALC_LCD2.2C
Модель жизненного цикла должна обеспечить необходимый контроль за разработкой и сопровождением ОО.
16.3.5.2.3 ALC_LCD.2.3C
Документация по определению жизненного цикла должна объяснить выбор модели.
16.3.5.2.4 ALC_LCD.2.4C
Документация по определению жизненного цикла должна объяснить, как модель используется при разработке и сопровождении ОO.
16.3.5.2.5 ALC_LCD.2.5C
Документация по определению жизненного цикла должна демонстрировать согласованность со стандартизованной моделью жизненного цикла.
16.3.5.3 Элементы действий оценщика
16.3.5.3.1 ALC_LCD.2.1E
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
16.3.6 ALC_LCD.3 Измеримая модель жизненного цикла
Зависимости: нет зависимостей.
16.3.6.1 Элементы действий разработчика
16.3.6.1 1 ALC_LCD.3.1D
Разработчик должен установить модель жизненного цикла, используемую при разработке и сопровождении ОО.
16.3.6.12. ALC_LCD.3.2D
Разработчик должен представить документацию по определению жизненного цикла.
16.3.6.1.3 ALC_LCD.3.3D
Разработчик должен использовать стандартизованную и измеримую модель жизненного цикла для разработки и сопровождения ОО.
16.3.6.1.4 ALC_LCD.3.4D
Разработчик должен количественно оценить, процесс разработки ОО, используя стандартизованную и измеримую модель жизненного цикла.
16.3.6.2 Элементы содержания и представления свидетельств
16.3.6.2.1 ALC_LCD.3.1С
Документации по определению жизненного цикла должна содержать описание модели, применяемой при разработке и сопровождении ОО, включая детализацию ее количественных параметров и/или метрик, используемых для оценки соответствия процесса разработки ОО принятой модели.
16.3.6.2.2 ALC_LCD.3.2C
Модель жизненного цикла должна обеспечить необходимый контроль за разработкой и сопровождением ОО.
16.3.6.2.3 ALC_LCD.3.3С
Документация по определению жизненного цикла должна объяснить выбор модели.
16.3.6.2.3 ALC_LCD.3.4С
Документация по определению жизненного цикла должна объяснить, как модель используется при разработке и сопровождение ОО.
Документация по определению жизненного цикла должна демонстрировать согласованность со стандартизованной и измеримой моделью жизненного цикла.
16.3.6.2.6 ALC_LCD.3.6C
Документация по жизненному циклу должна представить результаты количественной оценки процесса разработки ОО с использованием стандартизованной и измеримой модели жизненного цикла.
16.3.6.3 Элементы действий оценщика
16.3.6.3.1 ALC_LCD.3.1E
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
16.4 Инструментальные средства и методы (ALC_TAT)16.4.1 Цели
Семейство ALC_TAT связано с выбором инструментальным средств, используемых для разработки, анализа и реализации ОО. Семейство содержит требования по предотвращению использования плохо определенных, несогласованных или неподходящих инструментальных средств разработки ОО. Это относится, в частности, к языкам программирования, документации, стандартам реализации и некоторым частям ОО, например, вспомогательным динамическим библиотекам.
16.4.2 Ранжирование компонентов
Компоненты в данном семействе ранжированы на основе повышения требований к описанию и области применения стандартов реализации и документации по опциям, зависимым от реализации.
16.4.3 Замечания по применению
Полностью определенными называют инструментальные средства разработки, которые применимы без необходимости подробных дополнительных пояснений. Например, принято считать полностью определенными языки программирования и системы автоматизации проектирования (САПР), которые основаны на стандартах.
В данном семействе различают стандарты реализации, которые применялись разработчиком (ALC_TAT.2.3D) и стандарты реализации для "всех частей ОО" (ALC_TAT.3.3D), в которые дополнительно включены программные, аппаратные или программно-аппаратные средства сторонних разработчиков.
Требование в АLC_ТАТ.1.2С применяют, главным образом, к языкам программирования для обеспечения однозначности всех операторов исходного текста.
16.4.4 ALC_TAT.1 Полностью определенные инструментальные средства разработки
Зависимости: ADV_IMP.1 Подмножество peaлизации ФБО
1:6.4.4.1 Элементы действий разработчика
16.4.4.1.1 ALC_TAT.1.1D
Разработчик должен идентифицировать инструментальные средства разработки ОО.
16.4.4.1.2 ALC_TAT.1.2D
Разработчик должен задокументировать выбранные опции инструментальных средств разработки, обусловленные реализацией.
16.4.4.2 Элементы содержания и представления свидетельств
16.4.4.2.1 ALC_TAT.1.1С
Все инструментальные средства разработки, используемые для реализации, должны быть полностью определены.
16.4.4.2.2 ALC_TAT.1.2C
Документация инструментальным средств разработки должна однозначно определить значения всех конструкций языка, используемых в реализации.
16.4.4.2.3 ALC_TAT.1.3С
Документация инструментальных средств разработки должна однозначно определить значения всех опций, обусловленных реализацией.
16.4.4.3 Элементы действий оценщика
16.4.4.3.1 АLС_ТАТ.1.1Е
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
16.4.5 ALC_TAT.2 Соответствие стандартам реализации
Зависимости: ADV_IMP.1 Подмножество реализации ФБО
16.4.5.1 Элементы действий разработчика
16.4.5.1.1 ALC_TAT.2.1D
Разработчик должен идентифицировать инструментальное средства разработки ОО.
16.4.5.1.2 ALC_TAT.2.2D
Разработчик должен задокументировать выбранные опции инструментальным средств разработки, обусловленные реализацией.
16.4.5.1.3 ALC_TAT.2.3D
Разработчик должен привести описание применявшихся стандартов реализации.
16.4.52 Элементы содержания и представления свидетельств
16.4.5.2.1 АLС_ТАТ.2.1С
Все инструментальные средства разработки, используемые для реализации, должны быть полностью определены.
16.4.5.2.2 ALC_TAT.2.2C
Документация инструментальных средств разработки должна однозначно определить значения всех конструкций языка, используемых в реализации.
16.4.5.2.3 АLС_ТАТ.2.3С
Документация инструментальных средств разработки должна однозначно определить значения всех опций, обусловленных реализацией.
16.4.5.3 Элементы действий оценщика
16.4.5.3.1 АLС_ТАТ.2.1E
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
16.4.5.3.2 АLС_ТАТ.2.2Е
Оценщик должен подтвердить, что стандарты реализации применялись.
16.4.6 ALC_TAT.3 Соответствие всех частей ОО стандартам реализации
Зависимости: ADV_IMP.1 Подмножество реализации ФБО
16.4.6.1 Элементы действий разработчика
16.4.6.1.1 ALC_TAT.3.1D
Разработчик должен идентифицировать инструментальные средства разработки ОО.
16.4.6.1.2ALC_TAT.3.2D
Разработчик должен задокументировать выбранные опции инструментальным средств разработки, обусловленные реализацией.
16.4.6.1.3 ALC_TAT.3.3D Разработчик должен привести описание стандартов реализации для всех частей ОО.
16.4.6.2 Элементы содержания и представления свидетельств
16.4.6.2.1 АLС_ТАТ.3.1С
Все инструментальные средства разработки, используемые для реализации, должны быть полностью определены.
Документация инструментальным средств разработки должна однозначно определить значения всех конструкций языка, используемых в реализации.
16.4.6.2.3 АLС_ТАТ.3.3С
Документация инструментальным средств разработки должна однозначно определить значения всех опций, обусловленных реализацией.
16.4.6.3 Элементы действий оценщика
16.4.6.3.1 ALC_TAT.3.1E
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
16.4.6.3.2 АLС_ТАТ.3.2Е
Оценщик должен подтвердить, что стандарты реализации применялись.
- Главная
- "МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. Часть 3. ТРЕБОВАНИЯ ДОВЕРИЯ К БЕЗОПАСНОСТИ. ГОСТ Р ИСО/МЭК 15408-3-2008" (утв. Приказом Ростехрегулирования от 18.12.2008 N 521-ст)