13. Задание по безопасности для изделия ит.

Задание по безопасности — совокупность требований безопасности и спецификаций, предназначенная для использования в качестве основы для оценки конкретного ОО.

ЗБ содержит совокупность требований безопасности.

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

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

ЗБ является основой для соглашения между всеми сторонами относительно того, какую безопасность предлагает ОО.

14. Структура и содержания типичного профиля защиты.

15. Структуры и содержания типичного задания по безопасности.

16. Класс функциональных требований: аудит безопасности

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

Класс можно разложить на следующие составляющие:

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

2. Генерация данных аудита безопасности — определяет требования по регистрации возникновения событий, относящихся к безопасности, которые подконтрольны ФБО. Это семейство идентифицирует уровень аудита, перечисляет типы событий, которые потенциально должны подвергаться аудиту с использованием ФБО, и определяет минимальный объем связанной с аудитом информации, которую следует представлять в записях аудита различного типа.

3. Анализ аудита безопасности — определяет требования для автоматизированных средств, которые анализируют показатели функционирования системы и данные аудита в целях поиска возможных или реальных нарушений безопасности. Этот анализ может использоваться для поддержки как обнаружения проникновения, так и автоматической реакции на потенциальное нарушение безопасности.

4. Просмотр аудита безопасности — определяет требования к средствам аудита, к которым следует предоставить доступ уполномоченным пользователям для использования при просмотре данных аудита.

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

6. Хранение данных аудита безопасности — определяет требования, при выполнении которых ФБО способны создавать и сопровождать журнал аудита безопасности. Под хранимыми записями аудита понимаются записи в журнале аудита, но не записи аудита, которые были загружены (во временную память) в процессе выбора.

17. Класс функциональных требований: связь и криптографическая поддержка.

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

Доказательство (неотказуемость) отправления — обеспечивает невозможность отрицания отправителем информации факта ее отправления. Данное семейство содержит требование, чтобы ФБО обеспечили метод предоставления субъекту-получателю свидетельства отправления информации. Это свидетельство может быть затем верифицировано этим субъектом или другими субъектами. Разбивается на избирательное (возможность запросит проверку) и принудительное (всегда проверять).

Доказательство (неотказуемость) получения — обеспечивает невозможность отрицания получателем информации факта ее получения. Данное семейство содержит требование, чтобы ФБО обеспечили метод предоставления субъекту-отправителю свидетельства получения информации. Это свидетельство может быть затем верифицировано этим субъектом или другими субъектами. так же бывает избирательным и принудительным.

Класс криптографической поддержки состоит из двух семейств:

«Управление криптографическими ключами» и «Криптографические операции». В семействе «Управление криптографическими ключами» рассмотрены аспекты управления криптографическими ключами, тогда как в семействе «Криптографические операции» рассмотрено практическое применение этих криптографических ключей.

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

Жизненный цикл ключа: создание → распределение → хранение → уничтожение.

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

18. Класс функциональных требований: защита данных пользователя.

Класс «Защита данных пользователя» содержит семейства, определяющие требования, связанные с защитой данных пользователя. Класс «Защита данных пользователя» разбит на четыре группы семейств (перечислены ниже), применяемые к данным пользователя в пределах ОО при их импорте, экспорте и хранении, а также к атрибутам безопасности, прямо связанным с данными пользователя.

Данный класс как уже было сказано содержит четыре группы семейств:

1. Политики функций безопасности для защиты данных пользователям — в данной группе находятся семейства «политики управления доступом» и «политики управления информационными потоками» которые отвечают за описание соответствующих политик.

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

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

4. Связь между Функциями Безопасности Объекта — Семейства данной группы отвечают за взаимодействие ФБО, а именно за целостность и конфиденциальности передачи данных между ФБО.

19. Класс функциональных требований: идентификация и аутентификация.

Семейства этого класса связаны с определением и верификацией идентификаторов пользователей, определением их полномочий на взаимодействие с ОО, а также с правильной ассоциацией атрибутов безопасности с каждым уполномоченным пользователем. Эффективность требований других классов (таких, как «Защита данных пользователя», «Аудит безопасности») во многом зависит от правильно проведенных идентификации и аутентификации пользователей.

Данный класс состоит из семейств:

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

2. Определение атрибутов пользователя — определяет требования для ассоциации атрибутов безопасности с пользователями в соответствии с необходимостью поддержки ФТБ при принятии решений по безопасности. (атрибуты — дополнительные характеристики субъекта, помимо идентификатора).

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

4. Аутентификация пользователя — определяет типы механизмов аутентификации пользователя, предоставляемые ФБО. Оно также определяет те атрибуты, на которых необходимо базировать механизмы аутентификации пользователя.

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

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

20. Класс функциональных требований: управление безопасностью.

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

Данный класс состоит из:

