Вопросы на собеседовании: Аналитик кибербезопасности

Я буду настраивать самые затратные детекты по размеченным результатам, сохраняя подтвержденное покрытие ATT&CK.

• В Splunk ES я ранжирую 120 поисков по времени аналитиков и доле ложных срабатываний, затем настрою 15 правил, создающих 70% нагрузки, прежде чем трогать малошумные детекты.
• Я добавлю критичность активов, контекст учетной записи и 14-дневные базовые уровни в пороги SPL, допустив до 10 минут задержки корреляции ради сокращения безопасных оповещений минимум на 60%.
• После каждого изменения я повторю тесты Atomic Red Team для 20 приоритетных техник ATT&CK и отменю настройку правила, если полнота упадет ниже 95%, даже если цель в 5% ложных срабатываний не достигнута.

Я буду коррелировать медленные массовые отказы по учетным записям и источникам вместо фиксированного порога для одного пользователя.

• В Sentinel KQL я агрегирую отказы за 10 минут по IP-источнику, tenant и протоколу аутентификации, требуя минимум 20 пользователей и долю отказов выше 95%, чтобы убрать обычные ошибки ввода.
• Я обогащу данные named locations Entra ID и списками сервисных учетных записей, допустив проверяемый allowlist не более чем из 30 сканеров ради повышения точности до 90%.
• Я проверю T1110.003 на 12 положительных и 40 безопасных fixtures в тестовом workspace Sentinel, оставив запуск запроса каждые 5 минут, чтобы задержка не превышала 15 минут ценой дополнительных вычислений.

Я буду обнаруживать подозрительные последовательности и контекст запуска shell, а не каждый интерактивный запуск.

• В Elastic EQL я свяжу сетевой родительский процесс, запуск shell и следующую утилиту в пределах 60 секунд, сократив поиск на 180 000 EPS до ограниченной последовательности из 3 событий.
• Я потребую редкую пару родителя и потомка либо запуск сервисной учетной записью, используя 30-дневный базовый уровень и допуская 24 часа на обучение ради лимита в 300 оповещений в день.
• Я проверю 15 вариантов T1059.004 и 100 примеров скриптов развертывания на репрезентативном replay со скоростью 180 000 EPS, отклонив правило при p95 задержки выше 2 минут или полноте ниже 90%.

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

• В слое ATT&CK Navigator я зафиксирую все 40 техник, источник данных, платформу, ID правила, владельца и последний тест, считая видимость, детект и предотвращение 3 отдельными состояниями.
• Я выполню тесты Atomic Red Team или CALDERA минимум для 10 техник за sprint, допустив 2 часа контролируемого простоя тестовых хостов, чтобы завершить все 40 за 90 дней.
• Я отчитаюсь по доле подтвержденных детектов и возрасту тестов, требуя срабатывания в пределах SLO для 90% из 40 техник и показывая технику без теста за 90 дней как непроверенную, а не зеленую.

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

• Я сохраню все 180 правил Sigma с logsource, соответствием ATT&CK, владельцем и 6 положительными и отрицательными fixtures, а SPL, KQL и Elasticsearch-запросы создам через backends pySigma.
• Я разрешу платформенные overrides максимум для 15% правил, где различаются joins или семантика полей, принимая двойную поддержку только при повышении точности нативной логики минимум на 10 процентных пунктов.
• CI воспроизведет каждый созданный запрос на выборке за 7 дней и заблокирует выпуск при совпадении результатов ниже 85%, а срок исключения в 30 дней не позволит расхождению стать постоянным.

Я сделаю версионируемые тесты, ограниченную shadow-проверку и откат через Git обязательными для каждого изменения детекта.

• GitHub Actions проверит синтаксис и схему 25 еженедельных правил и запустит минимум 5 положительных и 20 безопасных fixtures на правило, добавив около 8 минут к CI.
• API Splunk REST, Sentinel Content или Elastic Detection Engine опубликуют кандидатов как shadow rules на 7 дней только в именованных тестовых workspaces или indexes, блокируя выпуск при объеме выше 125% базового или точности ниже 80%.
• Production-выпуск применит одобренную Git-ревизию через тот же API, а rollback повторно развернет предыдущий Git tag за 15 минут ради доли неудачных изменений ниже 2%.

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

• В CrowdStrike Falcon LogScale я размечу результаты за 30 дней по командной строке, подписи, родителю, пользователю и уровню актива, затем найду 5 безопасных кластеров, создающих минимум 80% объема.
• Я подавлю только подписанные одобренные комбинации через allowlist с владельцем и сроком 45 дней, принимая до 20 минут еженедельной поддержки ради снижения объема ниже 500 оповещений.
• После каждого изменения я воспроизведу 2 существенных случая и минимум 20 вариантов эмуляции, отклонив настройку при полноте ниже 95%, даже если нагрузка аналитиков останется высокой.

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

