Анализ логов SIEM

🔹 1. Как работает SIEM?

SIEM (Security Information and Event Management) — это система, предназначенная для сбора, анализа и корреляции данных о событиях безопасности в ИТ-инфраструктуре. Она помогает выявлять угрозы, расследовать инциденты и обеспечивать соответствие требованиям регуляторов. Вот как это работает и как настраивается: Как работает SIEM:

Сбор данных (Data Collection):
- SIEM собирает данные из различных источников: сетевых устройств (роутеры, фаерволы), серверов, рабочих станций, приложений, баз данных и т.д.
- Данные могут включать логи, метрики, события безопасности и другую информацию.
Нормализация и агрегация:
- Собранные данные приводятся к единому формату (нормализация) для удобства анализа.
- Данные агрегируются, чтобы уменьшить объем и упростить обработку.
Корреляция событий:
- SIEM использует правила и алгоритмы для выявления связей между событиями. Например, несколько неудачных попыток входа в систему с последующим успешным входом могут указывать на атаку методом brute force.
Анализ и обнаружение угроз:
- Система анализирует данные на основе предопределенных правил, сигнатур и поведенческих моделей.
- Используются методы машинного обучения и искусственного интеллекта для выявления аномалий.
Оповещения и отчеты:
- При обнаружении подозрительной активности SIEM генерирует оповещения для SOC (Security Operations Center) или администраторов.
- Формируются отчеты для анализа и аудита.
Реагирование:
- Некоторые SIEM интегрируются с SOAR (Security Orchestration, Automation and Response) для автоматизации реагирования на инциденты.

🔹 2. В чем разница между security event и incident?

Событие безопасности (Security Event):

Определение: Это любое наблюдаемое изменение в системе или сети, которое может быть связано с безопасностью. Событие не обязательно представляет угрозу.

📌Примеры:

Неудачная попытка входа в систему.
Сканирование портов сети.
Получение письма с вложением (даже если оно подозрительное, но не открытое).

📌Характеристики:

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

Инцидент безопасности (Security Incident):

Определение: Это событие, которое представляет угрозу для конфиденциальности, целостности или доступности данных или систем. Инцидент требует реагирования и расследования.

📌Примеры:

Успешный взлом системы (несанкционированный доступ).
Утечка конфиденциальных данных.
Заражение системы вредоносным ПО (вирусы, ransomware).
DDoS-атака, приводящая к отказу сервиса.

📌Характеристики:

Представляет реальную угрозу для организации.
Требует немедленного реагирования и расследования.
Может привести к финансовым, репутационным или юридическим последствиям.

🔹 3. Как искать события в Windows и Linux?

Где искать события в Windows?

📌 1) Просмотрщик событий (Event Viewer)

В Windows основным инструментом для просмотра логов является Просмотрщик событий (Event Viewer).
Открывается через eventvwr.msc или Пуск → Администрирование → Просмотр событий.

Основные журналы событий:
✅ Application (Приложение) – ошибки и предупреждения от установленных программ.
✅ Security (Безопасность) – логи аутентификации, доступа, использования учетных записей (например, логин/выход, изменения прав).
✅ System (Система) – системные ошибки, сбои оборудования, загрузка драйверов.
✅ Setup (Установка) – журналы установки ПО и обновлений.
✅ Forwarded Events (Пересланные события) – события, полученные с других машин.

Полезные ID событий:
🔹 4624 – успешный вход в систему.
🔹 4625 – неудачная попытка входа.
🔹 4648 – вход с указанием учетных данных.
🔹 4720 – создание учетной записи.
🔹 4722 / 4725 – включение/отключение учетной записи.
🔹 4732 – добавление пользователя в группу.
🔹 1102 – очистка журнала событий (возможный признак атаки).

📌 2) Журналы Windows (Log Files)

Некоторые логи находятся в файловой системе:
📂 C:\Windows\System32\winevt\Logs\ – файлы .evtx с системными логами.
📂 C:\Windows\Logs\CBS\CBS.log – лог установки компонентов Windows.
📂 C:\Windows\System32\config\SAM – реестр с учетными записями пользователей.

Где искать события в Linux?

📌 1️) Системный журнал (syslog, journalctl)

В большинстве дистрибутивов Linux основным логом является syslog:
📂 /var/log/syslog – системные события, включая сообщения от служб и ядра.
📂 /var/log/messages – общий лог системных событий (используется в CentOS/RHEL).

