Өндірістік желідегі ИБ-инциденттерді есепке алу: қандай өрістер керек

Мақсат: инцидентті нақты OT-контекстке байланыстыру

Өндірістік желідегі ИБ-инциденттерді есепке алу кеңсе-желіден өзгеше: мақсат — жай қатерді жою емес, өндірістің қауіпсіз әрі үздіксіз жұмысын сақтау. Бір индикатор (мысалы, күдікті желілік сұраныс) IT-де «оқшаула және қайта орнат» дегенді білдіруі мүмкін, ал OT-де — «қазір қол тимайық, әйтпесе линияны тоқтатамыз» дегенді білдіруі мүмкін.

Егер инцидент нақты OT-активке және зонаға байланбаса, тергеу тез тұралайды. Команда журналдағы оқиғаларды көреді, бірақ бұл түйіннің не екенін түсінбейді: инженерлік жұмыс орны ма, HMI ме, тарихи деректер сервері ме, контроллер ме, әлде мердігердің тест ноутбугі ме? Зонасыз да түсініксіз: бір нәрсе ячейка ішіндегі трафик пе, әлде IT пен OT арасындағы шекараны кесіп өткен бе.

Бұдан басқа, кей деректерді ашық жазуға болмайды, әсіресе журнал кең тобына қолжетімді болғанда. Әдетте жалпы бөлімде келесілер жазылмайды:

• сегментация схемасын ашатын нақты IP-адрестер мен хост атаулары
• логиндер, жеке деректер және қызметкерлердің есімдері
• технологиялық процестің детальдары (рецепттер, параметрлер, қондырғылардың атаулары)
• конфигурациялардың толық дамптары мен контроллер жобаларының негізгі файлдары

Сондықтан инцидент картасының біртұтас форматы қажет: OT-мағынасы бар, бірақ артық нақтылықсыз. Ол бірнеше рөлдерге керек: ауысым персоналына (процеске тәуекелді түсіну үшін), ИБ-ке (тергеу жүргізу үшін), АСУ ТП инженерлеріне (жабдыққа әсерді бағалау үшін) және басшылыққа (статус пен салдарды көру үшін). Интеграторлар мен инфрақұрылым жеткізушілер қатысатын жобаларда (мысалы, серверлер мен жұмыс орындарын орналастыруда, GSE.kz сияқты) бір формат командалар арасындағы шатасуды азайтады: барлығы бірдей өрістер бойынша сөйлеседі.

Қарапайым мысал: SOC SMB арқылы күдікті кіруді байқайды. Егер картада бірден көрсетілсе: «инженерлік станция, зона: OT-DMZ, критикалдық: жоғары, рұқсат етілетін әрекет: тек брандмауэрде блоктау», команда түйінді сілтеп өшіріп, учаскіні тоқтатудың тәуекелін алмайды.

Журнал жүргізіп, құпиялылықты қалай бұзбау керек

OT-инциденттер журналы — жылдам әрекет ету және тиімді шешімдерді қайталау үшін керек, барлығын жинау үшін емес. Практикалық ереже: шешім қабылдау, реагирлеуді орындау және оның орындалғанын растау үшін міндетті емес нәрселерді жазбаңыз.

Картада қолжетімділік деңгейіне қарай бөлімдерге бөлу жақсы жұмыс істейді:

• Жалпы бөлік: көпшілік қатысушыларға керек мәліметтер (қысқаша сипаттама, уақыт, статус, категория, зақымданған зона және идентификатор түрінде актив).
• Шектеулі бөлік: тергеуге көмектесетін, бірақ желінің құрылымын немесе жеке деректерді аша алатын детальдар.
• Құпия бөлік: шикі артефактілер мен «толық дәлдік» (трафик дамптары, конфигурациялар, нақты хост атаулары) — бөлек қорғалған қоймада, қолжетімділік сұраныс бойынша.

Артық жазбау үшін атаулар мен адрестердің орнына псевдонимдер қолданыңыз: Asset ID, Site ID, Zone ID, Case ID. Қай Asset ID-нің нақты қай станция екенін, қай жерде тұрғанын, IP қандай екенін бөлек және қолжетімділік бақылаусымен сақтаңыз.

Әдетте мына бірнеше қарапайым тәжірибе көп әсер береді:

