Наскрізний робочий процес SOC, автоматизація (SOAR), управління якістю та самоперевірка

Прибуток:

• Можливість розробити наскрізний робочий процес SOC, який складається зі збору, виявлення, сортування, дослідження, втручання, покращення, звітності та зворотного зв’язку, вказуючи розташування штучного інтелекту та людських воріт
• Можливість розділити автоматизацію відповідно до рівня ризику (кроки з низьким ризиком/оборотні кроки є автоматичними, кроки з високим ризиком/необоротні кроки контролюються людиною) і розробити шлях відкату для кожної автоматичної дії.
• Можливість налагодити цикл самоконтролю та зворотного зв’язку, який регулярно вимірює частоту хибних позитивних/негативних результатів, MTTD/MTTR, точність виведення та дрейф моделі

У цьому останньому розділі об’єднано елементи, які ми вивчали окремо протягом модуля — аналіз журналів, пошук загроз, керування вразливими місцями, реагування на інциденти, фішинг, перевірка коду, розвідка, звітування — в єдиний наскрізний робочий процес. У справжньому центрі безпеки (SOC) ці кроки не відключаються; Сигнал тривоги запускає розслідування, яке викликає відповідь, яке викликає звіт, який запускає виправлення. Штучний інтелект задіяний у кожній ланці цього ланцюга, але саме людина тримає ланцюжок і приймає рішення за кожними критичними дверима.

Крім того, цей розділ охоплює дві важливі теми. По-перше, це автоматизація: коли SOAR (Security Orchestration, Automation and Response — платформа, яка автоматизує та організовує процеси безпеки) та ШІ поєднуються, потужність і ризик збільшуються; Необхідно розрізняти те, що можна автоматизувати, і те, що ніколи не можна позбавити схвалення людини. По-друге, управління якістю та саморегулювання: операція безпеки з підтримкою штучного інтелекту не встановлюється та не припиняється один раз; воно постійно контролюється, вимірюється, повертається та коригується. Автоматизація збільшує швидкість, але не скасовує відповідальності; Програма безпеки залишається безпечною лише завдяки регулярному самоконтролю.

Наскрізний робочий процес SOC

Давайте подивимося, де ШІ вступає в гру і хто його схвалює в типовому життєвому циклі інциденту:

1. Збір і моніторинг: журнали надходять до SIEM; AI зменшує шум, підсумовує. (Автоматично, низький ризик.)
2. Виявлення та тривога: правило + виявлення аномалії + ШІ. (Автоматичне виробництво; сортування відбувається на людях.)
3. Сортування: сигнал тривоги справжній чи помилковий? AI пропонує обґрунтування та пріоритет; підтверджує аналітик. (Людські двері.)
4. Розслідування: ШІ збирає докази, встановлює часові рамки, перераховує першопричину; аналітик підтверджує необробленими доказами. (Людські двері.)
5. Втручання: Ізоляція, блокування, очищення. ШІ забезпечує вибір/вплив; Рішення в руках уповноваженого аналітика. (Критичні людські ворота.)
6. Усунення: закриття вразливості, усунення першопричини. проект плану АІ; схвалення в управлінні змінами. (Людина + процес.)
7. Звітність: AI пише чернетку, адаптується до аудиторії; Експерт перевіряє та підписує докази. (Людські двері.)
8. Вивчення уроків і зворотній зв'язок: ШІ виділяє шаблони; Оновлює правила виявлення команди та підручники. (Людина + процес.)

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

Таблиця рішень автоматизації

крок

Чи можна автоматизувати

стан

людське схвалення

Збір журналів, нормалізація

Так точно

—

не потрібно

Збагачення тривоги (пошук 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 позначив тривогу як «низький пріоритет, імовірно хибно позитивний» і перемістив її в кінці списку. Що повинен робити аналітик з цією тривогою?

• A) Все ще самостійно перевіряє сигнал тривоги та перевіряє його за допомогою необроблених доказів; Аналітик приймає рішення про закриття та фіксує його ✔
• B) Штучний інтелект автоматично вимикає будильник, не перевіряючи його, оскільки він каже, що він має низький пріоритет.
• C) Передає будильник на наступну зміну як є.
• D) Просто подивіться на резюме, надане штучним інтелектом, і пройдіть звіт

