Прибыль:
- Способность разработать комплексный рабочий процесс SOC, включающий сбор, обнаружение, сортировку, расследование, вмешательство, улучшение, отчетность и обратную связь с указанием местоположения искусственного интеллекта и человеческих ворот.
- Возможность разделить автоматизацию по уровню риска (шаги с низким риском/обратимые выполняются автоматически, шаги с высоким/необратимым риском контролируются человеком) и разработать путь отката для каждого автоматического действия.
- Возможность создать цикл самоконтроля и обратной связи, который регулярно измеряет частоту ложноположительных/отрицательных результатов, MTTD/MTTR, точность выходных данных и дрейф модели.
Этот последний модуль объединяет части, которые мы изучали отдельно в рамках модуля — анализ журналов, поиск угроз, управление уязвимостями, реагирование на инциденты, фишинг, проверка кода, аналитика, отчетность — в единый сквозной рабочий процесс. В настоящем центре управления безопасностью (SOC) эти этапы не разъединены; Тревога запускает расследование, которое запускает ответ, который запускает отчет, который запускает исправление. Искусственный интеллект задействован в каждом звене этой цепи, но именно человек держит цепь и принимает решения у каждой важной двери.
Кроме того, в этом модуле рассматриваются две важные темы. Первый — это автоматизация: когда SOAR (Security Orchestration, Automation and Response — платформа, которая автоматизирует и организует процессы безопасности) и ИИ объединяются, увеличиваются как мощность, так и риски; Необходимо различать то, что можно автоматизировать, и то, что никогда нельзя убрать из-под контроля человека. Во-вторых, управление качеством и саморегулирование. Операция по обеспечению безопасности с использованием ИИ не создается и не прекращается один раз; его постоянно контролируют, измеряют, пересылают и корректируют. Автоматизация увеличивает скорость, но не снимает ответственности; Программа безопасности остается безопасной только благодаря регулярному самоконтролю.
Комплексный рабочий процесс SOC
Давайте посмотрим, где ИИ вступает в игру и кто его утверждает в типичном жизненном цикле инцидента:
- Сбор и мониторинг: журналы передаются в SIEM; ИИ снижает шум, суммирует. (Автоматически, низкий риск.)
- Обнаружение и сигнализация: правило + аномалия + обнаружение шаблонов AI. (Автоматическое производство; сортировка проводится на людях.)
- Сортировка: является ли сигнал тревоги реальным или ложноположительным? ИИ предлагает обоснование и приоритет; аналитик подтверждает. (Человеческая дверь.)
- Расследование: ИИ собирает доказательства, устанавливает сроки, перечисляет первопричины; Аналитик подтверждает это неопровержимыми доказательствами. (Человеческая дверь.)
- Вмешательство: Изоляция, блокировка, очистка. ИИ обеспечивает выбор/влияние; Решение находится в руках уполномоченного аналитика. (Критические человеческие ворота.)
- Устранение: закрытие уязвимостей, устранение первопричин. проект плана ИИ; одобрение в управлении изменениями. (Человек + процесс.)
- Отчетность: ИИ пишет черновик, адаптируется к аудитории; Эксперт проверяет и подписывает доказательства. (Человеческая дверь.)
- Извлечение уроков и обратная связь: ИИ извлекает закономерности; Обновляет правила и инструкции по обнаружению команд. (Человек + процесс.)
Правило этой цепочки: повторяющиеся и обратимые шаги с низким уровнем риска могут быть автоматизированы; Через человеческие двери проходят рискованные, необратимые и требующие принятия решительных мер шаги.
Таблица решений по автоматизации
шаг
Можно ли это автоматизировать
состояние
человеческое одобрение
Сбор журналов, нормализация
Да, именно
—
не обязательно
Обогащение аварийных сигналов (поиск IOC)
Да
Источник надежный
Он рассматривается
Ложноположительное исключение (заведомо хорошее)
частично
строгое правило
Проверено путем отбора проб
Карантин фишингового письма
частично
высокая точность
Обзор + путь отката
Автоматически заблокировать учетную запись
осторожный
Только четкие критерии
Быстрая проверка человеком
Изолировать сервер
Обычно нет
За исключением критической инфраструктуры
Вынужденное человеческое решение
Исправление (производство)
нет
—
Тестирование + управление изменениями
Официальный отчет/уведомление
нет
—
Эксперт + право
Управление качеством и самоконтроль
Операция по обеспечению безопасности на основе искусственного интеллекта — это живая система; его производительность меняется со временем (новые атаки, изменение среды, обновления модели). Для обеспечения безопасности необходимы регулярные измерения:
- Уровень ложноположительных и ложноотрицательных результатов: как часто ИИ напрасно поднимает тревогу, как часто он упускает реальную угрозу? Особое внимание уделяется ложноотрицательным результатам, поскольку они молчаливо причиняют вред.
- MTTD/MTTR: Улучшается ли среднее время обнаружения и реагирования?
- Точность вывода ИИ: какая часть резюме/выводов/цитатов ИИ проходит проверку при выборке?
- Безопасность автоматизации: работают ли автоматические действия должным образом, есть ли ложные срабатывания, работают ли откаты?
- Цикл обратной связи: Становятся ли фактические события новыми правилами обнаружения, а возникающие сигналы тревоги — списками исключений?
Условия: MTTD (среднее время обнаружения). Цикл обратной связи — это когда операция учится на собственных результатах и обновляет свои правила. Дрейф модели — это когда ИИ устаревает, а производительность падает по мере изменения среды. Самоаудит — это регулярный критический анализ собственных процессов команды.
три мини-кейса
Случай 1 — Правильная автоматизация. SOC автоматизирует этап «автоматического обогащения и определения приоритета предупреждений, которые соответствуют известным вредоносным IOC и относятся к категории низкого риска»; но всегда оставляет этап «изоляции сервера» на одобрение человека. Результат: аналитики освобождаются от 400 рутинных сигналов тревоги в день, освобождая время для реальных расследований, оставляя важные решения на усмотрение человека. Правильная часть цепочки — автомат, правильное место — человек.
Случай 2. Автоматизация имеет неприятные последствия. Другой SOC очень широко определяет правило «автоблокировки учетной записи при подозрительном входе в систему». Однажды из-за ошибки конфигурации правило блокирует сразу 1200 легальных пользователей, и работа прекращается; Более того, путь восстановления не определен. Урок: высокоэффективная автоматизация должна иметь строгие критерии, постепенное развертывание и путь отката. Автоматизация должна быть обратимой и контролироваться посредством саморегулирования.
Случай 3 — Проскальзывание, пойманное самообладанием. В ходе трехмесячного самоаудита команда замечает, что точность обнаружения фишинга ИИ снижается: новая волна фишинга пропускается, поскольку она не соответствует старым шаблонам (дрейф шаблона). Команда собирает образцы, обновляет правила обнаружения и обновляет контекст, предоставленный ИИ. Без регулярного самоконтроля это молчаливое уклонение могло бы продолжаться месяцами. Урок: если производительность однажды была хорошей, она не всегда останется хорошей; измерение и обратная связь имеют важное значение.
Слабая подсказка / Сильная подсказка
Слабая подсказка:
Полностью автоматизируйте наш SOC и позвольте искусственному интеллекту справиться со всем.
Этот запрос требует автоматизации без дискриминации рисков, игнорирует человеческие двери и не учитывает откат и контроль. Если они будут реализованы, решения с высоким риском станут автоматизированными без контроля и обернутся катастрофой при первой же ошибке.
Мощная подсказка:
Ваша роль: Консультант по разработке процессов SOC. [Перечислите] эти этапы жизненного цикла события на три в зависимости от уровня риска: (A) полностью автоматизированный (низкий риск, обратимый, повторяющийся), (B) ИИ рекомендует + одобряет человек, (C) всегда человеческое решение (высокий риск, необратимый). Предложите обязательный путь отката и метрику отслеживания для каждого (A) и (B). Также составьте ежеквартальный контрольный список для самопроверки: уровень ложноположительных/отрицательных результатов, MTTD/MTTR, выборка точности выходных данных ИИ, признаки отклонения шаблона.
Высокий спрос разделяет автоматизацию по уровням риска, требует отката и мониторинга, а также создает систему саморегулирования.
Копируемые шаблоны подсказок
ШАБЛОН РАЗДЕЛЕНИЯ РИСКОВ АВТОМАТИЗАЦИИ Разделите эти этапы рабочего процесса безопасности на три: (A) полностью автоматизированный подход, (B) Рекомендует одобрение человека, (C) всегда решение человека. Напишите обоснование, обратимость и влияние на бизнес для каждого шага. Рекомендовать обязательный путь отката для важных шагов. Шаги: [список]
ШАБЛОН ПРОЕКТИРОВАНИЯ ОТКАТА для автоматического действия [например. блокировка учетной записи] предлагают безопасную конструкцию: критерии запуска (узкие), постепенное развертывание, шаг отката ложного триггера, предупреждение и точка проверки человеком. Проектируйте так, чтобы избежать слепой автоматизации. Действие: [написать]
ШАБЛОН КОНТРОЛЬНОГО СПИСКА ДЛЯ САМОАУДИТА Составьте ежеквартальный контрольный список для самоаудита SOC на базе искусственного интеллекта: частота ложноположительных/отрицательных результатов, смещение MTTD/MTTR, выборка точности выходных данных ИИ, ложные срабатывания автоматизации, признаки отклонения шаблона, работа петли обратной связи, соблюдение требований конфиденциальности/анонимизации. Для каждого пункта напишите, как он будет измеряться.
ШАБЛОН ЦИКЛА ОБРАТНОЙ СВЯЗИ Нарисуйте то, что вы узнали из фактического события/тревоги, которая не удалась: (1) шаблон, который станет новым правилом обнаружения, (2) ложное срабатывание, которое будет добавлено в список исключений, (3) шаг сценария, который будет обновлен, (4) новый контекст, который будет передан ИИ. Сводка событий/тревог: [вставить]
Распространенные ошибки
- Автоматизация этапа высокого риска. Необратимые шаги, такие как изоляция сервера, исправление производства, официальное уведомление, не удаляются от человеческой двери.
- Не продумывая путь к возвращению. Любое автоматическое действие может сработать неправильно; Автоматизация без точки отмены и подтверждения опасна.
- Поставил и забыл. Производительность ИИ меняется по мере изменения окружающей среды; Без регулярного самоконтроля и измерения накапливаются молчаливые уклонения.
- Просто отслеживаю ложное срабатывание. Ложноотрицательный результат (реальная упущенная угроза) более опасен, но его труднее заметить; Смотрите это в частном порядке.
- Пренебрежение обратной связью. Если обнаруженные события не превращаются в новое правило, а неудавшиеся сигналы тревоги не превращаются в исключение, операция не обучается и повторяет ту же ошибку.
Подсказка: золотой вопрос при принятии решения по автоматизации: «Можно ли отменить это действие, если оно было запущено неправильно, и как это повлияет на бизнес?» Если ответ «легко отменить, мало воздействия», автоматизируйте; Если «необратимое или серьезное воздействие» держитесь у человеческой двери.
Внимание: автоматизация не снимает ответственности, а только ускоряет ее. Непродуманное автоматическое действие наносит ущерб гораздо быстрее и масштабнее, чем это мог бы сделать человек. Каждая автоматизация окружена узкими критериями, путями отката и регулярными проверками; Конечная ответственность всегда лежит на человеке.
В заключение
Этот модуль объединил все части модуля в сквозной рабочий процесс SOC: сбор, обнаружение, сортировка, расследование, реагирование, исправление, отчетность и обратная связь. ИИ участвует в каждом звене, но именно человек держит цепь и принимает решения у каждой важной двери. Автоматизация (SOAR+AI) увеличивает мощность; Правило ясно: обратимые, повторяющиеся шаги с низким уровнем риска становятся автоматизированными, необратимые шаги с высоким риском проходят через человеческие двери, и каждая автоматизация имеет способ отмениться. Наконец, действует программа безопасности на базе искусственного интеллекта: регулярно измеряются ложные срабатывания/отрицательные результаты, MTTD/MTTR, точность выходных данных и отклонение шаблона; То, что найдено, превращается в правила и инструкции в цикле обратной связи. Автоматизация ускоряет ответственность, а не снимает ее; Самоконтроль поддерживает безопасность.
Задача приложения
Напишите жизненный цикл инцидента вашей организации (или примерный SOC). Классифицируйте каждый шаг как A/B/C с помощью шаблона «Разделение рисков автоматизации» и разработайте безопасный проект автоматизации с помощью шаблона «Проектирование отката» хотя бы для одного «высокоэффективного» шага. Затем создайте квартальный контрольный список с помощью шаблона «Контрольный список для самоаудита» и определите, как вы будете измерять каждый показатель в своей среде.
контрольный список
- [ ] Я разделил каждый этап жизненного цикла инцидента на класс риска A/B/C.
- [ ] Я продолжал рискованные, необратимые шаги к человеческой двери.
- [ ] Я разработал узкие критерии и путь отмены для каждого автоматического действия.
- [ ] Я планировал отслеживать количество ложноположительных результатов и особенно ложноотрицательных результатов.
- [ ] Я планировал регулярно измерять MTTD/MTTR и точность вывода AI.
- [ ] Я составил ежеквартальный контрольный список для самоконтроля на предмет отклонения шаблонов поведения.
- [ ] Я подключил найденные события и закинул тревоги в контур обратной связи.
Модульный экзамен
1. ИИ сортировки SIEM пометил сигнал тревоги как «низкий приоритет, вероятно, ложное срабатывание» и переместил его в конец списка. Что должен делать аналитик с этой тревогой?
- А) Тем не менее самостоятельно проверяет сигнализацию и подтверждает ее необработанными доказательствами; Аналитик принимает решение о закрытии и записывает его ✔
- Б) Искусственный интеллект автоматически отключает сигнал тревоги, не проверяя его, поскольку говорит, что он имеет низкий приоритет.
- C) Переносит тревогу на следующую смену как есть.
- D) Просто посмотрите сводку, предоставленную искусственным интеллектом, и передайте отчет.
Пояснение: Определение приоритетов ИИ — это рекомендация, а не диагноз; Флаг «низкий приоритет» может скрывать реальную атаку (ложноотрицательный результат). Аналитик все равно должен самостоятельно проверить оповещение, сверить его с необработанными доказательствами и самому принять решение о его закрытии. Отрицательный результат ИИ не является гарантией «отсутствия угрозы».
2. Какая комбинация рисков заключается в том, что ИИ помечает реальную атаку как «нормальную», а аналитик доверяет этому и расслабляет свой собственный анализ?
- А) Только ложноположительные результаты и тревожная усталость
- Б) Ложноотрицательный результат и предвзятость автоматизации (чрезмерная зависимость от ИИ) ✔
- C) Отсутствие только источника журнала
- D) Только ошибка правила SIEM
Пояснение: Это ложноотрицательный результат, если модель не учитывает реальную угрозу; Предвзятость автоматизации — это когда аналитик чрезмерно доверяет искусственному интеллекту и отказывается от независимой проверки. Когда они объединяются, смысл существования человеческого контроля исчезает, и атаку можно полностью обойти. Поэтому также исследуются области, которые искусственный интеллект называет «чистыми».
3. Во время сортировки ИИ сказал: «CVE-2024-88888, CVSS 9.8, исправьте немедленно». Что аналитик должен сделать в первую очередь?
- А) Считает CVE заслуживающим доверия и немедленно инициирует план исправлений.
- Б) Просто потому, что CVSS имеет версию 9.8, он ставит ее на первое место, не обращая внимания на другие уязвимости.
- C) Проверяет номер CVE и оценку в записи NVD/поставщика; ✔ Если записи нет, она не будет указана, зная, что она может быть поддельной.
- Г) Без проверки CVE администратор записывает его в отчете как «критическую угрозу».
Описание: Языковые модели могут свободно соответствовать несуществующему номеру и баллу CVE (галлюцинации). Аналитик должен проверить CVE в журнале NVD/поставщика и подтвердить его подлинность и оценку, прежде чем переходить к графику исправлений. Непроверенный CVE сначала подключается к ресурсу; В противном случае команда потратит время на погоню за патчем, которого не существует.
4. Чтобы ускорить расследование инцидента, эксперт вставляет необработанный журнал брандмауэра вместе с фактическими внутренними IP-адресами, именами пользователей и именами VPN-серверов в общедоступный инструмент искусственного интеллекта. В чем здесь главная проблема?
- А) ИИ не может прочитать формат журнала, поэтому анализ бесполезен
- Б) Если бревно слишком длинное, это замедляет работу модели.
- В) Журналы фаервола в любом случае не подходят для анализа
- D) Реальный IP-адрес, имена пользователей и серверов передаются без анонимизации; Это одновременно и нарушение КВКК, и утечка карты сети организации ✔
Описание: Данные безопасности — это как личные данные (пользователя, IP), так и корпоративная разведка, раскрывающая поверхность атаки организации (топология сети, имена серверов). Передача этого внешнего инструмента без его анонимизации является одновременно нарушением KVKK и раскрывает карту сети, которая будет полезна злоумышленнику. Во-первых, фактические значения маскируются последовательными заполнителями.
5. Что делает поиск угроз хорошо спланированным?
- А) Все начинается с конкретной, поддающейся проверке гипотезы, а обнаруженный след подтверждается необработанными данными ✔
- Б) Он начинается с сообщения искусственному интеллекту: «Найди, есть ли злоумышленник в моей сети».
- В) Автоматически объявляет каждое аномальное/редкое событие атакой.
- D) Работает только при поступлении сигнала тревоги, не является превентивным.
Объяснение: Хороший поиск угроз начинается не с сигнала тревоги, а с конкретной и проверяемой гипотезы, которая может оказаться верной, а может и нет (например, «Подключалась ли учетная запись X к более чем 50 внутренним IP-адресам в нерабочее время»). Расплывчатый вопрос типа «Что-то плохое в моей сети» не может быть проверен и оставляет ИИ гадать. Найденный след не считается угрозой, пока не будет подтвержден необработанными доказательствами.
6. Уязвимость имеет рейтинг CVSS 9,1 на изолированном тестовом сервере во внутренней сети; В том же списке CVSS 7.5 на сервере, открытом для Интернета, но в списке KEV есть еще одна уязвимость (которая на самом деле используется). Что такое правильная расстановка приоритетов?
- А) Тот, у кого самый высокий CVSS (9.1), всегда обновляется первым.
- Б) Уязвимость версии 7.5 в Интернете и списке KEV выдвинута вперед; CVSS — не единственный критерий, решающее значение имеют разоблачение и фактическое злоупотребление ✔
- В) Оба патча обновляются одновременно и с одинаковым приоритетом, различие не требуется.
- Г) Ни один из них не исправлен, поскольку на тестовом сервере есть уязвимость.
Объяснение: CVSS не устанавливает приоритеты самостоятельно; Фактический риск определяется EPSS (вероятность эксплуатации), KEV (фактическая эксплуатация) и организационным контекстом (воздействие, критичность, компенсаторный контроль). Уязвимость, обнаруженная и фактически использованная в Интернете (KEV), предотвращает изолированную и маловероятную уязвимость с высоким уровнем CVSS.
7. В ответ на инцидент искусственный интеллект сообщает: «Трафик, исходящий от IC_HOST_7, является подозрительным, изолируйте этот сервер». IC_HOST_7 — основной сервер аутентификации заведения. Что должен делать аналитик?
- А) Искусственный интеллект немедленно изолирует сервер, потому что он так говорит
- Б) Решение о изоляции полностью остается на усмотрение искусственного интеллекта.
- C) Сначала оцените влияние на бизнес и причину трафика; Он не изолирует критическую инфраструктуру, не измеряя ее влияние, и принимает решение как аналитик ✔
- D) Изолирует сервер, а затем удаляет все журналы.
Описание: Изоляция — это важнейшее решение, которое трудно отменить и которое может привести к остановке бизнеса; невозможно передать искусственному интеллекту. Изоляция сервера аутентификации может помешать всем сотрудникам войти в систему. Аналитик должен сначала оценить влияние на бизнес и причину трафика (может быть легитимная транзакция), принять решение самостоятельно; Предложение об искусственном интеллекте не должно реализовываться как приказ.
8. В случае инцидента с программой-вымогателем команда хочет восстановить пораженную машину, чтобы быстро очистить ее; но на машине есть доказательства (дамп памяти, инструменты злоумышленника), которые еще не собраны. Каков правильный подход?
- А) Машина сразу переустанавливается; доказательства не имеют значения
- Б) Искусственному интеллекту запрашивается «самая быстрая уборка», и инструкции выполняются вслепую.
- В) Машина выключается и выбрасывается, поскольку доказательства уже есть в журнале.
- Г) Сначала создается судебно-медицинский образ и дамп памяти и сохраняются доказательства, затем выполняется очистка/восстановление ✔
Пояснение: Скорость восстановления не может превзойти сохранение доказательств. Переустановка машины без сбора доказательств разрушает цепочку поставок и наносит вред судебному процессу. Сначала создается криминалистический образ и дамп памяти, затем выполняется очистка/восстановление. Криминалистические действия не делегируются ИИ.
9. Каков один из наиболее надежных уровней технической проверки при анализе подозрительного фишингового электронного письма и как его следует подтвердить?
- А) результаты SPF/DKIM/DMARC в заголовках электронных писем; Подтверждено из исходного названия, а не из резюме ИИ ✔
- Б) Цвет и шрифт электронного письма; решил визуальный дизайн
- В) Нажмите на подозрительную ссылку в действующей системе и посмотрите на открывшуюся страницу.
- Г) Искусственный интеллект, говорящий о «фишинге», является достаточным доказательством.
Объяснение: Результаты SPF/DKIM/DMARC в заголовках электронных писем являются надежным индикатором того, действительно ли электронное письмо пришло из домена, на который оно претендует; Если все три потерпят неудачу и отправитель подделает домен, подозрения станут сильнее. Однако это должно быть подтверждено исходным названием, а не кратким описанием AI. Кроме того, в действующей системе никогда не нажимаются подозрительные ссылки.
10. В ходе проверки кода ИИ предложил исправление XSS-уязвимости и сказал, что «оно закрывает уязвимость». Что должен делать аналитик/разработчик?
- А) Считает исправление надежным и запускает его непосредственно в производство.
- Б) Просматривает исправление, подтверждает, что оно действительно закрывает уязвимость и не создает новых уязвимостей/ошибок, и пишет тест; Только тогда он попадает на хранение ✔
- В) Так как он не уверен, то переписывает весь файл на искусственный интеллект и использует его.
- D) Применяет исправление, но проходит без написания каких-либо тестов.
Пояснение: Исправление, предложенное ИИ, не является автоматически безопасным; Он может не закрыть уязвимость полностью, очистить не тот слой или ввести новую уязвимость/функциональную ошибку. Каждый патч просматривается, оценивается, действительно ли он закрывает уязвимость и не создает ли он новые проблемы, и пишутся положительные и отрицательные тестовые примеры; Только после этого он поступает на склад.
11. Анализируя атаку, искусственный интеллект сказал: «Это определенно работа группы APT-Dark Eagle». Каков правильный подход с точки зрения анализа угроз?
- А) Примите ссылку такой, какая она есть, и запишите ее в отчете как «определенного виновника».
- Б) Он строит всю свою защиту на основе этой группы, даже не задаваясь вопросом о названии группы.
- В) Использует формулировки «соответствующие технике», а не точную атрибуцию, проверяет группу по известным источникам и учитывает возможность фальсификации ✔
- Г) Цитирование всегда лишнее, оно вообще не принимается во внимание
Пояснение: Атрибуция группы — самая трудная и самая неточная область разведки; ИИ может даже придумать название несуществующей группы. Вместо точной ссылки используется формулировка, «совместимая с этими методами», а название группы подтверждается в известных разведывательных источниках. Кроме того, защита основана не на кратковременных IOC, а на постоянном обнаружении TTP.
12. В проекте отчета об инциденте ИИ написал предложение: «Злоумышленник, скорее всего, находился внутри в течение трех недель и украл данные клиентов»; тогда как нет убедительных доказательств в поддержку этих утверждений. Что должен делать аналитик?
- А) Оставляет предложение как есть, потому что оно драматично и впечатляюще
- Б) Оставляет предложение, но добавляет в конце «искусственный интеллект написал».
- В) Перепечатывает весь отчет искусственному интеллекту и подписывает его, не проверяя.
- D) Исправляет претензии на основании доказательств; Делает различие между «возможно/доказано/расследуется» и извлекает окончательное утверждение без доказательств ✔
Комментарий: В официальном отчете о безопасности каждое утверждение должно быть обосновано, и никогда не следует путать «вероятное» с «доказанным». Претензия без доказательств имеет юридические, финансовые и репутационные последствия. Аналитик должен исправить предложение в соответствии с доказательствами (например, написать дату первого обнаруженного доступа и сказать: «Убедительных доказательств не обнаружено, расследование продолжается» в отношении утечки данных).
13. Руководитель хочет профилировать всю активность сотрудника из журналов безопасности с помощью искусственного интеллекта, чтобы понять, «лоялен» он или нет. Что должен делать специалист по безопасности?
- А) Отклоняет запрос и передает его в соответствующий канал (кадровое/юридическое/определенное расследование); данные безопасности не являются средством личного наблюдения ✔
- Б) Создает и доставляет профиль по запросу менеджера.
- В) Он извлекает только некоторые журналы и дает частичный профиль.
- D) Иметь профиль, созданный искусственным интеллектом, поскольку ответственность переходит к искусственному интеллекту.
Описание: Данные безопасности собираются в целях безопасности; Отслеживание/профилирование человека является злоупотреблением, превращается в личное наблюдение и нарушает КВКК. Эксперт должен отклонить этот запрос и передать его в соответствующий канал (HR, юридический, определенную и законную структуру расследования). Добрая воля или желание менеджера не оправдывают это ограничение.
14. SOC решает, какие этапы рабочего процесса безопасности следует автоматизировать. Какой принцип автоматизации является лучшим?
- А) Решения, связанные с наивысшим риском, должны быть автоматизированы в первую очередь, чтобы исключить участие человека.
- Б) Автоматизированы обратимые этапы с низким уровнем риска; высокий риск/необратимые действия остаются за дверью человека, и у каждой автоматизации есть способ отменить ✔
- В) Все SOC должны быть полностью автоматизированы, а самоконтроль не требуется.
- Г) Автоматизированные действия не нужно отменять, поскольку ИИ не допускает ошибок.
Пояснение. Повторяющиеся и обратимые действия с низким уровнем риска (сбор журналов, пополнение сигналов тревоги) можно автоматизировать; Шаги с высоким риском, необратимые и требующие принятия решений (изоляция сервера, исправление производства, официальное уведомление) проходят через человеческую дверь. Кроме того, каждое автоматическое действие должно иметь узкие критерии и способ отмены. Автоматизация не снимает ответственности, она лишь ускоряет ее.