Как и чем отвечать на атаки: мнение лида группы реагирования01.11.2022 12:16

«Если не можете расшифровать наши данные, то зачем вы здесь?», — примерно так порой реагируют на приезд нашей команды. Сейчас все объясню, а заодно:

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

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

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

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

В общем, восприятие неких событий, как инцидента сильно зависит от контекста, от модели угроз, но мы обычно реагируем по одной и той же схеме. Она основана на стандарте SANS (SysAdmin, Audit, Network, and Security). Так или иначе, его использует большинство безопасников.

SANS выделяет шесть ступеней реагирования на инцидент:

подготовка;
обнаружение;
сдерживание;
удаление;
восстановление;
извлечение уроков

Причем мы, как внешняя команда реагирования включаемся в этот процесс не сразу.

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

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

инвентаризировать сети;
правильно распределять подсети;
ставить правильный софт, антивирусы и другие security controls;
нанимать правильных людей, в конце концов.

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

У каждой атаки свой dwell time — время от попадания злоумышленника в сеть до обнаружения его активности. Если у атаки долгий dwell time (3–4 месяца), а срок хранения журналов 2 дня, то команде расследований будет намного сложнее найти «точку входа». Необходимые данные уже будут недоступны. В такой ситуации мы можем провести реагирование, но вероятность получения 100% результата сильно снижается.

2. Обнаружение

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

Даже базовые шаги значительно повышают вероятность раннего обнаружения угрозы. Если нанять хороший сторонний SOC (он же Security Operations Center), организовать хороший уровень покрытия сети эндпоинтами, выстроить качественный мониторинг, то все может сложиться удачно. Тщательная подготовка позволяет обнаружить атаку на ранних этапах, пока злоумышленник не нанес вреда.

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

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

Этап, который выполняется в тесном взаимодействии команды реагирования и команды заказчика.

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

4. Удаление

Следующий этап реагирования — удаление. Предполагается, что к этому моменту мы предоставили клиенту анализ инцидента и вредоносов, индикаторы компрометации и так далее. Мы тщательно сканируем сеть, а затем вычищаем все аномалии.

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

На этом этапе проводится последовательное и аккуратное восстановление работоспособности IT-систем заказчика. Оно подразумевает не только восстановление машин из бекапов, но и активацию и проверку СЗИ.

Обычно восстановление средств защиты — достаточно простая задача. Дело в том, что злоумышленники, как правило, действуют в обход, получают административные привилегии и при возможности просто отключают СЗИ. Да, хакеры могут использовать софт, который мешает логированию журналов Windows, нарушить взаимодействие с Critical Event Management или как-то уронить эндпоинт, но такие случаи встречаются сравнительно редко.

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

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

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

Ответы на эти вопросы помогают выработать рекомендации, например:

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

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

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

В-третьих, без адекватного реагирования не получится прокачать подготовку и обнаружение, а это фундамент, на котором строится система безопасности компании.

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

«Очевидные» советы важны

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

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

Читайте публичные отчеты

Они подсказывают, какими инструментами и атаками оперируют злоумышленники — так вы будете в курсе событий и сформируете для себя актуальные критерии безопасности. В отчетах часто приводятся конкретные рекомендации, как обезопаситься от той или иной атаки. Условно, вы видите, что происходит, смотрите как защищаетесь, и что надо бы улучшить. Один из лучших источников такой информации MITRE ATT&CK Matrix for Enterprise, только не стоит воспринимать его, как единственно верный. Он не идеален. Когда-нибудь мы найдем время и опишем интересные случаи из практики, ну, а пока есть, например, отчеты Group-IB и лаборатории Касперского.

Не паникуйте и не сносите все до нашего приезда

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

Не выключайте электричество не подумав

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

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

Обращайтесь к специалистам по необходимости

Можно ли в случае атаки обойтись своими силами? Да, если у вас есть собственный SOC с грамотно выстроенными линиями. В таком случае вы, скорее всего, можете провести расследование силами третьей линии SOC-а. В противном случае нужна будет помощь со стороны. Однако, когда речь идет о небольшой компании с ограниченными ресурсами, то, возможно, оно вам и не надо. Это мнение несколько компрометирует безопасников вроде нас, но для малого бизнеса, по крайней мере на российском рынке, есть ненулевая вероятность, что реагирование окажется слишком дорогим и при этом не сильно рентабельным.

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