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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процедуры

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

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

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

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