Ինչպես անցկացնել անվտանգության արտադրանքի թեստ, որի արդյունքներին կարելի է վստահել

Սա վեցից հինգերորդ մասն է այն մասին, թե ինչպես գնահատել ցանցային անվտանգության արտադրանքը։ Մաս 1՝ datasheet-ների տարբերությունը։ Մաս 2՝ NGFW-ի ծուղակները։ Մաս 3՝ WAF, IPS, DLP։ Մաս 4՝ SASE։

Շարքի նախորդ գրառումները ցույց տվեցին, թե ինչն է սխալ գնում անվտանգության արտադրանքի տիպիկ գնահատումներում․ վենդորի տակ ընտրված թեստային պայմաններ, PCAP-replay գործիքներ, որոնց տակ վենդորը պատրաստվում է, AppMix-ի շեղում, որի պատճառով վենդորների համեմատությունն անիմաստ է, և demo-ներ, որոնք մարտական ծանրաբեռնվածությանն առնչություն չունեն։ Այս գրառումն այն մասին է, թե ինչ տեսք ունի լավ կառուցված գնահատումը և ով պետք է այն վարի։

Շահերի բախման խնդիրը

Մեթոդիկայից առաջ արժե ուղիղ ասել, թե ով է սովորաբար վարում անվտանգության արտադրանքի գնահատումները և ինչ խթաններ ունի։

Վենդորները վարում են PoC՝ իրենց արտադրանքը վաճառելու համար։ Նրանց ինժեներները հմուտ են, պրոֆեսիոնալ և գիտակ, և նրանք աշխատում են բարենպաստ արդյունքի վրա։ Տրաֆիկի պրոֆիլը, DUT-ի կոնֆիգուրացիան, PoC-ի համար ընտրված սցենարները, հաշվետվության մետրիկաները՝ այս ամենն արտացոլում է այդ խնդիրը։ Սա խաբեություն չէ, սա ռացիոնալ կոմերցիոն վարք է։ Չեզոք գնահատում այն չի տալիս։

Ինտեգրատորները կրում են կառուցվածքային բախում, որի մասին ավելի քիչ են խոսում։ Ինտեգրատորի մարժան նախագծի վրա կախված է նրանից, թե որ արտադրանքն է ընտրված, ինչ գնով և ներդրման ծառայությունների ինչ ծավալով։ Ինտեգրատորը, որ համեմատում է երեք վենդոր և առաջարկում է նրան, ում մարժան ավելի ցածր է, գործում է իր ֆինանսական շահի դեմ։ Ինտեգրատորների մեծ մասն աշխատում է բարեխղճորեն, բայց խթանների կառուցվածքն իրական է, և թանկ որոշումներում այն պետք է հաշվի առնել։

Ներքին թիմերը open-source գործիքներով բախվում են այլ խնդրի․ սովորաբար նրանց չի հերիքում մեթոդիկայի խորությունը՝ թեստ նախագծելու համար fast path-ի օպտիմիզացիաների, AppMix-ի շեղման և շրջանցումների ծածկույթի հաշվառմամբ։ Արդյունքները տեսք ունեն իմաստալից և տեխնիկապես իրական, բայց արտացոլում են պայմանները, որոնց տակ վենդորը պատրաստվել է։

Անկախ լաբորատորիան հանում է կառուցվածքային բախումը։ Նրա վարձատրությունը վճարում է գնորդը, այն ֆիքսված է անկախ արդյունքից և կախված չէ կոնկրետ վենդորի ընտրությունից։ Լաբորատորիայի արժեքն ամբողջովին իր արդյունքների արժանահավատության և պաշտպանելիության մեջ է։

Ազնիվ թեստ-պլանի պարտադիր տարրերը

Թեստ-պլանը, որ տալիս է որոշման մակարդակի արդյունքներ, պետք է փակի հինգ տարր, որոնք տիպիկ գնահատումներում կայունորեն բաց են թողնում։

1. Ֆիքսված կոնֆիգուրացիա մինչև թեստերի սկիզբը

