Toto je druhé pokračovanie článku Príručka nášho zákazníka I – Aký penetračný test alebo bezpečnostný audit potrebujem? (RFI).

Chcem ponuku, čo odo mňa potrebujete? (RFP)

Ak už presne viete, o aké penetračné testy alebo bezpečnostné audity máte záujem, tak nás neváhajte kontaktovať. Môžete to učiniť aj bezpečným šifrovaným spôsobom – zaslať nám S/MIME alebo PGP šifrovanú správu (naše kľúče nájdete tu) alebo nás kontaktovať cez aplikáciu Signal (na čísle uvedenom v našich oficiálnych kontaktoch).

Aby sme vám dokázali vytvoriť cenovú ponuku, tak budeme od vás potrebovať pár informácií.

Štandardné penetračné testy ponúkame za fixnú cenu, ktorá reflektuje našu fixnú pracnosť. Je nutné podotknúť, že tento druh penetračných testov je určený skutočne pre jednoduché weby alebo aplikácie, prípadne pre získanie odpovede na otázku “Dokáže cielený útočník vyhackovať môj web behom troch dní?”. Je ale vyslovene nevhodný pre väčšie alebo komplexné aplikácie.

Odhad pracnosti detailného bezpečnostného auditu webovej aplikácie dokážeme realizovať tromi spôsobmi. Pre vás najjednoduchší (a pre nás najrýchlejší) spôsob je taký, že nám vytvoríte testovací účet do vašej aplikácie, ktorú chcete otestovať. Ak chcete testovanie realizovať z pohľadu používateľov s rôznymi rolami, tak potrebujeme samostatný testovací účet pre každú rolu. Toto nám potom stačí, aby sme odhadli komplexnosť samotnej aplikácie a teda aj našu predpokladanú pracnosť a výslednú cenu. Bohužiaľ nie vždy dokážeme získať testovací prístup do testovanej aplikácie (napríklad uvedená aplikácia môže byť ešte vo vývoji). V tomto prípade existujú ďalšie dva spôsoby ako odhadnúť komplexnosť uvedenej aplikácie a teda našu samotnú pracnosť. Prvý spôsob je, že nám pošlete všetku technickú dokumentáciu, ktorú k aplikácii máte. Ideálne rovno so screenshotmi a detailnými popismi každého formulára. Druhý spôsob je, že nám odpoviete na sadu našich špecifických otázok, ktoré vám zašleme, a ktoré sa týkajú samotnej aplikácie:

• aký je odhadom počet stránok riešenia? (t.j. unikátnych “obrazoviek”, alebo “routes”)
• aký je zhruba počet formulárových vstupov? (t.j. vstupných “políčok” na celom webe)
• používa sa SSL?
• používa sa autentifikácia (testuje sa autentifikovaná časť webu)?
  • ak áno, používa sa viacfaktorová autentifikácia?
• používa sa captcha?
• viete stručne popísať účel a funkcionalitu aplikácie 2-3 vetami?
• aký je počet používateľských rolí (z pohľadu ktorých sa testuje)? Ak sú role variabilné, odporúčame vytvoriť 3-4 role – najmenej a najviac oprávnenú, najviac exponovanú a pod.
• používa sa niekde v riešení technológia náchylná na problémy so správou pamäte na strane servera? (C/C++)
• používa sa v riešení tučný klient (Java applety, Silverlight, Flash, ActiveX, …)?
• prajete si aplikáciu testovať na DoS zraniteľnosti (nie DDoS)?
• používajú sa HTML5 features, napr. web sockets, local storage, atď.?
• vystavuje aplikácia vlastné webové služby (SOAP alebo REST), iné ako tie, ktoré konzumuje frontend (napr. pre integráciu tretích strán)?
  • prosím, dodajte nám dokumentáciu týchto API v štandardnom formáte (WSDL, Swagger, Postman, API Blueprint, …)
  • ak to nie je možné, koľko operácií s koľkými parametrami tieto API implementujú?
  • je k týmto webovým službám k dispozícii klient (napr. javascript web, mobilná aplikácia, alebo aspoň SOAP UI projekt), ktorý dokáže generovať legitímne požiadavky na API?
  • akým spôsobom je riešená autentifikácia?
