Агентство Активного Аудита

т: +38(044) 228-15-88

e-mail: info@auditagency.com.ua

Разбираемся в документации по информационной безопасности

Целью информационной безопасности и анализа рисков  в компании является не «защитить всю информацию компании по максимуму», а защитить ценную  информацию компании, т. е. адекватно ее ценности. Тут  невозможно обойтись без документации, которая помогает организовать процессы информационной безопасности (ИБ), а также дает возможность принимать правильные и обоснованные решения руководству и владельцам бизнеса.

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

1. Управление информационной безопасностью в компании

Эффективное и адекватное управление ИБ в компании должно быть частью общего процесса управления. Оно должно давать неоспоримые выгоды  и поддерживать стратегию бизнеса.

Основополагающие документы, регулирующие управление ИБ составляют:

1.1 Стратегия информационной безопасности

  

Стратегия ИБ – документ, который определяет цели ИБ, и служит средством поддержания стратегии бизнеса, а также является основанием для составления программы ИБ.

Целью стратегии ИБ является достижение желаемого уровня ИБ, определенное руководством компании.  Как правило, можно определить шесть целей стратегии ИБ:

  • Согласование с целями бизнеса;
  • Эффективное управление рисками компании;
  • Оптимизация инвестиций в ИБ;
  • Управление ресурсами;
  • Измерение производительности;
  • Интеграция всех функций управления ИБ.

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

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

Существует несколько методологий, и стандартов, которые могут помочь в определении целей и  разработке стратегии ИБ, такие, как Capability Maturity Model,  CobIT, Balansed Scorecard, SABSA, ISO 27001, NIST, GASSP/GAISP и другие.

Примером выражения, которое может быть написано в стратегии ИБ:  внедрить стандарт ISO 27001. Или: провести классификацию информации в зависимости от ее критичности.

1.2 Roadmap

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

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

Например,  целью поставленной в стратегии ИБ может быть классификация всех информационных ресурсов. Но если компания большая, то достижение результата может занять достаточно продолжительное время. В таком случае можно в Roadmap включить контрольную точку, чтобы за год провести классификацию 25% информационных активов.

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

1.3 Архитектура информационной безопасности

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

Также архитектура ИБ включает в себя технические чертежи и схемы инфраструктуры ИT систем компании, приложения и потоки информации.

