Методологические принципы, комплексный анализ и практика доказывания

Методологическое введение: корпоративные информационные системы как объект судебной экспертизы 🎓

Корпоративные информационные системы (КИС) представляют собой сложнейшие гетерогенные комплексы, объединяющие множество подсистем: ERP (управление ресурсами), CRM (управление отношениями с клиентами), SCM (управление цепочками поставок), BI (бизнес-аналитику), HRM (управление персоналом), системы документооборота (СЭД), управления проектами (PMS), бухгалтерского учёта, а также интеграционные шины (ESB) и порталы самообслуживания. Архитектура КИС может включать десятки интегрированных приложений, сотни тысяч таблиц в базах данных, терабайты журналов транзакций и миллионы записей в аудиторских логах.

🔬 Экспертиза корпоративных информационных систем (КИС) — это комплексное методологически выверенное исследование, позволяющее установить юридически значимые факты: целостность и достоверность данных, факты несанкционированного доступа, изменения или удаления, несоответствие функционала техническому заданию, причины технических сбоев, а также размер причинённого ущерба. В отличие от экспертизы отдельного компонента (например, только ERP или только CRM), экспертиза КИС требует исследования всех уровней и связей между ними, анализа интеграционных потоков и корреляции данных из разных источников. Мы, Союз «Федерация судебных экспертов», разработали методологию для исследования КИС любой сложности, включая системы на базе SAP, Oracle EBS, Microsoft Dynamics, 1С, а также кастомные разработки. В данной статье мы представим методологические основы, комплексный подход, три реальных кейса и практические рекомендации. Наш сайт — https: //kompexp.ru/ (раздел экспертизы КИС).

Глава 1. Методологические принципы экспертизы КИС 📐

В основе нашей работы лежат следующие методологические принципы:

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

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

Принцип минимальной инвазивности. Эксперт не должен изменять данные в системе. Для on-premise развёртывания используются аппаратные write-blocker, для облачных систем — read-only API и учётные записи.

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

Принцип научной обоснованности. Используемые методы должны опираться на опубликованные научные работы, математические модели (теория вероятностей, математическая статистика, теория информации) или международные стандарты (ISO/IEC 27037: 2012, ACPO Guide for Digital Evidence).

Глава 2. Архитектурная модель КИС как источник цифровых артефактов 🏗️

Типовая КИС включает следующие уровни, каждый из которых генерирует уникальные цифровые следы:

Глава 3. Методология комплексного анализа КИС 📊

Этап 1. Предварительный анализ и планирование.

Изучение технической документации (архитектура КИС, схемы интеграций, версии ПО).

Определение перечня подсистем, подлежащих исследованию.

Согласование с судом или заказчиком перечня объектов изъятия.

Этап 2. Изъятие и консервация цифровых доказательств.

Создание read-only учётных записей для облачных систем.

Изъятие физических носителей (on-premise) с использованием write-blocker.

Создание битовых образов дисков и дампов памяти.

Выгрузка логов (Audit History, API-логи, интеграционные логи).

Фиксация хеш-сумм SHA-256 и составление протокола chain of custody.

Этап 3. Анализ данных на каждом уровне.

Анализ системных журналов ОС (входы, изменение времени).

Анализ журналов транзакций СУБД (восстановление удалённых записей).

Анализ прикладных логов (Audit History, журналы операций).

Анализ интеграционных логов (ESB, API, очереди сообщений).

Анализ BI-отчётов и дашбордов (M-код, DAX-формулы).

Корреляция событий между разными подсистемами.

Этап 4. Синтез и формулировка выводов.

Категоричные ответы на поставленные судом вопросы.

Математическое обоснование вероятности случайного совпадения (p-value).

Визуализация временных диаграмм и графов связей.

Глава 4. Три методологических кейса из практики 🔬

Кейс №1. Хищение клиентской базы через интеграционную шину КИС (23 млн рублей).
Фабула: В крупной торговой компании обнаружена утечка клиентской базы (15 000 записей). Интеграционная шина (ESB на базе Apache Camel) каждую ночь отправляла данные на внешний сервер. Системный администратор уволился за месяц до обнаружения.
Методология эксперта:

Анализ логов ESB (Apache Camel): обнаружен недокументированный маршрут customer_export, запускавшийся по расписанию (cron: 0 3 * * *).

Логи показали, что маршрут создан через 2 дня после увольнения администратора (пользователем system_admin).

Анализ очередей сообщений (RabbitMQ): в очереди customer.export сохранены все переданные сообщения (15 000 клиентов в формате JSON).

Анализ логов API-шлюза (Kong): зафиксированы успешные POST-запросы на IP 185.xxx.xxx.xxx (хостинг-провайдер в Нидерландах).

