Реакция үшін SOAR: бірінші кезекте қай плейбуктарды автоматтандыру керек

SOAR реагирацияда нақты немен жылдамдатады

SOAR тергеуді толықтай жылдамдатпайды, ол қайталанатын қадамдарды тездетеді. Ол поштадан, EDR немесе SIEM-ден келген сигналды түсінікті тапсырмаға айналдырып, әдетте қолмен жасалатын рутиналық әрекеттерді дереу орындайды.

SOC-та көп уақыт әдетте күрделі шешімдерде емес, күту мен жүйелер арасында ауысуда кетеді: есепшот иесін табу, лог сұрау, бірнеше консолді ашу, хэштi қайта тексеру, тикет рәсімдеу, изоляцияны келісу. Әр қадамда қате кетуі оңай: хабарламаны басқа адамға жіберу, артефактты қосуды ұмыту, есепте маңызды өрісті жіберіп алу.

SOAR типтік операцияларда минуттар мен сағаттарды үнемдейді:

• деректер жинау және обогащение (хат тақырыптары, IP, домендер, хэштәр, кіру тарихы);
• автоматты сұрыптау (инцидент категориясы, приоритет);
• әрекеттерді оркестрациялау (тикет жасау, ескертулер, келісім сұрау);
• тез сдерживание (есепшотты уақытша блоктау, хостты карантинге жіберу, сессияларды қайтару).

Бастапқы автоматтандыруларға ең жақсы сәйкес келетіндер — жиі болатын, сценарийі айқын және "иә/жоқ" тармақтары бар инциденттер. Көп жұмыс орны мен серверлері бар ұйымдарда "күдік тудыратын хат — клик — аномалды кіру" тізбегі жиі қайталанады және әр ретте шамамен бірдей тексерулерді талап етеді.

Дегенмен бәрін бірден автоматтандыруға болмайды. Кейде процесс пен чеклистті реттеп алу әлдеқайда жылдам әрі қауіпсіз:

• сирек және біртұтас емес шаблондар (уникалды шабуылдар, күрделі тізбектер);
• келісімсіз істелсе үлкен тоқтап қалуға әкелетін әрекеттер (критикалық серверлерді изоляциялау);
• пайдаланушымен контекст пен әңгіме қажет қадамдар;
• деректерге немесе құқықтарға қолжетімділік болмағандықтан интеграцияларға тіреліп қалатын процестер.

Практикалық ереже — қайталанатын, айтарлықтай жылдамдататын және қауіпсіз қайтарылуға болатындығын автоматтандыру.

Первые плейбуктарды қалай таңдау керек

SOAR нақты жылдамдық беру үшін ең "ақылды" сценарийлерден емес, ең жиі болатындардан бастаңыз. Инцидент тоқсан сайын ғана болса, әдемі плейбук презентацияда ұнаса да алғашқы айларда жұмысқа айтарлықтай әсер етпейді.

Жақсы алғашқы плейбук қысқа тестті өтуі тиіс: қадамдар түсінікті, деректер қолжетімді, нәтиже оңай тексеріледі. Ең тез қайтарымды сценарийлерде көп қолмен жасалатын рутина болады: хатты ашу, IOC алу, пайдаланушыны AD-те тексеру, лог сұрау, тикет жасау, жүйе иесіне хабарлау.

2–3 кандидат таңдау үшін әдетте бес критерий жеткілікті:

• жиілігі: дежурный оны апта сайын қанша рет орындайды;
• тәуекел: 30 минутқа қателесу немесе кешігу неге әкеп соғуы мүмкін;
• қайталанушылық: әр жолы қадамдар бірдей ме;
• рутина долі: қанша рет басу мен көшіріп қоюды жоюға болады;
• деректер дайындығы: қажетті жүйелерге қолжетімділік және оқиғаларда қалыпты өрістер бар ма.

Уақытты "қадам бойынша" есептеу ыңғайлы. Процесті 6–10 әрекетке бөліп, әрқайсысының қолмен қанша минут алатынын және автоматтандырудан кейін қанша қалатынын жазыңыз. Көбінесе SOAR барлығын алмастырмаса да, күту мен жүйелер арасында ауысуды алып тастайды — бұл жалпы алғанда ондаған минут береді.

