Positive Technologies

Детекты и аналитика SOC, приоритизация событий, LLM в безопасности

Разработчик продуктов для защиты корпоративной инфраструктуры: мониторинг событий, анализ трафика, поиск уязвимостей. ML здесь редко работает автономно — он помогает аналитику центра мониторинга: снижает поток событий, объединяет их в цепочки и подсказывает, с чего начать разбор. Поэтому и метрики измеряются работой аналитика, а не только качеством классификатора.

Этапы отбора

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

Все форматы проверок →
  1. Скрининг

    Рекрутер уточняет направление: аналитика событий, работа с трафиком, продуктовые ML-фичи, исследования.

  2. Алгоритмическая секция

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

  3. ML-секция: модели, признаки, валидация

    ML-секция: модели на событиях, дисбаланс, метрики, валидация во времени.

  4. Секция по ML в безопасности

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

  5. Секция по LLM, RAG и агентам

    Для направлений с языковыми моделями — секция по LLM: помощь в разборе инцидентов, оценка ответов, ограничения.

  6. Финальная встреча

    Команда, задачи, уровень.

Что оценивают на любом направлении
  • Понимание работы центра мониторинга: модель должна экономить время аналитика, а не добавлять ему задач.
  • Готовность работать с данными без готовой разметки и строить её самому.
  • Внимание к объяснимости: аналитик должен понимать, почему событие поднялось наверх.
  • Понимание, что противник активно противодействует детектированию.

Чем проверяют себя перед отбором

4 формата проверки из отбора Positive Technologies — и тест атласа под каждый. Слабые места видно сразу после захода, а темы для разбора собираются автоматически.

Живое кодирование: решение вслух и код в редакторе

На чём валятся
  • Молчаливое написание кода: интервьюер оценивает ход рассуждения, а не только результат.
  • Отсутствие практики — теория известна, но простая задача пишется час.

Классика табличных задач и честная проверка качества

На чём валятся
  • «Взял бустинг, получил 0.85 AUC» без бейзлайна и без объяснения, что это значит для продукта.
  • Случайное разбиение в задаче, где данные упорядочены во времени.
24 вопроса в банкеТест: Классический ML

Редкие события, состязательный противник и цена ложной тревоги

На чём валятся
  • ROC-AUC как единственная метрика при доле положительных в сотые доли процента.
  • Статичная модель без плана обновления в состязательной задаче.
24 вопроса в банкеТест: Классический ML

Программа подготовки под компанию

20 тем по всем направлениям Positive Technologies — если команда ещё не выбрана. Программа разложит их по неделям от математики к продакшену; под конкретное направление список короче, и его можно собрать ниже.

Собрать программу подготовки

Эти 20 тем можно разложить по неделям: программа выстроит их от математики к продакшену, поставит тест в конце каждой недели и вернёт тему на повторение, если вы в ней ошиблись. Выйдет примерно 4 недели под Positive Technologies · Все направления.

Проверяем, вошли ли вы…

Направления

Выберите направление: обязательные темы со ссылками в атлас, типовые вопросы с ответами и тест для самопроверки.

Все тесты →
Направление

Аналитика событий и приоритизацияSOC Analytics

Снижение потока событий, объединение в инциденты, приоритизация разбора. Специфика — сотни тысяч событий в сутки, единицы настоящих инцидентов и аналитик как конечный потребитель.

Пройти тест: Классический ML (24 вопроса)
Собрать программу подготовки

Эти 10 тем можно разложить по неделям: программа выстроит их от математики к продакшену, поставит тест в конце каждой недели и вернёт тему на повторение, если вы в ней ошиблись. Выйдет примерно 2 недели под Positive Technologies · Аналитика событий и приоритизация.

Проверяем, вошли ли вы…

Типовые вопросы секции (4)
Какая метрика правильная для системы приоритизации событий?

Не точность классификатора, а работа аналитика: доля подтверждённых инцидентов в первых N разобранных событиях и время до обнаружения настоящего инцидента. Модель ранжирует очередь, поэтому метрики @K отражают её пользу точнее, чем средние по всему потоку.

Разбор в атласе: Precision — Точность
Как объединять разрозненные события в один инцидент?

Графом связей: общие хосты, учётные записи, адреса, временная близость. Компоненты связности и обнаружение сообществ дают кандидатов на цепочку атаки, а правила и модель оценивают их правдоподобие. Разбор цепочки экономит аналитику больше времени, чем фильтрация отдельных событий.

Разбор в атласе: Community Detection — Поиск сообществ
Разметки инцидентов почти нет. Как обучать модель?

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

Разбор в атласе: Weak Supervision — Слабая разметка
Аналитик не доверяет модели. Что с этим делать технически?

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

Разбор в атласе: SHAP — SHAP
Что сделать руками до собеседования
  • Постройте ранжирование событий и посчитайте долю подтверждённых инцидентов в первых N.
  • Соберите граф связей событий и проверьте, объединяются ли в нём шаги одной атаки.
  • Сделайте контур обратной связи от вердиктов и оцените прирост качества после дообучения.