1. Управление отдельными функциями ФБО — позволяет уполномоченным пользователям управлять функциями из числа ФБО. К ним относятся, например, функции аудита и аутентификации.

2. Управление атрибутами безопасности — позволяет уполномоченным пользователям управлять атрибутами безопасности. Такое управление может включать в себя возможности просмотра и модификации атрибутов безопасности. (сюда относится не только изменение атрибутов, но и проверка безопасности атрибутов (типо как ss ds * свойства) и их наследование)

3. Управление данными ФБО — позволяет уполномоченным пользователям (ролям) управлять данными ФБО. Примеры данных ФБО: информация аудита, текущее значение времени, другие параметры конфигурации ФБО.

4. Отмена — связано с отменой атрибутов безопасности различных сущностей в пределах ОО.

5. Срок действия атрибута безопасности — связано с возможностью установления срока действия атрибутов безопасности.

6. Спецификация функций управления — позволяет специфицировать функции управления, предоставляемые ОО. Если вкратце, то тут речь идет о возможности изменения атрибутов ФБО, то есть проведение настройки ФБО. Так же сюда относят функции резервирования и восстановления данных.

7. Роли управления безопасности — предназначено для управления назначением различных ролей пользователям. Возможности этих ролей по управлению безопасностью описаны в других семействах этого класса.

21. Класс функциональных требований: приватность.

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

Состоит из семейств отвечающих за:

1. Анонимность — обеспечивает, чтобы пользователь мог использовать ресурс или услугу ОО без раскрытия своего идентификатора. Требования семейства предоставляют защиту идентификатора пользователя. Семейство не предназначено для защиты идентификаторов субъектов. Тут есть два уровня защиты: невозможность определения идентификатора пользователя связанного с чем либо и ужесточение данного уровня путем запрета запроса идентификатора.

2. Псевдонимность — обеспечивает, чтобы пользователь мог использовать ресурс или услугу без раскрытия своего идентификатора, оставаясь в то же время ответственным за это использование. Смысл в том, что несмотря на поддержание анонимности по отношению к другим пользователям, система могла определить кто ответственен за те или иные действия. (обратимая псевдонимность).

3. Невозможность ассоциации — обеспечивает, чтобы пользователь мог неоднократно использовать ресурсы или услуги, не давая в то же время никому возможности связать вместе их использование. (если вкратце: псевдонимы должны меняться и их должно быть несколько для разных действий в системе, иначе со временем можно связать псевдоним с идентификатором)

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

22. Класс функциональных требований: защита функций безопасности объекта.

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

В рамках этого класса выделяются три существенные составные части ФБО:

1. Реализация ФБО, которая выполняется на абстрактной машине и реализует механизмы, осуществляющие ПБО.

2. Данные ФБО, которые являются административными базами данных, управляющими осуществлением ПБО.

3. Внешние сущности, с которыми может взаимодействовать ФБО для выполнения ФТБ.

Семейства(их тут много но большинство понятно из названия):

1. Безопасность при сбое

2. Доступность экспортируемых данных ФБО

3. Конфиденциальность экспортируемых данных ФБО

4. Целостность экспортируемых данных ФБО (тут разделение на «обнаружение» и «обнаружение и исправление»)

5. Передача данных ФБО в пределах ОО («базовая защита при передаче», «разделение данных при передаче», «контроль целостности при передаче»)

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

7. Надежное восстановление («автоматическое» и «ручное» восстановление после сбоев, либо «восстановление функций» которое позволяет корректно завершить часть функций при сбое, а остальные откатить до безопасного состояния)

8. Обнаружение повторного использования (это избавление от запросов типа «а жмякну ка я не 2, а 22 раза, мб быстрее откроется»)

9. Протокол синхронизации состояний — тут речь о проблемах распределенных систем. Из-за сильной физической удаленности компонентов друг от друга появляются задержки, из-за которых возможна ситуация при которой изменение ФБО произойдет только в части системы. Данные проблемы решаются путем получения НАДЕЖНОГО подтверждения об изменениях от всех частей системы. Подтверждение бывают двусторонние и односторонние(только со стороны получателя)

10. Метки времени

11. согласованность данных ФБО между ФБО

12. Тестирование внешних сущностей

13. Согласованность данных ФБО при дублировании в пределах ОО

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

23. Класс функциональных требований: использование ресурсов и доверенный маршрут.

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

1. Семейство «Отказоустойчивость» предоставляет защиту от недоступности ресурсов, вызванной сбоем ОО.

2. Семейство «Приоритет обслуживания» обеспечивает, чтобы ресурсы выделялись наиболее важным или критичным по времени задачам и не могли быть монополизированы задачами с более низким приоритетом.

3. Семейство «Распределение ресурсов» устанавливает ограничения использования доступных ресурсов, предотвращая монополизацию ресурсов пользователями.