avs Online

It's time for the quarterly blog post! (In reality, people who want to follow me probably do so via Twitter.)

Sometime last autumn, I finally got around to finalising my e-pamphlet on security in agile product management. I wrote the article, Software security in agile product management, for two kinds of people:

1. CISOs who, one day, get a visit from a guy whose business card says he's a "coach", wearing hipster horn-rimmed glasses, and hear that your R&D is going to be agile from now on.
2. Product Owners, who would like to go beyond the security features and actually help the teams to create secure code.

The former group tends to be of the opinion that having security in agile product development is hard. My argument is that it is not, if you are running a mature agile process. Scrum needs to be seen as an engine that consumes backlog items and produces working code, and if you feed software security activities into that engine, it will be reflected as a quality in the end product. This, of course, requires that the engine doesn't leak, or that it doesn't have some sort of ghost inputs.

The part that is of interest to Product Owners looks at bringing software security into a Leffingwellian "backlog feeder" system. The focus is on security requirements elicitation and getting non-functional security requirements in. It is important to make all security work visible on the backlog so not doing it will be an explicit decision, and also to make the cost of security visible.

(The rest of this post has nothing to do with security.)

The article was also a try to use Adobe InDesign to produce an e-book simultaneously with a PDF. If you have a high resolution display, say, a proper monitor, iPad, or a colour printer, I would recommend getting the PDF. It turns out that the HTML and EPUB exports leave a lot to be desired. I fed the HTML inside the e-book container to a validator and apparently the output doesn't even validate. Getting the pictures into their right places with respect to the text flow required manual (!) editing of the HTML. I spent significant time cleaning up the document XML representation in InDesign, and I have to say that the usability leaves a lot of room for development.

It appears that the support for reflowable and flexible documents is pretty hard to add into an application geared towards print production. This is visible not only in the e-book support but also in their newer products such as Muse (code name), where the designer is supposed to know the web page dimensions in pixels. I wish we finally got rid of "best viewed in 1024x768" footnotes and "we have detected you are using a mobile phone, would you like to view our mobile site" popups.

If I were the InDesign Product Owner, I'd probably beef up the document structure view of InDesign so that the document could be edited in the "DOM domain" (for logical structure) and a number of "layout domains" (for output in print PDF, reflowable HTML5, e-books, etc.).

I recently had the opportunity to speak about Privacy by Design at a Nixu seminar. I didn't really realise that the slides were available before being tweeted by @aukia. The tweet mentioned STRIDE+4, and I thought that I'd break my half-year blog silence by explaining what that idea was all about.

STRIDE is a Microsoft-originated security threat analysis method, essentially a pimped-up CIA model that approaches the target from various threat perspectives (S stands for spoofing, T for tampering, etc.) I find it a very useful and easily approachable threat analysis tool for architectural design and implementation.

My favourite way of applying STRIDE is to a data flow diagram that shows software components, data flows between them, and the bearers or storage media for those data flows. The idea is to evaluate each of the STRIDE aspects for each data flow. Its main benefit over a more freeform threat analysis is that it has a distinct end - once you've applied STRIDE to each data flow, you know you're done. Also, being slightly checklist-ey, it helps a non-security practitioner to cover all the main aspects. After some successful whiteboard-DFD STRIDE sessions, I began to think whether it would be possible to extend STRIDE into privacy and data protection world.

Privacy and security may have slightly deviating management and governance targets, privacy being more affected by legislation and often driven by the legal department and security by business continuity and functional security requirements. However, the closer you get to the architecture and code, the closer these two become. First, in order to actually enforce privacy controls, you have to apply security. Privacy folks speak of notice, choice, consent and controls, and security and secure software is what makes the controls work. Second, on the code level, it will no longer be separate corporate departments who would take care of security and privacy - they will converge in the same code repository, implemented by the same developers.