• В матрице телеметрии я свяжу каждый из 30 детектов с обязательными полями и ранжирую источники по уникальному покрытию, сохранив Entra audit, EDR process, DNS и cloud control-plane события, поддерживающие минимум 2 поведения.
• Через Cribl Stream я удалю подробные события успеха и отправлю сырые копии в object storage, допустив 30 минут на холодное получение ради снижения приема SIEM с 9 до 5 ТБ в день.
• Я установлю ежедневный SLO в 98% для доставки событий и полноты полей, восстановив любой отфильтрованный класс за 4 часа, если canary-детект или проверка схемы потеряет покрытие.

Я сначала докажу, помещается ли поток в канал, а затем оставлю достаточный запас для разгрузки backlog после сбоя.

• Канал 200 Мбит/с передает 25 МБ/с, около 208 байт на событие при 120 000 EPS до overhead; если измеренный compressed wire size выше, полная передача в real time математически невозможна.
• Cribl удержит detection-critical поток ниже 50% канала, что эквивалентно примерно 104 байтам на событие при полном EPS, а raw low-priority events сохранит в регионе для поздней передачи или secondary path.
• Kafka сохранит минимум 2 часа с диском по measured stored bytes и replication factor, а 50% свободной полосы должны выгрузить 30-минутный critical backlog за следующие 30 минут теста сбоя.

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

• В Microsoft Sentinel я свяжу sign-ins Entra из 60 приложений с device ID, ASN, результатом MFA, token ID и 30-дневным профилем пользователя, потребовав 2 несогласованных свойства помимо локации.
• Я учту 12 разрешенных диапазонов VPN и ASN мобильных операторов как контекст, а не полные исключения, допустив 5 минут задержки обогащения ради точности 85%.
• Я проверю T1078 на 25 воспроизведенных аномальных сессиях и 200 безопасных примерах поездок, сохранив полноту выше 90% и снизив объем с 1 600 до 250 оповещений в день.

Я построю профиль разрешенных хостов, протоколов и расписания каждой сервисной учетной записи и буду сообщать об ограниченных отклонениях.

• Splunk UBA изучит 30 дней источников и часовых профилей всех 6 500 учетных записей до применения отклонений.
• Splunk ES свяжет входы 4624 типов 2 или 10 с 4672 по Logon ID и потребует новый хост или расписание; 4672 означает назначение специальных привилегий, а не доступ к привилегированной группе.
• Отдельный сигнал отследит изменения членства по событиям 4728, 4732 и 4756 и свяжет измененную учетную запись с последующим аномальным входом.
• Я сначала подключу 200 самых привилегированных учетных записей и воспроизведу 20 одобренных изменений jobs с целью менее 100 оповещений в день и ниже 5% неудачных batch-задач.

Я совместно оценю новизну домена и признаки туннелирования, чтобы обычный DNS-шум не доминировал.

• В Elastic Security я агрегирую 15-минутные окна Zeek DNS по хосту и домену, оценивая длину label выше 40 символов, энтропию, долю NXDOMAIN и более 500 запросов как признаки T1071.004.
• Я добавлю 30-дневный профиль доменов и allowlist корпоративных resolver, принимая 24 часа задержки для новых одобренных сервисов ради сокращения 90 миллионов запросов до 50 кейсов в день.
• Я проверю 10 контролируемых шаблонов iodine или dnscat2 и 100 доменов обновления ПО, потребовав минимум 90% полноты вредоносных примеров и менее 2% ложных срабатываний в размеченной выборке.

Я свяжу encoded execution с происхождением, содержанием и последующим поведением вместо широкого подавления PowerShell.

• CrowdStrike Falcon свяжет командные строки PowerShell с родительским процессом, подписью, пользователем, сетевым соединением и результатом AMSI, требуя минимум 2 подозрительных признака за 5 минут.
• Я добавлю allowlist из 40 подписанных административных скриптов по SHA-256 и владельцу на 30 дней, принимая еженедельную пересертификацию ради сокращения 4 500 оповещений минимум на 80%.
• Тесты Atomic Red Team T1059.001 охватят 15 вариантов кодирования и скачивания, а выпуск заблокируется при полноте ниже 95% или p95 задержки оповещения выше 3 минут.

Я буду обнаруживать новые пути доверия AWS-ролей, а прикрепление policies вынесу в отдельную аналитику расширения привилегий.

