Uhkamallinnus: muunna arkkitehtuuri tietoturvapäätöksiksi

Uhkamallinnus kysyy, mikä tietyssä järjestelmässä voisi mennä pieleen ja mitä tiimin pitäisi asialle tehdä. Sen hyödyllinen tuotos ei ole luettelo pelottavista mahdollisuuksista. Se on joukko arkkitehtuuriin sidottuja suunnittelu- ja toteutuspäätöksiä, joilla on omistajat ja näyttö siitä, että valitut puolustuskeinot toimivat.

Teknologiajohtajalle keskeinen kysymys on, pystyykö kehitystiimi selittämään, miten tärkeät tietoturvaominaisuudet säilyvät järjestelmän todellisessa toiminnassa: uudelleenyrityksissä, taustatöissä, etuoikeutetuissa tukitoimissa, toimittajien käyttökatkoissa ja vihamielisissä syötteissä. Kaavio tekee näistä keskusteluista konkreettisia. Ylläpidetty uhkamalli muuntaa johtopäätökset toimitettavaksi työksi.

OWASP:n uhkamallinnusohjeistus antaa hyödyllisen perustan: ymmärrä järjestelmä, tunnista uhat, päätä, miten niihin vastataan, ja arvioi, onko työ riittävää. Alla kuvattu työnkulku soveltaa tätä ajattelua kehityspäätöksiin.

Kuvatkaa järjestelmä ennen kuin keskustelette hyökkäyksistä

Aloittakaa rajatusta kyvykkyydestä, kuten asiakastietojen viennistä, maksujen käynnistämisestä tai laitepäivityksistä. Koko alustan mallintaminen kerralla tuottaa usein pinnallisia havaintoja, koska kukaan ei pysty selittämään jokaista riippuvuutta riittävän yksityiskohtaisesti.

Ilmaiskaa suojattavat kohteet ja tietoturvatavoitteet toiminnallisin termein. ”Suojataan asiakastiedot” on liian laaja. ”Tunnistautunut käyttäjä voi viedä vain niitä tietueita, jotka kuuluvat hänen valtuutettuun asiakasympäristöönsä” antaa tiimille testattavan ominaisuuden. Muut tavoitteet voivat koskea transaktioiden eheyttä, palvelun saatavuutta, palautumista tai hallinnollisten toimien jäljitettävyyttä.

Tunnistakaa käyttäjät, palvelut, tietovarastot, ulkoiset riippuvuudet, sisääntulokohdat ja luottamusrajat. Piirtäkää tärkeät tietovirrat, mukaan lukien asynkroninen käsittely ja hallinnolliset polut. Merkitkää tietovirtoihin siirrettävä tieto, tunnistautumismekanismi ja valtuutuskonteksti silloin, kun ne vaikuttavat analyysiin.

Luottamusraja merkitsee kohtaa, jossa oletukset tai valtuudet muuttuvat, eikä se välttämättä ole verkon kehä. Selain, joka kutsuu API:a, ylittää yhden rajan. Asiakkaan puolesta toimiva jaettu työprosessi ylittää toisen, vaikka molemmat palvelut toimisivat samassa klusterissa.

Näyttäkää monivuokralaissovelluksessa, missä asiakasympäristön (tenant) identiteetti määritetään ja miten se välittyy valtuutustarkistuksiin, taustatöihin ja vienteihin. Ottakaa mukaan palveluidentiteetit, objektitallennuksen käyttöoikeudet, tukityökalut ja ulkoiset takaisinkutsut. Muuten kaavio voi kuvata onnistuneen polun mutta jättää pois ne polut, jotka todennäköisimmin ohittavat eristyksen.

Kirjatkaa oletukset erillään tosiasioista. ”Asiakkaat eivät voi kirjoittaa jonoon” tarvitsee tuekseen konfiguraationäyttöä. Tuntemattomista asioista tulee selvitystehtäviä eikä hiljaisesti hyväksyttyjä puolustuskeinoja.

Valitkaa menetelmä, joka auttaa tiimiä päättelemään

Menetelmä tarjoaa kysymyksiä ja rakennetta. Se ei ratkaise, mitkä uhat ovat tärkeimpiä, todista suunnittelua turvalliseksi tai korvaa järjestelmän tuntemusta.