Жауапкершіліктің шекарасын алдын ала бекітіңіз. Мысалы: артефакт жинау және бастапқы тексеру автоматты, ал есепшотты блоктау немесе хостты изоляциялау — аналитик растайтыннан кейін (немесе алдын ала анықталған активтерге қатты шарттармен) ғана.

"Плейбук бар, бірақ ол ештеңе істемейді" жағдайын болдырмау үшін интеграциялар мен құқықтарды тексеріңіз: пошта (Exchange/Office 365), EDR, AD/LDAP, тикет-жүйе және хабарландыру арналары. Таралған инфрақұрылымда құқықтар мен жауапкершілікті алдын ала келісу өте маңызды: SOAR әрекеттерін кім бекітеді және автоматтандыру маңызды қызметті тоқтатса кім жауап береді.

Плейбук 1: фишинг және зиянды хаттар

Фишинг автоматтандырудан тез нәтиже береді: оқиғалар қайталанады, деректер типтік, жылдамдық шынымен зиянды төмендетеді. Бұл реагирация үшін SOAR-дың алғашқы плейбуктерінің бірі — рутина қысқарады және хатты басқа да адамдар ашып алу ықтималдығы азаяды.

Плейбук бірнеше сигналдан іске қосылса жақсы: қолданушыдан түскен хабарлама (Report Phishing батырмасы немесе Service Desk тикеті), пошталық шлюзтың алерті, EDR-дан қосымша тауып алуы немесе SIEM-дағы корреляциялар (бір URL-ге көп адамнан кликтер, ұқсас хаттар).

Келесі міндет — фактілерді жедел жинау, бірақ қате жаппай блоктауларға жол бермеу. Типтік автоматты сценарий:

• хаттан URL, домендер, қосымшалардың хэштары, жіберуші адресі, тақырып және Message-ID алу;
• URL мен файлдардың беделін тексеру, ішкі IOC-пен салыстыру;
• егер саясат рұқсат етсе, қосымшаны немесе сілтемені пісіргішке (песочница) жіберіп, вердикт сақтау;
• жіберуші, тақырып, хэштер, URL бойынша ұқсас хаттарды табу;
• әрекеттер дайындау: жіберушіні блоктау, қабылдаушылардан хаттарды жою, IOC-тарды қорғаныс жүйелеріне қосу.

Жиі қолмен шешімді сақтауға тұратын жерлер: басшылар мен критикалық бөлімшелердегі хаттарды жою (заңды хатты жоюдан сақтану үшін), сондай‑ақ домендер мен URL-дарды жаппай блоктау, бұл бизнес-процестерге әсер етуі мүмкін. Мұндай жерлерде плейбук әрекетке ұсыныс жасап, аналитиктен растама сұрағаны ыңғайлы.

Фишингті жабуды жай ғана "тексерілген" деп жазудан гөрі нақты нәтижемен бекітіңіз. Мысалы: барлық табылған қабылдаушылардан хат өшірілді, жіберуші мен IOC-тар қорғаныс контурларына қосылды, әсерленген пайдаланушылардың тізімі расталды, алғашқы тексеру нәтижелері инцидентке тіркелді.

Плейбук 2: есепшот компрометациясына күдік

Есепшоттың бұзылуы көбіне бір жұқтырылған ПК-дан ауыр соққы береді: шабуылшы почтаға, құжаттарға және ішкі жүйелерге кіре алады және "қызметкер ретінде" әрекет ете алады. Сондықтан бұл плейбук SOAR-дан айтарлықтай әсер береді.

Типтік триггерлер: әдеттен тыс елден немесе ASN-нан кіру, "мүмкін емес қозғалыс" (сызықтар арасында қысқа уақытта географиялық ауысулар), бірнеше сәтсіз кірулер, жұмыс уақытынан тыс кіру, парольдермен сәйкестік (утіктелген деректермен), мінез-құлқтың кенет өзгеруі.

Блоктаудан бұрын плейбук не тексереді

Мұнда автоматтандыру мақсаты — 1–3 минут ішінде контекст жинап, қауіпсіз шешім қабылдау; бәрін дереу тоқтату емес.

Жақсы тәртіп әдетте мынадай:

