Стежити У корпоративному середовищі щогодини генеруються мільйони подій. Під час інциденту респондеру рідко потрібні всі вони. Їм потрібні лише кілька сотень, які розповідають історію: сплеск невдач 4625, що супроводжується єдиним успішним 4624, закодований PowerShell, запущений winword.exe, нова служба, встановлена о 03:12 на контролері домену. Аналіз журналів – це дисципліна, що дозволяє перейти від першого числа до другого досить швидко, щоб це мало значення.
Ця робота стала важчою в двох напрямках одночасно. Нападники, використовуючи ІІ-інструменти, генерують докази зі швидкістю машини та заповнюють реальні дії активністю, що виглядає як нешкідлива. Тим часом, очевидний скорочений шлях передавання журналів до LLM стикається із захисними планками, обмеженнями вікна контексту та обов’язками щодо захисту даних. На цю стіну натрапили респондери Hugging Face у липні 2026 року, коли приблизно 17,000 подій було відхилено передовими моделями і довелося обробити на локальній моделі.
Нижче ми покриваємо аналіз журналів від початку до кінця, а потім розглядаємо LogTotal, безкоштовну відповідь SOC Prime на версію проблеми в часі інциденту.
Спробуйте LogTotal, безкоштовно
Які основи аналізу журналів?
Кожен робочий процес аналізу журналів, чи то він виконується в SIEM, озері даних або на ноутбуці респондера, базується на тих самих п’яти етапах. Пропуск одного зазвичай проявляється пізніше як пропущене виявлення або хибнопозитив, які ніхто не може пояснити.
- Збирання. Агенти, пересилачі syslog, API-респондери та хмарні експортні програми переміщують події від джерела. Пропуски тут беззвучні: конфігурація Sysmon, що випускає ідентифікатор події 10 (доступ до процесу), означає, що дампування облікових даних через LSASS ніколи не відображається нижче за потоком.
- Розбір і нормалізація. Сирі рядки перетворюються на поля. Джерело IP має бути тим самим полем, чи воно походить з брандмауера, IdP або EDR, саме тому існують схеми на кшталт ECS і OCSF.
- Збагачення. Критичність активів, роль користувача, GeoIP та розвідка загроз перетворюють IP-адресу на контекст, на який аналітик може реагувати.
- Кореляція. Однорідні події рідко щось доводять. Зв’язок їх за хостом, користувачем, GUID процесу або ідентифікатором сесії створює наратив атаки.
- Збереження і цілісність. Гаряче зберігання для пошуку, холодне зберігання для розслідування і ознаки підміни, завдяки чому записи зберігають свою цілісність.
Що таке аналіз журналів?
Аналіз журналів – це процес вивчення згенерованих машинами записів для відтворення того, що сталося на системі, вирішення, чи це має значення, і визначення наступних дій. У сфері безпеки він відповідає на п’ять запитань щодо будь-якої підозрілої активності: хто діяв, на якому активі, коли, звідки і яким механізмом.
Це відрізняється від управління журналами. Управління – це сантехніка: поглинання, зберігання, збереження, контроль доступу. Аналіз – це інтерпретація. Команда може мати добре налагоджену трубопровід журналів і все ще пропустити вторгнення, тому що ніхто, ні людина, ні машина, не ставили правильні запитання до даних.
На практиці аналіз журналів працює в трьох режимах:
- Виявлення. Правила та моделі регулярно оцінюють події та піднімають тривоги, коли з’являється відоме шкідливе поводження.
- Розслідування. Після попередження чи підказки аналітики перевіряють пов’язані події, щоб оцінити інцидент і знайти першопричину.
- Полювання на загрози. Аналітики виходять з гіпотези, наприклад, зловживання конкретним LOLBin, та активно шукають докази, які пропустив шар виявлення.
З усіх команд, що використовують журнали, сек’юрність має найменше місця для прогалин.
Чому аналіз журналів такий важливий?
Тому що час впливає на витрати на проникнення, а журнали – це місце, де час виграється або втрачається. Звіт IBM про витрати на витік даних у 2026 році визначає середній час для виявлення та ліквідації витоку в 247 днів, що є першим збільшенням за п’ять років. Пробою із життєвим циклом понад 200 днів в середньому коштували 5,65 мільйона доларів, порівняно з 4,32 мільйона доларів за ті, що були ліквідовані швидше.
Окрім вартості, аналіз журналів підкріплює чотири зобов’язання, які має кожна програма безпеки:
- Виявлення. EDR та NDR бачать фрагменти активності. Журнали від постачальників ідентичності, аудиторські сліди SaaS і контрольні площини хмар заповнюють прогалини між ними.
- Оцінка масштабу і першопричини. Без доказів на рівні подій респондери не можуть сказати, які облікові записи було торкнуто або як зловмисник проник, тому ліквідація стає здогадкою.
- Регуляторна звітність. Вимога 10 стандарту PCI DSS 4.0 вимагає перевірки аудит-журналів і їх збереження протягом 12 місяців. Форма SEC 8-K розділу 1.05 дає зареєстрованим компаніям чотири робочі дні після визначення матеріальності, що неможливо без швидкої оцінки.
- Інженерія виявлення. Реальна телеметрія – це те, як тестуються та налаштовуються правила.
Є одне зауваження. Журнали, які роблять все це можливим, містять користувацькі імена, IP-адреси, кукі сеансу та маркери носія. Все частіше хорошим аналізом стає безпечний аналіз.
Спробуйте LogTotal, безкоштовно
Які є типи даних журналів?
Журнали, що мають значення для безпеки, поділяються на шість сімейств. Кожне відповідає на різне питання, і розслідування, що покладається лише на одне чи два з них, матиме сліпі зони, в яких може жити зловмисник.
| Сім’я журналів | Типові джерела | Що воно повідомляє аналітику |
| Кінцевий пункт і ОС | Windows Security (4624, 4688, 7045), Sysmon, Linux auditd, journald | Який процес виконувався, під яким обліковим записом, з яким батьком і командним рядком |
| Ідентичність | Active Directory (4768, 4769), входи Entra ID, Okta System Log | Хто автентифікувався, звідки, з яким протоколом і результатом MFA |
| Мережа | Брандмауер, DNS, веб-проксі, Zeek, NetFlow | Хто спілкувався з ким, скільки даних переміщено, які домени вирішено |
| Хмарна контрольна площина | AWS CloudTrail, Azure Activity Log, GCP Audit Logs, Kubernetes audit | Які виклики API змінили інфраструктуру, роль або політики |
| Програми та SaaS | Журнали доступу веб-сервера, Microsoft 365 Unified Audit Log, Google Workspace | Що користувачі робили всередині бізнес-аплікацій і сховищ даних |
| Контроль безпеки | EDR, IDS/IPS (Suricata), WAF, поштовий шлюз | Що вже відмітили інші інструменти, і чому |
Найцінніші знахідки зазвичай знаходяться на стиках. Спроба Kerberoasting з’являється як кластер запитів 4769 з шифруванням RC4 у журналах ідентичності. Докази того, що зломисник зробив з обліковим записом служби із зламаним паролем, вимагають даних кінцевого пункту і хмари.
Які є спільні формати і структури файлів журналів?
Журнали варіюються від повністю структурованих до вільнотекстових, і навантаження на розбір зростає відповідно. Чотири формати охоплюють більшість того, з чим SOC стикається щодня.
Syslog. Досі лінгва франка для мережевих пристроїв і Unix-хостів. RFC 3164 (BSD syslog) слабо визначений і бідний на часові позначки. RFC 5424 додає поле версії, часові позначки ISO 8601, MSGID і блок STRUCTURED-DATA, але саме повідомлення часто є вільним текстом від вендора.
CEF. Загальний формат подій ArcSight охоплює події заголовком, розділеним трубами, з подовженнями у вигляді ключ=значення:
CEF:0|Acme|FW|7.2|4625|Logon failure|5|src=10.1.4.22 suser=jdoe dst=10.1.0.5
Легкий для розбору, але поверхневий, і вендори по-різному відображають поля. LEEF, що використовується QRadar, слідує тій самій ідеї.
JSON і NDJSON. За замовчуванням для хмарних та SaaS аудиторських журналів. Одна об’єкція на рядок робить NDJSON потоковим, але глибока вкладеність і масиви ускладнюють сплощення в фіксовану схему.
Windows EVTX. Бінарний формат нарізаних записів, що містять дані події XML. Ви не можете grep його; він потребує спеціалізованого розбірника, а корисні поля знаходяться в EventData.
Практичний тест для інструмента аналізу – чи поглинає він всі чотири формати нативно, без того щоб аналітик писав скрипти перетворення під час інциденту.
Моніторинг журналів у реальному часі
Моніторинг у реальному часі означає оцінювання подій по мірі їх прибуття, а не за розкладом пошуку. Запланований запит SIEM, що виконується кожні 15 хвилин за вікном ревізії 20 хвилин, із затримкою в прийомі та індексації в кілька хвилин, може легко поставити півгодини між дією зловмисника і першим сигналом тривоги.
Потокові архітектури усувають цю прогалину, переміщуючи логіку виявлення вище по потоку. Події проходять через шину, таку як Kafka, або через конвеєр, такий як Cribl Stream, і правила оцінюються в польоті зі станочними вікнами для підрахунку і послідовності. Тільки збагачені, позначені події та сигнали переходять до SIEM, що також знижує витрати на прийом.
Це породжує три інженерні проблеми:
- Пізні та неупорядковані події. Вікна потребують водяних знаків або періодів благодаті, інакше послідовність, розділена на відкладений пакет, ніколи не завершиться.
- Управління станом. Відстеження 10,000 хостів протягом 30-хвилинного вікна – це проблема пам’яті, а не запиту.
- Обсяг сигналів. Швидше виявлення шумних правил лише створює шум швидше.
Потокові конвеєри в реальному часі також мають сліпу зону за дизайном. Вони бачать лише те, що підключене до них. Журнали, витягнуті з ізольованого сервера, підрядницького ноутбука або новопридбаної дочірньої компанії, все ще потребують швидкого, автономного аналізу.
Які є основні техніки розпізнавання шаблонів у журналах?
Розпізнання шаблонів у журналах працює на рівнях, від окремих подій до цілих ланцюгів атак.
- Атомне співпадання. Одна подія, одна умова: відомий поганий хеш, rundll32.exe, що завантажується з каталогу, до якого можуть писати користувачі, або правило Sigma щодо підозрілого командного рядка. Швидкий і точний, але сліпий до всього, що є шкідливим тільки в контексті.
- Агрегація та пороги. Підрахунок за вікном. Двадцять невдалих спроб входу до одного облікового запису свідчать про грубу силу; одна невдала спроба кожна до двадцяти облікових записів з одного джерела свідчить про розпилення паролів. Один ідентифікатор події, різний шаблон.
- Кореляція послідовності. Упорядковані події в часовому вікні, такі як новий локальний адміністратор, створений і потім використаний для входу RDP протягом десяти хвилин.
- Базування та виявлення аномалій. Перші помічені батьківсько-дочірні пари процесів, рідкі рядки агентів-користувачів, входи поза нормальними годинами користувача.
- Кореляція вищого рівня. Правила, що виконуються поверх виявлень, а не сирих подій, зшиваючи індивідуальні попадання в ланцюг, нанесений на тактики MITRE ATT&CK. Це той шар, який перетворює 400 сигналів на один інцидент.
Які є основні інструменти аналізу журналів?
Жоден окремий продукт не охоплює всю роботу. Зрілі команди поєднують інструменти аналізу журналів з чотирьох категорій.
| Категорія | Приклади | Найкраще підходить для |
| SIEM | Splunk, Microsoft Sentinel, Google SecOps, Elastic Security | Централізоване виявлення, тріаж сигналів, управління кейсами |
| Потоки даних безпеки | Cribl Stream, Vector, Fluent Bit | Маршрутизація, фільтрація, нормалізація та контроль витрат перед зберіганням |
| Озерні дані | Amazon Security Lake (OCSF), Snowflake, ClickHouse | Дешеве довгострокове зберігання і масштабне полювання |
| Інструменти DFIR | Hayabusa, Chainsaw, EvtxECmd, Velociraptor | Швидкий тріаж зібраних артефактів, зокрема EVTX |
Прогалини виявляються під час реагування на інциденти. SIEM передбачає, що дані вже на борту. Інструменти DFIR швидкі, але працюють з обмеженим набором правил і залишають кореляцію на відповідальність аналітика. Загального призначення LLM стикається з обмеженнями контексту і відмовляє вміст безпеки. Інструмент, створений для першої години інциденту, потребує короткого списку властивостей:
- нативне поглинання EVTX, syslog, CEF і JSON
- велику, підтримувану бібліотеку виявлень, а не кілька сотень правил
- кореляція в ланцюги атак, а не в плоский список попадань
- результати за хвилини на товарній інфраструктурі
- модель конфіденційності, що переживе перевірку DPO
Чому LogTotal – один з кращих?
LogTotal відмічає кожен пункт цього списку, і він робить це безкоштовно. SOC Prime відкрив його як громадський попередній перегляд 26 серпня 2026 року і оголосив про загальний випуск 15 жовтня. Робочий процес простий: завантаження, санітаризація, отримання розслідування назад.
| Вимога | Як LogTotal задовольняє її |
| Нативні формати | Автоматично виявляє EVTX, JSON/NDJSON і syslog, без етапу конвертації |
| Глибина виявлень | Підходить події близько 1,000,000 правил виявлення і 13,000 міток загроз |
| Кореляція | Вищого порядку правила Sigma плюс агентна AI кореляція створюють ланцюги атак, нанесені на MITRE ATT&CK |
| Швидкість | До 1,7 мільйона подій менше ніж за хвилину, приблизно в 100 разів більше, ніж набір журналів Hugging Face |
| Конфіденційність | Санітаризація виконується у браузері, нічого не зберігається, і дані клієнтів не використовуються для навчання |
Швидкість – це не трюк GPU. Міркування про те, як виглядає кожна атака, були виконані заздалегідь і скомпільовані в зміст виявлення, тому двигун виконує підходження та кореляцію, а не генерує токени.
Модель конфіденційності – це те, що дозволяє LogTotal пройти юридичну перевірку. Відкритий вихідний код @socprime/logtotal-sanitizer (Apache-2.0) змінює облікові дані, IP-адреси, імена хостів та імена користувачів на стабільні HMAC токени, тому один користувач на трьох хостах залишається однією сутністю після редагування. Ви зберігаєте ключ. Кожен аналіз виконується на одноразовому, незмінному екземплярі, який потім видаляється.
Знахідки надходять у вигляді ранжованих ланцюгів атак, з прапорами для стелс-технік та сплесків нешкідливої активності, що є типовими для проникнень на основі ІІ.
Головні тенденції аналізу журналів у 2026 році
П’ять зрушень переформатовують те, як команди аналізують журнали в цьому році.
- Швидкість атак на основі ІІ змінює те, що виглядає “підозрілим”. IBM повідомляє, що більше ніж одна з чотирьох організацій зазнала атаки на основі ІІ, що на 56% більше рік до року. Об’ємні аномалії в нешкідливих класах подій самі по собі стають сигналом виявлення.
- SIEM ділиться. 2026 Hype Cycle для операцій безпеки Gartner показує розподіл ринку на інтегровані SOC платформи та озерні дані безпеки, з AI SOC агентами на піку завищених очікувань. Аналіз все більше відбувається там, де живуть дані.
- Детекція переміщується у поток. Запуск правил на потоці, перед індексацією, знижує як середній час виявлення, так і витрати на прийом.
- OCSF стає спільною схемою. Нормалізовані дані – це то, що дозволяє одному і тому ж виявленню, або одному і тому ж AI агенту, працювати між вендорами.
- Аналіз, що зберігає конфіденційність, стає стандартною практикою. IBM підрахувала тіньовий-ІІ участь у 43% інцидентів, з 20%. Вставлення сирих журналів у чат-бот – це саме те. Псевдонімізація з ключем перед тим, як журнали покинуть організацію, перетворюється з хорошої практики на очікування.
Спільна нитка – це швидкість без розголошення. Це проблема, яку LogTotal був розроблений для вирішення, і ніщо не коштує протестувати його на власних журналах.
