SOC

SOC, или Security Operations Center, — центр мониторинга информационной безопасности, который объединяет специалистов, процессы и технические инструменты для обнаружения, анализа и расследования киберугроз.

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

SOC работает не как отдельная программа, а как организационно-техническая функция. В нем используются SIEM, EDR, XDR, Firewall, Threat Intelligence, SOAR и другие средства защиты, но ключевым элементом остаются процессы и специалисты, которые принимают решения.

SOC — это не одна система безопасности, а команда и набор процессов, которые превращают Security Alerts в расследование и реальные действия по защите бизнеса.

Что такое SOC простыми словами

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

Каждую минуту инфраструктура генерирует тысячи Security Events:

Firewall → blocked connection
EDR → suspicious process
SIEM → correlation alert
VPN → unusual login
Cloud → admin role assigned

Если никто не анализирует эти события, средства защиты могут обнаружить атаку, но компания отреагирует слишком поздно.

SOC следит за Alert, определяет, насколько он опасен, расследует причину и запускает Response.

Расшифровка SOC

SOC расшифровывается как Security Operations Center — центр операций информационной безопасности.

Иногда используют русские варианты «центр мониторинга информационной безопасности» или «центр реагирования на киберугрозы».

Для чего нужен SOC

SOC решает несколько ключевых задач:

• круглосуточный мониторинг Security Events;
• анализ Alerts;
• расследование инцидентов;
• Threat Hunting;
• координация Incident Response;
• эскалация критичных угроз;
• улучшение Detection Rules;
• контроль покрытия средств защиты;
• подготовка отчетности.

Что мониторит SOC

Источниками данных могут быть:

SOC и SIEM

SIEM — один из основных технических инструментов SOC.

Она собирает события из разных систем и создает Alerts, а SOC анализирует их.

Infrastructure
↓ logs
SIEM
↓ alerts
SOC Analyst
↓
Investigation / Response

Таким образом, SIEM — технология, а SOC — организационная функция, использующая эту технологию.

Можно ли иметь SIEM без SOC

Технически да.

Компания может установить SIEM и собирать Logs, но если Alerts никто регулярно не рассматривает, ценность Detection резко снижается.

Особенно опасно, если критичный Incident происходит ночью или в выходные.

SOC и EDR

EDR предоставляет детальные данные о рабочих станциях и серверах.

SOC Analyst использует EDR, чтобы увидеть:

• Process Tree;
• Command Line;
• Network Connections;
• Files;
• User Activity;
• Detection Timeline.

При подтвержденной атаке аналитик может изолировать Host или остановить Process.

SOC и XDR

XDR помогает SOC связывать события из разных Security Domains.

Например:

Phishing Email
↓
Suspicious Process
↓
Unusual Login
↓
Cloud Data Access

Вместо четырех Alerts SOC получает более целостный Incident.

SOC и SOAR

SOAR автоматизирует типовые действия SOC.

Например, после подтвержденного Malware Alert система может:

1. изолировать Endpoint;
2. заблокировать Hash;
3. создать Ticket;
4. уведомить Incident Response Team.

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

SOC и Threat Intelligence

Threat Intelligence предоставляет информацию о вредоносных IP, Domains, File Hash и тактиках атакующих.

SOC использует эти данные для обогащения Alerts и Threat Hunting.

SOC и Incident Response

Incident Response — процесс реагирования на подтвержденную атаку.

SOC часто является первой командой, которая обнаруживает Incident и запускает его расследование.

Далее могут подключаться Network, System Administration, Legal, Management и другие подразделения.

Основные этапы работы SOC

Типичный процесс выглядит так:

Detection
↓
Triage
↓
Investigation
↓
Containment
↓
Eradication
↓
Recovery
↓
Lessons Learned

Detection

На этапе Detection система безопасности создает Alert или аналитик самостоятельно находит подозрительную активность.

Источник может быть SIEM, EDR, WAF, Cloud или пользовательское сообщение.

Triage

Triage — первичная оценка события.

Аналитик определяет:

• реальный ли это Incident;
• какова Severity;
• какие Assets затронуты;
• нужна ли срочная эскалация.

Investigation

На этапе расследования SOC собирает контекст.

Например:

• какой User выполнял действие;
• какой Host был затронут;
• какой Process запущен;
• откуда пришел Login;
• были ли аналогичные события на других устройствах.

Containment