Методики, такие, как например SABSA (http://www.sabsa.org/), могут предложить структурированный подход к вопросу создания архитектуры ИБ.

1.4 Программа информационной безопасности

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

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

  • Цели программы ИБ
  • Бизнес-кейсы (ценовое обоснование)
  • Необходимые ресурсы
  • Помехи и препятствия
  • Риски
  • Мероприятия и средства защиты информации (контроли)
  • Бюджет
  • Планы проектов
  • Контрольные точки
  • Расписание проектов
  • Метрики для определения успеха
  • Требования по тренингам и обучению персонала

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

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

Примером выражения из политики ИБ может быть: «серверы должны быть обеспечены источниками бесперебойного электроснабжения для предотвращения перерывов в бизнес-процессах».

1.6 Стандарты информационной безопасности

В стандартах ИБ определяют показатели и допустимые границы для процедур и практик, технологий и систем, людей и событий.  Это мощный инструмент,  для проверки соответствия требованиям политики ИБ.

Если политика – конституция, то стандарты – это законы ИБ. Они определяют дальнейшее создание процедур и руководств по ИБ для элементов архитектуры.

Пример выражения из стандарта ИБ может быть таким:  «пароль пользователя должен состоять из минимум 8 символов, из них 2 цифры и 2 буквы в верхнем регистре».

1.7 Процедуры информационной безопасности

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

Например, процедура для архивации данных администратором будет включать в себя инструкцию, с пошаговыми указаниями как сделать резервную копию данных с сервера.

1.8 Руководства по информационной безопасности

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

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

Фундаментом для ИБ  является управление рисками компании, а основой управления рисками, в свою очередь, является оценка рисков и  анализ потерь бизнеса  (Business Impact Assessment - BIA).  

Без постановки процесса управления рисками нельзя написать актуальную стратегию ИБ, управление рисками – это обязательная часть программы ИБ.

Постановка процесса анализа рисков  требует разработки дополнительной  документации, кроме того, что уже утверждается в стратегии, программе, политиках и стандартах. Подходы к постановке  управления рисками можно найти в  методиках CobIT, NIST, IRAM, OCTAVE, FAIR и прочих.

Управление рисками должно быть интегрировано в общую структуру управления ИБ компании и включать стратегию и программу управления рисками. Они могут быть написаны как отдельными документами, так и входить в состав стратегии и программы ИБ.

Обобщенный  подход в создании документации, необходимой для эффективного управления рисками сводится к разработке следующих документов:

2.1 Политика управления  информационными рисками

Политика управления информационными рисками должна содержать в себе как минимум следующую информацию:

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

2.2 Политика классификации информационных активов

 Этот документ необходим для определения чувствительность и критичность информационных активов. Политика классификации информационных активов должна отвечать на такие вопросы:

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

2.3 Реестр информационных активов

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

Реестр должен содержать в себе следующую информацию:

  • описание информационного актива;
  • технические спецификации (если применимо);
  • количество копий информационного актива;
  • место расположения или хранения;
  • специальные требования;
  • лицензии (если требуются);
  • владелец актива.

2.4 Оценка ущерба для бизнеса (BIA)

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

Суть процесса оценки ущерба состоит в том, что для каждого информационного актива (из тех, что указаны в реестре), владельцы определяют его ценность и критичность для бизнеса. Для того, чтобы понять насколько ценен информационный актив, и какое влияние он имеет на бизнес в целом, владелец отвечает на вопрос: «Какие последствия для бизнеса, если актив перестанет существовать?».

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

Подготовка BIA  в виде документа зависит от выбранной методики проведения анализа рисков.

2.5 Реестр рисков

Реестр рисков, включает в  себя следующую информацию:

  • описание угроз ИБ;
  • описание уязвимостей ИБ;
  • описание рисков ИБ (риск, как вероятность реализации угрозы  при наличии уязвимостей  в системе);
  • описание внедренных мер и средств защиты;
  • рекомендации по  мерам и средствам защиты, которые следует внедрить с пояснением, почему именно эти меры должны быть внедрены;
  • описание возможных  последствий от реализации рисков;
  • вероятности реализации по каждому из рисков;
  • рейтинг рисков (сводка рисков в виде рейтингового отчета).

После создания реестра менеджмент имеет достаточно информации для принятия решения, что и каким образом нужно защищать. После принятия решения пишется план снижения рисков (или совокупность планов по каждому риску).

2.6 План снижения рисков

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

2.7 Аудиторские отчеты

 Выводы и рекомендации проведенных аудитов или других мониторинговых процедур, касательно ИБ.

2.8 Процедура  управления изменениями и форма запроса на изменение

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

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

2.9 План реагирования на инциденты и восстановления после катастроф

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

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

План должен описывать действия организации в случае инцидента и включает 6 этапов:

  • Подготовка  (применяющиеся подходы и практики, планирование обучения персонала, план осведомления пользователей на случай возникновения инцидента, критерии считать ли ситуацию инцидентом или нет, описание активации команды реакции на инциденты, необходимые ресурсы).
  • Обнаружение инцидента (присвоение инциденту «владельца», идентификация уровня инцидента и описание процесса осведомления ответственных лиц.).
  • Работа с инцидентом, удержание (активация команды реагирования, осведомление ответственных лиц и руководства компании, принятие решения по планируемым ответным действиям, документация инцидента).
  • Выяснение деталей (выяснения причин случившегося,  перепроверка совершённых действий,  тестирование систем).
  • Восстановление (восстановление операций, подтверждение нормального функционирования).
  • Выводы (написание отчета об инциденте, анализ проблем и неудач, улучшение плана).

2.10 Процедуры реакции на инциденты

Необходимо, чтобы персонал знал  пошаговые инструкции при возникновении инцидента,  и умел по ним действовать. Таким образом, достигается правильная и адекватная реакция на инцидент.

Выводы:

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

документация иб

Ермолаев Евгений, CISM