моя защита2


Санкт-Петербургский государственный электротехнический университет «ЛЭТИ»
Кафедра АСОиУОтчет по курсовой работе
«Методы и Средства Защиты Информации»
Выполнил: Рыбиков А. Э.
ФКТИ
8373
Проверил: Воробьев Владимир Михайлович
Санкт-Петербург, 2011 г.
Объект защиты: Локальная сеть офиса малого предприятия. Работа предприятия заключается в анализе данных из сети интернет, их обработки, хранения обработанной информации(часть из которой может быть секретна), а так же печать документов.

Рис.1. Схема локальной сети.
Выделение сущностей и определение отношений.
Источники угроз:
Пользователь
Злоумышленник
Администратор сети
Электросеть
Угрозы:
НСД
Сбой в электроснабжении
Установка нештатного ПО
Проблемы с доступом в интернет
Проблемы с локальной сетью
События риска:
Потеря информации
Разглашение информации
Изменение данных
Изменение прав доступа
Отсутствие доступа к необходимой информации
Отсутствие возможности печати
Компоненты объекта:
ОС
Принтер
Отчеты о работе
Секретная информация
Граф системы:

Логические цепочки:
ИУ1►УСР1►СРК1
ИУ1►УСР2►СРК2
ИУ1►УСР3►СРК3
ИУ1►УСР3►СРК4
ИУ1►УУ1►УСР4►СРК3
ИУ1►УУ1►УСР4►СРК4
ИУ1►УУ1►УСР5►СРК5
ИУ2►УСР4►СРК3
ИУ2►УСР4►СРК4
ИУ2►УСР5►СРК5
ИУ3►УСР1►СРК1
ИУ3►УСР2►СРК2
ИУ3►УСР3►СРК3
ИУ3►УСР3►СРК4ИУ3►УУ1►УСР4►СРК3
ИУ3►УУ1►УСР4►СРК4
ИУ3►УУ1►УСР5►СРК5
ИУ4►УСР4►СРК3
ИУ4►УСР4►СРК4
ИУ4►УСР5►СРК5
ИУ5►УСР4►СРК4
ИУ5►УСР5►СРК5
ИУ6►УСР6►СРК6
ИУ6►УСР6►СРК6
ИУ6►УСР7►СРК7
ИУ7►УСР8►СРК6
ИУ7►УСР8►СРК7
ИУ8►УУ2► УСР6►СРК6
ИУ8►УУ2► УСР7►СРК7
ИУ8►УУ3► УСР8►СРК6ИУ8►УУ3► УСР8►СРК7Работа с "Security analysis".
После введения данных получаем следующий вид:

Связь : Источники угроз – Угрозы :
Связь : Угрозы – Угрозы/События риска:

Связь : События риска – Объекты защиты:

Связь : Объекты защиты – Защита:

Введение весовых коэффициентов отношений матрицы W.

Расчет матрицы защищенности V.

Анализ взаимодействия элементов анализа.
Влияние источников угроз на безопасность защищаемого объекта:

Влияние угроз на безопасность защищаемого объекта:

Влияние компонентов на безопасность защищаемого объекта:

Синтез системы защиты.
По данным матрицы V можем выделить наиболее влиятельные источники угроз и угрозы.
Источники угроз:
Злоумышленник
Пользователь
Угрозы:
НСД
Потеря информации
Изменение прав доступа
Проблемы с локальной сетью
Для защит от наиболее влиятельных источников угроз и угроз можно предложить следующие меры:
Установить файервол на маршрутизатор
Установить ИБП
Обеспечить резервное копирование данных
Ограничить доступ администратора и некоторых пользователей к секретной информации
Схема защищенной локальной сети

Рис.2. Cхема защищенной сети
Матрица R

Вектор результативности

