Какие метрики включил бы в отчет об проверке уязвимости сотрудников к фишингу

Развернутый отчет по метрикам фишингового тестирования

Как DevOps Engineer с акцентом на безопасность инфраструктуры и процессов (DevSecOps), я подхожу к отчету о фишинговых тестах не просто как к статистике, а как к инструменту для снижения операционных и репутационных рисков. Моя цель — превратить данные в исполнимые инженерные и организационные решения.

Ключевые метрики эффективности (KPI)

Эти метрики дают общую картину уязвимости организации.

1. Общий процент успешных атак (Click Rate):

    *   **Что это**: Процент сотрудников, перешедших по ссылке или открывших вложение в фишинговом письме.
    *   **Зачем**: Базовый индикатор уровня бдительности. Рост этого показателя — прямой сигнал для ужесточения технических контролей (например, настройки **SPF, DKIM, DMARC**, фильтрации входящей почты).

1. Процент предоставления данных (Submission Rate):

    *   **Что это**: Процент сотрудников, введших свои учетные данные (логин/пароль) на фишинговой странице.
    *   **Зачем**: Наиболее критичный показатель. Высокий `Submission Rate` требует немедленного реагирования: принудительной смены паролей, аудита правил **MFA (Multi-Factor Authentication)** и проверки систем **SIEM (Security Information and Event Management)** на предмет аномальных входов.

1. Процент сообщений об инциденте (Report Rate):

    *   **Что это**: Процент сотрудников, которые не только не поддались на атаку, но и официально сообщили о подозрительном письме (например, через кнопку "Report Phish" в клиенте).
    *   **Зачем**: Показывает зрелость **культуры безопасности**. Высокий `Report Rate` — это "человеческий сенсорный слой", который компенсирует возможные провалы технических средств.

Глубинные метрики для анализа и улучшений

Эти метрики помогают понять "почему" и определить точки приложения усилий.

1. Временные метрики (Time to Click / Time to Report):

    *   **Анализ**: Как быстро после получения письма происходит клик или отчет. Быстрые клики (<2 мин) указывают на автоматизм и отсутствие проверки. Быстрые отчеты (<5 мин) — на эффективность тренировок.
    *   **Пример для дашборда**:

    ```sql
    -- Усредненное время до клика по фишинговой кампании
    SELECT campaign_id,
           AVG(EXTRACT(epoch FROM (click_time - email_delivery_time))) / 60 as avg_minutes_to_click
    FROM phishing_results
    WHERE click_time IS NOT NULL
    GROUP BY campaign_id;
    ```

2. Метрики по сегментам организации:

    *   **Анализ по отделам**: Финансы, HR, DevOps и R&D — традиционные цели целенаправленного фишинга. Сравнение их показателей помогает адресовать обучение.
    *   **Анализ по локациям/устройствам**: Показывает, чаще ли кликают с мобильных устройств или корпоративных рабочих станций. Это влияет на политики **MDM (Mobile Device Management)** и настройки почтовых клиентов.

1. Повторяемость поведения (Repeat Clickers / Repeat Reporters):

    *   **Зачем**: Выявление сотрудников, попадающихся многократно (требуют персонального вмешательства) и "чемпионов безопасности" (многократно сообщающих, их можно поощрять).

Метрики эффективности контрмер (Engineering Metrics)

Здесь фокус смещается на DevOps — как мы автоматизируем реакцию и укрепляем систему.

1. Эффективность технических средств защиты:

    *   **Показатель**: Сколько писем было **блокировано** почтовым шлюзом (**Secure Email Gateway**) до доставки пользователю, а сколько пропущено и легло в основу теста.
    *   **Действие**: Настройка правил сигнатур и анализа поведения (**UEBA**).

1. Скорость реагирования на инцидент:

    *   **Показатель**: Время от получения первого отчета о фишинге до:
        *   Добавления IoC (Indicators of Compromise) в фильтры.
        *   Принудительного сброса паролей для скомпрометированных учетных записей (если тест был реалистичным).
    *   **Пример автоматизации ответа (псевдокод)**:

    ```python
    # Интеграция webhook платформы фишинга с тикет-системой и Active Directory
    def handle_phish_report(employee_email, phishing_url):
        # 1. Создать высокоприоритетный тикет в ServiceNow/Jira
        ticket_id = create_incident_ticket(employee_email, phishing_url, severity="HIGH")

        # 2. Автоматически добавить URL в блокировщик веб-прокси (например, Squid)
        block_url_at_proxy(phishing_url)

        # 3. Если тест был "credential harvesting" - запланировать принудительную смену пароля
        if "credential_harvest" in phishing_url:
            schedule_forced_password_reset(employee_email, delay_minutes=5)
            send_alert_to_soc(employee_email)

        log_action(ticket_id, f"Automated containment initiated for {employee_email}")
    ```

3. Коэффициент снижения риска (Risk Reduction Ratio):

    *   **Расчет**: Сравнение метрик (`Click Rate`, `Submission Rate`) до и после цикла "тест → обучение → внедрение технической контрмеры".
    *   **Пример**: После теста, выявившего уязвимость к имитации внутреннего сервиса, мы внедрили **строгую привязку сессии (Session Binding)** и **MFA** для этого сервиса. Следующий тест должен показать близкий к нулю `Submission Rate`, даже если `Click Rate` останется высоким.

Рекомендуемый формат отчета (Executive Summary)

Отчет должен содержать:

• Тренд за квартал/год: Снижается ли общий Click Rate?
• Топ-3 самых успешных сценария атаки: (например, "Уведомление от HR", "Сбой в CI/CD", "Обновление VPN").
• Рекомендации: Разбитые на категории:

    *   **Немедленные технические**: "Усилить фильтрацию писем с темой 'Срочное обновление учетных данных'".
    *   **Обучение**: "Провести целевую тренировку для отдела разработки на тему фишинга через поддельные уведомления от GitLab/Jenkins".
    *   **Процессные**: "Автоматизировать процедуру блокировки фишинговых URL в течение 15 минут после первого отчета".

Такой комплексный подход превращает фишинговый тест из "карательной" акции в цикл непрерывного улучшения безопасности, где данные напрямую влияют на конфигурацию инфраструктуры, процессы CI/CD (в части проверки зависимостей) и культуру команд.