Lausunto Sovelluskehityksen tietoturvaohjeluonnoksesta
|
|
- Maria Järvenpää
- 6 vuotta sitten
- Katselukertoja:
Transkriptio
1 Lausunto 1 (7) Ari-Pekka Lehtonen Tulli Dnro 14/930/12 VM Dnro 047:14/2007 Valtiovarainministeriö Julkisen hallinnon ICT-toiminto PL VALTIONEUVOSTO valtiovarainministerio@vm.fi Tullihallituksen lausunto lausuntopyyntöön dnro 14/930/12 (VM dnro 047:14/2007) Lausunto Sovelluskehityksen tietoturvaohjeluonnoksesta Johdanto Tullihallituksen lausunto sovelluskehityksen tietoturvaohjeluonnoksesta on Tullilaitoksen tietohallinnossa laadittu lausunto, jonka valmisteluun ovat osallistuneet Arkkitehtuurit-ryhmän tietoturva-arkkitehti, sovelluskehityksen tietoturva-asiantuntija, tietoturva-asiantuntija ja Tullin turvallisuuspäällikkö. Tullin tietohallinto vastaa Tullin teknisestä IT-tietoturvasta, jonka yhtenä osa-alueena on järjestelmäkehityksen tietoturvallisuuden varmistaminen. Tullihallitus katsoo sovelluskehityksen tietoturvaohjeen antamisen olevan tarpeellista, jotta organisaatioiden sovelluskehityksen tietoturvallisuuden varmistamista voidaan yhdenmukaistaa ja ohjata hyvien käytäntöjen mukaisiksi. Yleistä sovelluskehityksen tietoturvaohjeesta Sovelluskehityksen tietoturvaohje on odotettu ja erittäin tarpeellinen hallinnonalojen toimijoiden järjestelmäkehityksen tietoturvallisuuden varmistamiselle hyvien käytäntöjen mukaisesti. Sovelluskehityksen tietoturvaohje arvioidaan hyödylliseksi ja hyvin toimivaksi käsikirjaksi, johon on koottu keskeiset hyvät käytännöt. Ohjeessa käytetty sovelluskehitysmalli ja sen vaiheisiin liitetyt tietoturvallisuuden varmistamisen tehtävät vastaavat hyvin pitkälle Tullissa käytössä olevaa systeemityömallia. Näkemyksemme mukaan ohje voisi hyvin täydentää Tullin olemassa olevaa ohjeistusta. Vaatimusten esittäminen tietoturvatasoittain on hyvä asia, joka auttaa konkretisoimaan tietoturvatasojen merkitystä sovelluskehityksen eri vaiheissa ja tuotoksissa. Viittaukset Kansallisen turvallisuusauditointikriteeristön vaatimuksiin ovat tervetulleita, koska ne on suositeltavaa vähintäänkin tiedostaa tietoturvatasovaatimusten lisäksi. Konkreettisempia KATAKRI-vaatimuksia on usein helpompi toteuttaa hankkeissa, koska ne eivät vaadi niin paljon tulkintaa kuin tietoturvatasojen vaatimukset. Vaatimusten velvoittavuus ei kuitenkaan käy selkeästi ilmi ohjeesta, mutta tieto on usein löydettävissä viitatusta lähdedokumentista. Postiosoite Puhelin Faksi Sähköposti PL HELSINKI (09) kirmo@tulli.fi
2 Lausunto 2 (7) Olisi silti toivottavaa, että kaikki valtion organisaatioiden tietoturvallisuutta koskevat ohjeet voitaisiin paketoida yhdeksi vaatimuskokonaisuudeksi, josta on poistettu päällekkäisyydet. Tietoturvatasojen ja KATAKRIn vaatimusten yhdistäminen olisi näkemyksemme mukaan toivottavaa. Viittausten käytössä olisi toivottavaa, että lukija voisi tekstin ulkoasusta päätellä mikä on lainattua tekstiä (esim. lainattu vaatimuslause kursiivilla) ja mikä on tämän ohjeen omaa sisältöä. Kun viittauksia käytetään tekstissä kappaleiden lopussa olevissa taulukoissa, niin olisi toivottavaa että viittaus tarkennettaisiin osoittamaan lähdedokumentin lukuun tai vaatimuskorttiin. Joiltain osin viittauksia ulkoisiin ohjeisiin on hyvin runsaasti, mm. lokitietojen käsittelyn osalta. Näitä voisi kenties tiivistää jossain määrin. Tekstin joukossa olevat viittaustaulukot heikentävät jossain määrin ohjeen luettavuutta, mutta ovat toisaalta tarpeellisia. Viittauksiin olisi suositeltavaa kattavuuden varmistamiseksi lisätä OWASP Top 10 ohjeet. On myös huomattava, että vaatimusten ja ohjeiden kopioiminen lähdedokumenteista on ylläpidettävyyden kannalta haasteellinen ratkaisu, silloin kun lukuisat viitatut dokumentit päivitetään uudempaan versioon. Ohjeen jaottelussa voisi vielä selkeämmin jakaa omiin lukuihinsa organisaation yleisen sovelluskehityksen tietoturvallisuuden hallinnan ja hankekohtaisesti noudatettavat ohjeet, jotta eri kohderyhmät löytäisivät tarvitsemansa tiedot helposti. Uhka-analyysin ja muidenkin tehtävien kuvaukset tuntuvat toistuvan useammassa kohdassa ohjetta, tätä olisi hyvä selkiyttää mahdollisuuksien mukaan. Ohjeessa olisi lisäksi hyvä painottaa organisaation sisällä toimivan ohjeita ja konsultointia tarjoavan sovelluskehityksen tietoturvallisuuden asiantuntijatahon merkitystä toiminnalle. Tällaista suositellaan mm. BSIMM3-mallissa. Sisältökohtaiset kommentit Kpl 1.1, toinen kappale: sovelluksen avulla käsiteltävät luottamukselliset tiedot pitäisi olla salassa pidettävät? Kpl 1.2, sivu 6 Tehtävät ja vaatimukset voisi jakaa kahteen pääosaan: organisaatiotason tietoturvallisuuden hallinta ja projekti tietoturvallisuuden hallinta. Lisäksi vaihe Uhkien mallintaminen on yhden projektin vaiheen tehtävä, kun taas muut esitetyt kohdat ovat projektin vaiheita. Se tulisi poistaa luettelosta? Kpl 2.2, sivu 9 Haasteita sovelluskehityksen tietoturvassa luettelo voisi sisältää myös kohdat defensiivinen ohjelmointi, virheiden sietokyky (robustness), ennalta määrittelemättömiin tilanteisiin varautuminen ja niistä suoriutuminen turvallisesti. Kpl 2.3, sivu 11 Ketterien sovelluskehitysmenetelmien viittaukset tulisi muuttaa esitysmuotoon, jossa on selväkielinen nimi ohjeiden julkaisijaan ja sen lisäksi linkki (URL) esim. alaviitteenä. Kpl 2.4, kuva 3 Esitutkimusvaihe: emme pidä ulkoisen auditoijan käyttämistä esitutkimusvaiheessa olennaisena. Katselmointi on yleensä riittävä keino. Lisäksi auditoijan käyttö on merkitty Käyttöönotto-vaiheeseen, mutta näkisimme sen kuuluvan jo edeltävään Testaus-vaiheeseen. Vasta auditoinnin hyväksytyn läpimenon ja
3 Lausunto 3 (7) mahdollisten puutteiden korjauksen ja niiden uudelleen testaamisen ja tarkistamisen jälkeen voidaan edetä käyttöönottoon. Taulukossa olisi hyvä olla mukana roolina Sisäinen tarkastus / tietojärjestelmätarkastus, joka on esitetty taulukkoa seuraavassa tekstikuvauksessa. Rooleihin voitaisiin lisätä organisaation tietoturvaryhmä tai vastaava toimielin, jonka tehtävänä on hyväksyä keskeisten vaiheiden tietoturvatuotokset (katselmointi), vrt. BSIMM3 SSG, Sofware Security Group. Kpl 2.6, sivu 15 Tietoturvaryhmän asiantuntijatuki ja yhteisesti hyväksytyt tietoturva-arkkitehtuurit, linjaukset ja standardit olisi hyvä huomioida, (vrt. BSIMM3 standards and requirements). Kpl 2.7, sivu 15 Tietoturva-arkkitehtuuri tulee ottaa huomioon, erityisesti se, kuinka laajasti toteutus nojautuu organisaation hyväksyttyyn arkkitehtuuriratkaisuun ja yhteisiin teknisiin komponentteihin (BSIMM3: Security Features and Design). Kpl 2.8, sivu 16 Noudatettavat standardit (sisäisetkin) on listattava, liittyen toteutukseen, suunnitteluun, testaukseen jne. (BSIMM3: Standards and Requirements, level 2) Kpl 2.10, sivu 17 SaaS-palvelussa täytyy varmistua siitä, että auditoinnin lisäksi järjestelmän tietoturvan taso voidaan varmistaa myös arkkitehtuuritasolla, ts. että saadaan riittävä selvitys tietoturvaarkkitehtuurista (esim. autentikointiratkaisut ja tietosisällön tekniset suojaukset). Kpl 3.1.1, STR-002 Riskienhallinnassa olisi syytä kiinnittää huomiota liiketoiminnalle merkityksellisiin riskeihin. Esimerkiksi reverse engineering ei ole riski vaan tekninen hyökkäystapa, johon voi liittyä liiketoimintariskiä (esim. IPR-rikkomus). Sellaisenaan se ei itse ole riski. Kpl 3.1.2, POL-006 Lokipolitiikka on irrallinen asia, jonka rinnalle voisi mainita monta muutakin politiikkaa (esim. Open Source -komponenttien käyttöpolitiikka). Tämä lienee tosin ainoa, johon on suora VAHTI-ohjeistus olemassa. Kpl 3.1.3, OSK-001 Koulutuksen uusiminen samoille henkilöille vähintään vuoden välein on käytännössä liian usein. Koulutus on tarpeen uusille henkilöille tai kun tekninen ympäristö muuttuu suuresti. Kpl 3.1.3, OSK-003 Henkilöille tulee esitellä tietoturvaryhmä tai muu taho, jolta saa apua tarvittaessa tietoturvaratkaisujen laatimisessa. Kpl 3.1.3, OSK-006 Tämä on enemmänkin perustason vaatimus. Security coachin (tai security groupin) tulee olla tiiviissä yhteydessä arkkitehtuurin kehittämiseen ja käytännön sovelluskehitystyöhön. OSK-007 ja OSK-008 ovat varsin yleisellä tasolla esitettyjä.
4 Lausunto 4 (7) Kpl 3.1.4, STA-001 Ulkoisten kirjastojen luokittelu ei ole käytännössä mahdollista muuten kuin sitä kautta, mitkä sovellukset niitä käyttävät. (Edellyttää komponenttien mäppäämistä sovelluksiin.) Komponenttien osalta luokittelu ei ole perustason vaatimus, vaan se tulisi edellyttää jollakin ylemmällä tasolla. Kpl Komponenttikirjastot tulee säilyttää paikallisena kopiona repositoryssä, ja repositoryn päivittäminen kirjastojen kehittäjiltä tulee hoitaa hallitusti (jolloin mm. kirjastoversioiden ja niiden eheyden hallinta tulee hoidettua). Kehittäjien ei tule käyttää ulkoisia repositoryjä. Käytetyistä ulkoisista komponenteista ja niiden versioista tulee pitää kirjaa, sekä tietoa siitä, missä sovelluksissa tai muissa arkkitehtuurin komponenteissa niitä on käytetty. Tämä mahdollistaa mm. komponenttihaavoittuvuuksien hallinnan. Kpl 3.3 Uhkien mallintaminen ei kronologisesti tapahdu ennen vaatimusmäärittelyä, vaan vaatimusmäärittelyn ja suunnittelun aikana (ks. edellisen sivun kuva!) Suositeltavaa olisi suorittaa uhkien hallinta näin: - vaikutusanalyysi esitutkimuksessa (business impact analysis) - ns. liiketoimintauhkien (worst-case scenarioiden) kartoitus vaatimusmäärittelyvaiheessa - uhkapuun laatiminen/täydentäminen suunnitteluvaiheessa (jossa huomioidaan myös tekniset ratkaisut) Tämä soveltuu myös ketterään malliin. Kpl BIA (business impact analysis) / tietoriskien arviointi ja järjestelmän luokittelu tulisi toteuttaa esitutkimusvaiheessa. Se luo pohjan seuraavien vaiheiden tietoturvatyölle. Kpl Varsinkin vaatimusmäärittelyvaiheessa on järkevää keskittyä liiketoimintauhkiin teknisten uhkien sijasta. Tekniset uhkat voidaan tunnistaa vasta, kun teknologia on määritetty. Käytännössä järkevää olisi edellyttää, että järjestelmän liiketoimintauhkat saataisiin listattua, ilman vaatimusta että niille pitää kyetä löytämään esiehdot. Uhka-analyysi tulisi tehdä suunnitteluvaiheessa. Kpl 3.3.3, VTM-001 Viitataan esisuunnitteluvaiheeseen, pitäisi olla esitutkimusvaihe? Mitä tarkkaan ottaen ohjeessa kuvatun analyysin tuotteena saadaan? Eikö nuo korkean tason sovelluksen tietoturvavaatimukset ole jo se mitä esitutkimuksessa on laadittu? Pitäisikö tässä listata, että analyysi tuottaa tietoa järjestelmän suojattavista kohteista C/I/Anäkökulmasta, tai jotain muuta? VTM-003 Olennaisesti sama tehtävä kuin UHM-001? VTM-004: Tietoturvavaatimusten määrityksessä tulisi hyödyntää uhka-analyysiä mahdollisimman paljon, jotta vaatimusten jäljitettävyys todellisiin liiketoimintauhkiin toteutuu. Sikäli kun
5 Lausunto 5 (7) uhka-analyysi ei kata kaikkea, yleisiä käytäntöjä, määräyksiä jne (ks. VTM-005) on syytä hyödyntää. VTM-006 Abuse caset ovat vain yksi tapa tehdä uhka-analyysiä. Myös muut järjestelmälliset tavat tulee sallia. Abuse caset eivät esimerkiksi toimi ei-toiminnallisten vaatimusten kanssa eivätkä välttämättä löydä tapauksia, jotka toistuvat kauttaaltaan sovelluksessa (esim. CSRF, XSS-pohjaiset hyökkäykset). Kpl 3.3.4, SNT-004 Nämä tulisi olla ennemminkin arkkitehtuuri- ja sovelluskehitysohjeistuksessa, ja näitä tulisi katselmoida design- ja koodikatselmoinneissa. SNT-006 Hyökkäyspinta-alan (attack surface) suomenkielinen vastine lienee hyökkäyspinta? Hyökkäyspinta määrittyy niihin kohtiin, joissa osapuolet eivät voi luottaa toisiinsa täysin varauksetta (usein myös esim. sovelluspalvelimen ja tietokannan välille). Toisinaan hyökkäyspintoja on samankin palvelimen sisällä, esimerkiksi jos palvelimella ajetaan useampaa sovellusta. SNT-007 Tietoturvavaatimukset on jo kerätty määrittelyvaiheessa, joten haastatteluja yms. ei tarvita tässä vaiheessa. Arkkitehtuuri pitää katselmoida vaatimuksia vasten (ja mielellään myös toisinpäin). SNT-008 Tulee olla policy, että käytetään yhteisiä hyväksyttyjä tietoturvaratkaisuja. Policyä valvotaan suunnittelukatselmoinneissa ja toteutuksen edetessä koodikatselmoinneissa. SNT-009 Omistajan vastuulla on määritellä tarvittavan tunnistautumisen vahvuus, ei tiettyä tunnistautumismenetelmää (ellei sillä ole muuta varsinaista merkitystä esim. käyttäjäryhmän takia). Erityisesti tulee välttää tilannetta, että sovelluksen omistaja keksii vaatia tarpeettomasti jotain tiettyä tunnistautumistapaa, jolle ei tietoturva-arkkitehtuurista löydy toteutusta, kun yhtä hyvin voisi käyttää toista yhtä vahvaa tapaa, jolle jo löytyy tuettu toteutus. SNT-010 Salasanojen käsittelyä sovelluksissa tulisi välttää; sen sijaan ne pitäisi pitää LDAP:ssa tms, jonne ko. laatuvaatimukset voidaan toteuttaa. SNT-011 Tämä least privilege -periaate pätee myös esimerkiksi tietokantatunnuksiin, jossa esimerkiksi tietokantaskeeman muutokset on usein järkevä estää sovelluksen tunnukselta. SNT-012 Trust boundary on usein sama kuin hyökkäyspinta. SNT-014
6 Lausunto 6 (7) Rainbow tableja vastaan auttaa ennemminkin vahvempi suola. Brute forceen auttaa moninkertainen hashaus. Salasanalauseiden käyttö tai käyttämättömyys on lähinnä käyttäjäohjeistuksen asia. Testiympäristössä käytetyt salausavaimet pitää ilman muuta vaihtaa tuotantoympäristöön siirryttäessä. SNT-015 Data sourcen käyttö tässä yhteydessä ei avaudu lukijalle. Kpl 3.3.5, TOT-001 Toteutukseen liittyviä ohjeistuksia ja huomioitavia asioita: - defensiivinen ohjelmointi (erittäin tärkeä!) - toteutukseen liittyen code review on syytä mainita - toteutusta tukemaan on syytä olla olemassa turvallisen kehityksen ohjeistus ja/tai referenssisovellus - arkkitehtuuriratkaisujen tulisi toteuttaa mahdollisimman suurelta osin tietoturvatoiminnot, pienentäen sovellusten vastuulla olevien asioiden määrää Joitain teknisiä ohjeita puuttuu, mm.: - injektiohyökkäysten välttäminen (oikea enkoodaus oikeassa kontekstissa, variable binding jne): olennaista tunnistaa sovelluksesta kaikki kontekstit, joissa injektio voi syntyä - XSS-suojautuminen on syytä mainita erikseen, ongelman yleisyyden ja vakavuuden vuoksi - insecure direct object reference - ongelman välttäminen - tiedostojen käsittelyn vaarat (mm. että tiedostopolku täytyy validoida huolellisesti, jos se on saatu käyttäjältä) - em. teknisten ohjeiden osalta järkevintä olisi kai viitata olemassa olevaan ohjeistukseen, esim. OWASP, CERT, SANS jne TOT-002 / TOT-003 Lokiohjeeseen voisi viitata ja vähentää lainauksia? Nämä lokien käsittelyyn ja tuottamiseen liittyvät ohjeet ovat epäsuhdassa sen kanssa, mitä teknisiä toteutusseikkoja tulee ohjelmistokehityksessä huomioida tietoturvan osalta. Erityisesti on syytä huomata, että oikein järjestetty sovellusarkkitehtuuri tarjoaa sovelluksille lokituskomponentin, jossa valtaosa näistä ohjeista voidaan huomioida. Tällöin sovelluskehityksessä asioita ei tarvitse huomioida muuten kuin käyttämällä ko. komponenttia. Olisiko järkevämpää viitata ko. VAHTI-ohjeeseen tai koostaa nämä ohjeet omaksi liitteekseen? Onnistunutta syötteenkäsittelyä harvemmin on järkevää kirjata. Se myös tuottaa valtavat määrät tietoa. Sama voi päteä onnistuneisiin pääsynhallintapäätöksiin. Tässä puhutaan tietoturvalokista, mikä lienee syytä tähdentää (ks. kolmas bullet). TOT-006 Monet istunnon kaappaamisen estävät mekanismit ovat web-palvelimen tai järjestelmän arkkitehtuuriratkaisujen vastuulla, ei sovelluksen. CSRF-hyökkäys on eri asia kuin istunnon kaappaaminen. Siitä olisi järkevä olla oma suosituskohtansa.
7 Lausunto 7 (7) Kpl TST-001 Tietoturvatestitapauksia tulee kehittää aiempien löydösten tai insidenttien perusteella. Tietoturvatestitapaukset on järkevä jakaa teknisiin teknologiakohtaisiin testeihin, joissa voidaan käyttää yleistä ohjeistusta (esim. OWASP:lta), sekä sovelluskohtaisiin testitapauksiin, jotka voivat pohjautua esim. misuse caseihin. TST-004 Katselmoinnin tulokset tulee käsitellä samalla tavalla kuin muukin katselmointi: tietoturvakatselmointi on laadunvarmistusta ja -parantamista. Pöytäkirjan sijaan havainnot voidaan syöttää esimerkiksi bugienhallintajärjestelmään, suoraan ohjelmakoodiin, jne., riippuen käyttötarpeesta. Epäformaaleissa coachin tekemissä katselmoinneissa on järkevää välttää erityistä "tarkastusasetelmaa": tarkoitus ei ole tuomita vaan auttaa. Turvallisen sovelluskehityksen menetelmät ovat osa toteutusta, ei testausta. TST-005 Staattinen koodin analysointi, erityisesti riskeinä pidettyjen ohjelmointivirheiden osalta on suositeltavaa (esim. XSS- ja injektiovirheiden löytäminen). Porttiskannerin käyttö kehitysja testausympäristössä on harvoin järkevää. TST-006 Suositeltavaa olisi, että auditointi sisältää myös arkkitehtuuriratkaisujen arvioinnin, sisältäen mm. TST-007:ssa listattuja asioita. TOT-008 alkaen : onko merkinnän alku vahingossa vaihtunut ja pitäisi olla TST-? TOT-011 Voidaan edellyttää esimerkiksi, että kaikki haavoittuvuudet, joiden vakavuus (esim. CVSSarvo) on yli 3, tulee olla korjattuna, ennen kuin julkaisu voidaan tehdä. Kaikkia haavoittuvuuksia ei usein ole järkevää eikä aina mahdollistakaan korjata. Kpl 3.3.7, KTY-001 Tuotantoympäristössä pitäisi olla mekanismi, jolla voidaan reagoida nopeasti yllättäviin tietoturvatilanteisiin, estäen tunnistetun haavoittuvuuden hyväksikäytön. Tällainen mekanismi on esimerkiksi sovelluspalomuuri, joka voi suodattaa HTTP-liikennettä konfiguroitavien sääntöjen mukaisesti. Jos tällaista ei ole, joku muu vastaava mekanismi tulee olla, jolla ongelmaan voidaan reagoida nopeasti (esim. alle 24 h). KTY-021 Lokia ei voi tarkkailla manuaalisesti kuin satunnaisesti, sen pitää olla automaattinen tarkastelu. Ari-Pekka Lehtonen Tietoturva-arkkitehti
Tietoturvallisuuden hallintajärjestelmä pähkinänkuoressa
Tietoturvallisuuden hallintajärjestelmä pähkinänkuoressa Valtorin tietoturvaseminaari 2.4.2014 Pekka Ristimäki Johtava asiantuntija, CISM, CISSP, CRISC Valtori / Tietoturvapalvelut Mikä on hallintajärjestelmä?
LisätiedotTietoturvallisuuden kokonaisvaltainen hallinta Heikki O. Penttinen Castilsec Oy.
Tietoturvallisuuden kokonaisvaltainen hallinta 3.12.2015 Heikki O. Penttinen Castilsec Oy Tietoturvallisuuden päätavoitteet organisaatioissa Tietoturvallisuuden oikean tason varmistaminen kokonaisvaltaisesti
LisätiedotSähköi sen pal l tietototurvatason arviointi
Sähköisen palvelun l tietototurvatason arviointi Kirsi Janhunen Arviointia tehdään monesta syystä Itsearviointi Sisäinen arviointi Sisäinen tarkastus Vertaisarviointi Ulkoinen arviointi Lähtökohtana usein
LisätiedotOpas verkkopalvelun tietoturvan varmentamiseen
Opas verkkopalvelun tietoturvan varmentamiseen Haavoittuvuustutkimustiimi - 2NS www.2ns.fi 2/10 Johdanto Olemme vuodesta 2005 lähtien toteuttaneet yli 1000 verkkopalvelun haavoittuvuustestausta ja auditointia
LisätiedotTurvallisen sovelluskehityksen käsikirja. Antti Vähä-Sipilä, F-Secure
Turvallisen sovelluskehityksen käsikirja Antti Vähä-Sipilä, F-Secure antti.vaha-sipila@f-secure.com, Twitter @anttivs Tavoitteet Käsikirjan tavoitteena on tukea nykyaikaista, DevOps-henkistä ketterää ohjelmistotuotantoa
LisätiedotSuomi.fi - Tietoturvallisuus sovelluskehityksessä. VAHTI sähköisen asioinnin tietoturvaseminaari
Suomi.fi - Tietoturvallisuus sovelluskehityksessä VAHTI sähköisen asioinnin tietoturvaseminaari 3.10.2017 YLEISTÄ Suomi.fi-palvelut esuomi.fi Tietoturvallisuus sovelluskehityksessä Yleisiä periaatteita
LisätiedotVERKKOPALVELUN TIETOTURVAN VARMENTAMINEN
VERKKOPALVELUN TIETOTURVAN VARMENTAMINEN Tietoturvaopas1 2NS - Haavoittuvuustutkimustiimi www.2ns.fi 2/10 Johdanto Olemme vuodesta 2005 lähtien toteuttaneet yli 1000 verkkopalvelun haavoittuvuustestausta
LisätiedotSovellustietoturvallisuus Petteri Arola OWASP Chapter Leader Nixu Oy OWASP The OWASP Foundation
Sovellustietoturvallisuus 7.2.2012 Petteri Arola Chapter Leader Nixu Oy petteri.arola@owasp.org Copyright The Foundation Permission is granted to copy, distribute and/or modify this document under the
LisätiedotCase VRK: tietosuojan työkirjat osa 2. JUDO Työpaja #4 - tietosuoja Noora Kallio
Case VRK: tietosuojan työkirjat osa 2 JUDO Työpaja #4 - tietosuoja Noora Kallio Esityksen sisältö Tietosuojan hallintamalli Prosessi Työkaluina tietosuojan työkirjat Ratkaistava asia Miten tietosuoja-asetuksen
LisätiedotVIRTU ja tietoturvatasot
1 VIRTU ja tietoturvatasot VIRTU/HAKA seminaari 3.2.2010 Erja Kinnunen VK/VIP VIPin palvelut Tietoturvallisuuden viitekehys valtionhallinnossa Ei tietoturvallisuutta koskevaa erillislakia Valtioneuvoston
LisätiedotOnnistunut SAP-projekti laadunvarmistuksen keinoin
Onnistunut SAP-projekti laadunvarmistuksen keinoin 07.10.2010 Patrick Qvick Sisällys 1. Qentinel 2. Laadukas ohjelmisto täyttää sille asetetut tarpeet 3. SAP -projektin kriittisiä menestystekijöitä 4.
LisätiedotOhjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit
Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää
LisätiedotLaatua ja tehoa toimintaan
Laatua ja tehoa toimintaan Tietoturvallisuus osana laatua Kuntamarkkinat 12.9.2013 Aapo Immonen, Senior Manager, FCG konsultointi Oy 5.9.2013 Page 1 Sisältö Tavoitteet Tietoturvallisuutta ohjaavat tekijät
LisätiedotTietoturvan ja -etosuojan suhde sovelluskehityksessä. An6 Vähä- Sipilä Tietoturva ry SFS:n seminaari 26.11.2013 avs@iki.
Tietoturvan ja -etosuojan suhde sovelluskehityksessä An6 Vähä- Sipilä Tietoturva ry SFS:n seminaari 26.11.2013 avs@iki.fi, TwiHer @an6vs TIETOTURVAN JA TIETOSUOJAN OLEMUKSIEN EROT Tietoturva LuoHamuksellisuus
LisätiedotOhjelmiston toteutussuunnitelma
Ohjelmiston toteutussuunnitelma Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1 1 Johdanto Tämä luku antaa yleiskuvan koko suunnitteludokumentista,
LisätiedotTIE Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori
TIE-21204 Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2 Antti Jääskeläinen Matti Vuori Työn yleiset järjestelyt 14.9.2015 2 Valmistautuminen Ilmoittaudu kurssille Lue harjoitustyön nettisivut
LisätiedotStandardien PCI DSS 3.0 ja Katakri II vertailu
Standardien PC DSS 3.0 ja Katakri vertailu Copyright Solinor Oy 2014 Solinor Oy, Teollisuuskatu 21 A, F-00510 HELSNK, FNLAND +358 10 279 2940 / www.solinor.com / Business D 17967170 Standardien PC DSS
LisätiedotLuonnos - VAHTI-ohje 2/2016 Toiminnan jatkuvuuden hallinta
Luo / Muokkaa Lähetä Lausunnonantajat Yhteenveto Luonnos - VAHTI-ohje 2/2016 Toiminnan jatkuvuuden hallinta Johdanto Kommentit ja huomiot - Johdanto Tiivistäisin alkuun jatkuvuuden määritelmän esim. seuraavasti:
LisätiedotTik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti
Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu TESTIRAPORTTI LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 1.1 Tila: hyväksytty Päivämäärä: 13.2.2001 Tekijä:
LisätiedotTIETOTURVALLISUUDEN UUDET ULOTTOVUUDET TOIMITILOISSA
TIETOTURVALLISUUDEN UUDET ULOTTOVUUDET TOIMITILOISSA TOIMITILAPÄIVÄ 21.3.2013 Johtava asiantuntija Fyysinen turvallisuus ja varautuminen Marko Kalliokoski Verohallinto 020 612 5192 etunimi.sukunimi@vero.fi
LisätiedotHAAVOITTUVUUKSIEN HALLINTA RAJOITA HYÖKKÄYSPINTA-ALAASI
HAAVOITTUVUUKSIEN HALLINTA RAJOITA HYÖKKÄYSPINTA-ALAASI VIHOLLISET EIVÄT TARVITSE USEITA HAAVOITTUVUUKSIA YKSI RIITTÄÄ 90 MIN välein löytyy uusia haavoittuvuuksia 8000 haavoittuvuutta julkaistaan joka
LisätiedotMuutoshistoria Versio Laatija Päiväys Muutokset Hyväksynyt 0.9 Juuso Mikkonen
1 (6) 25.11.2015 Lappeenrannan kaupungin tietoturvapolitiikka 2016 Muutoshistoria Versio Laatija Päiväys Muutokset Hyväksynyt 0.9 Juuso Mikkonen 25.11.2015 Valmis Tietohallintotyöryhmän käsittelyyn. 1.0
LisätiedotOhje arviointikriteeristöjen tulkinnasta
Ohje 1 (6) 28.10.2015 Ohje arviointikriteeristöjen tulkinnasta Kansalliset arvioinnit 1 Arviointikriteeristöt Lain viranomaisten tietojärjestelmien ja tietoliikennejärjestelyjen tietoturvallisuuden arvioinnista
LisätiedotLausunto Ohjausvaikutusten parantamiseksi julkisen hallinnon yhteisten arkkitehtuurilinjausten laatukriteerejä ovat mm:
Helsingin kaupunki, Kaupunginkanslia Lausunto 30.06.2017 Asia: VM/711/00.01.00.01/2015 Julkisen hallinnon ICTlinjauksia Linjausten tarkoitus JHKA 2.0 hallintamallissa mainitaan seuraavaa: Ohjausvaikutusten
LisätiedotVerkkosovellusten tietoturvastrategia
Verkkosovellusten tietoturvastrategia Information Security konferenssi 20.4.2010 Jari Pirhonen Turvallisuusjohtaja Samlink Sisältö Nykyaikaisten verkkosovellusten tietoturvaaminen on haastavampaa kuin
LisätiedotSisäänrakennettu tietosuoja ja ohjelmistokehitys
Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 14. kesäkuuta, 2018 Petri Strandén Manager Cyber Security Services Application Technologies Petri.stranden@kpmg.fi Petri vastaa KPMG:n Technology
LisätiedotTietoturvapolitiikka
Valtiokonttori Ohje 1 (6) Tietoturvapolitiikka Valtion IT -palvelukeskus Valtiokonttori Ohje 2 (6) Sisällysluettelo 1 Johdanto... 3 2 Tietoturvallisuuden kattavuus ja rajaus Valtion IT-palvelukeskuksessa...
LisätiedotDigital by Default varautumisessa huomioitavaa
Digital by Default varautumisessa huomioitavaa VAHTI Sähköisen asioinnin tietoturvaseminaari 3.10.2017 osana VAHTI Digitaalisen turvallisuuden teemaviikkoa 1 Agenda Palvelun riskienhallinta ja riippuvuudet
LisätiedotSalasanojen hallinta. Salasanojen hallintaopas RESTAURANT ENTERPRISE SOLUTION
Salasanojen hallinta Salasanojen hallintaopas RESTAURANT ENTERPRISE SOLUTION Restaurant Enterprise Solution Asiakirjan tarkoitus Tämä asiakirja kertoo tarvittavat säännöt kuinka hallinnoida RES salasanoja
LisätiedotJHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 6: Katselmointi
JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 6: Katselmointi Versio: 0.9 Julkaistu: n.n.2011 Voimassaoloaika: toistaiseksi Sisällys 1 Katselmointi osana laadunvarmistusta... 2 2 Yleistä katselmoinneista...
LisätiedotJulkisen hallinnon linjaukset tiedon sijainnista ja hallinnasta. Yhteenveto. Taustaa linjauksille. Linjausten tavoitteet
Valtion tieto ja viestintätekniikkakeskus Valtori Lausunto 07.09.2018 Dnro 110/00.04/2018 Asia: VM/276/00.01.00.01/2018 Julkisen hallinnon linjaukset tiedon sijainnista ja hallinnasta Yhteenveto Kommentit
LisätiedotSähköiseen säilytykseen liittyvät organisaation auditoinnit
Sähköiseen säilytykseen liittyvät organisaation auditoinnit Arto Kangas, auditoija & konsultti Netum konsultointi Oy Torstai 29.11.2012 29.11.2012 Arto Kangas, SÄHKE-Expo 1 Arto Kangas Koulutus: Kauppatieteiden
LisätiedotOhjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely
582101 - Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely 1 Vaatimukset ja käyttötapaukset Vaiheittainen mallintaminen ja abstraktiotasot Järjestelmän rajaaminen sidosryhmäkaaviolla
LisätiedotMiten varmennan ICT:n kriittisessä toimintaympäristössä?
Miten varmennan ICT:n kriittisessä toimintaympäristössä? Sairaalatekniikan päivät 2018 8.2.2018 Tommi Tervo, Istekki Oy Kehittämispäällikkö Mistä sairaalan ICT koostuu? Noin 6000 päätelaitetta Noin 200
LisätiedotJulkisen hallinnon linjaukset tiedon sijainnista ja hallinnasta. Yhteenveto. Taustaa linjauksille. Linjausten tavoitteet
Sara Saari Lausunto 07.09.2018 Asia: VM/276/00.01.00.01/2018 Julkisen hallinnon linjaukset tiedon sijainnista ja hallinnasta Yhteenveto Kommentit yhteenvetoon: Taustaa linjauksille Kommentit taustaan:
LisätiedotOmahoitopolut.fi Toteutuksen tilannekatsaus
Omahoitopolut.fi Toteutuksen tilannekatsaus PVM 1 Sisällysluettelo Aikataulu ja saavutukset tähän mennessä Aikataulu, seuraavaksi toteutettavat tehtävät Budjetti Kertynyt työmäärä suhteessa suunniteltuun
LisätiedotJulkisen hallinnon linjaukset tiedon sijainnista ja hallinnasta. Yhteenveto. Taustaa linjauksille. Linjausten tavoitteet. Lausunto
Lausunto 04.09.2018 Asia: VM/276/00.01.00.01/2018 Julkisen hallinnon linjaukset tiedon sijainnista ja hallinnasta Yhteenveto Kommentit yhteenvetoon: Seuraavat kommentit linjauksiin: 2. Riippuen palveluntarjoajasta
LisätiedotMaster data tietojen ja kriteeristön sekä hallintamallin määrittely ja suunnittelu TRE:933/02.07.01/2011
Lisätieto 15.2.2011 Master data tietojen ja kriteeristön sekä hallintamallin määrittely ja suunnittelu TRE:933/02.07.01/2011 Vastaukset täydentävät vaatimusmäärittelyämme lisätietona ja ne tulee ottaa
LisätiedotKertomusluonnoksesta annetut lausunnot 20/2018 Valtionhallinnon riskienhallinta ja toimintojen jatkuvuus 263/54/2017
Kertomusluonnoksesta annetut lausunnot 20/2018 Valtionhallinnon riskienhallinta ja toimintojen jatkuvuus 263/54/2017 Valtioneuvoston kanslia, 12.11.2018. Valtiovarain controller -toiminto, 12.11.2018.
LisätiedotAloite Onko asioiden esittämistapa riittävän selkeä ja kieleltään ymmärrettävä?
Aloite 08.02.2017 1 (3) VVC VM036:00/2015 Lausunto luonnoksesta valtion riskienhallintopolitiikkamalliksi Yleistä Onko aineistokokonaisuus, jossa on riskienhallinnan järjestämistä koskevia ohjeita,
LisätiedotSFS-ISO/IEC 27002:2014 Tietoturvallisuuden hallintakeinojen menettelyohjeet
SFS-ISO/IEC 27002:2014 Tietoturvallisuuden hallintakeinojen menettelyohjeet Yleisesittely Julkaisutilaisuus 12.6.2014 Teknologiajohtaja Aki Siponen, Microsoft Oy SFS-ISO/IEC 27002:2013 tietoturvallisuuden
LisätiedotELM GROUP 04. Teemu Laakso Henrik Talarmo
ELM GROUP 04 Teemu Laakso Henrik Talarmo 23. marraskuuta 2017 Sisältö 1 Johdanto 1 2 Ominaisuuksia 2 2.1 Muuttujat ja tietorakenteet...................... 2 2.2 Funktiot................................
LisätiedotSuunnitteluvaihe prosessissa
Suunnittelu Suunnitteluvaihe prosessissa Silta analyysin ja toteutuksen välillä (raja usein hämärä kumpaankin suuntaan) Asteittain tarkentuva Analyysi -Korkea abstraktiotaso -Sovellusläheiset käsitteet
LisätiedotLohtu-projekti. Testaussuunnitelma
Lohtu-projekti Testaussuunnitelma Versiohistoria: 1.0 19.2.2003 1. versio Mari 1.1 20.2.2003 Muutoksia Mari 1.2 25.2.2003 Katselmoinnissa esiin tulleet Mari muutokset 1.3 17.3.2003 2. syklissä tehtävät
LisätiedotTAPAS - puheenvuoro - TAPAS-päätösseminaari Tommi Oikarinen, VM / JulkICT
TAPAS - puheenvuoro - TAPAS-päätösseminaari 28.10.2011 Tommi Oikarinen, VM / JulkICT Projektin ensisijaisena tavoitteena on yhteisesti suunnitella ja arvioida alueellisen ja paikallisen tason tietojärjestelmäarkkitehtuurin
LisätiedotTietoturvapalvelut valtionhallinnolle
Tietoturvapalvelut valtionhallinnolle Netum yrityksenä Yli 80 it-ammattilaista Kohderyhmänä julkishallinto ja suuret yritykset. Tavoitteena kannattava kasvu Yrityskulttuurin ytimessä jatkuva parantaminen
LisätiedotVirtu tietoturvallisuus. Virtu seminaari 18.3.2014
Virtu tietoturvallisuus Virtu seminaari 18.3.2014 Sisältö Virtu edistää tietoturvallisuutta Tietoturvallisuus Valtorin palveluissa Tietoturvavaatimukset luottamusverkostoon liityttäessä 2 Kertakirjautuminen
LisätiedotOhjelmistojen mallintaminen. Luento 11, 7.12.
Ohjelmistojen mallintaminen Luento 11, 7.12. Viime viikolla... Oliosuunnittelun yleiset periaatteet Single responsibility eli luokilla vain yksi vastuu Program to an interface, not to concrete implementation,
LisätiedotOmakannan Omatietovaranto palvelun asiakastestaus
Omakannan Omatietovaranto palvelun asiakastestaus 18.4.2017 Johdanto Tämä dokumentti käsittelee hyvinvointisovelluksen toimittajan asiakastestaukseen liittymistä Kuvauksessa ei käsitellä Ammattilaissovelluksia
LisätiedotTietojärjestelmän osat
Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto
LisätiedotMiksi auditoidaan? Pirkko Puranen FT, Ylitarkastaja
Miksi auditoidaan? Pirkko Puranen FT, Ylitarkastaja Vaatimus kudoslaitoksille: Fimean määräys 3/2014 Liite V 6. Laatukatselmus 6.1 Toiminnoille, joille lupaa haetaan, on oltava käytössä auditointijärjestelmä.
LisätiedotLuonnos hallituksen esitykseksi eduskunnalle laiksi julkisen hallinnon tiedonhallinnasta sekä eräiksi siihen liittyviksi laeiksi
Lshp Lausunto 01.10.2018 Asia: VM183:00/2017 ja VM/1631/03.01.00/2018 Luonnos hallituksen esitykseksi eduskunnalle laiksi julkisen hallinnon tiedonhallinnasta sekä eräiksi siihen liittyviksi laeiksi Lausunnonantajan
LisätiedotTietoturvan huomioon ottaminen tietojärjestelmähankinnassa
Tässä Relator Oy:n tuottamassa White Paper -julkaisussa käsitellään sovellusten hankkimista sekä sovelluskehitystä tietoturvan näkökulmasta. White Paperin ovat kirjoittanut Relator Oy:n konsultit Kimmo
LisätiedotIoT-järjestelmän ja ulkovalaistuksen ohjauksen hankinta -markkinavuoropuhelutilaisuus
IoT-järjestelmän ja ulkovalaistuksen ohjauksen hankinta -markkinavuoropuhelutilaisuus Teknologia-arkkitehtuuri ja rajapinnat/integraatiot 21.3.2019 Sisältö Alustojen asemoituminen ja pilvivalmius Arkkitehtuuriperiaatteet
Lisätiedottsoft Tarkastusmenettelyt ja katselmukset Johdanto Vesa Tenhunen 4.2.2004
Tarkastusmenettelyt ja katselmukset tsoft Vesa Tenhunen 4.2.2004 http://cs.joensuu.fi/tsoft/ Johdanto Yksi tärkeimmistä tekijöistä laadukkaiden ohjelmistojen tuottamisessa on puutteiden aikainen havaitseminen
LisätiedotTietoturvapolitiikka
Mäntsälä Hyväksyntä Julkisuusluokka JULKINEN Sijainti Versio 0.9 2/8 Sisällys 1 Johdanto... 4 2 Mitä tietoturvallisuus on?... 4 2.1 Tietoturvallisuuden hallinta... 5 2.2 Riskienhallinta sekä jatkuvuuden
LisätiedotTietoturvallisuuden huoneentaulu mitä jokaisen on hyvä muistaa
Tietoturvallisuuden huoneentaulu mitä jokaisen on hyvä muistaa 2.10.2017 Julkisen hallinnon digitaalisen turvallisuuden teemaviikko Petri Puhakainen, valtioneuvoston tietoturvapäällikkö Tietoturvallisuuden
LisätiedotTIETOTURVA LIIKETOIMINNAN MAHDOLLISTAJANA
TTL 60 vuotta Roadshow, Tampere 5.11.2013 TIETOTURVA LIIKETOIMINNAN MAHDOLLISTAJANA Antti Pirinen, Tietoturva ry Antti Pirinen Tietoturva ry Hallituksessa 2009 -> Sihteeri 2013 Työkokemus: 2012 -> KPMG:n
LisätiedotArviointiraportti. Patenttitoimisto Jaakko Väisänen
2016-06-16 1 (5) Arviointiraportti Patenttitoimisto Jaakko Väisänen 14. - 16.6.2016 Raportti nspecta Sertifiointi Oy Visiting address CN: 1065745-2 Group headquarters: nspecta Group Oy, Helsinki, 2016-06-16
LisätiedotToimintaohjeistus. Tietoturvallisuusohjeistus TIETOTURVASUUNNITELMAT
TIETOTURVALLISUUDEN KEHITTÄMINEN Opettaja: Tuija Kyrölä 040-5455465 tuija.kyrola@kolumbus.fi Toimintaohjeistus Tietoturvallisuusohjeistus I-TASO II-TASO III-TASO Ylin johto hyväksyy Konsernihallinto valmistelee
LisätiedotMiten suojautua nykyisiltä tieto- ja kyberuhilta? Petri Vilander, Kyberturvallisuuspäällikkö, Elisa Oyj
Miten suojautua nykyisiltä tieto- ja kyberuhilta? Petri Vilander, Kyberturvallisuuspäällikkö, Elisa Oyj Kyberturvallisuus toiminta Valtio Kyberturvallisuuden poliittinen ohjaus kuuluu valtioneuvostolle,
LisätiedotT-110.5690 Yritysturvallisuuden seminaari. Kappaleet 15-16: Operational Risk Management Assurance Management
T-110.5690 Yritysturvallisuuden seminaari Kappaleet 15-16: Operational Risk Management Assurance Management Operational Risk Management Määritelmä Lakien tuomat vaatimukset Laadulliset ja numeraaliset
LisätiedotArkkitehtuuri muutosagenttina
Arkkitehtuuri muutosagenttina Smarter Processes, Development & Integration Hannu Salminen CTO OP-Pohjola 2013 IBM Corporation Taustaa Nykyinen IT-arkkitehtuuri ja liiketoimintatarpeet eivät kohtaa OP-Pohjolan
LisätiedotTapahtuipa Testaajalle...
Tapahtuipa Testaajalle... - eli testaus tosielämässä 09.10.2007 Juhani Snellman Qentinel Oy 2007 Agenda Minä ja mistä tulen Testauksen konteksti Tapauksia tosielämästä ja työkaluja 2 Minä Juhani Snellman
LisätiedotTietoturvakonsulttina työskentely KPMG:llä
Tietoturvakonsulttina työskentely KPMG:llä Helsingin Yliopisto 28 Helmikuuta 2014 Agenda Agenda Työtehtävistä yleisesti Esimerkkejä Osaamisen/toiminnan kehittäminen 1 Turvallisuuden arviointi / auditointi
LisätiedotLiite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu
Liite 1: skenaariot ja PoC tulokset 1. Palvelun kehittäjän näkökulma Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Palvelun uusi versio on Palveluiden kehittäminen voitava asentaa tuotantoon vaikeutuu
LisätiedotUCOT-Sovellusprojekti. Testausraportti
UCOT-Sovellusprojekti Testausraportti Ilari Liukko Tuomo Pieniluoma Vesa Pikki Panu Suominen Versio: 0.02 Julkinen 11. lokakuuta 2006 Jyväskylän yliopisto Tietotekniikan laitos Jyväskylä Hyväksyjä Päivämäärä
LisätiedotTUTKI OMAT TIETOTURVA-AUKKOSI. ENNEN KUIN JOKU MUU TEKEE SEN PUOLESTASI. F-Secure Radar Ville Korhonen
TUTKI OMAT TIETOTURVA-AUKKOSI. ENNEN KUIN JOKU MUU TEKEE SEN PUOLESTASI. F-Secure Radar Ville Korhonen ON OLEMASSA KAHDENLAISIA YRITYKSIÄ: 1. NE JOIHIN ON MURTAUDUTTU 2. NE JOTKA EIVÄT VIELÄ TIEDÄ SITÄ
LisätiedotJulkisen hallinnon linjaukset tiedon sijainnista ja hallinnasta. Yhteenveto. Taustaa linjauksille. Linjausten tavoitteet
VM Lausunto 07.09.2018 VM/1499/00.00.05/2018 Asia: VM/276/00.01.00.01/2018 Julkisen hallinnon linjaukset tiedon sijainnista ja hallinnasta Yhteenveto Kommentit yhteenvetoon: Taustaa linjauksille Kommentit
LisätiedotTietoturvallisuuden ja tietoturvaammattilaisen
Tietoturvallisuuden ja tietoturvaammattilaisen haasteet Turvallisuusjohtaminen 2006 25.10.2006 Jari Pirhonen puheenjohtaja Tietoturva ry Turvallisuusjohtaja, CISSP, CISA Oy Samlink Ab Tieto lisää turvaa
LisätiedotPikaopas. Tietoturva, GDPR ja NIS. Version 3.0
Pikaopas Tietoturva, GDPR ja NIS Version 3.0 GDPR henkilötietojen suojaus EU:n uusi tietosuoja-asetus tuli voimaan 25.5.2018 kaikissa EU-valtioissa. Asetus syrjäyttää ja korvaa aikaisemman henkilötietojen
LisätiedotKäyttöönottosuunnitelma Virtu-kotiorganisaatiolle
Ohje 1 (6) Käyttöönottosuunnitelma -kotiorganisaatiolle Ohje 2 (6) Asiakirjan muutoshistoria versio päiväys tekijä tarkastaja hyväksyjä Muutoshistoria 1.0 11.12.2009 Mikael Linden käyttöönottohankkeen
LisätiedotOhjelmiston testaus ja laatu. Testaustasot
Ohjelmiston testaus ja laatu Testaustasot Testauksen vaihejako Tarpeet / sopimus Järjestelmätestaus Hyväksymiskoe Määrittely testauksen suunnittelu ja tulosten verifiointi Arkkitehtuurisuunnittelu Moduulisuunnittelu
LisätiedotISO 9001:2015 JÄRJESTELMÄ- JA PROSESSIAUDITOIN- NIN KYSYMYKSIÄ
ISO 9001:2015 JÄRJESTELMÄ- JA PROSESSIAUDITOIN- NIN KYSYMYKSIÄ IMS Business Solutions Oy, J Moisio 10/ 2016 2.10.2016 IMS Business Solutions Oy 2 ISO 9001:2015 PROSESSIEN AUDITOINTIKYSYMYKSIÄ ISO 9001:2015
LisätiedotJunaliikenteen häiriötilannetietojen tuottaminen ja tiedotus
Junaliikenteen häiriötilannetietojen tuottaminen ja tiedotus Esiselvitys ja vaatimusmäärittely 28.10.2004 Hankkeen tavoitteet Toimiva prosessi junaliikenteen häiriötilanteiden tietojen tuottamiseen, ylläpitämiseen
LisätiedotUutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3
Uutisjärjestelmä Vaatimusmäärittely Versio 1.3 Sisällys 1 Muutoshistoria... 4 2 Viitteet... 4 3 Sanasto... 4 3.1 Lyhenteet... 4 3.2 Määritelmät... 4 4 Johdanto...5 4.1 Järjestelmän yleiskuvaus... 5 4.2
LisätiedotMiten 333 organisaatiota voi kehittää yhtä yhteistä digitaalista palvelua ja vielä kuunnella kaikkien asiakkaita?
#finnayhdessä Miten 333 organisaatiota voi kehittää yhtä yhteistä digitaalista palvelua ja vielä kuunnella kaikkien asiakkaita? Riitta Peltonen, johtava käytettävyyssuunnittelija, Finnan 5-vuotisseminaari,
LisätiedotYrityksen jatkuvuussuunnitelma
Yrityksen jatkuvuussuunnitelma TIVA:n alueseminaari Ari Väisänen, Ernst & Young Oy Luennoitsijan taustaa Partner and Practice leader of IT Risk and assurance Services, Ernst & Young, 2007-2002-2007 IT-tarkastus
LisätiedotToimitilojen tietoturva
Toimitilojen tietoturva Toimitilakonseptikoulutus Tuija Lehtinen 18.2.2014 Toimitilaturvallisuus Tarkoittaa toimitilojen fyysistä suojaamista, jonka avulla pyritään turvaamaan organisaation häiriötön toiminta
LisätiedotConsultor Finland Oy. Paasitorni / Markus Andersson Toimitusjohtaja
Consultor Finland Oy Paasitorni / Markus Andersson Toimitusjohtaja Consultor Finland Oy Consultor (lat. kysyy neuvoja, on neuvoja, neuvonantaja) Consultor Finland Oy on (1) suomalainen edelläkävijä (2)
LisätiedotEläketurvakeskuksen tietosuojapolitiikka
Eläketurvakeskus Tietosuojapolitiikka 1 (5) Eläketurvakeskuksen tietosuojapolitiikka Eläketurvakeskus Tietosuojapolitiikka 2 (5) Sisällysluettelo 1 Yleistä... 3 2 Tietosuojatoimintaa ohjaavat tekijät...
LisätiedotJulkisen hallinnon linjaukset tiedon sijainnista ja hallinnasta. Yhteenveto. Taustaa linjauksille. Linjausten tavoitteet
Solita Oy Lausunto 07.09.2018 Asia: VM/276/00.01.00.01/2018 Julkisen hallinnon linjaukset tiedon sijainnista ja hallinnasta Yhteenveto Kommentit yhteenvetoon: Taustaa linjauksille Kommentit taustaan: Linjausten
LisätiedotEsityksen sisältö Määrittelyjen mukaisuudesta varmistuminen - PlugIT-leima
Esityksen sisältö Johdanto Yleistä leimausmenettelystä ja leimasta Leimausmenettelyn vaiheet Kuinka määrittelyjen mukaisuus testataan: esimerkkejä testitapauksista Olennaisimmat kysymykset leimausmenettelyn
LisätiedotJulkisen hallinnon linjaukset tiedon sijainnista ja hallinnasta. Yhteenveto. Taustaa linjauksille. Linjausten tavoitteet
Verohallinto Lausunto 07.09.2018 Asia: VM/276/00.01.00.01/2018 Julkisen hallinnon linjaukset tiedon sijainnista ja hallinnasta Yhteenveto Kommentit yhteenvetoon: Taustaa linjauksille Kommentit taustaan:
LisätiedotTIE Ohjelmistojen testaus 2016 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori
TIE-21201 Ohjelmistojen testaus 2016 Harjoitustyö Vaiheet 1 ja 2 Antti Jääskeläinen Matti Vuori Työn yleiset järjestelyt 20.9.2016 2 Valmistautuminen Ilmoittaudu kurssille Lue harjoitustyön nettisivut
LisätiedotMäärittelyvaihe. Projektinhallinta
Määrittelyvaihe Projektinhallinta testaus määrittely suunnittelu ohjelmointi käyttöönotto, testaus tuotteenhallinta laadunvarmistus dokumentointi vaatimustenhallinta Määrittely Määrittely, eli kansanomaisesti
LisätiedotTARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI
TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI Vesa Tenhunen Tarkastusmenettelyt Keino etsiä puutteita ohjelmakoodeista, dokumenteista ym. ohjelmistoprosessissa syntyvästä materiaalista Voidaan käyttää kaikissa
LisätiedotTestaussuunnitelma. Pizzeria - Pitseria HAAGA-HELIA ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma. WebPizza
Testaussuunnitelma Pizzeria - Pitseria HAAGA-HELIA ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma Versio 1.0 Ehdotus Laatija Raine Kauppinen VERSIOHISTORIA Versionotyyppi Versio- Päiväys Tekijä
LisätiedotJulkisen hallinnon linjaukset tiedon sijainnista ja hallinnasta. Yhteenveto. CSC-Tieteen tietotekniikan keskus Oy. Lausunto
CSCTieteen tietotekniikan keskus Oy Lausunto 07.09.2018 VM/276/00.01.00.01/2018 Asia: VM/276/00.01.00.01/2018 Julkisen hallinnon linjaukset tiedon sijainnista ja hallinnasta Yhteenveto Kommentit yhteenvetoon:
LisätiedotJHS Avoimen tietoaineiston käyttölupa
JHS Avoimen tietoaineiston käyttölupa Anne Kauhanen-Simanainen ja Marjut Salokannel Esittely julkisen hallinnon tietohallinnon neuvottelukunnalle (JUHTA) 11.12.2014 Valtioneuvoston periaatepäätös (3.3.2011)
LisätiedotOLENNAISET TOIMINNALLISET VAATIMUKSET - PÄIVITETTY LUOKITUS JA JÄRJESTELMÄLOMAKE Kela toimittajayhteistyökokous 26.4.
OLENNAISET TOIMINNALLISET VAATIMUKSET - PÄIVITETTY LUOKITUS JA JÄRJESTELMÄLOMAKE 24.4.2019 Kela toimittajayhteistyökokous 26.4.2019 1 ASIAKASTIETOLAIN 250/2014 MUKAISET OLENNAISET VAATIMUKSET I Toiminnalliset
LisätiedotMitä varautumissuunnitelmilta odotetaan? Tarvo Siukola
Mitä varautumissuunnitelmilta odotetaan? Tarvo Siukola Huoltovarmuuskeskuksen ohjeistama varautumissuunnittelu Huoltovarmuuskeskukselle 2016 toimitettu SML 28 :n mukainen varautumissuunnitelma koostui
LisätiedotSovelto Oyj JULKINEN
1 (5) 21.3.2018 JULKINEN :n Vastuu :n toiminnasta on sen ylimmällä johdolla. Yrityksen toiminta ja palvelut ovat suuresti riippuvaisia tietotekniikkapalveluiden saatavuudesta ja niiden turvallisesta toiminnasta.
LisätiedotStandardit tietoturvan arviointimenetelmät
Standardit tietoturvan arviointimenetelmät Tietoturvaa teollisuusautomaatioon (TITAN) VTT Auditorio, Vuorimiehentie 5, Espoo, 9.11.2010 Jarkko Holappa Tietoturvallisuuden arviointi osana tietoturvan hallintaa
LisätiedotCase VRK: tietosuojan työkirjat. JUDO Työpaja #2 - tietosuoja Noora Kallio
Case VRK: tietosuojan työkirjat JUDO Työpaja #2 - tietosuoja Noora Kallio Esityksen sisältö Tietosuojan hallintamalli Prosessi Työkaluina tietosuojan työkirjat Ratkaistava asia Miten tietosuoja-asetuksen
LisätiedotCase-esimerkki: Miten Valtori hallitsee riskejä? Tommi Simula Riskienhallintapäällikkö
Case-esimerkki: Miten Valtori hallitsee riskejä? Tommi Simula Riskienhallintapäällikkö Valtorin riskienhallintamalli Perustuu VAHTI 22/2017 riskienhallintaohjeeseen ja ISO31000-standardiin Mallin kuvauksina
LisätiedotLuku 8 Rakennusvaihe. Detailed Design. Programming. Moduulisuunnittelu. Ohjelmointi
Luku 8 Rakennusvaihe Moduulisuunnittelu Detailed Design Programming Ohjelmointi Teknisen Complete suunnittelun Technical viimeistely Design Suunnittelukatselmuksen Design Perform suorittaminen Review Yhteisen
LisätiedotTietoturvapolitiikka Porvoon Kaupunki
Tietoturvapolitiikka Porvoon Kaupunki 1 Sisältö 1 Johdanto... 3 2 Mitä tietoturvallisuus on?... 4 Tietoturvallisuuden hallinta... 4 Riskienhallinta sekä jatkuvuuden hallinta ja varautuminen... 5 3 Tietoturvallisuustavoitteet...
LisätiedotAineistosiirron testauksen aloituksen ohje Trafin sopimuskumppaneille
TraFin ulkoinen integraatio Aineistosiirron testauksen aloituksen ohje Trafin sopimuskumppaneille Ohje 26.2.2014 Versio 1.1, Hyväksytty Luottamuksellinen Vastuutaho Trafi MUUTOSHISTORIA Versio Päiväys
LisätiedotHyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa
1 Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa Passion leads to design, design leads to performance, performance leads to SUCCESS! OLLI NIEMI Yoso Oy Mitä määrittelyltä
Lisätiedot