Sovellustietoturvallisuuden kehittymistä suomalaisissa organisaatiossa läheltä seuranneena huomaan edelleen törmääväni usein siihen, että sovelluksia ostavilla tai sovelluksia kehittävillä henkilöillä on vääriä käsityksiä sovellustietoturvallisuudesta tai jopa perustiedot sovellustietoturvallisuudesta puuttuvat.

Nykyistäkin perustietämystasoa kuvaa hyvin eräs vuoden takainen uutinen, jossa tunnettua suomalaista web-palvelua pyörittävän yrityksen toimitusjohtajalta kyseltiin ovatko palvelun käyttäjätunnukset ja salasanat turvassa, kun juuri aikaisemmin olivat erään toisen web-palvelun käyttäjätunnukset ja salasanat vuotaneet julkisuuteen. Toimitusjohtajan vastaus oli, että käyttäjätunnukset ja salasanat ovat turvassa – ne ovat kahden palomuurin takana.

“Meidän sovelluksemme on suojattu, meillä on palomuurit, virustorjunta ja IDS”, “Mutta kun meidän sovelluskehitys-framework huolehtii näistä tietoturva-asioista”, “Meidän organisaation tietoturva-asiantuntijat hoitavat nämä asiat”. Kuulostaako tutulta?

Näyttää siltä, että kestää vielä tovin kunnes sovelluksen ostaja tai peruskehittäjäkin tiedostaa, että se sovelluksen tietoturvallisuus on omasta työstä kiinni. Ei ole olemassa mitään maagista verkkolaitetta tai tietoturvaohjelmistoa joka huolehtisi siitä, että sovelluksen tiedot olisivat turvassa, jos sovellus itsessään on haavoittuva.

Sovellustietoturvaa läpi koko prosessin

Alan mediakin keskittyy sovellustietoturvasta puhuttaessa vain uusien haavoittuvuuksien uutisointiin. Hyvin harvoin artikkeleissa puhutaan turvallisesta sovelluskehityksestä ja mistä johtuu se, että sovellukset alun alkaenkin ovat niin haavoittuvia.

Onneksi valoa on näkyvissä tunnelin päässä. Useat organisaatiot ovat vihdoin heräämässä ja käynnistäneet hankkeita sovellustietoturvallisuuden tietoisuuden kasvattamiseksi ja oman sovelluskehitys- tai sovellushankintaprosessin uudistamiseksi, niin että tietoturvallisuus tulee huomioitua heti jo uutta sovellusta suunniteltaessa.

Toivottavasti myös alan oppilaitoksetkin pikkuhiljaa alkaisivat ottamaan sovellustietoturvallisuutta opetusohjelmiinsa. Ainakin TKK:lla sovellustietoturvallisuus on melko tuntematon käsite. Lähimpänä tätä aihepiiriä olevat tietoturvallisuuden kurssit keskittyvät vielä verkkoprotokollatasolle.

Sovellustietoturvallisuuteen perehtyminen kannattaa aloittaa OWASPin sivuilta. OWASP (Open Web Application Security Project) on voittoa tavoittelematon organisaatio, jonka tarkoituksena on kasvattaa tietoisuutta ja kehittää sovellusturvallisuutta. Vapaasti kaikkien käytettävissä oleva ASVS (Application Security Verification Standard) on OWASPin ensimmäinen standardi. Standardissa kuvattuja vaatimuksia voidaan käyttää esim. sovelluksen turvallisuusvaatimuksia määriteltäessä, ohjeistuksena sovelluksen turvakontrollien toteutuksessa tai arvioitaessa jo valmiin sovelluksen tietoturvallisuuden tasoa.

Kirjoittajasta:

Inspect-yksikön vetäjä Petteri Arola aloitti vuoden alussa OWASP Helsinki Chapterin chapter leader -tehtävässä.

