<rss version="2.0">
 <channel>
  <title>Infosecurity Blog</title>
  <link>http://www.infosecurity.net</link> 
  <description>Infosecurity Blogs RSS</description>  
  <copyright>(c) Array Publications</copyright>  
  
<item>
    <guid isPermaLink="true"><![CDATA[http://www.infosecurity.net/Blogs/76144/Voor-het-vaderland"]]></guid>
    <title><![CDATA[Voor het vaderland]]></title>
    <description><![CDATA[<p>We gaan &ndash; heel zorgvuldig &ndash; de cloud in. We kiezen voor een Nederlandse provider die zijn servers in Nederlandse datacenters heeft staan. Het personeel is gescreend, er is een strak beveiligingsbeleid, aan alles is gedacht. Dat moet ook wel, want onze internationale onderwijsinstelling heeft studenten van vele nationaliteiten. Privacy is voor hen soms een kwestie van leven of dood. Gelukkig beschermen de &lsquo;Data Protection Directive 95/46/EU&rsquo; en de daarop gebaseerde nationale wetten hen tegen ongewilde uitwisseling van gegevens met landen buiten de Europese Economische Zone (de Europese Unie plus een aantal landen in de regio).<br />
<br />
Zoals gezegd: onze zorgvuldig geselecteerde cloudprovider heeft alles onder controle. Alles, behalve haar aandeelhouders. Op een goede dag krijgen die een aanbod dat te goed is om te weigeren: een buitenlandse partij wil onze cloudprovider overnemen en is bereid een forse premie op de laatste beurskoers te betalen. Doen! De stukken worden massaal aangeboden en luttele maanden later is het zover. Niet alleen de (voormalige) aandeelhouders zijn blij, ook de medewerkers en klanten zien een glorierijke toekomst. Er is genoeg geld om te investeren en de Amerikaanse moeder introduceert goede ideeën en technieken. En dan wordt duidelijk dat onze zorgvuldig geselecteerde cloudprovider onderdeel is van een Amerikaanse multinational. Oké, de VS is geen schurkenstraat &ndash; no problem.<br />
<br />
Dan komt er een e-mail uit het hoofdkantoor in de VS, gericht aan de directie van onze hostingprovider. Daarin wordt opdracht gegeven om de gegevens van één van zijn klanten &ndash; ónze gegevens dus &ndash; ter inzage te geven. Een ongebruikelijk verzoek, maar de rest van de e-mail is ronduit schokkend. Als onderdeel van een Amerikaans bedrijf zijn directie en medewerkers van onze cloudprovider wettelijk verplicht om mee te werken aan dit &lsquo;onderzoek naar activiteiten die mogelijk de belangen van de VS zouden kunnen schaden&rsquo;. En, volgens dezelfde Amerikaanse wet, is het ten strengste verboden om de persoon of de organisatie waarvan gegevens worden opgevraagd, daar toestemming voor te vragen, of zelfs maar over in te lichten. Een &lsquo;gaging order&rsquo; heet dat heel plastisch.<br />
<br />
Hè? Een Amerikaanse wet die hier in Nederland onze landgenoten verplicht om gegevens van derden te kopiëren en hen verbiedt het slachtoffer toestemming te vragen of zelfs maar iets te vertellen &ndash; kan dat zomaar? Yes, we can.<br />
<br />
De &lsquo;Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism Act of 2001&rsquo;, door liefhebbers aangeduid als de &lsquo;USA Patriot Act&rsquo;, stamt uit 2001 en werd onder president George W. Bush aangenomen naar aanleiding van de terreuraanslagen van 11 september van dat jaar. De wet zou voor vijf jaar gelden. In 2006 werden grote delen voor nog eens vijf jaar verlengd en in mei 2011 werd een aantal onderdelen van de wet met vier jaar verlengd. Eén van die onderdelen is het stiekem verzamelen van informatie uit documenten in allerlei vormen.<br />
<br />
Toen eerder dit jaar aan Gordon Frazer, de baas van Microsoft UK, werd gevraagd of hij kon verklaren dat de gegevens uit zijn datacenter onder geen beding aan de VS zouden worden uitgeleverd, gaf hij een eerlijk en helder antwoord: &ldquo;Nee, die garantie kunnen wij niet geven&rdquo;.<br />
&nbsp;</p>
<p>Ernst Lopes Cardozo<br />
<a href="mailto:e.lopescardozo@aranea.nl">e.lopescardozo@aranea.nl</a></p>]]></description>
    <pubDate>Thu, 01 Sep 2011 15:49:50 GMT</pubDate>
    <link><![CDATA[http://www.infosecurity.net/Blogs/76144/Voor-het-vaderland]]></link>     
</item>
<item>
    <guid isPermaLink="true"><![CDATA[http://www.infosecurity.net/Blogs/76142/APT-een-trend-"]]></guid>
    <title><![CDATA[APT een trend?]]></title>
    <description><![CDATA[<p>Er wordt in de securitymarkt tegenwoordig veel gesproken over de zogeheten Advanced Persistent Threat. Het is een term die stamt uit de cyberspionagewereld. Daar wordt hij in kringen van met name militaire experts al wat langer gebruikt voor een zorgvuldig voorbereide operatie, waarbij het ene land onder de cyberradar van het andere land doorvliegt en zich zo geruisloos en voor langere tijd met malware op diens digitale systemen weet te nestelen. Doel is het naar buiten sluizen van gevoelige informatie betreffende de nationale veiligheid van &lsquo;de vijand&rsquo;. Het is dus niets meer en minder dan digitaal inlichtingenwerk. De ontwerpers van zo&rsquo;n APT gaan zeer doelgericht te werk, kunnen putten uit een rijk arsenaal aan middelen (geld, kennis, et cetera), doen vooraf aan hun operatie heel gedegen onderzoek en maken iets dat primair bedoeld is om niet gedetecteerd te worden.<br />
<br />
U en ik hoorden daar tot voor kort dan ook nooit iets over. We konden natuurlijk een sterk vermoeden hebben dat dit soort activiteiten plaatsvond, maar we namen er nooit echt kennis van. Tot Stuxnet in de openbaarheid kwam. Stuxnet was geen APT in de zin van zojuist beschreven, want sabotage en niet informatie verzamelen was hier het doel. Maar verder had het natuurlijk alle ingrediënten van een APT. Het was daarmee een heerlijke kluif voor de IT-markt van securityleveranciers. Dit hebben we nog nooit eerder gezien, klonk het commentaar. Iets van die omvang en met een dusdanige scherpzinnigheid in elkaar gezet, is ongekend.<br />
<br />
Van &lsquo;ongekend&rsquo; naar een trend blijkt voor de securitymarkt over het algemeen een kleine stap. Natuurlijk werd dit voorval direct door hen aangegrepen om het fenomeen APT in bredere kring bekendheid te geven, maar &lsquo;mainstream&rsquo;, zoals het onlangs door de SBIC uitgebracht rapport &lsquo;When Advanced Persistent Threats Go Mainstream&rsquo; suggereert, is het verschijnsel nog zeker niet.<br />
<br />
Vanzelfsprekend zullen de grotere industriële bedrijven en kennisinstellingen van onze kenniseconomie zich moeten wapenen tegen de digitale inlichtingenactiviteiten uit de hoek van minder kennisintensieve landen. Maar ik ben zo optimistisch te geloven dat die daartoe niet hoeven worden aangezet door een APT-hype in de infosecuritymarkt.<br />
<br />
Dus APT een trend? Het is tot nu toe vooral een trend er in de securitymarkt veel over te praten!<br />
&nbsp;</p>
<p><strong>Dick Schievels<br />
</strong></p>]]></description>
    <pubDate>Thu, 01 Sep 2011 15:40:49 GMT</pubDate>
    <link><![CDATA[http://www.infosecurity.net/Blogs/76142/APT-een-trend-]]></link>     
</item>
<item>
    <guid isPermaLink="true"><![CDATA[http://www.infosecurity.net/Blogs/74081/D-Day"]]></guid>
    <title><![CDATA[D-Day]]></title>
    <description><![CDATA[<p>Bent u ook verantwoordelijk voor de informatiebeveiliging van uw organisatie? Zo ja, dan weet u waarschijnlijk ook dat het niet de vraag is óf, maar wanneer uw organisatie met een ernstig incident te maken krijgt. De maand april gaf een aardig beeld van wat er misgaat bij grote en kleine bedrijven. Het waren niet de minsten: Amazon en Sony kwamen wereldwijd in het nieuws door uitval en dataverlies bij de eerste en schending van de vertrouwelijkheid van gegevens van klanten, mogelijk inclusief hun creditcardgegevens, bij de laatste. Nu zijn Amazon en Sony geen amateuristische of armlastige organisaties, maar toch leden beide groot gezichtsverlies en directe financiële schade.<br />
<br />
Er is geen enkele reden om aan te nemen dat u en uw organisatie niet iets soortgelijks zou kunnen overkomen. Zelfs als u alles tiptop in orde hebt, zijn er nog allerlei zakelijke partners die roet in úw eten kunnen gooien: bedrijven die uw creditcardtransacties afhandelen, uw back-uptapes bewaren, uw oude apparatuur recyclen, uw printers en kopieerapparaten onderhouden (met hard disks vol met informatie die ooit werd geprint of gescand) en nog veel meer. Nee, u kunt er weinig tot niets aan doen, maar toch zullen de klanten uw organisatie er op aankijken.<br />
<br />
Natuurlijk doet u er alles aan om de organisatie bewust te makken en houden van het belang van informatiebeveiliging. Zeker, u controleert van elk project of de beveiligingsaspecten zijn doordacht en of er adequate maatregelen zijn genomen. Maar u weet dat het niet genoeg is, dat Murphy op het ongelukkigste moment toe zal slaan. Wat doen we eraan?<br />
<br />
Het begint met verwachtingsmanagement. Als uw management denkt dat het uw taak is te voorkomen dat er ooit iets misgaat, dan bent u bij voorbaat verloren. Verklaar dus nooit dat u alles onder controle heeft, dat bepaalde incidenten bij u niet mogelijk zijn &ndash; zelfs niet als u ervan overtuigd bent dat uw maatregelen waterdicht zijn. Uw taak is het verkleinen van de kans op incidenten én het minimaliseren van de impact. Als u er vanuit gaat dat er met de creditcardtransacties vroeg of laat iets misgaat, overweeg dan om de impact te verminderen door de transacties in twee groepen te splitsen en daar twee partners voor aan te trekken. De meerkosten zijn beperkt en misschien zelfs nihil, want u kunt deze beide scherp houden door hun prijzen en prestaties met elkaar te vergelijken.<br />
<br />
Bereid uw organisatie voor op het onvermijdelijke. Een draaiboekje met aspecten als het escalatieschema (wie belt wanneer de algemeen directeur?), het communicatieplan (wie staat de pers te woord en vooral: wie niet) en uiteraard: welke acties liggen er klaar om de schade te beperken? Er zijn genoeg voorbeelden van hoe het niet moet en hoe het ook kan. Transparantie blijkt een goed uitgangspunt te zijn, al is het zelden de eerste reflex van organisaties.&nbsp;<br />
<br />
Stel er belt iemand naar uw organisatie met het verhaal dat uw website klantgegevens lekt. Zet direct een berichtje op de site waarin u dat blote feit meldt. &ldquo;We hebben gehoord dat &hellip;, we zoeken het uit en houden u op de hoogte.&rdquo; Blijkt het loos alarm, dan wordt dat eraan toegevoegd. &ldquo;We hebben niets gevonden, gaan er vooralsnog vanuit dat het niet klopt.&rdquo; In alle gevallen: zorg dat de klant de eerste is die het weet, én dat ze het van ú horen!</p>
<p>Ernst Lopes Cardozo<br />
<a href="mailto:e.lopescardozo@aranea.nl">e.lopescardozo@aranea.nl</a><br />
&nbsp;</p>]]></description>
    <pubDate>Wed, 18 May 2011 12:05:12 GMT</pubDate>
    <link><![CDATA[http://www.infosecurity.net/Blogs/74081/D-Day]]></link>     
</item>
<item>
    <guid isPermaLink="true"><![CDATA[http://www.infosecurity.net/Blogs/74080/Trial-en-error"]]></guid>
    <title><![CDATA[Trial en error]]></title>
    <description><![CDATA[<p>Infosecurity is erg belangrijk, maar je kunt het soms een beetje overdrijven. Toen ik eind februari mij aan het prepareren was voor CeBIT, u weet wel die steeds rustigere beurs georganiseerd door onze oosterburen in Hannover, probeerde ik als vertegenwoordiger van de pers mij toegang te verschaffen tot een beveiligd gedeelte van de CeBIT-site. Ik was een aardig eind op streek. Ik moest na mijn gebruikersnaam, waarvoor ik mijn e-mailadres kon gebruiken, alleen nog een zelf te kiezen wachtwoord invoeren.<br />
<br />
Dat invoeren werd begeleid door een rood balkje. Terwijl ik mijn zelf bedachte wachtwoord intikte, u weet wel dat wachtwoord dat ik overal gebruik, waarmee ik mijn eigen soort Single Sign-on tracht te creëren, werd dat balkje slechts voor zestig procent groen. Ik kwam niet verder.<br />
<br />
Van een van mijn eindredacteuren die ik te hulp riep, kreeg ik de raad hoofd- en kleine letters te gebruiken en dat hier en daar af te wisselen met wat rare tekens. Zo gezegd, zo gedaan, en ja hoor, eindelijk de hele balk op groen. Tóch weer een foutmelding.<br />
<br />
Nu bleek ik ongeoorloofde tekens te hebben verwerkt in mijn dus allang niet meer Single Sign-on-geknutsel. Weer overnieuw, maar wat ik ook probeerde, ik kwam er niet door. Het leek ook wel alsof die module leerde en het me steeds moeilijker maakte. En slaagde ik per ongeluk toch, dan kwam-ie weer met de smoes van die ongeoorloofde tekens opzetten. Ik gaf het op en verliet de site.<br />
<br />
&ldquo;Zal ik het ook eens proberen&rdquo;, vroeg mijn eindredacteur. En verdomd, hij slaagde binnen twee minuten voor de test. Ik met zijn wachtwoord in de hand &ndash; &lsquo;alleen even dat ene cijfertje veranderen&rsquo;, gaf hij mij mee &ndash; probeerde ik het nog één keer opnieuw. Nu werd ik al bij het invoeren van mijn gebruikersnaam, mijn e-mailadres dus, geweigerd. Dat was bij het systeem al in gebruik, werd mij gemeld.<br />
<br />
Ik heb nog een mailtje gestuurd naar de CeBIT-helpdesk. Nooit meer wat op gehoord. Wel naar CeBIT afgereisd. Kon zonder pas, of wat dan ook, zo naar binnen wandelen. Gekke wereld toch.</p>
<p>Dick Schievels</p>]]></description>
    <pubDate>Wed, 18 May 2011 12:01:46 GMT</pubDate>
    <link><![CDATA[http://www.infosecurity.net/Blogs/74080/Trial-en-error]]></link>     
</item>
<item>
    <guid isPermaLink="true"><![CDATA[http://www.infosecurity.net/Blogs/72316/Postzegel-voor-mail"]]></guid>
    <title><![CDATA[Postzegel voor mail]]></title>
    <description><![CDATA[<p>Spam is oud nieuws. Ja het bestaat, ja het kost ons allemaal ergernis en geld, maar je kunt er niets aan doen. Af en toe wordt er een grote spammer gepakt of wordt een botnet ontmanteld, en dan zakt het spamvolume voor een paar weken in, waarna alles weer bij het oud is.<br />
<br />
Spam is alleen mogelijk omdat het versturen van e-mail vrijwel gratis is. Dan is het niet erg dat de opbrengst per verstuurde mail niet meer dan een cent is: een miljoen centen is tienduizend euro, een mooi inkomen als je er weinig voor hoeft te doen. Als het versturen van elk mailtje een cent zou kosten, levert deze vorm van spammen niets meer op. Vraag: zouden wij er een cent per mailtje voor over hebben om spamvrij te zijn? Nooit meer onze mail in een spamfilter te verliezen? Een flink deel van de internettransportcapaciteit vrij te maken? Geen spam meer over onze nog niet zo erg goedkope mobiele verbindingen te ontvangen?<br />
<br />
Stel dat de mensen van goede wil besluiten dat ze best 0,01 euro per adres per verzonden mail willen betalen. Wie gaat dat innen? Uiteraard gaan we niet per mailtje afrekenen. De beheerder van onze uitgaande server, of dat nu onze ISP, Gmail of Hotmail is, zal ons mailgebruik tellen en eens per maand afrekenen. Misschien wil hij dat we een prepaid rekening openen. Als het eenmaal is opgezet, hoeft dat niet veel werk te zijn. En daarbij, hij hoeft er niets van af te dragen, de opbrengst is feitelijk alleen voor het administreren.<br />
<br />
Wat hij wel moet doen, is zorgen dat alleen onze eigen mail wordt geaccepteerd. Dat begint er mee dat we ons bij zijn server moeten identificeren. Kan makkelijk, alle protocollen en programma&rsquo;s zijn er klaar voor en XS4All en Gmail doen het al jaren. Een bijkomend voordeel is dat je vanuit elke plek op aarde mail kunt versturen; je bent niet langer gebonden aan het netwerk van je ISP thuis. Zelf moeten we zorgen dat spammers onze mailserverlogins niet te pakken krijgen, om daarna op onze kosten hun spam te gaan versturen. Als dat toch gebeurt &ndash; en natuurlijk zal het gebeuren &ndash; dan zal de spamrun worden beperkt tot ons saldo bij de mailprovider op is. Wie dagelijks vijftig (externe) mails naar gemiddeld twee adressen verstuurt, verstookt per maand minder dan drie euro. Per gekraakt mailaccount zal de spammer misschien honderd mails kunnen versturen; het kraken mag hem dus niet te veel tijd en geld kosten, anders is de lol er snel af.<br />
<br />
Daarmee zijn er we er natuurlijk niet. Onze mailservers mogen alleen betaalde mail aanpakken. Er moet een &lsquo;postzegel&rsquo; op zitten. Nu wordt de meeste mail niet als losse berichten doorgegeven, maar als een hele sliert mail van de zendende mailserver naar de ontvangende. In plaats van elk bericht van een elektronische postzegel te voorzien, kunnen we volstaan met het authenticeren van de verzendende mailserver als een partij die zich aan de spelregels houdt. Mail van losse pc&rsquo;s zal niet meer worden geaccepteerd.<br />
<br />
Een paar jaar gelden waren er als eens voorstellen om alleen gewaarmerkte mail te accepteren. Daar is weinig van terechtgekomen. Ik vermoed dat de ISP&rsquo;s het niet zagen zitten: extra moeite doen zonder dat er iets tegenover staat. Enigszins kortzichtig, want inmiddels hebben ze allemaal noodgedwongen spamfilters geïnstalleerd. Mijn voorstel levert ze direct wat op: extra inkomsten waarvoor ze niet al te veel hoeven te doen. Er zijn ten slotte maar weinig ondernemers die niet bereid zijn een kassa neer te zetten als ze daar vervolgens geld in kunnen ontvangen. Kans van slagen?</p>
<p>Ernst Lopes Cardozo<br />
<a href="mailto:e.lopescardozo@aranea.nl">e.lopescardozo@aranea.nl</a><br />
&nbsp;</p>]]></description>
    <pubDate>Mon, 21 Mar 2011 15:15:13 GMT</pubDate>
    <link><![CDATA[http://www.infosecurity.net/Blogs/72316/Postzegel-voor-mail]]></link>     
</item>
<item>
    <guid isPermaLink="true"><![CDATA[http://www.infosecurity.net/Blogs/72315/Alice-en-Bob"]]></guid>
    <title><![CDATA[Alice en Bob]]></title>
    <description><![CDATA[<p>Alice en Bob? &lsquo;Who the hell&rsquo; zijn Alice en Bob? Ingewijden weten natuurlijk direct over wie het gaat, maar voor niet-ingewijden zal ik het nog even uitleggen. Alice en Bob spelen de hoofdrol in vrijwel elk scenario gesitueerd in de wereld van de cryptografie. Ze ontsproten aan het brein van Ron Rivest die samen met Adi Shamir en Leonard Adleman in 1978 menig hart in de cryptografiegemeenschap sneller deed kloppen.<br />
<br />
Als je de geschiedenis erop naslaat, figureren ze voor het eerst in een technisch memo van de hand van Rivest uit april 1977 getiteld &lsquo;A Method for Obtaining Digital Signatures en Public-Key Cryptosystems&rsquo;. In plaats van de onpersoonlijke A en B in frases als &lsquo;A stuurt een bericht aan B&rsquo; gebruikte hij Alice en Bob als de hoofdfiguren in zijn betoog. Een gewoonte die sinds de officiële publicatie van wat we nu wereldwijd kennen als het public-key RSA-algoritme in brede kring navolging heeft gekregen.<br />
<br />
Bob en Alice werden afgelopen maand, in de week die begon met Valentijnsdag, in het zonnetje gezet in San Francisco. En dat ondanks het slechte weer. Aan dat huldebetoon ligt weer een heel ander verhaal ten grondslag.<br />
<br />
Dat verhaal begint in 1982 toen R, S en A besloten hun vinding ook in toepassingen om te zetten en RSA Data Systems oprichtten. Dat bedrijf kende vele avonturen, mogelijk nog spannender dan die van Alice en Bob, maar het overleefde en RSA geniet ook in 2011 nog wereldwijd bekendheid als de securitydivisie van IT-opslagleverancier EMC.<br />
<br />
Half februari organiseerde RSA voor de twintigste keer zijn jaarlijks terugkerende RSA-conferentie. Plaats van handeling San Francisco, jubileumthema &lsquo;The Adventures of Alice &amp; Bob&rsquo;.<br />
<br />
Alice en Bob hebben er door toedoen van securityexpert Bruce Schneier, onder meer bekend als auteur van boeken als &lsquo;Beyond Fear&rsquo;, &lsquo;Secrets and Lies&rsquo; en &lsquo;Applied Cryptography&rsquo; en medeauteur van het recent verschenen &lsquo;Cryptography Engineering&rsquo;, nog veel nieuwe vrienden en vriendinnen bij gekregen. Voor een iets ingewikkelder communicatiescenario met vier partijen (A, B, C en D) introduceerde Schneier, naast Alice en Bob, bijvoorbeeld Carol en Dave. En zo ging het verder.<br />
<br />
In Applied Cryptography vindt u het hele alfabet aan figuren door Schneier opgevoerd. Daarbij gaat het overigens niet alleen om vrienden en vriendinnen. Zo wordt het avontuurlijke universum van Alice en Bob ook bevolkt door figuren als &lsquo;Eve the Eavesdropper&rsquo; en &lsquo;Mallory the Malicious Attacker. Hoedt u voor hen!</p>
<p>Dick Schievels<br />
&nbsp;</p>]]></description>
    <pubDate>Mon, 21 Mar 2011 15:09:27 GMT</pubDate>
    <link><![CDATA[http://www.infosecurity.net/Blogs/72315/Alice-en-Bob]]></link>     
</item>
<item>
    <guid isPermaLink="true"><![CDATA[http://www.infosecurity.net/Blogs/69317/Snel-bediend!"]]></guid>
    <title><![CDATA[Snel bediend!]]></title>
    <description><![CDATA[<p>In de vorige uitgave van Infosecurity (de Infosecurity.nl-beurscatalogus) eindigde ik mijn redactioneel met de stelling dat het hoog tijd wordt dat de overheid serieus gaat investeren in onderzoek en regelgeving ter bestrijding van de naar aanleiding van Stuxnet gesignaleerde opkomende vorm van elektronische oorlogsvoering. Het lijkt erop dat de overheid mijn schrijven heeft gelezen, want opeens word ik om de oren geslagen met presentaties waaruit blijkt dat de overheid zowel voor als achter de schermen het thema cybersecurity hoog op de agenda heeft geplaatst.<br />
<br />
Allereerst was er op Infosecurity.nl in de Jaarbeurs de keynote van generaal-majoor Koen Gijsbers over &lsquo;De rijksoverheid en cybersecurity&rsquo; (een uitgebreid verslag daarvan vindt u op pagina 12 tot en met 15). Gijsbers wees in de opening van zijn betoog direct op de eind vorig jaar aan de minister van Defensie gestelde kamervragen met de strekking: de digitale wereld begint steeds onveiliger te worden en we horen maar niets van de kant van de overheid. Dat initiatief mondde uiteindelijk uit in een motie waarin de regering werd opgeroepen om in interdepartementaal verband een cybersecuritystrategie te ontwikkelen. Generaal-majoor Gijsbers kwam ons op Infosecurity.nl vertellen dat daaraan op dit moment hard wordt gewerkt, dat het eerste concept daarvan nog voor het einde van dit jaar klaar is en dat het ergens in februari 2011 naar buiten wordt gebracht. En als iemand het kan weten is het Gijsbers wel, want hij maakt hoogstpersoonlijk deel uit van de stuurgroep die hiervoor door de ministeries van BZK (Binnenlandse Zaken en Koninkrijksrelaties), V en J (Veiligheid en Justitie) en ELI (Economische Zaken, Landbouw en Innovatie) in het leven is geroepen.<br />
<br />
En dan was er bovendien, vlak voordat dit nummer naar de drukker moest, op 15 november nog de lancering van het Nationaal Trendrapport Cybercrime en Digitale Veiligheid 2010, opgesteld door Govcert.nl, het Computer Emergency Response Team van de Nederlandse overheid (zie voor een beknopte samenvatting dáárvan pagina 16 tot en met 19). Het doet een poging de trends gedestilleerd uit de bijdragen van experts en de vele bestaande rapportages en publicaties op gebied van cybercrime en digitale veiligheid van organisaties als de KLPD, NCTb, AIVD, MIVD, OPTA en Govcert.nl in samenhang te presenteren.<br />
<br />
Ik kan uit deze voortvarendheid van de kant van de overheid concluderen dat ik de plank volledig heb geraakt met mijn vorige maand geponeerde stelling. Het is niet helemaal op mijn wenken maar we worden in ieder geval snel bediend!</p>
<p>Dick Schievels<br />
&nbsp;</p>]]></description>
    <pubDate>Thu, 25 Nov 2010 14:24:33 GMT</pubDate>
    <link><![CDATA[http://www.infosecurity.net/Blogs/69317/Snel-bediend!]]></link>     
</item>
<item>
    <guid isPermaLink="true"><![CDATA[http://www.infosecurity.net/Blogs/65232/Cloud---security-revisited"]]></guid>
    <title><![CDATA[Cloud & security revisited]]></title>
    <description><![CDATA[<p>Onder de titel &lsquo;De keerzijde van cloudcomputing&rsquo; publiceerde Infosecurity in december van afgelopen jaar een stuk van de hand van Sjon Post, productmanager en trainer bij Compu&rsquo;Train. Ik heb het nog eens opgeslagen. Post legt in zijn artikel haarfijn de achilleshiel bloot van wat door velen &ndash; ook door mij &ndash; wordt gezien als de volgende grote revolutie in de informatietechnologie: IT uit de muur.</p>
<p>Die achilleshiel is &lsquo;security&rsquo;. Post stelt twee cruciale securitygerelateerde vragen. Vraag één is: wat zijn de risico&rsquo;s voor organisaties. Hij signaleert er drie. Als eerste risico voert hij aan: het opslaan van informatie &lsquo;in de cloud&rsquo;. Hoe zit het met de veiligheid van de informatie die we in goed vertrouwen afgeven? We weten niet meer waar die informatie geografisch gezien belandt, terwijl de privacyregels en compliancy per land aanmerkelijk verschillen. Het tweede risico dat hij aanroert, geldt de rechtsposities en contractkwesties: met de huidige regelgeving is lang niet altijd duidelijk wat wel en niet mag worden opgeslagen in de cloud. En het derde risico dat hij signaleert, is hacking &ndash; in het licht van de centralisatie van dataopslag die inherent is aan cloudcomputing. Zijn tweede vraag luidt: zijn cloudleveranciers wel te vertrouwen? Als die vraag met &lsquo;nee&rsquo; zou moeten worden beantwoord, kan dit aspect natuurlijk aan de risico&rsquo;s van cloudcomputing worden toegevoegd. Post geeft hierop dan ook geen antwoord, maar hij suggereert aan de hand van een voorbeeld wel dat we op onze hoede moeten zijn.</p>
<p>We zijn nu een half jaar verder en het verhaal van Post heeft nog niets aan actualiteit ingeboet. Cloud &amp; security zijn nog steeds twee zijden van dezelfde veelbelovende medaille. De cloud kan niet zonder security en security kan niet zonder de cloud. Die laatste opmerking slaat natuurlijk op het feit dat steeds meer securityleveranciers hun diensten met behulp van cloudcomputing aanbieden. Security uit de muur dus. Grote vraag die opdoemt: is dat te vertrouwen? Verstandig antwoord: blijf ook wat dat betreft alert!</p>
<p>Dick Schievels<br />
&nbsp;</p>]]></description>
    <pubDate>Fri, 02 Jul 2010 13:31:52 GMT</pubDate>
    <link><![CDATA[http://www.infosecurity.net/Blogs/65232/Cloud---security-revisited]]></link>     
</item>
<item>
    <guid isPermaLink="true"><![CDATA[http://www.infosecurity.net/Blogs/64387/Hoofdpijndossier"]]></guid>
    <title><![CDATA[Hoofdpijndossier]]></title>
    <description><![CDATA[<p>Bij de invoering van het elektronisch patiëntendossier (EPD) hinkt de overheid op twee gedachten. Enerzijds streeft men veiligheid na, anderzijds wil men alles zo efficiënt en gebruiksvriendelijk mogelijk inrichten. Een leerzaam schouwspel. Guido van &rsquo;t Noordende van de Universiteit van Amsterdam deed onderzoek naar de beveiliging van het EPD. Hij signaleert een aantal ernstige technische en organisatorische tekortkomingen.</p>
<p>Op dit moment liggen de patiëntgegevens bij allerlei verschillende zorgverleners: de huisarts, het ziekenhuis, de specialist, de thuiszorg, noem maar op. Het zou de kwaliteit van de zorg ten goede komen als die zorgverleners toegang hebben tot elkaars gegevens. Tenminste, dat is de gedachte achter het EPD. Natuurlijk moeten die gegevens wel goed worden beschermd. Er zijn echter meer dan 400 duizend zorgverleners die in geval van nood onmiddellijk toegang moeten hebben tot onze dossiers.</p>
<p>Maar ook als er geen sprake is van een spoedgeval, wil de overheid de zorgverleners niet lastigvallen met administratieve rompslomp. Een van de argumenten vóór het EPD is namelijk dat het veel eenvoudiger moet zijn om gegevens uit het verleden te raadplegen en zodoende fouten en onnodig onderzoek te voorkomen. Als het te veel tijd en moeite kost om toestemming te krijgen, zal de zorgverlener de gegevens niet gebruiken. De ontwerpers van het EPD hebben daaruit de conclusie getrokken dat vooraf toestemming vragen onwenselijk is.</p>
<p>Vermoedelijk om de maatschappelijke weerstand te temperen, heeft men gekozen voor een verwijssysteem. Het EPD bestaat uit een landelijk schakelpunt (LSP), dat alleen verwijzingen bevat naar de medische informatie die bij de diverse zorgverleners is opgeslagen. Daarmee wordt de suggestie gewekt dat er geen sprake is van een centrale database met álle medische gegevens van álle Nederlanders. Het klopt inderdaad dat een inbreker er niet met een stelletje disks vandoor kan gaan met daarop de medische gegevens van het hele land, maar elektronische vormen van inbraak voorkom je er niet mee. Het LSP functioneert bovendien als poortwachter: zorgverleners moeten zich bij het LSP authenticeren om toegang te verkrijgen tot gegevens die bij andere aangesloten zorgverleners liggen. Maar omdat de toegangscontrole centraal geschiedt, biedt gespreide opslag geen extra veiligheid.</p>
<p>Een ander zwak punt is de mandatering: een arts kan een kersverse uitzendkracht machtigen het EPD te gebruiken. Sterker nog, de uitzendkracht kan zichzelf machtigen, eenvoudig door de naam of ID van de arts in te voeren. Actieve medewerking van de arts is niet nodig. De beveiliging berust helemaal op de afschrikwekkende werking van de controle achteraf.</p>
<p>Voor die controle houdt het LSP bij welke zorgverlener toegang heeft gekregen tot welke patiëntendossiers. Die verkeersgegevens zijn op zich al bijzonder privacygevoelig: dat je bekend bent bij een psychiatrische inrichting of afkickkliniek hoeft niemand te weten. Helemaal kwalijk is dat die controle achteraf nog geen vaste vorm heeft gekregen. Wie gaat de verkeersgegevens controleren? Aan de hand van welke criteria gebeurt dat? Hoeveel ambtenaren zijn daarvoor nodig?</p>
<p>De oplossing voor deze chaos? Toon de patiënt via het zogeheten virtuele klantenloket welke zorgverleners zijn gegevens hebben opgevraagd of gewijzigd. Daarmee sla je twee vliegen in één klap: de controle wordt uitgevoerd door gratis en gemotiveerde krachten én de zorgverlener die het EPD misbruikt weet van tevoren dat de patiënt daarvan als eerste op de hoogte zal zijn.</p>]]></description>
    <pubDate>Fri, 28 May 2010 15:12:37 GMT</pubDate>
    <link><![CDATA[http://www.infosecurity.net/Blogs/64387/Hoofdpijndossier]]></link>     
</item>
<item>
    <guid isPermaLink="true"><![CDATA[http://www.infosecurity.net/Blogs/64386/What-s-in-a-name-"]]></guid>
    <title><![CDATA[What's in a name?]]></title>
    <description><![CDATA[<p>Mijn vrouw houdt niet van varen, maar tot mijn geluk is zij toch ooit met mij in het huwelijksbootje gestapt. Indertijd kregen wij van de burgerlijke stand de vraag voorgelegd of een van ons eventueel de naam van de ander wilde gaan voeren. Nee, dat wilden wij niet. Mijn vrouw voorop! Toen zij enige tijd na ons trouwen een schrijven van de kant van de overheid kreeg met de aanhef &lsquo;Geachte mevrouw Schievels&rsquo;, was ze dan ook behoorlijk geïrriteerd. En ze werd helemaal ziedend toen ik als reactie op haar klagen een lichte glimlach niet kon onderdrukken. Ik begreep toen ook echt niet waarom ze zich daar zo kwaad over maakte.</p>
<p>Toen ik onlangs bezig was met het uitwerken van het thema-interview met Helmer Wieringa (zie Infosecurity 2/20210, pag. 14 e.v.) en enthousiast vertelde over de problematiek rond privacy en identiteit, werd ik door mijn vrouw nog eens herinnerd aan die aanvaring van ruim tien jaar geleden. &ldquo;Jíj hebt nu de mond vol van hoe belangrijk het is dat de privacy en identiteit van een persoon op een goede manier worden beschermd? Misschien dat je dan ook mijn woede van toen kunt plaatsen, want het verdonkeremanen van iemands naam is natuurlijk een schoolvoorbeeld van identiteitsverminking.&rdquo; De spijker op zijn kop natuurlijk en stom dat ik dat destijds niet tot me liet doordringen.</p>
<p>Ik voer dit voorbeeld aan omdat ik tegenwoordig steeds vaker mensen tegenkom die &ndash; een beetje als ik tóén &ndash; nogal nonchalant reageren als het om allerlei overheidsmaatregelen gaat die, onder het mom van zaken als terreurbestrijding, de privacy en identiteit van de burger aantasten. Zolang je niets te verbergen hebt, hoef je je over je privacy geen zorgen te maken, is daarbij de veelgehoorde argumentatie. Uit mijn interview met Helmer Wieringa, expert op gebied van privacy en identiteit, komt naar voren dat wij burgers daar toch een stuk zorgvuldiger over zouden moeten denken.</p>
<p>Naar aanleiding van die opmerking van mijn vrouw schoot me overigens nog een voorval te binnen waaruit ik ook zelf had kunnen concluderen hoe belangrijk iemands naam soms is voor zijn identiteit &ndash; de mijne in dit geval. Nog voordat ik trouwde, kreeg ik een keer een mailtje van een andere Dick Schievels, die mijn (zijn?) naam was tegengekomen op het internet. Ik vond het toen zó raar om te ontdekken dat er iemand met exact dezelfde naam rondliep in Nederland dat het me enige dagen kostte voor ik het kon bevatten. Kijk, als je Jan Jansen heet, dan groei je op in de wetenschap dat er nog vele anderen opereren onder hetzelfde label als dat van jou. Maar Schievels is een vrij zeldzame naam hier te lande. Vandaar dus dat rare gevoel, waarvan ik nu óók plotseling besef dat ik dat als een aanslag op mijn identiteit ervoer.</p>
<p>&ldquo;Identity, silly!&rdquo;, zou ik tegen Juliet willen zeggen.</p>]]></description>
    <pubDate>Fri, 28 May 2010 15:03:02 GMT</pubDate>
    <link><![CDATA[http://www.infosecurity.net/Blogs/64386/What-s-in-a-name-]]></link>     
</item>   
 </channel>
</rss>

