Odporúčania na testovanie bezpečnosti

Vzťahuje sa na toto odporúčanie Power Platform dobre zostaveného kontrolného zoznamu zabezpečenia:

Prísne testovanie je základom dobrého bezpečnostného dizajnu. Testovanie je taktickou formou overovania, aby ste sa uistili, že kontroly fungujú podľa plánu. Testovanie je tiež proaktívny spôsob odhaľovania zraniteľností v systéme.

Vytvorte prísnosť testovania prostredníctvom kadencie a overenia z viacerých Perspektívy. Mali by ste zahrnúť vnútorné pohľady, ktoré testujú platformu a infraštruktúru, a externé hodnotenia, ktoré testujú systém ako externý útočník.

Táto príručka poskytuje odporúčania na testovanie bezpečnostnej pozície vašej pracovnej záťaže. Implementujte tieto testovacie metódy, aby ste zlepšili odolnosť vašej pracovnej záťaže voči útokom a zachovali dôvernosť, integritu a dostupnosť zdrojov.

Definície

Kľúčové dizajnové stratégie

Testovanie je stratégia, o ktorej sa nedá vyjednávať, najmä pokiaľ ide o bezpečnosť. Umožňuje vám proaktívne zisťovať a riešiť bezpečnostné problémy skôr, ako ich možno zneužiť, a overiť, či vami implementované bezpečnostné ovládacie prvky fungujú tak, ako boli navrhnuté.

Rozsah testovania musí zahŕňať aplikáciu, infraštruktúru a automatizované a ľudské procesy.

Zapojte sa do plánovania testov. Tím pre pracovné zaťaženie nemusí navrhnúť testovacie prípady. Táto úloha je často centralizovaná v podniku alebo dokončená externými bezpečnostnými expertmi. Tím pre pracovné zaťaženie by mal byť zapojený do tohto procesu návrhu, aby sa zabezpečilo, že bezpečnostné záruky sa integrujú s funkčnosťou aplikácie.

Myslite ako útočník. Navrhnite svoje testovacie prípady s predpokladom, že systém bol napadnutý. Týmto spôsobom môžete odhaliť potenciálne zraniteľné miesta a podľa toho uprednostniť testy.

Spustite testy štruktúrovaným spôsobom a s opakovateľným procesom. Postavte svoju prísnosť testovania na kadencii, typoch testov, hnacích faktoroch a plánovaných výsledkoch.

Použite správny nástroj pre danú prácu. Používajte nástroje, ktoré sú nakonfigurované na prácu s pracovným zaťažením. Ak nástroj nemáte, kúpte si ho. Nestavajte to. Bezpečnostné nástroje sú vysoko špecializované a vytvorenie vlastného nástroja môže predstavovať riziká. Využite odbornosť a nástroje, ktoré ponúkajú centrálne tímy SecOps alebo externé prostriedky, ak tím pre pracovné zaťaženie nemá túto odbornosť.

Nastavte oddelené prostredia. Testy možno klasifikovať ako deštruktívne alebo nedeštruktívne. Nedeštruktívne testy nie sú invazívne. Naznačujú, že sa vyskytol problém, ale nemenia funkčnosť s cieľom odstrániť problém. Deštruktívne testy sú invazívne a môžu poškodiť funkčnosť odstránením údajov z databázy.

Testovanie v produkčnom prostredí vám poskytne najlepšie informácie, ale spôsobí najväčšie narušenie. V produkčnom prostredí zvyknete robiť len nedeštruktívne testy. Testovanie v neprodukčných prostrediach je zvyčajne menej rušivé, ale nemusí presne reprezentovať konfiguráciu produkčného prostredia spôsobmi, ktoré sú dôležité pre bezpečnosť.

Môžete vytvoriť izolovaný klon vášho produkčného prostredia pomocou funkcie kopírovania prostredia. Ak máte nastavené kanály nasadenia, môžete svoje riešenia nasadiť aj do vyhradeného testovacieho prostredia.

