Экспорт активности агента для юридической проверки: как создать доказательную базу

Экспорт активности агента должен позволять стороннему проверяющему ответить на четыре простых вопроса, не полагаясь на человека, который его подготовил: какие действия произошли, когда они произошли, менялись ли записи и кто контролировал материалы после сбора. Большинство команд может ответить на первый вопрос. Остальные три превращают обычный инцидент в спор о доказательствах.

Не ждите повестки, трудового спора, инцидента безопасности или жалобы клиента, чтобы решить, что сохранять. К этому моменту задания хранения могли удалить журналы, люди могли открыть и переставить файлы, а спешивший инженер мог экспортировать только записи, которые показались ему важными. Это понятно. Но именно так пакет для проверки теряет убедительность.

Ниже описан практический способ подготовить записи действий агента для юристов, внутреннего расследования, проверки соответствия требованиям или внешнего эксперта. Он не заменяет юридическую консультацию. Зато дает юристам нечто гораздо более полезное, чем таблица с успокаивающим именем файла.

Считайте пакет доказательством, а не отчетом

Пакет доказательств сохраняет исходные материалы и объясняет, как с ними обращались. Отчет отбирает, интерпретирует и обосновывает выводы на основе этих материалов. Вам могут понадобиться оба документа, но неосторожное объединение создает проблемы.

В отчете можно написать: «Агент попытался выполнить команду SSH на этом узле в указанное время». Пакет доказательств должен позволять найти исходную запись действия, увидеть представление времени, изучить зафиксированный результат, подтвердить систему-источник и проверить, изменился ли экспорт. Отчет должен находиться рядом с пакетом, а не внутри его единственной копии.

Это различие особенно важно, когда первоначальная версия событий оказывается ошибочной. По мере расследования специалисты часто сужают фокус. Если они экспортировали вручную выбранные «плохие» события, а затем удалили соседние записи, позднее они не смогут проверить, не объясняют ли событие повторная попытка, утверждение, смена сессии или действие оператора. Контекст не служит украшением. Часто именно он отличает действительно несанкционированное действие от вводящей в заблуждение последовательности обычных сбоев.

До сбора определите его границы. Сформулируйте их одним коротким заявлением, в котором указаны:

• идентификаторы процессов или сессий агентов, входящих в объем сбора
• каналы действий, например HTTP и SSH
• начальное и конечное время в UTC
• охваченные системы или учетные записи
• известные исключения и причину каждого из них

Позднее не расширяйте границы молча. Выполните дополнительный сбор. Например, если первый пакет охватывает шестичасовое окно инцидента, а затем проверяющий просит данные за предыдущий день, создайте второй пакет с собственным манифестом и хешами. Свяжите его с первым пакетом в записи цепочки хранения. Так сохраняется факт, что первоначальное решение имело определенные границы.

Здесь команды часто допускают серьезную ошибку: путают представление активности с полной исходной записью. Панель управления может быть полезна для первичной проверки, но она часто применяет фильтры, постраничный вывод, пользовательские настройки и ограничения хранения, которые не видны на снимке экрана. Собирайте исходные записи или максимально близкий к ним экспорт источника, а затем создавайте удобные представления на основе этих материалов.

Разделяйте подлинность и полноту

Подлинность и полнота являются разными утверждениями, и хороший пакет подтверждает каждое из них отдельно.

Подлинность отвечает на вопрос, получена ли конкретная запись из заявленного источника и не изменил ли ее кто-либо после сбора. Для этого помогают хеши, подписи, хранилища с добавлением данных только в конец и хешированные цепочки. Полнота отвечает на вопрос, содержит ли пакет все записи, которые должны входить в заявленные границы. Здесь важны запросы, количество записей в источнике, настройки хранения и заметки о сборе.

Команды часто приписывают файловому хешу слишком много. Хеш SHA-256 может показать, что activity.jsonl сейчас совпадает с версией, для которой вы ранее рассчитали хеш. Но он не доказывает, что файл содержит каждое действие за период, что системные часы показывали правильное время или что файл действительно получен из системы, указанной в служебной записке. Хеш отлично подтверждает непрерывность байтового содержимого. Универсальной печатью истины он не является.

