единици
1. Въведение в изкуствения интелект в киберсигурността: роли, граници, отбранителна етика и проверка 2. Анализ на регистрационен файл и SIEM: Разделяне на събитие от шум с изкуствен интелект 3. Лов на заплахи: Създаване на хипотези и търсене на сигнали с изкуствен интелект 4. Сканиране на уязвимости и приоритизиране: Правилно сортиране с CVE, CVSS, EPSS и контекст 5. Реагиране на инциденти: Бърз анализ, наръчник и контролирано решение с изкуствен интелект 6. Анализ на фишинг и социално инженерство: Преглед на имейл, URL адрес и хедър 7. Преглед на защитен код и статичен анализ: Намиране на уязвимости с изкуствен интелект 8. Threat Intelligence: IOC, TTP, MITER ATT&CK и Sensemaking с изкуствен интелект 9. Докладване и комуникация: от констатации до технически доклади до резюме 10. Граници, поверителност, етика и забрана за неоторизирана употреба 11. SOC работен процес от край до край, автоматизация (SOAR), управление на качеството и самоодит
единица 11 / 11

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

Печалби:

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

Този последен модул съчетава частите, които научихме поотделно в рамките на модула – анализ на регистрационни файлове, откриване на заплахи, управление на уязвимости, реакция при инциденти, фишинг, преглед на кода, разузнаване, докладване – в един работен процес от край до край. В истински център за операции по сигурността (SOC) тези стъпки не се прекъсват; Алармата задейства разследване, което задейства отговор, което задейства доклад, което задейства коригиране. Изкуственият интелект е включен във всяка брънка от тази верига, но човекът е този, който държи веригата и взема решения на всяка критична врата.

Освен това този модул обхваща две критични теми. Първата е автоматизацията: когато SOAR (Оркестрация на сигурността, автоматизация и реакция — платформата, която автоматизира и организира процесите на сигурност) и AI се комбинират, мощността и рискът се увеличават; Необходимо е да се прави разлика между това, което може да бъде автоматизирано и това, което никога не може да бъде премахнато от човешкото одобрение. Второ, управление на качеството и саморегулиране: Операция за сигурност с активиран AI не се настройва и изоставя веднъж; непрекъснато се наблюдава, измерва, подава обратно и коригира. Автоматизацията увеличава скоростта, но не премахва отговорността; Програмата за сигурност остава безопасна само чрез редовно самонаблюдение.

SOC работен процес от край до край

Нека да видим къде AI влиза в игра и кой го одобрява в типичен жизнен цикъл на инцидент:

  1. Събиране и наблюдение: Поток на регистрационни файлове към SIEM; AI намалява шума, обобщава. (Автоматично, нисък риск.)
  2. Откриване и аларма: правило + аномалия + откриване на AI модел. (Автоматично производство; сортирането е при хора.)
  3. Сортиране: истинска ли е алармата или фалшиво положителна? AI предлага обосновка и приоритет; анализаторът потвърждава. (Човешка врата.)
  4. Разследване: AI събира доказателства, установява график, изброява първопричината; анализаторът потвърждава със сурови доказателства. (Човешка врата.)
  5. Интервенция: Изолиране, заключване, почистване. AI осигурява избор/влияние; Решението е в ръцете на оторизирания анализатор. (Критична човешка врата.)
  6. Отстраняване: Затваряне на уязвимостта, елиминиране на първопричината. проект на AI план; одобрение в управлението на промените. (Човек + процес.)
  7. Докладване: AI пише чернова, адаптира се към аудиторията; Експертът заверява и подписва доказателствата. (Човешка врата.)
  8. Учене и обратна връзка: AI извлича модели; Актуализира правилата за откриване на екипи и наръчниците. (Човек + процес.)

Правилото на тази верига: нискорискови, повтарящи се, обратими стъпки могат да бъдат автоматизирани; През човешката врата минават високорискови, необратими стъпки, изискващи преценка.

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

стъпка

Може ли да се автоматизира

състояние

