Jaa

Uhka-analyysia koskevat suositukset

  • Artikkeli

Koskee tätä Power Platform hyvin suunniteltua tietoturvan tarkistuslistasuositusta:

SE:02 Sisällytä suojattu suunnittelu käyttämällä uhkamallinnusta suojautuaksesi suojauksen estäviltä toteutuksilta.

Kattava uhkat, hyökkäykset, heikkoudet ja vastatoimet tunnistava kattava analyysi on välttämätön työkuorman suunnitteluvaiheessa. Uhkien mallinnus on suunnitteluharjoitus, joka sisältää suojaustarpeiden määrittämisen, uhkien tunnistamisen ja niiden lieventämisen sekä kyseisten lievennysten tarkistaminen. Vaikka tätä tekniikkaa voidaan käyttää missä tahansa sovelluksen kehityksen tai tuotannon vaiheessa, tehokkaimmillaan se on uuden toiminnon suunnitteluvaiheissa.

Tässä oppaassa käsitellään sellaisen uhkien mallinnuksen suosituksia, joiden avulla suojauksen puutteet voidaan tunnistaa nopeasti ja suojauksen puolustautuminen suunnitella.

Määritelmät

Termi Määritelmä
Ohjelmistokehityksen elinkaari (SDLC) Monivaiheinen ohjelmallinen ohjelmistojärjestelmien kehitysprosessi.
STRIDE A-määritelty Microsoft taksonomia uhkatyyppien luokitteluun.
Uhkien mallinnus Prosessi potentiaalisten suojauksen haavoittuvuuksien tunnistamiseen sovelluksessa ja järjestelmässä, riskien lieventämiseen ja suojauksen hallintatoimien tarkistamiseen.

Tärkeimmät suunnittelustrategiat

Uhkien mallinnus on välttämätön prosessi, jonka organisaation on integroitava SDLC:hen. Uhkien mallinnus ei ole ainoastaan kehittäjä tehtävä. Sen sijaan vastuu jaetaan siinä seuraavien kesken:

  • Työkuormatiimi, joka vastaa järjestelmän teknisistä puolista.
  • Liiketoiminnan sidosryhmät, jotka ymmärtävät liiketoiminnan tulokset ja joille suojauksesta on etua.

Organisaation johdon ja teknisten tiimien välillä ei ole usein keskinäistä ymmärrystä tärkeiden työkuormien liiketoimintatarpeista. Tämä yhteisymmärryksen puute voi johtaa ei-toivottuihin tuloksiin etenkin suojaukseen tehtävissä investoinneissa.

Uhkien mallinnusharjoitusta tehtäessä onkin otettava huomioon sekä liiketoiminnan tarpeet että tekniset tarpeet. Työkuormatiimin ja liiketoiminnan sidosryhmien on oltava yhtä mieltä työkuorman suojaukseen liittyvistä tarpeita, sillä vain tämä mahdollistaa riittävät sijoitukset vastatoimiin.

Suojaustarpeet toimivat koko uhkien mallinnusprosessin ohjenuorana. Harjoitus on tehokas vain, jos työkuormatiimi ottaa suojauksen vakavasti ja on koulutettu käyttämään uhkien mallinnustyökaluja.

Harjoituksen vaikutusalueen ymmärtäminen

Tehokkaan uhkien mallinnuksen kannalta on välttämätöntä, että vaikutusalueesta on selkeä käsitys. Se auttaa keskittämään toimet ja resurssin kaikkein tärkeimmille alueille. Tämä strategia sisältää järjestelmän rajojen määrittämisen, suojattavien resurssien selvittämisen ja suojauksen hallintatoimia varten tarvittavan panostustason ymmärtämisen.

Tietojen kerääminen kustakin komponentista

Työkuorman arkkitehtuurikaavio on lähtökohta, josta tietojen kerääminen voidaan aloittaa, sillä se ilmaisee järjestelmän visuaalisesti. Kaavio tuo esiin järjestelmän tekniset dimensiot. Se näyttää esimerkiksi käyttäjätyönkulut, tietojen siirtymisen työkuorman eri osissa, tietojen arkaluonteisuustasot ja tietotyypit sekä käyttäjätietojen käyttöpolut.

Tämän tarkan analyysin avulla saadaan usein merkityksellisiä tietoja suunnitelman potentiaalisista haavoittuvuuksista. Kunkin komponentin ja sen riippuvuuksien toimintojen ymmärtäminen on tärkeää.

