CompTIA SY0-701: Операции по обеспечению безопасности, мониторинг и обнаружение — Руководство по подготовке
Часть CompTIA Security+ SY0-701 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов CompTIA, или пройдите тесты на время на ExamRoll.io.
Современные операции по обеспечению безопасности (Security Operations) зависят от способности наблюдать, сопоставлять и реагировать на сигналы, поступающие из всех уголков предприятия — с конечных точек, сетевых устройств, поставщиков удостоверений, облачных рабочих нагрузок и приложений. Зрелая программа обнаружения — это не отдельный продукт, а целая экосистема, состоящая из конвейеров телеметрии, аналитических движков, аналитиков и автоматизированных рабочих процессов реагирования, созданная для сокращения времени между компрометацией и ее локализацией.
SIEM и централизованная агрегация журналов
Платформа для управления информацией о безопасности и событиями (SIEM) — это связующее звено центра операций по обеспечению безопасности (SOC). Она собирает журналы из разрозненных источников — журналов событий Windows, syslog в Linux, данных о потоках межсетевого экрана, DNS-резолверов, Active Directory, агентов на конечных точках, аудиторских журналов SaaS — нормализует их в общую схему и применяет правила корреляции ко всему агрегированному потоку. Ценность заключается не просто в хранении, а в способности сопоставить неудачную аутентификацию по VPN из одного источника журналов с успешным входом под привилегированной учетной записью и боковым перемещением по SMB из другого, создавая одно высокоточное оповещение там, где три изолированных события были бы просто шумом.
К распространенным платформам относятся Splunk, Microsoft Sentinel, IBM QRadar, Elastic Security и Chronicle. В облачных средах нативные инструменты, такие как AWS CloudTrail в сочетании с CloudWatch и GuardDuty, или Azure Monitor с рабочими областями Log Analytics, служат основой для сбора журналов и часто передают данные в вышестоящую SIEM-систему.
Типичный корреляционный поиск в Splunk, иллюстрирующий логику сопоставления данных из разных источников:
index=wineventlog EventCode=4625
| stats count by src_ip, user
| where count > 10
| join user [search index=vpn action=success]
| table _time, user, src_ip, count
Подвох здесь неочевиден: организация может развернуть SIEM, собирать терабайты данных и все равно пропускать вторжения, потому что отсутствуют критически важные источники журналов. Если события создания процессов на конечных точках (ID события Windows 4688 или ID события Sysmon 1) не пересылаются или журналы запрещающих правил межсетевого экрана усекаются, целые фазы атаки становятся невидимыми. Покрытие источников журналов, явно сопоставленное с фреймворком, таким как MITRE ATT&CK, является необходимым условием для эффективного обнаружения.
Endpoint Detection and Response (EDR)
EDR расширяет видимость до уровня хоста, где в конечном итоге и проявляется большая часть активности злоумышленников. В отличие от традиционных антивирусов, которые сверяют хеши и сигнатуры файлов, EDR-платформы, такие как CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint и Carbon Black, записывают непрерывную телеметрию: деревья процессов, аргументы командной строки, изменения в реестре, сетевые подключения и загрузки DLL. Эти данные позволяют как обнаруживать аномальное поведение в реальном времени, так и проводить ретроспективный поиск угроз (threat hunting).
Распространенное заблуждение — рассматривать EDR как средство предотвращения, эквивалентное межсетевому экрану. EDR в первую очередь обнаруживает и помогает в реагировании — он может блокировать известное вредоносное поведение, но его основная ценность заключается в предоставлении криминалистического следа, который позволяет аналитику определить, что делал скомпрометированный процесс, к каким учетным данным он получил доступ и куда переместился латерально. Действия по реагированию, такие как изоляция хоста, завершение процесса и помещение файла в карантин, обычно инициируются аналитиком или сценарием SOAR, а не одним лишь EDR.
IDS/IPS, сигнатуры и контроль базовых показателей
Сетевые системы обнаружения и предотвращения вторжений (IDS/IPS) проверяют трафик на соответствие сигнатурам и поведенческим моделям. IDS (например, Snort или Suricata в режиме мониторинга) оповещает о подозрительных паттернах; IPS устанавливается в разрыв сети и отбрасывает соответствующий трафик. Правило Snort для обнаружения определенного паттерна эксплойта демонстрирует логику на основе сигнатур:
alert tcp any any -> $HOME_NET 445 (
msg:"SMB Exploit Attempt";
content:"|ff|SMB"; offset:4; depth:4;
content:"|72 00|"; distance:0;
sid:9000001; rev:1;
)
Обнаружение на основе аномалий создает базовый профиль поведения (baseline) и оповещает об отклонениях — рабочая станция, которая внезапно начинает делать DNS-запросы в 10 раз чаще обычного, или сервер, который впервые открывает исходящее соединение на порт 4444, — оба случая требуют расследования независимо от того, совпадает ли трафик с какой-либо сигнатурой.
Аналитика угроз и управление индикаторами
Аналитика угроз (Threat Intelligence) преобразует необработанные данные в полезные знания о тактиках, техниках и процедурах (TTP) злоумышленников. STIX (Structured Threat Information eXpression) — это стандартный формат для представления объектов аналитики угроз (индикаторов, кампаний, субъектов угроз, паттернов атак), а TAXII (Trusted Automated eXchange of Indicator Information) — транспортный протокол для обмена ими. Коммерческие и открытые источники данных (VirusTotal, AlienVault OTX, MISP, Recorded Future) предоставляют репутацию IP-адресов, списки блокировки доменов, хеши файлов и правила YARA, которые могут быть напрямую загружены в SIEM-системы и межсетевые экраны.
Индикаторы компрометации (IoC) — вредоносные IP-адреса, хеши файлов, доменные имена, ключи реестра — это наиболее оперативно применимые, но в то же время и самые недолговечные сведения; злоумышленники быстро меняют инфраструктуру. Индикаторы атаки (IoA) фокусируются на поведении, а не на артефактах: процесс, порождающий дочернюю оболочку, закодированная команда PowerShell или служба, созданная со случайным именем. Обнаружение на основе IoA сложнее обойти, поскольку оно нацелено на технику, а не на конкретный инструмент.
Практический сценарий: пробел в обнаружении из-за отсутствия источников журналов
Финансовая компания развернула SIEM и настроила сбор журналов с периметрового межсетевого экрана, журналов безопасности Windows и шлюза электронной почты. В ходе учений red team команда получила первоначальный доступ через фишинговое письмо (которое было обнаружено), но затем использовала WMI для бокового перемещения и удаленное выполнение команд через PowerShell — ни одно из этих действий не генерировало событий в журналах безопасности Windows при стандартной конфигурации. Команда red team добралась до рабочей станции казначейства и выгрузила имитированный файл банковского перевода, не вызвав ни одного оповещения в SIEM после первоначального обнаружения фишинга. Пробел в защите: Sysmon не был развернут, ведение журнала блоков скриптов PowerShell не было включено, а для журналирования активности WMI требовалась дополнительная настройка. Учения продемонстрировали, что покрытие SIEM эффективно лишь настолько, насколько полны питающие его источники журналов — урок, который необходимо усвоить в ходе учений purple team, а не принимать на веру на основе документации поставщика.
← Сетевая безопасность и архитектура · Все домены · Реагирование на инциденты →
Отработать эти вопросы → · Тесты на время на ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Сдайте экзамен →