човешко одобрение

Събиране на журнали, нормализиране

Да точно така

не е необходимо

Обогатяване на аларма (IOC търсене)

да

Източникът е надежден

Преглежда се

Фалшиво положително елиминиране (известно добро)

частично

строго правило

Проверен чрез вземане на проби

Фишинг имейл под карантина

частично

висока точност

Преглед + път за връщане назад

Автоматично заключване на акаунт

внимателен

Само ясни критерии

Бърза човешка проверка

Изолирайте сървъра

Общо взето не

С изключение на критичната инфраструктура

Принудително човешко решение

Изкърпване (производство)

не

Тестване + управление на промените

Официален доклад/уведомление

не

Експерт + закон

Управление на качеството и самоодит

Операцията за сигурност, задвижвана от AI, е жива система; неговата производителност се променя с времето (нови атаки, променяща се среда, актуализации на модела). Необходимо е редовно измерване, за да бъде безопасно:

  • Процент на фалшиви положителни и фалшиви отрицателни резултати: Колко често AI алармира напразно, колко често пропуска истинската заплаха? Фалшивите негативи се наблюдават особено, защото мълчаливо причиняват вреда.
  • MTTD/MTTR: ​​​​Подобряват ли се средното време за откриване и реакция?
  • Точност на изхода на AI: Чрез вземане на проби, колко от резюметата/констатациите/цитатите на AI преминават проверката?
  • Сигурност на автоматизацията: Работят ли автоматичните действия според очакванията, има ли фалшиви тригери, работят ли връщанията назад?
  • Цикъл за обратна връзка: Действително откритите събития стават ли нови правила за откриване, а повдигнатите аларми стават ли списъци с изключения?

Условия: MTTD (средно време за откриване). Цикълът за обратна връзка е, когато операцията се учи от собствените си резултати и актуализира своите правила. Дрейфът на модела е, когато AI остарее и производителността намалява с промяната на средата. Самоодитът е редовен, критичен преглед на собствените процеси на екипа.

три мини калъфа

Случай 1 — Правилна автоматизация. SOC автоматизира стъпката на „автоматично обогатяване и приоритизиране на предупреждения, които съответстват на известни злонамерени IOC и са в категория с нисък риск“; но винаги оставя стъпката „изолиране на сървър“ за одобрение от човека. Резултатът: анализаторите са освободени от 400 рутинни аларми на ден, освобождавайки време за реални разследвания, оставяйки критичните решения на човека. Правилната част от веригата е автоматична, точното място е човек.

Случай 2 — Автоматизацията има обратен ефект. Друг SOC дефинира правилото за „автоматично заключване на акаунт при подозрително влизане“ много широко. Един ден, поради грешка в конфигурацията, правилото блокира 1200 легитимни потребители наведнъж и работата спира; Освен това пътят за възстановяване не е дефиниран. Урок: автоматизацията с голямо въздействие трябва да има строги критерии, постепенно внедряване и път за връщане назад. Автоматизацията трябва да бъде обратима и наблюдавана чрез саморегулиране.

Случай 3 — Подхлъзване, уловено от самоконтрол. При тримесечен самостоятелен одит екип забелязва, че точността на откриване на фишинг на AI намалява: пропуска се нова фишинг вълна, защото не отговаря на старите модели (отклоняване на шаблона). Екипът събира проби, актуализира правилата за откриване и опреснява контекста, даден на AI. Без редовен самоконтрол това мълчаливо укриване можеше да продължи с месеци. Урок: само защото представянето е добро веднъж, то не винаги остава добро; измерването и обратната връзка са от съществено значение.

Слаба подкана / Силна подкана

Слаба подкана:

Напълно автоматизирайте нашия SOC и оставете AI да се справи с всичко.

Тази заявка изисква автоматизация без дискриминация на риска, игнорира човешки врати и не взема предвид връщане назад и контрол. Ако бъдат приложени, високорисковите решения ще станат автоматизирани без надзор и ще се превърнат в катастрофа при първата грешка.

