Обзор специальных публикаций NIST по управлению киберинцидентами
В предыдущих публикациях мы сделали обзор самых интересных на наш взгляд специальных публикаций NIST по информационной безопасности. В данном посте мы рассмотрим два документа от NIST, которые посвящены выстраиванию процессов реагирования на инциденты ИБ: публикации NIST SP 800–61 «Computer Security Incident Handling Guide» («Руководство по обработке инцидентов компьютерной безопасности») и NIST SP 800–83 «Guide to Malware Incident Prevention and Handling for Desktops and Laptops» («Руководство по предотвращению и обработке инцидентов заражения ВПО на десктопах и лэптопах»). Приступим!
NIST SP 800–61 «Computer Security Incident Handling Guide»
Для эффективного реагирования на инциденты ИБ чрезвычайно важно заблаговременно выстроить четкий процесс управления киберинцидентами, поскольку именно в момент наступления инцидента, в условиях стресса и возможного отсутствия ресурсов, требуется максимально корректно выполнить все необходимые этапы реагирования. Для решения данной задачи можно воспользоваться методическими рекомендациями документа NIST SP 800–61 Rev. 2 «Computer Security Incident Handling Guide» («Руководство по обработке инцидентов компьютерной безопасности», версия 2), который вышел в 2012 году, но концептуально не устарел, поскольку предложенный в нем фреймворк и описанные организационные и технические аспекты реагирования на киберинциденты можно адаптировать под современные технологии и актуальные киберугрозы.
Организационные рекомендации документа NIST SP 800–61
Документ NIST SP 800–61 предлагает использовать следующие определения:
Событие — это любое зафиксированное явление в системе или сети (например, подключение пользователя к файловому серверу, обработка веб-запроса сервером, отправка email-сообщения, блокирование межсетевым экраном сетевого соединения).
Неблагоприятное событие — это событие с негативными последствиями (например, преднамеренный сбой в работе ПО, несанкционированный доступ к данным, несанкционированное использование повышенных привилегий, запуск вредоносного ПО).
Киберинцидент — это нарушение или неизбежная угроза нарушения политик ИБ, политик допустимого использования или стандартных практик ИБ.
При выстраивании процесса управления киберинцидентами важно разработать политику, план и процедуры реагирования на киберинциденты.
Политика реагирования на киберинциденты должна быть индивидуально разработана для каждой конкретной организации и включать в себя такие элементы, как:
1. Утверждение о вовлеченности руководства компании в процесс реагирования на киберинциденты и понимание его важности на всех уровнях компании;
2. Цели и задачи политики;
3. Термины и определения для создания единого понятийного аппарата;
4. Организационная структура и распределение ролей, ответственности, полномочий и уровней принятия решений;
5. Уровни критичности и приоритизация инцидентов;
6. Метрики эффективности процесса реагирования на киберинциденты;
7. Формы отчетности и отправки уведомлений.
План реагирования на киберинциденты должен отражать формализованный, согласованный и специфичный для конкретной организации подход к реагированию на киберинциденты, в котором будут отражены следующие элементы:
1. Миссия, стратегия и цели плана реагирования на киберинциденты;
2. Согласование плана руководством компании;
3. Общий подход компании к реагированию на киберинциденты;
4. Структура команды реагирования на киберинциденты;
5. Способ взаимодействия команды реагирования с работниками компании и с другими компаниями;
6. Метрики оценки возможностей и эффективности функции реагирования на киберинциденты в компании;
7. «Дорожная карта» повышения уровня зрелости функции реагирования на киберинциденты в компании;
8. Взаимосвязь функции реагирования на киберинциденты с другими функциями в компании.
Процедуры реагирования на киберинциденты должны опираться на политику и план реагирования и содержать детальное описание технических процессов, действий, техник, чек-листов и форм отчетности. Для каждого типа инцидента следует разработать отдельные процедуры реагирования, в которых будет учтена специфика инфраструктуры компании и конкретных действий по реагированию на определенный тип инцидента.
В рамках разработки документов по управлению киберинцидентами следует описать формат и способ взаимодействия со сторонними лицами в случае выявления инцидента:
1. Взаимодействие со СМИ: следует назначить ответственного за взаимодействие со СМИ, рассмотреть необходимость привлечения юридического департамента во время общения со СМИ, предусмотреть формат и объем сообщаемой информации об инциденте для уменьшения полезной для атакующих публичной информации, продумать формат краткого обсуждения подробностей инцидента с уполномоченными по взаимодействию со СМИ, предусмотреть способы актуализации информации об инциденте для СМИ, проинструктировать сотрудников компании о возможных форматах взаимодействия со СМИ. Также рекомендуется проводить тренировочные интервью, заранее прорабатывая ответы на вопросы о том, кто и зачем атаковал вашу компанию; когда, как и почему это случилось; насколько разрушительным был инцидент и как идет его внутреннее расследование; каковы последствия инцидента, была ли затронута охраняемая законом информация (например, персональные данные), каков предварительный финансовый ущерб от инцидента.
2. Взаимодействие с государственными органами: в зависимости от страны, к компаниям могут применяться различные требования по оповещению государственных структур по фактам выявления инцидента ИБ. Следует назначить ответственного за взаимодействие с госорганами, который должен знать формат взаимодействия и быть подготовленным юридически и технически.
3. Взаимодействие с центрами реагирования на киберинциденты: обязательное предоставление информации о произошедшем киберинциденте в государственные центры реагирования на киберинциденты (в РФ это ФинЦЕРТ и НКЦКИ) или обмен информацией о произошедших инцидентах и получение помощи от отраслевых или коммерческих центров противодействия кибератакам.
4. Взаимодействие с интернет-провайдером: блокирование сетевого трафика (например, в случае DDoS-атаки), сохранение и получение логов сетевых соединений.
5. Взаимодействие с владельцем атакующего IP-адреса: в случае атаки можно взаимодействовать с Abuse-контактом внешнего провайдера или с владельцем автономной системы.
6. Взаимодействие с вендорами: взаимодействие с ИБ-вендором может помочь при возникновении вопросов по работе с СЗИ или при вероятных ложноположительных срабатываниях, а взаимодействие с производителем ПО поможет обменяться информацией о возможных уязвимостях или новых векторах атак на софт.
7. Взаимодействие с третьими лицами, затронутыми инцидентом: клиенты, контрагенты, поставщики, подрядчики могут быть затронуты инцидентом, произошедшим в компании, либо они могут сообщить об инциденте, источником которого может являться ваша компания. В обоих случаях следует предусмотреть формат взаимодействия и объем передаваемой вовне информации.
В документе NIST SP 800–61 рассматриваются также различные варианты структуры команды реагирования на киберинциденты, которые могут состоять из штатных сотрудников или быть частично / полностью на аутсорсе:
1. Централизованная команда реагирования: данная модель подходит для небольших организаций, не имеющих географически разветвленной структуры.
2. Распределенная команда реагирования: данная модель подходит для больших географически распределенных компаний, где за каждый сегмент или филиал отвечает своя выделенная команда. При этом все филиальные команды реагирования централизованно управляются и координируются головной структурой.
3. Координирующая команда: может использоваться для помощи и оказания услуг в случаях, когда между командами в различных филиалах нет прямого подчинения.
Следующие факторы следует учитывать при выборе структуры команды реагирования:
1. Потребность в работе команды в режиме 24/7: необходимость круглосуточной работы может быть продиктована структурой бизнес-процессов компании, при этом рекомендуется именно круглосуточная работа дежурной смены.
2. Члены команды, работающие полный рабочий день или частично занятые на других должностях: некоторые этапы реагирования на киберинциденты могут выполняться сотрудниками, которые штатно работают в других департаментах, например, в ИТ, но на время инцидента подключаются к работе команды реагирования.
3. Мотивация сотрудников: недостаток квалифицированных специалистов и сложность круглосуточной работы в команде реагирования приводят к ожидаемым сложностям при наборе кадров, поэтому рекомендуется снять с членов команды административную нагрузку и снизить количество рутинных операций.
4. Затраты: компания может недооценивать бюджетирование работы круглосуточной дежурной смены, включая фонд оплаты труда и затраты на программное обеспечение и СЗИ, а также техническое обеспечение работы команды (помещение, связь, техника).
5. Опыт и экспертиза сотрудников: обработка киберинцидентов требует специфического опыта, при этом у MSSP-провайдеров может быть более сильная экспертиза, но отсутствовать глубокое понимание процессов конкретной компании. У штатных сотрудников есть глубокое понимание инфраструктуры и контекст бизнес-процессов конкретной компании, при этом может отсутствовать обширная база знаний по решению инцидентов и актуальная информация о трендах кибератак.
При передаче на аутсорс части функций реагирования на киберинциденты подрядчикам, например, MSSP-провайдерам, следует учитывать следующие факторы:
1. Оценка качества работы аутсорс-компании, при этом не только текущих показателей, но и будущих перспектив сотрудничества, включая инвестиции аутсорсинговой компании в свои сервисы и специалистов.
2. Разделение обязанностей: некоторые критичные операции компания будет, вероятно, выполнять самостоятельно (например, изоляция хостов, отключение учетных записей и т.д.), поэтому следует заранее определить зоны ответственности и выполняемые действия.
3. Передача конфиденциальной информации подрядчику: определение зон ответственности, разграничение прав доступа, подписание соглашений о неразглашении, применение технических способов сокрытия определенной чувствительной информации могут помочь в решении вопроса обработки внутренней информации аутсорсерами.
4. Недостаток знаний о специфике инфраструктуры организации, отсутствие доступа к определенным журналам событий безопасности, отсутствие физического доступа к оборудованию — эти типовые ограничения работы подрядчиков также следует учитывать.
5. Поддержка уровня внутренних компетенций: в различных ситуациях услуги аутсорсеров могут стать недоступными, и в таком случае компании важно иметь собственных сотрудников, которые смогут сами корректно отреагировать на инцидент.
Технические рекомендации документа NIST SP 800–61
В соответствии с документом NIST SP 800–61, реагирование на инциденты ИБ состоит из нескольких взаимосвязанных процессов:
1. Подготовка;
2. Детектирование;
3. Анализ;
4. Сдерживание;
5. Устранение;
6. Восстановление;
7. Пост-инцидентные действия;
Далее опишем подробнее все рекомендации для выстраивания указанных процессов управления киберинцидентами.
1. Подготовка
Документ NIST SP 800–61 подчеркивает важность приложения максимальных усилий для подготовки к реагированию на киберинциденты и недопущения их возникновения.
1.1. Подготовка к обработке инцидентов ИБ.
В публикации NIST SP 800–61 подчеркивается важность полноценной и заблаговременной подготовки всех ресурсов и инструментов для эффективного реагирования на инциденты ИБ, также как говорится и о необходимости наличия резервных надежных способов связи, взаимодействия и координации на случай их выхода из строя или компрометации. Следует подготовить следующие ресурсы и инструменты:
1.1.1. Способы взаимодействия и обеспечения реагирования на киберинциденты:
1) Контактная информация членов команды реагирования на инциденты ИБ (далее — КРИИБ), сотрудников компании, внешних контрагентов, включая контактную информацию основного и запасного персонала, включая номера телефонов, адреса email, псевдонимы в мессенджерах, а также способы проверки аутентичности контакта;
2) Информация о дежурных сменах других команд в компании, включая информацию, необходимую для эскалации запросов;
3) Способы сообщения пользователями информации об инцидентах, включая телефонные номера, адреса email, веб-формы, мессенджеры; при этом как минимум один способ должен позволять передавать информацию анонимно;
4) Тикетинг-система для хранения информации об инциденте и мониторинга его статуса (в настоящее время данные функции включены в IRP/SOAR-системах);
5) Смартфоны для связи членов КРИИБ с установленным необходимым ПО;
6) ПО для шифрования информации, при необходимости;
7) Выделенная переговорная комната / конференц-зал (т.н. war room, буквально «командный пункт») для совместной работы членов КРИИБ;
8) Выделенное место для защищенного хранения предметов, имеющих отношение к инциденту.
1.1.2. Программное и аппаратное обеспечение для анализа киберинцидентов:
1) Устройства и накопители для создания образов дисков, хранения логов, сохранения иной относящейся к инциденту информации;
2) Ноутбуки для работы аналитиков, включая анализ данных и трафика, подготовки отчетов по инцидентам;
3) Запасное оборудование, включая АРМ и серверы, сетевое оборудование, виртуальные машины для действий, выполняемых при реагировании, например, для восстановления информации или анализа ВПО;
4) Чистые накопители;
5) Принтер для печати значимой информации;
6) Снифферы пакетов и анализаторы протоколов для захвата и анализа сетевого трафика;
7) ПО для форензики устройств и накопителей;
8) Носители с ПО для сбора свидетельств с устройств и систем;
9) Аксессуары для корректного и юридически значимого сбора доказательств и свидетельств, такие как видео- и аудио-записывающие устройства, пакеты и конверты для хранения улик, подготовленные формы для сохранения доказательства целостности улик (т.н. chain of custody, цепочка хранения).
1.1.3. Методические документы для анализа инцидентов:
1) Список стандартных сетевых портов и типичных сетевых портов, используемых ВПО;
2) Документация на ОС, ПО, СЗИ, устройства;
3) Сетевые схемы, списки критичных информационных активов в инфраструктуре;
4) Baseline-данные об известном нормальном поведении сетей, систем, приложений;
5) Значения криптографических хэш-сумм известных критичных файлов (можно руководствоваться данными репозиториев NIST NSRL и данными проекта xCyclopedia).
1.1.4. ПО для снижения последствий инцидента: «золотые образы» ОС и дистрибутивы ПО для восстановления систем после инцидентов.
1.2. Предотвращение инцидентов.
Обеспечение кибербезопасности и предотвращение киберинцидентов важно с точки зрения КРИИБ по причине того, что слишком большой объем инцидентов не позволит оперативно реагировать на каждый из них, что может привести к значительному ущербу, при этом члены КРИИБ могут предоставить ценную информацию о слабых местах защиты и дать свои рекомендации. Авторы документа NIST SP 800–61 подчеркивают, что перечисление всех возможных способов предотвращения киберинцидентов выходит за рамки данной публикации, но приводят список основных направлений обеспечения ИБ:
1) Оценка киберрисков позволяет выявить и обработать риски ИБ, а также выявить информационные активы, чье состояние защищенности необходимо контролировать и реагировать на соответствующие инциденты;
2) Безопасность конечных точек следует обеспечить путем применения стандартизированных конфигураций безопасности, обновления ПО, обеспечения принципа наименьших привилегий, журналирования событий ИБ, мониторинга состояния и конфигураций;
3) Сетевая безопасность должна работать по принципу «запрещено все, что явно не разрешено» с обеспечением защиты периметра, точек подключения и каналов сетевого взаимодействия;
4) Борьба с ВПО должна обеспечиваться на уровне ОС, серверных приложений, на клиентском уровне;
5) Awareness-тренинги пользователей и администраторов могут содержать «выученные уроки» о произошедших инцидентах и должны помочь сотрудникам компании осознать важность своевременного сообщения о признаках инцидента, а администраторам — понять необходимость безопасной настройки ИТ-систем.
2. Детектирование
2.1. Вектора кибератак.
Подготовиться ко всем киберинцидентам нереально, поэтому составители NIST SP 800–61 рекомендуют сосредоточиться на наиболее распространенных типах инцидентов, в которых применяются общие вектора атак. При этом для каждого типа инцидента следует разработать отдельную стратегию реагирования. В документе приводится ограниченный список типовых методов атак, который можно использовать для разработки детальных специфичных процедур обработки (сегодня также можно порекомендовать использовать матрицу MITRE ATT&CK для понимания тактик и техник современных кибератак). Список типовых векторов атак, по состоянию на год выпуска публикации NIST SP 800–61 (2012 год) выглядел следующим образом:
1) Внешние / съемные накопители;
2) Истощение ресурсов (например DDoS или атаки перебора);
3) Веб-атаки (например, XSS);
4) email-атаки (вредоносные вложения, фишинг);
5) Атаки подмены (спуфинг, MitM-атаки, SQL-инъекции);
6) Недопустимое использование (нарушение корпоративных политик допустимого использования информационных ресурсов);
7) Утеря или кража оборудования, устройств;
8) Иные атаки, не подпадающие под перечисленные выше категории.
2.2. Признаки киберинцидента.
Одним из самых сложных этапов при реагировании может являться корректное выявление и оценка потенциальных киберинцидентов, включая заключение о том, действительно ли произошел инцидент, какого он типа, каков его масштаб и опасность. Основными сложностями при выявлении и оценки инцидентов являются большое количество событий от различных источников, предоставляемых с разной детальностью и точностью, возможные скрытые и неявные признаки инцидентов, а также необходимость иметь специализированные технические знания для выявления инцидентов.
Признаки киберинцидентов можно условно разделить на прекурсоры и индикаторы инцидентов ИБ:
1) Прекурсор — это признак того, что инцидент ИБ может произойти в будущем (например, сканирование портов, обнаружение новой уязвимости в инфраструктуре компании, угрозы от кибергруппировок). При выявлении прекурсоров кибератаку можно предотвратить, повысив состояние защищенности потенциальной цели атаки и детальность мониторинга.
2) Индикатор — это признак того, что инцидент уже произошел или происходит прямо сейчас (например, сообщения от СЗИ, вредоносная активность, сбои в работе систем, неуспешные попытки аутентификации, сообщения от ИТ-администраторов).
Источниками прекурсоров и индикаторов киберинцидентов в общем случае могут быть алерты от СЗИ (IDS/IPS-системы, SIEM-системы, антивирусные и антиспам решения, ПО для контроля целостности, сообщения от сторонних сервисов мониторинга), логи (журналы ОС, ПО, сервисов, сетевых устройств, сетевые потоки (netflow, sFlow и т.д.)), публично доступная информация (информация об эксплойтах, уязвимостях), люди (персонал внутри компании, сторонние пользователи).
3. Анализ.
3.1. Первичный анализ информации об инциденте.
Большинство прекурсоров и индикаторов инцидентов могут неточными, поэтому инциденты бывает достаточно трудно выявить и проанализировать. Некоторые инциденты могут быть выявлены по явным симптомам (например, недоступность ресурса или дефейс), но свидетельства других инцидентов могут быть крайне малозаметными (например, лишняя строка в конфигурационном файле), поэтому выявление инцидентов является во многих случаях творческой задачей для квалифицированных ИБ-аналитиков. Члены КРИИБ должны оперативно и слаженно анализировать и проверять каждый инцидент, следуя заранее разработанному процессу и документируя каждый сделанный шаг. В случае появления подозрений на «боевой» инцидент, члены КРИИБ должны оперативно провести первичный анализ для выявления масштабов инцидента (какие сети, системы, приложения затронуты), кто или что является причиной инцидента, каким образом осуществляется атака (какие инструменты и методы использую атакующие, какие уязвимости эксплуатируются). В результате первичного анализа должно появится достаточное количество информации для приоритизации последующих действий, таких как сдерживание инцидента и более глубокий анализ последствий инцидента.
Для упрощения анализа инцидентов и повышения эффективности проверки информации о возможных инцидентах авторы NIST SP 800–61 предлагают следующие рекомендации:
1) Составление профилей сетей и систем для понимания нормального состояния и поведения систем в целях последующего выявления изменений, например, путем установки ПО для контроля целостности, изучения типичного сетевого трафика для различных систем и дней недели;
2) Понимание нормального поведения систем, сетей, приложений путем изучения журналов аудита и выявления подозрительных событий, при этом рекомендуется взаимодействовать с профильными сотрудниками, отвечающими за соответствующие элементы инфраструктуры;
3) Разработка политики хранения журналов аудита и настройка времени хранения логов поможет выявить более ранние значимые события ИБ или обнаружить ранее незамеченные инциденты ИБ;
4) Корреляция событий ИБ для более точного выявления и понимания возможного инцидента;
5) Синхронизация времени на всех элементах инфраструктуры;
6) Поддержка и использование внутренней базы знаний с документацией, описанием инцидентов, кодов ошибок и алертов, перечислением действенных способов решения инцидентов для упрощения работы членов КРИИБ и накопления опыта в единой информационной структуре;
7) Использование интернет-поисковиков для получения информации об обнаруженных прекурсорах и индикаторах;
8) Запуск сетевых снифферов для сбора дополнительной информации из сетевого трафика в случае недостаточности имеющейся информации;
9) Фильтрация данных для анализа только значимых индикаторов для ускорения поиска следов атаки в условиях недостатка времени;
10) Обращение за помощью к другим командам, к MSS-провайдерам услуг реагирования на инциденты для оперативного решения инцидента и выявления причин инцидента с целью недопущения его повторения.
3.2. Документирование.
При выявлении инцидента членам КРИИБ следует немедленно начать документировать все факты и свидетельства, касающиеся инцидента, при этом не допуская субъективность суждений относительно выявленных фактов и соблюдая конфиденциальность, целостность и доступность собранной информации. Для документирования можно использовать тикетинговую систему, в которую должна вноситься следующая информация об инциденте:
1) Текущий статус инцидента (новый, в работе, отправлен на расследование, закрыт, и т.д.);
2) Описание инцидента;
3) Индикаторы, имеющие отношение к инциденту;
4) Другие инциденты, связанные с текущим инцидентом;
5) Действия с инцидентом, предпринятые всеми членами КРИИБ;
6) Доказательства целостности улик (chain of custody), в случае перспективы судебного разбирательства;
7) Оценка негативного влияния инцидента;
8) Контактные данные вовлеченных и заинтересованных сторон (например, владельцев систем, администраторов);
9) Список улик и свидетельств, собранных в рамках расследования инцидента;
10) Комментарии членов КРИИБ;
11) Список последующих шагов, которые следует предпринять.
3.3. Приоритизация инцидентов.
Обработку инцидентов нужно выстраивать с учетом их критичности ввиду ограниченности ресурсов, оценивая негативное влияние инцидента на бизнес и прогнозируемые затраты на восстановление после инцидента. Следует учитывать такие факторы, как:
1) Функциональное негативное влияние инцидента: оценка влияния киберинцидента на информационные системы, информацию и пользователей, с учетом как непосредственного текущего негативного эффекта, так и долгосрочного влияния в случае неустранения инцидента. Возможные категории для оценки функционального негативного влияния могут зависеть от объема затронутых инцидентом систем и возможностей предоставления услуг пользователям.
2) Информационное негативное влияние инцидента: в результате инцидента ИБ может быть затронута конфиденциальность, целостность, доступность информации, обрабатываемой в организации, причем информация может также принадлежать не самой компании, а ее контрагентам. Возможные категории для оценки информационного негативного влияния могут включать в себя внутреннюю конфиденциальную информацию, персональные данные клиентов и сотрудников, коммерческую тайну, служебную тайну.
3) Возможность восстановления после инцидента: последствия некоторых инцидентов не могут быть легко устранены (например, последствия утечки данных), при этом следует оценивать объем необходимых для полного восстановления ресурсов в каждом случае. Оценка возможности восстановления после инцидента может зависеть от наличия внутренних ресурсов, возможности получить дополнительные внешние ресурсы, предсказуемости времени восстановления, а также от оценки принципиальной возможности восстановления после инцидента (например, в случае публикации внутренней конфиденциальной информации в интернет).
3.4. Уведомление об инциденте.
При анализе и приоритизации инцидента, соответствующая информация должна быть доведена до заинтересованных лиц в соответствии с разработанной политикой реагирования, в которой должно быть указано, какая информация каким образом должна передаваться определенным лицам и с какой частотой — это можно указать в виде матрицы коммуникации. При этом необходимо также предусмотреть возможность эскалации инцидента в случае, если ответственный сотрудник не отвечает на запросы в течение определенного времени — это можно реализовать в матрице эскалации. Следует также продумать способы передачи и обновления информации об инциденте, включая обеспечение защиты каналов связи и их резервирование на случай недоступности или компрометации.
4. Сдерживание
4.1. Выбор стратегии и методов сдерживания.
Выбор стратегии сдерживания (также называемой локализацией) кибератаки чрезвычайно важен для предотвращения распространения киберинцидента в инфраструктуре и для снижения уровня ущерба. Корректно реализованное сдерживание также дает компании больше времени на выработку стратегии дальнейшего реагирования. Для каждого типа инциденте следует разработать свои способы сдерживания с учетом допустимых рисков и возможных затрат. Критериями для определения стратегии сдерживания могут быть:
1) Потенциальный ущерб инфраструктуре и кража активов;
2) Необходимость сохранения юридически значимых доказательств инцидента;
3) Доступность сервисов (сетевая связность, предоставляемые другим лицам услуги);
4) Время и ресурсы на реализацию стратегии сдерживания во время атаки;
5) Эффективность стратегии (частичное или полное сдерживание);
6) Длительность применяемых мер (временные меры или workaround, среднесрочные меры, постоянные меры).
В некоторых случаях компании могут перенаправить атакующих в «песочницы» или в honeypot / honeynet (ловушки-приманки) для контролируемого изучения тактик и техник атакующих. Следует также иметь ввиду, что методы в целом сдерживания следует применять как можно скорее для предотвращения эскалации инцидента и горизонтального передвижения угрозы по сети, при этом некоторые методы сдерживания могут нанести ущерб атакованной системе.
4.2. Сбор доказательств и их хранение.
Для сбора и корректного хранения юридически значимых доказательств следует разработать соответствующие правила и согласовать их с юридической точки зрения. Для всех улик следует сохранять журнал аудита, который включает в себя идентификационную информацию (местоположение, серийный номер, название модели, имя хоста, MAC и IP-адрес устройства); имя, должность, контактные данные сотрудника, который собрал или обрабатывал доказательства во время расследования; время и дата каждого факта обработки доказательств; места хранения улик.
4.3. Выявление атакующих.
В момент кибератаки защитникам лучше сосредоточиться на сдерживании и устранении угрозы и на восстановлении после атаки. При этом однозначно установить подробности об атакующих сущностях часто бывает затруднительно, однако, может быть целесообразным проверить IP-адрес атакующего через публичные сервисы проверки принадлежности IP-адресов и в репутационных базах, обогатить данные по IP-адресу у поставщиков данных киберразведки, провести анализ каналов возможного взаимодействия атакующих и атакованного хоста.
5. Устранение
Этап устранения следует за этапом сдерживания для ликвидации всех компонентов инцидента, например, путем удаления ВПО, отключения скомпрометированных учетных записей, устранения всех использовавшихся в атаке уязвимостей. На этапе устранения важно выявить все элементы инфраструктуры, которые были скомпрометированы, для полного устранения угрозы. При этом в некоторых случаях устранение может быть выполнено на этапе восстановления или не потребоваться вообще. Авторы документа NIST SP 800–61 указывают, что действия по устранению угроз специфичны для каждой компании и инфраструктуры, а поэтому не дают подробных инструкций по реализации данного этапа.
6. Восстановление
На этапе восстановления следует привести инфраструктуру в состояние «до атаки», восстановить нормальные бизнес-операции, проверить работоспособность всех систем, а также устранить уязвимости для предотвращения повторных инцидентов. В рамках восстановления системы могут восстанавливаться из резервных копий (при этом следует проверить, что бекапы были сделаны до начала инцидента), можно заново переустановить ОС и ПО из надежных репозиториев и «золотых образов», обновить программные компоненты, установить обновления безопасности, сменить пароли. Также следует пересмотреть архитектуру и настройки безопасности сетевого оборудования, включить расширенное логирование и мониторинг трафика. Следует учесть, что атакующие часто повторяют атаки на однажды атакованные инфраструктуры, используя те же методы, которые уже приводили их к успеху. Полное восстановление может занять длительное время, поэтому вначале следует сосредоточиться на способах, которые помогут быстро повысить общий уровень защищенности, а затем переходить к более масштабным инфраструктурным изменениям.
7. Пост-инцидентные действия
7.1. Анализ «выученных уроков».
Этап анализа произошедшего инцидента, реализованных контрмер и действий по реагированию как результат разбора инцидента поможет улучшить состояния защиты компании, сделать выводы о необходимости пересмотра текущих сценариев реагирования или политик ИБ в целом, а также позволит членам КРИИБ повышать свою квалификацию. Встречу для разбора закрытого инцидента следует назначать в течение нескольких дней после окончания инцидента, и на ней следует обсудить:
1) Что именно и когда случилось?
2) Как справились с инцидентом члены КРИИБ и иные работники компании? Следовали ли все разработанным процедурам и регламентам? Были ли данные документы адекватны ситуации?
3) Какую информацию требовалось получить как можно быстрее?
4) Были ли осуществлены действия, которые могли помешать восстановлению после инцидента?
5) Что следует делать по-другому членам КРИИБ и руководству в следующий раз при наступлении сходного инцидента?
6) Как можно улучить обмен информацией и взаимодействие?
7) Какие корректирующие действия могут предотвратить аналогичные инциденты в будущем?
8) На какие прекурсоры и индикаторы следует обращать внимание в дальнейшем для недопущения повторения аналогичного инцидента?
9) Какие дополнительные инструменты и ресурсы требуются для выявления, анализа, предотвращения будущих инцидентов?
7.2. Использование данных об инцидентах.
Затраченные ресурсы, типы произошедших инцидентов, недостатки мер и средств защиты должны быть проанализированы для проведения переоценки киберрисков, выделения дополнительных ресурсов, выбора и внедрения дополнительных мер и средств защиты. Данные об инцидентах также могут помочь оценить эффективность работы КРИИБ и выстроенных процессов, для чего можно использовать следующие метрики:
1) Время, затраченное на инциденты: общее время работы членов КРИИБ; время обнаружения и реагирования на инциденты; прошедшее время между всеми этапами реагирования; скорость осуществления эскалации и уведомления ответственных.
2) Объективная оценка инцидента: пересмотр логов, отчетов, заполненных форм на соответствие установленным политикам и процедурам реагирования на инциденты; прекурсоры и индикаторы, которые помогли выявить инцидент; ущерб от инцидента до момента выявления; определение того, была ли выявлена причина инцидента, был ли определен вектор атаки и проэксплуатированные уязвимости, были ли определены характеристики атакованных элементов инфраструктуры; является ли инцидент повторением уже ранее случавшихся инцидентов; предварительная оценка финансового ущерба от инцидента; различие между предварительной и финальной оценкой негативного влияния инцидента; определение мер и способов защиты, которые могли бы предотвратить инцидент.
3) Субъективная оценка инцидента: самооценка членов КРИИБ своих действий, действий коллег и
