SIEM: що це й як система збирає події безпеки в одну картину

У середній компанії журнали ведуть десятки джерел: сервери, робочі станції, мережеве обладнання, антивірус, поштовий шлюз, хмарні сервіси. Разом вони пишуть десятки тисяч рядків щодоби. Прочитати такий потік вручну неможливо, а зловмисник рідко лишає один яскравий слід — його дії розсипані по різних журналах і поодинці виглядають буденно. Звести все докупи й покликати людину лише тоді, коли справді є привід, — робота SIEM.

SIEM: що це й звідки взявся термін

Повна назва англійською — Security Information and Event Management. Українською її передають так: SIEM — управління інформацією та подіями безпеки.

Технічно ж SIEM — програмна платформа, яка забирає журнали з усіх систем організації, зводить їх до єдиного формату, зіставляє записи між собою за правилами й показує лише те, на що варто витратити увагу аналітика. Замість десятків розрізнених консолей адміністратор отримує одне вікно.

Звідки взялася назва

Термін увели в обіг 2005 року аналітики Gartner Марк Ніколетт і Амріт Вільямс. До того ринок ділився надвоє:

• SIM (Security Information Management) — тривале зберігання журналів, аналітика заднім числом, звітність для аудиторів;
• SEM (Security Event Management) — оброблення потоку в реальному часі, кореляція, сигнали тривоги.

Обидві половини склали докупи — і вони донині описують дві ролі платформи: «зберігати все» й «сигналізувати про важливе зараз».

Про варіанти розшифрування

У тендерах і каталогах постачальників трапляється формулювання SIEM — управління інцидентами та подіями безпеки, а подеколи й зворотний порядок слів: управління інцидентами та подіями безпеки — SIEM. Розшифрування неточне: в оригіналі стоїть information, а не incidents. Різниця принципова. Платформа працює з потоком записів, тоді як опрацювання самих інцидентів — окремий процес із людьми, ролями й строками.

Для SIEM подія — сировина, а не тривога

Подія (event) — будь-який зафіксований факт: успішний вхід, невдала спроба входу, підключення накопичувача, зміна прав доступу, спрацювання правила фаервола, звернення до застосунку. Переважна більшість таких записів абсолютно безневинні — саме тому їх не показують людині поодинці.

Натомість атака майже завжди складається з ланцюжка буденних на вигляд фактів. Двадцять невдалих входів — випадковість. Двадцять невдалих входів, один успішний, а слідом підвищення прав і звернення до файлового сховища о третій ночі — уже сценарій. Жоден окремий рядок тут не виглядає «поганим»; підозріла їхня послідовність.

Тому платформа не оцінює записи поодинці. Уся її цінність — у зв'язках між ними. Межу між сповіщенням і підтвердженим інцидентом детально розібрано в матеріалі про те, як сигнал стає керованим інцидентом.

Джерела: звідки беруться записи

Сама по собі SIEM події не створює — усі вони народжуються в інших системах. Питання лише в тому, які саме джерела підключити. Типовий перелік:

• операційні системи серверів і робочих станцій — входи, зміни прав, запуск процесів;
• мережеве обладнання: маршрутизатори, комутатори, проксі, VPN-шлюз;
• захист застосунків — WAF перед сайтом і клієнтським кабінетом;
• служба каталогів — облікові записи, групи, політики;
• антивірус і EDR на кінцевих пристроях;
• пошта — шлюз, фільтр спаму, карантин;
• DNS і DHCP — недооцінені джерела: чимало шкідливих програм видають себе саме запитами до дивних доменів;
• бізнес-застосунки й бази даних — доступ до чутливих таблиць;
• хмара — журнал дій в обліковому записі провайдера.

Агент чи без агента

Забрати журнал можна двома способами. Агент — невелика програма на самому джерелі: читає локальні файли, буферизує їх, шифрує канал і переживає короткі розриви зв'язку. Безагентний збір — коли джерело саме надсилає рядки протоколом syslog або віддає їх через API. Агент дає більше контролю, безагентний спосіб дешевший в обслуговуванні; на практиці зазвичай працюють обидва.

Пастка, на якій спотикаються майже всі: годинник

Кореляція тримається на часових мітках. Якщо на одному сервері годинник відстає на десять хвилин, ланцюжок «спроба входу → успіх → підвищення прав» просто розсиплеться: платформа побачить три непов'язані факти в різні моменти. Тому синхронізація годинників — обов'язкова умова працездатності всієї конструкції.

Додаток А ISO 27001 містить три суміжні контролі поспіль: A.8.15 «Журналювання», A.8.16 «Діяльність з моніторингу» й A.8.17 «Синхронізація годинників». Сусідство не випадкове: без спільного часу перші два контролі втрачають сенс.

Конвеєр: від сирого рядка до сигналу тривоги

1. Збір. Платформа під'єднується до джерел і забирає їхні журнали.
2. Розбір і нормалізація. Рядок Windows, рядок Linux і рядок фаервола написані по-різному. Модуль розбору розкладає їх на однакові поля — хто, коли, звідки, куди, з яким результатом. Лише після цього події з різних систем стають порівнюваними.
3. Збагачення. До запису додають контекст: чий пристрій, наскільки критичний актив, чи фігурує адреса в стрічках індикаторів загроз (наприклад, у MISP).
4. Кореляція. Ядро платформи. Сценарій описують правилом — набором умов і вікном часу, у якому вони мають зійтися.
5. Сповіщення. Спрацювало правило — виникає тривога з пріоритетом.
6. Зберігання й звітність. Записи лягають у сховище: для розслідувань, аудитів і ретроспективного пошуку.

