Управление информационной безопасностью. Стандарты СУИБ (СИ)

В 2004 году Британским институтом стандартов был опубликован стандарт ISO/IEC TR 18044 «ИТ. Методы защиты. Управление инцидентами ИБ». В дальнейшем на его базе подкомитетом SC 27 «Методы защиты» совместного технического комитета ISO/IEC JTC 1 «Информационная технология» был разработан международный стандарт ISO/IEC 27035 «ИТ. Методы защиты. Управление инцидентами ИБ», который был опубликован в 2011 году.

Основные понятия

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

Инцидент ИБ — нежелательное событие, которое может нарушить бизнес-процесс и угрожать ИБ.

Возникновение события ИБ не обязательно означает, что попытка была успешна или что оказано какое-либо влияние на конфиденциальность, целостность и/или доступность, т. е. не все события ИБ классифицируются как инциденты ИБ.

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

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

Рисунок показывает эти отношения объектов в цепи инцидента ИБ. Затемненные объекты существуют изначально и воздействуют на остальные объекты в цепи, которая приводит к инциденту ИБ.

Цели управления инцидентами

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

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

— остановить и задержать,

— уничтожить,

— анализировать и оповестить, и

— последующие шаги.

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

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

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

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

— известные уязвимости ИБ оценены и обработаны соответствующим образом;

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

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

Выгоды от структурного подхода

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

— обеспечение осведомленности в вопросах ИБ;

— сокращение негативного влияния на бизнес;

— оправдание расхода бюджета и ресурсов;

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

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

— усиление приоритетности;

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

— улучшение состояния ИБ;

— улучшение управления рисками ИБ;

— обеспечение вклада в политику ИБ.

Обеспечение осведомленности в вопросах ИБ

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

Сокращение неблагоприятного воздействия на бизнес

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

Оправдание расхода бюджета и ресурсов

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

— использование менее квалифицированного персонала для идентификации и фильтрации ложных сигналов тревоги;

— обеспечение лучшего руководства действиями квалифицированного персонала;

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

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

Усиление внимания к предотвращению инцидентов ИБ

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

Усиление приоритетности

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

Усиление правовой экспертизы

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

Улучшение состояния ИБ

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

Улучшение результатов оценки и управления рисками ИБ

Использование структурного подхода к управлению инцидентами ИБ способствует:

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

— предоставлению данных о частоте возникновения идентифицированных типов угроз.

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

Обеспечение вклада в политику ИБ

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

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

Управление инцидентами ИБ состоит из 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. Создание ГРИИБ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Взаимодействие с заинтересованными сторонами

Процедуры общения со СМИ и ответственность за это общение также должны быть согласованы с высшим руководством и задокументированы. Эти процедуры должны определить представителя организации по работе со СМИ и его взаимодействие с ГРИИБ.

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

— контрактный персонал внешней поддержки,

— национальная ГРИИБ,

— сервис-провайдеры, в том числе поставщики телекоммуникационных и интернет-услуг,

— службы охраны правопорядка,

— аварийные службы,

— соответствующие правительственные органы,

— юридические службы,

— официальные лица по связям с общественностью и/или представители СМИ,

— бизнес-партнеры,

— потребители,

— общественность.

1.5. Техническая и другая поддержка

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

Мероприятия поддержки включают в себя:

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

— доступ к задокументированным процедурам кризисного управления;

— документированные и опубликованные процессы коммуникаций;

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

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

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

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

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

— быстрое получение отчетов о уязвимости / инциденте / событии ИБ;

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

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

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

— процесс сбора всех данных об ИС, сервисе и/или сети и всех обрабатываемых и сохраненных данных;

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

— упрощение архивирования и защиты собранной информации (например, применяя ЭЦП к лог-файлам и другие свидетельства перед хранением в автономном режиме на носителях, предназначенных только для чтения на устройствах CD или DVD ROM);

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

— восстановление штатного режима работы системы, сервиса и/или сети с помощью процедур, связанных с кризисным управлением:

• тестирование резервных копий,

• защита от вредоносного ПО,