• пайдаланушы профилін жинау: рөлі, бөлімшесі, критикалығы, рұқсат түрі (админ немесе әдеттегі);
• соңғы кірулер мен белсенді сессияларды тексеру: қайдан, қандай құрылғылардан, қандай қосымшаларда;
• құрылғылар мен жаңалық белгілерін салыстыру: жаңа браузер немесе агент, жаңа IP, SIM өзгеруі, күдік тудыратын форвардинг ережелері;
• соңғы өзгерістерді табу: пароль қалпына келтіру, MFA өзгерістері, топтарға қосылу, форвардинг ережелерінің қосылуы;
• тәуекел бағасын беру және тармақ таңдау: "әрекет қажет", "тексеру керек", "жалған срабатывание".

Қажетсіз тоқтап қалмай әрекеттер мен хабарламалар

Егер тәуекел жоғары болса, плейбук бақылаулы қадамдар жасайды: есепшотты уақытша блоктау, парольді қайта орнату, сессиялардан шығару, MFA-ны қосу немесе күшейту, егер кіру нақты құрылғыдан болса — сол құрылғыға арналған тапсырма құру.

Параллель хабарламалар жіберіледі: есепшот иесіне (қарапайым тілмен әрі не істеу керек екенін), ИБ және ИТ-ға, қажет болса бөлімше басшысына. Жұмысты тоқтатпау үшін «жұмсақ» тармақты қарастырған жөн: уақытша шектеулі рұқсат (мысалы, тек корпоративтік желі және тек қажетті қосымшалар). Критикалық рөлдер үшін эксклюзияларды және шарттарды алдын‑ала келісу маңызды.

Осы плейбуктің негізгі сапа көрсеткіші — сигналдан сенімді тармаққа өту жылдамдығы (компрометация расталды немесе дабыл түсірілді) жаппай блоктаулар мен коммуникациялардағы хаоссыз.

Плейбук 3: хостты изоляциялау және алғашқы деректер жинау

Хостты изоляциялау — SOAR-дағы ең күшті, бірақ бизнес үшін ең қауіпті қадамдардың бірі. Оны автоматтандыру қажет болғанда ғана қосу керек: шифрлаушы белгілері, C2 байланысы, күдікті процестердің көбейуі, желілік ресурстарға жаппай қолжеткізу әрекеттері сияқты жағдайларда кешігу зияндырақ болады.

"Қатты" қимылдан аулақ болу үшін плейбук сигналды қысқа тексеріп, желіні үзуге дейін ең негізгі артефактілерді жинауы тиіс. Бұл маңызды: изоляциядан кейін кейбір деректер қолжетімсіз болуы мүмкін, пайдаланушы ПК-ны қайта жүктеуі ықтимал.

Минималды қауіпсіз сценарий

Практикада бес қадамнан тұратын реттілік жақсы жұмыс істейді:

• сигналды растау: хостты, пайдаланушыны, уақытты, алерт көзін, қайталанушылықты салыстыру;
• базалық артефактілерді жинау: процестер тізімі, белсенді желілік қосылыстар, соңғы іске қосулар, маңызды кіру оқиғалары;
• нені күдікті деп белгілегенін тіркеу: файл жолдары, хэштәр, parent процесс аты, командалық жол;
• EDR арқылы изоляцияны орындау (немесе балама түрде — желілік профильді өшіру, порттарды блоктау, таралуға тыйым салу);
• инцидент ашу және жауапты тұлғаларды хабардар ету: SOC, ИТ, сервис иесі (тоқтау басқарыла алатындай болу үшін).

Параллель плейбук процестер мен қосылыстардың қабылдамасын сақтай алады, күдікті файлдардың хэштәрін шығарып, изоляцияға дейін хосттың байланысқан құрылғыларын белгілей алады. Бұл тергеуді құралдар арасында жүгіріп жүріп жинаудың орнына бастапқы материал береді.

Хостты қайта қолдануға қалай қайтару керек

Деизоляцияны пайдаланушы сұрағанына қарай емес, критерийлер бойынша орындау жақсы: зиянды файл жойылды немесе карантинге алынды, себеп жабылды (мысалы, пароль өзгертіліп, сессиялар қайтарылды), белгіленген уақыт ішінде қайталанулар жоқ, ИТ және сервис иесінің келісімі бар.