Вывод:
Глобальная результативность предложенных мер защиты равна 74,9%.
Данные критерии подходят для защиты сервера компании
Санкт-Петербургский государственный электротехнический университет «ЛЭТИ»
БЕЗОПАСНОСТЬ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
Локальная сеть малого предприятия
Профиль защиты
(первая редакция)
2011
Перечень сокращенийЗБ задание по безопасности
ИС информационная система
МЭ межсетевой экран
МЭПУ межсетевой экран провайдерского уровня
НСД несанкционированный доступ
ОДФ область действия функции безопасности
ОКОбщие критерии
ОО объект оценки
ОС операционная система
ОУД оценочный уровень доверия к безопасности
ПБО политика безопасности ОО
ПЗ профиль защиты
ПФБ политика функции безопасности
РД руководящий документ
УК управление конфигурацией
ФБО функции безопасности ОО
1. Введение1.1. Идентификация ПЗНазвание: Локальная сеть малого предприятия. Профиль защиты. Обозначение: ПЗ ЛСМП.001-2011.
Регистрация:
Ключевые слова: управление доступом, межсетевой экран, источник бесперебойного питания, резервное копирование, профиль защиты.
Родственные ПЗ: .1.2. Аннотация ПЗДанный профиль защиты описывает и обосновывает функциональные требования и требования доверия для локальной сети малого предприятия, т.е. описывает непосредственную защиту ресурсов предприятия от неконтролируемых в рамках предприятия или организации воздействий.
1.3. СоглашенияСистема обозначений, формат и соглашения, используемые в этом профиле защиты, основаны на версии 2.1 ОК.
ОК разрешают четыре операции с функциональными компонентами, применяемые в функциональных требованиях: назначение, итерация, уточнение и выбор.
Операции назначения или выбора указываются в квадратных скобках ("[ ]"). Оставшиеся незавершенными операции в профиле защиты должны быть специфицированы разработчиком в задании по безопасности.
Операции уточнения определяются при помощи слова "Уточнение:", написанного после мнемонического (краткого) имени. Эти операции предоставляют возможность добавить подробности или конкретизировать требования при использовании компонента.
Операции итерации определяются числом внутри круглых скобок ("(#)"). Такое обозначение следует после краткого имени элемента требований и позволяет использовать компоненты более чем один раз с изменяющимися операциями.
Замечания по применению используются для того, чтобы читатель мог лучше понять требования безопасности или намерения разработчика. В тексте профиля замечания по применению приведены после компонента, который необходимо пояснить.
В таблице 1 показаны операции, которые представляются с помощью полужирного, курсивного и подчеркнутого текста.
Таблица 1: Соглашение по использованию выделения шрифтом
Соглашение Цель Операция
Полужирный Выделение текста полужирным шрифтом применяется для предупреждения о том, что этот текст добавлен по отношению к тексту ОК. Назначение Уточнение
Курсив Выделение текста курсивом применяется, когда операция назначения или выбора не завершена разработчиком. Назначение
Подчеркивание Выделение текста подчеркиванием применяется к результату операции выбора в требованиях ОК. Выбор
Полужирный
и курсив Выделение текста полужирным шрифтом и курсивом применяется, когда разработчик ПЗ добавил к требованию новый текст, содержащий незавершенную операцию. Назначение
Уточнение
1.4. Термины и определенияМежсетевым экраном называется локальное (однокомпонентное) или функционально-распределенное средство (комплекс), реализующее контроль за информацией, поступающей во внутреннее информационное пространство и/или выходящей из него, и обеспечивает защиту ИС посредством фильтрации информации, т.е. ее анализа по совокупности критериев и принятия решения о ее распространении во (из) внутреннее информационное пространство.
Информационным пространством называется информационная и телекоммуникационная инфраструктура, способная предоставлять и получать информационные сервисы.
Внешним информационным пространством называется информационное пространство, неконтролируемое в рамках политики безопасности организации вследствие наличия иного собственника каких-либо компонент информационного пространства либо с более слабыми требованиями к сервисам безопасности, чем в рассматриваемой информационной системе.
Внутренним информационным пространством называется информационное пространство, защищаемое МЭ. Основным признаком внутреннего информационного пространства является возможность проведения согласованной политики безопасности в пределах этого пространства и на межсетевом экране.
Информационным обменом называется получение и/или предоставление информационных сервисов. Внешним информационным обменом называется информационный обмен с внешним информационным пространством.
Правила фильтрации – перечень условий, по которым с использованием заданных критериев фильтрации осуществляется разрешение или запрещение дальнейшей передачи пакетов (данных), и перечень действий, производимых МЭ по регистрации и/или осуществлению дополнительных защитных функций.
Экранирование – функция МЭ, позволяющая поддерживать безопасность объектов внутреннего информационного пространства, игнорируя несанкционированные запросы из внешнего информационного пространства.
2. Описание объекта оценкиВ данном документе в качестве ОО рассматривается локальная сеть предприятия. Перед сотрудниками стоят задачи: сбор информации в сети интернет, ее обработка, сохранение на сервер. ОО предназначена для объединения сотрудников в сеть, а так же для защиты данной сети.OO может быть реализован в виде программно-аппаратного комплекса, а так же в виде аппаратного комплекса.3. Среда безопасности ООA.SINGLEPT (Единая точка входа) ОО является единственной точкой контроля информационного обмена.
A.SECURE (Контроль физического доступа) ОО, связанная с ним консоль, активное сетевое и кроссовое оборудование, а также система электропитания защищены физически и доступны только для обслуживающего персонала.
A.COMMS (Защита передаваемых данных) Защита передаваемых в процессе информационного обмена данных обеспечивается дополнительными средствами безопасности, либо было явно принято решение о том, что такая защита не требуется.
A.USER (Пользователи) ОО не предоставляет информационных сервисов общего назначения. ОО осуществляет идентификацию и аутентификацию пользователей, осуществляющих внешний информационный обмен. Доступ к ресурсам ОО осуществляется только уполномоченным администратором (администраторами) в соответствии с регламентом эксплуатации ОО.
A.ENV_MANAGE (Среда управления) Управление настройками ОО, включая безопасность содержащейся в нем информации, а также выделение уровней системных ресурсов, должно осуществляться в соответствии с документацией, поставляемой в комплекте с ОО.
A.NOEVIL (Обслуживающий персонал) Предполагается, что уполномоченные администраторы квалифицированно выполняют обязанности по реализации документированной политики доступа.
3.1. Предположения безопасностиA.SINGLEPT (Единая точка входа) ОО является единственной точкой контроля внешнего информационного обмена.
A.SECURE (Контроль физического доступа) ОО, связанная с ним консоль, активное сетевое и кроссовое оборудование, а также система электропитания защищены физически и доступны только для обслуживающего персонала.
A.COMMS (Защита передаваемых данных) Защита передаваемых в процессе внешнего информационного обмена данных обеспечивается дополнительными средствами безопасности, либо было явно принято решение о том, что такая защита не требуется.
A.USER (Пользователи) ОО не предоставляет информационных сервисов общего назначения. ОО осуществляет идентификацию и аутентификацию пользователей, осуществляющих внешний информационный обмен. Доступ к ресурсам ОО осуществляется только уполномоченным администратором (администраторами) в соответствии с регламентом эксплуатации ОО.
A.ENV_MANAGE (Среда управления) Управление настройками ОО, включая безопасность содержащейся в нем информации, а также выделение уровней системных ресурсов, должно осуществляться в соответствии с документацией, поставляемой в комплекте с ОО.
A.NOEVIL (Обслуживающий персонал) Предполагается, что уполномоченные администраторы квалифицированно выполняют обязанности по реализации документированной политики доступа.
3.2. Предотвращаемые угрозы3.2.1. Угрозы, предотвращаемые ООT.НСД Лицо, не имеющее соответствующих полномочий, может получить доступ к ОО.
T.ElectroError Сбой в сети электроснабжения.T.EvilSoft установка нештатного ПО.T.InternetError проблемы с доступом в интернет.
T.LocalError проблемы с локальной сетью.T.DataLost потеря информации.T.SecureDataPublication публикация секретных данных.T.DataEvilEdition изменение данных.
T.RightsEvilEdition изменение прав доступа.T.DataNoConnection отсутствие доступа к необходимой информации.
T.PrinterNoConnection отсутствие доступа к принтеру.3.2.2. Угрозы, предотвращаемые средойT.INSTALL ОО может быть доставлен и установлен таким образом, что появится возможность нарушения безопасности.
T.OPERATE Нарушение безопасности может произойти из-за неправильного управления или эксплуатации ОО.
T.INSHARE Внутренние пользователи могут несанкционированно передать конфиденциальную информацию в процессе внешнего информационного обмена, либо реализовать отказ в обслуживании, используя разрешенные информационные сервисы.
T.COMMS Нарушитель может перехватить конфиденциальную информацию, передаваемую в процессе внешнего информационного обмена.
3.3. Политика безопасностиНиже приведены варианты политики безопасности, совместимые с ПЗ ОО.
P.OWNER ограничение физического доступа к офису с помощью пропускного режима
P.FIREWALL ограничение доступа злоумышленников из интернета, с помощью файрволаP.ANTIVIRUS Установка антивируса
P.SECURESTUDY Разъяснение сотрудникам об опасности установки несанкционированном ПО
P.EXECUTION , введение наказаний за разглашение информации
P.CUT_CONNECTION Разграничение доступа к секретной информации для всех пользователей, в том числе системного администратора
P.IBP Установка ИБП для предотвращения потери ценной информации.4. Цели безопасностиЦели безопасности для ООO.DONT_LOST препятствование каким бы то ни было информационным потерям
O.DONT_CHANGE препятствование пагубному изменению информации
O.DONT_PUBLIC препятствование опубликованию сведений
O.ONLINE поддержание оборудования в режиме постоянного функционирования.Цели безопасности для средыO.INSTALL Необходимо обеспечить установку, инсталляцию и администрирование ОО таким образом, чтобы обеспечить безопасное состояние защищаемой системы.
O.SECURE Необходимо осуществление контроля физического доступа к ОО.
O.TRAIN Необходимо, чтобы уполномоченные администраторы были обучены способам администрирования ОО, знали и могли реализовать утвержденную политику внешнего информационного обмена.
O.SUPPORT Необходимо обеспечить сопровождение установленного ОО в части решения проблем, возникающих в процессе эксплуатации ОО, оперативного мониторинга и исправления недостатков в программном обеспечении.
5. Требования безопасностиВ данном разделе приводятся функциональные требования и требования доверия, которым должен удовлетворять ОО, соответствующий ПЗ. Эти требования состоят из функциональных компонентов части 2 ОК и оценочного уровня доверия, содержащего компоненты доверия из части 3 ОК.
5.1. Функциональные требованияФункциональные требования состоят из компонентов части 2 ОК, приведенных в Таблице 2
Таблица 2: Компоненты функциональных требований ОО
Компонент Название
LIVE_ACCES Пропускной режим
MECH_BACKUP Резервное копирование
MECH_IBP Источник бесперебойного питания
SYS_FIREWALL ФайерволSYS_ANTIVIRUS Антивирус
5.1.1. Физическая защита офиса (LIVE)
LIVE_ACCES - Пропускной режим
LIVE_ACCES(1) Доступ к в офис предприятия должен быть организован таким образом, что посторонний человек не сможет проникнуть внутрь
5.1.2. Техническое оснащение офиса (MECH)MECH_BACKUP - Резервное копирование
MECH_BACKUP(1) Подразумевает установку дополнительного сервера на который будет производиться резервное копирование данных.
MECH_IBP – Источник бесперебойного питания
MECH_IBP(1) Должна быть произведена установка источника бесперебойного питания для обеспечения работоспособности офиса в случае неполадок с сетью электропитания.
5.1.3. Системные защитные средства(SYS)SYS_FIREWALL - ФайерволSYS_FIREWALL(1) Над коммутатором должен быть установлен файервол, которой будет препятствовать доступу из вне в ОО.
SYS_ANTIVIRUS - Антивирус
SYS_ANTIVIRUS(1) Установка антивируса, препятствующего заражению компьютеров и серверов вредоносным ПО.