Vždy vyhodnoťte výsledky testu. Testovanie je zbytočná námaha, ak sa výsledky nepoužijú na uprednostňovanie akcií a na vylepšenia. Zdokumentujte bezpečnostné pokyny vrátane osvedčených postupov, ktoré odhalíte. Dokumentácia, ktorá zachytáva výsledky a plány nápravy, vzdeláva tím o rôznych spôsoboch, akými sa útočníci môžu pokúsiť narušiť bezpečnosť. Vykonávajte pravidelné bezpečnostné školenia pre vývojárov, správcov a testerov.

Pri navrhovaní plánov testovania sa zamyslite nad nasledujúcimi otázkami:

• Ako často očakávate spustenie testu a ako to ovplyvní vaše prostredie?
• Aké sú rôzne typy testov, ktoré by ste mali spustiť?

Ako často očakávate, že budú testy prebiehať?

Pravidelne testujte pracovné zaťaženie, aby ste sa uistili, že zmeny nepredstavujú bezpečnostné riziká a že nedochádza k žiadnym regresom. Tím musí byť tiež pripravený reagovať na overenia zabezpečenia organizácie, ktoré môžu byť vykonané kedykoľvek. Existujú aj testy, ktoré môžete spustiť v odpoveď na bezpečnostný incident. Nasledujúce časti poskytujú odporúčania týkajúce sa frekvencie testov.

Rutinné testy

Rutinné testy sa vykonávajú s pravidelnou kadenciou ako súčasť vašich štandardných prevádzkových postupov a na splnenie požiadaviek zhody. Rôzne testy môžu prebiehať v rôznych kadenciách, ale kľúčové je, že sa vykonávajú pravidelne a podľa plánu.

Tieto testy by ste mali integrovať do vášho SDLC, pretože poskytujú hĺbkovú obranu v každej fáze. Diverzifikujte testovaciu sadu na overenie záruk identity, ukladania a prenosu údajov a komunikačných kanálov. Vykonajte rovnaké testy v rôznych bodoch životného cyklu, aby ste sa uistili, že nedôjde k regresii. Rutinné testy pomáhajú stanoviť počiatočný benchmark. To je však len východiskový bod. Keď odhaľujete nové problémy v rovnakých bodoch životného cyklu, pridávate nové testovacie prípady. Testy sa zlepšujú aj opakovaním.

V každej fáze by tieto testy mali overiť pridaný alebo odstránený kód alebo zmenené konfiguračné nastavenia, aby sa zistil vplyv týchto zmien na bezpečnosť. Mali by ste zlepšiť účinnosť testov pomocou automatizácie, vyváženej s partnerskými hodnoteniami.

Zvážte spustenie bezpečnostných testov ako súčasť automatizovaného potrubia alebo plánovaného testovania. Čím skôr zistíte problémy so zabezpečením, tým ľahšie je nájsť kód alebo zmenu konfigurácie, ktorá ich spôsobuje.

Nespoliehajte sa len na automatizované testy. Použite manuálne testovanie na odhalenie zraniteľností, ktoré dokáže zachytiť iba ľudská odbornosť. Manuálne testovanie je dobré pre prieskumné prípady použitia a zisťovanie neznámych rizík.

Improvizované testy

Improvizované testy poskytujú okamžitú validáciu bezpečnostnej ochrany. Bezpečnostné výstrahy, ktoré môžu v danom čase ovplyvniť pracovné zaťaženie, spúšťajú tieto testy. Organizačné mandáty môžu vyžadovať pauzu a testovanie myslenia na overenie účinnosti obranných stratégií, ak výstraha eskaluje na núdzovú situáciu.

Prínosom improvizovaných testov je pripravenosť na skutočný incident. Tieto testy môžu byť vynútenou funkciou, aby vykonala užívateľské akceptačné testovanie (UAT).