• Рөлдік қолжетімділік: SOC жалпы бөлікті көреді, OT-инженер — техникалық детальдарды, басшы — қорытынды мен тәуекелдерді.
• Өзгерістерді журналдау: кім және қашан өрістерді өзгертті, не өзгерді, не үшін.
• Деректерді маскілеу: ФИО орнына рөл («ауыспалы электрші»), толық IP орнына подсеть немесе хеш.
• Қосымшаларды бақылау: файлдар мен скриншоттар қажет ретінде ғана, қолжетімділік деңгейімен белгіленіп сақталсын.
• Пікір үлгілері: адамдар конфигурациялар мен парольдерді еркін мәтінге жазбас үшін шаблондар.

Мысал: инженерлік станцияның ықтимал компрометациясы кезінде жазасыз: «Asset ID: ENG-042, Zone ID: OT-ENG, белгі: белгісіз процесс іске қосылды, әсер: тоқтау жоқ». Толық пайдаланушы аты, хост атауы және файл жолы жабық бөлікте қалады және түйінмен жұмыс істейтін мамандарға ғана беріледі.

Сақтау мерзімдерін деректер түрі мен тәуекелге қарай белгілеңіз. Метадеректер әдетте аналитика үшін ұзақ сақталады, ал шикі артефактілер (пакеттер, дамптар, жеке деректер бар логтар) қысқа уақыт сақталып, автоматты жоюға қойылсын — журнал сезімтал деректер қоймасына айналмасын.

Инцидент картасының негізгі өрістері: әрдайым не жазу керек

Карта барлық жағдайға бірдей болуы керек. Өрістер қазіргідей қарапайым және тұрақты болған сайын оқиғалар арасында байланысты табу, ұқсас эпизодтарды салыстыру және формулировкаларға келіспеу оңайырақ.

1) Оқиғаны идентификациялау. Бірегей идентификатор (Incident ID) және тіркеу көзі: кім жазды және сигнал қайдан келді (ауыспалы инженер, мониторинг, мердігер). Бұл кіріс ақпараттың сенімділігін бағалауға және командалар арасындағы тасымалдау кезінде ақпаратты жоғалтпауға көмектеседі.

2) Уақыт. OT-де уақыт өте маңызды: ауысымдар, технологиялық терезелер мен жоспарлы жұмыстар бар. Төрт уақыт белгілерін бөлу ыңғайлы: қашан байқалды, қашан басталған болуы мүмкін, қашан расталды, қашан аяқталды. Әрқашан уақыт белдеуін көрсетіңіз.

3) Классификация. Түсінікті класс жеткілікті: зиянды бағдарлама, рұқсат етілмеген кіру әрекеті, саясаты бұзу, ақау немесе аномалия. Бұл таңдау кімді қосуға және қандай процедураларды іске қосуға әсер етеді.

4) Критикалдық. Шкала бойынша белгілеңіз (төмен/орта/жоғары) және ықпал критерийін қысқаша жазыңыз: «технологиялық сегменттің қолжетімділігіне әсері», «өндірісті үздіксіздігіне қауіп», «есептік жазбалар зақымданған». Жалпы бөлімде нақты осалдықтарды, адрестерді немесе жабдық модельдерін жазбаңыз.

5) Қысқа сипаттама. Бейтарап және тексерілетін: не байқалған және қай жерде, айыптаулар мен факт ретінде ұсынылған болжамдар болмауы керек.

Сипаттама мәтіні үшін ыңғайлы ереже:

• тек бақылауға алынған белгілер
• орын — жалпы терминдермен (учаскe, зона, жүйе рөлі)
• статус (расталған немесе тексеруді қажет етеді)
• масштаб (бір түйін, топ, белгісіз)
• келесі қадам және жауапты

Мысал: «Инженерлік контурға нетиптік есептік жазбадан кіруге әрекет байқалды. Растау күтілуде. Технологиялық процестерге әсер анықталған жоқ. Тексеру үшін ИБ мен ауысым инженері жауапты етіп тағайындалды».

OT-активке байлау үшін өрістер

OT-де инцидент абстрактілі «бірнәрсе болды» дегенге айналмауы үшін карта оқиға қай активке қатысты екенін біржақты көрсетуі керек. Сол кезде журнал персонал мен техникалық детальдардың қоймасы болмауы тиіс.

Міндетті идентификаторлар жиынтығы