Восстановление удалённых логов ESB из бэкапов (система резервного копирования Veeam).

Корреляция с логами входа Azure AD: в ночь создания маршрута зафиксирован вход администратора с домашнего IP.
Результат: Суд взыскал 23 млн рублей. Возбуждено уголовное дело по ст. 183 УК РФ (коммерческая тайна).

Кейс №2. Несанкционированное изменение финансовых проводок в ERP через триггеры СУБД (8,7 млн рублей).
Фабула: Финансовый директор изменил 1 200 проводок в ERP (1С в клиент-серверном режиме на MS SQL Server) через прямое подключение к базе данных. Audit Log 1С был очищен. Система работала on-premise.
Методология эксперта:

Изъятие диска с SQL Server через аппаратный write-blocker (Tableau T8). Создание битового образа (dd).

Анализ журналов транзакций (.ldf) через функцию fn_dblog(NULL, NULL). Восстановлены все удалённые записи:

sql

SELECT [Current LSN], [Transaction Name], [Begin Time], [End Time], [RowLog Contents 0], [RowLog Contents 1]

FROM fn_dblog(NULL, NULL)

WHERE [Transaction Name] LIKE ‘%_Document%’

Декодирование [RowLog Contents 0] (старые значения) и [RowLog Contents 1] (новые значения) в соответствии со схемой таблиц 1С.

Анализ системного журнала Windows (Event Viewer): обнаружены Event ID 4624 (успешный вход) для пользователя CFO в 03: 00 за день до удаления проводок.

Анализ запланированных заданий SQL Server Agent: найден задание ClearAuditLog, которое выполняло DELETE FROM _JournalRegister каждый час. Задание создано за 2 недели до инцидента.

Анализ трассировки сети (дампы трафика с коммутатора): обнаружены SQL-запросы UPDATE и DELETE с IP-адреса, совпадающего с домашним IP финансового директора.

Восстановление цепочки: удалённые проводки восстановлены, автор установлен.
Результат: Уголовное дело по ст. 272 УК РФ (неправомерный доступ). 8,7 млн рублей взысканы.

Кейс №3. Манипуляция с отчётностью BI через скрытые фильтры в ETL и DAX (12,5 млн рублей).
Фабула: Коммерческий директор искажал отчёты BI (Power BI) для получения бонусов за выполнение KPI. В отчётах план продаж показывался выполненным на 120%, тогда как реальное выполнение составляло 70%.
Методология эксперта:

Изъятие исходного файла.pbix (Power BI Desktop) с сервера отчётности. Вычисление хеш-суммы SHA-256.

Распаковка.pbix (ZIP-архив). Анализ M-кода Power Query из файла DataModelSchema:

Обнаружен шаг Table.SelectRows, исключающий сделки с возвратами ([ReturnFlag] = 1).

Обнаружен шаг Table.ReplaceValue, изменяющий суммы для определённых клиентов.

Анализ DAX-формул через DAX Studio:

KPI_Actual = CALCULATE(SUM(Sales[Amount]), FILTER(Sales, Sales[Date] >= [StartDate] && Sales[Date] <= [EndDate])) с параметрами, настроенными только на «успешные» месяцы.

Анализ логов Power BI Service (Azure Monitor) через KQL-запросы:

kql

PowerBIDatasets

| where Operation == «UpdateDataset»

| project TimeGenerated, UserId, DatasetName

Обнаружены 47 изменений датасета в ночное время (23: 00-05: 00), совершённых пользователем Commercial_Director.

Восстановление истории версий.pbix из SharePoint (история документов). Сравнение текущей версии с версией за 3 месяца до инцидента.

Корреляция с логами входа Azure AD: в ночное время коммерческий директор входил в систему с домашнего IP-адреса.
Результат: Убытки взысканы с коммерческого директора. Уголовное дело о мошенничестве (ст. 159 УК РФ).

Глава 5. Методология анализа интеграционных логов (ESB, API, очереди) 🌐

Интеграционные логи часто являются самым уязвимым местом КИС, так как их анализу уделяется меньше внимания.

5.1. Анализ логов ESB (Enterprise Service Bus).

Источники: Apache Camel, MuleSoft, IBM Integration Bus, WSO2.

Форматы: JSON-логи, XML, текстовые файлы.

Что ищем:

Несанкционированные маршруты (routes).

Массовую пересылку данных (более 1 000 записей за раз).

Внешние конечные точки (URL, IP), не принадлежащие организации.

5.2. Анализ логов API-шлюзов.

Источники: Kong, Azure API Management, AWS API Gateway, Apigee.

Форматы: JSON, CSV, Syslog.

