Priporočila za varnostno testiranje
Velja za to Power Platform priporočilo za dobro strukturiran varnostni kontrolni seznam:
| SE:09 | Vzpostavite obsežen režim testiranja, ki združuje pristope za preprečevanje varnostnih težav, preverjanje implementacij preprečevanja groženj in preizkušanje mehanizmov za odkrivanje groženj. |
|---|
Strogo testiranje je temelj dobre varnostne zasnove. Testiranje je taktična oblika validacije, s katero se zagotovi, da kontrole delujejo, kot je predvideno. Testiranje je tudi proaktiven način za odkrivanje ranljivosti v sistemu.
Vzpostavite strogost testiranja s kadenco in preverjanjem iz več perspektiv. Vključiti morate poglede od znotraj navzven, ki preizkušajo platformo in infrastrukturo, ter ocene od zunaj navznoter, ki preizkušajo sistem kot zunanji napadalec.
Ta priročnik ponuja priporočila za testiranje varnostne drže vaše delovne obremenitve. Izvedite te testne metode, da izboljšate odpornost svoje delovne obremenitve na napade in ohranite zaupnost, celovitost in razpoložljivost virov.
Definicije
| Trajanje | Definicija |
|---|---|
| Testiranje varnosti aplikacij (AST) | Tehnika Microsoftovega življenjskega cikla varnostnega razvoja (SDL), ki uporablja metodologije testiranja bele in črne škatle za preverjanje varnostnih ranljivosti v kodi. |
| Testiranje črne skrinjice | Metodologija testiranja, ki potrjuje zunanje vidno vedenje aplikacije brez poznavanja notranjosti sistema. |
| Modra ekipa | Ekipa, ki se brani pred napadi rdeče ekipe v vaji vojne igre. |
| Testiranje penetracije | Metodologija testiranja, ki uporablja etične hekerske tehnike za potrditev varnostne obrambe sistema. |
| Rdeča ekipa | Ekipa, ki igra vlogo nasprotnika in poskuša vdreti v sistem v vaji vojne igre. |
| Življenjski cikel razvoja varnosti (SDL) | Nabor praks, ki jih nudi Microsoft in podpira zahteve glede zagotavljanja varnosti in skladnosti. |
| Življenjski cikel razvoja programske opreme (SDLC) | Večstopenjski, sistematičen proces za razvoj programskih sistemov. |
| Testiranje v beli škatli | Metodologija testiranja, pri kateri izvajalec pozna strukturo kode. |
Ključne strategije oblikovanja
Testiranje je strategija, o kateri se ni mogoče pogajati, zlasti za varnost. Omogoča vam proaktivno odkrivanje in reševanje varnostnih težav, preden jih je mogoče izkoristiti, ter preverjanje, ali varnostni nadzor, ki ste ga implementirali, deluje, kot je bilo načrtovano.
Obseg testiranja mora vključevati aplikacijo, infrastrukturo ter avtomatizirane in človeške procese.
opomba,
Ta navodila razlikujejo med testiranjem in odzivom na incident. Čeprav je testiranje mehanizem odkrivanja, ki v idealnem primeru odpravi težave pred proizvodnjo, ga ne smemo zamenjevati s sanacijo ali preiskavo, ki je opravljena kot del odziva na incident. Vidik okrevanja po varnostnih incidentih je opisan v Priporočilih za odziv na varnostni incident.
Sodelujte pri načrtovanju testov. Ekipa za delovno obremenitev morda ne bo oblikovala testnih primerov. Ta naloga je pogosto centralizirana v podjetju ali jo opravijo zunanji varnostni strokovnjaki. Skupina za delovno obremenitev mora biti vključena v ta proces načrtovanja, da se zagotovi integracija varnostnih zagotovil s funkcionalnostjo aplikacije.
Razmišljaj kot napadalec. Oblikujte svoje testne primere ob predpostavki, da je bil sistem napaden. Tako lahko odkrijete morebitne ranljivosti in ustrezno razvrstite teste po prednosti.
Izvajajte teste na strukturiran način in s ponovljivim postopkom. Zgradite svojo strogost testiranja glede na kadenco, vrste testov, gonilne dejavnike in predvidene rezultate.
Uporabite pravo orodje za delo. Uporabite orodja, ki so konfigurirana za delo z delovno obremenitvijo. Če nimate orodja, ga kupite. Ne gradi ga. Varnostna orodja so visoko specializirana in izdelava lastnega orodja lahko predstavlja tveganje. Izkoristite strokovno znanje in orodja, ki jih ponujajo osrednje ekipe SecOps ali z zunanjimi sredstvi, če ekipa za delovno obremenitev nima tega strokovnega znanja.
Nastavite ločena okolja. Teste lahko razvrstimo kot destruktivne in nedestruktivne. Nedestruktivni testi niso invazivni. Označujejo, da obstaja težava, vendar ne spremenijo funkcionalnosti, da bi odpravili težavo. Destruktivni testi so invazivni in lahko poškodujejo funkcionalnost z brisanjem podatkov iz zbirke podatkov.
Testiranje v produkcijskih okoljih vam da najboljše informacije, vendar povzroči največ motenj. V produkcijskih okoljih običajno opravljate le neporušitvene teste. Testiranje v neproizvodnih okoljih je običajno manj moteče, vendar morda ne predstavlja natančno konfiguracije produkcijskega okolja na načine, ki so pomembni za varnost.
Z uporabo funkcije kopiranja okolja lahko ustvarite izoliran klon svojega produkcijskega okolja. Če imate nastavljene cevovode za uvajanje, lahko svoje rešitve uvedete tudi v namensko preskusno okolje.
Vedno ocenite rezultate testa. Preizkušanje je zaman trud, če se rezultati ne uporabijo za določanje prednosti dejanj in izboljšav navzgor. Dokumentirajte varnostne smernice, vključno z najboljšimi praksami, ki jih odkrijete. Dokumentacija, ki zajema rezultate in sanacijske načrte, poučuje ekipo o različnih načinih, na katere lahko napadalci poskušajo vdreti v varnost. Izvajajte redna varnostna usposabljanja za razvijalce, skrbnike in preizkuševalce.
Ko oblikujete svoje testne načrte, razmislite o naslednjih vprašanjih:
- Kako pogosto pričakujete, da se bo preizkus izvajal in kako to vpliva na vaše okolje?
- Katere različne vrste testov bi morali izvesti?
Kako pogosto pričakujete izvajanje testov?
Redno preizkušajte delovno obremenitev, da se prepričate, da spremembe ne predstavljajo varnostnih tveganj in da ni regresij. Ekipa mora biti tudi pripravljena, da se odzove na validacije organizacijske varnosti, ki se lahko izvedejo kadar koli. Obstajajo tudi testi, ki jih lahko izvedete kot odgovor na varnostni incident. V naslednjih razdelkih so podana priporočila glede pogostosti testov.
Rutinski testi
Rutinski testi se izvajajo z redno hitrostjo, kot del vaših standardnih operativnih postopkov in za izpolnjevanje zahtev glede skladnosti. Različni testi se lahko izvajajo pri različnih kadencah, vendar je ključno, da se izvajajo redno in po urniku.
Te teste bi morali vključiti v svoj SDLC, ker zagotavljajo poglobljeno obrambo na vsaki stopnji. Razširite nabor testov, da preverite zagotovila za identiteto, shranjevanje in prenos podatkov ter komunikacijske kanale. Izvedite iste teste na različnih točkah življenjskega cikla, da zagotovite, da ni regresij. Rutinski testi pomagajo vzpostaviti začetno merilo. Vendar je to le izhodišče. Ko odkrijete nove težave na istih točkah življenjskega cikla, dodate nove testne primere. Tudi testi se izboljšajo s ponavljanjem.
Na vsaki stopnji morajo ti testi potrditi kodo, ki je bila dodana ali odstranjena, ali konfiguracijske nastavitve, ki so bile spremenjene, da bi zaznali vpliv teh sprememb na varnost. Učinkovitost testov bi morali izboljšati z avtomatizacijo, uravnoteženo s strokovnimi pregledi.
Razmislite o izvajanju varnostnih testov kot dela avtomatiziranega cevovoda ali načrtovanega preskusnega izvajanja. Prej ko odkrijete varnostne težave, lažje boste našli kodo ali spremembo konfiguracije, ki jih povzroča.
Ne zanašajte se samo na avtomatizirane teste. Uporabite ročno testiranje za odkrivanje ranljivosti, ki jih lahko ujame le človeško znanje. Ročno testiranje je dobro za raziskovalne primere uporabe in iskanje neznanih tveganj.
Improvizirani testi
Improvizirani testi zagotavljajo pravočasno preverjanje varnostnih obramb. Varnostna opozorila, ki bi lahko vplivala na delovno obremenitev v tistem času, sprožijo te preizkuse. Organizacijski mandati lahko zahtevajo miselnost za premor in preizkus, da se preveri učinkovitost obrambnih strategij, če opozorilo preraste v nujni primer.
Prednost improviziranih testov je pripravljenost na resničen incident. Ti testi so lahko prisilna funkcija k izvedbi testiranja sprejemljivosti uporabnika (UAT).
Varnostna skupina lahko pregleda vse delovne obremenitve in po potrebi izvede te teste. Kot lastnik delovne obremenitve morate olajšati varnostne ekipe in sodelovati z njimi. Z varnostnimi ekipami se dogovorite za dovolj časa, da se lahko pripravite. Potrdite in sporočite svoji ekipi in zainteresiranim stranem, da so te motnje nujne.
V drugih primerih boste morda morali zagnati teste in poročati o stanju varnosti sistema pred morebitno grožnjo.
Kompromis : Ker so improvizirani testi moteči dogodki, pričakujte ponovno razvrstitev prednostnih nalog, kar lahko odloži drugo načrtovano delo.
Tveganje: Obstaja tveganje neznanega. Improvizirani testi so lahko enkratni poskusi brez vzpostavljenih procesov ali orodij. A prevladujoče tveganje je morebitna motnja ritma poslovanja. Ta tveganja morate oceniti glede na koristi.
Testi varnostnih incidentov
Obstajajo testi, ki odkrijejo vzrok varnostnega incidenta pri njegovem izvoru. Te varnostne vrzeli je treba odpraviti, da preprečimo ponovitev incidenta.
Incidenti tudi sčasoma izboljšajo testne primere z odkrivanjem obstoječih vrzeli. Ekipa bi morala uporabiti izkušnje, pridobljene iz incidenta, in redno vključevati izboljšave.
Katere so različne vrste testov?
Teste lahko kategoriziramo po tehnologiji in po metodologijah testiranja. Združite te kategorije in pristope znotraj teh kategorij, da dobite popolno pokritost.
Z dodajanjem več testov in vrst testov lahko odkrijete:
- Vrzeli v varnostnem nadzoru ali kompenzacijskem nadzoru.
- Napačne konfiguracije.
- Vrzeli v opazljivosti in metodah odkrivanja.
Dobro modeliranje groženj lahko pokaže na ključna področja, da se zagotovi pokritost in pogostost testiranja. Za priporočila o modeliranju groženj glejte Priporočila za varovanje življenjskega cikla razvoja.
Večino testov, opisanih v teh razdelkih, je mogoče izvesti kot rutinske teste. Vendar lahko ponovljivost v nekaterih primerih povzroči stroške in povzroči motnje. Pazljivo razmislite o teh kompromisih.
Testi, ki potrjujejo tehnološki sklad
Tukaj je nekaj primerov vrst testov in njihovih osredotočenih področij. Ta seznam ni izčrpen. Preizkusite celoten sklad, vključno s skladom aplikacij, sprednjim in zadnjim delom, API-ji, bazami podatkov in morebitnimi zunanjimi integracijami.
- Varnost podatkov: preizkusite učinkovitost šifriranja podatkov in kontrol dostopa, da zagotovite ustrezno zaščito podatkov pred nepooblaščenim dostopom in spreminjanjem.
- Omrežje in povezljivost: Preizkusite svoje požarne zidove, da zagotovite, da dovoljujejo samo pričakovan, dovoljen in varen promet za delovno obremenitev.
- Aplikacija: Preizkusite izvorno kodo s tehnikami testiranja varnosti aplikacije (AST), da zagotovite, da sledite praksam varnega kodiranja, in da odkrijete napake med izvajanjem, kot so poškodbe pomnilnika in težave s privilegiji.
- Identiteta: Ocenite, ali dodelitve vlog in pogojna preverjanja delujejo, kot je predvideno.
Metodologija testiranja
Obstaja veliko pogledov na metodologije testiranja. Priporočamo teste, ki omogočajo lov na grožnje s simulacijo napadov iz resničnega sveta. Prepoznajo lahko potencialne akterje groženj, njihove tehnike in podvige, ki predstavljajo grožnjo delovni obremenitvi. Naj bodo napadi čim bolj realistični. Uporabite vse možne vektorje groženj, ki jih identificirate med modeliranjem groženj.
Tukaj je nekaj prednosti testiranja z napadi iz resničnega sveta:
- Ko te napade vključite v rutinsko testiranje, uporabite perspektivo od zunaj navznoter, da preverite delovno obremenitev in zagotovite, da obramba zdrži napad.
- Na podlagi pridobljenih lekcij ekipa nadgrajuje svoje znanje in raven spretnosti. Ekipa izboljšuje zavedanje situacije in lahko samooceni svojo pripravljenost za odzivanje na incidente.
Nekateri primeri simuliranih testov vključujejo testiranje črne in bele škatle, testiranje penetracije in vaje vojnih iger.
Testiranje v črni in beli škatli
Te vrste testov ponujajo dve različni perspektivi. Pri testih črne skrinjice notranjost sistema ni vidna. Pri testih bele škatle preizkuševalec dobro razume aplikacijo in ima celo dostop do kode, dnevnikov, topologije virov in konfiguracij za izvajanje poskusa.
Testi, ki simulirajo napade s testiranjem prodora
Varnostni strokovnjaki, ki niso del IT ali aplikacijskih skupin organizacije, izvajajo penetracijsko testiranje ali pentesting. Na sistem gledajo tako, da zlonamerni akterji dosegajo površino napada. Njihov cilj je najti varnostne vrzeli z zbiranjem informacij, analiziranjem ranljivosti in poročanjem o rezultatih.
Strokovnjaki bodo morda potrebovali dostop do občutljivih podatkov v celotni organizaciji. Upoštevajte pravila sodelovanja, da zagotovite, da dostop ne bo zlorabljen. Oglejte si vire, navedene v Poglej tudi.
Testi, ki simulirajo napade z vajami vojne igre
V tej metodologiji simuliranih napadov obstajata dve ekipi:
- The rdeča ekipa je nasprotnik, ki poskuša modelirati napade iz resničnega sveta. Če so uspešni, poiščete vrzeli v svoji varnostni zasnovi in ocenite radij zadrževanja njihovih vdorov.
- The modra ekipa je delovna ekipa, ki se brani pred napadi. Preizkušajo svojo sposobnost zaznavanja, odzivanja in sanacije napadov. Potrjujejo obrambo, ki je bila implementirana za zaščito virov delovne obremenitve.
Če se izvajajo kot rutinski testi, lahko vaje vojnih iger zagotovijo stalno vidljivost in zagotovilo, da vaša obramba deluje, kot je načrtovano. Vaje vojnih iger lahko potencialno preizkusijo več ravni znotraj vaših delovnih obremenitev.
Priljubljena izbira za simulacijo realističnih scenarijev napadov je Microsoft Defender za Office 365 usposabljanje simulacije napadov.
Za več informacij glejte Vpogledi in poročila za usposabljanje simulacije napada.
Za informacije o nastavitvi red-team in blue-team glejte Microsoft Cloud Red Teaming.
Power Platform olajšanje
Rešitev Microsoft Sentinel za Microsoft Power Platform omogoča strankam zaznavanje različnih sumljivih dejavnosti, kot so:
- Power Apps izvedba iz nepooblaščenih geografskih območij
- Sumljivo uničenje podatkov s strani Power Apps
- Množično brisanje Power Apps
- Izvedeni napadi lažnega predstavljanja Power Apps
- Power Automate pretaka aktivnost z odhajajočimi zaposlenimi
- Microsoft Power Platform priključki, dodani v okolje
- Posodobitev ali odstranitev Microsoft Power Platform pravilnikov za preprečevanje izgube podatkov
Za več informacij glejte Microsoft Sentinel rešitev za Microsoft Power Platform pregled.
Za dokumentacijo o izdelku glejte Lovne zmogljivosti v programu Microsoft Sentinel.
Microsoft Defender za oblak ponuja iskanje ranljivosti za različna tehnološka področja. Za več informacij glejte Omogočanje skeniranja ranljivosti z upravljanjem ranljivosti Microsoft Defender.
Praksa DevSecOps vključuje varnostno testiranje kot del stalne in nenehne miselnosti za izboljšave. Vaje vojnih iger so običajna praksa, ki je vključena v ritem poslovanja pri Microsoftu. Za več informacij glejte Varnost v DevOps (DevSecOps).
Azure DevOps podpira orodja tretjih oseb, ki jih je mogoče avtomatizirati kot del cevovodov za stalno integracijo/neprekinjeno uvajanje (CI/CD). Za več informacij glejte Omogočanje DevSecOps z Azure in GitHub.
Glejte tudi
Najnovejše preskuse možnosti vdora in ocene varnosti lahko najdete na Portalu za zanesljivost storitve Microsoft.
Microsoft izvaja obsežno testiranje storitev Microsoft Cloud. To testiranje vključuje testiranje prodora, rezultati pa so objavljeni na portalu Service Trust za vašo organizacijo. Vaša organizacija lahko izvede lasten test prodora na storitve Microsoft Power Platform in Microsoft Dynamics 365. Vsa testiranja penetracije morajo biti v skladu s pravili sodelovanja pri testiranju penetracije Microsoft Cloud. Pomembno si je zapomniti, da v mnogih primerih Microsoft Cloud uporablja skupno infrastrukturo za gostovanje vaših sredstev in sredstev, ki pripadajo drugim strankam. Vse teste prodora morate omejiti na svoja sredstva in se izogniti nenamernim posledicam za druge stranke okoli vas.
Upoštevajte pravila sodelovanja, da zagotovite, da dostop ne bo zlorabljen. Za navodila o načrtovanju in izvajanju simuliranih napadov glejte:
V Azure lahko simulirate napade zavrnitve storitve (DoS). Upoštevajte pravilnike, določene v Preizkušanje simulacije zaščite Azure DDoS.
Varnostni kontrolni seznam
Oglejte si celoten sklop priporočil.