- •1. Основные понятия и определения
- •Протоколирование и аудит
- •2. Источники, риски и формы атак на информацию
- •Определение понятия атаки
- •2.2 Виды атак
- •Инициаторы атак
- •Системы обнаружения атак
- •2.5 Классификация ids по используемым механизмам обнаружения атак
- •Методы анализа и корреляция данных
- •2.7 Архитектура ids
- •2.8 Перспективы развития
- •Представление данных в системах обнаружения атак.
- •Принятие решений, прогнозирование атак.
- •3. Политика безопасности
- •3.1 Суть проблемы
- •3.2 Определение
- •Формирование рекомендаций по формированию политики безопасности, необходимое по и оборудования.
- •3.4 Дискреционная политика (Discretionary policy)
- •Политика mls. (Многоуровневая политика безопасности)
- •4. Стандарты безопасности (классификация систем защиты)
- •4.1 Документы гтк по защите информации [4]
- •4.2 Классификация систем защиты по "Оранжевой книге"
- •4.2.1 Выбор класса защиты
- •Международные стандарты
- •Новый подход к безопасности
- •4.3.2 Содержание и основные идеи "Общих критериев"
- •4.3.3 Функциональные требования общих критериев
- •4.3.4 Требования гарантии "Общих критериев"
- •4.3.5 Классы безопасности компьютерных систем
- •4.3.6 Перспективы Общих критериев
- •4.3.6 Использование стандарта ”Общих критериев” в снг
- •Р ис. 5а. Схема симметричного шифрования
- •5.1 Алгоритмы с секретным ключом
- •5.1.1 Алгоритмы блочного шифрования
- •Стойкость des
- •Гост-28147-89
- •5.2 Алгоритмы с открытым ключом
- •5.2.1 Стандарт ассиметричного шифрования rsa
- •5.2.1.1 Генерация ключей
- •5.3 Комбинированный метод
- •6. Электронная цифровая подпись
- •Положение о эцп в России
- •6.2 Технология обработки и обмена электронными документами
- •7. Алгоритмы аутентификации пользователей
- •Определение и основные типы аутентификации
- •7.1.2 Общие политики аутентификации в Интернете
- •7.1.3 Политика администрирования паролей
- •7.1.4. Политика для устойчивой аутентификации
- •7.2 Протокол аутентификации Kerberos
- •7.2.1 Преимущества протокола Kerberos, версия 5
- •7.2.2 Пример работы протокола
- •7. 2.3 Особенности реализации протокола Kerberos в Windows 2000
- •7. 2.4 Условия использования протокола Kerberos
- •8. Многоуровневая защита корпоративных сетей
- •8.1 Особенности корпоративных сетей.
- •8.1.1 Наличие централизованной справочной службы
- •8.1.2 Серверы приложений
- •8.1.3 Асинхронность
- •Служба безопасности
- •9. Защита информации в сетях
- •9.1 Межсетевые экраны.
- •9.2 Коммутаторы (канальный уровень).
- •9.3 Сетевые фильтры (сетевой уровень).
- •9.4 Шлюзы сеансового уровня (сеансовый уровень).
- •9.4.1 Фильтры контроля состояния канала связи
- •9.4.2 Шлюзы, транслирующие адреса или сетевые протоколы
- •9.4.3 Посредники сеансового уровня
- •9.4.4 Общие недостатки шлюзов сеансового уровня
- •9.5 Посредники прикладного уровня (прикладной уровень).
- •9.6 Инспекторы состояния
- •9.7 Другие возможности межсетевых экранов
- •10. Средства анализа защищенности
- •10.1 Механизмы работы
- •10.2 Этапы сканирования
- •11. Виртуальные частные сети
- •11.1 Основные подходы к построению vpn
- •11.2 Классификация по типу реализации.
- •11.3 Vpn в системах Windows 2000
- •11.3.1 Аутентификация
- •11.3.2 Использование коммутируемых соединений
- •11.3.4 Создание и настройка vpn-подключения
- •12. Защищенные протоколы
- •12.1 Протокол Рoint-to-point tunneling protocol (pртр)
- •12.1.1 Особенности архитектуры
- •12.1.2 Обеспечение безопасности
- •12.2 Протокол l2f
- •12.3 Протоклы ipSec
- •12.3.1 Распределение функций между протоколами ipSec
- •12.3.2 Безопасная ассоциация
- •12.3.3 Транспортный и туннельный режимы
- •12.4 Протокол Secure Socket Layer (ssl)
- •12.4.1 Принцип работы
- •13.1 Локальная безопасность на уровне системы
- •13.1.2 Остальные субъекты локальной безопасности
- •13.2 Безопасность на уровне домена
- •13.3 Безопасность на уровне домена и локальная безопасность
- •14. Безопасность в unix
- •14.1 Система идентификации и аутентификации в unix-подобных ос
- •14.1.1 Пользователи и группы
- •Добавление пользователей
- •14.1.3 Удаление пользователей
- •14.1.4 Группы
- •14.2 Безопасность файловой системы в unix-подобных ос
- •14.2.1 Атрибуты процессов и элементов файловой системы
- •14.3 Права доступа
- •14.3.1 Команды используемые для работы с правами доступа
- •3. Назначение прав доступа по умолчанию.
- •4. Изменение владельца файла и его группы
- •14.4 Доверительные отношения
4.2 Классификация систем защиты по "Оранжевой книге"
В период с 1983 по 1988 год в США Министерством обороны (Department of Defence, DoD) и Национальным комитетом по компьютерной безопасности (National Committee of Computer Security, NCSC) была разработана система стандартов в области компьютерной безопасности. Она включает следующие документы:
«Критерий оценки достоверных компьютерных систем» (Trusted Computer Systems Evaluation Criteria), больше известный как «Оранжевая книга», благодаря цвету своей обложки;
«Программа оценки безопасности продуктов»;
«Руководство по применению критерия оценки безопасности компьютерных систем в специфических средах», известный под названием «Желтая книга»;
комплект документов под общим названием «Радужная серия» (Rainbow Series; www.radium.ncsc.mil/tpep/library/ rainbow), включающий «Разъяснение критерия оценки безопасности компьютерных систем для безопасных сетей», «Разъяснение критерия оценки безопасности компьютерных сетей для безопасных СУБД», «Разъяснение критерия оценки безопасности компьютерных систем для отдельных подсистем безопасности».
Затем к этой системе добавлен еще ряд документов, уточняющих и развивающих положения оранжевой книги:
«Руководство по произвольному управлению доступом в безопасных системах» (A guide to understanding discretionary access control in trusted systems);
«Руководство по управлению паролями» (Password management guideline);
«Руководство по применению Критериев безопасности компьютерных систем в специфических средах» (Guidance for applying the Department of Defence Trusted Computer System Evaluation Criteria in specific environment);
«Руководство по аудиту в безопасных системах» (A Guide to Understanding Audit in Trusted Systems);
«Руководство по управлению конфигурацией в безопасных системах» (Guide to understanding configuration managment in trusted systems) и др.
В 1995 году Национальным центром компьютерной безопасности США опубликован документ под названием «Пояснения к критериям безопасности компьютерных систем», объединивший все имеющиеся на тот момент дополнения и разъяснения к «Оранжевой книге».
Остановимся подробнее на содержании «Оранжевой книги».
«Оранжевая книга» необходима:
пользователям, для того, чтобы они могли оценить степень доверия системе, выбираемой для обработки конфиденциальной информации;
производителям, чтобы они знали требования предъявляемые к системам защиты информации и учитывали это в своих коммерческих продуктах.
разработчикам стандартов для обеспечения основы разработки других стандартов в области безопасности.
Во всех документах МО США, связанных с ОК, понятие «обеспечение
безопасности информации» определяется следующей аксиомой:
Аксиома |
Электронная система обработки данных (ЭСОД)- называется безопасной, если она обеспечивает контроль за доступом информации так, что только надлежащим образом уполномоченные лица или процессы, которые функционируют от их имени, имеют право читать, писать, создавать или уничтожать информацию.
|
Из этой аксиомы вытекает шесть фундаментальных требований к защищенным ЭСОД. Прежде, чем формулировать их дадим несколько определений.
Определение |
Идентификация - это распознавание имени объекта. Идентифицируемый объект это однозначно распознаваемый объект. |
Определение |
Аутентификация - это подтверждение того, что предъявленное имя соответствует объекту. |
Определение |
Достоверная вычислительная база, TCB (Trusted Computing Base) – система, как совокупность механизмов защиты в вычислительной системе (включая аппаратную и программную составляющие), которые отвечают за поддержку политики безопасности. |
Определение |
Аудит - это регистрация событий, позволяющая восстановить и доказать факт происшествия этих событий. |
Выделяются два основных критерия оценивания достоверных систем:
политика безопасности (набор правил и норм, определяющих дисциплину обработки, защиты и распространения информации, а также выбор конкретных механизмов обеспечения безопасности; это активный компонент защиты);
гарантированность (степень доверия, которая может быть оказана конкретной реализации ОС; отражает уровень корректности механизмов безопасности; является пассивным компонентом защиты).
В соответствии с «Оранжевой книгой» выделяются три роли: системный администратор, системный оператор и администратор безопасности. Согласно требованиям TCSEC документация производителя должна включать в себя четыре важных элемента: политику безопасности; интерфейсы достоверной вычислительной базы; механизмы TCB; руководство по эффективному использованию механизмов TCB.
В “Оранжевой книге” выдвигаются 6 основных требований.
Политика безопасности - Необходимо иметь явную и хорошо определенную политику обеспечения безопасности, т. е. необходимо иметь набор правил, используемых системой, для того, чтобы определить, можно ли разрешить указанному субъекту доступ к конкретному объекту.
Маркировка - Для того, чтобы управлять доступом к информации в соответствии с правилами мандатной политики, должна быть предусмотрена возможность маркировать каждый объект меткой, которая надежно идентифицирует степень ценности объекта (например секретности) и/или режимы допуска, предоставленные тем субъектам, которые потенциально могут запросить доступ к объекту.
Идентификация - Каждый доступ к информации должен быть рассмотрен на предмет того, кто запрашивает доступ к информации и на какие классы информации он имеет право получить доступ. Такого рода идентифицирующая и санкционирующая информация обязательно должна присутствовать и надежно защищаться вычислительной системой. Эта информация должна быть связана с каждым активным элементом, выполняющим действия, имеющие отношение к безопасности системы.
Подотчетность - Защищенная система должна быть в состоянии регистрировать в аудиторском файле появление событий, имеющих отношение к безопасности системы. Аудиторская информация должна быть защищена от модификации, несанкционированного уничтожения, чтобы позволять выявлять и исследовать нарушения правил безопасности.
Гарантии - Для того, чтобы гарантировать, что рассмотренные выше 4 требования по безопасности (политика, маркировка, идентификация и аудит) реализуются вычислительной системой, необходимо предусмотреть корректно определенный и объединенный в единое целое набор программных и аппаратных средств управления, реализующий указанные функции. Эти механизмы должны быть соответствующим образом документированы, чтобы была возможность провести независимый анализ их работы.
6) Постоянная защита - Механизмы, реализующие указанные базовые требования, должны быть постоянно защищены от «взлома» и/или несанкционированного внесения изменений.
Класс защищенности присваивается системе, при прохождении ею сертификации. Во время сертификации специалисты NCSC на основании представленных исходных текстов программ и документации на систему оценивают уровень реализации той или иной возможности системы по защите информации.
Следует отметить, что сертификации подвергается вся система в целом, а класс защищенности присваивается только в том случае, когда самый «слабый» показатель удовлетворяет требованиям класса защищенности.
Класс D |
Минимальная защита |
Класс D присваивается тем системам, которые не прошли испытаний на более высокий уровень защищенности, а также системы, использующие для защиты лишь отдельные функции (подсистемы) безопасности. |
|
Класс С1 |
Защита основанная на разграничении доступа |
Средства защиты систем класса С1 удовлетворяют требованиям избирательной политики управления доступом, обеспечивая разделение пользователей и данных. Избирательная политика управления доступом заключается в том, что для каждого объекта и субъекта в системе явно и недвусмысленно задается перечень допустимых типов доступа (чтение, запись и др.) субъекта к объекту. В системах этого класса обязательна идентификация и аутентификация субъекта доступа, а также поддержка со стороны оборудования. Среда класса С1 предназначена для пользователей, обрабатывающих данные одного уровня секретности.
Политика обеспечения безопасности: дискреционная.
Идентификация и аутентификация: TCB должна требовать от пользователей, чтобы те идентифицировали себя перед тем, как начинать выполнять какие-либо действия, в которых TCB предполагает быть посредником. Более того, TCB обязательно должна использовать один из механизмов аутентификации (например пароли) для того, чтобы проверять подлинность идентификации пользователей. TCB должна защищать аутентификационные данные таким образом, чтобы доступ к ним со стороны пользователя, не имеющего на это полномочий, был невозможен.
Архитектура системы: TCB должна содержать домен, который должен обеспечивать ее собственную работу и защищать ее от внешнего воздействия или от внесения в нее несанкционированных изменений. Целостность системы: должны быть предусмотрены аппаратные и/или программные средства, предназначенные для периодической проверки на правильность и корректность функционирования аппаратных и микропрограммных элементов TCB. Тестирование функций безопасности: механизм защиты должен соответствовать описанию содержащемуся в документации. Виды документации: 1) Руководство пользователя по использованию средств обеспечения безопасности. 2) Руководство администратора системы на средства защиты. В руководстве ориентированном на администратора, должно содержаться описание мер предосторожности и полномочий, которые необходимо контролировать в процессе функционирования. 3) Документация по тестам. Разработчик системы должен предусмотреть для лиц, занятых оцениванием безопасности системы, документ, в котором дается описание плана тестирования, процедур тестирования, излагающих каким способом проверяются механизмы обеспечения безопасности, и где представлены итоговые результаты функционального тестирования механизмов обеспечения безопасности. 4) Документация по проекту. В наличии должна быть документация, в которой имеется описание основополагающих принципов защиты, выбранных изготовителем данного средства или системы, а также объяснение того, как эти принципы реализованы. Если TCB состоит из нескольких модулей, то должно быть дано описание интерфейсов между этими модулями.
|
|
Класс С2 |
Защита, основанная на управляемом доступе |
К требованиям класса C1 добавляются требования уникальной идентификации субъекта доступа, защиты по умолчанию и регистрации событий.
Уникальная идентификация означает, что любой пользователь системы должен иметь уникальное имя. Защита по умолчанию предполагает назначение полномочий доступа пользователям по принципу “все что не разрешено, то запрещено“. Все те ресурсы, которые явно не разрешены пользователю полагаются недоступными.
В системах этого класса обязательно ведение системного журнала, в котором должны отмечаться события, связанные с безопасностью системы. Данные журнала должны быть защищены от доступа любых пользователей, за исключением администратора системы. |
|
Системы класса B
Помимо требований предъявляемых к системам класса C2, системы класса B характеризуются реализацией в них полномочной модели управления доступом, при которой каждый субъект и объект системы снабжается метками конфиденциальности и решение на доступ субъекта к объекту принимается по определенному правилу на основе сопоставления информации, содержащихся в обеих метках. При этом оборудование должно обеспечить целостность меток безопасности и использование их при разграничении доступа.
Класс B1 |
Меточная защита |
Метки безопасности должны быть присвоены всем субъектам и объектам системы, которые могут содержать или получать конфиденциальную информацию. При этом должно контролироваться соответствие меток на данных, экспортируемых из системы с устройствами, на которые осуществляется вывод. Метка безопасности на вводимые данные запрашивается у пользователя. |
|
Класс B2 |
Структурированная защита |
Дополнительно к требованиям класса B1 предъявляется требование наличия хорошо определенной и документированной формальной модели политики безопасности, требующей действия избирательного и полномочного управления доступом ко всем объектам системы. Помимо этого, должен быть проведен анализ, связанный с наличием побочных каналов утечки информации. Система должна быть четко разделена на критичные и некритичные к защите элементы. Также предъявляются дополнительные требования по защите механизмов аутентификации. Интерфейс с TCB должен быть хорошо документирован.
|
|
Класс B3 |
Домены безопасности |
В системах этого класса в оборудовании должна быть реализована концепция монитора обращений (reference monitor):
Из системы защиты должен быть исключен код, который не требуется для обеспечения поддержки политики безопасности. Механизмы регистрации событий безопасности должны сразу же оповещать администратора и пользователей о нарушении безопасности. Обязательным также является наличие процедур, обеспечивающих восстановление работоспособности системы. |
|
Класс А1 |
Верифицированный проект. |
Системы класса А1 отличаются от систем класса B3 тем, что для Проверки правильности функционирования системы защиты применяются формальные методы. Предусматриваются также специальные процедуры по безопасному размещению систем в местах дислокации. |
|