Varnostno-razvojni cikel SDL
V začetku so bili programski hrošči, vsaka kompleksna koda namreč vsebuje napake. Vedno in povsod. Sledilo je obdobje sistematičnega kompromitiranja okenskih sistemov, pandemične ekspanzije spletnih črvov in programov "klikni-in-hekaj". Enkrat takrat je javno zasmehovanje nad količino in resnostjo odkritih vrzeli v Oknih postalo del folklore. Nato je prišel SDL.
Po SDL ni bilo nič več tako kot prej. No, skoraj nič, kajti SDL (Security Development Lifecycle) seveda ni odpravil vseh programskih defektov, kar je tudi povsem utopično pričakovati. Varnostno-razvojni cikel namreč ni čarobna paličica, ki bi z enim zamahom odpravila pomanjkljivosti. Razvojni proces SDL ima v svojem bistvu dva primarna namena: zmanjšati količino napak v kodi in zmanjšati učinek pomanjkljivostim, ki so se izmuznile celotnemu postopku.
Namen članka seveda ni opevati slavo gigantu iz Redmonda, vendar moramo priznati, da je Microsoft v zadnjih letih, tudi po zaslugi SDL in seveda velikanske količine vloženega denarja, radikalno spremenil odnos do varnosti. Na bolje seveda. Marsikdo se s slednjim verjetno ne strinja in že brska po spletu za najnovejšo "security metric" analizo, ki trdi ravno nasprotno. Hvala za trud, vendar že podroben pregled naključne spletne zbirke z zlonamerno kodo povsem zadostuje. Delujoča izkoriščevalna koda za najnovejša Okna je zelo redek pojav. Nihče kakopak ne trdi, da takih kritičnih vrzeli ni, vendar je njihov indeks izkoriščanja (exploitability index) zelo visok, učinek omejen, samo delovanje pa največkrat pogojeno z "doprinosom" uporabnika ali zunanje "3rd party" aplikacije. Microsoft se je iz svojih preteklih spodrsljajev nedvomno veliko naučil. Danes številni priznani varnostni strokovnjaki celo trdijo, da je, kar zadeva obravnavo varnostnih incidentov in pristopa do varnosti, lahko mnogim za vzgled. Tisto ponarodelo prepričanje, da "Okna in varnost ne gre skupaj", je torej zgolj stereotip, čeprav je res, da ima Microsoft v svoji omari še kar nekaj okostnjakov.
Začetki
Uradni viri navajajo, da je Microsoft na pobudo samega Billa Gatesa, uvedel Trustworty Computing (TwC) leta 2002 kot odgovor na vse večjo nevarnost, ki je pretila s strani hekerjev in spletnih kriminalcev. TwC je predvideval tudi implementacijo SDL v razvojni proces programske opreme. Čeprav je bil SDL dokumentiran že od samega začetka, je širši javnosti postal znan leta 2006, ko sta Michael Howard in Steve Lipner objavila istoimensko knjigo, v kateri sta podrobno opisala celoten postopek.
Kaj sploh je "varnostno razvojni cikel"? Gre za proces oz. način razvoja programske opreme, ki določa varnostne zahteve in mejnike in je obvezen za vse izdelke, ki so izpostavljeni varnostnim tveganjem. V nasprotju s splošnim prepričanjem ne gre za avtorsko zaščiten ali patentiran pristop, saj Microsoft spodbuja preostale korporacije in razvijalce, naj integrirajo SDL v svoj programsko razvojni cikel (SDLC, Software Development Lifecycle).
Tradicionalno razvojni cikel programske opreme sestavlja pet faz (no, to je sicer čisto odvisno od samega modela): analiza, načrtovanje, razvoj, implementacija in kontrola/vzdrževanje. SDL ni nič drugega kot nekoliko spremenjen in izpopolnjen SDLC s poudarkom na varnosti.
Faze varnostno razvojnega cikla SDL
Naj se na kratko spustimo v posamezne faze procesa SDL.
Najprej je predfaza v obliki različnih varnostnih tečajev in delavnic, ki je obvezna za vse Microsoftove razvijalce. V tej fazi si udeleženci pridobijo razumevanje varnostnih problemov in konceptov. Sledi analiza oz. so to v SDL metodologiji zahteve (requirements), kjer se opravi analiza varnostnih tveganj in varovanja zasebnosti ter sprejme odločitve, kako oboje kar najučinkoviteje integrirati v razvojni proces. Naslednji korak je načrtovanje, pri čemer se izvaja analiza groženj (threat analysis, threat modeling) in analiza vseh mogočih načinov, kako lahko napadalec kompromitira aplikacijo (t. i. attack surface analysis). V tej fazi je pomembno razločevati med grožnjo in ranljivostjo, kar še zdaleč ni isto. Ranljivost je največkrat mogoče odpravi s popravkom, grožnjo pa le s korenitim posegom. Čisto preprost zgled: izvajanje JavaScripta v brskalnikih predstavlja grožnjo, v celoti pa jo lahko odpravimo le z izklapljanjem omenjene funkcionalnosti. Šele pri grožnjah pride tisti znani rek "Varnost je sklepanje kompromisov" do popolnega izraza. Implementacija predvideva uporabo specifičnih razvojnih orodij, npr. ustreznih stikal v prevajalniku (/GS, /NXCOMPAT, /SAFESEH, /DYNAMICBASE, /analyze ...), uporabo ustreznih "header" datotek (npr. banned.h), ki preprečujejo uporabo nevarnih C/C++ funkcij, in izvajanje statične analize kode. Verifikacija je faza konkretnega preverjanja predhodno postavljenih zahtev. To zajema intenzivno uporabo t. i. "fuzzer" programov, ki preverjajo delovanje aplikacije v kaotičnem okolju. Na tej ravni se izvaja tudi dinamična analiza. Faza izdaje (release) nastopi, tik preden je izdelek pripravljen za vstop na trg oz. v roke uporabnikom. Primarni namen te faze je izdelava strateškega (odzivnega) načrta za primer, da bi bila v programu odkrita varnostna pomanjkljivost. Izvede se tudi končni varnosti pregled (Final Security Review), ki zaobjema podrobno analizo vseh predhodnih stopenj. Zadnja točka v procesu, dejansko gre za "postfazo", nastopi, ko je izdelek tudi javno dostopen. Faza predvideva, da je skupina strokovnjakov v vsakem trenutku pripravljena odgovoriti na vsakršen varnostni incident v zvezi z aplikacijo. To skupino med drugim sestavljajo tudi člani ekip SRC (Security Response Center) in SRD (Security vulnerability Research & Defense).
Orodja
Microsoft v procesu SDL uporablja veliko interno razvitih orodij. Nekatera čez čas tudi javno objavi. Čeprav velja prepričanje, da so ti programi namenjeni zgolj razvijalcem, pa to ne drži povsem, saj so mnogi uporabni tako za domače uporabnike kot tudi za skrbnike sistemov. V nadaljevanju si bomo ogledali nekaj teh orodij. Nekaterih opisanih programov sicer ni razvila ekipa SDL, temveč že omenjena ekipa SRD oziroma ekipa SEC (Security Engineering Center), ki tesno sodelujeta v varnostno-razvojnem procesu. Vsa orodja so seveda povsem brezplačna.
!exploitable
Gre za podaljšek (extension) razhroščevalnika WinDbg, ki omogoča avtomatično analizo in vrednotenje tveganj (risk assessment) v primeru sesutja aplikacije. Uporabniki Microsoftovega razhroščevalnika verjetno poznajo stikalo "!analyze", ki deluje po podobnem načelu, le da gre v primeru stikala "!exploitable" za poudarek na varnostnih vidikih. Podaljšek vsako sesutje aplikacije vrednoti po naslednjem kriteriju: "izkoriščanje možno", "izkoriščanje verjetno možno", "izkoriščanje verjetno ni možno" in "neznano". Seveda prvi kriterij še zdaleč ne pomeni, da je izkoriščanje vrzeli trivialno, prav tako zadnji ni poroštvo, da izkoriščanje ni možno. Uporaba podaljška je zelo preprosta. Datoteko msec.dll prekopiramo v imenik Winext znotraj namestitvenega imenika razhroščevalnika WinDbg. Ob sesutju aplikacije se avtomatično zažene WinDbg (slednje zagotovimo z ukazom "windbg -I"), modul naložimo z ukazom "!load winext\msec.dll", nato pa uporabimo stikalo "!exploitable".
Podaljšek "!exploitable" označi sesutje programa kot tvegano
EMET (Enhanced Mitigation Evaluation Toolkit)
Orodje EMET je namenjeno zmanjševanju učinka (mitigation) pri nekaterih najpogosteje uporabljenih pristopih izkoriščanja vrzeli v sistemih Windows. EMET konkretno izvaja naslednje oblike zaščite: SEHOP (preprečuje prepisovanje strukture SEH); Dynamic DEP (označi določene dele pomnilniškega prostora procesa kot neizvedljive); preprečuje dodeljevanje pomnilniške strani NULL in onemogoča izkoriščanje dereferenciranega kazalca NULL (NULL pointer dereference); izvaja predodeljevanje najbolj razširjenih pomnilniških naslovov, ki se uporabljajo pri vrivanju kode z razprševanjem kopice (heap spraying). Tudi v tem primeru je uporaba programa trivialna. Če želimo, da bo EMET izvajal zaščito nad določenim programom, izvedemo naslednji ukaz: emet_conf -add program.exe, programu odstranimo zaščito z ukazom emet_conf -delete program.exe. Priporočljivo je uporabljati EMET s programi, ki so pogosto tarča 0-day ranljivosti (Internet Explorer, Firefox, Acrobat Reader, Word, Excel, Windows Media Player, Windows Live Messenger, Apple QuickTime ...).
Vsekakor pa si velja ogledati tudi drugo plat medalje. EMET dejansko ni preveden s /SafeSEH stikalom, obenem pa se dinamična knjižnica (emet.dll) vedno naloži na statični naslov v pomnilniku (t. i. "pseudo-ASLR"), kar pomeni, da so naslovi operacij (delno) predvidljivi in jih lahko napadalci uporabijo za premostitev mehanizma ASLR. Še več, raziskovalci so tudi odkrili način, kako zaobiti zaščito, ki preprečuje dodeljevanje strani NULL. V vsakem primeru pa je EMET program, ki prinaša več pozitivnih kakor negativnih lastnosti, njegova uporaba pa je za lastnike starejših sistemov (XP/2003) skoraj obvezna.
BinScope
Naslednje orodje se v fazi verifikacije uporablja že od samih začetkov procesa SDL. BinScope je program za analizo binarnih datotek s poudarkom na preverjanju uporabe ustreznih stikal pri prevajanju, pa tudi opozarjanju na morebitno uporabo odsvetovanih programerskih metod, npr.: globalnih kazalcev ali nevarnih deljenih sekcij (shared sections). Čeprav je BinScope namenjen predvsem programerjem, je s prijaznim grafičnim vmesnikom primeren tudi za navadne uporabnike, ki z njim lahko preverijo minimalno varnostno ustreznost aplikacij. Marsikdo bo neprijetno presenečen nad brezbrižnostjo, tudi velikih in uveljavljenih razvijalcev, pri implementaciji osnovnih principov glede varnosti pri razvoju aplikacij.
BinScope preveri, preveri, ali smo program prevedli s pravimi stikali.
MiniFuzz
Programi za testiranje delovanja aplikacije v kaotičnem okolju oz. "fuzerji" so danes primarna orodja za odkrivanje pomanjkljivosti v programih. Microsoft tako navaja, da je okrog 25 % pomanjkljivosti odkritih ravno v internem "fuzz testing" procesu. Ker se ti programi v fazi verifikacije intenzivno uporabljajo, je MiniFuzz eno prvih orodji, ki jih je ekipa SDL tudi javno objavila. MiniFuzz je intuitiven "file fuzzer", namenjen uporabnikom, ki nimajo izkušenj z izvajanjem takega testiranja.
Delovanje programa bomo najlaže opisali na primeru aplikacije za prikazovanje fotografij. V imenik "Templates" znotraj namestitvenega imenika prekopiramo vse v testirani aplikaciji podprte formate fotografij (jpg, png, bmp ...), nato v samem programu določimo pot do izvršne datoteke testirane aplikacije in klikemo "Start fuzzing".
SDL MiniFuzz izvaja t. i. "dumb fuzzing", kar preprosto pomeni, da vsaki datoteki v imeniku "Template" najprej spremeni naključni niz bitov, nato pa jo kot vnosni parameter posreduje testirani aplikaciji. SDL predvideva najmanj 100.000 takih vnosov za posamezni format. Ob sesutju testiranega programa se "števec" izniči, to pa zahteva izvajanje nadaljnjih 100.000 iteracij "bremenilnega" formata.
Threat Modeling Tool
www.microsoft.com/security/sdl/getstarted/threatmodeling.aspx
Postopek izdelave modela groženj (threat modeling) je proces odkrivanja zasnovnih napak (design flaw) v programskih komponentah, preden je aplikacija v celoti napisana in prevedena. Gre za obsežno in zahtevno skupinsko delo, pri katerem sodelujejo vodje projektov, arhitekti, oblikovalci in programerji. Da bi Microsoft zapleteni proces vsaj nekoliko približal tudi zunanjim programerjem, je izdelal orodje "Thread Modeling Tool", ki uporablja interno razviti model STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privileges). Model predvideva, da je vse grožnje mogoče definirati s kategorijami STRIDE. Razvijalec torej določi, katere so potencialne grožnje ustaljenemu delovanju aplikacije, orodje pa predlaga specifične premostitvene postopke, ki jih programer nato upošteva pri razvoju programa.
Tudi v tem orodju so raziskovalci našli nekaj varnostnih "spodrsljajev" Microsoftovih programerjev. Starejše različice programa "Threat Modeling" so namreč vsebovale lokalne vrzeli XSS, omogočale pa so tudi izvajanje kode prek ranljivih gradnikov ActiveX: www.sensepost.com/blog/4120.html. Aktualna različica teh težav seveda nima.
OffVis
http://go.microsoft.com/fwlink/?LinkId=158791
Morda se bo kdo vprašal, zakaj neki je OffVis, čeprav ni namenjen uporabi v procesu SDL, kljub temu našel svoje mesto v tem kratkem sprehodu skozi programe. Preprosto, je namreč eno redkih javno dostopnih orodij, ki je namenjeno izključno analizi Pisarniških formatov datotek (doc, xls, ppt). V času, ko so t. i. "client-side" napadi, ki izkoriščajo 0-day vrzeli v Pisarniških programih, postali stalnica, je takšno orodje vredno vsaj omeniti. OffVis je sicer namenjen predvsem uporabnikom Office 2000/XP/2003, saj so ti pogosteje tarča vsiljivcev. Uporaba programa je dokaj preprosta, vendar zahteva vsaj osnovno razumevanje problema. Nekomu, ki se mu popolnoma nič ne svita, kako naj bi bilo videti zlonamerno breme (malicious payload) v šestnajstiškem formatu, tak program seveda prav nič ne koristi.
Orodje OffVis odkrije zlonamerno breme Vir: www.microsoft.com
Seveda to še zdaleč niso vse dobrote, ki jih Microsoft v okviru SDL iniciative brezplačno ponuja uporabnikom. Predvsem paleta pripomočkov, namenjenih programerjem, je zelo široka. Med drugim zajema tudi FxCop (orodje za analizo .NET kode), knjižnico Anti-XSS (varuje pred izvajanjem XSS vrzeli v skriptih ASP), CAT.NET (orodje za analizo kode, ki olajša odkrivanje XSS pomanjkljivosti, vrivanje SQL in vrivanje XPath), SiteLock (omejuje dostop do gradnikov ActiveX), banned.h ("header" datoteka, ki preprečuje uporabo nevarnih C/C++ funkcij) ter Source Code Analyzer for SQL Injection (program za statično analizo kode, namenjen iskanju "SQL injection" vrzeli). Pred kratkim pa so v okviru programa SDL začeli tudi izdajati publikacije QSR (Quick Security References), v katerih bodo periodično predstavili specifičen razred ranljivosti. Prva v serija sta bila XSS in vrivanje SQL poizvedb.
Da ima varnostno-razvojni cikel med strokovnjaki za računalniško varnost visoko podporo, dokazuje tudi projekt SDL Pro Network, torej omrežje ponudnikov svetovalnih storitev, ki ponuja nasvete in podporo organizacijam pri uporabi metodologije SDL v svojih okoljih. Žal med vključenimi podjetji nismo našli domačega.
Seveda ima SDL tudi nekatere nasprotnike. Priznani varnostni raziskovalec Alexander Sotirov je nedavno po Twitterju objavil naslednje sporočilo: "Začnite čim prej uporabljati SDL. To je najboljši način reševanja varnostnih problemov izpred desetih let." Sotirov je nedvomno avtoriteta na področju računalniške varnosti in njegove besede imajo še posebno težo. Vendar je njegovo delo iskanje pomanjkljivosti. Njegov pogled na varnostne/obrambne mehanizme je pogosto pretirano pesimističen in kritičen. Pred raziskovalci njegovega ranga seveda ni obrambe, tudi zato, ker so v "vsaki kompleksni kodi programski hrošči, vedno in povsod." Z doslednim izvajanjem varnostno-razvojnega cikla pa lahko programerji poskrbijo, da bodo tudi varnostni raziskovalci na poti do večne slave in bogastva krepko garali. To je bilo v preteklosti prej izjema kot pravilo.
Spletna stran projekta SDL:
www.microsoft.com/security/sdl/default.aspx
Vodnik po SDL:
Pogovor z odgovornim
steve_lipner.jpg
Steve Lipner, direktor varnostne strategije v korporaciji Microsoft, je vodja iniciative SDL in odgovorna oseba za projekte, vezane na uvedbo procesa SDL zunaj matične korporacije. Je tudi odgovorna oseba za korporacijsko strategijo preverjanja varnostnih vidikov Microsoftove programske opreme za potrebe državnih ustanov. Steve ima več kot 35 let izkušenj z varnostjo v IT industriji. Skupaj s kolegom Michael Howardom je soavtor knjige "The Security Development Lifecycle (Microsoft Press, 2006).
Microsoft spodbuja tudi druge organizacije in podjetja, naj prevzamejo model SDL in ga uvrstijo v svoj programsko-razvojni proces. Nedavno je SDL začela uporabljati tudi družba Adobe. Lahko morda navedete še druge korporacije, ki so ga že uvedle?
Microsoft se je obvezal, da bo varoval svoje uporabnike in jim omogočil bolj varno in zaupanja vredno izkušnjo računalništva. Eden izmed načinov, kako to doseže, je z izmenjavo izkušenj, znanja in idej s področja varnosti ter varovanja zasebnosti znotraj IT industrije. Z objavo postopkov SDL, ustreznih orodij in tesnega sodelovanja z našimi partnerji iz omrežja SDL Pro Network smo tako spodbudili številne organizacije k uvedbi varnostno-razvojnega cikla. Adobe je le ena izmed številnih družb, ki se je odločila vpeljati model SDL v svoj programsko-razvojni proces. Zelo smo jim hvaležni, ker so to tudi javno priznali. Seveda so tudi druga podjetja in organizacije, ki so to že storili, vendar želijo ostati neimenovani. Njihovo željo seveda spoštujemo, zato ne morem navesti njihovih imen. Lahko pa povem, da so bili naši napotki za uvedbo SDL preneseni več kot 80.000-krat, naša brezplačna orodja pa so že presegla mejo 50.000 prenosov.
Lastniška programska oprema ima torej model SDL, medtem ko je koncept odprtokodne skupnosti "many-eyebals". Ali menite, da bi bil SDL lahko integriran v odprtokodno okolje, konkretno npr. v razvoj linuxnega jedra?
Danes je na profesionalni ravni razvoja programske opreme ključnega pomena zahteva po izboljšani varnosti in zasebnosti. To velja tako za odprto kot tudi zaprto kodo. Mi seveda verjamemo, da je SDL mogoče integrirati tudi v razvoj odprtokodnih programov. V Microsoftu je SDL ključni del razvoja vse kritične programske opreme, torej opreme, ki se bo uporabljala v organizacijah ali podjetjih, v medmrežju, ali pa bo obdelovala zaupne in osebne podatke. Ravno zato menimo, da bi tudi druge družbe, ki se ukvarjajo z razvojem programske opreme, morale začeti uporabljati SDL ali podoben proces za vse programe, ki se bodo uporabljali v prej navedenih kritičnih okoljih - ne glede na to, ali je programska oprema lastniška ali prosto dostopna (op. avtorja: Eugene Teo, Red Hat Security Response Team, nam je zagotovil, da korporacija Red Hat uporablja interno razvito različico procesa SDL, čeprav postopki (še) niso javno objavljeni).
Zgolj zanašanje na načelo "many eyeballs", ne da bi imeli izdelan transparenten in strukturiran razvojni model, brez uporabe namensko razvitih orodij in brez predhodnega izobraževanja na področju varnosti, ne more zagotoviti razvoja dobre programske opreme, ki bi se lahko kosala z današnjimi varnostnimi izzivi. To dokazujejo tudi primerjalne analize, ki so bile narejene z javno dostopnimi podatki, s katerimi razpolaga NIST (www.nist.gov). Ti potrjujejo, da se koncept "many eyeballs" ne more primerjati s SDL, kar zadeva odpravljanje in odkrivanje pomanjkljivosti.
Predvsem pa bi želel poudariti, da je bil model SDL zasnovan kot "neodvisna platforma". Gre za proces, ki je namenjen predvsem razvoju varnejše programske opreme, njegovi temeljni koncepti se torej lahko uporabijo za razvoj programov na vsakršni platformi.
Uporaba SDL je definitivno prispevala k občutnemu zmanjšanju števila pomanjkljivosti. Postavlja se torej vprašanje, zakaj tudi novejše različice operacijskega sistema Windows še vedno vsebujejo nekatere potencialno nevarne storitve, npr. NetBIOS, RPC ..., ki so na slabem glasu že vrsto let. Kje leži ključni razlog, da so te storitve po vseh teh letih še vedno hroščate?
Da bi odkrili vzrok pomanjkljivosti, Microsoftovi razvojni oddelki temeljito pregledajo vsako novo sporočeno ranljivost, pa najsi gre za novo ali "legacy" kodo. Z analiziranjem ranljivosti smo prišli do sklepa, da je z uvedbo procesa SDL število t. i. "preprostih" ranljivosti skoraj izginilo. Večina danes sporočenih ranljivosti je zahtevna, njihovo odkrivanje pa je silno težavno. To je tudi eden izmed ključnih razlogov, zakaj se varnosti raziskovalci pa tudi zlobni napadalci vse bolj osredotočajo na "3rd party" aplikacije. Zadnja leta Microsoft namreč ni več primarna tarča napadalcev.
Vsekakor bomo nadaljevali raziskave in vpeljevanje novih orodij in postopkov, s katerimi bomo lahko še hitreje in bolje odkrivali tudi bolj kompleksne ranljivosti v naših izdelkih.
Zanima me, ali se SDL uporablja tudi pri razvoju jedra. Nekateri strokovnjaki za varnost namreč trdijo, da se v jedru operacijskega sistema Windows še vedno najdejo t. i. "format string" vrzeli (gre za razred pomanjkljivosti, ki je značilen za kodo, pisano v jeziku C/C++, te vrzeli so danes prava redkost). Tudi nedavno odkrita pomanjkljivost CVE-2010-0232, za katero se je izkazalo, da se vleče še iz časov NT 3.5, je dokaz o permanentnih programskih hroščih v samem jedru.
SDL se seveda uporablja tudi pri razvoju jedra. Ko so nekatere pomanjkljivosti odkrite, so na prvi pogled videti nadvse preproste. Vendar, kot sem že omenil, po naših izkušnjah so danes odkrite ranljivosti nadvse kompleksne in obskurne - daleč od t. i. "low hanging fruit" vrzeli.
Primarni namen procesa SDL je zmanjšati število ranljivosti v kodi ter znižati raven učinka pomanjkljivostim, ki so "ubežale". Seveda je popolnoma razumljivo, da je vse vrzeli nemogoče odkriti, vendar se poraja občutek, da so vse ranljivosti, odkrite s strani varnostnih raziskovalcev, kritične.
Naša obvestila o vrednotenju resnosti (severity rating) trenutno ne upoštevajo nekaterih varovalnih mehanizmov, ki so vgrajeni v novejše različice operacijskega sistema Windows. Rezultat tega je, da je ranljivost lahko označena kot kritična tudi v primerih, ko jo je zelo preprosto izkoristiti na Windows 2000/XP, vendar izjemno težko ali pa sploh ne na Window 7. Indeks izkoriščanja (Exploitability Index, technet.microsoft.com/en-us/security/cc998259.aspx) zainteresiranim uporabnikom sicer ponuja dodatne informacije o verjetnosti izkoriščanja ranljivosti. Ravnokar smo v procesu določanja kriterija, ki bi kar najbolje odseval indeks izkoriščanja glede na implementirane varovalne mehanizme. Zavedamo se namreč, da naši uporabniki zahtevajo bolj uravnotežen pregled vrednotenja resnosti.