Расследование инцидентов — это критически важный подпроцесс управления инцидентами информационной безопасности, направленный на выявление первичного вектора компрометации, минимизацию ущерба и предотвращение подобных инцидентов в будущем. Эффективность расследования зависит от трех ключевых факторов: компетентности команды реагирования, наличия инструментов для анализа и сбора данных, а также согласованности процессов информационной безопасности организации-заказчика в целом.
Последний фактор оказывает существенное влияние на ход расследования, включая точность, полноту и достоверность итоговых результатов расследования. В частности, отсутствие налаженных ИБ-процессов может привести к изменению ключевых артефактов, затруднить идентификацию источника проникновения и снизить вероятность обнаружения новых индикаторов компрометации (IOCs).
На протяжении множества расследований команда Solar 4RAYS сталкивалась с такими «препятствиями». Проанализировав их, мы решили описать проблемы, возникающие в том или ином ИБ-процессе, которые негативно влияют на расследование инцидента.
Когда возникают проблемы
Классические модели расследования делят процесс реагирования на шесть стадий: подготовку, обнаружение, сдерживание, ликвидацию, восстановление и извлечение уроков.
В реальности взаимодействие между этапами может быть не линейным, поэтому в рамках данной статьи мы рассмотрим проблемы на трех условных этапах расследования:
До расследования инцидента.
В процессе расследования.
После расследования.
До расследования инцидента
Да, мы приняли риски
В каждой организации есть циклический процесс, известный как управление рисками информационной безопасности. Он направлен на идентификацию, оценку, приоритизацию и снижение рисков, связанных с потенциальными инцидентами. Для данного процесса существует несколько стратегий управления, одной из которых является «Принятие риска».
«Принятие риска» — это стратегия, подразумевающая осознанное игнорирование мер по снижению вероятности срабатывания риска или устранению угрозы. Такой подход может быть обусловлен экономическими факторами, то есть его могут применить, если ожидаемый ущерб от реализации угрозы ниже затрат на ее предотвращение. Однако в рамках рисков ИБ мы видим искажение этой стратегии. Часто она сопровождается мысленным консенсусом: «Зачем вообще тратить деньги на то, что может не произойти?»
Такой подход неизбежно приводит к ситуации, в которой «принятый» риск срабатывает, случается инцидент, и организация оказывается к нему полностью не готова. Последствия такой неготовности, особенно в современных реалиях ландшафта киберугроз, ведут к неизбежным экономическим и репутационным издержкам. При этом издержки в большинстве случаев превышают любые ожидания организации.
На практике это проявляется в виде игнорирования достоверных предупреждений. Мы в Solar 4RAYS отслеживаем активность известных нам группировок и, когда видим признаки атаки, предупреждаем атакованную организацию о компрометации ее инфраструктуры. Однако эти оповещения чаще всего остаются без ответа. Иногда в ответ просят предоставить индикаторы компрометации, но никакого дополнительного расследования не проводится. Нередко такое бездействие приводило к развитию инцидента и его публичной огласке.
При этом стратегия «Принятия» не является ошибкой сама по себе. Однако ее применение должно быть осознанным решением, основанным на честном анализе возможного ущерба в случае инцидента. А не только предположении, что инцидент может и не случиться. Практика наших расследований показывает, что целью атаки профессиональной группировки может стать буквально любая организация.
Что? Где? Когда?
Команда Solar 4RAYS сталкивалась с ситуациями, когда при инциденте заказчик не знал точно, из чего состоит его собственная инфраструктура. Такое чаще всего происходит из-за неналаженного процесса управления активами и инвентаризации. Аналогичные проблемы возникают и с контролем доступов и администрированием учетных записей. В результате происходит ситуация, при которой жертва вместе с командой расследования проводит инвентаризацию на ходу, по сути занимаясь live-аудитом, с особенностью в виде частично отключенной инфраструктуры.
Недостаток информации о сегментах инфраструктуры оказывает негативное влияние на процесс расследования. В частности:
Создает необходимость проведения live-аудита. В отсутствие актуальной информации об инфраструктуре IR-команде, вместо самого расследования, приходится выявлять веб-сервера, доменные контроллеры, учетные записи с привилегиями и т. д. На это уходит время, которого у расследователей может и не быть. Например, в случае, когда атакующие все еще сохраняют присутствие в инфраструктуре и могут нанести ущерб.
Приводит к отсутствию согласованности в изоляции. Команда реагирования может столкнуться с ситуацией, когда «изолировано» не то, что нужно, из-за слабой информированности об инфраструктуре.
Как бы очевидно это ни звучало, единственным способом знать, из чего состоит ваша инфраструктура, является налаженный процесс управления активами и инвентаризацией. Это хорошая практика и вне контекста расследования киберинцидентов, но в случае кибератаки она серьезно повышает эффективность и скорость деятельности расследователей.
Крайне важно, чтобы в условиях инцидента не оказывалось так, что атакующий лучше знает вашу инфраструктуру, чем вы сами.
Пример из реального кейса
Атакующие обнаружили в инфраструктуре жертвы устаревший доменный контроллер, который, хотя и был выведен из эксплуатации, сохранял связь с другими компонентами сети. При первичном подключении злоумышленники разместили в системе 3proxy, что позволяло им туннелировать трафик. Далее атакующие загрузили ProcDump для дампа процессов памяти — в частности, lsass.exe.
В дальнейшем атакующие применяли контроллер домена в качестве промежуточного узла для горизонтального перемещения по всей инфраструктуре. Для заказчика такая «находка» стала неожиданностью.
Если я не вижу — значит, этого нет?
Сетевая инфраструктура любой организации — это сложная и динамическая система, требующая постоянного внимания как с технической точки зрения, так и с точки зрения безопасности. В связи с постоянным ростом числа атак невозможно сохранить защищенность инфраструктуры без налаженного процесса мониторинга.
Суть процесса мониторинга заключается не в простом сборе данных, а в их постоянном анализе с применением дополнительных инструментов. Цель всего процесса — выявление аномалий, указывающих на потенциальную вредоносную активность до реального ущерба. Результатом анализа становится уведомление о подозрительном событии, которое, в свою очередь, оценивается непосредственно получателем уведомления (заказчиком).
К сожалению, в таком процессе есть серьезные риски. Даже при наличии достоверных оповещений получатель уведомления может их проигнорировать, неправильно оценить или неправильно интерпретировать (фолз-позитив). В результате — катастрофические последствия в виде шифрования или утечки данных.
Фактически игнорирование оповещения или ложная его оценка из-за халатности или недостаточной осведомленности не только не защищает организацию, но и создает ложное впечатление безопасности. Формируется мнение: «Какие-то события идут, процесс налажен, а это значит, что я в безопасности и ничего делать не нужно».
Другим риском выступает неполное покрытие средствами мониторинга ключевых сегментов инфраструктуры, что создает для службы мониторинга слепые зоны.
Последствия вышеописанных рисков влияют на процесс расследования, а именно:
Значительная задержка между оповещением и реагированием может привести к утрате критических артефактов: журналов событий, следов активности, временных файлов.
Присутствие слепых зон может замедлить определение зараженных систем и мониторинг IOCs.
В случае разрушения инфраструктуры (например, в результате шифрования), расследование начинает зависеть от наличия бэкапов и журналов мониторинга. Отсутствие мониторинга (и, как следствие, его журналов) может негативно сказаться на результативности расследования.
Единственным способом устранения таких рисков является ответственный подход к мониторингу. Важно эскалировать явно вредоносную активность до ответственного лица, даже если последнее ранее утверждало, что активность «легитимна». Если событие окажется ложноположительным, последствия такой эскалации минимальны, в то время как игнорирование реальной угрозы может обернуться огромными потерями средств и времени.
В свою очередь, лицо, получившее уведомление, обязано обладать насмотренностью. Для этого важно, чтобы оно регулярно ознакамливалось со свежими отчетами о деятельности хакерских группировок, представляло, как выглядит применение тех или иных тактик и техник атакующих.
Важным является покрытие мониторингом ключевых для организации сегментов инфраструктуры, а именно: серверного сегмента, с веб-серверами, базами данных и т. д., демилитаризованной зоны (DMZ), которая связывает внутренний сегмент сети со внешней, и других. Наличие серых зон может позволить атакующим прятаться в них.
Аналогичная логика применима и к другим средствам защиты: WAF, EDR, АВПО. Игнорирование их оповещений также является ошибкой.
Увидел, испугался, удалил
Представьте, что сотрудник организации обнаружил аномальную активность в своей системе. Например, необычный каталог на рабочем столе, отсутствовавший ранее, или исполняемый файл с подозрительным именем или расположением. При быстрой оценке подобной активности пользователь понимает, что это ВПО, и просто удаляет подозрительный объект, полагая, что тем самым он предотвратил инцидент. В лучшем случае после этого он запустит проверку с помощью АВПО. Однако, как показывает практика, такие действия не предотвращают инцидент, а могут только отсрочить его.
Такой подход мы назвали «Увидел, испугался, удалил». По своей сути он является ошибочным не столько в самой процедуре удаления, а в отсутствии системного подхода к реагированию на подобные события. При этом наибольшую опасность вызывает не попытка самостоятельно решить инцидент, а отсутствие эскалации обнаружения до профильного специалиста.
Для группы расследования данный подход несет следующие риски:
При удалении подозрительного файла может быть безвозвратно утрачен образец вредоносного ПО и/или новый С2 атакующих. При этом восстановить файл в связи с разными обстоятельствами зачастую бывает невозможно.
С момента «Увидел, испугался, удалил» и до момента «Вызывайте команду реагирования» может пройти достаточно времени для ротации различных артефактов. Все это негативно сказывается на оперативности и точности анализа произошедших в системе событий.
Пользователь может забыть или намеренно скрыть (например, из опасений получить дисциплинарное взыскание), что в системе происходило что-то подозрительное, и при расследовании не сообщит про «интересные находки».
Решение данной проблемы требует комплексного подхода, состоящего из двух частей. Во-первых, внедрение обязательного мониторинга позволит избежать игнорирования инцидента или несохранения факта события. Во-вторых, обучение сотрудников хотя бы азам информационной безопасности позволяет внедрить осмысленный подход к обнаружению угрозы.
Идеальным сценарием поведения сотрудника в вышеописанных случаях могут быть следующие действия:
Самым важным является эскалация произошедшего до профильного специалиста. Скрытие произошедшего может привести к катастрофическим последствиям.
После эскалации не нужно предпринимать самостоятельных действий. Они могут помешать установлению причины инцидента.
Другими словами, «Увидел, испугался, удалил» должно превратиться в «Увидел, сообщил в ИБ, выполнил инструкции от специалистов».
Отдельно стоит упомянуть сценарий, при котором организация выбирает самостоятельное реагирование. При нем необходимо подробно фиксировать обнаруженные артефакты вредоносной активности. В будущем, при расследовании новых инцидентов, база «исторических» знаний поможет либо проследить развитие старого инцидента и понять, где принятые защитные меры дали сбой, либо установить, что активности никак не связаны, и не тратить время на тупиковую ветвь расследования.
Подробный отчет о самостоятельном реагировании поможет не только вам, но и сторонней команде реагирования, если возникнет необходимость в ее привлечении.
Случаи, когда заказчик или его сотрудник удаляли следы заражения по принципу «Увидел, испугался, удалил», в практике команды Solar 4RAYS встречаются достаточно часто. В типичном случае администратор или любой другой сотрудник видят оповещение от АВПО, указывающее на факт заражения. Действуя по вышеописанному сценарию, они не сохраняют какие-либо данные о событии и окружении события. Удаление одного образца ВПО, как правило, никак не ограничивает возможности атакующих, и более серьезный инцидент, частью которого было удаленное сотрудником ВПО, рано или поздно происходит.
Руководители организации задаются вопросом: «А как система была заражена?» — и решают провести анализ системы. Как итог самодеятельности, часть данных оказывается уничтожена силами сотрудников организации, и специалисту по расследованию инцидентов остается только выдвигать гипотезы, на основании разрозненных фактов, о том, как злоумышленники проникли в сеть.
Отдельно отметим случаи, когда в инцидентах APT-группировки применяют вредоносное ПО, которое существует только в оперативной памяти системы. А заказчик, после информирования, что системы заражены, попросту выполняет экстренное выключение всей инфраструктуры. Как итог, после включения системы уже очищены от вредоносного ПО и анализировать попросту нечего. Но это отнюдь не означает, что у группировки не сохранился доступ в инфраструктуру.
В процессе расследования
Управление инцидентом
Иногда на начальных этапах расследований наша команда сталкивалась с проблемой неготовности заказчика к реагированию на инцидент. Мы не раз становились свидетелями, когда заказчик разрывался на части, пытаясь одновременно найти ответственного за инфраструктуру, начать помогать нам в расследовании и приступить к восстановлению инфраструктуры.
Согласованность действий при инциденте — довольно редкое явление, и наблюдается оно только в тех организациях, где есть заранее разработанный план реагирования.
Разработка такого плана — не просто формальное соблюдение требований. Это практический пошаговый сценарий взаимодействия между ключевыми участниками процесса (от технических специалистов до руководства), который очень пригодится в ситуации, когда кажется, что все пропало. Основой такого плана выступает политика управления инцидентами ИБ, которая определяет ответственность, порядок уведомления, классификацию инцидентов и прочие действия.
При этом отдельно необходимо проработать план взаимодействия с внешними командами расследования. Такие команды могут давать рекомендации по тем или иным действиям с вашей инфраструктурой, чтобы помочь в ее восстановлении и сохранении значимых артефактов для расследования. Отсутствие плана взаимодействия неизбежно приводит к проблемам в процессе расследования.
Как раз приведем характерный пример:
В ходе расследования инцидента был обнаружен след, ведущий к скомпрометированной системе. Но на запрошенные данные заказчик отправляет чистый триаж/образ с только что переустановленной системы. Мы запросили еще системы, и пришли точно такие же. Выяснилось, что заказчик уже частично восстановил системы с золотого образа, даже не подумав предупредить нас о своем намерении.
В однопоточном режиме
Обычно со стороны заказчика для коммуникаций с командой реагирования выделяется очень небольшой коллектив. Зачастую непосредственным исполнителем оперативных указаний команды расследования становится всего один сотрудник — системный администратор. Он имеет все необходимые права для сбора данных, а также обладает более детальной информацией об инфраструктуре «на месте».
Это порождает некоторые проблемы. В большинстве организаций количество администраторов ограничено. Их основная обязанность после инцидента — заниматься восстановлением инфраструктуры, обновлением доступов, изменением конфигураций, и они не всегда могут эффективно распределять время между сбором данных для экспертов по реагированию и своими прямыми обязанностями.
Чтобы не перегрузить сотрудника, лучшей практикой будет выделять ему небольшой промежуток времени на решение задач от команды расследования. Многие ставящиеся задачи зачастую связаны со сбором данных, то есть запуском утилит или выполнением конкретных команд. После чего сотрудник может быть свободен до завершения сбора данных.
В свою очередь, команда расследования обязана ставить конкретные задачи и при этом объяснять, как выполнить то или иное действие, чтобы облегчить работу администратору.
Все хранится за семью замками!
Наша команда встречалась со случаями, когда предоставление данных на исследование осложнялось страхом заказчика за возможную их утрату или утечку. Иногда встречались попытки удалить некоторые артефакты из собранных данных. Однако, на наш взгляд, такие опасения избыточны. Более того, попытка удалить какие-либо собранные данные может повлиять на результаты расследования.
Прежде всего, услуга расследования и реагирования на инцидент подразумевает, что стороны подписывают договор о неразглашении (NDA), в котором оговариваются все необходимые обязанности и условия. Более того, в договоре о неразглашении указываются сроки хранения данных об инциденте.
С технической точки зрения, команда Solar 4RAYS хранит все переданные заказчиком данные исключительно в защищенных хранилищах с многоуровневой системой контроля доступа, основанной на принципе минимальных привилегий. Доступ к данным специалисту предоставляется на ограниченное время, а все действия с файлами сохраняются в журнале аудита.
Как итог, передача и обработка данных в рамках расследования полностью безопасны. А «сомнения» заказчика могут негативно отразиться на процессе расследования.
После расследования инцидента
Кому нужны эти ваши рекомендации…
Рекомендации являются квинтэссенцией результатов расследования инцидента. Они систематизируют конкретные обоснованные действия, необходимые для устранения последствий компрометации, восстановления целостности инфраструктуры и снижения риска повторного заражения. В их состав входят не только технические указания, но и организационные рекомендации для укрепления общей защищенности. Отдельное внимание уделяется индикаторам компрометации, которые необходимо отслеживать и после инцидента.
Практика показывает, что иногда рекомендациям не уделяется должное внимание, либо они вовсе игнорируются. Такие «упущения» не просто снижают эффективность расследования, они прямо способствуют повторной компрометации.
И, как бы это очевидно ни звучало, самым эффективным способом предотвращения повторных инцидентов является строгое выполнение рекомендаций. Они не являются формальностью. Каждое из указанных в рекомендациях действий обусловлено анализом угроз, действиями атакующих и итогами расследования. Каждый шаг представляет собой часть последовательной цепочки, нарушение которой может оставить систему уязвимой к аналогичным или схожим атакам.
Приведем пример из практики расследования инцидентов:
Заказчик попросил провести ограниченное по количеству систем расследование инцидента. В процессе были обнаружены множественные следы активности APT-группировки.
В результате мы дали ряд рекомендаций: что сделать с инфраструктурой, какие индикаторы компрометации отслеживать и как. Однако относительно скоро к нам пришел тот же заказчик — в ходе мониторинга его специалисты обнаружили обращения к C2 атакующих, указанным в нашем отчете.
Выяснилось, что рекомендации были выполнены лишь спустя полгода после расследования. За это время атакующие продолжили заражение разветвленной инфраструктуры и начали использовать новый С2.
Выводы
Вышеперечисленные проблемы по отдельности не всегда препятствуют расследованию, но в совокупности способны помешать ему или исказить итоговые результаты.
В современных условиях высокого уровня киберугроз системный подход к процессам информационной безопасности является не рекомендацией, а суровой необходимостью.
Каждая организация, независимо от масштаба и отрасли, обязана иметь четкий план действий на случай инцидента информационной безопасности. Помимо плана, должны быть налажены процессы управления активами, обучения сотрудников азам информационной безопасности, мониторинга.
Особое внимание следует уделить принципу сохранения цифровых следов, связанных с инцидентом. Следы, оставленные атакующими, являются ключевыми доказательствами вредоносной активности. Их изменение или утрата могут затруднить процесс исследования и препятствовать точности результатов.
Все это существенно снизит риск инцидента, а в случае его происшествия выстроенные процессы помогут в кратчайшее время провести качественное расследование.
Другие статьи о расследовании и реагировании на кибератаки, а также исследования киберугроз (включающие индикаторы компрометации) вы найдете в нашем блоге.
Команда центра исследования киберугроз Solar 4RAYS