Bezpečnostný tím môže auditovať všetky pracovné zaťaženia a podľa potreby spustiť tieto testy. Ako vlastník pracovného zaťaženia musíte uľahčovať bezpečnostné tímy a spolupracovať s nimi. S bezpečnostnými tímami si dohodnite dostatočný čas na prípravu, aby ste sa mohli pripraviť. Uznajte a komunikujte svojmu tímu a zainteresovaným stranám, že tieto prerušenia sú nevyhnutné.

V iných prípadoch možno budete musieť spustiť testy a nahlásiť stav zabezpečenia systému proti potenciálnej hrozbe.

Kompromis : Keďže improvizované testy sú rušivé udalosti, počítajte so zmenou priorít úloh, čo môže oddialiť inú plánovanú prácu.

Riziko: Existuje riziko neznámeho. Improvizované testy môžu byť jednorazovým úsilím bez zavedených procesov alebo nástrojov. No prevládajúcim rizikom je potenciálne prerušenie rytmu podnikania. Tieto riziká musíte zhodnotiť vo vzťahu k prínosom.

Testy bezpečnostných incidentov

Existujú testy, ktoré odhalia príčinu bezpečnostného incidentu pri jeho zdroji. Tieto bezpečnostné medzery musia byť vyriešené, aby sa zabezpečilo, že sa incident nebude opakovať.

Incidenty tiež zlepšujú testovacie prípady v priebehu času odhaľovaním existujúcich medzier. Tím by mal uplatniť ponaučenie z incidentu a pravidelne začleňovať vylepšenia.

Aké sú rôzne typy testov?

Testy možno kategorizovať podľa technológie a podľa metódií testovania. Skombinujte tieto kategórie a prístupy v rámci týchto kategórií, aby ste získali úplné pokrytie.

Pridaním viacerých testov a typov testov môžete odhaliť:

• Medzery v bezpečnostných kontrolách alebo kompenzačných kontrolách.
• Nesprávne konfigurácie.
• Medzery v pozorovateľnosti a metódach detekcie.

Dobré cvičenie modelovania hrozieb môže poukázať na kľúčové oblasti na zabezpečenie pokrytia a frekvencie testov. Odporúčania týkajúce sa modelovania hrozieb nájdete v časti Odporúčania na zabezpečenie životného cyklu vývoja.

Väčšinu testov opísaných v týchto častiach možno spustiť ako rutinné testy. Opakovateľnosť však môže v niektorých prípadoch spôsobiť náklady a spôsobiť narušenie. Pozorne zvážte tieto kompromisy.

Testy, ktoré overujú technologický zásobník

Tu je niekoľko príkladov typov testov a oblastí ich zamerania. Tento zoznam nie je úplný. Otestujte celý zásobník vrátane zásobníka aplikácií, frontendu, backendu, rozhraní API, databáz a akýchkoľvek externých integrácií.

• Zabezpečenie údajov: Otestujte účinnosť šifrovania údajov a kontroly prístupu, aby ste sa uistili, že údaje sú správne chránené pred neoprávneným prístupom a manipuláciou.
• Sieť a konektivita: Otestujte svoje brány firewall, aby ste sa uistili, že povoľujú iba očakávanú, povolenú a bezpečnú prevádzku pracovnej záťaže.
• Aplikácia: Otestujte zdrojový kód pomocou techník testovania zabezpečenia aplikácií (AST), aby ste sa uistili, že dodržiavate postupy bezpečného kódovania a zachytávajte chyby pri spustení, ako je poškodenie pamäte a problémy s privilégiami.
• Identita: Vyhodnoťte, či priradenia rolí a podmienené kontroly fungujú podľa plánu.

Testovacia metodika

