#seminaarikannu

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.

Jussi Vuokko, Louhi Networks Oy: OSS-ratkaisujen tietoturvallinen hosting

Avoimen lähdekoodin ratkaisut vahvassa hyötykäytössä Louhi Networksissä

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

Parhaita toimintamalleja:
- proaktiivinen toimintaprosessi
- käytä todellista testiympäristöä
- harkitse kaupallista tukea

Juhani Eronen, CERT-FI: Open Source -haavoittuvuuskoordinointi

kaksi ihmistä tekee cert-fi:ssä haavoittuvuuskoordinointia. tavalliselle kansalle tutuinta on cert-fi:n haavoittuvuusfeedi.

lainauksia Linus Torvaldsin kommenteista tietoturvasta. hae googlella "Linus security rants"

Torvaldsin mielestä kaikki turvallisuusbugit ovat tavallisia bugeja

Torvalds ajaa takaa sitä, että mikäli tietoturvabugeille annetaan erityskohtelu, niin se vähentää tuottavuutta ja aiheuttaa, että kaikki bugit merkataan non-security flagillä

sekä avoimessa että suljetussa lähdekoodissa on puolensa tietoturvan kannalta. 80/20 -sääntö pätee molempiin: 20 % hoitaa asiansa hyvin, 80 % huonosti

os-maailmassa henkilökemiat voivat olla ratkaisevat. jos riitaannut pääkehittäjän kanssa, niin yhteistyön tekeminen voi olla mahdotonta.

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

avoimen lähdekoodin etu ja vaikeus: you can fix it yourself
suljetun lähdekoodin etu ja vaikeus: you cannot fix it yourself

suurille yrityksille pitää varata enemmän aikaa valmistautumiseen. iso pyörä pyörähtää h i t a a s t i.

cert-fi:tä usein moititaan, että "meihin ei otettu yhteyttä". ei cert-fi:kään voi erikseen kaikkia kontaktoida.

@smoinen tuossa ohitetaan kokonaan se että useimpien open source -projektien ympärillä on yrityksiä jotka pystyvät tarjoamaan muutoksia ja korjauksia palveluna

Mika Boström, Nomovok: Puolivalmis palapeli - kuinka varmistaa osien saanti

@bergie Tästä COSSin Ilkka Lehtinen kommentoikin puheenvuoron lopussa. Tärkeä pointti siis.

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.

Jos OS-projekti on ollut aktiivinen viisi vuotta, niin siihen on yleensä syy: tuote on riittävän hyvä ja sille on riitävästi aktiivisia kehittäjiä

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ä

Yritykset ostavat markkinointipalveluja haluamastaan yrityksestä. Miksi näin ei tehtäisi myös esim. tuotetuen osalta?

Jaakko Lindgren, Tieto: Open Source Due Diligence

Lindgrenin vastuualueisiin kuuluu mm. Tiedon open source -asiat

Gartner sanoo, että 85 % yrityksistä käyttää jo avointa lähdekoodia, loput 15 % alkavat käyttää lähivuosina

Helsingistä löytyy lakimiehiä/kokonaisia asianajotoimistoja, jotka pelottelevat asiakkaita avoimen lähdekoodin "haitoista"

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.

Avoimen lähdekoodin ohjelmistot eivät muuta liiketoimintaa. Kysymys on riskinhallinnasta.

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

Legal open source due diligence:
- lisenssiehdot
- patentit
- tuoteturvallisuus
- tietoturva

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

patenttitarkastukset on paljon helpompi tehdä avoimen lähdekoodin tuotteisiin, koska koodi on avointa

DD-tarkastuksen laajuus on riippuvainen lopputuotteen käyttötarkoituksesta. täytyy olla paljon huolellisempi esim. asiakkaalle toimitettavien päätelaitteiden kuin esim. palvelinohjelmiston kanssa

palvelinohjelmistosta patenttiloukkaus tms. ongelma on helpompi korjata kuin asiakkaille toimitetuista laitteista/ohjelmistoista

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.

lähdekoodin sulkeminen ei siis poista tarvetta DD-tsekkaukselle

Lounastauko.

@smoinen Kiitos!

Ari Vainio, Priorite: Avoimen lähdekoodin työkalut sovelluskehityksen turvallisuuden kasvattamisessa

Jo vuonna 1975 on esitetty periaate, että piilottamalla ei voida parantaa tietoturvaa. Security through obscurity ei ole järkevä peruste.

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/

Pitkät metodit eivät olekaan tilastollisesti huonolaatuisempia. Tutkimusraportti: http://www.coverity.com/scan/

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.

Ohjelmiston toteutusvaiheessa niin paljon automatisointia kuin mahdollista bugien löytämiseksi aikaisemmin -> parempi laatu.

Yleisöltä: Firefoxin master-salasanasuojaus ei ole turvallinen. Kun salasana on kerran annettu, niin firefox liitännäisineen pääsee käsiksi sanasanoihin.

on se master salasana sentään vähän turvallisempi kuin se ettei salasanaa ole ollenkaan...

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.

@myrtti ilman muuta. ja jos koneelle on päässyt malwarea, niin käyttäjä on töpännyt jossain vaiheessa jo aikaisemmin.

Juhani Mäkelä, Nixu: Tietoturvan ja avoimuuden yhteensovittaminen - haasteita ja mahdollisuuksia

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)

Mer - täysin open source versio Maemosta (Maemo on Ubuntu)

case Maemo - Maemo platform security

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ä.

maemossa käyttäjän data on suojattu monin tavoin. esim. vain omilla sovelluksilla luku-/kirjoitusoikeudet.

laite käynnistyy aina closed-moodissa. alkuun tehdään tsekkauksia onko kaikki ok: esim. onko bootloader oikea ja kernel tunnistetaan.

Nokia vastannut yhteisön kysymyksiin Maemo Securitysta: http://wiki.maemo.org/Maemo_security

^ yllä olevan linkin takaa juttua mm. open ja closed -moodien eroista ja open-moodin rajoituksista

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

Antti Vähä-Sipilä, Nokia: Tietoturvan hallinta OSS-pohjaisille kuluttajatuotteille

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.

open source mahdollistaa pikaiset korjaukset. aina näin ei kuitenkaan käy (case OpenSSL)

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ä"

päivityskanavan on oltava kunnossa!
turvallisuus pitää rakentaa designin perusteella, ei tietoa piilottamalla

Tilaisuus ohi. Oikein mainio tilaisuus, kiitokset esiintyjille, järjestäjille ja yleisölle!

Aikamoinen tietopaketti, kiitos.

suurkiitokset raportoinnista, monta hyvää asiaa ajateltavaksi sait välitettyä!