STRIDE järjestelmällisiä kysymyksiä varten

STRIDE tarkastelee kuutta luokkaa. Soveltakaa niitä asiaankuuluviin komponentteihin, tietovirtoihin ja rajoihin sen sijaan, että pakottaisitte jokaisen luokan jokaiseen kaavion osaan.

Yksi skenaario voi kattaa useita luokkia. Pitäkää tarvittaessa yksi toimintakelpoinen tallenne sen sijaan, että loisitte päällekkäisiä tikettejä luokittelun vuoksi.

Muita menetelmiä eri kysymyksiin

PASTA (Process for Attack Simulation and Threat Analysis) tarjoaa seitsemänvaiheisen, riskikeskeisen lähestymistavan, joka yhdistää liiketoiminnan tavoitteet, teknisen soveltamisalan, järjestelmän jäsentämisen, uhka- ja haavoittuvuusanalyysin, hyökkäysmallinnuksen ja riskien käsittelyn. Se sopii syvällisempään analyysiin, kun hyökkääjän toiminta ja liiketoiminnalliset seuraukset vaativat erityistä huomiota.

Hyökkäyspuut alkavat hyökkääjän tavoitteesta ja jakavat sen vaihtoehtoisiin tai yhdistettyihin reitteihin. Tavoitteelle ”hanki toisen asiakasympäristön vienti” vaihtoehtoja voivat olla API-valtuutuksen ohittaminen, työprosessin asiakasympäristökontekstin sekoittaminen tai lataustunnisteen varastaminen. JA-suhteet kuvaavat ehtoja, joiden on toteuduttava yhdessä; TAI-suhteet kuvaavat vaihtoehtoja.

VAST (Visual, Agile, and Simple Threat modeling) korostaa skaalautuvaa mallinnusta sekä sovelluksen että operoinnin näkökulmista. Sitä harkitsevien tiimien tulee tarkastella, pystyvätkö niiden työkalut ja kehitysprosessi ylläpitämään näitä näkymiä johdonmukaisesti.

Käytännöllinen suositus alkuun on tietovuokaavio ja STRIDE, minkä jälkeen laaditaan hyökkäyspuu seurauksiltaan merkittävimmälle skenaariolle. Lisämenetelmät ovat hyödyllisiä vain, jos ne parantavat päätöksiä.

Rakentakaa katselmointi konkreettisten skenaarioiden ympärille

Kootkaa paikalle ihmiset, jotka ymmärtävät toteutuksen ja operoinnin: kehittäjä, arkkitehti tai tekninen vetäjä, tietoturvakatselmoija ja joku, joka tuntee tuotantoympäristön toiminnan. Ottakaa mukaan tuote-, tietosuoja- tai toimittaja-asiantuntijoita, kun heidän tietämyksensä vaikuttaa soveltamisalaan.

Jakakaa ennen tilaisuutta kaavio, tietoturvatavoitteet, asiaankuuluva konfiguraatio ja ratkaisemattomat oletukset. Käykää katselmoinnissa läpi yksi pyyntö tai tapahtuma sisääntulosta valmistumiseen. Kysykää, missä identiteetti muuttuu, missä tieto tallentuu pysyvästi, mitä yritetään uudelleen ja millä komponentilla on valtuudet hyväksyä toimenpide.

Kirjoittakaa uhat skenaarioina, älkää nimilappuina. ”Valtuutusongelma” ei ole riittävän hyödyllinen. Vahvempi muotoilu on: ”Tunnistautunut käyttäjä vaihtaa tilalle toisen asiakasympäristön vientitunnisteen; latausrajapinta tarkistaa kirjautumisen mutta ei objektin omistajuutta, jolloin asiakastiedot paljastuvat.”

Erottakaa kolme käsitettä:

• Uhka kuvaa haitallista toimintaa tai tapahtumaa, kuten luvatonta viennin noutamista.
• Haavoittuvuus on heikkous, joka voisi mahdollistaa sen, kuten puuttuva omistajuustarkistus.
• Riski ottaa huomioon skenaarion todennäköisyyden ja seuraukset todellisessa ympäristössä.