Existuje veľa Perspektívy o metodológiách testovania. Odporúčame testy, ktoré umožňujú vyhľadávanie hrozieb simuláciou útokov v reálnom svete. Môžu identifikovať potenciálnych aktérov hrozieb, ich techniky a ich zneužitia, ktoré predstavujú hrozbu pre pracovnú záťaž. Urobte útoky čo najrealistickejšie. Využite všetky potenciálne vektory hrozieb, ktoré identifikujete počas modelovania hrozieb.

Tu je niekoľko výhod testovania prostredníctvom útokov v reálnom svete:

• Keď urobíte tieto útoky súčasťou rutinného testovania, použijete perspektívu zvonka, aby ste skontrolovali pracovné zaťaženie a ubezpečili sa, že obrana dokáže odolať útoku.
• Na základe toho, čo sa naučili, si tím zvyšuje úroveň vedomostí a zručností. Tím zlepšuje situačné povedomie a môže sám zhodnotiť svoju pripravenosť reagovať na incidenty.

Riziko: Testovanie vo všeobecnosti môže ovplyvniť výkon. Ak deštruktívne testy vymažú alebo poškodia údaje, môžu nastať problémy s kontinuitou prevádzky. S vystavením sa informáciám sú spojené aj riziká; dbajte na zachovanie dôvernosti údajov. Po dokončení testovania zaistite integritu údajov.

Niektoré príklady simulovaných testov zahŕňajú testovanie čiernej a bielej skrinky, penetračné testovanie a cvičenia vojnových hier.

Testovanie čiernej skrinky a bielej skrinky

Tieto typy testov ponúkajú dva rôzne Perspektívy. Pri testoch čiernej skrinky nie sú vnútorné časti systému viditeľné. V testoch white-box tester dobre rozumie aplikácii a dokonca má prístup ku kódu, protokolom, topológii zdrojov a konfiguráciám na vykonávanie experimentu.

Riziko: Rozdiel medzi týmito dvoma typmi je v nákladoch vopred. Testovanie v bielej skrinke môže byť drahé, pokiaľ ide o čas potrebný na pochopenie systému. V niektorých prípadoch si testovanie white-box vyžaduje zakúpenie špecializovaných nástrojov. Testovanie čiernej skrinky si nevyžaduje čas na rozbeh, ale nemusí byť také efektívne. Možno budete musieť vynaložiť ďalšie úsilie na odhalenie problémov. Ide o časovú investíciu.

Testy, ktoré simulujú útoky prostredníctvom penetračného testovania

Bezpečnostní experti, ktorí nie sú súčasťou IT alebo aplikačných tímov organizácie, vykonávajú penetračné testovanie alebo pentestovanie. Pozerajú sa na systém tak, ako útočníci dosahujú povrch útoku. Ich cieľom je nájsť bezpečnostné medzery zhromažďovaním informácií, analýzou zraniteľností a nahlasovaním výsledkov.

Kompromis: Penetračné testy sú improvizované a môžu byť drahé z hľadiska prerušenia a peňažných investícií, pretože pentesting je zvyčajne platenou ponukou odborníkov tretích strán.

Riziko: Pentesting môže ovplyvniť runtime prostredie a môže narušiť dostupnosť pre normálnu prevádzku.

Odborníci môžu potrebovať prístup k citlivým údajom v celej organizácii. Dodržiavajte pravidlá zapojenia, aby ste zabezpečili, že prístup nebude zneužitý. Pozrite si zdroje uvedené v Súvisiace informácie.

Testy, ktoré simulujú útoky prostredníctvom cvičení vojnových hier

V tejto metodológii simulovaných útokov existujú dva tímy:

• The červená tím je protivník, ktorý sa pokúša modelovať útoky v reálnom svete. Ak sú úspešné, nájdete medzery vo svojom bezpečnostnom dizajne a vyhodnotíte rozsah výbušnosti pri ich narušení.
• The modrá tím je pracovný tím, ktorý sa bráni útokom. Testujú svoju schopnosť odhaliť, reagovať a napraviť útoky. Overujú obranu, ktorá bola implementovaná na ochranu zdrojov pracovného zaťaženia.