Мощна подкана:

Вашата роля: Консултант в дизайна на SOC процеси. [Избройте] тези стъпки от жизнения цикъл на събитието в три въз основа на нивото на риск: (A) напълно автоматизирано (нисък риск, обратимо, повтарящо се), (B) AI препоръчва + одобрява от човек, (C) винаги човешко решение (висок риск, необратимо). Предложете задължителен път за връщане назад и показател за проследяване за всеки (A) и (B). Също така начертайте тримесечен контролен списък за самоодит: фалшиви положителни/отрицателни проценти, MTTD/MTTR, вземане на проби за точност на AI изхода, признаци на отклонение на модела.

Силното търсене разделя автоматизацията по ниво на риск, изисква връщане назад и наблюдение и установява рамка за саморегулиране.

Копируеми шаблони за подкана

ШАБЛОН ЗА РАЗДЕЛЯНЕ НА РИСКА ЗА АВТОМАТИЗАЦИЯ. Разделете тези стъпки на работен поток за сигурност на три: (A) напълно автоматизирано, подходящо, (B) Препоръчва, одобрява от човек, (C) винаги взема решение от човека. Напишете обосновка, обратимост и въздействие върху бизнеса за всяка стъпка. Препоръчайте задължителен път за връщане назад за стъпки с голямо въздействие. Стъпки: [списък]

ВЪРТАНЕ НА ДИЗАЙН ШАБЛОН за автоматично действие [напр. заключване на акаунта] предлагат сигурен дизайн: критерии за задействане (тесни), постепенно внедряване, фалшива стъпка за връщане назад, предупреждение и човешка точка за проверка. Проектирайте, за да избегнете сляпа автоматизация. Действие: [пишете]

ШАБЛОН НА КОНТРОЛЕН СПИСЪК ЗА САМООДИТ Изготвяне на тримесечен контролен списък за самоодит за SOC, задвижван от AI: фалшиво положителен/отрицателен процент, MTTD/MTTR пристрастие, извадка за точност на изхода на AI, фалшиви тригери за автоматизация, признаци на отклонение на модела, работа на обратна връзка, съответствие на поверителност/анонимност. За всеки артикул напишете как ще се измерва.

ШАБЛОН ЗА ОБРАТНА СВЪРЗКА Начертайте какво се научава от действителното събитие/аларма, която е неуспешна: (1) моделът, който ще се превърне в ново правило за откриване, (2) фалшивото положително, което ще бъде добавено към списъка с изключения, (3) стъпката на книгата, която ще бъде актуализирана, (4) новият контекст, който ще бъде даден на AI. Резюме на събитие/аларма: [поставяне]

Често срещани грешки

  • Автоматизиране на високорисковата стъпка. Необратими стъпки като изолиране на сървъра, корекция на продукцията, официално известие не се премахват от човешката врата.
  • Без измисляне на път за извличане. Възможно е всяко автоматично действие да се задейства неправилно; Автоматизацията без точка за отмяна и потвърждение е опасна.
  • Задайте и забравете. Производителността на ИИ се променя с промяната на средата; Без редовен самоконтрол и измерване се натрупват тихи увъртания.
  • Просто проследявам фалшивия положителен резултат. Фалшивият отрицателен резултат (истинската заплаха, която е пропусната) е по-опасен, но по-труден за забелязване; Гледайте го лично.
  • Пренебрегване на обратната връзка. Ако откритите събития не се превърнат в ново правило и неуспешните аларми не се превърнат в изключение, операцията не се учи и повтаря същата грешка.
Подсказка: Златният въпрос при решението за автоматизация: „Може ли това действие да бъде отменено, ако е задействано неправилно и какво е въздействието върху бизнеса?“ Ако отговорът е „лесно се отменя, слабо въздействие“, автоматизирайте; Ако е „необратимо или силно въздействие“, дръжте на вратата на човека.
Внимание: Автоматизацията не премахва отговорността, а само я ускорява. Лошо обмисленото автоматично действие причинява щети много по-бързо и по-широко, отколкото би могъл човек. Всяка автоматизация е заобиколена от тесни критерии, път за връщане назад и редовна проверка; Крайната отговорност винаги е на човешкото същество.

