Политика безопасности

Автор: Пользователь скрыл имя, 07 Декабря 2011 в 17:18, доклад

Описание работы

Современная лицензионная политика в области безопасности информации определяет наличие у организаций, разрабатывающих средства защиты информации (СЗИ) или оказывающих услуги по защите информации, документа, в котором определены концептуальные и общеорганизационные вопросы информационной безопасности (ИБ). Традиционно в мировой практике такой документ называется политикой безопасности (ПБ) организации, однако в нашей стране до недавнего времени отсутствовали какие-либо четкие требования к документу такого рода. Актуальность разработки ПБ возникла с формированием новейшей нормативной базы в области ИБ, в первую очередь ГОСТ 15408-02, ГОСТ 15.002-00, а также ожидаемой отечественной редакцией ISO 17799. Структура и общие вопросы разработки ПБ с учетом новейшей нормативной базы по ИБ и рассматриваются в данной статье.

Содержание

Введение 2
1. Политика безопасности: основное содержание 2
1.1. Новые нормативные требования, касающиеся политики безопасности организации 2
1.2. ГОСТ 15408 - «Критерии оценки безопасности информационных технологий» 3
1.3. ISO 17799-неформальный подход к разработке политики безопасности 3
1.4. Пример структуры неформальной политики безопасности 5
1.5. Формализация положений политики безопасности 6
2. Идентификация системы. 7
3. Средства управления. 7
4. Функциональные средства. 7
5. Технические средства. 8
2. Разработка политики безопасности организации: средства автоматизации 10
2.1. Особенности разработки политики безопасности 10
2.2. COBRA: неформальные советы мудрой змеи 10
2.3. КОНДОР: ISO 17799 с высоты птичьего полета 12
2.4. CC Toolbox: автоматизация разработки формальной политики безопасности 13
Заключение 14
Список использованной литературы 14

Работа содержит 1 файл

Политика безопасности.docx

— 39.18 Кб (Скачать)

          2.9. Общее описание  важности информации.

          3. Средства управления.

          3.1. Оценка рисков  и управление.

          3.2. Экспертиза СЗИ. 

          3.3. Правила поведения,  должностные обязанности и ответственность. 

          3.4. Планирование  безопасности.

          3.5. Разрешение на  ввод компонента в строй. 

          3.6. Порядок подключения  подсетей подразделения к сетям  общего пользования. 

          4. Функциональные  средства.

          4.1. Защита персонала. 

          4.2. Управление работой  и вводом-выводом. 

          4.3. Планирование  непрерывной работы.

          4.4. Средства поддержки  программных приложений.

          4.5. Средства обеспечения  целостности информации.

          4.6. Документирование.

          4.7. Осведомленность  и обучение специалистов.

          4.8. Ответные действия  в случаях возникновения происшествий.

          5. Технические средства.

          5.1. Требования к  процедурам идентификации и аутентификации.

          5.2. Требования к  системам контроля и разграничения  доступа. 

          5.3. Требования к  системам регистрации сетевых  событий.  

         Примерные инструкции по реализации ПБ могут быть, например, следующими:

          1. Требования к  защите портов и служб. 

          2. Порядок проведения  экспертизы СЗИ. 

          3. Порядок проведения  анализа рисков.

          4. Использование  автоматизированных систем анализа  защищенности.

          5. Порядок восстановления  автоматизированных систем после  аварийных ситуаций.

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

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

1.5. Формализация положений  политики безопасности

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

          • формальные  положения ПБ допускают исчерпывающий  анализ их полноты и непротиворечивости;

          • облегчается  процесс проверки соответствия  объекта оценки положениям ПБ.

          В качестве  базы для формализации положений  ПБ целесообразно выбрать КОБИТ.  Указанный мета-стандарт содержит  исчерпывающий комплекс требований, которые могут быть успешно  использованы для построения  разного рода стандартов, а значит, и для формализации неформально  изложенных требований ПБ. Структура  соответствующего документа ничем  не регламентируется, однако целесообразно  представлять ПБ организации  как Профиль защиты объекта  оценки «Информационная инфраструктура  организации». Конкретные же инструкции  по реализации положений ПБ  можно рассматривать как Задание  по безопасности этого же объекта оценки.

          Проиллюстрируем  вышесказанное на рассмотренном  выше примере структуры ПБ. Выделим  те разделы, которые целесообразно  формулировать в терминах КОБИТ,  и приведем ссылки на соответствующие  семейства требования стандарта.

2. Идентификация системы.

         2.1. Идентификатор и  имя системы.

         Идентификатор системы  целесообразно выбрать в стиле  КОБИТ, например S.MAINSYS, где S - идентификатор  группы родственных систем, а MAINSYS - идентификатор конкретной (главной) системы.

