You are here: TUTWiki>Tietoturva/Tutkielmat>TyoLuettelo?>2007-2
Ismo Kantola:

Riskien arviointi OCTAVE-menetelmällä

1. Johdanto

Tietotekniikan hyväksikäyttö on tuonut hyötyjen lisäksi myös riskejä organisaatioille. Useimmissa organisaatioissa tietotekniikkaa käytetään ylimmästä johdosta aina työntekijöihin saakka varsin suuren osan työajasta. Entä jos tietotekniikka ei joku päivä toimisikaan? Varsin mielenkiintoisia työntekijöiden tunteenpurkauksia olisi luvassa, jos organisaation tietotekniikasta vastaava joutuisi kertomaan henkilöstölle, että tietotekniikka ei toimi muutamaan päivään tai jopa viikkoon.

Tietoteknisten riskien arvioinnilla varmistetaan, että yritys on tietoinen joko tietoisesti tai tiedostamatta ottamistaan riskeistä. Tähän on saatavilla useita sekä kaupallisia, että ilmaisia menetelmiä, joilla arvioinnin toteuttamista voi helpottaa. Vasta kun yritys on tunnistanut riskinsä, se voi hallita niitä erilaisin riskienhallinnan keinoin.

Tutkielmassa esitellään ja arvioidaan alan kirjallisuuden perusteella yhtä Internetistä ilmaiseksi saatavaa riskien arvioinnin menetelmää nimeltään OCTAVE. Se on OCTAVE-sarjan ensimmäinen versio, josta nykyisellään on periytetty kaksi hieman karsittua versiota.

Tutkielma on jaettu siten, että kappaleessa 2 kerrotaan yleistä tietoa riskienhallinnasta jaettuna kahteen päävaiheeseen: riskien arvioimiseen ja hallitsemiseen. Sen jälkeen kerrotaan hieman OCTAVE-menelmän taustasta. Kappaleessa 4 käydään lyhyesti läpi menetelmän varsinainen ydin eli riskien arvioinnin vaiheet. Lopussa arvioin menetelmää ja sen soveltuvuutta suomalaisiin yrityksiin.

2. Riskienhallinta

Ennen kuin tarkastellaan riskienhallintaa lähemmin, on syytä kiinnittää huomiota riskin määritelmään. Riski liittyy suurelta osin epävarmuuteen ja riskin toteutumisella on aina vähintään yksi seuraus, mutta usein niitä on enemmän. Seuraukset voivat olla joko myönteisiä tai kielteisiä. Riskille määritellään usein suuruus arvioimalla riskin toteutumisen todennäköisyys sekä toteutumisen seuraukset. [12] Riskejä voidaan jakaa eri luokkiin, kuten poliittisiin, ympäristöön liittyviin, taloudellisiin, teknisiin, inhimillisiin ja laillisiin riskeihin sekä suunnittelu-, projekti- ja turvallisuusriskeihin [13]. Tietotekniset riskit voidaan nähdä osana teknisiä riskejä mutta toisaalta suurin osa näistäkin riskeistä aiheutuu yleensä ihmisten toiminnasta, minkä vuoksi niihin liittyy myös inhimillisiä riskejä.

Riskienhallinta tarkoittaa VAHTI-tietoturvakäsitteistön mukaan järjestelmällistä toimintaa riskien rajoittamiseksi siten, että ne ovat optimisuhteessa riskien rajoittamisen kustannuksiin samalla, kun organisaation toiminnalle asetetut tavoitteet voidaan saavuttaa. Riskienhallinnan vaiheita ovat riskianalyysi, riskienhallintamenetelmän valinta, päätös riskistrategiasta sekä riskienhallinnan organisointi. [1, s. 35-36.] Edellä mainitut prosessit voidaan jakaa kahteen päävaiheeseen, jotka ovat riskien arviointi ja riskien hallitseminen. Näitä kahta prosessia on esitelty tarkemmin seuraavissa alaluvuissa.