Potentiaalisten uhkien arvioiminen

Kukin komponentti on analysoitava tarkastellen sitä ulkoa sisäänpäin. Miten helppoa hyökkääjän on esimerkiksi päästä käyttämään arkaluonteisia tietoja? Jos hyökkäävät pääsevät ympäristöön, voivatko he siirtyä sivusuuntaisesti sekä päästä mahdollisesti käsiksi muihin resursseihin ja voivatko he jopa käsitellä näitä resursseja? Nämä kysymykset auttavat ymmärtämään, miten hyökkääjä voi hyödyntää työkuorman resursseja.

Uhkien luokitteleminen toimialan metodologian avulla

Yksi menetelmä uhkien luokitteluun on STRIDE, jota Microsoft tietoturvakehityksen elinkaari käyttää. Uhkien luokitteleminen auttaa ymmärtämään kunkin uhkan luonteen ja käyttämään soveltuvia suojauksen hallintatoimia.

Uhkien lieventäminen

Kaikki tunnistettavat uhkat on dokumentoitava. Kullekin uhkalle määritetään suojauksen hallintatoimet ja reagointi hyökkäykseen, jos kyseiset suojaustoimet pettävät. Sellaisten prosessien ja aikajanan määrittäminen, jotka minimoivat altistuminen työkuormassa tunnistetuille haavoittuvuuksille; tällä tavoin kyseiset haavoittuvuudet eivät jää käsittelemättä.

Menetelmänä kannattaa käyttää oletettua rikkomusta. Se auttaa tunnistamaan hallintatoimet, joita suunnitelmassa tarvitaan riskin lieventämiseen, jos ensisijainen suojauksen hallintatoimi pettää. Lisäksi on arvioitava, kuinka todennäköistä ensisijaisen hallintatoimen pettäminen on. Jos se pettää, kuinka laaja potentiaalinen riski organisaatiolle on? Ja kuinka tehokkaita korvaavat hallintatoimet ovat? Arvioinnin perusteella käytetään sitten kattavia toimia suojauksen hallintatoimien potentiaalisen pettämisen käsittelemiin.

Esimerkki:

Kysyttävä kysymys Päätös hallintatoimesta...
Todennetaanko yhteydet Microsoft Entra ID:n kautta ja käytetäänkö suojaustiimin hyväksymiä moderneja suojausprotokollia

- käyttäjien ja sovelluksen välillä?

- sovelluksen komponenttien ja palveluiden välillä?

- Käyttäjien ja perämiehen välillä?		 Sovelluksen komponenttien ja tietojen luvattoman käytön estäminen.
Rajoitetaanko käyttö vain tileille, joihin on kirjoitettava ja joiden on muokattava sovelluksen tietoja? Tietojen luvattoman peukaloinnin ja muuttamisen estäminen.
Kirjataanko ja syötetäänkö sovellusaktiviteetti SIEM (suojauksen tietojen ja tapahtumien hallinta) -järjestelmään Azure Monitorin tai vastaavan ratkaisun kautta? Hyökkäyksien tunnistaminen ja tutkiminen nopeasti.
Onko tärkeät tiedot suojattu suojaustiimin hyväksymällä salauksella? Levossa säilytettävien tietojen luvattoman kopioinnin estäminen.
Onko saapuva ja lähtevä verkkoliikenne eristetty suojaustiimien hyväksymille toimialueille? Tietojen luvattoman kopioinnin estäminen.
Onko sovellus suojattu ympäristön IP-palomuurien avulla ulkopuolisista tai julkisista sijainneista, kuten kahviloista, tapahtuvalta käytöltä? Käytön estäminen ei-hyväksytyistä julkisista sijainneista.
Säilytetäänkö sovelluksessa muiden sovellusten, tietokantojen tai palvelujen kirjautumistietoja tai avaimia? Selvitetään, voiko hyökkäys käyttää sovellusta toisiin järjestelmiin hyökkäämiseen.
Mahdollistavatko sovelluksen hallintatoimet lakisääteisten vaatimusten täyttämisen? Käyttäjien henkilökohtaisten tietojen suojaaminen ja vaatimustenmukaisuuteen liittyvien sakkojen välttäminen.

Uhkien mallinnustulosten seuraaminen

Uhkien mallinnustyökalun käyttäminen on erittäin suositeltavaa. Työkalut voivat automatisoida uhkien tunnistamisprosessin ja laatia kattavan raportin kaikista tunnistettavista uhkista. Tulokset on muistettava kertoa kaikille kiinnostuneille tiimeille.

