- •1. Актуальность защиты информации. Предпосылки кризиса систем защиты информации (сзи). Современные требования к сзи.
- •Электромагнитные каналы утечки информации
- •5. Факторы, воздействующие на информацию (гост р 51275-99). Внешние, внутренние, объективные и субъективные.
- •8. Парольные системы. Методы компрометации паролей и защиты от нее. Количественная оценка стойкости парольных систем.
- •9. Аудит: регистрация потенциально опасных событий в компьютерной системе, необходимость, требования, политика аудита.
- •Мандатное управление доступом
- •(Принудительное, нормативное, меточное)
- •Метки безопасности
- •Мандатное управление доступом
- •Отличие от дискреционной защиты
- •12. Ролевое управление доступом (rbas). Основные понятия. Статическое и динамическое разделение обязанностей. Ролевое управление доступом
- •2.5.2. Таксономия требовании и критериев «Оранжевой книги»
- •2.5.2.1. Политика безопасности
- •2.5.2.2. Аудит
- •2.5.2.3. Корректность
- •2.5.2.4. Таксономия критериев безопасности
- •2.5.3. Классы безопасности компьютерных систем
- •2.6.2. Функциональные критерии
- •2.6.3. Критерии адекватности
- •4. Нормативное закрепление основополагающих принципов информационной
- •18. Канадские критерии безопасности компьютерных систем ctcpec. Таксономия функциональных критериев и критериев адекватности реализации системы безопасности информации. Уровни адекватности т0-т7.
- •2.9.2. Базовые понятия «Канадских критериев»
- •2.9.2.1 Объекты и субъекты
- •2.9.3. Основные положения и структура «Канадских критериев»
- •19. Концепция защиты от нсд к информации (рд гтк рф). Два направления - ас и свт. Модель нарушителя: уровни возможностей.
- •2.7.2. Таксономия критериев и требований безопасности
- •1. Классификация ас
- •2. Требования по защите информации от нсд для ас
- •1. Общие положения
- •1. Общие положения
- •2.Термины и определения
- •24. Испытания программных средств на наличие компьютерных вирусов (гост р 51188-98). Виды вирусов и методы испытаний.
- •1. Классификация авс
- •2. Требования по защите ас от вирусов
- •26. Специальные защитные знаки (сзз) (рд гтк рф). Классификация по возможности подделки, идентифицируемости и стойкости защитных свойств. Применение на объектах различной категории.
- •27. Гост р 15408:2002. Часть 1. Методология оценки безопасности ит. Области применения стандарта «Общие критерии».
- •28. Гост р 15408:2002. Часть 1. Последовательность формирования требований и спецификаций: среда безопасности, цели безопасности, требования безопасности ит и краткая спецификация оо.
- •29. Гост р 15408:2002. Часть 1. Представление требований безопасности: классы, семейства, компоненты, элементы. Виды связей и зависимостей между компонентами, разрешенные операции с компонентами.
- •30. Гост р 15408:2002. Часть 1. Источники требований безопасности. Виды оценок: пз, зб, оо. Поддержка доверия.
- •31. Гост р 15408:2002. Часть 1. Особенности пз. Структура пз: введение, описание оо. Среда безопасности оо, цели безопасности, требования безопасности оо, замечания по применению, обоснование.
- •Функциональные компоненты безопасности
- •Структура класса
- •Структура семейства
- •Структура компонента
- •Разрешенные операции с функциональными компонентами
- •35. Гост р 15408:2002. Часть 3. Парадигма доверия в стандарте. Основные принципы стандарта. Значимость уязвимостей. Причины возникновения уязвимостей. Подход к доверию в стандарте. Роль оценки.
- •36. Гост р 15408:2002. Часть 3. Представление требований доверия к безопасности. Структура класса, семейства, компонента, элемента и оценочных уровней доверия.
- •Требования доверия к безопасности
- •38. Гост р 15408:2002. Часть 3. Обзор оценочных уровней доверия (оуд1 - оуд7). Примерное соответствие классам «Оранжевой книги», Европейских критериев и рд гтк рф.
-
Структура компонента
Идентификация компонента
Идентификация компонента включает описательную информацию, необходимую для идентификации, категорирования, записи и реализации перекрестных ссылок компонента. Для каждого функционального компонента представляется следующее.
Уникальное имя. Имя отражает предназначение компонента.
Краткое имя. Уникальная краткая форма имени функционального компонента. Это краткое имя служит как основное имя ссылки для категорирования, записи и реализации перекрестных ссылок компонента. Оно отражает класс и семейство, которым компонент принадлежит, а также номер компонента в семействе.
Список иерархических связей. Список других компонентов, для которых этот компонент иерархичен, и вместо которых он может использоваться при удовлетворении зависимостей от перечисленных компонентов.
Функциональные элементы
Каждый компонент включает набор элементов. Каждый элемент определяется отдельно и является самодостаточным.
Функциональный элемент – это функциональное требование безопасности, дальнейшее разделение которого не меняет значимо результат оценки. Он является наименьшим функциональным требованием безопасности, идентифицируемым и признаваемым в настоящем стандарте.
При формировании ПЗ, ЗБ и/или пакетов не разрешается выбирать только часть элементов компонента. Для включения в ПЗ, ЗБ или пакет необходимо выбирать всю совокупность элементов компонента.
Вводится уникальная краткая форма имени функционального элемента. Например, имя FDP_IFF.4.2 читается следующим образом: F – функциональное требование, DP – класс "Защита данных пользователя", _IFF – семейство "Функции управления информационными потоками", .4 – 4-ый компонент "Частичное устранение неразрешенных информационных потоков", .2 – 2-ой элемент компонента.
Зависимости
Зависимости среди функциональных компонентов возникают, когда компонент не самодостаточен и нуждается либо в функциональных возможностях другого компонента, либо во взаимодействии с ним для поддержки собственного выполнения.
Каждый функциональный компонент содержит полный список зависимостей от других функциональных компонентов и компонентов доверия. Некоторые компоненты могут иметь список "Нет зависимостей". Компоненты из списка, могут, в свою очередь, иметь зависимости от других компонентов. Список, приведенный в компоненте, показывает прямые зависимости, т.е. содержит ссылки только на те функциональные компоненты, которые заведомо необходимы для обеспечения выполнения рассматриваемого компонента. Косвенные зависимости, определяемые собственными зависимостями компонентов из списка, прослежены в приложении А к этой части стандарта. Отметим, что в некоторых случаях зависимость выбирается из нескольких предлагаемых функциональных компонентов, причем каждый из них достаточен для удовлетворения зависимости (см., например, FDP_UIT.1).
Список зависимостей идентифицирует минимум функциональных компонентов или компонентов доверия, необходимых для удовлетворения требований безопасности, ассоциированных с данным компонентом. Компоненты, которые иерархичны по отношению к компоненту из списка, также могут быть использованы для удовлетворения зависимости.