2.1 Riskien arviointi

Riskien arvioiminen tai riskianalyysi (engl. risk assessment, risk analysis) on prosessi, jossa tunnistetaan vaarat ja arvioidaan riskiskenaarioiden todennäköisyys ja seuraukset. Riskien arvioimisessa vastataan kolmeen kysymykseen, jotka ovat:

  1. Mikä voi mennä vikaan?
  2. Mikä on todennäköisyys sille, että riskiskenaario toteutuu?
  3. Mitkä ovat riskiskenaarion seuraukset? [12]

Riskianalyysi alkaa analyysin tavoitteiden sekä tarkasteltavan systeemin määrittelemisellä eli kohteen rajauksella. Tämän jälkeen analysoidaan vaarat, jotka voivat vaikuttaa kohteeseen ja tunnistetaan niiden lähteet, jotka voivat olla sisäisiä tai ulkoisia. Lisäksi mahdolliset riskiskenaariot kuvataan mahdollisimman tarkasti. Kun vaarat on tunnistettu, on kerättävä dataa, jonka perusteella tehdään laadullinen ja/tai määrällinen riskianalyysi. [12, 13] Laadullisessa riskianalyysissa muodostetaan kattava lista vaaroista ja kuvataan riskin toteutumisen todennäköiset seuraukset. Määrällisessä riskianalyysissa puolestaan analysoidaan yleensä tilastollista dataa käyttämällä jotakin ohjelmaa. [13] Viimeinen vaihe riskianalyysissa on riskiperustainen päätöksenteko, jossa määritellään, mitkä riskit tarvitsevat toimenpiteitä. Tätä varten riskejä yleensä priorisoidaan ja luokitellaan. [12, 13]

Valtiovarainministeriön mukaan riskien arviointi on hyvin tärkeä osa organisaation riskienhallintaa ja myös keskeinen osa jatkuvaa tietoturvatyötä [3, s. 1]. COBIT:n mukaan riskien arvioinnin hyötynä liiketoiminnalle on tietoteknisten riskien analysointi ja tiedottaminen siitä, millaisia uhkia ja vaikutuksia riskeillä on liiketoimintaprosesseihin ja yrityksen tavoitteisiin [4]. Myös Koller korostaa, että yksi suurimmista riskianalyysin hyödyistä on juurikin se, että se lisää organisaation yleistä tietoisuutta riskeistä ja kaikesta niihin liittyvästä [14]. Ilman riskien arviointia yritys onkin kuin entisaikojen laiva ilman karttaa ja siten suunnitelmaa siitä, miten matkan varrella olevat karit vältettäisiin. Kuuselan et al. mukaan sana riski tulee nimittäin kreikkalaisperäisestä sanasta 'rhi zikon', joka lienee tarkoittanut karia, ja riskien hallinta kansanlatinan 'risicare'–sanasta, joka tarkoittaa karin kiertämistä [5]. Kun riskianalyysi on tehty, on määriteltävä, mitä riskeille tehdään ja toteutettava suunnitellut toimenpiteet käytännössä. Tätä käsitellään tarkemmin seuraavassa alaluvussa.

2.2 Riskien hallitseminen

Kun riskianalyysiin lisätään riskien hallitseminen, voidaan puhua riskienhallinnasta. Riskien hallitsemisessa suunnitellaan riskien vastatoimenpiteet ja toteutetaan toimenpiteitä turvallisuuden parantamiseksi riskianalyysin tulosten perusteella. [12] Riskien hallitsemiseksi käytetään yleensä jotakin seuraavista strategioista:

  • riskin välttäminen
  • riskin pienentäminen
  • riskin siirtäminen
  • riskin hyväksyminen [13].

