Читать книгу "Управление информационной безопасностью. Стандарты СУИБ"

Фазы управления инцидентами

Управление инцидентами ИБ состоит из 5 фаз:

1) планирование и подготовка;

2) обнаружение и оповещение;

3) оценка и принятие решения;

4) реагирования;

5) извлечение уроков.

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

1 фаза – планирование и подготовка

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

Фаза подготовки включает в себя следующие первоначальные мероприятия:

– разработка политики управления инцидентами ИБ и утверждение ее руководством;

– интеграция управления инцидентами ИБ во все политики;

– разработка схемы управления инцидентами ИБ;

– тестирование схемы управления инцидентами ИБ, ее процессов и процедур.

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

– создание группы реагирования на инциденты ИБ (далее – ГРИИБ);

– создание технической и другой поддержки (включая организационную и операционную);

– взаимодействие с внутренними и внешними организациями;

– обеспечение осведомленности и обучения персонала.

1.1. Разработка политики управления инцидентами ИБ и утверждение ее руководством

Организация должна оформить свою политику управления событиями, инцидентами и уязвимостями в виде свободно распространяемого документа как часть политики СУИБ (см. ISO/IEC 27001) или как часть политики ИБ (см. ISO/IEC 27002). Размер, структура, вид бизнеса организации и сфера ее программы управления инцидентами ИБ являются решающими факторами для определения, какие из этих факторов применить. Организация должна охватить политикой управления инцидентами ИБ каждого, кто имеет доступ к информационным системам и местам их размещения.

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

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

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

1) важность управления инцидентами ИБ для организации и утверждение высшим руководством этого управления и его схемы;

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

3) общее представление об оценке инцидентов ИБ, включая перечень ответственных лиц, оповещения об инцидентах и дальнейших действий ответственных лиц;

4) краткое изложение действий после подтверждения того, что событие ИБ является инцидентом ИБ;

5) ссылку на необходимость правильной регистрации всех действий по управлению инцидентами ИБ для дальнейшего анализа и непрерывного мониторинга для обеспечения безопасного хранения электронных свидетельств на случай их востребования для судебного разбирательства или внутреннего дисциплинарного расследования;

6) действия, следующие за разрешением инцидента ИБ, включая извлечение урока из инцидента и улучшение процесса, следующего за инцидентом ИБ;

7) общее представление об оповещении и обработке уязвимостей ИБ;

8) подробности места хранения документации схемы, включая процедуры хранения;

9) общее представление о деятельности ГРИИБ, включающее следующие вопросы:

– организационную структуру ГРИИБ и весь основной ее персонал, включая лиц, ответственных за:

• информирование высшего руководства об инцидентах,

• работу с запросами и следующие за этим действия, и

• связь со сторонними организациями (при необходимости);

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

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

– определение сферы деятельности ГРИИБ. Обычно в сферу деятельности ГРИИБ организации входят все ИС, сервисы и сети организации. В некоторых случаях для организации может потребоваться сужение сферы действия ГРИИБ. При этом необходимо четко документировать, что входит и что не входит в сферу ее деятельности;

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

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

9) общее представление о техническом и других механизмах поддержки;

10) общее представление о программе обеспечения осведомленности и обучения управлению инцидентами ИБ;

11) перечень правовых и нормативных аспектов, предполагаемых к рассмотрению.

1.2. Интеграция управления инцидентами ИБ во все политики

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

Интеграция всех политик ИБ должна быть нацелена на следующее:

– описание важности управления инцидентами ИБ, особенно схемы оповещения и обработки инцидентов ИБ;

– указание ответственности руководства за надлежащую подготовку к инцидентам ИБ и реагирования на них, т.е. схему управления инцидентами ИБ;

– обеспечение согласованности разных политик;

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

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

Политики должна содержать следующие разделы:

– обязательства руководства по отношению к ней;

– описание политики;

– описание схемных процессов и соответствующей инфраструктуры;

– требования по обнаружению, оповещению, оценке и управлению событиями, инцидентами и уязвимостями ИБ;

– четкое определение персонала, ответственного за авторизацию и/или проведение определенных критических действий (например, перевод системы в режим внешней недоступности или даже ее отключение).

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

