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

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

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

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

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

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

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

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

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

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

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

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

Уровень	Компоненты	Форматы данных	Инженерные артефакты	Метод доступа
Клиентский	Веб-интерфейс, десктоп-приложения, мобильные клиенты, терминалы	HTML, JS, CSS, локальное хранилище (IndexedDB), кэш	Логи браузера (консоль F12), временные файлы, cookies, история	Сбор на рабочей станции пользователя (с согласия, по определению суда)
Прикладной	Модули ERP, CRM, SCM, HRM, BI, СЭД, PMS	Собственные форматы, XML, JSON, бинарные логи	Журналы аудита (Audit Logs), логи транзакций, дампы памяти процессов	API, логи приложений, прямой доступ
Интеграционный	ESB (Enterprise Service Bus), шины данных, API-шлюзы, очереди сообщений	XML, JSON, SOAP, REST, AMQP, MQTT	Логи интеграций, очереди сообщений, журналы трансформации, заголовки запросов	API-логи, журналы ESB, дампы очередей
Базы данных	SQL Server, Oracle, PostgreSQL, MongoDB, Cassandra	.mdf,.ldf,.dbf,.ibd, WAL, redo-логи	Журналы транзакций, redo-логи, дампы памяти БД, схемы таблиц	Прямой доступ к серверу, write-blocker, SQL-запросы
Операционная система	Windows Server, Linux (RHEL, SUSE), AIX, Solaris	Системные журналы (Event Log, syslog), конфигурации	Логи входа (Event ID 4624, auth.log), изменение времени (Event ID 1), доступ к файлам	Доступ к ОС, Syslog, анализ реестра/конфигураций
Сетевая инфраструктура	Маршрутизаторы, файрволы, прокси-серверы, балансировщики	PCAP, NetFlow, Syslog, IPFIX	IP-адреса, порты, MAC-адреса, сессии, NAT-трансляции	Логи сетевого оборудования, дампы трафика
Аппаратный	Физические серверы, диски (HDD, SSD), RAID-массивы, SAN	Битовые образы, сектора (512 байт), кластеры (4 КБ), страницы	Удалённые файлы, теневые области, MFT, inode, журналы файловых систем	PC-3000, write-blocker, создание битовых образов

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

Кейс №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 УК РФ).

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

Этап 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).

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

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

Инструмент	Назначение	КИС-совместимость	Лицензия
FTK Imager / dcfldd	Создание битовых образов дисков	Любые (on-premise)	Бесплатные
Write-blocker Tableau T8	Аппаратная защита от записи	Любые (on-premise)	Коммерческая
PC-3000	Восстановление данных с повреждённых/форматированных дисков	Любые (on-premise)	Коммерческая
Volatility Framework	Анализ дампов оперативной памяти	Windows, Linux	Open source
SQL Management Studio	Анализ.mdf,.ldf, выполнение SQL-запросов	SQL Server	Бесплатная
Oracle LogMiner	Анализ redo-логов Oracle	Oracle	Встроенная
pg_waldump	Анализ WAL PostgreSQL	PostgreSQL	Open source
Azure Monitor / Log Analytics	KQL-запросы к логам облачных систем	Dynamics 365, Power BI, Azure	Платная (по потреблению)
Wireshark	Анализ сетевого трафика (PCAP)	Любые (при наличии дампов)	Open source
X-Ways Forensics	Комплексный анализ файловых систем	Любые (on-premise)	Коммерческая
EnCase Forensic	Судебная платформа	Любые (on-premise)	Коммерческая
Autopsy / The Sleuth Kit	Анализ файловых систем (open source)	Любые (on-premise)	Open source

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

Этап 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 с указанием: даты, времени, участников, перечня изъятых объектов, хеш-сумм.

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

Глава 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. Сравнительный анализ типов КИС с точки зрения экспертизы 📊

Тип КИС	Примеры	Сложность экспертизы	Основные источники	Специфические сложности
ERP-центричная	SAP, 1С, Oracle EBS	Высокая	Журналы транзакций, CDHDR, audit logs	Бизнес-логика внутри БД, сложные связи между модулями
CRM-центричная	Salesforce, Dynamics 365	Средняя	Audit History, API-логи, Change Tracking	Облачная модель ограничивает доступ
BI-центричная	Power BI, Tableau, Qlik	Средняя	M-код, DAX-формулы, ETL-логи	Легко подделать DAX-формулы
Кастомная разработка	Индивидуальные системы	Очень высокая	Исходный код, логи приложения, БД	Нет стандартных механизмов аудита
Интеграционная шина	Apache Camel, MuleSoft	Высокая	Логи маршрутов, очереди сообщений	Логи могут быть настроены на ротацию

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

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

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

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

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

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

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

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

Образец 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-адрес назначения».*

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 13. Типовые методологические ошибки при экспертизе КИС ❌

Ошибка	Последствие	Правильный метод
Изъятие без дампа памяти	Потеря активных транзакций, ключей	Всегда делать дамп RAM до выключения
Работа без write-blocker	Изменение временных меток → недопустимость	Только с write-blocker
Игнорирование интеграционных логов	Пропуск утечек через ESB	Анализировать все компоненты
Анализ только одной подсистемы	Неполная картина	Исследовать все уровни КИС
Отсутствие корреляции данных	Невозможность установить причинно-следственные связи	Всегда коррелировать события из разных источников

Глава 14. Судебная практика по КИС-экспертизе ⚖️

На основе 150 экспертиз за 15 лет:

Споры о внедрении — 35% (несоответствие ТЗ, некачественная интеграция).

Споры о хищении данных — 28% (коммерческая тайна, ст. 183 УК РФ).

Споры о фальсификации отчётности — 20% (BI-манипуляции).

Споры о лицензировании — 10% (нелицензионное ПО).

Иные — 7%.

Глава 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% дел с нашим заключением — в пользу заказчика.

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

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