Tapahtuman ohjelma: http://bit.ly/15Y05J Aluksi järjestäjät esittäytyivät: Antti Vähä-Sipilä, Tietoturva ry; Ilkka Lehtinen, COSS, Heikki Roikonen, Nixu.
Mahdollisuuksia: - Avoin lähdekoodi on tietoturvallisempi tapa toteuttaa ohjelmia (tämä aiheuttaa aina paljon keskustelua) - Nykyään hyvin paljon saatavilla kaupallista tukea OS-ratkaisuihin - Tietoturvan korjaaminen on mahdollista (kiertotiet/kludget) - Tietoturvaa lisäävien komponenttien liittäminen on mahdollista (mutta ei välttämättä triviaalia)
Haasteita - Jatkokehitys ja tietoturvapäivitykset riippuvat yhteisön motivaatiosta - Tuen saanti voi joskus olla ongelma - Dokumentointi voi olla puutteellista tai virheellistä - Esim. yleisistä CMS-järjestelmistä löytyy viikottain/kuukausittain puutteita tietoturvassa
Kysymys yleisöstä: Raportoiko Louhi löydetyistä tietoturvaongelmista takaisin yhteisölle? Vastaus: Kyllä. Joko suoraan projektille tai yhteistyökumppanille
Torvalds ajaa takaa sitä, että mikäli tietoturvabugeille annetaan erityskohtelu, niin se vähentää tuottavuutta ja aiheuttaa, että kaikki bugit merkataan non-security flagillä
toisaalta suljetulla puolella asiat voivat edetä todella hitaasti ja firman security-tiimit voivat pallotella asiaa toisilleen ja asia viipyy...kunnes lopulta yhteyttä ottaa lakimies
avoimella puolella bugit ovat kaikkien katsottavissa - myös siis tietoturva-aukot suljetulla puolella bugit piilotetaan - asiakas saa mustan laatikon ja joutuu luottamaan toimittajaan
@smoinen tuossa ohitetaan kokonaan se että useimpien open source -projektien ympärillä on yrityksiä jotka pystyvät tarjoamaan muutoksia ja korjauksia palveluna
suljetun koodin puolella tuote ja sen toimittaja voi kadota esim. konkurssin tai yritysoston myötä. kehittäjät voivat vaihtaa maisemaa ja tuotetuki loppua kuin seinään
konkurssi -> tuotetuki loppuu -> etsitään uusi jatkokehittäjä (oikeudet, koodi, sisäänajo) -> korjaa bugeja -> integroi -> uusi versio - aikaa tähän kaikkeen menee todella paljon. aikaa kuluu mm. pesänselvittelyyn, jota hoitaa juristi.
Yleensä ottaen kannattaa välttää projekteja, joissa on vain yksi kehittäjä. Yhden kehittäjän tilanteelle on yleensä hyvä syy: projekti ei ehkä kiinnosta muita tai pääkehittäjä on ilkeämielinen tai haluton ottamaan mukaan muita kehittäjiä
Tieto tekee mitä asiakas haluaa. Jos halutaan avointa lähdekoodia, niin sitä tehdään. Usein herää kysymys, että uskaltaako asiakas käyttää avointa lähdekoodia? Pelkotiloihin vaikuttavat mm. yllä mainitut asianajotoimistot. Yleensä uhkakuvia luodaan vastuunrajoituksista.
open source due diligence -termillä tarkoitetaan kohdeohjelman huolellista ja perusteellista tarkastusta, jossa pyritään löytämään ohjelmaan liittyvät juridiset, tekniset ja käytännööiset riskit ja puutteet
suomessa lisenssien validointityötä tekee Validos-yhdistys, jossa validointityö tehdään ohjelmistolle/komponentille kerran ja tulokset jaetaan kaikille yhdistyksen jäsenille. Näin vältetään päällekkäistä validointityötä, joka muutoin tehtäisiin jokaisessa yrityksessä erikseen. Lisätietoja: http://www.validos.org
DD-tarkastuksen laajuus on riippuvainen lopputuotteen käyttötarkoituksesta. täytyy olla paljon huolellisempi esim. asiakkaalle toimitettavien päätelaitteiden kuin esim. palvelinohjelmiston kanssa
Yhteenveto: - tee huolellinen ennakkotarkastus, kun otat käyttöön tai liität omiin tuotteisiisi avointa lähdekoodia - älä lupaa asiakkaalle liikoja (myyntimiehet huom!) - tekninen tuki on oleellinen osa avoimen lähdekoodin osia sisältävän tietojärjestelmän menestyksekästä käyttöä
kolmansien osapuolten tuotteille on tehtävä patenttiskriinaus ihan samalla tavoin kuin avoimen lähdekoodin tuotteille. usein avoimen lähdekoodin tuotteissa asiat ovat paremmalla tolalla.
joka päivä pitää kirjautua niin moneen paikkaan, että: - pelkkään kirjautumiseen ja salasanojen muistamiseen menee hermot - salasanat tallennetaan selaimen muistiin - monessa paikassa käytetään samoja salasanoja - yleisten järjestelmien salasanoista ylläpidetään kaikkien saatavilla olevaa listaa
Coverity Scan, joka tarjoaa koodin skannauspalveluja on tarkistanut kuinka avoimen lähdekoodin virheiden määrä on muuttunut viimeisen kolmen(?) vuoden aikana. Virheiden määrä on vähentynyt 16 %. Ei huima muutos, mutta kuitenkin muutos parempaan. http://coverity.com/
Isojenkin toimijoiden on ollut "pakko taipua" käyttämään avoimen lähdekoodin työkaluja. Esim. Oracle käyttää Eclipseä. Omien tuotteiden valmistaminen on yksinkertaisesti niin kallista.
Yleisöltä: Firefoxin master-salasanasuojaus ei ole turvallinen. Kun salasana on kerran annettu, niin firefox liitännäisineen pääsee käsiksi sanasanoihin.
Käyttöönotto- ja ylläpitovaiheessa ensiarvoisen tärkeää on sopia siitä, miten bugeista pidetään kirjaa ja miten niihin reagoidaan. Työkaluja mm. Jira ja BugZilla.
haasteita: - avoin toteutus, ei varaa virheille - lisensointi, erityisesti GPL3 - koodin laatu, dokumentaation puute toisinaan - "keskimäärin os-koodi laadukkaampaa. ei kehtaa julkaista huonoa koodia"
mahdollisuuksia: - minimal temptation for security through obscurity - Eric S. Raymond: Given enough eyeballs, all bugs are shallow - "riittääkö silmämunia kaikelle koodille?" - pääsee suoraan toteutukseen. valmista softaa ja esimerkkejä löytyy niin paljon kuin jaksaa etsiä. - helppo debugata, testata ja arvioida (ei tarvitse allekirjoittaa NDA:ita)
MPS:ssä kaksi moodia: open a closed. open on sama kuin vanhemmassa internet tabletissa. closed-moodi on suljetumpi tyyliin iPhone. closed-moodi kasvattaa tietoturvaa ja lisää kopiointisuojauksia ja DRM:ää.
kansainvälinen olympiakomitea on kaikessa viisaudessaan kategorisesti todennut, että olympiakisoja ei netistä katsota ellei lähetys ole DRM-suojattu - piste. closed-moodi voi tarjota joitain bisnesmalleja.
maemossa pääsynhallinta (access control) sovelluskeskeinen, ei käyttäjäkeskeinen kuten esim. unix/linux-järjestelmissä, joissa samalla laitteella on tyypillisesti useita käyttäjiä. kännykällä on yleensä yksi käyttäjä.
salausalgoritmien vaihtaminen on tarvittaessa helppoa. kaikki algoritmit ovat julkisia, vain salasanat ovat salattuja. suurin osa Maemo Securityn softasta julkaistaan GPL2:lla tai LGPL2:lla
miksi ei GPL3? - GPL3 kieltää "tivoizationin" (http://en.wikipedia.org/wiki/Tivoization) ja ohjelmistopatentit - juridiset tulkinnat vielä epäselviä - ennakkotapaukset: Cisco/Linksys, OLPC
Maemoon ei toistaiseksi kuulu mitään GPL3-lisensoitua softaa.
Yhteenveto: - tähän mennessä kaikki näyttää hyvältä. hyödyt voittavat ongelmat. - suurin tähän mennessä huomattu hyöty on säästöt työkuormassa. koodaminen on helppoa - N900-kokemus tulee antamaan tärkeää palautetta - GPLv3-yhteensopimattomuus kasvava ongelma
Yhdysvalloissa FCC on todennut, että open source -järjestelmien pitää erikseen osoittaa tietoturvallisuutensa.
Yleisöltä: toisaalta Yhdysvaltain puolustushallinto on aivan hiljattain todennut, että kaikissa heidän järjestelmissään pitää oletusarvioisesti käyttää avointa lähdekoodia, jotta kaikki koodi voidaan tarkistaa ja todentaa.
myynnissä on koodinsekoittajaohjelmia (obfuscation), joilla koodista saadaan sekavaa. open source -maailmassa tällä ei ole paikkaa, mutta closed source -puolella tällä voidaan voittaa aikaa. suunnitteluperiaatteena tämä ei kuitenkaan toimi.
"eipähän kaikkein tyhmimmät hakkerit tule kyselemään tyhmiä"
