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

NIST SP 800-83 "Guide to Malware Incident Prevention and Handling for Desktops and Laptops"

Документ NIST SP 800-83 "Guide to Malware Incident Prevention and Handling for Desktops and Laptops", Rev.1 («Руководство по предотвращению и обработке инцидентов заражения ВПО на десктопах и лэптопах», версия 1) дает рекомендации по реагированию на киберинциденты, связанные с вредоносным программным обеспечением (ВПО), включая описание основных тактик защиты от ВПО и фаз реагирования (подготовка, выявление, анализ, сдерживание, устранение, восстановление, анализ причин). Документ был выпущен в 2013 году, поэтому некоторые его детали уже потеряли свою актуальность, но в целом общий подход при реагировании на инциденты заражения ВПО можно применять и сегодня.

В публикации NIST SP 800-83 дается краткое описание классов ВПО, актуальных на момент релиза документа:

· Вирусы, включая подклассы скомпилированных (в виде PE-файлов) и интерпретируемых вирусов (например, в виде вредоносного макроса, powershell/javascript-кода);

· Черви, включая подклассы сетевых и почтовых червей;

· Вирусы-троянцы;

· Вредоносный мобильный код (ВПО на базе Java, ActiveX);

· ВПО смешанного типа.

В качестве типов инструментов атакующих в документе перечислены:

· Бэкдоры (ВПО для удаленного управления зараженным устройством-ботом);

· Кейлоггеры (ВПО для записи нажатий на клавиатуру, создания снимков экрана);

· Руткиты (ВПО для скрытия вредоносной активности, которое запускается до загрузки ОС);

· Вредоносные плагины для браузеров (ВПО для осуществления несанкционированного доступа к данным веб-сайтов, отображающихся в интернет-браузере атакованного устройства);

· Генераторы email (для дальнейшего распространения ВПО или спама как в пределах атакованной сети, так и вовне);

· Тулкиты (наборы хакерских утилит и скриптов).

Авторы документа NIST SP 800-83 справедливо полагают, что для эффективного противостояния столь разнородным видам ВПО следует прежде всего применять превентивные меры для недопущения первичного заражения ВПО. Типы мер для предотвращения заражения ВПО могут быть следующими:

1. Разработка внутренней политики для предотвращения заражения ВПО.

Данный документ должен быть, с одной стороны, достаточно гибким для исключения частого редактирования, с другой стороны, в нем должны быть описаны конкретные шаги и мероприятия, которые реализуются компанией для предотвращения заражения ВПО. В политике должны быть прописаны, например, такие требования:

1.1. Требования по предварительному сканированию съемных накопителей перед их использованием на оборудовании компании;

1.2. Требования по предварительному сканированию email-вложений перед их открытием;

1.3. Запрет на пересылку и получение определенных типов файлов (таких как .exe, .lnk, .bat, .ps1, .vbs, .js, .hta и т.д.; при этом не следует забывать о часто используемой атакующими уловке по пересылке ВПО в запароленном архиве, который не подвергается указанной почтовой фильтрации);

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

1.5. Запрет на использование съемных накопителей на корпоративных устройствах, особенно на серверах, критичных АРМ или устройствах, доступных за пределами контролируемой зоны (например, на терминалах в торговых залах);

1.6. Определение типов средств антивирусной защиты и их политик/настроек, которые обязательно должны быть установлены, обновлены и исправны на определенных типах устройств (например, на АРМ, рядовых серверах, критичных серверах, мобильных устройствах);

1.7. Ограничение или запрет на использование работниками компании личных устройств для удаленного доступа к ресурсам компании.

2. Проведение программ повышения осведомленности.

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

2.1. Запрет на открытие вложений и переход по ссылкам из неожиданных, подозрительных email-сообщений; запрет на посещение веб-сайтов, которые могут содержать ВПО;

2.2. Запрет на переход по ссылкам из всплывающих окон;

2.3. Запрет на открытие подозрительных типов файлов (таких как .exe, .lnk, .bat, .ps1, .vbs, .js, .hta и т.д.);

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

2.5. Запрет на использование учетных записей с административными полномочиями;

