Agile ja vesiputousmallin projektien tietoturva

1. Projektien tietoturva
Uhat tänään
Projekti
Vesiputous
Innovatiivinen
Projektin yleiset käytännöt
(jos aikaa, ajankohtaista tietoturvasta)
Yliopistojen Projekti SIG 3.2.2015

2. Kuka?
2
Tomi Järvinen
twitter.com/tomppaj , slideshare.com/tomppaj
• IT Security Specialist at Aalto University
• Project manager at F-secure corporation
• IT Manager at Falck Security / G4S
• IT-Specialist / Program manager at Instrumentarium
• Administrator at Outokumpu Oyj

3. • Tietojen luottamuksellisuus (confidentiality)
tietojen paljastumisen estäminen
• valtuudet
• henkilöiden tunnistaminen
• todentaminen
• salaus
• Tietojen oikeellisuus ja eheys (integrity)
tieto ei saa muuttua tahattomasti tai tahallisesti
• varmistukset
• valtuuksien määrittely
• muutosten hallinta
• Tietojen saatavuus (availability)
tieto saatavilla kun sitä tarvitaan
• varajärjestelyt
• tiedonsiirron kapasiteetti
• varahenkilöt
Tietoturva tuo mukanaan
”C I A”
Luottamuksellisuus
(Confidentality)
Eheys (Integrity).
Käytettävyys (Availability)
7

4. Tietoturvaan liittyviä uhkia
1. Kalastelu (tunnusten hyväksikäyttö)
2. Haittaohjelmat (cryptolocker)
2. Tahallinen väärinkäyttö (henkilöriskit)
3. Haavoittuvuudet (suuri määrä palvelimia)
4. Huolimattomuus (kiire, stressi, mobiili)
5. Mobiililaitteet (BYOD, Android..)
6. Sosiaalinen media (julkisuus tai julkaisu)
7. ”Social engineering” käyttäjän manipulointi (taloudellinen hyöty)
8. Zero-day exploits, uudet haavoittuvuudet, joihin ei ole korjausta
9. Pilviteknologia (saatavuus, käyttöehdot, eheys)
10. Vakoilu (innovaatiot)

5. Uhka on myös todellinen
• 21.1 2015 University of Oregon unlawfully releases 22,000 pages with confidential
faculty, staff and student records
• 16.1.2015 Hacker breached Metropolitan State University database with personal info
• 7.1.2015 University of Hawaii and Cornell University hacked by @MarxistAttorney
• 15.12.2014 Point Loma Nazarene University discloses breach after employees fall for
phishing scheme
• 13.12.2014 University of California – Berkeley discloses data breach
• 8.12.2014 Officials report University of Oklahoma nursing web server compromised
(updated)
• 14.11.2014 FL: Nova Southeastern University law students’ data hacked
• 16.10.2014 Marquette University suffers potential data breach on grad school
applications
• Suomalaisia unohtamatta…
Working Paper: Data Breaches in Europe: Reported Breaches of Compromised Personal
Records in Europe, 2005‐2014:
229 data breach incidents involved the personal records of people in Europe. Globally, all
these incidents resulted in the loss of some 645 million records.
http://www.databreaches.net/?s=university&searchsubmit=
http://www.databreaches.net/working-paper-data-breaches-in-europe-reported-breaches-of-compromised-
personal-records-in-europe-2005%E2%80%902014/

6. Projektit ja
tietoturva

7. Yleistä
• Luo projektille turvallinen paikka missä projektia hallitaan, huomioi
mahdolliset sidosryhmien tietoturvavaatimukset.
• Samaa asiaa saatetaan suunnitella useassa paikassa
– jotta kaikki relevantit tahot tietävät tulevista hankkeista
– turhaa päällekkäisyyttä ei esiinny
– varmistetaan että ei tehdä asioita politiikkojen vastaisesti
• Kaikki tarpeelliset ryhmät otettava mukaan riittävän varhaisessa vaiheessa
– Loppukäyttäjät, ”käytettävyyden ja vaatimusten tarkistus”
– IT-arkkitehdit
”varmistetaan sopivuus kokonaisarkkitehtuuriin”
– Tietoturva
”Tietoturvan, tietosuojan ja jatkuvuuden varmistus”
– Hankinta
”Kilpailutuksessa avustaminen, sopimukset”
• Pienistäkin asioista tulee tehdä dokumentaatiota

