Archive for May, 2011

How I got seduced by the dark side and failed to resist (and a sparkle of hope?)

Wednesday, May 18th, 2011

I am not the biggest fan of google. Never was.  I loathe their hunger for information, any information, about individuals. I loathe the fact that they provide a single point of entry to a wealth of mineable information to the us government. I loathe how they have become a synonym for the internet. I was a strong opponent of anything google, and laughed at my friends when they got a google account to personalize their search results. Yet, by now I have become fully integrated in the google network. I have joined the borg. And I am even kinda happy about it.

Just try one for free

It started like so many addictions. You try one of their samplings. In my case, it started with google docs. I don’t remember what my first google doc was. I was participating in some project or the other and someone offered to share a document with me (and the rest of the team). Relucantly, I created a google account (with some feigned name and custom email address to keep up the pretence of anonymity) and went into the document. All went well, we shared information, changed the document collaboratively and that was it.

Yet, after a while, someone on another project wanted to share a document. So I created a new account, went in, and did the rest. Well, after a while I had 20 google accounts for as many documents. It became a nuisance, I had to log out and log in again to get to another document. So I crossed a line. I merged all the documents into one account.

Later, I bought my android phone (the HTC Dream aka G1) directly from the pusher. I created another google account to activate it, thinking I would miss out if I would use the phone without. I know that if you don’t use any of googles services, it is fine not to use a google account on your phone (after some hackery). But I was curious, ok??

So all went fine. I had my google docs account. I had my android phone account. I tried to take care and not leave any traces that would link the two together. I would never log in to google from my desktop with the android account and vice versa.

Meanwhile, I was running some web-based groupware suite to keep track of my appointments. This had some disadvantages though: it was clunky to use on my phone. Also, it was a nuisance to have yet another tool to maintain, keep track of security updates and what have you. I mean, an agenda should increase producitivty, right, not get in the way of productivity.

So I made a next big step, I decided I wanted to try google calendar. It came integrated on my phone by default and had a usable interface on the web so I could use it on my desktop as well. So after a few tentative test-runs I switched and decommisioned the groupware suite.

From there, it all went down-hill for me.  I started using google latitude to share my location on my blog during my trip through the US, used google voice to make cheap international calls from the us back home, started using google tasks to keep track of my todo items, initiated new google docs myself and even had a short period where I (unwillingly) experimented with google wave.

Antagonizing realization

But all this time I had stayed far from the one google service that symbolizes, for me at least, the summum of giving up any privacy one has: google contacts. I would not, never, share my contacts with google! But then  I wanted to upgrade my phone to cyanogen mod. Well, I actually had to flash the device because I broke the dalvik cache and it would not execute any app anymore. I had somehow deleted all the permission definitions. I could not even install new apps anymore. With no sensible way to backup my contacts, I started to contemplate the uncontemplateable: google contacts! Because of course, google apps still had all the permissions they needed.

So I broke. Synced my contacts, flashed the device and restored them again. And discovered how convenient google contacts actually is. I am now even looking into integrating google contacts into mutt.

And there you have it. That is the story of how I turned from a decent google opponent into a fully integrated cell of the great google information collection agency. I use google services to organize my life. And I like it.

Healing

Now, some people, when they hear I am addicted to google services, sigh “Oh you fool, I can do without just fine!”. Yeah well, that’s nice for them. But those are either the people that are impossible to work with because they always forget what they promised to do by when and need constant reminders to get even the silliest little thing done. Or they are the people with nice unconvoluted lives who generally are not that full of initiative or commitment.

For the rest of us, the people who operate on the same high level of energy as myself, tools like described above are essential to keep track of the many things going without keeping it all in your head and going insane. Some use apple’s crap but most are also on google.

I would love to kick this habit!

But their applications are so damn easy to use. They do what I want, without getting in the way. They are not overly complex. They don’t require me to maintain a server, keep track of security issues with the zillion of dependencies and keep an eye on the hardware. I can access them from wherever I want, on whatever device I want. I get reminders on the desktop and on the phone, so that whatever I’m doing I’m not going to miss an appointment.

Now, I can see a few ways out here. The first would be to reverse-engineeer some of their protocols. This should not be too hard, as it all works browser-based. It just takes time.

Another thing I could imagine to prevent google from looking at your contacts and tasks would be to write custom applications to access those but store everything encrypted. Looking at google tasks for example, I could simply write a desktop application and an android application that both use the same encryption algorithm and key to store each individual task encrypted. I could build an android contacts store to store my contacts encrypted, or on another server. It just takes time.

And oh, I could try and implement the google calendar backend protocol in a relatively simple daemon that would not require lots of dependencies and thus would be easy to maintain. Then redirect calendar traffic from my phone to my own backend server, and use sunbird as a frontend. It just takes time.