В обобщение

Това звено комбинира всички части на модула в цялостен SOC работен процес: събиране, откриване, сортиране, разследване, реакция, отстраняване, докладване и обратна връзка. AI участва във всяка връзка, но човекът е този, който държи веригата и взема решения на всяка критична врата. Автоматизацията (SOAR + AI) увеличава мощността; Правилото е ясно: нискорисковите, обратими, повтарящи се стъпки стават автоматизирани, високорисковите, необратими стъпки минават през човешката врата и всяка автоматизация има начин да се отмени. И накрая, задвижвана от AI програма за сигурност е активна: фалшивите положителни/отрицателни резултати, MTTD/MTTR, точността на изхода и отклонението на модела се измерват редовно; Намереното се превръща в правила и книги за игра в обратна връзка. Автоматизацията ускорява отговорността, а не я премахва; Самоконтролът поддържа сигурността жива.

Задача за приложение

Напишете жизнения цикъл на инцидента на вашата собствена организация (или примерен SOC). Класифицирайте всяка стъпка като A/B/C с шаблона „Разделяне на риска от автоматизацията“ и извлечете безопасен дизайн за автоматизация с шаблона „Дизайн за връщане назад“ за поне една стъпка с „високо въздействие“. След това създайте тримесечен контролен списък с шаблона „Контролен списък за самопроверка“ и определете как ще измервате всеки показател във вашата среда.

контролен списък

  • [ ] Разделих всяка стъпка от жизнения цикъл на инцидента на A/B/C рисков клас.
  • [ ] Поддържах високорискови, необратими стъпки пред човешката врата.
  • [ ] Създадох тесни критерии и път за отмяна за всяко автоматично действие.
  • [ ] Планирал съм да наблюдавам процента на фалшивите положителни резултати и особено фалшивите отрицателни резултати.
  • [ ] Планирах редовно да измервам MTTD/MTTR и изходната точност на AI.
  • [] Създадох тримесечен контролен списък за самонаблюдение за отклонение на модела.
  • [ ] Свързах откритите събития и хвърлените аларми към веригата за обратна връзка.

Изпит по модул

1. ИИ за сортиране на SIEM маркира аларма като „нисък приоритет, вероятно фалшиво положителна“ и я избута в дъното на списъка. Какво трябва да направи анализаторът с тази аларма?

  • A) Все още независимо проверява алармата и я потвърждава със сурови доказателства; Анализаторът взема решение за затваряне и го записва ✔
  • Б) Изкуственият интелект автоматично изключва алармата, без да я изследва, защото казва, че е с нисък приоритет.
  • C) Прехвърля алармата към следващата смяна така, както е.
  • Г) Просто погледнете резюмето, дадено от изкуствения интелект и предайте доклада

Обяснение: приоритизирането на AI е препоръка, а не диагноза; Флагът „нисък приоритет“ може да покрие истинска атака (фалшиво отрицание). Анализаторът все пак трябва независимо да провери сигнала, да го потвърди със сурови доказателства и да вземе решението да го затвори сам. Отрицателният AI резултат не е гаранция за „липса на заплаха“.

2. Каква комбинация от рискове AI етикетира истинска атака като „нормална“ и анализаторът се доверява на това и отпуска собствения си анализ?

  • A) Само фалшиви положителни резултати и аларма за умора
  • B) Фалшиво отрицание и пристрастие към автоматизацията (прекомерно разчитане на AI) ✔
  • C) Липса само на източник на журнал
  • D) Само грешка в правилото SIEM

Обяснение: Това е фалшиво отрицание, ако моделът пропусне истинската заплаха; Пристрастие към автоматизацията е, когато анализаторът се довери прекалено много на изкуствения интелект и се откаже от независимия преглед. Когато двете се комбинират, причината за човешкия контрол изчезва и атаката може да бъде напълно заобиколена. Ето защо се изследват и области, които изкуственият интелект нарича „чисти“.