Ішкі кодтар мен активтің өндірістегі рөлін негізге алыңыз. Бұл инцидентті нақты контекстпен байланыстырып, құпиялылықты сақтауға көмектеседі.

• Asset ID (ішкі): CMDB/реестрдегі идентификатор, серия нөмірін ашпайды.
• Актив түрі: PLC, HMI, инженерлік станция, сервер, шлюз, коммутатор (справочниктан алу ұсынылады).
• Процестегі рөлі: басқару, визуализация, архив/историк, техникалық қызмет, межсалалық алмасу.
• Иесіне және рөлдік жауапты: мысалы «АСУ ТП цехы 3», «ауыспалы инженер» (ФИО-сыз).
• Активтің критикалығы: қауіпсіздік, сапа, тоқтау ықпалы (мысалы 1–4 шкала немесе S/Q/D).

Бұл өрістер әдетте «ыстық» активтер бойынша есеп жүргізуге жеткілікті, артық мәліметсіз.

Техникалық деректер — артық нақтылықсыз

Техникалық атрибуттар тергеуге пайдалы, бірақ жалпы бөлімде оларды диапазондар немесе кластар түрінде сақтау жақсы. Мысалы: ОС отбасы және версия класы («Windows 10 LTSC, версия 20xx»), ПЛК прошивкасы класы («v3.x»), модель тобы («S200 сериясы»). Нақты жинақ нөмірлері, сериялар, MAC және толық конфигурациялар — қолжетімділік шектеулі жабық қосымшаларда.

Мысал: инженерлік станцияда утилита іске қосылғанын ескерту шықты. Картаның жалпы бөлігінде Asset ID, тип «инженерлік станция», рөл «ПЛК қызметі», критикалдық «жоғары» және иесі «АСУ ТП қызметі» көрсетіледі. Бұл жеткілікті, сонда команда дұрыс маманды тағайындайды, ПО нұсқалары мен сериялық нөмірлерін жарияламай-ақ.

Желілік зонаға және сегментацияға байлау өрістері

Желілік зона мен сегмент шекарасына байланыс проблеманың қайда пайда болғанын, қайда таралуы мүмкін екенін және қай бақылау нүктелерін тексеру керегін көрсетеді.

Зона үшін минималды өрістер

«Ауыспалы атаулар» емес, анық кодтар мен справочниктерден бастау ұсынылады.

• Zone ID және зона атауы: мысалы «OT-Z03, розлив учаскісі, ячейка 2».
• ISA-95/IEC 62443 бойынша зона класы: деңгей (L2/L3) немесе зона түрі (Control Zone, DMZ және т.б.).
• Зақымдалған сегменттер (кодтар): VLAN-идент., подсетьтер, контурлар — «VLAN-120, NET-10.20.30.0/24» түрінде.
• Зоналар арасындағы қиылыстар (ID арқылы): FW-07, GW-03, JS-02 сияқты бақылау нүктелері.
• Байланыс бағыты және типі: зона ішінде, зоналар арасында, DMZ; «инициатор -> алушы», қосымша протокол атауы (мысалы RDP, SMB) — толық дампсыз.

Шекараны қалай жазуға болады, артық ақпарат бермей

«Карталарда не жазатынын» және «дәлелдемелер қайда орналасатынын» бөліңіз. Картта сегмент кодтары мен бақылау нүктелері ғана қалсын. Толық IP, хост атаулары, FW ережелері мен нақты лог-строкалар — рөлге сай сақталсын.

Мысал: инженерлік станцияда күдікті кіру байқалды. Картада OT-Z03, зақымданған VLAN-120 және DMZ-VLAN-10, қиылыс JS-02 пен FW-07, бағыт DMZ -> OT көрсетіледі. Қай журналдарды сұрату керегі анықталған.

Дәлелдер мен бақылаулар: артық детальсыз қалай жазу керек

OT-де бақылауларды тексерілетін және контекстке бай етіп жазу керек, бірақ журналда жеке деректер мен технологиялық детальдарды шашпау керек.

Ашық бөлімде не жазу керек

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

Көбіне бес пункт жеткілікті:

• сигнал көзі және уақыт (бірдей уақыт белдеуінде)
• бақылау мәні (не "қате")
• сенімділік (расталды / мүмкін / тексеруді қажет етеді)
• әсер (тоқтау, сапа, қауіпсіздік) және критикалдық деңгей
• болжамды вектор (USB, қашықты қосу, мердігер, т.б.)