Containment ограничивает распространение атаки.

Возможные действия:

• изолировать Endpoint;
• заблокировать Account;
• отключить Network Connection;
• заблокировать Domain;
• закрыть уязвимый сервис.

Eradication

На этом этапе удаляются Malware, Persistence, вредоносные Accounts и другие следы атакующего.

Также устраняется первоначальная причина проникновения, например Vulnerability или украденный Password.

Recovery

Система возвращается в Production после проверки безопасности.

Могут восстанавливаться данные из Backup, обновляться Credentials и повторно подключаться изолированные Hosts.

Lessons Learned

После Incident SOC анализирует, почему атака произошла и почему она не была обнаружена раньше.

Результатом могут стать новые Detection Rules, изменение Firewall Policy или обучение сотрудников.

Уровни аналитиков SOC

В классической модели функции могут разделяться по уровням.

Конкретное разделение зависит от размера организации.

SOC Analyst L1

Первая линия анализирует входящие Alerts и выполняет Triage.

Основная задача — быстро отличить очевидный False Positive от события, требующего расследования.

SOC Analyst L2

Вторая линия занимается более сложными Incidents.

Она анализирует Endpoint, Network, Identity и другие данные и определяет Scope Attack.

SOC Analyst L3

Третья линия работает с наиболее сложными угрозами, Threat Hunting и нестандартными атаками.

Специалист может создавать Hypothesis и искать ранее незамеченную активность.

Detection Engineer

Detection Engineer разрабатывает и улучшает правила обнаружения атак.

Он анализирует реальные Incidents и переводит знания об атаках в Detection Logic.

SOC Engineer

SOC Engineer отвечает за техническую инфраструктуру мониторинга.

Он подключает Log Sources, поддерживает SIEM, Parsers, Integrations и Automation.

Threat Hunter

Threat Hunter проактивно ищет атаки, которые могли пройти мимо автоматического Detection.

Например, он ищет необычные PowerShell Commands или подозрительные Authentication Patterns.

Incident Responder

Incident Responder специализируется на действиях после подтвержденной компрометации.

Он координирует Containment, Eradication и Recovery.

SOC Manager

SOC Manager отвечает за процессы, людей, KPI, эскалации и взаимодействие с бизнесом.

Его задача — обеспечить устойчивую работу всей функции мониторинга.

SOC 24/7

Для критичной инфраструктуры SOC часто работает круглосуточно.

Атаки не зависят от рабочего графика компании.

Если Alert обнаружен в 03:00, Response через восемь часов может быть слишком поздним.

Нужен ли всем компаниям SOC 24/7

Не обязательно.

Небольшая компания с ограниченной критичной инфраструктурой может использовать рабочий режим или внешний MDR.

Решение зависит от Business Risk и требований Availability.

Внутренний SOC

Internal SOC полностью находится внутри компании.

Преимущества:

• глубокое знание инфраструктуры;
• прямой доступ к IT Team;
• полный контроль процессов;
• гибкая настройка Detection.

Недостаток — высокая стоимость команды и технологий.

Внешний SOC

Компания может передать мониторинг специализированному Provider.

Это называется Managed SOC или может быть частью MDR Service.

Provider получает Security Events и выполняет Monitoring и Triage.

Гибридный SOC

Hybrid Model сочетает внешнего Provider и внутреннюю Security Team.

Например, Provider обеспечивает 24/7 Monitoring, а внутренние специалисты принимают решения по критичным Business Systems.

SOC и MDR

MDR, или Managed Detection and Response, — сервис управляемого обнаружения и реагирования.

По смыслу он близок к внешней SOC-функции, но обычно делает акцент именно на Detection and Response, а не просто на мониторинге Logs.

SOC и MSSP

MSSP, или Managed Security Service Provider, предоставляет широкий набор управляемых Security Services.

Это может включать Firewall Management, Vulnerability Scanning, SIEM и SOC Monitoring.

SOC и NOC

SOC и NOC решают разные задачи.

При крупном Incident команды часто работают совместно.

Пример взаимодействия SOC и NOC

Сайт становится недоступен.

NOC видит резкий рост Traffic и считает это перегрузкой.

SOC анализирует WAF и Firewall и определяет, что происходит DDoS Attack.

Команды совместно подключают Anti-DDoS Protection.

SOC и DDoS

SOC отслеживает признаки атаки через Network, WAF и CDN Metrics.