3. AI ​​каза „CVE-2024-88888, CVSS 9.8, корекция незабавно“ по време на сортиране. Какво първо трябва да направи анализаторът?

  • A) Счита CVE за надежден и незабавно инициира плана за корекция
  • B) Само защото CVSS е 9.8, той го поставя на първо място, без да разглежда други уязвимости
  • C) Проверява номера на CVE и резултата в записа на NVD/доставчика; ✔ Ако няма запис, той няма да бъде посочен, знаейки, че може да е фалшив.
  • D) Без да проверява CVE, администраторът го записва в отчета като „критична заплаха“

Описание: Езиковите модели могат свободно да пасват на несъществуващ CVE номер и резултат (халюцинират). Анализаторът трябва да провери CVE в NVD/дневника на доставчика и да потвърди неговата автентичност и резултат, преди да се ангажира с графика за корекция. Непроверен CVE първо се свързва с ресурса; В противен случай екипът ще губи време в преследване на кръпка, която не съществува.

4. За да ускори разследването на инцидент, експерт поставя необработения дневник на защитната стена заедно с действителните вътрешни IP адреси, потребителски имена и имена на VPN сървъри в публично достъпен AI инструмент. Какъв е основният проблем тук?

  • A) AI не може да прочете формата на журнала, така че анализът е безполезен
  • B) Ако дневникът е твърде дълъг, това забавя модела.
  • C) Регистрационните файлове на защитната стена така или иначе не са подходящи за анализ
  • D) Истински IP, имена на потребители и сървъри се споделят без анонимизиране; Това е както нарушение на KVKK, така и изтичане на мрежовата карта на организацията ✔

Описание: Данните за сигурност са едновременно лични данни (потребител, IP) и корпоративно разузнаване, което разкрива повърхността на атака на организацията (топология на мрежата, имена на сървъри). Предоставянето на това на външен инструмент без анонимизиране е едновременно нарушение на KVKK и разкрива мрежова карта, която ще бъде полезна за нападателя. Първо, действителните стойности са маскирани с последователни контейнери.

5. Какво прави ловът на заплахи да се счита за добре проектиран?

  • A) Започва с конкретна, подлежаща на проверка хипотеза и намерената следа се потвърждава от необработени доказателства ✔
  • B) Започва, като казва на изкуствения интелект „открий дали има нападател в моята мрежа“
  • C) Автоматично обявява всяко открито необичайно/рядко събитие като атака
  • Г) Работи само когато пристигне аларма, не е проактивен

Обяснение: Доброто търсене на заплахи не започва с аларма, а с конкретна и подлежаща на проверка хипотеза, която може или не може да се окаже вярна (напр. „Акаунт X свързал ли се е с повече от 50 вътрешни IP адреси по време на неработно време“). Неясен въпрос като „Има ли нещо лошо в моята мрежа“ не може да бъде тестван и оставя AI да гадае. Намерената следа не се счита за заплаха, докато не бъде потвърдена със сурови доказателства.

6. Уязвимостта има CVSS оценка 9.1 на изолиран тестов сървър във вътрешната мрежа; В същия списък CVSS 7.5 на сървър, отворен към интернет, но има друга уязвимост в списъка с KEV (която всъщност се използва). Какво е правилното приоритизиране?

  • A) Този с най-висок CVSS (9.1) винаги се пачва първи
  • B) Уязвимостта на 7.5 в интернет и списъка с KEV се пренася напред; CVSS не е единственият критерий, излагането и действителната злоупотреба са решаващи ✔
  • C) И двете се закърпват по едно и също време и с еднакъв приоритет, разграничението е ненужно
  • Г) Нито един от тях не е коригиран, защото има уязвимост в тестовия сървър