Қандай нәрселер жабық өрістерге көшуі тиіс

Артефактілерді дәл түрде сақтаңыз, бірақ қоғамға ашпаңыз: файл хештері, толық аттар мен жолдар, IP және MAC, нақты есептік жазбалар, сериялық нөмірлер, инженерлік жоба атаулары — бәрі жабық бөлімде. Жалпы бөлімде «учетка-3», «хост-7» сияқты псевдонимдер мен ішкі артефакт номері қалсын.

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

Реагирлеу шаралары мен әрекеттерді басқару өрістері

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

Статус пен жұмыс барысы

Статустар бірізді және қарапайым болсын: жаңа, жұмыс барысында, сдержан, жойылған, жабылған, кейінге қалдырылды. Қай уақытта және қысқа себеп жазу пайдалы — кешігулерді талдауға көмектеседі.

«Әрекеттер» блогы

Әр әрекет — жеке жол, нәтижесі көрсетіледі. Өнеркәсіптік желіде типтік шаралар қайталанып отырады: түйінді оқшаулау, есептік жазбаны блоктау, брандмауэр ережесін өзгерту, қашықтан қолжетімділікті өшіру, конфигурацияны қалпына келтіру.

Әр шара үшін минималды өрістер:

• шара түрі (оқшаулау, блоктау, ережені өзгерту, қалпына келтіру)
• объект (актив ID, есептік жазба ID, ереже ID)
• басталу және аяқталу уақыты
• орындаушы (рөл/команда) және мақұлдау (рөл) + уақыт
• нәтиже (сәтті, жартылай, кері қайтарылды) және қысқа түсініктеме

OT-де міндетті түрде «шарадан келетін тәуекел» өрісін қосыңыз: дәл қазір не тоқтап қалуы мүмкін. Күтулі әсерді және келісілген айналып өту жолын жазыңыз («жергілікті басқару», «қосалқы арна», «норматив бойынша жұмыс»).

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

Мысал: триаж инженерлік станцияда күдікті белсенділік анықтады. Статус — «жұмыс барысында». Алғашында өндірісті тоқтатпай-ақ сдерживание: станцияның байланыстарын қажет сервиске шектеу, «дежурный инженер АСУ ТП» рөлімен мақұлдау жазылды, тәуекел — «жобаларды жаңарту кешігуі», айналып өту — «қосалқы станцияға көшіру». Тексеріп, тазалап болған соң статус «жойылды», қалпына келтіру ID-сы бекітіліп, бақылау мерзімі өткен соң жабылды.

Қарапайым тергеу процесі: триаждан жабуға дейінгі қадамдар

OT-де жылдам әрі сақтықпен тергеу маңызды. Реагирлеудегі қате технологиялық процесті тоқтатуы мүмкін, сондықтан процесс қысқа әрі бірізді болуы керек.

Көптеген OT-инциденттер үшін ортақ қадамдар

1. Триаж және иесі. Бұл инцидент екенін растаңыз, жоспарлы жұмыс емес екенін тексеріңіз. Иесін тағайындаңыз (SOC, ИБ-дuty немесе АСУ ТП инженері) және келесі статус жаңартуының уақытын белгілеңіз.

2. Өндірісті аз күйде бұзатын сдерживание. Қауіпті төмендететін ең жұмсақ шараны таңдаңыз: қашықтан кіруді шектеу, есептік жазбаны уақытша блоктау, түйінді шектеулі VLAN-ге ауыстыру. Түйінді күшпен өшіру — тек келісіммен және егер үлкен қауіп анықталса ғана.

3. Фактілер жинау. Тіркеңіз: OT-активтің ID-сы, рөлі (инженерлік станция, PLC, HMI), зона және желі сегменті, зақымданған протоколдар, қолжетімді логтар (EDR, домен, коммутаторлар, өзгерістер журналы). Егер жеке деректер бар болса, қызметтік идентификаторларды қолданыңыз және детальдарды бөлек сақтаңыз.