• Splunk ES сравнит старый и новый trust document в CloudTrail UpdateAssumeRolePolicy и свяжет субъекта, целевую роль, нового trusted principal, исходный аккаунт и 45-дневный профиль.
• Детект сообщит о новом неодобренном principal и повысит уверенность после его успешного AssumeRole, исключая автоматизацию только при одобренной identity и change ID ради объема ниже 30 оповещений в день.
• AttachRolePolicy и PutRolePolicy попадут в отдельную аналитику расширения привилегий, а 12 тестов изменения доверия и 100 одобренных deployments должны дать 95% полноты за 10 минут.

Я буду выводить или перестраивать правила по результатам тестов и ценности угрозы, а не только по частоте оповещений.

• Splunk Monitoring Console ранжирует все 260 правил по стоимости поиска, пропущенным запускам, приоритету ATT&CK и подтвержденным находкам, выделив 20 поисков с 60% scheduler load.
• Я переведу широкие real-time поиски в 5-минутные запросы по ускоренным data models там, где это разрешает SLO, принимая до 5 минут задержки ради снижения общих вычислений на 25%.
• 90 тихих правил останутся только при успешных тестах Atomic Red Team и приоритетной технике; иначе перед выводом правило 30 дней проработает как включенный non-paging shadow search с одобрением владельца.

Я рассчитаю мощность до распределения по уровням и сокращу ручную проверку до объема, который реально выдерживает roster.

• Все 40 человек дают максимум 8 gross minutes на alert при 12 000 alerts и 40-часовой неделе, а с shrinkage 30% остается 5,6 минуты еще до резерва на расследования и engineering.
• Если 10 специалистов оставить на сложные расследования и 6 на detection engineering, у 24 triage-аналитиков будет 4,8 gross minutes, поэтому новый handoff на 3 минуты невозможен без сокращения intake.
• Обогащение и проверенное risk splitting ограничат ручной review примерно 5 040 alerts при AHT 8 минут и shrinkage 30%, а поля ServiceNow и еженедельный QA снизят rework ниже 8%.

Я применю ночной triage MDR с жестким бюджетом внутреннего on-call и договорным резервом.

• MDR подтвердит все 180 ежемесячных оповещений высокой важности за 10 минут, соберет обязательные доказательства и разрешит либо передаст кейсы по одобренным playbooks.
• Ротация из 6 senior-аналитиков примет не более 6 ночных эскалаций в неделю суммарно; седьмой и следующие кейсы останутся у резервной команды MDR до передачи в рабочую смену.
• Каждый ночной вызов даст аналитику 8 часов восстановления и именованную замену в следующей смене, а потерянная мощность будет учтена в roster.
• Пилот за 90 дней измерит пропущенные кейсы, подтверждение, overflow, соблюдение восстановления и стоимость до решения о переносе внутрь.

Я автоматизирую сбор доказательств, оставив аналитику только неоднозначную классификацию и определение масштаба.

• Cortex XSOAR за 3 минуты получит заголовки, результат detonation URL, историю отправителя, число получателей и mailbox actions, экономя около 15 минут аналитика на каждом из 700 кейсов.
• Playbook автоматически закроет кейс только при согласии 5 безопасных проверок и уверенности выше 98%, оставляя около 20% кейсов вручную ради ошибочного закрытия ниже 2%.
• Еженедельная QA-выборка из 100 кейсов в ServiceNow измерит медиану обработки и ошибку закрытия, а нарушение 12 минут или 2% в течение 2 недель отменит последнее изменение автоматизации.

Я перенесу поддерживаемую первичную аналитику ближе к региональной identity-телеметрии и отделю ее передачу от массовых логов.

• Региональные workspaces Sentinel применят NRT rules с минутным циклом для совместимой identity-логики; неподдерживаемые joins получат минимальный поддерживаемый scheduled-интервал, например 5 минут, а не выдуманный запуск каждые 2 минуты.
• Identity-события пойдут через отдельный Event Hub и выделенную consumer group, отдельно от массовой телеметрии, с региональным буфером на 30 минут; я не буду приписывать Event Hubs приоритизацию записей внутри одного потока.
• Я разделю 8 минут по типу правила, например на 2 минуты приема, 5 минут scheduled-анализа и 1 минуту доставки, и вызову владельца при нарушении участка.

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

• ServiceNow SecOps обогатит каждый кейс данными CMDB, Entra ID и CrowdStrike за 2 минуты, принимая ежедневную сверку длительностью 1 час ради устранения большей части текущего ожидания в 35%.
• Cortex XSOAR параллельно выполнит 6 read-only запросов и приложит результаты к стандартному timeline, экономя целевые 30 минут на кейс высокой важности без автоматического сдерживания.
• Я буду 8 недель измерять p50 и p90 MTTR по playbooks и выпущу изменение только при медиане ниже 4 часов и доле повторно открытых кейсов менее 3%.