Riskin välttämisessä uhka poistetaan kokonaan. Tämä tehdään joko poistamalla riskin lähde tai välttämällä kohteita, jotka ovat alttiita kyseiselle riskille. Riskiä voidaan pienentää joko pienentämällä riskiskenaarion todennäköisyyttä ja/tai seurauksia. Riskin siirtäminen ei poista tai pienennä riskiä, vaan muuttaa riskin kohteen, jolloin riskiskenaarion seuraukset eivät kohdistu omaan organisaatioon, vaan riskin ottaa jokin sidosryhmä. [13] Esimerkiksi ottamalla vakuutus riskin varalle, riski siirretään vakuutusyhtiölle. Todellisuudessa riskiä ei pakolla kokonaan voida siirtää toiselle taholle, vaan voi olla järkevämpää puhua riskin jakamisesta. Resurssien rajallisuuden vuoksi on riskien hallitsemisessa usein määriteltävä, mitkä riskit voidaan hyväksyä [12]. Esimerkiksi riskien suuruuksien määrittelyn avulla voidaan toimenpiteet kohdentaa kaikista vakavimpeihin riskeihin ja liiketoiminnalle merkityksettömämmät riskit hyväksyä, jos toimenpiteet niiden hallitsemiselle vaatisivat kohtuuttomasti resursseja.

Riskienhallinnasta saadaan monenlaista hyötyä. Ensinnäkin liiketoiminnan haasteet selvenevät ja niitä voidaan ymmärtää paremmin. Toisekseen datan perusteellisen analyysin avulla voidaan tukea päätöksentekoa. Riskienhallinta tulisi nähdä lineaarisen prosessin sijasta jatkuvana syklinä, jossa riskien tunnistamista, analysointia, hallitsemista ja raportointia suoritetaan alituisesti. Riskienhallinnassa onnistumiseen ei ole olemassa mitään valmista ratkaisua, vaan se vaatii huolellista pohdintaa, vaivannäköä ja yksilöllisten avainasioiden tunnistamista. [13]

3. OCTAVE-menetelmä

OCTAVE on Software Engineering Institute:ssa (SEI) kehitetty ja julkaistu tietoturvariskien arviointimenetelmä [6, s. 1]. SEI on osa Carnegie Mellon yliopistoa. OCTAVE tulee englannin kielen sanoista Operationally Critical Threat, Asset, and Vulnerability Evaluation [7], joka vapaasti käännettynä tarkoittaa operatiivisesti kriittisten uhkien, suojattavien kohteiden ja haavoittuvuuksien arviointimenetelmää.

Ensimmäisen version OCTAVEsta SEI julkaisi Carnegie Mellon yliopistossa vuonna 1999. SEI kehitti yhdessä Telemedicine and Advanced Technology Research Centerin kanssa menetelmän uusimman version, versio 2.0:n, Yhdysvaltain puolustusministeriölle, joka halusi ottaa sen käyttöön täyttääkseen Health Insurance Portability and Accountability Act (HIPAA) -lain velvoitteet. Menetelmä julkaistiin syyskuussa 2001. Näiden jälkeen julkaistiin OCTAVE Criteria joulukuussa 2001. [8, s. 4; 10, s. 2.] Se määritteli yleiset kriteerit OCTAVE-menetelmille [9, s. 2].