4. Негізгі себепті талдау. Қай жақтан әсер келгенін, қандай есептік жазбалар пайдаланылғанын, қандай баптаулар өзгергенін және бекіту әрекеттері болған-жоғын қалпына келтіріңіз. OT-де жиі кездесетін себептер: мердігердің қашықтан қолжетімділігі, жалпы парольдар, USB арқылы тасымалдау.

5. Жою, қалпына келтіру және жабу. Себепті жойып, учасктің жұмысын тексеріп, қайталанбауы үшін бақылау орнатыңыз (сигнал, конфигурация тексеруі). Жабу кезінде қорытынды, сабақтар, тапсырмалар, мерзімдер және жауапты тұлғаларды тіркеңіз.

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

Мысал сценарий: инженерлік станцияға қатысты инцидент

АСУ ТП учаскесінде диспетчер инженерлік станциядан (ES-17) PLC-ға сұраныстар санының өскенін байқайды. Сұраныстар әдетте сол зонеде жасалады, бірақ уақыт белгісіз — кешкі уақытта, жұмыс терезесі емес. Сонымен қатар коммутаторда көрші зонаға тез уақытты қысқа байланыс әрекеттері жазылады.

Инцидент картасы дереу толтырылады, осылайша есеп ауызша келісімдерге бөлінбейді. Тек OT-контекстпен байланыстыратын ақпарат жазылады, артық нақтылық жоқ.

Минималды өрістер мысалы:

• Incident ID: OT-2026-014
• Анықтау/кезең: 21:42–22:05
• Asset ID (инженерлік станция): ES-17
• Байланысты OT-актив: PLC-3A (реестрден ID)
• Zone ID: OT-Z3 (ячейка/линия), және көрші зона OT-Z2 туралы белгі
• Критикалдық: жоғары (технологиялық үрдіске әсер қаупі)

Біріншіден ең жиі кездесетін «бейбіт» түсініктеме тексеріледі: техникалық жұмыстар болды ма. Өндірістен жұмыстың журналын және техникалық тапсырмалардан өтініштер сұралады, ИТ-ИБ-ден инженерлік станцияға соңғы кірулер тізімі сұралады. Мердігер қатысқан-жоқтығын тексереді: қызметтік терезе болды ма, қандай түрде (жергілікті/қашықтан) — бұл ақпарат картада жеке деректерсіз көрсетіледі.

Тексеру жүріп жатқанда жұмсақ сдерживание жасалады. Межзоналық трафик ережесін уақытша қатайтады: тек технологиялық алмасуға қажет қызметтер қалдырылады, конфигурация протоколдары тек бекітілген терезеде және тек ES-17-ден рұқсат етіледі. Картада әрекет, уақыт, рөл бойынша жауапты және негіз көрсетіледі.

Тергеу нәтижесі: мердігер диагностиканы орындағаны расталды, бірақ ескірген рөл профилін қолданған. Салдарынан инженерлік станция PLC-ды қате шаблонмен сұрады. Бастапқы баптаулар қалпына келтіріліп, профиль жаңартылып, конфигурация тұтастығы тексерілді.

Сабақтарды қысқа әрі әрекетке айналатындай жазған дұрыс:

• мердігердің қолжетімдігін нақты Zone ID және уақытқа байлау
• сдерживание шаблондарын плейбуктар ретінде сақтау
• жұмыстардан кейін қысқа валидация өткізу: кім неге қосылып жатқанын тексеру, артық сұраныстар жоқ па

OT-инциденттерді есепке алуда жиі жіберілетін қателіктер

Карта әдетте «артық детальдермен романға» айналады немесе бір-екі жолға түсіп қалады, әрі ол бойынша ешнәрсе қалпына келтірілмейді. Баланс керек: тергеу мен аудит үшін жеткілікті OT-контекст, бірақ сезімтал деректерді ашпау.

Жеке және техникалық деректерді бір өріске араластыру. Сипаттамада станциядағы оқиғалар, қызметкердің ФИО-сы және ауысым байланыстары бірге жазылады. Нәтижесінде картаны мердігерге, SOC не басқа цехтың әріптестеріне қауіпсіз көрсету мүмкін болмайды. Бөліңіз: жалпы техникалық бөлік және жеке деректер бар жабық бөлік.

Активтер мен зоналарға тұрақты ID болмауы. Барлығы мәтінмен жазылған кезде («ПЛК линия 3», «цех желісі») қайталанулар мен түсініспеушіліктер пайда болады. Минимум: біртұтас OT-актив идентификаторы (реестрден), зона/сегмент идентификаторы және өзгермейтін атау ережесі.

Жалпы бөлікте тым көп деталь. IP-адрестер, прошивка нұсқалары, хост атаулары, есептік жазбалар, жоба жолдары ақпараттың таралу қаупін арттырады. Бұл мәліметтерді жабық қосымшаларда немесе псевдонимдермен сақтау қауіпсіз.

Шешімдер мен мақұлдауларды жазбау. «Портты өшірдік» деп жазған, бірақ не үшін дәл сол шара таңдалғаны, қандай тәуекелдер қабылданғаны және кім мақұлдағаны көрсетілмеген. Кейін учасктің тоқтатылуын түсіндіру қиын болады.

Инцидентті сабақсыз жапқызу. Егер қысқа қорытынды (негізгі себеп) және нақты тапсырмалар (сегментацияны өзгерту, қолжетімдіктерді қайта бөлу, резервті қалпына келтіру) болмаса, оқиға қайталанады. Жабу тек 1–3 өлшенетін әрекет пен жауапты тұлғалар болғанда ғана дұрыс.

Қысқа мысал

Журналда: «Инженерлік станцияда вирусты жойдық». Бір айдан кейін қайталанды, өйткені станция ID-сы, зонасы, не істелгені (неге жалпы қолжетімдікті қалдырғандары) және тапсырмалар жазылмаған. Дұрыс карта: қандай актив, қай жерде, қандай шара келісілген және қай нәрсаларды өзгерту қажет екенін көрсетеді.

Жылдам тексеру тізімі және енгізу үшін келесі қадамдар

Егер әлі біртұтас журнал жоқ болса, қарапайымнан бастаңыз: бір шаблон карточка және бір сақтау орны. Мақсат: карта оқиғаны OT-контекстімен байланыстыруы (актив, зона, әсер) және артық мәліметті ашпау.

80% пайда әкелетін минималды өрістер тізімі:

• Инцидент ID және уақыт: бірегей нөмір, анықталған уақыт, басталу уақыты (білсе), кім хабарлаған.
• OT-ке байланыстырылуы: Asset ID, актив түрі (PLC/HMI/инженерлік станция/сервер), актив иесі (бөлім).
• Желі мен зона: Zone ID, сегмент (мысалы, Level 2/3), байланыс жолы (межзоналық арна, шлюз), зона критикалдығы.
• Әсер мен тәуекел: зақымдалған процесс, ықпал деңгейі (адам қауіпсіздігі, сапа, тоқтау), масштаб.
• Статус және шаралар: кезең (триаж, тергеу, сдерживание, қалпына келтіру, жабу), қабылданған шаралар, рөлдер бойынша жауапты, мерзімдер.

Құпиялылық үшін минимум екі деңгей ұстаңыз: көпшілікке арналған жалпы өрістер және тар топқа арналған жабық өрістер. Жабықта әдетте пайдаланушы аттары, нақты IP/сериялық нөмірлер, толық логтар және осалдықтар детальдары сақталады.

Сапаны бақылау үшін әдетте үш есеп жеткілікті: зоналар бойынша (қай жерде жиі), активтер бойынша (қай құрылғылар қайталанады), себептер мен шаралар бойынша (қандай шаралар шын мәнінде қайталанбауды азайтады).

Келесі қадамдар процессті бекіту үшін:

• бір шаблон картаны таңдап, 1–2 зонада пилот жүргізу
• рөлдер тағайындаңыз: кім инцидент ашады, кім жабуды мақұлдайды, кім активтің иесі
• апталық 30 минуттық талқылау орнатыңыз: бірнеше инцидент, 1–2 сабақ, бір іс-шара жоспары
• қолжетімділікті және сақтау ережелерін орнатыңыз: журнал, қоса қосымшалар, сақтау мерзімдері, өзгерістер аудиті

Егер журналды және байланысқан артефактілерді тұрақты инфрақұрылымға орналастырып, қолдауды бекіту керек болса, бұл жиі жүйелік интегратормен бірге жасалады. Қазақстанда мұндай тапсырмалар, серверлік инфрақұрылым мен қызмет көрсету арқылы, GSE.kz орындап, S200 Series серверлері мен тәулік бойы техникалық қолдауды ұсынады.