T Yritysturvallisuuden seminaari. Kappaleet 15-16: Operational Risk Management Assurance Management

Transkriptio

1 T Yritysturvallisuuden seminaari Kappaleet 15-16: Operational Risk Management Assurance Management

2 Operational Risk Management Määritelmä Lakien tuomat vaatimukset Laadulliset ja numeraaliset metodit Standardit Riskien vähentäminen Riskien valvonta Vakuutukset

3 Mitä operational risk management tarkoittaa? Yrityksen tai organisaation toimintaan liittyvät riskit ja niiden hallinta Ei kuitenkaan selvää määritelmää Basel-sopimus määrittelee operaationaalisen riskin seuraavasti: risk of losses resulting from inadequate or failed internal processes, people and systems, or external events

4 Lakien tuomat vaatimukset Pakottavat tiettyjen alojen organisaatioiden toteuttamaan riskien hallintaa Esimerkkeinä aloista lentoliikenne, terveydenhuolto ja pankkitoiminta Esimerkkeinä: FDA 21 CFR Part 11, HIPAA, Basel II Useiden yritysten sisäisen kontrollin pettäminen on ajanut tähän tilanteeseen

5 Riskitason määrittäminen Mahdollista tehdä joko numeraalisilla tai laadullisilla menetelmillä Ongelmana kompleksisuus Jonkin riskin pienentäminen saattaa vaikuttaa toiseen riskiin Riskien erottelu hankalaa

6 Numeraaliset menetelmät Perustuu tilastotieteeseen Riskit, uhkat ja seuraukset saatava esitettyä nuumeraalisesti Lähes poikkeuksetta käytetään rahaa riskin suuruuden arvioimiseen VAR = Kustannukset * P(Uhka) * P(Kontrollien pettäminen)

7 Numeraalisten menetelmien käyttö Lasketaan kuinka usein tappioita tulee vuoden aikana Lasketaan tappioiden suuruksia vuoden aikana Sovitetaan kerätty data Posson- ja lognormal -jakaumaan Yhdistämällä nämä saadaan riskin arvolle (VAR) jakauma (yleensä Poisson-jakauma)

8 Jakauman tulkinta Odotetut tappiot ovat välillä [0, μ+δ] Katastrofaaliset tappiot ovat välillä [μ+4δ, ] Keskiarvoa ja keskihajontaa pienentämällä todennäköisyys katastrofaalisille tappioille pienenee

9 Numeraalisten menetelmien ongelmat Yritetään ennustaa tulevaisuutta menneisyydestä Nopeasti muuttuvassa maailmassa eivät välttämättä vanhat tilastot päde Tiettyjä asioita on vaikea muuttaa rahalliseksi arvoksi Esimerkiksi maine Vaikutuksen suuruus saattaa muuttua aikaisemmista tapahtumista

10 Laadulliset menetelmät Ei ole lukuarvoja käytössä Riskien luokittelu paljon karkeampaa Esimerkiksi liikennevalot Tulokset eivät ole niin tarkkoja kuin numeraalisissa menetelmissä Kaikkia uhkia ei voi arvioida lukuarvoilla

11 Standardit riskien hallintaan Vain yksi kansallinen standardi olemassa AS/NZ 4360:1999 Muut de facto standardeita

12 AS/NZS 4360 Kommunikoi ja konsultoi Kokonaiskuvan muodostaminen Riskien tunnistaminen Riskien analysointi Riskien arviointi Riskien hoitaminen Seuraa & katselmoi

13 Riskinhallinnan hyötyjä Pitää ylimmän johdon pois vankilasta Toimilupien pysyminen Tiedossa vähemmän epämukavia yllätyksiä Yllättäviin tilanteisiin varautuminen parempaa

14 Strategioita riskien hallintaan Riskien vähentäminen Nostaa yleensä kustannuksia Riskin siirtäminen toiselle osapuolelle (vakuutukset) Nykyisen riskitason hyväksyminen

15 Riskien pienentäminen Uhkien vähentäminen Haavoittuvuuksien vähentäminen Vaikutuksen pienentäminen Ongelmien havainnointi ja toimenpiteiden aktivointi tarvittaessa

16 Sopiva riskitaso Uhkan seuraukset Liian suuri altistuminen Liian suuret kustannukset Kustannukset

17 Katselmoinnit Analysoi liiketoiminnan riskit Kirjan esimerkissä käytetty SABSA Business Attributesia Selvitä uhkien realisoitumisen seuraukset liiketoiminnalle Arvioi riskitaso Etsi suurimmat riskit ja pienennä niitä Riskit voi esimerkiksi jakaa kolmeen ryhmään: a, b ja c

18 SABSA Business Attributes

19 Riskien jaottelu Vaikutus liiketoiminnalle Matala Keskitaso Korkea Haavoittuvuus Korkea Keskitaso Matala C B A C B B C C C

20 Vakuutukset Riskit voidaan siirtää toiselle osapuolelle Jatkuvia pieniä kustannuksia (vakuutusmaksut) Ei suurta kertamaksua riskin realisoituessa Huonosti saatavilla vakuutuksia aineettomalle omaisuudelle Suurilla yrityksillä kannattavampaa perustaa oma vakuutusyhtiö

21 Yhteenvetona Riskienhallinta elintärkeätä organisaatioille Osataan varautua ja torjua pahimmat uhkat Tietyillä aloilla laki ja määräykset tuovat tiettyjä velvoitteita Riskin suuruuden ja kustannusten välille löydettävä kompromissi Kaikkia riskejä ei voida koskaan eliminoida