8. Esiselvitys johtaa Projektiin
Asiakkaan ja IT:n keskustelussa huomataan että tarvitaan
uusi ”Oikea” palvelu, alkaa yleensä Projekti
Tietoturvan, tietosuojan ja jatkuvuudenhallinnan
näkökulmasta tärkeimmät:
• Esiselvityslomake (tarve, sisältö, kenelle)
• hankinnan vaatimusmäärittelypohjat (kaikki tarpeet myös
toteutuu)
• Sopimukset, erit. NDA sopimus (auditointipykälä)
• projektien tietoturvaohjeet (turvallisuus toteutuksen aikana)
• jatkuvuussuunnitelma (toteutus toimii jatkossakin)
Aallon malli hankkeen läpiviemiseksi

9. Yksi tapa jakaa projektin vaiheet
Projektin vaiheet, tietoturvan näkökulmasta
Valmistelu,
esiselvitys
Projektin
suunnittelu
Testaus ja
käyttöönotto
Tuotteistus,
Käyttö
Käytännöt ja vaadittava dokumentaatio vaihtelee, tässä jotain yleisimpiä
Esiselvitys,
Tarkistuslista
Tietoturvaohje
Vaatimusmäärittelyt
-Omat politiikat
-Tietoturvatasot
-Katakri
-Lainsäädäntö
Jatkuvuussuunnitelma
Projektin Toteutus
Projektin riskienhallinta
Käyttöikeudet
palomuuriavaukset
kulkuluvat
Vaatimusmäärittelyt
Kilpailutus
Sopimukset
Testaussuunni-
telma, tietoturva-
auditointi,
tietoturvaskannaus
Tietoturvan
tarkistuslista,
aineiston
luovutukset,
seloste,
käyttäjien ja
ylläpidon ohjeet

10. Esiselvitys (”valmisteluvaihe”*)
Hyvä tapa on tarkistuslista** jota voidaan käyttää ensimmäisessä
Asiakastapaamisessa.
Käytännössä tämä tulisi tehdä jo ennen projektia (sen kuka asiakkaan ja
käyttäjän kanssa asiasta keskustelee), todellisuudessa jää usein
projektipäällikölle
*Aallon projektienhallinnassa käytettyjä termejä
**Saa pyynnöstä

11. Projektin tietoturvariskien hallinta
Projektia aloitettaessa tulee tehdä riskienhallintasuunnitelma
(liitä projektisuunnitelmaan). Riskejä tulee seurata
säännöllisesti koko projektin ajan, vähintään joka toinen
kuukausi. (sykli riippuen projektin pituudesta)
Analyysissä tulee arvioida ainakin luottamussuhteen
syntymistä ja säilyttämistä, toteutettavan ”Järjestelmän”
riskejä, tietojen käyttöön saamista, tietojen varmistamista,
käytettävyyttä, kiistämättömyyttä ja eheyttä sekä tietojen
luottamuksellisuuden määrittämistä ja takaamista.
Oleellista on kohdistaa ehkäiseviä toimenpiteitä
vaikutuksiltaan vakavimpiin ja todennäköisimpiin riskeihin.
(Esimerkki tietoturvariskilista jaetaan osallistujille)

12. Esiselvityksen vaikeimpia, tietosisältö?
Periaatteessa yksinkertainen, käytännössä vaikea.
Aallon julkiseksi linjattu
luokitteluohje:
• julkisuus ja tietosuojaohje
• tietoaineistojen luokittelu
• käsittelysäännöt
(saa pyynnöstä)
IT: Mitä palvelu sisältää?
Asiakas: projektisuunnitelmia, pöytäkirjoja,
lähdeaineistoa
IT: Ei kun mitä se sisältää? Tietosisältö?
Asiakas: ????
Eli näin: onko esim: psykologisia arvioita, merkittävän
tutkimuksen ratkaiseva tieto, Turvallisuustiedot,
sopimuksin salattava tieto..

13. Tietosisältö
Tärkeysluokit-
telu, SLA
Saatavuus
3. Tärkeys-
luokka
(normaali)
2. tärkeys-
luokka
(tärkeä)
1. tärkeys-
luokka (erittäin
tärkeä)
Säilytys-aika
10, 5, 1
vuotta?
Tiedon
elinkaari
Säilytys-
muoto
Metatiedon
käsittely
Ei
salassapito-
vaatimuksia
Sisäinen Luottamuksel-
linen,
ST IV, ST III
Tietoturva- ja tietosuoja ok, mutta entä
Järjestelmän/palvelun eheys ja Jatkuvuus?
Asiakkaan, tai Omistajan on nämä määriteltävä!
IT:n tulee toki auttaa
Vaatimukset
projektille

