Sisältö
- Vain tosiasiat
- Ei vikoja, ei stressiä - vaiheittaiset ohjeet elämää muuttavien ohjelmistojen luomiseen tuhoamatta elämääsi
- Kirjanpidon vaikutus?
- Aika muuttaa järjestelmää?
Lähde: BrianAJackson / iStockphoto
Ottaa mukaan:
On aika tutkia asioita siitä, miten ajattelemme avoimen lähdekoodin komponenttien riskien arviointia.
Järjestelmän kehittäminen sen arvioimiseksi, kuinka vakavasti ohjelmistokehitysyhteisön tulisi ottaa haavoittuvuuksia, on haaste lempeästi sanottuna. Ihmiset ovat kirjoittaneet koodin, ja sillä on aina puutteita. Kysymys on sitten, jos oletamme, että mikään ei koskaan ole täydellistä, miten voimme luokitella komponentit parhaiten niiden riskin mukaan tavalla, joka antaa meille mahdollisuuden jatkaa tuottavaa työtä?
Vain tosiasiat
Vaikka ongelman ratkaisemiseksi voidaan käyttää monia erilaisia lähestymistapoja, joilla jokaisella on oma pätevä perusteensa, yleisin menetelmä näyttää perustuvan kvantitatiiviseen malliin.
Toisaalta kvantitatiivisen lähestymistavan käyttäminen haavoittuvuuden vakavuuden arviointiin voi olla hyödyllistä, koska se on objektiivisempi ja mitattavissa, ja se perustuu yksinomaan itse haavoittuvuuteen liittyviin tekijöihin.
Tässä metodologiassa tarkastellaan, millaisia vaurioita voi syntyä, jos haavoittuvuutta käytetään hyväksi, ottaen huomioon, kuinka laajasti komponenttia, kirjastoa tai projektia käytetään koko ohjelmistoteollisuudessa, sekä tekijöitä, kuten minkälaisia pääsyjä se voi antaa hyökkääjälle hylyn tuho, jos he käyttävät sitä rikkomaan tavoitettaan. Sellaisilla tekijöillä kuin helppo potentiaalinen hyväksikäyttö voi olla suuri merkitys pisteet vaikuttaessa. (Lisätietoja tietoturvasta, katso kyberturvallisuus: Kuinka uudet edut tuovat uusia uhkia - ja varapuheenjohtaja.)
Jos haluamme tarkastella makrotasoa, kvantitatiivisessa perspektiivissä tarkastellaan, kuinka haavoittuvuus voisi vahingoittaa laumaa, keskittyen vähemmän vahinkoihin, jotka voivat kohdistua hyökkäyksen tosiasiassa kärsineisiin yrityksiin.
Kansallinen haavoittuvuustietokanta (NVD), ehkä tunnetuin heikkouksien tietokanta, käyttää tätä lähestymistapaa molemmille versioille 2 ja 3 niiden yhteiseen haavoittuvuuspistejärjestelmään (CVSS). Heidän haavoittuvuuksien arviointia koskevia tietojaan kuvaavalle sivulle he kirjoittavat menetelmästään, joka:
Sen kvantitatiivinen malli varmistaa toistettavan tarkan mittauksen ja antaa käyttäjille mahdollisuuden nähdä taustalla olevat haavoittuvuusominaisuudet, joita käytettiin pisteiden luomiseen. Siten CVSS sopii hyvin standardi mittausjärjestelmäksi toimialoille, organisaatioille ja hallituksille, jotka tarvitsevat tarkkoja ja yhdenmukaisia haavoittuvuuksien vaikutuspisteitä.
Pelattujen kvantitatiivisten tekijöiden perusteella NVD pystyy sitten keksimään vakavuusasteen, molemmilla on niiden asteikolla oleva luku - 1–10, 10 on vakavimpia - samoin kuin LOW, MEDIUM ja HIGH luokkiin. .
Ei vikoja, ei stressiä - vaiheittaiset ohjeet elämää muuttavien ohjelmistojen luomiseen tuhoamatta elämääsi
Et voi parantaa ohjelmointitaitojasi, kun kukaan ei välitä ohjelmiston laadusta.
Kirjanpidon vaikutus?
Näyttää kuitenkin siltä, että NVD pyrkii pysymään selvillä siitä, mitä voimme kutsua paremmin haavoittuvuuden kvalitatiiviseksi toimenpiteeksi sen perusteella, kuinka vaikuttava tietty hyödyntäminen on ollut vahingon aiheuttamisessa. Oikeudenmukaisuuden vuoksi niihin sisältyy vaikutuksia siltä osin kuin ne mittaavat haavoittuvuuden vaikutusta järjestelmään tarkastelemalla luottamuksellisuuden, eheyden ja saatavuuden tekijöitä. Nämä ovat kaikki tärkeitä tarkasteltavia elementtejä - kuten helpommin mitattavissa olevan käyttövektorin, pääsyn monimutkaisuuden ja todentamisen yhteydessä -, mutta ne eivät vastaa tehtävästään yhdistää reaalimaailman vaikutukset, kun haavoittuvuus aiheuttaa organisaatiolle todellisia menetyksiä.
Otetaan esimerkiksi Equifax-rikkomus, joka paljasti noin 145 miljoonan ihmisen henkilökohtaiset tunnistetiedot, mukaan lukien heidän ajokorttitietonsa, sosiaaliturvatunnuksensa ja muut bitit, joita häikäilemättömät henkilöt voisivat käyttää massiivisten petosoperaatioiden suorittamiseen.
Se oli haavoittuvuus (CVE-2017-5638), joka löydettiin Apache Struts 2 -projektista ja jota Equifax käytti verkkosovelluksessaan ja jonka avulla hyökkääjät pystyivät kävelemään etuovesta ja saamaan sen lopulta kätensä täynnä mehukkaita henkilökohtaisia tietoja .
Vaikka NVD antoi sille oikein vakavuuspisteen 10 ja HIGH, heidän päätöksensä johtui niiden mahdollisen vahingon kvantitatiivisesta arvioinnista, eikä heihin vaikuttanut laajat vahingot, joita tapahtui myöhemmin, kun Equifax-rikkomus tuli julkiseksi.
Tämä ei ole NVD: n valvonta, vaan osa heidän ilmoitettua politiikkaa.
NVD tarjoaa CVSS "perustulokset", jotka edustavat kunkin haavoittuvuuden luontaisia ominaisuuksia. Emme tällä hetkellä tarjoa "ajallisia pistemääriä" (mittarit, jotka muuttuvat ajan myötä haavoittuvuuden ulkopuolella olevien tapahtumien takia) tai "ympäristöpisteitä" (pisteitä, jotka on räätälöity heijastamaan haavoittuvuuden vaikutusta organisaatioosi).
Päätöksentekijöille kvantitatiivisen mittausjärjestelmän tulisi olla vähemmän tärkeä, koska se tarkastelee mahdollisuuksia levittää haittoja koko teollisuudelle. Jos olet pankin kansalaisjärjestö, sinun tulee olla huolissaan laadullisista vaikutuksista, joita hyväksikäytöllä voi olla, jos sitä käytetään selvittämään asiakkaasi tietosi tai mikä pahempaa, heidän rahansa. (Lisätietoja erityyppisistä haavoittuvuuksista tekniikan 5 pelottavimmassa uhassa.)
Aika muuttaa järjestelmää?
Joten pitäisiko Equifax-tapauksessa käytetyn Apache Strusts 2: n haavoittuvuus saada korkeampi sijoitus, kun otetaan huomioon sen vahingon laajuus tai muutoksen tekeminen NVD: n kaltaiselle järjestelmälle liian subjektiiviseksi jatkaa?
Myönnämme, että NVD: n kuvaamien "ympäristöpisteiden" tai "ajallisten pisteiden" laatimiseksi tarvittavien tietojen hankkiminen olisi erittäin vaikeaa, avaamalla ilmaisen CVSS-ryhmän johtajat loputtomalle kritiikalle ja paljon työtä NVD: lle ja muille heidän tietokantojensa päivittämiseksi, kun uutta tietoa ilmestyy.
Tietysti on kysymys siitä, kuinka tällainen pistemäärä kootaan, koska hyvin harvat organisaatiot todennäköisesti tarjoavat tarvittavat tiedot rikkomisen vaikutuksista, ellei niitä edellytetä julkistamislaissa. Uber-tapauksesta olemme nähneet, että yritykset ovat valmiita maksamaan nopeasti maksamaan toiveensa siitä, että rikkomusta ympäröivät tiedot tulevat saapumaan lehdistölle, etteivät ne joudu julkisen takaiskuihin.
Ehkä tarvitaan uusi järjestelmä, joka voisi yhdistää haavoittuvuustietokantojen hyvät ponnistelut ja lisätä omat lisäpisteensä, kun tietoa tulee saataville.
Miksi aloittaa tämä ylimääräinen pisteytyskerros, kun edellinen näyttää suorittaneen tehtävänsä riittävän hyvin kaikki nämä vuodet?
Suoraan sanottuna organisaatioiden vastuu on vastuu hakemuksistaan. Ihanteellisessa maailmassa jokainen tarkistaa tuotteissaan käyttämiensä komponenttien pisteet ennen niiden lisäämistä luetteloon, vastaanottaa hälytyksiä, kun aiemmin turvallisina pidettyjen projektien yhteydessä havaitaan uusia haavoittuvuuksia, ja ottamaan tarvittavat korjaukset käyttöön yksin .
Ehkä jos olisi luettelo, joka osoittaisi, kuinka tuhoisat jotkut näistä haavoittuvuuksista voivat olla organisaatiolle, organisaatiot saattavat tuntea suurempaa painostusta olla ottamatta kiinni vaarallisista komponenteista. Ainakin he voivat ryhtyä toimiin todellisen luettelon tekemiseksi jo olemassa olevista avoimen lähdekoodin kirjastoista.
Equifax-fiaskon jälkimainingeissa useampi kuin yksi C-tason johtaja yritti todennäköisesti sekoittaa varmistaakseen, että heillä ei ollut tuotteissa haavoittuvaa versiota Strutsista. On valitettavaa, että tarvittiin tämänsuuruinen tapaus pakottaa teollisuus ottamaan avoimen lähdekoodin tietoturvansa vakavasti.
Toivottavasti oppitunnilla, jonka mukaan sovellusten avoimen lähdekoodin komponenteilla voi olla erittäin todellisia seurauksia, on vaikutusta siihen, kuinka päätöksentekijät priorisoivat tietoturvaa valitsemalla oikeat työkalut tuotteiden ja asiakkaiden tietojen pitämiseksi turvassa.