При подтверждении DDoS он координирует действия с Network Team и Provider.

SOC и Phishing

Phishing является одним из наиболее частых сценариев расследования.

Процесс может включать:

1. анализ письма;
2. проверку URL и Attachment;
3. поиск других получателей;
4. проверку Endpoint;
5. анализ Authentication;
6. удаление вредоносного письма.

SOC и Ransomware

При признаках Ransomware скорость Response критична.

SOC может изолировать зараженный Host и проверить, началось ли распространение по сети.

SOC и Credential Theft

Если пользовательский Password украден, SOC анализирует Login History, MFA Events и активные Sessions.

Response включает блокировку Account, отзыв Tokens и смену Credentials.

SOC и Insider Threat

SOC может выявлять аномальную активность легитимного сотрудника.

Например, массовую загрузку документов перед увольнением.

Такие расследования требуют осторожности и взаимодействия с HR и Legal.

SOC и Cloud Security

Современный SOC должен видеть не только локальную сеть, но и Cloud Infrastructure.

Важные события:

• создание Access Key;
• назначение Admin Role;
• изменение Security Group;
• массовая загрузка данных;
• отключение Logging.

SOC и SaaS

SaaS Applications также должны попадать в Security Monitoring.

Особенно важны Identity, File Sharing и Administrative Events.

SOC и Zero Trust

Zero Trust управляет доступом, а SOC анализирует признаки компрометации User и Device.

Risk Signal от SOC Platform может использоваться для дополнительной Authentication или блокировки Session.

SOC и Vulnerability Management

SOC обнаруживает атаки, а Vulnerability Management помогает уменьшить поверхность атаки заранее.

Если Alert связан с Server с известной критичной Vulnerability, его Severity повышается.

SOC и Patch Management

SOC может сообщить IT Team, что атака использует определенную Vulnerability.

Но непосредственное обновление Servers обычно относится к отдельному Operational Process.

SOC и Backup

SOC не заменяет резервное копирование.

При Ransomware Security Team останавливает атаку, а Backup используется для восстановления данных.

Threat Hunting

Threat Hunting отличается от обычной обработки Alerts.

Аналитик самостоятельно формулирует гипотезу:

Мог ли злоумышленник использовать PowerShell для persistence?

После этого выполняет поиск по накопленной Telemetry.

Threat Intelligence в SOC

Threat Intelligence помогает SOC понимать актуальные Tactics и Indicators.

Однако простая загрузка тысяч IOC без контекста может создать много False Positives.

IOC

Indicator of Compromise — технический признак возможной атаки.

Например:

• IP Address;
• Domain;
• File Hash;
• URL;
• Registry Key.

IOA

Indicator of Attack описывает поведение или действие атакующего.

Например, последовательность Credential Dumping и Lateral Movement.

Поведенческие Indicators часто устойчивее простых File Hash.

MITRE ATT&CK в SOC

ATT&CK используется как единая модель тактик и техник атакующих.

SOC может сопоставлять Detection Rules с:

Initial Access
Execution
Persistence
Credential Access
Lateral Movement
Exfiltration

Detection Coverage

Security Team анализирует, какие ATT&CK Techniques уже покрыты Rules, а где есть Blind Spots.

Так строится план развития Detection.

Use Case

SOC Use Case описывает конкретную угрозу и логику ее обнаружения.

Например:

Use Case: RDP brute force
Source: Windows Security Logs
Condition: many failed logins
Response: alert SOC

Runbook

Runbook — инструкция, как обрабатывать конкретный тип Alert.

Например, для подозрительного RDP Login:

1. Проверить Source IP.
2. Проверить User.
3. Сопоставить VPN Session.
4. Посмотреть EDR Activity.
5. При подтверждении заблокировать Account.

Playbook

Playbook описывает более широкий или автоматизированный сценарий Response.

Часть шагов может выполнять SOAR.

Эскалация

Не каждый Alert требует участия Incident Response Team.

L1 Analyst должен понимать критерии, при которых событие передается дальше.

Например, компрометация Domain Controller эскалируется немедленно.

Severity

Уровень Severity помогает приоритизировать работу.

Обычно учитываются:

• тип угрозы;
• Criticality Asset;
• Confidence;
• масштаб;
• наличие Active Compromise.

False Positive

False Positive — легитимное действие, которое Detection ошибочно считает атакой.