2.6. Запрет на скачивание и запуск ПО из недоверенных источников;

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

2.8. Методы выявления фишинговых веб-сайтов, запрет на ввод персональных данных, учётных данных, одноразовых паролей, ПИН-кодов и т.д. на них;

2.9. Методы выявления распространения ВПО даже от известных email-отправителей, необходимость уточнения информации по альтернативным каналам связи;

2.10. Выявление иных методов атак методом социальной инженерии (звонки, сообщения в мессенджерах, СМС и т.д.).

3. Управления уязвимостями.

Поскольку ВПО зачастую использует уязвимости ПО, а скорость обнаружения уязвимостей во многих случаях не позволяет компаниям-разработчикам своевременно выпускать обновления, компаниям следует предусмотреть различные способы обработки уязвимостей, такие как установка обновлений, применение workaround до выхода обновлений, отключение уязвимого функционала, изоляция уязвимых сервисов, виртуальный патчинг. Также следует использовать средства автоматизации для контроля применения рекомендуемых вендором настроек политик безопасности, включая принудительное применение защищенных конфигураций (это может быть реализовано, например, с помощью технологии auto-SGRC). Кроме этого, следует применять следующие практики для снижения вероятности возникновения инцидентов ВПО:

3.1. Применение принципа наименьших полномочий для исключения предоставления пользователям избыточных привилегий, которые могут быть использованы ВПО при атаке;

3.2. Отключение или удаление избыточных, дополнительных сервисов, служб, которые не используются для реализации бизнес-процессов, но могут использоваться ВПО для развития атаки;

3.3. Отключение незащищенных общих файловых папок, которые часто используются ВПО;

3.4. Смена или отключение учетных записей и паролей по умолчанию;

3.5. Отключение автозапуска исполняемых файлов и скриптов;

3.6. Смена файловых ассоциаций для наиболее часто используемых атакующими типов файлов (например, установка notepad.exe как средства запуска по умолчанию для файлов типа .pif, .vbs, .js);

3.7. Предусмотреть возможность автоматизированного изменения настроек ПО на наиболее безопасные в случае появления эксплуатируемой уязвимости или при распространении ВПО по сети.

4. Снижение вероятности успешного заражения ВПО.

Несмотря на усилия по устранению уязвимостей, уменьшению поверхности атаки и обучению пользователей, у создателей ВПО есть шансы на реализацию успешной кибератаки благодаря ошибкам сотрудников, уязвимости контрагентов, отсутствию целостных процессов ИБ. Следовательно, требуется применять средства защиты информации, задача которых - снижение вероятности успешного заражения ВПО. Такими решениями (по состоянию на год публикации документа) были:

4.1. Средства антивирусной защиты, с функционалом сканирования критичных системных компонент хоста, сканирования объектов в режиме реального времени при создании и запуске, контроля поведения прикладного ПО на хосте, сканирования на наличие ВПО и хакерских утилит, помещения подозрительных объектов в карантин или лечения;

4.2. Средства предотвращения вторжений (IPS), работающие на уровне устройства, на уровне сети, а также системы поведенческого анализа трафика;

4.3. Межсетевые экраны (сетевые и хостовые);

4.4. Системы контентной фильтрации и инспекции трафика для выявления и блокирования опасных файлов и содержимого веб-страниц;

4.5. Системы контроля запуска приложений для запрета на запуск несогласованного или непроверенного ПО пользователями и администраторами.

5. Кроме использования средств антивирусной защиты, авторы документа NIST SP 800-83 предлагают организациям также использовать дополнительные меры защиты, такие как:

5.1. Защита BIOS / UEFI для защиты и контроля целостности микропрограмм, которые могут подвергаться целенаправленной модификации при реализации сложных кибератак или атак на цепочки поставок;

5.2. Применение сред изолированного запуска (песочниц) для изоляции подозрительных объектов, изучения поведения подозрительных объектов, быстрого восстановления в исходное безопасное состояние;

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

