Подписаться
Читать в телеграм
Сегодня такие инциденты происходят регулярно, что заставляет бизнес искать новые способы защиты своих информационных активов.
Кто-то сосредоточивается на обнаружении инцидентов, создавая собственный SOC или обращаясь за подобными услугами к партнерам. Это правильное решение, таким образом можно получить достаточно полную картину того, что происходит с сетью и ее информационными активами. Но полномочия SOC заканчиваются ровно в момент обнаружения инцидента. Как правило, дальнейшие шаги — сдерживание, устранение, расследование причин и принятие мер для предотвращения повторения инцидента в будущем — возлагаются на другие службы.
Одной из таких аутсорсинговых служб является команда реагирования на инциденты ИБ, работающая в Jet CSIRT. В наши задачи входит Incident Response (IR) — процесс обработки инцидента ИБ в течение всего жизненного цикла (от детектирования до восстановления пораженных активов и принятия превентивных мер).
Ниже я поделюсь опытом, накопленным за время работы аналитиком в команде мониторинга и реагирования на инциденты ИБ Jet CSIRT.
Я представлю свое видение грамотной организации реагирования на инциденты ИБ, расскажу о задачах направления, процессах, необходимых для полноценного функционирования Incident Response, инструментах, которыми нужно пользоваться в рамках IR, приведу реальные примеры и лучшие практики, ставшие для нас ориентиром при создании CSIRT.
Краткая история вопроса
Термин «реагирование на инциденты ИБ» уходит корнями в 1988 г., когда Роберт Тэппэн Моррис, на тот момент 22-летний аспирант одного из вузов США, в ходе неудачного эксперимента запустил в сеть (тогда еще ARPANET) первого сетевого червя. Ущерб был настолько разрушительным, что парализовал работу около 6 тысяч узлов и фактически сделал использование сети невозможным.
В ответ на этот инцидент в Университете Карнеги — Меллона экстренно создали экспертную группу из ИБ-специалистов «Компьютерная команда реагирования на чрезвычайные ситуации» (Computer Emergency Response Team — CERT). Она должна была остановить действие вредоносного ПО.
В дальнейшем аналогичные экспертные команды CERT начали появляться по всему миру. Такие группы существуют и сегодня, однако со временем они стали фокусироваться на аналитике угроз на глобальном и региональном уровнях, как правило, в рамках отдельно взятой страны.
Тенденцию подхватили коммерческие организации, создавшие схожие группы реагирования на инциденты ИБ — Computer Security Incident Response Team (CSIRT). Эти команды должны были следить за безопасностью в рамках отдельной компании.
По опыту, для организации грамотного реагирования недостаточно просто выделить в ИТ-департаменте группу сотрудников, знающих принципы работы межсетевого экрана, назвать их CSIRT и надеяться, что отныне угрозы ИБ компании не страшны. Необходимо сформировать для группы задачи, наделить ее определенными полномочиями, обеспечить нужными инструментами и ресурсами, составить план и выстроить процессы реагирования на инциденты ИБ.
Отрицание, гнев, торг, принятие
В условиях повсеместной цифровизации, распространения IoT и BYOD можно защититься от кибератак, разве что отключив интернет, но даже в этом случае вы не будете защищены на 100%. Это значит, что жертвой киберпреступления может стать любая организация. Поэтому первым шагом на пути к защите должно стать принятие того факта, что рано или поздно вашу компанию могут взломать. Возможно, это происходит прямо сейчас, пока вы читаете эту статью. Не исключено, что в вашей сети есть критические незакрытые уязвимости, которые может проэксплуатировать злоумышленник.
Либо же в эту самую минуту ваш сотрудник открывает письмо с вредоносным вложением или вставляет в компьютер найденную в офисе USB-флешку и запускает в сеть очередной вирус-шифровальщик. Гораздо хуже, если в компании действует инсайдер, который планирует продать ваши секретные данные мошенникам.
И наконец, прямо сейчас у стен вашего офиса может быть припаркован автомобиль со шпионской Wi-Fi-точкой, к которой подключаются ваши коллеги и, сами того не зная, сливают все «пароли и явки» киберпреступникам.
Даже если ваша сеть напичкана всевозможными средствами защиты, установлены антивирусы, построен SOC, проводится регулярное сканирование на уязвимости и налажено получение актуальных TI-фидов, инцидент ИБ все равно может случиться. Но правильная организация процесса Incident Response может минимизировать возможные последствия и снизить вероятность возникновения инцидента.
Согласно февральскому совместному отчету McAfee и Центра стратегических и международных исследований США (CSIS), киберпреступления уже стоили глобальной экономике порядка 600 млрд долларов. Для сравнения, в 2016 г. эта сумма составляла 445 млрд.
Функции CSIRT
Функции реагирования у команды CSIRT гораздо шире, чем просто реакция на инцидент. Их можно разделить на 3 группы.
Реактивные (reactive). Действия, в рамках которых осуществляется немедленное реагирование на инцидент по факту его выявления для снижения возможного ущерба для организации.
Проактивные (proactive). Действия, направленные на обнаружение и снижение потенциала инцидентов и событий ИБ путем их детектирования и сдерживания.
Повышение качества безопасности (security quality improvement). Меры по усилению осведомленности о состоянии защищенности и реальных угрозах ИБ. Это доносимая различными способами информация, основанная на экспертизе группы реагирования, полученной в ходе расследования и анализа инцидентов, взаимодействия с другими подразделениями и прочих активностей. Такие данные также могут способствовать предотвращению возможных инцидентов.
Основные функции CSIRT, которые так или иначе встречаются во всех источниках, можно описать следующим образом (см. табл.).
| ФУНКЦИИ CSIRT | ||
| Реактивные | Проактивные | Повышение качества безопасности |
| Обработка инцидентов ИБ | Мониторинг и детектирование событий ИБ | Повышение осведомленности сотрудников в области ИБ |
| Компьютерная форензика | Предоставление регулярной отчетности | Проведение тренингов и обучений коллег |
| Выездное и дистанционное реагирование | Аудит активов информационной системы | Консультирование по вопросам ИБ |
| Координация действий внутренних и сторонних подразделений | Управление средствами защиты | Публикация бюллетеней ИБ и других материалов |
| Устранение уязвимостей | Проактивный поиск угроз (Threat Hunting) | Разработка и корректировка регламентов и политик ИБ |
| Эксплуатация средств защиты | Оценка безопасности компьютерных систем | Участие в вопросах построения архитектуры ИБ и выборе конкретных решений |
| Накопление опыта и рекомендации по усилению защищенности | Поддержка средств ИБ | Оценка и анализ рисков ИБ для организации |
План реагирования
План — это отправная точка в процессе организации Incident Response. В нем должны быть четко обозначены:
/ цели, которых компания хочет достичь с помощью CSIRT;
/ ключевые роли в команде CSIRT;
/ способы взаимодействия CSIRT с внутренними подразделениями (техподдержка, ИТ-отдел) и другими организациями
(СМИ, вендоры, правоохранительные органы);
/ «дорожная карта» развития направления реагирования на инциденты ИБ;
/ методы оценки эффективности работы CSIRT и метрики, используемые для оценки.
После проработки и утверждения плана его необходимо периодически пересматривать и вносить коррективы в соответствии с изменениями в компании, ее внутренней политике, процессах реагирования и т.д.
Процесс реагирования
Это сердце CSIRT, то, для чего он, собственно, и задумывался. Процесс делится на фазы, которые относятся к реактивным функциям реагирования.
Несмотря на то что сценариев инцидента может быть много, все они вписываются в общую модель процесса реагирования.
В разных источниках фазы процесса разделяются по-разному. Например, NIST 800-61 R2 выделяет 4 фазы реагирования (Preparation, Detection & Analysis, Containment & Eradication & Recovery, Post-Incident Activity). Стандарт ISO/IEC 27035:2016 содержит 5 фаз, а институт SANS делит процесс на 6 фаз, но все они сводятся к следующим пунктам:
1. ПОДГОТОВКА
2. ОБНАРУЖЕНИЕ
3. АНАЛИЗ ПРОИЗОШЕДШЕГО
5. СДЕРЖИВАНИЕ
6. УСТРАНЕНИЕ
7. ВОССТАНОВЛЕНИЕ
8. ПОСТИНЦИДЕНТНАЯ АКТИВНОСТЬ
Действия злоумышленников и потери от них:
- кражи интеллектуальной собственности и конфиденциальной информаци;
- онлайн-мошенничество и финансовые махинации, которые часто происходят в результате кражи персональных данных;
- финансовые манипуляции, связанные с инсайдерскими утечками;
- срыв предоставления ИБ-сервисов в ходе кибератак и затраты на восстановление после инцидента;
- нанесение урона деловой репутации компании и бренда.
Оценить реальный ущерб от киберпреступ лений очень сложно: жертвы часто не сообщают об инцидентах из страха нанести еще больший вред репутации. На фоне этих данных глобальная задача, которая стоит перед CSIRT, — это минимизировать для компании риск стать очередной финансовой транзакцией в киберпреступной экономике.
1. Подготовка
Фаза подготовки (Preparation) — это планирование, создание команды, подготовка инструментов, места, составление документации и материалов для реагирования и т.д. О подготовке сказано уже достаточно много, однако есть один важный момент, на котором стоит остановиться.
В любой критичной ситуации важно сохранять хладнокровие, и инцидент ИБ не исключение. Действия группы реагирования должны быть систематическими и последовательными. Каждый член команды должен четко понимать, что, в какой момент и зачем нужно делать.
Для этого нужно иметь четкие задокументированные алгоритмы действий на случай того или иного типа инцидента (плэйбуки — playbook). Хорошей практикой считается создание плэйбуков по каждой категории инцидентов, так как эти документы способствуют не только повышению общей эффективности реагирования, но и оперативному включению в процесс новых членов команды. В Jet CSIRT мы создали плэйбуки для всех типовых классов инцидентов ИБ и теперь точно знаем, какие действия мы должны выполнить на каждой фазе реагирования. Благодаря этому процесс доведен практически до автоматизма.
Описание следующих фаз мы спроецировали на реальный инцидент, с которым столкнулись. Заодно мы рассматриваем, какие инструменты и ресурсы используются в процессе реагирования.
2. Обнаружение
Представьте ситуацию: ночью, когда на работе нет никого, кроме охранников, система мониторинга (SIEM) фиксирует событие ИБ — обнаружение вредоносного ПО на рабочей станции одного из сотрудников.
Автоматизация — это, конечно, хорошо, но, следуя старому принципу «доверяй, но проверяй», после обнаружения подобного события аналитик должен тщательно проверить всю информацию, зафиксированную системой. В соответствии с порядком действий в плэйбуке реагирования, на этапе обнаружения в первую очередь нужно подтвердить, что зарегистрированное событие — действительно инцидент ИБ (true positive). Всю полезную информацию, которую можно «вытянуть» (например, индикаторы компрометации, учетные записи, задействованные активы и т.п.), необходимо фиксировать в системе управления инцидентами ИБ (IRP) в виде карточки инцидента для последующего анализа и обмена информацией с другими подразделениями.
3. Анализ произошедшего
Далее начинается чисто аналитическая фаза: необходимо разобраться, что произошло и как это могло случиться, оценить уровень опасности произошедшего и на основании полученных данных принять решение о дальнейших действиях.
В соответствии с нашими плэйбуками реагирования проверяются сразу несколько векторов атак: запуски исполняемых файлов; получение электронных писем; сетевые взаимодействия узла; посещение веб-ресурсов.
Поиск вектора атаки — очень важный момент, поскольку его обнаружение помогает выработать правильную стратегию укрепления защиты и принятия мер, для того чтобы такие инциденты не повторялись в будущем. Но это уже задачи другой фазы — постинцидентной активности.
Найденные в рамках проверки индикаторы компрометации (хеш-суммы, имена файлов, IP-адреса, URL) необходимо затем проверить по репутационным базам. Для анализа выявленных индикаторов мы используем как коммерческие, так и открытые ресурсы, такие как VirusTotal, IBM X-Force Exchange, Cisco Talos и др. Это помогает выяснить детали инцидента, а также выявить новые индикаторы компрометации для последующей блокировки на средствах защиты.
На этапе анализа предстоит сделать еще очень много всего — например, выяснить, было ли заражение успешным, выполнить поиск связанных и предшествующих событий на зараженном узле, выяснить степень распространения и определить критичность инцидента, а также классифицировать вредоносное ПО.
После выполнения всех действий готовится вердикт, включающий в себя всю информацию, которую удалось собрать на этапе анализа инцидента. На основании вердикта принимается решение о дальнейших действиях. В случае подтвержденного заражения подключаются другие подразделения и начинается следующая фаза — сдерживание.
4. Сдерживание
Зная векторы атаки, имея сведения об индикаторах компрометации и затронутых активах, можно предпринять меры по сдерживанию распространения инцидента, другими словами — по его изоляции. На данном этапе в дело вступают инженеры реагирования. Они имеют доступ к необходимым средствам защиты и, исходя из содержащейся в карточке инцидента информации, производят действия по минимизации возможного ущерба от него. Например, в случае с вредоносным ПО может потребоваться изоляция зараженной станции средствами межсетевого экрана или блокировка вредоносных ресурсов, к которым обращается станция, на основании выявленных индикаторов компрометации.
5. Устранение
Как только инцидент изолирован и его дальнейшее распространение исключено, необходимо «вылечить» пораженные активы.
Результатом действий, проведенных на данном этапе, должно стать, например, подтверждение того, что на пораженных активах больше нет вредоносного ПО и что они не несут угрозу остальной сети. Иногда наша группа реагирования выезжает к заказчику для принятия необходимых мер по устранению. В большинстве случаев удается справиться удаленно. Все действия при этом подробно документируются, информация в карточке инцидента дополняется.
6. Восстановление
Когда активы восстановлены и угрозы для остальной сети нет, инженеры реагирования должны снять примененные ранее ограничения по изоляции на средствах защиты и подключить пострадавшие активы к сети.
Кроме того, необходимо сменить пароли для всех учетных записей, которые были задействованы в инциденте, и произвести другие действия, направленные на восстановление нормальной и безопасной работы.
7. Постинцидентная активность
После выполнения всех действий в рамках обработки инцидента необходимо провести Lesson learned.
На основании собранной и задокументированной в карточке инцидента информации могут:
/ вырабатываться рекомендации по усилению защищенности по выявленному вектору атаки;
/ корректироваться настройки средств защиты и правил выявления инцидентов;
/ корректироваться нормативная и справочная документация по реагированию на инциденты ИБ;
/ применяться административные меры по усилению осведомленности сотрудников в области ИБ или дисциплинарные взыскания.
Только после этого инцидент можно считать решенным.
Заключение
Как видите, реагирование на инциденты ИБ — комплексный и сложный набор мер, включающий работу различных подразделений и информационных систем.
Сегодня угрозы ИБ для бизнеса растут пропорционально ценности и стоимости информации. Современные технологии и автоматизация хотя и обеспечивают достаточно надежную защиту от автоматизированных атак, еще не способны полностью обезопасить инфраструктуру организации от спланированных и целенаправленных киберпреступных кампаний.
В Jet CSIRT мы собрали команду, которая точно знает, как нужно обрабатывать инциденты ИБ, делает это оперативно и грамотно, используя лучшие практики ведущих ИБ-организаций и собственные наработки.