14. Vaatimusmäärittelyt, ~ 2 vko- 2 kk
(toki toiminnalliset, käytettävyys..)
Tietoturva:
•dokumentointi
•lainsäädäntö
•Pääsynhallinta
•lokit
•suojaus
•ylläpito ja hallinta
•maantieteellinen sijainti

15. Tietoturvavaatimuksia, (muista C- I – A)
• Yleinen
• järjestelmän toteutuksessa on otettu huomioon OWASP Top 10
Tietoturvariskit
• auditoinnin mahdollisuus
• Dokumentointi
• toimittaja vastaa että järjestelmä ja sen tietosisältö on
dokumentoitu.
• Lainsäädäntö
• järjestelmä täyttää lainsäädännön henkilötietojen käsittelylle tai
lokitukselle asettamat vaatimukset.
• Arkistolaki, yliopistolaki, Henkilötietolaki, TeTsl
• Pääsynhallinta
• Shibboleth autentikointi, tai jos on ulkopuolisia käyttäjiä niin
kunnollisesti toteutettu kirjautuminen
7/11/2016
15

16. Tietoturvavaatimuksia
• Lokit
• Vaativa asia, käytä pohjana Katakri, VAHTI-ohjeet
• lokeihin kohdistuu paljon vaatimuksia, lainsäädäntö, teknisen
toiminnan varmistaminen, pääsynhallinnan valvonta, tietosuojan
valvonta
• Suojaus
• kaikki järjestelmän verkkoliikenne salataan
• salasanoja ei säilytetä selkokielisenä.
• Ylläpito ja hallinta
• palvelun tuottajan ylläpito- ja hallintakäyttäjille on henkilökohtaiset
käyttäjätunnukset.
• järjestelmän otetaan säännöllisesti varmuuskopiot.
• Maantieteellinen sijainti
• järjestelmän tarvitsemat fyysiset laitteet ja järjestelmän sisältämä
materiaali sijaitsee EU alueella. Tietosuojadirektiivin mukaisesti
tietosuojan taso pitää olla vastaava kuin EUssa.
7/11/2016
16

17. Tietoturvavaatimuksia (pelkkä perussetti 52 kpl) ”CIA”
7/11/2016
17

18. Lopetusvaihe, tarkistuslista
7/11/2016
18
1. Kaikkeen aineistoon ja työmateriaaleihin on merkitty projektipäällikön vahvistama turvallisuusluokitus siten,
että materiaali on luovutuskunnossa. (luokitus tulossa 2012)
2. Synnytetty työ- ja välidokumentaatio on hallinnassa.
2 a. Kaikki hävitettäväksi päätetty projektin materiaali (sähköinen, paperi, muistivälineet) on hävitetty
raportoidusti organisaation ohjeiden määrittämällä tavalla:
Tietoaineistojen hävittäminen
2 b. Kaikki taltioitava työ- ja välidokumentaatio on luovutettu ohjausryhmän päättämille tahoille, vahvistettu
turvallisuusluokitus merkittynä, ja materiaali on tarvittaessa kirjattuna haltijoiden diaariin (dokumentit tulee olla
luetteloitu)*.
3. Projektiin osallistuville on selkeästi kerrottu projektin loppumisen jälkeiset vastuut tietoturvallisuudesta ja
vastuut seuraaville vaiheille on luovutettu.
4. Palvelun käytöstä on ohjeistus, jossa huomioidaan tietoturva (esim. raporttien ja tietokantahakujen
vieminen/tallentaminen järjestelmän ulkopuolelle)
4. a. Ohjeilla on omistajat ja he tarkistavat ohjeet tarvittaessa ja vuosikellon mukaisesti
4 b. Mahdolliset asennusohjeet (työasemalle sekä palvelimelle) huomioivat tietoturvallisuusvaatimukset.
5. Palvelusta on Aallon IT-jatkuvuussuunnitelman mallipohjan mukainen jatkuvuussuunnitelma.
6. Tietosisältö on kuvattu (usein osana rekisteriselostetta).
7. Rekisteriseloste / tietosuojaseloste on tehty ja sijoitettu käyttäjien saataville (tarvittaessa).
8.Tietojärjestelmäseloste on tehty ja sijoitettu käyttäjien saataville (tarvittaessa).

19. Projekti
Innovatiivinen,
ketterä, Agile