5.2. Требования доверия к безопасностиКомбинация выбранных компонентов доверия к безопасности соответствует 3-му оценочному уровню доверия к безопасности (ОУД3), усиленному компонентом ADV_SPM.1 (Неформальная модель политики безопасности ОО) для удовлетворения зависимости функционального компонента FPT_FLS.1.
5.2.1. Управление конфигурацией (ACM)5.2.1.1. ACM_CAP.3 Средства контроля авторизации
ACM_CAP.3.1D Разработчик должен предоставить маркировку для ОО.
ACM_CAP.3.2D Разработчик должен использовать систему УК.
ACM_CAP.3.3D Разработчик должен представить документацию УК.
ACM_CAP.3.3C Документация УК должна включать в себя список конфигурации и план УК.
ACM_CAP.3.4C Список конфигурации должен содержать описание элементов конфигурации, входящих в ОО.
ACM_CAP.3.8ССвидетельство должно демонстрировать, что система УК действует в соответствии с планом УК.
ACM_CAP.3.9СДокументация УК должна содержать свидетельство, что система УК действительно сопровождала и продолжает эффективно сопровождать все элементы конфигурации.
ACM_CAP.3.10ССистема УК должна предусмотреть такие меры, при которых в элементах конфигурации могут быть сделаны только санкционированные изменения.
ACM_CAP.3.1ЕОценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
5.2.1.2. ACM_SCP.1 Охват УК объекта оценкиACM_SCP.1.1D Разработчик должен представить документацию УК.
ACM_SCP.1.1C Документация УК должна показать, что система УК, как минимум, отслеживает: представление реализации ОО, проектную документацию, тестовую документацию, документацию пользователя, документацию администратора и документацию УК.
ACM_SCP.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
5.2.2. Поставка и эксплуатация (ADO)5.2.2.1. ADO_DEL.1 Процедуры поставкиADO_DEL.1.1D Разработчик должен задокументировать процедуры поставки ОО или его частей пользователю.
ADO_DEL.1.2.D Разработчик должен использовать процедуры поставки.
ADO_DEL.1.1C Документация поставки должна содержать описание всех процедур, необходимых для поддержки безопасности при распространении версий ОО к местам использования.
ADO_DEL.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
5.2.2.2. ADO_IGS.1 Процедуры установки, генерации и запускаADO_IGS.1.1D Разработчик должен задокументировать процедуры, необходимые для безопасной установки, генерации и запуска ОО.
ADO_IGS.1.1C Документация должна содержать описание последовательности действий, необходимых для безопасной установки, генерации и запуска ОО.
ADO_IGS.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
ADO_IGS.1.2E Оценщик должен сделать независимое заключение, что процедуры установки, генерации и запуска приводят к безопасной конфигурации.
5.2.3. Разработка (ADV)5.2.3.1. ADV_FSP.1 Неформальная функциональная спецификацияADV_FSP.1.1D Разработчик должен представить функциональную спецификацию.
ADV_FSP.1.1C Функциональная спецификация должна содержать неформальное описание ФБО и их внешних интерфейсов.
ADV_FSP.1.2C Функциональная спецификация должна быть внутренне непротиворечивой.
ADV_FSP.1.3C Функциональная спецификация должна содержать описание назначения и методов использования всех внешних интерфейсов ФБО, обеспечивая, где это необходимо, детализацию результатов, нештатных ситуаций и сообщений об ошибках.
ADV_FSP.1.4C Функциональная спецификация должна полностью представить ФБО.
ADV_FSP.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
ADV_FSP.1.2E Оценщик должен сделать независимое заключение, что функциональная спецификация - точное и полное отображение функциональных требований безопасности ОО.
5.2.3.2. ADV_HDL.2 Проект верхнего уровняADV_HLD.2.1D Разработчик должен представить проект верхнего уровня ФБО.
ADV_HLD.2.1C Представление проекта верхнего уровня должно быть неформальным.
ADV_HLD.2.2C Проект верхнего уровня должен быть внутренне непротиворечивым.
ADV_HLD.2.3C Проект верхнего уровня должен содержать описание структуры ФБО в терминах подсистем.
ADV_HLD.2.4C Проект верхнего уровня должен содержать описание функциональных возможностей безопасности, предоставленных каждой подсистемой ФБО.
ADV_HLD.2.5C Проект верхнего уровня должен идентифицировать все базовые аппаратные, программно-аппаратные и/или программные средства, требуемые для реализации ФБО, с представлением функций, обеспечиваемых поддержкой механизмов защиты, реализуемых этими средствами.
ADV_HLD.2.6C Проект верхнего уровня должен идентифицировать все интерфейсы для подсистем ФБО.
ADV_HLD.2.7C Проект верхнего уровня должен идентифицировать, какие из интерфейсов подсистем ФБО являются видимыми извне.
ADV_HLD.2.8C Проект верхнего уровня должен содержать описание назначения и методов использования всех интерфейсов подсистем ФБО, обеспечивая, где это необходимо, детализацию результатов, нештатных ситуаций и сообщений об ошибках.
ADV_HLD.2.9C Проект верхнего уровня должен содержать описание разделения ОО на подсистемы, осуществляющие ПБО, и прочие.
ADV_HLD.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
ADV_HLD.2.2E Оценщик должен сделать независимое заключение, что проект верхнего уровня - точное и полное отображение функциональных требований безопасности ОО.
5.2.3.3. ADV_RCR.1 Неформальная демонстрация соответствияADV_RCR.1.1D Разработчик должен представить анализ соответствия между всеми смежными парами имеющихся представлений ФБО.
ADV_RCR.1.1C Для каждой смежной пары имеющихся представлений ФБО анализ должен демонстрировать, что все функциональные возможности более абстрактного представления ФБО, относящиеся к безопасности, правильно и полностью уточнены в менее абстрактном представлении ФБО.
ADV_RCR.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
5.2.3.4. ADV_SPM.1 Неформальная модель политики безопасности ООADV_SPM.1.1D Разработчик должен представить модель ПБО.
ADV_SPM.1.2D Разработчик должен демонстрировать соответствие между функциональной спецификацией и моделью ПБО.
ADV_SPM.1.1C Модель ПБО должна быть неформальной.
ADV_SPM.1.2C Модель ПБО должна содержать описание правил и характеристик всех политик ПБО, которые могут быть смоделированы.
ADV_SPM.1.3C Модель ПБО должна включать в себя логическое обоснование, которое демонстрирует, что она согласована и полна относительно всех политик ПБО, которые могут быть смоделированы.
ADV_SPM.1.4C Демонстрация соответствия между моделью ПБО и функциональной спецификацией должна показать, что все функции безопасности в функциональной спецификации являются непротиворечивыми и полными относительно модели ПБО.
ADV_SPM.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
5.2.4. Документация (AGD)5.2.4.1. AGD_ADM.1 Руководство администратораAGD_ADM.1.1D Разработчик должен представить руководство администратора, предназначенное для персонала системного администрирования.
AGD_ADM.1.1C Руководство администратора должно содержать описание функций администрирования и интерфейсов, доступных администратору ОО.
AGD_ADM.1.2C Руководство администратора должно содержать описание того, как управлять ОО безопасным способом.
AGD_ADM.1.3C Руководство администратора должно содержать предупреждения относительно функций и привилегий, которые следует контролировать в безопасной среде обработки информации.
AGD_ADM.1.4C Руководство администратора должно содержать описание всех предположений о поведении пользователя, которые связаны с безопасной эксплуатацией ОО.
AGD_ADM.1.5C Руководство администратора должно содержать описание всех параметров безопасности, контролируемых администратором, указывая, при необходимости, безопасные значения.
AGD_ADM.1.6C Руководство администратора должно содержать описание каждого типа относящихся к безопасности событий, связанных с выполнением обязательных функций администрирования, включая изменение характеристик безопасности сущностей, контролируемых ФБО.
AGD_ADM.1.7C Руководство администратора должно быть согласовано со всей другой документацией, представленной для оценки.
AGD_ADM.1.8C Руководство администратора должно содержать описание всех требований безопасности к среде ИТ, которые относятся к администратору.
AGD_ADM.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
5.2.4.2. AGD_USR.1 Руководство пользователяAGD_USR.1.1D Разработчик должен представить руководство пользователя.
AGD_USR.1.1C Руководство пользователя должно содержать описание функций и интерфейсов, которые доступны пользователям ОО, не связанным с администрированием.
AGD_USR.1.2C Руководство пользователя должно содержать описание применения доступных пользователям функций безопасности, предоставляемых ОО.
AGD_USR.1.3C Руководство пользователя должно содержать предупреждения относительно доступных для пользователей функций и привилегий, которые следует контролировать в безопасной среде обработки информации.
AGD_USR.1.4C Руководство пользователя должно четко представить все обязанности пользователя, необходимые для безопасной эксплуатации ОО, включая обязанности, связанные с предположениями относительно действий пользователя, содержащимися в изложении среды безопасности ОО.
AGD_USR.1.5C Руководство пользователя должно быть согласовано со всей другой документацией, представленной для оценки.
AGD_USR.1.6C Руководство пользователя должно содержать описание всех требований безопасности к среде ИТ, которые имеют отношение к пользователю.
AGD_USR.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

