Разработка политики безопасности организации в свете новейшей нормативной базы

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

Следует отметить, что политика безопасности не является и не может быть единственным документом, регламентирующим процесс обеспечения информационной безопасности организации. Наряду с политикой безопасности должны быть предоставлены подробные инструкции, касающиеся конкретных вопросов реализации политики безопасности. Если политика безопасности сама по себе является статичным документом, определяется общей инфраструктурой организации и подлежит корректировке только в случае фундаментальных изменений, то инструкции должны непрерывно обновляться и совершенствоваться в ходе модернизации информационной системы предприятия .. Общие рекомендации по настройке СЗИ (безотносительно к конкретным продуктам) целесообразно включить в состав ПБ, конкретные же рекомендации по безопасному конфигурированию приложений разрабатываются администратором информационной безопасности в виде одной или нескольких инструкций.

Особняком среди инструкций стоит план обеспечения непрерывности ведения бизнеса. Часто этот вопрос выносится за рамки проблематики информационной безопасности – и совершенно неоправданно, поскольку при разработке такого плана необходимо полагаться, прежде всего, на анализ рисков безопасности, выполняемый в рамках общего аудита безопасности системы. Конкретная методология анализа рисков стандартом не регламентируется и может быть выбрана исходя из сложившихся на предприятии подходов к управлению рисками или же на базе одной из общеизвестных методик. Ручной анализ рисков является трудоемким и для больших компаний вряд ли целесообразен, поэтому рекомендуется применение автоматизированных систем управления рисками. (RiskWatch, BRA и др.).

Ключевой момент обеспечения непрерывности деятельности информационной системы – выделение критических компонентов этой системы и четкая отработка мероприятий по их восстановлению в случае поражения. Дополнительным методом обеспечения непрерывности деятельности, хотя и менее результативным, является страхование, позволяющее значительно снизить ущерб в случае реализации выявленных угроз.

 

1.4. Пример структуры неформальной политики безопасности

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

1. Общие положения.

1.1. Назначение документа.

1.2. Основания для разработки документа.

1.3. Основные определения.

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

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

2.2. Ответственные подразделения.

2.3. Режим функционирования системы.

2.4. Описание и цели системы.

2.5. Цели и задачи ПБ.

2.6. Системная среда.

2.6.1. Физическая организация системы.

2.6.2. Логическая организация системы.

2.7. Реализованные сервисы системы.

2.8. Общие правила, принятые в системе.

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. Порядок восстановления автоматизированных систем после аварийных ситуаций.

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

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

 

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

2. Средства управления и идентификация системы. Оценка рисков и управление.

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

● Семейство FRU_FLT – Отказоустойчивость – устанавливает требования для продолжения работы системы в случае отказа. Этот раздел представляет собой формализацию плана по непрерывному ведению бизнеса.

● Семейство FPT_ELS – Ошибка безопасности – требует обеспечение выполнения положений политики безопасности при сбоях заданных типов.

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

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

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

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

● Семейство FPT_RCV – Быстрое и надежное восстановление – регулирует возможность автоматического восстановления безопасного состояния в случае определенного вида сбоев.

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

3.1. Особенности разработки политики безопасности

Разработка политики безопасности организации, как формальной, так и неформальной, – безусловно, нетривиальная задача. Эксперт должен не только владеть соответствующими стандартами и хорошо разбираться в комплексных подходах к обеспечению информационной безопасности организации, но и, на- пример, проявлять недюжинные детективные способности при выявлении особенностей построения информационной системы и существующих мер по организации защиты информации. Сходная проблема возникает в дальнейшем при необходимости анализа соответствия рекомендаций политики безопасности реальному положению вещей: необходимо по некоторому критерию отобрать своего рода «контрольные точки» и сравнить их практическую реализацию с эталоном, задаваемым политики безопасности.

В общем случае можно выделить следующие процессы, связанные с разработкой и реализацией политики безопасности и поддающиеся автоматизации.

1. Комплекс мероприятий, связанных с проведением анализа рисков. К этой группе можно отнести:

● учет материальных или информационных ценностей;

● моделирование угроз информационной безопасности системы;

● собственно анализ рисков с использованием того или иного подхода – например, стоимостный анализ рисков.

2. Мероприятия по оценке соответствия мер по обеспечению информационной безопасности системы некоторому эталонному образцу: стандарту, формальной политике безопасности, профилю защиты и т. п.