Lausunto Sovelluskehityksen tietoturvaohjeluonnoksesta

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