Uhkaa voi olla syytä tutkia jo ennen kuin haavoittuvuus on vahvistettu. Yhtä lailla heikkouden löytyminen ei osoita, että jokainen kuviteltavissa oleva hyökkäys on toteutettavissa.

Ottakaa ulkoisten hyökkäysten rinnalle mukaan oikeutettujen käyttäjien väärinkäyttö, etuoikeutetut sisäpiiriläiset, konfiguraatiovirheet ja toimittajien häiriöt. Kysykää, mitä tapahtuu, kun riippuvuus aikakatkaistaan tai palauttaa odottamattoman vastauksen. Näistä keskusteluista nousee usein esiin avoimeksi vikaantuva käyttäytyminen ja epäjohdonmukaiset uudelleenyritykset.

Esimerkki: monivuokralainen vientiputki

Seuraava esimerkki on havainnollistava. Oletetaan, että SaaS-sovelluksessa on selainasiakas, API, jaettu tietokanta, työjono, vientityöprosessi ja objektitallennus. Asiakasympäristöjen käyttäjät pyytävät CSV-vientejä; työprosessi luo tiedostot, ja API myöntää väliaikaiset latauslinkit. Tuen ylläpitäjillä on erillinen vianmääritysliittymä.

Tietoturvatavoitteet ovat asiakasympäristöjen eristys, valtuutettu viennin käynnistäminen, rajattu resurssien kulutus ja tukitoimien jäljitettävyys. Oletetaan, että työprosessilla on riittävän laaja tietokantapääsy palvellakseen useita asiakasympäristöjä. Tämä tekee asiakasympäristökontekstin käsittelystä keskeisen päätöksen eikä pientä toteutusyksityiskohtaa.

Seuratkaa valtuuksia tietovirran läpi

API:ssa tunnistautunut toimija liitetään sallittuun asiakasympäristön jäsenyyteen. Selaimen antama asiakasympäristön tunniste on valintapyyntö, ei todiste valtuutuksesta. API tarkistaa jäsenyyden ja vientioikeuden ennen kuin se luo muuttumattoman työtietueen, joka sisältää valtuutetun asiakasympäristön, pyytäjän ja sallitun viennin laajuuden.

Jonoviesti viittaa tähän tietueeseen. Työprosessi validoi työn ja panee täytäntöön asiakasympäristökohtaisen tietojen käytön viennin tuottamisessa. Tallennuksen metatiedot liittävät syntyneen objektin työhön ja asiakasympäristöön. Ennen latauslinkin myöntämistä API tarkistaa nykyisen pyytäjän valtuutuksen tätä liitosta vasten.

Tämä suunnitelma edellyttää silti nimenomaisia päätöksiä käyttöoikeuksien mitätöinnistä: pitäisikö käyttäjän, joka menettää jäsenyytensä viennin pyytämisen jälkeen, säilyttää pääsy valmiiseen tiedostoon? Tiimin on määriteltävä tämä käytäntö ja toteutettava se johdonmukaisesti.

Muuntakaa skenaariot kontrolleiksi ja testeiksi

Väliaikaiset linkit tuovat mukanaan jäljelle jäävän altistusikkunan: mekanismista riippuen linkin hallussapito voi mahdollistaa pääsyn sen vanhenemiseen asti. Tiimin tulee päättää, onko tämä hyväksyttävää kyseisten tietojen osalta vai tarvitaanko latauksille tunnistautunut välittäjä, joka tarkistaa ajantasaisen valtuutuksen.

Älkää sulkeko mallia, kun olette testanneet vain synkronisen API:n. Todentakaa viivästetyt työt, uudelleenyritykset, perutut pyynnöt, vanhentunut jäsenyys, poistetut asiakasympäristöt ja osittaiset virheet. Esimerkiksi uudelleen yritetty työ ei saa käyttää uudelleen toiseen asiakasympäristöön liitettyä objektia tai julkaista keskeneräistä vientiä onnistuneena.

Lopputuloksena on katselmoitu arkkitehtuuri, uhkarekisteri, toteutustehtävät ja linkitetyt todentamistulokset. Se ei ole pelkkä kaavio.