3. Средства управления.

         3.1. Оценка рисков  и управление.

          • Семейство  FMT_MOF - Управление отдельными функциями  - требует установление возможности  конфигурирования средств безопасности  только уполномоченными пользователями.

          • Семейство  FMT_MSA - Управление атрибутами безопасности - требует наличие контроля безопасности  присваиваемых значений.

          • Семейство  FMT_SAE- Сроки действия атрибутов  безопасности - регламентирует использование  временных ограничений. 

          • Семейство  FMT_SMR - Роли управления безопасностью  - регламентирует порядок назначения  порядка соответствующих ролей  пользователям. 

          • Семейство  FTA_LSA - Ограничение области выбираемых  атрибутов - определяет требования  по ограничению области атрибутов  безопасности, которые может выбрать  пользователь.

          • Семейство  FTA_SSL - Блокирование сеанса - определяет  порядок блокирования или завершения  сеанса работы по инициативе  пользователя или системы безопасности.

         3.2. Экспертиза СЗИ.

         • Семейство FPT_TST - Самотестирование функций безопасности - определяет порядок самотестирования и контроля целостности данных и исполняемого кода функций безопасности.

4. Функциональные средства.

         4.1. Защита персонала. 

         • Семейство FDP_UCT - Защита конфиденциальности данных пользователя - требует обеспечить защиту данных от несанкционированного раскрытия.

          • Семейство  FPT_PHP - Физическая защита - регламентирует  меры по обеспечению физической  безопасности системы и ее  отдельных компонентов. В частности,  определяются меры ответного  воздействия в случае физического  нападения (см. также раздел 4.8).

         4.2. Управление работой  и вводом-выводом.

         • Семейство FDP_RIP - Защита остаточной информации - определяет порядок  защиты от повторного использования  информации.

          • Семейство  FTA_TAH - История доступа - определяет  требования к отображению истории  попыток получить доступ от  имени пользователя, осуществившего  успешный вход в систему. 

         4.3. Планирование непрерывной  работы.

         • Семейство FRU_FLT - Отказоустойчивость - задает требования по обеспечению  непрерывного функционирования системы  в случае сбоя. Данный раздел является формализацией Плана по непрерывному ведению бизнеса.

          • Семейство  FPT_ELS - Безопасность при сбое - требует  обеспечение выполнения положений  ПБ при сбоях заданных типов. 

         4.5. Средства обеспечения  целостности информации.

         • Семейство FDP_SDI - Целостность  хранимых данных - определяет меры по мониторингу  целостности защищаемых объектов и  действия в случае обнаружения нарушения  целостности.

          • Семейство  FDP_ROL - Откат - регламентирует возможность  восстановления последнего стабильного  состояния системы, то есть  отмены последней операции с  целью сохранения целостности  данных пользователя.

          • Семейство  FDP_UIT - Защита целостности данных  пользователя - регламентирует меры  противодействия модификации, удаления, вставки и повторного использования  данных. Из всей совокупности  требований целесообразно выбрать  только наиболее общие, оставив  частные вопросы для задания  по безопасности конкретных систем.

          • Семейство  FPT_RCV - Надежное восстановление - регламентирует  возможность автоматического восстановления  безопасного состояния в случае  определенного вида сбоев. 

5. Технические средства.

         5.1. Требования к процедурам  идентификации и аутентификации.

         • Семейство FIA_UID - Идентификация  пользователя - определяет набор действий, выполнение которых возможно до идентификации. В большинстве случаев целесообразно  использовать компонент FIA_UID.2, запрещающий  такие действия.

          • Семейство  FIA_UAU - Аутентификация пользователя - специфицирует применяемые технологии аутентификации и режимы их работы.

          • Семейство  FIA_ATD - Определение атрибутов пользователя - позволяет связать неформально  определенные атрибуты безопасности  с субъектом пользователя, который,  в свою очередь, определяется  семейством FIA_USB - Связывание пользователь-субъект. 

          • Семейство  FPR_ANO - Анонимность - определяет услуги, предоставляемые системой без  идентификатора пользователя. В  соответствующий перечень необходимо  включить, в частности, все общедоступные  услуги, предоставляемые компанией. 

         5.2. Требования к системам  контроля и разграничения  доступа.

         • Семейство FDP_ACC - Политика управления доступом - определяет режим  и порядок разграничения доступа.

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

          • Класс FCS - Криптографическая поддержка - определяет порядок работы с  криптографическими ключами, а  также криптографические операции.

         5.3. Требования к системам  регистрации сетевых  событий. 

         • Семейство FAU_GEN - Генерация  данных аудита безопасности - определяет подвергаемые протоколированию и аудиту события, уровень протоколирования, перечень регистрационных данных о  событии, а также предписывает ассоциировать  потенциально регистрируемые события  с идентификаторами пользователей  системы.

          • Семейство  FAU_SEL - Выбор со бытий аудита безопасности - определяет атрибуты, на основании которых производится выбор протоколируемых событий безопасности.

          • Семейство  FAU_STG - Хранение событий аудита  безопасности - определяет порядок  хранения и защиты регистрируемой  информации.

          • Семейство  FAU_SAA - Анализ аудита безопасности - регламен тирует требования к механизмам аудита безопасности.

          • Семейство  FAU_ARP - Автоматическая реакция аудита  безопасности - определяет требования  к применяемым методам активного  аудита.

         Разумеется, предложенный подход к формализации ПБ не является единственно возможным и допускает  дальнейшее развитие. При практической разработке формальной ПБ могут быть успешно применены стандартные  средства автоматизации применения КОБИТ, порядок использования которых  заслуживает отдельного рассмотрения.

2. Разработка политики  безопасности организации:  средства автоматизации

Информация о работе Политика безопасности