Большое число таких событий перегружает SOC.

Alert Fatigue

Если аналитик получает сотни однотипных бессмысленных Alerts за смену, он начинает уделять каждому меньше внимания.

Это повышает риск пропустить реальную атаку.

Tuning

Tuning — настройка Detection Rules для уменьшения ложных срабатываний.

Исключение должно быть точным и не создавать широкую Blind Zone.

False Negative

False Negative возникает, когда реальная атака не была обнаружена.

Для уменьшения риска проводят Threat Hunting, Purple Team Tests и улучшают Telemetry Coverage.

Telemetry Coverage

SOC не может расследовать события, которые не собираются.

Если новый Cloud Service не подключен к SIEM или XDR, появляется Blind Spot.

Log Source Health

Критичные Sources должны постоянно отправлять Logs.

Если Domain Controller неожиданно перестал присылать Events, SOC должен получить Alert о потере Telemetry.

Время в SOC

Для расследования важно, чтобы разные системы имели синхронизированные часы.

Иначе события одной атаки будут отображаться в неправильном порядке.

SOC Dashboard

Dashboard показывает состояние Security Operations.

Например:

• Critical Incidents;
• Open Alerts;
• Top Attack Sources;
• Endpoint Coverage;
• MTTD;
• MTTR.

MTTD

Mean Time to Detect — среднее время от начала угрозы до ее обнаружения.

Чем меньше MTTD, тем меньше времени атакующий остается незамеченным.

MTTR

Mean Time to Respond — среднее время реагирования после Detection.

Хорошо организованный SOC стремится уменьшить и Detection Time, и Response Time.

Mean Time to Triage

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

Для Critical Events этот показатель особенно важен.

KPI SOC

Количество закрытых Alerts само по себе является слабой метрикой.

Полезнее отслеживать:

SLA SOC

Для Alerts могут задаваться SLA обработки.

Например, Critical Event должен быть просмотрен в течение нескольких минут, а Low Severity — в течение более длительного времени.

Почему SOC не должен измеряться только количеством Alerts

Чем качественнее Detection, тем меньше лишнего шума.

Большое количество Alerts может означать не хорошую защиту, а плохую настройку SIEM.

Документирование расследований

Каждый серьезный Incident должен иметь историю действий.

Нужно фиксировать:

• когда обнаружено событие;
• кто анализировал;
• какие данные проверены;
• какие действия выполнены;
• каков итог.

Ticketing System

SOC может использовать отдельную Incident Management Platform или интеграцию с Service Desk.

Alert превращается в Ticket и проходит понятный Lifecycle.

Chain of Custody

При серьезном расследовании важно понимать, кто и как работал с доказательствами.

Это особенно актуально для Forensics и юридически значимых Incident.

Digital Forensics

При сложной компрометации SOC может передать систему специалистам по цифровой криминалистике.

Они анализируют Disk Images, Memory, Artifacts и другие данные.

SOC и бизнес

Основная цель SOC — не максимальное количество технических Alerts, а снижение реального риска бизнеса.

Например, компрометация тестового Server и компрометация платежной системы должны иметь разный приоритет.

Business Context

Для качественной приоритизации SOC должен знать:

• какие Systems критичны;
• где хранятся важные данные;
• какие Accounts привилегированы;
• какие Services связаны с выручкой;
• какие системы имеют высокий Regulatory Risk.

CMDB и SOC

CMDB помогает обогатить Alert данными об Asset.

Например, IP 10.20.30.40 превращается из неизвестного Address в:

Host: PAYMENTS-DB-01
Owner: Finance IT
Criticality: Critical

После этого аналитик лучше понимает приоритет.

SOC и автоматизация

Без автоматизации специалисты тратят много времени на повторяющиеся действия.

Можно автоматизировать:

• обогащение IP;
• поиск Hash;
• создание Ticket;
• запрос EDR Telemetry;
• отправку уведомления.

Что не стоит автоматизировать бездумно

Массовая блокировка Accounts или остановка Production Systems по одному Low-confidence Alert может нанести бизнесу больше вреда, чем сама угроза.

Автоматизация должна учитывать Context.

SOC и искусственный интеллект

AI может помогать группировать Alerts, суммировать Incident Context и ускорять поиск информации.

Но финальные решения о критичных действиях должны учитывать качество данных и риск ошибок.

SOC и Machine Learning

