Standardi Yhteenveto vaikutuksista Päävaikutustapa ISO/IEC
15408 (Common Criteria)
Yhteinen perusta IT-tuotteiden tietoturvan yh-teismitalliseen ja riippumattomaan evaluoimiseen ja varmistamiseen.
Voidaan soveltaa esim. vaatimalla tietyn EAL-tason tuotteita suojavyöhykkeittäin systemaat-tinen vaatimustasomäärittely.
Arvioinnit/
kriteerit
DHS CSSP Ymmärretään uhkia ja haavoittuvuuksia käytännössä.
Haavoittuvuuksien vaikutus voidaan minimoida.
Yksityiskohtainen suojausten käyttöönoton suun-nittelu paranee.
Käytännöt
ISA99 Antaa perustiedot tietoturvamekanismien sovel-tamisesta teollisuusautomaatioon.
Soveltuvat käytännöt ja ratkaisut voidaan yrityksen tarkemmassa analyysissä räätälöidä, jolloin rele-vantit suojaukset saadaan helpommin käyttöön.
Mallit/
esimerkit
ISO/IEC 27000 -sarja
Yrityksen merkittävimmät riskit saadaan arvioi-tua ja kontrolloiarvioi-tua tietoturvanhallintajärjestel-mässä.
Laajan alueen kattavia tietoturvavaatimuksia ja käytäntöjä voidaan valita suojaamaan toimintaa soveltuvin osin.
Normikäytännöt parantavat operatiivista tietoturvaa.
Käytännöt
NIST 800 -sarja
Ymmärretään erityyppisten järjestelmien (myös ICS) haavoittuvuudet, soveltuvat verkkoarkkiteh-tuurit, sekä spesifit tekniset tietoturvakontrollit, jolloin tietoturvan hallinta saadaan organisoitua tehokkaasti.
Hankintatoimi tehostuu yhtenevien tietoturvavaa-timusten ansiosta.
Ymmärretään pääasiat relevanteista uhkista ja ratkaisuista.
Mallit/
esimerkit
AGA Std 12 Auttaa yritystä kuvaamaan tietoturvakäytäntöjen perusteet.
Käytännöt
Tietoturvatavoitteet ja käytäntöjen määrittely auttavat arvioimaan riskitoteumaa ja kehittämään tietoturvatoimintaa.
API Std 1164
Auttaa yritystä kuvaamaan tietoturvakäytäntöjen perusteet.
Operaattorin ymmärtäessä toimintojen sekä jär-jestelmien haavoittuvuudet ja riskit, voidaan suojaavat toimenpiteet kohdistaa oikein.
Käytännöt
NERC CIP Yhteneväiset vaatimukset operatiivisten tietotur-vatoimintojen määrittelyyn tuovat synergiaetuja, mm. laitevalmistajille esitetään yhteneviä tieto-turvavaatimuksia. Tämä antaa mahdollisuuden investoida laadukkaisiin toteutuksiin.
Arvioinnit/
kriteerit
IEEE 1686 Kenttälaitteille saadaan määriteltyä yhteneväiset tietoturvaominaisuudet.
Antaa mallin NERCin vaatimusten mukaisesta laitesuojasta.
Mallit/
esimerkit
2.6 Johtopäätöksiä standardeista
Teollisuusautomaation tarpeisiin löytyy lukuisia erilaisia (mainiosti tai heikom-min soveltuvia) tietoturvastandardeja ja parhaita käytäntöjä. Käytännössä on-gelmana onkin tunnistaa, valita ja räätälöidä näistä soveltuvimmat osat kunkin suomalaisen alan yrityksen erityistarpeisiin. Yritysten tietoturvavaatimukset ja -käytännöt eivät koskaan voine olla täysin yhteneviä johtuen ajan kuluessa toi-mijoille asetetuista erilaisista vaatimuksista tai mahdollisista eroista toiminta-ympäristöjen yleisessä kehityksessä.
Tässä luvussa on esitelty joukko erittäin potentiaalisia ohjeistoja sekä muun muassa vaatimus- ja tarkastuslistoja, joita voitaisiin käyttää hyväksi parhaiden käytäntöjen suomenkielisten kuvausten laadinnassa. On kuitenkin syytä koros-taa, että soveltuvimman ”tietoturvareferenssin” kiinnittäminen menestyksellises-ti kullekin menestyksellises-tietoturvan hallinnan osa-alueelle edellyttää relevantmenestyksellises-tien yritysten ja laitosten aktiivista osallistumista määrittelytyöhön. Yritysevaluaatiot ja laajat asiantuntijakatselmoinnit Suomessa ovatkin tärkeitä keinoja asian edistämiseen käytännössä. Pelkkä teoreettinen tarkastelu ei vielä riitä erilaisten näkemysten huomioonottamiseksi laadittaessa kuvauksia eri tarkoituksiin.
3. Automaatiojärjestelmän tietoturvan arviointi
Tässä luvussa on kuvattu yleisiä, parhaiten soveltuvia ratkaisumalleja automaa-tiojärjestelmän tietoturvan arviointiin. Tavoitteen saavuttamiseksi on vertailtu useiden erilaisten arviointimallien ja -ratkaisujen käyttökelpoisuutta. Erityisesti tässä luvussa kuvataan erityyppisiä tietoturvatavoitteita ja -vaatimuksia, joita voidaan (soveltuvin osin) käyttää järjestelmän tietoturvan evaluoimiseen yleis-luontoisissa, teollisuusautomaatioon liittyvissä tapauksissa.
3.1 Yleistä
Erilaiset automaatiojärjestelmät ja niiden yksittäiset komponentit vaativat eri-tyiskäsittelyä, kun ajatellaan operatiiviseen toimintaan otettavan tieto-, kommu-nikointi- tai ohjausjärjestelmien tietoturvan arvioimista. ICS (Industrial Control Systems) -alueen järjestelmien tietoturva-arvioinnissa on otettava huomioon useita erityispiirteitä, jotka voivat olla jopa ristiriidassa toistensa kanssa. Tällöin niiden välille on pyrittävä löytämään tasapaino.
Ensimmäinen ulottuvuus on, että tuotantoa ohjaavien ja seuraavien järjestel-mien käyttövarmuus ja oikea toiminta on varmistettava ensisijaisesti. Sopivan tasoisten tietoturvaominaisuuksien tulee olla käytössä, mutta ne eivät saa aiheut-taa häiriöitä, jotka voisivat heikentää käyttövarmuutta.
Toinen ulottuvuus on erilaiset arviointimenetelmät ja niiden käyttö. Suoma-laistenkin toimijoiden käyttöön on yleisesti saatavilla erilaisia avoimia ja kaupal-lisia ohjelmistotyökaluja, jotka määrittävät tietoturvahaavoittuvuuksien sekä käyttöjärjestelmien ja erilaisten sovellusten konfiguraatioiden turvallisuutta.
Niiden soveltuvuutta ICS-alueella toimivaan organisaatioon tai yritykseen voi kuitenkin olla vaikea arvioida. Tietty menetelmä tai työkalu voi esimerkiksi listata käyttäjälle kuusisataa erilaista järjestelmän tietoturvaan liittyvää
varoitus-ta, mutta käyttäjän voi olla hankala soveltaa tulosta järjestelmän kehittämiseksi tai sen arvioimiseksi, onko järjestelmän turvallisuus riittävän hyvä. Tällöin eri yhteisöissä tarvitaan melko tarkkaa yhteistä määrittelyä siitä, miten tiettyä tieto-turvan varmistamisen menetelmää tai työkalua sovelletaan jollakin käyttöalueel-la. Työkalulle on määriteltävä esimerkiksi erityisiä profiileja, joissa valmiit testi-tapaukset testaavat vaikkapa automaatiosovelluksen käyttämien käyttöjärjestel-mä- ja sovellusominaisuuksien sallitut versiot ja asetukset.
3.2 Evaluaation tavoitteet ja vaiheet
Tietoturvaevaluaatioon tarvitaan taustatiedoiksi käyttöönotettavan järjestelmän tai tuotteen tietoturvatavoitteet, vaatimukset, asennuspisteessä vallitseva tieto-turvapolitiikka ym. Näiden määrittelemisessä operoiva yritys on voinut käyttää apuna valmiita skelettejä (esim. maksullista standardia API Std 1164 [API-1164], sen Annex B: SCADA-järjestelmän tietoturvasuunnitelma). On välttämä-töntä tuoda esiin olemassa olevat tietoturvan taustavaatimukset. Jos määrittely on kesken, viimeistään nyt tulee määritellä ne tarkemmin. Alue on laaja ja mo-nimutkainen: kunkin operatiivisen toiminnan tietoturvatavoitteisiin ja -vaati-muksiin vaikuttavat muun muassa ko. teolliselle toiminnalle asetettu lainsäädäntö, sääntely, asiakassopimukset, yleisen turvallisuuden ylläpitäminen, jne.
Periaate 1. Evaluaation perusidea – vertailu.
Evaluaatio perustuu ennen kaikkea vertailuun: mahdollisimman varman tiedon keräämiseen siitä, ovatko evaluaatiokohteen ominaisuudet tavoitteiden mukai-set. Jos kohde ei täytä ennakkovaatimuksia, on yleensä järkevää selvittää ja kirjata, millaisia löydetyt poikkeamat ovat, miten paljon niitä on jne.
Tässä käsikirjassa ei määritellä, millä menetelmällä tavoitteet ja vaatimukset tulisi yksityiskohtaisesti määrittää tai mistä kaikkialta vaatimuksia voi tulla. Sitä vastoin esitetään erityyppisiä yleisiä tavoitteita ja vaatimuksia sekä joitain yksi-tyiskohtia näiden evaluoimiseksi.
Periaate 2. Tietoturvaevaluaatioon liittyviä kysymyksiä.
Tietoturvaevaluaation yhteydessä voidaan tarkastella esimerkiksi seuraavia kysymyksiä:
1. Vastaako järjestelmän (käyttöjärjestelmä, sovellukset, tietoliikenne, jne.) asetukset ennalta määriteltyä mallia tai sallittua konfiguraatiota?
2. Kestääkö järjestelmä toiminnassa, vaikka sitä vastaan suunnataan tietyn-tyyppisiä tietoturvahyökkäyksiä (esim. palvelunestohyökkäykset, fuzz-testaus)?
3. Onko järjestelmän toteutukseen jäänyt tietoturvahaavoittuvuuksia (esim.
puskuriylivuodot, puutteellinen input/output-käsittely)?
4. Onko järjestelmästä poistettu kaikki sellainen toiminnallisuus, joka ei ole käytössä (esim. web-palvelinohjelmistot, toimisto-ohjelmistot)?
5. Onko ohjelmistojen päivitysominaisuuksien turvallisuudesta huolehdittu?
Entä vikojen korjaamisesta?
6. Onko järjestelmässä huomioitu haittaohjelmien torjunta? Voivatko tor-juntamekanismit itsessään aiheuttaa haittaa?
Näihin kysymyksiin vastaaminen riippuu vahvasti siitä, mihin kohtaan järjestel-män elinkaarta kyseessä oleva tietoturvaevaluaatio kohdistuu. Mikäli evaluaatio suoritetaan tuotekehityksen aikana, korostuvat yleispätevät asiat, kuten hyvien suunnittelusääntöjen käyttö ja lähdekoodin virheettömyyden varmistaminen.
Toisaalta jos evaluaatio kohdistuu käytössä olevan (tai käyttöönotettavan) jär-jestelmän evaluoimiseen, siirtyy painopiste helposti järjestelmäasetusten oikeel-lisuuteen, kovennukseen, päivitysprosesseihin tms. ominaisuuksiin, jotka voivat riippua voimakkaastikin esimerkiksi tietyn asiakkaan tai projektin vaatimuksista.
Huolimatta edellä mainitusta lähtökohtien moninaisuudesta järjestelmän tietotur-vaevaluaation voidaan katsoa koostuvan seuraavista päävaiheista:
1. evaluaatiokohteen määrittely (sis. evaluaation alaisten kohteiden rajaus) 2. evaluaatiokriteeristön määrittely (sis. vaatimukset vyöhykkeessä)
3. evaluaatiometodien ja työkalujen valitseminen sekä evaluaatio-ohjeen tarkempi määrittely (evaluaatiotyökalussa käytettävä profiili, skeletit, tarkistuslistat, jne. http://web.nvd.nist.gov/view/ncp/repository)
4. evaluointiaktiviteettien suorittaminen ja raportointi (esim. tietoturvates-taustyökalujen käyttö realistisessa testijärjestelmässä, ei tuotantokäytön aikana laitosjärjestelmissä)
5. evaluaation tulosten validointi.
Kuva 2. Määritelmä – automaatiojärjestelmän tietoturvaevaluaation päävaiheet.
3.3 Yleiskuvaus evaluaation vaiheista
Seuraavassa kuvataan lyhyesti käyttöönotettavan automaatiojärjestelmän eva-luaatioon kuuluvat vaiheet.
Periaate 3. Evaluaation perusongelmana on teknisten yksityiskohtien voimakas tapaus-kohtaisuus.
Vakioidun evaluaation perusongelmana on se, että tehokkaan tietoturvaevaluaa-tion yksityiskohtainen toteutus riippuu vahvasti evaluoitavan kohteen tyypistä, liiketoiminnan päätavoitteista sekä evaluaatiolle asetetuista tavoitteista. Yleispä-tevää, kaikkialle suoraan soveltuvaa tekniikkaa ei ole.
3.3.1 Evaluaatiokohteen määrittely
Käyttöönotettavasta järjestelmästä määritellään evaluoitava osuus. Koko järjes-telmää ei ole välttämätöntä evaluoida, mikäli halutaan rajata evaluointi sup-peammalle alueelle esimerkiksi työmäärän vähentämiseksi tai riittävän tarkkojen tulosten aikaansaamiseksi. Usein evaluaatio voidaan suorittaa tehokkaasti ja tarkasti, kun kohdistetaan tutkinta tiettyyn järjestelmän kohtaan (kuten vajavai-sesti testattuun uuteen komponenttiin), joka on esimerkiksi prosessinomistajien ja vastaavien viiteryhmien kattavassa riskiarviointipalaverissa todettu kriittiseksi ja potentiaalisesti haavoittuvaksi. Toisaalta jossain muussa asiayhteydessä (esim.
järjestelmäsuunnittelussa) voi olla jo valmiiksi dokumentoitu, että evaluoitavan moduulin merkitys koko järjestelmän oikealle toiminnalle on erityisen suuri.
Eräs tapa voi olla selvittää, minkä komponentin tekniseen toteuttamiseen on liittynyt suuria epävarmuuksia – tiedetäänkö esimerkiksi, onko komponentin kehittämisessä käytetty teknologia-alusta vielä joiltain osin testaamaton.
Tärkeää on rajata mahdollisimman selkeästi evaluaatiokohteesta tutkittavat ominaisuudet. Käytännössä kohdetta rajattaessa voidaan määritellä, että tutkitta-vasta moduulista evaluoidaan ainoastaan esimerkiksi ulkoinen käyttäytyminen, ei moduulin sisältämän lähdekoodin tietoturvaominaisuuksia kokonaisuudessaan.
Tietoturvaevaluaation kohteena on tällöin tietyn moduulin ulkoinen käyttäytymi-nen, ei se, miten tai millä säännöillä se on rakennettu (tai ohjelmoitu). Tällainen rajaus voi tulla kyseeseen esimerkiksi silloin, kun lähdekoodi ei ole saatavilla tai lähdekoodin tiedetään olevan hyvin laaja, jolloin sen kaikkia haavoittuvuuksia ei ehdittäisi kuitenkaan korjaamaan vaadittavassa ajassa. Tällaisessa tilanteessa ky-seisen lähdekoodin vaikutusalue ei saisi tietenkään olla kokonaisjärjestelmän tur-vallisuuden kannalta kriittinen. Esimerkkejä mahdollisista evaluaatiota rajaavista valinnoista voisivat olla vaikkapa kohteen lähdekoodin tietoturvaominaisuudet,
kohteen käyttäytymisen ulkoiset vaikutukset, järjestelmäasetusten oikeellisuus tai hyökkäysten vaikutukset järjestelmän suorituskykyyn.
Periaate 4. Evaluaatiokohteen määrittely.
Evaluaatiokohteen määrittely sisältää pääsääntöisesti seuraavia vaiheita:
1. Edellytys: Organisaatio on suorittanut tai tilannut (ja dokumentoinut) järjestelmän kokonaisriskiarvioinnin, jossa järjestelmän riskialtteimmat osat on tunnistettu. Riskiarvioinnin yhteydessä voidaan käyttää hyväksi järjestelmän teknistä skannausta tai sellaisten ominaisuuksien profiloin-tia, jotka osoittavat järjestelmästä riskialttiita kohtia.
2. Organisaatio päättää muun muassa riskiarvioinnin ja muiden suunnitel-miensa ja tavoitteidensa perusteella, mitä evaluaatiokohteita kussakin tietoturvaevaluaatiossa tutkitaan.
3. Yksittäisessä evaluaatiossa organisaatio rajaa evaluaatiokohteiden tut-kittavat ominaisuudet. Esimerkki: Kohteesta määritellään evaluoitavaksi ainoastaan ulkoinen (black box) käyttäytyminen järjestelmän ollessa tie-toturvatestauksen alaisena. Käyttäytymisen on oltava todennettavissa standardimenetelmin (ja koskettava kokonaisjärjestelmän toimintaky-vyn kannalta olennaiseksi todettua toimintoa).
Nämä vaiheet voidaan toteuttaa vapaamuotoisella, kullekin organisaatiolle sopi-valla tasopi-valla. Tulokset eli evaluaatiokohteen ja siitä tutkittavien ominaisuuksien rajaus tulee aina dokumentoida selkeästi ja mahdollisimman yksiselitteisesti.
Kuva 3. Esimerkki evaluoitavaksi valituista kohteista (harmaa väri) ja evaluoitavien omi-naisuuksien rajauksesta.
3.3.2 Evaluaatiokriteeristön määrittely
Tämä vaihe eli kysymyksenasettelu on evaluaatioon liittyvistä määrittelyistä kenties vaikein: ”Mitä kriteeristöä vasten kulloistakin evaluaatiokohdetta tutki-taan?” Monissa aiemmissa yhteyksissä on havaittu, että on erittäin tärkeää mää-ritellä ja todella ottaa käyttöön tarkoitukseen soveltuva kriteeristö evaluaation suorittamista varten. Mikäli kriteeristöä ei ole määritelty tarpeeksi tarkkaan tai se ei kohdistu tietoturvan kannalta oleellisiin järjestelmän seikkoihin, eivät evaluaa-tiotuloksetkaan vastaa tarkoitustaan eli järjestelmän ominaisuuksien todentamis-ta sen tietoturvavaatimuksia vasten. Kuten todettu, soveltuva kriteeristö riippuu voimakkaasti evaluaatiokohteesta sekä tavoitteista, jotka järjestelmän toiminnal-le on asetettu. Mitään sellaista kaikenkattavaa kriteeristöä ei otoiminnal-le otoiminnal-lemassa, joka sopisi kaikkiin käyttötarkoituksiin suoraan, sillä kyse on yrityksen itsensä mää-rittelemästä asiasta.
Evaluoitavan yrityksen operatiivista toimintaa kuvaavien tietoturvamääritte-lyjen ja -säännöstöjen tulee olla kunnossa. Mikäli näin ei ole, evaluoijat eivät voi tietää, mitkä ovat toimintaympäristön tarkat vaatimukset ja niiden täyttämiseksi
tarvittavat tietoturvakontrollit. (Evaluaatiota voitaisiin tietysti ajatella tehtävän vaikkapa jonkin yleistason mukaisesti, mutta tällöin ei tiedetä, miten evaluaation tulokset todella hyödyttäisivät kyseisen yrityksen operatiivisen toiminnan tur-vaamista.)
1. Kullakin automaatio- ja tietoliikennejärjestelmän evaluoitavalla osalla tulee olla operoivan organisaation erityisesti määräämä ja käytössä oleva tietoturvatason (security level) määrittely, johon kuuluvat kiinteästi sekä tietyt tietoturvakontrollit että yksityiskohtainen tekninen ja hallinnolli-nen tietoturvapolitiikka.
2. Lisäksi kokonaisjärjestelmän arkkitehtuurikuvauksessa on oltava määri-teltynä suojattavien kohteiden vyöhykkeet, joissa kussakin vallitsee tiet-ty tietoturvataso.
Yleisesti ottaen voidaan siis sanoa, että käyttöympäristöstä tulevat vaatimukset määräävät ehkä kaikkein voimakkaimmin valittavan evaluaatiokriteeristön yksi-tyiskohdat sekä referenssitason, johon evaluoitavaa komponenttia verrataan.
Lisäksi hyvän kriteeristön yleisiä ominaisuuksia ovat selkeys, yksiselitteisyys, käytettävyys sekä riittävä kattavuus. Tällöin kriteeristö sopii käyttötarkoituk-seensa hyvin ja antaa edellytykset saavuttaa evaluaatiolle asetetut tavoitteet.
Monesti yritykset käyttävät omien tietoturvakontrolliensa ja niihin liittyvien säännöstöjensä määrittelytyön pohjana olemassa olevia tietoturvastandardeja ja parhaita käytäntöjä. Usein otetaan mallia standardien soveltuvista osista ja lisä-tään mukaan omien toimintatapojen, erikoisvaatimusten tai -säännöstöjen yksi-tyiskohtia. Tavoitteena yleensä on, että tietoturvaohjeistus on yhteensopiva yrityksen olemassa olevaan säännöstökannan, laatukäsikirjojen ym. kanssa.
Automaatiojärjestelmän suojaamiseksi asetetaan usein muun muassa seuraavia vaatimuksia:
järjestelmän saatavuuden ja käyttövarmuuden varmistaminen, resurssien käytön kontrollit
vikatilanteista elpymisen suunnitelmat ja turvaaminen, toiminnan jatkuvuus
valvontatiedon saannon ja prosessinohjauskyvyn turvaaminen
pääsynvalvonnan kontrollit (esim. roolipohjainen), käyttäjätilien hallit-seminen
järjestelmän suojauksen ja eristämisen kontrollit
järjestelmien kovennus, rajapintojen palveluiden rajoittaminen
järjestelmään tallennetun datan ja viestien eheyden suojaaminen
turvajärjestelmien signaloinnin (mm. hälytykset) varmistaminen
tapahtumatiedon jäljitettävyys ongelmatilanteissa (accountability, ym.)
haittaohjelmasuojauksen kontrollointi.
Käytännössä tällaisia vaatimuksia täytyy tarkentaa organisaatiotasolla, jotta riittä-vän tarkka evaluaatiokriteeristö saadaan johdettua voimassa olevista tietoturva-vaatimuksista, -säännöistä ja -käytännöistä.
Alla on lueteltu teollisuusautomaatiojärjestelmien käyttöön soveltuvia tieto-turvastandardeja ja -käytäntöjä (sis. valmiita kriteeristöjä ja vaatimuksia), joita voidaan käyttää hyväksi suunniteltaessa käyttöönotettavan automaatiojärjestel-män tietoturvaevaluaatiota.
Taulukko 14. Teollisuusautomaatiojärjestelmien turvaamiseen soveltuvia