1.3. Разработка схемы управления инцидентами ИБ

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

Необходимо использовать схему в качестве руководства для выполнения следующих первоначальных действий:

– реагирование на события ИБ;

– определение того, является ли событие ИБ инцидентом;

– управление инцидентами ИБ до их разрешения.

Также необходимо использовать схему в качестве руководства для выполнения следующих завершающих действий:

– реагирование на уязвимости ИБ;

– идентификация полученных уроков и улучшений схемы и/или безопасности в целом;

– реализация идентифицированных улучшений.

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

– обнаружение и оповещение о событиях ИБ (постоянный или контрактный персонал организации и ее компаний);

– оценку и реагирование на события и инциденты ИБ, их разрешение и улучшения ИБ и самой схемы (группа поддержки, ГРИИБ, руководство, пресс-секретари и юристы);

– оповещение об уязвимостях ИБ (постоянный или контрактный персонал организации и ее компаний) и всего связанного с ними.

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

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

– описание политики управления инцидентами ИБ;

– описание схемы управления инцидентами ИБ в целом;

– подробные действия, процедуры и данные всех фаз управления инцидентами.

Схема должна содержать определенную информацию каждой фазы

Для 1-й фазы – планирование и подготовка:

– стандартизированный подход к категоризации и классификации инцидентов/событий ИБ для обеспечения единого подхода. Во всяком случае решение должно быть основано на фактических или планируемых неблагоприятных воздействиях на бизнес-операции организации и соответствующих директивах;

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

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

– процедуры, которые гарантируют, что все действия по управлению инцидентами ИБ должным образом зафиксированы, и что лог-анализ проводит уполномоченный персонал;

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

– процедуры правового анализа инцидента ИБ;

– процедуры и директивы по использованию систем обнаружения вторжения (Intrusion Detection System, IDS) и предотвращения вторжения (Intrusion Prevention System, IРS), которые гарантируют обеспечение связанных с ними правовых и нормативных аспектов. Директивы должны включать перечень преимуществ и недостатков обеспечения контроля вторжений;

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

– материал для осведомленности и программы обучения по вопросам управления событиями, инцидентами и уязвимостями ИБ;

– процедуры и спецификации для тестирования схемы управления инцидентами ИБ;

– схема организационной структуры управления инцидентами ИБ;

– сферы полномочий и ответственности ГРИИБ в целом и ее членов в отдельности;

– важная контактная информация.

Для 2-й фазы – обнаружение и оповещение:

– обнаружение и оповещение о событиях ИБ (человеком или автоматическими средствами),

– сбор информации о событиях ИБ,

– обнаружение и оповещение об уязвимостях ИБ,

– полная запись всей собранной информации в базе данных уязвимости / инцидента / события ИБ.

Для 3-й фазы – оценка и принятие решения:

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

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

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

– полная запись всей информации в базе данных уязвимости / инцидента / события ИБ.

Для 4-й фазы – реагирования:

– отчет ГРИИБ для определения, находится ли инцидент ИБ под контролем, и:

• если инцидент под контролем, инициировать реагирование немедленно (в реальном времени) или позже,

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

– определение всех функций и организаций (внешних и внутренних), необходимых для схемы управления инцидентами;

– локализация и ликвидация инцидента ИБ путем смягчения или предотвращения расширения границ и степени воздействия инцидента;

– оповещение о существовании инцидента ИБ или любых связанных с этим деталей других внутренних и внешних лиц или организаций;

– документальное завершение и внесение записей об успешнм разрешении инцидента ИБ в базу данных уязвимостей / инцидентов / событий ИБ;

– проведение правового анализа, если потребуется;

– проверка правильности регистрации всей деятельности для дальнейшего анализа,

– сбор и сохранность результатов правовой экспертизы;

– поддержка режима контроля изменений и обновлений базы данных уязвимостей / инцидентов / событий ИБ;

– поиск взаимосвязей с уязвимостями ИБ.

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

Для 5-й фазы – извлечение уроков:

– идентификация уроков обработки инцидентов и уязвимостей ИБ;

