Събиране, обогатяване и обработка на логове чрез решения с отворен код. Анализиране, обясняване и откриване на аномалии в логове с използване на големи езикови модели.
Open source collection, decoding and enriching logs. Analyzing, explaining and anomaly detection using large language models (LLM)
В тази статия представяме примерно решение (Proof of Concept), базирано изцяло на технологии с отворен код и имплементирано локално в собствена инфраструктура.
Обработката на логове с използване на AI технологии и по-специално големи езикови модели (LLM) е изключително активно развивано в последно време. По разбираеми причини, преобладават комерсиални разработки и се предлагат предимно като клауд базирани услуги на съответните доставчици (Elastic, Splunk, ATT Cybersecurity и много други).
Основните принципи на представеното решение са:
- Събиране на широк набор от логове, например:
- Системни логове (syslog) – Linux, Windows, Mac
- Логове от приложения (например уеб сървъри)
- Инсталационни логове / Install logs
- Логове от мрежови устройства / Network logs
- Логове от файъруоли / Firewall logs
- HIDS (Host Intrusion Detection Systems) и NIDS (Network Intrusion Detection Systems) logs
- Обогатяване на логовете, например:
- Добавяне на геолокация по IP адрес
- Корелация на събития
- Локална обработка на логове – макар да е възможна реализация на системата в публични клауд услуги, ако организацията желае да упражнява пълен контрол над своите логове, те може да се събират, обработват и съхраняват локално
- Евтино дългосрочно съхраняване на събраната информация – без зависимост от ценовата политика и ограниченията на доставчици на решения за обработка на логове
- Възможност за AI обработка на логове с използване на локални големи езикови модели (Local LLM), това позволява:
- Контрол над разходите – при комерсиалните езикови модели се заплаща на “token” входяща и изходяща комуникация със съответния модел.
- За сравнение – ако се използва комерсиален LLM, едно изпълнение на описаната по-долу обработка на логове (доста ограничена по обем) през API на OpenAI ще струва около $0.1 – интензивната обработка на големи обеми логове е с доста висока себестойност при използване на комерсиални решения
- Контрол на информацията –
- Логовете на компанията не излизат извън неин контрол/юрисдикция
- Чувствителна по отношение на сигурността информация не излиза извън рамките на компанията
- Комерсиалните доставчици на LLM не използват тази информация за обучение на своите модели
- По-високо бързодействие – то изцяло зависи от използвания ресурс, а не от споделеното използване на клауд услуга
Лог процесори
Съществуват множество популярни опън сорс средства за събиране и обработка на логове (за които имаме статии в блога), например:
- Те осигуряват декодиране на логовете, обогатяване с допълнителна информация и прилагане на правила и корелации (rules and correlations), с които редуцираме обема на информацията за анализиране, което оптимизира бързодействието на езиковите модели, качеството и себестойността на анализа.
Тестова постановка
- За събиране, обработка и обогатяване на логовете използваме Wazuh
- Wazuh позволява да редуцураме излишния шум и се съсредоточим само до тип и клас събития, които са важни
- LLM (Large Language Model) – за гарантиране сигурността на логовете (не напускат нашия контрол) и контрол на разходите използваме допълнително настроен (fine tuning) LLM базиран на mistral-7b.
- Добри резултати се получават и с Qwen1.5 или Phi-3-Minи.
- За фина настройка са използвани access, setup, file logs и допълнителна информация като описание на команди и дефиниране на потенциални заплахи и рискови състояния
- Работа с локални LLM – този въпрос не се разглежда поради тривиалност. Има много статии по въпроса, добра отправна точка е тази статия:
- Обработка на лог събития с LLM – използва се LangChain
- Вариант с писане на код – например
- Вариант с LowCode платформа
- n8n
- Примерно n8n workflow е свободно достъпно при заявка
- Използван хардуер
- Wazuh – според препоръките за размер на необходимата инфраструктура
- GPU server за поддръжка на локален LLM (Large Lаnguage Model)
- GPU: Nvidia 30xx, 40xx, Axxxx
- Поне 16GB VRAM
- Препоръчително 24GB VRAM
- Оптимално 32-48GB VRAM
Експеримент
13:38:38 - ps ax |grep ps
13:38:42 - exit
13:38:44 - w
13:38:50 - last
13:39:00 - ls -lah
13:39:21 - chmod 770 nmapscan.py
13:39:40 - joe nmapscan.py
134:0:49 - ./nmapscan.py
13:40:33 - passwd
13:40:37 - w
Jun 12, 2024 @ 13:40:33.262 Command: “ 165 passwd” executed by root in logai1
Jun 12, 2024 @ 13:39:49.400 Command: “ 164 ./nmapscan.py” executed by root in logai1
Jun 12, 2024 @ 13:39:49.400 Command: “ 163 joe nmapscan.py]” executed by root in logai1
Jun 12, 2024 @ 13:39:40.792 Command: “ 163 joe nmapscan.py” executed by root in logai1
Jun 12, 2024 @ 13:39:21.183 Command: “ 162 chmod 770 nmapscan.py” executed by root in logai1
Jun 12, 2024 @ 13:39:00.751 Command: “ 161 ls -lah” executed by root in logai1
Jun 12, 2024 @ 13:38:50.740 Command: “ 160 last” executed by root in logai1
Jun 12, 2024 @ 13:38:44.734 Command: “ 159 w” executed by root in logai1
Jun 12, 2024 @ 13:38:42.738 Command: “ 158 exit” executed by root in logai1
Jun 12, 2024 @ 13:38:38.733 Command: “4 ps ax |grep ps” executed by user in logai1
- Промпт към LLM – имаме следните цели:
- Ясна задача
- Предотвратяване на халюцинации
- Недопускане на отклонения
- Дефиниране на нормалност
I need help analyzing logs of Linux commands used by a user to identify and explain anomalies in their behavior. The logs include fields such as timestamp, user ID, command executed, and any relevant command arguments or output.
Normal user behavior typically involves:
- Common commands like but not limited to "ls", "cd", "grep", "cp", and "rm"
- Execution of commands between 8 AM and 8 PM
- Commands executed in typical sequences (e.g., "cd" followed by "ls")
Agent in these logs means the name of the computer audited.
I am interested in detecting anomalies such as:
- Execution of unusual or rarely used commands (e.g., "iptables", "shutdown", "chmod 777")
- Commands executed at unusual times (e.g., late night or early morning)
- Unexpected sequences of commands (e.g., "rm -rf" followed by "shutdown")
- Commands that could compromise security or system stability
Specific metrics to focus on:
- Frequency of security-related commands (e.g., "iptables", "passwd")
- Time intervals between potentially harmful commands
- Deviations from normal command sequences
The analysis should cover the log period and be presented with summary statistics, text based visualizations, and detailed explanations of identified anomalies, including the purpose of the command and its potential impact on security or stability.
Analyzing the provided logs from the user on the system "logai1," we can observe several commands executed and identify any anomalies or unusual patterns based on the typical user behavior and security considerations. Here's a detailed breakdown:
### Log Summary:
1. **Command Execution Times**: All commands are executed between 13:38 and 13:40, which falls within the normal operational hours (8 AM to 8 PM).
2. **Command Frequency and Sequence**:
- Common commands like ps, w, last, ls, and exit are used.
- Security-sensitive commands like chmod, passwd, and execution of a script (./nmapscan.py) are noted.
- Use of the text editor joe to edit nmapscan.py.
### Detailed Analysis:
1. **ps ax | grep ps**:
- **Purpose**: Lists all running processes and filters for processes related to ps.
- **Impact**: Generally harmless, used for monitoring or checking processes.
2. **exit**:
- **Purpose**: Exits the terminal session or a shell.
- **Impact**: Normal command, no security implications.
3. **w**:
- **Purpose**: Shows who is logged on and what they are doing.
- **Impact**: Common monitoring command, no direct security implications.
4. **last**:
- **Purpose**: Displays a list of last logged in users.
- **Impact**: Used for checking recent accesses, harmless unless used to track other users' activities for malicious reasons.
5. **ls -lah**:
- **Purpose**: Lists all files in the current directory in a detailed format.
- **Impact**: Common command, typically harmless.
6. **chmod 770 nmapscan.py**:
- **Purpose**: Changes the permissions of the file nmapscan.py to allow full permissions for the owner and group, and no permissions for others.
- **Impact**: Security-sensitive as it modifies access rights, especially relevant if nmapscan.py is a critical or sensitive file.
7. **joe nmapscan.py**:
- **Purpose**: Opens the file nmapscan.py in the Joe editor for editing.
- **Impact**: Depends on the content of nmapscan.py. If it's a script related to network scanning, modifications could be sensitive.
8. **./nmapscan.py**:
- **Purpose**: Executes the Python script nmapscan.py.
- **Impact**: Highly sensitive depending on the script's function. If it's used for network scanning, it could be used for security assessments or potentially unauthorized network activities.
9. **passwd**:
- **Purpose**: Changes the user's password.
- **Impact**: Highly sensitive, especially if used without proper authorization. Could indicate an attempt to secure an account after unauthorized access or to change another user's password.
### Anomalies and Concerns:
- **Execution of chmod 770 nmapscan.py and subsequent execution of nmapscan.py**: This sequence suggests preparation and execution of potentially impactful scripts, which could be used for network scanning or other activities that might affect system/network security.
- **Use of passwd**: Needs to be validated if it was authorized. Frequent or unauthorized use can be a security concern.
### Recommendations:
- **Review the purpose and content of nmapscan.py** to ensure it complies with organizational policies.
- **Audit the use of passwd** to confirm it aligns with security policies and that there was no unauthorized access.
- **Monitor for further use of sensitive commands** (chmod, passwd, script executions) to detect any pattern that might suggest malicious intent or policy violation.
This analysis should be integrated into regular security audits to ensure continuous monitoring and quick response to potential security incidents
Известия
- Крайният резултат – анализите извършени от LLM се предостяват чрез mail или messenger (Slack, Telegram…) интеграция.
- Удобно за служители по сигурността и оперативни мениджъри е получаването на резюме за събития с отношение към информационната сигурност на регулярни интервали от време, примерно веднъж дневно
- За оператори на системи за сигурност системата може да работи и предоставя анализи в реално (или близко до реално време с оглед необходимостта да се правят корелации и детекция на аномалии във времето).
Коментари и изводи
- LLM са доста ефективни и полезни за анализиране и обясняване на предварително обработена лог информация.
- Откриването на аномалии работи при добре изчистена информация, в зависимост от качеството на използвания промпт, но следва да се приема критично и да не се счита за окончателно
- Критично важно е LLM да получава добре изчистени от шум логове
- Възможността им да редоставят кратки резюмета и/или подробни анализи на информация и събития е изключително полезна, както за оперативни ръководители в сферата на информационната сигурност и IT операции, но също така и за оперативен персонал в сферата на сигурността
- Доколкото производителността на езиковия модел (необходимото за извършване на анализ време), както и себестойността (при локални модели – капиталовия и оперативен разход за поддръжка на необходимата IT инфраструктура)) зависят от обема на обработваната информация, силно препоръчително е подаването не на обща, а на максимално изчистена от шум и обогатена с метаданни (например IP геолокация) лог информация.
- Тоест използването на добре настроена SIEM система (например Wazuh) е изключително важно
- Текущ недостатък на LLM е склонноста им към халюцинации и отклонение от инструкциите с течение на времето. Този процес следва да се следи и да се управлява чрез наличните методи (понастоящем активно се работи в тази посока, при развитие на технологиите ще допълним статията)
- Фино настроени свободно достъпни локални LLM показват сравними с резултатите на комерсиалните модели, все пак следва да се отчита:
- Комерсиалните модели се справят по-добре при неоптимални промптове, респективно добрите промптове са ключ към ефективността
- Комерсиалните модели се справят по-добре с голям обем информация (заради по-широките си контекстуални прозорци (conеtxt window).
- Следва да се отчита, че използването на по-широки контекстуални прозорци при локалните модели предполага повече GPU памет и по-голяма нужда от производителност на хардуера
- В тази връзка, предварителната обработка на информацията, намаляването на обема и, шума, както и допълнителното и обогатяване са ключ не само за себестойността, но и за нейното качество и като цяло ефективност на концепцията.
Необходима експертиза за реализация на подобно решение
- Компонент Log processing – DevOps/SysAdmin експертиза и сериозен опит в обработка на логовеи сериозен опит в обработка на логове
- Компонент LLM – базово Python програмиране
Препоръка
- AI Based Log Processing using LLM, дори понастоящем, е доста зряла технология и вече си струва широкото и имплементиране с цел:
- Намаляване натоварването на персонал
- Повишаване възможностите за обработка и детекция на аномалии
- Повишаване видимостта върху процеси свързани със сигурността
- Това е особено полезно за мениджъри в областта на информационна сигурност и експлоатация
- Подпомага процесите на сертификация, ресертификация и вътрешен одит в областта на информационната сигурност
- Автоматизация на дейности в областта на информационната сигурност, които изискват ниска квалификация
- Все пак следва да се отчитат недостатъците на LLM – халюцинации, отклоняване и техните анализи да се приемат критично и да не се считат за пълни и/или окончателни
