2.3 Алгоритм работы системы

Базовый процесс функционирования АСУ «Бустсейв» включает последовательность этапов от получения события до формирования итоговой отчётности.

1. Получение событий.

Система принимает входящие данные безопасности от различных источников: серверов, рабочих станций, сетевого оборудования, приложений, систем контроля целостности, антивирусов и средств обнаружения вторжений. Все события передаются в базовую подсистему.

2. Регистрация и приведение к единому формату.

Базовая подсистема выполняет предварительную обработку:

• нормализует события, приводя их к единой структуре;

• присваивает технические параметры;

• сохраняет записи в хранилище для дальнейшего анализа.

3. Анализ, сопоставление и выявление инцидентов.

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

На основе установленных шаблонов и правил определяется факт возникновения инцидента, ему присваиваются:

• уникальный идентификатор;

• тип угрозы;

• уровень критичности.

4. Определение приоритета и выбор обработки.

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

5. Выполнение сценариев реагирования.

При выборе автоматической обработки подсистема шаблонов инициирует действия согласно соответствующему сценарию:

• блокировка подозрительных сетевых соединений;

• изоляция устройств;

• остановка активных сессий;

• формирование уведомлений ответственным сотрудникам;

• создание записей в служебных журналах и задач для смежных систем.

6. Контроль выполнения и эскалация.

Система отслеживает ход выполнения сценариев и время реакции по заданным нормативам SLA. При нарушении допустимых сроков или ошибках выполнения инцидент автоматически передаётся на уровень эскалации.

7. Завершение обработки.

После устранения угрозы или подтверждения ложного срабатывания инцидент получает итоговый статус.

Вся хронология действий – автоматических и ручных – сохраняется в подсистеме хранения данных.

8. Формирование отчётности и аналитики.

Подсистема работы с документами формирует необходимые отчёты:

• оперативные сводки для SOC;

• аналитические материалы;

• статистику по KPI, SLA, MTTR, MTTD.

Данные используются подразделениями информационной безопасности, техническими службами и руководством.

2.4 Структура входных и выходных данных

Каждое поле входных и выходных данных имеет строгое значение и назначение:

• EventID – уникальный идентификатор события безопасности, присваиваемый при его регистрации в системе;

• IncidentID – уникальный идентификатор инцидента, сформированного в результате корреляции событий;

• UserID – идентификатор пользователя системы (оператора SOC, администратора безопасности, системного администратора, CISO и др.);

• Source – источник возникновения события: сервер, рабочая станция, прикладной сервис, сетевое устройство, IP-адрес или пользователь;

• EventType – тип события: аутентификация, сетевой трафик, изменение конфигурации, попытка доступа, ошибка приложения и другие категории;

• Severity – уровень критичности события или инцидента: Low, Medium, High, Critical;

• Status – текущий статус инцидента: Active, In Progress, Resolved, False Positive;

• Timestamp – временная метка события или обновления статуса в стандарте ISO 8601 (YYYY-MM-DDThh:mm:ssZ);

• ActionTaken – выполненные системой или специалистами меры реагирования: блокировка IP, изоляция хоста, уведомление, запуск сценария;

• RiskLevel – уровень риска, присвоенный анализируемому событию (Low, Medium, High, Critical);

• Description – текстовое описание события или инцидента, включающее ключевые детали и контекст;

• Owner – пользователь или подразделение, назначенное ответственным за обработку инцидента;

• ResolutionTime – время устранения инцидента (в минутах или часах), фиксируемое подсистемой отчётности;

• KPI – показатели эффективности реагирования: MTTD (Mean Time To Detect), MTTR (Mean Time To Respond), SLA и другие метрики.

Семантика данных обеспечивает однозначную интерпретацию информации всеми подсистемами и позволяет:

• стандартизировать обмен данными между модулями системы;

• обеспечивать корректную корреляцию событий;

• формировать отчёты и аналитические панели;

• сохранять целостность и непротиворечивость информации.