DUT-ի կոնֆիգուրացիան՝ firmware-ի տարբերակը, միացված ֆունկցիաները, անվտանգության քաղաքականությունները, լոգավորման մակարդակները, բոլոր ակտիվ և ոչ ակտիվ մոդուլները՝ փաստագրված և ֆիքսված է մինչև առաջին փաթեթը։ Ոչ մի փոփոխություն թեստի պատուհանում։ Ոչ մի «tuning» գործարկումների միջև։ Ոչ մի ուղղում հետին թվով սցենարը կրկնելուց առաջ։

Սա կարևոր է, որովհետև թեստի ընթացքում կոնֆիգուրացիայի փոփոխությունն արդյունքը կառավարելու եղանակ է։ Սարքը թույլ աշխատեց վաղ գործարկումներում X ֆունկցիայով, հետո X-ը հանգիստ անջատեցին վերջնական գործարկման համար, որ ընկավ հաշվետվության մեջ։ Սա ազնիվ համեմատություն չէ։ Կոնֆիգուրացիան նախապես ֆիքսելը հանում է այս փոփոխականը։

Ֆիքսված կոնֆիգուրացիան պետք է արտացոլի ձեր նպատակային մարտականը՝ ձեր կանոնների քանակը, ձեր միացված քաղաքականությունները, ձեր լոգավորման ծավալը, ձեր inspection-ի կարգավորումները։ Ոչ վենդորի default-ը։ Ոչ նվազագույն հավաքածուն՝ գեղեցիկ թվերի տակ։

2. Տրաֆիկի դինամիկ գեներացիա L7-ի սեսիաների բազմազանությամբ

Ամեն սեսիա գեներացվում է ընթացքում։ Նույն տիպի երկու հոսք չպետք է ունենան նույն payload-ը L7-ի վրա։ Դա նշանակում է․

• եզակի HTTP տրանզակցիաներ տարբեր վերնագրերով, token-ներով, URI փաթերներով և բովանդակության երկարությամբ;
• TLS սեսիաներ cipher suite-ի տարբեր համաձայնեցմամբ, սերտիֆիկատների մշակմամբ և SNI արժեքներով;
• SMTP ուղարկող/ստացող տարբեր համակցություններով, նամակի կառուցվածքներով և կցորդների պրոֆիլներով;
• DNS հարցումների տարբեր տիպերով և պատասխանների մշակմամբ։

Սա անջատում է քեշի և fast path-ի օպտիմիզացիաները, որոնք PCAP-replay-ի արդյունքներն անվստահելի են դարձնում։ Սարքը ստիպված է ամեն հոսք առանձին դասակարգել և inspection անել՝ ճիշտ ինչպես պրոդում։

Դինամիկ գեներացիան չի նշանակում պատահական և անվերահսկելի։ Տրաֆիկի պրոֆիլը սահմանված է, պարամետրիզացված և վերարտադրելի։ Նույն seed-ը, նույն պարամետրերը, նույն թեստը՝ տրաֆիկի նույն բնութագրերն ամեն անգամ։ Վերարտադրելիությունը դարձնում է արդյունքները պաշտպանելի և թույլ է տալիս վերաստուգել կոնֆիգուրացիայի փոփոխություններից հետո։

3. AppMix-ի վերահսկում փակ ցիկլով՝ DUT-ի վրա ստուգմամբ

Հավելվածների միքսը, որ անցնում է DUT-ով, պետք է չափել, ցույց տալ հաշվետվության մեջ և վերահսկել։ Չի կարելի ենթադրել, որ այն համընկնում է գեներատորում կարգավորվածի հետ։

Հաշվետվությունը «տրաֆիկի պրոֆիլ․ 30% HTTPS, 20% HTTP, 15% DNS…» արտահայտությամբ պետք է ներառի ստուգված չափում այն բանի, ինչ իրապես անցել է DUT-ով պրոտոկոլների մակարդակում՝ DUT-ի սեփական տրաֆիկի հաշվիչներից կամ թեստային պորտերի inline-չափումից։ Եթե չափված միքսը շեղվում է սահմանվածից համաձայնեցված թույլատրելիից ավելի, թեստն անվավեր է։