Мысалы: бухгалтердің жұмыс станциясында EDR күдікті процесті және сыртқы узелдерге сұрауларды тіркеді. Плейбук процестер мен желілік қосылыстардың қабылдамасын жинап, хостты изоляциялады, сосын ИТ‑ға уақытша алмастыру жұмыс орнын беру тапсырмасын автоматты түрде жасады. Қауіпсіздік уақыт сатып алады, ал бизнес не болатынын және қашан қалпына келетінін біледі.

Плейбукты жинау: енгізуге арналған қадамдық тәсіл

SOAR шынымен SOC жұмысты жылдамдатуы үшін плейбук адамдарға да, машинаға да бірдей түсінікті болуы керек. Көбіне плейбук "қалай болғаны жақсы" дегенді сипаттайды, бірақ кірістер, шешімдер және нәтиже нақты көрсетілмеген. Нәтижесінде оны автоматтандыру және бақылау қиын болады.

Біртұтас шаблоннан бастаңыз. Әдетте жеткілікті нәрселерді көрсетіңіз: инцидент қайдан келеді (SIEM, пошта, EDR), қай өрістер міндетті (пайдаланушы, хост, хэш, тикет), қандай қадамдар орындалады, қай жерде шешім керек (шарттар) және сценарий қалай аяқталады (жабу, эскалация, растаманы күту).

Содан кейін плейбукты қайта қолдануға болатын модульдерге бөліңіз:

• обогащение: домен/хэш беделі, AD/CMDB‑ден контекст, алертер тарихы;
• шешім: ережелер, шекті мәндер, исключения, тәуекелге қарай "егер/онда" логикасы;
• әрекеттер: блоктау, парольді қайта орнату, хостты изоляциялау, хатты карантинге жіберу;
• хабарламалар: кімге не жіберілуі керек және қалай тикетте тіркеледі.

Автоматтандыруның бизнесті зиянға ұшыратпауы үшін бақылау нүктелерін қосыңыз. Мысалы, сервер изоляциясы тек дежурныйдың бекітуінен және сервис критичтігін тексеруден кейін ғана мүмкін болсын; VIP‑аккаунттарға парольды қалпына келтіру сервис иесінің растауын талап етсін.

Cortex XSOAR, Splunk SOAR және IBM Resilient арасындағы айырмашылықтар көбіне интеграциялар мен тапсырма формасында болады. Плейбук логикасы жалпы болуы керек: бірдей кірістер, шарттар және нәтижелер. Сондықтан алдымен платформадан тәуелсіз түрде плейбук сипаттаңыз, сосын нақты конструкторға ауыстырыңыз.

Енгізуді кезең-кезеңімен жасаңыз: бір тип инцидент пен шектелген контурда пилот, кейін көбірек көздер мен бөлімшелерге кеңейту. Егер ұйымда интеграциялар, approvals және тәуліктік қолдау маңызды болса, жүйелік интегратор бұл мәселені шешуге көмектеседі, сонда плейбуктар күндіз де, түнде де тұрақты жұмыс істейді.

Жауап беру уақытын қалай өлшеу

SOAR-дың пайдасын дәлелдеу үшін "реагирования уақыты" дегеннің нені білдіретінін алдын ала келісіңіз. Көбіне анықтау, қабылдау және нақты шешім кезеңдерін араластырып жібереді. Егер осы кезеңдерді бөліп алмасаңыз, көрсеткіштер SOC пен басшылыққа пайдалы болмайды.

MTTD (Mean Time To Detect) — оқиға басталғаннан оны анықтағанға дейінгі орташа уақыт.

MTTA (Mean Time To Acknowledge) — детекттен инцидент жұмысқа алынғанға дейін өткен уақыт (тағайындау немесе растау).

MTTR (Mean Time To Respond/Resolve) — детекттен (немесе қабылдаудан) шешімге дейін: жою, блоктау, изоляция, кейсті жабу.

Бір бастапқы нүктені таңдап, әрқашан сол бойынша тіркеңіз.

Метрикаларды есептеу үшін бір жерде айқын таймстемптер болуы керек (SIEM, SOAR немесе тикетинг). Міндетті тізбек:

• детект (alert жасалды);
• кейс/инцидент SOAR-да ашылды;
• аналитикке тағайындау (немесе авто- тағайындау);
• бірінші әрекет (мысалы, артефакт сұрау, блоктау, изоляция);
• жабу/резолюция.

Автоматтандыруға дейін базалық желіні жинаңыз: сол көздер мен бірдей уақыт есептеу ережелері бойынша 2–4 апталық статистика. Осылай нақты әсерді көресіз, ал маусымдық өзгерістер шатастырмайды.

Дұрыс салыстырыңыз: бірдей типтағы инциденттер мен бірдей ауырлықтағыларды салыстырыңыз. Мысалы, "фишинг с вложением" пен "фишинг со ссылкой" бөлек, админнің компрометациясы мен әдеттегі пайдаланушының компрометациясы бөлек болуы керек. Әйтпесе жеңіл кейстер автоматтандыруы MTTR‑дың күрт төмендегендей көрінуге әкелуі мүмкін.

Жылдамдық сапаны нашарлатпауы керек. Қосымша бақылау көрсеткіштерін қосыңыз:

• жалған блоктаулардың үлесі (пошта, есепшоттар, хосттар);
• қайта ашылған кейстердің пайызы;
• қолмен қайтаруды қажет еткен кейстердің пайызы;
• критикалық инциденттер бойынша SLA сақтау.

Осылайша сіз тек жеделдікті емес, плейбуктардың шынымен көмектесіп жатқанын көрсетесіз.

SOC пен бизнес үшін түсінікті есептер мен KPI

SOAR автоматтандыруды жай ғана автоматтандыру деп көрсетпеу үшін алдын ала қандай сандар SOC‑қа және басшылыққа көрсетілетінін келісіңіз. Жақсы есеп екі сұраққа жауап береді: не үдетілді және оны күнделікті қаншалықты сенімді орындаймыз.

Плейбук кезеңдері бойынша KPI

Жалпы MTTA/MTTR‑дан бөлек, қадамдар бойынша уақытты өлшеу пайдалы. Қай жерде минуттар жоғалайтынын бірден көруге болады: контекст іздеуде, келісімдерде, қолмен тексерулерде.

Әдетте төрт блоктың ұзақтығын тіркеу жеткілікті:

• обогащение: контекст жинау (пайдаланушы, хост, қосымшалар, бедел, соңғы кірулер);
• шешім: тексеру мен әрекет таңдау уақыты (жалған деп жабу, эскалация, блоктау);
• әрекет: әрекетті орындау ұзақтығы (изоляция, парольді қалпына келтіру, домен блоктау, тикет жасау);
• коммуникация: хабарламалар, растама сұрау, инициаторға есеп беру.

Надежность көрсеткіштерін қосыңыз, әйтпесе "жылдамдық" бірегей сәтті іске қосылым болуы мүмкін. Байқаңыз: іске қосу табыстылығының пайызы, қайтарулардың үлесі (деизоляция немесе блоктауды алып тастау), қолмен араласу пайызы (плейбук басталып, аналитик жартысы қадамдарды аяқтады).

SLA мен ішкі мақсаттарды инцидент түрлері бойынша бөліңіз. Фишинг үшін бастапқы вердикт пен таралуды тоқтату маңызды. Есепшоттар үшін — парольді мәжбүрлеп өзгерту және белсенді сессияларды өшіру уақыты. Хост үшін — изоляцияға дейінгі және алғашқы артефактілер жинау уақыты.

Басшылыққа арналған есеп

Басшылыққа әдетте 3–5 көрсеткіш жеткілікті: MTTA медианасы, MTTR медианасы, MTTR‑дың 90‑шы перцентилі (ауыр жағдайларды көрсету үшін), іске қосылымдардың табыстылығы, эскалациясыз жабылған инциденттердің үлесі.

Әсерді "бұрын және кейін" медианалар мен 90‑шы перцентиль бойынша көрсету маңызды, орташа мән кейбір ауыр кейстермен бұрмалануы мүмкін.

SOAR автоматтандырудағы жиі қателіктер

SOAR-пен проблемалар көбіне платформада емес, процестің сипатталуында жатыр. "Бірнеше батырма істесек, SOC екі есе жылдам болады" деген көзқарас көбінесе ақауларға, даулы блоктауларға және қолмен айналып өтуге әкеледі.