Alkuperäinen OCTAVE-metodi suunniteltiin organisaatioille, joissa on henkilöstöä yli 300 henkilöä ja merkittävät hierarkiat. Se suoritetaan työryhmissä, joihin osallistuu työntekijöitä jokaiselta hierarkiaportaalta. Vuonna 2003 esiteltiin SEI:n TIDE-ohjelman (Technology Insertion, Demonstration and Evaluation) tukema uusi versio OCTAVE-S. OCTAVE-S:n tarkoitus oli skaalata alkuperäistä OCTAVE-metodia toimimaan pienemmissäkin alle sadan työntekijän yrityksissä. OCTAVE-S koostuu kolmesta vaiheesta samaan tapaan kuin OCTAVE, mutta sen suorittaa pienempi analysointitiimi, jonka oletetaan tuntevan kaikki osa-alueet, eikä OCTAVEn kaltaista tietojenkeruuta suoriteta (tästä selvennystä myöhempänä). Tietoturvamalleja on lisättynä OCTAVE-S:n työkirjoihin ja oppaisiin, jotka tarjoavat kattavan tiedon myös niille osallistujille, joiden lähtöarvoiset taidot eivät ole parhaat mahdolliset. OCTAVE-S:stä on lisäksi karsittu hieman yrityksen informaatioinfrastruktuurin analysointia. Tuorein malli OCTAVE Allegro koostuu neljästä vaiheesta ja yhteensä kahdeksasta prosessista. Allegron tarkoitus on edesauttaa riskien arvioinnin tuloksia ilman kattavaa riskien arviointitietoutta. Tämän Allegro tekee keskittymällä siihen, kuinka tietoresursseja käytetään, talletetaan, kuljetetaan ja käsitellään, sekä kuinka ne altistuvat uhkille. [10,11] OCTAVE-S:n ja Allegron tarkempi tutkiminen jätetään tämän tutkielman ulkopuolelle.

OCTAVE mainostaa olevansa itse-suuntautuva (engl. self-directed), mikä tarkoittaa sitä, että organisaation ihmiset ottavat itse vastuun tietoturvan arvioinnista [6, s. 6]. Menetelmän mainitaan eroavan perinteisistä lyhyen tähtäimen teknologiasuuntautuneista arviointimenetelmistä ja olevan enemmänkin organisationaalisiin riskeihin ja strategisiin osa-alueisiin keskittyvä menetelmä. Lisäksi räätälöitävyys mainitaan yhtenä hyvänä puolena. [6, s. 3.]

4. OCTAVEn riskien arvioinnin vaiheet

Riskien arviointi menetelmässä koostuu kolmesta vaiheesta, jotka on jaettu kahdeksaan prosessiin [7, vol 1, s. I9-I10]. Vaiheet ovat:

  • Vaihe 1: Tee suojattava kohde –pohjaiset uhkaprofiilit (engl. Build Asset-Based Threat Profiles) [7, vol 1, s. I9-I10]. Tästä käytetään myös nimitystä: Organisationaalinen näkökulma (engl. Organizational view) [6, s. 5].
  • Vaihe 2: Havaitse infrastruktuurin haavoittuvuudet (engl. Identify Infrastructure Vulnerabilities) [7, vol 1, s. I9-I10]. Tästä käytetään myös nimitystä: Teknologinen näkökulma (engl. Technological View) [6, s. 5].
  • Vaihe 3: Suunnitelmien laadinta (engl. Develop Security Strategy and Plan) [7, vol 1, s. I9-I10]. Palaan luvun 4.4 lopussa tarkemmin siihen, miksi päädyin tähän suomennokseen.

Varsinaisten kolmen vaiheen lisäksi OCTAVEsta löytyy kaksi pienempää vaihetta nimeltään Esivalmistelu (engl. Preparation) ja Arvioinnin jälkeen (engl. After Evaluation), joissa käydään läpi nimensäkin mukaisesti mitä tulisi tehdä ennen ja jälkeen varsinaisten vaiheiden [7, vol 1, s. I9-I10]. Kuva 1 havainnollistaa yksinkertaisesti OCTAVEn vaiheita. Vaiheet 1-3 toteutetaan analyysitiimin vetäminä puolen päivän - päivän pituisina työpajoina [7, vol 1, s. I8; 7, vol 2, s. PG18-20]. Seuraavaksi esittelen näiden viiden vaiheen sisällöt lyhyesti kronologisessa järjestyksessä.

OCTAVE_vaiheet.gif
Kuva 1. Riskien arvioinnin vaiheet OCTAVEssa [mukaillen 6, s.5].

4.1 Esivalmistelu