Обяснение: CVSS не задава приоритети сам; действителният риск се определя от EPSS (вероятност за експлоатация), KEV (действителна експлоатация) и организационен контекст (излагане, критичност, компенсаторен контрол). Интернет изложена и действително използвана (KEV) уязвимост предотвратява изолирана и нисковероятна висока CVSS уязвимост.

7. В отговор на инцидент изкуственият интелект казва „Трафикът, произхождащ от IC_HOST_7, е подозрителен, изолирайте този сървър“. IC_HOST_7 е основният сървър за удостоверяване на институцията. Какво трябва да направи анализаторът?

  • А) Изкуственият интелект веднага изолира сървъра, защото го казва
  • B) Оставя решението за изолация изцяло на изкуствения интелект
  • C) Първо оценете бизнес въздействието и причината за трафика; Той не изолира критична инфраструктура, без да измерва нейното въздействие, и взема решението като анализатор ✔
  • D) Изолира сървъра и след това изтрива всички регистрационни файлове

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

8. При инцидент с ransomware екипът иска да възстанови засегната машина, за да я почисти бързо; но има криминалистични доказателства (изхвърляне на паметта, инструменти за атакуващи) на машината, които все още не са събрани. Какъв е правилният подход?

  • A) Машината незабавно се преинсталира; доказателствата са без значение
  • B) От изкуствения интелект се иска „най-бързо почистване“ и инструкцията се прилага на сляпо.
  • В) Машината е изключена и изхвърлена, защото доказателствата вече са в дневника.
  • D) Първо се вземат съдебномедицинското изображение и дъмпът на паметта и доказателствата се запазват, след което се извършва почистване/възстановяване ✔

Обяснение: Скоростта на възстановяване не може да надмине запазването на доказателства. Повторното инсталиране на машината без събиране на доказателства разрушава веригата на защита и осакатява съдебния процес. Първо се правят криминалистично изображение и дъмп на паметта, след което се извършва почистване/възстановяване. Криминалистичните стъпки не са делегирани на AI.

9. Кое е едно от най-надеждните нива на техническа проверка при анализиране на предполагаем фишинг имейл и как трябва да се потвърди?

  • A) SPF/DKIM/DMARC води до заглавки на имейли; Потвърдено от необработеното заглавие, а не от резюмето на AI ✔
  • Б) Цвят и шрифт на имейла; решен чрез визуален дизайн
  • C) Щракнете върху подозрителната връзка в активната система и погледнете страницата, която се отваря.
  • Г) Изкуственият интелект казва, че „фишингът“ сам по себе си е достатъчно доказателство

Обяснение: SPF/DKIM/DMARC резултатите в имейл заглавките са силни индикатори за това дали имейлът действително идва от домейна, за който претендира; Ако и трите се провалят и подателят подмени домейна, подозрението става по-силно. Това обаче трябва да се потвърди от необработеното заглавие, а не от резюмето на AI. Освен това никога не се кликва върху подозрителни връзки в системата на живо.

10. В преглед на кода AI предложи корекция за XSS уязвимост и каза, че „той затваря уязвимостта“. Какво трябва да направи анализаторът/разработчикът?

  • A) Счита корекцията за надеждна и я пуска директно в производство
  • B) Преглежда корекцията, потвърждава, че тя действително затваря уязвимостта и не въвежда нови уязвимости/бъгове, и пише тест; Едва след това постъпва на склад ✔
  • В) Тъй като не е сигурен, той пренаписва целия файл на изкуствения интелект и го използва.
  • D) Прилага корекцията, но преминава без писане на тестове

Обяснение: Поправката, предложена от AI, не е автоматично безопасна; Може да не затвори напълно уязвимостта, може да почисти грешния слой или може да въведе нова уязвимост/функционална грешка. Всеки пач се преглежда, оценява се дали наистина затваря уязвимостта и дали въвежда нови проблеми и се записват положителни и отрицателни тестови случаи; Едва след това влиза в склада.