• хранение исходных носителей с системным и прикладным ПО,

• хранение загрузочного носителя системы,

• хранение безопасных патчей для системы и приложений.

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

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

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

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

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

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

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

— пользователь обращается с вопросом в службу поддержки по телефону или с помощью электронной заявки (электронная почта, или специальные сервисы подачи заявок);

— оператор (1-я линия поддержки, Call-center) регистрирует обращение, при возможности помогает пользователю самостоятельно, либо передаёт заявку на 2-ю линию поддержки и контролирует ее выполнение;

— 2-я линия поддержки получает заявки от 1-й линии, работает по ним, при необходимости привлекая к решению проблемы специалистов из других отделов предприятия (системные и сетевые администраторы, поддержка специального ПО и оборудования и т. д.).

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

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

— системы обнаружения вторжения;

— устройства мониторинга и защиты сети;

— антивредоносное ПО.

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

— технологическое отслеживание новых видов угроз и атак;

— управление уязвимостями (включая безопасное обновление и исправление уязвимых систем);

— логи аудита и ПО их мониторинга.

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

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

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

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

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

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

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

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

— способы оповещения о событиях, инцидентах и уязвимостях ИБ,

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

— обеспечение конфиденциальности источников (при необходимости);

— соглашения об уровнях сервиса схемы;

— уведомление о результатах — на каких условиях будут информированы источники;

— любые ограничения, налагаемые соглашениями о неразглашении;

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

— кто и как получает сообщения от схемы управления инцидентами ИБ.

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

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

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

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

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

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

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

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

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

2 фаза — обнаружение и оповещение

Оперативный процесс схемы управления инцидентами ИБ состоит из 3-х фаз:

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

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

— реагирования.

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

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

Для этой фазы организация должна выполнить следующие действия:

1) обнаружение и оповещение о событии или уязвимости ИБ, что включает в себя:

— предупреждение системы мониторинга безопасности, таких как системы обнаружения и предотвращения атак на приложения (Intrusion Detection System / Intrusion Prevention System, IDS/IPS), «приманки» для хакеров в виде виртуальных ресурсов, например, вэб-сервер (honeypot), имитации открытого порта в системе для введения хакеров в заблуждение (tarpits), антивирусная программа, СУИБ, системы мониторинга и корреляции логов событий и другие,

— предупреждение систем сетевого контроля, таких как брандмауэры, сканеры сетевого трафика, вэб-фильтры и другие,

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

— результат анализа информации логов устройств, сервисов, хостов и других систем,

— результат деятельности систем технической поддержки (help desk),

— сообщения пользователей,

— уведомления внешних организаций, таких как другие ГРИИБ, Интернет-провайдеры, поставщики телекоммуникационных услуг, аутсорсинговые компании или национальная ГРИИБ;

2) сбор сведений о событии ИБ или уязвимости;

3) регистрация всех действий, результатов и соответствующих решений для дальнейшего анализа группой поддержки;

4) регистрация в системе мониторинга инцидентов.

2.1. Обнаружение события

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

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

Возможными источниками обнаружения события ИБ могут быть:

— пользователи,

— линейные менеджеры и руководители службы безопасности,

— клиенты,

— ИС технической поддержки (help desk — поддержка 1-го уровня),

— подразделение ИТ, в том числе Центр сетевых операций и Центр безопасных операций (поддержка 2-го уровня),

— поставщики услуг (в том числе интернет-провайдеры),

— ГРИИБ,

— другие сотрудники и персонал, которые могут обнаружить аномалии в течение их ежедневной работы,

— СМИ (газеты, радио, телевидение и т. п.),

— веб-сайты (публичные веб-сайты ИБ, веб-сайты специалистов по ИБ, веб-сайты служб ИБ и т. п.).

2.2. Оповещение о событии

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

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

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

В форме отчета о событии регистрируется такая первоначальная информация:

— время / дата обнаружения,

— результаты наблюдения,

— контактная информация.

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

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

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

