Инженерия обнаружения
SIEM и правила обнаружения — корреляция, ключевые источники логов, разметка по MITRE ATT&CK, IOC против IOA, пирамида боли, EDR против AV, threat intelligence и тюнинг без слепых зон.
13 вопросов
JuniorТеорияОчень частоЧто такое ложные срабатывания и пропуски в алертинге и почему усталость от алертов — это провал безопасности?
Что такое ложные срабатывания и пропуски в алертинге и почему усталость от алертов — это провал безопасности?
Ложное срабатывание — алерт на безобидную активность; пропуск — реальная атака без алерта. Поток ложных срабатываний вызывает усталость: очередь закрывают не читая, и настоящий детект теряется вместе с шумом. Шум становится пропущенным взломом, а не потерей часов.
Типичные ошибки
- ✗Менять местами определения ложного срабатывания и пропуска
- ✗Считать шум алертов операционным неудобством, а не провалом детекта
- ✗Плодить алерты ради видимости покрытия, когда очередь никто не читает
Уточняющие вопросы
- →Как измерить, стоит ли вообще оставлять конкретное правило?
- →Что проверить перед отключением правила, чтобы не создать слепую зону?
JuniorТеорияОчень частоЧем индикаторы компрометации (IOC) отличаются от индикаторов атаки (IOA) при обнаружении?
Чем индикаторы компрометации (IOC) отличаются от индикаторов атаки (IOA) при обнаружении?
IOC — статический артефакт после факта: хеш файла, IP, домен, ключ реестра. IOA — поведенческая последовательность в моменте, например документ, запускающий командную оболочку. IOC точны, но быстро устаревают; IOA переживают смену инструментов.
Типичные ошибки
- ✗Путать термины местами — называть хеш файла индикатором атаки
- ✗Строить детект только на IOC-фидах и никогда на поведении
- ✗Считать, что IOC не устаревают, и держать в правилах старые хеши и IP
Уточняющие вопросы
- →Почему детект по хешу устаревает быстрее поведенческого?
- →Какая телеметрия нужна, чтобы правило на IOA вообще можно было написать?
JuniorТеорияЧастоЧто даёт защитнику агент EDR (обнаружение и реагирование на конечных точках), чего нет у сигнатурного антивируса?
Что даёт защитнику агент EDR (обнаружение и реагирование на конечных точках), чего нет у сигнатурного антивируса?
EDR непрерывно пишет поведение хоста: деревья процессов, командные строки, соединения, запись файлов — и отдаёт для детекта, хантинга и реагирования. Сигнатурный антивирус сверяет известные файлы при сканировании, поэтому бесфайловые и новые атаки проходят мимо.
Типичные ошибки
- ✗Называть EDR просто антивирусом с большим числом сигнатур
- ✗Считать, что сигнатурный движок ловит бесфайловую активность и легитимные утилиты
- ✗Забывать, что ценность EDR — в сохранённой телеметрии, а не только в блокировке
Уточняющие вопросы
- →Какие поля EDR важнее всего при разборе подозрительного процесса?
- →Почему сохранённая телеметрия EDR вообще делает возможным threat hunting?
JuniorТеорияЧастоЧто такое корреляционное правило в SIEM — платформе агрегации логов, и почему важно его временное окно?
Что такое корреляционное правило в SIEM — платформе агрегации логов, и почему важно его временное окно?
Корреляционное правило срабатывает, только когда сходятся несколько событий: 20 неудачных входов, затем успешный по той же учётке. Окно задаёт, что считать одной историей: узкое пропустит медленную атаку, широкое склеит посторонний шум в ложный алерт.
Типичные ошибки
- ✗Считать корреляционное правило одиночным условием или поиском по слову
- ✗Расширить окно ради полноты и утонуть в склейке посторонних событий
- ✗Думать, что узкое окно всегда безопаснее — медленные атаки выпадают из него
Уточняющие вопросы
- →Как подобрать окно для медленного password spraying по многим учёткам?
- →Какое состояние SIEM должен хранить, чтобы считать многособытийное правило?
MiddleДебаггингЧастоВ логе прокси один хост обращается к одному и тому же домену каждые 60 секунд. Разберите случай и скажите, что происходит.
В логе прокси один хост обращается к одному и тому же домену каждые 60 секунд. Разберите случай и скажите, что происходит.
Почти постоянный интервал и одинаково крошечные ответы — это машинная периодичность, а не человеческий сёрфинг, который рваный. Подтвердите через EDR: процесс и его родитель, проверьте возраст и репутацию домена, затем изолируйте хост, если процесс недоверенный.
Открыть задачу →Типичные ошибки
- ✗Считать фиксированный интервал доказательством легитимного апдейтера, не проверив процесс
- ✗Доверять строке user-agent как свидетельству, что трафик вёл человек
- ✗Выносить вердикт по одним сетевым логам, без перехода на телеметрию хоста
Уточняющие вопросы
- →Как джиттер в интервале изменил бы ваш подход к детекту?
- →Какие поля EDR решают, легитимен ли вызывающий процесс?
MiddleТеорияЧастоКакие сигналы телеметрии указывают на утечку данных или маячок управляющего канала C2?
Какие сигналы телеметрии указывают на утечку данных или маячок управляющего канала C2?
В DNS смотрите на объём запросов, длинные случайные поддомены и высокую энтропию. На выходе — на перекос выгрузки и новые назначения. Для маячка — на почти фиксированный интервал с малым джиттером к одному хосту. Базовая линия — по пользователю и активу.
Типичные ошибки
- ✗Полагаться на плоский порог по байтам вместо базовой линии по пользователю или активу
- ✗Доверять трафику только потому, что он идёт по порту 443 или 53
- ✗Игнорировать тайминг соединений, из-за чего медленный маячок не выделяется
Уточняющие вопросы
- →Как отличить маячок от легитимного опрашивающего агента или проверки обновлений?
- →Почему джиттер в интервале усложняет детект, построенный на интервалах?
MiddleТеорияЧастоКакие источники логов обязательны для обнаружения и что становится невидимым без каждого из них?
Какие источники логов обязательны для обнаружения и что становится невидимым без каждого из них?
EDR даёт родословную процессов и командные строки; логи аутентификации — злоупотребление учётками и продвижение по сети; DNS и прокси раскрывают управляющий канал и утечку; облачный аудит — изменения control plane. Уберите один — класс активности исчезнет.
Типичные ошибки
- ✗Считать, что нормализация в SIEM делает разные источники взаимозаменяемыми
- ✗Собирать только сетевую телеметрию и терять весь процессный контекст
- ✗Пропускать облачный аудит, из-за чего изменения control plane не оставляют следа
Уточняющие вопросы
- →Какой источник подключите первым при ограниченном бюджете приёма и почему?
- →Как доказать, что источник действительно идёт, а не молча сломался?
MiddleТеорияЧастоЧем тактики отличаются от техник в матрице поведения атакующих MITRE ATT&CK и почему процент покрытия вводит в заблуждение?
Чем тактики отличаются от техник в матрице поведения атакующих MITRE ATT&CK и почему процент покрытия вводит в заблуждение?
Тактики — цели атакующего: закрепление, эксфильтрация; техники — конкретные способы их достичь. Разметка детектов по техникам показывает пробелы, но процент обманчив: одно слабое правило помечает технику покрытой, а сами техники очень разные по значимости.
Типичные ошибки
- ✗Переворачивать иерархию — считать техники целями, а тактики способами
- ✗Отчитываться процентом покрытия так, будто все техники равнозначны
- ✗Помечать технику покрытой, когда правило ловит лишь один узкий вариант
Уточняющие вопросы
- →Как взвесить техники по значимости именно для вашей отрасли?
- →Какие доказательства подтверждают, что размеченная техника действительно детектится?
MiddleДебаггингЧастоАлерт о переборе паролей срабатывает 400 раз в сутки, и SOC закрывает его автоматом. Разберитесь и настройте правило.
Алерт о переборе паролей срабатывает 400 раз в сутки, и SOC закрывает его автоматом. Разберитесь и настройте правило.
Неудачи считаются по исходному IP, а VPN-шлюз прячет за одним адресом сотни пользователей, поэтому обычные опечатки перебивают порог. Считайте по учётной записи, а для общего выхода алертите на число разных учёток с неудачами — так spraying остаётся видимым.
Открыть задачу →Типичные ошибки
- ✗Поднять порог, что глушит spraying вместо устранения шума
- ✗Полностью исключить IP шлюза и потерять всю видимость за ним
- ✗Читать общий NAT-адрес как одного атакующего пользователя
Уточняющие вопросы
- →Как доказать, что настроенное правило всё ещё ловит медленный spraying?
- →Каким контекстом обогатить алерт, чтобы ускорить разбор?
MiddleТеорияЧастоЧто модель иерархии индикаторов «пирамида боли» говорит о детектах по хешам и IP против детектов на уровне TTP?
Что модель иерархии индикаторов «пирамида боли» говорит о детектах по хешам и IP против детектов на уровне TTP?
Она ранжирует индикаторы по цене их смены для атакующего. Хеши и IP внизу: их меняют за минуты, поэтому детекты на них быстро протухают. Инструменты и TTP (тактики, техники, процедуры) наверху — перестройка ремесла дорога, и такие детекты живут долго.
Типичные ошибки
- ✗Читать пирамиду как сложность сбора для защитника, а не как цену для атакующего
- ✗Строить программу детекта почти целиком на фидах хешей и IP
- ✗Считать правило уровня TTP просто медленной версией совпадения по индикатору
Уточняющие вопросы
- →Какая телеметрия нужна детекту уровня TTP, но не нужна совпадению по хешу?
- →Как обосновать стоимость поведенческих правил против дешёвого IOC-фида?
MiddleТеорияИногдаЧем различаются стратегическая, операционная и тактическая threat intelligence и почему IOC-фиды нужно устаревать?
Чем различаются стратегическая, операционная и тактическая threat intelligence и почему IOC-фиды нужно устаревать?
Стратегическая разведка питает решения о рисках, операционная описывает кампании и акторов, тактическая поставляет машиночитаемые IOC. Тактическая протухает быстрее всех: адреса переназначают, домены — в sinkhole, поэтому индикаторы без срока бьют по невиновным.
Типичные ошибки
- ✗Путать уровни — называть фид IOC стратегической разведкой
- ✗Заливать фид индикаторов в блокировки без политики срока жизни
- ✗Считать все фиды одинаково достоверными вместо оценки по источнику
Уточняющие вопросы
- →Какую политику срока жизни зададите для доменов против хешей?
- →Как измерить, оправдывает ли платный фид своё место в вашем конвейере?
SeniorТеорияИногдаКак находить настоящие пробелы в покрытии детектами и проверять их через совместные учения purple team?
Как находить настоящие пробелы в покрытии детектами и проверять их через совместные учения purple team?
Начинайте с телеметрии, а не с матрицы: техника детектируема, только если данные собираются. Ранжируйте техники по релевантности для вашей отрасли, затем безопасно выполняйте их вместе и фиксируйте, что дало алерт, что лишь попало в лог, а что осталось немым.
Типичные ошибки
- ✗Начинать с матрицы ATT&CK вместо доступной телеметрии
- ✗Принимать заявленное вендором покрытие без проверки в своей среде
- ✗Проводить учения как счёт красных против синих, а не как совместное измерение
Уточняющие вопросы
- →Как выбрать, для каких немых техник детект пишется первым?
- →Что менять, когда техника даёт алерт, но по нему невозможно действовать?
SeniorДизайнИногдаВы отвечаете за обнаружение в компании на 3000 человек: 4000 Windows-хостов с EDR, Active Directory, локальные прокси и DNS-резолвер, два аккаунта AWS. Бюджет SIEM покрывает около 300 ГБ в сутки, а конвейер уже принимает 450 ГБ — в основном подробные события Windows и разрешающие строки прокси. Детект обязан по-прежнему закрывать злоупотребление учётками, продвижение по сети, маячки управляющего канала и изменения control plane в облаке, а аналитики должны искать по истории за 12 месяцев. Комплаенс требует год хранения логов аутентификации и облачного аудита. Спроектируйте конвейер: что оставить в полной точности, что фильтровать или агрегировать на краю, что увести в дешёвое хранилище вместо SIEM и как затем доказать, что ни один детект не потерял свой источник.
Вы отвечаете за обнаружение в компании на 3000 человек: 4000 Windows-хостов с EDR, Active Directory, локальные прокси и DNS-резолвер, два аккаунта AWS. Бюджет SIEM покрывает около 300 ГБ в сутки, а конвейер уже принимает 450 ГБ — в основном подробные события Windows и разрешающие строки прокси. Детект обязан по-прежнему закрывать злоупотребление учётками, продвижение по сети, маячки управляющего канала и изменения control plane в облаке, а аналитики должны искать по истории за 12 месяцев. Комплаенс требует год хранения логов аутентификации и облачного аудита. Спроектируйте конвейер: что оставить в полной точности, что фильтровать или агрегировать на краю, что увести в дешёвое хранилище вместо SIEM и как затем доказать, что ни один детект не потерял свой источник.
Разделяйте по ценности для детекта, а не по объёму. Горячими в SIEM остаются события процессов EDR, аутентификация, DNS, прокси и облачный аудит; подробный шум Windows и разрешающие строки прокси фильтруются на краю, сырьё дёшево архивируется. Свяжите правила с полями источников.
Типичные ошибки
- ✗Равномерно семплировать источники, что незаметно ломает многособытийную корреляцию
- ✗Резать источник по сырому объёму, а не по его ценности для детекта
- ✗Фильтровать без связи правил с источниками, из-за чего потеря поля молча глушит правило
Уточняющие вопросы
- →Как обнаружить, что источник перестал идти после смены формата логов?
- →Какие события оставите горячими, хотя по отдельности они редки?
