46    Процесс реагирования на компьютерные инциденты

ствовать процесс путем выявления пробелов и определения областей улучше-

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

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

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