5.4. Использование средств виртуализации, таких как гостевые ОС и VDI, поможет отделить потенциально рискованные действия с недоверенным контентом (например, интернет-браузинг или работа с email) от конфиденциальной работы (например, интернет-банкинг или администрирование ОС и сетевых устройств).

В следующем разделе авторы NIST SP 800-83 справедливо утверждают, что, несмотря на все предпринимаемые меры, кибератака с использованием ВПО все же может произойти, и в таком случае чрезвычайно важно корректно и оперативно обработать данный инцидент ИБ. Следуя общему фреймворку управления киберинцидентами из публикации NIST SP 800-61, действия при реагировании на инцидент ВПО можно разделить на следующие этапы:

1. Подготовка.

1.1. Развитие навыков и компетенций по анализу ВПО, включая реверс-инжиниринг, выделение сэмплов ВПО, формирование индикаторов компрометации конкретного образца ВПО;

1.2. Обеспечение коммуникации и координации действий путем назначения группы сотрудников для реагирования и оповещения пользователей, предоставления сведений руководителям компании, обработки запросов пользователей;

1.3. Приобретение специализированных инструментов для реагирования на инциденты ВПО (включая тестовые устройства для запуска образцов ВПО, интерактивного анализа запущенного ВПО, форензики зараженного устройства).

2. Детектирование и анализ.

2.1. Определение характеристик инцидента ВПО для приоритизации инцидента путем сбора информации об активности предполагаемого ВПО от средств антивирусной защиты, от IDS, из иных источников (через SIEM) для выяснения типа угрозы (категории ВПО, название сигнатуры), каталога обнаружения подозрительного объекта, типа и имени атакованного устройства. Если известна сигнатура, то на порталах антивирусных лабораторий можно получить подробности о данном типе ВПО (эксплуатируемые уязвимости, используемые протоколы и порты, имена и хэши модулей, методы распространения ВПО, оказываемые негативные воздействия на атакованное устройство).

2.2. Выявление всех зараженных устройств следующими способами:

2.2.1. Форензик-выявление путем поиска признаков и следов вредоносной активности по данным от антивирусов, IDS, SIEM, по данным DNS-запросов, журналов аудита на конечных точках, сетевых снифферов, журналов соединений на сетевых устройствах.

2.2.2. Активная идентификация путем автоматизированного поиска индикаторов компрометации на конечных устройствах, создания уникальных IDS-правил для обнаружения конкретного сэмпла ВПО, применения сетевых снифферов и анализаторов трафика для выявления характерных паттернов сетевого взаимодействия ВПО.

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

2.3. Приоритизация реагирования на инцидент ВПО в зависимости от прогнозируемого ущерба и характеристик ВПО (методы распространения, тип ВПО, какие действия выполняет ВПО, какие устройства и сети могут быть атакованы далее).

2.4. Анализ ВПО, который может проводиться в активном режиме (через запуск в контролируемой среде) или с помощью форензики (анализ состояния устройства после воздействия ВПО).

3. Сдерживание.

При сдерживании ВПО следует остановить распространение ВПО по сети и предотвратить нанесение дальнейшего ущерба уже зараженным устройствам. При сдерживании ВПО, которое не распространяется по сети компании, будет достаточно изолировать атакованные хосты от сети. При угрозе сетевого распространения вируса следует в максимально короткие сроки обеспечить защиту от заражения других устройств в сети, тем самым снизив наносимый вред и уменьшив время восстановления инфраструктуры в нормальное состояние. Следует также иметь ввиду, что некоторые образцы ВПО могут обнаружить меры сдерживания, например, потерю доступа к C&C-серверу атакующих в результате мер сетевой изоляции, и выполнить деструктивные действия на зараженном хосте для сокрытия следов и индикаторов атаки. Кроме того, следует заранее продумать, кто будет обладать полномочиями по выполнению мероприятий сдерживания во время инцидента ВПО, при каких условиях те или иные мероприятия могут производиться, на какой период времени подобные ограничивающие меры могут быть задействованы. Меры сдерживания можно условно разделить на следующие категории (допускается одновременное использование мер из различных категорий):

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