Priorisoikaa altistuksen ja seurausten perusteella

Priorisoikaa uskottavat skenaariot altistuksen, vaikutuksen, edellytysten ja olemassa olevien puolustuskeinojen perusteella. Erottakaa suoraan tavoitettavissa oleva valtuutusvirhe skenaariosta, joka edellyttää useita todentamattomia murtoja. Huomioikaa tarvittaessa kyseiset tiedot, palvelukatkos, taloudelliset seuraukset, turvallisuusvaikutukset ja palautumisen vaikeus.

Käyttäkää yksinkertaista johdonmukaista asteikkoa, jos se auttaa tiimiä, mutta kirjatkaa luokituksen perustelut. Numeerinen pistemäärä, jonka lähtötietoja ei selitetä, luo näennäistä tarkkuutta. CVSS voi tukea konkreettisen haavoittuvuuden arviointia; se ei korvaa liiketoimintavaikutuksen tai arkkitehtuuritason väärinkäyttötapauksen ymmärtämistä.

Käsittelyvaihtoehtoja ovat suunnittelun muuttaminen, altistuksen pienentäminen, ennaltaehkäisevien tai havaitsevien kontrollien lisääminen, kyvykkyydestä luopuminen tai jäljelle jäävän riskin hyväksyminen. Toimittajasopimukset voivat jakaa vastuita, mutta ne eivät poista teknisiä vikaantumistapoja.

Jäännösriskillä tulee olla nimetty päätöksentekijä, perustelu, päättymispäivä tai katselmoinnin käynnistäjä sekä mahdolliset toimintaehdot. Kehitystyön valmistuminen ja riskin hyväksyminen ovat eri päätöksiä. Tiketti voi olla valmis, vaikka merkittävä riski on edelleen olemassa.

Viekää malli toimitukseen ja näyttöön

Kirjatkaa jokaisesta olennaisesta skenaariosta sen tunniste, kyseiset komponentit, edellytykset, seuraus, olemassa olevat puolustuskeinot, käsittely, omistaja ja todentamistapa. Linkittäkää tallenne arkkitehtuuriversioon ja asiaankuuluvaan toteutustyöhön, jotta katselmoijat näkevät, mitä suunnitelmaa arvioitiin.

Muuntakaa käsittelyt testattaviksi hyväksymiskriteereiksi. ”Parannetaan pääsynhallintaa” on epämääräinen. ”Asiakasympäristö A ei voi pyytää, kysellä, perua tai ladata asiakasympäristön B vientiä minkään tuetun rajapinnan kautta” yksilöi käyttäytymisen, jonka kehitys voi todentaa.

Käyttäkää väitteeseen sopivaa näyttöä:

• Koodikatselmointi voi osoittaa, missä valtuutus pannaan täytäntöön.
• Konfiguraation tarkastus voi osoittaa palvelujen oikeudet ja tallennuksen altistuksen.
• Kielteiset integraatiotestit voivat testata asiakasympäristöjen välisiä rajoja ja oikeustasojen rajoja.
• Kuormitus- ja vikojen injektointitestit voivat tarkastella saatavuutta ja vikaantumiskäyttäytymistä.
• Kohdennettu tunkeutumistestaus voi tutkia hyökkäyspolkuja, jotka vaativat riippumatonta selvittämistä.

Mikään yksittäinen artefakti ei todista koko mallia. Kuvakaappaus asetuksesta ei todista, että jokainen työprosessi käyttää sitä, eikä läpäisty testi osoita testaamatonta polkua. Kirjatkaa testiympäristö, laajuus, tulokset ja rajoitukset.

Uhkamallinnus täydentää turvallista ohjelmointia, riippuvuuksien arviointia, haavoittuvuusskannausta ja tunkeutumistestausta. Sen erityinen anti on arkkitehtuuritason päättely: se voi paljastaa vaarallisen valtuuksien jaon silloinkin, kun yksittäisissä komponenteissa ei ole tunnettuja haavoittuvuuksia.

Pitäkää työkalut ja automaatio mallin alisteisina

