Märkus.
Juurdepääs sellele lehele nõuab autoriseerimist. Võite proovida sisse logida või kausta vahetada.
Juurdepääs sellele lehele nõuab autoriseerimist. Võite proovida kausta vahetada.
Kehtib selle Power Platform hästi koostatud turbe kontrollnimekirja soovituse kohta.
| SE:09 | Looge terviklik testimisrežiim, mis ühendab lähenemisviise turvaprobleemide ennetamiseks, ohtude ennetamise rakenduste valideerimiseks ja ohtude tuvastamise mehhanismide testimiseks. |
|---|
Range testimine on hea turvadisaini alus. Testimine on taktikaline valideerimise vorm, et veenduda, et kontrollid töötavad ettenähtud viisil. Testimine on ka ennetav viis süsteemi haavatavuste tuvastamiseks.
Kehtestage testimise rangus rütmi ja mitmest vaatenurgast kontrollimise kaudu. Peaksite lisama seestpoolt väljapoole vaatenurki, mis testivad platvormi ja infrastruktuuri, ning väljastpoolt hinnanguid, mis testivad süsteemi nagu väline ründaja.
See juhend annab soovitusi oma töökoormuse turbeseisundi testimiseks. Rakendage neid testimismeetodeid, et parandada oma töökoormuse vastupanuvõimet rünnakutele ning säilitada ressursside konfidentsiaalsus, terviklikkus ja kättesaadavus.
Mõisted
| Mõiste | Määratlus |
|---|---|
| Rakenduse turvalisuse testimine (AST) | Microsofti turbearenduse elutsükli (SDL) meetod, mis kasutab koodi turvaaukude kontrollimiseks valge kasti ja musta kasti testimismeetodeid. |
| Musta kasti testimine | Testimismetoodika, mis kinnitab väliselt nähtavat rakenduse käitumist ilma süsteemi sisemusi tundmata. |
| Sinine meeskond | Meeskond, kes kaitseb punase meeskonna rünnakute eest sõjamängu õppusel. |
| Läbitungimise testimine | Testimismetoodika, mis kasutab süsteemi turvakaitse kinnitamiseks eetilisi häkkimistehnikaid. |
| Punane meeskond | Meeskond, kes mängib vastase rolli ja üritab sõjamängu õppusel süsteemi häkkida. |
| Turbe arendamise elutsükkel (SDL) | Microsofti pakutavad tavad, mis toetavad turbe tagamise ja vastavuse nõudeid. |
| Tarkvaraarenduse elutsükkel (SDLC) | Mitmeastmeline süstemaatiline protsess tarkvarasüsteemide arendamiseks. |
| Valge kasti testimine | Testimismetoodika, mille puhul koodi struktuur on praktikule teada. |
Peamised disainistrateegiad
Testimine on vaieldamatu strateegia, eriti turvalisuse huvides. See võimaldab teil ennetavalt avastada ja lahendada turbeprobleeme enne, kui neid saab ära kasutada, ning kontrollida, kas teie rakendatud turbekontrollid toimivad ettenähtud viisil.
Testimise ulatus peab hõlmama rakendust, infrastruktuuri ning automatiseeritud ja inimprotsesse.
Märkus.
Selles juhendis eristatakse testimist ja intsidentidele reageerimist. Kuigi testimine on tuvastamismehhanism, mis ideaalis lahendab probleemid enne tootmist, ei tohiks seda segi ajada kahjutustamise või uurimisega, mida tehakse intsidentidele reageerimise osana. Turvaintsidentidest taastumise aspekti kirjeldatakse jaotises Soovitused turvaintsidentidele reageerimiseks.
Olge kaasatud testide planeerimisse. Töökoormuse meeskond ei pruugi testjuhtumeid kavandada. See ülesanne on sageli ettevõttes tsentraliseeritud või seda täidavad välised turbeeksperdid. Töökoormuse meeskond peaks olema kaasatud sellesse projekteerimisprotsessi, et tagada turvatagatiste integreerumine rakenduse funktsionaalsusega.
Mõelge nagu ründaja. Kujundage oma testjuhtumid eeldusel, et süsteemi on rünnatud. Nii saate avastada võimalikud haavatavused ja seada testid vastavalt tähtsuse järjekorda.
Käivitage testid struktureeritud viisil ja korratava protsessiga. Ehitage oma testimise rangus rütmi, testitüüpide, liikumapanevate tegurite ja kavandatud tulemuste ümber.
Kasutage töö jaoks õiget tööriista. Kasutage tööriistu, mis on konfigureeritud töökoormusega töötama. Kui teil pole tööriista, ostke tööriist. Ärge ehitage seda. Turbetööriistad on väga spetsialiseerunud ja oma tööriista loomine võib kaasa tuua riske. Kasutage ära kesksete SecOpsi meeskondade pakutavaid teadmisi ja tööriistu või väliste vahenditega, kui töökoormuse meeskonnal neid teadmisi pole.
Seadistage eraldi keskkonnad. Katseid võib liigitada hävitavateks või mittepurustavateks. Mittepurustavad testid ei ole invasiivsed. Need näitavad, et probleem on olemas, kuid ei muuda funktsiooni probleemi lahendamiseks. Hävitavad testid on invasiivsed ja võivad andmebaasist andmete kustutamisel kahjustada funktsionaalsust.
Testimine tootmiskeskkondades annab teile parimat teavet, kuid põhjustab kõige rohkem häireid. Tootmiskeskkondades kipute tegema ainult mittepurustavaid katseid. Testimine mittetootmiskeskkondades on tavaliselt vähem häiriv, kuid ei pruugi tootmiskeskkonna konfiguratsiooni täpselt kajastada turvalisuse seisukohast olulisel viisil.
Saate luua oma tootmiskeskkonna isoleeritud klooni, kasutades keskkonna kopeerimise funktsiooni . Kui teil on juurutuskonveierid seadistatud, saate oma lahendused juurutada ka spetsiaalsesse testimiskeskkonda.
Hinnake alati testi tulemusi. Testimine on raisatud pingutus, kui tulemusi ei kasutata tegevuste tähtsuse järjekorda seadmiseks ja paranduste tegemiseks. Dokumenteerige avastatud turbejuhised, sh head tavad. Tulemusi ja parandusplaane jäädvustav dokumentatsioon õpetab meeskonda erinevate viiside kohta, kuidas ründajad võivad üritada turvalisust rikkuda. Viige läbi regulaarseid turvakoolitusi arendajatele, administraatoritele ja testijatele.
Testiplaanide koostamisel mõelge järgmistele küsimustele:
- Kui sageli eeldate, et test viiakse läbi ja kuidas see teie keskkonda mõjutab?
- Millised on erinevad testitüübid, mida peaksite läbi viima?
Kui sageli eeldate, et testid toimuvad?
Testige töökoormust regulaarselt, et veenduda, et muudatused ei too kaasa turberiske ja et ei esine regressiooni. Meeskond peab olema valmis reageerima ka organisatsiooni turbe valideerimistele, mis võidakse igal ajal läbi viia. Samuti on olemas testid, mida saate käivitada vastuseks turvaintsidendile. Järgmistes punktides antakse soovitusi katsete sageduse kohta.
Rutiinsed testid
Rutiinseid teste viiakse läbi regulaarse sagedusega, mis on osa teie standardsetest tööprotseduuridest ja vastavusnõuete täitmiseks. Erinevaid teste võidakse läbi viia erineva sagedusega, kuid peamine on see, et neid viiakse läbi perioodiliselt ja ajakava järgi.
Peaksite need testid integreerima oma SDLC-sse, kuna need pakuvad igas etapis sügavat kaitset. Mitmekesistage testikomplekti, et kontrollida identiteedi, andmete salvestamise ja edastamise ning sidekanalite tagatisi. Viige läbi samad testid elutsükli erinevates punktides, et tagada regressioonide puudumine. Rutiinsed testid aitavad luua esialgse võrdlusaluse. See on aga alles alguspunkt. Kui avastate elutsükli samades punktides uusi probleeme, lisate uusi testjuhtumeid. Testid paranevad ka kordamisega.
Igas etapis peaksid need testid kinnitama lisatud või eemaldatud koodi või muudetud konfiguratsioonisätteid, et tuvastada nende muudatuste turbemõju. Testide tõhusust tuleks parandada automatiseerimise abil, tasakaalustades vastastikuste eksperdihinnangutega.
Kaaluge turbetestide käivitamist automatiseeritud konveieri või ajastatud testimise osana. Mida varem turvaprobleemid avastate, seda lihtsam on neid põhjustavat koodi või konfiguratsioonimuudatust leida.
Ärge lootke ainult automatiseeritud testidele. Kasutage käsitsi testimist, et tuvastada haavatavusi, mida suudavad tabada ainult inimteadmised. Käsitsi testimine on hea uurimuslikeks kasutusjuhtudeks ja tundmatute riskide leidmiseks.
Improviseeritud testid
Improviseeritud testid pakuvad turvakaitse ajahetke valideerimist. Turbeteatised, mis võivad sel ajal töökoormust mõjutada, käivitavad need testid. Organisatsioonilised mandaadid võivad nõuda pausi ja testimise mõtteviisi, et kontrollida kaitsestrateegiate tõhusust, kui hoiatus eskaleerub hädaolukorraks.
Improviseeritud testide eeliseks on valmisolek reaalseks juhtumiks. Need testid võivad olla sundfunktsioon kasutaja vastuvõtutesti (UAT) tegemiseks.
Turbemeeskond võib auditeerida kõiki töökoormusi ja käivitada need testid vastavalt vajadusele. Töökoormuse omanikuna peate turbemeeskondi hõlbustama ja nendega koostööd tegema. Leppige turvameeskondadega kokku piisavalt tarneaega, et saaksite valmistuda. Tunnistage ja teavitage oma meeskonda ja sidusrühmi, et need häired on vajalikud.
Muudel juhtudel võidakse teilt nõuda testide käivitamist ja süsteemi turbeseisundist teatamist võimaliku ohu vastu.
Kompromiss: Kuna improviseeritud testid on häirivad sündmused, oodake ülesannete tähtsuse muutmist, mis võib muud kavandatud tööd edasi lükata.
Risk: On olemas tundmatu oht. Improviseeritud testid võivad olla ühekordsed jõupingutused ilma väljakujunenud protsesside või tööriistadeta. Kuid valdav risk on ärirütmi võimalik katkemine. Peate neid riske hindama kasulikkuse suhtes.
Turvaintsidentide testid
On olemas testid, mis tuvastavad turvaintsidendi põhjuse selle allikas. Need turvalüngad tuleb lahendada, et intsident ei korduks.
Juhtumid parandavad aja jooksul ka testjuhtumeid, paljastades olemasolevad lüngad. Meeskond peaks rakendama intsidendist saadud õppetunde ja regulaarselt lisama parandusi.
Millised on testide eri tüübid?
Teste saab liigitada tehnoloogia ja testimismetoodikate järgi . Täieliku katvuse saamiseks kombineerige need kategooriad ja lähenemisviisid nende kategooriate piires.
Lisades mitu testi ja testitüüpi, saate avastada:
- Lüngad turvakontrollides või kompenseerivates kontrollides.
- Valed konfiguratsioonid.
- Lüngad jälgitavuses ja tuvastamismeetodites.
Hea ohtude modelleerimise harjutus võib osutada võtmevaldkondadele, et tagada testide katvus ja sagedus. Ohu modelleerimise soovitused leiate teemast Soovitused arenduse elutsükli turvalisuse tagamiseks.
Enamikku nendes jaotistes kirjeldatud teste saab läbi viia rutiinsete testidena. Korratavus võib aga mõnel juhul kaasa tuua kulusid ja põhjustada häireid. Kaaluge neid kompromisse hoolikalt.
Testid, mis kinnitavad tehnoloogiapinu
Siin on mõned näited testide tüüpidest ja nende fookusvaldkondadest. See nimekiri ei ole ammendav. Testige kogu pinu, sealhulgas rakenduste pinu, esiosa, tagaosa, API-sid, andmebaase ja mis tahes väliseid integratsioone.
- Andmete turvalisus: testige andmete krüptimise ja juurdepääsukontrolli tõhusust, et tagada andmete nõuetekohane kaitse volitamata juurdepääsu ja võltsimise eest.
- Võrk ja ühenduvus: testige oma tulemüüre, et veenduda, et need lubavad töökoormusele ainult oodatud, lubatud ja turvalist liiklust.
- Rakendus: Testige lähtekoodi rakenduse turvalisuse testimise (AST) tehnikate abil, et veenduda, et järgite turvalisi kodeerimistavasid ja tuvastate käitusaja tõrkeid, nagu mälu riknemine ja privileegide probleemid.
- Identiteet: hinnake, kas rollimäärangud ja tingimuskontrollid töötavad ettenähtud viisil.
Katse metoodika
Testimismetoodikatel on palju vaatenurki. Soovitame teste, mis võimaldavad ohtude jahtimist, simuleerides reaalseid rünnakuid. Nad suudavad tuvastada potentsiaalsed ohus osalejad, nende tehnikad ja ärakasutamised, mis ohustavad töökoormust. Muutke rünnakud võimalikult realistlikuks. Kasutage kõiki võimalikke ohuvektoreid, mille ohu modelleerimise käigus tuvastate.
Siin on mõned reaalsete rünnakute kaudu testimise eelised:
- Kui teete need rünnakud rutiinse testimise osaks, kasutate töökoormuse kontrollimiseks väljastpoolt perspektiivi ja veendumaks, et kaitse suudab rünnakule vastu pidada.
- Saadud õppetundide põhjal täiendab meeskond oma teadmisi ja oskuste taset. Meeskond parandab olukorrateadlikkust ja oskab ise hinnata oma valmisolekut intsidentidele reageerida.
Mõned näited simuleeritud testidest hõlmavad musta kasti ja valge kasti testimist, läbitungimistesti ja sõjamängude õppusi.
Musta kasti ja valge kasti testimine
Need testitüübid pakuvad kahte erinevat vaatenurka. Musta kasti testides pole süsteemi sisemised osad nähtavad. Valge kasti testides mõistab testija rakendust hästi ja tal on isegi juurdepääs koodile, logidele, ressursitopoloogiale ja konfiguratsioonidele katse läbiviimiseks.
Testid, mis simuleerivad rünnakuid läbistustestimise abil
Turbeeksperdid, kes ei kuulu organisatsiooni IT- või rakendusmeeskondadesse, viivad läbi läbitungimistestimist ehk pentestimist. Nad vaatavad süsteemi nii, nagu pahatahtlikud osalejad ründepinnale ulatust võtavad. Nende eesmärk on leida turvalüngad, kogudes teavet, analüüsides haavatavusi ja teatades tulemustest.
Praktikud võivad vajada juurdepääsu tundlikele andmetele kogu organisatsioonis. Järgige kaasamisreegleid, et juurdepääsu ei kuritarvitataks. Vaadake jaotises Seotud teave loetletud ressursse.
Testid, mis simuleerivad rünnakuid sõjamängu harjutuste kaudu
Selles simuleeritud rünnakute metoodikas on kaks meeskonda:
- Punane meeskond on vastane, kes üritab modelleerida reaalseid rünnakuid. Kui need on edukad, leiate oma turbekujunduses lüngad ja hindate nende rikkumiste plahvatusraadiust.
- Sinine meeskond on töökoormuse meeskond, kes kaitseb rünnakute eest. Nad testivad oma võimet rünnakuid tuvastada, neile reageerida ja neid parandada. Nad kinnitavad töökoormuse ressursside kaitsmiseks rakendatud kaitsemeetmeid.
Kui sõjamängude õppused viiakse läbi rutiinsete katsetena, võivad need pakkuda pidevat nähtavust ja kindlust, et teie kaitse töötab nii, nagu ette nähtud. Sõjamängude harjutused võivad potentsiaalselt testida teie töökoormuse eri tasemeid.
Populaarne valik realistlike ründestsenaariumide simuleerimiseks on Microsoft Defender for Office 365 Attack simulatsioonikoolitus.
Lisateavet leiate teemast Rünnakusimulatsiooni koolituse ülevaated ja aruanded.
Lisateavet punase meeskonna ja sinise meeskonna häälestamise kohta leiate teemast Microsoft Cloud Red Teaming.
Power Platform Hõlbustamine
Microsoft Sentineli lahendus Microsoft Power Platform võimaldab klientidel tuvastada mitmesuguseid kahtlasi tegevusi, näiteks:
- Power Apps Täitmine volitamata geograafilistest piirkondadest
- Kahtlaste andmete hävitamine Power Apps
- Massiline kustutamine Power Apps
- Andmepüügirünnakud Power Apps
- Power Automate vood tegevus lahkuvate töötajate poolt
- Microsoft Power Platform Keskkonda lisatud konnektorid
- Andmepoliitikate värskendamine või eemaldamine Microsoft Power Platform
Lisateavet leiate ülevaate saamiseks Microsoft Power Platform teemastMicrosoft Sentineli lahendus.
Tootedokumentatsiooni leiate teemast Jahivõimalused Microsoft Sentinelis.
Microsoft Defender for Cloud pakub haavatavuste skannimist erinevate tehnoloogiavaldkondade jaoks. Lisateavet leiate teemast Nõrkuste kontrolli lubamine Microsoft Defenderi nõrkushalduse abil.
DevSecOpsi praktika integreerib turvatestimise pideva ja pideva täiustamise mõtteviisi osana. Sõjamängude õppused on tavaline tava, mis on integreeritud Microsofti ärirütmi. Lisateavet leiate teemast DevOpsi turvalisus (DevSecOps).
Azure DevOps toetab kolmanda osapoole tööriistu, mida saab automatiseerida pideva integratsiooni/pideva juurutamise (CI/CD) torujuhtmete osana. Lisateavet leiate teemast DevSecOpsi lubamine Azure’i ja GitHubiga.
Seotud teave
Uusimad läbitungitavuse testid ja turvalisuse hinnangud on leitavad Microsofti teenuse usaldusportaalist.
Microsoft viib läbi Microsofti pilveteenuste ulatuslikku testimist. See testimine hõlmab läbistustestimist, mille tulemused avaldatakse teie organisatsiooni teenuse usaldusväärsuse portaalis. Teie organisatsioon võib teha oma läbitungimistesti Microsoft Power Platform ja 365 Microsoft Dynamics teenuseid. Kõik läbistustestid peavad järgima Microsofti pilvteenuste läbitungimistestimise reegleid. Oluline on meeles pidada, et paljudel juhtudel kasutab Microsofti pilv teie varade ja teistele klientidele kuuluvate varade majutamiseks jagatud infrastruktuuri. Peate piirama kõiki läbitungimisteste oma varadega ja vältima soovimatuid tagajärgi teistele teid ümbritsevatele klientidele.
Järgige kaasamisreegleid, et veenduda, et juurdepääsu ei kuritarvitata. Lisateave simuleeritud rünnakute kavandamise ja teostamise kohta:
Azure’is saate simuleerida teenusetõkestusrünnakuid (DoS). Järgige kindlasti Azure’i DDoS-kaitse simulatsioonitestimisel sätestatudpoliitikaid.
Turvalisuse kontroll-loend
Vaadake kõiki soovitusi.