Ең зиянды қателіктер

Плейбуктар командаға жалықтырып, автоматтандыруға сенім жоғалтуына әкеп соғатын ең типтік себептер:

• келісімдердің болмауы: плейбук өздігінен есепшотты блоктап немесе хостты изоляциялап қояды, ал сервис иесі пайдаланушылардан біліп қалады;
• тым кең плейбук: барлық фишинг немесе барлық компрометация түрлерін бір процесспен жабуға тырысу көптеген тармақтар мен исключенияға әкеледі;
• кіріс деректердің нашарлығы: алертте анық пайдаланушы, хост, хат немесе SIEM инциденті көрсетілмесе, SOAR оқиғаны обогащение ете алмайды;
• исключенияларды елемеу: сервис аккаунттар, критикалық серверлер, VIP‑пайдаланушылар, терминалдық фермалар бөлек ережелерді талап етеді;
• қайтару жоспарының болмауы: қате изоляция немесе есепшотты блоктау тез әрі айқын қайтаруды қажет етеді.

Жақсы ереже: алдымен қауіпсіз қадамдарды автоматтандырыңыз (деректер жинау, обогащение, тапсырма қою), тәуекелді қадамдарды сенімділік деңгейі жоғары болғанда және анық "тежегішпен" қосыңыз.

Плейбуктарды іске қосар алдында қысқа чеклист

Алғашқы автоматтандыруларды қосар алдында базалық заттарды тексеріңіз, әйтпесе қате блоктаулар, артық изоляция және жауапкершілік шатасуы пайда болуы мүмкін.

Әр қадамның иесі болуы керек, әр кіріс өрістің көзі көрсетілген, әр тәуекелді әрекеттің айқын стоп‑кран болуы тиіс.

• процестерге иелер мен дежурлық ролдер тағайындалған: кім әрекеттерді растайды, кім ИБ/ИТ-пен сөйлеседі, кім кейсті жабады; егер SOC сырттан болса, шекаралар алдын ала бекітілген;
• триггерлер мен міндетті кіріс деректері анықталған: кейсті не іске қосады (хат, EDR алерті, кіру аномалиясы), қандай өрістер міндетті (акаунт, хост, уақыт, көз, критичность);
• тәуекелді қадамдарға approvals орнатылған: есепшотты блоктау, сессияларды қайтару, хостты изоляциялау, хатты карантинге алу;
• хабарламалар мен коммуникация үлгілері дайын: пайдаланушыға қысқа мәтін, ИТ‑қа хабар, басшыға жазба;
• метрикалар мен дашбордтар келісілген: MTTA және MTTR плюс орындау сапасы (қолмен араласу үлесі, блоктауларды қайтару пайызы, жалған оң көрсеткіштер).

Чеклистті бір типтік сценарийде тексеріңіз. Мысалы: қызметкер фишинг туралы шағымданды, плейбук IOC-тар бойынша сәйкестіктер тауып, қабылдаушылардан хатты алу мен жіберушіні уақытша блоктауды ұсынады. Егер алдын ала кім блоктауды растайтыны және себебі қайда тіркелетіні шешілген болса, іске қосу тыныш өтеді және нақты уақыт үнемдейді.

Егер сізде көптеген филиалдар мен әртүрлі деңгейдегі ИТ бар болса, SOC қай әрекеттерді орталықтан орындайтыны және қайсысы жергілікті қолдауға жіберілетінін алдын ала анықтаңыз. Бұл MTTR‑ға платформалар арасындағы таңдаудан гөрі көп әсер етеді.

Мысал сценарий: фишинг пен есепшотты басып алуға әрекет

Қызметкерге "Жедел: парольді жаңартыңыз" сияқты тақырыппен хат келеді және қосымша тіркелген. 15 минуттан кейін SIEM оның есепшотына жаңа аймақ пен жаңа құрылғыдан кіруді тіркейді. Бұл — жеке қарағанда елеусіз көрінетін екі сигнал бірігіп тез әрекет етуді талап ететін типтік жағдай.