ML-модели могут использоваться для Anomaly Detection и Risk Scoring.

Однако аномалия не равна атаке, поэтому результат требует контекста.

Типичные ошибки при создании SOC

1. Купить SIEM и считать, что SOC уже создан.
2. Собирать все Logs без Use Cases.
3. Не определить процессы эскалации.
4. Не иметь круглосуточного покрытия при необходимости.
5. Не контролировать качество Alerts.
6. Не учитывать Business Criticality.
7. Не проводить Threat Hunting.
8. Не документировать Incidents.
9. Не отслеживать Telemetry Gaps.
10. Не проводить Post-Incident Review.

Как создать SOC

Шаг 1. Определить цели

Нужно понять, какие Business Risks и Threat Scenarios SOC должен контролировать.

Шаг 2. Определить Coverage

Составьте список Endpoint, Cloud, Network, Identity и Applications.

Шаг 3. Подключить SIEM и другие инструменты

Соберите необходимые Security Data.

Шаг 4. Создать Use Cases

Для каждой угрозы определите Detection Logic и Sources.

Шаг 5. Настроить Triage

Аналитики должны понимать, какие Alerts расследовать первыми.

Шаг 6. Создать Runbooks

Опишите стандартные действия по основным Incident Types.

Шаг 7. Определить эскалацию

Критичные события должны быстро доходить до ответственных.

Шаг 8. Измерять эффективность

Контролируйте MTTD, MTTR, False Positives и Coverage.

Практический пример

В 02:15 SIEM создает High Severity Alert: учетная запись администратора успешно вошла по VPN из нового региона после серии Failed Logins.

L1 SOC Analyst проверяет VPN Logs и обнаруживает, что пользователь обычно подключается только из корпоративной сети.

EDR показывает, что через несколько минут после Login на одном из Servers был запущен необычный PowerShell Process.

Firewall фиксирует исходящее соединение с подозрительным внешним Domain.

События складываются в цепочку:

Failed logins
↓
Successful VPN login
↓
RDP to server
↓
PowerShell
↓
External connection

Incident эскалируется на L2.

Account блокируется, активные Sessions отзываются, а Server изолируется через EDR.

Threat Hunting показывает, что злоумышленник пытался подключаться еще к двум Hosts, но Authentication завершилась ошибкой.

После расследования выясняется, что Password был украден через Phishing.

Компания меняет Credentials, удаляет вредоносные письма из Mailboxes и добавляет новое Detection Rule на аналогичный сценарий.

Этот пример показывает, что SOC объединяет Technology и Human Analysis в единый Response Process.

SOC для бизнеса

Для бизнеса SOC особенно важен, когда простая установка Antivirus и Firewall уже недостаточна из-за масштаба инфраструктуры.

Чем больше Servers, Cloud Services и Remote Users, тем сложнее вручную контролировать Security Events.

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

Преимущества SOC

• централизованный Security Monitoring;
• быстрое Detection;
• структурированный Incident Response;
• Threat Hunting;
• контроль Security Coverage;
• улучшение Detection Rules;
• снижение времени реакции;
• единый процесс эскалации.

Ограничения SOC

• требует квалифицированных специалистов;
• зависит от качества Telemetry;
• может быть дорогим для небольшой компании;
• не заменяет Preventive Security;
• нуждается в постоянном Tuning;
• не гарантирует обнаружение всех атак;
• требует взаимодействия с IT и бизнесом.

Когда нужен собственный SOC

Собственный SOC обычно оправдан при большой инфраструктуре, высоких рисках, требованиях 24/7 и наличии собственной Security Team.

Для небольшой или средней компании внешний SOC или MDR часто экономически эффективнее.

Связанные термины

Краткий итог

SOC — Security Operations Center, центр мониторинга и реагирования на киберугрозы. Он объединяет специалистов, процессы и технологии для постоянного анализа Security Events и расследования Incidents.

SIEM, EDR, XDR и SOAR являются инструментами SOC, но сами по себе не заменяют операционную команду. Главная задача SOC — превратить технический Alert в понятное решение: является ли событие атакой, какие системы затронуты и какие действия нужно выполнить.

Эффективный SOC строится вокруг качественной Telemetry, Detection Rules, Runbooks, четкой эскалации и измеримых показателей MTTD и MTTR. Для компаний, которым собственный круглосуточный центр слишком дорог, альтернативой может быть внешний SOC или MDR-сервис.