Získanie certifikácie ISO 27001 pre vašu organizáciu je trochu ako bežať maratón. Je to dlhý, vyčerpávajúci proces dokumentácie, tvorby zásad a auditu, ktorý sa môže zdať nekonečný. Ale pre väčšinu z nás v technologickom a bezpečnostnom svete je skutočným "vrcholom" technická validačná časť. Môžete mať najkrajšiu príručku bezpečnostných zásad na svete, ale ak nejaký náhodný script kiddie nájde otvorený S3 bucket alebo SQL injection point vo vašej primárnej aplikácii, váš Information Security Management System (ISMS) je v podstate fikcia.
Tu sa cloudový Penetration Testing stáva nevyhnutnosťou, a nie len "dobrým doplnkom". Ak sa usilujete o certifikáciu ISO 27001, nekontrolujete len políčko; snažíte sa audítorovi dokázať, že skutočne viete, kde sú vaše riziká, a že máte opakovateľný proces na ich nájdenie a opravu. V cloudovom prostredí je to ťažšie, ako sa zdá. Perimetr je priepustný, konfigurácie sa menia v priebehu sekúnd prostredníctvom Terraform alebo CloudFormation a jediné nesprávne kliknutie na zaškrtávacie políčko v konzole AWS alebo Azure môže sprístupniť celú vašu zákaznícku databázu verejnému internetu.
Mnohé tímy robia chybu, keď si myslia, že vulnerability scan je to isté ako Penetration Test. Nie je. Scan vám povie, že dvere sú odomknuté; Penetration Test vám povie, že niekto môže prejsť cez tie dvere, nájsť serverovňu a ukradnúť korunovačné klenoty. Pre ISO 27001, konkrétne v rámci kontrol prílohy A, ktoré sa týkajú riadenia zraniteľností a technickej zhody, preukázanie, že ste vykonali "etické hackovanie" alebo hĺbkové testovanie, je to, čo dáva audítorovi dôveru vo vaše bezpečnostné postavenie.
V tejto príručke si rozoberieme, ako presne pristupovať ku cloudovému Penetration Testingu, aby ste splnili požiadavky ISO 27001. Prejdeme od žargónu a pozrieme sa na praktické kroky, ktoré musíte podniknúť – od rozsahu vašich cloudových aktív až po spracovanie správ o náprave, ktoré budú audítori skutočne chcieť vidieť.
Prečo ISO 27001 vyžaduje viac ako len základné skenovanie
ISO 27001 je rámec pre riadenie rizík. Explicitne nehovorí "musíte vykonávať Penetration Test každý utorok", ale vyžaduje, aby ste riadili technické zraniteľnosti. Ak audítorovi poviete, že ste "zabezpečení", pretože ste spustili automatizovaný scan, opýta sa vás, ako validujete tieto zistenia a ako testujete zložité útočné reťazce, ktoré skenery prehliadajú.
Rozdiel medzi skenovaním a testovaním
Väčšina spoločností sa spolieha na automatizované vulnerability scannery. Tie sú skvelé na nájdenie zastaraných knižníc alebo chýbajúcich záplat. Ale scannery sú slepé voči obchodnej logike. Scanner si nevšimne, že používateľ si môže zmeniť svoje user_id v URL, aby videl súkromné fakturačné údaje iného zákazníka. To je problém Broken Object Level Authorization (BOLA) a je to zlatá baňa pre útočníkov.
Cloudový Penetration Testing vypĺňa túto medzeru. Zahŕňa človeka (alebo sofistikovanú platformu kombinujúcu automatizáciu s ľudskou logikou), ktorý sa pokúša preniknúť cez vašu sieť. Napríklad, pentester môže nájsť zraniteľnosť s nízkou závažnosťou vo webovej aplikácii, použiť ju na získanie oporného bodu v kontajneri, objaviť príliš povoľujúcu IAM rolu pripojenú k tomuto kontajneru a potom použiť tieto povolenia na dump celej vašej RDS databázy. Tento "útočný reťazec" je presne to, čo ISO 27001 chce, aby ste identifikovali a zmiernili.
Mapovanie Penetration Testingu na kontroly prílohy A
Ak sa pozeráte na aktualizované normy ISO 27001:2022, niekoľko kontrol sa silne opiera o výsledky Penetration Testingu:
- A.8.8 Management of Technical Vulnerabilities: Toto je to hlavné. Musíte identifikovať zraniteľnosti a prijať vhodné opatrenia. Penetration Testing je zlatý štandard pre "identifikáciu" vecí, ktoré softvér prehliada.
- A.8.25 Secure Development Life Cycle: Ak denne posielate kód do cloudu, musíte dokázať, že bezpečnostné testovanie je súčasťou tohto cyklu.
- A.5.37 Compliance with Policies and Standards: Testovanie dokazuje, že vaše interné bezpečnostné zásady sa skutočne dodržiavajú v produkčnom prostredí.
V podstate správa z Penetration Testu slúži ako priečinok s "dôkazmi" pre audítora. Dokazuje, že len nehádžete svoje zabezpečenie – skutočne ste ho otestovali.
Stanovenie rozsahu vášho cloudového prostredia pre audit
Jednou z najväčších bolestí hlavy v cloudovom Penetration Testingu je rozširovanie rozsahu. Začnete testovaním jedného API a zrazu sa snažíte testovať tri AWS účty, starší on-premise server a integráciu SaaS tretej strany. Pre ISO 27001 musí byť váš rozsah jasne definovaný, pretože audítor skontroluje, či vaše testovanie zodpovedá vášmu uvedenému "Statement of Applicability" (SoA).
Identifikácia vašich "korunovačných klenotov"
Nemôžete testovať všetko s rovnakou intenzitou. Musíte si stanoviť priority. Začnite zmapovaním toku vašich dát. Kde sa nachádzajú PII (osobné identifikačné údaje)? Ktoré služby spracovávajú platobné údaje? Ktoré API gateways sú vystavené verejnosti?
V cloudovom kontexte by mal váš rozsah zahŕňať:
- Verejne prístupné koncové body: Load balancery, API gateways a webové aplikácie.
- Identity and Access Management (IAM): Toto je nový perimetr. Testovanie by sa malo zamerať na to, či kompromitovaný používateľský účet môže eskalovať privilégiá.
- Container Orchestration: Ak používate Kubernetes (EKS, GKE, AKS), konfigurácia samotného klastra je rozsiahly útočný vektor.
- Serverless Functions: Lambda alebo Azure Functions majú často "skryté" povolenia, ktoré sa dajú zneužiť.
- Storage Buckets: S3, Azure Blobs alebo Google Cloud Storage. Nesprávne nakonfigurované buckety sú najčastejšou príčinou narušenia cloudových dát.
Definovanie "pravidiel zapojenia"
Pred odoslaním jediného paketu potrebujete dokument Rules of Engagement (RoE). To je kritické pre ISO 27001, pretože to ukazuje audítorovi, že máte kontrolovaný proces. RoE by mal odpovedať:
- Čo je zakázané? (napr. "Nevykonávajte Denial of Service útoky na produkčnú databázu").
- Kedy môže testovanie prebiehať? (napr. "Iba mimo špičky" alebo "Nepretržité testovanie je povolené").
- Kto je kontaktná osoba? Ak bezpečnostný tím zaznamená nárast v prenose, komu zavolá, aby overil, či ide o pentestera a nie o skutočného útočníka?
- Ako sa bude zaobchádzať s dátami? Pentesteri nájdu citlivé dáta. Ako sú tieto dáta šifrované a odstránené po teste?
Výzva "Cloudových povolení"
Pred pár rokmi ste museli požiadať AWS alebo Azure o povolenie pred Penetration Testing. Dnes väčšina hlavných poskytovateľov cloudových služieb uvoľnila tieto pravidlá pre bežné služby. Stále však nemôžete vykonávať DDoS útoky alebo cieliť na základnú cloudovú infraštruktúru (hypervízory).
Ak používate platformu ako Penetrify, stáva sa to oveľa jednoduchším. Pretože ide o cloud-natívnu platformu, je navrhnutá tak, aby fungovala v rámci hraníc týchto prostredí, čo vám umožňuje škálovať vaše testovanie bez obáv z náhodného spustenia bezpečnostného bloku na úrovni poskytovateľa.
Bežné cloudové zraniteľnosti, ktoré potrápia kandidátov na ISO 27001
Keď dostanete späť svoju správu z Penetration Testu, pravdepodobne uvidíte zoznam zistení. Aby ste boli úspešní vo svojej certifikácii, musíte ich chápať nielen ako "chyby," ale ako zlyhania vo vašom ISMS.
1. IAM nočná mora (Privilege Escalation)
V cloude je identita všetkým. Bežným zistením sú "Príliš povoľujúce IAM roly."
Predstavte si, že vývojár vytvorí rolu pre jednoduchú aplikáciu na zaznamenávanie, ale priradí jej AdministratorAccess, pretože to bolo jednoduchšie ako zistiť konkrétne potrebné povolenia. Pentester nájde spôsob, ako spustiť jednoduchý príkaz na tejto aplikácii, ukradne dočasné bezpečnostné tokeny a zrazu má plnú kontrolu nad celým vašim cloudovým účtom.
Z pohľadu ISO 27001 ide o zlyhanie princípu "Least Privilege". Opravou nie je len zmena roly; je to implementácia procesu na štvrťročné preverovanie IAM povolení.
2. Rozširovanie tajomstiev
Pevne zakódované API kľúče v GitHub, heslá v premenných prostredia alebo tajomstvá uložené v obyčajnom texte v konfiguračnom súbore. Pentesteri to milujú. Nájdu uniknutý kľúč, použijú ho na prístup k databáze a v priebehu niekoľkých minút sú vo vašej sieti.
Poukazuje to na medzeru vo vašich kontrolách "Secure Development". Na uspokojenie audítora by ste sa mali posunúť smerom k nástroju na správu tajomstiev (ako AWS Secrets Manager alebo HashiCorp Vault) a implementovať skenovanie, aby sa zabránilo odovzdávaniu tajomstiev do kódu.
3. Nesprávne nakonfigurované S3 Buckets a Blobs
Všetci sme videli titulky. "Interný" bucket je omylom nastavený na "Verejný." Zatiaľ čo skenery ich dokážu nájsť, pentester vám presne ukáže, aké dáta je možné exfiltrovať a ako sa tieto dáta dajú použiť na spustenie ďalších útokov.
Ide o zlyhanie "Configuration Management". Nápravou je často automatizovaná politika (ako AWS GuardDuty alebo Azure Policy), ktorá zabraňuje tomu, aby sa buckety stali verejnými.
4. Nebezpečné API Endpoints
S prechodom na mikroservisy je väčšina cloudových aplikácií len zbierkou API. Medzi bežné problémy patria:
- Nedostatok Rate Limiting: Umožnenie útočníkovi brute-force heslá alebo extrahovať dáta.
- Nedostatočná autentifikácia: Endpoints, ktoré predpokladajú, že "ak požiadavka pochádza z internej siete, je bezpečná."
- Mass Assignment: Umožnenie používateľovi odoslať požiadavku ako
{"role": "admin"}počas aktualizácie profilu, aby si udelil administrátorské práva.
Tieto zistenia ukazujú audítorovi, že vaše testovanie "Application Security" je nedostatočné.
Krok za krokom: Integrácia Penetration Testing do vášho pracovného postupu ISO 27001
Nemali by ste len raz ročne vykonať rozsiahly Penetration Test a považovať to za vybavené. To je "compliance-driven security" a je to nebezpečné. Namiesto toho chcete "security-driven compliance." Tu je návod, ako zakomponovať Penetration Testing do vášho celkového systému riadenia.
Krok 1: Posúdenie rizík (Základ)
Pred testovaním musíte vykonať posúdenie rizík. Identifikujte svoje aktíva, hrozby pre tieto aktíva a aktuálne zavedené kontroly.
- Aktívum: Zákaznícka databáza v RDS.
- Hrozba: Neoprávnený prístup prostredníctvom API zraniteľnosti.
- Aktuálna kontrola: WAF a Basic Auth.
- Zvyškové riziko: Vysoké (pretože API nebolo hĺbkovo testované).
Penetration Test je nástroj, ktorý používate na overenie, či je toto "Zvyškové riziko" skutočne také vysoké, ako si myslíte.
Krok 2: Výber frekvencie testovania
Ako často by ste mali vykonávať Penetration Testing pre ISO 27001? Norma neuvádza číslo, ale bežným priemyselným štandardom je:
- Ročne: Pre celé prostredie (hĺbková analýza).
- Štvrťročne: Pre kritické aplikácie prístupné externe.
- Pri každom hlavnom vydaní: Vždy, keď vykonáte významnú zmenu vo svojej cloudovej architektúre.
Ak používate cloudovú platformu ako Penetrify, môžete prejsť na "nepretržitý" model. Namiesto raz ročnej udalosti, ktorá narúša váš tím, môžete spúšťať cielené testy ako súčasť vášho CI/CD pipeline.
Krok 3: Fáza vykonávania
Tu sa deje skutočný hacking. Dobrý cloudový Penetration Test by mal nasledovať štruktúrovanú metodológiu (ako PTES alebo OWASP). Zvyčajne to vyzerá takto:
- Reconnaissance: Získavanie informácií o vašej cloudovej stope (DNS záznamy, verejné IP adresy, uniknuté prihlasovacie údaje).
- Scanning: Identifikácia otvorených portov a služieb.
- Exploitation: Pokus dostať sa dovnútra.
- Post-Exploitation: Akonáhle sú vo vnútri, ako ďaleko sa môžu dostať? Môžu sa dostať do databázy? Môžu sa presunúť z Dev účtu do Prod účtu?
- Reporting: Záverečný dokument, ktorý uvádza všetko, čo bolo nájdené.
Krok 4: Cyklus nápravy (Čo audítorov skutočne zaujíma)
Tu je tajomstvo: Audítorov nezaujíma, či máte zraniteľnosti. Každá spoločnosť ich má. Čo ich zaujíma, je čo ste s nimi urobili.
Ak ukážete audítorovi správu s 20 "kritickými" zisteniami a žiadny dôkaz o opravách, neuspejete. Ak im ukážete správu s 20 "kritickými" zisteniami, spolu s Jira boardom, ktorý ukazuje, že 18 z nich je opravených, 1 je "akceptované riziko" s podpísaným obchodným odôvodnením a 1 je naplánovaná na opravu v nasledujúcom šprinte – prejdete s výbornými výsledkami.
Krok 5: Re-test
Penetration Test nie je dokončený, kým sa neurobí "re-test". Akonáhle vaši vývojári opravia chyby, testeri by sa mali vrátiť a pokúsiť sa ich znova prelomiť. Toto poskytuje konečný dôkaz pre audítora ISO 27001, že zraniteľnosť je preč.
Porovnanie: Manuálny vs. Automatizovaný vs. Hybridný Cloud Penetration Testing
Pri rozhodovaní o tom, ako zvládnuť vaše testovanie, uvidíte niekoľko rôznych možností. Každá má svoje miesto v stratégii ISO 27001, ale nie sú zameniteľné.
| Funkcia | Automatizované skenovanie | Manuálny Penetration Testing | Hybridný (napr. Penetrify) |
|---|---|---|---|
| Rýchlosť | Extrémne rýchla | Pomalá | Rýchla až stredná |
| Hĺbka | Povrchová úroveň | Veľmi hlboká | Hlboká |
| Cena | Nízka | Vysoká (za angažmán) | Škálovateľná/Predplatné |
| Logické chyby | Prehliadne ich | Nájde ich | Nájde väčšinu |
| Konzistencia | Vysoká | Nízka (závisí od testera) | Vysoká |
| Hodnota ISO 27001 | Nízka (iba základná) | Vysoká (validácia) | Vysoká (nepretržitá validácia) |
Kedy ktorý použiť
- Automatizované skenovanie: Používajte ho denne. Je to vaša prvá línia obrany. Umiestnite ho do svojich GitHub Actions alebo GitLab CI.
- Manuálny Penetration Testing: Používajte ho pre vaše najkritickejšie aplikácie s vysokým rizikom raz ročne. Chcete, aby ľudský mozog kreatívne premýšľal o tom, ako obísť vašu špecifickú obchodnú logiku.
- Hybridná platforma: Používajte ju pre všetko medzi tým. Poskytuje vám škálu automatizácie s inteligenciou rámca pre Penetration Testing, čo uľahčuje správu "nepretržitej" požiadavky moderného ISMS.
Sekcia "Bežné chyby": Kde spoločnosti zlyhávajú pri audite
Videl som veľa organizácií, ktoré prešli úsilím Penetration Testu a stále sa trápia počas auditu ISO 27001. Tu sú najčastejšie úskalia.
Chyba 1: Pasca "Čistej správy"
Niektoré spoločnosti tlačia na svoje firmy vykonávajúce Penetration Testing, aby "zmiernili" správu, aby vyzerala lepšie pre audítora. Nerobte to.
Skúsení audítori vedia, že žiadne cloudové prostredie nie je dokonalé. Správa, ktorá hovorí "Nenájdené žiadne zraniteľnosti" v komplexnom cloudovom nastavení, je červená vlajka. Naznačuje to, že test nebol dostatočne prísny alebo že spoločnosť niečo skrýva. Je oveľa lepšie mať správu so zisteniami a jasný, zdokumentovaný plán nápravy.
Chyba 2: Považovanie Penetration Testingu za jednorazový projekt
Ľudia sa k Penetration Testu správajú ako k daňovému priznaniu – niečo, čo robíte raz ročne a potom na to zabudnete. Ale v cloude môže jediný Terraform apply zaviesť kritickú zraniteľnosť v priebehu niekoľkých sekúnd.
Ak urobíte svoj Penetration Test v januári a váš audit je v decembri, audítor sa opýta, čo ste urobili za 11 mesiacov od testu. Ak je odpoveď "nič", nepreukázali ste mentalitu "neustáleho zlepšovania", čo je základný princíp ISO 27001.
Chyba 3: Zlé mapovanie dôkazov
Správa z Penetration Testu je technický dokument. Audítor ISO je často osoba pre dodržiavanie predpisov, nie hacker. Ak im len odovzdáte 60-stranové PDF plné Python skriptov a CURL príkazov, stratia sa.
Musíte vytvoriť "preklenovací" dokument. Zmapujte každé zistenie v správe z Penetration Testu na špecifickú kontrolu ISO 27001. Napríklad: "Zistenie #4 (S3 Public Access) sa týka kontroly A.8.8. Náprava bola dokončená 12. októbra prostredníctvom Ticket #123."
Chyba 4: Ignorovanie zistení s "nízkou" závažnosťou
Je lákavé opraviť iba "kritické" a "vysoké". Útočníci však často používajú reťaz troch problémov s "nízkou" závažnosťou na vytvorenie jedného "kritického" narušenia.
Audítor skontroluje, či máte racionálny proces na rozhodovanie o tom, čo neopraviť. Ak ignorujete "nízke" bez zdokumentovaného dôvodu, vyzerá to, že zanedbávate svoj proces riadenia rizík.
Príklad z praxe: Od objavu k certifikácii
Prejdime si scenár z reálneho sveta, aby sme videli, ako to všetko zapadá do seba.
Spoločnosť: Stredne veľký FinTech startup s názvom "PaySwift", ktorý prechádza na AWS. Chcú ISO 27001, aby získali viac podnikových zákazníkov.
Nastavenie: Majú React frontend, Node.js API na EKS (Kubernetes) a Aurora PostgreSQL databázu.
Proces Penetration Testu:
- Nález: Pentester zistí, že Node.js API má zraniteľnosť, kde môže odoslať špeciálne vytvorenú požiadavku na endpoint
/debug, ktorý odhalí premenné prostredia podu. - Pivot: V týchto premenných prostredia pentester nájde AWS Access Key.
- Eskalácia: Tento kľúč patrí role s oprávneniami
s3:ListBucketas3:GetObject. Pentester to použije na nájdenie bucketu s názvompayswift-backups-proda stiahne výpis databázy. - Výsledok: Nález s označením "Kritický". Úplné ohrozenie zákazníckych dát.
ISO 27001 Nápravná Cesta:
- Okamžitá oprava: Odstráňte endpoint
/debugz produkcie a obmeňte uniknuté AWS kľúče. - Systemická oprava: Implementujte politiku "Secrets Management". Presuňte kľúče z premenných prostredia do AWS Secrets Manager.
- Riadiaca oprava: Aktualizujte dokument "Štandard bezpečného kódovania" tak, aby explicitne zakazoval debug endpointy v produkcii.
- Dôkaz: PaySwift zdokumentuje ticket, commit kódu, ktorý to opravil, a aktualizovanú politiku. Potom požiadajú o re-test od Penetrify, aby potvrdili, že diera je zaplátaná.
Keď audítor príde, PaySwift to neskrýva. Ukážu audítorovi presne túto sekvenciu. Povedia: "Našli sme kritický problém v našom API. Tu je, ako sme to opravili, a tu je nová politika, ktorú sme zaviedli, aby sme sa uistili, že sa to už nikdy nestane."
Reakcia audítora: "Toto je presne to, čo chcem vidieť. Máte funkčný ISMS, ktorý identifikuje riziko, odstraňuje ho a učí sa z neho."
Hĺbková analýza: Penetration Testing vášho Cloud-Native Stacku
Ak chcete skutočne poskytnúť hodnotu vášmu auditu ISO 27001, musíte ísť nad rámec webovej aplikácie. Tu sú konkrétne oblasti cloud-native stacku, ktoré si vyžadujú hĺbkové testovanie.
Kubernetes (K8s) Security Testing
Ak používate EKS alebo GKE, vaša útočná plocha sa rozširuje. Pentesteri by mali hľadať:
- Pod-to-Pod Communication: Ak je jeden pod kompromitovaný, môže útočník dosiahnuť každý iný pod v klastri? (Nedostatok Network Policies).
- Kubelet Misconfigurations: Môže útočník komunikovať s Kubelet API na vykonávanie príkazov na uzle?
- RBAC Over-privilege: Majú servisné účty viac povolení, ako potrebujú? (napr. pod, ktorý môže vypísať všetky tajomstvá v namespace).
Serverless (Lambda/Functions) Testing
Serverless neznamená "žiadne zabezpečenie." V skutočnosti to mení hru. Zamerajte sa na:
- Event Injection: Keďže funkcie sú spúšťané udalosťami (nahrávanie S3, správy SQS), môže útočník vložiť škodlivý kód do týchto udalostí?
- Over-privileged Execution Roles: Má Lambda
AdministratorAccesslen na zápis jedného súboru do bucketu? - Timeout/Resource Exhaustion: Môže útočník spustiť funkciu 10 000-krát a zvýšiť účet za cloud alebo dosiahnuť limit súbežnosti (forma DoS)?
Cloud Storage and Data Persistence
Úložisko je miesto, kde žijú dáta a kde dochádza k najväčším únikom. Testovanie by malo zahŕňať:
- Cross-Account Access: Môže AWS účet z inej organizácie pristupovať k vašim bucketom kvôli nesprávne nakonfigurovanej politike bucketu?
- Unencrypted Data at Rest: Sú dáta šifrované? Ak pentester získa prístup k snímke disku, môže si prečítať dáta?
- Presigned URL Abuse: Ak vaša aplikácia generuje dočasné odkazy na stiahnutie súborov, dajú sa tieto odkazy uhádnuť alebo opakovane použiť na neurčito?
Komplexný Cloud Pentesting Checklist pre Súlad
Ak sa pripravujete na audit, použite tento kontrolný zoznam, aby ste zabezpečili dostatočné pokrytie testovaním.
Fáza 1: Plánovanie a Rozsah
- Definujte "Crown Jewels" (PII, Financie, Intelektuálne vlastníctvo).
- Zmapujte všetky verejne prístupné IP adresy a DNS záznamy.
- Zdokumentujte Statement of Applicability (SoA) a prepojte ho s testom.
- Vytvorte podpísaný dokument Rules of Engagement (RoE).
- Upozornite poskytovateľa cloudu (ak je to potrebné) a interný SOC tím.
Fáza 2: Technická Realizácia
- Identita: Otestujte obídenie MFA a eskaláciu privilégií v IAM.
- Sieť: Vykonajte interné testy laterálneho pohybu (Pod-to-Pod, VPC-to-VPC).
- Aplikácia: Otestujte OWASP Top 10 (Injection, BOLA, XSS, atď.).
- Konfigurácia: Skontrolujte otvorené porty (SSH, RDP) a verejné úložné buckety.
- Tajomstvá: Skenujte uniknuté kľúče v logoch, kóde a premenných prostredia.
- API: Otestujte limity rýchlosti, autentifikačné tokeny a validáciu vstupu.
Fáza 3: Náprava a Dôkazy
- Zaznamenajte všetky nálezy v systéme sledovania (Jira, ServiceNow).
- Kategorizujte nálezy podľa závažnosti (Kritické, Vysoké, Stredné, Nízke).
- Zdokumentujte "Risk Acceptance" pre všetky nálezy, ktoré nebudú opravené.
- Vykonajte formálny re-test všetkých kritických a vysokých nálezov.
- Vytvorte súhrnnú správu mapujúcu nálezy na kontroly ISO 27001.
Často Kladené Otázky (FAQ)
Otázka: Vyžaduje ISO 27001 certifikovaného pentestera?
Hoci norma výslovne neuvádza žiadnu certifikáciu (ako OSCP alebo CISSP), vyžaduje, aby boli bezpečnostné kontroly implementované a testované "kompetentnými" osobami. Ak použijete interného zamestnanca, ktorý nemá žiadne bezpečnostné školenie, audítor pravdepodobne spochybní platnosť testu. Použitie profesionálnej firmy alebo špecializovanej platformy ako Penetrify zaisťuje splnenie požiadavky "kompetentnosti".
Otázka: Môžem použiť automatizovaný nástroj a nazvať to "Penetration Test" pre môj audit?
Vo všeobecnosti nie. Automatizovaný nástroj poskytuje "Vulnerability Assessment". "Penetration Test" vyžaduje prvok ľudského prieskumu a využitia. Väčšina audítorov pozná rozdiel. Ak máte iba správy zo skenovania, stále môžete prejsť, ale budete podrobnejšie skúmaní, pokiaľ ide o to, ako riešite komplexné riziká.
Otázka: Ako mám riešiť "kritické" zistenie nájdené tesne pred mojím auditom?
Neprepadajte panike a určite to neskrývajte. Najhoršie, čo môžete urobiť, je predstierať, že zraniteľnosť neexistuje. Namiesto toho okamžite zdokumentujte zistenie, vytvorte plán zmiernenia (aj keď ide o dočasné riešenie) a ukážte audítorovi, že ste ho našli prostredníctvom vlastného proaktívneho testovania. V skutočnosti to vyzerá lepšie, ako keby to našiel audítor sám.
Otázka: Kto by mal byť zapojený do procesu Penetration Testing?
Je to tímová práca. Potrebujete:
- Bezpečnostný tím: Na riadenie RoE a dohľad nad testom.
- DevOps/Infraštruktúrny tím: Na poskytnutie prístupu a opravu problémov s konfiguráciou.
- Vývojári: Na opravu chýb na úrovni kódu.
- Pracovník pre dodržiavanie predpisov: Na zabezpečenie, aby boli výsledky mapované na požiadavky ISO 27001.
Otázka: Je "Gray Box" alebo "Black Box" test lepší pre ISO 27001?
Pre súlad s predpismi je "Gray Box" zvyčajne najlepšia rovnováha. V Black Box teste tester nemá žiadne znalosti (simuluje vonkajšieho útočníka), čo je skvelé pre realizmus, ale môže mu veľa uniknúť, pretože tester trávi polovicu času len snahou nájsť prihlasovaciu stránku. V Gray Box teste im poskytnete nejakú dokumentáciu alebo používateľské konto s nízkou úrovňou prístupu. To im umožňuje stráviť viac času testovaním internej architektúry a rolí IAM, kde sa nachádzajú najnebezpečnejšie cloudové riziká.
Záverečné myšlienky: Posun smerom k nepretržitej odolnosti
Certifikácia ISO 27001 je skvelý úspech a určite pomáha s predajom a dôverou. Ale na konci dňa je certifikát len kus papiera. Skutočná hodnota spočíva v procese, ktorý si vybudujete, aby ste zostali v bezpečí.
Cloudové prostredia sa pohybujú príliš rýchlo na starý bezpečnostný model "raz za rok". Keď je vaša infraštruktúra definovaná ako kód, vaše bezpečnostné testovanie by malo byť rovnako agilné. Integráciou hĺbkového cloudového Penetration Testing do vášho pracovného postupu prestanete považovať bezpečnosť za prekážku, ktorú treba prekonať pre audítora, a začnete ju považovať za konkurenčnú výhodu.
Ak sa cítite preťažení zložitosťou rozsahu vašich cloudových aktív alebo ste unavení z vysokých nákladov a pomalého obratu tradičných firiem zaoberajúcich sa Penetration Testing, možno je čas pozrieť sa na cloudovo-natívny prístup. Penetrify je navrhnutý špeciálne pre toto. Odstraňuje infraštruktúrne bariéry, čo vám umožňuje vykonávať bezpečnostné posúdenia na profesionálnej úrovni, ktoré sa škálujú s vaším prostredím. Namiesto čakania týždne na správu vo formáte PDF získate užitočné informácie, ktoré sa priamo vkladajú do vašich existujúcich pracovných postupov.
Nedovoľte, aby bola vaša cesta k ISO 27001 stresujúcim zhonom za dôkazmi. Vybudujte kultúru nepretržitého testovania, overujte svoje predpoklady a premeňte svoje bezpečnostné postavenie na niečo, na čo ste skutočne hrdí – nielen na niečo, čo uspokojí audítora.