Tämä tiistai on IT- ja tietoturva-ammattilaisille harvinaisen haastava. Samana päivänä tietoturvapäivityksensä julkaisevat niin Adobe, Microsoft kuin Oraclekin.

Adoben julkaisemat päivitykset ovat vuoden ensimmäisen neljänneksen päivityksiä, Microsoftin päivitykset tammikuun kuukausipäivityksiä ja Oraclen 24 päivitystä taas ensimmäisen neljänneksen CPU-päivityspaketti - Critical Patch Update.

Microsoftin päivityksiä koskevia ennakkotiedotteita on ollut käytettävissä vuoden 2005 alusta, samasta hetkestä jolloin Oracle aloitti neljännesvuosipäivityksensä. Etukäteistiedotteet Oracle otti käyttöön kylläkin vasta myöhemmin.

Uusin etukäteistiedottaja kolmikosta on Adobe, joka aloitti säännölliset päivityksensäkin vasta viime kesänä.

Ennakkotietojen laajuus vaihteleekin sitten jo paljon. Oraclen erityispiirteenä on paikattavien haavoittuvuuksien korkeimman CVSS-arvon kertominen. Tällä kertaa arvo on tuotteiden Listener for Oracle Database Server, Secure Backup ja JRockit kohdalla korkein mahdollinen eli 10.0.

Haittaohjelmien tekijöille lisää aikaa

Kuinka ohjelmistojätit sitten ovat onnistuneet päivitysprosesseissaan? Suoraa vastausta ei kysymykseen ole olemassa, mutta Microsoftille päätös on välillä ollut haasteellinen.

Microsoftilla on nimittäin päätetty jättää kuukausipäivitykset julkaisematta kaikkiaan neljä kertaa: joulukuussa 2003, maalis- ja syyskuussa 2005 sekä maaliskuussa vuonna 2007. Samalla kun päivitysten ennakkotiedote edellisen viikon torstaina kertoo päivityksien kohteet saavat haavoittuvuuksien hyödyntäjät eli esimerkiksi haittaohjelmien tekijät pahimmassa tapauksessa kuukauden lisäaikaa toimilleen.

Buutti tarvitaan, olkaa valppaina

Päivitysten perusteellinen testaaminen ottaa myös aikansa, ja sitä ehdottomasti täällä Nixussa suosittelemme. Ennakkotiedote kertoo ylläpitäjille mitä ollaan paikkaamassa ja auttaa suunnittelemaan esimerkiksi palvelinten uudelleenkäynnistyksen, kun Microsoft kertoo sen pakolliseksi päivityksen astumiseksi voimaan.

Hyökkääjällä on usein useita hyökkäysvektoreita valittavanaan. Hyökkäys voidaan suunnitella ja oikea hyökkäysvektori valita sitä paremmin mitä enemmän aikaa ennen päivityksen julkaisua on käytettävissä.

Adoben tapauksessa tämä onkin jo nähtävissä. Kun aikaisemmin Acrobat-haavoittuvuuksia hyödynnettiin pitkälti lähinnä ns. kohdennetuissa hyökkäyksissä on päivitystä odotellessa nähty yhä uusia haavoittuvuutta hyödyntäviä hyökkäyksiä. Hyödynnettävä haavoittuvuus on miltei poikkeuksetta joulukuun puolivälissä löytynyt, Adoben tietoturvatiedotteessa APSA09-07 mainittu haavoittuvuus (CVE-2009-4324).

Verkkorikolliset käyttävät aikansa tehokkaasti, koska päivityksen tultua tänään saataville vähenee haavoittuvien kohteiden määrä jatkuvasti. Tieto korjausaikataulustahan saatiin jo joulukuun puolivälissä, ei suinkaan viime torstain ennakkotiedotteen kautta. Hyökkäyskoodi on ollut Metasploitissa jo peräti kuukauden.

Saamaansa lisäaikaa verkkorikolliset käyttävätkin usein kehittämällä exploit- eli hyökkäyskoodista koodinajamiseen kykenevän version.