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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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