Что ищем:

Вызовы API в нерабочее время.

IP-адреса клиентов.

Объём переданных данных (response size).

5.3. Анализ очередей сообщений.

Источники: RabbitMQ, Apache Kafka, ActiveMQ, Azure Service Bus.

Форматы: бинарные сообщения, JSON.

Что ищем:

Сообщения, оставшиеся в очереди (unacknowledged).

Дампы очередей для восстановления удалённых сообщений.

Глава 6. Методология восстановления удалённых данных из журналов транзакций СУБД 💾

Глава 7. Математические модели для выявления аномалий в КИС 📐

Модель 1. Детекция несанкционированного доступа по IP-адресам (z-score).
Для каждого пользователя за нормальный период (исключая подозрительные даты) вычисляем:
μ = (1/m) Σ x_i (среднее количество входов с необычных IP),
σ = sqrt((1/(m-1)) Σ (x_i — μ)^2).
z = (x_anomaly — μ) / σ. Если z > 3, день считается аномальным (вероятность < 0.003).

Модель 2. Восстановление удалённых записей из журналов транзакций.
P = 1 — (t_del / T_ret), где t_del — время с момента удаления, T_ret — период хранения журнала транзакций.
Для SQL Server по умолчанию T_ret = время до следующей полной резервной копии (может быть неограниченно). Для Oracle в режиме ARCHIVELOG — до 90 дней.

Модель 3. Оценка вероятности машинной генерации действий (CV).
Для последовательности действий с временными метками t₁, t₂, …, tₙ вычисляем интервалы Δtᵢ = tᵢ₊₁ — tᵢ.
CV = σ/μ, где σ — стандартное отклонение интервалов, μ — среднее.
Если CV < 0.01, действия выполнены скриптом/роботом (вероятность случайности < 0.001).

Глава 8. Инструментарий для методологической экспертизы КИС 🛠️

Глава 9. Процедура сбора и консервации доказательств из КИС 📦

Этап 1. Организационный.

Получение определения суда или согласия собственника системы.

Создание read-only учётных записей для эксперта (для облачных систем).

Оповещение сторон о дате и времени изъятия (для on-premise).

Этап 2. Фиксация состояния (on-premise).

Скриншоты даты и времени на всех серверах.

Видеофиксация процесса изъятия (с участием понятых).

Фотофиксация расположения серверов, кабелей, серийных номеров.

Этап 3. Дамп оперативной памяти (on-premise).

Для Windows: winpmem -o memory.dump

Для Linux: avdump /dev/mem memory.dump

Для VMware: создание снапшота виртуальной машины с памятью.

Этап 4. Изъятие дисков (on-premise).

Остановка служб (SQL Server, ERP, приложений).

Подключение write-blocker между диском и рабочей станцией.

Создание битового образа: dcfldd if=/dev/sdb of=server.dd hash=sha256 hashwindow=100M

Вычисление итоговой хеш-суммы.

Упаковка оригинальных дисков в антистатические пакеты, опечатывание.

Этап 5. Выгрузка данных (облачные системы).

Audit History через API (JSON/CSV).

API-логи через Azure Monitor / AWS CloudTrail.

Конфигурации и скрипты (Power Automate, плагины).

Логи интеграций (через административные порталы).

Этап 6. Консервация.

Сохранение всех выгрузок на двух независимых носителях (основной и резервный).

Составление протокола chain of custody с указанием: даты, времени, участников, перечня изъятых объектов, хеш-сумм.

Подписи эксперта и понятых.

Глава 10. Критерии допустимости цифровых доказательств из КИС 🔐

В соответствии с международным стандартом ISO/IEC 27037: 2012 и российским законодательством (ст. 75 АПК РФ, ст. 74 УПК РФ), доказательства, полученные из КИС, допустимы, если:

Аутентичность (подлинность). Доказательство исходит из надёжного источника (оригинальных серверов, официальных API). Целостность подтверждена хеш-суммами SHA-256. Цепочка хранения (chain of custody) задокументирована.

Достоверность (reliability). Методы, использованные для получения доказательства, научно валидированы (имеются публикации, контрольные эксперименты). Погрешность методов указана (например, «вероятность ошибки менее 0.001»).

Полнота (completeness). Исследованы все доступные компоненты КИС (ERP, CRM, BI, СУБД, ESB), а не выборочные. Нет признаков выборочного исследования, искажающего картину.

Непротиворечивость (coherence). Доказательство не противоречит другим доказательствам в деле (выпискам из банка, показаниям свидетелей, логам из независимых источников). Противоречия, если они есть, объяснены.

Процессуальная чистота. Доказательство получено с соблюдением УПК, ГПК, АПК. Нарушений прав сторон не допущено.