Точно так же цепочка аудита может выявить удаление или изменение внутри охватываемой ею последовательности, но не исправит плохо определенные границы. Если вы собрали только одну сессию агента, хотя в инциденте участвовали две, целая цепочка первой сессии не делает пакет полным.

Используйте манифест, чтобы эти утверждения можно было проверить. В нем нужно указать источник, границы, сборщика, время сбора, перечень файлов и материалы для проверки. Храните его в простом текстовом формате, который не требует определенного приложения для чтения.

case_reference: IR-2025-017
package_id: 2025-017-agent-actions-01
collected_at_utc: 2025-03-08T14:27:19Z
collected_by: employee-id-1842
source_system: macOS workstation, asset WS-042
scope_start_utc: 2025-03-07T18:00:00Z
scope_end_utc: 2025-03-08T02:00:00Z
channels: HTTP, SSH
included_files:
  - original/activity-records.jsonl
  - original/session-records.jsonl
  - original/audit-verification.txt
  - derived/action-timeline.csv
exclusions: Browser history and local shell history were outside this collection.

В каталоге original должны находиться собранные исходные материалы. В каталоге derived можно хранить шкалу событий в CSV, служебную записку или отредактированную копию. Такое разделение предотвращает распространенную ошибку: кто-то открывает JSON-файл, сохраняет его через редактор, который меняет переводы строк или кодировку, а затем обнаруживает, что исходный хеш больше не совпадает.

Федеральные правила доказывания рассматривают подтверждение подлинности в правиле 901 через доказательства, достаточные для вывода о том, что предмет является именно тем, за что его выдает сторона. Правило 902(14) отдельно касается сертифицированных данных, скопированных с электронного устройства, носителя или файла, если квалифицированный специалист идентифицирует их с помощью процесса цифровой идентификации. Эти правила не позволяют техническим специалистам отказываться от документации. Напротив, они делают процесс идентификации частью доказательства.

Зафиксируйте источник до того, как придадите данным удобный вид

Соберите данные один раз, сохраните этот результат, а сортировку и форматирование выполняйте на копиях. Это кажется излишней осторожностью, пока следователю впервые не приходится объяснять, почему файл изменился после того, как команда объявила его доказательством.

Начните с каталога дела с ограниченным доступом. Запишите точное расположение системы, из которой собирались записи, учетную запись, использованную для сбора, и продолжал ли источник работать после сбора. Если источник может получать новые события, укажите это. Работающая система не является статичным вещественным доказательством, и попытка представить ее так приводит к путанице в шкале событий.

Затем создайте прямой экспорт источника. Не открывайте файлы в табличном редакторе до расчета хешей. Табличные приложения регулярно переинтерпретируют даты, обрезают длинные значения, меняют разделители и воспринимают идентификаторы как числа. Для рабочего аналитического файла это может быть приемлемо. Для сохраненной копии это недопустимо.

В macOS рассчитайте перечень SHA-256 из каталога пакета после размещения в нем оригиналов:

find original -type f -print0 | sort -z | xargs -0 shasum -a 256 \u003e SHA256SUMS.txt
cat SHA256SUMS.txt

В выводе будет одна строка на файл: 64-символьный шестнадцатеричный дайджест и путь к файлу. Сохраните вывод команды в составе пакета и укажите, кто ее выполнил. Позднее проверяйте данные по тому же перечню:

shasum -a 256 -c SHA256SUMS.txt

При успешной проверке после каждого пути выводится OK. Если для пути появляется FAILED, перестаньте считать пакет неизменным. Сохраните копию с ошибкой, зафиксируйте результат и выясните, вызвали ли его передача, переименование, преобразование переводов строк или фактическое изменение. Не создавайте заново файл хешей и не продолжайте работу молча.

Имена файлов должны быть простыми и стабильными. При необходимости указывайте идентификатор пакета, категорию источника и время сбора в UTC. Избегайте имен вроде final-final-v3 или suspicious stuff. Проверяющий не должен полагаться на устные объяснения, чтобы отличить исходный экспорт от отфильтрованного рабочего листа аналитика.

В документе NIST Special Publication 800-86, Guide to Integrating Forensic Techniques into Incident Response, подчеркивается необходимость сохранять данные и документировать их сбор и обработку. Этот документ старше инструментов для агентов, но его принцип по-прежнему применим. Действия агентов выполняются быстро. Это довод в пользу более подробных заметок о сборе, а не повод снижать требования.