And there you have it. Google’s services are there. There is no open alternative for any of those services that is as easy to use, as integrated as googles services, cross-platform and without the hassle of maintaining dozens of packages.

Who knows. Now that I am aware of my problematic addiction, I might work up the energy to start a project to provide a more open alternative with privacy and encryption as the driving design forces, instead of data-mining and dollar signs. A suite where you have a choice to host it yourself, or on community-operated servers. Or perhaps even a non-profit that you pay a little amount towards keeping the software and hardware running for you.

I could see this kick off. Now all I need is a little time (or money so I don’t have to worry about making a living while making this work).

Addendum

By the way, in case you are wondering: I’m not entirely stupid. I do make my own backups of everything I stuff in their cloud.

Flattr this

Privacy, ITSec, overheid, hackers en koffie

Tuesday, May 3rd, 2011

Naar aanleiding van een discussie met een hacker die de zoveelste simpele beveiligingsfout in een overheidswebsite had ontdekt (jawel, een SQL-injectie) verwonderde ik me er over dat er geen enkele controle is op systemen die grootschalig persoonsgegevens verwerken of opslaan. Dat is eigenlijk raar, en geeft aan dat het besef van risico’s op het gebied van ICT bijzonder laag is bij de overheid. Ik was dan ook blij verrast een uitnodiging voor een ‘open koffie’ in mijn mailbox te vinden voor maandag 9 mei a.s. waarin dit onderwerp aan bod komt, georganiseerd door ambtenaar 2.0. Ik ben daarbij, om te pleiten voor een verplichte controle door een onafhankelijke partij die verstand heeft van beveiliging wanneer een systeem wordt opgeleverd, en deze partij al bij het opstellen van de eisen ind de aanbesteding te betrekken.

Het is niet de eerste keer, en zeker niet de laatste, dat een overheidssite slecht in elkaar blijkt te zitten. Vorig jaar al kondigde een andere bevriende hacker de ‘mogbug’ (‘month of government bugs’) aan. Hij/zij had in maar liefst 30 verschillende overheidssites lekken gevonden die toegang gaven tot persoonsgegevens of mogelijk gebruikt konden worden om bezoekers te misleiden en hun gegevens prijs te geven. Het gaat dan om elementaire fouten zoals SQL-injectie of cross-site scripting (XSS). Dit zijn fouten die een beginnend programmeur nog mag maken, maar bij een professioneel ICT-bedrijf simpelweg niet mogen voorkomen. En al helemaal niet bij een bedrijf dat door de overheid wordt betaald om systemen te ontwikkelen.

Dat deze fouten toch keer op keer de kop op steken heeft een aantal redenen. Om te beginnen is er bij de gemiddelde ‘brood-programmeur’ weinig besef van beveiliging. Er wordt gekeken naar de functionele eisen aan het systeem, en wanneer het geschreven programma daar aan voldoet is het ‘af”. De functionele eisen worden oogkleppen, de programmeurs bezien hun noeste arbeid slechts in het licht van normaal gebruik. Voer het systeem onverwachte input, en er gebeuren ineens vreemde dingen.

Er zijn enkele basis-principes die een programmeur kan aanhouden om dit soort voor de hand liggende maar verstrekkende fouten te voorkomen. De principes zijn geen goed bewaard geheim, wie een simpele google query doet naar “how to build secure web applications” is al een heel eind. Het hoeft niet meer dan een half uur te kosten om programmeurs bewust te maken van de meest voor de hand liggende risico’s. Wie dan ook nog eens een paar uurtjes steekt in het lezen van bijvoorbeeld de vrij beschikbare OWASP development guide zal niet snel meer met open ogen in de oude valkuilen lopen.

Kortom, met een kleine hoeveelheid basis-kennis en een dosis gezond verstand kunnen de keer op keer weer gemaakte beginnersfouten worden voorkomen. Echter, er is meer nodig. Veiligheid is niet iets dat achteraf aan een systeem kan worden toegevoegd. Voor een veilig systeem is het nodig reeds in de beginfase al na te denken over mogelijke aanvallen op het systeem. ‘Security by design’ moet het uitgangsprincipe zijn. Wanneer het systeem ontworpen wordt, moeten de architecten en ontwikkelaars al nadenken over de risico’s en hoe deze zo klein mogelijk te maken.

Een goed ontwerp maken dat ook rekening houdt met alle mogelijke aanvallen die het systeem kunnen breken kost natuurlijk wel wat meer tijd dan wanneer men uitsluitend let op de functionele eisen. Een gebrek aan inzicht in beveiliging leidt er toe dat overheidsinstellingen dit niet voldoende meenemen in aanbestedingen van grote software-projecten. Hierdoor zal, bij gelijke aandacht voor de functionele eisen, de partij die wel ‘security by design’ toepast duurder uitpakken dan de partij die dit onder het tapijt schuift.

