Partilhar via


Days-at-risk sammenligning

Days-at-risk er (i alle enkelhet) definert som tiden det tar fra en sårbarhet er offentlig kjent og fram til produsenten kommer opp med en fiks. Dette er etter hvert en mye brukt målemetode rundt sikkerhet i systemer og produsentens evne til å holde produktet oppdatert og dermed sikrere.

I mer detaljerte studier deler man det inne ytterligere i Black, Grey og White risk , da man mener ordinær Days-at-risk alene ikke gir et godt nok svar på den faktiske risikoen. Definert slik:

Black Tiden fra oppdagelse til offentliggjøring. I denne perioden vil det være et fåtall personer som vil være i stand til å utnytte sårbarheten.
Grey Den ordinære definisjonen av Days-at-risk gitt over
White Perioden etter at en fiks er gjort tilgjengelig og fram til systemet faktisk er oppdatert og sikret

 

En annen del av Days-at-risk som ofte diskuteres er hvordan man sammenligner alvorligheten av sårbarheten. Ulike sårbarheter vil jo innebære ulike konsekvenser og jo større konsekvens, jo større er risikoen. De fleste produsenter benytter jo en vekting av sårbarheter, basert på alvorlighet/konsekvens, til å prioritere utvikling og distribusjon av fikser og dette spiller således stor rolle når man sammenligner Days-at-risk for ulike leverandører.

Eksempel

Et system(1) med flere kjente mindre alvorlige feil og høy Days-at-risk kan jo hevdes å være sikrere/bedre oppdatert enn et system (2)med ytterst få, men alvorlige feil og lav days-at-risk. Personlig vil jeg hevde at det ikke alltid er tilfellet om man benytter ganske alminnelige risikovurderinger. F.eks vil lengre tid uten fiks, system 1, øke sannsynligheten for at sårbarheten blir utnyttet og flere sårbarheter (1) er igjen med å øke sannsynligheten for utnyttelse. Men igjen, om konsekvens i systemet 2 er tilsvarende mye større enn totalen for system 2 vil dette komme ut som mer alvorlig like fullt. Det er en enkel formel, om enn ikke like enkel å bruke i praksis, for å vurdere dette, ved å definere risiko som dette:

Risiko = Sannsynlighet * Konsekvens

Og i IT-verden komme det jo inn en parameter til, White-Risk. Hvor mye kapasitet har IT-avdeling til å holde systemene oppdatert? Og for mange er det ofte et spørsmål om hva konsekvensen av oppdateringen blir også. Uten å gå mer inn på det her nå, White-risk blir dermed avhengig av rutiner, verktøy for oppdatering og ikke minst verktøy og rutiner for kartlegging av konsekvensen av oppdateringen. (Enkelt eks: Update Compatibility Evaluator)

 

Resultater av ny sammenligning

Jeff Jones, fra Microsoft, med tung bakgrunn innen IT-sikkerhet de siste 19 årene, poster jevnlig sikkerhetssammenligninger og tilpasser disse etter den vanlige kritikken som kommer mot slike sammenligninger og datagrunnlaget. Jeg syns derfor disse resultatene er interessante. Han har nylig postet en Days-at-risk sammenligning som du finner her:

2006-dor

Om du går inn på posten hans og leser litt ned vil du også finne en spennende sammenligning der Alvorligheten av sårbarheten er tatt med som en faktor i tillegg og se at (nesten) alle leverandører da har noe lavere Days-at-risk. Der finner du også kildene, de ulike leverandørenes sider med tallene og kan sjekke disse selv.

 

Ellers anbefaler jeg fortsatt www.secunia.dk som et godt verktøy for å hente ut sårbarhetsstatisikk selv.

Comments

  • Anonymous
    January 01, 2003
    Days-at-risk er definert som tiden det tar fra en sårbarhet er offentlig kjent og fram til produsenten