Ak sa vykonávajú ako rutinné testy, cvičenia vojnových hier môžu poskytnúť neustálu viditeľnosť a istotu, že vaša obrana funguje tak, ako bola navrhnutá. Cvičenia vojnových hier môžu potenciálne testovať naprieč úrovňami v rámci vašej pracovnej záťaže.

Obľúbenou voľbou na simuláciu realistických scenárov útoku je Microsoft Defender pre Office 365 Nácvik simulácie útoku.

Ďalšie informácie nájdete v časti Štatistiky a správy pre výcvik simulácie útoku.

Informácie o nastavení červeného a modrého tímu nájdete v Microsoft Cloud Red Teaming.

Power Platform uľahčenie

Microsoft Riešenie Sentinel for Microsoft Power Platform umožňuje zákazníkom odhaliť rôzne podozrivé aktivity, ako napríklad:

• Power Apps exekúcie z neoprávnených geografických oblastí
• Podozrivé zničenie údajov Power Apps
• Hromadné vymazanie Power Apps
• Prebehli phishingové útoky Power Apps
• Power Automate prúdi činnosť odchádzajúcimi zamestnancami
• Microsoft Power Platform konektory pridané do prostredia
• Aktualizácia alebo odstránenie Microsoft Power Platform zásad prevencie straty údajov

Viac informácií nájdete v Microsoft riešenie Sentinel pre Microsoft Power Platform prehľad.

Dokumentáciu k produktu nájdete v časti Možnosti lovu v Microsoft Sentinel.

Microsoft Defender for Cloud ponúka skenovanie zraniteľností pre rôzne technologické oblasti. Ďalšie informácie nájdete v časti Povolenie skenovania zraniteľností pomocou Microsoft Defender Vulnerability Management.

Prax DevSecOps integruje testovanie bezpečnosti ako súčasť neustáleho a neustáleho zlepšovania myslenia. Cvičenia vojnových hier sú bežnou praxou, ktorá je integrovaná do rytmu podnikania v Microsoft. Ďalšie informácie nájdete v časti Zabezpečenie v DevOps (DevSecOps).

Azure DevOps podporuje nástroje tretích strán, ktoré je možné automatizovať ako súčasť kontinuálnej integrácie/kontinuálneho nasadzovania (CI/CD). Ďalšie informácie nájdete v časti Povolenie DevSecOps pomocou Azure a GitHub.

Súvisiace informácie

Najnovšie penetračné testy a hodnotenia bezpečnosti nájdete na portáli Microsoft Service Trust.

Microsoft vykonáva rozsiahle testovanie Microsoft cloudových služieb. Toto testovanie zahŕňa penetračné testovanie s výsledkami zverejnenými na portáli Service Trust Portal pre vašu organizáciu. Vaša organizácia môže vykonať svoj vlastný penetračný test v službách Microsoft Power Platform a Microsoft Dynamics 365. Všetky penetračné testy musia byť v súlade s Microsoft pravidlami zapojenia testovania penetrácie cloudu. Je dôležité si uvedomiť, že v mnohých prípadoch Microsoft Cloud využíva zdieľanú infraštruktúru na hosťovanie vašich aktív a aktív patriacich iným zákazníkom. Všetky penetračné testy musíte obmedziť na svoje aktíva a vyhnúť sa neúmyselným následkom pre ostatných zákazníkov vo vašom okolí.

Dodržiavajte pravidlá zapojenia, aby ste sa uistili, že prístup nebude zneužitý. Pokyny na plánovanie a vykonávanie simulovaných útokov nájdete v časti:

• Pravidlá penetračného testovania
• Penetračné testovanie

Útoky odmietnutia služby (DoS) môžete simulovať v Azure. Nezabudnite dodržiavať zásady uvedené v Azure testovanie simulácie ochrany DDoS.

Kontrolný zoznam zabezpečenia

Pozrite si úplný súbor odporúčaní.