Обнаружение становится одним из наиболее важных элементов управления безопасностью для компании. Датчики, расположенные по всей сети (локаль- ные и облачные), будут играть важную роль при выявлении подозрительной активности и создании оповещений. Растущая тенденция в области кибер­ безопасности заключается в использовании разведывательных данных и рас- ширенной аналитики для более быстрого обнаружения угроз и уменьшения количества ложных срабатываний. Это может сэкономить время и повысить общую точность.

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

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

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

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

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

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

Передовые методы оптимизации обработки компьютерных инцидентов

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

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

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

Реагирование на компьютерные инциденты в облаке

Когда мы говорим об облачных вычислениях, то ведем речь о разделении от- ветственности(4)междуоблачнымпровайдеромикомпанией,котораязаклю- чаетконтрактнаобслуживание.Уровеньответственностибудетварьироваться

взависимости от модели обслуживания, как показано на рис. 2.6.

Вслучае с моделью SaaS (англ. software as a service – программное обеспече- ниекакуслуга)большаячастьответственностилежитнаоблачномпровайдере. Действительно,ответственностьклиентазаключаетсявтом,чтобыобеспечить защитусвоейинфраструктурылокально(включаяконечнуюточку,котораяоб- ращается к облачному ресурсу). В случае с моделью IaaS (англ. Infrastructure as a service–инфраструктура как услуга) большая частьответственностилежитна

стороне клиента, включая уязвимости и управление исправлениями.

Пониманиеобязанностейважнодляопределенияграницсбораданныхвце- лях реагирования на инциденты. В среде IaaS у вас есть полный контроль над виртуальной машиной и полный доступ ко всем журналам, предоставляемым операционной системой. Единственная недостающая информация в этой мо- дели–базовая сетевая инфраструктура и журналы гипервизора.Укаждого об- лачного провайдера (5) будетсвоя собственная политика сбораданных в целях реагирования на инциденты, поэтому обязательно ознакомьтесь с политикой облачного провайдера, прежде чем запрашивать какие-либо данные.

Для модели SaaS подавляющее большинство информации, относящейся к реагированию на инциденты, принадлежит облачному провайдеру. Если в службе SaaS обнаружены подозрительные действия, вам следует связаться напрямую с провайдером или сообщитьоб инциденте через портал (6).Обяза- тельно ознакомьтесь со своим соглашением об уровне предоставления услуги, чтобы лучше понять правила участия в сценарии реагирования на инцидент.

Обновление процесса реагирования,чтобы включить облако

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

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

обнаружение. В зависимости от используемой вами облачной модели можно включить решение облачного провайдера для обнаружения, что- бы помочь вам во время расследования (7);