Bezpečnostní přezkum, zpevnění nebo řízený test: jak vybrat

Co to je?

Security Baseline Review je vhodný k pochopení dohodnutého současného stavu; Website Hardening převádí potvrzené priority konfigurace na řízené změny; Application Security Review se zabývá vybranými otázkami bezpečnosti aplikace. Application Load & Stress Testing sleduje dohodnuté scénáře užívání, zatímco DDoS Resilience Testing zkoumá řízené podmínky odolnosti s hranicemi danými poskytovateli a bezpečností. Red Team Exercise je autorizované vzdělávací cvičení vedené cílem a řízené pravidly zapojení. Nejde o zaměnitelná označení. Report se zjištěními, změna konfigurace, pozorování výkonu, pozorování odolnosti a organizační vzdělávací cvičení odpovídají na různé otázky zákazníka. Invazivnější testování není automaticky užitečnější.

Pro koho to je?

Toto srovnání pomáhá zákazníkům, kteří:

• Mají obavu týkající se bezpečnosti nebo spolehlivosti, ale ještě si nejsou jisti, zda potřebují důkazy, implementaci, ověření nebo širší vzdělávací cvičení
• Potřebují pochopit, zda produkční systémy, poskytovatelé třetích stran, písemné oprávnění nebo bezpečnostní limity ovlivňují dostupné možnosti
• Chtějí porovnat výstupy a hranice dříve, než požádají dodavatele o vymezení práce
• Uvědomují si, že přezkum, změna zpevnění a řízený test mohou následovat po sobě, a nemusí se vzájemně vylučovat

Co to pomůže objasnit

Srovnání využijte k ujasnění:

• Zda je problém známý, nebo nejistý, a zda by další krok měl přinést důkazy, nebo provést dohodnutou změnu
• Zda je relevantním aktivem web, aplikace, konfigurace, zákaznická cesta, služba při očekávané zátěži, nebo cesta odolnosti
• Zda zakázka vyžaduje písemné oprávnění, souhlas poskytovatele, období zákazu testování, kontakty nebo podmínky okamžitého zastavení
• Jaký výsledek je užitečný nyní: report se zjištěními, záznam o změně, pozorování výkonu, pozorování odolnosti, nebo vyhodnocení připravené k rozhodnutí

Co je zahrnuto

• Srovnání výchozího přezkumu, zpevnění webu, přezkumu aplikace, řízeného zátěžového testování, testování odolnosti vůči DDoS a cvičení red teamu srozumitelným jazykem
• Rozhodovací faktory zahrnující nejistotu, důkazy versus implementaci, dopad na produkci, oprávnění, třetí strany a očekávané výstupy
• Doporučení k postupnému využití služeb tam, kde zdokumentovaný přezkum přirozeně připravuje pozdější řízenou práci
• Připomínka, že upřesnění rozsahu nebo discovery může být nejrozumnějším prvním krokem, pokud otázka ještě není ustálená

Co není součástí

• Univerzální doporučení služby, certifikace ani příslib, že kterákoli možnost odstraní veškeré riziko
• Doporučení provádět řízené testování bez potvrzeného oprávnění, bezpečných hranic, požadavků poskytovatele a rozsahu
• Provozní testovací taktiky, návody ke zneužití zranitelností, metody narušení ani návody k obcházení
• Tvrzení, že přezkum, zakázka zpevnění nebo cvičení zajistí soulad, dostupnost, výkon, odolnost nebo prevenci

Kdy si ji vybrat

Tohoto průvodce si přečtěte, když tým porovnává možnosti dříve, než zvolí zakázku. Je zvláště užitečný, když jedna zainteresovaná strana žádá „testování“, zatímco jiná žádá změnu konfigurace nebo písemné posouzení. Pokud jsou systémy, požadované rozhodnutí, vlastnictví nebo dostupné důkazy nejasné, mělo by výběru předcházet upřesnění rozsahu. Krátký rozhovor může zjistit, zda zákazník skutečně žádá přezkum současného stavu, řízenou implementaci, cílenou otázku k aplikaci, pozorování kapacity, posouzení odolnosti nebo cvičení vedené cílem.

Náš přístup

Začněte obchodním rozhodnutím a poté zužte technickou otázku. Sepište dotčené systémy, co je již známo, kdo je vlastní, zda by mohla být ovlivněna produkce a jak by vypadal užitečný výstup. Dále identifikujte oprávnění a třetí strany dříve, než budete diskutovat o jakémkoli řízeném testu. Výchozí přezkum může vytvořit důkazy pro zpevnění; zpevnění může předcházet pozdějšímu testu; pozorování zátěže může odhalit otázku infrastruktury; cvičení red teamu může být užitečné až poté, co cíle a řízení dozrají. Smyslem není vytvořit pevný žebříček. Jde o to zvolit přiměřený, autorizovaný další krok a pozdější práci vymezit samostatně. Zákazník si také může zaznamenat praktická omezení, která tuto volbu ovlivňují: dostupné důkazy, stáří systémů, podmínky dodavatelů, závazky vůči zákazníkům, pravděpodobné okno údržby a zda lze změnu bezpečně otestovat mimo produkci. Tato omezení sama o sobě službu nevyberou, ale pozdější rozsah díky nim bude pravdivější. Srovnání funguje dobře zejména tehdy, když je tým ochoten nechat otázku otevřenou, místo aby ji vtěsnal do nesprávného označení zakázky. Před navázáním kontaktu si připravte stručnou poznámku s datem rozhodnutí, dotčenými aktivy, obchodním vlastníkem, technickým vlastníkem, podstatnými dodavateli, aktuálními změnovými aktivitami a všemi známými limity přístupu. Tyto údaje nejsou důkazem problému; jsou kontextem, díky němuž může poskytovatel říci, kam se hodí standardní rozsah a kde je třeba ověřit předpoklad. Usnadňují také vyhnout se žádosti o široký test jen proto, že problém ještě nebyl formulován. Pokud existuje termín, vysvětlete, zda je obchodní, smluvní, provozní nebo regulatorní a co by rozhodnutí učinilo užitečným. Všichni pak mohou odlišit požadovaný výsledek od důkazů, které lze v odpovědném rozsahu skutečně shromáždit.

Často kladené otázky

Související články