View
116
Download
0
Category
Preview:
DESCRIPTION
- Miten tietoturvaratkaisut sisällytetään arkkitehtuurisuunnitteluun? - Tietoturva järjestelmäkehitysprosessissa - Tietoturvan ylläpitäminen jatkuvassa palvelussa - Ulkoistus ja tietoturva - Tietoturva ja lainsäädäntö
Citation preview
Tietoturva ja IT-arkkitehtuuri
-"Speksit muuttuu?"
-"Eihän nyt niin voi..."
26.10.2011
Thomas Malmberg
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 2
Päivän puheenaiheet
• Miten tietoturvaratkaisut sisällytetään arkkitehtuurisuunnitteluun?
• Tietoturva järjestelmäkehitysprosessissa
• Tietoturvan ylläpitäminen jatkuvassa palvelussa
• Ulkoistus ja tietoturva
• Tietoturva ja lainsäädäntö ”Kysymyksiä voi
esittää koska
tahansa”
Tietoturva ja IT-arkkitehtuuri
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 3
...mutta alkuun: mikä tietoturva?
• On hyvä muistaa ettei tietoturvaa saavuteta vain teknisillä vimpaimilla ja kallilla härveleillä – eikä varsinkaan Isolla Voimalla
• Tietoturva kostuu tässä kontekstissa ainakin seuraavista asioista – Sovellus- ja palvelukehityksestä
– Loppukäyttäjistä
– Mustista hatuista
– Palvelimien fyysisestä suojaamisesta
– Käyttäjätunnuksista
– Valtuushallinnasta
– Sertifikaattien hallinnasta
– Konfiguraatioiden hallinnasta
– Koodin laadusta
– Tietojen suojaamisesta
– Testaamisesta
• Tärkeintä: tietoturva on riskien hallintaa
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 4
...ja sitten: miksi tietoturvaa arkkitehtuureissa?
• Onko eroa onko meillä tietoturvaa arkkitehtuureissa vai tietoturva-arkkitehtuuri?
• Tietoturva alkaa ennen projektia – Liiketoiminnan vaatimuksista johdetut asiat – Lainsäädäntö – Hyvät käytännöt – Liiketoiminnan jatkuvuus – Asiakkaiden suojeleminen
• Tietoturvan on kuljettava mukana kaikissa projektin osa-alueissa – Tietoturva ui harvemmin organisaatioon intranetin
kautta annettavien tiedotteiden muodossa – Tietoturva ui hankkeisiin ja käytäntöihin projektien
kautta • Tietoturva ei lopu projektiin
– Tietoturva-arkkitehtuurin on kyettävä tuottamaan tietoturvallista palvelua – jatkuvasti
• Tietoturva-arkkitehtuuri on ohjeisto, toimintamalli, tekniikkaa, käytäntöjä ja ihmisiä - tietoturvakulttuuria – ja joskus vähän voimasanoja
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 5
Miten tietoturvaratkaisut sisällytetään arkkitehtuuri suunnitteluun?
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 6
Miten tietoturvaa tehdään?
• Tietoturvaa on helpointa jalkauttaa projektien kautta
• Projekti voi olla – Sovelluskehitystä
– Päivitys
– Infran uusiminen
– Ulkoistaminen
• Tietoturva on hallinnollista sekä teknistä
• Tietoturva on osa jatkuvuutta ja riskienhallintaa
• Yhdistä kaikki nämä ja teet tietoturvaa – Joudut koordinoimaan eri tahojen tarpeita ja
vaatimuksia sekä erilaisia tahto- ja tavoitetiloja
• Jos olet uusimassa arkkitehtuuria, tee siitä oikea projekti – Oikein tehdystä arkkitehtuurista on hyvä ja
helppo ponnistaa
– Poistaa esimerkiksi tietoturvapäänsäryn monesta kohdasta
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 7
Liitä tietoturva prosesseihin
• Lähtökohtana projekti – Tuo tietoturva mukaan uusiin
hankkeisiin
– Kenen vastuulla tietoturva on? • Organisaatiosta löydyttävä tietoturvasta
vastaava
• Projektiorganisaatiosta ja projektista nimettävä tietoturvasta vastaava
• Kuten aina: vastuuta ei voi ulkoistaa, tekemisen voi.
• Selvitä faktat ja määrittele – Mikä on haluttu tietoturvataso
– Onko joitakin erityisehtoja arkkitehtuurissa, jotka vaativat tietynlaisia ratkaisuja
– Onko joitain muita erityisehtoja (esim. PCI-DSS)
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 8
Mitä tarvitaan ennen kuin projektin voi aloittaa?
• Oletetaan, että projekti on perusteltu ja hyväksytty sekä että sillä on budjetti ja aikataulu
• Voidaan kuvitella, että tarvitaan ainakin
– Tietoisuus siitä, mitä tietoturvavaatimuksia liiketoiminta vaatii
– Tieto siitä, mitä tietoturva saa maksaa
– Selvitys projektin tietoturvavaatimusten mahdollisista ulkoisista vaikutuksista
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 9
Tietoturvasuunnitelma
• Hyvä tietoturvasuunnitelma tukee projektia
– Ei turhia kommervenkkejä
– Perusteltuja vaatimuksia
– Selkeitä ohjeita – konkretiaa
• Älä jätä infrastruktuurin suunnittelijalle liikaa vapauksia päänvaivaa
• Älä jätä sovellusarkkitehdille liikaa vapauksia päänvaivaa
– Johdata projekti kohti onnellista lopputilaa
• Mutta: jos on pakko, niin pakota
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 10
Tietoturvasuunnitelma - esimerkki
• Tietoturvasuunnitelma ottaa kantaa esimerkiksi seuraaviin asioihin – Miten varaudutaan tietoturvauhkiin
– Miten tietoturvaa voidaan mitata
– Audit-trail tarpeet
– Lokitus ja siihen liittyvä ohjeistus
– Tietosuojaan liittyvät asiat
– Infrastruktuurin suojaaminen • Palomuurit ja politiikka
• Pääsynhallinta
• Salasanapolitiikka
– Tietoliikenteen suojaaminen • Tietoliikenneprotokollat
• SSL
– Auditointitarpeet ja kohteet
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 11
Entä sitten se arkkitehtuuri?
• Arkkitehtuureja on monenlaisia ja tietoturvasuunnitelman on otettava kantaa kaikkiin
– Infrastruktuuri
– Sovelluskehitys
– Palvelukehitys
• Jos on olemassa valmiit prosessit ja käytännöt arkkitehtuurien määrittelemiselle ja toteuttamiselle, on tietoturvan lisääminen niihin melko helppoa
• Usein kuitenkin arkkitehtuureilla on tapana uusiutua samalla kuin uutta hanketta lähdetään toteuttamaan
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 12
Tietoturva järjestelmäkehitysprosessissa
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 13
Projektin elinkaari ja prosessi
• Olemassa olevaan kehitysprosessiin / hankeprosessiin / projektiprosessiin on helppoa lisätä tietoturvaan liittyviä kohtia
• Jos prosessia ei ole olemassa, jää tietoturva-asiat (kuten muutkin) roikkumaan epämääräisiksi action pointeiksi joiden valvomista ja edistymistä ei ehkä kukaan pysty valvomaan
• Tietoturvaa on helpompaa perustella jos voidaan näyttää mihin kaikkeen se liittyy
Projektin
asettaminen
Vaatimus-
määrittely
RUP Inception
(on alkanut jo
määrittelyvaiheessa)
Projekti-
suunnitelma
Aloituskokous
Tekninen
suunnitelma
Testaus-
suunnitelma
Toteutus
Raportointi
Koodi
Deliverable
Katselmointi
suunnitelma
Riski-
analyysi
Käyttöönotto
kokous
RUP Construction
Suunnittelu
RUP Elaboration
- Analysointi
- Priorisointi
- Käyttötapaukset
- 1 iteraatio
- Arkkitehtuuri
- Riskianalyysi
- Tavoitteiden ymmärtäminen
- 1 iteraatio
RUP Transition
- 2-3 viikon iteraatiot
- Käyttötapausten valinta
- Testitapaukset ja ohjeet
- 1-n iteraatiota
- Viimeistely
- Testaus
- Asennusohjeet
- 1-2 iteraatiota
Kehitys
ympäristö
Infran tilaus
Katselmointi
raportti
Käyttöliittymä
Käyttötapauk-
set
Katselmointi
raportti
Käyttöönotto
aikataulu
Testaus
Käyttötapauk-
set
Testausprosessi
Yksikkötestaus
Käyttöönotto
suunnitelma
Tietoturva
dokumentaatio
Tietoturva-
vaatimukset
Tietoturva-
suunnitelma
Suunnitelmasta tiedot
dokumentaatioon
Mahdollisia tietoturva
sovelluskehityksessä-
koulutuksia kehittäjille
ennen toteutus-
vaiheen alkua
IT-riskit ohjaavat
tietoturvatestauksen
fokuksen määrittelyssä
Sisällytä
tietoturvakatselmoinnit
suunnitelmaan
Suunnitelmien
katselmointiTietoturvakatselmoin-
neissa varmistetaan,
että tietoturva-
vaatimukset on täytetty
ja tunnistettuihin
riskeihin on reagoitu
Sisällytetään
tietoturvatestaus-
toimenpiteitä osaksi
käyttötestausta, esim.
virheelliset syötteet
Riskien seuraaminen
ja riskianalyysin
päivittäminen
Koodin
katselmointi
kriittisissä
järjestelmissä,
iteraatio n>1
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 14
Liitä tietoturva jo vaatimusvaiheessa
• Vaatimusmäärittelyvaiheessa on hyvä tuoda esille liiketoiminnasta vastaaville mitä kaikkea tietoturvaan liittyvää heidän uuteen hankkeeseen saataa liittyä
• Ohjaa tavoitteet palvelemaan sekä liiketoimintaa että tietoturvaa
– Tietoturva hallitsee myös riskejä, jota kautta se palautuu nopeasti liiketoiminnalliseksi vaatimukseksi – esimerkiksi osana jatkuvuutta
• Pyri viestimään ettei tietoturva ole erillinen liiketoimintaa estävä toiminto!
Projektin
asettaminen
Vaatimus-
määrittely
RUP Inception
(on alkanut jo
määrittelyvaiheessa)
Projekti-
suunnitelma
Aloituskokous
Tekninen
suunnitelma
Testaus-
suunnitelma
Toteutus
Raportointi
Koodi
Deliverable
Katselmointi
suunnitelma
Riski-
analyysi
Käyttöönotto
kokous
RUP Construction
Suunnittelu
RUP Elaboration
- Analysointi
- Priorisointi
- Käyttötapaukset
- 1 iteraatio
- Arkkitehtuuri
- Riskianalyysi
- Tavoitteiden ymmärtäminen
- 1 iteraatio
RUP Transition
- 2-3 viikon iteraatiot
- Käyttötapausten valinta
- Testitapaukset ja ohjeet
- 1-n iteraatiota
- Viimeistely
- Testaus
- Asennusohjeet
- 1-2 iteraatiota
Kehitys
ympäristö
Infran tilaus
Katselmointi
raportti
Käyttöliittymä
Käyttötapauk-
set
Katselmointi
raportti
Käyttöönotto
aikataulu
Testaus
Käyttötapauk-
set
Testausprosessi
Yksikkötestaus
Käyttöönotto
suunnitelma
Tietoturva
dokumentaatio
Tietoturva-
vaatimukset
Tietoturva-
suunnitelma
Suunnitelmasta tiedot
dokumentaatioon
Mahdollisia tietoturva
sovelluskehityksessä-
koulutuksia kehittäjille
ennen toteutus-
vaiheen alkua
IT-riskit ohjaavat
tietoturvatestauksen
fokuksen määrittelyssä
Sisällytä
tietoturvakatselmoinnit
suunnitelmaan
Suunnitelmien
katselmointiTietoturvakatselmoin-
neissa varmistetaan,
että tietoturva-
vaatimukset on täytetty
ja tunnistettuihin
riskeihin on reagoitu
Sisällytetään
tietoturvatestaus-
toimenpiteitä osaksi
käyttötestausta, esim.
virheelliset syötteet
Riskien seuraaminen
ja riskianalyysin
päivittäminen
Koodin
katselmointi
kriittisissä
järjestelmissä,
iteraatio n>1
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 15
Koulutus ja tiedottaminen
• Ennen projektin varsinaista alkua
– Selvitä reunaehdot
– Tutustu sidosryhmiin
– Selvitä lainsäädännölliset asiat
– Selvitä hankintaprosessit
– Minkälainen projekti on tulossa
– Onko tietoturva vastuutettu
– Tietävätkö sidosryhmät tietoturvaan liittyvät roolinsa
– Tiedetäänkö tietoturvavaatimukset
– Onko sopimuksiin lisätty vaatimusta hyvästä koodista (liitetty laatu esim. OWASP-kehikkoon)
– Osataanko koodata tietoturvallisesti
– Onko tietoturvalla budjettia
Projektin
asettaminen
Vaatimus-
määrittely
RUP Inception
(on alkanut jo
määrittelyvaiheessa)
Projekti-
suunnitelma
Aloituskokous
Tekninen
suunnitelma
Testaus-
suunnitelma
Toteutus
Raportointi
Koodi
Deliverable
Katselmointi
suunnitelma
Riski-
analyysi
Käyttöönotto
kokous
RUP Construction
Suunnittelu
RUP Elaboration
- Analysointi
- Priorisointi
- Käyttötapaukset
- 1 iteraatio
- Arkkitehtuuri
- Riskianalyysi
- Tavoitteiden ymmärtäminen
- 1 iteraatio
RUP Transition
- 2-3 viikon iteraatiot
- Käyttötapausten valinta
- Testitapaukset ja ohjeet
- 1-n iteraatiota
- Viimeistely
- Testaus
- Asennusohjeet
- 1-2 iteraatiota
Kehitys
ympäristö
Infran tilaus
Katselmointi
raportti
Käyttöliittymä
Käyttötapauk-
set
Katselmointi
raportti
Käyttöönotto
aikataulu
Testaus
Käyttötapauk-
set
Testausprosessi
Yksikkötestaus
Käyttöönotto
suunnitelma
Tietoturva
dokumentaatio
Tietoturva-
vaatimukset
Tietoturva-
suunnitelma
Suunnitelmasta tiedot
dokumentaatioon
Mahdollisia tietoturva
sovelluskehityksessä-
koulutuksia kehittäjille
ennen toteutus-
vaiheen alkua
IT-riskit ohjaavat
tietoturvatestauksen
fokuksen määrittelyssä
Sisällytä
tietoturvakatselmoinnit
suunnitelmaan
Suunnitelmien
katselmointiTietoturvakatselmoin-
neissa varmistetaan,
että tietoturva-
vaatimukset on täytetty
ja tunnistettuihin
riskeihin on reagoitu
Sisällytetään
tietoturvatestaus-
toimenpiteitä osaksi
käyttötestausta, esim.
virheelliset syötteet
Riskien seuraaminen
ja riskianalyysin
päivittäminen
Koodin
katselmointi
kriittisissä
järjestelmissä,
iteraatio n>1
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 16
Tietoturvan, katselmointien ja riskienhallinnan suunnitelmat
• Lisää projektisuunnitelmaan oma kohta tietoturvasta
• Tee tietoturvasuunnitelma ja viesti se eteenpäin
• Muista aikatauluttaa katselmoinnit
• Tässä vaiheessa on hyvä esittää tietoturvaan liittyvät testaukset aikatauluun
– Voiko jo tässä vaiheessa määritellä projektiin liitettyjen tietoturvavaatimusten exit-ehdot?
Projektin
asettaminen
Vaatimus-
määrittely
RUP Inception
(on alkanut jo
määrittelyvaiheessa)
Projekti-
suunnitelma
Aloituskokous
Tekninen
suunnitelma
Testaus-
suunnitelma
Toteutus
Raportointi
Koodi
Deliverable
Katselmointi
suunnitelma
Riski-
analyysi
Käyttöönotto
kokous
RUP Construction
Suunnittelu
RUP Elaboration
- Analysointi
- Priorisointi
- Käyttötapaukset
- 1 iteraatio
- Arkkitehtuuri
- Riskianalyysi
- Tavoitteiden ymmärtäminen
- 1 iteraatio
RUP Transition
- 2-3 viikon iteraatiot
- Käyttötapausten valinta
- Testitapaukset ja ohjeet
- 1-n iteraatiota
- Viimeistely
- Testaus
- Asennusohjeet
- 1-2 iteraatiota
Kehitys
ympäristö
Infran tilaus
Katselmointi
raportti
Käyttöliittymä
Käyttötapauk-
set
Katselmointi
raportti
Käyttöönotto
aikataulu
Testaus
Käyttötapauk-
set
Testausprosessi
Yksikkötestaus
Käyttöönotto
suunnitelma
Tietoturva
dokumentaatio
Tietoturva-
vaatimukset
Tietoturva-
suunnitelma
Suunnitelmasta tiedot
dokumentaatioon
Mahdollisia tietoturva
sovelluskehityksessä-
koulutuksia kehittäjille
ennen toteutus-
vaiheen alkua
IT-riskit ohjaavat
tietoturvatestauksen
fokuksen määrittelyssä
Sisällytä
tietoturvakatselmoinnit
suunnitelmaan
Suunnitelmien
katselmointiTietoturvakatselmoin-
neissa varmistetaan,
että tietoturva-
vaatimukset on täytetty
ja tunnistettuihin
riskeihin on reagoitu
Sisällytetään
tietoturvatestaus-
toimenpiteitä osaksi
käyttötestausta, esim.
virheelliset syötteet
Riskien seuraaminen
ja riskianalyysin
päivittäminen
Koodin
katselmointi
kriittisissä
järjestelmissä,
iteraatio n>1
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 17
Tietoturvatestaus osana tietoturva-arkkitehtuurin verifiointia
• Tietoturva on pakko verifioida ja asioista on löydyttävä evidenssiä
• Onko mahdollista saada "test-driven tietoturva"
• Tietoturva toteutuu tarpeeksi hyvin silloin kun on olemassa tietoturvavaatimukset, niihin liitetyt testit sekä testeihin määritellyt exit-ehdot
• Testaaminen voi olla (ja onkin) – Koodin katselmointia – Toteutettujen ohjelmointiratkaisujen vertailu
asetettuihin ehtoihin – Palomuuriratkaisujen testaaminen (verkko-
auditointi) – Palvelimien auditointi (host-review) – Konesaliauditointi – Hallinnollinen auditointi – Varusohjelmistojen patch-tason testaaminen – Penetraatiotestaus – Kriittisten ongelmatilanteiden pöytätestaus – Jatkuvuussuunnitelmien pöytätestaus
Projektin
asettaminen
Vaatimus-
määrittely
RUP Inception
(on alkanut jo
määrittelyvaiheessa)
Projekti-
suunnitelma
Aloituskokous
Tekninen
suunnitelma
Testaus-
suunnitelma
Toteutus
Raportointi
Koodi
Deliverable
Katselmointi
suunnitelma
Riski-
analyysi
Käyttöönotto
kokous
RUP Construction
Suunnittelu
RUP Elaboration
- Analysointi
- Priorisointi
- Käyttötapaukset
- 1 iteraatio
- Arkkitehtuuri
- Riskianalyysi
- Tavoitteiden ymmärtäminen
- 1 iteraatio
RUP Transition
- 2-3 viikon iteraatiot
- Käyttötapausten valinta
- Testitapaukset ja ohjeet
- 1-n iteraatiota
- Viimeistely
- Testaus
- Asennusohjeet
- 1-2 iteraatiota
Kehitys
ympäristö
Infran tilaus
Katselmointi
raportti
Käyttöliittymä
Käyttötapauk-
set
Katselmointi
raportti
Käyttöönotto
aikataulu
Testaus
Käyttötapauk-
set
Testausprosessi
Yksikkötestaus
Käyttöönotto
suunnitelma
Tietoturva
dokumentaatio
Tietoturva-
vaatimukset
Tietoturva-
suunnitelma
Suunnitelmasta tiedot
dokumentaatioon
Mahdollisia tietoturva
sovelluskehityksessä-
koulutuksia kehittäjille
ennen toteutus-
vaiheen alkua
IT-riskit ohjaavat
tietoturvatestauksen
fokuksen määrittelyssä
Sisällytä
tietoturvakatselmoinnit
suunnitelmaan
Suunnitelmien
katselmointiTietoturvakatselmoin-
neissa varmistetaan,
että tietoturva-
vaatimukset on täytetty
ja tunnistettuihin
riskeihin on reagoitu
Sisällytetään
tietoturvatestaus-
toimenpiteitä osaksi
käyttötestausta, esim.
virheelliset syötteet
Riskien seuraaminen
ja riskianalyysin
päivittäminen
Koodin
katselmointi
kriittisissä
järjestelmissä,
iteraatio n>1
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 18
Riskienhallinta ja riskien hallinta
• Projektin alussa on arvioitu riskit
• Testauksen perusteella voidaan verifioida ja uudelleen arvioida löydetyt riskit
• Jos ei uusia riskejä ole löytynyt, on jokin alue todennäköisesti jäänyt testaamatta
• Kun koodataan ja toteutetaan iteratiivisesti on myös tietoturvan sopeuduttava
– Uusia ominaisuuksia ja siten koodia nousee kuin sieniä sateella – projektin viime metreille asti
– Uusia riskejä ja uhkakuvia nousee taivaalle
– ... jotka saattavat osaltaa viivästyttää tai kallistuttaa projektia
– On ehkä arvioitava uuden ominaisuuden mielekkyys uudestaan?
– Elämä on.
Projektin
asettaminen
Vaatimus-
määrittely
RUP Inception
(on alkanut jo
määrittelyvaiheessa)
Projekti-
suunnitelma
Aloituskokous
Tekninen
suunnitelma
Testaus-
suunnitelma
Toteutus
Raportointi
Koodi
Deliverable
Katselmointi
suunnitelma
Riski-
analyysi
Käyttöönotto
kokous
RUP Construction
Suunnittelu
RUP Elaboration
- Analysointi
- Priorisointi
- Käyttötapaukset
- 1 iteraatio
- Arkkitehtuuri
- Riskianalyysi
- Tavoitteiden ymmärtäminen
- 1 iteraatio
RUP Transition
- 2-3 viikon iteraatiot
- Käyttötapausten valinta
- Testitapaukset ja ohjeet
- 1-n iteraatiota
- Viimeistely
- Testaus
- Asennusohjeet
- 1-2 iteraatiota
Kehitys
ympäristö
Infran tilaus
Katselmointi
raportti
Käyttöliittymä
Käyttötapauk-
set
Katselmointi
raportti
Käyttöönotto
aikataulu
Testaus
Käyttötapauk-
set
Testausprosessi
Yksikkötestaus
Käyttöönotto
suunnitelma
Tietoturva
dokumentaatio
Tietoturva-
vaatimukset
Tietoturva-
suunnitelma
Suunnitelmasta tiedot
dokumentaatioon
Mahdollisia tietoturva
sovelluskehityksessä-
koulutuksia kehittäjille
ennen toteutus-
vaiheen alkua
IT-riskit ohjaavat
tietoturvatestauksen
fokuksen määrittelyssä
Sisällytä
tietoturvakatselmoinnit
suunnitelmaan
Suunnitelmien
katselmointiTietoturvakatselmoin-
neissa varmistetaan,
että tietoturva-
vaatimukset on täytetty
ja tunnistettuihin
riskeihin on reagoitu
Sisällytetään
tietoturvatestaus-
toimenpiteitä osaksi
käyttötestausta, esim.
virheelliset syötteet
Riskien seuraaminen
ja riskianalyysin
päivittäminen
Koodin
katselmointi
kriittisissä
järjestelmissä,
iteraatio n>1
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 19
Tietoturvan ylläpitäminen jatkuvassa palvelussa
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 20
Tietoturvan ylläpitäminen jatkuvassa palvelussa
• Palvelu joka on tuotannossa ja loppukäyttäjien tuotannollisessa käytössä
• Jatkuvaa palvelua ostetaan usein ulkoiselta toimittajalta
– Konesalipalvelut
– Sovelluspalvelinylläpito
– Ohjelmiston ylläpito
– Tietoturvaskannaus
• Mutta! Samat lainalaisuudet pätevät myös vaikka palvelua tuotettaisiin oman organisaation sisällä
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 21
Tietoturvan ohjaaminen
• Jotta tietoturvaa voidaan saada projektin ja hankkeen jälkeisessä elämässä, on siitä sovittava etukäteen
– Sitä saa mitä tilaa – kirjaimellisesti
– Tietoturva ei ole automaattista vaikka "kaikki" olisi ulkoistettu
– Lopullinen vastuu on aina palvelua tarjoavalla, ei palvelua pyörittävällä
– Tietoturva voidaan toteuttaa paperilla - osittain sopimuksilla, mutta tietoturvan varmistaminen on oma prosessinsa
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 22
Tietoturvan ohjaaminen
• Tiedä kenen kanssa olet tekemisissä – Tietoturva ei elä tyhjiössä – Toimiva tietoturva edellyttää interaktiota – Rakenna suhteet valmiiksi niihin tahoihin
joita tulet tarvitsemaan sekä arjessa että kriisissä
– Liitä tietoturva muihin palvelun pyörittämiseen liittyviin prosesseihin
• Ohjaamisen perusteet – sovi kaikista asioista etukäteen – Määrittele, hyväksytä ja kirjaa
• Luo tietoturvan vuosikello – Muut osapuolet osaavat ennakoida
vaatimuksiasi • Projektin tai hankkeen
tietoturvasuunnitelma luo pohjan sille, mitä vaatimuksia jatkuvalle palvelulle tulisi asettaa
• Mistä aloittaa? Esimerkiksi palvelukokouksista
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 23
Tietoturvapalvelukokoukset
• Esimerkkiagenda
– Insidentit
• Virukset
• Murtoyritykset
• Löydetyt virheet
– Muutokset ympäristöihin
– Käyttöoikeudet
– Jatkuvuusanalyysi
– Auditointitarpeet ja raportit
– Threat landscape – katsaukset (esim. CERT-FI)
– Patch management ja tietoturvapäivitykset
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 24
Ulkoistus ja tietoturva
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 25
Ulkoistus ja tietoturva
• Mitä ulkoistaminen kattaa? Mitä eri ulkoistamisasteita voidaan identifioida?
– Konesalipalvelut
• Oma sovellus, oma rauta toisen ympäristössä
• Oma sovellus, toisen rauta toisen ympäristössä
– Sovellusulkoistus
• Valmissovellus jota käytetään verkon yli
• Dedikoitu tietylle yritykselle
– Pilvipalvelu
• Mitä kukin haluaa tällä ymmärtää
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 26
Ulkoistus ja tietoturva - nyanssit
• Konesalipalvelut
– SLA:n kautta myös tietoturva
– Auditoitava – vaadi evidenssiä!
• Sovellusulkoistus
– SLA voi purra tähänkin
– Valmissovelluksissa omat haasteet
– Kustomoidun sovelluksen ulkoistuksessa et kuitenkaan voi ulkoistaa sovelluksen ongelmia
• Pilvipalvelu
– Tietääkö kukaan mitä ostaa?
– Yksityinen pilvi?
– Kenen kanssa jaat tietosi?
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 27
Ulkoistus ja tietoturva – bottom line
• Taas kerran: – Lopullinen vastuu palvelusta on aina palvelua
loppukäyttäjälle tarjoavalla, ei palvelua pyörittävällä
– Vahingon sattuessa SINÄ olet vastuussa asiakkaallesi (myös siitä että valitsit epäluotettavan ulkoistuskumppanin)
• Ulkoistuksessa on tietoturvan kannalta huomioitava seuraavat asiat – Tavoitetilan ei pitäisi erota tavallisesta
"omasta" palvelusta – Sopimuksiin on ehkä lisättävä asioita – Jos sopimuksia ei oikeasti voida tehdä tai
muokata oman mielen mukaan (google, amazon,...) on riskienhallinnassa otettava tiukka kanta ja ote mm. lainsäädännöllisiin asioihin
• Onko jaettu ongelma ei kenenkään ongelma? Miten ratkaiset omat erityistarpeesi? – Käy asiat toimittajan kanssa huolellisesti läpi – Kirjaa osaksi sopimusta – Vaadi
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 28
Tietoturva ja lainsäädäntö
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 29
Lainsäädäntö
• Erilaisilla organisaatioilla erilaiset vaatimukset
• Kaikilla organisaatioilla jonkinlaiset vaatimukset!
• Lainsäätäjän vaatimukset ja best-practicet eroavat harvoin hengessä toisistaan
• Lainsäädäntö on keinotekoinen rajoite – nykypäivänä on paljon muutakin sitovaa "säädäntöä" – Kansalliset lait – Muiden maiden lait jossa toimintaa
harjoitetaan (tai esimerkiksi verkkopalvelua tullaan käyttämään)
– Partnereiden ja ylikansallisten konsortioiden vaatimukset (PCI-DSS)
– EU-direktiivit – Valtiohallinnon ohjeet – Finanssivalvonnan vaatimukset
(kansallisesti ja ylikansallisesti)
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 30
Lainsäädäntö
• Esimerkkejä asioista joihin lainsäädäntö vaikuttaa
– Käyttöoikeudet
– Käyttöoikeuksen valvonta
– Transaktioiden lokitus
– Tietojen säilyminen
– Tietojen säilöminen
– Tietojen tuhoaminen
– Lokitus
– Anonymiteetti
– Ulkoistaminen
– Palvelimien fyysinen sijainti
– Raportointi
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 31
Lainsäädäntö – esimerkkejä 1
• Esimerkkejä lainsäädännöistä (finanssialapainotteisesti) – Laki henkilön sähköisestä tunnistamisesta
617/2009 • Vahva sähköinen tunnistaminen 2§ ja 8§ • Pakottavuus kuluttajasuhteissa 3§ • Oikeustoimen tekeminen 5§ • Ensitunnistaminen 17§ • Tietojen suojaaminen ja riittävä tietoturva 13§ • Ilmoitusvelvollisuus uhkista ja häiriöistä 16§ • Vastuu oikeudettomasta käytöstä 27§
– Euroopan yhteisöjen neuvoston ja parlamentin sähköisiä allekirjoituksia koskevista neuvoston puitteista annettu direktiivi 93/1999/EY
– Finanssivalvonnan määräys 4.4b (riskienhallinta) ja erityisesti luvut 6.6 ja 6.7
– Laki rahanpesun ja terrorismin rahoittamisen estämisestä ja selvittämisestä 503/2008 • Asiakkaan tuntemistiedot ja niiden säilyttäminen 10§
– Euroopan parlamentin ja neuvoston direktiivi rahoituspalvelujen etämyynnistä 2002/65/EY
– Amerikkalaiset kirjanpitosäädökset
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 32
Lainsäädäntö – esimerkkejä 2
• Ei finanssialapainotteisia (joita myös esim. pankkien projektit joutuvat huomioimaan)
– Henkilötietolaki
• Tietojen suojaaminen ja riittävä tietoturva 32§
– Laki tietoyhteiskunnan palvelujen tarjoamisesta 458/2002
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 33
Lainsäädäntö – and beyond
• Muuta? Kyllä. Sitovaa? Joillekin.
– PCI-DSS
• Visan ja MasterCardin "sitovia" vaatimuksia
– Vahti
• Sitoo valtiohallintoa hankkeissa, mutta sisältää valtavasti hyvin toimitettuja ohjeita ja käytäntöjä – suomeksi kirjoitettuna
– 3/2009 Lokiohje
– 2/2009 ICT-toiminnan varautuminen häiriö- ja erityistilanteisiin
– 9/2008 Hankkeen tietoturvaohje
– 3/2008 Valtionhallinnon salauskäytäntöjen tietoturvaohje
– 12/2006 Tunnistaminen julkishallinnon verkkopalveluissa
– 9/2006 Käyttövaltuushallinnon periaatteet ja hyvät käytännöt
– Luoti-ohjelma
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 34
Lainsäädäntö – and beyond
• Vielä jotain?
– Kansainväliset standardit
– ISO27000
– OWASP
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 35
Yhteenveto
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 36
Yhteenveto
• Sopiminen – Sopimukset kuntoon
– Toimintatavat paperille
• Viestiminen – Toimintatavat tietoon
– Tavoitteet määriteltävä
• Varmistaminen – Tavoitteet ja niiden toteutuminen
– Lopputulokset
• Kehittyminen – Lopputulokset ja vajaukset sekä
poikkeamat
• Oppiminen – Lisää oppimasi asiat prosesseihin
11.9.2014 (C) Thomas Malmberg [FOR INTENDED AUDIENCES ONLY] 37
Voiko tämä oikeasti toteutua?
• Kyllä
– Prosessikehitykseen panostettava
– Työkalut hankittava
– Ostettava oikea määrä konsultointia (muutakin kuin slidewarea) ennen kuin prosessit ja menetelmät lyödään lukkoon
• Kokemuksen, kantapään ja oppimisen kautta
• Vaadi osaavia ja motivoituneita ihmisiä (PAKKO-sääntö)
– P äteviä projektipäälliköitä
– A nsiokkaita arkkitehtejä
– K ovia koodareita
– K okeneita konsultteja
– O saavia ostajia
”Ihmisten kokoisia
järjestelmäprojekteja”
Thank You!
Kiitos!
Tack!
Questions?
Kysymyksiä?
Frågor?
Contact:
thomas.malmberg@aktia.fi
http://fi.linkedin.com/in/thomasmalmberg
twitter @tsmalmbe
Esityksen kuvat:
Aktia sekä stock.xchng
Recommended