• testovanie je možné aj na diaľku alebo je potrebné byť fyzicky u zákazníka?
• aký má byť jazyk výslednej správy?
• kde bude aplikácia hostovaná počas testu, na vlastnom hw/VPS/cloud/zdieľaný hosting (kvôli súhlasu resp. obmedzeniam prevádzkovateľa)?
• na akom prostredí sa testuje (DEV/TEST, INT/UAT, PROD… (odporúča sa 1:1 kópia produkcie bez “ostrých” dát, dedikovaná len pre penetračné testy))
• aký je preferovaný termín testovania?

Na základe nich dokážeme potom odhadnúť našu výslednú pracnosť a teda výslednú cenu. 

Ak máte záujem o testy mobilných aplikácií, tak potrebujeme tie aplikácie ideálne tiež vidieť (nemusia byť nevyhnutne v Google/iOS repozitári, stačí binárne APK) alebo poslať k nim všetku dostupnú technickú dokumentáciu. Tiež potrebujeme detailný popis webových služieb, ktoré daná mobilná aplikácia používa (napríklad Swagger špecifikáciu). Tento krok nie je potrebný, ak chcete blackbox testovanie samotnej aplikácie (v tomto prípade si samotné používané metódy, ich vstupy a výstupy sami zistíme odpočúvaním komunikácie samotnej aplikácie).

Pri externých penetračných testoch potrebujeme vedieť počet testovaných IP adries alebo IP rozsahov, ideálne ak je možné špecifikovať aj použité operačné systémy alebo typy sieťových zariadení. Tiež nám pomôže mapa sieťovej architektúry (nie je potrebná pri blackbox testoch).  V prípade, že vyžaduje úplne blackbox testy a nechcete nám povedať žiadne informácie o testovanej infraštruktúre, tak to je tiež možné – v tomto prípade použijeme ale horný cenový odhad externých penetračných testov.

Pri interných penetračných testoch potrebujeme tiež vedieť počet testovaných IP adries alebo IP rozsahov (prípadne aj počet lokalít, ak testovanie prebieha “onsite”). Ak prevádzkujete nejaké veľmi staré systémy, kde je pravdepodobné, že spadnú pri agresívnom scane (táto situácia sama o sebe predstavuje bezpečnostné riziko a nemala by ani nastať), tak je možné nám dodať ich zoznam IP adries a my ich pri testovaní vynecháme.

