Suojauksen testaussuosituksia
Koskee tätä Power Platform hyvin suunniteltua tietoturvan tarkistuslistasuositusta:
| SE:09 | Luo kattava testausohjelma, joka yhdistää lähestymistavat tietoturvaongelmien estämiseen, uhkien ehkäisyn toteutusten validointiin ja uhkien havaitsemismekanismien testaamiseen. |
|---|
Hyvä suojaussuunnittelu perustuu tiukkoihin testeihin. Testaus on taktinen tarkistusmuoto, jolla varmistetaan, että hallintatoimet toimivat tarkoituksenmukaisesti. Testaus on myös ennakoiva tapa havaita järjestelmässä olevat haavoittuvuudet.
Tiukat testit perustuvat testausväleihin ja useita näkökulmia hyödyntävään tarkistukseen. Sisältä ulospäin suuntautuvassa testauksessa testataan ympäristöä ja infrastruktuuria, kun taas ulkoa sisällepäin suuntautumissa arvioissa järjestelmää testataan ulkoista hyökkääjää matkien.
Tässä oppaassa on työkuorman suojaustasoa koskevia testaussuosituksia. Näiden testausmenetelmien toteuttaminen parantaa työkuorman kykyä vastustaa hyökkäyksiä sekä ylläpitää resurssien luottamuksellisuutta, eheyttä ja käytettävyyttä.
Määritelmät
| Termi | Määritelmä |
|---|---|
| Sovelluksen suojaustestaus (AST) | Security Microsoft Development Lifecycle (SDL) -tekniikka, joka käyttää valkoisen laatikon ja mustan laatikon testausmenetelmiä koodin tietoturvahaavoittuvuuksien tarkistamiseen. |
| Ulkoinen testaus | Testausmenetelmä tarkistaa sovelluksen ulkoisesti näkyvän toiminnan ilman tietoa järjestelmän sisäosista. |
| Sininen ryhmä | Ryhmä, joka puolustautuu punaisen ryhmän hyökkäyksiltä sotapeliharjoituksessa. |
| Tunkeutumistestaus | Testausmenetelmä käyttää eettisiä hakkerointitekniikoita järjestelmän suojauksen puolustuksen tarkistamiseen. |
| Punainen ryhmä | Vastapuolen roolissa toimiva ryhmä, joka yrittää hakkeroida järjestelmän sotapeliharjoituksessa. |
| Turvallisuuskehityksen elinkaari (SDL) | Joukko käytäntöjä Microsoft , jotka tukevat tietoturvan varmistusta ja vaatimustenmukaisuusvaatimuksia. |
| Ohjelmistokehityksen elinkaari (SDLC) | Monivaiheinen ohjelmallinen ohjelmistojärjestelmien kehitysprosessi. |
| Sisäinen testaus | Testausmenetelmä, jossa käyttäjä tuntee koodin rakenteen. |
Tärkeimmät suunnittelustrategiat
Testaus on etenkin suojauksen osalta strategia, jota ei voi jättää tekemättä. Sen avulla voidaan ennakoivasti löytää ja käsitellä suojausongelmat, ennen kuin niitä voidaan hyödyntää, sekä tarkistaa, että toteutettu suojauksen hallinta toimii suunnitellusti.
Testauksen on katettava sovellus, infrastruktuuri sekä automatisoidut että ihmisten suorittamat prosessit.
Muistiinpano
Tässä oppaassa erotellaan testaus ja reagointi tapaukseen. Vaikka testaus on havaintomekanismi, joka parhaassa tapauksessa korjaa ongelmat ennen tuotantoa, sitä ei saa sekoittaa tapaukseen reagoinnin osana tehtävään korjaukseen tai tutkimukseen. Suojaustapahtumista palautumista käsitellään kohdassa Suojaustapaukseen reagoinnin suositukset.
Osallistuminen testauksen suunnitteluun. Työkuormatiimi ei ehkä suunnittele testitapauksia. Tämä tehtävä suoritaan usein keskitetysti yrityksessä tai sen suorittajat ovat ulkoisia tietoturva-asiantuntijoita. Työkuormatiimin on oltava mukana tässä suunnitteluprosessi, sillä niin voidaan varmistaa, että suojauksen varmistuksen integroituvat sovelluksen toimintoihin.
Hyökkääjän tavoin ajatteleminen. Testitapauksen suunnittelussa kannattaa käyttää oletusta, että järjestelmään on hyökätty. Tällä tavoin mahdolliset haavoittuvuudet saadaan esiin ja testi voidaan priorisoida vastaavasti.
Testien suorittaminen jäsennetysti ja toisinnettavana prosessina. Tiukoissa testeissä on otettava huomioon testausvälit, testien tyypit, edistävät tekijät ja toivotut tulokset.
Työhön soveltuvan työkalun käyttäminen. Käytettävien työkalujen on oltava määritetty toimimaan työkuormassa. Jos työkalua ei ole, se on ostettava. Sitä ei saa muodostaa itse. Tietoturvatyökalut ovat erittäin erikoistuneita työkaluja ja oman työkalun muodostaminen voi olla riskialtista. Kannattaa hyödyntää keskitettyjen SecOps-tiimien asiantuntemusta ja työkaluja tai ulkoisia palveluja, jos työkuormatiimillä ei ole tällaista asiantuntemusta.
Erillisten ympäristöjen määrittäminen. Testit voidaan luokitella tuhoaviksi ja ei-tuhoaviksi. Ei-tuhoavat testit eivät ole invasiivisia. Ne ilmaisevat, että ongelma on olemassa mutta eivät korjaa ongelmaa toimintoa muuttamalla. Tuhoavat testit ovat invasiivisia ja voivat vahingoittaa toimintoa poistamalla tietoja tietokannasta.
Testauksessa tuotantoympäristössä saadaan parhaiten tietoja, mutta samalla se on häiritsevin vaihtoehto. Tuotantoympäristöissä tehdään yleensä vain ei-tuhoavia testejä. Testaus ei-tuotantoympäristöissä ei ole yleensä yhtä häiritsevää, mutta silloin tuotantoympäristön määritys ei ole ehkä käytettävissä suojauksen kannalta tärkeillä tavoilla.
Tuotantoympäristön eristetty klooni voidaan luoda ympäristön kopiointiominaisuudella. Jos käyttöönottoputkia on määritettynä, ratkaisut voidaan ottaa käyttöön myös erillisessä testausympäristössä.
Testitulokset on aina arvioitava. Testauksesta ei ole mitään hyötyä, jos tulosten perusteella ei priorisoida toimintoja eikä tehdä parannuksia. Esiin tulevat suojauksen ohjeet, mukaan lukien parhaat käytännöt, on dokumentoitava. Tulokset ja korjaussuunnitelmat sieppaava dokumentaatio näyttää tiimille erilaisia tapoja, joilla hyökkääjät voivat yrittää murtaa suojausta. Kehittäjille, järjestelmänvalvojille ja testaajille kannattaa järjestää säännöllisesti suojauskoulutusta.
Testisuunnitelmia suunniteltaessa kannattaa pohtia seuraavia kysymyksiä:
- Kuinka usein testi on tarkoitus suorittaa ja miten se vaikuttaa ympäristöön?
- Mitä erilaisia testityyppejä on suoritettava?
Kuinka usein testit on tarkoitus suorittaa?
Työkuormaa kannattaa testata säännöllisesti, sillä näin varmistetaan, että muutokset eivät aiheuta tietoturvariskejä ja ettei regressiota ole tapahtunut. Tiimin on myös on oltava valmis reagoimaan organisaation suojaustarkistuksiin, joita voidaan suorittaa koska tahansa. Lisäksi on testejä, jotka on suoritettava suojaustapauksen vuoksi. Seuraavissa osissa on suosituksia testien suoritusväleistä.
Rutiinitestit
Rutiinitestejä suoritetaan säännöllisin väliajoin vakiotoimintomenettelyjen osana ja vaatimustenmukaisuusvaatimusten mukaisesti. Eri testejä voidaan suorittaa erilaisin väliajoin, mutta tärkeintä on niiden suorittaminen säännöllisesti aikataulun mukaisesti.
Nämä testit kannattaa integroida ohjelmistokehityksen elinkaareen, koska niiden avulla saadaan perusteellinen suojaus kussakin vaiheessa. Testipaketti kannattaa hajauttaa tarkistamaan käyttäjätietojen, tietojen tallennustilan ja siirtämisen sekä viestintäkanavien varmistukset. Suorittamalla samat testi elinkaaren ei vaiheissa voidaan varmistaa, ettei regressiota ole tapahtunut. Rutiinitekstin avulla voidaan muodostaa ensimmäinen vertailukohta. Se kuitenkin vasta aloituskohta. Kun uusia ongelmia havaitaan samoissa elinkaaren kohdissa, uusia testitapauksia lisätään. Myös testit parantuvat toistojen mukana.
Näillä testeillä on tarkistettava kussakin vaiheessa lisätty tai poistettu koodi tai muuttuneet määritysasetukset, sillä näin havaitaan kyseisten muutosten vaikutus suojaukseen. Testien tehokkuutta kannattaa parantaa automaation avulla, mutta myös vertaisarvioita on käytettävä.
Suojaustestien suorittamista automaattisen putken tai aikataulutetun testiajon osana kannattaa harkita. Mitä nopeammin suojausongelmat havaitaan, sitä helpompi on löytää ongelmat aiheuttava koodin tai määrityksen muutos.
Pelkät automaattiset testit eivät riitä. Manuaalisella testauksella voidaan havaita haavoittuvuudet, jotka voi huomata vain ihmisen asiantuntemuksella. Manuaalinen testaus sopii hyvin tutkiviin käyttötapauksiin ja tuntemattomien riskien löytämiseen.
Improvisoidut testit
Improvisoiduilla testeillä voi tarkistaa suojauksen puolustamista tietyllä hetkellä. Kyseisellä hetkellä työkuormaan vaikuttavat suojausilmoitukset käynnistävät nämä testit. Organisaation valtuudet saattavat edellyttää pysähtymistä ja testaamista suojausstrategioiden tehokkuuden varmistamiseksi, jos ilmoitus eskaloituu hätätilanteeksi.
Improvisoitujen testien etuna on valmistautuminen todelliseen tapaukseen. Nämä testit voivat pakottaa toiminnon tekemään käyttäjien hyväksyntätestauksen (UAT).
Suojausryhmä saattaa tarkistaa kaikki työkuormat ja suorittaa nämä testit tarvittaessa. Työkuorman omistajan on avustettava suojaustiimejä ja tehtävä yhteistyötä tiimien kanssa. Suojaustiimien kanssa on neuvoteltava riittävän pitkä varoaika, jotta aikaa jää valmistautumiseen. Näiden häiriöiden tarpeellisuus on hyväksyttävä ja tämä on ilmoitettava tiimille ja sidosryhmille.
Joissakin tapauksissa on ehkä suoritettava testit ja ilmoitettava järjestelmän suojauksen tila potentiaalisen uhkan osalta.
Kompromissi: Koska improvisoidut testit ovat häiritseviä tapahtumia, odota priorisoivan tehtäviä uudelleen, mikä voi viivästyttää muuta suunniteltua työtä.
Riski: On olemassa tuntemattoman riski. Improvisoidut testit voivat olla kertaluonteisia ilman määritettyjä prosesseja tai työkaluja. Keskeisin riski on kuitenkin liiketoiminnan mahdollinen häiriintyminen. Näitä riskejä on arvioitava suhteessa etuihin.
Tietoturvatapaustestit
Tietyt testit havaitsevat tietoturvatapauksen syyn tapauksen lähteessä. Nämä tietoturva-aukot on ratkaistava, sillä niin voidaan varmistaa, ettei tapaus toistu.
Tapaukset myös parantavat testitapauksia ajan mittaan, sillä olemassa olevat aukot havaitaan niiden avulla. Tiimin pitäisi hyödyntää tapauksessa opittua ja sisällyttää parannukset rutiininomaisesti.
Minkälaisia erityyppisiä testejä on?
Testit voidaan luokitella teknologian ja testausmenetelmien mukaan. Täydellinen kattavuus saadaan yhdistämällä kyseisiä luokkia ja luokkiin sisältyviä menettelyjä.
Useita testejä ja testityyppejä lisäämällä voidaan löytää
- suojauksen hallinnassa tai kompensoivassa hallinnassa olevia aukkoja
- virheellisiä määrityksiä
- havaittavuudessa ja havaintomenetelmissä olevia aukkoja.
Hyvä uhkien mallinnusharjoitus voi osoittaa avainalueille, mikä varmistaa testin kattavuuden ja tiheyden. Uhkien mallinnussuosituksia on kohdassa Kehityksen elinkaaren suojaussuosituksia.
Useimmat näissä osissa käsitellyt testit voidaan suorittaa rutiinitesteinä. Toistettavuus voi kuitenkin aiheuttaa kustannuksia joissakin tapauksissa ja aiheuttaa häiriöitä. Näitä kompromisseja on harkittava huolellisesti.
Teknologiapinon tarkistavat testit
Seuraavassa on esimerkkejä testityypeistä ja niiden kohdealueista. Tämä luettelo ei ole täydellinen. Koko pino, mukaan lukien sovelluspino, edusta, tausta, ohjelmointirajapinnat, tietokannat ja mahdolliset ulkoiset integroinnit on testattava.
- Tietoturva: Testaa tietojen salauksen ja käyttöoikeuksien valvonnan tehokkuus varmistaaksesi, että tiedot on suojattu asianmukaisesti luvattomalta käytöltä ja peukaloinnilta.
- Verkko ja yhteydet: Testaa palomuurisi varmistaaksesi, että ne sallivat vain odotetun, sallitun ja turvallisen liikenteen kuormitukseen.
- Sovellus: Testaa lähdekoodia sovellusten tietoturvatestaustekniikoilla (AST) varmistaaksesi, että noudatat suojattuja koodauskäytäntöjä, ja havaitaksesi suorituksenaikaiset virheet, kuten muistin vioittumisen ja käyttöoikeusongelmat.
- Käyttäjätiedot: Arvioi, toimivatko roolimääritykset ja ehdolliset tarkistukset tarkoitetulla tavalla.
Testausmenetelmät
Testausmenetelmissä on monia näkökulmia. Suosituksena on käyttää testejä, jotka ovat uhkien etsiminen käyttöön reaalimaailman hyökkäyksiä simuloimalla. Niillä voidaan tunnistaa potentiaaliset uhkatoimijat, niiden tekniikat ja heikkoudet, jotka uhkaavat työkuormaa. Hyökkäysten on oltava mahdollisimman realistisia. Kaikkia uhkien mallinnuksen aikana tunnistettuja potentiaalisia uhkavektoreita on syytä käyttää.
Reaalimaailman hyökkäysten testaamisen etuja:
- Kun nämä hyökkäykset ovat rutiinitestauksen osa, ulkopuolelta sisäänpäin katsovaa näkökulmaa voidaan käyttää työkuorman tarkistamiseen ja sen varmistamiseen, että puolustus kestää hyökkäyksen.
- Tiimi päivittää tietämystään ja taitotasoaan opitun perusteella. Tiimin tilannetietoisuus paranee, ja tiimi voi arvioida itse valmiutensa reagoida tapauksiin.
Ulkoinen ja sisäinen testaus, tunkeutumistestaus sekä sotapeliharjoitukset ovat esimerkkejä simuloiduista testeistä.
Ulkoinen ja sisäinen testaus
Näillä testityypeillä saadaan kaksi erilaista näkökulmaa. Ulkoisissa testeissä järjestelmä sisäosat eivät ole näkyvissä. Sisäisissä testeissä testaaja tuntee sovelluksen hyvin, minkä lisäksi koodi, lokit, resurssitopologia ja määritykset ovat testaajan käytettävissä testin aikana.
Tunkeutumistestien kautta hyökkäyksiä simuloivat testit
Organisaaton IT- tai sovellustiimien ulkopuoliset tietoturva-asiantuntijat suorittavat tunkeutumistestauksen eli penetraatiotestin. He tarkastelevat järjestelmää samalla tavoin kuin pahantahotoiset toimijat arvioivat hyökkäyspintaa. Heidän tavoitteenaan on löytää tietoturva-aukkoja keräämällä tietoja, analysoimalla heikkouksia ja ilmoittamalla tulokset.
Suorittajat tarvitsevat ehkä koko organisaation arkaluonteisten tietojen käyttöoikeuden. Toimintasääntöjen noudattaminen varmistaa, ettei tätä käyttöoikeutta käytetä väärin. Katso aiheeseen liittyviä tietoja -kohdassaluetellut resurssit.
Hyökkäyksiä sotapeliharjoituksissa simuloivat testit
Tässä simuloiduissa hyökkäysmenetelmässä on kaksi ryhmää:
- Punainen ryhmä on vastustaja, joka yrittää mallintaa reaalimaailman hyökkäyksiä. Jos ryhmä onnistuu, suojauksen suunnittelussa on aukkoja ja tietoturvarikkomusten vaikutusalueen eristäminen voidaan arvioida.
- Sininen ryhmä on hyökkäyksiltä puolustautuva työkuormatiimi. He testaavat kykyjään havaita hyökkäykset, reagoida hyökkäysiin ja korjata tilanne. He tarkistavat työkuormaresurssien suojaamista varten toteutetut puolustautumistoimet.
Jos sotapeliharjoitukset suoritetaan rutiinitesteinä, niiden avulla voidaan saada jatkuvasti näkyvyys puolustustoimiin ja varmuus siitä, että ne toimivat suunnitellusti. Sotapeliharjoituksia voidaan käyttää potentiaalisesti työkuormien eri tasojen testaamiseen.
Suosittu valinta realististen hyökkäysskenaarioiden simulointiin on Microsoft Defender for Attack - Office 365 simulaatiokoulutus.
Lisätietoja on kohdassa Hyökkäyssimulaatiokoulutusta koskevia merkityksellisiä tietoja ja raportteja.
Lisätietoja punaisen ja sinisen joukkueen asetuksista on kohdassa Microsoft Cloud Red Teaming.
Power Platform – avustaminen
Microsoft Sentinel-ratkaisun Microsoft Power Platform avulla asiakkaat voivat havaita erilaisia epäilyttäviä toimintoja, kuten:
- Power Appsin toteuttaminen valtuuttamattomilla maantieteellisillä alueilla
- Power Appsin tekemä epäilyttävien tietojen tuhoaminen
- Tietojen joukkopoisto Power Appsissa
- Tietojenkalasteluhyökkäykset Power Appsin kautta
- Power Automate -työnkulkuaktiviteetti poistamalla käyttäjiä
- Ympäristöön lisätyt Microsoft Power Platform -yhdistimet
- Microsoft Power Platformin tietojen menetyksen estämiskäytäntöjen päivittäminen tai poistaminen
Lisätietoja on yleiskatsauksessa Microsoft Microsoft Power Platform kohdassaSentinel-ratkaisu.
Katso tuotedokumentaatio kohdasta Metsästysominaisuudet Sentinelissä Microsoft .
Microsoft Defender for Cloud tarjoaa haavoittuvuuksien skannauksen eri teknologia-alueille. Lisätietoja on kohdassa Haavoittuvuuksien tarkistuksen ottaminen käyttöön Defenderin haavoittuvuuksien hallinnan Microsoft avulla.
DevSecOps-käytäntö integroi suojaustestauksen jatkuvan parantamisen osaksi. Sotapeliharjoitukset ovat yleinen käytäntö, joka on integroitu liiketoiminnan Microsoft rytmiin. Lisätietoja on kohdassa Suojaus DevOpsissa (DevSecOps).
Azure DevOps tukee kolmannen osapuolen työkaluja, jotka voidaan automatisoida CI/CD (jatkuva integrointi ja jatkuva käyttöönotto) -putkien osana. Lisätietoja on kohdassa DevSecOpsin ottaminen käyttöön Azuren ja GitHubin avulla.
Liittyvät tiedot
Uusimmat tunkeutumistestit ja tietoturva-arvioinnit löytyvät Service Trust -portaalista Microsoft .
Microsoft suorittaa pilvipalveluiden laajan testauksen Microsoft . Testaus sisältää tunkeutumistestauksen, jonka tulokset julkaistaan organisaation Service Trust Portalissa. Organisaatio voi suorittaa oman tunkeutumistestin Microsoft Power Platform- ja Microsoft Dynamics 365 -palveluissa. Kaikkien tunkeutumistestien on noudatettava Microsoft Cloud Penetration Testing Rules of Engagement -sääntöjä. On tärkeää muistaa, että monissa tapauksissa pilvi käyttää jaettua Microsoft infrastruktuuria muiden asiakkaiden omaisuuden ja omaisuuden isännöintiin. Kaikki tunkeutumistestit on rajoitettava omiin resursseihin ja on vältettävä tahattomien vaikutusten aiheuttamista muille asiakkaille.
Toimintasääntöjen noudattaminen varmistaa, ettei tätä käyttöoikeutta käytetä väärin. Ohjeita simuloitujen hyökkäysten suunnitteluun ja toteuttamiseen:
Palvelunestohyökkäyksiä (DoS-hyökkäyksiä) voidaan simuloida Azuressa. Kohdassa Azuren DDoS-suojauksen simulointitestaus ilmoitettuja käytäntöjä on noudatettava.
Suojauksen tarkistusluettelo
Katso lisätietoja suositusten kokoelmasta.