20. Projekti – perinteinen ”vesiputousmalli”
Perinteinen vai ketterä
Vaatimusmäärit
tely
Projekti Testaus Käyttö
Innovatiivinen projekti – Agile
Lista
ominaisuuksi
a
Toteutus
työlistan
mukaan
Esim 2 asiaa/
vko.
Tuote tai
tuotteen osa
GO/NO GO
Käyttö
.
Menetelmiä esim Scrum, Extreme Programming (XP), DSDM
Projektiteamillä suuri vapaus mutta myös vastuu!
Tietoturva pitää saada osaksi prosessia ja tekemistä. Esim. säännöllinen
testaus. Riskejä saatetaan hyväksyä tuntematta kokonaisuutta,
liiketoimintariskit, tms. Vaatimusmäärittely ei ole enää niin suuressa
roolissa tai sitä ei edes ole.

21. Ketterä tai iteratiivinen toimintatapa
Huomioi:
• asiakas ei osaa pyytää turvallisuutta,
(tietoturvaominaisuuksia)
• vaatimukset tyypillisesti avoimia
• ei voi olla puoliksi turvallinen järjestelmä
• missä vaiheessa voidaan testata julkisesti, ota huomioon backlogin
priorisoinnissa (kirjautumisen toteutus vs, avataan nettiin)
• tietoturvaan liittyen tulee yleensä toiminnallisia ja ei toiminnallisia
vaatimuksia
• backlog muutokset iteraatioiden välillä tulisi tehdä niin että jos jotain
oleellista muuttuu tai tulee joku uusi ominaisuus/komponentti/ ,
tehdään uusi riskiarvio tai tietoturvapohdiskelu. Tiimin osaaminen
suuressa roolissa. (tämän prosessin ei tarvitse olla raskas)

22. Tietoturva ”user stories” (backlog item)
Asiakkaat eivät tyypillisesti tiedä mitä he haluavat
(vaatimusmäärittelutasolla) joten miten he pystyisivät ilmaisemaan
turvallisuusvaatimukset. Mutta esimerkiksi näin:
• Käyttäjä: ”Haluan nostaa rahaa ja katsoa tilini tiedot selaimella”
• Tulisi olla: ”Haluan olla ainoa, joka voi käyttää tiliäni jotta voin pitää
tietoni salassa.”
• Tulisi olla: ”Haluan että tietoni salataan siirron ja tallennuksen aikana
jotta kukaan ulkopuolinen ei pääse niihin”
• Talousjohtaja, esim näin: ”Haluan olla ainoa, joka
voi muokata Henkilöstön palkkoja
• ylläpitäjä, esim näin : ”haluan lokittaa kaikki turvallisuuteen liittyvät
tapahtumat”
• väärinkäyttötapaukset/hyökkääjä tarinat
– Jos vaikka tehdään autentikointiin liittyvää komponenttia niin testauksessa tulee
keskittyä epäonnistuneisiin autentikointeihin, pyritään esimerkiksi tunkeutumaan
järjestelmään.

23. ”Misuse cases”
Wikimedia Commons
Opiskelija tekee
tunnuksen
järjestelmään
Tunnus kaapataan
liikenteestä
Tunnus vuotaa
palvelimelta
Backlog items:
• SSL salattu liikenne
• Salasanat hash+suolaus+etc

