Для чего нужен Incident Response и как это устроено ?
Информационная безопасность Информационная безопасность

Последние два года выдались для сферы ИБ особенно напряженными.

Главная>Информационная безопасность>Погружение в Incident Response. Как это устроено
Информационная безопасность Тема номера

Погружение в Incident Response. Как это устроено

Дата публикации:
03.10.2019
Посетителей:
2392
Просмотров:
2601
Время просмотра:
2.3

Авторы

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

 

 

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

 

Кто-то сосредоточивается на обнаружении инцидентов, создавая собственный 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 мы собрали команду, которая точно знает, как нужно обрабатывать инциденты ИБ, делает это оперативно и грамотно, используя лучшие практики ведущих ИБ-организаций и собственные наработки.  

Уведомления об обновлении тем – в вашей почте

Аудит безопасности информационных систем

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

Информационная безопасность - обзор основных положений. Часть 3

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

Информационная безопасность - обзор основных положений. Часть 1

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

Распределенные атаки на распределенные системы

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

Подушка безопасности

Режим коммерческой тайны – когда нужно о нем задуматься и как его внедрить

Методология оценки безопасности информационных технологий по общим критериям

  В 1990 году под эгидой Международной организации по стандартизации (ИСО) и при содействии в дальнейшем государственных организаций США, Канады, Великобритании, Франции, Германии и Нидерландов были развернуты работы по созданию ...

Оценка рисков как must have, или перестаньте тыкать пальцем в небо

Как часто нужно проводить оценку рисков? Какой софт целесообразно использовать для таких проектов? По каким причинам снижается продуктивность ИБ-специалистов?

Категорирование информации и информационных систем. Обеспечение базового уровня информационной безопасности

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

Информационная безопасность: экономические аспекты

Отечественный ИТ-рынок в последние несколько лет динамично развивается, по оценкам экспертов его рост превышает 10% в год. При этом сектор информационной безопасности (ИБ) развивается еще более быстрыми темпами – более чем на 25% в год. Такой ...

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня