Обзор публикации NIST SP 800-61 "Computer Security Incident Handling Guide". Часть 2

Обзор публикации NIST SP 800-61 "Computer Security Incident Handling Guide". Часть 2


  |  Слушать на Google Podcasts  |   Слушать на Mave  |   Слушать на Яндекс Музыке  |  Слушать на Podcast Addict  |   Слушать на Pocket cast  |  

Руслан Рахметов, Security Vision

В предыдущей части мы описали организационные рекомендации документа NIST SP 800-61 "Computer Security Incident Handling Guide" («Руководство по обработке инцидентов компьютерной безопасности»). В данной части речь пойдет про технические рекомендации по управлению киберинцидентами.

В соответствии с документом 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) Субъективная оценка инцидента: самооценка членов КРИИБ своих действий, действий коллег и работы КРИИБ в целом; оценка владельцем атакованной системы корректности предпринятых КРИИБ мер по реагированию.

Интересные публикации