Вопрос 30 Определение и классификация нарушителя. Модель нарушителя. Модель нарушителя в соответствии с рд фстэк.
Модель нарушителя. Виды: формальный и не формальный.
Формальная модель в соответствии с РД ФСТЭК Нарушитель правил разграничения доступа – субъект доступа, осуществляющий несанкционированный доступ к информации
Модель нарушителя правил разграничения доступа – абстрактное (формализованное или неформализованное) описание нарушителя правил разграничения доступа.
Источником всех угроз является человек или нарушитель - субъект, имеющий доступ к работе со штатными средствами АС и СВТ и являющийся специалистом высшей квалификации, знающим все о АС и, в частности, о системе и средствах ее защиты.
В РД ФСТЭК дается классификация нарушителя по уровню возможностей, предоставляемых ему штатными средствами АС и СВТ. Классификация является иерархической. Выделяется 4 уровня.
Первый уровень определяет самый низкий уровень - запуск программ из фиксированного набора, реализующих заранее предусмотренные функции по обработке информации .
Второй уровень определяется возможностью создания и запуска собственных программ с новыми функциями по обработке информации .
Третий уровень определяется возможностью управления функционированием АС, т.е. воздействием на базовое программное обеспечение системы и на состав и конфигурацию ее оборудования
Четвертый уровень определяется всем объемом возможностей лиц, осуществляющих проектирование, реализацию и ремонт технических средств АС, вплоть до включения в состав СВТ собственных технических средств с новыми функциями по обработке информации.
В своем уровне нарушитель является специалистом высшей квалификации, знает все об АС и, в частности, о системе и средствах ее защиты.
Неформальная модель нарушителя. При описании вводят несколько критериев по которым классифицируются нарушитель и затем создают обобщенную модель включающую несколько позиций классификации. Модели нарушителя должны быть определены след. образом: 1) предположение о категории лиц, к которым может принадлежать нарушитель. Категории нарушителей: внутренние, внешние 2) предположение о мотивах и целях действий нарушителя. 3)предположение о квалификации нарушителя, используемых им средствах и времени
Модель взаимоотношений собственника и нарушителя
Вопрос 31 Стандарты по безопасности информационных технологий. Основные положения ГОСТ Р ИСО/МЭК 15408. Структура профиля защиты и задания по безопасности. Структура и содержание функциональных требований. Структура и содержание требований доверия. ОУД.
Объект оценки (ОО) – подлежащий оценке продукт ИТ или система с руков-ми админа и польз-я.
Это стандарт по оценке безопасности ИТ. Состоит из 3 частей. Общее название для всех частей – «Информационные технологии. Методы и средства обеспечения безопасности. Критерии оценки безопасности ИТ». Каждая из 3 частей имеет собственное название.
«Введение и общая модель» - содержит сведения об области применения стандарта, устанавливает общий подход к формированию требований к оценке безопасности.
«Функциональные требования безопасности» - содержит универсальный систематизированный каталог функциональных требований безопасности и предусматривает возможность их детализации и расширения по определенным правилам.
«Требования доверия к безопасности» - систематизированный каталог требований доверия, определяющий меры, которые должны быть приняты на всех этапах жизненного цикла продукта для обеспечения уверенности в том, что они удовлетворяют предъявляемые к ним функциональные требования.
Профиль защиты содержит совокупность требований безопасности, взятых из ОК или сформулированных в явном виде, в которую следует включить ОУД. ПЗ позволяет выразить независимые от конкретной реализации требования безопасности для некоторой совокупности ОО полностью согласованные с набором целей безопасности. ПЗ предназначен для многократного использования и определения как функциональных требований, так и требований доверия к ОО, которые полезны и эффективны для достижения установленных целей. ПЗ также содержит логическое обоснование требований и целей безопасности.
Задание по безопасности содержит совокупность требований безопасности, которые могут быть определены ссылками на ПЗ, непосредственно на функциональные компоненты или компоненты доверия из ОК или же сформулированы в явном виде. ЗБ позволяет выразить для конкретного ОО требования безопасности, которые по результатам оценки ЗБ признаны полезными и эффективными для достижения установленных целей безопасности.
ЗБ содержит краткую спецификацию ОО совместно с требованиями и целями безопасности и логическим обоснованием для каждого из них. ЗБ является основой для соглашения между всеми сторонами относительно того, какую безопасность предлагает ОО.
Для структуризации пространства требований в Общих Критериях введена иерархия: класс-семейство-компонент-элемент. Классы определяют наиболее общую, как правило, предметную группировку требований. Семейства в пределах класса различаются по строгости и другим характеристикам. Компонент – минимальный набор требований, фигурирующий как единое целое. Элемент – это неделимое требование (внутри компонента). Между компонентами могут существовать зависимости, они возникают, когда компонент сам по себе недостаточен для достижения целей безопасности.
Вторая часть ОК описывает 11 классов, 66 семейств, 135 компонентов функциональных требований безопасности и содержит сведения о том, какие цели безопасности могут быть достигнуты при современном уровне современных технологий и каким образом. 1) FAU - аудит безопасности; 2) FIA - идентификация/аутентификация; 3) FRU - использование ресурсов; 4) FCO - связь; 5) FPR - приватность Высокоуровневые цели безопасности описываются в 2-х классах: 1) FDР – защита данных пользователя; 2) FРТ - защита функций безопасности ОО.
Классы требований, играющих инфраструктурную роль: 1) FCS – криптографическая поддержка; 2) FMT – управление безопасностью; 3) FTA – доступ к ОО, речь идет об управлении сеансами работ пользователей; 4) FTP – доверенный маршрут/канал.
Требования доверия безопасности составляют 3-ю часть содержания ОК и ГОСТ Р ИСО/МЭК 15408.
Требование доверия безопасности охватывает весь ЖЦ продукта системы ИТ и предполагает выполнение следующих действий:– оценивание ЗБ и ПЗ, являющиеся источниками требований безопасности объектов оценки; –анализирует различные представления проекта ОО и соответствия между ними, а также соответствие каждого из них требованиям безопасности; – проверяются процессы и процедуры безопасности, их применение; – анализируется документация; – верификация представленных доказательств; – анализируются тесты и их результаты; – анализируются уязвимости ОО; –проводится независимое тестирование, в том числе тестирование с проникновением.
Каждое требование (элемент доверия) принадлежит одному из трех типов: ~ элементы действия разработчика помечаются буквой D после номера элемента эти действия должны подтверждаться доказательным материалом (свидетельствами); ~ элементы представления и содержания свидетельств помечаются буквой С; ~ элементы действий оценщика – Е.
Требования доверия разделены на 10 классов, 44 семейства, 93 компонента. Условно классы можно сгруппировать в зависимости от охватываемых этапов ЖЦ ОО. К 1-й группе, логически предшествующей разработке и оценке, принадлежат классы АРЕ (оценка ПЗ) и АSЕ (оценка ЗБ). Во 2-ю – входят классы ADV (разработка), ALC(поддержка ЖЦ), АСМ (управление конфигурацией). К этапу получения, представления и анализа результатов разработки можно отнести AGD (руководство), АТЕ (тестирование), АVА (оценка уязвимостей). Требования к поставке, эксплуатации составляют содержание класса АDО. Класс АМА – поддержка доверия – включает требования, применяемые после сертификации ОО на соответствие общим требованиям.
Оценочные уровни доверия (ОУД),
ОУД 1, предусматривающий функц-ое тестирование, применим, когда треб-ся некоторая уверенность, что объект оценки работает безукоризненно, а угрозы безопасности не считаются серьезными.
ОУД 2 предусматривает структурное тестирование и доступ к части проектной документации и результатам тестирования разработчиком.
ОУД 3 предусматривающий систематическое тестирование и проверку, позволяет достичь максимально возможного доверия при использовании обычных методов разработки.
ОУД 4 предусматривает систематическое проектирование, тестирование и просмотр.
ОУД 5 – полуформальное проектирование и тестирование.
ОУД 6 характеризуется полуформальной верификацией проекта.
ОУД 7 предусматривающий формальную верификацию проекта, применим к разработке изделий ИТ для использования в ситуациях чрезвычайно высокого риска или там, где высокая ценность активов оправдывает повышенные затраты.