24. Järjestelmässä on mahdollista määritellä eri tasoisia
käyttöoikeuksia.
Käyttöoikeudet annetaan käyttäjäryhmäkohtaisesti.
Käyttäjäryhmien määrää ei ole rajattu.
Järjestelmässä metatietokenttä voi olla tekstikenttä.
Poistettavien asioiden ja asiakirjojen säilyvät
järjestelmässä määritellyn ajan, jolloin ne olisivat
vielä asiakirjahallintopääkäyttäjän palautettavissa
(vrt. ”roskakori”).
Käyttäjä voi muuttaa asian / asiakirjan / liitteen
julkisesta osittain salaiseksi tai salaiseksi ja valita
THS:n mukaisen salassapitoperusteen.
Julkisessa asiassa voi olla luottamuksellisia
asiakirjoja.
Julkisella asiakirjalla voi olla luottamuksellisia
liitteitä.
Käyttäjäryhmiä / käyttäjiä on pystyttävä lisäämään ja
poistamaan kesken asian käsittelyn tai jo suljettuun
asiaan.
Määräaikoja sisältäviin asioihin ja asiakirjoihin on
mahdollista liittää ajallinen muistutus, joka voi olla
henkilökohtainen tai siihen voi liittää käyttäjiä ja / tai
käyttäjäryhmiä.
Suljetun asian voi tarvittaessa avata uudelleen
käsittelyyn.
Asian avaaja tai käsittelijä voi lähettää asian tietylle
käsittelijälle / käyttäjäryhmälle jatkokäsittelyyn
seuraavaa toimenpidettä varten.
Kun asia lähetetään edelleen, asiaan voidaan liittää
viesti.
Käyttäjän keskeneräiset asiat on mahdollista nähdä
koottuna.
Saapuneesta tehtävästä / toimenpidepyynnöstä tulee
ilmoitus käsittelijälle sähköpostitse.
Järjestelmä lähettää käsittelijälle sähköpostitse
muistutuksen määritellyin väliajoin käsittelemättömänä
olevista asioista.
Järjestelmä ilmoittaa ylläpitäjälle, mikäli järjestelmästä
on säilytysajan perusteella poistumassa asiakirjaryhmä.
Käyttäjä voi tuoda ja muokata asiakirjan seuraavissa
formaateissa järjestelmässä: Office, PDF jne.
Järjestelmän etusivunäkymässä on pikahaku-toiminto.
Kaikki asia-avausten ja asiakirjojen metatietokentät ovat
valittavissa haun piiriin.
Käyttäjä voi tallentaa ja nimetä omia hakuja.
Hakutulokset voi siirtää exceliin ja PDF:ksi
Käyttäjähallinnan auditointi on mahdollista kaikilla
tasoilla: ryhmän käyttäjät ja oikeudet; ryhmän
erillismääriteltyjen asioiden ja asiakirjojen käyttäjät;
käyttäjän ryhmät, roolit ryhmissä jne.
Raportit voi siirtää exceliin ja PDF:ksi.
Koodattavia asioita ”Backlog Items”
JEE!
https://www.owasp.org/images/c/c6/OWASP_AppSec_Research_2010_Agile_Prod_Sec_Mgmt_by_Vaha-Sipila.pdf

25. Projektin aikainen tietoturva
Vesiputous tai ketterä, samat asiat
Tulosta vaikka tämä ohjeistus tai jaa ainakin
”Tietoturvan huoneentaulu”*
(huomioi organisaation omat ohjeet, politiikat)
(*Aallon huoneentaulu pyynnöstä)

26. Tietoturvavastuut
Projektipäällikkö vastaa siitä, että tietoturva ei vaarannu projektin eri vaiheissa ja
että projektin lopputuotos on tietoturvallinen. Tietoturvaryhmän asiantuntijan
vastuulla on tietoturvavaatimusten oikeellisuus ja riittävyys suhteessa projektiin.
• Raportoida tietoturvapoikkeamista. kaikki projektin aikaiset tietoturvaa
vaarantavat tapahtumat ja uhkaavat asiantilat. Haittaohjelmatartunnat,
kalastelut, ym.
• Määrittää dokumenttien ja muun käytettävän materiaalin tietoturvallisuustaso
yhteistyössä projektin omistajan kanssa.
• Huolehtia, että riskianalyysi tehdään projektin eri vaiheissa.
• Määrittää projektin aikaiset vastuut, oikeudet ja periaatteet.
• Vastata työhön osallistuvan henkilöstön ohjeistamisesta, kouluttamisesta ja
valvonnasta.
• Vastata tiedon hallinnasta projektin aikana. Tietoa ei saa päästä vuotamaan
projektin aikana ihmisten tai tietojärjestelmien kautta.
• Varmistaa projektin loppuessa, että tarvittavat tietoturvadokumentit, kuten
jatkuvuussuunnitelma, rekisteriseloste tai tietoturvan huomioivat käyttäjien
ohjeet, on tehty

27. Ulkopuolisen asiantuntijan käyttö
Mahdollisen ulkopuolisen asiantuntijan osalta projektipäällikön tulee
varmistaa:
• Varmistuminen siitä, että ulkopuolinen asiantuntija sekä sitoutuu
periaatteisiin että kykenee myös täyttämään niiden vaatimukset.
• Yritystason turvallisuussopimusten ja auditointien tekeminen tarpeen
mukaan ennen yhteistyön käynnistämistä.
• Turvallisuussopimukset saa tyypillisesti organisaation
hankinnalta/Tietoturvaryhmältä/Lakitiimi.
• Ulkopuolinen asiantuntija saa tarvittavat tunnukset järjestelmiin.
Tarkista oikea prosessi
• Projektin henkilöstön ohjeistaminen toiminnasta ulkopuolisen
toimittajan kanssa, mahdollisesti projektisuunnitelman päivittäminen.
Jatkuvan valvonnan mekanismin luominen, ulkopuolisella asiantuntijalla
tulee olla nimetty yhteyshenkilö ja sopia työnteon ja kulkuoikeuksien
käytännöt.

