Рассказываем про пять простых шагов, которые помогут создать универсальный эффективный план реагирования на инциденты кибербезопасности в любой организации.
Статистика гласит: чем больше предприятий переводят свои операции в цифровую реальность, тем больше появляется рисков кибербезопасности. Согласно опросу GetApp 2020 Data Security, 35% ответивших компаний столкнулись с утечкой данных в уходящем 2020 году, а 28% столкнулись с атакой программ-вымогателей.
А что бы сделали вы? Есть ли у вас и вашей организации план действий по реагированию?
Думаем, мы знаем ответ – согласно отчету IBM, лишь 26% фирм имеют четко определенный план ответных мер безопасности на утечку данных и другие виды кибератак. В этом материале мы обсудим, что такое план реагирования на инциденты в области кибербезопасности и какую пользу он вам принесет. И выделим пять шагов по созданию плана реагирования на инциденты и предоставим ряд ресурсов, которые помогут вам начать работу.
Что такое инцидент кибербезопасности
Инцидент кибербезопасности — это любое событие, которое нарушает политику ИТ-безопасности организации и подвергает риску конфиденциальные данные – например, финансовые данные клиентов. Заражение вредоносным ПО, DDoS-атаки, атаки программ-вымогателей, несанкционированный доступ к сети, внутренние атаки и фишинг – вот лишь некоторые из распространенных типов инцидентов, связанных с кибербезопасностью.
Что такое план реагирования на инциденты кибербезопасности
План реагирования на инциденты кибербезопасности — это набор инструкций, которые помогут вашим сотрудникам выявлять инциденты кибербезопасности, реагировать на них и восстанавливаться – после них.
Такой план включает меры, которым стоит следовать, дабы предотвратить кибератаки, шаги, которые необходимо предпринять, когда компания с атакой уже столкнулась, а также меры после атаки – например, информирование заинтересованных сторон или сообщение об инциденте госорганам.
Зачем нужен план реагирования на инциденты кибербезопасности
Приведем основные причины, по которым каждой организации нужен хорошо задокументированный и регулярно обновляемый план реагирования на инциденты кибербезопасности.
Вы будете подготовлены к борьбе с кибератаками
Благодаря плану реагирования вы и ваша команда будете знать, что именно нужно делать. При этом у каждого будет задокументированная роль и собственная ответственность. Вам не нужно будет давать дополнительные инструкции своей команде, чтобы не было потери времени или перерывов в общении.
Вы будете соблюдать правила
В случае нарушения безопасности вы должны выполнить множество требований, таких как информирование заинтересованных сторон и сообщение об инциденте властям. А план реагирования поможет вам отслеживать и четко придерживаться этих требований. Например, закон о защите данных потребителей GDPR требует, чтобы вы сообщали о событии безопасности в течение 72 часов с момента его возникновения, а стандарт безопасности финансовой информации PCI DSS требует, чтобы вы имели план реагирования на инциденты и проверяли его как минимум раз в год.
Вам не придется полагаться на специальные меры реагирования на инциденты
План реагирования на инциденты кибербезопасности — это письменный документ, в котором четко указаны шаги, которые вы и ваши сотрудники должны выполнять при обнаружении нарушения безопасности. Он одобрен руководством компании – а это значит, что вам не придется импровизировать. Согласитесь, заранее подготовленный ответ более эффективен, чем спонтанный и хаотичный.
5 шагов для создания плана реагирования на инциденты кибербезопасности
1. Задокументируйте общие типы инцидентов безопасности.
Для начала создайте документ с перечислением потенциальных угроз для вашего бизнеса – он поможет вам подготовить различные стратегии реагирования на разные типы киберинцидентов.
2. Расставляйте приоритеты в инцидентах безопасности в зависимости от их серьезности.
Инциденты безопасности различаются по величине и серьезности. Поврежденный файл на ноутбуке сотрудника может считаться менее приоритетным по сравнению с DDoS-атакой, которая может вывести из строя весь сайт. Определите серьезность каждого инцидента безопасности – дабы решить, следует ли разрешать его первым.
Итак, оцените, влияет ли инцидент на ваши данные (делает их недоступными, крадет или приводит к их потере) или на вашу способность обслуживать клиентов или выполнять операции. Любой инцидент, который влияет как на безопасность данных, так и на операционную безопасность, должен рассматриваться в приоритетном порядке.
Используйте наш инструмент приоритизации инцидентов безопасности для оценки рисков различных инцидентов безопасности.
Укажите степень влияния инцидента на ваши операции и данные (нет, низкое, среднее или высокое), и сервис автоматически отобразит, действительно ли он в приоритете, или же его разрешение может немного подождать.
Не забудьте установить и временные рамки для разрешения всех выявленных инцидентов. В идеале инциденты с высоким приоритетом должны разрешаться в течение 2-6 часов после обнаружения, а вот инциденты с низким приоритетом – в течение суток.
3. Создайте блок-схему реагирования на инцидент с указанием необходимых действий
План реагирования на инциденты будет определять шаги, которые вы должны предпринять для сдерживания атаки. Составьте свой план в виде блок-схемы, чтобы ваша команда могла максимально быстро понять, какой именно путь снижения угроз нужно использовать.
Пример схемы.
Укажите, кто отвечает за выполнение каждого шага, упомянутого в вашей блок-схеме. Распределите четкие и не конфликтующие между собой обязанности между своими сотрудниками, чтобы не было столкновений или ненужных споров.
Используйте матрицу ответственных, подотчетных, консультируемых и проинформированных (RACI), чтобы указать, кто должен нести ответственность, отчитываться, консультироваться или только информироваться о различных шагах реагирования на инциденты. Это может быть и один сотрудник – например, ваш менеджер по безопасности будет нести ответственность за ведение записей об инцидентах, отвечать за технические операции, консультироваться по вопросам подготовки отчета после инцидента и информировать об общей координации и взаимодействии с регулирующими органами.
Вот образец матрицы RACI, в которой указаны обязанности разных участников, который вы можете скачать и настроить в соответствии с характеристиками вашей организации. Например, если у вас нет MSSP, ваш менеджер по безопасности будет ответственным за все технические операции.
4. Проведите тест-драйв и обучите своих сотрудников.
Одной программы реагирования на инциденты недостаточно. Вам необходимо проверить его эффективность, проведя имитационные учения, которые также будут обучать ваших сотрудников их роли в управлении инцидентами безопасности. Вот эффективное упражнение красных и синих команд, которое вы можете провести в качестве модели.
5. Регулярно обновляйте план реагирования на инциденты.
Регулярно обновляйте свой план, чтобы не отставать от изменений в ландшафте угроз или включать сведения о любых новых мерах безопасности, которые вы недавно приняли. Не реже одного раза в год пересматривайте свои действия по реагированию и работайте над сокращением времени, которое вы тратите на сдерживание инцидентов и восстановление после них.
Используйте информацию, собранную из предыдущих инцидентов безопасности и имитационных учений, чтобы определить возможности улучшения и внедрить новые элементы управления для вашего плана реагирования на инциденты безопасности (например, обязательно ищите шаги, которые можно автоматизировать).
И, наконец, используйте специальное программное обеспечение, ведь оно может помочь более эффективно обнаруживать и устранять угрозы безопасности. Они позволяют продолжать бизнес-операции, даже если действия по реагированию на инциденты выполняются в фоновом режиме.
Вот некоторые из них:
- Антивирусное ПО
- ПО для защиты конечных точек
- ПО сетевой безопасности
- ПО для мониторинга сети
- SIEM
- ПО для резервного копирования данных
- ПО для обеспечения непрерывности бизнеса
Конец
Технология сценариев реагирования на инциденты информационной безопасности, так называемые плейбуки (от англ. playbook), позволяет задать для конкретного типа инцидента алгоритм действий по реагированию и в автоматическом режиме реализовать его при срабатывании определенного правила. Как это работает, рассмотрим на примере платформы R-Vision Incident Response Platform.
- Введение
- Как работать со сценариями реагирования в R-Vision IRP
- 2.1. Подход к автоматизации сценариев
- 2.2. Подготовка R-Vision IRP к формированию каталога сценариев реагирования
- 2.3. Создание, визуализация и редактирование сценариев реагирования
- 2.4. Основные типы действий в сценариях реагирования
- Управление исполнением сценария реагирования и журналирование действий
- Адаптация преднастроенных сценариев реагирования
- Выводы
Введение
Сама по себе типизация цепочки действий реагирования на инциденты в виде плейбуков не является новой технологией. Обязательной практикой как в области информационной безопасности, так и в других отраслях, является регламентация правил возможной реакции на различные типы входных данных о поступившем событии, а также их дальнейшая автоматизация, особенно если дело касается потоковой обработки множества событий или обращений, как это, к примеру, происходит в SOC.
Сценарий реагирования в общем случае включает в себя как действия, направленные на сбор данных и свидетельств, сохранение их целостности и возможность исследования этих данных в будущем, так и мероприятия, которые позволяют снизить ущерб от инцидента, осуществить необходимые первоочередные шаги для блокирования атаки, а также максимально оперативно уведомить все заинтересованные стороны в соответствии с зонами ответственности и запланировать последующие задачи по обработке и аналитике.
До недавнего времени команды реагирования SOC чаще всего использовали в автоматизации своей деятельности инструменты, аналогичные тем, что используют коллеги из служб технической поддержки (service desk и т.д.). Однако в настоящее время с развитием технологий набирает популярность класс специализированных программных решений, позволяющих максимально разгрузить персонал команды реагирования не только за счет маршрутизации заявок, но в большей степени уже за счет автоматизации рутинных и типовых операций, оставив на откуп специалистам принятие лишь ключевых решений по цепочке действий.
Рассмотрим подход к автоматизации сценариев реагирования на инциденты, реализованный в одной из таких платформ — R-Vision IRP.
Как работать со сценариями реагирования в R-Vision IRP
Подход к автоматизации сценариев
Автоматизация действий по реагированию на инциденты в R-Vision IRP заключается в инициации полностью или частично самостоятельной реакции набора инструментов реагирования на поступившую в систему информацию об инциденте с помощью срабатывания правил, определенных заранее в настройках. Критерием для срабатывания правил может выступать как принадлежность инцидента к определенному типу, так и значение любого поля-атрибута инцидента, например, связанный с инцидентом актив (узлы, пользователи и т.д.).
Рассмотрим пример – сценарий реагирования на инцидент типа «Компрометация доменной учетной записи». Вот как может выглядеть такой сценарий в форме перечня необходимых шагов специалиста, ответственного за обработку инцидента, в каком-либо внутреннем документе, регламентирующем его деятельность или деятельность команды реагирования SOC (Памятка, Инструкция, Регламент и т.д.):
Шаг 1. Зарегистрировать инцидент (событие) в учетной системе, присвоить номер, назначить исполнителя в соответствии с картой ответственности.
Шаг 2. Уведомить всех сотрудников группы реагирования, а также владельца актива, с которым связан инцидент.
Шаг 3. Если инцидент критичный, уведомить CISO.
Шаг 4. Запустить сбор информации о текущих сессиях скомпрометированной учетной записи
Шаг 5. Осуществить отключение (прерывание сессий) скомпрометированной учетной записи пользователя
Шаг 6. Уведомить ИТ-службу о блокировании учетной записи
Шаг 7. Осуществить сброс учетной записи и смену пароля при следующем входе.
Шаг 8. Разблокировать учетную запись.
Шаг 9. Провести действия по мониторингу действий пользователя под учетной записью и анализ собранных свидетельств,
Шаг 10. Уведомить пользователя с помощью смс, звонком или личного контакта.
Шаг 11. Инициировать служебное расследование, выявление причин возникновения инцидента.
Шаг 12. После выявления причин инцидента требуется осуществить действия по заполнению аналитической информации по инциденту, присвоить инциденту закрытый статус.
Шаг 13. Уведомить рабочую группу о закрытии инцидента
Шаг 14. Если инцидент был признан критичным, осуществить уведомление CISO.
Как видно, в данном примере все шаги, кроме пп. 9 – 12, могут быть автоматизированы, так как являются типовыми действиями и зависят от известных входных данных (параметры хоста, учетной записи, пользователь и т.п.). Более того, часть действий могут быть выполнены параллельно.
А вот как приведенный пример может выглядеть в виде полуавтоматического сценария — схемы действий (на рисунке ниже). Видно, что одновременно запускается и выполняется сразу несколько веток реагирования. Блоки, требующие вовлеченности персонала, отмечены знаком «», остальные действия выполняются автоматически.
Рисунок 1. Пример сценария реагирования на инцидент типа «Компрометация доменной учетной записи»
Подготовка R-Vision IRP к формированию каталога сценариев реагирования
Базовая подготовка к формированию каталога сценариев реагирования начинается уже на этапе формирования типовых «карточек» инцидентов различных категорий (типов) и необходимых полей-атрибутов, применимых к соответствующим категориям (типам).
Рисунок 2. Окно настройки категории инцидента в R-Vision IRP
Далее именно эти поля-атрибуты, а чаще всего их комбинация, будут служить условиями срабатывания правил. Доступные для создания типы полей̆:
- Стандартные (числовые, текстовые поля, дата, выпадающий̆ список, чек-бокс).
- Выбор пользователя — позволяет указать в поле одного из пользователей̆, созданных в системе.
- Счетчик времени — поле, в котором ведется отсчет времени с указанного в его свойствах момента (указанная вручную дата или значение выбранного поля типа Дата).
Для полей̆ инцидента могут быть заданы регулярные выражения. Настройка типовых карточек инцидентов осуществляется в интерфейсе Настроек. Далее требуется задать цикл и последовательность статусов, в соответствии с которыми осуществляется процесс работы с инцидентами ИБ, то есть сформировать т. н. воркфлоу (от англ. workflow) обработки инцидента.
Рисунок 3. Циклы обработки инцидентов в R-Vision IRP
Настройка сценариев реагирования на последующих шагах позволит при необходимости автоматизировать в том числе и перевод по статусам цикла обработки инцидента.
Создание, визуализация и редактирование сценариев реагирования
Создание типовых сценариев является ключевым шагом настройки автоматизации реагирования с помощью платформы R-Vision IRP. Чтобы создать сценарий реагирования, требуется:
- Добавить условия, по которым сценарии будут срабатывать для инцидентов.
Критерии выбираются из двух типов: Значение поля или Связанный̆ актив. Для типа Связанный̆ актив требуется указать связанные активы. Для типа Значение поля необходимо задать его значение: текст, несколько текстовых строк, время, дата, число, элемент списка (для полей̆ типа Дата и Время также можно выбрать способ оценки: значение или диапазон).
Существует возможность установить правило исключения, если необходимо искать любые значения, кроме указанного. Если установить флажок Значение не указано, то сценарий будет срабатывать на всех инцидентах, у которых указанное поле не заполнено.
При использовании нескольких критериев есть возможность настроить логику их сочетания с помощью логических операторов и выражений: < >, AND, OR, а также скобок. Один критерий можно использовать несколько раз.
- Добавить сами действия по инциденту, которые входят в состав сценария.
Можно добавить действия нескольких типов. После выбора типа действия на экране отобразится окно редактирования параметров действия, которые различаются в зависимости от типа действия.
Рисунок 4. Окно настройки сценария реагирования в R-Vision IRP
Созданные базовые сценарии можно визуализировать и осуществлять их тонкую настройку уже в наиболее удобном и наглядном представлении — режиме графического редактора. Можно создать сценарий и сразу в графической схеме. Переходы между действиями (блоками) в сценарии отмечены стрелками. Возможность изменять последовательность действий̆ реализована простым перетаскиванием блоков и стрелок мышью.
Рисунок 5. Визуализация сценария реагирования «Компрометация доменной учетной записи»
Существует возможность скопировать сценарий реагирования и на его основе создать аналогичный путем редактирования/добавления необходимых действий или последовательности.
Основные типы действий в сценариях реагирования
При использовании R-Vision IRP можно выполнять следующие типы действий в составе сценариев реагирования:
- Уведомление — позволяет отправить уведомление выбранным пользователям или группам пользователей̆. Можно создавать шаблоны темы письма и текста письма с помощью переменных.
- Назначение — позволяет сформировать для текущего инцидента список пользователей̆ и/или групп пользователей̆ и указать роли, которые будут им автоматически назначены.
- Модификация — позволяет внести изменения в любые поля инцидента (например, установить уровень критичности, сменить статус и пр.).
- Действие персонала — позволяет добавить действие/задачу, которое необходимо предпринять персоналу в отношении инцидента, с указанием типа запуска (сразу, после завершения другого действие и т. д.).
- Скрипт — действие, которое позволяет исполнить скрипт из заранее определенного в настройках списка. В R-Vision IRP уже есть большая база скриптов реагирования (в системе предустановлено более 50 скриптов автоматизации).
Таблица 1. Пример списка предустановленных действий, которые исполнит скрипт реагирования в R-Vision IRP
| Наименование | Тип | Описание |
| Сбросить сеансы всех пользователей Linux | sh script | Команда производит принудительный сброс сеансов всех пользователей узла Linux. Для этого производится запрос списка всех вошедших в систему,пользователей командой who -u и для каждого пользователя из списка производится сброс сеанса командой kill -9. |
| Конфигурация сетевого оборудования Cisco | Cisco | Команда возвращает конфигурацию сетевого оборудования Cisco |
| Завершить RDP сеансы всех пользователей | Power Shell | Команда производит завершение RDP сеансов всех пользователей узла Windows. Для этого производится запрос списка всех вошедших в систему пользователей командой quser, список пользователей фильтруется по наличию RDP сессии и для каждого пользователя производится завершение сеанса командой logoff. |
| Сменить пароль локального администратора Windows при следующем входе | cmd | С помощью команды net user производится включение параметра учетной записи локального администратора «Требовать смену пароля при следующем входе в систему». При этом параметр «Срок действия пароля не ограничен» должен быть отключен. |
Также система позволяет добавлять собственные скрипты, написанные на различных языках, которые далее будет выполняться в процессе обработки инцидентов.
Запустить скрипт в сценарии можно как для всех связанных с инцидентом объектов, так и указать категорию и тип оборудования, для которого нужно выполнить скрипт (выборочное оборудование).
Рисунок 6. Окно добавления скрипта в сценарий реагирования в R-Vision IRP
- Решение — позволяет создать разветвление хода сценария в зависимости от условий. В системе есть два вида решений: решения пользователя (в этом случае пользователь получает уведомление о том, что нужно принять решение по инциденту) и автоматическое решение (вариант решения выбирается автоматически в соответствии с заданными критериями).
- Запрос информации — позволяет направить запрос дополнительной информации по инциденту выбранным пользователям или группам пользователей̆. Можно создавать шаблоны темы письма и текста письма с помощью переменных.
- Инцидент HP Service Manager — действие, которое позволяет добавить или изменить инцидент, полученный через интеграцию с HP Service Manager. Можно сформировать список полей инцидентов HP Service Manager и задать соответствие полям инцидентов в системе R-Vision IRP.
- Запрос событий по инциденту в SIEM (QRadar SIEM/ ArcSight ESM) — действие, которое позволяет сделать запрос событий по инциденту в SIEM и просмотреть результаты запроса в виде таблицы и графика.
- Сканирование связанного оборудования — позволяет выполнить сканирование определенных внутренних узлов, связанных с инцидентом.
- Запуск сценария реагирования — позволяет запустить сценарий реагирования из списка сценариев, существующих в системе.
- Запуск коннектора — позволяет запустить коннектор из списка коннекторов, существующих в системе. Система поддерживает работу с коннекторами следующих типов:
- LDAP — включая Active Directory (поиск, чтение, создание, изменение, удаление).
- SSH — выполнение скрипта bash.
- SOAP.
- REST.
- CMD.
- Power Shell — выполнение скрипта PowerShell.
- SNMP — v3.
- MS SQL.
- PostgreSQL.
- MySQL.
- Oracle.
- R-Vision — выполнение скрипта на коллекторе (поддерживаются скрипты Bash, Java, Python, JavaScript).
- SMB (DNS — парсинг файлов с общего ресурса).
- WMI.
Управление исполнением сценария реагирования и журналирование действий
При добавлении или изменении инцидента система осуществляет проверку справочника настроенных сценариев реагирования. Если инцидент соответствует заданным критериям, система запускает нужный сценарий. Система может запустить несколько сценариев. Для каждого инцидента сценарий реагирования срабатывает только один раз.
Все действия по инциденту, которые были применены в соответствии со сценарием, а также их статус и прогресс, можно просмотреть. При этом графическое отображение дерева действий̆ для инцидента также доступно. Цвет блока зависит от статуса действия:
- Желтый — действия выполняется.
- Зеленый — действие выполнено.
- Серый — действие запланировано.
Рисунок 7. Карточка инцидента с информацией по сценарию реагирования
Рисунок 8. Карта рабочего процесса по инциденту
Можно внести корректировки в действия на лету: изменить срок исполнения, ответственного, статус.
Адаптация преднастроенных сценариев реагирования
Вместе с платформой R-Vision IRP производитель предоставляет несколько предустановленных шаблонных плейбуков, а благодаря удобному графическому интерфейсу они могут быть оперативно адаптированы под специфику организации и непосредственно структуру команды реагирования. Например, для адаптации действия «Уведомление», достаточно выбрать в сценарии нужный блок, нажать кнопку «Изменить» и скорректировать пользователей и текст уведомления.
Рисунок 9. Изменение действия в графическом редакторе
Рисунок 10. Окно настройки действия типа Уведомление
Также можно добавить дополнительные действия, если это требуется.
Рисунок 11. Добавление действия в сценарий в графическом редакторе
Выводы
От эффективности, качества и скорости обработки инцидентов напрямую зависит масштаб возможных финансовых и репутационных потерь для компании вследствие реализации киберугрозы. При современном количестве инцидентов и применении ускоренных методов взлома киберпреступниками для команд реагирования счет идет на минуты, иногда секунды. Без автоматизации действий и использования готовых алгоритмов современному SOC практически невозможно обеспечить адекватную скорость реакции.
Автоматизация реагирования с помощью сценариев дает командам SOC сразу несколько преимуществ:
- Экономия времени специалистов за счет выполнения действий в автоматическом режиме и распараллеливания операций. На первичный сбор данных по инциденту и базовые действия по его регистрации и уведомлению сотрудников может требоваться от 10 до 30 минут. С помощью плейбуков их можно осуществить в 2-5 раз быстрее.
- Повышение скорости обработки инцидента и развертывания защитных мер. Сценарий реагирования позволяет в автоматическом режиме выполнять действия в инфраструктуре прямо из интерфейса IRP-платформы.
- Сведение к минимуму человеческого фактора, соблюдение точности процедур и обеспечение непрерывности процессов. Когда алгоритм действий четко зафиксирован в сценарии, ни одно из них не будет пропущено, а весь рабочий процесс навсегда останется в логах.
- Удобство в отслеживании и управлении процессом реагирования. В любой момент времени можно посмотреть, на каком этапе находится сценарий, кто какие действия выполнял и каковы были результаты, а также оперативно скорректировать ход выполнения.
Наличие автоматизированных сценариев реагирования – функциональность, без которой крайне трудно получить нужный эффект при внедрении решения класса Incident Response Platform. Мы рассмотрели его реализацию на примере российской платформы R-Vision IRP. Стоит отметить, что данное решение имеет весьма широкий набор возможностей в области формирования плейбуков, предусматривает гибкие инструменты и предустановленные справочники, чтобы создавать максимально автоматизированные варианты сценариев реагирования с минимальным количеством действий пользователя. Однако при необходимости можно создать как комбинированный, так и полностью «ручной» сценарий, который может служить подсказкой для специалиста и своеобразным регламентом реагирования на инциденты.
Ранее в своих материалах о том, как защититься от DDoS-атак, мы неоднократно советовали составить план своей инфраструктуры, ее уязвимых мест и первичных действий при кибератаках. Сегодня поговорим о том, что такое план реагирования на киберинциденты, почему он нужен каждой организации, как его составить и что он в себя включает.
По мере развития изощренности кибератак, должна трансформироваться и стратегия их предотвращения. К сожалению, многие компании полагаются на устаревшие планы, а еще большее количество и вовсе их не имеет.
Чтобы увеличить шансы пережить непредвиденную атаку и сохранить репутацию, любому бизнесу, проекту, компании нужно задуматься о создании плана реагирования на инциденты кибербезопасности.
Что такое инцидент кибербезопасности
Инцидент кибербезопасности — это ситуация, которая ведет к нарушению политики информационной безопасности организации и подвергает риску ее конфиденциальные сведения: личные данные клиентов, государственные, коммерческие и врачебные тайны. Далее в тексте вы встретите аббревиатуру КБ — это сокращенный вариант термина «кибербезопасность».
Национальный координационный центр по компьютерным инцидентам (НКЦКИ) выделяет следующие виды инцидентов кибербезопасности:
| 1. DoS-атаки | 8. несанкционированный вывод объекта из строя |
| 2. DDoS-атаки | 9. публикация в объекте мошеннической информации |
| 3. рассылка спама с объекта | 10. использование объекта для распространения вредоносного ПО |
| 4. захват сетевого трафика объекта | 11. социальная инженерия, направленная на компрометацию объекта |
|
5. компрометация учетной записи в объекте |
12. публикация в объекте запрещенной законодательством РФ информации |
| 6. успешная эксплуатация уязвимости в объекте | 13. несанкционированное изменение информации, обрабатываемой в объекте |
| 7. внедрение в объект модулей вредоносного ПО | 14. несанкционированное разглашение информации, обрабатываемой в объекте |
Атаки могут производиться бесчисленным количеством способов, поэтому невозможно разработать единую инструкцию для решения всех нарушений. Каждый отдельный тип инцидента нуждается в уникальной стратегии реагирования. Далее рассмотрим несколько типов угроз, основанных на общих векторах атак. Они помогут определиться с выбором стратегии реагирования.
Типы инцидентов КБ по вектору атаки:
Внешний или съемный носитель: атака выполняется со съемного носителя (например, флэш-накопителя, компакт-диска) или периферийного устройства.
Истощение: атака, в которой используются методы компрометации, ухудшения качества или уничтожения систем, сетей или сервисов. Механизм заключается в подборе учетных данных пользователя для получения несанкционированного доступа.
Веб: Атака, осуществляемая с сайта или веб-приложения.
Email: атака идет с помощью сообщений на электронную почту или вложения, ее цель — скомпрометировать данные пользователя. Этот вид атаки известен под названием «фишинг» и является одним из наиболее распространенных.
Ненадлежащее использование: любой инцидент, возникший в результате нарушения авторизованным пользователем политики организации.
Потеря или кража оборудования: потеря ноутбука, смартфона или другого носителя информации, используемого организацией.
Эксперт компании DDoS-Guard, руководитель направления защиты L7 Дмитрий Никонов, отмечает: «Мы видим, что атаки становятся более интеллектуальными. Мы активно наблюдаем за созданием геораспределенных ботнет-сетей, которые включают в себя почти все континенты планеты.
Злоумышленники создают и выкладывают проекты с открытым кодом, и инструкцией как развернуть проект у себя на ПК, чтобы стать частью ботнета. Наиболее популярные атаки сейчас: backdoors, malware, ransomware, phishing и website defacement.
Из уникальных примеров можно выделить случай, когда злоумышленники использовали онлайн-игру для атак. Все пользователи, которые заходили в нее, автоматически становились участниками централизованной атаки на определенные веб-ресурсы».
Возможные цели и мотивы злоумышленников:
| 1. вымогательство | 6. создание нечестной конкуренции |
| 2. похищение средств | 7. демонстрация силы и возможностей |
| 3. уничтожение бизнеса | 8. ущерб репутации компании или государства |
| 4. корпоративный шпионаж | 9. площадка для дальнейших атак на другие компании |
| 5. государственный шпионаж | 10. похищение ценной информации для ее продажи или использования |
Что такое план реагирования на инцидент кибербезопасности
План реагирования на инциденты кибербезопасности — это свод четко регламентированных правил, где прописаны шаги, которые сотрудники должны выполнять при обнаружении опасности. План разрабатывается совместно с высшим руководством организации и SOC (Центр информационной безопасности). Составляются сценарии по реагированию на самые распространенные методы атак. Это поможет сотрудникам правильно и оперативно действовать в любой критической ситуации.
План реагирования может использоваться в качестве руководства при ряде действий:
- обнаружение угроз;
- реагирование на инциденты;
- анализ и документирование инцидента;
- взаимодействие между подразделениями внутри организации;
- определение необходимых шагов для повышения эффективности процедур реагирования.
Необходимо регулярно проводить тестовый контроль обучения, чтобы план реагирования был знаком команде. Реакция должна быть чёткой и быстрой. Ошибки крайне нежелательны, поэтому важно проверять план на практике и анализировать скорость устранения инцидента.
Почему каждой организации нужен план реагирования
Злоумышленники атакуют как небольшие проекты, так и крупные компании, среди которых банки, энергетические компании, медиаресурсы, ИТ-предприятия и другие. Сегодня кибербезопасность — стратегическая необходимость для каждой организации.
В 2020 году компания IBM опубликовала отчет, согласно которому, лишь 26% компаний имеют четкий план реагирования на киберинциденты. Низкий уровень защищенности чреват для бизнеса и общества серьезными последствиями. Общее число происшествий растет ежеквартально, злоумышленники постоянно совершенствуют атаки, а их эффективность только повышается, поэтому важно быть начеку.
Согласно анализу компании Dragos, которая занимается вопросами кибербезопасности, средняя стоимость одного киберинцидента обходится пострадавшей стороне почти в $3 миллиона. В сумму включены расходы на устранение пришествия, и при этом они не включают упущенную выгоду.
Компания Veeam опубликовала отчет о тенденциях в области защиты данных за 2022 год, согласно которому:
- 76% организаций подверглись хотя бы одной атаке программ-вымогателей;
- 24% либо не подвергались атаке, либо еще не знают об этом;
- 42% сотрудников компаний активировали фишинговые ссылки;
- 43% инцидентов были вызваны невнимательностью со стороны администратора.
По данным опроса, в котором участвовали 1376 непредвзятых организаций, в среднем, пострадавшим удалось восстановить только 64% своих данных. Это означает, что более 1/3 данных невозможно восстановить.
Три причины, почему вам нужен план реагирования на киберинциденты
1. Сотрудники будут готовы к сложным ситуациям. Грамотно составленный план поможет вашей команде чувствовать себя уверенно. В критической ситуации каждый сотрудник будет знать, что ему делать. Это сохранит время и позволит быстро среагировать на инцидент.
2. Сохраните репутацию, деньги и нервы. Чем быстрее обнаружите вторжение злоумышленников, тем безболезненнее предотвратите возможные последствия. Хакеры не смогут завершить процесс взлома, а значит не потребуют выкуп за украденные данные или не навредят другим способом.
3. Компания будет под надежной защитой надолго. Невозможно гарантировать, что после одной атаки не последует следующей. Если у вас будет четкий план реагирования, вы не только сможете им воспользоваться, но и неоднократно улучшить, чтобы все последующие атаки все меньше воздействовали на инфраструктуру компании. Ваша команда разберет все шаги и ошибки, которые привели к атаке, что позволит действовать эффективнее в будущем.
Как составить план реагирования на инциденты кибербезопасности
План реагирования на киберинциденты должен включать в себя понятную схему действий и подробные пошаговые инструкции к ним. Для разработки плана привлекайте специалистов, которые будут участвовать в реагировании и устранении угроз.
План должен быть согласован и утвержден с высшим руководством организации. К разработке и процессу согласования могут быть привлечены также юридические специалисты и другие ответственные лица.
6 этапов создания плана реагирования на киберинциденты
1. Подготовка
На этом этапе строится вся архитектура вашего плана. Формируются основные компоненты процесса реагирования и выполняются следующие задачи:
1.1. Создать и описать стандарты политики безопасности.
1.2. Создать команду реагирования и определить роли сотрудников.
1.3. Создать и описать политику реагирования.
1.4. Определить план коммуникации для команды реагирования и всех заинтересованных сторон.
1.5. Создать журнал документирования инцидентов, в котором каждая ответственная сторона должна описать свои шаги на каждом этапе реагирования:
- кто отреагировал?
- что было затронуто?
- где произошел инцидент?
- почему было принято то или иное действие?
- как действие помогло и если нет, то описать возможную причину.
1.6. Провести обучение команды.
1.7. Проверить контроли доступа.
2. Обнаружение
На этом этапе команда должна оперативно определить, следует ли реализовывать план реагирования. Необходимо тщательно анализировать сообщения об ошибках и следить за состоянием системы.
При обнаружении подозрительной активности, предупредите всех членов команды реагирования как можно скорее. На этом этапе эффективно настроенная коммуникация критически важна.
Следует убедиться, что вся команда после обнаружения угрозы начала документировать свои действия по реагированию в журнале инцидентов (см. раздел 1.5.)
Обнаружение потенциальных угроз является обязанностью всех сотрудников компании вне зависимости, входят они в команду по реагированию на инциденты или нет. Это должно быть четко отражено в политике безопасности и регулярно повторяться на учебных мероприятиях.
Например, отдел маркетинга обнаружил странную активность на своем компьютере после открытия ссылки, которая пришла на почту. Сотрудник должен незамедлительно сообщить ответственному лицу из команды реагирования о ситуации.
3. Сдерживание
Цель данного этапа — оперативно предотвратить повреждение сети, даже если это задерживает основные бизнес-процессы. Сдерживание состоит из следующих шагов:
3.1. Краткосрочное сдерживание. Постарайтесь предотвратить дальнейшее повреждение сети и сделать это быстро. Несколько примеров краткосрочной стратегии сдерживания:
- отключение зараженных устройств из сети;
- изоляция зараженного элемента сети;
- отключение маршрутизатора в зараженных сетях.
3.2. Выполните судебную экспертизу, если того требует устав вашей компании.
3.3. Регулярно делайте резервные копии системы. Это образ диска с программным обеспечением и данные, которые сохранены на нем. Процедура необходима для того, чтобы в случае критических изменений была возможность вернуть систему в исходное рабочее состояние. Также сохраните копию зараженной системы, чтобы в дальнейшем была возможность проанализировать инцидент.
3.4. Долгосрочное сдерживание. Восстановите работоспособность бизнеса путем исправления затронутых систем, удаления backdoor, либо перенаправьте сетевой трафик для очистки систем резервного копирования.
3.5. Протестируйте бизнес-операции, чтобы убедиться, что они вернулись к рабочему состоянию.
4. Ликвидация
Первые шаги по ликвидации киберугрозы предпринимаются уже на 3 этапе (сдерживание). Они продолжаются до завершения этапа ликвидации.
Условия по устранению включают:
- Сканирование зараженных систем на наличие вредоносных программ и их следов.
- Отключение зараженных систем, чтобы защитить сеть.
- Устранение уязвимостей в исправных резервных копиях.
5. Восстановление
На этом этапе идет возвращение систем в их первоначальное состояние. Процесс начинается с замены сред, уже прошедших стадию ликвидации, безопасными резервными копиями.
Важно помнить, что копии могут содержать те же уязвимости, которые и привели к инциденту. Поэтому зараженные файлы необходимо устранить в первую очередь.
Перед повторным подключением всей восстановленной системы рекомендуется проверить журнал событий системы на предмет аномалий, которые укажут на продолжающееся заражение вредоносным ПО или же наличие АРТ-атак (Advanced Persistent Threat).
6. Получение знаний
Цель этапа — завершение документации по прошедшему циклу атаки. В отчете следует четко прописать всю последовательность действий. Описание должно быть понятно заинтересованным сторонам.
Рекомендуется собраться всем участникам инцидента не позднее двух недель после события. На встрече следует обсудить киберинцидент, его обнаружение, обработку и устранение, а также предложить варианты по возможному улучшению каждого из этапов.
На обсуждении участники могут обсудить следующие вопросы:
- Кто обнаружил инцидент?
- Кто сообщил об инциденте?
- Как локализовали инцидент?
- Когда был обнаружен инцидент?
- Кому было сообщено об инциденте?
- Как очищали скомпрометированные системы?
- Какие процессы задействовали для восстановления?
- В какой области команда наиболее эффективно сработала?
- Какие шаги были приняты для анализа успеха мер по ликвидации?
- Как можно улучшить действия по реагированию на возможные киберугрозы?
Подходите к составлению плана как к жизненному циклу, где каждая фаза реагирования идет в правильной последовательности. Шаги должны основываться на понимании и четкой работе.
Что должно быть в плане реагирования: чек-лист из 10 шагов
Когда случается непредвиденная ситуация, нет времени разбирать стратегии реагирования. В таком случае пригодится сжатая и полезная информация о том, какие шаги следует предпринять в кратчайшие сроки, чтобы ликвидировать угрозу.
Используйте инструкцию по контрольному списку действий реагирования на киберинциденты.
Что должен включать в себя план реагирования на инциденты
1. Оценка рисков в масштабе организации
Основной целью является определение вероятности рисков в инфраструктуре кибербезопасности.
2. Анализ инфраструктуры предприятия в ключевых областях
Используйте оценку рисков для выявления уязвимых мест. Определите и опишите приоритет реагирования по низким и средним рискам.
3. Определение членов команды реагирования
Задокументируйте роли и обязанности каждого ключевого лица команды. Проведите обучение, и протестируйте функции команды.
4. Документирование и приоритизация основных типов киберинцидентов
В плане реагирования должно быть определено, что считается инцидентом и кто отвечает за активацию стратегии реагирования. Важно выявить и описать приоритет инцидентов. От этой информации будет зависеть насколько оперативно произойдет обработка угрозы, и какие ресурсы будут задействованы для нормализации и восстановления инфраструктуры компании. Обновляйте информацию в документах, изучайте новые атаки злоумышленников и хакерские тренды.
5. Инвентаризация всех ресурсов и активов компании
- Бизнес-ресурсы: члены команды, отдел кибербезопасности, деловые партнеры.
- Бизнес-процессы: частичное сдерживание, стратегия наблюдения и отключения системы, деактивация, — все эти ресурсы следует включить в ваш план реагирования. Воспользуйтесь ими в зависимости от типа и серьезности нарушения безопасности.
6. Создание блок-схем с иерархией полномочий и последовательностью действий команды реагирования
Определите шаги, которые нужно выполнить на разных этапах реагирования. Выявите, кто является ответственным менеджером на этих этапах, а кто контактным лицом между вами, вашими клиентами, правоохранительными органами, СМИ.
Все данные соберите в единую схему полномочий.
7. Актуализация контактной информации о команде реагирования и всех заинтересованных сторон (страховые компании, юристы и так далее)
Составьте базу контактной информации, которая будет обновляться. Команда сможет обратиться к ней в критической ситуации, чтобы не тратить время на поиски.
8. Подготовка шаблонов публичных заявлений
Заранее спланируйте публичные заявления. Шаблоны должны быть на разные случаи: электронные письма скомпрометированным пользователям, письма для связи со СМИ, шаблоны заявлений о нарушении. Отнеситесь внимательно к информации, которую сообщаете массовой аудитории.
9. Подготовка и ведение журнала инцидента
Во время и после инцидента кибербезопасности вам потребуется отслеживать как, кто, когда и где обнаружил и устранил нарушение. Эта информация должна вноситься в журнал инцидента. Подготовьте шаблон заранее, чтобы его было легко заполнить. Он должен включать:
- место, время и характер обнаружения инцидента;
- детали связи: кто, что и когда;
- релевантные данные вашего ПО для создания актуальных отчетов о безопасности и журналов событий.
10. Разработка и описание стратегии тестирования эффективности мер реагирования
Совместно с командой реагирования пропишите несколько ключевых стратегий реагирования. Регулярно собирайтесь для обсуждения и улучшения данного процесса. Используйте руководства, шаблоны и чек-листы, которые будут дополняться и расширяться в соответствии с актуальными изменениями.
Примеры плана реагирования на инциденты кибербезопасности
В сети есть общедоступные примеры планов реагирования на киберинциденты. Мы собрали несколько полезных и эффективных шаблонов, которые можно использовать как руководство, чтобы создать собственный план реагирования. Изучите примеры и адаптируйте под свою компанию. Обратите внимание, что все документы англоязычны.
1. Шаблон Национального института стандартов и технологий (NIST)
Основные разделы документа:
- организация реагирования;
- регулирование;
- координация и обмен информацией;
- сценарии обработки;
- анализ данных, связанных с инцидентом.
2. Шаблон Калифорнийского института технологий
Файл содержит 17-шаговую базовую процедуру реагирования на инциденты со ссылками на более подробные специализированные планы. Кратко рассмотрены различные типы инцидентов.
3. Шаблон Института передовых технологий (SANS)
Руководство разработано институтом SANS и базируется на общедоступных источниках. SANS является одним из крупнейших в мире исследовательских центров в области кибербезопасности.
В документе представлены подробные рекомендации и стандарты реагирования на различные угрозы. Он доступен для использования, изменения и переформатирования в соответствии с конкретными потребностями вашей организации.
Еще один полезный инструмент — чек-лист Microsoft для подготовки вашей команды безопасности к реагированию на инциденты кибербезопасности.
Является ли план реагирования обязательным
Наличие плана реагирования КБ имеет рекомендательный характер. Российское законодательство не предусматривает обязательным использование и разработку плана реагирования на киберинциденты. Однако ряд законов и ГОСТов регулируют юридическую сторону вопроса обеспечения информационной безопасности.
В частности ГОСТ Р ИСО/МЭК ТО 18044-2007 регулирует вопросы менеджмента инцидентов информационной безопасности, куда входят рекомендации по созданию плана реагирования на инциденты КБ.
Для принятия правильных правовых мер, следует точно определить уровень защиты информации вашей компании.
Выделяют три уровня системы защиты конфиденциальной информации:
- правовой;
- организационный;
- технический.
Важным моментом является не только установление самого перечня конфиденциальной информации, но и порядка ее защиты, а также порядка её использования.
В соответствии со ст. 10 Закона N 98-ФЗ по охране конфиденциальности информации, меры принимаемые ее обладателем, должны включать в себя:
- определение перечня данных, составляющих коммерческую тайну;
- ограничение доступа к таким сведениям путем установления порядка обращения с ними и контроля за соблюдением этого порядка;
- организацию учета лиц, получивших доступ к конфиденциальной информации, или лиц, которым она была предоставлена;
- регулирование отношений по использованию данных, составляющих коммерческую тайну, работниками на основании трудовых договоров и контрагентами на основании гражданско-правовых договоров;
- нанесение на материальные носители и документы, содержащие конфиденциальную информацию грифа «Коммерческая тайна» с указанием владельца такой информации.
В соответствии с ГОСТ Р 50922-2006 можно выделить следующие меры защиты конфиденциальной информации:
- защита от утечки;
- защита от разглашения;
- защита от неправомерного воздействия;
- защита от преднамеренного воздействия;
- защита от несанкционированного доступа;
- защита от несанкционированного воздействия.
Как использовать информацию об инцидентах КБ для избежания их в будущем
Используйте всю собранную информацию по прошедшим инцидентам для регулярного обучения сотрудников. Совместно с командой реагирования разбирайте шаги плана реагирования и пересматривайте действия. Анализ и обсуждение всех инцидентов позволит улучшить и внедрить новые элементы управления. Рекомендуется пересматривать политику реагирования минимум раз в год.
Если у вас еще нет команды реагирования на инциденты кибербезопасности, пришло время ее создать. Включите в команду ключевых членов компании: специалистов отдела безопасности, юристов, PR-специалистов.
Подведем итоги
План реагирования на инциденты кибербезопасности — это необходимая мера защиты, которая поможет пережить эмоциональный хаос, часто сопутствующий атакам. Сценарий реагирования даст понятную стратегию смягчения последствий и минимизирует воздействие активных киберугроз.
Ваш план должен стать четким и действенным документом, который удобно использовать в самых разнообразных сценариях.
Помните, что защита вашей организации от кибератак — это масштабный процесс, который включает в себя различные этапы: от базы, на которой строится защита сетевой инфраструктуры, до создания плана реагирования на киберинциденты.
План реагирования на инциденты кибербезопасности — это набор инструкций, призванных помочь компаниям подготовиться к инцидентам сетевой безопасности, обнаружить их, отреагировать на них и восстановиться после них. Большинство планов ориентированы на технологию и касаются таких вопросов, как обнаружение вредоносных программ, кража данных и перебои в обслуживании. Однако любая значительная кибератака может повлиять на организацию в различных сферах деятельности, поэтому план должен охватывать такие области, как HR, финансы, обслуживание клиентов, коммуникации с сотрудниками, юридические вопросы, страхование, связи с общественностью, регулирующие органы, поставщики, партнеры, местные власти и другие внешние организации.
Существуют отраслевые стандарты реагирования на инциденты, разработанные такими организациями, как NIST и SANS, которые содержат общие рекомендации по реагированию на активный инцидент. Однако план реагирования на инциденты организации должен быть гораздо более конкретным и действенным — в нем подробно описано, кто, что и когда должен делать. В статье составлен контрольный список, в котором указаны ключевые компоненты плана.
Как создать план реагирования на инциденты
Любая организация, имеющая цифровые активы (компьютеры, серверы, облачные сервисы, данные и т. д.), потенциально может подвергнуться кибератаке или утечке данных. Создание плана реагирования на инциденты кибербезопасности поможет подготовиться к неизбежному и оснастить команду средствами реагирования до, во время и после кибератаки.
В идеале план реагирования на инциденты безопасности должен использоваться на постоянной основе, как живой документ, для осуществления повторяющихся действий по обнаружению и реагированию (поиск угроз, расследование кибер-инцидентов, реагирование на инциденты и устранение/восстановление). Выполняя постоянные действия по обнаружению и реагированию на инциденты, можно улучшить гигиену IT и безопасности и лучше защитить организацию от неизвестных угроз, скрытых злоумышленников и, возможно, предотвратить утечку данных.
Процесс планирования реагирования на инциденты разделен на несколько этапов:
Подготовка — это первый этап планирования реагирования на инциденты и, пожалуй, самый важный для защиты вашего бизнеса и цифровых активов. На этапе подготовки важно задокументировать и объяснить роли и обязанности команды инфраструктуры, в том числе установить основную политику безопасности, на основе которой будет разрабатываться план.
Определить, достаточно ли у в настоящее время IT-ресурсов для реагирования на атаку или потребуется поддержка сторонних организаций.
Распределить роли и обязанности всех заинтересованных сторон, включая IT, HR, внутренние коммуникации, поддержку клиентов, юридическую службу, PR и консультантов.
Составить схему рабочего процесса реагирования на инцидент между различными заинтересованными сторонами. Когда привлекается отдел кадров? Когда привлекается юридическая служба? Когда оповещаются СМИ? Когда привлекаются внешние органы?
Определить нормативные требования по кибербезопасности для организации по всем функциям и разработайте руководство по взаимодействию с правоохранительными и другими государственными органами в случае инцидента.
Хранить привилегированные учетные данные, включая пароли и ключи SSH, в надежном централизованном хранилище.
Автоматически менять привилегированные учетные данные, изолировать сессии привилегированных учетных записей для временных сотрудников.
Обнаружение и анализ
Фаза обнаружения при планировании реагирования на инциденты безопасности включает в себя мониторинг, обнаружение, оповещение и отчетность о событиях безопасности. Сюда входит выявление известных, неизвестных и предполагаемых угроз — тех, которые кажутся вредоносными по своей природе, но на момент обнаружения недостаточно данных, чтобы сделать то или иное заключение.
При обнаружении зацепки, угрозы или инцидента безопасности команда реагирования на инциденты должна немедленно (если не автоматически с помощью программного обеспечения для реагирования на кибер-инциденты) собрать и задокументировать дополнительную информацию — криминалистические доказательства, артефакты и образцы кода, чтобы определить серьезность, тип и опасность инцидента, а также сохранить эти данные для использования в судебном преследовании злоумышленника (злоумышленников) в более поздний момент времени.
Разработать стратегию проактивного обнаружения на основе инструментов, которые могут автоматически сканировать физические и виртуальные хосты, системы и серверы на наличие уязвимых приложений, идентификационных данных или учетных записей.
Рассмотреть традиционные решения, такие как антивирусное ПО или инструменты для обнаружения вредоносного ПО.
Провести оценку компрометации, чтобы проверить, была ли нарушена сеть, и быстро определить наличие известных вредоносных программ и постоянных угроз «нулевого дня», активных или спящих, которые обошли существующие средства защиты кибербезопасности.
Реагирование
Реагирование на инциденты безопасности может принимать различные формы. Действия по реагированию на инциденты могут включать сортировку оповещений от ваших средств защиты конечных точек, чтобы определить, какие угрозы являются реальными, и/или приоритет в устранении инцидентов безопасности. Действия по реагированию на инцидент могут также включать сдерживание и нейтрализацию угрозы (угроз) — изоляцию, выключение или иное «отключение» зараженных систем от вашей сети для предотвращения распространения кибератаки. Кроме того, операции по реагированию на инциденты включают устранение угрозы (вредоносных файлов, скрытых бэкдоров и артефактов), которая привела к инциденту безопасности.
Немедленно изолировать системы, сети, хранилища данных и устройства, чтобы минимизировать масштабы инцидента и изолировать его от нанесения широкомасштабного ущерба.
Определить, были ли похищены или повреждены конфиденциальные данные, и если да, то каков потенциальный риск для бизнеса.
Удалить зараженные файлы и, если необходимо, замените оборудование.
Вести полный журнал инцидента и ответных действий, включая время, данные, местоположение и степень ущерба от атаки. Была ли это внутренняя, внешняя атака, системное оповещение или один из методов, описанных ранее? Кто ее обнаружил и как было сообщено об инциденте? Перечислить все источники и время, через которые прошел инцидент. На каком этапе подключилась команда безопасности?
Сохранить все детали нарушения для дальнейшего анализа происхождения, воздействия и намерений.
Обновить все брандмауэры и сетевую защиту, чтобы зафиксировать доказательства, которые впоследствии можно будет использовать для судебной экспертизы.
Привлечь команду юристов и изучите соответствие и риски, чтобы выяснить, не влияет ли инцидент на какие-либо нормативные акты.
Восстановление и последующие действия
Действия после инцидента (восстановление и последующие действия) включают устранение риска безопасности, анализ и отчет о произошедшем, обновление информации об угрозах с учетом новой информации о том, что хорошо, а что плохо, обновление плана с учетом уроков, извлеченных из инцидента безопасности, а также подтверждение и повторное подтверждение того, что среда действительно свободна от угрозы (угроз).
Заключение
Помните, что разработка плана реагирования на инциденты в сфере кибербезопасности не является одноразовым мероприятием. К сожалению, без регулярных тренингов по реагированию на инциденты и учений, включая сценарии кибератак в реальном времени, организации и их команды IT-безопасности могут внезапно обнаружить, что хакеры, которые меняют свои стратегии атак и выбор вредоносных программ, не справляются с задачей.
То, что сработало в прошлом, может не сработать завтра. Правильный план реагирования на инциденты безопасности должен быть «живым» документом, который не отстает от быстро меняющегося ландшафта угроз.
Основные термины (генерируются автоматически): инцидент, инцидент безопасности, план реагирования, реагирование, данные, действие, угроза, NIST, SANS, юридическая служба.