A | B | C | D | |
---|---|---|---|---|
1 | Liite 5 Tietoturvavaatimukset | |||
2 | Sovelluskehityksen tietoturvavaatimukset | |||
3 | ||||
4 | Toimittaja sitoutuu täyttämään kaikki tällä välilehdellä olevat vaatimukset Asiakkaalle palvelua tuottaessaan. | |||
5 | Asiakas voi täsmentää ja tarkentaa tällä välilehdellä esitettyjä vaatimuksia dynaamisen hankintajärjestelmän sisäisessä kilpailutuksessaan. Lisäksi Asiakas voi asettaa sisäisen kilpailutuksen tarjouspyynnössään myös muita tietoturvavaatimuksia. Asiakkaalla on oikeus auditoida tietoturvavaatimusten täyttyminen. Hanselin auditointioikeudesta on sovittu dynaamiseen hankintajärjestelmään osallistumista koskevassa sopimuksessa. | |||
6 | Mikäli muuta ei mainita, Toimittajan (ei Asiakkaan) tulee suorittaa tässä taulukossa kuvatut toimenpiteet, jotka kohdistuvat hankinnan kohteeseen eli palveluun. | |||
7 | ||||
8 | Tunniste | Vaatimus | Tarkentava selostus | |
9 | ||||
10 | 4 Palvelun tuottamiseen liittyvät sovelluskehitysvaatimukset | |||
11 | 4.1 | Toimittajan tulee kartoittaa ja tunnistaa sovelluskehityksen tietoturvan kannalta merkittävät roolit ja niistä vastuussa olevat henkilöt. | Tällaisia rooleja ovat mm: • Arkkitehdit ja projektipäälliköt • Sovelluskehitykseen käytetyn kehitysympäristön omistajat ja ylläpitäjät. • Kehitettävän sovelluksen omistaja • Testauspäällikkö Tunnistetuille henkilöille tulee määritellä varahenkilöt. Lisäksi varahenkilöt tulee kouluttaa tehtäviinsä, jotta he pystyvät tarvittaessa toimimaan varahenkilöinä tehokkaasti. | |
12 | 4.2 | Toimittaja varmistaa, että sovelluskehityksestä vastaavat henkilöt tuntevat riittävästi tietoturvallisuusasioita ja että heidän osaamisensa pysyy ajan tasalla. | Näin varmistutaan siitä, että kaikki organisaation henkilöt omaavat riittävät taidot rooliinsa kuuluvan tietoturvatyön hoitamiseksi. Tietoturvakoulutusta tulee antaa säännöllisesti, vähintään kerran vuodessa. | |
13 | 4.3 | Toimittaja vastaa siitä, että palvelun tuottamisessa käytettävät kehitys-, testi-, ja muut ympäristöt on eriytetty tuotantoympäristöistä. Toimittajan tulee määritellä menettely, jota seurataan siirrettäessä verkkosovelluksen toimintoja ympäristöstä toiseen. | ||
14 | 4.4 | Toimittajan tulee listata verkkosovelluksen tietoturvan pahimmat mahdolliset tapaukset (worst case scenario) käyttämällä lähtökohtana ratkaisun liiketoimintatarkoitusta, ratkaisun käsittelemää tietoa ja liiketoiminnan riskiprofiilia. Jokainen riski tulee kuvata yhdellä lauseella ja määritellä se hyökkääjän korkean tason tavoitteiksi. Tämän jälkeen jokaiselle riskille tulee määritellä esiehdot joiden pitää päteä jokaiselle hyökkääjän tavoitteen onnistumiselle. Informaation voi esittää ns. uhkapuuna tai rakenteellisena listana. | Esim: Organisaatio kehittää web-sähköpostisovellusta. Eräs tunnistettu pahin mahdollinen tapaus: käyttäjän viestit ovat muiden luettavissa. Tunnistettu uhka: hyökkääjä voi lukea muiden käyttäjien sähköposteja. Esiehdot: 1. Datan validointi ei toimi TAI 2. Auktorisointi ei toimi TAI 3. Selaimen välimuistiin jää luottamuksellista informaatiota JA a. Käyttäjä käyttää jaettua konetta TAI b. Hyökkäjä saa käyttäjän koneen käsiinsä TAI c. Selaimen tietoturvapuute altistaa välimuistin hyökkääjälle. | |
15 | 4.5 | Toimittajan tulee suunnitella verkkosovelluksen tehtävät muutokset siten, että korjausten ja tietoturvapäivitysten asentaminen on mahdollisimman helppoa. | Käytännössä tämä tarkoittaa ainakin seuraavien asioiden huomioimista: - Ei kovakoodattuja konfiguraatioarvoja - Sovellus ei ole riippuvainen tietyistä ohjelmistoversioista, kuten JRE-versiosta. - Kirjastoriippuvuudet on toteutettu siten, että päivittäminen onnistuu helposti. | |
16 | 4.6 | Virheiden käsittely: verkkosovelluksen poikkeus- ja virhetilanteiden käsittelyn tulee toimia siten, että virhetilanteet eivät johda verkkosovelluksen tietoturvan vaarantumiseen. | Huomioitavia asioita ovat ainakin: • Virheiden ja poikkeusten käsittelyn tulee kattaa koko sovellus • Virheiden käsittely tulee toteuttaa keskitetysti ja koko sovelluksen kattavasti, jolloin testaus saadaan kattavaksi ja virheiden korjaamien on nopeampaa. • Ns. fail-secure suunnitteluperiaatteella varmistetaan, että virhetilanteessa komponentin tai sovelluksen käyttö ennemmin estetään kuin sallitaan tietoturvaloukkauksen hyväksikäyttö. • Virheilmoitukset eivät saa sisältää luottamuksellista tietoa, kuten tietokantapalvelimen vastauksia, sovelluspalvelimen versiotietoja jne. Kaikissa virhetilanteissa näytetään yleinen virheilmoitus, joka kuvaa tapahtuneen virheen mutta ei anna tietoa sovelluksen toteutuksesta. Myöskään ”henkilökohtaista” tietoa, kuten ylläpitäjien nimiä ja yhteystietoja, ei tulisi sisällyttää virheviesteihin social engineering -hyökkäysten estämiseksi. | |
17 | 4.7 | Istunnon kaappaaminen on tyypillinen tietoturvahyökkäys sovelluksia vastaan. Tällöin hyökkääjä saa kirjautuneen käyttäjän istunnon haltuunsa esim. istuntotunnisteen kaappaamalla. Verkkosovelluksen tulee toimia siten, että autentikoituneen käyttäjän istuntoa ei voi kaapata luvattomasti. | Keinoja istunnon kaappaamisen estämiseksi ovat mm: • Yhteyden salaus • Istunnon aikakatkaisu • Vaikeasti arvattava istuntotunniste • Istuntotunnisteen suojaaminen (esim. seuraavat attribuutit: secure, httpOnly, domain, path, expires). • Istunnon tuhoaminen käyttäjän kirjautuessa ulos • Sivukohtaiset tunnisteet ns. CSRF-hyökkäyksen estämiseksi • Istunnon aloittajan IP-osoitteen tallentaminen ja käyttäminen istunnon seuraamisessa tunnisteen lisäksi. | |
18 | 4.8 | Toimittaja vastaa siitä, että verkkosovelluksen tietoturvapäivityksien ja korjauksien asennus on dokumentoitu. Dokumentin katselmointi ja päivitys on organisoitu ja vastuutettu. | Dokumentin pitää kuvata ainakin seuraavat asiat: • Päivitysten toimittaminen, päivityssykli • Kriittisten päivitysten toimittaminen • Päivityksen asennusmenettely • Varmuuskopiointi • Varmuuskopioiden palauttaminen. |