Tuloksien seuranta työkulkutiimin keskeneräisten töiden osina mahdollistaa oikea-aikaisen vastuun ottamisen. Tehtävät määritetään henkilöille, jotka vastaavat tietyn uhkien mallinnuksen tunnistaman riskin lieventämisestä.

Kun uusia ominaisuuksia lisätään ratkaisuun, myös uhkamalli on päivitettävä ja integroitava koodin hallintaprosessiin. Jos suojausongelma löytyy, on varmistettava, että ongelman vakavuuteen perustuvaa arviointia varten on prosessi. Prosessi helpottaa päättämään, miten ja milloin ongelma korjataan (esimerkiksi seuraavalla julkaisujaksolla tai sitä aiemmassa julkaisussa).

Liiketoiminnan kannalta keskeiset työkuorman tarpeet on tarkistettava säännöllisesti

Tarpeiden määrittämistä varten johtoa on tavattava säännöllisesti. Nämä tarkistukset ovat mahdollisuus varmistaa odotusten vastaavuus ja toiminnallisten resurssin varaaminen hanketta varten.

Power Platform – avustaminen

Power Platform perustuu suojatun suunnittelun kulttuuriin ja menetelmiin. Sekä kulttuuria että menetelmiä vahvistetaan Microsoft jatkuvasti alan johtavilla tietoturvakehityksen elinkaari - (SDL) ja uhkamallinnuskäytännöillä .

Tehokas uhkien mallinnuksen tarkistusprosessi varmistaa, että uhat tunnistetaan suunnitteluvaiheessa, niitä lievennetään ja että varmistetaan, että niitä on lievennetty.

Uhkien mallinnus tekee jatkuvasti arvioita, joiden perusteella se kattaa kaikki palveluiden muutokset, jotka on julkaistu. STRIDE-mallin tuella on helpompaa käsitellä epävarman suunnittelun tavallisimpia ongelmia.

MicrosoftSDL vastaa OWASP Software Assurance Maturity Model (SAMM) -mallia . Molemmat rakentuvat lähtökohdalle, että turvallinen suunnittelu on olennainen osa verkkosovellusten suojauksessa.

Lisätietoja on kohdassa Kymmenen merkittävintä OWASP-riskiä: lieventäminen Power Platformissa.

Esimerkki:

Tämä esimerkki perustuu IT-ympäristöön, joka muodostettiin kohdassa Suosituksia suojauksen perustason määrittämiseen. Tämän menetelmän avulla kattava käsitys erilaisten IT-skenaarioiden uhkaympäristöstä.

Kehityksen elinkaaripersoonat. Kehityksen elinkaaren mukana on monenlaisia henkilötyyppejä, kuten kehittäjiä, testaajia, loppukäyttäjiä ja järjestelmänvalvojia. Ne kaikki voivat vaarantua ja vaarantaa ympäristön tarkoituksellisesti luotujen haavoittuvuuksien tai uhkien vuoksi.

Mahdolliset hyökkääjät. Hyökkääjät ottavat huomioon monenlaiset, helposti saatavilla olevat työkalut, joita voi käyttää koska tahansa, kun he tutkivat haavoittuvuuksia ja aloittavat hyökkäyksen.

Turvatarkastukset. Tunnista osana uhka-analyysiä, tunnista Microsoft Azure ja Power Platform tietoturvapalvelut, joiden avulla voit suojata ratkaisusi ja näiden ratkaisujen tehokkuuden.

Lokien kerääminen. Lokit resursseista Power Platform ja muista kuormitukseen sisältyvistä komponenteista, kuten Azure-resursseista ja paikallinen komponenteista, voidaan lähettää Purview'hun Application Insights Microsoft , jotta voit ymmärtää kehittämäsi ratkaisun toimintaa ja yrittää siepata alkuperäiset haavoittuvuudet.

Security Information tapahtumien hallinta (SIEM) -ratkaisu. Microsoft Sentinel voidaan lisätä jopa ratkaisun varhaisessa vaiheessa, jotta voit luoda analytiikkakyselyitä uhkien ja haavoittuvuuksien lieventämiseksi ja ennakoida tietoturvaympäristöäsi tuotannon aikana.

Suojauksen tarkistusluettelo

Katso lisätietoja suositusten kokoelmasta.

Tietoturvan tarkistuslista