3.2. Сдерживание при помощи автоматизированных средств: антивирусных решений (после отправки в антивирусную лабораторию сэмпла незадетектированного ВПО и обновления базы антивирусных сигнатур), систем контентной фильтрации (они будут эффективны только для статического ВПО и для способов распространения с неизменными атрибутами), сетевых IPS (после написания и включения кастомной сигнатуры для выявления текущего ВПО), блокирования исполняемых файлов (по имени файла, хэшу, подписи издателя или путем блокирования всех недоверенных приложений в целом).

3.3. Сдерживание путем отключения служб или сервисов может нарушить бизнес-процессы, но в случае атаки опасного ВПО может быть действенной мерой: следует рассмотреть возможность полного отключения сервиса (например, email или веб-почты в случае уязвимости на Exchange), отключения части функционала, блокирования портов для определенного типа трафика. Например, при сдерживании атаки вируса WannaCry было целесообразно отключить прослушивание входящих SMB-подключений на сетевом периметре и ограничить SMB-трафик внутри сети.

3.4. Сдерживание при помощи ограничения сетевой связности можно реализовать либо блокированием внешних доменов и IP-адресов атакующих или IP-адреса атакованного хоста в ЛВС, либо с помощью сетевой изоляции (программными средствами или физически отключая Ethernet-кабель или прерывая Wi-Fi-подключение), либо с помощью сетевого оборудования (помещение атакованного хоста в карантинный VLAN, деаутентификация хоста через 802.1X, блокирование беспроводного подключения на Wi-Fi-контроллере, запрет на сетевые подключения между сегментами по определенным портам и протоколам, проведение оценки «здоровья» хоста перед и во время предоставления доступа к корпоративной сети).

4. Устранение.

Меры устранения угрозы тесно связаны с мерами сдерживания и должны включать в себя мероприятия по удалению текущей угрозы и недопущению повторного заражения: запуск антивирусного средства на всех устройствах и удаление ВПО и всех его компонентов, установка обновлений и перенастройка СЗИ, ОС, ПО (в первую очередь на всех атакованных хостах, затем на всех устройствах в сети). В случаях, когда нет уверенности в достаточности выполненных действий, следует переустановить ОС на всех затронутых инцидентом устройствах из "золотого образа" с установкой необходимых патчей, а также восстановить информацию из резервных копий, которые гарантированно не содержат ВПО. Критериями необходимости выполнения переустановки ОС могут быть следующие характеристики инцидента:

· Атакующие получили доступ к устройству с административными полномочиями;

· Несанкционированный доступ административного уровня к устройству был возможен для неустановленного числа лиц (например, через бэкдор);

· Системные файлы были заменены на модифицированные версии;

· Устройство функционирует ненормально после проведения действий по восстановлению;

· Есть сомнения относительно типа / масштаба заражения и возможного несанкционированного доступа.

5. Восстановление.

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

6. Пост-инцидентные действия.

После завершения действий по обработке инцидента ВПО ключевым членам команды реагирования и руководителям следует провести встречу для обсуждения выполненных действий, анализа принятых мер, выработки списка «выученных уроков». В результате обсуждения могут быть выработаны следующие рекомендации:

6.1. Внесение изменений, актуализация политик ИБ в компании для устранения организационных и логических уязвимостей в процессах кибербезопасности (например, внесение запрета на использование личных съемных накопителей, ограничение полномочий, перестройка бизнес-процессов);

6.2. Внесение изменений в программы повышения осведомленности работников для повышения бдительности и выполнения корректных действий при наступлении инцидента;

6.3. Перенастройка ОС и ПО для соответствия актуализированным политикам ИБ;

6.4. Перенастройка средств антивирусной защиты, включая повышение частоты получения обновлений сигнатур, повышение точности детектирования угроз и снижение ложноположительных срабатываний, увеличение границ мониторинга угроз в инфраструктуре (сегменты сети, типы устройств, типы контролируемых объектов), изменение действий по умолчанию при обнаружении ВПО, повышение эффективности доставки обновлений до всех устройств;

6.5. Закупка и развертывание новых типов средств защиты информации, которые защищают от актуальных киберугроз и снижают киберриски инцидентов ВПО.