В окно выглядывать – покой, мир, безопасная ситуация.В него вылезать или из...
Обучение руководителей и специалистов правовым, организационным и практическим вопросам расследования компьютерных инцидентов.
Прослушайте бесплатный вебинар про этот курс. Вебинар доступен в записи в любое удобное время.
Для просмотра перейдите по ссылке и запустите кнопку Play в левом нижнем углу.
http://m.mirapolis.ru/m/miravr/0074524156
В курсе подробно разбираются все аспекты деятельности уполномоченных органов (подразделений, лиц) организации при реагировании на инциденты в информационной системе.
Слушатели изучают и анализируют факторы и предпосылки, приводящие к компьютерным инцидентам, и представляющие наибольшую опасность для информационных систем организации. На конкретных примерах разбираются основные способы обеспечения непрерывности функционирования информационной системы в случае возникновения КИ и скорейшего устранения их последствий, рассматриваются основные аспекты технической политики организации, направленные на минимизацию, нанесенного КИ ущерба.
Подробно изучается весь комплекс юридических, технических и организационных мероприятий, проводимых немедленно после выявления КИ. В ходе практической работы слушателям предлагается самостоятельно разработать ряд организационно-распорядительных документов и выстроить оптимальную последовательность действий в ходе решения ситуационных задач, провести полный цикл расследования с составлением необходимых документов.
Рассматриваются современные технологии и средства, применяемые для расследования КИ. В ходе практических занятий слушатели знакомятся с рядом инструментальных средств (продуктов).
Особое внимание уделяется юридическим основам расследования КИ, обсуждению проблемы доказательной значимости материалов, полученных в ходе расследования КИ, вопросам взаимодействия с правоохранительными органами, специализированными организациями и судами. Слушатели знакомятся с различиями в юридической практике РФ и других государств, а также связанной с ними сложностью применения западных методик расследования КИ в России.
Практические занятия проводятся с использованием технологии виртуальных машин на специально сконфигурированных стендах.
После изучения курса слушатель будет
Знать:
Формирование знаний и навыков, необходимых для организации и проведения внутренних (внутрикорпоративных) расследований компьютерных инцидентов.
1. Правовая и нормативно-методическая база расследования компьютерных инцидентов
1.1. В настоящем Порядке используются следующие термины и определения:
Событие информационной безопасности (information security event ): Идентифицированное появление определенного состояния системы, сервиса или сети, указывающего на возможное нарушение политики информационной безопасности или отказ защитных мер, или возникновение неизвестной ранее ситуации, которая может иметь отношение к безопасности.
Инцидент информационной безопасности (information security incident ): Появление одного или нескольких нежелательных, или неожиданных событий информационной безопасности, с которыми связана значительная вероятность компрометации бизнес-операций и создания угрозы информационной безопасности.
1.2. Обработка инцидента информационной безопасности включает следующие этапы:
2.1. Примеры инцидентов информационной безопасности и их причины.
Инциденты информационной безопасности могут быть преднамеренными или случайными (например, являться следствием какой-либо человеческой ошибки или природных явлений ) и вызваны как техническими, так и не техническими средствами. Их последствиями могут быть такие события, как несанкционированные раскрытие или изменение информации, ее уничтожение или другие события, которые делают ее недоступной, а также нанесение ущерба активам организации или их хищение. Инциденты информационной безопасности, о которых не было сообщено, но которые были определены как инциденты, расследовать невозможно и защитных мер для предотвращения повторного появления этих инцидентов применить нельзя.
2.1.1 Отказ в обслуживании.
Отказ в обслуживании является обширной категорией инцидентов информационной безопасности, имеющих одну общую черту. Подобные инциденты информационной безопасности приводят к неспособности систем, сервисов или сетей продолжать функционирование с прежней производительностью, чаще всего при полном отказе в доступе авторизованным пользователям.
Существует два основных типа инцидентов информационной безопасности, связанных с отказом в обслуживании, создаваемых техническими средствами: уничтожение ресурсов и истощение ресурсов.
Некоторыми типичными примерами таких преднамеренных технических инцидентов информационной безопасности «отказ в обслуживании» являются:
Одни технические инциденты информационной безопасности «отказ в обслуживании» могут возникать случайно, например в результате ошибки в конфигурации, допущенной оператором, или из-за несовместимости прикладного программного обеспечения, а другие — преднамеренными. Одни технические инциденты информационной безопасности «отказ в обслуживании» инициируются намеренно с целью разрушения системы, сервиса и снижения производительности сети, тогда как другие — всего лишь побочными продуктами иной вредоносной деятельности. Например, некоторые наиболее распространенные методы скрытого сканирования и идентификации могут приводить к полному разрушению старых или ошибочно сконфигурированных систем или сервисов при их сканировании. Следует заметить, что многие преднамеренные технические инциденты типа «отказ в обслуживании» часто инициируются анонимно (то есть источник атаки неизвестен ), поскольку злоумышленник обычно не получает информации об атакуемой сети или системе.
Инциденты информационной безопасности «отказ в обслуживании» , создаваемые не техническими средствами и приводящие к утрате информации, сервиса и (или ) устройств обработки информации, могут вызываться, например, следующими факторами:
2.1.2. Сбор информации
В общих чертах инциденты информационной безопасности «сбор информации» подразумевают действия, связанные с определением потенциальных целей атаки и получением представления о сервисах, работающих на идентифицированных целях атаки. Подобные инциденты информационной безопасности предполагают проведение разведки с целью определения:
Типичными примерами атак, направленных на сбор информации техническими средствами, являются:
В некоторых случаях технический сбор информации расширяется и переходит в несанкционированный доступ, если, например, злоумышленник при поиске уязвимости пытается получить несанкционированный доступ. Обычно это осуществляется автоматизированными средствами взлома, которые не только производят поиск уязвимости, но и автоматически пытаются использовать уязвимые системы, сервисы и (или ) сети.
Инциденты, направленные на сбор информации, создаваемые не техническими средствами, приводят к:
Инциденты могут вызываться, например, следующими факторами:
2.1.3. Несанкционированный доступ
Несанкционированный доступ как тип инцидента включает в себя инциденты, не вошедшие в первые два типа. Главным образом этот тип инцидентов состоит из несанкционированных попыток доступа в систему или неправильного использования системы, сервиса или сети. Некоторые примеры несанкционированного доступа с помощью технических средств включают в себя:
Инциденты несанкционированного доступа, создаваемые не техническими средствами, которые приводят к прямому или косвенному раскрытию, или модификации информации, нарушениям учетности или неправильному использованию информационных систем, могут вызываться следующими факторами:
2.2. Ключевые процессы реагирования на инцидент информационной безопасности.
2.2.1. Обнаружение события информационной безопасности осуществляется любым работником, а также автоматически (например, срабатыванием модуля противодействия мошенничеству ).
В случае обнаружения события информационной безопасности работник обязан:
При автоматическом обнаружении события информационной безопасности начальник ОИБиЗИ:
2.2.2. Регистрация инцидента информационной безопасности.
При поступлении информации о событии информационной безопасности начальник ОИБиЗИ с привлечением специалистов департамента информационных технологий проводит анализ информации с целью ее отнесения к инциденту информационной безопасности и формирует отчет (Приложение № 1 к настоящему Порядку ).
Критериями отнесения события информационной безопасности к инциденту является нарушение следующих типов событий:
а) Физический уровень информационной инфраструктуры:
б) Уровень сетевого оборудования:
в) Уровень сетевых приложений и сервисов:
г) Уровень операционных систем:
д) Уровень технологических процессов и приложений и уровень бизнес-процессов:
В случае отнесения события информационной безопасности к инциденту информационной безопасности формируется отчет об инциденте информационной безопасности (Приложение № 2 к настоящему Порядку ).
Инциденты информационной безопасности классифицируются по следующим признакам:
Для устранения последствий и причин инцидента информационной безопасности в организации создается специальная группа, состоящая из следующих специалистов:
Все процессы устранения последствий и причин инцидентов, типизированных по признаку принадлежности нарушения какой-либо политики информационной безопасности, должны обязательно документироваться. Документирование сценариев реагирования на каждый возможный инцидент информационной безопасности проводится экспертным путем и оформляется в виде набора соответствующих регламентов и правил. Задачей Департамента Экономической Безопасности является сдерживание инцидента информационной безопасности, то есть принятия всех необходимых мер для локализации инцидента информационной безопасности и препятствующих его распространению. Сроки устранения последствий и причин инцидента зависят от уровня инцидента.
Ключевыми процессами устранения последствий и причин инцидентов являются:
Прекращение нападения и восстановление нормальной работы информационных систем требует скоординированных действий не только сотрудников организации, но и:
Заключительным этапом процесса устранения последствий и причин инцидентов является локализация ущерба, причиненного инцидентом информационной безопасности, который включает:
В процессе восстановления работоспособности информационных систем на некоторое время могут быть задействованы резервные (альтернативные ) аппаратные и программные платформы.
Кроме того, необходимым завершающим шагом может быть дополнительная информационная работа, которая включает:
Для проведения внутреннего расследования назначается должностное лицо (группа расследования ), имеющее навыки проведения подобных расследований.
4.1. Полная оценка ситуации
Данная оценка определяет текущее и потенциальное воздействие инцидента на бизнес организации, позволяет идентифицировать затронутую инфраструктуру и как можно полнее оценить ситуацию и быстрее определить соответствующее направление работы.
Для получения полной оценки ситуации:
Для проведения идентификации, анализа и документирования сетевой инфраструктуры и компьютеров, затронутых инцидентом, необходимо выполнить следующее:
Для исследования состояния приложений и операционных систем на компьютерах, которые затрагивает расследование, используются инструментальные средства (например, файлы журналов Windows, Windows Sysinternals PsTools и др. ).
4.2. Сбор доказательств
На стадии сбора доказательств нужно учесть, что если инцидент становится больше, чем просто внутреннее расследование и требует обращения в правоохранительные органы, то вполне возможно, что все процессы, используемые для сбора доказательств.
Доказательства должны содержать следующую информацию:
Сбор цифровых доказательств выполняется локально или по сети. Преимуществом локального сбора данных является большее управление компьютером и соответствующими данными. Однако локальный сбор данных не всегда возможен. В случае сбора данных по сети, необходимо учитывать тип собираемых данных и усилия, которые для этого потребуются.
В процесс сбора данных создается документация, которая позволит идентифицировать и подтвердить подлинность собранных доказательств включая следующую информацию:
При проведении расследования, как правило, используется комбинация автономных и интерактивных методов. При проведении автономных расследований дополнительный анализ выполняется на поразрядной копии оригинального доказательства. Поразрядная копия - законченная копия всех данных из целенаправленного источника, включая информацию загрузочного сектора, разделов и свободного дискового пространства. Автономный метод расследования применяется всегда, когда это возможно, так как это уменьшает риск повреждения оригинального доказательства. Данный метод может использоваться только в тех случаях, когда может быть создана соответствующая копия и не может быть использован для сбора некоторых энергозависимых данных.
4.3. Анализ данных
При анализе сетевых данных используется следующая процедура:
Анализ данных рабочих станций включают информацию о таких компонентах, как операционная система и установленные приложения.
Анализ носителей данных для определения их причастность (или непричастности ) к инциденту. При этом необходимо установить факт применения шифрования данных на основе ключей реестра, а также инструментальные средства восстановления файлов.
По результатам анализа данных готовится заключение, в котором устанавливаются причины инцидента для принятия превентивных мер, и лица, виновные в возникновении инцидента.
Выявление нарушителя - задача не всегда выполнимая, особенно при выявлении сложных и удаленных атак, но в случае внутренних нарушений это почти всегда удается. Работа по идентификации виновника (виновников ) зависит от множества факторов: полноты свидетельств, их непротиворечивости, сложности инцидента и т.д. Кроме того, свидетельства должны однозначно указывать на виновного и характеризовать наличие или отсутствие умысла. В случае, когда установить виновного удалось, можно выносить рекомендации о привлечении его к ответственности (в том числе обращаться в суд в роли истца - в целях компенсации нанесенного материального ущерба ).
После устранения последствий инцидента проводятся следующие мероприятия:
а) Организационные:
б) Технические:
Хранение отчетов о событии информационной безопасности и отчетов об инцидентах информационной безопасности осуществляется отделом информационной безопасности и защиты информации в течении пяти лет, после чего данные отчеты сдаются на архивное хранение.
информационной безопасности
Отчет о событии информационной безопасности
| Дата события | |||||||||
| Номер события*: | Соответствующие идентификационные номера событий и (или) инцидентов (если требуется): | ||||||||
| Информация о сообщающем лице | |||||||||
| Фамилия | Должность | ||||||||
| Подразделение | |||||||||
| Телефон | Электронная почта | ||||||||
Описание события информационной безопасности
Описание события:
Что произошло
Как произошло
Почему произошло
Пораженные компоненты
Негативное воздействие
Подробности о событии информационной безопасности
Дата и время наступления события
Дата и время обнаружения события
Дата и время сообщения о событии
___________________ ____________ _____________________
(должность) (подпись) (расшифровка подписи)
к Порядку обработки инцидентов
информационной безопасности
Отчет об инциденте информационной безопасности
_______________
* Номера инцидентов привязываются к номеру(ам) соответствующих событий.
Описание инцидента информационной безопасности
Дополнительное описание инцидента:
Что произошло
Как произошло
Почему произошло
Пораженные компоненты
Негативное воздействие на бизнес
Любые идентифицированные уязвимости
Подробности об инциденте информационной безопасности
Дата и время возникновения инцидента
Дата и время обнаружения инцидента
Дата и время сообщения об инциденте
Тип инцидента информационной безопасности
| (Сделать отметку в одном из квадратов, затем заполнить ниже соответствующие поля) | Действительный | | Попытка | | Предполагаемый | | |||||||
| (Один из) | Намеренная | | (указать типы угрозы) | ||||||||||
| Хищение (ТН) | | Хакерство/логическое проникновение | |||||||||||
| (НА) | | ||||||||||||
| Мошенничество (FR) | | Неправильное использование ресурсов | |||||||||||
| (MI) | | ||||||||||||
| Саботаж/физический ущерб (SA) | | Другой ущерб (OD) | | ||||||||||
| Вредоносная программа (MC) | | ||||||||||||
| Определитель: | |||||||||||||
| (Один из) | Случайная | | (указать типы угрозы) | ||||||||||
| Отказ аппаратуры (HF) | | Другие природные события (NE) | | ||||||||||
| Отказ ПО (SF) | | Определить: | |||||||||||
| Отказ системы связи (CF) | | потеря значимых сервисов (LE) | | ||||||||||
| Пожар (HE) | | недостаточное кадровое обеспечение (SS) | | ||||||||||
| Наводнение (FL) | | Другие случаи (ОА) | | ||||||||||
| Определить: | |||||||||||||
| (Один из) | Ошибка | | (указать типы угрозы) | ||||||||||
| Операционная ошибка (OE) | | Ошибка пользователя (UE) | | ||||||||||
| Ошибка в эксплуатации аппаратных средств (НЕ) | | Ошибка проектирования (DE) | | ||||||||||
| Ошибка в эксплуатации ПО (SE) | | Другие случаи (включая ненамеренные ошибки) (ОА) | | ||||||||||
| Определить: | |||||||||||||
| Неизвестно | | (Если еще не установлен тип инцидента ИБ (намеренный, случайный, ошибка), то следует сделать отметку в квадрате «неизвестно» и, по возможности, указать тип угрозы, используя сокращения, приведенные выше) | |||||||||||
| Определить: | |||||||||||||
Поражение активы
| Пораженные активы (при наличии) | (Дать описания активов, пораженных инцидентами ИБ или связанных с ним, включая (где требуются), серийные, лицензионные номера и номера версий) | ||
| Информация/данные | |||
| Аппаратные средства | |||
| Программное обеспечение | |||
| Средства связи | |||
| Документация | |||
Негативное воздействие/влияние инцидента на бизнес
Сделать отметку в соответствующих квадратах для указанных ниже нарушений, затем в колонке «значимость» указать степень негативного воздействия на бизнес по шкале 110, используя следующие сокращения (указатели категорий): (FD) — финансовые убытки/разрушение бизнес-операций, (СЕ) — коммерческие и экономические интересы, (PI) — информация, содержащая персональные данные, (LR) — правовые и нормативные обязательства (это необходимо сравнить с английским оригиналом), (МО) — менеджмент и бизнес-операции, (LG) — потеря престижа (см. примеры в приложении В). Записать кодовые буквы в колонке «указатели», а если известны действительные издержки, — указать их в колонке «стоимость».
| Значимость | Указатели | Издержки | ||
| Нарушение конфиденциальности (то есть несанкционированное раскрытие) | | |||
| Нарушение целостности (то есть несанкционированная модификация) | | |||
| Нарушение доступности (то есть недоступность) | | |||
| Нарушение неотказуемости | | |||
| Уничтожение | |
Общие расходы на восстановление после инцидента информационной безопасности
Разрешение инцидента
| Дата начала расследования инцидента ИБ | ||
| Фамилия(ии) лица (лиц), проводившего(их) расследование инцидента | ||
| Дата разрешения инцидента ИБ | ||
| Дата окончания воздействия | ||
| Дата завершения расследования инцидента ИБ | ||
| Место хранения отчета о расследовании |
Причастные к инциденту лица/нарушители
Описание нарушителя
Действительная или предполагаемая мотивация
| Определить: | ||
| Действия, используемые для разрешения инцидента информационной безопасности |
||
| (например, «никаких действий», подручными средствами", «внутреннее расследование», «внешнее расследование с привлечением…») | ||
| Действия, запланированные для разрешения инцидента | ||
| (включая возможные приведенные выше действия) | ||
| Прочие действия | ||
| (например, по-прежнему требуется проведение расследования, но другим персоналом) | ||
Заключение
| (Сделать отметку в одном из квадратов, является ли инцидент значительным или нет, и приложить краткое изложение обоснования этого заключения) | Значительный | | Незначительный | | |||||
| (Указать любые другие заключения) | |||||||||
| Оповещенные лица/субъекты | |||||||||
| (Эта часть отчета заполняется соответствующим лицом, на которое возложены обязанности в области ИБ и которое формулирует требуемые действия. Обычно этим лицом является руководитель ИБ организации) | Руководитель службы ИБ | | Руководитель Банка | | |||||
| Руководитель (уточнить, какого) подразделения | | Руководитель ДИТ | | ||||||
| Автор отчета | | Руководитель автора отчета | | ||||||
| Полиция | | Другие лица | | ||||||
| (например, справочная служба, отдел кадров, руководство, служба внутреннего аудита, регулятивный орган, сторонняя организация) | |||||||||
| Определить: | |||||||||
Привлеченные лица
| Инициатор | Аналитик | Аналитик | ||||||
| Подпись | Подпись | Подпись | ||||||
| Фамилия | Фамилия | Фамилия | ||||||
| Должность | Должность | Должность | ||||||
| Дата | Дата | Дата | ||||||
| Аналитик | Аналитик | Аналитик | ||||||
| Подпись | Подпись | Подпись | ||||||
Скачать ZIP файл (64961) Пригодились документы - поставь «лайк» или : | ||||||||
Каждые сутки обрабатываются полтора миллиона событий ИБ, поступающих от различных систем и устройств: IDS, IPS, межсетевых экранов, сканеров состояния защищённости, антивирусов, сетевых устройств. Автоматизированная обработка выявляет события, влияющие на безопасность, для последующего детального анализа. Аналитики компании вручную исследуют 180–200 событий. Каждое такое подозрительное событие является потенциальным инцидентом ИБ, с которым связана вероятность компрометации данных и нарушения конфиденциальности, целостности и доступности.
Инцидент - негативное событие с финансовыми, правовыми и репутационными последствиями для жертвы компьютерной атаки. Если организация хочет быть готовой противостоять злоумышленникам, она должна реагировать на каждый такой случай. И мы можем в этом помочь.
Наша работа по расследованию инцидентов состоит из 5 этапов.
Инцидент информационной безопасности может обнаружить дежурная смена Центра мониторинга. Или к нам может обратиться непосредственно владелец ресурса, если в его информационной системе есть подозрительная активность, при которой внедрённые ранее средства защиты информации «молчат». При этом у объекта атаки может быть недостаточно ресурсов или опыта для расследования инцидента.
Мы также можем определить, подвергалась ли организация атакам в прошлом и был ли какой-либо ущерб, проанализировав имеющиеся записи журналов различных систем.
Главная задача после обнаружения инцидента - не допустить компрометации данных и снизить влияние на бизнес-процессы. Для этого заказчик локализует атакованный узел и блокирует вредоносную активность.
Мы взаимодействуем с ведомственными и корпоративными центрами реагирования на кибератаки , чтобы получать информацию об угрозах и методах противодействия в реальном времени.
На этом этапе мы находим и документируем любые сведения, связанные с инцидентом, чтобы ответить на следующие вопросы:
После того, как мы соберём информацию об инциденте, заказчик расследования может запускать процессы восстановления после инцидентов ИБ. Если таких процессов нет, мы поможем восстановить работоспособность затронутых атакой информационных систем и ресурсов.
После анализа результатов расследования компьютерного инцидента мы даём рекомендации по изменению настройки и состава средств защиты информации, которые могут предотвратить повторение инцидента в будущем или закрывают наиболее критичный вектор атак.
В случае успешного взлома сервер может быть использован для рассылки спама,
распространения вареза, организации атак на другие хосты, кроме того, могут быть
украдены или уничтожены важные корпоративные данные. Конечно, своевременный
бэкап позволит восстановить все в первоначальное состояние, но не факт, что
через некоторое время инцидент не повторится вновь. Поэтому важно научиться
проводить компьютерные расследования и определять, что же в действительности
произошло.
Немедленное восстановление системы из резервных архивов для продолжения
нормальной работы сервера - это самая распространенная ошибка. Даже если
начальник грозно нависает над головой, а телефон ломится от звонков возмущенных
клиентов, следует на некоторое время остановить сервер, сохранить его состояние
на другой носитель, чтобы затем можно было спокойно произвести расследование
всех обстоятельств.
Зачем это нужно? Во-первых, чтобы ситуация не повторилась, ведь обновление
ПО, антивирусных баз и т.д. отнюдь не гарантирует того, что хакер не использует
свой способ для повторного проникновения. Во-вторых, нельзя четко сказать, когда
произошел взлом, поэтому, казалось бы, "нормальная" архивная копия уже может
содержать "черный ход". И, наконец, собранная инфа поможет узнать, был ли это
взлом вообще: может, это системная или человеческая ошибка, а может, происки
инсайдера.
Процесс расследования (digital/computer forensics
) хорошо описан в книге
Уоррена Круза (Warren G. Kruse II) и Джея Хэйзера (Jay G. Heiser) "Computer
Forensics: Incident Response Essentials", которая является своего рода библией
для тех, кто занимается подобными исследованиями. К сожалению, в русском
переводе ее нет, в интернете можно найти отдельные главы и выдержки из
оригинала. Само исследование состоит из 5 этапов - подготовка (исследователя),
оценка ситуации, сбор данных, анализ и отчет. Стандартные инструменты, входящие
в состав ОС, в большинстве случаев могут быть использованы лишь как
вспомогательные. Злоумышленник в первую очередь сделает все возможное, чтобы
скрыть от них свои следы (например, время последнего обращения к файлу очень
просто изменить, в итоге это может помешать исследованию, а полученный результат
нельзя будет использовать как доказательство). Первое время поиск следов
проводился на "выключенном компьютере", т.е. создавался образ и, используя
инструментарий, о котором пойдет речь далее, исследователь пытался найти следы
взлома. Такой метод получил название "Dead analysis
".
Сегодня ситуация несколько другая. Известно, что некоторые современные вирусы
не оставляют следов на жестком диске, яркий пример - червь "SQL slammer",
который работает только в ОЗУ, и засечь его можно лишь по сетевой активности
(порт 1434, UDP пакет ~400 байт). Еще один момент: в настоящее время повсеместно
внедряются криптографические средства защиты (например в Windows - BitLocker,
EFS), и без ключей, хранящихся в ОЗУ, получить доступ к защищенной информации
нет никакой возможности. Поэтому сегодня чаще используется анализ на рабочей
системе - "Live analysis
", когда собирается полная инфа о сетевой активности,
приложениях и процессах. Как ты понимаешь, единой процедуры, подходящей для всех
случаев, не существует, в каждой конкретной ситуации подход сугубо
индивидуальный.
В зависимости от ситуации состав приложений может меняться и подбирается
индивидуально. Нужно отметить, что в настоящее время существует совсем немного
специализированных программ проведения расследований. Из коммерческих продуктов
популярны ProDiscover от Technology Pathways ,
EnCase Forensic от Guidance Software
и The Forensic Toolkit .
Некоторые проекты предлагают демки ограниченных версий. Например, ProDiscover
Basic Edition Freeware, которая доступна для закачки на сайте Technology
Pathways, не имеет сетевых функций. Но, тем не менее, есть ряд продуктов,
распространяемых под Freeware-лицензией, возможностей которых вполне достаточно
для проведения полного анализа. Более того, существуют специализированные
дистрибутивы Linux, где все нужные утилиты уже собраны и настроены. Например,
DEFT Linux ,
FCCU GNU/Linux Forensic Boot CD ,
Helix3 и
другие.
Кстати, коммерческий вариант
Helix3
в своем роде уникальный дистрибутив, так как содержит утилиты для Linux, Windows
и Mac OS X.
Самой первой и поэтому известной утилитой, написанной для Unixсистем,
является TCT (The Coroner"s Toolkit). TCT разработан двумя авторами SATAN -
Dan Farmer и Wietse Venema - и представляет собой набор утилит, при помощи
которых можно произвести как Dead, так и Live анализ Unixсистемы. Некоторое
время проект практически не развивался, поэтому в специализированных
дистрибутивах его заменил
The Sleuth Kit
.
TSK разработан экспертом по безопасности Brian Carrier и основан на исходном
коде проектов TCT и TCTUtils. Сырцы серьезно переписаны, что позволяет собрать и
использовать утилиты в Linux, Mac OS X, Cygwin, FreeBSD, OpenBSD и Solaris. При
помощи TSK можно проанализировать данные, находящиеся на разделах NTFS, FAT,
Ext2, Ext3, UFS1 и UFS2, а также в образах, созданных командами dd и dd_rescue.
В состав включены 24 утилиты, большинство из них для удобства пользователя
разбиты на группы, и имя начинается с определенной буквы:
Попробуем найти удаленный файл. Для начала запустим утилиту fls, чтобы
получить имена файлов и каталогов, в том числе и удаленных. Утилита имеет
несколько дополнительных параметров, из них стоит отметить:
A - вывод имен файлов, начинающихся с точки (. и..), их очень любят
использовать взломщики для маскировки;
-d - вывод только удаленных файлов;
-u - вывод только не удаленных файлов;
-l - вывод подробной информации о файле;
-r - рекурсивный обход каталогов.
# fls -rd /dev/sda1
Первая буква показывает тип файла, т.е. r-egular, d-irectory, l-ink, s-ocket
или не определен (?). Знак "*" на второй позиции показывает, что файл не
распределен (удален). Теперь запросим больше информации о конкретном inode:
# ffind -a /dev/sda1 111
/windows/system32/cmd.exe
# istat /dev/sda1 111
inode: 111
Not Allocated
uid / gid: 0 / 0
mode: rwxr-xr-x
size: 0
num of links: 0
# fsstat /dev/sda1
Чтобы просмотреть данные, соответствующие inode, используем icat:
# icat /dev/sda1 1234 | less
Аналогично за вывод данных в конкретном блоке отвечает утилита blkcat. Для
примера просмотрим один блок и сохраним несколько блоков, принадлежащих файлу:
# blkcat -h /dev/sda1 111 | less
# blkcat 111-120 > output.blk
В сформированном образе адрес блока будет отличаться от исходного, поэтому
вручную найти его непросто. Но это и не требуется, чтобы упросить поиск, можно
воспользоваться специальным калькулятором - blkcalc. Еще одна полезная команда
"blkls /dev/sda1" позволит просмотреть содержимое блоков выбранного раздела
диска в удобочитаемом виде. По умолчанию выводятся только нераспределенные блоки
данных (соответствует ключу "-A"). Сохранив вывод blkls в файл, затем можно
использовать утилиты strings и grep для поиска нужных фрагментов.
# blkls sda1.dd > sda1.blkls
# strings -t d sda1.blkls > sda1.str
Теперь в sda1.str находятся все текстовые строки из образа/раздела вместе с
данными, указывающими на смещение относительно начала блока.
В Sleuth Kit v1.63 появилась утилита mmls. Примечательна она тем, что выводит
таблицу разделов и показывает, какие сектора не используются. Таким образом
можно увидеть "спрятанные" данные:
# mmls -t dos /dev/sda
Описание утилит можно продолжать долго, лучше один раз запустить и увидеть
результат. Но все, о чем говорилось, позволяет лишь собрать данные, а их анализ
целиком возлагается на плечи исследователя. Для того чтобы найти в нескольких
гигабайтах информации инструменты взломщика, потребуется немало времени и опыта.
Здесь на помощь приходит утилита hfind из комплекта TSK, которая умеет
рассчитывать хеш-функции файлов и сравнивать результат с заранее созданной
базой. База может формироваться как самостоятельно при помощи md5sum, так и на
основе библиотеки NSRL (National Software Reference Library )
. Проект NSRL
поддерживается рядом солидных организаций, среди которых - Национальный Институт
Американского Министерства юстиции (NIJ), Национальный Институт Стандартов и
Технологии (NIST) и так далее. В NSRL собраны в справочный информационный набор
RDS (Reference Data Set, полный комплект занимает 4 CD по 300 Мб каждый) профили
различного ПО - хеш-функции (MD5 и SHA-1), данные о файле (происхождение, имя,
размер и т.п.), что позволяет однозначно идентифицировать файл, даже если он был
переименован. Кстати, одной из основных задач этой библиотеки является поиск
программ при расследовании преступлений, направленных против интеллектуальной
собственности.
Утилита hfind проверяет значения хеш-функции в базе данных, используя
двоичный алгоритм поиска, поэтому она работает быстрее, чем штатный grep, но
вначале следует создать индексный файл (ключ "-i"):
# hfind -i nsrl-sha1 /usr/local/hash/nsrl/
NSRLFile.txt
Index Created
В результате в текущем каталоге появится NSRLFile.txtsha1.idx. Теперь можно
пробить любой файл по базе:
# md5sum /bin/ls
# hfind /usr/local/hash/nsrl/NSRLFile.txt f58
860f27dd2673111083670c9445099
Hash
Not Found
Для примера создадим md5-сумму важных системных файлов:
# md5sum /bin/* /sbin/* /usr/bin/* /usr/bin/*
> system.md5
Проверяем результат командой "cat system.md5", генерируем индексный файл:
# hfind -i md5sum system.md5
Теперь можно периодически проверять наличие измененных файлов в
контролируемых каталогах:
# md5sum /bin/* > bin.md5
# hfind -f bin.md5 system.md5
3/bin/bash
Invalid Hash Value
Как видишь, /bin/bash изменился со времени создания базы, его контрольная
сумма не совпадает.
И, наконец, скрипт sorter. Он умеет анализировать образ (для этого запускает
fls и icat), а также находит и распознает файлы (при помощи file). Если
задействована база NSRL, сортировщик может определить сразу и характер файла
(опасный или нет). Опасные файлы автоматически заносятся в отдельный файл -
alert.txt (если использован параметр "-s", то будет сохранено и содержимое
файла). Создаем каталог, куда будет сохраняться результат, и запускаем анализ
раздела или dd-образа:
# mkdir data
# sorter -d data -f ntfs /dev/sda1
По окончании работы в подкаталоге data появится несколько файлов с
расширением txt:
archive.txt documents.txt disk.txt sorter.sum
# cat data/documents.txt
Documents and Settings/All Users/Главное меню/Программы/
Стандартные/desktop.ini
ISO-8859 text, with CRLF line terminators
Image: /dev/sda1 Inode: 5805-128-1
В sorter.sum найдем общий итог по поиску.
Утилит в составе Sleuth Kit более чем предостаточно, и это вызывает некоторые
затруднения не только в их изучении, но и использовании даже у бывалых спецов.
Но не беда, так как в дополнение к TSK был создан инструмент визуализации -
Autopsy Forensic Browser
,
поддерживаемый тем же автором. Autopsy для своей работы требует наличия TSK и
желательно NSRL. После запуска в командной строке копируем выданный URL в
веб-браузер (http://localhost:9999).
Первым делом следует создать базу данных dd-образов, предварительно взятых с
различных дисков и систем. Для этого нужно нажать ссылку "New Case" и заполнить
название и описание (можно указать несколько вариантов, чтобы упростить поиск).
Далее нужно добавить сведения об узле, с которого снят образ. Жмем "Adding a New
Host" и заполняем данные - имя компьютера, описание, временной пояс, путь к
базам NSRL. И, наконец, через "Adding a New Image" подключаем образ - задаем
путь к файлу, тип (диск, раздел). После этого можно выбрать: копирование образа,
перемещение образа, создание симлинка. В следующем окне указываем файловую
систему и точку монтирования. По окончании можно начинать работу. Например,
извлечь строковые данные, отдельные блоки или удаленные файлы можно в
"Image Details". Здесь же получаем всю необходимую информацию о данных,
содержащихся в тех или иных блоках (ASCII, Hex, String). При необходимости
добавляем комментарий к нужному участку. Аналогично можно вывести список файлов,
данные о состоянии inode и прочую информацию. Сторонними разработчиками создана
альтернатива Autopsy - PTK ,
обладающая большим удобством в использовании и расширенными возможностями.
RFC3227 "Guidelines for Evidence Collection and Archiving" -
ftp.rfc-editor.org/innotes/rfc3227.txt .
Документ, подготовленный Национальным институтом юстиции США (National
Institute of Justice) "Forensic Examination of Digital Evidence: A Guide for Law
Enforcement" -