Tot slot is het belangrijk dat een opgeleverd systeem door een derde, onafhankelijke partij wordt getoetst. Het is eigenlijk niet zo heel ongewoon. Wanneer de overheid een pand laat bouwen, wordt na oplevering een bouwkundige inspectie uitgevoerd. Een opgeleverd ICT-systeem wordt echter klakkeloos in bedrijf genomen. De partij die het systeem heeft ontwikkeld mag het ook installeren en uitrollen. Er is geen inspecteur, die kijkt of het systeem veilig is gebouwd. Er is niemand die kijkt of niet weer de gebruikelijke fouten zijn gemaakt.

Gelukkig beschikt Nederland over een gezonde en bloeiende hacker-community, mensen met een idealistische drijfveer. Mensen zoals in mijn inleiding al genoemd. Zij kijken ongevraagd met een kritische blik naar alle systemen die de overheid uitrolt. Zij vinden de voor de hand liggende, en minder voor de hand liggende fouten. En rapporteren het resultaat van hun onderzoek onbetaald aan de overheid. Jammer genoeg is dat vaak aan dovemansoren gericht, en worden de bezwaren onder het tapijt of in de doofpot geveegd. “We willen niet de indruk geven dat we onzorgvuldig met gegevens van burgers omgaan”, “er is al zoveel geld uitgegeven, we kunnen dit nu niet meer terugdraaien”, en andere excuses om het eigen falen te verbloemen zijn niet van de lucht. In uitzonderlijke gevallen kreeg de goedbedoelende klokkenluider zelfs te maken met juridische intimidatie om toch vooral stil te houden dat er iets fundamenteel niet deugt.

Ik denk dat de privacy van burgers gebaat is bij het structureel toepassen van controle door ter zake kundige beveiligingsexperts. Huur hiervoor een gerenommeerd ICT beveiligingsbedrijf in, of beter nog zorg voor een eigen overheidsdienst met mensen die snappen waar het over gaat. Zorg dat elk systeem eerst aan een uitgebreide controle wordt onderworpen, waardoor de elementaire vergissingen nog voor ingebruikname worden gesignaleerd. Betrek deze controleurs al vroeg bij het bedenken, uitwerken, implementeren en uitrollen van systemen zodat zij ook mee kunnen denken over de aanbesteding en al tijdens het uitvoeringstraject aan de bel kunnen trekken.

Het frappante is, er bestaan al een aantal organen die deze rol zouden kunnen (of moeten) vervullen. Enerzijds is er GOVCERT. Deze overheidsorganisatie heeft als missie ‘het voorkomen en afhandelen van ICT-veiligheidsincidenten’. In de praktijk blijkt dit een papieren tijger. Het team wordt niet tijdig bij grote aanbestedingen betrokken. Maar ook wanneer ze worden geconfronteerd met lekken in bestaande systemen, staan ze met de handen op de rug gebonden. Ze hebben geen macht, maar kunnen slechts advies geven.

Hetzelfde geld eigenlijk voor het College Bescherming Persoonsgegevens (CBP). Zij is ingesteld om toe te zien op de naleving van de wet bescherming persoonsgegevens. Hoewel ze advies kunnen geven, is het niet verplicht bij de implementatie van een systeem om ook de veiligheid hiervan te laten toetsen door het CBP (dit even los van de vraag of het CBP uberhaupt over de technische know-how beschikt om hier een deskundig oordeel over te kunnen vormen).

Dus zowel de officiele instanties zoals GOVCERT en het CBP alsmede de hacker-community lopen voortdurend achter de feiten aan. Pas als het eigenlijk al te laat is, krijgen zij de kans om lekken in de software te onderzoeken en te signaleren.

Ik pleit er daarom voor dat beveiliging van systemen een principieel uitgangspunt wordt bij de start van een nieuw groot overheidsproject. GOVCERT moet hierin een belangrijke rol krijgen. Dit betekent ook dat zij vooraanstaande experts op het vakgebied meer moeten betrekken, of wellicht zelfs in dienst moeten nemen. Ook moeten de bevoegdheden worden uitgebreid. Van vrijblijvend advies moet een fiat van GOVCERT een vereiste worden bij aanbestedingsprojecten en uitrol van nieuwe systemen.

En blijft de overheid falen? Dan is het aan ons, hackers van Nederland, om ons nog meer dan voorheen in te zetten om het falen aan de kaak te stellen. WOB de ontwikkeltrajecten, stel lijsten op van software-huizen die keer op keer onveilige systemen hebben afgeleverd, spreek top-ambtenaren publiekelijk aan op hun verantwoordelijkheid voor onze privacy, leg de zaken uit aan politici, benader de pers en blijf de overheid hacken. Wij zijn het technologisch geweten van de samenleving.

 

Flattr this