Пояснення: пріоритезація ШІ – це рекомендація, а не діагноз; Позначка «низького пріоритету» може прикривати справжню атаку (помилково негативне). Аналітик все одно повинен самостійно перевірити попередження, підтвердити його необробленими доказами та прийняти рішення про його закриття самостійно. Негативний результат штучного інтелекту не є гарантією відсутності загрози.

2. Яка комбінація ризиків полягає в тому, що штучний інтелект позначає реальну атаку як «нормальну», а аналітик довіряє цьому та послаблює власний аналіз?

• A) Лише хибні спрацьовування та тривога втоми
• B) Хибно негативний результат і упередженість автоматизації (надмірна залежність від ШІ) ✔
• C) Відсутність лише джерела журналу
• D) Лише помилка правила SIEM

Пояснення: це помилково негативний результат, якщо модель пропускає реальну загрозу; Упередження автоматизації — це коли аналітик надмірно довіряє штучному інтелекту та відмовляється від незалежного огляду. Коли вони поєднуються, сенс існування людського контролю зникає, і атаку можна повністю обійти. Тому досліджуються також області, які штучний інтелект називає «чистими».

3. ШІ сказав «CVE-2024-88888, CVSS 9.8, виправлення негайно» під час сортування. Що повинен зробити аналітик в першу чергу?

• A) Вважає CVE надійним і негайно починає план виправлення
• B) Просто тому, що CVSS 9.8, він ставить його на перше місце, не дивлячись на будь-які інші вразливості
• C) Перевіряє номер CVE та оцінку в записі NVD/постачальника; ✔ Якщо запису немає, його не буде вказано, знаючи, що він може бути підробленим.
• D) Не перевіряючи CVE, адміністратор записує його у звіті як «критичну загрозу»

Опис: мовні моделі можуть вільно підбирати неіснуючий номер CVE та бал (галюцинації). Аналітик повинен перевірити CVE у NVD/журналі постачальника та підтвердити його автентичність і оцінку перед виконанням графіка виправлення. Неперевірений CVE спочатку підключається до ресурсу; Інакше команда витрачатиме час на пошуки патча, якого не існує.

4. Щоб прискорити розслідування інциденту, експерт вставляє необроблений журнал брандмауера разом із фактичними внутрішніми IP-адресами, іменами користувачів та іменами серверів VPN у загальнодоступний інструмент ШІ. У чому тут головна проблема?

• A) AI не може прочитати формат журналу, тому аналіз марний
• B) Якщо журнал занадто довгий, це сповільнює роботу моделі.
• C) Журнали брандмауера все одно непридатні для аналізу
• D) Справжня IP-адреса, імена користувачів і серверів надаються без анонімізації; Це і порушення КВКК, і витік карти мережі організації ✔

Опис: Дані безпеки — це як особисті дані (користувач, IP), так і корпоративні дані, які розкривають поверхню атаки організації (топологія мережі, імена серверів). Передача цього зовнішньому інструменту без анонімізації є порушенням KVKK і відкриває карту мережі, яка буде корисна для зловмисника. По-перше, фактичні значення маскуються узгодженими заповнювачами.

5. Чому полювання на загрозу вважається добре спланованою?

• A) Все починається з конкретної гіпотези, яку можна перевірити, і знайдений слід підтверджується необробленими доказами ✔
• B) Він починається з того, що повідомляє штучному інтелекту «знайти, чи є зловмисник у моїй мережі».
• C) Автоматично оголошує кожну аномальну/рідкісну подію як атаку
• D) Він працює лише тоді, коли надходить сигнал тривоги, він не є проактивним

Пояснення: ефективне полювання на загрозу починається не з сигналу тривоги, а з конкретної гіпотези, яку можна перевірити, яка може виявитися правдивою, а може й ні (наприклад, «чи підключався обліковий запис X до більш ніж 50 внутрішніх IP-адрес у неробочий час»). Розпливчасте запитання на зразок «Чи є щось погане в моїй мережі» неможливо перевірити, і ШІ змушує здогадуватися. Знайдений слід не вважається загрозою, доки він не буде підтверджений необробленими доказами.

6. Уразливість має оцінку CVSS 9,1 на ізольованому тестовому сервері у внутрішній мережі; У тому ж списку CVSS 7.5 на сервері, відкритому для Інтернету, але в списку KEV є ще одна вразливість (яка фактично використовується). Що таке правильна розстановка пріоритетів?