Առանց դրա վենդորների համեմատությունը մաթեմատիկապես անհիմն է։ Չի կարելի համեմատել A և B սարքերի արդյունքները, եթե ամեն մեկի իրական AppMix-ը տարբեր էր, նույնիսկ նույն նպատակային բաշխման դեպքում։

4. Պաշտպանության արդյունավետությունը ծանրաբեռնվածության տակ, ոչ իզոլյացիայում

Դետեկտի rate-ը և արգելափակման արդյունավետությունը չափում են արտադրողականության թեստի ընթացքում, ոչ դրանից առանձին։

Սցենարը հարձակումների տրաֆիկը մատուցում է լեգիտիմ հավելվածների տրաֆիկի ֆոնային հոսքի ներսում, մարտականին մոտ ծանրաբեռնվածության մակարդակով՝ սարքի անվանական throughput-ի 60–80%-ի վրա։ Դետեկտի rate-ը, արգելափակման rate-ը, false positive-ների rate-ը և հարձակման տակ պաշտպանության աշխատանքից latency-ի կամ throughput-ի ցանկացած փոփոխություն՝ այս ամենը գրանցվում է։

Սարքը, որ բռնում է հարձակումների 99%-ը պարապ ընթացքում և 65%-ը 75% ծանրաբեռնվածության դեպքում, տալիս է այլ պաշտպանության մակարդակ, քան ասում է վերնագրային թիվը։ Իզոլյացիայում թեստը դա թաքցնում է։

5. Մանրամասն հաշվետվություն ըստ պրոտոկոլների

Գումարային throughput-ը, գումարային latency-ն և ընդհանուր դետեկտի rate-ը արդյունքը չեն բացատրում։ Հաշվետվությունը պետք է ներառի․

• throughput և հաջողված տրանզակցիաների rate ըստ պրոտոկոլների (HTTPS առանձին HTTP-ից, DNS, SMTP և այլն);
• latency-ի բաշխումներ ըստ պրոտոկոլների՝ ոչ միայն միջինները, կարևոր են 95-րդ և 99-րդ պերցենտիլները;
• AppMix-ի ստուգված բաշխումը DUT-ի վրա;
• դետեկտի և արգելափակման rate ըստ հարձակումների կատեգորիաների;
• ձախողված տրանզակցիաների քանակ ըստ պրոտոկոլների տիպերի;
• սարքի ռեսուրսների օգտագործումը թեստի պատուհանում՝ CPU, հիշողություն, միաժամանակյա սեսիաների քանակ։

Մանրամասն հաշվետվությունը թույլ է տալիս հասկանալ, թե ինչու է սարքը տվել այդ արդյունքը, և կանխատեսել, արդյոք այն կպահվի ձեր մարտական տրաֆիկի պրոֆիլի տատանումների դեպքում։

Ճիշտ գործիքներ․ ինչու է դա կարևոր

Միայն մեթոդիկան քիչ է։ Տրաֆիկի գեներացիայի և չափման պլատֆորմը պետք է մեթոդիկան ճշգրիտ իրականացնի։

Պրոֆեսիոնալ կոմերցիոն պլատֆորմները՝ դրանց թվում Keysight BreakingPoint և CyPerf՝ ստեղծված են հենց այս դասի թեստերի համար։ Դրանք տրաֆիկ են գեներացնում ընթացքում, պահում են AppMix-ի վերահսկումը փակ ցիկլով, հարձակումներ են մատուցում լեգիտիմ տրաֆիկի ներսում և տալիս են պրոտոկոլների կտրվածքով մանրամասն վիճակագրություն՝ լրիվ հաշվետվության համար։ Խոշորագույն օպերատորները, ֆինանսական կազմակերպությունները և պետական կառույցները դրանք օգտագործում են ենթակառուցվածքի որակավորման համար հենց այն պատճառով, որ արդյունքները վերարտադրելի են և ստուգելի։

Open-source գործիքները փաթեթների գեներատորներ և բազային ծանրաբեռնման ծրագրեր են։ Իրենց խնդիրների համար դրանք օգտակար են։ Անվտանգության արտադրանքի գնահատման համար դրանք չեն հերիքում․ չկա L7-ի դինամիկ գեներացիա, չկա AppMix-ի հետադարձ կապ, չկա պրոտոկոլների վիճակագրություն DUT-ի մակարդակում, չկա հարձակումների ներդրված էմուլյացիա շրջանցումների տարբերակմամբ։ Դրանք թվեր են տալիս։ Հասկացողություն չեն տալիս։

