Әлсіздіктерді басқару: Tenable, Qualys, Rapid7 таңдау

Неліктен «CVE саны» тәуекелді басқаруға көмектеспейді

CVE саны сенімді көрінуі мүмкін: «бізде 12 000 әлсіздік табылды». Бірақ бұл тәуекел туралы көп айтпайды. CVE — тек идентификатор; ол қай жерде проблема, оны шабуылшыға қаншалықты қолжетімді және оны пайдалансақ не болады деген сұрақтарға жауап бермейді.

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

«Түзетуге ұзын кезек» мәселесінің мәні — команда шұғыл мен маңыздыны ажырата алмайды. Бэклогта мыңдаған тапсырма болғанда, түзетулер «көрнекілігіне» немесе «оңай жабылатындығына» қарай жасала бастайды, ал бизнеске әсері бойынша емес. Нәтижесінде маңызды жүйелер апталар бойы уязвим болып қалуы мүмкін: оларды патчтау күрделірек, жұмыс терезесі, келісім және тестілеу талап етіледі.

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

Көшбасшылар әдетте қанша CVE табылғанына мән бермейді. Оларға не болуы мүмкін және сіз бірінші кезекте нені істеп жатқаныңыз қызықты. Типтік сұрақтар:

• Қазір қай 10 жүйе ең қауіпті және неге?
• Қай уязвимостар қазір белсенді пайдаланылып жатыр ма?
• Егер біз бір ай ішінде түзетпесек, не өзгеруі мүмкін?
• Тәуекелді айтарлықтай төмендету үшін қанша ресурс керек?
• Түзетулер үшін кім жауапты және біз мерзімді қалай бақылаймыз?

Егер мақсат — әлсіздіктерді басқару, CVE саны екінші жоспарда болуы керек. Бірінші орынға бизнеске түсінікті приоритеттер шығады: қай активтер маңыздырақ, қандай қауіптер нақтырақ және келесі аптада тәуекелді ең тиімді төмендететін қандай әрекеттер.

Зрел процесс әлсіздіктерді басқару қайдан басталады

Зрел басқару сканерден немесе есептен басталмайды, ол: нені қорғайтыныңыз және кім жауапты екенін анықтаудан басталады. Егер бұл болмаса, кез келген CVE цифрлары шудан аспайтын болады, ал команда «ең дауысқұмар» табылымдарға уақыт жұмсайды, нақты тәуекелдерге емес.

Активтерді және сканерлеу шекарасын айқындаңыз

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

Тиімді түрде төрт нәрсені бекітіңіз: қазір қамтылатын сегменттер мен кейінгі қамту; актив есепке қалай қосылады (сатып алу, тапсыру, желіге қосылу); міндетті атрибуттар (иесі, критикалдық, орта — prod немесе test); «көрінбейтін аймақтарды» қалай жабасыз (қашықтағы ноутбуктер, филиалдар, бөлек VLAN).

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

Иелерді тағайындаңыз және тәуекел-ерешім ережелерін жасаңыз

Жүйенің иесі болуы керек — түзетуді шешетін адам: патштау, басқарудың арқасында өтем жасау немесе уақытша тәуекелді қабылдау. Иелер жоқ кезде әлсіздік ИБ, ИТ және эксплуатация арасында шексіз түрде «ойналасып» жүреді.

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

SLA келісіп, әлсіздіктер ағындарын түрге бөлу

SLA-ны тек критикалдық бойынша емес, актив түрі мен сырттан қолжетімділік бойынша да есептеген дұрыс. Сыртқы периметрдегі әлсіздік пен ішкі жұмыс станциясындағы әлсіздік әртүрлі реакция жылдамдығын талап етеді.

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

Приоритизация: бір CVSS-тен маңыздырақ сигналдар

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

Пайдалысы — бірнеше сигналды жинап, тәуекел бойынша шешім қабылдау. Зрел басқаруда приоритетті есептейтіндер есептің цифрлары емес, шабуыл ықтималдығы мен нақты актив үшін қателік бағасы.

CVSS-ден маңыздырақ жиі қолданылатын сигналдар

Тұрақты түрде ұстауға болатын жинақтан бастаңыз:

• Эксплуатацияның дәлелі. Егер әлсіздікті қазір пайдаланып жатқаны расталса, бұл кез келген теориядан жоғары тұрады.
• KEV және ұқсас тізімдер. Мұндай тізімдерге кіру «шұғыл» режимін қосуы тиіс, әсіресе периметр мен әкімшілік интерфейстер үшін.
• EPSS. Бұл жақын уақытта эксплуатациялау ықтималдығын бағалауға көмектеседі, «дауыстың» емес, нақты аңшылықтың табылуына септігін тигізеді.
• Активтің критикалығы. Бизнес-сервис, деректер және қолжетімділік талаптары ең маңызды.
• Желілік контекст. Интернетке ашықтық, сегмент, артық құқықтар, бүйірлік қозғалу мүмкіндігі.

Қысқа мысал

CVSS 9.8 бар екі табылымды қарастырыңыз. Біріншісі — бухгалтердің жұмыс станциясында, әкімшілік құқықтары жоқ, қатал сегментте. Екіншісі — интернеттен қолжетімді веб-серверде, жеке кабинет қызметін беретін және дерекқорға байланысы бар.

Егер екінші әлсіздікте EPSS жоғары немесе ол KEV тізімінде болса, онда приоритет анық: алдымен оны түзету, тіпті екі табылым «балл бойынша» бірдей болса да. Біріншісіне жөндеу терезесін жоспарлап, өтем шаралардың бар-жоғын тексеріп (мысалы, EDR, құқықтарды шектеу, сегментация) қауіпті паникасыз жабуға болады.

Приоритет ережесін жазып қою пайдалы әдет: мысалы, «интернетке ашық KEV — 72 сағат ішінде түзетілуі керек». Сонда приоритизация қайталанатын әрі дау-дамайсыз болады.

Эксплуатация дәлелі және нақты қатерді тексеру

Басты тұзақтардың бірі — барлық жоғары CVSS мәселелерін бірдей қауіпті санап қою. Көп пайдасы бары — шабуыл жолы бар ма және әлсіздік қазір қолданылып жатыр ма екендігін түсіну.

Екі ұқсас сигналды ажырату маңызды. Exploit available — эксплойт бар, бұл шабуыл ықтималдығын арттырады, бірақ сізге нақты шабуыл жасалғанын дәлелдемейді. Exploited in the wild — жеткізушілер, CERT немесе қатер-аналитикасы негізінде расталған нақты эксплуатация оқиғалары. Мұндай сигнал әдетте приоритетті жоғарылатады, тіпті әлсіздік CVSS бойынша «критикалық» болмаса да.

Өз ортаңызда эксплуатация фактін қалай тексеруге болады

Бұл жерде тек сканер есептері ғана емес, телеметрия көмектеседі. Практикалық минимум:

• Периметр және веб-шлюз логтары: 4xx/5xx толқындары, күдікті URI, файл жүктеуге әрекеттер, белгісіз User-Agent.
• EDR оқиғалары: қызметтер атынан күдікті процестер, веб-серверден шыққан child-process, көп байланыстар, құпия сөзті ұрлауға әрекеттер.
• Желілік оқиғалар: сирек елдер/ASN-лерге шыққан сыртқы байланыстар, DNS жаңа домендерге сұраныстар, әдеттен тыс порттар, C2 белгілері.
• Аутентификация логтары: аномалды кірулер, сәтсіз кірулердің өсуі, жаңа админ сессиялар.

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

Қашан «орташа» әлсіздік критикалық болады

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

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

ITSM-пен интеграциялар: тикеттерге батып қалмау

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

CMDB байланысынен бастаңыз. Оған дейін әлсіздіктің контексті жоқ: бұл чья сервері, қаншалықты маңызды, өзгеріс қашан мүмкін, кім келіседі — ештеңе белгісіз. CMDB-де кемінде сервис иесі, критикалдық, орта (prod/test) және өзгерістер терезесі болуы тиіс. Осылай бірдей әлсіздік бухгалтерияның терминал серверінде және тест стендінде әртүрлі өңделеді.

Жақсы ITSM интеграциясы тикет шаблондарынан басталады. Тикетте инженер қосымша чат сұрағынсыз әрекет ете алатындай деректер болуы тиіс.

Тикет шаблонында не сақтау керек

• Актив пен сервис: аты, орта, иесі, CMDB-ден алынған критикалдық.
• Мәселенің мән-жайы: әлсіздік, зақымданған ПО, нұсқа, активте бар екенінің растамасы.
• Ұсынылған әрекет: патч, конфигурация, уақытша шара, түзетуден кейін тексеру.
• Приоритет пен мерзім: есептеу ережесі, SLA, қайта тексеру күні.
• Деректер: неге осы жерде маңызды (мысалы, сыртқы қолжетімділік немесе критикалық сегмент).

Одан әрі кім тағайындайтынын шешеді. CMDB деректеріне сүйеніп орындаушы автоматты түрде анықталғаны жақсы: платформа командасы, қосымша иесі немесе мердігер. Бұл тикеттерді лақтырып жіберудің алдын алады және SLA-ны бақылауды жеңілдетеді. Егер бөлек өзгерістер командасы болса, қайта іске қосу немесе сервисті тоқтату қажет тапсырмалар дереу келіссөз терезесін талап ететін статус алсын.

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

Жұмыс циклінің практикадағы көрінісі

Мысалы, ауруханада немесе мемлекеттік органда персонал деректері бар сегменттегі сервер критикалық әлсіздік алады. Интеграция сервис иесін және өзгеріс терезесін шығарып, SLA бойынша приоритетпен тикет жасайды, орындаушыны тағайындайды, ал сервис иесіне қайта жүктеу келісімін сұрайды. Жұмыстан кейін қайта тексеру жасалады, және ғана тапсырма расталғанда жабылады.

Хабарландырулар мен ерекшеліктерді ойластырыңыз. Уақытша ерекшеліктер нақты рөлмен бекітілуі, мерзімі және себебі болу керек. Практикалық ереже: кез келген ерекшелік аяқталудан 7–14 күн бұрын автоматты ескерту алады және немесе ұзарту, немесе түзету жоспары талап етіледі.

Егер сіз GSE.kz сияқты жүйелік интегратормен жұмыс істесеңіз, алдын ала кім CMDB-ге ие екенін, кім тағайындау ережелеріне жауапты екенін және кім ерекшеліктерді бекітетінін келісіңіз. Солай ITSM интеграциясы шуды емес, басқарылатын түзетулер конвейері болады.

Басшылыққа есеп: CVE кестелері орнына не көрсету керек

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

Бизнеске түсінікті метрикалар

CVE тізімі орнына 5–6 көрсеткіш көрсетіңіз, олар минут ішінде оқылады:

• Ағымдағы тәуекел және 30–90 күндегі тренд (өсіп жатыр ма, төмендеп жатыр ма), бөлек критикалық сервистер бойынша.
• Түзету SLA-сының орындалуы және мерзімнен тыс үлесі.
• Топ-10 тәуекел: негізгі сервистер, бөлімдер және интернет-узелдер бойынша.
• Кезең бойынша прогресс: қанша жабылды, қанша қайта ашылды, кешігудің негізгі себептері.
• Ерекшіліктер: қанша белсенді, қанша мерзімге, кім бекітті және шешімнің негізі.

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

«Неге жаппады» сұрағын ақтамаусыз қалай түсіндіру

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

Деректер сапасын бөлек көрсетіңіз. Мысалы, сканер қамтуы 85% болса, 15% актив «белгісіз» — есеп тәуекелді төмен көрсетеді. Мысал формулировка: «интернет-узелдер 100% қамтылған, серверлер — 92%, жұмыс станциялары — 70%, белгісіз активтер — 8%». Басшыға келесі қадам нақты көрініп тұрады: көрінбейтін аймақтарды жауып, иелер тағайындау.

Tenable, Qualys, Rapid7: маркетингсіз салыстыру критерийлері

Платформаны таңдау кезінде функциялар витринасында тұрып қалу оңай — «кімде көбірек тапты» деген сауалдан арылыңыз. Нақты пайдалысы — құрал сіздің ортада тәуекелді қаншалықты тез төмендетуге көмектесетіні.

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

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

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

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

Соңында — интеграциялар мен API. Платформа ITSM/CMDB, EDR және SIEM-пен нашар интеграция жасаса, қолмен жұмысқа батырасыз.

Нақты сценарийде тексеріңіз: тикет жасау, CMDB-ден активке байлау, жауапты тағайындау, SLA, комментарийлер, қайта сканерлеуден кейін ғана жабылу. Көп жағдайда дәл осы жерде Tenable, Qualys және Rapid7 арасындағы айырмашылық жарнамалық кестелерден жақсы көрінеді.

Қадамдық платформа таңдау: талаптардан пилотқа дейін

Tenable, Qualys немесе Rapid7 таңдау демомен емес, сіздің қоршауыңызды сипаттаудан бастау керек. Қандай активтерді сканерлейсіз: серверлер, жұмыс станциялары, виртуалдар, бұлт, желі жабдықтары, контейнерлер; қандай командалар процесте болады: ИБ, әкімшілер, сервис иелері, DevOps; қандай есептер қажет: регуляторлық, аудит үшін, басшылыққа.

Содан кейін өнімге сай келмейтін must-have талаптарды бекітіңіз. Әдетте: ITSM-пен интеграция (тапсырмаларды автоматты түрде жасау, жаңарту, жабу), CMDB-мен байланыс немесе айқын инвентарь, SSO және рөлдер моделі, икемді ерекшеліктер пен келісімдер, деректер экспорттау және KPI-ларға арналған есептер.

Пилотты нақты сегментте жасаңыз, «лабораторияда» емес. Оптималды мерзім — 2–4 апта: аз мерзім сапалы деректер мен командаларға түсетін жүктемені көрсетпейді. Алдын ала сценарийлер мен табыстың критерийлерін сипаттаңыз, сонда әділ салыстыру болады.

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

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

Егер ішкі ресурстар жеткіліксіз болса, интегратор көмегін қарастырыңыз — олар пилотты қоя алады, интеграцияларды баптайды және басшылыққа арналған есептер дайындайды. Қазақстанда мұндай жұмыстарды жүйелік интеграторлар арқылы шешеді, мысалы GSE.kz. Бұл кезде инфрақұрылым мен қолдау бір контурда — жұмыс станцияларынан бастап 24/7 қолдауға дейін қамтылса ыңғайлы.

Енгізуде типтік қателер және олардан қалай сақтану

Таңдау Tenable, Qualys немесе Rapid7 болсын, сәтсіздіктің себебі көбіне процесстің ІТ жұмысында бекітілмеуінде. Құрал дабыл тудыратын машинаға айналып, әлсіздіктерді басқару «тикеттер жабу спортына» айналып, тәуекел төмендемей, тек CVE саны өседі.

Қате 1: бәрін кез-келген түрде сканерлейді, бірақ жауапты жоқ

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

Зрелдіктің жақсы белгісі: әр актив тобының иесі бар, минималды SLA критикалдық бойынша белгіленген және түзету мүмкін болмаса эскалация жолы түсінікті.

Қате 2: аутентификациясыз сканерлейді және шу тудырады

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

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

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

Периметрді ұмытпаңыз. Ішкі сканерлер қалып қойған тесттік порталды немесе ескі VPN-ді сыртқы адрес бойынша көрмейді. Сыртқы беттерді жүйелі тексеру енгізіп, кез келген сыртқы сервис иесі бар және келесі тексеру мерзімі тіркелсін деген ереже қойыңыз.

Және бір жиі кездесетін қате — есептер «ИБ үшін» жазылады, CVE кестелері бар, бірақ олар ИТ пен басшылықтың сұрақтарына жауап бермейді. ИТ не істеу керек және қай мерзімде керек екенін талап етеді; басшылыққа қандай тәуекелдер жабылып жатқаны және не қалғаны маңызды.

Қателіктерді азайтудың қысқа жолы:

• 1–2 критикалық сервистен бастаңыз және «таптық -> тағайындадық -> түзеттік -> тексердік» циклі толық жұмыс істелсін.
• Қай жерлерде аутентика қажет екенін анықтап қосыңыз және ерекшеліктерді тіркеңіз.
• Жұмыс ағындарын бөліңіз: патчтар бөлек, конфигурациялар бөлек, ұзақ жобалар бөлек.
• Сыртқы контурды тұрақты тексеру графигіне қосыңыз.
• Екі түрлі есеп құрыңыз: операциялық (ИТ үшін) және тәуекел-көрсеткішті (басшылық үшін).

Мысалы, мемлекеттік органда жұмыс станциялары мен серверлерде (оның ішінде жергілікті өндірістегі жүйелер) домен контроллерлері мен пошта қызметінен бастауға болады, активтерді ITSM-ге бекітіп, басшылыққа «қанша CVE» емес, негізгі жүйелерде расталған эксплуатацияланған критикалық әлсіздіктердің үлесін және олардың түзетілгенін көрсету тиімді.

Қысқа чек-лист және келесі қадамдар

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

Зрелдіктің мини-чек-листі

Бес пункт, олар әлсіз жақтарды тез көрсетеді:

• Қамту: барлық критикалық сервистер мен негізгі желі сегменттері сканерленеді және не сканерленбейтіні белгілі.
• Приоритет: қарапайым шұғылдық ережесі бар, мысалы «эксплуатация + интернет» = бірінші түзету.
• Процесс: тикеттер автоматты жасалады, әрбірі иесі мен түсінікті мерзімге ие.
• Бақылау: апта сайын қысқа шолу өткізіледі — мерзімнен тыс, ерекшеліктер және дау-дамайлы жағдайлар.
• Есеп: басшылыққа тәуекел динамикасы көрсетіледі (қанша критикалық жабылды, қанша мерзімінен тыс, тікелей тармақтар), CVE тізімі емес.

Келесі қадамдар — 2–4 апта

Мақсат — қысқа пилот арқылы «тұрақты түзету жасауға бола ма?» деген сұраққа жауап алу:

• Процесс иесін және резерв иесін тағайындаңыз.
• 1–2 ең маңызды бизнес-сервисті таңдап, толық циклді өтіңіз: сканерлеу, приоритизация, тикет, жабу, қайта тексеру.
• Әр түрлі тәуекел деңгейлері үшін SLA келісіп, ерекшеліктер ережесін бекітіңіз (кім бекітеді, қанша мерзім, өтем шаралар).
• ITSM интеграциясын осылай орнатыңыз: тикеттер тек расталған критикалық сыртқы узелдер үшін автоматты түрде жасалсын — әйтпесе команда кезекке батады.

Егер ішкі тәжірибе немесе уақыт жеткіліксіз болса, жүйелік интегратор көмегін қарастырыңыз. Мысалы, GSE.kz платформа таңдауға, ITSM және инфрақұрылымға интеграциялауға көмектесіп, пилотты нақты жұмыс процессіне сай өткізеді, есептерді басшылыққа дайындайды және 24/7 қолдауды қамтамасыз ете алады. Бұл кезде инфрақұрылым мен қолдау бір контурда — жұмыс станцияларынан бастап тұрақты қызмет көрсетуге дейін жабылады.