Стежити Корпоративне середовище генерує мільйони подій щогодини. Під час інциденту реагуючому рідко потрібні всі ці події. Їм потрібні кілька сотень, які розповідають історію: сплеск невдач 4625, що супроводжуються одним успішним виявленням 4624, закодована PowerShell, запущена winword.exe, нова служба, встановлена о 03:12 на контролері домену. Аналіз журналів – це дисципліна, яка дозволяє перейти від першого числа до другого достатньо швидко, щоб це мало значення.
Це завдання стало важчим у двох напрямках одночасно. Атакуючі, які використовують інструменти на основі штучного інтелекту, генерують докази на швидкості машини та заповнюють реальні дії діяльністю, яка виглядає безпечною. Тим часом явний спосіб вивантажити журнали в LLM натрапляє на обмеження захисних механізмів, обмеження контексту вікна та зобов’язання щодо захисту даних. Обробники Hugging Face натрапили на цю стіну у липні 2026 року, коли близько 17 000 подій було відхилено передовими моделями і їх довелося обробляти на локальній моделі.
Нижче ми детально розглянемо аналіз журналів, а потім звернемо увагу на LogTotal, безкоштовну відповідь SOC Prime на версію проблеми під час інциденту.
Які основи аналізу журналів?
Кожен робочий процес аналізу журналів, незалежно від того, чи працює він у SIEM, сховищі даних або на ноутбуці реагуючого, спирається на ті самі п’ять стадій. Пропуск однієї зазвичай з’являється пізніше у вигляді пропущеного виявлення або хибного спрацювання, яке ніхто не може пояснити.
- Збір. Агенти, пересильники syslog, опитувачі API та експортатори, що працюють на основі хмарних принципів, переміщують події з джерела. Пропуски тут безмовні: конфігурація Sysmon, яка відкидає події з Event ID 10 (доступ процесу), означає, що витік облікових даних через LSASS ніколи не з’являється далі.
- Парсинг та нормалізація. Сирі рядки стають полями. Джерело IP повинне бути тим самим полем, незалежно від того, чи воно надійшло з брандмауера, IdP чи EDR, саме тому існують схеми на зразок ECS та OCSF.
- Збагачення. Критичність активів, роль користувача, GeoIP та загрозова інформація перетворюють IP адресу в контекст, на який аналітик може реагувати.
- Кореляція. Одинокі події рідко щось доводять. Пов’язування їх за допомогою хоста, користувача, GUID процесу або ID сеансу є тим, що створює наратив атаки.
- Збереження та цілісність. Гаряче зберігання для пошуку, холодне зберігання для судово-медичної експертизи і свідоцтво про несанкціоновані зміни, щоб записи залишились достовірними.
Що таке аналіз журналів?
Аналіз журналів — це процес вивчення записів, згенерованих машиною, щоб відтворити те, що сталося на системі, вирішити, чи це має значення, і визначити, що робити далі. У сфері безпеки це відповідає на п’ять запитань щодо будь-якої підозрілої діяльності: хто діяв, на якому активі, коли, звідки і яким механізмом.
Це відрізняється від управління журналами. Управління — це водопровід: прийом, зберігання, збереження, контроль доступу. Аналіз — це інтерпретація. Команда може мати добре налагоджену систему управління журналами і все ж таки пропустити вторгнення, тому що ні людина, ні машина не ставлять дані правильні запитання.
На практиці аналіз журналів відбувається у трьох режимах:
- Виявлення. Правила та моделі безперервно оцінюють події та видають попередження, коли з’являється відома шкідлива поведінка.
- Розслідування. Після попередження або підказки аналітики переходять до пов’язаних подій, щоб визначити масштаб інциденту і знайти основну причину.
- Полювання за загрозами. Аналітики починають з гіпотези, такої як зловживання конкретним LOLBin, і проактивно шукають докази, які упустив шар виявлення.
З усіх команд, які використовують журнали, у безпеки найменше місця для прогалин.
Чому так важливо аналізувати журнали?
Тому що час визначає вартість порушення, і журнали — це місце, де час виграється або втрачається. Звіт IBM 2026 року про вартість витоку даних показує, що середній час виявлення та обмеження порушення становить 247 днів, що є першим зростанням за п’ять років. Витоки з тривалістю більше 200 днів у середньому коштують 5,65 мільйонів доларів, проти 4,32 мільйонів для тих, що були обмежені швидше.
Окрім вартості, аналіз журналів підтримує чотири зобов’язання, які має кожна програма безпеки:
- Виявлення. EDR та NDR бачать частини активності. Журнали від постачальників ідентичності, SaaS-треки аудиту та контрольні панелі хмар заповнюють проміжки між ними.
- Визначення масштабу та основної причини. Без доказів на рівні подій реагуючі не можуть сказати, які облікові записи були пошкоджені або як атакуючий проник, тому процес усунення помилок стає припущенням.
- Регуляторна звітність. Вимога PCI DSS 4.0 пункту 10 вимагає перевірки журналів аудиту та зберігання на 12 місяців. Форма SEC 8-K пункт 1.05 надає публічним компаніям чотири ділових дні після визначення матеріальності, що неможливо без швидкого визначення масштабу.
- Інженерія виявлення. Реальна телеметрія — це спосіб тестування та налаштування правил.
Є одне застереження. Ті самі журнали, які роблять усе це можливим, містять імена користувачів, IP-адреси, куки сеансів і маркери носіїв. Їхній детальний аналіз дедалі частіше означає безпечний аналіз.
Які типи даних журналів існують?
Журнали, що мають значення для безпеки, діляться на шість груп. Кожна з них відповідає на різні питання, і розслідування, яке базується лише на одній чи двох з них, матиме сліпі зони, в яких зможе пересуватися атакуючий.
| Сімейства журналів | Типові джерела | Що це говорить аналітику |
| Кінцева точка та ОС | Безпека Windows (4624, 4688, 7045), Sysmon, Linux auditd, journald | Який процес відбувся, під яким обліковим записом, з яким батьком та командним рядком |
| Ідентичність | Active Directory (4768, 4769), входи Entra ID, системний журнал Okta | Хто аутентифікувався, звідки, з яким протоколом та результатом MFA |
| Мережа | Брандмауер, DNS, веб-проксі, Zeek, NetFlow | Хто з ким спілкувався, скільки даних передано, які домени розв’язані |
| Контрольний обліковий запис у хмарі | AWS CloudTrail, журнал дій Azure, журнали аудиту GCP, аудит Kubernetes | Які API-виклики змінили інфраструктуру, ролі чи політики |
| Додатки та SaaS | Журнали доступу до веб-серверів, об’єднаний журнал аудиту Microsoft 365, Google Workspace | Що користувачі робили всередині бізнес-додатків і сховищ даних |
| Засоби безпеки | EDR, IDS/IPS (Suricata), WAF, шлюз електронної пошти | Що вже відзначили інші інструменти і чому |
Найбільш цінні знахідки зазвичай зустрічаються на стиках. Спроба Kerberoasting з’являється як кластер запитів 4769 з RC4-шифруванням у журналах ідентичності. Щоб довести, що атакуючий робив з розкритим обліковим записом служби, потрібні дані кінцевих та хмарних точок.
Які загальні формати та структури файлів журналів існують?
Журнали варіюються від повністю структурованих до вільного тексту, а навантаження на парсинг відповідно масштабується. Чотири формати покривають більшість випадків, з якими СОЦ стикається щодня.
Syslog. Досі лінгва франка для мережевих пристроїв і хостів Unix. RFC 3164 (BSD syslog) ледь визначений і бідний на часові позначки. RFC 5424 додає поле версії, часові позначки ISO 8601, MSGID і блок STRUCTURED-DATA, але саме тіло повідомлення часто є специфічним для постачальника вільним текстом.
CEF. Загальний формат подій (Common Event Format) ArcSight огортає події в заголовок з розділювачем “|” з наступними розширеннями key=value:
CEF:0|Acme|FW|7.2|4625|Невдача входу|5|src=10.1.4.22 suser=jdoe dst=10.1.0.5
Це легко для парсинга, але поверхнево, і постачальники поля визначають нестандартно. LEEF, що використовується QRadar, слідує тієї ж ідеї.
JSON та NDJSON. Стандарт де-факто для хмарних і SaaS журналів аудиту. Один об’єкт на рядок робить NDJSON потоковим, але глибоке вкладення і масиви ускладнюють приведення у фіксовану схему.
Windows EVTX. Бінарний формат блочних записів, що містить XML-дані подій. Ви не можете провести пошук у ньому; потрібен спеціальний парсер, і корисні поля знаходяться в EventData.
Корисним тестом для будь-якого інструмента аналізу є питання, чи він імпортує всі чотири з цих форматів без аналітичного написання скриптів перетворення під час інциденту.
Моніторинг журналів у режимі реального часу
Моніторинг у реальному часі означає оцінювання подій по мірі їхньої появи, а не за розкладом пошуку. Запланований запит SIEM, що запускається кожні 15 хвилин у 20-хвилинному вікні перегляду, із затримкою кілька хвилин на прийом і індексацію, може легко поставити півгодини між дією атакуючого й першим попередженням.
Архітектури потокової передачі закривають цей розрив, переміщуючи логіку виявлення вгору за потоком. Події проходять через шину, таку як Kafka, або через конвеєр, такий як Cribl Stream, і правила оцінюються в польоті з вікнами, що зберігають стан, для підрахунків і послідовності. Тільки збагачені, помічені події та попередження йдуть до SIEM, що також зменшує вартість прийому.
Три інженерні проблеми супроводжують це:
- Пізні та невпорядковані події. Вікна потребують водяних знаків або граціозних періодів, або послідовність, розбита на затриманий набір, ніколи не завершується.
- Керування станом. Відстеження 10 000 хостів за 30-хвилинне вікно – це проблема пам’яті, а не проблема запиту.
- Обсяг попереджень. Швидше виявлення галасливих правил лише генерує шум швидше.
Реальночасові конвеєри також мають сліпу зону за дизайном. Вони бачать лише те, що підключено до них. Журнали, отримані з ізольованого сервера, ноутбука підрядчика або нещодавно придбаного дочірнього підприємства, все ще потребують швидкого, автономного аналізу.
Які основні техніки розпізнавання шаблонів у журналах?
Розпізнавання шаблонів у журналах працює на різних рівнях, від одиничних подій до цілих ланцюгів атак.
- Атомарне співставлення. Одна подія, одна умова: відомий поганий хеш, rundll32.exe, завантажений з шляху, що записується користувачем, правило Sigma на підозрілому командному рядку. Швидке та точне, але сліпе до всього, що шкідливо лише в контексті.
- Агрегація та пороги. Підрахунок через вікно. Двадцять невдалих входів для одного облікового запису вказують на брутфорс; одна невдача для кожного з двадцяти рахунків з одного джерела вказує на розпилювання паролів. Та ж ID події, інший шаблон.
- Кореляція послідовності. Впорядковані події в межах тимчасового вікна, такі як новий локальний адміністратор, створений, а потім використаний для входу через 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 пройти юридичний перегляд. Open-source @socprime/logtotal-sanitizer (Apache-2.0) замінює облікові дані, IP, хости та імена користувачів на стабільні HMAC токени, тож один користувач за трьома хостами залишається однією сутністю після редагування. Ви зберігаєте ключ. Кожен аналіз виконується на одноразовій, незмінній копії, яка після завершення видаляється.
Знаходження прибувають у вигляді ранжованих ланцюгів атак із прапорами для технічних прихованих методик та сплесків безпекової активності, типової для нападів, керованих AI.
Основні тенденції аналізу журналів у 2026 році
П’ять зрушень змінюють те, як команди аналізують журнали цього року.
- Напади на швидкості AI змінюють вигляд “підозрілого”. IBM повідомляє, що більше чверті організацій зіткнулися з нападом, керованим AI, із зростанням на 56% в порівнянні з попереднім роком. Аномалії об’ємів у класах безпечних подій стають сигналом виявлення самі по собі.
- SIEM розділяється. Цикл ажіотажу Gartner 2026 року для операцій безпеки показує, що ринок ділиться на інтегровані платформи СОЦ і сховища даних безпеки, із агентами AI СОЦ на піку завищених очікувань. Аналіз все частіше відбувається там, де знаходяться дані.
- Виявлення переміщується у конвеєр. Запуск правил у потоці, до індексації, зменшує середній час виявлення та витрати на прийом.
- OCSF стає загальною схемою. Нормалізовані дані – це те, що дозволяє одному і тому ж виявленню, або тому самому агенту AI, працювати у різних постачальників.
- Аналіз, що зберігає конфіденційність, стає стандартною практикою. IBM нарахувала участь тіньового AI в 43% інцидентів, зрісши з 20%. Вставляння сирих журналів у чат-бота – це саме те. Псевдонімізація з ключем, перед тим як журнали покинуть організацію, перетворюється з доброї практики в очікування.
Загальний мотив – це швидкість без витоку. Це проблема, для вирішення якої був створений LogTotal, і не коштує нічого, щоб перевірити його на ваших власних журналах.