Ennen varsinaisia riskien arvioinnin vaiheita tulee tehdä esivalmisteluja. Näihin sisältyvät ylimmän johdon sitouttaminen, analyysiryhmän nimeäminen ja tarpeen vaatiessa myös kouluttaminen menetelmään, aikataulun asettaminen, rajausten määrittely ja eri vaiheiden osallistujien valinta sekä heidän perehdyttäminen [7, vol 2].

Esivalmistelu, kuten muutkin riskien arvioinnin vaiheet, on hyvin kuvattu OCTAVEssa. Siinä on selitetty varsin yksityiskohtaisesti mistä vaihe koostuu, mitä vaiheessa tehdään, mitä taitoja ja tietoja ne edellyttävät ja mitkä ehdot tulee täyttyä, jotta vaihe on tehty.

4.2 Vaihe 1: Organisationaalinen näkökulma

Tämä vaihe on jaettu neljään prosessiin [7, vol 1, s. I9-I10]:

  • Prosessi 1: Tunnista ylimmän johdon tietämys (engl. Identify Senior Management Knowledge)
  • Prosessi 2: Tunnista operatiivisen johdon tietämys (engl. Identify Operational Area Management Knowledge)
  • Prosessi 3: Tunnista henkilöstön tietämys (engl. Identify Staff Knowledge)
  • Prosessi 4: Luo uhkaprofiilit (engl. Create Threat Profiles)

Prosesseissa 1-3 analyysitiimi kerää organisaation edustajilta tiedot suojattavista kohteista, niiden nykyisistä suojauskäytännöistä, suojattaviin kohteisiin liittyvistä huolen aiheista ja niiden tietoturvavaatimuksista sekä organisaation haavoittuvuuksista. Jokaisen prosessin tulokset myös esitellään prosessissa mukana olleille organisaation edustajille. Prosessissa 4 analyysitiimi valitsee edellisten prosessien tulosten pohjalta kriittiset suojattavat kohteet ja rakentaa niille uhkaprofiilit. [7, vol 3-6.]

4.3 Vaihe 2: Teknologinen näkökulma

Tässä vaiheessa katsotaan organisaation teknologisia haavoittuvuuksia keskittyen vaiheessa 1 tunnistettuihin kriittisiin suojattaviin kohteisiin [7, vol 7, s. iv]. Vaihe 2 koostuu kahdesta prosessista [7, vol 1, s. I9-I10]:

  • Prosessi 5: Tunnista tärkeät komponentit (engl. Identify Key Components)
  • Prosessi 6: Arvioi valittuja komponentteja (engl. Evaluate Selected Components)

Prosessissa 5 analyysitiimi tunnistaa IT-asiantuntijoiden avustamana teknisestä infrastruktuurista ne tärkeät komponentit, jotka ovat keskeisiä kriittisille suojattaville kohteille. Prosessissa 6 näitä tärkeitä komponentteja vastaan suoritetaan etukäteen sovitulla ajan hetkellä hyökkäyksiä automatisoiduilla työkaluilla, jotta tunnistettaisiin tekniset haavoittuvuudet niissä. Analyysitiimi arvioi yhdessä IT-asiantuntijoiden kanssa työkalujen tuottamia tuloksia ja kirjaa havaitut haavoittuvuudet komponenteissa. [7, Vol 7-8.]

Menetelmässä teknologinen näkökulma on mielestäni ehkä turhan tietoliikenne- ja verkkopalveluiden ohjelmistoturvallisuuteen keskittyvä. Näin esimerkiksi VAHTI-oktetin kuusi kahdeksasta tietoturvallisuuden osa-alueista saattaa helposti jäädä tarkastelematta.

4.4 Vaihe 3: Suunnitelmien laadinta

Kolmannen vaiheen muodostavat prosessit [7, vol 1, s. I9-I10]:

  • Prosessi 7: Riskianalyysin laadinta (engl. Conduct Risk Analysis)
  • Prosessi 8: Suojaussuunnitelman laadinta (engl. Develop Protection Strategy)

