Մեկ թեստը քիչ է․ ինչու է անվտանգության ենթակառուցվածքին պետք մշտական ստուգում
Alexander Zemskov
Սա ցանցային անվտանգության արտադրանքի գնահատման շարքի վեցերորդ մասն է։ Մաս 1՝ datasheet-ների տարբերությունը։ Մաս 2՝ NGFW-ի ծուղակները։ Մաս 3՝ WAF, IPS, DLP։ Մաս 4՝ SASE։ Մաս 5՝ մեթոդիկա և անկախ թեստ։
Առաջին հինգ գրառումները գնման փուլի մասին էին․ ինչպես կառուցել թեստ, որի արդյունքներին կարելի է վստահել, մինչև պայմանագրի ստորագրումը։ Այս գրառումն այն մասին է, ինչ է լինում ստորագրումից հետո։ Առաջին գնահատումը որպես միանվագ իրադարձություն դիտարկելը անվտանգության շահագործման ամենահաճախ և ամենաթանկ սխալներից է։
Երկու տարի անց դուք աշխատում եք ոչ այն պլատֆորմի վրա, որ գնել եք
Ցանկացած կորպորատիվ անվտանգության պլատֆորմ՝ NGFW, WAF, IPS, DLP, SASE՝ պարբերաբար ստանում է ծրագրային թարմացումներ․ firmware-ի ռելիզներ, անվտանգության patch-եր, threat intelligence-ի բազաների թարմացումներ, նոր ֆունկցիաների բացում, ալգորիթմների փոփոխություն, արտադրողականության օպտիմիզացիա։ Վենդորները դրանք թողարկում են անընդհատ։ Միայն NGFW սեգմենտում խոշոր վենդորները տարեկան մի քանի անգամ թողարկում են firmware-ի խոշոր թարմացումներ, իսկ hotfix-երն ու անվտանգության patch-երը՝ զգալիորեն ավելի հաճախ։
Ամեն այդպիսի թարմացում փոխում է պլատֆորմը։ Երբեմն փոփոխությունները մանր են։ Երբեմն՝ ոչ։
Firmware-ի թարմացումը նոր DPI ալգորիթմով՝ ավելի բարձր դետեկտի ճշգրտություն, պրոտոկոլների ավելի լայն ծածկույթ, շրջանցումների նկատմամբ ավելի լավ դիմադրություն՝ ավելացնում է նաև նոր overhead ամեն inspection արվող սեսիայի վրա։ Threat intelligence-ի բազայի թարմացումը 50 000 նոր սիգնատուրայով բարելավում է պաշտպանությունը և բարձրացնում ամեն փաթեթի որոնման արժեքը։ Իրական օգուտով նոր ֆունկցիան՝ շիֆրված DNS-ի inspection, ML-ով անոմալիաների դետեկտ, ամպային sandbox-ի հետ խիտ ինտեգրում՝ ծախսում է հիշողություն, CPU-ի ցիկլեր և հնարավոր է ASIC-ի առանձնացված հզորություն։
Պլատֆորմը, որ ստուգել եք գնման ժամանակ՝ firmware-ի կոնկրետ տարբերակով, ֆունկցիաների կոնկրետ հավաքածուով և բազաների վիճակով, այն պլատֆորմը չէ, որ աշխատում է 18 ամիս պարբերական թարմացումներից հետո։ Արտադրողականության միջակայքը շեղվում է ամեն նշանակալի փոփոխության հետ։ Հարցն այն է, արդյոք դուք հետևում եք այդ շեղմանը, թե իմանում եք դրա մասին, երբ պրոդի վթարը ստիպում է հասկանալ։
Սարքավորումը ֆիքսված սահմանափակում է։ Ծրագիրը՝ ոչ։
Այստեղ ամպային և ապարատային անվտանգության պլատֆորմների տարբերությունը դառնում է գործառնական առումով նշանակալի այնպես, ինչպես գնման որոշումները սովորաբար հաշվի չեն առնում։
Ամպային SASE-ն կամ վիրտուալ NGFW-ն էլաստիկ ենթակառուցվածքի վրա ունեն ճկունության պաշար, երբ ծրագրի թարմացումը բարձրացնում է ռեսուրսների ծախսը․ բազային հաշվարկները մասշտաբավորվում են, բարձրանում են լրացուցիչ instance-ներ, ավելանում է հիշողություն և CPU՝ առանց սարքավորման գնման ցիկլի։ Գործառնական շփումն իրական է, արժեքն աճում է, բայց առաստաղը ֆիքսված չէ։
Ապարատային appliance-ը ռեսուրսների փակ բյուջե է։ RAM-ը զոդված է։ CPU-ն ֆիքսված է։ Ցանցային պրոցեսորը և անվտանգության ASIC-ն այնպիսին են, ինչպիսին կան։ Firmware-ի թարմացումը բարձրացրեց սեսիայի վրա հիշողության ծախսը՝ հիշողություն ավելացնել հնարավոր չէ։ Inspection-ի նոր ալգորիթմն ավելացրեց CPU-ի 15% ծանրաբեռնվածություն՝ միջուկներ ավելացնել հնարավոր չէ։ Նոր ֆունկցիաների և թարմացված սիգնատուրների բազայի համակցությունը միաժամանակյա սեսիաների հիշողության ծախսը հասցրեց տեղադրված RAM-ի 90%-ի՝ տրաֆիկի պոռթկումների պաշարն անհետացավ։
Վենդորները firmware-ի նոր հնարավորությունները հայտարարում են մարկետինգով, որտեղ առաջին տեղում անվտանգության և ֆունկցիոնալության բարելավումներն են։ Ռեսուրսների ծախսի հետևանքները նկարագրված են release notes-ում, եթե ընդհանրապես նկարագրված են, տեխնիկական լեզվով, որը հազվադեպ է վերածվում հստակ «այս թարմացումը կնվազեցնի էֆեկտիվ throughput-ը N%-ով այս մոդելների վրա» ձևակերպման։ Հաճախորդը տեսնում է ֆունկցիայի հայտարարությունը։ Արտադրողականության վրա էֆեկտը գալիս է պրոդ։
Սա վարկած չէ։ Ընկերությունները, որ գնման ժամանակ աշխատում էին ապարատային appliance-ների անվանական հզորության 60–70%-ով, պարբերաբար հայտնվում են 85–90%-ի վրա երկու-երեք տարի հետո՝ առանց սարքավորման փոփոխության, առանց տրաֆիկի նկատելի աճի, firmware-ի թարմացումների ցանկով, որոնցից ամեն մեկն առանձին մանր էր թվում։
Նոր ֆունկցիաները որպես տրոյական ձի
Կա կոնկրետ փաթեր, որ արժե ուղիղ անվանել, որովհետև այն կրկնվում է տարբեր վենդորների և արտադրանքի կատեգորիաների մոտ։
Վենդորը թողարկում է firmware-ի խոշոր տարբերակ հնարավորություններով, որոնք հաճախորդին իրապես պետք են․ ավելի լավ տեսանելիություն շիֆրված տրաֆիկում, ավելի ճշգրիտ հավելվածների նույնականացում, սպառնալիքների դետեկտի նոր շարժիչ ակնհայտ ավելի բարձր catch rate-ով։ Անվտանգության թիմը գնահատում է նոր հնարավորությունները, հաստատում, որ դրանք փակում են իրական բացեր, պլանավորում է թարմացումը։
Ինչ չեն գնահատում՝ որովհետև դրա տակ կառուցվածքային թեստ չկա՝ դա նոր հնարավորությունների միացման էֆեկտն է ընթացիկ սարքավորման վրա, մարտական տրաֆիկի պրոֆիլի տակ, մարտական ծանրաբեռնվածության մակարդակով։
Թարմացումը տեղակայվեց։ Նոր ֆունկցիաները միացվեցին։ Առաջին օրերին ամեն ինչ նորմալ տեսք ունի։ Հետո, սահուն կամ կտրուկ՝ կախված փոփոխության բնույթից, հայտնվում են ախտանիշները․ latency-ի աճ պիկի տակ, միացումների հաստատման տեմպի դեգրադացիա, հիշողության ծախսը սողում է վեր և չի վերադառնում, գալիս են առաջին ticket-երը օգտատերերից դանդաղ հավելվածների մասին, որոնք առաջ արագ էին։
Մեկնարկում է ինցիդենտի քննությունը։ Եզրակացությունը․ նոր firmware-ը ընթացիկ սարքավորման վրա տրաֆիկի ընթացիկ ծավալի դեպքում այլևս բավարար պաշար չունի։ Տարբերակները․ հետ գլորել firmware-ը և կորցնել անվտանգության բարելավումները, անջատել նոր ֆունկցիաները և կորցնել թարմացման պատճառը, արագացնել սարքավորման թարմացումը և ստանալ չպլանավորված capex։
Երեք ելքն էլ կարելի էր բացահայտել մինչև պրոդ դուրս գալը։ Ոչ մեկը թանկ կամ բարդ թեստավորում չի պահանջում։ Պետք է կառուցվածքային ստուգման պրոցես մինչև տեղակայումը։
Ստուգում մինչև տեղակայումը․ ինչ է իրապես պետք
Անվտանգության պլատֆորմի թարմացումը մինչև պրոդ դուրս գալը ստուգելը գնման փուլի ամբողջ PoC-ը վերարտադրելը չէ։ Դա ավելի կետային հարցերի շարքին պատասխանելն է։
Throughput-ի ռեգրեսիա։ Արդյոք թարմացված firmware-ը պահում է throughput-ը նախորդ տարբերակից ընդունելի թույլատրելիի սահմաններում, նույն տրաֆիկի պրոֆիլի տակ։ 5% ռեգրեսիան կարող է ընդունելի լինել։ 20% ռեգրեսիան հզորության պլանավորման իրադարձություն է։
Ռեսուրսների ծախսը մարտական ծանրաբեռնվածության վրա։ Ինչ են CPU-ն, հիշողությունը և միաժամանակյա սեսիաների քանակը բնորոշ մարտական ծանրաբեռնվածության վրա նոր firmware-ի տակ։ Ինչպես է դա հարաբերվում նախորդ տարբերակի հետ։ Ինչ է նոր պաշարը։
Նոր ֆունկցիաների ճշտությունը։ Արդյոք նոր հնարավորություններն աշխատում են ինչպես փաստաթղթում։ Արդյոք ճիշտ են փոխազդում ընթացիկ քաղաքականությունների հետ։ Արդյոք տրաֆիկի մշակման մեջ անսպասելի փոփոխություններ չկան։
Անվտանգության ռեգրեսիա։ Արդյոք թարմացումը պահում է դետեկտի արդյունավետությունը կամ բարելավում է այն։ Firmware-ի փոփոխությունները, որոնք դիպչում են DPI շարժիչին, կանոնների համապատասխանեցման տրամաբանությանը կամ պրոտոկոլների պարսերներին, կարող են ռեգրեսիա մտցնել դետեկտի ծածկույթում՝ ոչ թե որովհետև վենդորն այդպես է ուզել, այլ որովհետև բարդ համակարգերը փոխվում են ոչ ակնհայտ։ Սա պետք է ստուգել, ոչ ենթադրել։
Հետ գլորման աշխատունակությունը։ Եթե թարմացումը պրոդում անսպասելի խնդիր տա, կարելի՞ է այն մաքուր հետ գլորել։ Հետ գլորման ուղին ստուգելը մինչև դուրս գալը՝ դա պլանային 20 րոպեանոց հետ գլորման և արտակարգ չորսժամյա հետ գլորման տարբերությունն է, մինչ մարտական համակարգը դեգրադացվում է։
Փաստարկ մշտական թեստային ֆունկցիայի օգտին
Այս գրառման ամփոփ եզրակացությունը մշտական թեստավորումն է որպես գործառնական կարգապահություն, ոչ թե թեստավորումն որպես դրվագ, որ գործարկում է գնման իրադարձությունը։
Այն կետում, որտեղ կազմակերպությունը կառավարում է մի քանի անվտանգության պլատֆորմ, ամեն մեկն իր թարմացումների ռիթմով, իսկ պրոդում կարևոր են արտադրողականության և անվտանգության բազային մակարդակները, գործառնական մոդելը փոխվում է։ Խոշոր թարմացումներից առաջ միանվագ թեստերը սկիզբ են։ Կառուցվածքային վերարտադրելի ստուգման պրոցեսը՝ սահմանված բազային մակարդակներով, ռեգրեսիայի շեմերով և հասկանալի ուղով «թարմացումը դուրս եկավ»-ից մինչև «թույլատրված է պրոդ»՝ ահա հասունության մակարդակը, որ հանում է նկարագրված ինցիդենտների դասը։
Այս ֆունկցիան ներսում կառուցելը ճիշտ պատասխան է որոշակի մասշտաբում․ երբ թեստավորման ծավալը, ստուգում պահանջող թարմացումների հաճախականությունը և ներքին մարդկանց առկայությունն արդարացնում են ներդրումը մշտական թեստային ենթակառուցվածքի և գործիքների մեջ։ Այդ կետում սեփական թեստային ստենդը կոմերցիոն մակարդակի տրաֆիկի գեներացիայով անվտանգության թիմին տալիս է հնարավորություն, որ ինքն իրեն արդարացնում է գնումների, թարմացումների ստուգման, ինցիդենտների քննության և հզորության պլանավորման վրա։
Այն կազմակերպությունների համար, որոնք դեռ այս մասշտաբում չեն կամ որոնց հնարավորությունը պետք է անմիջապես՝ առանց ներքին ենթակառուցվածք կառուցելու ժամանակի, գործառնական մոդելը մշտական հարաբերությունն է անկախ լաբորատորիայի հետ։ Ոչ միանվագ աշխատանք գնման փուլում, այլ կրկնվող պրոցես․ թարմացումը դուրս եկավ, ստուգման թեստն անցկացվեց համաձայնեցված բազային մակարդակի դեմ, արդյունքները համեմատվեցին, go/no-go որոշումը կայացվեց մինչև պրոդ դուրս գալը։
Այդ պրոցեսի արժեքը մեկ թարմացման ցիկլի վրա կանխատեսելի է և սահմանափակ։ Չստուգված թարմացման արժեքը, որ պրոդում դեգրադացիա տվեց՝ ինժեներական ժամանակ, ինցիդենտի քննություն, հնարավոր արտակարգ սարքավորման գնում, բիզնեսի վնաս՝ ոչ։
Թարմացումների ստուգման աշխատող շրջանակ
Անկախ նրանից՝ թեստավորում եք ներսում, թե լաբորատորիայի միջոցով, պրոցեսին պետք է երեք տարր՝ հետևողական և պաշտպանելի լինելու համար։
Սառեցված բազային մակարդակ։ Գնման ստուգման ժամանակ (կամ թեստավորման ծրագրի մեկնարկին) ֆիքսվում է արտադրողականության և անվտանգության բազան համաձայնեցված տրաֆիկի պրոֆիլի դեմ։ Սա հետագա բոլոր թարմացումների հաշվարկի կետն է։ Throughput սահմանված AppMix-ի վրա, ռեսուրսների օգտագործում սահմանված ծանրաբեռնվածության մակարդակների վրա, դետեկտի rate համաձայնեցված հարձակումների պրոֆիլի դեմ։ Այս թվերը արգելափակված են և չեն փոխվում մինչև բազան թարմացնելու գիտակցված որոշումը։
Սահմանված ռեգրեսիայի թույլատրելի։ Ցանկացած չափվող պարամետրի ինչ չափի փոփոխությունը պահանջում է էսկալացիա մինչև պրոդ դուրս գալը։ Շեմերը սահմանում են նախապես և համաձայնեցնում անվտանգության թիմի ու շահագործման միջև, ոչ թե դուրս բերում հետին թվով ինցիդենտի քննության ժամանակ։ Տիպիկ պարամետրեր․ throughput-ի ռեգրեսիա X%-ից ավելի, հիշողության օգտագործման աճ Y տոկոսային կետից ավելի, միաժամանակյա սեսիաների հզորության նվազում Z%-ից ավելի։
Վերարտադրելի թեստի գործարկման պրոցես։ Թեստը պետք է կատարվի նրա կողմից, ով վարում է այն՝ ներքին թիմ, արտաքին լաբորատորիա՝ և ամեն անգամ տա համեմատելի արդյունք։ Նույն տրաֆիկի պրոֆիլը, նույն ծանրաբեռնվածության մակարդակները, նույն չափման մեթոդիկան։ Գործարկման մեթոդիկայի ցրվածությունը տալիս է արդյունքների ցրվածություն, և տրենդի վերլուծությունն անհնարին է դառնում։
Ինչ չի փոխվում
Մեկ բան մնում է անփոփոխ ծրագրի հասունության ցանկացած մակարդակում․ թեստի արժանահավատությունը հենվում է տրաֆիկի պրոֆիլի որակի և չափման գործիքների ճշգրտության վրա։
Շարքի նախորդ գրառումների բոլոր խնդիրները՝ AppMix-ի շեղում, PCAP-replay-ի կանխատեսելիություն, պաշտպանության արդյունավետության ստուգում իզոլյացիայում՝ կիրառելի են թարմացումների ստուգմանը այնպես, ինչպես գնման թեստերին։ Անվստահելի գործիքներով վերցված բազան բազա չէ։ Ռեգրեսիայի համեմատությունն այն գործիքով, որ անկայուն արդյունք է տալիս, պաշտպանելի եզրակացություններ չի տալիս։
Ճիշտ մեթոդիկայի և ճիշտ գործիքների ներդրումը գնման փուլում ինքն իրեն արդարացնում է հետագա ամեն գործարկման վրա՝ պլատֆորմի ողջ կյանքի ցիկլի ընթացքում։
Թեստավորումը գործառնական ենթակառուցվածք է
Գնման թեստը անվտանգության պլատֆորմի հետ հարաբերության սկիզբն է, ոչ վերջը։ Սարքավորման սահմանափակումները ֆիքսված են, ծրագրի բարդությունն աճում է ամեն թարմացման ցիկլի հետ։ Նոր ֆունկցիաներն ու ալգորիթմները, որ վենդորը վաճառում է որպես բարելավումներ, կարող են հանգիստ ուտել այն արտադրողականության պաշարը, որ հիմնավորել է սարքավորման ընտրությունը։
Կազմակերպությունները, որ շրջանցում են նկարագրված ինցիդենտների դասը, միավորում է մեկ բան․ նրանք թեստավորումը դիտարկում են որպես մշտական գործառնական ենթակառուցվածք, ոչ որպես նախագծի միանվագ ծախս։ Նրանք ունեն բազա։ Նրանք ունեն պրոցես։ Նրանք այն գործարկում են։
Նրանց համար, ովքեր կառուցում են այս հասունության մակարդակը կամ ում ստուգումը պետք է հիմա, TEST4NET LLC-ն փակում է և գնման առաջին գնահատումը, և թարմացումների ստուգման շրջանակը։ Աշխատանքի մեկ մոդել, մեկ մեթոդիկա, արդյունքներ, որ համեմատելի են պլատֆորմի կյանքի ցիկլի ցանկացած կետում։
Ամբողջ շարքը՝ Գրառում 1 · Գրառում 2 · Գրառում 3 · Գրառում 4 · Գրառում 5 · Գրառում 6