Форму отчета о событии ИБ нужно передать безопасным способом в группу поддержки, а копию — руководителю ГРИИБ. Группа поддержки должна работать, по возможности, круглосуточно (24 ч/7д).

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

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

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

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

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

3 фаза — оценка и принятие решения

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

В этой фазе организация должна выполнить следующие действия:

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

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

— область воздействия (физическая или логическая),

— попадающие под влияние активы (информация, процессы, сервисы и приложения),

— возможное влияние на ключевые сервисы;

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

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

3) расширение, при необходимости, сферы принятия решений (эскалация) для дальнейших оценок и/или решений;

4) регистрация всех действий, результатов и соответствующих решений для более позднего анализа;

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

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

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

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

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

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

9) применение директив по ведению документации о событии ИБ и последующих действиях для инцидента ИБ, если событие ИБ классифицируется как инцидент;

10) обновление базы данных события / инцидента / уязвимости ИБ.

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

3.1. Оценка и предварительное решение группы поддержки

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

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

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

Кроме даты и времени выполнения действий необходимо документировать:

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

— место хранения доказательств;

— как доказательства архивировались (если необходимо);

— как выполнялось подтверждение доказательств (если необходимо);

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

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

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

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

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

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

— возможная цель;

— возможная причина;

— степень значительности;

— принятые меры.

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

— несанкционированное разглашение информации,

— несанкционированная модификация информации,

— отрицание информации;

— недоступность информации и/или сервиса,

— уничтожение информации и/или сервиса,

— снижение эффективности сервиса.

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

Примерами категорий последствий могут быть:

— финансовые убытки/прерывание бизнес-операций;

— ущерб коммерческим и экономическим интересам;

— ущерб информации, содержащей персональные данные;

— нарушение правовых и нормативных обязательств;

— сбои операций управления и бизнес-операций;

— утрата престижа организации;

— телесные повреждения или смерть;

— социальные проблемы.

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

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

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

— когда и кому необходимо направлять материалы об инциденте;

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

3.2. Оценка и подтверждение инцидента ГРИИБ

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

— подтвердить его получение (должен быть заполнен группой поддержки максимально подробно);

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

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

— проанализировать содержание отчета.

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

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

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

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

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

— цель;

— причина;

— степень значительности;

— последствия;

— принятые меры.

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

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

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

4 фаза — реагирования

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

В этой фазе ГРИИБ выполняет следующие первоначальные действия:

— немедленное реагирование (локализация инцидента);

— оценка контроля инцидента;

— последующее реагирование;

— передача информации об инциденте.

Также ГРИИБ выполняет при необходимости следующие действия:

— кризисные действия;

— правовая экспертиза;

— эскалация (расширение сферы принятия решений);

— документирование и контроль внесения изменений в схему.

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

4.1. Немедленное реагирование

После подтверждения инцидента ГРИИБ выполняет следующие действия:

— немедленное реагирование,

— регистрация подробностей в форме отчета,

— введение в базу данных,

— уведомление сотрудников о требуемых действиях.

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

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

Процесс реагирования на инциденты ИБ включает следующие действия:

— ограничение их неблагоприятных влияний,

— улучшение ИБ.

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

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

Примерные действия

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

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

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

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

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

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

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

Обновление информации об инцидентах

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

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

— что собой представляет;

— как, чем или кем был вызван;

— на что повлиял или мог повлиять;

— как изменялась его серьезность;

— как обрабатывался до сих пор.

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

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

Для инцидента ИБ, повлившего на ИТ, необходимо выполнить следующие действия.

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

При этом необходимо:

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

— собрать и проанализировать журналы (логи) соседних систем, сервисов и/или сетей, например, маршрутизаторов и межсетевых экранов;

— всю собранную информацию хранить только на неперезаписываемых носителях;

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

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

Дальнейшая деятельность

После определения реальности инцидента ГРИИБ должна выполнить и другие важные действия:

— проведение правовой экспертизы;

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

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

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

Член ГРИИБ при оценке инцидента ИБ должен на основании руководящей документации схемы управления ими знать следующее:

— когда и кому направлять материалы,

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

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

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

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

