Belešku
Pristup ovoj stranici zahteva autorizaciju. Možete pokušati da se prijavite ili da promenite direktorijume.
Pristup ovoj stranici zahteva autorizaciju. Možete pokušati da promenite direktorijume.
Odnosi se na ovu Power Platform preporuku za proveru dobro arhitektonske bezbednosti:
| SE:09 | Uspostaviti sveobuhvatan režim testiranja koji kombinuje pristupe za sprečavanje bezbednosnih problema, validaciju implementacija za sprečavanje pretnji i testiranje mehanizama za otkrivanje pretnji. |
|---|
Rigorozno testiranje je temelj dobrog bezbednosnog dizajna. Testiranje je taktički oblik validacije kako bi se osiguralo da kontrole rade kako je predviđeno. Testiranje je takođe proaktivan način otkrivanja ranjivosti u sistemu.
Uspostaviti strogost testiranja kroz ritam i verifikaciju iz više perspektiva. Trebalo bi da uključite stavove iznutra prema van koji testiraju platformu i infrastrukturu i spoljne procene koje testiraju sistem kao spoljni napadač.
Ovaj vodič daje preporuke za testiranje bezbednosnog položaja vašeg radnog opterećenja. Implementirajte ove metode testiranja kako biste poboljšali otpornost vašeg radnog opterećenja na napade i održali poverljivost, integritet i dostupnost resursa.
Definicije
| Termin | Definicija |
|---|---|
| Testiranje bezbednosti aplikacija (AST) | Tehnika Microsoft Securiti Development Lifecicle (SDL) koja koristi metodologije testiranja bele i crne kutije za proveru bezbednosnih ranjivosti u kodu. |
| Testiranje crne kutije | Metodologija testiranja koja potvrđuje eksterno vidljivo ponašanje aplikacije bez poznavanja unutrašnjosti sistema. |
| Plavi tim | Tim koji se brani od napada crvenog tima u ratnoj igri vežbe. |
| Testiranje penetracije | Metodologija testiranja koja koristi etičke hakerske tehnike za potvrđivanje bezbednosne odbrane sistema. |
| Crveni tim | Tim koji igra ulogu protivnika i pokušava da hakuje sistem u vežbi ratne igre. |
| Životni ciklus razvoja bezbednosti (SDL) | Skup praksi koje pruža Microsoft koji podržava bezbednosno osiguranje i zahteve usklađenosti. |
| Životni ciklus razvoja softvera (SDLC) | Višestepeni, sistematski proces za razvoj softverskih sistema. |
| Testiranje bele kutije | Metodologija testiranja u kojoj je struktura koda poznata praktičaru. |
Ključne strategije dizajna
Testiranje je strategija o kojoj se ne može pregovarati, posebno za bezbednost. Omogućava vam da proaktivno otkrijete i rešite bezbednosne probleme pre nego što se mogu iskoristiti i da proverite da li bezbednosne kontrole koje ste implementirali funkcionišu kako je dizajnirano.
Obim testiranja mora uključivati aplikaciju, infrastrukturu i automatizovane i ljudske procese.
Belešku
Ova uputstva prave razliku između testiranja i odgovora na incident. Iako je testiranje mehanizam detekcije koji idealno rešava probleme pre proizvodnje, ne treba ga mešati sa sanacijom ili istragom koja se vrši kao deo odgovora na incident. Aspekt oporavka od bezbednosnih incidenata opisan je u Preporukama za odgovor na bezbednosne incidente.
Budite uključeni u planiranje testova. Tim za radno opterećenje možda neće dizajnirati testne slučajeve. Taj zadatak je često centralizovan u preduzeću ili završen od strane spoljnih stručnjaka za bezbednost. Tim za radno opterećenje treba da bude uključen u taj proces dizajna kako bi se osiguralo da se bezbednosne garancije integrišu sa funkcionalnošću aplikacije.
Razmišljajte kao napadač. Dizajnirajte svoje testne slučajeve uz pretpostavku da je sistem napadnut. Na taj način možete otkriti potencijalne ranjivosti i odrediti prioritete testova u skladu s tim.
Pokrenite testove na strukturiran način i sa ponovljivim procesom. Izgradite svoju strogost testiranja oko ritma, vrste testova, faktori vožnje i željeni ishodi.
Koristite pravi alat za posao. Koristite alate koji su konfigurisani za rad sa radnim opterećenjem. Ako nemate alat, kupite alat. Nemojte ga graditi. Sigurnosni alati su visoko specijalizovani, a izgradnja sopstvenog alata može dovesti do rizika. Iskoristite stručnost i alate koje nude centralni SecOps timovi ili spoljnim sredstvima ako tim za radno opterećenje nema tu stručnost.
Podesite odvojena okruženja. Testovi se mogu klasifikovati kao destruktivni ili nedestruktivni. Testovi bez razaranja nisu invazivni. Oni ukazuju na to da postoji problem, ali oni ne menjaju funkcionalnost kako bi se rešio problem. Destruktivni testovi su invazivni i mogu oštetiti funkcionalnost brisanjem podataka iz baze podataka.
Testiranje u proizvodnim okruženjima daje vam najbolje informacije, ali izaziva najviše poremećaja. Skloni ste da radite samo testove bez razaranja u proizvodnim okruženjima. Testiranje u neproizvodnim okruženjima je obično manje ometajuće, ali možda neće tačno predstavljati konfiguraciju proizvodnog okruženja na načine koji su važni za bezbednost.
Možete kreirati izolovani klon vašeg proizvodnog okruženja pomoću funkcije kopiranja okruženja. Ako imate postavljene cevovode za raspoređivanje, takođe možete da primenite svoja rešenja u namensko okruženje za testiranje.
Uvek procenite rezultate testa. Testiranje je uzaludan napor ako se rezultati ne koriste za određivanje prioriteta akcija i poboljšanje uzvodno. Dokumentujte bezbednosne smernice, uključujući najbolje prakse, koje ste otkrili. Dokumentacija koja snima rezultate i planove za sanaciju obrazuje tim o različitim načinima na koje napadači mogu pokušati da prekrše bezbednost. Sprovesti redovnu bezbednosnu obuku za programere, administratore i testere.
Kada dizajnirate svoje testne planove, razmislite o sledećim pitanjima:
- Koliko često očekujete da će se test pokrenuti i kako to utiče na vaše okruženje?
- Koje su različite vrste testova koje treba pokrenuti?
Koliko često očekujete da će se testovi pokrenuti?
Redovno testirajte radno opterećenje kako biste bili sigurni da promene ne uvode bezbednosne rizike i da nema regresija. Tim takođe mora biti spreman da odgovori na organizacione bezbednosne validacije koje se mogu sprovesti u bilo kom trenutku. Postoje i testovi koje možete pokrenuti kao odgovor na bezbednosni incident. Sledeći odeljci daju preporuke o učestalosti testova.
Rutinski testovi
Rutinski testovi se sprovode u redovnom ritmu, kao deo vaših standardnih operativnih procedura i da ispune zahteve usklađenosti. Različiti testovi mogu se izvoditi u različitim ritmovima, ali ključno je da se sprovode periodično i po rasporedu.
Trebalo bi da integrišete ove testove u svoj SDLC jer oni pružaju dubinsku odbranu u svakoj fazi. Diverzifikujte paket testova kako biste potvrdili garancije za identitet, skladištenje i prenos podataka i kanale komunikacije. Sprovedite iste testove u različitim tačkama životnog ciklusa kako biste bili sigurni da nema regresija. Rutinski testovi pomažu u uspostavljanju početnog repera. Međutim, to je samo polazna tačka. Dok otkrivate nove probleme u istim tačkama životnog ciklusa, dodajete nove testne slučajeve. Testovi se takođe poboljšavaju ponavljanjem.
U svakoj fazi, ovi testovi treba da potvrde kod koji je dodat ili uklonjen ili podešavanja konfiguracije koja su se promenila kako bi se otkrio bezbednosni uticaj tih promena. Trebalo bi da poboljšate efikasnost testova automatizacijom, uravnoteženom sa recenzijama.
Razmislite o pokretanju bezbednosnih testova kao deo automatizovanog cevovoda ili zakazanog probnog rada. Što pre otkrijete bezbednosne probleme, lakše je pronaći kod ili promenu konfiguracije koja ih uzrokuje.
Ne oslanjajte se samo na automatizovane testove. Koristite ručno testiranje da biste otkrili ranjivosti koje samo ljudska stručnost može uhvatiti. Ručno testiranje je dobro za istraživačke slučajeve upotrebe i pronalaženje nepoznatih rizika.
Improvizovani testovi
Improvizovani testovi pružaju validaciju bezbednosne odbrane u tački u vremenu. Bezbednosna upozorenja koja mogu uticati na radno opterećenje u to vreme pokreću ove testove. Organizacioni mandati mogu zahtevati način razmišljanja o pauzi i testiranju kako bi se proverila efikasnost strategija odbrane ako upozorenje eskalira u hitan slučaj.
Prednost improvizovanih testova je spremnost za pravi incident. Ovi testovi mogu biti funkcija prisiljavanja za testiranje prihvatanja korisnika (UAT).
Tim za bezbednost može da izvrši reviziju svih radnih opterećenja i pokrene ove testove po potrebi. Kao vlasnik radnog opterećenja, morate olakšati i sarađivati sa timovima za bezbednost. Pregovarajte dovoljno vremena sa timovima za obezbeđenje, tako da možete da se pripremite. Priznajte i komunicirajte sa svojim timom i zainteresovanim stranama da su ovi poremećaji neophodni.
U drugim slučajevima, možda ćete morati da pokrenete testove i prijavite bezbednosno stanje sistema protiv potencijalne pretnje.
Kompromis: Pošto su improvizovani testovi ometajući događaji, očekujte da ćete ponovo odrediti prioritete zadataka, što može odložiti drugi planirani rad.
Rizik: Postoji rizik od nepoznatog. Improvizovani testovi mogu biti jednokratni napori bez utvrđenih procesa ili alata. Ali preovlađujući rizik je potencijalni prekid ritma poslovanja. Morate da procenite te rizike u odnosu na koristi.
Testovi bezbednosnih incidenata
Postoje testovi koji otkrivaju uzrok bezbednosnog incidenta na njegovom izvoru. Ove bezbednosne praznine moraju biti rešene kako bi se osiguralo da se incident ne ponovi.
Incidenti takođe poboljšavaju testne slučajeve tokom vremena otkrivanjem postojećih praznina. Tim treba da primeni lekcije naučene iz incidenta i rutinski uključi poboljšanja.
Koje su različite vrste testova?
Testovi se mogu kategorizovati po tehnologiji i metodologijama testiranja. Kombinujte te kategorije i pristupe unutar tih kategorija da biste dobili potpunu pokrivenost.
Dodavanjem više testova i tipova testova, možete otkriti:
- Praznine u bezbednosnim kontrolama ili kompenzacionim kontrolama.
- Pogrešne konfiguracije.
- Praznine u metodama posmatranja i detekcije.
Dobra vežba modeliranja pretnji može ukazati na ključne oblasti kako bi se osigurala pokrivenost i učestalost testa. Za preporuke o modeliranju pretnji, pogledajte Preporuke za obezbeđivanje životnog ciklusa razvoja.
Većina testova opisanih u ovim odeljcima može se pokrenuti kao rutinski testovi. Međutim, ponovljivost može nastati troškovima u nekim slučajevima i izazvati poremećaje. Pažljivo razmotrite te kompromise.
Testovi koji potvrđuju tehnološki stek
Evo nekoliko primera tipova testova i njihovih fokusnih oblasti. Ova lista nije iscrpna. Testirajte ceo stek, uključujući aplikaciju, prednji kraj, zadnji kraj, API-je, baze podataka i sve spoljne integracije.
- Bezbednost podataka: Testirajte efikasnost šifrovanja podataka i kontrole pristupa kako bi se osiguralo da su podaci pravilno zaštićeni od neovlašćenog pristupa i neovlašćenog ometanja.
- Mreža i povezivanje: Testirajte svoje zaštitne zidove kako biste bili sigurni da dozvoljavaju samo očekivani, dozvoljeni i bezbedan saobraćaj na radnom opterećenju.
- Primena: Testirajte izvorni kod pomoću tehnika testiranja bezbednosti aplikacija (AST) kako biste bili sigurni da pratite bezbedne prakse kodiranja i da uhvatite greške u izvođenju kao što su oštećenje memorije i problemi sa privilegijama.
- Identitet: Procenite da li dodele uloga i uslovne provere rade kako je predviđeno.
Metodologija ispitivanja
Postoji mnogo perspektiva metodologija testiranja. Preporučujemo testove koji omogućavaju lov na pretnje simulacijom napada u stvarnom svetu. Oni mogu da identifikuju potencijalne aktere pretnji, njihove tehnike i njihove podvige koji predstavljaju pretnju radnom opterećenju. Učinite napade što realnijim. Koristite sve potencijalne vektore pretnji koje identifikujete tokom modeliranja pretnji.
Evo nekih prednosti testiranja kroz napade u stvarnom svetu:
- Kada ove napade učinite delom rutinskog testiranja, koristite spoljašnju perspektivu da biste proverili radno opterećenje i uverili se da odbrana može da izdrži napad.
- Na osnovu lekcija koje su naučili, tim nadograđuje svoje znanje i nivo veština. Tim poboljšava situacionu svest i može samoproceniti svoju spremnost da odgovori na incidente.
Neki primeri simuliranih testova uključuju testiranje crne kutije i bele kutije, testiranje penetracije i vežbe ratnih igara.
Testiranje crne kutije i bele kutije
Ovi tipovi testova nude dve različite perspektive. U testovima crne kutije, unutrašnjost sistema nije vidljiva. U testovima bele kutije, tester dobro razume aplikaciju i čak ima pristup kodu, evidencijama, topologiji resursa i konfiguracijama za sprovođenje eksperimenta.
Testovi koji simuliraju napade kroz testiranje penetracije
Stručnjaci za bezbednost koji nisu deo IT ili aplikativnih timova organizacije sprovode testiranje penetracije ili pentesting. Oni gledaju na sistem na način na koji zlonamerni akteri obuhvataju površinu napada. Njihov cilj je da pronađu bezbednosne praznine prikupljanjem informacija, analizom ranjivosti i izveštavanjem o rezultatima.
Praktičari će možda trebati pristup osetljivim podacima u celoj organizaciji. Pratite pravila angažovanja kako biste osigurali da se pristup ne zloupotrebljava. Pogledajte resurse navedene u Srodne informacije.
Testovi koji simuliraju napade kroz vežbe ratnih igara
U ovoj metodologiji simuliranih napada postoje dva tima:
- Crveni tim je protivnik koji pokušava da modelira napade u stvarnom svetu. Ako su uspešni, naći ćete praznine u vašem bezbednosnom dizajnu i proceniti radijus eksplozije zadržavanje njihovih kršenja.
- Plavi tim je tim za radno opterećenje koji se brani od napada. Oni testiraju svoju sposobnost da otkriju, odgovore i saniraju napade. Oni potvrđuju odbranu koja je implementirana radi zaštite resursa radnog opterećenja.
Ako se sprovode kao rutinski testovi, vežbe ratnih igara mogu pružiti stalnu vidljivost i sigurnost da vaša odbrana radi kako je dizajnirano. Vežbe ratnih igara mogu potencijalno testirati na svim nivoima u okviru vaših radnih opterećenja.
Popularan izbor za simulaciju realnih scenarija napada je Microsoft Defender za Office 365 simulaciju napada.
Za više informacija pogledajte Uvid i izveštaji za obuku simulacije napada.
Za informacije o podešavanju crvenog i plavog tima, pogledajte Microsoft Cloud Red Teaming.
Power Platform Olakšavanju
Microsoft Sentinel rešenje za Microsoft Power Platform omogućava korisnicima da otkriju različite sumnjive aktivnosti, kao što su:
- Power Apps izvršenje iz neovlašćenih geografija
- Sumnjivo uništavanje podataka od strane Power Apps
- Masovno brisanje Power Apps
- Phishing napadi napravljeni kroz Power Apps
- Power Automate tokovi aktivnosti od strane zaposlenih koji odlaze
- Microsoft Power Platform konektori dodani u okruženje
- Ažuriranje Microsoft Power Platform ili uklanjanje politika podataka
Za više informacija pogledajte Microsoft Sentinel rešenje za Microsoft Power Platform pregled.
Za dokumentaciju o proizvodu pogledajte članke Mogućnosti lova u programu Microsoft Sentinel.
Microsoft Defender for Cloud nudi skeniranje ranjivosti za različite tehnološke oblasti. Za više informacija pogledajte Omogućite skeniranje ranjivosti pomoću Microsoft Defender Vulnerability Management-a.
Praksa DevSecOps-a integriše bezbednosno testiranje kao deo stalnog i kontinuiranog načina razmišljanja o poboljšanju. Vežbe ratnih igara su uobičajena praksa koja je integrisana u ritam poslovanja u Microsoftu. Za više informacija, pogledajte Bezbednost u DevOps (DevSecOps).
Azure DevOps podržava alate nezavisnih proizvođača koji se mogu automatizovati kao deo cevovoda za kontinuiranu integraciju / kontinuirano raspoređivanje (CI / CD). Za više informacija pogledajte Omogućite DevSecOps sa Azure i GitHub.
Srodne informacije
Najnoviji testovi penetracije i bezbednosne procene mogu se pronaći na Microsoft portalu za pouzdanost usluga.
Microsoft vrši opsežno testiranje Microsoft Cloud usluga. Ovo testiranje uključuje testiranje penetracije, a rezultati su objavljeni na portalu Service Trust za vašu organizaciju. Vaša organizacija može da izvrši sopstveni test penetracije na Microsoft Power Platform i Microsoft Dynamics 365 usluga. Sva testiranja penetracije moraju biti u skladu sa Microsoft Cloud Penetration Testing Pravila angažovanja. Važno je zapamtiti da u mnogim slučajevima Microsoft Cloud koristi zajedničku infrastrukturu za hostovanje vaše imovine i imovine koja pripada drugim kupcima. Morate ograničiti sve testove penetracije na svoju imovinu i izbegavati neželjene posledice za druge kupce oko vas.
Pratite pravila angažovanja kako biste bili sigurni da pristup nije zloupotrebljen. Saznajte više o planiranju i izvršavanju simuliranih napada:
Možete simulirati uskraćivanje usluge (DoS) napade u Azure. Budite sigurni da pratite politike postavljene u Azure DDoS Protection simulacijskom testiranju.
Bezbednosna kontrolna lista
Pogledajte kompletan set preporuka.