22 Assurance Management Määritelmä Standardit Järjestelmien auditointi Prosessien hallinta järjestelmien ylläpidossa ja ohjelmistokehityksessä Testaus

23 Määritelmä Varmuus, että järjestelmät ja prosessit ovat kunnossa Todella laaja aihe Kirja käsitteli pääasiassa ohjelmistokehityksen ja tietotekniikan näkökulmasta

24 Standardit CobiT Ei käsittele ainoastaan tietoturvaa Käsittelee yleisesti tietojärjestelmien hallintaa ISO/IEC 17799:2000 ja BS7799-2:2002 Painottunut turvallisuuteen

25 CobiT Käsittelee yleisesti tietojärjestelmien hallintaa Vanha ja hyvin testattu järjestelmä Sisältää yleisesti hyväksyttyjä mittareita, prosesseja ja hyväksi koettuja käytäntöjä

26 ISO/IEC 17799:2000 ja BS7799-2:2002 Keskittynyt turvallisuuteen Hyvin korkean abstraktiotason teos Ei ole tekninen standardi Lähinnä ohjeistus johdolle, miten asiat tulisi tehdä Prosessilähtöinen ajattelu turvallisuudelle

27 Sertifioinnit Kummallakin järjestelmällä on koulutetut auditoijat CobiT:ssa tärkein on CISA-koe BS7799:ssa sertifioinnin suorittaa UKAS (UK Accreditation Service) Tarkistetaan, onko vaadittavat asiat kunnossa Poikkeavuuksille tarvitaan selvitys

28 Järjestelmien auditointi Tarkoituksena taata, että järjestelmä täyttää kaikki turvavaatimukset Päivittäiset lokien tarkastukset Säännölliset järjestelmän läpikäynnit Selvitetään, mitä järjestelmästä pitäisi löytyä ja miten sen pitäisi toimia Verrataan siihen, mitä löydettiin ja miten se toimi Osa prosesseista voidaan automatisoida

29 Järjestelmän ja ohjelmistojen kehitys Koko kehityshistoria saatava selville tarvittaessa Säännölliset auditoinnit, joilla varmistetaan määräysten noudattaminen Kehitys- ja tuotantoympäristöt eristettävä toisistaan Käytetään vain organisaation hyväksymiä työkaluja Testaus

30 Ohjelmistojen eheys sekä virukset Ohjelmat asennetaan vain luotetuilta medioilta Kaikki sisään tuleva tieto skannataan virusten varalta Omien tuotteiden koodin auditointi Vain hyväksyttyjen ja validoitujen ohjelmien käyttö Työntekijöiden koulutus

31 Resurssien käyttö Periaatteessa kaikki työhön liittymätön kiellettävä Selkeä ohjeistus työntekijöille, mikä on sallittua Internetin käyttöä mahdollista rajoittaa erilaisilla sensuuriohjelmilla Eivät käytännössä toimi

32 Testaus Testaussuunnitelma luotava Testaushenkilökunnan määrittäminen Kuinka paljon virheitä ja millaisia virheitä hyväksytään Aikataulutus. Mitkä testit suoritetaan ja missä järjestyksessä Testausympäristön selvitys

33 Unit testing Testataan ohjelmiston yksittäisiä osia Monesti tehdään koodaajien toimesta Varmistetaan yksiköiden perustoiminnallisuus Raja-arvotestaus Testataan sallittuja ja kiellettyjä arvoja Yksikön toiminta poikkeustilanteissa Lähes aina white box -testausta

34 Integration testing Moduulien integroimisen jälkeen Testataan moduulien toiminta yhdessä Unit testingissä testattu vain erikseen Virheet voivat kertautua helpommin Aikakriittisissä sovelluksissa suorituskykyä voidaan testata vasta nyt

35 Validation testing Lopullinen testaus ennen asiakkaalle luovuttamista Testausta suorittavat henkilöt eivät saa olla tekemisissä ohjelman kehittäjien kanssa Testataan suunnitteluvaiheessa luotuja määritelmiä ja vaatimuksia vasten

36 User Acceptance Testing Testi tehdään asiakkaiden toimesta Mahdollisesti beta-testausta Käyttäjät testaavat ohjelmaa suunnitellun testiohjelman mukaisesti Kun testi on läpäisty hyväksyttävästi, voidaan järjestelmä siirtää tuotantoon

37 Operational Acceptance Testing Koskee talon ulkopuolelta ostettuja ohjelmistoja Varmistetaan, että ohjelmisto täyttää tarvittavat vaatimukset Ominaisuudet Luotettavuus Turvallisuus Mahdollisesti laki voi tuoda omia vaatimuksia FDA 21 CFR Part 11

38 Penetration testing Ammattilaisten suorittama Voidaan ostaa konsultointina Pyritään murtautumaan järjestelmään tai saada ohjelmisto tekemään ei-toivottuja asioita Halutaan varmistua ohjelmiston/palvelun turvallisuudesta, ennen kuin se laitetaan tuotantoon

39 Ohjelmistojen laadun takaaminen Hyvä ohjelma täyttää seuraavat kriteerit: Vähän bugeja Toimitetaan ajallaan Täyttää vaatimukset ja käyttäjien odotukset On käytettävä ja ylläpidettävä Voidaan käyttää CMMI kypsyysasteita Ohjelmiston koodin laadun tarkkailua Testauksen valvonta

40 Yhteenveto Varmuus, että organisaation prosessit ovat kunnossa Tähän varmuuteen voidaan päästä erilaisilla auditoinneilla ja testeillä Kaikki muutokset ohjelmistoissa ja järjestelmissä tulisi olla jäjitettävissä