Պրոֆեսիոնալ գործիքների և open-source-ի գնի տարբերությունն իրական է, բայց բազմամյա անվտանգության ենթակառուցվածքի պայմանագրի գնման սխալի արժեքի ֆոնին այն փոքր է։

Ինչ է անում TEST4NET-ը

TEST4NET-ը ցանցերի և անվտանգության թեստավորման անկախ լաբորատորիա է։ Աշխատանքները ֆիքսված արժեքով են, դրանք վճարում է գնման որոշում կայացնող կազմակերպությունը՝ առանց կոմերցիոն հարաբերությունների գնահատվող վենդորների հետ։

Թեստավորումն անցնում է Keysight BreakingPoint-ի և CyPerf-ի վրա․ տրաֆիկի դինամիկ գեներացիա, AppMix-ի վերահսկում փակ ցիկլով, լրիվ մանրամասն հաշվետվություն պրոտոկոլների բոլոր տիպերով։ Հարձակումների էմուլյացիան օգտագործում է ընթացքում գեներացված payload-ներ շրջանցումների կառավարվող տարբերակմամբ՝ ոչ ստատիկ PCAP-replay։

Ամեն աշխատանք սկսվում է թեստ-պլանով, որը համաձայնեցված և ֆիքսված է մինչև թեստերի մեկնարկը․ DUT-ի կոնֆիգուրացիա, տրաֆիկի պրոֆիլի պարամետրեր, նպատակային AppMix ստուգման մեթոդիկայով, pass/fail չափանիշներ, հաշվետվության ֆորմատ։ Թեստ-պլանը փաստաթուղթ է, որը պատկանում է գնորդին։ Եթե վենդորը կամ ինտեգրատորը վիճարկում է մեթոդիկան, գնորդն ունի պաշտպանելի գրառում այն մասին, թե ինչ է թեստավորվել և ինչպես։

Արդյունքների մեջ մտնում է․

• մեթոդիկայի փաստաթուղթ՝ ֆիքսված մինչև թեստերի սկիզբը;
• թեստերի հում տվյալներ՝ պրոտոկոլների կտրվածքով;
• AppMix-ի ստուգված չափումներ DUT-ից;
• վենդորների համեմատություն կողք կողքի՝ նույն պայմաններում;
• վերջնական հաշվետվություն գտածոներով, վերլուծությամբ և գնման առաջարկով՝ չափված տվյալների վրա։

TEST4NET-ը բերում է այն, ինչ վենդորը և ինտեգրատորը կառուցվածքային առումով բերել չեն կարող․ արդյունքի վրա խաղադրույքի բացակայությունը։

Մինչև պայմանագիրը ստորագրելը

Անկախ թեստի ներդրումը 3–5 տարվա անվտանգության ենթակառուցվածքի պարտավորության արժեքի մի մասն է, եթե այն ընտրված է վենդորի տակ ստացված արդյունքներով։ Հարցը ոչ թե այն է, արդյոք կարող եք թույլ տալ ձեզ անկախ թեստ։ Հարցն այն է, արդյոք կարող եք թույլ տալ ձեզ բաց թողնել այն։

Եթե ձեր կազմակերպությունը պլանավորում է NGFW-ի, WAF-ի, DLP-ի, IPS-ի կամ SASE-ի գնահատում և ուզում է մեթոդիկա արդյունքներով, որոնք կարելի է պաշտպանել տնօրենների խորհրդի, աուդիտորների և շահագործման ծառայության առջև՝ խոսեք TEST4NET-ի հետ մինչև PoC-ի մեկնարկը։

Հաջորդը շարքում՝ Գրառում 6՝ ինչու է մեկ գնահատումը քիչ՝ մշտական ստուգում անվտանգության պլատֆորմի ողջ կյանքի ցիկլի ընթացքում։

Ամբողջ շարքը՝ Գրառում 1 · Գրառում 2 · Գրառում 3 · Գրառում 4 · Գրառում 5 · Գրառում 6