Jaa

Uhka-analyysia koskevat suositukset

  • Artikkeli

Koskee tätä Power Platform Well-Architected -ratkaisun suojauksen tarkistusluetteloa koskevaa suositusta:

SE:02 Ota suojattu rakenne käyttöön käyttämällä uhkien mallinnusta suojana suojauksen ohittavia toteutuksia vastaan.

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 Microsoftin määrittämä uhkatyyppien luokittelutaksonomia.
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

Yksin uhkien luokittelumetodologia on STRIDE, jota Microsoftin turvallisuuskehityksen 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 tekoälyavustajan välillä (agentti)?		 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ä valvotaan jatkuvasti Microsoftin alan johtavien Turvallisuuskehityksen elinkaari (SDL)- ja Uhkien mallinnus -käytäntöjen avulla.

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.

Microsoftin SDL vastaa OWASP Software Assurance Maturity Model -mallia (SAMM). 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ä.

Henkilötyyppien kehityksen elinkaari. 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.

Potentiaaliset 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.

Suojauksen hallintatoimet. Uhka-analyysin osana selvitetään Microsoftin, Azuren ja Power Platformin suojauspalvelut, joita voidaan käyttää ratkaisun suojaamiseen, samoin kuin se kuinka tehokkaita kyseiset ratkaisut ovat.

Lokikokoelma. Power Platform -resurssien ja muiden työkuormaan sisältyvien komponenttien, kuten Azure-resurssit ja paikallisten komponenttien, lokit saatetaan lähettää Application Insightsiin tai Microsoft Purview'hun, jotta saadaan parempi käsitys kehitetyn ratkaisun toiminnasta. Lisäksi tällä tavoin yritetään siepata sisäisiä haavoittuvuuksia.

SIEM (suojaustietojen ja tapahtumien hallinta) -ratkaisu Microsoft Sentinel voidaan lisätä jo varhaisessa vaiheessa ratkaisuun, ja sen avulla voidaan muodostaa analyysikyselyjä uhkien ja haavoittuvuuksien lieventämistä varten. Tällä tavoin voidaan ennakoida tuotannossa käytettävää suojausympäristöä.

Suojauksen tarkistusluettelo

Katso lisätietoja suositusten kokoelmasta.

Suojauksen tarkistusluettelo