Если система использует systemd, удобно просматривать логи через journalctl:

journalctl -xe # просмотр последних критических событийjournalctl -u sshd # просмотр логов службы SSHjournalctl --since "1 hour ago" # события за последний час`

📌 2) Логи аутентификации и безопасности

📂 /var/log/auth.log – успешные и неудачные входы, sudo-команды (Ubuntu/Debian).
📂 /var/log/secure – аналогичный лог для CentOS/RHEL.

cat /var/log/auth.log | grep "Failed password" # поиск неудачных входов cat /var/log/auth.log | grep "Accepted password" # успешные входы по SSH

📌 3) Логи служб и приложений

📂 /var/log/apache2/access.log – логи доступа веб-сервера Apache.
📂 /var/log/nginx/access.log – логи Nginx.
📂 /var/log/mysql.log – логи базы данных MySQL.

📌 4) Логи ядра и ошибок системы

📂 /var/log/dmesg – загрузка системы и аппаратные ошибки.
📂 /var/log/kern.log – системные сообщения ядра.

dmesg | tail -20

📌 5) Логи пользователей и команд

📂 ~/.bash_history – история команд пользователя (можно проверить активности злоумышленника).
📂 /var/log/wtmp – история входов пользователей.
📂 /var/log/btmp – неудачные попытки входа.

🔹 4. Что такое анализ ложных срабатываний? (false positive analysis)

Ложное срабатывание (False Positive) — это ситуация, когда система безопасности ошибочно классифицирует легитимное действие как угрозу. Анализ ложных срабатываний помогает минимизировать такие ошибки, чтобы сократить количество ненужных тревог и повысить точность выявления реальных инцидентов.

Почему важен анализ ложных срабатываний?

🔹 Снижение нагрузки на SOC – уменьшение количества ненужных тревог позволяет аналитикам сосредоточиться на реальных угрозах.
🔹 Предотвращение "усталости от тревог" – если SOC-аналитики постоянно видят ложные срабатывания, они могут начать игнорировать реальные угрозы.
🔹 Оптимизация сигнатур и правил – настройка SIEM-систем и IDS/IPS для уменьшения ложных тревог.
🔹 Уменьшение числа ложных блокировок – предотвращение блокировки легитимных пользователей, сервисов или трафика.

📌 Пример ложного срабатывания и его анализа

Сценарий:

Организация использует SIEM-систему для мониторинга сети. Внезапно SOC-аналитик получает тревогу:

"Подозрительная активность: множественные неудачные попытки входа по RDP (remote desktop protocol) с одного IP-адреса"

Такое поведение может указывать на атаку перебором паролей (Brute Force), но это также может быть ложным срабатыванием. 📌 Шаги анализа ложного срабатывания

1. Проверка источника тревоги

IP-адрес принадлежит внутреннему сотруднику.
Время событий совпадает с началом рабочего дня (что может быть обычной активностью).

2. Анализ паттернов поведения

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

3. Сравнение с предыдущими событиями

Похожая активность наблюдалась и раньше, но она не привела к компрометации системы.

4. Уточнение у пользователя или администратора

Запрос пользователю показал, что он действительно забыл пароль и вводил его несколько раз.

Вывод: Это ложное срабатывание. Необходимо скорректировать правила SIEM, чтобы не поднимать тревогу при 3–5 ошибочных попытках входа от одного пользователя в течение короткого времени.

🔹 5. Как проводить анализ логов при расследовании инцидента?

Анализ логов – один из ключевых этапов расследования инцидентов безопасности. Логи позволяют выявить источник атаки, зафиксировать действия злоумышленника и понять масштаб компрометации.

Шаги анализа логов во время расследования инцидента

1) Определение цели анализа

📌 Какие события необходимо расследовать (взлом учетной записи, подозрительная активность в сети, попытки эксплуатации уязвимостей)?
📌 Какие системы и сервисы затронуты (Windows, Linux, SIEM, веб-сервер, Active Directory)?
📌 Какой временной диапазон нужно исследовать?

Пример: выявление несанкционированного входа в систему и возможной эксфильтрации данных.

2) Сбор и агрегирование логов

📌 Использование SIEM-систем (Splunk, ELK, QRadar, ArcSight) для централизованного анализа логов.
📌 Ручной анализ логов с критических узлов (/var/log/, Event Viewer).
📌 Выгрузка логов для последующего анализа (journalctl, wevtutil, PowerShell).