• A) Той, у кого найвищий CVSS (9.1), завжди виправляється першим
• B) Уразливість 7.5 в Інтернеті та список KEV перенесено на новий рівень; CVSS – не єдиний критерій, вирішальними є виявлення та фактичне зловживання ✔
• C) Обидва виправлені одночасно та з однаковим пріоритетом, різниця непотрібна
• D) Жоден із них не виправлено, оскільки на тестовому сервері є вразливість

Пояснення: CVSS не встановлює пріоритети самостійно; фактичний ризик визначається EPSS (ймовірність експлуатації), KEV (фактична експлуатація) та організаційним контекстом (вплив, критичність, компенсаційний контроль). Уразливість, що розкрита в Інтернеті та фактично використовується (KEV), запобігає ізольованій та низькоймовірній уразливості CVSS.

7. У відповідь на інцидент штучний інтелект повідомляє: «Трафік, що надходить з IC_HOST_7, є підозрілим, ізолюйте цей сервер». IC_HOST_7 є основним аутентифікаційним сервером установи. Що має робити аналітик?

• А) Штучний інтелект негайно ізолює сервер, тому що він так каже
• B) Залишає рішення про ізоляцію цілком штучному інтелекту
• C) Спочатку оцініть вплив на бізнес і причину трафіку; Він не виокремлює критичну інфраструктуру, не вимірявши її вплив, і приймає рішення як аналітик ✔
• D) Ізолює сервер, а потім видаляє всі журнали

Опис: ізоляція є критичним рішенням, яке важко скасувати та може призвести до переривання бізнесу; не можна перенести на штучний інтелект. Ізоляція сервера автентифікації може припинити вхід усіх співробітників. Аналітик повинен спочатку оцінити вплив на бізнес і причину трафіку (може бути законною транзакцією), прийняти рішення самостійно; Пропозицію штучного інтелекту не слід реалізовувати як наказ.

8. Під час інциденту з програмою-вимагачем команда хоче перебудувати уражену машину, щоб швидко її очистити; але на машині є докази (дамп пам’яті, інструменти зловмисників), які ще не зібрано. Який правильний підхід?

• A) Машина негайно перевстановлюється; докази не мають значення
• Б) Штучний інтелект запитують «найшвидше очищення», і інструкція виконується наосліп.
• C) Машину вимикають і викидають, оскільки докази вже є в журналі.
• D) Спочатку створюється криміналістичне зображення та дамп пам’яті, а докази зберігаються, а потім виконується очищення/відновлення ✔

Пояснення: Швидкість відновлення не може переважати над збереженням доказів. Перевстановлення машини без збору доказів руйнує ланцюжок контролю та руйнує судовий процес. Спочатку робиться криміналістичне зображення та дамп пам’яті, а потім виконується очищення/відновлення. Криміналістичні дії не делеговані ШІ.

9. Що є одним із найнадійніших рівнів технічної перевірки під час аналізу ймовірного фішингового електронного листа та як його слід підтвердити?

• A) SPF/DKIM/DMARC призводить до заголовків електронних листів; Підтверджено з необробленої назви, а не з резюме AI ✔
• B) Колір і шрифт електронного листа; вирішено візуальним дизайном
• C) Клацніть на підозріле посилання в активній системі та перегляньте сторінку, що відкриється.
• D) Штучний інтелект каже, що сам по собі «фішинг» є достатнім доказом

Пояснення: результати SPF/DKIM/DMARC у заголовках електронної пошти є надійними показниками того, чи справді електронний лист надходить із домену, на який він претендує; Якщо всі три не вдаються, і відправник підроблює домен, підозра стає сильнішою. Однак це має бути підтверджено з необробленої назви, а не з резюме ШІ. Крім того, підозрілі посилання ніколи не натискаються в живій системі.

10. Під час перевірки коду AI запропонував виправити вразливість XSS і сказав, що «це закриває вразливість». Що має робити аналітик/розробник?

• A) Вважає виправлення надійним і запускає його безпосередньо у виробництво
• B) Переглядає виправлення, підтверджує, що воно справді закриває вразливість і не створює нових уразливостей/помилок, і пише тест; Тільки після цього потрапляє на зберігання ✔
• C) Оскільки він не впевнений, він переписує весь файл у штучний інтелект і використовує його.
• D) Застосовує виправлення, але проходить без написання жодних тестів

