Získání certifikace ISO 27001 pro vaši organizaci je trochu jako běh maratonu. Je to dlouhý a vyčerpávající proces dokumentace, psaní zásad a auditu, který se může zdát nekonečný. Ale pro většinu z nás v technologickém a bezpečnostním světě je skutečnou "horou" technická validační část. Můžete mít nejkrásnější příručku bezpečnostních zásad na světě, ale pokud náhodný script kiddie najde otevřený S3 bucket nebo SQL injection bod ve vaší primární aplikaci, váš Information Security Management System (ISMS) je v podstatě fikce.
Zde se cloudový Penetration Testing stává nutností, nikoli jen "příjemným doplňkem". Pokud usilujete o certifikaci ISO 27001, nekontrolujete jen políčko; snažíte se auditorovi dokázat, že skutečně víte, kde jsou vaše rizika, a že máte opakovatelný proces pro jejich nalezení a opravu. V cloudovém prostředí je to těžší, než se zdá. Perimetr je propustný, konfigurace se mění během sekund prostřednictvím Terraformu nebo CloudFormation a jediné špatně kliknuté zaškrtávací políčko v konzoli AWS nebo Azure může zpřístupnit celou vaši zákaznickou databázi veřejnému internetu.
Mnoho týmů dělá chybu, když si myslí, že skenování zranitelností je totéž co Penetration Test. Není. Sken vám řekne, že dveře jsou odemčené; Penetration Test vám řekne, že někdo může těmi dveřmi projít, najít serverovnu a ukrást korunovační klenoty. Pro ISO 27001, konkrétně v rámci kontrol přílohy A týkajících se správy zranitelností a technické shody, je prokázání, že jste provedli "etické hackování" nebo hloubkové testování, to, co dává auditorovi důvěru ve vaše bezpečnostní postavení.
V této příručce si rozebereme, jak přesně přistupovat ke cloudovému Penetration Testing, abyste splnili požadavky ISO 27001. Přejdeme od žargonu a podíváme se na praktické kroky, které musíte podniknout – od vymezení rozsahu vašich cloudových aktiv až po zpracování zpráv o nápravě, které budou auditoři skutečně chtít vidět.
Proč ISO 27001 vyžaduje více než jen základní skenování
ISO 27001 je rámec pro řízení rizik. Explicitně neříká "musíte provádět Penetration Test každé úterý", ale vyžaduje, abyste spravovali technické zranitelnosti. Pokud auditorovi řeknete, že jste "zabezpečeni", protože jste spustili automatizované skenování, zeptá se, jak validujete tato zjištění a jak testujete složité útočné řetězce, které skenery přehlédnou.
Rozdíl mezi skenováním a testováním
Většina společností se spoléhá na automatizované skenery zranitelností. Ty jsou skvělé pro nalezení zastaralých knihoven nebo chybějících záplat. Ale skenery jsou slepé k obchodní logice. Skenner si nevšimne, že uživatel může změnit své user_id v URL, aby viděl soukromé fakturační údaje jiného zákazníka. To je problém Broken Object Level Authorization (BOLA) a je to zlatý důl pro útočníky.
Cloudový Penetration Testing tuto mezeru vyplňuje. Zahrnuje člověka (nebo sofistikovanou platformu kombinující automatizaci s lidskou logikou), který se pokouší pivotovat vaší sítí. Například pentester může najít zranitelnost nízké závažnosti ve webové aplikaci, použít ji k získání opěrného bodu na kontejneru, objevit příliš permisivní roli IAM připojenou k tomuto kontejneru a poté použít tato oprávnění k výpisu celé vaší databáze RDS. Tento "útočný řetězec" je přesně to, co ISO 27001 chce, abyste identifikovali a zmírnili.
Mapování Penetration Testing na kontroly přílohy A
Pokud se díváte na aktualizované normy ISO 27001:2022, několik kontrol se silně opírá o výsledky Penetration Testing:
- A.8.8 Management of Technical Vulnerabilities: Toto je to hlavní. Musíte identifikovat zranitelnosti a přijmout vhodná opatření. Penetration Testing je zlatý standard pro "identifikaci" věcí, které software přehlédne.
- A.8.25 Secure Development Life Cycle: Pokud denně posíláte kód do cloudu, musíte prokázat, že bezpečnostní testování je součástí této smyčky.
- A.5.37 Compliance with Policies and Standards: Testování prokazuje, že vaše interní bezpečnostní zásady jsou skutečně dodržovány v produkčním prostředí.
V podstatě zpráva z Penetration Test slouží jako složka "důkazů" pro auditora. Dokazuje, že jen nehádáte, jaká je vaše bezpečnost – skutečně jste ji otestovali.
Vymezení rozsahu vašeho cloudového prostředí pro audit
Jednou z největších bolestí hlavy v cloudovém Penetration Testing je rozšiřování rozsahu. Začnete testováním jednoho API a najednou se snažíte testovat tři účty AWS, starší on-premise server a integraci SaaS třetí strany. Pro ISO 27001 musí být váš rozsah jasně definován, protože auditor zkontroluje, zda vaše testování odpovídá vašemu uvedenému "Statement of Applicability" (SoA).
Identifikace vašich "korunovačních klenotů"
Nemůžete testovat vše se stejnou intenzitou. Musíte stanovit priority. Začněte zmapováním toku dat. Kde žijí PII (Personally Identifiable Information)? Které služby zpracovávají platební údaje? Které API gateways jsou vystaveny veřejnosti?
V cloudovém kontextu by měl váš rozsah zahrnovat:
- Veřejně přístupné koncové body: Load balancery, API gateways a webové aplikace.
- Identity and Access Management (IAM): Toto je nový perimetr. Testování by se mělo zaměřit na to, zda kompromitovaný uživatelský účet může eskalovat oprávnění.
- Container Orchestration: Pokud používáte Kubernetes (EKS, GKE, AKS), konfigurace samotného clusteru je masivní útočný vektor.
- Serverless Functions: Lambda nebo Azure Functions mají často "skrytá" oprávnění, která lze zneužít.
- Storage Buckets: S3, Azure Blobs nebo Google Cloud Storage. Nesprávně nakonfigurované buckety jsou nejčastější příčinou narušení cloudových dat.
Definování "pravidel zapojení"
Než je odeslán jediný paket, potřebujete dokument Rules of Engagement (RoE). To je kritické pro ISO 27001, protože to ukazuje auditorovi, že máte kontrolovaný proces. RoE by měl odpovědět:
- Co je zakázané? (např. "Neprovádějte útoky typu Denial of Service na produkční databázi").
- Kdy může testování probíhat? (např. "Pouze mimo špičku" nebo "Kontinuální testování je povoleno").
- Kdo je kontaktní osoba? Pokud bezpečnostní tým zaznamená nárůst provozu, komu zavolá, aby ověřil, zda se jedná o pentestera a nikoli o skutečného útočníka?
- Jak bude nakládáno s daty? Pentesters najdou citlivá data. Jak jsou tato data šifrována a smazána po testu?
Výzva "Cloud Permission"
Před několika lety jste museli požádat AWS nebo Azure o povolení před zahájením Penetration Testing. Dnes většina velkých poskytovatelů cloudu uvolnila tato pravidla pro běžné služby. Stále však nemůžete provádět útoky DDoS nebo cílit na základní cloudovou infrastrukturu (hypervisory).
Pokud používáte platformu jako Penetrify, stává se to mnohem jednodušší. Protože se jedná o cloudovou platformu, je navržena tak, aby fungovala v rámci hranic těchto prostředí, což vám umožní škálovat vaše testování, aniž byste se museli obávat náhodného spuštění bezpečnostního bloku na úrovni poskytovatele.
Běžné cloudové zranitelnosti, které komplikují situaci kandidátům na ISO 27001
Až obdržíte zprávu z Penetration Testu, pravděpodobně uvidíte seznam zjištění. Abyste byli úspěšní ve své certifikaci, musíte je chápat nejen jako "chyby," ale jako selhání ve vašem ISMS.
1. Noční můra IAM (Privilege Escalation)
V cloudu je identita vším. Běžným zjištěním je "Příliš permisivní role IAM."
Představte si, že vývojář vytvoří roli pro jednoduchou aplikaci pro protokolování, ale udělí jí AdministratorAccess, protože to bylo jednodušší než zjistit konkrétní potřebná oprávnění. Pentester najde způsob, jak spustit jednoduchý příkaz v této aplikaci, ukradne dočasné bezpečnostní tokeny a najednou má plnou kontrolu nad celým vaším cloudovým účtem.
Z pohledu ISO 27001 se jedná o selhání zásady "Least Privilege". Oprava nespočívá pouze ve změně role; spočívá v zavedení procesu čtvrtletního přezkoumávání oprávnění IAM.
2. Rozrůstání Secretů
Pevně zakódované API klíče v GitHubu, hesla v proměnných prostředí nebo secrety uložené jako prostý text v konfiguračním souboru. Pentesters to milují. Najdou uniklý klíč, použijí ho pro přístup k databázi a během několika minut jsou uvnitř vaší sítě.
To poukazuje na mezeru ve vašich kontrolách "Secure Development". Abyste uspokojili auditora, měli byste přejít k nástroji pro správu secretů (jako je AWS Secrets Manager nebo HashiCorp Vault) a implementovat skenování, abyste zabránili tomu, aby byly secrety vůbec odeslány do kódu.
3. Nesprávně nakonfigurované S3 Buckety a Bloby
Všichni jsme viděli titulky. "Interní" bucket je omylem nastaven na "Public." Zatímco skenery je mohou najít, pentester vám ukáže přesně, jaká data lze exfiltrovat a jak lze tato data použít k zahájení dalších útoků.
Jedná se o selhání "Configuration Management". Náprava je často automatizovaná politika (jako AWS GuardDuty nebo Azure Policy), která zabraňuje tomu, aby byly buckety vůbec zveřejněny.
4. Nezabezpečené API Endpointy
S přechodem na mikroservisy je většina cloudových aplikací jen sbírka API. Mezi běžné problémy patří:
- Nedostatek Rate Limiting: Umožnění útočníkovi prolomit hesla hrubou silou nebo extrahovat data.
- Nedostatečná autentizace: Endpointy, které předpokládají, že "pokud požadavek pochází z interní sítě, je bezpečný."
- Mass Assignment: Umožnění uživateli odeslat požadavek jako
{"role": "admin"}během aktualizace profilu, aby si udělil administrátorská práva.
Tato zjištění ukazují auditorovi, že vaše testování "Application Security" je nedostatečné.
Krok za krokem: Integrace Penetration Testing do vašeho pracovního postupu ISO 27001
Neměli byste jen jednou za rok provést velký Penetration Test a považovat to za hotové. To je "compliance-driven security" a je to nebezpečné. Místo toho chcete "security-driven compliance." Zde je návod, jak zakomponovat Penetration Testing do vašeho celkového systému řízení.
Krok 1: Posouzení rizik (Základ)
Před testováním musíte provést posouzení rizik. Identifikujte svá aktiva, hrozby pro tato aktiva a stávající zavedené kontroly.
- Aktivum: Zákaznická databáze v RDS.
- Hrozba: Neoprávněný přístup prostřednictvím zranitelnosti API.
- Stávající kontrola: WAF a Basic Auth.
- Zbytkové riziko: Vysoké (protože API nebylo hloubkově testováno).
Penetration Test je nástroj, který používáte k ověření, zda je toto "Zbytkové riziko" skutečně tak vysoké, jak si myslíte.
Krok 2: Výběr frekvence testování
Jak často byste měli provádět Penetration Testing pro ISO 27001? Norma neuvádí číslo, ale běžným průmyslovým benchmarkem je:
- Ročně: Pro celé prostředí (hloubková analýza).
- Čtvrtletně: Pro kritické externě orientované aplikace.
- Při každém hlavním vydání: Kdykoli provedete významnou změnu ve své cloudové architektuře.
Pokud používáte cloudovou platformu, jako je Penetrify, můžete přejít k "kontinuálnímu" modelu. Místo jednorázové roční události, která narušuje váš tým, můžete spouštět cílené testy jako součást vašeho CI/CD pipeline.
Krok 3: Fáze provedení
Zde se odehrává skutečný hacking. Dobrý cloudový Penetration Test by měl dodržovat strukturovanou metodologii (jako PTES nebo OWASP). Obvykle to vypadá takto:
- Reconnaissance: Získávání informací o vaší cloudové stopě (DNS záznamy, veřejné IP adresy, uniklé přihlašovací údaje).
- Scanning: Identifikace otevřených portů a služeb.
- Exploitation: Pokus o proniknutí dovnitř.
- Post-Exploitation: Jakmile jsou uvnitř, jak daleko se mohou dostat? Mohou se dostat do databáze? Mohou se přesunout z Dev účtu do Prod účtu?
- Reporting: Závěrečný dokument, který uvádí vše, co bylo nalezeno.
Krok 4: Cyklus nápravy (na čem auditorům skutečně záleží)
Tady je tajemství: Auditory nezajímá, jestli máte zranitelnosti. Má je každá společnost. Zajímají je opatření, která jste proti nim podnikli.
Pokud auditorovi ukážete zprávu s 20 nálezy s označením „Critical“ a žádnými důkazy o opravách, neuspějete. Pokud jim ukážete zprávu s 20 nálezy s označením „Critical“ spolu s nástěnkou Jira, která ukazuje, že 18 z nich je opraveno, 1 je „accepted risk“ s odsouhlaseným obchodním zdůvodněním a 1 je naplánována k opravě v příštím sprintu – projdete s vyznamenáním.
Krok 5: Re-test
Penetration Test není dokončen, dokud není proveden „re-test“. Jakmile vaši vývojáři opraví chyby, testeři by se měli vrátit a pokusit se je znovu prolomit. To poskytuje konečný důkaz pro auditora ISO 27001, že zranitelnost je pryč.
Srovnání: Manuální vs. Automatizovaný vs. Hybridní Cloud Penetration Testing
Při rozhodování o tom, jak zvládnout vaše testování, uvidíte několik různých možností. Každá má své místo ve strategii ISO 27001, ale nejsou zaměnitelné.
| Funkce | Automatizované skenování | Manuální Penetration Testing | Hybridní (např. Penetrify) |
|---|---|---|---|
| Rychlost | Extrémně rychlá | Pomalá | Rychlá až střední |
| Hloubka | Povrchová úroveň | Velmi hluboká | Hluboká |
| Cena | Nízká | Vysoká (za zakázku) | Škálovatelná/Předplatné |
| Logické chyby | Přehlíží je | Nachází je | Nachází většinu |
| Konzistence | Vysoká | Nízká (záleží na testerovi) | Vysoká |
| Hodnota pro ISO 27001 | Nízká (pouze základní) | Vysoká (validace) | Vysoká (průběžná validace) |
Kdy co použít
- Automatizované skenování: Používejte to denně. Je to vaše první linie obrany. Vložte to do svých GitHub Actions nebo GitLab CI.
- Manuální Penetration Testing: Používejte to pro vaše nejkritičtější aplikace s vysokým rizikem jednou ročně. Chcete, aby lidský mozek kreativně přemýšlel o tom, jak obejít vaši specifickou obchodní logiku.
- Hybridní platforma: Používejte to pro všechno mezi tím. Poskytuje vám škálu automatizace s inteligencí rámce pro Penetration Testing, což usnadňuje správu požadavku „continuous“ moderního ISMS.
Sekce „Běžné chyby“: Kde společnosti selhávají při auditu
Viděl jsem spoustu organizací, které prošly úsilím Penetration Testu a stále se potýkají s problémy během auditu ISO 27001. Zde jsou nejčastější úskalí.
Chyba 1: Past „Čisté zprávy“
Některé společnosti tlačí na své firmy provádějící Penetration Testing, aby „zmírnily“ zprávu, aby vypadala lépe pro auditora. Nedělejte to.
Zkušení auditoři vědí, že žádné cloudové prostředí není dokonalé. Zpráva, která říká „Nenalezeny žádné zranitelnosti“ ve složitém cloudovém nastavení, je varovným signálem. Naznačuje to, že test nebyl dostatečně důkladný nebo že společnost něco skrývá. Je mnohem lepší mít zprávu s nálezy a jasný, zdokumentovaný plán nápravy.
Chyba 2: Považování Penetration Testingu za jednorázový projekt
Lidé se k Penetration Testu chovají jako k daňovému přiznání – něco, co děláte jednou ročně a pak na to zapomenete. Ale v cloudu může jediný Terraform apply zavést kritickou zranitelnost během několika sekund.
Pokud provedete Penetration Test v lednu a váš audit je v prosinci, auditor se zeptá, co jste udělali za 11 měsíců od testu. Pokud je odpověď „nic“, nepodařilo se vám prokázat myšlení „continuous improvement“, což je základní princip ISO 27001.
Chyba 3: Špatné mapování důkazů
Zpráva z Penetration Testu je technický dokument. Auditor ISO je často osoba pro dodržování předpisů, nikoli hacker. Pokud jim jen předáte 60stránkové PDF plné skriptů Python a příkazů CURL, ztratí se.
Musíte vytvořit „přemosťovací“ dokument. Namapujte každý nález ve zprávě z Penetration Testu na konkrétní kontrolu ISO 27001. Například: „Nález č. 4 (S3 Public Access) se týká kontroly A.8.8. Náprava byla dokončena 12. října prostřednictvím ticketu č. 123.“
Chyba 4: Ignorování nálezů s „Low“ závažností
Je lákavé opravit pouze „Critical“ a „High“. Útočníci však často používají řetězec tří problémů se závažností „Low“ k vytvoření jednoho „Critical“ narušení.
Auditor zkontroluje, zda máte racionální proces pro rozhodování o tom, co neopravit. Pokud ignorujete „Low“ bez zdokumentovaného důvodu, vypadá to, že zanedbáváte svůj proces řízení rizik.
Propracovaný příklad: Od objevu k certifikaci
Projděme si scénář z reálného světa, abychom viděli, jak to všechno do sebe zapadá.
Společnost: Středně velký FinTech startup s názvem „PaySwift“, který přechází na AWS. Chtějí ISO 27001, aby získali více podnikových zákazníků.
Nastavení: Mají React frontend, Node.js API na EKS (Kubernetes) a databázi Aurora PostgreSQL.
Proces Penetration Testu:
- Nález: Pentester zjistí, že Node.js API má zranitelnost, kde může odeslat speciálně vytvořený požadavek na endpoint
/debug, který zveřejní proměnné prostředí podu. - Pivot: Uvnitř těchto proměnných prostředí pentester najde AWS Access Key.
- Eskalace: Tento klíč patří roli s oprávněními
s3:ListBucketas3:GetObject. Pentester to využije k nalezení bucketu s názvempayswift-backups-proda stáhne výpis databáze. - Výsledek: Nález "Kritický". Totální kompromitace zákaznických dat.
Cesta k nápravě podle ISO 27001:
- Okamžitá oprava: Odstraňte endpoint
/debugz produkce a otočte uniklé AWS klíče. - Systemická oprava: Implementujte zásadu "Secrets Management". Přesuňte klíče z proměnných prostředí do AWS Secrets Manager.
- Řídící oprava: Aktualizujte dokument "Standard bezpečného kódování" tak, aby výslovně zakazoval debug endpointy v produkci.
- Důkaz: PaySwift zdokumentuje ticket, code commit, který to opravil, a aktualizovanou zásadu. Poté požádají o re-test od Penetrify, aby potvrdili, že díra je zalátaná.
Když dorazí auditor, PaySwift to neskrývá. Ukážou auditorovi přesně tuto sekvenci. Říkají: "Našli jsme kritický problém v našem API. Zde je, jak jsme to opravili, a zde je nová zásada, kterou jsme zavedli, abychom zajistili, že se to už nikdy nestane."
Reakce auditora: "Přesně tohle chci vidět. Máte funkční ISMS, který identifikuje rizika, napravuje je a učí se z nich."
Hloubková analýza: Penetration Testing vašeho Cloud-Native Stacku
Abyste skutečně poskytli hodnotu vašemu auditu ISO 27001, musíte jít nad rámec webové aplikace. Zde jsou konkrétní oblasti cloud-native stacku, které vyžadují hloubkové testování.
Kubernetes (K8s) Security Testing
Pokud používáte EKS nebo GKE, vaše útočná plocha se rozšiřuje. Penteři by se měli zaměřit na:
- Komunikace Pod-to-Pod: Pokud je jeden pod kompromitován, může útočník dosáhnout na každý další pod v clusteru? (Nedostatek Network Policies).
- Kubelet Misconfigurations: Může útočník komunikovat s Kubelet API a spouštět příkazy na uzlu?
- RBAC Over-privilege: Mají servisní účty více oprávnění, než potřebují? (např. pod, který může vypsat všechny secrets v namespace).
Serverless (Lambda/Functions) Testing
Serverless neznamená "žádné zabezpečení". Ve skutečnosti to mění hru. Zaměřte se na:
- Event Injection: Protože jsou funkce spouštěny událostmi (S3 uploads, SQS messages), může útočník vložit škodlivý kód do těchto událostí?
- Over-privileged Execution Roles: Má Lambda
AdministratorAccessjen proto, aby zapsala jeden soubor do bucketu? - Timeout/Resource Exhaustion: Může útočník spustit funkci 10 000krát a zvýšit účet za cloud nebo dosáhnout limitu souběžnosti (forma DoS)?
Cloud Storage and Data Persistence
Úložiště je místo, kde žijí data, a kde dochází k největším únikům. Testování by mělo zahrnovat:
- Cross-Account Access: Může AWS účet z jiné organizace přistupovat k vašim bucketům kvůli nesprávně nakonfigurované bucket policy?
- Unencrypted Data at Rest: Jsou data šifrována? Pokud pentester získá přístup k diskové snapshotu, může si data přečíst?
- Presigned URL Abuse: Pokud vaše aplikace generuje dočasné odkazy ke stažení souborů, lze tyto odkazy uhodnout nebo opakovaně používat donekonečna?
Komplexní kontrolní seznam Cloud Penetration Testing pro shodu
Pokud se připravujete na audit, použijte tento kontrolní seznam, abyste zajistili, že vaše testovací pokrytí je dostatečné.
Fáze 1: Plánování a rozsah
- Definujte "Crown Jewels" (PII, Finanční údaje, Duševní vlastnictví).
- Zmapujte všechny veřejně přístupné IP adresy a DNS záznamy.
- Zdokumentujte Statement of Applicability (SoA) a propojte jej s testem.
- Vytvořte podepsaný dokument Rules of Engagement (RoE).
- Upozorněte poskytovatele cloudu (pokud je to nutné) a interní SOC tým.
Fáze 2: Technická realizace
- Identita: Otestujte obcházení MFA a eskalaci oprávnění v IAM.
- Síť: Proveďte interní testy laterálního pohybu (Pod-to-Pod, VPC-to-VPC).
- Aplikace: Otestujte OWASP Top 10 (Injection, BOLA, XSS, atd.).
- Konfigurace: Zkontrolujte otevřené porty (SSH, RDP) a veřejné storage buckets.
- Secrets: Skenujte uniklé klíče v protokolech, kódu a proměnných prostředí.
- API: Otestujte rate limits, authentication tokens a input validation.
Fáze 3: Náprava a důkazy
- Zaznamenejte všechny nálezy do systému sledování (Jira, ServiceNow).
- Kategorizujte nálezy podle závažnosti (Critical, High, Medium, Low).
- Zdokumentujte "Risk Acceptance" pro všechny nálezy, které nebudou opraveny.
- Proveďte formální re-test všech Critical a High nálezů.
- Vytvořte souhrnnou zprávu mapující nálezy na kontroly ISO 27001.
Často kladené otázky (FAQ)
Otázka: Vyžaduje ISO 27001 certifikovaného pentestera?
I když norma výslovně neuvádí žádnou certifikaci (jako OSCP nebo CISSP), vyžaduje, aby bezpečnostní kontroly byly implementovány a testovány "kompetentními" osobami. Pokud použijete interního zaměstnance, který nemá žádné bezpečnostní školení, auditor pravděpodobně zpochybní platnost testu. Použití profesionální firmy nebo specializované platformy, jako je Penetrify, zajistí splnění požadavku "kompetence".
Otázka: Mohu použít automatizovaný nástroj a nazvat to "Penetration Test" pro můj audit?
Obecně ne. Automatizovaný nástroj poskytuje "Vulnerability Assessment". "Penetration Test" vyžaduje prvek lidského průzkumu a zneužití. Většina auditorů zná rozdíl. Pokud máte pouze zprávy ze skenování, můžete stále projít, ale budete pod větším dohledem ohledně toho, jak řešíte složitá rizika.
Otázka: Jak mám řešit "kritické" zjištění nalezené těsně před auditem?
Nepanikařte a rozhodně to neskrývejte. Nejhorší, co můžete udělat, je předstírat, že zranitelnost neexistuje. Místo toho okamžitě zdokumentujte zjištění, vytvořte plán zmírnění (i když je to dočasné řešení) a ukažte auditorovi, že jste to našli prostřednictvím vlastního proaktivního testování. To ve skutečnosti vypadá lépe, než kdyby to auditor našel sám.
Otázka: Kdo by se měl podílet na procesu Penetration Testing?
Je to týmová práce. Potřebujete:
- Bezpečnostní tým: Pro správu RoE a dohled nad testem.
- DevOps/Infrastrukturní tým: Pro poskytnutí přístupu a opravu problémů s konfigurací.
- Vývojáři: Pro opravu chyb na úrovni kódu.
- Pracovník pro dodržování předpisů: Pro zajištění, že výsledky jsou mapovány na požadavky ISO 27001.
Otázka: Je "Gray Box" nebo "Black Box" test lepší pro ISO 27001?
Pro shodu s předpisy je "Gray Box" obvykle nejlepší rovnováha. V Black Box testu tester nemá žádné znalosti (simuluje vnějšího útočníka), což je skvělé pro realismus, ale může mu hodně uniknout, protože tester tráví polovinu času jen snahou najít přihlašovací stránku. V Gray Box testu jim dáte nějakou dokumentaci nebo uživatelský účet s nízkou úrovní oprávnění. To jim umožní trávit více času testováním vnitřní architektury a rolí IAM, kde se nacházejí nejnebezpečnější cloudová rizika.
Závěrečné myšlenky: Směrem k trvalé odolnosti
Certifikace ISO 27001 je skvělý úspěch a jistě pomáhá s prodejem a důvěrou. Ale nakonec je certifikát jen kus papíru. Skutečná hodnota spočívá v procesu, který si vybudujete, abyste zůstali v bezpečí.
Cloudová prostředí se pohybují příliš rychle na starý bezpečnostní model "jednou za rok". Když je vaše infrastruktura definována jako kód, vaše bezpečnostní testování by mělo být stejně agilní. Integrací hloubkového cloudového Penetration Testing do vašeho pracovního postupu přestanete vnímat bezpečnost jako překážku, kterou je třeba překonat pro auditora, a začnete ji vnímat jako konkurenční výhodu.
Pokud se cítíte zahlceni složitostí rozsahu vašich cloudových aktiv nebo jste unaveni z vysokých nákladů a pomalého obratu tradičních firem provádějících Penetration Testing, možná je čas podívat se na cloudový přístup. Penetrify je navržen speciálně pro toto. Odstraňuje infrastrukturní bariéry a umožňuje vám provádět bezpečnostní hodnocení na profesionální úrovni, která se škálují s vaším prostředím. Místo čekání týdny na zprávu ve formátu PDF získáte praktické poznatky, které se přímo promítají do vašich stávajících pracovních postupů.
Nenechte svou cestu k ISO 27001 být stresujícím sháněním důkazů. Vybudujte kulturu neustálého testování, ověřujte své předpoklady a proměňte své zabezpečení v něco, na co jste skutečně hrdí – nejen v něco, co uspokojí auditora.