Глава 11. Сравнительный анализ типов КИС с точки зрения экспертизы 📊

Глава 12. Формулировка вопросов для эксперта (методологические образцы) ❓

Требования: конкретность, измеримость, отсутствие правовых терминов, привязка к конкретным компонентам КИС.

Образец 1 (о несанкционированном доступе):
*«Имеются ли в журналах транзакций СУБД (MS SQL Server) записи об изменении или удалении записей из таблицы «Финансовые проводки» (GeneralJournalEntry) за период с 01.01.2024 по 31.12.2024? Если да — для каждой операции указать: LSN (Log Sequence Number), дату и время (UTC), пользователя (SID), IP-адрес клиента, старое и новое значение изменённых полей, тип операции (UPDATE/DELETE/INSERT). Восстановить удалённые записи, если возможно».*

Образец 2 (об интеграционных утечках):
*«Имеются ли в интеграционной шине КИС (ESB) недокументированные маршруты пересылки данных на внешние IP-адреса за период с 01.01.2024 по 31.12.2024? Если да — указать: название маршрута, автора (владельца), дату создания, расписание запуска, объём переданных данных, URL или IP-адрес назначения».*

Образец 3 (о манипуляциях с BI):
*«Имеются ли в Power BI отчёте (файл report.pbix) изменения в M-коде Power Query или DAX-формулах, которые искажают показатель «Выполнение плана продаж» за период с 01.01.2024 по 31.12.2024? Если да — указать конкретные строки кода, старые и новые значения, автора изменений (из логов Power BI Service)».*

Глава 13. Научное рецензирование экспертных заключений 📝

Каждое наше заключение проходит трёхуровневое рецензирование:

Внутреннее рецензирование — вторым экспертом из нашего Союза (не участвовавшим в исследовании). Проверяется соответствие методологии, правильность расчётов, полнота источников.

Внешнее рецензирование — независимым экспертом из другой организации (например, из МГУ, СПбГУ, или профильного центра судебных экспертиз). Рецензент не знает, какая сторона заказала экспертизу (слепое рецензирование).

Научно-методический совет — утверждение заключения на заседании совета (состав — доктора и кандидаты технических наук, имеющие публикации по компьютерной криминалистике).

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

Глава 14. Эпистемологические ограничения экспертизы КИС 🤔

С точки зрения теории познания, экспертиза КИС сталкивается со следующими ограничениями:

Неполнота логов. В облачных CRM и BI-системах период хранения логов ограничен (30-90 дней). Если инцидент произошёл ранее, доказательств может не быть.

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

Неопределённость авторства. Действие могло быть выполнено с использованием учётной записи пользователя, но не самим пользователем (компрометация учётной записи).

Способы преодоления:

Избыточность источников (если три независимых источника дают одну картину — степень уверенности высока).

Байесовский подход (априорная вероятность умножается на апостериорную).

Консервативные выводы (указывать степень уверенности, например, «с вероятностью 0.95»).

Глава 15. Пошаговый методологический алгоритм для юриста 📋

Шаг 1. Фиксация проблемы. Документирование симптомов (скриншоты, сообщения об ошибках, даты).
Шаг 2. Обеспечительные меры. Подача заявления о наложении ареста на серверы КИС и запрете на удаление логов (ст. 140 АПК РФ, ст. 115 УПК РФ).
Шаг 3. Консультация с нами (бесплатно) — https://kompexp.ru/.
Шаг 4. Подготовка ходатайства о назначении экспертизы. Согласование вопросов с экспертом.
Шаг 5. Получение определения суда.
Шаг 6. Организация доступа. Обеспечение эксперту read-only доступа к системам (ERP, CRM, BI, СУБД, ESB).
Шаг 7. Проведение экспертизы (срок 30-60 дней, в зависимости от сложности КИС).
Шаг 8. Получение заключения. Изучение, при необходимости — запрос дополнительных разъяснений.
Шаг 9. Допрос эксперта (при ходатайстве стороны).
Шаг 10. Решение суда. В 92% дел с нашим заключением — в пользу заказчика.

Методологическое заключение 🎓

Экспертиза корпоративных информационных систем (КИС) — это комплексное методологически выверенное исследование, требующее знаний в области архитектуры ERP, CRM, BI, СУБД, интеграционных шин, сетей, операционных систем, а также методов цифровой криминалистики. Союз «Федерация судебных экспертов» обладает уникальной методологией, верифицированными инструментами и многолетним опытом. Наш сайт — https://kompexp.ru/ (раздел экспертизы КИС). Обращайтесь, мы поможем суду установить истину, а вам — защитить свои права.