T-110.5690 Yritysturvallisuuden seminaari Kappaleet 15-16: Operational Risk Management Assurance Management
Operational Risk Management Määritelmä Lakien tuomat vaatimukset Laadulliset ja numeraaliset metodit Standardit Riskien vähentäminen Riskien valvonta Vakuutukset
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
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
Riskitason määrittäminen Mahdollista tehdä joko numeraalisilla tai laadullisilla menetelmillä Ongelmana kompleksisuus Jonkin riskin pienentäminen saattaa vaikuttaa toiseen riskiin Riskien erottelu hankalaa
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)
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)
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
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
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
Standardit riskien hallintaan Vain yksi kansallinen standardi olemassa AS/NZ 4360:1999 Muut de facto standardeita
AS/NZS 4360 Kommunikoi ja konsultoi Kokonaiskuvan muodostaminen Riskien tunnistaminen Riskien analysointi Riskien arviointi Riskien hoitaminen Seuraa & katselmoi
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
Strategioita riskien hallintaan Riskien vähentäminen Nostaa yleensä kustannuksia Riskin siirtäminen toiselle osapuolelle (vakuutukset) Nykyisen riskitason hyväksyminen
Riskien pienentäminen Uhkien vähentäminen Haavoittuvuuksien vähentäminen Vaikutuksen pienentäminen Ongelmien havainnointi ja toimenpiteiden aktivointi tarvittaessa
Sopiva riskitaso Uhkan seuraukset Liian suuri altistuminen Liian suuret kustannukset Kustannukset
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
SABSA Business Attributes
Riskien jaottelu Vaikutus liiketoiminnalle Matala Keskitaso Korkea Haavoittuvuus Korkea Keskitaso Matala C B A C B B C C C
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ö
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
Assurance Management Määritelmä Standardit Järjestelmien auditointi Prosessien hallinta järjestelmien ylläpidossa ja ohjelmistokehityksessä Testaus
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
Standardit CobiT Ei käsittele ainoastaan tietoturvaa Käsittelee yleisesti tietojärjestelmien hallintaa ISO/IEC 17799:2000 ja BS7799-2:2002 Painottunut turvallisuuteen
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ä
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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ä