– идентификация и внедрение улучшений средств защиты (новых и/или усовершенствованных) как в соответствии с политикой управления инцидентами ИБ, так и в результате полученных уроков;

– идентификация и внедрение улучшений оценки и управления рисками ИБ в результате полученных уроков;

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

– обновление базы данных уязвимостей / инцидентов / событий ИБ;

– проведение, если потребуется, дальнейшей правовой экспертизы;

– взаимосвязь и обмен результатами обзора с доверенными сторонами (если организация пожелает).

При разработке схемы необходимо учитывать следующие факторы:

– категории и классы инцидентов;

– формы учета инцидентов;

– рабочие процедуры;

– доверие персонала;

– конфиденциальность информации

Категории и классы инцидентов

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

Шкала классификации инцидента / события ИБ зависит от степени серьёзности воздействия инцидентов / событий на активы или бизнес-операции организации.

Такая шкала может быть простой и иметь только 2 класса инцидента:

– значительный;

– незначительный.

Шкалу можно сделать более сложной, имеющую 4 класса инцидента:

– класс IV – очень серьёзный;

– класс III – серьёзный;

– класс II – менее серьёзный;

– класс I – несерьёзный.

Очень серьёзные инциденты – те, которые:

– воздействуют на очень важные ИС,

– приводят к катастрофическим бизнес-потерям или

– вызывают огромные социальные проблемы (увольнения).

Серьёзные инциденты – те, которые:

– воздействуют на очень важные или важные ИС,

– приводят к серьезным бизнес-потерям или

– вызывают большие социальные проблемы (забастовки).

Менее серьёзные инциденты – те, которые:

– воздействуют на важные или обычные ИС,

– приводят к значительным бизнес-потерям или

– вызывают значительные социальные проблемы (митинги).

Несерьёзные инциденты – те, которые:

– воздействуют на обычные ИС,

– приводят к незначительным бизнес-потерям или их отсутствию,

– вызывают незначительные социальные проблемы или их не вызывают,

– не требуются никаких действий и нет последствий.

Взимосвязь категорий и классов

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

Формы отчета об инцидентах

Формы отчета об уязвимости / инциденте / событии ИБ ведутся для:

1) полноты персонального описания события ИБ (не членом группы управления инцидентами ИБ), которое вносится в базу данных уязвимости / инцидента / события ИБ;

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

В базе данных уязвимости / инцидента / события ИБ записывается каждая стадия обновления. Полнота записи в базе данных уязвимости / инцидента / события ИБ затем облегчает деятельность по разрешению инцидента;

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

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

Процедуры

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

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

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

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

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

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

В этом случае рассматривают следующие аспекты:

– процесс оповещения для обработки таких исключительных случаев;

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

– предварительно одобренное делегирование принятия решения без обычного процесса одобрения.

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

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

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

– продолжение работы поврежденной системы, сервиса и/или сети (подключенной и действующей);

– мониторинг данных, получаемых на входе и выходе поврежденной системы, сервиса и/или сети;

– активацию процедур резервирования и кризисного управления и действий согласно политики ИБ (системы, сервиса и/или сети);

– безопасное хранение электронных доказательств для дальнейшего судебного разбирательства или дисциплинарного расследования;

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

Доверие персонала

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

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

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

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

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

Конфиденциальность информации

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

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

1.4. Создание ГРИИБ

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

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

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

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

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

– планирования;

– мониторинга;

– реагирования;

– анализа и т. п.

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

Группа мониторинга отвечает в реальном времени за контроль и фактическую операционную деятельность, как например, мониторинг / обнаружение / идентификация событий ИБ, регистрация инцидента и его предотвращение;

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

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

Руководитель ГРИИБ обязан:

– немедленно принимать меры для решения инцидента на основании заранее делегированных полномочий;

– иметь отдельную линию для связи с руководством, изолированную от обычных бизнес-коммуникаций;

– обеспечить высокий уровень знаний и мастерства всех членов ГРИИБ, а также постоянную поддержку этого уровня;

– поручать расследование каждого инцидента наиболее компетентному члену ГРИИБ.

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