This led me to think whether I could extend STRIDE by bringing in those privacy aspects that could be analysed on the data flow level. Not all of them suit this level of analysis. The underlying business case could be hostile to privacy targets, in which case no amount of data flow level fiddling will save the day. However, I believe there are at least four aspects which can be easily done as a STRIDE extension. For the lack of a new acronym, I decided to call this STRIDE+4.

These plus-four are:

• Consent: For each outgoing data flow, ask whether we have a plausible argument that the user has given a permission to send the given data. As an example, if the user has clicked on a share button in a photo gallery app, it is plausible to assume that the user indeed wants to share the image. However, we might not be able to argue that the user has given a permission to share the GPS coordinates in the EXIF metadata, unless this was evident from the UI.
• Data minimisation: For each outgoing data flow, ask whether the data is the minimum that is technically required to enable the business logic. Do not send data which does not have a clear technical need to be sent.
• Jurisdictional boundaries: For each data flow, ask whether it is possible that the data flow will ever cross a jurisdictional or contractual boundary (for example, exits EU/EEC, or is sent to a service which is not under your ToS/privacy policy). If either end is mobile, this brings in an additional twist.
• Deletion and retention: For each data flow that is to a data storage, ask whether we have a deletion or retention policy, and how do we enforce it.

There are many more privacy principles, such as a requirement for the user to be able to check and rectify data, for data being accurate, and for the collection having a valid purpose. However, it is a bit difficult to bring these in on the data flow level. Even the ones in this set aren't pure data flow issues; they have UX and policy aspects. Even so, data flow analysis is the level on which they can be detected.

One aspect that privacy practitioners probably spot is the lack of "notice" which usually is paired with "consent". I've decided to leave it out from the +4 for a reason. I feel that it is intellectually more honest to ask the designers to build a plausible argument for user being aware of data being shared than referring to the service ToS where the "notice" has been buried in legalese on page 36 of 45. This way, there is no easy way out.

Many of the questions in both STRIDE and the +4 extension end up as being business case judgment calls. There are technical restrictions, business reasons, and all sorts of other real world impediments that may make it impossible to address every finding. But at that point STRIDE+4 has already fulfilled its purpose: the issue has been identified, discussed, and a conscious decision has been made.

Aiemmin pitämieni ketterien menetelmien ohjelmistoturvallisuusesitysten jatkoksi on nyt tullut vähemmän tietoturvakeskeiselle yleisölle suunnattu, suomenkielinen esitys ketterästä ohjelmistoturvallisuudesta. Tämä on pidetty AKVAn seminaarissa 29. syyskuuta.

Takarivistä kuuluu usein haukotus, joka on ansaittua palautetta. Prosessimalleja on helppo heitellä sivusta, mutta paholainen onkin todella pesiytynyt yksityiskohtiin, eikä yksi prosessi kesää tee. Nämäkin ehdotukset tulisi aina ymmärtää turvallisuutta edistävinä menetelminä. Ne eivät missään tapauksessa ratkaise ohjelmiston tietoturvaongelmia. Samaten on pidettävä mielessä, että prosessien käytännön seuraaminen on joka tapauksessa vaillinaista, vaikka ketteriä koutseja olisi palkattu firmaan läjäpäin.

"Ideologisesti puhtaasta" ketterästä tai hoikasta mallista lähteminen on kuitenkin tärkeää prosessimäärittelyssä sen vuoksi, että puhdasta mallia on aina helpompi sovittaa eri tavoin saastuneisiin käytäntöihin kuin ottaa jo jollakin toisella tavalla saastunut malli käyttöön omassa organisaatiossa. Puhtaat mallit kun saastuvat yleensä yrityksen vallitsevien käytäntöjen vuoksi ja nämä käytännöt vaihtelevat yrityksestä toiseen. Esimerkiksi tuotteen omistaja, product owner, on oikeastaan jonkinlainen antropomorfinen kuvaus kaikille niille asioille, jotka kunnollisessa softakehityksessä pitäisi tehdä. Koska tällaisia superhenkilöitä on vaikea löytää (ainakaan halvalla), eri firmat toteuttavat tuotteen omistajan roolin eri tavoin - esimerkiksi hajauttamalla vastuita usean henkilön kesken. Tämä tuotteen omistajan roolin tulkinta on sidoksissa yrityksen muuhun organisaatiorakenteeseen, poliittiseen peliin, lasikattojen korkeuteen ja selkäänpuukotuksen asteeseen, HR:n kykyyn rekrytoida ja firman kiinnostavuuteen työpaikkana. Tiettyä tuotteen omistajan roolin toteutusta ei siis voida välttämättä suoraan kopioida firmasta toiseen sellaisenaan.

