Toto je druhé pokračování článku Příručka našeho zákazníka I – Jaký penetrační test nebo bezpečnostní audit potřebuji? (RFI).

Chci nabídku, co ode mě potřebujete? (RFP)

Pokud již přesně víte, o jaké penetrační testy nebo bezpečnostní audity máte zájem, tak nás neváhejte kontaktovat. Můžete to učinit i bezpečným, šifrovaným způsobem – zaslat nám S/MIME nebo PGP šifrovanou zprávu (naše klíče naleznete zde) nebo nás kontaktovat přes aplikaci Signal (na čísle uvedeném v našich oficiálních kontaktech).

Abychom vám dokázali vytvořit cenovou nabídku, tak budeme od vás potřebovat pár informací.

Standardní penetrační testy nabízíme za fixní cenu, která reflektuje naši fixní pracnost. Je nutné podotknout, že tento druh penetračních testů je určen skutečně pro jednoduché weby nebo aplikace, případně pro získání odpovědi na otázku “Dokáže cílený útočník vyhackovať můj web během tří dnů?”. Je ale vysloveně nevhodný pro větší nebo komplexní aplikace.

Odhad pracnosti detailního bezpečnostního auditu webové aplikace dokážeme realizovat třemi způsoby. Pro vás nejjednodušší (a pro nás nejrychlejší) způsob je takový, že nám vytvoříte testovací účet do vaší aplikace, kterou chcete otestovat. Pro realizaci testůz pohledu uživatelů s různými rolemi, tak potřebujeme samostatný testovací účet pro každou roli. Toto nám pak stačí, abychom odhadli komplexnost samotné aplikace a tedy i naši předpokládanou pracnost a výslednou cenu. Bohužel ne vždy dokážeme získat testovací přístup do testované aplikace (například proto, že uvedená aplikace může být ještě ve vývoji). V tomto případě existují další dva způsoby, jak odhadnout komplexnost uvedené aplikace a tedy naši samotnou pracnost. První způsob je, že nám pošlete veškerou technickou dokumentaci, kterou k aplikaci máte. Ideálně zátoveň se screenshoty a detailními popisy každého formuláře. Druhý způsob je, že nám odpovíte na sadu našich specifických otázek, které vám zašleme, a které se týkají samotné aplikace:

• jaký je odhadem počet stránek řešení? (Tj unikátních “obrazovek”, nebo “routes”)
• jaký je zhruba počet formulářových vstupů? (Tj vstupních “políček” na celém webu)
• používá se SSL?
• používá se autentifikace (testuje se ovęřena část webu)?
• pokud ano, používá se vícefaktorová autentifikace?
• používá se captcha?
• víte stručně popsat účel a funkcionalitu aplikace 2-3 větami?
• jaký je počet uživatelských rolí (z pohledu nichž testuje)? Pokud jsou role variabilní, doporučujeme vytvořit 3-4 role – nejméně a nejvíce oprávněnou, nejvíce exponovanou apod.
• používá se někde v řešení technologie náchylná na problémy se správou paměti na straně serveru? (C / C ++)
• používá se v řešení tlustý klient (Java applety, Silverlight, Flash, ActiveX, …)?
• přejete si aplikaci testovat na DoS zranitelnosti (ne DDoS)?
• používají se HTML5 features, např. web sockets, local storage atd.?
• vystavuje aplikace vlastní webové služby (SOAP nebo REST), jiné než ty, které konzumuje frontend (např. pro integraci třetích stran)?
  • prosím, dodejte nám dokumentaci těchto API ve standardním formátu (WSDL, Swagger, Postman, API Blueprint, …)
  • pokud to není možné, kolik operací s kolika parametry tyto API implementují?
  • je k těmto webovým službám k dispozici klient (např. javascript web, mobilní aplikace, nebo alespoň SOAP UI projekt), který dokáže generovat legitimní požadavky na API?
  • jakým způsobem je řešena autentifikace?