3) Анализ подозрительных событий

📌 Фильтрация по ключевым событиям

В Windows: 4624 (успешный вход), 4625 (неудачный вход), 4720 (создание учетной записи).
В Linux: /var/log/auth.log (Failed password, Accepted password).
В веб-логах: 401 Unauthorized, 403 Forbidden, 500 Internal Server Error.

📌 Выявление аномальной активности

Множественные неудачные попытки входа.
Логины с необычных IP-адресов или в нестандартное время.
Запуск подозрительных процессов или выполнение команд от имени администратора.

4) Корреляция событий и выявление угроз

📌 Сопоставление данных из разных логов (файловых систем, сетевых устройств, SIEM).
📌 Анализ времени между событиями (например, вход → запуск подозрительного процесса → передача данных в сеть).
📌 Поиск индикаторов компрометации (IoC) через Threat Intelligence (VirusTotal, MISP, AbuseIPDB).

5) Выводы и документирование

📌 Описание хронологии атаки (время, метод атаки, вовлеченные системы).
📌 Подготовка отчета для SOC или службы безопасности.
📌 Разработка рекомендаций по предотвращению повторных атак (например, настройка MFA, улучшение логирования, запрет определенных IP).

🔹 6. Расскажи про жизненный цикл реагирования на инциденты. (Incident Response Lifecycle)

Реагирование на инциденты безопасности – это процесс выявления, анализа, сдерживания, устранения и последующего обучения на основе инцидентов. Один из наиболее распространенных подходов – NIST Incident Response Lifecycle, который включает 6 ключевых этапов.

1) Подготовка (Preparation)

🔹 Разработка политики реагирования на инциденты.
🔹 Создание команды Incident Response (SOC, CSIRT).
🔹 Внедрение средств мониторинга (SIEM, IDS/IPS, EDR, XDR).
🔹 Обучение сотрудников и проведение тестов (Red Team, Phishing-кампании).
🔹 Разработка плана коммуникаций (внутренние уведомления, контакт с регуляторами).

Пример: Настройка логирования в SIEM и проведение киберучений по реагированию.

2) Идентификация (Detection & Analysis)

🔹 Обнаружение инцидента через SIEM, EDR, IDS/IPS, SOC-мониторинг.
🔹 Классификация инцидента (DDoS, malware, phishing, data exfiltration).
🔹 Корреляция событий из логов (Windows Event Logs, /var/log/auth.log).
🔹 Анализ индикаторов компрометации (IoC) через Threat Intelligence (VirusTotal, AbuseIPDB).
🔹 Оценка потенциального ущерба.

Пример: В логах обнаружены множественные неудачные попытки входа, SIEM сигнализирует о возможной атаке Brute Force.

3) Сдерживание (Containment)

🔹 Изоляция зараженных систем (отключение от сети, блокировка учетных записей).
🔹 Запуск блокирующих правил на брандмауэрах и IDS/IPS.
🔹 Создание бэкапа критических данных перед удалением угрозы.
🔹 Временное ограничение привилегий пользователей, если это необходимо.

Пример: Если обнаружен вредоносный процесс, система отключается от сети, а вредоносный файл помещается в карантин.

4) Устранение (Eradication)

🔹 Удаление вредоносного ПО, исправление уязвимостей.
🔹 Установка обновлений безопасности (патч-менеджмент).
🔹 Восстановление систем из чистых бэкапов.
🔹 Откат изменений, внесенных злоумышленником.

Пример: На сервере найдены руткиты → запуск антивирусного сканирования, восстановление системы, смена учетных данных.

5) Восстановление (Recovery)

🔹 Проверка работоспособности системы после устранения угрозы.
🔹 Мониторинг на предмет повторных атак.
🔹 Постепенный возврат систем в эксплуатацию.
🔹 Оценка эффективности проведенных мер.

Пример: После восстановления зараженного сервера проводится тестирование и мониторинг логов в SIEM на предмет повторной активности злоумышленника.

6) Пост-инцидентный анализ (Lessons Learned)

🔹 Разбор инцидента (что сработало хорошо, что можно улучшить).
🔹 Обновление политики безопасности и плана реагирования.
🔹 Повышение осведомленности сотрудников.
🔹 Улучшение механизмов детектирования и защиты.

Пример: После атаки фишинга в компании вводят обязательное обучение и внедряют двухфакторную аутентификацию (2FA).