V prípade všetkých vyššie uvedených testoch platí, že keď chcete realizovať agresívne DoS (Denial Of Service) testy, tak je možné sa dohodnúť na presnom čase testovania (napríklad v nedeľu o 4:00 ráno.

Niektorí zákazníci chcú realizovať distribuované DoS útoky (DDoS). Tu je potrebné podotknúť, že tieto testy majú zmysel iba vtedy, ak sú realizované z tisícok rôznych IP adries. Ktoré obvykle žiadna IT security firma nevlastní. Toto dokážeme vyriešiť spôsobom, že od cloudových poskytovateľov (napríklad Amazon) zakúpime na dohodnutú dobu testov tisícky virtuálnych serverov s tisíckami IP adries. Uvedené riešenie ale vyžaduje extra náklady potrebné na objednanie a prevádzku týchto tisíc serverov. Preto obvykle distribuované DoS útoky nerealizujeme. Namiesto toho realizujeme tzv. aplikačné DoS testy, ktorých cieľom je otestovať či dokážeme uvedenú aplikáciu alebo systém zhodiť z bežného domáceho internetového pripojenia. Je potrebné poznamenať, že dostatočné silné distribuované DoS útoky dokážu zhodiť prakticky akúkoľvek internetovú službu a môže byť veľmi problematické sa voči nim brániť (v prípade takéhoto rizika preto odporúčame použiť riešenia ako napríklad Cloudflare).

Po dohode s našimi etickými hackermi a podľa ich časových možností vám spolu s našou vypracovanou ponukou vieme dať presne vedieť, kedy sa do samotného testovania dokážeme pustiť. Najviac preťažení sme koncom roka, najmenej na jar alebo uprostred leta. Najlepšiu dostupnosť máme pri vykonávaní webových testoch, ktoré dokážu realizovať všetci naši etickí hackeri. Najnižšiu dostupnosť máme pri úzko špecializovaných bezpečnostných testoch, ktoré vyžadujú špeciálne znalosti a vedia ich realizovať len úzko profilovaní experti. Špecializované testy odporúčame preto zarezervovať pár týždňov až mesiacov dopredu. 

A posledná vec, ktorú potrebujeme vedieť, je v akom jazyku má byť vytvorená samotná ponuka aj výsledná správa (v prípade angličtiny to vieme pokryť najväčším množstvom testerov).

Po tom, ako nám zašlete všetky informácie potrebné na odhad pracnosti samotného testovania vám behom najbližších dní vyhotovíme profesionálnu cenovú ponuku. Ponuku štandardne vyhotovujeme buď v slovenčine alebo v angličtine, v prípade potreby ju vieme vyhotoviť aj v inom jazyku.

Rozhodol som sa pre vaše služby, poďme do toho!

Ak vás naša ponuka oslovila, tak nám dajte spätne vedieť, ideálne (šifrovaným) emailom. 

Nastal čas na spripomienkovanie a podpis zmluvy, ktorou nám udeľujete súhlas s vykonaním penetračných testov alebo bezpečnostných auditov vašich aplikácií, systémov či sieťovej infraštruktúry.

Za 14 rokov našej existencie sme rôznymi iteráciami dospeli k rozsiahlej 17 stranovej “Zmluve o zhodnotení bezpečnosti” (k dispozícii máme aj anglickú verziu “Vulnerability Assessment Agreement”), kde sú obsiahnuté všetky potrebné informácie na bezproblémové začatie testovania a popísané prakticky všetky možné neštandardné situácie, ktoré počas testovania môže nastať. Od presného dátumu, kedy bude vykonané testovanie, cez presný predmet a rozsah samotného testovania, typy testov až po popis použitej metodológie. Zmluva definuje presne práva a povinnosti nás aj našich zákazníkov. V prípade, že si od nás objednáte len krátky štandardný penetračný test, tak vám v rámci minimalizácie byrokracie dokážeme poskytnúť zjednodušenú verziu tejto rozsiahlej zmluvy.

Množstvo našich zákazníkov vyžaduje podpísanie zmluvy o mlčanlivosti (tzv. NDA). V tomto prípade je možné použiť našu šablónu NDA zmluvy alebo dokážeme použiť aj vašu NDA zmluvu, ak na tom trváte. V tomto prípade ale všetky nové zmluvy (nielen NDA) podliehajú kontrole nášho právneho oddelenia, ktoré potrebuje pár dní na ich analýzu a zapracovanie pripomienok. Je potrebné podotknúť, že niektorí naši zákazníci majú nerealistické očakávania v NDA zmluve – napríklad chcú zmluvu o mlčanlivosti podpísať na dobu neurčitú alebo navrhujú obrovské zmluvné pokuty, ktoré sú pri objeme objednaných služieb, úplne neadekvátne. 

Čo všetko vieme a čo nevieme garantovať našim zákazníkom nájdete v tomto článku.

Ak máte špeciálne požiadavky na vykonanie testov alebo na zmluvu o mlčanlivosti, tak treba počítať s tým, že podpis samotnej zmluvy sa môže o niekoľko dní posunúť (v tomto prípade prepojíme naše právne oddelenie s vašim právnym oddelením). Tento problém nemusíte mať, ak sa rozhodnete použiť naše existujúce vyladené zmluvy. Úprimne sa snažíme o to, aby naše zmluvy neboli jednostranné a boli obojstranne vyvážené. Ako zákazníka vás totiž chceme nielen teraz, ale aj v budúcnosti.

V zmluve je potrebné tiež uviesť kontaktné údaje na vašich aplikačných a systémových administrátorov. Pre prípad, že by nám testovaná aplikácia spadla alebo prestala fungovať (nestáva sa to často, ale môže sa to stať). 

Zmluva špecifikuje napríklad aj to, kedy a či vôbec budú realizované agresívne DoS testy (ak ich zákazník vyžaduje).

Na vykonanie testov potrebujeme dodať v šifrovanej forme minimálne dva testovacie účty, ktoré budeme počas testovania využívať. Ide minimálne o dva rôzne testovacie účty pre každú testovanú rolu (to je potrebné, aby sme korektne otestovali vertikálnu a horizontálnu eskaláciu privilégií v prípade testovania autorizácie). Ak chcete svoju aplikáciu otestovať úplne, tak potrebujeme disponovať všetkými používateľskými účtami, ktoré dokážu funkčne pokryť všetky formuláre testovanej aplikácie.

Po podpísaní samotnej zmluvy zákazníkovi automaticky garantujeme, že v čase dohodnutého testovania mu rezervujeme našich dedikovaných testerov. Keďže naši testeri participujú na rôznych projektoch rôznych zákazníkov v rôznom čase, je potrebné aby nám zákazník umožnil plnohodnotné testovanie v dohodnutom čase.

Keďže množstvo našich testerov je zo zahraničia a nehovorí slovensky, len anglicky, tak v prípade, že sa rozhodnete pre angličtinu, tak vám dokážeme zabezpečiť najväčšiu dostupnosť.

Ako pripravím testovacie prostredie a testovacie účty

Nedostatočne dobre pripravené testovacie prostredie zo strany zákazníka je bohužiaľ často kameň úrazu, kvôli ktorému sa nedokážeme včas pustiť do testov (a častokrát následne stihnúť deadline testovania). Ak totiž nestihneme deadline nie našim zavinením, tak do pokračovania testov sa vieme pustiť až keď naši testeri budú mať opäť čas. Čo zákazníka môže stáť ďalšie peniaze a čas.

Preto je veľmi dôležité, aby zákazník pripravil včas a poriadne prostredie, ktoré má byť predmetom našich testov. Keďže agresívne penetračné testovanie môže spôsobiť pád systémov, aplikácií, či poškodenie dát, tak preferujeme vykonávanie testov primárne v testovacom alebo pred produkčnom prostredí (to je také, ktoré je čo najviac identické s produkčným prostredím). Súvisí to tiež s tým, že chceme minimalizovať akúkoľvek zodpovednosť za škody spôsobené našim testovaním, ktoré principiálne nemôžeme niesť. Ak sa zákazník bojí, že naše testovanie spôsobí výpadok jeho služieb alebo poškodenie dát, tak by mal spraviť všetko preto, aby mal k dispozícii testovacie alebo predprodukčné prostredie, kde môžeme vykonať potenciálne agresívne testovanie. Ak toto nedokáže zabezpečiť a vyžaduje testovanie v produkčnom prostredí (čo sa nám bohužiaľ niekedy stáva), tak by mal mať k dispozícii aktuálne zálohy a počas testovania k dispozícii svojho aplikačného alebo systémového administrátora, ktorému dokážeme kedykoľvek zavolať, keď nám testovaná aplikácia vypadne alebo prestane normálne reagovať.

Tiež je dôležité, aby počas testovania zákazník testované prostredie nijako nemenil či neaktualizoval, čo môže spôsobiť nekonzistenciu našich odhalených nálezov.

Zákazník by podľa podpísanej zmluvy mal zabezpečiť k dátumu spustenia samotného testovania prístup všetkým našim penetračným testerom – overiť či funguje VPN spojenie, ktoré nám poskytol ako aj samotné testovacie účty. Ak samotné prihlasovanie vyžaduje druhý faktor (OTP kalkulačku alebo hardvérový token), tak je potrebné, aby nám ho včas doručil.

Testovanie úspešne prebieha, čo mám čakať?

Po zabezpečení testovacieho prostredia a testovacích účtoch sa vo finále púšťame do testov. Ak ide o testovanie v testovacom alebo predprodukčnom prostredí, tak naši testeri vykonávajú testy prakticky nonstop (preferovaná situácia). 

Ak ide o testovanie produkčného prostredia, tak sa môžeme prispôsobiť časovým požiadavkám zákazníka (niektorí vyžadujú testovanie mimo pracovnej prevádzky, aby testovanie negatívne neovplyvňovalo funkčnosť testovanej aplikácie, niektorí naopak vyžadujú testovanie počas pracovnej prevádzky, aby administrátori a vývojári aplikácie u zákazníka dokázali okamžite reagovať na prípadné otázky zo strany našich testerov).

Ak počas testovania odhalíme kritické zraniteľnosti v testovanej aplikácii, systéme alebo v infraštruktúre, ktoré by mohli viesť k úniku citlivých informácií alebo znefunkčneniu, tak okamžite kontaktujeme (telefonicky alebo e-mailom) zákazníka. A požiadame ho bezprostrednú opravu.

Kritické ako aj všetky menej kritické zraniteľnosti naši testeri zahrnú do výslednej správy, ktorá je na konci testovania zaslaná a odprezentovaná zákazníkovi (pokým je to možné, tak v šifrovanej forme).

Výsledná správa

Na konci každého penetračného testu alebo bezpečnostného auditu, od nás obdržíte profesionálne vypracovanú výslednú správu (v angličtine alebo inom podporovanom jazyku).

Výsledná správa obsahuje na začiatku manažérske zhrnutie a výsledky testov pre jednotlivé aplikácie, služby či systémy. Výsledky obsahujú zoznam odhalených zraniteľností zoradených podľa stupňa závažnosti – od kritických zraniteľnosti, cez zraniteľnosti s vysokým, stredným a nízkym stupňom závažnosti. Ku každej odhalenej zraniteľnosti je uvedený detailný popis, stupeň závažnosti a riešenie ako uvedenú zraniteľnosť opraviť. Ak uvedenú zraniteľnosť nie je jednoduché opraviť, tak uvedieme tiež “workaround”, ktorý umožní negatívny dopad danej zraniteľnosti čo najviac minimalizovať. Každá zraniteľnosť obsahuje tiež voliteľné odkazy na CVE, či iný štandardizovaný alebo komunitný popis.

Detailný bezpečnostný audit obsahuje v cene aj osobnú prezentáciu výsledkov, ktorú je možné spraviť aj online a prípadne si ju doobjednať pre akýkoľvek iný vykonaný test. V tejto prezentácii naši testeri vysvetlia vývojárom aplikácie alebo systému, ako je možné uvedené odhalené zraniteľnosti zneužiť a samozrejme ako ich opraviť. Tiež ako je možné v budúcnosti predchádzať uvedeným zraniteľnostiam (bezpečnostným chybám).

Výsledná správa je platná k dátumu odovzdania zákazníkovi. Bohužiaľ po tomto čase nedokážeme garantovať, že sa neobjaví nejaká nová kritická zraniteľnosť, ktorá bude zneužitá. Preto odporúčame realizovať opakované testy a aplikáciu tiež zaradiť do bug bounty programu.

V tretej nasledujúcej časti článku si povieme niečo o tom, ako fungujú opakované penetračné testy, bug bounty programy, aké technologické certifikáty na etické hackovanie sú najlepšie a tiež o tom, aké sú výhody slobodnej voluntaryistickej firmy ako je tá naša.