Плейбук хаттан немесе аномалды кіруден іске қосылып, оқиғаларды бір инцидентке біріктіреді. Содан кейін обогащение жасайды: хат тақырыптарын, домен беделін және қосымша хэштарын шығарады, хат кімдерге жеткенін тексереді, есепшоттың картасына пайдаланушы туралы деректерді қосады (топ, критичность, соңғы кірістер, белсенді сессиялар).

Әрекеттер әдетте үш деңгейге бөлінеді:

• автоматты түрде: ұқсас хаттарды іздеу, пошталық шлюзта домен/хэш блоктау, артефактілер жинау (IP, user-agent, message-id), SOC пен сервис иесіне хабарлама;
• аналитик растамасыннан кейін: парольді қайта орнату, токендер/сессияларды қайтару, есепшотты уақытша блоктау, мәжбүрлі MFA тексерісін іске қосу;
• жауаптылар шешімімен: пайдаланушының басшысын немесе ИБ қызметін хабардар ету, егер есепшотқа артықшылықтар берілген болса.

Уақыт есептері бойынша обогащение және есепшот картасын жинау бұрын 10–20 минутты алатын болса, қазір бұл 1–2 минутта автоматты түрде жасалады. Шешім аналитикке дайын «дәлел пакеті» береді — іздеуге уақыт кетірілмейді, растамаға уақыт бөлінеді.

Кейс себеп тіркеліп, басқа күдікті сессиялар жоқтығы тексерілген соң жабылады. Плейбукты жетілдіруде корреляция белгілері (география + невозможное уақыт), пайдаланушыға хабарламалар үлгілері және автоматты блоктау/растама ережелері қосылады.

Келесі қадамдар: қалай бастау және кімге тапсыру

SOAR-ды жылдам енгізу платформаны таңдау емес, алғашқы үш плейбукты таңдап, соларға интеграциялар, құқықтар мен метрикаларды тексеру арқылы жүзеге асады. Осылай қай жерде уақыт үнемделетінін және қай жерде процесс кедергі болатынын бірден көруге болады.

Оңай инвентарь жасаңыз: соңғы 1–3 айдағы ең жиі 10–20 инцидентті (тикеттер, SIEM, пошта, SOC) жазып шығыңыз. Содан топ‑3 таңдаңыз: апталық қайталанатын, көп қолмен қадамдарды қажет ететін және шаршаудан қателесуге орын беретіндер (мысалы, фишинг, есепшот компроментациясы, хостты изоляция).

Келесі — жүйелер арасындағы " тігістер" мәселесін шешетіндерді анықтаңыз. SOAR әдетте интеграциялар мен құқықтарға тіреледі: кім API‑кілттер береді, кім пайдаланушыны блоктауға құқылы, EDR‑да қандай әрекеттер бекітіледі.

Плейбуктар жұмыс істемесе болмайтын рөлдер

Көп жағдайда төрт иесі жеткілікті, тіпті команда шағын болса да:

• SOC аналитигі (плейбук логикасы мен триггер критерийлерінің иесі);
• ИБ инженері немесе админ (интеграциялар, құқықтар және қауіпсіз баптаулардың иесі);
• сервис иесі (Exchange, AD, EDR сияқты жүйелер бойынша келісім);
• SOC/ИБ басшысы (қауіпті қалай басқаруға болатынын бекітеді: не автоматты түрде, не растамадан кейін орындалатыны).

Пилотты бір бөлімше немесе бір актив түрінде іске қосу жақсы: мысалы, корпоративті пошта үшін фишингті автоматтандыруды бірінші қадамға алып, хост изоляциясын бастапқыда қолмен растауды талап ету.

Егер интеграциялар және түпкілікті қолдау маңызды болса, жүйелік интегратормен бірге жұмыс жасау ыңғайлы. Мысалы, GSE.kz (gse.kz) жабдық жеткізу мен өндірістен бөлек жүйелік интегратор болып, ИБ пен ИТ арасындағы сквозной процесті құруға көмектесе алады, сонда плейбуктар құқықтар мен жауапкершілікке тірелмейді.

Алдын ала метрикалар мен есеп туралы келісіңіз: нақты қай MTTA/MTTR есептеледі, қай бастапқы нүктеден және қаншалықты жиі нәтижені көрсетесіз (мысалы, SOC үшін аптасына, басшылық үшін айына бір рет).