Пояснення: виправлення, запропоноване ШІ, не є автоматично безпечним; Він може не закрити вразливість повністю, може очистити неправильний рівень або створити нову вразливість/функціональну помилку. Кожен патч переглядається, оцінюється, чи справді він закриває вразливість і чи створює нові проблеми, а також записуються позитивні та негативні тестові випадки; Тільки після цього потрапляє на склад.

11. Аналізуючи атаку, штучний інтелект сказав, що «це безперечно робота групи APT-Dark Eagle». Який правильний підхід з точки зору аналізу загроз?

• A) Прийміть посилання таким, яким воно є, і напишіть його в звіті як «певного злочинця»
• B) Він будує весь свій захист на основі цієї групи, навіть не ставлячи під сумнів назву групи.
• C) Використовує формулювання «узгоджено з технікою», а не точне приписування, перевіряє групу за відомими джерелами та враховує можливість фальсифікації ✔
• Г) Цитування завжди непотрібне, воно взагалі не береться до уваги

Пояснення: Групове віднесення є найскладнішою та найбільш неточною сферою інтелекту; ШІ навіть може придумати назву групи, якої не існує. Замість точного посилання використовується мова «сумісна з цими методами», а назва групи підтверджується у відомих джерелах розвідки. Крім того, захист базується не на короткочасних IOC, а на постійному виявленні TTP.

12. У чернетці звіту про інцидент ШІ написав речення «зловмисник, швидше за все, був усередині протягом трьох тижнів і викрадав дані клієнтів»; в той час як немає переконливих доказів журналу, які підтверджують ці твердження. Що має робити аналітик?

• А) Залишає речення без змін, оскільки воно драматичне та вражаюче
• B) Залишає речення, але додає «штучний інтелект написав» у кінці
• C) Передруковує весь звіт для штучного інтелекту та підписує його без перевірки.
• D) виправляє претензії на основі доказів; Розрізняє «можливе/доведене/розслідується» та виділяє остаточне твердження без доказів ✔

Коментар: у офіційному звіті про безпеку кожне твердження має бути обґрунтованим, а слово «ймовірне» ніколи не слід плутати з словом «доведене». Позов без доказів має правові, фінансові та репутаційні наслідки. Аналітик має виправити речення відповідно до доказів (наприклад, написати дату першого виявлення доступу та сказати «переконливих доказів не знайдено, розслідування триває» щодо витоку даних).

13. Керівник хоче профілювати всю діяльність співробітника з журналів безпеки за допомогою штучного інтелекту, щоб зрозуміти, «лояльний» він чи ні. Що повинен робити фахівець із безпеки?

• A) Відхиляє запит і направляє його до відповідного каналу (HR/юрисдикція/визначене розслідування); дані безпеки не є засобом особистого спостереження ✔
• B) Створює та доставляє профіль на вимогу менеджера
• C) Витягує лише деякі журнали та дає частковий профіль
• D) Створити профіль штучним інтелектом, тому що відповідальність переходить до штучного інтелекту

Опис: дані безпеки збираються з метою безпеки; Відстеження/профайлінг особи є неправомірним використанням, перетворюється на особистий нагляд і порушує КВКК. Експерт повинен відхилити цей запит і направити його до відповідного каналу (кадровий, юридичний, визначена та законна база розслідування). Доброзичливість чи бажання керівника не виправдовують цю межу.

14. SOC вирішує, які кроки робочого процесу безпеки автоматизувати. Який принцип є найкращим для автоматизації?

• A) Рішення з найвищим ризиком слід спочатку автоматизувати, щоб не було участі людини
• B) Низькоризикові/зворотні етапи автоматизовані; високий ризик/незворотні кроки залишаються біля дверей людини, і кожна автоматизація має спосіб скасувати ✔
• C) Усі SOC повинні бути повністю автоматизовані, а самоаудит непотрібний
• D) Автоматизовані дії не потрібно скасовувати, оскільки ШІ не робить помилок

Пояснення: повторювані та оборотні кроки з низьким рівнем ризику (збір журналів, збагачення сигналів) можуть бути автоматизовані; Високий ризик, незворотні кроки, що вимагають судження (ізоляція сервера, виправлення для виробництва, офіційне сповіщення) проходять через людські двері. Крім того, кожна автоматична дія має мати вузькі критерії та спосіб скасування. Автоматизація не знімає відповідальності, а лише прискорює її.