4.2. Оценка контроля инцидентов ИБ

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

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

Если не подтверждается, что инцидент ИБ находится под контролем, член ГРИИБ должен инициировать кризисные действия.

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

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

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

4.3. Последующее реагирование

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

Последующее реагирование может включать в себя следующие действия:

— восстановление пораженных систем;

— предотвращение повторного возникновения инцидента;

— активация дополнительных средств мониторинга систем.

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

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

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

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

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

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

4.4. Реагирования на кризисные действия

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

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

Стратегия кризисного управления должна определить требуемые меры и структуры:

— меры поддержки и кризисного управления;

— организационную структуру и обязанности;

— структуру и положения плана кризисного управления.

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

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

План кризисного управления содержит активацию:

— средств пожаротушения и процедур эвакуации;

— средств предотвращения наводнения и процедур эвакуации;

— средств предотвращения взрыва бомбы и процедур эвакуации;

— специальных расследований технических атак;

— специальных расследований мошенничества в ИС.

4.5. Правовая экспертиза

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

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

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

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

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

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

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

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

— обеспечение защиты целевой системы, сервиса и/или сети в процессе проведения правовой экспертизы от появления недоступности, изменений или другой компрометации, включая вредоносное ПО (в том числе вирусы), и каких-либо влияний на их нормальную работу;

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

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

— восстановление как можно большего числа стертых файлов и других данных;

— раскрытие IP-адресов, имен хостов, сетевых маршрутов и информации Web-сайтов;

— извлечение содержимого скрытых, временных файлов и файлов подкачки, используемых как прикладное, так и системное ПО;

— доступ к содержимому защищенных или зашифрованных файлов (если это не запрещено законодательством);

— анализ всех возможно значимых данных, найденных в специальных (обычно недоступных) областях памяти на дисках;

— анализ времени доступа к файлу, его создания и изменения;

— анализ логов системы / сервиса / сети и приложений;

— определение деятельности пользователей и/или приложений в системе / сервисе / сети;

— анализ электронной почты на наличие исходной информации и ее содержания;

— проведение проверок целостности файлов с целью обнаружения файлов, содержащих «троянского коня», и файлов, изначально отсутствовавших в системе;

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

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

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

— обеспечение экспертной поддержки для любого дисциплинарного или правового действия (при необходимости).

Методы выполнения вышеуказанных действий должны документироваться в процедурах ГРИИБ.

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

Необходимо учесть следующее:

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

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

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

4.6. Коммуникации

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

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

— прямые внутренние получатели (кризисный персонал, персонал СУИБ и т. п.);

— прямые внешние получатели (внешняя ГРИИБ, партнеры, поставщики и т. п.);

— другие внешние получатели, например, телевидение, пресса и/или другие СМИ.

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

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

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

4.7. Расширение сферы принятия решений (эскалация)

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

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

4.8. Документирование и контроль внесения изменений

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

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

5 фаза — извлечение уроков

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

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

— идентификацию полученных уроков;

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

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

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

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

— коммуникации и распространение результатов пересмотра в пределах доверенного сообщества;

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

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

5.1. Идентификация полученных уроков

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

Полученные уроки могут рассматриваться с точки зрения:

— новых или изменившихся требований к мерам защиты;

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

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

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

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

Поэтому необходимо регулярно анализировать базы данных события / инцидента / уязвимости ИБ для осуществления:

— идентификации тенденций / шаблонов:

— идентификации проблемных областей;

— анализа сфер применения превентивных мер для снижения вероятности появления инцидентов.

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

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

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

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

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

5.2. Идентификация улучшений мер защиты и их внедрение

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

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

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

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

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

5.4. Идентификация улучшений схемы управления инцидентами и их внедрение

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

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

На этом совещании должны рассматриваться следующие вопросы:

— работали ли должным образом процедуры, принятые в схеме управления инцидентами;

— существуют ли процедуры или методы, которые способствовали бы обнаружению инцидентов;

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

— применялись ли процедуры, помогающие восстановлению систем после идентификации инцидента;

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

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

5.5. Другие улучшения

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