 |
Стандарты информационной безопасности.
|
|
|
|
Стандарты нужны для того, что бы
1) Обычно являются результатом формализации опыта специалистов той или иной области, поэтому представляют собой источник надежных решений.
2) Стандарты являются одним из основных механизмов обеспечения совместимости различных продуктов и систем от разных производителей.
Стандарты информационной безопасности разделяются на оценочные и спецификации.
Оценочные - предназначены для оценки и классификации автоматизированных систем и средств защиты информации по требованиям безопасности (оранжевая книга, еще какая то шляпа).
Спецификации – регламентируют различные аспекты реализации использования средств и методов защиты.
ГОСТ 28147-89, ISO 17799, ISO 27001.
Перечислим основные стандарты в области информационной безопасности имеющие в настоящее время официальный статус в РФ:
1) ГОСТ Р ИСО /МЭК 15408-2002 – более известные как общие критерии. Действует и применяется при проведении сертификации средств защиты не предназначенных для работы с информацией, представляющей собой государственную тайну.
2) ГОСТ 28147 – 89 – стандарт симметричного шифрования.
3) ГОСТ 3410-2001 – стандарт ассиметричного шифрования
4) ГОСТ 3411-94 – шифрование хэш-функции.
5) Руководящие документы гостехкомиссии России. Применяются при проведении сертификации средств защиты. Федеральная служба экспертного контроля ФСТЭК.
Являются обязательными для применения в системах защиты информации, позиционируемых как средства криптографической защиты.
ГОСТ Р ИСО /МЭК 17799-2005 – информационные и практические правила управления информационной безопасностью.
ГОСТ Р ИСО /МЭК 27001-2006 – информационные технологии, методы и средства осуществления безопасности. Система менеджмента информационной безопасности и требования.
|
|
|
Стандарт “Оранжевая книга” – критерий оценки доверенных компьютерных систем. Разработан министерством обороны США в 1983 году и стал первым общедоступным оценочным стандартом в области информационной безопасности.
Стандарт «общие критерии»
ISO / IFC 15408 – 1999. Разработан совместными усилиями канадских, американских, нидерландских и германских специалистов. Развитие стандарта непрерывно продолжается. В России аутентичный перевод общих критериев версии 2.0 прият в качестве ГОСТ в 2002 году и введен в действие 1 января 2004 года. ГОСТ ИСО/МЭК 15408 – 2002. «информационные технологии методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий». Документ состоит из 3 частей:
1) Введение и общая модель.
2) Функциональное требование безопасности.
3) Доверие к безопасности.
Основное свойство общих критериев – максимально возможная универсальность. Водится понятия объекта оценки (ОО). Понимается произвольный продукт информационных технологий или система с руководствами администратора и пользователя. Предполагается, что критерии могут быть использованы следующими категориями пользователей:
1) Потребители. Общие критерии определяет требования безопасности для потребителя.
2) Разработчики. Используют критерии для формирования утверждения о соответствии ОО соответствующим требованиям.
3) Оценщики – формирую заключение, что ОО соответствует предъявляемым требованиям.
ОО рассматривается в контексте среды безопасности, в которую он включается. Законодательная среда – законы и нормативные акты, затрагивающие объект оценки. Административная среда – политика безопасности, затрагивающая объект оценки и учитывающая его особенности. Процедурная среда – меры физической защиты, персонал и его специфика. При подготовке к оценке формулируются следующие аспекты. При подготовке формируются следующие аспекты среды оценки:
|
|
|
1) Предположение безопасности. Выделяют объект ОО из общей системы, задают границы его рассмотрения.
2) Угроза безопасности. Формируются аспекты среды. Выделяют угрозы, наличие которых установлено или предполагается. каждая угроза характеризуется следующими параметрами: источник угрозы, предполагаемый способ реализации, уязвимости которые являются предпосылкой реализации угрозы, активы которые являются целью нападения, нарушаемые свойства безопасности, последствия реализации угрозы.
3) Политика безопасности. Излагаются положениями политики безопасности, применяемые в организации, которые имеют непосредственное отношение к модели оценки.
На основании сформулированных предположениях безопасности с учетом угроз и политик формируется цели безопасности для ОО. Для достижения целей к объекту оценки и его среде предъявляются требования безопасности следующих типов:
Часть 2. Функциональные требования.
Соответствуют активному аспекту защиты и применяются к функциям безопасности объекта оценки и реализующим его механизмам.
Часть 3. Требования доверия.
Предъявляются к технологии и процессу реализации, эксплуатации и оценке объекту оценки. Призваны гарантировать адекватность механизмов безопасности.
При формировании требований к ОО могут быть разработаны 2 документа:
1) профиль защиты и задания по безопасности. Представляет собой типовой набор требований, которым должны удовлетворять продукты или системы определенного класса (ОС). Профиль защиты не привязан к конкретному объектов оценки. Представляет собой обобщенный стандартный набор функциональных требований и требований доверия. Например профиль защиты на межсетевой экран.
2) Задание по безопасности – документ, содержащий требования безопасности для конкретного объекта оценки и определяют функции безопасности и меры доверия.
Для структурирования пространства требований в общих критериях введены понятия класса, семейства, компонента и элемента. Класс определят наиболее общие группировки требований. Семейство в пределах класса разделяются по строгим нюансам требований. Компонент – минимальный набор требований, фигурирующий как целое. Элемент – неделимое целое.
|
|
|
Функциональные требования – сгруппированы на основе выполняемой ими роли или обслуживаемые цели безопасности. В общих критериях представлено 11 классов, 66 семейств и 135 компонентов функциональных требований. Перечислим классы:
1) Идентификация и аутентификация.
2) Защита данных пользователя
3) Защита функций безопасностей.
4) Управление безопасностью.
5) Аудит безопасности.
6) Доступ к объекту оценки.
7) Класс приватность – защита от раскрытия и несанкционированного доступа к данным.
8) Использование ресурсов.
9) Криптографическая поддержка.
10) Связь.
11) Доверенный маршрут канал.
Класс приватность содержит 4 семейства функциональных требований.
1) Анонимность позволяет выполнять действия без раскрытия идентификатора пользователя другим пользователем субъектом – объектом.
2) Семейство “псевдонимность” – почти как анонимность, но применение псевдонима поддерживается ссылка на идентификатор пользователя.
3) Невозможность ассоциации – обеспечивает возможность неоднократного использования сервисов и не позволяет ассоциировать случаи между собой и приписывать очередному лицу.
4) Скрытность – требования направлены на то, чтобы можно было использовать сервис со скрытием факта использования.
Функциональные требования не сгруппированы в осмысленные наборы, в которых могло бы применяться наследование. Это чревато появлением слишком большого числа комбинации функциональных компонентов, не сопоставимых между собой.
Требования доверия. Форма представления требований доверия такая же как у функциональных требований, но специфика состоит в том, что каждый элемент требований принадлежит 1 из 3 типов: действия разработчиков, представления и содержания свидетельств, действия оценщиков.
Всего содержат 10 классов, 44 семейства и 93 компонента. Перечислим основные классы:
1) Разработка.
2) Поддержка жизненного цикла.
3) Тестирование
|
|
|
4) Оценка уязвимостей.
5) Поставка и эксплуатация.
6) Управление конфигурацией.
7) Руководство.
8) Поддержка доверия.
9) Оценка профиля защиты.
10) Оценка задания по безопасности.
Применительно к требованиям доверия введены оценочные уровни доверия. Их всего 7 и они содержат осмысленные комбинации компонентов.
Оценочный уровень доверия 1. Предусматривает анализ функциональной спецификации, спецификации интерфейса, эксплуатационные документации и независимое тестирование.
Оценочный уровень доверия 2. В добавок к 1 предусматривает наличие проекта верхнего уровня объекта оценки, выборочное независимое тестирование, анализ стойкости безопасности, поиск разработчиком явных уязвимых мест.
На 3 уровне ведется контроль среды разработки и объект конфигурации.
На 4 уровне добавляется полная спецификация интерфейсов, применение неформальной политики безопасности, независимый анализ уязвимых мест, реализация конфигураций.
Сопутствующие документы. Рассмотренные 3 части общих критериев представляют собой законченный самостоятельный стандарт, дополнительные документы являются вспомогательными и нужны для легкой интерпретации положения и различных вариантов их реализации.
Безопасность информационных технологий. Типовая методика оценок профиля защиты и задания по безопасности. Руководство по разработке профиля защиты и задания по безопасности.
|
|
|