Фиксируйте временные метки вместе с контекстом часов

Временная метка без определенных часов содержит лишь часть факта. Сохраняйте исходное значение времени, его часовой пояс или смещение, имя поля и любой известный идентификатор порядка.

Используйте UTC как эталонное время пакета. Записывайте его в формате ISO 8601, например 2025-03-08T14:27:19Z. При этом сохраняйте исходные временные метки ровно в том виде, в каком их экспортировал источник. Если источник показывает местное время, укажите настроенный часовой пояс и синхронизировала ли система время через утвержденный сервис. Не заменяйте исходную метку только потому, что команде удобнее другой формат.

Одно действие агента может породить несколько временных значений. Запись может содержать момент, когда агент запросил операцию, момент появления утверждения, время утверждения человеком, время выполнения системой и время ответа удаленного сервиса. Это разные события.

Для полезной шкалы событий обозначайте их по типу события, а не сводите к одному столбцу timestamp. Запрос в 10:00:01, утверждение в 10:00:28, выполнение в 10:00:29 и сбой удаленного сервиса в 10:00:31 рассказывают совсем другую историю, чем выполнение до утверждения. Порядок может подтвердить или опровергнуть утверждение о контроле со стороны человека.

Сохраняйте идентификаторы последовательности, если они есть. Монотонно возрастающая последовательность аудита, номер вызова внутри сессии или идентификатор запроса помогают разрешить совпадения, когда две записи имеют одинаковую точность времени. Если записи содержат только секунды, так и напишите. Не создавайте миллисекундную точность, записывая время экспорта.

Разногласия между часами требуют отдельной заметки. Если локальная рабочая станция и удаленный API расходятся на несколько минут, сохраните это наблюдение и укажите источники. Не «исправляйте» одну запись, чтобы шкала событий выглядела аккуратнее. Позже проверяющему может понадобиться выяснить, использовали ли системы разные часы или событие пересекло границу времени.

В пакет нужно включить короткое заявление о времени, например: «Все представления шкалы событий используют UTC. Исходные значения сохранены в оригинальных файлах. Во время сбора рабочая станция сообщала смещение UTC +00:00. Независимая проверка часов не выполнялась». Последняя фраза может показаться неудовлетворительной, но она честна. Необоснованная уверенность вредит сильнее, чем зафиксированное ограничение.

Сохраняйте действие и контекст принятия решения

В записи действия должно быть достаточно контекста, чтобы отличить попытку запроса, разрешенное выполнение и завершившийся внешний эффект. Это разные события.

Для активности HTTP сохраняйте время действия, идентификатор сессии или процесса, метод, целевой узел, путь, относящиеся к делу заголовки запроса после удаления секретов, порядок обработки тела запроса, статус ответа и метаданные результата. В пакете не должны находиться пригодные для повторного использования токены носителя, пароли или закрытые ключи только потому, что они прошли через систему действий. Секрет может создать второй инцидент уже внутри процесса работы с доказательствами.

Для активности SSH сохраняйте целевой узел или его псевдоним, идентификатор пользователя, использованный системой действий, команду или категорию команды, если они записываются, результат аутентификации, код завершения и возвращенный вывод с учетом документированного правила редактирования. Если вывод команды может содержать данные клиентов, сохраните оригинал с ограниченным доступом и создайте копию для проверки, где описано каждое редактирование. Черные полосы без журнала редактирования заставляют проверяющих думать, что исчезло что-то еще.

Идентичность процесса не менее важна, чем само действие. Зафиксируйте процесс агента, инициировавший вызов, полномочия подписи его кода, если они доступны, идентификатор сессии и продолжительность сессии. Формулировка «это сделал агент для программирования» слишком расплывчата для юридической проверки. Разные процессы могут иметь разное происхождение, разные утверждения и разные разрешения, даже если человек называет их одним и тем же агентом.

К записям об утверждении нужно подбирать точные формулировки. Утверждение означает, что человек разрешил определенную операцию или сессию в соответствии с замыслом системы. Оно не доказывает, что человек прочитал каждую деталь, понял все последствия или обладал полномочиями по правилам компании. Не делайте таких выводов без отдельных подтверждений.

