Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №5 «Приоритизируйте реагирование на киберинциденты»

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

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

1. Выбор фреймворков и методологий.

Для подготовки плана реагирования на киберинциденты авторы рекомендуют руководствоваться следующими фреймворками:

- Специальная публикация NIST SP 800-61 "Computer Security Incident Handling Guide" («Руководство по обработке инцидентов компьютерной безопасности»);

- Специальная публикация NIST SP 800-184 "Guide for Cybersecurity Event Recovery" («Руководство по восстановлению после киберинцидентов»);

- Классификация ENISA (Агентство ЕС по кибербезопасности) "Reference Incident Classification Taxonomy" («Справочная классификация инцидентов»);

- Классификация типов киберинцидентов Open Source платформы MISP;

- Концепция OODA ("Observe, Orient, Decide, Act", т.е. «Наблюдайте, ориентируйтесь, принимайте решение, действуйте»).

В целом, подход к управлению киберинцидентами, на который ориентируются авторы публикации MITRE, заключается в цикле «Подготовка, планирование - Выявление, анализ - Сдерживание, устранение, восстановление - Пост-инцидентные действия». В соответствии с этим циклом и строится описание рекомендаций в Стратегии №5.

2. Планирование.

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

Для подготовки к большинству инцидентов SOC-центру потребуются:

- Сотрудники с сильными техническими, аналитическими, коммуникативными навыками;

- Документальное обеспечение: стандартизированные операционные процедуры (SOP, standard operating procedure), концепция операционных процедур (CONOPS, Concept of Operations) SOC-центра (т.е. описание того, как работает SOC-центр, какими полномочиями обладает и какую ответственность несет персонал SOC, описание ролевой модели, функций, возможностей, требований SOC-центра), а также описание процедур эскалации;

- Средства координации действий по анализу и реагированию членов команды SOC;

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

- Инструменты для сбора и анализа артефактов для выявления фактов, относящихся к киберинцидентам;

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

В план реагирования могут быть включены такие документы, как:

- Описание ролей и ответственных членов команды реагирования, с указанием зон ответственности, включая контакты аутсорсеров;

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

- Справочная документация, руководства, описание выполняемых процедур, таких как SOP, руководства по формированию отчетности, применимые политики;

- Описание инструментов, технологий и физических ресурсов, используемых SOC, с описанием способа получения доступа к ним;

- Перечень критичных процессов восстановления сетей и данных, включая подробные инструкции по восстановлению;

- Ссылка на Устав SOC и иные документы, которые закрепляют за SOC определенные полномочия, использующиеся при реагировании.

Перед приоритизацией типов инцидентов следует сначала составить весь перечень ожидаемых и моделируемых кибератак, включая как самые частые и известные типы, так и происходящие редко, но опасные. В отечественных реалиях перечень типов инцидентов можно составить на основе актуализированной модели угроз, а также можно руководствоваться методическими рекомендациями, в частности, из БДУ ФСТЭК России. Кроме того, авторы публикации рекомендуют использовать данные из матрицы MITRE ATT&CK при формировании списка инцидентов, с указанием приоритета для каждого типа киберинцидента/нежелательного (недопустимого) события ИБ, а также с кратким описанием способов реагирования. При этом, разумеется, для каждой организации и инфраструктуры подобный перечень будет уникальным, как и приоритет и способ реагирования.

Способы и шаги по реагированию для релевантных типов инцидентов подробно описываются в руководствах по обработке инцидентов - плейбуках (playbooks) или сценариях реагирования, которые требуются для упорядочивания реагирования и повторяемости, шаблонизируемости действий членов команды SOC-центра. Это также важно и для новых сотрудников, которым будет проще войти в должность, и для опытных сотрудников, которым не придется каждый раз «изобретать велосипед» при реагировании, а можно будет уделить внимание новым особенностям и деталям инцидента. Грамотно составленные описания последовательности выполняемых при реагировании действий (сценариев реагирования) также являются ключевым фактором успеха при автоматизации действий по реагированию.

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

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

3. Выявление и анализ.

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

3.1. Триаж инцидентов.

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

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

- Категорировать инциденты можно в зависимости от векторов атаки и влияния на активы компании, но при использовании при атаке различных тактик и техник категории может возникнуть путаница.

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

- Можно выбирать категории инцидентов в зависимости от организационных подразделений, которые будут участвовать в реагировании (например, при фишинге это будут администраторы email-сервиса, а при атаке на веб-сайт - администраторы веб-приложений).

- Следует определить типы категорий инцидентов до момента наступления инцидента для упрощения планирования, при этом всегда можно будет добавить новые типы в дальнейшем.

- Следует разработать руководства по триажу инцидентов для оперативности и во избежание образования очереди входящих инцидентов, которые медленно обрабатываются сотрудниками SOC.

3.2. Анализ инцидентов.

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

- Проверяйте предположения и гипотезы, основываясь на фактах, а не на домыслах.

