ГОСТ Р ИСО МЭК 15408-3 2007 (1027766), страница 13
Текст из файла (страница 13)
таблицу 13) обеспечивает доверие посредством анализа функций безопасности сиспользованием для понимания режима безопасности функциональной спецификации, полнойспецификации интерфейсов, руководств, проекта ОО верхнего уровня и нижнего уровня, а такжеструктурированного представления реализации. Доверие дополнительно достигается применением формальной модели политики безопасности ОО, формального представления функциональной спецификации и проекта верхнего уровня, полуформального представления проектанижнего уровня, а также формальной (где это требуется) и полуформальной демонстрации соответствия между ними. Кроме этого, требуется модульное, иерархическое (по уровням) и простое проектирование ОО.Анализ поддержан независимым тестированием ФБО, свидетельством разработчика об испытаниях, основанных на функциональной спецификации, проекте верхнего уровня, проекте ниж-49ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)него уровня и представлении реализации, полным независимым подтверждением результатовтестирования разработчиком, анализом стойкости функций, свидетельством поиска разработчикомуязвимостей и независимым анализом уязвимостей, демонстрирующим противодействие попыткам проникновения нарушителей с высоким потенциалом нападения.
Анализ также включает в себя проверку правильности систематического анализа разработчиком скрытых каналов.ОУД7 также обеспечивает доверие посредством использования структурированного процесса разработки, средств контроля среды разработки и всестороннего управления конфигурациейОО, включая полную автоматизацию, и свидетельства безопасных процедур поставки.Этот ОУД представляет значимое увеличение доверия по сравнению с ОУД6, требуявсесторонний анализ, использующий формальные представления и формальное соответствие, а также всестороннее тестирование.Т а б л и ц а 13 – ОЦЕНОЧНЫЙ УРОВЕНЬ ДОВЕРИЯ 7Класс доверияACM: УправлениеконфигурациейADO: Поставка иэксплуатацияADV: РазработкаAGD: РуководстваALC: Поддержкажизненного циклаATE: ТестированиеAVA: Оценкауязвимостей50Компоненты доверияACM_AUT.2 Полная автоматизация УКACM_CAP.5 Расширенная поддержкаACM_SCP.3 Охват УК инструментальных средств разработкиADO_DEL.3 Предотвращение модификацииADO_IGS.1 Процедуры установки, генерации и запускаADV_FSP.4 Формальная функциональная спецификацияADV_HLD.5 Формальный проект верхнего уровняADV_IMP.3 Структурированная реализация ФБОADV_INT.3 Минимизация сложностиADV_LLD.2 Полуформальный проект нижнего уровняADV_RCR.3 Формальная демонстрация соответствияADV_SPM.3 Формальная модель политики безопасности ООAGD_ADM.1 Руководство администратораAGD_USR.1 Руководство пользователяALC_DVS.2 Достаточность мер безопасностиALC_LCD.3 Измеримая модель жизненного циклаALC_TAT.3 Соответствие всех частей объекта оценки стандартамреализацииATE_COV.3 Строгий анализ покрытияATE_DPT.3 Тестирование на уровне реализацииATE_FUN.2 Упорядоченное функциональное тестированиеATE_IND.3 Полное независимое тестированиеAVA_CCA.2 Систематический анализ скрытых каналовAVA_MSU.3 Анализ и тестирование опасных состоянийAVA_SOF.1 Оценка стойкости функции безопасности ООAVA_VLA.4 ВысокостойкийГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)11Классы, семейства и компоненты доверияРазделы 12–18 содержат детализированные требования, представленные во всех компонентах доверия, сгруппированных в классы и семейства в алфавитном (по-латински) порядке.51ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)12Класс ACM: Управление конфигурациейУправление конфигурацией (УК) – один из методов или способов установить, что в созданном ОО реализованы функциональные требования и спецификации.
УК отвечает этим целям,предъявляя требования дисциплины и контроля в процессе уточнения и модификации ОО и связанной с ним информации. Системы УК используют для обеспечения целостности частей ОО, которые они контролируют, предоставляя метод отслеживания любых изменений, и для того, чтобывсе изменения были санкционированы.На рисунке 8 показаны семейства этого класса и иерархия компонентов в семействах.ACM_AUT Автоматизация УК12ACM_CAP Возможности УК123ACM_SCP Область УК12345Рисунок 8 –Декомпозиция класса ACM «Управление конфигурацией»12.1 Автоматизация УК (ACM_AUT)12.1.1ЦелиЦель привлечения инструментальных средств автоматизации УК – повышение эффективности системы УК. Несмотря на то, что как автоматизированные, так и ручные системы УК могутбыть обойдены, игнорироваться или оказываться недостаточными для предотвращения несанкционированной модификации, автоматизированные системы все же менее восприимчивы к человеческому фактору – ошибке или небрежности.12.1.2Ранжирование компонентовКомпоненты в этом семействе ранжированы на основе набора элементов конфигурации, которые управляются с применением автоматизированных средств.12.1.3Замечания по применениюACM_AUT.1.1C содержит требование, которое связано с представлением реализации ОО.Представление реализации ОО включает в себя все аппаратные, программные и программноаппаратные средства, которые составляют ОО по существу.
В случае, когда ОО состоит только изпрограммных средств, представление реализации может состоять исключительно из исходного иобъектного кода.ACM_AUT.1.2C содержит требование, чтобы система УК предоставила автоматизированныесредства для поддержки генерации ОО. При этом требуется, чтобы система УК предоставила автоматизированные средства, содействующие принятию заключения, что при генерации ОО использованы правильные элементы конфигурации.ACM_AUT.2.5C содержит требование, чтобы система УК предоставила автоматизированныесредства, позволяющие установить различия между ОО и его предыдущей версией.
Если преды-52ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)дущей версии ОО не существует, разработчик все равно нуждается в предоставлении автоматизированных средств, чтобы установить различия между ОО и последующей версией ОО.12.1.4ACM_AUT.1Частичная автоматизация УКЗависимости: ACM_CAP.3 Средства контроля авторизации12.1.4.1 ЦелиВ средах разработки, где представление реализации является сложным или создается многими разработчиками, трудно контролировать изменения без использования автоматизированныхинструментальных средств. В частности, от этих автоматизированных инструментальных средствтребуется способность поддерживать многочисленные изменения, которые возникают в процессеразработки, и обеспечить санкционированность этих изменений.
Целью данного компонента является обеспечение контроля представления реализации с использованием автоматизированныхсредств.12.1.4.2 Элементы действий разработчика12.1.4.2.1ACM_AUT.1.1DРазработчик должен использовать систему УК.12.1.4.2.2ACM_AUT.1.2DРазработчик должен представить план УК.12.1.4.3 Элементы содержания и представления свидетельств12.1.4.3.1ACM_AUT.1.1CСистема УК должна предоставить автоматизированные средства, с использованиемкоторых в представлении реализации ОО производятся только санкционированные изменения.12.1.4.3.2ACM_AUT.1.2CСистема УК должна предоставить автоматизированные средства для поддержки генерации ОО.12.1.4.3.3ACM_AUT.1.3CПлан УК должен содержать описание автоматизированных инструментальныхсредств, используемых в системе УК.12.1.4.3.4ACM_AUT.1.4CПлан УК должен содержать описание, как автоматизированные инструментальныесредства используются в системе УК.12.1.4.4 Элементы действий оценщика12.1.4.4.1ACM_AUT.1.1EОценщик должен подтвердить, что представленная информация удовлетворяет всемтребованиям к содержанию и представлению свидетельств.12.1.5ACM_AUT.2Полная автоматизация УКЗависимости: ACM_CAP.3 Средства контроля авторизации12.1.5.1 ЦелиВ тех средах разработки, где элементы конфигурации являются сложными или создаютсямногими разработчиками, трудно контролировать изменения без использования автоматизированных инструментальных средств.
В частности, требуется, чтобы эти автоматизированные инструментальные средства были способны поддерживать многочисленные изменения, которые возникают в процессе разработки, и обеспечить санкционированность этих изменений. Цель данного53ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)компонента – обеспечить, чтобы все элементы конфигурации контролировались с использованиемавтоматизированных средств.Применение автоматизированных средств для выявления различий между версиями ОО иопределение, на какие элементы конфигурации воздействует модификация других элементовконфигурации, содействуют определению воздействия изменений на последовательные версииОО.
Это, в свою очередь, может предоставить ценную информацию, позволяющую определить,реализованы ли изменения ОО во всех элементах конфигурации, требующих согласования междусобой.12.1.5.2 Элементы действий разработчика12.1.5.2.1ACM_AUT.2.1DРазработчик должен использовать систему УК.12.1.5.2.2ACM_AUT.2.2DРазработчик должен представить план УК.12.1.5.3 Элементы содержания и представления свидетельств12.1.5.3.1ACM_AUT.2.1CСистема УК должна предоставить автоматизированные средства, с использованием которыхв представлении реализации ОО и во всех остальных элементах конфигурации производятсятолько санкционированные изменения.12.1.5.3.2ACM_AUT.2.2CСистема УК должна предоставить автоматизированные средства для поддержки генерацииОО.12.1.5.3.3ACM_AUT.2.3CПлан УК должен содержать описание автоматизированных инструментальных средств, используемых в системе УК.12.1.5.3.4ACM_AUT.2.4CПлан УК должен содержать описание, как автоматизированные инструментальные средстваиспользуются в системе УК.12.1.5.3.5ACM_AUT.2.5CСистема УК должна предоставить автоматизированные средства для выявления различий между ОО и его предшествующей версией.12.1.5.3.6ACM_AUT.2.6CСистема УК должна предоставить автоматизированные средства для определениявсех других элементов конфигурации, на которые воздействует модификация данного элемента конфигурации.12.1.5.4 Элементы действий оценщика12.1.5.4.1ACM_AUT.2.1EОценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.12.2 Возможности УК (ACM_CAP)12.2.1ЦелиВозможности системы УК связаны с вероятностью того, что могут произойти случайные илинесанкционированные модификации элементов конфигурации.
Следует, чтобы система УК обес-54ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)печила целостность ОО, начиная с ранних этапов проектирования и на протяжении всей последующей деятельности по сопровождению.Цели этого семейства состоят в следующем:a) обеспечение корректности и полноты ОО к моменту представления его потребителю;b) обеспечение, чтобы никакие элементы конфигурации не были пропущены в процессеоценки;c) предотвращение несанкционированной модификации, добавления или удаления элементов конфигурации ОО.В случае, когда ОО является подмножеством некоторого продукта, требования класса ACMприменяются только к элементам конфигурации ОО, а не к продукту в целом.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