28. Yritys- ja henkilöstöturvallisuus
Projekteihin saattaa kohdistua eri syistä ulkopuolista mielenkiintoa
(esim. media, muut yritykset). Näissä tapauksissa projektipäällikkö
päättää kenelle, projektin tietoja voi luovuttaa ja tarvittaessa suorittaa
luovutukset itse. Kaikki hanketta koskeva tiedottaminen on
projektipäällikön vastuulla, kenenkään projektissa ei tule tiedottaa
projektin asioista ilman projektipäällikön valtuutusta. Tietojen
luovutuksesta tulee aina keskustella myös hankkeen omistajan tai
asiakkaan kanssa.
Matkustettaessa yleisissä kulkuneuvoissa tai oleiltaessa yleisissä
tiloissa tulee projektin luottamuksellisia tietoja kuljettaa suojattuina
sekä käsitellä siten, että ulkopuoliset eivät niitä saa tietoonsa.
Dokumentit voidaan hävittää hankkeeseen osallistuvien
organisaatioiden tietoturvamateriaalin hävittämismenettelyillä, usein
silppuamalla aineisto vaatimukset täyttävällä silppurilla.
(tietoturvaohjeet, huoneentaulu, käsittelysäännöt)

29. Fyysinen turvallisuus
Tilojen, joissa työtä tehdään, on oltava äänieristykseltään,
näkösuojaltaan, kulunvalvonnaltaan ja murtosuojaukseltaan
sellaiset, että niissä käsiteltävän luottamuksellisen tai
salaisen tiedon joutuminen projektin kannalta ulkopuolisen
haltuun ei ole mahdollista.
Tilojen valinnassa ja käytössä on huomioitava tietojen
suojausluokan vaatimukset. Työn tekemistä johtava henkilö
vastaa siitä, että tilat täyttävät edellä kuvatut vaatimukset ja
ettei tilojen käytön loppuessa niihin jää mitään
tietoturvallisuuden kannalta arkaa materiaalia.
Työtä voidaan tehdä ulkopuolisissa tiloissa, jotka täyttävät
edellä kuvatut vaatimukset.

30. Ohjelmistoturvallisuus
Turvallisuuden ja tiedon eheyden varmistamiseksi projektissa
tulee käyttää vain mukana olevien organisaatioiden
tietohallinnon tukemia ja ylläpitämiä ohjelmistoja.
Ohjelmistojen pitää olla päivitettyjä, erityisesti relevanteista
tietoturvapäivityksistä tulee huolehtia ilman tarpeetonta
viivytystä.
Hyvään dokumentin hallintaan kuuluu sopiminen
tallennuskäytännöistä sekä varmistuksesta. Dokumenteista
on säilytettävä aiempia versioita sekä varmistettava, että
materiaali on varmuuskopioitu. Dokumentit, joita ei enää
muokata, kannattaa mahdollisuuksien mukaan lähettää oman
organisaation ulkopuolelle pdf-muodossa (huomioi myös
dokumenttien piilotiedot).

31. Tietoliikenneturvallisuus
Sähköpostilla välitettävä luottamuksellinen tieto on suojattava
salaamalla liitetiedostot paketeiksi. Nykyään voidaan
salauksen minimitasona käyttää erittäin turvallista AES 256
salausta (käytä esimerkiksi ilmaista 7-Zip ohjelmaa)
Ennen menetelmän käyttöönottoa on kuitenkin selvitettävä
sen soveltuvuus projektin eri osapuolien välillä.
Projektin käyttöön voidaan avata sähköinen ryhmätyötila,
jonka käyttö on ohjeistettava erikseen luottamuksellisen
materiaalin osalta. Ryhmätyötilan käytöstä päättävät
osallistuvat organisaatiot keskenään silloin, kun se käyttö on
mahdollista. Projektin työtilaa ei tule normaalista avata
julkiseksi vaan laatia käyttöoikeuksiin perustuva hallinta.
.

32. Kiitokset!