• testování je možné i na dálku nebo je potřeba být fyzicky u zákazníka?
• jaký má být jazyk výsledné zprávy?
• kde bude aplikace hostovaná během testu, na vlastním hw / VPS / cloud / sdílený hosting (kvůli souhlasu resp. omezením provozovatele)?
• na jakém prostředí se testuje (DEV / TEST, INT / UAT, PROD … (doporučeno 1:1 kopie produkce bez “ostrých” dat, dedikovaná jen pro penetrační testy)
• jaký je preferovaný termín testování?

Na základě nich dokážeme pak odhadnout naši výslednou pracnost a tedy i výslednou cenu.

Pokud máte zájem o testy mobilních aplikací, pak ideálně potřebujeme tyto aplikace také vidět (nemusí být nutně v Google / iOS repozitáři, stačí binární APK) nebo poslat k nim veškerou dostupnou technickou dokumentaci. Také potřebujeme detailní popis webových služeb, které daná mobilní aplikace používá (například Swagger specifikaci). Tento krok není nutný, pokud chcete blackbox testování samotné aplikace (v tomto případě si samotné používané metody, jejich vstupy a výstupy sami zjistíme odposlechem komunikace samotné aplikace).

Při externích penetračních testech potřebujeme vědět počet testovaných IP adres nebo IP rozsahů, ideálně pokud je možné specifikovat i použité operační systémy nebo typy síťových zařízení. Také nám pomůže mapa síťové architektury (není nutná při blackbox testech). V případě, že vyžaduje zcela blackbox testy a nechcete nám sdělovat žádné informace o zkoušené infrastruktuře, tak to je také možné – v tomto případě použijeme ale horní cenový odhad pro externí penetrační testy.

Při interních penetračních testech potřebujeme také vědět počet testovaných IP adres nebo IP rozsahů (případně i počet lokalit, pokud testování probíhá “onsite”). Pokud provozujete nějaké velmi staré systémy, kde je pravděpodobné, že spadnou při agresivním scanu (tato situace sama o sobě představuje bezpečnostní riziko a neměla by ani nastat), tak je možné nám dodat jejich seznam IP adres a my jejich při testování vynecháme.

U všech výše uvedených testů platí, že když chcete realizovat agresivní DoS (Denial Of Service) testy, tak je možné se dohodnout na přesném čase testování (například v neděli o 4:00 ráno.

Někteří zákazníci chtějí realizovat distribuované DoS útoky (DDoS). Zde je třeba podotknout, že tyto testy mají smysl pouze tehdy, pokud jsou realizovány z tisíců různých IP adres. Které obvykle žádná IT security firma nevlastní. Toto dokážeme vyřešit způsobem, že od cloudových poskytovatelů (například Amazon) zakoupíme na dohodnutou dobu testů tisíce virtuálních serverů s tisíci IP adres. Uvedené řešení ale vyžaduje extra náklady potřebné na objednání a provoz těchto tisíc serverů. Proto obvykle distribuované DoS útoky nerealizujeme. Namísto toho realizujeme tzv. aplikační DoS testy, jejichž cílem je otestovat zda dokážeme uvedenou aplikaci nebo systém shodit z běžného domácího internetového připojení. Je třeba poznamenat, že dostatečné silné distribuované DoS útoky dokáží shodit prakticky jakoukoliv internetovou službu a může být velmi problematické se vůči nim bránit (v případě takového rizika proto doporučujeme použít řešení jako například CloudFlare).

Po dohodě s našimi etickými hackery a podle jejich časových možností vám spolu s naší vypracovanou nabídkou umíme dát přesně vědět, kdy se do samotného testování dokážeme pustit. Nejvíce přetížení jsme koncem roku, nejméně na jaře nebo uprostřed léta. Nejlepší dostupnost máme při provádění webových testů, které dokáží realizovat všichni naši etičtí hackeři. Nejnižší dostupnost máme v případě úzce specializovaných bezpečnostních testů, které vyžadují speciální znalosti a umějí je realizovat jen úzce profilování experti. Specializované testy doporučujeme proto zarezervovat pár týdnů až měsíců dopředu.

Poslední věc, kterou potřebujeme vědět, je v jakém jazyce má být vytvořena samotná nabídka i výsledná zpráva (v případě angličtiny to víme pokrýt největším množstvím testerů).

Po zaslání veškerých informací potřebných pro odhad pracnosti samotného testování vám během nejbližších dnů vyhotovíme profesionální cenovou nabídku. Nabídku standardně vyhotovujeme buď v češtině nebo v angličtině, v případě potřeby ji umíme vyhotovit i v jiném jazyce.

Rozhodl jsem se pro vaše služby, pojďme do toho!

Pokud vás naše nabídka oslovila, kontaktujte nás, ideálně (šifrovaným) emailem.

Nastal čas pro  vypracování a podpis smlouvy, kterou nám udělujete souhlas s provedením penetračních testů nebo bezpečnostních auditů vašich aplikací, systémů či síťové infrastruktury.

Za 14 let naší existence jsme různými iteraci dospěli k rozsáhlé 17 stranné “Smlouvě o zhodnocení bezpečnosti” (k dispozici máme také anglickou verzi “Vulnerability Assessment Agreement”), kde jsou obsaženy všechny potřebné informace na bezproblémové zahájení testování a popsány prakticky všechny možné nestandardní situace, které během testování může nastat. Od přesného data, kdy bude provedeno testování, přes přesný předmět a rozsah samotného testování, typy testů až po popis použité metodologie. Smlouva definuje přesně práva a povinnosti nás i našich zákazníků. V případě, že si od nás objednáte jen krátký standardní penetrační test, tak vám v rámci minimalizace byrokracie dokážeme poskytnout zjednodušenou verzi této rozsáhlé smlouvy.

Množství našich zákazníků vyžaduje podepsání smlouvy o mlčenlivosti (tzv. NDA). V tomto případě je možné použít naši šablonu NDA smlouvy nebo dokážeme použít vaši NDA smlouvu, pokud na tom trváte. V tomto případě ale všechny nové smlouvy (nejen NDA) podléhají kontrole našeho právního oddělení, které potřebuje pár dní na jejich analýzu a zapracování připomínek. Je třeba podotknout, že někteří naši zákazníci mají nerealistická očekávání v NDA smlouvě – například chtějí smlouvu o mlčenlivosti podepsat na dobu neurčitou nebo navrhují obrovské smluvní pokuty, které jsou při objemu objednaných služeb, zcela neadekvátní.

Co všechno víme a co nevíme garantovat našim zákazníkům najdete v tomto článku.

Pokud máte speciální požadavky na provedení testů nebo na smlouvu o mlčenlivosti, tak je nutno počítat s tím, že podpis samotné smlouvy se může o několik dní posunout (v tomto případě propojíme naše právní oddělení s vaším právním oddělením). Tento problém nemusíte mít, pokud se rozhodnete použít naše stávající vyladěné smlouvy. Upřímně se snažíme o to, aby naše smlouvy nebyly jednostranné a byly oboustranně vyvážené. Jako zákazníka vás totiž chceme nejen nyní, ale i v budoucnosti.

Ve smlouvě je třeba také uvést kontaktní údaje na vašie aplikační a systémové administrátory. Pro případ, že by nám testovaná aplikace spadla nebo přestala fungovat (nestává se to často, ale může se to stát).

Smlouva specifikuje například i to, kdy a zda vůbec budou realizovány agresivní DoS testy (pokud je zákazník vyžaduje).

Na otestávaní potřebujeme dodat v šifrované formě minimálně dva testovací účty, které budeme během testování využívat. Jde minimálně o dva různé testovací účty pro každou testovanou roli (to je nutné, abychom korektně otestovali vertikální a horizontální eskalaci privilegií v případě testování autorizace). Chcete-li svou aplikaci otestovat úplně, tak potřebujeme disponovat všemi uživatelskými účty, které dokáží funkčně pokrýt všechny formuláře testované aplikace.

Po podepsání samotné smlouvy zákazníkovi automaticky garantujeme, že v době dohodnutého testování mu rezervujeme několik našich dedikovaných testerů. Jelikož naši testeři participují na různých projektech různé zákazníky v různém čase, je třeba aby nám zákazník umožnil plnohodnotné testování v dohodnutém čase.

Jelikož množství našich testerů je ze zahraničí a nemluví česky, jen anglicky, tak v případě, že se rozhodnete pro angličtinu, tak vám dokážeme zabezpečit největší dostupnost.

Jak připravím testovací prostředí a testovací účty

Nedostatečně připravené testovací prostředí ze strany zákazníka je bohužel často kámen úrazu, kvůli kterému se nedokážeme včas pustit do testů (a častokrát následně stihnout slíbený deadline testování). Pokud totiž nestihneme deadline nikoli našim zaviněním, tak do pokračování testů se můžeme pustit až když naši testeři budou mít opět čas. To zákazníka může stát další peníze a čas a snažíme se tomu předejít.

Proto je velmi důležité, aby zákazník připravil včas a pořádně prostředí, které má být předmětem našich testů. Jelikož agresivní penetrační testování může způsobit pád systémů, aplikací, či poškození dat, tak preferujeme provádění testů primárně v testovacím nebo předprodukčním prostředí (to je takové, které je co nejvíce identické s produkčním prostředím). Souvisí to také s tím, že chceme minimalizovat jakoukoliv odpovědnost za škody způsobené našim testováním, které principiálně nemůžeme nést. Pokud se zákazník bojí, že naše testování způsobí výpadek jeho služeb nebo poškození dat, tak by měl udělat vše proto, aby měl k dispozici testovací nebo předprodukční prostředí, kde můžeme provést potenciálně agresivní testování. Jestliže toto nedokáže zajistit a vyžaduje testování v produkčním prostředí (což se nám bohužel někdy stává), tak by měl mít k dispozici aktuální zálohy a během testování k dispozici svého aplikačního nebo systémového administrátora, kterému dokážeme kdykoliv zavolat, když nám testována aplikace vypadne nebo přestane normálně reagovat.

Také je důležité, aby během testování zákazník testované prostředí nijak neměnil či neaktualizoval, což může způsobit nekonzistence našich odhalených nálezů.

Zákazník by podle podepsané smlouvy měl zajistit k datu spuštění samotného testování přístup všem našim penetračním testerem – ověřit zda funguje VPN spojení, které nám poskytl i samotné testovací účty. Pokud samotné přihlašování vyžaduje druhý faktor (OTP kalkulačku nebo hardwarový token), tak je nutné, aby nám ho včas doručil.

Testování úspěšně probíhá, co mám čekat?

Po zajištění testovacího prostředí a testovacích účtů se ve finále pouštíme do testů. Pokud jde o testování v testovacím nebo předprodukční prostředí, tak naši testeři provádějí testy prakticky nonstop (preferovaná situace).

Pokud jde o testování produkčního prostředí, tak se můžeme přizpůsobit časovým požadavkům zákazníka (někteří vyžadují testování mimo pracovní provoz, aby testování negativně neovlivňovalo funkčnost testované aplikace, někteří naopak vyžadují testování během pracovního provozu, aby administrátoři a vývojáři aplikace u zákazníka dokázali okamžitě reagovat na případné otázky ze strany našich testerů).

Pokud během testování odhalíme kritické zranitelnosti v testované aplikaci, systému nebo v infrastruktuře, které by mohly vést k úniku citlivých informací nebo neúčinnost, tak okamžitě kontaktujeme (telefonicky nebo e-mailem) zákazníka a požádáme ho bezprostřední opravu.

Kritické jakož i všechny méně kritické zranitelnosti naši testeři zahrnou do výsledné zprávy, která je na konci testování zaslána a představena zákazníkovi (dokud je to možné, tak v šifrované formě).

Výsledná zpráva

Na konci každého penetračního testu nebo bezpečnostního auditu, od nás obdržíte profesionálně vypracovanou výslednou zprávu (v angličtině nebo jiném podporovaném jazyce).

Výsledná zpráva obsahuje na začátku manažerské shrnutí a výsledky testů pro jednotlivé aplikace, služby či systémy. Výsledky obsahují seznam odhalených zranitelností seřazených podle stupně závažnosti – od kritických zranitelnosti, přes zranitelnosti s vysokým, středním a nízkým stupněm závažnosti. Ke každé odhalené zranitelnosti je uveden detailní popis, stupeň závažnosti a řešení jak uvedenou zranitelnost opravit. Pokud uvedenou zranitelnost není jednoduché opravit, tak uvedeme také “workaround”, který umožní negativní dopad dané zranitelnosti co nejvíce minimalizovat. Každá zranitelnost obsahuje také volitelné odkazy na CVE, či jiný standardizovaný nebo komunitní popis.

Detailní bezpečnostní audit obsahuje v ceně i osobní prezentaci výsledků, kterou lze udělat i online a případně si ji doobjednat pro jakýkoli jiný provedený test. V této prezentaci naši testeři vysvětlí vývojářům aplikace nebo správci systému, jak je možné odhalené zranitelnosti zneužít a samozřejmě i jak je opravit, případně jak je možné v budoucnu uvedeným zranitelnostem (bezpečnostním chybám) předcházet.

Výsledná zpráva je platná k datu předání zákazníkovi. Bohužel po tomto čase nedokážeme garantovat, že se neobjeví nějaká nová kritická zranitelnost, která bude zneužita. Proto doporučujeme provádět opakované testy a aplikaci také zařadit do bug bounty programu.

Ve třetí následující části článku si řekneme něco o tom, jak fungují opakované penetrační testy, bug bounty programy, jaké technologické certifikáty na etické hackování jsou nejlepší a také o tom, jaké jsou výhody svobodné voluntaryistickej firmy jako je ta naše.