Jaettu kaavio ja jäsennelty rekisteri voivat tukea rajattua ensimmäistä katselmointia. Erillisistä työkaluista tulee hyödyllisiä, kun tiimit tarvitsevat uudelleenkäytettäviä komponenttikirjastoja, johdonmukaisia tunnisteita, yhteistyötä ja luotettavia linkkejä uhkien ja toimitustallenteiden välillä.

Arvioikaa, tukeeko työkalu luottamusrajoja, omia skenaarioita, versiohistoriaa, vietäviä tallenteita, omistajuutta ja näyttöviittauksia. Automaattisesti tuotetut uhat ovat tarkasteltavia kysymyksiä, eivät vahvistettuja havaintoja. Pitkät luettelot ilman kontekstia voivat piilottaa ne harvat päätökset, joilla on merkitystä.

Tekoälyavusteisuus voi luonnostella skenaariokuvauksia, ehdottaa puuttuvia polkuja tai verrata muutoksia aiempaan malliin. Ihmiskatselmoijien on silti validoitava arkkitehtuuri, toteutettavuus, torjuntakeinojen kattavuus ja jäännösriski. Pitäkää luottamukselliset kaaviot ja tunnistetiedot poissa hyväksymättömistä palveluista. Uhkamallien tuottaminen on myös eri asia kuin ajonaikainen havaitseminen; mallin laatiminen ei vakiinnuta jatkuvaa valvontaa tai automaattista korjaamista.

Katselmoikaa, kun arkkitehtuuri tai oletukset muuttuvat

Päivittäkää malli uusien integraatioiden, tunnistautumismuutosten, etuoikeutettujen toimien, tietoluokkien, verkkoaltistuksen ja merkittävien riippuvuusmuutosten yhteydessä. Myös poikkeama tai odottamaton testitulos voi tehdä aiemmasta oletuksesta pätemättömän.

Eri järjestelmät vaativat eri painotuksia. Pilvisovellukset vaativat huomiota identiteettien oikeuksiin ja hallintatason pääsyyn. Mobiiliasiakkaita tulee käsitellä hyökkääjän hallitsemina ympäristöinä eikä luotettuina täytäntöönpanopisteinä. Verkkoon kytketyt laitteet tuovat mukanaan fyysisen pääsyn, päivitysten eheyden, palautumisen ja mahdollisesti turvallisuusseuraukset. Tekoälyä hyödyntävät ominaisuudet lisäävät epäluotettavan sisällön ja työkalujen käytön rajoja; valtuutuksen on rajattava toimintoja mallin tuotoksesta riippumatta.

Mitatkaa, onko tärkeillä tietovirroilla ajantasaiset mallit, onko korkean prioriteetin käsittelyillä todentavaa näyttöä, onko oletuksia ratkaisematta ja onko hyväksyttyjen riskien katselmointeja myöhässä. Pelkkien uhkien laskeminen palkitsee määrää eikä hyödyllistä analyysia. Pyytäkää säännöllisesti riippumatonta katselmoijaa haastamaan yksi kriittinen skenaario ja sen näyttö.

Tehkää ensimmäisestä katselmoinnista niin pieni, että sen saa valmiiksi

Secani voi säilyttää näiden päätösten ympärillä olevan työnkulun mallintamalla asiaankuuluvat järjestelmät ja riippuvuudet, osoittamalla omistajat ja katselmoijat sekä yhdistämällä näytön vaatimuksiin, kontrolleihin ja päätöksiin. Ratkaisemattomista oletuksista tulee tehtäviä; lähdeaineisto ja ihmisten tekemät hyväksynnät pysyvät liitettyinä katselmointiin. Kaikki tekoälyavusteiset ehdotukset tulee tarkistaa ennen hyväksyntää.

Aloittakaa yhdestä kriittisestä tietovirrasta. Seuratkaa sen valtuuksia päästä päähän, tunnistakaa kourallinen uskottavia skenaarioita ja päättäkää työ omistettuihin käsittelyihin ja nimenomaisiin todentamiskriteereihin. Ajoittakaa seuraava katselmointi niiden arkkitehtuurimuutosten mukaan, jotka voisivat tehdä näistä päätöksistä pätemättömiä.