1. Инвентаризация инфраструктуры: Нельзя защитить то, о чем не знаешь
Первый шаг любого проекта по мониторингу — это полная и доскональная инвентаризация. Вы должны знать каждый актив в вашей сети. Этот процесс называется управление активами (Asset Management).
Что нужно инвентаризировать:
- Аппаратные активы: Серверы, рабочие станции, ноутбуки, сетевое оборудование (маршрутизаторы, коммутаторы), мобильные устройства.
- Программные активы: Операционные системы, установленное ПО, базы данных, веб-серверы.
- Данные: Где хранятся самые ценные данные (персональные, финансовые, коммерческая тайна)? Классификация данных — ключевой этап.
- Сетевая топология: Актуальная карта сети со всеми подсетями, VLAN'ами, точками входа и выхода.
Этот процесс должен быть автоматизирован. Используйте сканеры сети (например, Nmap), системы инвентаризации (GLPI, Snipe-IT) и CMDB (Configuration Management Database) для поддержания этой информации в актуальном состоянии.
2. Выделение параметров мониторинга: На что смотреть?
После инвентаризации мы определяем, какие именно параметры (метрики и события) мы будем отслеживать для каждого типа активов. Цель — покрыть все критически важные аспекты работы и безопасности.
| Тип актива | Ключевые параметры для мониторинга |
|---|---|
| Серверы (Windows/Linux) | Загрузка CPU, использование RAM и диска, сетевая активность, события входа/выхода (успешные и неудачные), создание/удаление пользователей, изменения в критических файлах, запуск новых процессов. |
| Сетевое оборудование | Утилизация каналов, ошибки на интерфейсах, изменения конфигурации, события VPN-подключений, срабатывания ACL (списков доступа). |
| Веб-приложение | Количество запросов (RPS), время ответа, количество ошибок (4xx, 5xx), срабатывания WAF, попытки SQL-инъекций и XSS. |
| База данных | Нагрузка, время выполнения запросов, неудачные попытки аутентификации, запросы от необычных источников, DDL/DCL операции. |
3. Источники событий: Где рождается правда
Все параметры, которые мы выделили, фиксируются в виде событий (events), которые записываются в журналы (логи). Это наши "глаза и уши" в инфраструктуре.
Основные источники логов для SIEM-системы:
- Операционные системы: Windows Event Log (Security, System, Application), Linux Syslog, Auditd.
- Сетевое оборудование: Syslog от маршрутизаторов, коммутаторов, файрволов.
- Средства защиты: Логи антивирусов/EDR, IDS/IPS, WAF, VPN-шлюзов.
- Приложения: Логи веб-серверов (Apache, Nginx), баз данных (PostgreSQL, MSSQL), бизнес-приложений.
- Облачные сервисы: AWS CloudTrail, Azure Monitor, Google Cloud Logging.
Ключевая задача — обеспечить полноту и целостность сбора логов. Если логи не собираются или их можно незаметно изменить, вся система мониторинга бесполезна.
4. Нормализация, корреляция, аналитика в SIEM
Сырые логи от разных систем выглядят по-разному. Чтобы с ними можно было работать, SIEM-система выполняет несколько магических преобразований.
- Нормализация: Процесс приведения всех событий к единому формату (например, Common Event Format). SIEM "разбирает" сырую строку лога (
"Dec 10 12:00:01 sshd[1234]: Failed password for root from 1.2.3.4") на стандартизированные поля:timestamp,hostname,process_name,event_type,source_ip,username. - Обогащение (Enrichment): SIEM добавляет к событию дополнительный контекст. К IP-адресу
1.2.3.4добавляется информация о его геолокации (GeoIP) и репутации (является ли он известным источником атак). К логину `bsmith` добавляется ФИО и должность из Active Directory. - Корреляция: Это мозг SIEM. Система анализирует нормализованные и обогащенные события из РАЗНЫХ источников и ищет в них признаки сложных, распределенных во времени атак.
Пример правила корреляции:
ЕСЛИ (Событие "Неудачный вход по VPN" для пользователя X) И (в течение 5 минут после этого Событие "Успешный вход по VPN" для того же пользователя X, но с IP-адреса из другой страны) ТОГДА создать алерт "Подозрение на компрометацию учетных данных VPN".
5. Playbook: Алгоритмы реагирования на инциденты
Playbook (или Standard Operating Procedure, SOP) — это пошаговая инструкция для аналитика, что именно делать при срабатывании конкретного алерта. Плейбуки устраняют хаос и гарантируют, что даже в стрессовой ситуации будут выполнены все необходимые действия.
Пример плейбука для алерта "Возможная фишинговая атака":
- Идентификация:
- Проанализировать заголовок письма (поля `Received`, `Return-Path`).
- Проверить репутацию IP-адреса отправителя и домена в Threat Intelligence базах (VirusTotal, AbuseIPDB).
- Проанализировать вложения и ссылки в "песочнице".
- Сдерживание (Containment):
- Если фишинг подтвержден, заблокировать IP-адрес отправителя на почтовом шлюзе и файрволе.
- Запустить поиск по всем почтовым ящикам и удалить аналогичные письма.
- Если пользователь перешел по ссылке и ввел данные — немедленно заблокировать его учетную запись и сбросить пароль.
- Ликвидация (Eradication): Убедиться, что на машине пользователя не было установлено вредоносное ПО.
- Восстановление (Recovery): Разблокировать учетную запись пользователя с новым паролем.
- Пост-инцидентный анализ: Проанализировать, почему фишинг прошел через фильтры, и донастроить их. Провести дополнительное обучение для пользователя.
6. Анализ инцидента и сбор доказательств (Форензика)
Это процесс глубокого расследования инцидента для ответа на вопросы: "Что произошло? Как это произошло? Какой ущерб нанесен?". Здесь важен принцип сохранности улик (Chain of Custody).
Ключевой навык — умение "читать" артефакты операционной системы:
- Анализ памяти (RAM Forensics): Снятие дампа оперативной памяти (с помощью утилит вроде FTK Imager, Volatility) позволяет найти запущенные процессы, сетевые соединения, ключи шифрования, которые исчезнут после перезагрузки.
- Анализ диска: Поиск вредоносных файлов, анализ логов, MFT (Master File Table) в NTFS, временных файлов, реестра Windows, истории браузера.
- Сетевая форензика: Анализ дампов трафика (PCAP-файлов) для восстановления сессии злоумышленника и определения, какие данные были украдены.
7. Устранение последствий и недопущение инцидентов в будущем
Работа не заканчивается, когда атака остановлена. Самый важный этап — это извлечение уроков.
Устранение (Remediation):
- Установка необходимых патчей и обновлений.
- Изменение уязвимых конфигураций.
- Блокировка скомпрометированных учетных записей и сброс паролей.
- Переустановка системы из "золотого образа", если есть подозрение, что она полностью скомпрометирована.
Пост-инцидентный анализ (Lessons Learned):
Команда собирается и отвечает на вопросы:
- Что мы сделали хорошо?
- Где мы действовали медленно или неэффективно?
- Каковы были корневые причины инцидента (не только технические, но и организационные)?
- Какие изменения в процессах, технологиях или обучении нам нужно внести, чтобы подобное не повторилось?
Цель этого этапа — не найти виновных, а улучшить систему. Культура "Blameless Post-Mortem" (разбор полетов без обвинений) — признак зрелой компании.
8. Визуализация данных и отчёты
Данные мониторинга должны быть понятны не только техническим специалистам, но и руководству. Для этого используются дашборды — интерактивные панели с графиками и ключевыми метриками.
Что должно быть на дашборде SOC:
- Карта атак в реальном времени.
- Топ-10 самых частых алертов.
- Топ-10 атакующих IP-адресов.
- Количество событий в секунду (EPS).
- Статус ключевых систем и каналов связи.
Отчеты формируются на регулярной основе (ежедневные, еженедельные, ежемесячные) и по итогам крупных инцидентов. Отчет для руководства должен быть написан на языке бизнеса, с акцентом на риски и финансовые показатели, а не на технические детали.