Yllä mainitussa suomenkielisessä esityksessäni tärkeä havainto on myös se, että ketterissä menetelmissäkin voidaan sortua helposti siihen, että niihin lisätään osia, jotka näyttävät pinnallisesti ketteriltä, mutta eivät olekaan pinnan alla hoikkien periaatteiden mukaisia. Hyvä esimerkki on nk. hardening-sprintti, joka sinänsä kuulostaa ketterältä ("sprintti") ja jonka joku voisi vielä ehkä perustella release train -metodin yhteydessä, mutta todellisuudessa se luo laatuvelkaa.

Oli prosessikehys mikä hyvänsä, yhtä vaatimusta ei tietoturvallisuuden saamiseksi voida ohittaa ja se on koulutus. Sekä tuotteen omistajat että suunnittelijat ja toteuttajat tarvitsevat riittävästi tietoa turvallisuudesta. Suurin osa tästä tiedosta ei kuitenkaan ole sitä kuuluisaa rakettitiedettä, vaan pikemminkin oikeaa, ilkeää mielenlaatua. Koulutuksessa hyvä menetelmä onkin vanha kunnon nuotiopiiri: vanhempi tieteenharjoittaja painaa päänsä hieman alaspäin, varjo peittää otsan ja kuulijat saavat taas kuulla yhden tarinan tietoturvallisuuden juoksuhaudoista.

Scrum-tyyppisen toiminnan ja ohjelmistoturvallisuuden hallinnan yhdistäminen on ollut viime aikoina merkittävä teema työpuolella. OWASP AppSec Research 2010 Stockholmissa pitämäni esitys ja kuva aiheesta. Huhtikuussa järjestimme myös workhopin samasta aihepiiristä.

I needed to get semi-authentic Commodore 64 colours for a job, and thought that perhaps someone else needs them too. Here's the Commodore 64 colour palette in RGB as an Adobe Swatch Exchange (.ase) file.

The palette is taken from Philip Timmermann's excellent page on VIC-II colours. The colours will probably look a lot less vivid than you remember, for two reasons: 1) in PAL YUV, the original C=64 colour space, your telly just clipped the oversaturated colours, and this palette here is normalised to fit into the RGB gamut, and 2) if you use this in a CMYK job, there are out-of-gamut colours even in this RGB palette. Given the variety of 1980s family TVs that C=64s were hooked to, probably no-one saw the same colours anyway, so don't sweat it.

Näyttää siltä, että kaikki maailman ruoat voi tehdä noin 6000 valmistusaineesta.

Omasta työstä voi aika harvoin puhua julkisuudessa, mutta aina välillä näitä hetkiä tulee.

Minua ja Nokian tuoteturvallisuusjohtajaa haastateltiin Gary McGraw'n Reality Check -podcastiin. Gary on tunnettu ohjelmistoturvallisuusalan hahmo ja hänen podcastinsa ovat näissä piireissä ihan hyvin kuunneltuja, joten oli ilo ja kunnia olla mukana.

Facebookin yksityisyydensuoja-asetusten perässä juokseminen on tehty hankalaksi. Tämä on nyt kolmas versio Facebookin yksityisyysartikkelistani, joka on päivitetty vastaamaan Facebookin joulukuun 2009 muutoksia. Artikkelin linkki on säilynyt samana. Artikkeli on alun perin julkaistu 21.2.2009. Mukailen 10 Privacy Settings Every Facebook User Should Know -artikkelia.

