Hyödyllinen uhkamalli selittää, mitä suojaat, kuka tai mikä voi vaikuttaa siihen, missä luottamus muuttuu ja miten vähennät ja testaat tärkeimmät riskit. Aloita todellisesta projektista yleisen työkalu luettelon sijaan.
Määrittele riittävän pieni laajuus, jota voi järkeillä
Aloita yhdestä toimivasta palvelusta: asiakasportaalista, julkaisusivustosta tai sisäisestä sovelluksesta. Kirjoita muistiin komponentit, joita käytät, ja ulkoiset järjestelmät, joihin tukeudut. Uhka mallin tulisi tehdä oletukset näkyviksi, ei antaa ymmärtää, että kaikki mahdolliset hyökkäykset on ratkaistu. Pidä ensimmäinen versio riittävän pienenä, jotta sovelluksen käyttöönottavat henkilöt voivat selittää sen ilman erillistä konsulttia, joka tulkitsee kaaviota.
Luettele arvokkaat tulokset ja omaisuuserät. Näitä voivat olla asiakastiedot, ylläpitokäyttöoikeudet, maksutila, julkaistu sisältö ja kyky palauttaa palvelu. Käytettävyys voi olla omaisuuserä, vaikka tiedot olisivat julkisia. Päätä, mitkä viat olisivat vain hankalia ja mitkä vahingoittaisivat ihmisiä tai organisaatiota. Tämä ero auttaa priorisoimaan valvontatoimia sen sijaan, että jokaista varoitusta kohdeltaisiin samalla tavalla.
Piirrä kohdat, joissa luottamus muuttuu
OWASP:n uhkamallinnusohje käyttää tietovirtoja ja luottamusrajoja suunnittelun ymmärrettävyyden parantamiseksi. Piirrä pientä isännöityä sovellusta varten selain, verkkoprosessi, tietokanta, ylläpitäjä, varmuuskopiointikohde ja ulkoiset integraatiot. Merkitse niiden välillä liikkuvat tiedot. Pyyntö, joka ylittää rajan epäluotetusta asiakkaasta etuoikeutettuun palvelintoimintoon, ansaitsee nimenomaisen validoinnin ja valtuutuksen.
Älä oleta, että saman koneen sisällä oleminen tekee kaikista komponenteista yhtä luotettavia. Julkisella latausprosessilla ei pitäisi olla samoja käyttöoikeuksia kuin tietokannan ylläpidolla. Varmuuskopiointityö voi tarvita lukuoikeuden ilman kykyä muuttaa tuotannossa olevia sovellustietueita. Näiden roolien erottaminen helpottaa kompromettoituneen komponentin vaikutusten rajaamista ja tarvittavien käyttöoikeuksien tarkistamista.
Valitse konkreettiset vikatilanteet
Käytä kourallista uskottavia tapahtumia suunnittelun haastamiseen. Hyökkääjä varastaa ylläpitäjän salasanan; käyttäjä pyytää toisen käyttäjän tietuetta; lataus täyttää levyn; käyttöönotto paljastaa asetustiedoston; palautuskopiota ei voi palauttaa. Kuvaile lähtötilanne, vaikutuksen kohteena oleva komponentti ja seuraus. Tietty skenaario on helpompi testata kuin laaja ohje turvallisuuden parantamiseksi.
Sisällytä mukaan virheet ja laillisen työnkulun väärinkäyttö sekä ulkoinen tunkeutuminen. Uudelleenyritys voi luoda kaksi arvokasta toimintoa, tai kaksi pyyntöä voi kilpailla saman objektin muuttamisesta. OWASP:n liiketoimintalogiikkaohje korostaa näitä prosessioletuksia. Tarkista, kuka saa siirtää työnkulun seuraavaan tilaan ja muuttaako pyynnön toistaminen tai uudelleenjärjestäminen tulosta odottamatta.
| Skenaario | Tutkittava valvontatoimi | Kerättävä todiste |
|---|---|---|
| Varastettu ylläpitotunnus | Rajoitettu pääsy ja toinen tekijä, jos tuettu | Luvaton kirjautuminen ei voi onnistua |
| Toisen käyttäjän objekti pyydetty | Palvelinpuolen objektivaltuutus | Eristetty testi palauttaa hylätyn tuloksen |
| Levy täyttyy latauksista | Koko-, kiintiö- ja säilytysvalvonnat | Raja pannaan täytäntöön ennen palvelun vikaantumista |
| Työnkulun kaksoispyyntö | Idempotenssi ja tapahtumarajat | Toistettu pyyntö luo yhden tuloksen |
Priorisoi vaikutuksen ja uskottavan polun mukaan
Kirjaa jokaisesta skenaariosta sen mahdollinen vaikutus ja ehdot, jotka tarvitaan sen toteutumiseen. Vältä teeskentelemästä, että arvattu numeerinen pistemäärä olisi tarkka todennäköisyys. Voit silti erottaa internetille altistetun heikon salasanan erittäin ehdollisesta paikallisesta tapahtumasta. Anna tärkeille riskeille omistaja ja käytännöllinen seuraava askel, jotta malli tuottaa työtä, jonka joku voi todella tehdä.
Harkitse tietojen elinkaarta sekä sovelluksen kompromettoitumista. Diagnostiikkavienti voi paljastaa tarpeettomia tietoja muuten normaalin toiminnan aikana. Säilytetty tilikenttä voi aiheuttaa altistumisen kauan sen käyttötarkoituksen päättymisen jälkeen. Tietosuojatarkastelu voi siksi poistaa tietoja tai lyhentää säilytysaikaa, kun taas tietoturvatarkastelu rajoittaa pääsyä jäljellä oleviin tietoihin. Molemmat muutokset kuuluvat malliin, kun ne suojaavat projektia.
Testaa valvontatoimet valtuutetussa ympäristössä
Luo staging-ympäristö, jossa on edustavat käyttöoikeudet ja keksityt tietueet. Testaa evätty pääsy, pyyntörajat, työnkulun uudelleenyritykset ja palautus. Älä käytä oikeita asiakastietoja, kun synteettiset tiedot voivat osoittaa toiminnan. Tavoitteena on varmistaa valvontatoimi, ei tuottaa vaikuttavaa hyökkäysliikennettä. Pysy järjestelmissä, jotka omistat tai joiden arviointiin sinulla on nimenomainen valtuutus.
Kirjaa, mikä meni läpi, mikä epäonnistui ja mikä on yhä tuntematonta. Skannerin tulos voi tuoda todisteita, mutta se ei korvaa sovelluksen liiketoimintasääntöjen testausta. Samoin verkkosuojausvaihtoehto ei vahvista objektivaltuutusta tai salaisen tiedoston käsittelyä. Liitä hyödylliset tulokset skenaarioon, jotta tulevat ylläpitäjät ymmärtävät, miksi tietty valvontatoimi on olemassa.
Pidä malli kytkettynä muutokseen
Tarkista asiaankuuluvat osat, kun lisäät integraation, avaat uuden päätepisteen, muutat käyttöoikeutta tai siirrät tietoja toiseen kohteeseen. Koko arkkitehtuuria ei tarvitse piirtää uudelleen pientä tekstimuokkausta varten. Laukaisijana on muuttunut oletus käyttöoikeudesta, tiedoista tai järjestelmän toiminnasta. Pidä malli käyttöönotto- ja palautusdokumentaation vieressä sen sijaan, että jättäisit sen kertaluonteiseksi työpajan tuotokseksi.
SwissOctet tarjoaa luettelon infrastruktuurivaihtoehdoista, ei valmista sovelluksen uhkamallia. Valitse kokoonpano ja vaihtoehdot, jotka tukevat valvontatoimiasi, ja varmista sitten rakentamasi käyttöönotto. Pieni, ylläpidetty malli ja testatut toimenpiteet ovat hyödyllisempiä kuin suuri kokoelma tietoturvatuotteita ilman selkeää selitystä siitä, mitä riskejä ne käsittelevät.
Käytännön tarkistuslistasi.
- Luettele omaisuuserät ja vian seuraukset.
- Piirrä tietovirrat ja luottamusrajat.
- Valitse tietyt tunkeutumis-, virhe- ja työnkulku skenaariot.
- Anna valvontatoimet ja omistajat tärkeille riskeille.
- Testaa synteettisillä tiedoilla valtuutetussa ympäristössä.
- Tarkista malli, kun olennainen oletus muuttuu.
Olennaiset yksityiskohdat.
Tarvitsenko muodollisen viitekehyksen aloittaakseni?+
Et. Pieni kaavio ja dokumentoitu skenaariojoukko voivat olla hyödyllisiä. Viitekehys auttaa varmistamaan, että tarkistat riskit johdonmukaisesti.
Korvaako haavoittuvuusskanneri uhkamallinnuksen?+
Ei. Skannerit voivat löytää teknisiä heikkouksia, kun taas uhkamalli tarkastelee myös suunnittelu oletuksia, käyttöoikeuksia ja liiketoiminnan työnkulkuja.
Kuinka usein mallia tulisi päivittää?+
Päivitä asiaankuuluvat osat, kun tietovirrat, integraatiot, käyttöoikeudet tai altistettu toiminnallisuus muuttuvat, ja tarkista ratkaisemattomat riskit säännöllisesti.
Mene lähteelle.
Nämä lähteet tukevat tämän oppaan teknisiä käsitteitä. Noudata ajantasaisia dokumentaatioita ennen tuotantojärjestelmän muuttamista.
- OWASP: Uhkamallinnuksen pikamuistio cheatsheetseries.owasp.org
- OWASP: Uhkamallinnus käytännössä devguide.owasp.org
- OWASP: Liiketoimintalogiikan tietoturva cheatsheetseries.owasp.org
Toimituksellinen ohjaus: SwissOctet. Esimerkit ovat havainnollistavia. Palvelumääritykset, saatavilla olevat vaihtoehdot ja sopimusehdot on tarkistettava erikseen.