11. Когато анализира атака, изкуственият интелект каза, че „това определено е дело на групата APT-Dark Eagle“. Какъв е правилният подход по отношение на разузнаването на заплахи?

  • А) Приемете справката такава, каквато е, и я запишете в доклада като „определен извършител“
  • Б) Той изгражда цялата си защита въз основа на тази група, без изобщо да поставя под въпрос името на групата.
  • C) Използва език „в съответствие с техниките“, а не точно приписване, проверява групата в известни източници и взема предвид възможността за измисляне ✔
  • Г) Цитирането винаги е излишно, изобщо не се взема под внимание

Обяснение: Груповото приписване е най-трудната и най-неточната област на интелигентността; AI може дори да създаде име на група, което не съществува. Вместо точна препратка се използва езикът „съвместим с тези техники“ и името на групата е потвърдено в известни източници на разузнаване. Освен това защитата не се основава на краткотрайни IOC, а на постоянно откриване на TTP.

12. В проектодоклад за инцидент AI написа изречението „нападателят най-вероятно е бил вътре в продължение на три седмици и е измъкнал клиентски данни“; като има предвид, че няма убедителни регистрационни доказателства в подкрепа на тези твърдения. Какво трябва да направи анализаторът?

  • А) Оставя изречението така, както е, защото е драматично и впечатляващо
  • Б) Оставя изречението, но добавя „изкуственият интелект е написал“ в края
  • В) Отпечатва отново целия доклад към изкуствения интелект и го подписва, без да го проверява.
  • Г) Коригира твърденията въз основа на доказателства; Прави разграничение между „възможно/доказано/в процес на разследване“ и извлича окончателното твърдение без доказателства ✔

Коментар: В официален доклад за сигурността всяко твърдение трябва да бъде обосновано и „вероятно“ никога не трябва да се бърка с „доказано“. Искът без доказателства има правни, финансови и репутационни последици. Анализаторът трябва да коригира изречението според доказателствата (например, напишете датата на първия открит достъп и кажете „няма открити убедителни доказателства, разследването продължава“ за изтичането на данни).

13. Мениджър иска да профилира цялата дейност на служител от регистрационните файлове на сигурността с изкуствен интелект, за да разбере дали е „лоялен“ или не. Какво трябва да прави един специалист по сигурността?

  • A) Отхвърля искането и го насочва към съответния канал (HR/юридическо/дефинирано разследване); данните за сигурност не са средство за лично наблюдение ✔
  • B) Създава и доставя профила, защото мениджърът го изисква
  • C) Извлича само някои регистрационни файлове и дава частичен профил
  • Г) Нека профилът е създаден от изкуствен интелект, защото отговорността преминава към изкуствения интелект

Описание: Данните за сигурност се събират за целите на сигурността; Проследяването/профилирането на лице е злоупотреба, превръща се в лично наблюдение и нарушава KVKK. Експертът трябва да отхвърли това искане и да го насочи към подходящия канал (HR, правен, определена и легитимна рамка за разследване). Добронамереността или желанието на мениджъра не оправдават това ограничение.

14. SOC решава кои стъпки от работния поток по сигурността да автоматизира. Кой е най-добрият принцип за автоматизация?

  • A) Решенията с най-висок риск трябва първо да бъдат автоматизирани, така че да няма човешко участие
  • B) Стъпките с нисък риск/обратими стъпки са автоматизирани; висок риск/необратими стъпки остават на вратата на човека и всяка автоматизация има начин да се отмени ✔
  • C) Всички SOC трябва да бъдат напълно автоматизирани и самоодитът не е необходим
  • Г) Автоматизираните действия не трябва да се отменят, защото AI не прави грешки

Обяснение: Нискорискови, повтарящи се и обратими стъпки (събиране на регистрационни файлове, обогатяване на аларми) могат да бъдат автоматизирани; Високорискови, необратими и изискващи преценка стъпки (изолиране на сървъра, корекция на продукцията, официално известие) минават през човешката врата. Освен това всяко автоматично действие трябва да има тесни критерии и начин за отмяна. Автоматизацията не премахва отговорността, а само я ускорява.