Prosessin 7 aikana käydään läpi edellisten prosessien 1-6 tulokset, analysoidaan ne ja tehdään riskiprofiili jokaiselle suojattavalle kohteelle. Prosessin 8 alussa analyysitiimi käyttää riski-profiileja, organisaation nykyisiä käytäntöjä ja tunnettuja haavoittuvuuksia sekä havaittuja teknologisia haavoittuvuuksia luodakseen organisaatiolaajuisen suojaussuunnitelman kriittisille suojattaville kohteille. Jokaiselle kriittiselle suojattavalle kohteelle tehdään myös riskien pienentämissuunnitelmat. Lisäksi tehdään lyhyen ja pitkän tähtäimen toimenpidesuunnitelma. Prosessin 8 lopussa suojaussuunnitelma, riskien pienentämissuunnitelmat ja toimenpidesuunnitelmat esitellään ja päätetään ylimmässä johdossa. [7, vol 9-11.]

Koska vaiheessa 3 ei siis varsinaisesti laadita tietoturvastrategiaa tai -suunnitelmaa, suomensin sen suunnitelmien laadinnaksi. Näin suomennos kuvaa mielestäni paremmin vaiheen 3 todellista sisältöä.

4.5 Arvioinnin jälkeen

Arvioinnin jälkeen -vaihe sisältää lähinnä vaiheessa 3 tehtyjen suunnitelmien toteutumisen seurantaa. Tätä varten menetelmässä on valmis räätälöitävissä oleva tarkistuslista. Tarkistuslistalla on ehdotukset siitä, mitä tulisi olla tehtynä ensimmäisen viikon, ensimmäisen kuukauden, kolmen kuukauden ja kuuden kuukauden aikana. [7, vol 13.] OCTAVE on selvästi riskien arviointiin tarkoitettu menetelmä eikä jatkuva prosessi eikä siten myöskään riskienhallintamenetelmä. OCTAVElla on nimittäin projektin kaltaisesti selvä alku ja loppu. OCTAVEn vaiheet ISO-17799 riskien hallinnan ympyrästä kattavat vain identify ja analyse -prosessit sekä plan-prosessin osittain. [8, s. 9.]

5. Soveltuvuus suomalaisiin yrityksiin

OCTAVE–menetelmä antaa mielestäni hyvin systemaattisen ja koherentin tavan toteuttaa organisaation tietoteknisten riskien arviointi. Tätä kuvastaa sekä menetelmän laajuus (sivumäärä liitteineen yli 1000 sivua) että tietynlainen pakettimaisuus (menetelmä sisältää muun muassa valmiit powerpoint –kalvot eri arvioinnin vaiheisiin). OCTAVE on myös hyvin tarkasti määritelty prosessi, jossa on selkeät vaiheet. Kaikki riskien arvioinnin vaiheet prosesseineen on kuvattu varsin yksityiskohtaisesti: mistä osista vaihe tai prosessi koostuu, mitä niissä pitäisi tehdä, kauanko ne ajallisesti kestävät, mitä taitoja ja tietoja ne edellyttävät ja mitkä ehdot tulee täyttyä, jotta vaihe tai prosessi on valmis.

Menetelmän suuri koko voidaan toisaalta kokea myös sen huonona puolena, sillä menetelmän hyvä osaaminen on edellytys menetelmän hyödyntämiselle ja ison yrityksen tietoteknisten riskien arvioijalla ei ole välttämättä aikaa perehtyä menetelmään. Pienehkönä puutteena voisin pitää myös menetelmän teknologista näkökulmaa, sillä se ei ole mielestäni kovin laaja-alainen. Joskin menetelmää voi tarpeen mukaan räätälöidä ja täydentää. Menetelmän englanninkielisyyden saattaa osa yrityksistä kokea ongelmaksi, mutta ainakin kansainväliset yritykset kokevat tämän varmasti pelkkänä plussana.