Як влаштована кореляція

Правила бувають кількох типів:

• порогові — «понад N однотипних спроб за M хвилин»;
• послідовності — «А, потім Б, потім В у межах години»;
• зіставлення з переліками — звернення до адреси з переліку індикаторів компрометації;
• статистичні, поведінкові (UEBA) — «цей обліковий запис уперше за рік вивантажує гігабайти з файлового сервера о четвертій ранку».

Порогові правила прості й галасливі; поведінкові тонші, зате потребують періоду навчання й чистих вхідних даних.

SIEM: IT-безпека, зведена в одне вікно

Що організація дістає від SIEM на практиці:

• єдина картина замість десятків розрізнених консолей;
• виявлення розподілених атак, слід яких розпорошено по кількох системах;
• швидкий пошук в архіві: «хто заходив із цієї адреси за пів року»;
• упорядковані докази з мітками часу — для внутрішнього розбору чи звернення до правоохоронців;
• звітність для аудиту й регуляторних вимог;
• вимірність: скільки тривог за добу, скільки з них хибних, як довго їх розбирають.

Хибні спрацювання: чому «увімкнув і забув» не працює

Щойно розгорнута платформа з типовими правилами стандартної поставки видає сотні тривог на добу, й майже всі вони хибні. Через тиждень аналітик перестає їх читати, а через місяць справжня атака губиться в шумі. Явище має назву — втома від сповіщень (alert fatigue).

Ліки — не «менше правил», а їх донастроювання:

• завести перелік відомих винятків: сканер уразливостей, резервне копіювання, службові облікові записи;
• прибрати правила без власника й без плану дій — тривога без сценарію реагування марна;
• почати з вузького набору сценаріїв, вивірити його, а лише потім розширювати;
• переглядати правило після кожного розбору — й після хибного спрацювання, й після справжнього.

Тут діє груба, але чесна формула: сміття на вході — сміття на виході. Платформа лише впорядковує журнали; підвищити їхню якість вона безсила.

Економіка журналів: скільки коштує «зберігати все»

Ліцензію рахують або за обсягом (гігабайти на добу), або за темпом (подій за секунду, EPS). Звідси головний організаційний конфлікт: інженер хоче підключити ще одне джерело, фінансист бачить рахунок. Наслідок передбачуваний — з бюджету випадають «неважливі» журнали, а потім саме їх бракує під час розслідування.

Робочий компроміс — рівні зберігання:

• гарячий (дні–тижні) — миттєвий пошук, дорогий;
• теплий (місяці) — повільніший, помітно дешевший;
• холодний архів (роки) — довге вивантаження, мінімальна вартість.

Строк зберігання визначають не «на око», а з двох боків: скільки потрібно для розслідування (зловмисника нерідко виявляють через місяці після проникнення) і скільки вимагають регулятор, галузеві правила й договори з клієнтами.

Окрема вимога — цілісність. Той, хто зламав сервер, насамперед чистить локальні журнали. Тому копію надсилають у сховище лише на дописування (WORM), а адміністратор системи не повинен мати прав видаляти її журнали.

Чого SIEM не робить

• Не блокує. Платформа бачить і сигналізує; зупиняють атаку інші засоби — фаервол, WAF, EDR.
• Не замінює людей. Без тих, хто розбирає тривоги, вона перетворюється на сирену в порожньому приміщенні. Хто саме цим займається — у матеріалі про центр операцій безпеки (SOC).
• Не бачить того, чого не записують. Вимкнене журналювання на джерелі — сліпа пляма, й жодне правило її не заповнить.
• Не є планом дій. Порядок кроків після підтвердження загрози описує план реагування на кіберінциденти, а стандартну модель процесу — ISO/IEC 27035.

Поруч існують суміжні класи засобів, з якими платформу регулярно плутають:

Спрощено: SIEM знаходить проблему, SOAR відпрацьовує реакцію за сценарієм, EDR дотягується до конкретного пристрою.

З чого почати невеликій компанії

Повноцінна платформа для команди з п'яти осіб — надмір. Але базове журналювання потрібне будь-кому. Мінімальний набір джерел, з якого варто починати:

1. служба каталогів або контролер домену — входи й зміни прав;
2. поштовий шлюз — найпоширеніші двері для зловмисника;
3. периметровий фаервол — передусім вихідні з'єднання назовні;
4. антивірус чи EDR на робочих станціях;
5. журнал дій у хмарному обліковому записі.

Далі — три прості умови: єдиний час на всіх машинах, копія журналів поза межами самого джерела й призначена людина, яка їх переглядає. Це ще не платформа кореляції, але вже й не темрява.

Підсумуємо. SIEM — не щит, а зір: вона не зупиняє атаку, зате перетворює хаос розрізнених журналів на впорядковані події безпеки, з якими вже здатна працювати людина.