Sallyport записывает запуски агентов в журнале Sessions, а отдельные вызовы в журнале Activity. Оба представления строятся на основе одного зашифрованного журнала аудита с хешированной цепочкой. Для проверки это удобно: вопрос на уровне сессии и вопрос на уровне вызова могут ссылаться на одну и ту же исходную последовательность записей.

Сохраняйте связь между исходным запросом и результатом. Неудачный вызов может быть не менее важен, чем успешный. Повторные сбои могут показать, что агент повторно использовал заблокированное удостоверение, измененный адрес или что оператор исправил конфигурацию. Удаление ошибок ради более короткой шкалы часто убирает объяснение единственного важного успеха.

Проверяйте признаки изменения, пока источник доступен

Выполняйте проверку целостности во время сбора и сохраняйте вывод вместе с исходными записями. Поздняя проверка тоже полезна, но ранний результат связывает пакет с состоянием системы журналирования в момент сбора.

Журнал с хешированной цепочкой связывает каждую запись с предыдущими материалами с помощью криптографических данных. Изменение, удаление или вставка записи обычно нарушает последующую связь. Это дает проверяющим конкретное свойство для проверки: подтверждается ли последовательность в том виде, в котором она была выпущена. Это не доказывает, что записанное действие было этичным или что в журнал попало каждое возможное событие системы. Эти утверждения нужно разделять.

Для журнала аудита Sallyport запустите sp audit verify для собранного источника до того, как начнете полагаться на представления журналов. Проверка может выполняться автономно над зашифрованными данными и не требует ключа хранилища. Это позволяет сохранить результат проверки целостности без получения учетных данных, использованных для внешних действий.

Сохраните полную расшифровку терминала, включая команду, текущий каталог, идентичность учетной записи, если это предусмотрено процедурой, время начала и окончания и код завершения. Снимок экрана слабее текста, поскольку его трудно искать, копировать и независимо запускать повторно. Если команда сообщает об ошибке, сохраните этот результат. Не экспортируйте только записи, которые успешно прошли проверку.

Проверка требует воспроизводимых условий. Укажите версию приложения, версию операционной системы, если это важно, и точный путь сбора. Если инструмент проверки зависит от определенной локальной установки, сохраните сведения об этой зависимости. Необязательно по умолчанию включать в пакет каждый исполняемый файл, но проверяющим нужно понимать, что потребуется для повторения проверки.

Простая заметка о проверке может выглядеть так: «Сборщик запустил команду проверки аудита в 2025-03-08T14:31:02Z для скопированного зашифрованного журнала аудита в original/. Команда завершилась успешно. Неизмененная расшифровка терминала находится в original/audit-verification.txt». Если команда завершилась неуспешно, напишите об этом прямо и укажите последствия для пакета. Доказательства целостности полезны именно потому, что могут противоречить удобному вам объяснению.

Ведите запись цепочки хранения с указанием людей и передач

Цепочка хранения представляет собой хронологическую запись владения и контроля. Это не страница с подписями, заполненная задним числом после чьей-то просьбы.

Начните запись в момент создания пакета сборщиком. В каждой записи указывайте идентификатор пакета, дату и время в UTC, лицо или сервисную учетную запись, передающую контроль, получателя, цель, способ передачи, место хранения и хеш пакета либо ссылку на перечень хешей. Если один человек сохраняет контроль на протяжении всего сбора, это тоже нужно зафиксировать.

Используйте имена или стабильные внутренние идентификаторы, которые компания сможет сопоставить с конкретным человеком. «Команда безопасности» не является хранителем. «Джейн из юридического отдела» тоже недостаточно. Люди меняют должности, уходят из компаний и по-разному вспоминают события под давлением.

2025-03-08T14:38:11Z
Package: 2025-017-agent-actions-01
Released by: employee-id-1842
Received by: legal-ops-id-77
Purpose: counsel review under incident hold
Method: encrypted internal file transfer
Integrity reference: SHA256SUMS.txt verified before transfer
Storage: matter workspace, restricted folder

Если передача выполняется через зашифрованное хранилище или защищенный обмен файлами, укажите способ, но не считайте, что шифрование доказывает соблюдение цепочки хранения. Шифрование защищает конфиденциальность при передаче. Запись цепочки показывает, кто намеренно передал и получил пакет. Попросите получателя подтвердить получение, а затем фиксируйте каждую копию, переданную консультанту, страховщику, регулятору или внешнему юристу.