Kaiken kaikkiaan menetelmän hyvät puolet vievät mielestäni voiton sen pienistä puutteista ja menetelmää voi hyvin suositella isoille yrityksille. Varmasti se on ainakin tutustumisen arvoinen vaihtoehto riskien arviointiin.

Lähteet

  • [1] Valtiohallinnon tietoturvakäsitteistö. 2003. Valtiohallinnon tietoturvallisuuden johtoryhmä 4/2003. ISBN 9518044048. 106 s. Saatavilla: http://www.vm.fi/vahti/
  • [2] Miettinen, J. 1999. Tietoturvallisuuden johtaminen - näin suojaat yrityksesi toiminnan. Gummerus Kirjapaino Oy. ISBN 9521402296. 280 s.
  • [3] Valtiohallinnon tietoturvallisuuden johtoryhmä VAHTI. 2003. Ohje riskien arvioinnista tietoturvallisuuden edistämiseksi valtionhallinnossa (VAHTI 7/2003). Edita Prima Oy. 82 s. Saatavilla: http://www.vm.fi/vahti/
  • [4] COBIT v4.0. 2005. It Governance Institute. ISBN 1933284374. 207 s. Saatavilla: www.isaca.org/cobit/
  • [5] Veriö, T. 1979. Riskienhallinta ja vahingontorjunta. Suomen palontorjuntaliitto. ISBN: 9519167188. 208 s.
  • [6] Alberts, C., Dorofee, A., Stevens, J., Woody, C. 2003. Introduction to the OCTAVE Approach. Pittsburgh, PA: Carnegie Mellon Software Engineering Institute. 37 s. Saatavilla: http://www.cert.org/octave/
  • [7] Alberts, C., Dorofee, A. 2001. OCTAVE Method Implementation Guide v2.0. Software Engineering Institute, Carnegie Mellon University. 863 s. + liitt. 188 s. Saatavilla: http://www.cert.org/octave/
  • [8] Woody, C., Coleman, J., Fancher, M., Myers, C., Young, L. 2006. Applying OCTAVE: Practioners Report. Software Engineering Institute, Carnegie Mellon University. 51 s. Saatavilla: http://www.cert.org/octave/
  • [9] Alberts, C., Dorofee, A. 2001. OCTAVE Criteria, Version 2.0. Software Engineering Institute, Carnegie Mellon University. 143 s. Saatavilla: http://www.cert.org/octave/
  • [10] Caralli, R., Stevens, J., Young, L., Wilson, W. 2007. Introducing OCTAVE Allegro: Improving the Information Security Risk Assessment Process. Software Engineering Institute, Carnegie Mellon University. 154 s. Saatavilla: http://www.cert.org/octave/
  • [11] CERT Research Annual Report 2008, Saatavilla: http://www.cert.org/research/2008research-report.pdf
  • [12] Ayyub, B. M. 2003. Risk Analysis in Engineering and Economics. Chapman and Hall.
  • [13] Merna, T. & Al-Thani, F. 2008. Corporate Risk Management, Second Edition. Hoboken, NJ, USA: Wiley.
  • [14] Koller, G. 2005. Risk Assessment and Decision Making in Business and Industry - A Practical Guide, Second Edition. Chapman and Hall.

-- JarkkoSillanpaeae? - 23 Sep 2009
Topic attachments
I Attachment Action Size Date Who Comment
OCTAVE_vaiheet.gifgif OCTAVE_vaiheet.gif manage 29.0 K 24 Sep 2009 - 00:36 JarkkoSillanpaeae Kuva 1. Riskien arvioinnin vaiheet OCTAVEssa [mukaillen 6, s.5].
Print version |  PDF  | History: r5 < r4 < r3 < r2 | 
Topic revision: r5 - 20 Mar 2014 - 20:16:26 - JennaLehtimaki?
 

TUTWiki

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TUTWiki? Send feedback