Ieteikumi drošības testēšanai
Attiecas uz šo Power Platform labi izstrādāto drošības kontrolsaraksta ieteikumu:
| SE:09 | Izveidojiet visaptverošu testēšanas režīmu, kas apvieno pieejas, lai novērstu drošības problēmas, apstiprinātu draudu novēršanas ieviešanu un pārbaudītu draudu noteikšanas mehānismus. |
|---|
Stingra pārbaude ir laba drošības dizaina pamats. Testēšana ir taktisks validācijas veids, lai pārliecinātos, ka kontrole darbojas, kā paredzēts. Testēšana ir arī proaktīvs veids, kā atklāt sistēmas ievainojamības.
Izveidojiet testēšanas stingrību, izmantojot kadenci un verifikāciju no vairākiem Perspektīvas. Jums jāiekļauj iekšējie viedokļi, kas pārbauda platformu un infrastruktūru, un ārējie novērtējumi, kas pārbauda sistēmu kā ārējs uzbrucējs.
Šajā rokasgrāmatā ir sniegti ieteikumi jūsu darba slodzes drošības stāvokļa pārbaudei. Ieviesiet šīs testēšanas metodes, lai uzlabotu darba slodzes izturību pret uzbrukumiem un saglabātu konfidencialitāti, integritāti un resursu pieejamību.
Definīcijas
| Termins | Definīcija |
|---|---|
| Lietojumprogrammu drošības testēšana (AST) | Microsoft Security Development Lifecycle (SDL) metode, kas izmanto baltās kastes un melnās kastes testēšanas metodes, lai pārbaudītu, vai kodā nav drošības ievainojamības. |
| Melnās kastes testēšana | Testēšanas metodika, kas validē ārēji redzamo lietojumprogrammas uzvedību, nezinot par sistēmas iekšējiem elementiem. |
| Zilā komanda | Komanda, kas aizstāvas pret sarkanās komandas uzbrukumiem kara spēles vingrinājumā. |
| Ielaušanās testēšana | Testēšanas metodika, kas izmanto ētiskas uzlaušanas metodes, lai apstiprinātu sistēmas drošības aizsardzību. |
| Sarkanā komanda | Komanda, kas spēlē pretinieka lomu un mēģina uzlauzt sistēmu kara spēles vingrinājumā. |
| Drošības izstrādes dzīves cikls (SDL) | Prakses kopums, ko nodrošina Microsoft un kas atbalsta drošības nodrošināšanu un atbilstības prasības. |
| Programmatūras izstrādes dzīves cikls (SDLC) | Daudzpakāpju, sistemātisks programmatūras sistēmu izstrādes process. |
| Baltās kastes testēšana | Testēšanas metodika, ja praktizējošam ārstam ir zināma koda struktūra. |
Galvenās dizaina stratēģijas
Testēšana ir neapspriežama stratēģija, jo īpaši attiecībā uz drošību. Tas ļauj jums proaktīvi atklāt un risināt drošības problēmas, pirms tās var izmantot, un pārbaudīt, vai jūsu ieviestās drošības kontroles darbojas, kā paredzēts.
Testēšanas tvērumā jāiekļauj lietojumprogramma, infrastruktūra, kā arī automatizēti un ar cilvēkiem saistīti procesi.
Piezīmes
Šajos norādījumos ir nošķirta testēšana un incidentu atbilde. Lai gan testēšana ir atklāšanas mehānisms, kas ideālā gadījumā novērš problēmas pirms ražošanas, to nevajadzētu jaukt ar novēršanu vai izmeklēšanu, kas tiek veikta kā daļa no incidenta atbilde. Aspekts, kā atgūties no drošības incidentiem, ir aprakstīts Ieteikumos par drošības incidentu atbilde.
Iesaisties testu plānošanā. Darba slodzes komanda, iespējams, neizstrādā testa gadījumus. Šis uzdevums bieži tiek centralizēts uzņēmumā vai to veic ārējie drošības eksperti. Šajā projektēšanas procesā būtu jāiesaista darba slodzes komanda, lai nodrošinātu, ka drošības garantijas integrējas lietotnes funkcionalitātē.
Domā kā uzbrucējs. Izstrādājiet savus testa gadījumus, pieņemot, ka sistēmai ir uzbrukts. Tādā veidā jūs varat atklāt iespējamās ievainojamības un attiecīgi noteikt testu prioritātes.
Veikt testus strukturētā veidā un ar atkārtojamu procesu. Veidojiet testēšanas stingrību, ņemot vērā kadenci, testu veidus, braukšanas faktorus un plānotos rezultātus.
Izmantojiet darbam piemērotāko rīku. Izmantojiet rīkus, kas ir konfigurēti darbam ar darba slodzi. Ja jums nav rīka, iegādājieties rīku. Nebūvējiet to. Drošības rīki ir ļoti specializēti, un sava rīka izveide var radīt riskus. Izmantojiet centrālās SecOps komandu piedāvātās zināšanas un rīkus vai ārējos līdzekļus, ja darba slodzes komandai nav šādu zināšanu.
Iestatiet atsevišķas vides. Testus var klasificēt kā destruktīvus vai nedestruktīvus. Nedestruktīvie testi nav invazīvi. Tie norāda, ka pastāv problēma, bet nemaina funkcionalitāti, lai novērstu problēmu. Sagraujošie testi ir invazīvi un var sabojāt funkcionalitāti, dzēšot datus no datu bāzes.
Testēšana ražošanas vidē sniedz vislabāko informāciju, bet izraisa vislielākos traucējumus. Jūs mēdzat veikt tikai nesagraujošus testus ražošanas vidē. Testēšana vidē, kas nav ražošana, parasti ir mazāk traucējoša, taču tā var precīzi neatspoguļot ražošanas vides konfigurāciju drošībai svarīgos veidos.
Varat izveidot izolētu ražošanas vides klonu, izmantojot vides kopēšanas līdzekli. Ja jums ir iestatīti izvietošanas konveijeri, varat arī izvietot savus risinājumus īpašā testēšanas vidē.
Vienmēr novērtējiet testa rezultātus. Testēšana ir veltīgs darbs, ja rezultāti netiek izmantoti, lai noteiktu darbību prioritātes un veiktu uzlabojumus iepriekšējā posmā. Dokumentējiet atklātās drošības vadlīnijas, tostarp paraugpraksi. Dokumentācija, kas atspoguļo rezultātus un koriģēšanas plānus, izglīto komandu par dažādiem veidiem, kā uzbrucēji var mēģināt pārkāpt drošību. Veiciet regulāras drošības apmācības izstrādātājiem, administratoriem un testētājiem.
Izstrādājot testa plānus, padomājiet par šādiem jautājumiem:
- Cik bieži jūs sagaidāt, ka tests tiks veikts, un kā tas ietekmē jūsu vidi?
- Kādi ir dažādie testa veidi, kas jums jāveic?
Cik bieži jūs sagaidāt testu izpildi?
Regulāri pārbaudiet darba slodzi, lai pārliecinātos, ka izmaiņas nerada drošības riskus un vai nav regresiju. Darba grupai ir jābūt arī gatavai reaģēt uz organizācijas drošības validācijām, kas var tikt veiktas jebkurā laikā. Ir arī testi, kurus varat veikt, atbilde drošības incidentu. Turpmākajās iedaļās sniegti ieteikumi par testu biežumu.
Kārtējie testi
Regulārie testi tiek veikti regulārā ritmā, kā daļa no jūsu standarta darbības procedūrām un lai izpildītu atbilstības prasības. Dažādus testus var veikt dažādās kadencēs, taču galvenais ir tas, ka tie tiek veikti periodiski un pēc grafika.
Jums vajadzētu integrēt šos testus savā SDLC, jo tie katrā posmā nodrošina padziļinātu aizsardzību. Dažādojiet testa komplektu, lai pārbaudītu identitātes, datu glabāšanas un pārsūtīšanas, kā arī sakaru kanālu garantijas. Veiciet vienus un tos pašus testus dažādos dzīves cikla punktos, lai pārliecinātos, ka nav regresiju. Rutīnas testi palīdz noteikt sākotnējo etalonu. Tomēr tas ir tikai sākuma punkts. Atklājot jaunas problēmas tajos pašos dzīves cikla punktos, jūs pievienojat jaunus testa pieteikumus. Testi uzlabojas arī ar atkārtošanos.
Katrā posmā šīm pārbaudēm ir jāvalidē pievienotais vai noņemtais kods vai mainītie konfigurācijas iestatījumi, lai noteiktu šo izmaiņu ietekmi uz drošību. Jums vajadzētu uzlabot testu efektivitāti, izmantojot automatizāciju, kas līdzsvarota ar salīdzinošo novērtēšanu.
Apsveriet iespēju veikt drošības testus kā daļu no automatizēta konveijera vai plānota testa brauciena. Jo ātrāk atklāsit drošības problēmas, jo vieglāk būs atrast kodu vai konfigurācijas izmaiņas, kas tās izraisa.
Nepaļaujieties tikai uz automatizētiem testiem. Izmantojiet manuālu testēšanu, lai atklātu ievainojamības, kuras var noķert tikai cilvēku zināšanas. Manuāla pārbaude ir piemērota izpētes gadījumiem un nezināmu risku atrašanai.
Improvizēti testi
Improvizēti testi nodrošina drošības aizsardzības validāciju laikā. Drošības brīdinājumi, kas tajā laikā var ietekmēt darba slodzi, aktivizē šīs pārbaudes. Organizācijas pilnvarām var būt nepieciešams pauzes un pārbaudes domāšanas veids, lai pārbaudītu aizsardzības stratēģiju efektivitāti, ja brīdinājums saasinās līdz ārkārtas situācijai.
Improvizētu testu ieguvums ir gatavība reālam incidentam. Šie testi var būt piespiedu funkcija, lai veiktu lietotāju pieņemšanas testēšanu (UAT).
Drošības komanda var auditēt visas darba slodzes un pēc vajadzības veikt šīs pārbaudes. Kā darba slodzes īpašniekam jums ir jāatvieglo un jāsadarbojas ar drošības komandām. Pārrunājiet pietiekami daudz sagatavošanās laika ar drošības komandām, lai jūs varētu sagatavoties. Atzīstiet un informējiet savu komandu un ieinteresētās personas, ka šie traucējumi ir nepieciešami.
Citos gadījumos jums, iespējams, būs jāveic testi un jāziņo par sistēmas drošības stāvokli pret iespējamo apdraudējumu.
Kompromiss: Tā kā improvizēti testi ir graujoši notikumi, sagaidiet, ka tiks mainītas uzdevumu prioritātes, kas var aizkavēt citus plānotos darbus.
Risks: pastāv risks nezināmajam. Improvizēti testi var būt vienreizēji centieni bez izveidotiem procesiem vai rīkiem. Bet dominējošais risks ir iespējamais uzņēmējdarbības ritma pārtraukums. Jums ir jānovērtē šie riski attiecībā pret ieguvumiem.
Drošības incidentu testi
Ir testi, kas atklāj drošības incidenta cēloni tā avotā. Šīs drošības nepilnības ir jānovērš, lai nodrošinātu, ka incidents neatkārtojas.
Incidenti laika gaitā arī uzlabo testa gadījumus, atklājot esošās nepilnības. Komandai būtu jāizmanto incidentā gūtā pieredze un regulāri jāiekļauj uzlabojumi.
Kādi ir testu veidi?
Testus var iedalīt kategorijās pēc tehnoloģijas un testēšanas metodikas. Apvienojiet šīs kategorijas un pieejas šajās kategorijās, lai iegūtu pilnīgu pārklājumu.
Pievienojot vairākus testus un testu veidus, varat atklāt:
- Nepilnības drošības kontrolēs vai kompensējošās kontrolēs.
- Nepareizas konfigurācijas.
- Nepilnības novērošanas un noteikšanas metodēs.
Labs draudu modelēšanas uzdevums var norādīt uz galvenajām jomām, lai nodrošinātu testu pārklājumu un biežumu. Ieteikumus par draudu modelēšanu skatiet sadaļā Ieteikumi izstrādes dzīves cikla nodrošināšanai.
Lielāko daļu šajās sadaļās aprakstīto testu var veikt kā rutīnas testus. Tomēr dažos gadījumos atkārtojamība var radīt izmaksas un radīt traucējumus. Rūpīgi apsveriet šos kompromisus.
Testi, kas validē tehnoloģiju steku
Tālāk ir sniegti daži testu veidu un to prioritāro jomu piemēri. Šis saraksts nav pilnīgs. Pārbaudiet visu steku, ieskaitot lietojumprogrammu steku, priekšpusi, aizmuguri, API, datu bāzes un visas ārējās integrācijas.
- Datu drošība: pārbaudiet datu šifrēšanas un piekļuves kontroles efektivitāti, lai nodrošinātu, ka dati ir pienācīgi aizsargāti pret nesankcionētu piekļuvi un manipulācijām.
- Tīkls un savienojamība: pārbaudiet ugunsmūrus, lai nodrošinātu, ka tie nodrošina tikai paredzamo, atļauto un drošo datplūsmu darba slodzei.
- Lietojumprogramma: pārbaudiet pirmkodu, izmantojot lietojumprogrammu drošības testēšanas (AST) metodes, lai pārliecinātos, ka ievērojat drošu kodēšanas praksi, un lai notvertu izpildlaika kļūdas, piemēram, atmiņas bojājumus un privilēģiju problēmas.
- Identitāte: novērtējiet, vai lomu piešķiršana un nosacījuma pārbaudes darbojas, kā paredzēts.
Testēšanas metodika
Ir daudz Perspektīvas par testēšanas metodiku. Mēs iesakām testus, kas iespējo draudu meklēšanu, simulējot uzbrukumus reālajā pasaulē. Viņi var identificēt potenciālos draudu dalībniekus, to metodes un to ekspluatāciju, kas apdraud darba slodzi. Padariet uzbrukumus pēc iespējas reālistiskākus. Izmantojiet visus potenciālos draudu vektorus, kurus identificējat draudu modelēšanas laikā.
Šeit ir dažas testēšanas priekšrocības, izmantojot reālās pasaules uzbrukumus:
- Kad jūs padarāt šos uzbrukumus par daļu no ikdienas testēšanas, jūs izmantojat ārēju perspektīvu, lai pārbaudītu darba slodzi un pārliecinātos, ka aizsardzība var izturēt uzbrukumu.
- Pamatojoties uz gūtajām mācībām, komanda uzlabo savas zināšanas un prasmju līmeni. Komanda uzlabo situācijas izpratni un var paši novērtēt savu gatavību reaģēt uz incidentiem.
Daži simulētu testu piemēri ietver melnās kastes un baltās kastes testēšanu, ielaušanās testēšanu un kara spēļu vingrinājumus.
Melnās kastes un baltās kastes testēšana
Šie testa veidi piedāvā divas dažādas Perspektīvas. Melnās kastes testos sistēmas iekšējie elementi nav redzami. Baltās kastes testos testerim ir laba izpratne par lietojumprogrammu un pat ir piekļuve kodam, žurnāliem, resursu topoloģijai un konfigurācijām eksperimenta veikšanai.
Testi, kas simulē uzbrukumus, izmantojot ielaušanās testēšanu
Drošības eksperti, kas nav daļa no organizācijas IT vai lietojumprogrammu komandām, veic ielaušanās testēšanu vai pentesting testēšanu. Viņi skatās uz sistēmu tā, kā ļaunprātīgi dalībnieki aptver uzbrukuma virsmu. Viņu mērķis ir atrast drošības nepilnības, apkopojot informāciju, analizējot ievainojamības un ziņojot par rezultātiem.
Praktiķiem var būt nepieciešama piekļuve sensitīviem datiem visā organizācijā. Ievērojiet iesaistes noteikumus, lai nodrošinātu, ka piekļuve netiek ļaunprātīgi izmantota. Skatiet resursus, kas uzskaitīti sadaļā Saistītā informācija.
Testi, kas simulē uzbrukumus, izmantojot kara spēļu vingrinājumus
Šajā simulēto uzbrukumu metodoloģijā ir divas komandas:
- Sarkanā komanda ir pretinieks, kas mēģina modelēt reālās pasaules uzbrukumus. Ja tie ir veiksmīgi, jūs atrodat nepilnības savā drošības dizainā un novērtējat sprādziena rādiusu, kas ierobežo to pārkāpumus.
- Zilā komanda ir darba slodzes komanda, kas aizstāvas pret uzbrukumiem. Viņi pārbauda savu spēju atklāt, reaģēt un novērst uzbrukumus. Viņi apstiprina aizsardzību, kas ir ieviesta, lai aizsargāt darba slodzes resursus.
Ja tie tiek veikti kā parastie testi, kara spēļu vingrinājumi var nodrošināt pastāvīgu redzamību un pārliecību, ka jūsu aizsardzība darbojas, kā paredzēts. Kara spēļu vingrinājumi var potenciāli pārbaudīt visus līmeņus jūsu darba slodzes ietvaros.
Populāra izvēle, lai simulētu reālistiskus uzbrukuma scenārijus, ir Microsoft Defender for Office 365 Attack simulācijas apmācība.
Papildinformāciju skatiet sadaļā Ieskati un pārskati par uzbrukuma simulācijas apmācību.
Informāciju par sarkanās komandas un zilās komandas iestatīšanu skatiet sadaļā Microsoft Cloud Red Teaming.
Power Platform atvieglošana
Microsoft Sentinel risinājums Microsoft Power Platform ļauj klientiem atklāt dažādas aizdomīgas darbības, piemēram:
- Power Apps Izpilde no neatļautām ģeogrāfiskām vietām
- Aizdomīga datu iznīcināšana, ko veic Power Apps
- Masveidā dzēst Power Apps
- Pikšķerēšanas uzbrukumi, kas veikti, izmantojot Power Apps
- Power Automate plūst aktivitāte, aizejošiem darbiniekiem
- Microsoft Power Platform Savienotāji, kas pievienoti videi
- Datu zuduma Microsoft Power Platform novēršanas politiku atjaunināšana vai noņemšana
Papildinformāciju skatiet sadaļā Microsoft Sentinel risinājums, lai iegūtu Microsoft Power Platform pārskatu.
Produkta dokumentāciju skatiet sadaļā Medību iespējas vietnē Microsoft Sentinel.
Microsoft Defender for Cloud piedāvā ievainojamību skenēšanu dažādām tehnoloģiju jomām. Lai iegūtu papildinformāciju, skatiet sadaļu Ievainojamības pārbaudes iespējošana, izmantojot Microsoft Defender ievainojamības pārvaldību.
DevSecOps praksē tiek integrēta drošības pārbaude kā daļa no pastāvīgas un nepārtrauktas uzlabošanas domāšanas veida. Kara spēļu vingrinājumi ir izplatīta prakse, kas ir integrēta Microsoft uzņēmējdarbības ritmā. Papildinformāciju skatiet sadaļā Drošība programmā DevOps (DevSecOps).
Azure DevOps atbalsta trešo pušu rīkus, kurus var automatizēt kā daļu no nepārtrauktas integrācijas/nepārtrauktas izvietošanas (CI/CD) konveijera. Papildinformāciju skatiet sadaļā Iespējot DevSecOps ar Azure un GitHub.
Saistītā informācija
Jaunākos penetrācijas testus un drošības novērtējumu var atrast Microsoft Service Trust portālā.
Microsoft veic plašu Microsoft mākoņpakalpojumu testēšanu. Šī pārbaude ietver iespiešanās testēšanu, kuras rezultāti tiek publicēti jūsu organizācijas pakalpojumu uzticamības portālā. Jūsu organizācija var veikt savu iespiešanās pārbaudi Microsoft Power Platform un Microsoft Dynamics 365 pakalpojumos. Visām iespiešanās pārbaudēm ir jāatbilst Microsoft mākoņa iespiešanās testēšanas iesaistīšanās noteikumiem. Ir svarīgi atcerēties, ka daudzos gadījumos Microsoft mākonis izmanto koplietotu infrastruktūru, lai mitinātu jūsu un citiem klientiem piederošos līdzekļus. Jums ir jāierobežo visi iespiešanās testi ar saviem līdzekļiem un jāizvairās no neparedzētām sekām citiem jūsu apkārtējiem klientiem.
Ievērojiet iesaistīšanās noteikumus, lai nodrošinātu, ka piekļuve netiek ļaunprātīgi izmantota. Norādījumus par simulētu uzbrukumu plānošanu un izpildi skatiet:
Varat simulēt pakalpojuma atteikuma (DoS) uzbrukumus Azure. Noteikti ievērojiet politikas, kas izklāstītas sadaļā Azure DDoS aizsardzības simulācijas testēšana.
Drošības kontrolsaraksts
Skatiet pilnu ieteikumu kopumu.