Журналы доступа могут поддерживать запись цепочки, но не заменяют ее. Журнал хранилища может показать, что учетная запись открывала файл. Но он не всегда объясняет, зачем это произошло, принадлежала ли учетная запись ожидаемому человеку в тот момент или выполнялась ли утвержденная передача за пределами системы хранения.

Не отправляйте единственный оригинал обычной электронной почтой. Почта создает неконтролируемые копии, риск автоматической пересылки, сложности с хранением и неясность относительно версий вложений. Если юристам нужна копия, создайте документированную копию для распространения, проверьте ее хеш после передачи, а оригинал сохраните в контролируемом месте.

Редактирование должно быть обратимым на уровне процесса, а не файлов

Редактируйте материалы для конкретной аудитории и цели, но сохраняйте неотредактированный оригинал, если этого требуют закон, политика и расследование. Отредактированная версия не должна оставаться единственным сохранившимся пакетом.

Записи агентов могут содержать секреты, исходный код, персональные или клиентские данные, внутренние имена узлов и операционные сведения, которые создают новый риск при широком распространении. Для юридической проверки редко нужны пригодные для повторного использования учетные данные API или закрытый материал SSH. Уберите их из копии для проверки и объясните, как процесс сбора с ними обращался. Если экспорт источника содержит секреты, лучше ограничить доступ к оригиналу, чем раздать его всем проверяющим.

Используйте журнал редактирования с отдельной строкой для каждого отредактированного элемента или единообразной категории. Указывайте файл, идентификатор записи, поле, причину, человека, выполнившего редактирование, дату и наличие оригинала с ограниченным доступом. Проверяющий должен отличать отредактированный заголовок авторизации от удаленного результата действия.

Не полагайтесь на визуальные накладки в PDF или на снимках экрана. Неправильное редактирование уже неоднократно открывало скрытый текст, поэтому его нельзя считать мелкой технической деталью. Создайте новый материал для проверки из контролируемой копии, проверьте его обычными средствами извлечения текста и убедитесь, что секретные данные больше не встречаются. Затем отдельно рассчитайте хеш отредактированного материала. Его хеш не должен заменять исходный перечень.

Отфильтрованная шкала событий может быть полезна, особенно если дело охватывает тысячи обычных вызовов. Пометьте ее как производный материал и включите логику фильтра. Например: «Включены вызовы к указанному клиентскому пространству между обозначенными моментами UTC; все остальные назначения исключены; исходные записи находятся в original/activity-records.jsonl». Эта фраза позволяет юристам объяснить, чем является материал, не выдавая его за полный журнал аудита.

Сделайте пакет понятным через полгода

Человек, собравший пакет, может не участвовать в его дальнейшем объяснении. Пишите заметки о сборе для того, кто унаследует дело после исчезновения переписки по инциденту и когда первоначальный инженер уже забудет подробности.

Включите короткий файл readme с ответами на практические вопросы: какие файлы являются оригиналами, какие производными, какой инструмент создал каждый экспорт, как проверить хеши, как интерпретировать временные метки и где контролируется доступ к сохраненному оригиналу. Мнения храните в отдельном анализе инцидента, если только пакет явно не помечает их как заявление аналитика.

Шлюз хранилища Sallyport, авторизация сессий и утверждения отдельных вызовов могут создавать записи, которые помогают объяснить контроль человека над действием. Сохраняйте уровень подтверждений, необходимый для дела, но не утверждайте, что технический контроль продукта отвечает на юридический вопрос о политике, полномочиях или намерении.

До начала расследования проведите одну тренировку. Попросите коллегу, который не собирал пакет, используя только readme, манифест, хеши и расшифровку проверки, ответить на вопросы: какие исходные записи включены? Могу ли я их проверить? Какая основа времени используется? Кто хранил пакет? Если коллеге приходится задавать сборщику базовые вопросы, пакет еще не готов.

Обычно первое полезное улучшение выглядит непримечательно: заранее создайте шаблон каталога дела, текстовый манифест, команду для перечня хешей и журнал цепочки хранения. Когда произойдет реальный инцидент, эти четыре элемента не дадут спешному экспорту превратиться в историю, которую невозможно проверить.