Четиридесет процента от екипите по сигурност вече използват изкуствен интелект (AI) всеки ден, а други 56% го тестват. Едва 4% нямат планове да го внедрят, според проучването State of AI in Security Operations 2026 на Prophet Security сред повече от 250 директори по информационна сигурност (CISO), ръководители на центрове за оперативна сигурност (SOC) и практикуващи специалисти. За екипите, които все още тестват технологията, следващото решение е дали техният собствен SOC е готов.
Готовността за AI SOC има две части: дали един SOC има проблемите, за чието решаване са създадени AI SOC агентите, и дали разполага с достъпа до данни, контекста, писмените стандарти и правилата за надзор, от които AI агентите се нуждаят, за да разследват прецизно сигналите в неговата среда. Не е необходимо един SOC да е напреднал в модела на зрялост, за да бъде готов. AI агентите извършват първоначалната си работа на най-долното ниво – обработката на сигнали за тревога, а спестените часове труд на анализаторите дават на екипа пространство да работи върху нивата над него.
Следващият раздел описва тези проблеми. Техническата готовност обхваща четири области: достъп и контекст, стандарт за разследване с базови показатели, правила за това какво може да прави агентът и план за оползотворяване на времето, което той освобождава.
Кои центрове за оперативна сигурност (SOC) извличат най-голяма полза от AI SOC агентите
Центровете за оперативна сигурност, които печелят най-много от AI SOC агентите, обикновено разпознават няколко от изброените по-долу проблеми – независимо дали външен доставчик обработва техните сигнали, или това се прави от собствените им анализатори.
Ако доставчик на управлявано откриване и реакция (MDR) или доставчик на управлявани услуги за сигурност (MSSP) обработва вашите сигнали:
- Вашият MDR маркира заплахите твърде бавно. Доставчикът обработва вашите сигнали в опашка, която споделя с другите си клиенти, така че ескалацията за реално проникване може да пристигне часове след началото на активността.
- Вашият MDR връща сигналите обратно поради липса на контекст. Ескалацията пристига с кратко резюме и въпроси като: очаквано ли е това влизане в системата, това продукционен сървър ли е, или този потребител пътува в момента? Доставчикът често не познава вашите потребители, активи и бизнес достатъчно добре, за да завърши разследването, затова вашите анализатори трябва да свършат останалото.
- Вашият MDR затваря сигнали, без да показва извършената работа. Когато доставчикът отбележи даден сигнал като безобиден, бележката може да не посочва какво е проверил и как е стигнал до това заключение, така че вашият екип или се доверява на преценката, или провежда разследването отново.
- Покритието на вашия MDR спира до инструментите, които той поддържа. Много договори обхващат EDR системата и фиксиран списък от източници на логове, така че сигналите от всичко останало, като например SaaS приложение или втора облачна платформа, остават за вашия екип.
Ако вашите собствени анализатори обработват опашката със сигнали, включително всичко, което външният доставчик връща обратно:
- Отговорът на въпроса „Засегнати ли сме?“ отнема дни. Когато критична уязвимост или нова кампания попадне в новините, ръководството иска отговор още същия ден. Получаването му означава ръчно търсене на заплахи в цялата среда, обикновено от анализатор, който същевременно обработва и текущата опашка със сигнали.
- Сигналите с по-ниска степен на критичност чакат или се затварят масово. Задълбоченото разследване означава превключване между SIEM, EDR, доставчика на идентичност, облачната конзола и инструментите за електронна поща, така че екипът успява да се справи с критичните и високорисковите сигнали, а до останалите стига, когато може. В проучването 60% от респондентите споделят, че сигнал, който са игнорирали или пропуснали, по-късно се е превърнал в сериозен проблем, като пробив в сигурността или прекъсване на работата.
- Твърде „шумните“ правила за откриване биват изключвани. Настройването на правило, което се задейства твърде често, отнема време, с което екипът не разполага, затова правилото се деактивира, а техниката, за която то е следяло, остава непокрита.
- Търсенето на заплахи (threat hunting) и инженерингът на правила за откриване чакат свободно време. Проактивната работа се случва само когато някой има свободен следобед, тъй като опашката със сигнали е с приоритет.
- Няколко старши анализатори носят тежестта на сложните случаи. Само един или двама души знаят как да обработват най-трудните разследвания, така че дори едно напускане може да върне екипа назад.
- Нощите и уикендите са слабо покрити. Осигуряването на персонал за денонощна обработка на опашката изисква повече анализатори, отколкото бюджетът позволява, затова сигналите, които се задействат извън работно време, чакат до сутринта или отиват при дежурния служител на разположение.
AI SOC агентите са създадени точно за тази работа. Те са проектирани да започват работа по всеки сигнал веднага щом той пристигне, независимо кой инструмент го е генерирал и в колко часа. Те могат да извличат от вашите собствени системи контекста, който липсва на външния доставчик, и да записват доказателствата зад всяко заключение, за да може екипът ви да ги провери. Някои от тях могат също така да проведат търсене на заплахи още в деня на разкриване на нова заплаха, което превръща въпроса „засегнати ли сме?“ в набор от заявки с готови отговори. Освободените часове на анализаторите могат да бъдат насочени към работата по откриване и търсене на заплахи, която днес остава на заден план.
Ако няколко от тези проблеми ви звучат познато, значи необходимостта е налице. Следващият въпрос е дали вашият SOC може да поддържа такова внедряване.
Къде се вписват AI агентите в модела на зрялост на SOC
Моделът на зрялост на SOC на Prophet Security, наречен SOC Hierarchy of Needs („Йерархия на нуждите на SOC“), има пет нива: управление на сигнали, покритие на откриването, информираност за заплахите, проактивно търсене на заплахи и подобрения в цялостното състояние на сигурността. Всяко ниво зависи от това под него. Екип, затрупан със сигнали, рядко стига до проактивно търсене на заплахи, а екип, който търси заплахи без информираност за тях, няма ясна представа какво точно да търси.
Много центрове за оперативна сигурност все още не са стабилизирали първото ниво. В проучването State of AI in Security Operations 2026 респондентите посочват, че 28% от техните сигнали никога не биват разследвани.
AI SOC агентите обикновено започват на това първо ниво, като разследват сигналите при тяхното постъпване. По-новите платформи също така провеждат търсене на заплахи и предлагат правила за откриване – работа, която достига до нива две и четири. И в двата случая часовете на анализаторите, които те освобождават, отиват за работа над първото ниво, така че готовността зависи от това от какво се нуждае първото ниво.
Един AI агент може да разследва само това, до което може да изпраща заявки
AI агентът провежда разследвания, като изпълнява заявки към вашите инструменти, така че не може да види нищо, до което няма достъп. Ако може да изпраща заявки към EDR системата, но не и към доставчика на идентичност, той може да опише какво се е случило на крайното устройство, но не и кой акаунт стои зад тези действия.
Готовността тук се състои от три части:
- API достъп до източниците, от които се нуждае разследването. Това обикновено означава SIEM, EDR, доставчик на идентичност, облачни платформи, електронна поща и ключови SaaS приложения.
- Контекст, който агентът може да разчете. Агентът се нуждае от информация за критичността на активите, потребителските роли, списъците с VIP потребители, бизнес звената и известната безобидна активност, като например планирани сканирания и администраторски скриптове, за да различи атакуващия от легитимния администратор.
- Надеждни канали за данни (data pipelines). Тих или забавен източник на логове може да накара едно разследване да изглежда завършено, когато всъщност липсват ключови доказателства, затова изправността на каналите за данни, които захранват разследванията, се нуждае от наблюдение.
Бърз тест: вземете пет скорошни инцидента и избройте всяка заявка, която старши анализатор е изпълнил, за да ги приключи. Всяка заявка, която агентът не би могъл да изпълни, бележи пропуск, който трябва да бъде отстранен преди пилотното внедряване.
Достъпът до данни повдига и най-често срещаното възражение. В нашето проучване 44% от екипите посочват поверителността на данните и начина на обучение на AI моделите — най-честата пречка, назована от респондентите. Попитайте всеки доставчик дали вашите данни обучават техните модели и къде се обработват тези данни.
Дефинирайте какво е завършено разследване и запишете базовите си показатели
Пилотният проект се нуждае от писмен стандарт, спрямо който да се оценява агентът. В много центрове за сигурност (SOC) само старшите анализатори знаят този стандарт и той рядко е разписан черно на бяло.
Стандартът обхваща кои доказателства приключват случай с фишинг, кога сигнал за „невъзможно пътуване“ (impossible-travel) изисква обаждане до ръководителя на потребителя и какво се счита за достатъчно, за да бъде обявен един сигнал за безобиден. Разписването му за типовете сигнали с най-голям обем дава на новите анализатори и ценен документ за въвеждане в работата.
Освен това поддържайте списък с детекциите, които са били изключени. В нашето проучване до 40% от организациите са изключили някои детекции, тъй като не са разполагали с достатъчно хора, които да ги проверяват. Когато един агент разследва всеки сигнал, някои от тези правила могат да бъдат върнати в действие, а списъкът ви казва откъде да започнете.
След това запишете показателите, спрямо които ще сравнявате: дела на разследваните сигнали, средното време за разследване, времето от получаване на сигнала до първия преглед и колко често приключените сигнали се отварят отново. Проучването дава отправна точка. Задълбоченото разследване отнема средно 75 минути, а сигналите често чакат близо час, преди някой да ги отвори.
Можете да изтеглите нашето ръководство за инженеринг на детекциите, за да научите повече за това как един базиран на агенти SOC подпомага инженеринга на детекции.
Решете какво може да прави агентът и кой одобрява повече правомощия
Разследването и реакцията носят различни рискове и повечето екипи ги третират по различен начин. В проучването 57% от екипите изискват човек да преглежда всяко решение на AI, преди даден сигнал да бъде приключен. По отношение на реакцията, при 44% AI препоръчва действия, които хората изпълняват, 30% му позволяват самостоятелно да извършва нискорискови действия по отстраняване, а нито един респондент не му дава пълна, неконтролирана автономност.
Един подготвен SOC има тези правила разписани преди началото на пилотния проект:
- Одобрения по подразбиране. Списък на действията, които остават за одобрение от човек, като например изолиране на хост, деактивиране на акаунт или блокиране на домейн.
- Как се разширяват правата. Кой може да предостави на агента повече автономност за дадена категория действия и какви доказани резултати трябва да види първо.
- Къде отиват констатациите. Констатациите на агента трябва да се появяват в инструментите за управление на случаи или тикетинг системите, които анализаторите вече използват, за да не се налага никой да следи още една конзола.
- Кой отговаря за обратната връзка. Конкретно определено лице преглежда грешките на агента и превръща корекциите в насоки, които той ще използва следващия път.
Започването с достъп само за четене при разследванията и последващото разширяване на правата с нарастването на увереността прилага същите правила, които един SOC използва за нов анализатор човек. Рамката на Prophet Security за изграждане на доверие в AI SOC следва същия поетапен подход.
Въпросник за готовност, съпоставен с модела на зрялост
Отговорете на всеки въпрос с „да“ или „не“. Част 1 проверява необходимостта, а Част 2 проверява техническата готовност. Нивото в скоби показва към кой слой от Йерархията на нуждите на SOC принадлежи всеки елемент.
Част 1: Има ли нужда вашият SOC от AI SOC агенти?
- Пристигат ли ескалациите от вашия MDR или MSSP доставчик часове след началото на активността? (Ниво 1: управление на сигнали)
- Връща ли вашият доставчик сигнали обратно, защото му е липсвал контекст, за да ги завърши? (Ниво 3: осведоменост за заплахите)
- Затваря ли вашият доставчик сигнали, без да показва какво е проверил? (Ниво 1: управление на сигнали)
- Попадат ли при вашия екип сигнали от инструменти извън обхвата на доставчика ви? (Ниво 1: управление на сигнали)
- Отнема ли повече от един ден, за да кажете на ръководството дали сте засегнати от нова уязвимост или кампания? (Ниво 4: проактивно търсене на заплахи)
- Чакат ли сигналите с ниска и средна критичност, или биват затваряни масово без разследване? (Ниво 1: управление на сигнали)
- Били ли са изключени „шумни“ детекции, защото никой не е имал време да ги настрои фино? (Ниво 2: покритие на детекциите)
- Чакат ли проактивното търсене на заплахи и инженерингът на детекции, докато някой намери свободно време? (Ниво 4: проактивно търсене на заплахи)
- Само един или двама старши анализатори ли знаят как да работят по най-трудните ви случаи? (Ниво 1: управление на сигнали)
- Чакат ли до сутринта сигналите, които се задействат през нощта или през уикендите? (Ниво 1: управление на сигнали)
Всяко „да“ е проблем, който един AI SOC агент може да поеме, и колкото повече са отговорите „да“, толкова по-силни са аргументите за внедряване.
Част 2: Готов ли е вашият SOC да ги внедри?
- Може ли нов инструмент да прави заявки към вашите SIEM, EDR, системи за идентичност, облачни и имейл източници чрез API? (Ниво 1: управление на сигнали)
- Записани ли са критичността на активите, потребителските роли и известната безобидна активност на място, което системата може да прочете? (Ниво 3: осведоменост за заплахите)
- Има ли писмен стандарт за това какво включва едно пълно разследване за типовете сигнали, които съставляват по-голямата част от обема ви? (Ниво 1: управление на сигнали)
- Решили ли сте кои действия остават за одобрение от човек и кой може да разширява правата на агента? (Ниво 1: управление на сигнали)
- Следите ли дали източниците на логове, от които зависят вашите разследвания, пристигат нормално? (Ниво 2: покритие на детекциите)
- Знаете ли какъв е текущият ви дял на разследвани сигнали и средното време за разследване? (Ниво 1: управление на сигнали)
- Поддържате ли списък с детекции, които са били изключени поради липса на капацитет? (Ниво 2: покритие на детекциите)
- Има ли план с конкретни отговорници за часовете на анализаторите, които агентът ще освободи, като например планирано търсене на заплахи или работа по детекции? (Ниво 4: проактивно търсене на заплахи)
Отговор „не“ на някой от първите четири въпроса си струва да бъде коригиран преди пилотен проект в продукционна среда. По останалите четири може да се работи и по време на самия пилот.
Какво да правите, ако отговорът е „все още не“
Повечето елементи от списъка в Част 2 представляват работа по конфигуриране и документиране: издаване на API идентификационни данни, експортиране на контекст за активи и потребители и разписване на стандарта за разследване. Един работещ ред на действие е следният:
- Първо затворете пропуските в достъпа от теста с петте инцидента, тъй като всяка следваща стъпка зависи от това агентът да вижда данните.
- Напишете стандартите за разследване за типовете сигнали с най-голям обем.
- Пуснете агента да работи паралелно с вашите анализатори за няколко седмици. Запишете базовите показатели преди старта и третирайте всяка корекция от страна на анализатор като данни за това къде агентът се нуждае от повече контекст.
- Разширявайте правата на агента с по една категория действия наведнъж, когато резултатите му го оправдават.
Някои екипи, които не са готови, обмислят вместо това да изградят свои собствени агенти. Проучването съветва за предпазливост: 72% от потребителите на изкуствен интелект са опитвали да разработят вътрешни AI инструменти, а 46% от тези проекти са били изоставени, никога не са достигнали до продукционна среда или са били заменени от търговски продукт.
Изграждането на работещ прототип е само малка част от работата. По-голямата част от нея е инженеринг и поддръжка на интеграции, чието разработване отнема седмици, но които се чупят, когато доставчик промени API интерфейс; ограничения на честотата на заявките (rate limits), които трябва да се заобикалят; остаряване и спиране от поддръжка на модели на всеки шест до девет месеца, което налага пълен цикъл от тестове за оценка (evals), предпазни механизми и тестване за инжектиране на промптове (prompt injection); както и одитни следи, обясняващи защо всяко предупреждение е било затворено.
Как работи Prophet Security
Prophet Security е водещата AI SOC платформа за корпоративни центрове за сигурност (SOC), отличена в класацията Rising in Cyber 2026 – признание, гласувано от над 150 главни директори по информационна сигурност (CISO) и лидери в сферата на сигурността. Нейната платформа, Prophet AI, работи директно с технологичния стек, който екипът вече използва. Инструментите за AI SOC от първо поколение спираха до триажа на предупрежденията. Prophet AI прави възможен един агентен SOC със специализирани агенти за разследване, проактивно търсене на заплахи (threat hunting) и инженеринг на детекции.
Prophet AI SOC Analyst разследва всяко предупреждение от всяко ниво на критичност, денонощно, със задълбочеността на старши анализатор. Той прави директни заявки към инструментите за SIEM, EDR, управление на идентичността, облачна среда и имейл, като записва всеки въпрос, заявка и доказателство, стоящи зад дадено заключение, така че анализаторът да може да изпълни отново всяка заявка и да провери свършената работа. Той предприема действия за реакция само в рамките на правата за достъп, зададени от клиента, като одобрението от човек е настройката по подразбиране.
Prophet AI Threat Hunter е създаден, за да отговаря на въпроса „засегнати ли сме?“. Той поддържа профил на индустрията на всяка организация, нейния технологичен стек и злонамерените субекти, които я вземат на прицел. Когато се появи нова сериозна заплаха, търсенето ѝ се стартира автоматично във фонов режим. Планираните претърсвания, включително такива, насочени към пропуски в покритието, и въпроси, които екипът формулира на естествен език, се изпълняват с честотата, зададена от екипа. Подозрителните следи се предават на SOC Analyst за пълно разследване.
Prophet AI Detection Engineer поема работата по инженеринг на детекции, която обикновено чака за свободно време. Той поддържа актуална карта на покритието спрямо MITRE ATT&CK, изградена на базата на собствените разследвания на организацията, като показва кои техники са покрити, кои са затихнали и за кои липсва видимост. Той създава и прецизира детекции въз основа на това, което разкриват разследванията, претърсванията за заплахи и пропуските в покритието, пише ги на езика за правила на съответната SIEM система или инструмента, в който се изпълняват, и тества всяка от тях ретроспективно (backtesting) спрямо собствената история от данни на организацията. Всяка промяна пристига като предложение за преглед със съответната обосновка и резултати от ретроспективния тест, като по подразбиране нищо не достига до продукционна среда, докато екипът не го одобри.
Откритията на всеки продукт захранват останалите. Разследванията показват кои детекции генерират твърде много шум и къде покритието е слабо, претърсванията за заплахи проверяват именно тези пропуски, а това, което те открият, се превръща в нови детекции. Екипът обучава Prophet AI на естествен език и тези насоки определят как да се провеждат разследванията, как да се задава обхватът на претърсванията и как да се пишат детекциите. Данните на клиентите никога не се използват за обучение на моделите, а равнината за обработка на данни (data plane) може да работи в собствения виртуален частен облак (VPC) на клиента.
Пълният доклад „State of AI in Security Operations 2026“, включително цитираните тук данни от проучването, е достъпен за изтегляне.