Подготовка (Preparation)
В момент, когда происходит инцидент ИБ, от сотрудников, ответственных за ИБ, требуются моментальные и точные действия. Поэтому для эффективного реагирования необходима предварительная подготовка. Cотрудники, ответственные за ИБ, должны обеспечить защиту ИС и проинформировать пользователей, а также ИТ-персонал, о важности мер по обеспечению ИБ. Сотрудники, занимающиеся реагированием на инциденты ИБ, должны пройти соответствующее обучение и регулярно посещать тренинги по ИБ, для того чтобы оперативно и эффективно реагировать на инциденты ИБ.
Для того чтобы эффективно противостоять угрозам ИБ, рекомендуется обеспечить защиту ИС на всех уровнях. На рабочих станциях рекомендуется установить Endpoint-антивирусы. В сети ИС должны присутствовать IPS, FireWall, Proxy с авторизацией, анти-APT-решения, SIEM с интегрированными потоками данных об угрозах, системы сетевых ловушек и другие системы ИБ.
Повышению безопасности ИС также способствует проведение тестов на проникновение в ИС данной компании (penetration testing) и ознакомление специалистов, обеспечивающих ИБ, с отчетами по тестированию на проникновение. Тестирование может быть проведено сторонними организациями, а информация из отчётов поможет выявить и устранить уязвимости в ИС организации.
Для отслеживания и ведения статистики инцидентов ИБ необходимо выработать процедуру реагирования на инциденты ИБ, а также выбрать средство накопления и хранения экспертной информации и отчётов о произошедших ранее инцидентах ИБ. Такая информация позволит ускорить расследования инцидентов ИБ в будущем.
Обнаружение (Identification)
Сотрудники, занимающиеся реагированием на инциденты, должны определить, является ли обнаруженное ими с помощью различных систем обеспечения ИБ событие инцидентом или нет. Для этого могут использоваться публичные отчеты, потоки данных об угрозах, средства статического и динамического анализа образцов ПО и другие источники информации. Статический анализ выполняется без непосредственного запуска исследуемого образца и позволяет выявить различные индикаторы, например, строки, содержащие URL-адреса или адреса электронной почты. Динамический анализ подразумевает выполнение исследуемой программы в защищенной среде (Песочнице) или на изолированной машине с целью выявления поведения образца и сбора артефактов его работы (IOC).
Сбор индикаторов компрометации является итерационным процессом. На основе первоначальной информации, полученной от SIEM-системы, происходит формирование сценариев обнаружения, применение которых, как правило, приводит к выявлению новых индикаторов компрометации. Полученные таким образом индикаторы помогают уточнить границы атаки и служат отправной точкой для нового цикла обнаружения.
Дальнейшие шаги предпринимаются только если событие решено считать инцидентом ИБ.
События ИБ, свидетельствующие о возможном инциденте ИБ
К источникам событий ИБ относятся Anti-APT-системы, сетевые ловушки (honeypot), системы обнаружения вторжений и многие другие решения для обеспечения ИБ (security controls). В рамках этого руководства область источников событий сужена до SIEM-систем (SIEM поддерживают интеграцию с различными программными и аппаратными решениями обеспечения ИБ, в том числе прокси-серверами, брандмауэрами и другими) и систем централизованного управления корпоративными Endpoint-антивирусами
Триггерами для начала реагирования на инцидент могут быть следующие события:
- Событие в SIEM, возникающее в результате срабатывания корреляционных правил.
- Некоторые срабатывания антивируса на Endpoint-компьютере (информация о срабатывании отображается в центре управления антивирусами).
- Не всякое срабатывание антивируса должно инициировать процесс реагирования на инциденты. Требующими расследования можно считать следующие срабатывания:
- обнаружение взаимодействия с сервером управления C&C;
- безуспешное лечение зараженных объектов;
- неоднократное заражение одного и того же компьютера;
- ошибки в работе антивируса, которые приводят к снижению уровня защищённости.
Эти триггеры почти всегда свидетельствуют о наличии инцидента ИБ. Однако не следует опираться только на них. О наличии инцидента могут свидетельствовать и иные события, наличие которых должно заставить сотрудника, ответственного за ИБ, более внимательно отнестись к исследованию данного события ИБ, например:
- наличие неизвестного ПО в списках автозагрузки;
- появление неизвестных сервисов в списке сервисов ОС;
- запуск исполняемых файлов из папок, в которых ПО обычно не располагается (например, временные папки системы, системный кеш и другие);
- загрузка динамических библиотек из папок, в которых обычно данные библиотеки не располагаются (например, загрузка системных библиотек из папки, в которой располагается загружающий их исполняемый файл);
- непредвиденная или необычная сетевая активность;
- непредвиденное повышение привилегий пользователя.
Общие указания по приоритизации
Время является одним из самых дефицитных ресурсов при реагировании на инциденты; от скорости реакции сотрудников ИБ зависит то, успеет атака достичь целей или нет. Однако в случае большого числа инцидентов реагировать на все инциденты сразу невозможно. В такой ситуации необходимо приоритизировать инциденты.
Приоритет инцидента выставляется в зависимости от сегмента сети (определяется не только физическим положением компьютера в сети, но и ценностью данных, которые размещены на потенциально скомпрометированной машине), в котором произошел инцидент, типа и количества инцидентов, а также от показателя достоверности индикатора, по которому был выявлен инцидент.
Определять, какие инциденты следует расследовать в первую очередь, следует исходя из специфики конкретной организации. В некоторых случаях наибольшую опасность могут представлять инциденты, в которых были обнаружены вирусы-шифровальщики (Ransomware), в других – инциденты с ПО, относящимся к категории условно
опасных программ.
В качестве примера приоритизации можно привести подход, при котором в первую очередь должны быть расследованы инциденты, в которых есть подозрения на APT-угрозы (способы определения APT-угроз перечислены ниже), затем следует переключиться на инциденты, связанные с вредоносными ПО. Последними расследуются инциденты, связанные с ПО, относящимся к категориям условно опасных угроз (Adware, Pornware и подобных).
Сдерживание (Containment)
Сотрудники, ответственные за ИБ, должны идентифицировать скомпрометированные компьютеры и настроить правила безопасности таким образом, чтобы заражение не распространилось дальше по сети. Кроме того, на этом этапе необходимо перенастроить сеть таким образом, чтобы ИС компании могла продолжать работать без зараженных машин.
Цель этого этапа заключается не только в том, чтобы изолировать скомпрометированные компьютеры, но и в том, чтобы не допустить уничтожения индикаторов компрометации, которые могут помочь в расследовании инцидента. Некоторые угрозы не создают файлов на диске, а полностью размещают себя в оперативной памяти, так как там их сложнее обнаружить. Поэтому недопустимо отключать питание компьютера, так как при этом будет утрачена вся информация, содержащаяся в оперативной памяти
Изоляция инфицированных машин
Рекомендуется вывести инфицированные компьютеры в отдельную сеть. В случае, если есть подозрение на APT-атаку, не следует физически отключать компьютер от локальной сети (извлечением провода). Некоторые виды угроз отслеживают наличие сетевого соединения и могут начать уничтожение следов в случае, если сеть была отключена на длительное время. Вместо этого следует перенастроить правила маршрутизации таким образом, чтобы инфицированные машины не смогли коммуницировать с другими компьютерами организации.
Снятие образов
Для дальнейшего расследования необходимо получить дампы оперативной памяти и диска скомпрометированного компьютера. Снятие образов позволяет получить все компоненты вредоносного ПО. По результатам исследования этих компонентов можно определить, как следует бороться с заражением. Также анализ образов позволит определить вектор распространения угрозы, чтобы не допустить повторного заражения по аналогичному сценарию.
В случае, если передача данных затруднена (например, организация имеет несколько географически распределенных офисов и сотрудники, ответственные за реагирование на инциденты, есть только в некоторых из них), необходимо в первую очередь передать для исследования дамп оперативной памяти и лишь затем принять решение о необходимости снятия полного образа диска. При снятии образа диска записывается полный образ диска
(в том числе с неиспользуемых секторов), а не только видимая пользователю часть, поэтому необходим носитель информации, превышающий общую емкость жесткого диска.
Перевод системы в режим работы без изолированных машин
Проведение этапа восстановления займет некоторое время. На это время ИС должна быть сконфигурирована так, чтобы отсутствие пораженных машин минимально влияло на функционирование ИС.
Удаление (Eradication)
Цель этого этапа – привести скомпрометированную ИС в состояние, в котором она была до заражения. Сотрудники, ответственные за ИБ, удаляют вредоносное ПО, а также все артефакты, которые оно могло оставить на зараженных компьютерах в ИС.
Существуют две стратегии проведения данного этапа – полное восстановление из образа рабочей станции или обнаружение и удаление угрозы и всех её артефактов (набор артефактов определяется по результатам анализа).
В корпоративных сетях, где рабочее место пользователя стандартизовано, может оказаться, что эффективнее вместо этапов сдерживания, удаления и восстановления полностью переустановить операционную систему и ПО на скомпрометированных пользовательских рабочих станциях (образцы вредоносного ПО при этом необходимо сохранить для расследования). В случае заражения мобильного устройства эффективнее может быть проведение процедуры аппаратного сброса.
Восстановление (Recovery)
После успешного проведения этапа удаления необходимо ввести машины обратно в сеть. При этом сотрудники, ответственные за ИБ, должны некоторое время внимательно наблюдать за состоянием сети и восстановленных машин, чтобы убедиться в том, что угроза была полностью устранена.
Выводы (Lessons learned)
По результатам расследования инцидента сотрудники, ответственные за ИБ, готовят отчет. Содержание отчета должно отвечать на вопросы:
- Когда, кем, и с помощью каких инструментов был впервые обнаружен инцидент?
- Что включал в себя инцидент?
- Как проводилось сдерживание, удаление и восстановление?
- На каких этапах реагирования сотрудники, ответственные за ИБ, были наиболее эффективны?
- Что необходимо улучшить в работе сотрудников, ответственных за ИБ?
Также на этом этапе необходимо подготовить рекомендации по повышению ИБ ИС. Рекомендации основываются на информации о способах доставки и закрепления угрозы, полученной в ходе расследования. Такие рекомендации позволяют дополнить правила устройств, обеспечивающих ИБ, новыми правилами и индикаторами угроз, в том числе
расширить черные списки полученными индикаторами, например, URL- и IP-адресами, хеш-суммами угроз.
Выводы также могут повлечь обновление регламентов и правил пользования ИС организации. В таком случае новые правила должны быть доведены до сведения всех сотрудников компании и отражены в бизнес-логике ИС.