10 типичных ошибок при расследовании инцидентов

Ошибка № 1 — Отсутствие плана реагирования

У компании украли деньги. Из средств информационной безопасности у нее только антивирус. Руководство не дает отключить сервер и учетные записи, так как не знает, как это повлияет на бизнес. Мы тратим несколько дней, чтобы выяснить, кто владеет атакованным компьютером и какова его роль в компании, а в это время хакеры могут опустошать банкоматы, выводить деньги или воровать данные. К реагированию на инцидент добавляется масса организационных проблем. Другое дело, когда в компании есть логирование, базовое управление активами и понимание бизнес-процессов. Это позволяет сотрудникам компании обнаружить хакеров в сети на промежуточной стадии атаки, а нам, в случае если инцидент все-таки произошел, сразу взяться за решение проблемы, не тратя драгоценное время. Такой подход значительно повышает эффективность расследования инцидента и дает возможность предотвратить серьезные последствия.

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

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

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

Чтобы не собирать половину компании по каждому обнаруженному вирусу, инциденты надо разделить по уровню опасности и по важности пораженного узла. Допустим, найдено шпионское вредоносное ПО на компьютере бухгалтера, что означает тревогу номер один. Чек-лист проверки должен включать все потенциальные действия, которые злоумышленник может на нем совершить: хищение денежных средств, подмена реквизитов, авторизация в системе ДБО, установка скрытых средств удаленного управления компьютером, копирование пользовательского ключа электронной подписи и т. д. Дальше необходимо провести полноценное расследование и понять, как далеко пробрались хакеры. Это позволит понять, какие контрмеры возможно применить и на каком этапе. Используя пример с бухгалтером, это могут быть: сброс ключей от ДБО, блокировка операций по счету, замена компьютера бухгалтера на заведомо чистый или блокировка сетевых доступов. Таким же образом должен быть составлен план для рабочих станций генерального директора, топ-менеджеров, рядовых сотрудников и для активов других классов.

Эксперты по расследованию, обнаружив систему с подозрительной активностью, нередко тратят от нескольких дней до недели, чтобы выяснить, где физические расположен этот компьютер, кто его владелец и какова его роль в бизнес-процессах, какие есть ограничения по его отключению или сбору данных. Прояснить это заранее — задача команд ИТ и ИБ. Бывает так, что система находится в бухгалтерии, и там просто не отдают рабочую стацию, так как на ней проводится оплата и работа остановится. Для критически важных систем, без которых деятельность компании невозможна, в ИТ-отделе должны быть подготовленные резервные компьютеры. Но обычно их нет, что затягивает расследование. А в это время злоумышленники могут выводить деньги из компании или красть данные.

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

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

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

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

Ошибка № 2 — Недорасследованные инциденты

Компания переустанавливает операционную систему на пораженном компьютере, ставит галочку «инцидент закрыт», а через неделю теряет крупную сумму денег со счета. Такое бывает довольно часто — нельзя ограничиваться полумерами. Необходимо понять, как атакующие проникли в сеть, восстановить хронологию развития инцидента и определить меры по локализации и устранению угрозы. Иначе могут остаться зараженные узлы, через которые атака продолжится.

Ошибка № 3 — Отсутствие инфраструктуры сбора событий

Проникновение в сеть компании могло случиться давно, и следов уже не осталось. Windows, как и любая операционная система, собирает события, но хранит данные локально и ограниченное время, зачастую только до перезарузки ОС. Еще хуже ситуация с сетевыми устройствами, которые обычно обладают небольшим объемом памяти для хранения событий. Это не позволяет узнать, подключался ли три месяца назад какой-то компьютер к вредоносному серверу или нет.

В наших расследованиях инфраструктура сбора событий встречается в одной-двух компаниях из десяти, а SIEM нередко есть только для галочки. Никто внутри таких компаний не проверял, правильно ли SIEM собирает данные и в нужном ли формате. Как интегратор внедрил, так и оставили. Данные могут храниться один день или неделю, и пользы от них нет.

ИТ-команды используют системы сбора логов и мониторинга в рамках своей работы. Такие системы тоже эффективны и их можно использовать в расследовании.

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

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