5.2.5. Поддержка жизненного цикла (ALC)5.2.5.1. ALC_DVS.1 Идентификация мер безопасностиALC_DVS.1.1D Разработчик должен иметь документацию по безопасности разработки.
ALC_DVS.1.1C Документация по безопасности разработки должна содержать описание всех физических, процедурных, относящихся к персоналу и других мер безопасности, которые необходимы для защиты конфиденциальности и целостности проекта ОО и его реализации в среде разработки.
ALC_DVS.1.2C Документация по безопасности разработки должна предоставить свидетельство, что необходимые меры безопасности соблюдаются во время разработки и сопровождения ОО.
ALC_DVS.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
ALC_DVS.1.2E Оценщик должен подтвердить применение мер безопасности.
5.2.6. Тестирование (ATE)5.2.6.1. ATE_COV.2 Анализ покрытияATE_COV.2.1D Разработчик должен представить анализ покрытия тестами.
ATE_COV.2.1C Анализ покрытия тестами должен демонстрировать соответствие между тестами, идентифицированными в тестовой документации, и описанием ФБО в функциональной спецификации.
ATE_COV.2.2C Анализ покрытия тестами должен демонстрировать полное соответствие между описанием ФБО в функциональной спецификации и тестами, идентифицированными в тестовой документации.
ATE_COV.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
5.2.6.2. ATE_DPT.1 Тестирование: проект верхнего уровняATE_DPT.1.1D Разработчик должен представить анализ глубины тестирования.
ATE_DPT.1.1C Анализ глубины должен показать достаточность тестов, идентифицированных в тестовой документации, для демонстрации, что ФБО выполняются в соответствии с проектом верхнего уровня.
ATE_DPT.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
5.2.6.3. ATE_FUN.1 Функциональное тестирование ATE_FUN.1.1D Разработчик должен протестировать ФБО и задокументировать результаты.
ATE_FUN.1.2D Разработчик должен представить тестовую документацию.
ATE_FUN.1.1C Тестовая документация должна состоять из планов и описаний процедур тестирования, а также ожидаемых и фактических результатов тестирования.
ATE_FUN.1.2C Планы тестирования должны идентифицировать проверяемые функции безопасности и содержать изложение целей тестирования.
ATE_FUN.1.3C Описания процедур тестирования должны идентифицировать тесты, которые необходимо выполнить, и включать в себя сценарии для тестирования каждой функции безопасности. Эти сценарии должны учитывать любое влияние последовательности выполнения тестов на результаты других тестов.
ATE_FUN.1.4C Ожидаемые результаты тестирования должны показать прогнозируемые выходные данные успешного выполнения тестов.
ATE_FUN.1.5C Результаты выполнения тестов разработчиком должны демонстрировать, что каждая проверенная функция безопасности выполнялась в соответствии со спецификациями.
ATE_FUN.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
5.2.6.4. ATE_IND.2 Выборочное независимое тестированиеATE_IND.2.1D Разработчик должен представить ОО для тестирования.
ATE_IND.2.1C ОО должен быть пригоден для тестирования.
ATE_IND.2.2C Разработчик должен представить набор ресурсов, эквивалентных использованным им при функциональном тестировании ФБО.
ATE_IND.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
ATE_IND.2.2E Оценщик должен протестировать необходимое подмножество ФБО, чтобы подтвердить, что ОО функционирует в соответствии со спецификациями.
ATE_IND.2.3E Оценщик должен выполнить выборку тестов из тестовой документации, чтобы верифицировать результаты тестирования, полученные разработчиком.
5.2.7. Оценка уязвимостей (AVA)5.2.7.1. AVA_MSU.1 Экспертиза руководствAVA_MSU.1.1D Разработчик должен представить руководства по применению ОО.
AVA_MSU.1.1C Руководства должны идентифицировать все возможные режимы эксплуатации ОО (включая действия после сбоя или ошибки в работе), их последствия и значение для обеспечения безопасной эксплуатации.
AVA_MSU.1.2C Руководства должны быть полны, понятны, непротиворечивы и обоснованы.
AVA_MSU.1.3C Руководства должны содержать список всех предположений относительно среды эксплуатации.
AVA_MSU.1.4C Руководства должны содержать список всех требований к внешним мерам безопасности (включая внешний контроль над процедурами, физическими мерами и персоналом).
AVA_MSU.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
AVA_MSU.1.2E Оценщик должен повторить все процедуры конфигурирования и установки для подтверждения, что ОО можно безопасно конфигурировать и использовать, применяя только представленные руководства.
AVA_MSU.1.3E Оценщик должен сделать независимое заключение, что использование руководств позволяет выявить все опасные состояния.
5.2.7.2. AVA_SOF.1 Оценка стойкости функции безопасности ООAVA_SOF.1.1D Разработчик должен выполнить анализ стойкости функции безопасности ОО для каждого механизма, идентифицированного в ЗБ как имеющего утверждение относительно стойкости функции безопасности ОО.
AVA_SOF.1.1C Для каждого механизма, имеющего утверждение относительно стойкости функции безопасности ОО, анализ должен показать, что ее стойкость достигает или превышает минимальный уровень стойкости, определенный в ПЗ/ЗБ.
AVA_SOF.1.2C Для каждого механизма, имеющего утверждение относительно конкретной стойкости функции безопасности ОО, анализ должен показать, что ее стойкость достигает или превышает конкретный показатель, определенный в ПЗ/ЗБ.
AVA_SOF.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
AVA_SOF.1.2E Оценщик должен подтвердить, что утверждения относительно стойкости корректны.
5.2.7.3. AVA_VLA.1 Анализ уязвимостей разработчикомAVA_VLA.1.1D Разработчик должен выполнить и задокументировать анализ поставляемых материалов ОО по поиску явных путей, которыми пользователь может нарушить ПБО.
AVA_VLA.1.2D Разработчик должен задокументировать местоположение явных уязвимостей.
AVA_VLA.1.1C Документация должна показать для всех идентифицированных уязвимостей, что ни одна из них не может быть использована в предполагаемой среде ОО.
AVA_VLA.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
AVA_VLA.1.2E Оценщик должен провести тестирование проникновения, основанное на анализе уязвимостей, выполненном разработчиком, для обеспечения учета явных уязвимостей.
Обоснование6.1. Обоснование целей безопасности
6.1.1. Обоснование целей безопасности для ООO.DONT_LOST Данная цель безопасности необходима для противодействия угрозам T.ElectroError, T.EvilSoft,T.LocalError ,T.DataLost, T.DataEvilEdition.
O.DONT_CHANGE Данная цель безопасности необходима для противодействия угрозам T.НСД,T.EvilSoft, T.DataEvilEdition.
O.DONT_PUBLICДанная цель безопасности необходима для противодействия угрозам T.SecureDataPublication.O.ONLINE Данная цель безопасности необходима для противодействия угрозам T.ElectroError, T.InternetError, T.LocalError, T.DataNoConnection , T.PrinterNoConnection.
6.1.2. Обоснование целей безопасности для средыO.INSTALL Средства контроля инсталляции и эксплуатации. Данная цель безопасности необходима для противодействия угрозам T.INSTALL и T.OPERATE.
O.SECURE Контроль физического доступа к ОО. Данная цель безопасности необходима для противодействия угрозам T.INSHARE и T.INALL.
O.TRAIN Обучение. Данная цель безопасности необходима для противодействия угрозам T.SERVICES, T.COMMS и T.INSHARE.
O.SUPPORT Сопровождение. Данная цель безопасности необходима для противодействия угрозе T.OPERATE.
6.2. Обоснование требований безопасности6.2.1. Обоснование функциональных требований MECH_BACKUP - Резервное копирование. Он непосредственно поддерживает цели безопасности O.DONT_CHANGE ,O.DONT_LOST
MECH_IBP – Источник бесперебойного питания. Он непосредственно поддерживает цели безопасности O.DONT_LOST, O.ONLINE.
SYS_FIREWALL – Файервол. Он непосредственно поддерживает цели безопасности O.DONT_PUBLIC,O.DONT_CHANGE ,O.DONT_LOST.
SYS_ANTIVIRUS – Антивирус. Он непосредственно поддерживает цели безопасности O.DONT_PUBLIC,O.DONT_CHANGE ,O.DONT_LOST.
6.2.2. Обоснование требований доверияОУД3, усиленный компонентом ADV_SPM.1 (Неформальная модель политики безопасности ОО), выбран для обеспечения независимо подтверждаемого среднего уровня доверия к безопасности на основе всестороннего исследования продукта и процесса его разработки без существенного изменения технологии разработки. В данном случае конечному пользователю доступны все отчетные материалы о разработке. Оценивание продукта может проводиться совместно с поставщиком.
Данный уровень предоставляет уверенность в безопасности посредством использования контроля среды разработки, управления конфигурацией продукта, свидетельства безопасных процедур поставки, предоставления документов руководства. Он требует более полного покрытия тестированием сервисов и механизмов безопасности, что дает определенную уверенность в отсутствии несанкционированных изменений продукта во время разработки.
Выбранный оценочный уровень доверия удовлетворяет всем функциональным зависимостям и не противоречит предполагаемой среде угроз.

Приложенные файлы

  • docx 26448120
    Размер файла: 491 kB Загрузок: 0

Добавить комментарий