- Расследования
- Реагирование на инциденты
- Процедуры реагирования на инциденты
Число компьютерных преступлений постоянно растет, поэтому специалистам по безопасности важно понимать, как должно проводиться расследование таких преступлений. Это включает в себя понимание требований законодательства к конкретным ситуациям, системы охраны вещественных доказательств (chain of custody), понимание того, какие доказательства приемлемы для использования в суде, какие следует применять процедуры реагирования на инциденты, процессы эскалации.
При расследовании компьютерного преступления очень важно правильно выполнить все необходимые для этого процедуры, предусмотренные законодательством. Это необходимо, чтобы собранные доказательства могли быть приняты в суде и проверены. Любое нарушение процедуры сбора доказательств может привести к тому, что доказательства не будут приняты судом и это разрушит все дело. Специалист по безопасности должен понимать, что расследование касается не только потенциальных улик на жестком диске – оно будет проводиться в отношении всего окружения: люди, сеть, любые подключенные внутренние и внешние системы.
О многих компьютерных преступлениях ничего не известно, поскольку часто жертвы таких преступлений либо не знают о том, что они стали жертвами, либо они хотят просто исправить проблему безопасности, которой воспользовался хакер, и сохранить в тайне сведения о произошедшем инциденте, чтобы избежать ущерба репутации компании. Это не позволяет рассчитать реальную статистику компьютерных преступлений – сколько их происходит ежедневно, каков причиняемый ущерб, какие методы атак применяются злоумышленниками.
Мы часто используем термины «событие» (event) и «инцидент» (incident) как взаимозаменяемые, но на самом деле между ними есть важное различие. Событие – это негативное происшествие, которое можно выявить, проверить и задокументировать, тогда как инцидент представляет собой последовательность событий, которая негативно влияет на компанию и / или воздействует на состояние ее безопасности. Именно поэтому мы называем реагирование на подобные проблемы «реагированием на инциденты» (incident response) и «обработкой инцидентов» (incident handling), именно инциденты вызывают нарушения безопасности и ведут к негативному влиянию на компанию.
Существует множество различных видов инцидентов (вирусы, инсайдерские атаки, утечки или повреждения информации и т.п.), часто они бывают следствием человеческих ошибок. На практике, люди, в обязанности которых входит реагирование на инциденты, довольно часто получают вызовы, потому что "система работает странно". Причиной может быть недавняя установка патча, который испортил что-нибудь, неправильная настройка системы администратором или ошибки программиста.
Если в компании происходит компьютерное преступление, она должна сохранить доказательства и окружение в неизменном состоянии и обратиться к специалистам (правоохранительным органам), уполномоченным на расследование таких происшествий. Человек, не знакомый с правильной организацией проведения процедуры сбора данных и улик на месте преступления, может уничтожить важные доказательства, что может привести к невозможности судебного преследования злоумышленника. У компании должны быть заранее проработанные процедуры по различным вопросам в области компьютерной безопасности, в частности, процедурам обеспечения непрерывности, процедурам восстановления после аварий, процедурам резервного копирования данных. Помимо них, должна быть разработана процедура расследования компьютерных инцидентов, поскольку количество таких инцидентов многократно возрастает из года в год. Среди таких инцидентов сетевые атаки, атаки на информационные системы, спам, фишинг, вредоносное программное обеспечение, DDoS-атаки и т.п.
К сожалению, многие компании не имеют представления о том, к кому обращаться и что делать в случае, если они станут жертвой компьютерного преступления. Поэтому любая компания должна заранее разработать политику реагирования на инциденты и соответствующие процедуры, предназначенные именно для таких случаев. Эта политика должна разрабатываться и поддерживаться юридическим департаментом (либо, как минимум, с его активным участием).
Политика реагирования на инциденты должна быть краткой и ясной. Например, она должна указывать, следует ли отключать системы, чтобы попытаться сохранить доказательства, либо системы должны продолжать работать, невзирая на риск уничтожения доказательств. Каждой системе и функции должен быть присвоен приоритет. Например, если файловый сервер компании заражен вирусом, его нужно отключить от сети, но не выключать. Однако если заражен почтовый сервер, он должен продолжать работать, поскольку он имеет более важное значение для компании, чем файл-сервер. Лучше заранее продумать все подобные компромиссы, прежде чем произойдет такая ситуация. Это позволит принять значительно более обдуманное и логичное решение, по сравнению с эмоциональным решением, принятым в спешке и хаосе критической ситуации.
В любой компании должна быть организована команда реагирования на инциденты (incident response team), которая должна быть готова к работе с широким спектром возможных инцидентов. Такая команда нужна для того, чтобы в компании всегда была группа имеющих необходимые навыки людей, которые готовы в короткие сроки приступить к выполнению определенного набора процедур в случае инцидента. Среди прочего, эта команда должна уметь скоординировано работать с правоохранительными органами. Команда реагирования на инциденты является одним из важнейших элементов программы безопасности в целом. В составе команды должны быть представители бизнес-подразделений, юридического департамента, кадровой службы, службы физической (корпоративной) безопасности, службы по связям с общественностью, подразделения информационной безопасности, департамента ИТ и кто-то из высшего руководства компании.
Существует три различных типа команды реагирования на инциденты. Виртуальная команда (virtual team) состоит из специалистов, которые в обычное время выполняют другие обязанности в компании. Время реагирования такой команды обычно больше, чем для команд других типов, к тому же в случае инцидента члены виртуальной команды будут вынуждены пренебречь своими повседневными обязанностями в компании. В результате, виртуальная команда может оказаться дорогим решением. Однако не каждая компания может позволить себе организовать постоянную команду (permanent team), состоящую из людей, единственной функцией которых является реагирование на инциденты. Третьим типом является смешанная команда (hybrid team). Ядро такой команды состоит из людей, выполняющих исключительно работу в части реагирования на инциденты, остальные члены команды привлекаются к ее работе в случае необходимости.
У команды реагирования на инциденты всегда под рукой должны быть следующие документы (сведения):
- Перечень внешних организаций и ресурсов, с которыми нужно взаимодействовать или перед которыми нужно отчитываться в случае инцидента
- Описание ролей и обязанностей
- Дерево вызовов для взаимодействия с этими ролями и внешними организациями (лицами)
- Список экспертов по компьютерной криминалистике, к которым можно обратиться при необходимости
- Описание шагов, которые необходимо выполнить для обеспечения сохранности и защиты доказательств
- Перечень пунктов, которые должны быть включены в отчет для руководства и (возможно) для суда
- Описание того, что следует делать с различными системами в такой ситуации (например, должны ли системы быть отключены от сети Интернет, внутренней сети или полностью выключены).
Компьютерные сети и бизнес-процессы стоят перед лицом множества различных угроз, каждая из которых требует определенной реакции. Тем не менее, команде реагирования на инциденты следует разработать и описать основные шаги, применимые к обработке любых инцидентов. Это гораздо лучше реактивного подхода, при котором о дальнейших действиях начинают думать, когда инцидент уже произошел – такие решения обычно эмоциональны, недостаточно продуманы и не скоординированы. Четко описанный процесс обработки инцидентов значительно более экономически эффективен, он обеспечивает более быстрое восстановление, а также единый подход, позволяющий рассчитывать на определенные результаты.
Обработка инцидентов должна быть тесно связана с планированием восстановления после аварий, она должна являться частью этого плана (приложением), поскольку оба этих плана предназначены для реагирования на определенные инциденты, которые требуют быстрой реакции для максимально быстрого возвращения компании к нормальной работе. Обработка инцидентов – это план восстановления, относящийся к техническим угрозам. Основной задачей обработки инцидента является минимизация ущерба, вызванного инцидентом, а также предотвращение дальнейшего ущерба. Обычно этапами обработки инцидента является: выявление проблемы, определение причин ее возникновения, решение проблемы и документирование всего этого процесса.
Не имея эффективной программы обработки инцидентов, часто люди даже с лучшими намерениями, могут только ухудшить ситуацию, повредив доказательства, разрушив системы и данные, либо допустив распространение вредоносной программы. Злоумышленники часто ставят ловушки в скомпрометированной системе, позволяющие, например, удалить определеные файлы, имеющие критическое значение, при выполнении пользователем какого-нибудь простого действия, например, вывода списка файлов в каталоге. Скомпрометированной системе нельзя доверять, поскольку злоумышленник мог переопределить внутренние команды или заменить системные файлы, вызов любой команды или программы на такой системе может привести к неожиданным последствиям. Злоумышленник может установить на скомпрометированную систему бэкдор, который позволит злоумышленнику вернуться в эту систему в любой момент, либо логическую бомбу, которая будет тихо ждать пользователя, чтобы уничтожить важные улики или начать следить за действиями пользователя.
Вопросы обработки инцидентов должны учитываться при проведении обучения и повышения осведомленности персонала компании по вопросам безопасности. В частности, до сведения сотрудников должны доводиться отдельные данные по ранее произошедшим инцидентам, чтобы они понимали, с чем может столкнуться компания, что нужно делать в таких случаях и как избежать повторения подобных инцидентов.
Сотрудники должны знать, каким образом и кого нужно уведомлять о произошедшем инциденте. Для этого политика реагирования на инциденты должна содержать детальное описание процесса эскалации, чтобы сотрудники понимали, когда о преступлении нужно сообщать руководству, а когда внешним организациям или правоохранительным органам. Этот процесс должен быть централизованным, удобным и легко выполнимым (иначе сотрудники не будут никого беспокоить). Многие сотрудники очень неохотно сообщают об инцидентах, потому что они боятся наказания, либо не хотят быть причастны к этому. Нет ничего хуже, чем получить по рукам, пытаясь сделать что-то правильное и важное. Сотрудники должны чувствовать себя вполне комфортно, участвуя в этом процессе, а не опасаться за последствия, сообщив о подозрительных действиях.
Политика реагирования на инциденты должна указывать, как сотрудники должны отвечать на вопросы внешних организаций, таких как средства массовой информации, правительственные учреждения, правоохранительные органы. Это достаточно сложный вопрос, он зависит, в частности, от юрисдикции, характера преступления и доказательств. Одна лишь юрисдикция может зависеть от страны, региона или надзорного органа. Учитывая нежелательность широкого распростанения информации об инциденте в компании, в процессе такого взаимодействия должны участвовать сотрудники подразделения по связям с общественностью, кадровой службы или другие заранее подготовленные люди, уполномоченные на публичное обсуждение произошедших в компании инцидентов. Если при публичном сообщении информации о произошедшем инциденте что-то было сделано неправильно, это может усугубить негативные последствия. Например, в современном информационном обществе ответ «без комментариев» или отрицание может привести к негативной реакции и распространению порочащих компанию слухов. Однако если все сделано правильно, это может дать компании возможность вернуть доверие общественности. Во многих странах либо уже существуют, либо планируются законы, требующие, чтобы компании сообщали общественности информацию об инцидентах безопасности (произошедших или подозреваемых), связанных с персональными данными или иной идентификационной информацией людей. Поэтому открытость и откровенность компании при взаимодействии с третьими сторонами все чаще находится в интересах компании.
Программа обработки инцидентов должна предусматривать работу с внешними учреждениями и контрагентами. Члены команды должны подписаться на рассылку CERT (Computer Emergency Response Team), чтобы получать актуальную информацию о новых угрозах и иметь возможность выявить признаки преступной деятельности, прежде чем преступление реально произойдет. CERT – это организация, которая осуществляет мониторинг и консультирует пользователей и компании о мерах по обеспечению безопасности и нарушениях безопасности.
В предыдущих разделах было неоднократно сказано, что в компании должен быть предварительно разработанный набор процедур, которым будет следовать команды при возникновении инцидента. Но что это за процедуры? Хотя различные компании по-разному описывают эти процедуры (или этапы), по сути, они выполняют практически одно и то же. Реагирование на инциденты – это динамический процесс. Отдельные его этапы выполняются параллельно, а другие – последовательно, в случае, если следующий этап зависит от результатов предыдущего. Очень важно, чтобы компания использовала методический подход, который обеспечит надлежащее документирование событий и действий, что может иметь важное значение на более поздних этапах процесса реагирования на инциденты или, если дело дойдет до суда, когда вас спросят, следовали ли вы стандартным процедурам, не пропускали ли вы отдельные шаги. Документ с перечнем шагов и вашими отметками об их выполнении будет приемлемым доказательством в суде.
Вам следует понимать следующий набор процедур для реагирования на инциденты:
- Установление очередности
- Локализация
- Расследование
- Анализ
- Отслеживание
- Восстановление
То же самое происходит в компьютерном мире. Сразу после получения информации об инциденте, мы анализируем его тяжесть и устанавливаем приоритеты в отношении этого инцидента. Процесс начинается с тщательного анализа информации о произошедшем событии для выяснения, действительно ли произошел инцидент и нужно ли приступать к продедуре его обработки. На одного из членов команды реагирования на инциденты должна быть возложена обязанность по анализу полученной информации об инциденте для выяснения, является ли она достоверной или ложной (например, вызванной ложным срабатыванием системы защиты). Если выясняется, что информация была ложной, сведения об этом регистрируются и процесс реагирования на инцидент на этом завершается. Однако если выясняется, что инцидент действительно произошел, он должен быть идентифицирован и классифицирован. Классификация инцидента должна быть произведена на основе уровня потенциального риска, который зависит от типа инцидента, его источника (внешний или внутренний), темпов его развития и возможности нанести ущерб. В свою очередь это определяет, какие уведомления требуются в рамках процесса эскалации, устанавливает границы и процедуры проведения расследования.
После выяснения серьезности инцидента, мы переходим к следующему этапу, которым является локализация (containment). К примеру, если врач выявил у больного туберкулез, он должен будет положить больного в изолятор, чтобы он никого не заразил. На этапе локализации должен быть минимизирован ущерб. В компьютерном мире, для этого может потребоваться отключить зараженный сервер от сети, внести изменения в настройки межсетевого экрана или полностью изолировать атакуемую систему от сети Интернет, чтобы остановить атакующего.
Правильная стратегия локализации дает команде реагирования на инциденты время для проведения надлежащего расследования и определения основной причины инцидента. Стратегии локализации должны быть основаны на категории атаки (внутренняя или внешняя), активах, которым нанесен вред, и их критичности. Какие стратегии локализации предпочтительны? Это зависит от конкретной ситуации. Стратегии локализации могут быть проактивными или реактивными. Какая из них лучше, зависит от окружения и категории атаки. В некоторых случаях, лучшим решением будет просто отключить систему от сети. Однако такой реактивный подход может привести к прерыванию обслуживания или ограничению функциональности критичных систем. При невозможности полной изоляции или локализации, можно использовать сегментацию сети для виртуальной изоляции системы (одной или нескольких). Граничные устройства также могут использоваться для предотвращения заражения одной системой других. Другой вариант реактивной стратегии предполагает анализ и внесение изменений в настройки правил межсетевого экрана или маршрутизатора с пакетной фильтрацией. Для снижения негативного воздействия также могут применяться списки контроля доступа. Однако по таким стратегиям локализации злоумышленник может понять, что его атака была замечена и предпринимаются контрмеры. Но что если вам нужно оставить пострадавшие системы подключенными к сети и делать вид, что вы не заметили атаку, чтобы собрать как можно больше информации для последующего анализа основных причин инцидента? Для этого вы можете использовать сети-приманки (или хосты-приманки), создав таким образом область, в которой злоумышленник может выполнять любые действия, с минимальным риском для компании. Для реализации такого решения следует проконсультироваться с юристами и высшим руководством компании, поскольку это может привести к правовым проблемам. Кроме того, компьютеры из сети-приманки могут быть использованы злоумышленником для атак на другие внутренние цели.
После того, как инцидент удалось локализовать, нужно собрать все относящиеся к этому инциденту данные, которые будут использоваться в процессе анализа и на последующих этапах. Сбор данных производится на этапе расследования. Целью этого этапа, помимо сбора данных, является выяснение причин инцидента и максимально быстрое восстановление штатного функционирование систем и процессов. Руководство должно решить, будут ли для проведения расследования привлекаться сотрудники правоохранительных органов, будут ли доказательства собираться с целью судебного преследования, или достаточно будет просто закрыть соответствующую уязвимость. В штате большинства компаний нет команды экспертов по компьютерной криминалистике (forensics team), которые могли бы выполнить задачи по расследованию. Поэтому в случае подозрения о совершении преступления, если руководство компании не хочет обращаться к правоохранительным органам для проведения расследования, следует обратиться к внешним экспертам.
Мы более подробно рассмотрим вопросы проведения компьютерной криминалистической экспертизы в следующем разделе. Сейчас важно знать, что при расследовании необходимо соблюдать как требования политики компании, так и требования применимого законодательства.
ПРИМЕЧАНИЕ. Не путайте реагирование на инциденты (incident response) с компьютерной криминалистической экспертизой (computer forensics). Хотя оба они по сути являются расследованием, эти термины не являются синонимами. Компьютерная криминалистическая экспертиза имеет более высокий критерий доказанности (standard of proof) по сравнению с реагированием на инцидент. Компьютерная криминалистическая экспертиза проводится, когда требуются приемлемые для суда доказательства, в рамках экспертизы доказательства обрабатываются соответствующим образом.После сбора всех относящихся к инциденту данных, нужно выяснить, что же произошло на самом деле, сложив вместе все имеющиеся части. Это является этапом анализа, на котором собираются дополнительные данные (журналы аудита, записи системы видеонаблюдения, отчеты о действиях людей, журналы работы систем), необходимые для выяснения, как произошел этот инцидент. Целью этого этапа является выяснение, кто это сделал, как он это сделал, когда он это сделал и почему. Руководство должно постоянно быть в курсе выполняемых мероприятий, поскольку именно ему нужно будет принимать важные решения о том, что теперь делать со всей этой неразберихой.
Члены команды, которые участвуют в проведении анализа, должны обладать различными навыками. Они также должны хорошо разбираться в системах, пострадавших в результате инцидента, уязвимостях систем и приложений, настройках сети и систем. Хотя образование имеет большое значение, ключевое значение для этих людей имеет практический опыт в сочетании со специализированным обучением. Одной из самых больших сложностей, с которыми сталкиваются такие специалисты, является динамичный характер журналов регистрации событий. Большинство интернет-провайдеров чистят или перезаписывают свои журналы регистрации событий через короткий промежуток времени, а время может быть потеряно момент инцидента. Может пройти не один час, прежде чем инцидент будет обнаружен. В некоторых странах существуют законы, обязывающие обеспечивать сохранность журналов регистрации событий в течение длительного времени. Однако такие законы создают сложности при хранении этих журналов (их объем может быть очень большим), а также ставят под угрозу неприкосновенность частной жизни.
После того как была собрана вся доступная информация и получены ответы на все вопросы, мы переходим к этапу отслеживания (tracking) (отслеживание может проводиться параллельно с анализом). Нужно определить, был ли источник этого инцидента внутренним или внешним, как злоумышленник смог проникнуть и получить доступ к активам. Если злоумышленник был внешним, команде следует связаться со своим интернет-провайдером, чтобы он оказал помощь в сборе данных и выявлении источника атаки. Часто это оказывается очень сложной задачей, поскольку нападающие перемещаются от одной системы к другой, что может потребовать обращаться за помощью сразу к нескольким провайдерам. В связи с этим, очень важно, чтобы у членов команды, выполняющих задачи по анализу и отслеживанию, были хорошие рабочие отношения с третьими сторонами, такими как интернет-провайдеры, другие команды реагирования, правоохранительные органы.
ПРИМЕЧАНИЕ. Все эти данные должны надлежащим образом документироваться и обрабатываться, чтобы они могли быть в дальнейшем использованы в качестве доказательств в суде.После того, как нам удалось понять этот инцидент, мы переходим к этапу восстановления (recovery) (или последующего контроля (follow-up)), на котором мы проводим исправления, необходимые для того, чтобы подобные инциденты не повторялись. Для этого может потребоваться заблокировать определенные порты, отключить уязвимые службы или функции, переключить работу на другую площадку или установить патч. Более правильно называть это «процедурами последовательного восстановления» (following recovery procedures), поскольку беспорядочное внесение изменений в среду, может привести к дополнительным проблемам. В состав процедуры восстановления может входить восстановление системы с образа, восстановление данных с резервной копии, тестирование системы, выполнение правильных настроек.
Независимо от специфики процедур восстановления, перед тем, как поврежденная система будет возвращена в работу, вы должны сначала обеспечить, что она сможет противостоять другой такой атаке. Иначе хакеры быстро заметят, что уязвимая система снова вернулась в работу. Специально подготовленные сотрудники подразделения информационной безопасности должны предварительно провести проверку системы на наличие уязвимостей. Инструменты для тестирования уязвимостей, имитирующие выполнение реальной атаки, могут помочь повысить безопасность системы и защитить ее от различных атак, включая ту в результате которой она ранее была повреждена.
ПРИМЕЧАНИЕ. Никогда не следует доверять атакованной или зараженной системе, поскольку вы не знаете, какие на ней произошли изменения, и истинные масштабы повреждений. Некоторые вредоносные программы могут скрыто оставаться в системе. Система должны быть полностью восстановлена «с нуля», чтобы исключить все потенциальные угрозы.
Чему мы можем научиться в результате инцидента? Закрытие инцидента определяется характером или категорией этого инцидента, ожидаемых результатов реагирования на инцидент (например, возобновление работы бизнеса или восстановление системы), успех команды заключается в выяснении источника инцидента и основных причин его возникновения. Когда это определено и инцидент закрывается, целесообразно провести совещание команды с привлечением всех групп, подвергшихся влиянию инцидента, для ответа на следующие вопросы:
- Что произошло?
- Чему мы научились?
- Что мы сможем улучшить в следующий раз?
Команда должна еще раз взглянуть на этот инцидент и процесс его обработки, чтобы провести итоговый анализ. Информация по результатам этого совещания покажет, что нужно усовершенствовать в процессе реагирования на инциденты и какие изменения нужно внести в документы. Введение такого совещания в качестве одной из обязательных процедур процесса реагирования на инциденты, позволит команде собирать данные, которые в дальнейшем могут быть использованы в качестве метрик эффективности.
Вызывать ли полицию? Руководству необходимо принять решение, нужно ли привлекать правоохранительные органы для обработки инцидента, связанного с нарушением безопасности. Ниже перечислены вещи, которые нужно учитывать при принятии решения о привлечении правоохранительных органов:
Нужно учесть и другие вопросы при разработке компанией процедур реагирования на инциденты, в том числе продумать, как инцидент будет объясняться средствам массовой информации, клиентам и акционерам. Для этого может потребоваться участие подразделения по связям с общественностью, кадровой службы (если в этом участвует персонал), департамента ИТ и юридического департамента. Компьютерные преступления могут иметь правовые последствия, которые не сразу заметны и к которым нужно подходить с осторожностью. Компания должна решить, как она будет доводить эту информацию до внешних лиц, чтобы они не восприняли ситуацию в совершенно ином свете.
- Компания теряет контроль над расследованием, им занимаются только правоохранительные органы
- Сохранение секретности не гарантируется, информация может стать достоянием широкой общественности
- Нужно учесть возможное влияние на репутацию (реакция на эту информацию клиентов, акционеров и т.д.).
- Сотрудники правоохранительных органов заберут все, что будет составлять доказательную базу. Все это будет недоступно компании в течение продолжительного времени (расследование может занять не один год, прежде чем дело дойдет до суда).
Ссылки по теме:
Комментариев нет:
Отправить комментарий