Kaikkein tärkeintä Facebookissa - ja kaikessa nettiviestinnässä sähköpostista blogaamiseen - on nk. Washington Post Test. Suomeksi se voisi olla vaikkapa Ilta=Sanomat -testi: älä koskaan laita nettiin mitään, mitä et haluaisi nähdä Ilta=Sanomien lööpissä sitten, kun olet ministeri.

Tätä testiä kannattaa käyttää esimerkiksi ennen kuin kirjoitat statukseesi heränneesi katuojasta, kirjoitat seinäkommentin, jossa haukut pomosi lyttyyn tai jaat kuvan, jossa nenästäsi valuu leivinjauhetta klo 03:23.

Facebookin yksityisyydensuojapuhdistus alkaakin useimmiten kaikkien turhien kuvien poistamisella. Kohtelias ihminen poistaa myös kuvat, joissa esiintyviltä ihmisiltä ei ole pyydetty lupaa kuvan julkaisuun. (Hieman tähän liittyen - ovatkohan kaikki vanhemmat aivan varmoja siitä, että heidän lapsensa haluavat lapsuutensa dokumentoituna Internetiin?) Yksityisyysasetusten Kuvat-alasivulta kannattaa vaihtaa kuvien näkyvyys mahdollisimman pieneksi. Kuvat voi myös jaotella enemmän ja vähemmän yksityisiin albumeihin.

Jos sinua harmittaa se, että kaverit merkitsevät sinut kuviinsa, joissa päähenkilönä ovat punainen nenäsi ja kaljatuoppi salamavalon syleilyssä, Yksityisyysasetusten Profiili-alasivulta voi valita ja "Kuvat, joihin sinut on merkitty" sekä "Videot, joihin sinut on merkitty" -yksityisyysasetuksiksi "Mukautettu" ja "Vain minä".

Identiteettivarkauksien ehkäisemiseksi kannattaa myös ehkäistä oman syntymäpäivän ja osoitteen näkyminen profiilissa. Tämän voit tehdä Profiili-sivun Tiedot-välilehdessä - valitse "Älä näytä syntymäaikaani profiilissa" ja anna osoitteelle kenkää tai minimoi sen näkyvyys yksityisyysasetusten Profiili-alasivun Yhteystiedot-välilehdellä.

Usein kuulee ihmisten tuskailevan, että "kun tuolla Facebookissa on noita ei-niin-kavereita, mutta en kehtaa niitä poistaakaan". Tähän Facebook tarjoaa hyvän ratkaisun: kaverilistat. Luo vaikkapa cow-orkereille oma "työkaverit"-lista ja kerran kätellyille kontakteille "satunnaiset"-lista. Tämä onnistuu Kaverit | Kaikki kaverit -näytöstä, valitsemalla vasemmalta "Luo uusi lista" ja kaverien lisäys listaan on helpointa klikkaamalla "Valitse useita kavereita".

Tämän jälkeen voit mennä yksityisyysasetuksiin (Asetukset | Yksityisyysasetukset | Profiili) ja valita kunkin kohdan alasvetovalikosta "Mukauta". Lisää luomasi kaverilista punertavaan kieltolistaan ja a vot, olet sulkenut kaverisi ulos sisäpiiristä ilman verenvuodatusta. Samalla kannattaa pistää kaikki tuon sivun asetukset muutenkin kuntoon.

Kaverilista on Facebookissa oletusarvoisesti julkinen. Tämä mahdollistaa esimerkiksi varsin kehittyneet huijaukset: huijari saa helposti selville, keihin luotat. Jostain syystä kaverilistan näkyvyyttä ei ole laitettu samaan paikkaan kuin muita yksityisyysasetuksia. Voit poistaa kaverilistasi näkymästä profiilissasi menemällä profiilisivulle ja klikkaamalla kynäikonia kaverilaatikon oikeassa yläkulmassa ja poistamalla rastin ruudusta "näytä kaverini profiilissani". Valitettavasti tämä asetus on joko/tai, ja lista on kuitenkin julkisemmasta päästä informaatiota - esimerkiksi sovellukset saavat tietoa siitä.

Jos sinulla on paljon "kavereita", jotka vasten parempaa ymmärrystä avautuvat seinällesi yksityisasioistasi, Yksityisyysasetukset-sivun Profiili-kohdasta kannattaa poistaa rasti "Kaverit saavat kirjoittaa seinälleni".

Sovellukset ovat useimmiten Facebookin ulkopuolisia toimintoja, joille vuodetaan paljon tietoa sinusta - ja ne voivat olla ties missä päin maailmaa, eikä niiden operoijista juuri saa tietoa. Sovelluksille ei siis kannata antaa yhtään liikaa tietoa. Valitse Sovellukset | Sovellusasetukset -sivulla alasvetovalikosta "Sallittu" ja poista X-merkkiä klikkaamalla kaikki ne sovellukset, joita et aktiivisesti käytä. Kun sinulle lähetetään kutsuja sovelluksilta, ota myös tavaksi klikata "Estä tämä sovellus" pelkän kutsun ohittamisen sijaan, jos kyseinen sovellus ei kiinnosta. Samalla vähennät sovellusten turhia viestejä. Lopuksi mene Yksityisyysasetukset-sivun kautta Sovellukset-sivulle ja valitse Asetukset-välilehti. Poista sieltä rastit kaikista ruuduista. Estä myös Facebook Connect- ja Beacon-toiminnallisuudet rastittamalla annetut ruudut (aiemmin tämä edellytti rastien poistamista, joten lue tekstistä ensin, mitä Facebook tänään haluaisi sinun tekevän).

Lopuksi kannattaa estää Facebook-profiilin näkyminen erilaisissa hauissa ja mainostusverkostoissa. Mene Yksityisyysasetusten Haku-sivulle ja valitse, ketkä saavat nähdä sinut haussa Facebookin sisällä, sekä minimoi hakutuloksessa näytettävät tiedot. Poista rasti ruudusta "Julkinen hakutulos", koska muuten kuka vain löytää sinut Googlella. Viimeistele näkymättömyys yksityisyysasetusten Uutiset ja Seinä -sivun Facebook-mainokset -välilehdellä, jossa kiellä näkyminen niissä (sivulla on ainakin kaksi alasvetovalikkoa, joita muuttaa).

Tervetuloa turvallisempaan Facebookiin.

Sähköisen äänestyksen yhteenvetomuistion kommentointia.

Suurin osa varmasti tuntee jo TED Talks -videopodcastsarjan, jossa TED-konferenssin äärimmäisen kiinnostavia esityksiä pääsee seuraamaan, vaikkei olisi rikas, kuuluisa tai Alex Niemisen shortlistalla. Uusin iTunes toi ruudulleni uutta (siis uutta minulle itselleni), joka varmasti kiinnostaa TED-narkkareita:

iTunes U.

iTunes U listaa sadoittain, todennäköisesti tuhansittain, ilmaisia luentoja erilaisista yliopistoista ja "yliopistoista" ympäri maailmaa. Mukana on pitkän linjan nettiopetusmateriaalitoimijoita kuiten MITin OpenCourseWare, iPod-yleisölle tarkoitettuja yhden metroasemavälin mittaisia luentoja (esim. Penn 60 second lectures) ja pidempiä opetusohjelmakokonaisuuksia (vaikkapa 24 tuntia iPhone-sovellusohjelmointia Stanfordin yliopistosta).

Opintopisteitä (tai -viikkoja meille ikälopuille) näistä ei valitettavasti kovin helpolla heru, mutta jos minulla olisi ollut TED Talks ja iTunes U opiskeluaikoinani, olisin ehkä a) löytänyt uusia ideoita ja saattanut opiskella laajemmin erilaisia tieteitä ja b) ollut vielä katkerampi opetuksen tasosta.