Не одна система не может функционировать без сбоев. Всегда есть риск того, что в процессе работы могут возникнуть проблемы, связанные с функционированием аппаратной части, софта или действиями пользователей. Далее, в этой статье мы будем говорить об инцидентах информационной безопасности и о реагировании на такие инциденты. Собственно, инцидентами ИБ мы будем называть одно или несколько нежелательных событий информационной безопасности, в результате которых возможна компрометация бизнес‑операций и угроза ИБ. Последствиями инцидентов ИБ могут быть прерывания бизнес‑процессов, нарушение конфиденциальности, целостности или доступности активов объекта, что в свою очередь приводит к потере производительности, ущербу с точки зрения материальных затрат или репутации.
Полностью избежать возникновение инцидентов практически невозможно, но можно научиться правильно реагировать на возникающие инциденты ИБ и минимизировать вероятность повторения подобных инцидентов. Для борьбы с инцидентами необходимо правильно выстроить процесс реагирования на инциденты, то есть комплекс мероприятий по обнаружению и прекращению кибератаки или утечки данных из инфраструктуры организации и устранению последствий. При этом, основная цель реагирования это свести к минимуму ущерб от инцидента, а также позволить организации как можно скорее и с наименьшими затратами вернуться к нормальному режиму работы.
Таким образом, нам важно не только оперативно выявлять инциденты, но и оперативно устранять их последствия и для этого рассмотрим основные этапы реагирования на инциденты.
Этапы реагирования
Традиционно принято выделять шесть основных этапов процесса реагирования на инциденты:
Подготовку
Идентификацию
Сдерживание
Ликвидацию
Возвращение к работе
Улучшение
Рассмотрим каждый из этапов подробно.
Подготовка
Начнем с этапа Подготовка. Насколько вообще можно подготовиться к инцидентам это вопрос открытый. Как бы хорошо мы не прорабатывали сценарии возможных проблемных ситуаций, всегда есть риск столкнуться с проблемой, которой еще не было. Однако, на этом этапе мы должны рассмотреть всевозможные инциденты ИБ, которые могут произойти.
Будем предполагать, что мы уже провели инвентаризацию наших ресурсов, составили модель угроз и теперь нам необходимо подготовить план реагирования на инциденты.
Далее нам необходимо составить список потенциальных угроз. Это могут быть заражения вредоносным ПО (такие типы инцидентов актуальны практически для любой организации), атаки на веб приложения, потеря или кража оборудования, атаки на отказ в обслуживании, злонамеренные действия сотрудников, фишинг и т. д.
После этого мы разрабатываем план реагирования на инциденты, который включает в себя сценарии работы сотрудников при наступлении того или иного события. Например, план реагирования на инцидент заражения вредоносным ПО должен включать в себя шаги по изоляции (но не физическому отключению!) зараженной машины, получению дампов памяти и жесткого диска, и других действий, необходимых для проведения расследования.
Также, план реагирования включает в себя список необходимых для работы ресурсов, перечень применяемых инструментов, права и обязанности команды реагирования.
И не стоит забывать о людях. Данный этап помимо прочего предполагает обучение ответственных за реагирование на инцидент сотрудников. То есть, для нашего примера с вредоносами нам необходимо наличие специалистов, умеющих работать со средствами сбора дампов.
И важно понимать, что этот этап не привязан к конкретному инциденту.
Идентификация
Прежде чем начать реагировать на инцидент, нам необходимо вообще узнать о том, что он произошел. Другими словами, нам нужно выявить инцидент. Для выявления инцидентов нам необходимо анализировать события, приходящие от различных источников, проверяя их на соответствие набору правил. В случае соответствия событий правилу, инцидент создается автоматически. Такой анализ потока событий в автоматическом режиме выполняют решения класса SIEM (Security Information Event Management), и их реинкарнации UBA/UEBA.
В рамках данной статьи мы не будем подробно рассматривать решения данного класса, так как SIEM системам будет посвящена отдельная статья.
В качестве примеров инцидентов можно привести вирусную атаку, когда вредоносы активизируются сразу на нескольких узлах. Еще одним не совсем типичным примером инцидента является отсутствие актуальных вирусных баз на узле в течении продолжительного периода времени. Если узел работает, но базы уже минимум неделю не обновлялись, то это тоже повод для инцидента.
И помимо автоматических средств создания инцидентов, не стоит забывать и о «ручных» методах. Так не стоит забывать, что о протечке в серверной или пропаже диска из RAID вам вряд ли сможет сообщить SIEM. Такие инциденты обычно создаются вручную, после поступления соответствующей информации от персонала. Поэтому не стоит забывать о возможностях создавать инциденты посредством телефонных звонков и заполнения веб форм.
Таким образом, реагирование на инцидент начинается с обнаружения кибератаки или утечки данных. На этом этапе поступает оповещение об инциденте, специалисты оценивают угрозу и собирают данные о ней.
Сдерживание
Далеко не всегда можно быстро остановить развитие инцидента. Так, для того, чтобы остановить быстрое распространение вредоносов необходимо изолировать сегменты с зараженными машинами от остальной сети. На этом этапе основной задачей является предотвращение распространения угрозы далее по сети. Речь о полном устранении угрозы пока не идет.
Но, как уже упоминалось выше, на этом этапе важно сохранить улики, необходимые для дальнейшего расследования. Многие современные вредоносы и хакерские инструменты могут не иметь файлового тела. То есть, весь необходимый для работы код находится в памяти компьютера жертвы. И в случае, отключения питания важная для расследования информация будет потеряна. Поэтому важно при изоляции скомпрометированных узлов не отключать на них питание. Лучшим способом изоляции является помещение узлов в отдельный изолированный сегмент или VLAN.
Анализ дампа памяти может выполняться с помощью различных средств, как программных, так и аппаратных, но пожалуй, наиболее распространенным является Open‑source фреймворк Volatility. Данный инструмент имеет множество плагинов для работы с дампами памяти. В частности с его помощью можно узнать из дампа памяти какие процессы и какие DLL были запущены в системе, какие пользователи залогинены и многое другое.
Так что сохранение дампа памяти это важный шаг, необходимый для эффективного расследования инцидента.
Ликвидация
После локализации инцидента и сохранения всех необходимых дампов и улик нам необходимо приступить к ликвидации последствий инцидента. Если у нас скомпрометированы критичные серверы или большое количество рабочих станций, то продолжительный простой этих ресурсов может оказать негативное влияние на бизнес процессы и нанести ущерб. Поэтому необходимо как можно скорее вернуть в строй пострадавшие ресурсы.
Зачастую, для восстановления работоспособности узлов приходится прибегать к перестановке системы и восстановлению из бэкапа (если он есть). При восстановлении не стоит забывать о необходимости смены паролей пострадавших учетных записей, так как это один необходимых шагов для недопущения повторения подобных инцидентов.
В итоге, на данном шаге мы осуществляем ввод обратно в эксплуатацию систем, затронутых инцидентом, подключение устройств к сети, тестирование и мониторинг корректности их работы.
Улучшение
Шаг Lessons learned можно переводить по разному. Суть этого шага заключается в том, что мы должны недопустить повторение подобных инцидентов в будущем. Или хотя бы сделать так, чтобы в дальнейшем решение аналогичных инцидентов занимало гораздо меньше времени. Для этого нам необходимо проанализировать, что именно произошло. При этом важно не зацикливаться на извечном вопросе «Кто виноват?», так как в таком случае вместо правильных выводов о причинах инцидента мы рискуем получить банальную склоку между различными подразделениями.
Так например, если инцидент произошел из‑за успешной эксплуатации уязвимости в прикладном ПО, необходимо понять почему данная уязвимость не была закрыта ранее, установить соответствующие патчи на другие узлы с данным ПО и принять меры по своевременному анализу наличия уязвимостей и установке обновлений.
После того как соответствующие «уроки выучены» необходимо произвести обновление плана реагирования на инциденты с учетом опыта, полученного при устранении кибератаки и проведенного анализа.
Заключение
В этой статье мы рассмотрели основные моменты, связанные с процессом реагирования на инциденты. Конечно каждый из этапов имеет ряд нюансов, связанных со спецификой работы той или иной организации, но в целом основные этапы будут именно такими.Больше практической информации мы рассказываем в рамках онлайн‑курса про реагирование на инциденты. Прямо сейчас вы можете зарегистрироваться на бесплатные уроки курса, которые пройдут совсем скоро: