ПЕРВОНАЧАЛЬНАЯ РЕАКЦИЯ
В этот момент уже сформирована команда реагирования на инцидент, которой сообщили о предполагаемом инциденте. Команда реагирования должна проверить сопутствующие факты и детали данного события. Факты об инциденте являются ключевой информацией для выбора командой реагирования ответной реакции и методов восстановления после инцидента.
Команда реагирования обязана проверить сам факт инцидента, выявить системы, на который прямо или косвенно влияет инцидент, и оценить потенциальное влияние инцидента на бизнес компании. Команда реагирования должна проверить достаточное количество показаний об инциденте, чтобы предпринять соответствующие ответные действия. Возможно, потребуется начать мониторинг сети только для того, чтобы подтвердить сам факт инцидента. Возникает вопрос: "Сколько потребуется данных, чтобы сформулировать общую стратегию реакции на инцидент?". Ответ на этот вопрос зависит от многих факторов.
В конце фазы первоначальной реакции надо знать, произошел ли реально инцидент, на какие системы он повлиял, каков его тип и влияние на бизнес компании. На основе этой информации можно принять правильное решение о реакции на инцидент.
ФОРМИРОВАНИЕ СТРАТЕГИИ РЕАКЦИИ НА ИНЦИДЕНТ
Необходимо выбрать оптимальные методы реакции на инцидент. Такая стратегия должна учитывать технические и организационные аспекты, и в обязательном порядке должна быть утверждена руководством компании. Выбранная стратегия реакции на инцидент непосредственно влияет на сотрудников, акционеров и клиентов компании
Выбор стратегии
Выбранная стратегия реакции на инцидент зависит от особенности атаки на систему, а также от характеристик пострадавшей компании. При выборе стратегии необходимо оценить следующие аспекты: сколько ресурсов потребуется для реакции на инцидент, где создавать дублирующие данные для судебных органов. Кроме того, надо знать:
• Насколько критическими были воздействия на системы
• Важность измененной или украденной информации
• Возможный виновник инцидента
• Стали ли сведения об инциденте достоянием общественности
• Уровень доступа, полученный атакующим
• Предполагаемая квалификация атакующего
• Приемлемые времена выключения системы или отключения от нее пользователей
• Общий ущерб от инцидента в денежном выражении
Инциденты бывают разными, от проникновения вирусов до кражи информации о кредитных карточках клиентов. Типичный вирус обычно приводит к некоторому простою и прекращению обслуживания, но кража данных о кредитных карточках может привести к краху компанию, занимающуюся электронной коммерцией. Соответственно, различаются и стратегии реакции на инциденты. Реакцией на проникновение вируса станет обычное восстановление нормальной работы, но реакция на похищение данных о кредитных карточках подобна реакции на пожар или наводнение — этот инцидент приведет к участию в реакции подразделения по связям с общественностью, главы компании и привлечению всех доступных технических ресурсов.
Подробности об инциденте, полученные на фазе первоначальной реакции, станут основой при выборе стратегии окончательного устранения инцидента. Например, атака отказа в обслуживании из университетской сети потребует совсем иной стратегии, чем такая же атака, инициированная конкурирующей компанией. Перед выбором стратегии реакции на инцидент требуется еще раз проанализировать все имеющиеся данные об этом событии.
Кроме того, следует учитывать факторы, не связанные с самим инцидентом. По большей части, к таким факторам относятся имеющиеся в компании финансовые и технические ресурсы, политические соображения, действующее законодательство и состояние бизнеса.
Вы получили некоторые сведения об атаке и доступных ресурсах для устранения ее последствий, теперь надо выбрать наиболее эффективную стратегию реакции на инцидент.
Предоставление руководству нескольких стратегий реакции на инцидент
Как отмечалось выше, при выборе стратегии реакции на инцидент учитываются бизнес-цели компании. Стратегия должна быть утверждена на уровне высшего административного руководства. Следовательно, в описании стратегии можно не прибегать к специальной технической терминологии, но точно отразить все "за" и "против" для каждого из предложенных вариантов стратегии, включая следующие показатели:
• Время отключения сети
• Время отключения пользователей
• Обязательства компании по законодательным нормам
• Общественное мнение
• Наличие кражи интеллектуальной собственности
СУДЕБНОЕ ДУБЛИРОВАНИЕ
Инцидент является основанием для выполнения судебного дублирования (резервного копирования для предоставления данных в органы правопорядка) поврежденных систем. Такое дублирование предполагает использование специализированного программного обеспечения, позволяющего сформировать "наилучшее копирование" материалов события. Обычно такое дублирование проводится для инцидентов, нанесших существенный ущерб, и является основанием для уголовного преследования злоумышленников.
Однако американские корпорации и судебные органы имеют разные взгляды на судебное дублирование. Органы правопорядка обычно предпочитают точное побитовое копирование систем (как систем-жертв, так и систем, использованных атакующими), либо просто проводят полное изъятие всей документации. Но частные компании предпочитают иной метод судебного дублирования, поскольку полное копирование (и последующее исследование) всех дисков и документации занимает слишком много времени.
Альтернативой судебному дублированию может стать некий отчет о реакции на инцидент. Если известно местоположение файлов и, кто, когда, где и как использовал их во время инцидента, то возможно выборочное предоставление в судебные органы только относящихся к делу данных. Если собраны только определенные и относящиеся к инциденту файлы и не проводится полное судебное дублирование, необходимо позаботиться о сохранении исходного состояния этих файлов, чтобы никто, случайно или с умыслом, не смог модифицировать информацию, предоставляемую органам правопорядка. Именно в этом поможет программное обеспечение для шифрования и отслеживания версий.
НАГЛЯДНЫЙ ПРИМЕР
Хотя выбор стратегии для реакции на инцидент кажется интуитивно понятным процессом и даже тривиальным, окончательное решение становится неким "Рубиконом" для компании. Как и любое важное решение, очень трудно сформулировать причины выбора определенной стратегии.
ВНИМАНИЕ Отличия исследования судебного дубля системы от отчета об инциденте похожи на отличия в работе врачей "скорой помощи" и патологоанатомов. Людям уже не нужно торопиться и можно расслабиться, когда приходится иметь дело с судебным дублем, а не с работающей системой.
Важность исследования фактов
Многие компании, расследующие инциденты, не вполне осознают уровень тщательности сбора фактов об инциденте. Однако фаза судебного дублировании требует повышенного внимания, поскольку возникает сомнение в необхо ДИКОСТИ копирования данных по юридическим или административным при чипам. Даже специалисты из государственных учреждений делают больше всего ошибок и погрешностей во время выполнения судебного дублирования, чем на остальных фазах расследования. Без подготовки к сбору необходимых данных и материалов об инциденте) компании могут сделать весьма серьезные ошибки на последующих фазах. Надеемся, что книга поможет избежать любых ошибок и недоразумений при выполнении судебного дублирования.
ИССЛЕДОВАНИЕ
На фазе исследования инцидента нужно определить, кто, как, когда, где и зачем проводил действия, приведшие к инциденту. Исследование можно проводить по результатам судебного дублирования, изучения работающей системы или по отчетам из сетевого монитора. Вне зависимости от способа выполнения исследования вы реагируете на инцидент, спровоцированный людьми.
Виновник инцидента преследует цели разрушения, кражи, доступа, сокрытия или атаки по отношению к некоторому информационному ресурсу. Поэтому на фазе исследования нужно ответить на вопрос, какие ресурсы подверглись воздействию людей. Однако не все компьютерные преступления попадают под действие такой упрощенной формулировки. Идентификация человека в сеги весьма сложная задача. Злоумышленники в киберпространстве используют различные способы для сокрытия своего истинного лица. Однако обнаружение человека, исказившего Web-сайт, может быть такой сложной задачей, что компания просто откажется от ее выполнения.
Поскольку идентификация нарушителя редко связана с искаженным или разрушенным ресурсом, многие компании полностью сосредоточивают все усилия только на подвергшихся нападению ресурсах и способах их восстановления. Сбор информации о таких ресурсах становится главной целью фазы исследования Следовательно, главной целью фазы исследования инцидента (как это будет показано в третьей части нашей книги) становится использование специальных методов расследования инцидентов, связанных с различными системами и приложениями.
РЕАЛИЗАЦИЯ МЕР БЕЗОПАСНОСТИ
Целью фазы реализации мер безопасности является проведение мероприятий, предотвращающих опасность будущих инцидентов. Другими словами, нужно устранить проблему. Изоляция и ограничения необходимы для реального восстановления или повторного построения системы. Если система не защищена от атак в будущем, то нельзя гарантировать "чистоту" восстановления.
Ниже будут рассматриваться стратегии реагирования на инциденты разного типа и предполагаемые разрушения системы. Возможность применения стратегии восстановления тоже зависит от доступных времени и ресурсов, включая людские ресурсы, оборудование и программное обеспечение.
Если собраны факты о возможных административных, уголовных и гражданских действиях, следует провести анализ этих данных еще до начала внедрения мер безопасности. Если быстро обезопасить систему (например, за счет изменения сетевой топологии, внедрения фильтрации пакетов или установки на хосте нового программного обеспечения), но не провести в необходимом объеме анализ и документирование инцидента, то теряются ниточки к источнику и причинам инцидента, столь необходимые при его расследовании. Самым важным правилом является сохранение состояния системы на момент инцидента!
На фазе изоляции и ограничения важно предотвратить дальнейшие действия атакующих. Перед началом восстановления системы следует проверить, что злоумышленники уже не смогут получить доступ к ранее скомпрометированной системе, сети или информационному ресурсу. Для этого существуют разнообразные программные инструменты и технологии.
Для изоляции и ограничения инцидентов, подобных вторжению в компьютер, можно просто отключить от сети скомпрометированный компьютер. Во многих случаях это позволяет предотвратить дальнейшие удаленные атаки. Однако не всегда этого бывает достаточно. Есть ли еще компьютеры-жертвы? Насколько важен компьютер для сетевых и бизнес-операций? Что делать, если необходимо продолжить мониторинг действия хакеров, чтобы собрать факты для уголовного дела?
Еще одним способом является электронная изоляция компьютера. Удалите из данного домена широковещательных рассылок другие компьютеры, чтобы ограничить доступ к другим системам компании. Злоумышленник не сможет провести сетевую атаку, не имея возможности перехватить имена пользователей, пароли и другие важные данные.
Внедрение сетевой фильтрации тоже обеспечивает хорошую электронную изоляцию. Такие фильтры позволяют продолжить мониторинг незаконных действий, но вместе с тем ограничить вторжение. Иногда этот метод называется "круглым аквариумом" (fishbowling), поскольку позволяет как бы под увеличительным стеклом рассматривать действия хакера, не разрешая ему выйти за пределы "стеклянной сферы". Кроме того, сетевая фильтрация помогает продолжить бизнес-операции, но запретить доступ хакерам за счет фильтрации пакетов по исходным адресам или характеру трафика. Можно фильтровать трафик к или из IP-адреса компьютера-жертвы на основе протокола, порта характеристик другой сети или транспортного уровня.
"Круглый аквариум" для поимки злоумышленников
Термин "круглый аквариум" используется сотрудниками правоохранительных органов для описания метода изоляции и ограничения действий хакеров. Целью этого метода является создание в сети области, которая на первый взгляд ничем не отличается от остальных сетевых областей, но находится под наблюдением сотрудников службы компьютерной безопасности или органов правопорядка. Для организации такой области необходимо совместное использование нескольких специальных технологий, поскольку требуется изолировать скомпрометированный компьютер (физически или электронным способом) за счет изменения сетевой топологии или таблицы маршрутизации. В такую область может быть специально помещен еще один компьютер, чтобы моделировать обычные сетевые операции.
СЕТЕВОЙ МОНИТОРИНГ
Сетевой мониторинг необходим для проведения расследования и восстановления. Для большей части инцидентов мониторинг должен начинаться на фазе первоначальной реакции и проводиться до полного завершения восстановления. Мониторинг преследует две цели:
• Позволяет отлеживать действия атакующего для сбора дополнительных фактов
• Гарантирует отсутствие повторения уже произошедшего инцидента
НАГЛЯДНЫЙ ПРИМЕР
Во время расследования одного из инцидентов было обнаружено, что взломана система Linux, установленная с параметрами по умолчанию. Были проведены почти все фазы расследования: исследование инцидента, сетевой мониторинг и т.д., но забыли изолировать устройство перед восстановлением системы с дистрибутива на компакт-диске — поэтому исследуемая система была постоянно подключена к сети! После восстановления системы с дистрибутива мы отправились спать, но не заблокировали систему. Каково же было наше удивление на следующее утро, когда было обнаружено, что журнал сетевого мониторинга опять показал вторжение в только что установленную систему!
Где и как проводить мониторинг
Лучше начать с мониторинга той подсети, где находится целевая система. Другая область потенциального проведения мониторинга включает в себя всю сеть или сеть интранет. Мониторинг в этих областях предполагает выявление незаконных действий, исходящих из внутренней или внешней сети. Все области мониторинга можно легко определить по топологической карте сети, разработанной на этапе подготовки к инциденту.
Во время расследования может потребоваться подключение к взломанному хакерами компьютеру или компьютеру, являющемуся источником атаки. В любом случае необходим доступ к участвовавшим в инциденте системам. Во время прослушивания целевыми системами считаются все компьютеры, которые анализируются в процессе расследования инцидента.
Мониторинг можно проводить разными методами. Полноценному мониторингу должна быть подвергнута вся подсеть целевой системы. Обычно переносной компьютер настраивается на режим перехвата пакетов, во время которого отбираются пакеты с атрибутами, наиболее подходящими для расследования данного инцидента. Менее полный мониторинг проводится в пределах всей сети. Можно рекомендовать регистрацию работы маршрутизаторов для выявления пакетов определенного типа, которые поступают или отправляются из клиентской сети.
Выбор информации для мониторинга
На фазе исследования должна быть получена информация для ограничения рамок мониторинга. Хотя возможен полномасштабный мониторинг всех сетевых операций, обычно существуют ограничения, связанные со свободным местом па дисках и сетевой полосой пропускания. В этом случае можно регистрировать только входящий и исходящий трафик системы жертвы. Трафик из взломанного атакующим компьютера тоже необходимо отслеживать, поскольку многие хакеры оставляют черные ходы для создания подключений к взломанным сис темам.
Если известны IP-адреса потенциальных источников атаки, необходим мониторинг трафика таких компьютеров. Если источник атаки находится в Интернете, может потребоваться мониторинг в рамках этой глобальной сети, а не только в подсети компьютера-жертвы. Мониторинг в Интернете позволит выявить все действия в подозреваемых IP-адресах источника любого хоста данной глобальной сети.
Необходимо проводить мониторинг уникальных характеристик атаки. Например, если атакующий пользовался троянцем Netbus, который слушает порт 12345, то необходимо провести мониторинг всего трафика на этом порту. Если же атакующий пользовался определенной комбинацией имени и пароля для доступа к системе, то следует провести мониторинг всего трафика, содержащего такую комбинацию. Точное следование типу инцидента во время мониторинга часто позволяет выявить сопутствующие атаки и незаконные действия.
ВОССТАНОВЛЕНИЕ
Целью фазы восстановления является воссоздание безопасного и рабочего состояния поврежденной системы. Это особенно важно для инцидентов с неавторизованным доступом, например вторжения в компьютерные системы. Однако обычной является ситуация, когда уволившиеся из компании сотрудники оставляют для себя черные ходы в систему, сохраняют имена входа или продолжают иметь иные пути доступа к компьютерным системам. Время на выполнение фазы восстановления зависит от особенностей конкретного инцидента и выбранной стратегии восстановления. В общем случае восстановление проводится только после завершения процесса сбора фактов об инциденте и изоляции компьютера от атак в будущем.
Выявление того, что было скомпрометировано
Перед восстановлением системы следует оценить уровень компрометации, а также тип и местоположение скомпрометированной системы. На фазе исследования необходимо определить не только уровень компрометации, но и идентифицировать возможные действия атакующего внутри системы.
Тип и местоположение скомпрометированной системы определяют реакцию, выполняемую в ответ на атаку. Если система находится в подсети вместе с другими хостами, придется исследовать все системы в подсети, поскольку внутренний трафик, скорее всего, был перехвачен атакующим, что может привести к компрометации остальных хостов в подсети. Если же скомпрометированная система является передним оконечным Web-сервером с жестко кодированным паролем доступа к задней оконечной базе данных, то на этапе исследования во время восстановления придется изучить и базу данных.
Пример инцидента
Атакующий использовал анонимный каталог FTP для загрузки и распространения пиратского программного обеспечения (ПО). Атакующий не имел привилегированного доступа к системе и никогда не исполнял на ней никаких программ. В этом случае восстановление выполняется просто — необходимо изменить пароль или права на доступ к серверу FTP, чтобы анонимные каталоги FTP не имели одновременно прав на запись и чтение.
Если система принадлежит большой области с взаимными доверительными отношениями (например, домену Windows NT), атакующий скорее всего взломает пароль для учетной записи, действующей в пределах всей такой области. В этом случае необходимо провести исследование и восстановление не только скомпрометированной системы, но и всех компьютеров, па которые действуют подозрительные учетные записи. Рекомендуем изменить пароль, действующий в пределах всей сети, особенно когда скомпрометированы реквизиты администрирования.
ВЫБОР СТРАТЕГИИ ВОССТАНОВЛЕНИЯ
Как отмечено выше, процесс восстановления сильно зависит от выбранной стратегии восстановления. В общем случае наиболее безопасным способом восстановления является переустановка системы с дистрибутивного компакт диска. Если атакующий загружал и исполнял на скомпрометированной системе неизвестный и опасный код, необходимо восстановление из последней успешной конфигурации, записанной в архивном носителе (так называемой "known good" конфигурации). После переустановки следует настроить систему для обеспечения ее безопасности, причем провести эту настройку еще до перевода системы в рабочее или интерактивное состояние. Безопасность системы (или усиление ее безопасности) предполагает отключение всех неиспользуемых служб, применение файлов обновления (patches) к операционной системе и приложениям, усиление паролей и проведение иных административных мероприятий для защиты от инцидентов в будущем. О безопасности операционных систем и ПО существует огромное количество интерактивных ресурсов и книг.
Во время восстановления можно использовать резервные копии системы, но только в том случае, если известно, что инцидент произошел уже после создания архивной копии. Иначе можно восстановить не только систему, но и созданные в ней черные ходы, которые успешно были записаны в архивной копии после проведения атаки. Кроме того, восстановление из резервной копии приведет к воссозданию старых паролей, имен входа и уязвимостей скомпрометированной системы. Проверьте, что ничто из перечисленного выше не будет воссоздано после возвращения системы в рабочее состояние.
После восстановления потребуется применить новые методы безопасности. Скорее всего, список дополнительных мер безопасности будет достаточно длинным. Для предотвращения инцидентов в будущем можно использовать средства контроля на уровне хостов, фильтры пакетов, брандмауэры, системы выявления вторжений (IDS), обучение пользователей и новые политики безопасности. Особенности произошедшего инцидента помогут выбрать наиболее эффективные методы дополнительного усиления безопасности. Многие методы безопасности нацелены на будущее, поэтому должны быть хорошо документированы во время их применения на фазе восстановления системы после инцидента.
Пример инцидента
Атакующий получил в системе UNIX права административного доступа за счет использования уязвимости в службе RPC (Remote Procedure Call, вызов удаленной процедуры). Система выявления вторжений IDS зарегистрировала в своем журнале, что атакующий использовал протокол FTP для пересылки файла из Интернета в скомпрометированную систему. Атакующий выполнил, а затем удалил подобный файл. В этом случае нужно оценить потенциальные возможности хакера. Уже нельзя точно определить, что было сделано после загрузки незаконного файла, поэтому следует исходить из наихудших предположений. Т.е. вы допускаете, что атакующий получил доступ к загружаемым модулям ядра системы, что очень трудно подтвердить или опровергнуть, поскольку черный ход может быть создан не на уровне файловой системы, а на уровне ядра. Уровень компрометации будет таков, что придется полностью переустанавливать систему с дистрибутивного компакт-диска и нельзя обойтись только изменениями паролей доступа к системе.
ОТЧЕТ
Целью фазы отчета является создание набора документов об инциденте (причем, чем больше будет описание инцидента, тем лучше). Естественно, это нелегкая работа, поэтому документирование инцидента следует начинать не в конце всего процесса, а с самого начала реакции на инцидент. В описании нужно отразить все фазы и операции реакции на инцидент. Если обнаружится, что нужно описать операции, проведенные три дня назад, то иногда лучше заново провести эти действия, чтобы точно отразить их в отчете.
Инциденты сопровождаются паникой и необоснованными действиями, но будет большой ошибкой отсутствие в отчете сведений о действиях, которые впоследствии оказались неадекватными. Реакция на инцидент — это скучный и педантичный процесс, который необходимо точно описать в отчете. Технические ошибки в сочетании с неясным отчетом не позволят эффективно предотвращать будущие инциденты. Ошибки в документации об инциденте могут привести к неправильным выводам и неадекватным защитным действиям.
Отчет об инциденте может стать основой для увольнения сотрудника или ареста хакера. Этот отчет возможно попадет судье, адвокатам или сотрудникам полиции. Однако любой человек знает, как трудно вспомнить факты о событиях, произошедших несколько дней или недель назад. А если придется описывать события, произошедшие несколько лет тому назад? Расследование многих компьютерных преступлений тянется годами, поэтому лучше сразу подробно и точно изложить все факты об административном, должностном или уголовном нарушении.
Фаза создания отчета предполагает действия, завершающие расследование инцидента и помогающие предотвратить инциденты в будущем. Среди них:
• Участие в административном или уголовном расследовании. Возможно, люди, участвовавшие в расследовании инцидента, будут привлечены как свидетели для дачи показаний во время уголовного, административного или должностного следствия. В этом им помогут отчеты и заметки, созданные во время расследования инцидента.
• Формирование окончательного заключения об инциденте. Собранная документация поможет сформировать взвешенный и обоснованный заключительный отчет об инциденте. В нем необходимо отразить особенности инцидента, предпринятые ответные действия, возможные причины инцидента и предложить рекомендации по устранению подобных инцидентов в будущем.
• Рекомендации по улучшению скомпрометированных инцидентом процессов. Любой инцидент является для нас хорошим уроком. Всё необходимо проработать со всеми членами команды реагирования на инциденты.