Без инфраструктуры по сбору событий невозможно достать данные из прошлого. Плюс она экономит время — не надо анализировать десятки, сотни, а иногда и тысячи компьютеров. Но лучше, конечно, задействовать правильно настроенные специализированные решения ИБ. Если есть средства сбора событий, например правильно настроенная система SIEM, то они могут помочь выявить инцидент, восстановить хронологию и найти точки входа злоумышленника. Наличие такой системы позволяет из отдельных микрособытий сложить мозаику.

Ошибка № 4 — Отсутствие информации об активах

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

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

Есть технические решения, которые упрощают работу, но в целом речь о процессах. Компания должна понимать свои бизнес-процессы, а как вести учет всех компьютеров — в Excel либо автоматизировать его с помощью SIEM — вопрос выбора.

Ошибка № 5 — Отсутствие документации

Документация в данном случае — схема нормального процесса взаимодействия между отделами, определяющая, например, должны ли бухгалтеры заходить на компьютеры ИТ-отдела, а Маша и Петя перекидывать документы через личную почту. Важна и техническая документация, описывающая, как взаимодействуют между собой системы. Пример: в документации описано, что один компонент работает только с одним модулем, а на деле он работает с тремя. В противном случае, особенно если айтишник, который все это знал, давно уволился, специалист по расследованию будет бегать за зацепками и подозрительными событиями, не относящимися к инциденту. И эти взаимодействия, которые сложились исторически или эволюционировали, уже выясняются в беседах с сотрудниками — например, у Маши и Пети нет другого инструмента для обмена файлами. Это съедает много времени. Правда, еще хуже, если сотрудников, помогающих понять эти устоявшиеся связи, нет вовсе.

Ошибка № 6 — Порча доказательств

Частая ошибка — пытаться расследовать инцидент, не имея необходимой квалификации. Бывает, что при попытке снятия образов диска неправильно проводят эту операцию и затирают диск с доказательствами. Иногда мы находим ключевой узел, через который развивалась атака, и узнаем, что владельцы переустановили систему, удалив тем самым критически важные для расследования артефакты. В каких-то случаях при снятии дампа памяти нельзя выключать компьютер, иначе информация будет уничтожена. При этом в SIEM не всегда есть все необходимые данные. И раскрутить цепочку дальше, не имея исторических копий, зачастую невозможно. Поэтому должен быть строгий план по корректному обращению с атакованными узлами, самый главный пункт которого — все подобные изменения с начала расследования согласовывать с профильными специалистами. Экспертный центр PT ESC в подобных экстренных ситуациях старается оперативно подключаться к расследованию, зачастую даже до заключения каких-либо официальных договоренностей.

Ошибка № 7 — Провоцирование злоумышленника

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

Ошибка № 8 — Невыученные уроки

Некоторые компании не делают никаких выводов из инцидентов. Периодически бывают случаи, когда мы расследовали атаку, установили хронологию, дали рекомендацию, а заказчик после работы с нами ничего не сделал — не построил процесс мониторинга, не устранил уязвимости. Летом мы помогли удалить последствия взлома, удалить вредоносное ПО, сбросить пароли, провели мероприятия по зачистке сети. А осенью ситуация повторяется снова. И хакеры возвращаются в сеть как к себе домой. Последний раз так дважды взломали одну государственную организацию. Большинство компаний все же внедряют меры защиты после инцидента, пусть и не сразу. Если сеть постоянно атакуют, у подразделения ИБ нет лишнего месяца для устранения критически опасной уязвимости, через которую проникли в первый раз. Повторный инцидент произойдет гораздо раньше.

Ошибка № 9 — Оповещение злоумышленников

Если почтовая система скомпрометирована, а переписку служба ИБ ведет в почте, то хакер может отслеживать все меры противодействия. Он либо заляжет на дно, удалив следы, что затруднит расследование, либо совершит деструктивные действия (см. ошибку № 7), и компании уже будет не до расследования. Именно это и произошло однажды, когда в ходе расследования администратор переписывался с нами через десктопную версию Telegram со скромпрометированного рабочего ПК. Хакеры смогли наблюдать за чатом и действовали на опережение, что усложнило и без того не простое расследование, ровно до тех пор, пока факт компрометации компьютера администратора не обнаружился и мы изменили канал коммуникации.

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

Ошибка № 10 — Зомби-инциденты

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

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

Эльмар Набигаев, заместитель директора экспертного центра Positive Technologies (PT Expert Security Center)