Выбери любимый жанр

Выбрать книгу по жанру

Фантастика и фэнтези

Детективы и триллеры

Проза

Любовные романы

Приключения

Детские

Поэзия и драматургия

Старинная литература

Научно-образовательная

Компьютеры и интернет

Справочная литература

Документальная литература

Религия и духовность

Юмор

Дом и семья

Деловая литература

Жанр не определен

Техника

Прочее

Драматургия

Фольклор

Военное дело

Последние комментарии
оксана2018-11-27
Вообще, я больше люблю новинки литератур
К книге
Professor2018-11-27
Очень понравилась книга. Рекомендую!
К книге
Vera.Li2016-02-21
Миленько и простенько, без всяких интриг
К книге
ст.ст.2018-05-15
 И что это было?
К книге
Наталья222018-11-27
Сюжет захватывающий. Все-таки читать кни
К книге

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


56
Изменить размер шрифта:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– цель;

– причина;

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

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

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

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

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

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

(window.adrunTag = window.adrunTag || []).push({v: 1, el: 'adrun-4-390', c: 4, b: 390})

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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