- Ищите свидетельства и данные, которые дополнят картину произошедшего, даже если они находятся вне «поля зрения» SOC.

- Анализируйте индикаторы компрометации (хэши, IP/URL-адреса, дампы трафика и т.д.) для получения полной картины использовавшихся атакующими TTPs.

- Создавайте временной график (timeline) релевантных событий для понимания действий атакующих и этапов атаки.

- Используйте сравнение известных и неизвестных программных компонентов, например, путем использования списка «известных хороших» хэшей системных файлов или сертификатов доверенных издателей для сравнения с данными подозрительных файлов.

- Не опирайтесь только на индикаторы компрометации, поскольку атакующие легко могут изменить хэши, IP/URL-адреса и т.д., следовательно, рекомендуется строить TTPs-модели атакующих и использовать индикаторы атак для более точного анализа поведения злоумышленников и их конечных целей.

- Анализ сценариев и гипотез атак на основе уже имеющихся фактов помогает выстроить предположения о дальнейших действиях атакующих и проводить поиск дополнительной информации об атаке.

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

3.3. Расследование.

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

Авторы публикации рекомендуют анализировать следующие артефакты:

- Файловая система и файлы, с поиском неизвестных каталогов, файлов, объектов;

- Запущенные процессы, с анализов неизвестных процессов и поиском аномалий в поведении известных процессов;

- Скрипты, исполняемые файлы;

- Хэши системных файлов, не соответствующие «известным хорошим» хэшам, а также данные о цифровой подписи файлов, не соответствующие известным доверенным издателям;

- Системные журналы аудита, с поиском активности неизвестных учетных записей, изменений привилегий, фактов создания новых доверенных хостов, существенных изменений файлов;

- Сетевая активность, включая VPN-подключения, удаленные подключения, создание туннелей, использование RDP и SSH, которые могут использоваться для создания атакующими несанкционированного канала передачи данных и команд.

При анализе и расследовании инцидентов члены команды SOC часто сталкиваются с большим количеством ложноположительных срабатываний, которые превышают по численности истинноположительные («боевые») срабатывания в большинстве систем обнаружения кибератак, поэтому важно непрерывно проводить донастройку (тюнинг) СЗИ, обогащать контекст событий, использовать средства автоматизации. Зачастую в SOC применяется также такая категория сработки, как «не угроза» или «доброкачественное» срабатывание (англ. benign positive) - в этом случае средство обнаружения верно зафиксировало истинноположительное событие, которое после проверки оказалось не вредоносным; такое может встречаться при обнаружении активности санкционированных пен-тестов или при объективно подозрительном поведении пользователей или устройств, которое после проверки оказалось легитимной активностью.

Авторы публикации также дают членам команд SOC-центров свои рекомендации по эффективному и результативному анализу аномалий и косвенных признаков сложных кибератак:

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

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

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

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

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

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

- Отличайте факты от предположений: следует заранее внедрить техники для анализа и проверки доказательств, корреляций и причинно-следственных связей.

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

4. Сдерживание, устранение, восстановление.

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

Авторы публикации дают ряд рекомендаций для проведения корректного сдерживания, устранения, восстановления:

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

- Постройте структуру управления: следует заранее разработать систему подчиненности, определить границы зон ответственности, выстроить взаимодействие внутри команды SOC, а также назначать ответственного за каждый киберинцидент.

- Не станьте жертвой «тумана кибервойны»: при реагировании (особенно на сложные, многовекторные кибератаки) убедитесь, что собраны точные и полные детали киберинцидента, т.к. без этого невозможно полностью устранить последствия атаки и не допустить ее повторения.

- Готовьтесь давать ответы на вопросы типа «И что?»: при донесении информации о киберинциденте топ-менеджменту и собственникам компании важно не вдаваться в технические термины, а объяснять ситуацию с точки зрения бизнеса, достижения целей компании, финансовых затрат; следует приготовиться к ответам на вопросы о том, что было атаковано, была ли атака успешной, кто стоит за ней и какова их мотивация, как продолжать бизнес-процессы.

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

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

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

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

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

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

Пост-инцидентный обзор (review) закрытого инцидента, по мнению авторов публикации, должен включать в себя обсуждение следующих вопросов:

- Какие меры и действия помогли при реагировании?

- Какие меры и действия не помогли при реагировании?

- Что замедляло реагирование?

- Была ли путаница? Когда и где, как ее избежать в дальнейшем?

- Был ли у ответственных лиц доступ к необходимой информации?

- Были ли выявлены отсутствующие, но требовавшиеся инструменты, были ли инструменты недоступны, были ли имеющиеся инструменты бесполезны?

- Каких инструментов или данных было недостаточно для успешного реагирования?

- Кто должен был быть вовлечен в реагирование на инцидент (но не был)?

- Какие навыки были нужны, а какие реально использовались?

- Хорошо ли отработали оповещение и отчетность?

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