Monday, October 24, 2016

Security-Standaarden



Toen ik voor mezelf de taak bedacht om als vakantieproject een overzicht te maken van security-standaarden had ik niet gedacht dat dit een zwaar onderwerp zou zijn. Ik heb de interactie opgezocht met collega’s. En het blijkt dat we het over veel zaken eens zijn. Maar één ding kan altijd breder: de scope. Ik roep wel eens gekscherend dat een architect van alles een beetje moet weten en een expert van een beetje alles moet weten. Maar een security-professional moet kennelijk van alles op het gebied van security veel weten. Ik kreeg veel verwijzingen naar standaarden die voor mij nieuw waren. Het gaf me ook te denken wat ik als security-standaard wilde accepteren. Ik wilde daar toch een aantal kenmerken bij toetsen: brede gedragenheid, uitstraling als standaard en een duidelijk beheer van het document. Dat had wel tot gevolg dat ik vele bronnen die mij aangedragen werden niet opgenomen heb in dit artikel. En ik ben blij toe, want met deze beperkte scope is het toch een lijvig artikel geworden.
Tijdens mijn onderzoek kwam ik ook nog een interessante kritiek tegen op een detail van wachtwoordbeheer dat in verschillende standaarden: de specificatie van een minimum wachtwoord-leeftijd, zijnde de tijd waarbinnen een wachtwoord niet veranderd mag worden. Vele experts vinden dit geen security-aspect. Toch zit dit attribuut ingebakken in het wachtwoordbeheer van bijvoorbeeld Microsoft Windows. Dit is er ingekomen toen Windows NT 4.0 eind 90-er jaren een C2 security certificatiestempel kreeg [1]. En waarom? Omdat er een boek was in de zogenaamde ‘Rainbow Series’ die dit als aanbeveling gaf. Het was een best practice die de certificerende consultants bij een eerdere certificatie in 1986 opgehaald hadden. Dit was de certificatie van een lijn van mainframes, Unisys A Series MCP versie 3.7. En hoe weet ik dit? Een software-engineer had dit als oplossing bedacht om wachtwoord recycling tegen te gaan op een systeem dat weinig capaciteit had om een reeks oude wachtwoorden op te slaan. Vandaag de dag is het moeilijk voor te stellen dat dit soort zaken zulke beperkingen hadden, maar de definitie van een gebruiker werd in 300 byte chunks ingelezen. Ik wilde zorgen dat alle informatie van een gebruiker meestal in die buffer paste, zodat het ophalen slecht één leesactie vergde. En dat moest dus inclusief de historie aan wachtwoordhashes zijn die we aan het toevoegen waren. Een logische ontwerpbeslissing in die tijd…
Dit was een belangrijke realisatie voor mij: standaarden moeten vooral op het goede abstractieniveau zitten. In dit geval was een specifieke maatregel van meer dan tien jaar oud in de standaarden blijven hangen. Volgens de wet van Moore waren computers 32 keer zo snel geworden. De snelheid van lezen en schrijven naar de harde schijf zeker een factor 100 en de capaciteit van harde schijven zo’n 1000 keer. De wereld was dus danig veranderd.
Met deze wetenschap ben ik ook vooral op zoek gegaan naar praktisch toepasbare standaarden. Ik heb ze naar thema gerangschikt en ook weggestreept. Tot de laatste avond van het uitwerken toe. En hierdoor zijn raamwerken als COBIT en standaarden als PCI-DSS op de vloer van knipselafval beland. Dat wil niet zeggen dat ze niet relevant zijn, maar het laat meer zien hoe rijk de informatie was, dat de lat zo hoog gelegd moest worden om dit behapbaar te houden. Nog een speciale vermelding wil ik doen van Bob Hulsebosch, die mij attendeerde op een studie van hem, gepubliceerd door het WODC met de titel ‘Inventarisatie en classificatie van standaarden voor cybersecurity’ [2]. Het is een onderzoek dat een hele andere dimensie van de wereld van standaarden belicht. Voor wie meer wil lezen, kan ik het aanbevelen.
Security-strategie
Ik begin met dit onderwerp omdat hier de wortels van een goede beveiliging liggen. Security moet uiteindelijk de bedrijfsdoelen ondersteunen en niet tegenwerken. Goede beveiliging moet het voor het bedrijf mogelijk maken kansen te benutten onder acceptabele restrisico’s. Zonder die beveiliging zouden die kansen niet benut zouden kunnen worden. Dus moet ik ook beginnen met het noemen van twee standaarden die niet door iedereen gezien zullen worden als security-standaarden, maar wel een cruciale rol hebben hierin: TOGAF [SS.1] en Archimate [SS.2]. Archimate noem ik vooral met een beetje Nederlandse trots, hier zijn ook andere kandidaten te noemen, zoals UML. Het belangrijkste is dat er een enterprise-architectuurmethode moet zijn die aandacht heeft voor beveiliging en een standaard representatie die daarmee gepaard gaat. Ik besef me dat ik strategie belicht vanuit het oogpunt van een architect, maar dat is dan ook het oogpunt dat ik gewend ben.
Om die enterprise-strategie door te kunnen vertalen naar de hele inrichting en uitvoering van security in de organisatie heb je een allesomvattend raamwerk nodig. In dit verband weet ik eigenlijk alleen maar SABSA [SS.3] te noemen. SABSA is een raamwerk dat ontstaan is parallel aan COBIT. Het mooie van SABSA is dat het, anders dan COBIT, niet bedrijfsbreed geadopteerd hoeft te worden om effectief gebruikt te worden door architecten. Maar eigenlijk is dat ook tegelijk het nadeel. Doordat deze adoptie niet noodzakelijk is, is het gebruik van SABSA vaak maar beperkt tot een aantal enthousiastelingen binnen een bedrijf.
Risk Management
Voor veel informatiebeveiligers is risicoanalyse het belangrijkste aandachtsgebied. Alle informatiebeveiligers dienen dit domein te kennen. Er zijn veel bronnen voor allerlei aspecten van risico, maar ik wil me in het kader van dit artikel beperken tot standaarden die het risicomanagement proces zelf beschrijven. Ik begin met het ISF. Toen ze nog ESF heetten kwamen ze met de Sprint standaard, dit is uitgegroeid tot IRAM2 [RM.1]. Helaas alleen beschikbaar voor leden, maar dan heb je ook een standaard ondersteund met vele instrumenten en beschrijvingen van best practices.
Hiernaast is er ook de ISO-standaard ISO/IEC 31000 [RM.2], die ik in de beveiligingspraktijk steeds vaker tegenkom. Het is een gebied dat ik zelf ook nog graag verder zou willen uitdiepen, want ik zie nog te vaak dat er risico’s worden geaccepteerd die niet op een structurele wijze bepaald zijn.
Security Management
In mijn vooronderzoek was er al snel een ding duidelijk: de ‘Code voor Informatiebeveiliging’ is onbetwist security-standaard nummer één! Iedereen kent deze standaard wel in een van zijn verschijningsvormen, maar dat zijn er helaas wel heel erg veel: De officiële internationale versie zijn de IEC/ISO 27001 en 27002 standaarden, ondersteund door de andere standaarden in de IEC/ISO 27000 Series [SM.1]. De historie van deze documenten is vrij direct terug te traceren naar voorgangers: de IEC/ISO 17799 en het tandem de BS 7799 / NEN Code voor Informatiebeveiliging, opgezet onder leiding van David Lacey en Pieter van Dijken. Maar daar stopt het niet. Er zijn verschillende afgeleiden gemaakt van ‘de Code’. De NEN 7510 [SM.2] voor de sector gezondheidszorg, en een serie baselines voor verschillende overheidstakken, waarvan de BIR [SM.3] voor rijksdiensten en de BIG [SM.4] voor gemeenten. Al deze standaarden hebben een eigen progressie, een gezamenlijk verleden en persoonlijk vind ik het jammer dat er de laatste jaren zoveel aftakkingen zijn.
Er zijn naast de 27000 Series toch ook wat andere standaarden op het gebied van security-management die het noemen waard zijn:
  • ISF publiceert de ‘Standard of Good Practice in Information Security’ [SM.5];
  • NIST publiceert het Cybersecurity Framework [SM.6];
  • IETF publiceert RFC 2196 Site Security Handbook;
  • AICPA publiceert de SSAE 16 - gericht op outsourcing;
  • CSA publiceert de Cloud Controls Matrix - gericht op clouddiensten.
Al deze standaarden hebben weer hun eigen inzichten en accenten, wat ze bruikbaarder maakt voor bepaalde organisaties of op bepaalde vlakken. Om dat goed te beschrijven kan er een heel apart artikel geschreven worden. Ik volsta hier met het opnoemen van de standaarden.
Security-technologie
Dit is misschien wel het makkelijkste thema om standaarden bij te noemen, maar tegelijk het moeilijkste thema om dan ook een gevoel erbij te geven dat je structureel de belangrijkste standaarden benoemd hebt. Dus laten we dicht bij huis beginnen: het NCSC publiceert een hele serie whitepapers [ST.1] die grotendeels over technologie-onderwerpen gaan. Als ik even kijk naar de meest recent gepubliceerde whitepapers: legacysystemen, detectie-oplossingen, webapplicaties, TLS, IPv6… Hiermee worden toch al meer dan de helft van de security-problemen van de hedendaagse projecten geraakt. Mocht je verder willen kijken, dan zijn de ‘Special Publications 800’ van het NIST [ST.2] een goede plaats om te kijken. Ook hier kun je richtlijnen vinden voor de toepassing van vele verschillende technologieën. Het is wat meer zoeken, dat komt omdat het NIST de publicaties op nummer zet, maar de nummers wel gelijk houdt bij updates. Hierdoor is er geen historische structuur, noch een inhoudelijke. Ze zijn bij NIST ook begonnen aan een SP 1800 Series, over cybersecurity. Het NIST kan soms vooruitstrevend zijn. NIST’s conceptversie voor SP 800–63–3 ‘Digital Authentication Guideline’ was afgelopen mei nog in het nieuws omdat hier afgerekend wordt met een aantal diepgewortelde overtuigingen over de kwaliteit van wachtwoorden. Dit concept beveelt aan wachtwoorden niet langer periodiek te laten verlopen en rekent af met SMS als een tweede factor.
En dan komen we bij een andere grossier in internet- standaarden, waarvan vele een security-tintje hebben: het IETF (Internet Engineering Taskforce). Het IETF heeft maar een handjevol echte standaarden, zoals HTTP en HTML. Maar onder de standaarden zit een hele laag aan RFC (Request for Comments)-documenten. Dit zijn feitelijk standaarden. Het zoeken naar specifieke onderwerpen is moeilijker dan bij de NIST SP 800 Series, en hierbij komt het dat het niet alleen om security- standaarden gaat, alle onderwerpen staan bij elkaar. Nieuwe versies krijgen een nieuw nummer, dus je moet oppassen als je op nummer een document ophaalt. Gelukkig is de IETF er goed in om aan te geven als je een verlopen versie opvraagt.
Eén RFC-document licht ik er uit, omdat het security-technieken op een meta-niveau beschrijft: RFC 3631 ‘Security Mechanisms for the Internet’ [ST.4]. Verder kun je geen internettechnologie noemen waarvoor geen RFC bestaat. Voor het onderwerp email-security heb je bijvoorbeeld SPF (RFC 4408), DKIM (RFC 6376) & DMARC (R7489) en voor connection-security bijvoorbeeld TLS (RFC 5246), Public key pinning (RFC 7469) & HSTS (6797).
Nog een uitsmijter: de standaarden voor digitale handtekeningen van het ETSI [ST.5]. Met de aandacht voor standaardafhandeling van digitaal tekenen staan deze standaarden voorlopig even in het spotlicht, zeker totdat dit soort activiteiten gewoon gemeengoed geworden zijn.
Veilige Software
Bij het thema ‘veilige software’ denk ik gelijk aan OWASP. Niet echt een standaard, maar wel een organisatie met een hele verzameling praktische richtlijnen, en toch ook een standaard in haar portfolio: de OWASP Application Security Verification Standard [SW.1]. Versie 3 is net uitgekomen. En daarnaast is OWASP heel bekend door de OWASP top 10 [SW.2], een lijst van de tien meest voorkomende web- applicatie-problemen. Deze lijst wordt elke drie jaar vernieuwd, en deze vernieuwing staat er ook weer aan te komen! Sinds 2010 is de top drie injection, broken authentication & session management en cross-site scripting (XSS). Vergelijkbaar met de OWASP top 10 is de ‘SANS top 25 Most dangerous software errors’ [SW.3]. De huidige lijst is uit 2011 en is wat meer op het voortbrengingsproces gericht dan op de programmeertechniek.
Dat brengt ons ook bij de laatste standaard die ik noem op dit vlak, een Nederlandse standaard: Grip op SSD [SW.4] van het CIP. SSD staat voor ‘secure software development’. Grip op SSD is een collectie van standaardeisen en normen voor het ontwikkelingsproces. Het wordt vooral bij de overheid gebruikt en de leveranciers in deze sector hebben het werken op deze manier omarmt.
Cloud Security
Op het gebied van Cloud Security zijn er verschillende standaarden. De eersten die ik noem komen van de Computer Security Alliance (CSA). De CSA is toch wel de meest bekende organisatie op dit gebied die standaarden uitgeeft. Daar waar anderen steevast refereren naar bestaande standaarden en volharden in het standpunt dat cloud niets anders is dan oude wijn in nieuwe zakken, weet het CSA exact de vinger te leggen op wát er dan wél anders is en dát juist te beschrijven. Als eerste noem ik de CSA Security Guidance [CS.1]. Deze richtlijn bevat richtlijnen in 14 domeinen, verdeeld over de thema’s architectuur, bestuur (governance) en operationeel. Het bevat een schat aan definities, normen en best practices en is van harte aan te bevelen aan eenieder die professioneel met cloud en security te maken heeft.
Iets minder bekend, wat meer gespecialiseerd, maar daardoor niet minder waardevol zijn de tien (!) CSA SecaaS Implementation Guidance documenten [CS.2]. Omdat de CSA zelf geen verzamelpagina heeft om deze documenten bij elkaar te presenteren, verwijs ik hierbij naar een blog van Kevin Fielder, die ze bespreekt en doorlinkt.
Privacy
Op het gebied van privacy is er één autoriteit in Nederland: de Autoriteit Persoonsgegevens (AP) De AP publiceert veel documenten op haar website, velen daarvan zijn onderzoeken en adviezen, geen standaarden of richtlijnen. Wel zou je de ‘richtsnoeren’ als zodanig kunnen beschouwen. Het belangrijkste richtsnoeren-document is “Richtsnoeren beveiliging persoonsgegevens” [P.1].
In de Richtsnoeren zelf wordt dan wel weer nadrukkelijk benoemd dat de erkende informatiebeveiligingsnormen een afdoende basis vormen om te voldoen aan de eisen uit de Wbp met betrekking tot beveiliging, maar dat het tevens slechts een onderdeel ervan is.
Daarnaast zijn er ook de “Beleidsregels meldplicht datalekken” [P.2], die in conceptvorm nog ‘richtsnoeren’ genoemd werden. Deze beleidsregels zijn eerder te kwalificeren als een soort van memorie van toelichting bij de wet dan als een standaard of richtlijn, maar dat is het niet. Het AP heeft in dit document beleid opgeschreven wat veel verder gaat dan de wetstekst en aangegeven dat er gehandhaafd wordt aan de hand van wat in het document staat. In die zin legt het dus wel normen neer in de vorm van regels.
Security Documentatie & Audit
Op het oog lijkt het vreemd deze twee onderwerpen met elkaar te combineren. Toch kwam ik er instinctief iedere keer op uit. De connectie is dat vanuit het perspectief van een beveiliger niet alleen maatregelen genomen moeten worden, maar ook aangetoond moet kunnen worden dat deze maatregelen genomen zijn en goed werken. Een groot onderdeel daarvan is de security-documentatie. De een doe je voor het ander, vandaar dat ik deze onderwerpen combineer. Recentelijk heb ik nog in dit blad het boek SIVA [DA.1] van Wiekram Tewarie besproken. Het wordt onder andere gebruikt om NCSC-normen te beschrijven. Ik volsta in dit artikel om te verwijzen naar twee artikelen [DA.2] van auditors over dit gedachtegoed.
Er is op dit vlak voor mijn gevoel nog meer te halen dan nu beschikbaar is. Wat ik zie in de markt is dat elke partij die een brede portfolio voor securitydocumentatie nodig heeft dit wiel zelf moet uitvinden. Dit is natuurlijk goed nieuws voor de security-consultants die zich specialiseren op dit vlak, maar het is niet effectief. Als er eerst bepaald moet worden wat een norm, standaard, richtlijn en handreiking is, welke er intern gemaakt kunnen worden, welke er extern geadopteerd kunnen worden en dan vervolgens de opzet van deze documenten weer vastgesteld moet worden, dan weet je dat het lang gaat duren en er waarschijnlijk niet een praktisch document uitkomt. Het wordt tijd om hier een standaard voor te hebben.
Security Certificaties
De beveiligers zelf moeten ook aan standaarden voldoen om hun capaciteiten op een gestandaardiseerde wijze aan te kunnen tonen. Ik begin met een ontwikkeling waar het PvIB nauw bij betrokken is: de Beroepsprofielen Informatiebeveiliging [SC.1]. Deze vier profielen geven een duidelijke visie hoe de markt van security professionals ingedeeld kan worden. Het geeft voldoende differentiatie dat een richting gekozen kan worden, zonder te verdwalen in een woud van mogelijkheden. De beroepsprofielen zijn in 2014 voor het eerst gepubliceerd, dus eigenlijk staan we nog aan de bakermat van deze ontwikkeling.
Naast deze profielen zijn er ook nog certificaten te behalen. De wereld van certificeren is internationaal, de meeste certificeringen zijn Amerikaans van oorsprong. Nu zijn er veel certificeringstrajecten. Ik ga ze niet allemaal noemen, want vele certificeringen zijn zo zeldzaam in de markt dat het onduidelijk is wat de exacte meerwaarde is. Ik beperk me tot de bekende certificeringen die een overwicht in de markt hebben. De meeste certificaten eisen dat je een examen haalt, een initieel niveau van ervaring aantoont en je kennis bijhoudt met doorlopend kennis vergaren. Kennis vergaren wordt opgedaan door CPE-punten te verdienen, bijvoorbeeld een cursus te doen, een conferentie te bezoeken, een boek te lezen of een artikel te schrijven.
Als eerste noem ik de CISSP-certificering [SC.2] van ISC2. Wat begon als een vrij technisch certificaat is nu meer richting de proceskant getrokken, waarbij minder relevante technische kennis (in het fysieke domein) minder belangrijk geworden is. Het omgekeerde is aan de gang bij de tegenhanger hiervan is de CISM-certificering [SC.3] van ISACA. Dit had een vrij procesgericht zwaartepunt, maar meer en meer komen ook hier technische details aan bod.
En dan is er de Britse SABSA-certificering [SC.4] voor enterprise- security-architecten. Het belang van SABSA komt vooral voort uit de integratie in TOGAF (zie ook Security Strategie, eerder in dit artikel) en de enthousiaste kern van beoefenaren. Cloud-security is de opkomende ster, dus ik wil het rijtje afsluiten met twee certificaties op dit vlak, die vergelijkbaar zijn, aangeboden door verschillende instituten: CCSK-certificaat van de CSA en het CCSP certificaat van ISC2. Het is nog te vroeg om te zeggen of een van deze twee de overhand krijgt, dus een gok is het wel.
Conclusie
Veel security-experts zullen 80% van de hiervoor genoemde standaarden goed kennen. Voor hen hoop ik dat er wat pareltjes tussen zitten die het toch het lezen waard maken. Voor de minder ervaren security-professionals hoop ik dat dit bijdraagt aan hun kennis van security-standaarden. Voor iedereen kan het fungeren als een referentielijst naar standaarden. Verder is het wat mij betreft een levend document. Ik zal vast wel een favoriete standaard gemist hebben of een detail verkeerd hebben uitgespeld. Graag hoor ik op- en aanmerkingen, dan zorg ik dat de levende versie ergens een goed thuis krijgt.
Links 
[1] Microsoft Windows NT 4.0 C2 Certificatie: https://msdn.microsoft.com/en-us/library/cc767092.aspx
[2] WODC Inventarisatie en classificatie van standaarden van cybersecurity: https://www.wodc.nl/onderzoeksdatabase/2552-inventarisatie-van-standaarden-en-normen-voor-cyber-security.aspx?cp=44&cs=6837
Referenties
Security Strategie
[SS.1] TOGAF: http://w1.opengroup.org/subjectareas/enterprise/togaf
[SS.2] Archimate: https://www2.opengroup.org/ogsys/catalog/W150
[SS.3] SABSA: http://www.sabsa.org/node/5
Risk Management
[RM.1] ISF IRAM2 :https://www.securityforum.org/uploads/2015/03/ISF-IRAM2-ES.pdf & http://www.infosecurity-magazine.com/news/isf-launches-inforisk-assessment/
[RM.2] ISO/IEC 31000 Series:http://www.iso.org/iso/home/standards/iso31000.htm
Security Management
[SM.1] IEC/ISO 27000 Series: http://www.iso.org/iso/iso27001
[SM.2] NEN 7510: https://www.nen.nl/NEN-Shop-2/Standard/NEN-75102011-nl.htm
[SM.3] BIR: https://www.communicatierijk.nl/vakkennis/r/rijkswebsites-verplichte-richtlijnen/inhoud/baseline-informatiebeveiliging-rijksdienst-bir--nen-iso-iec-27001-en-27002
[SM.4] BIG: https://www.ibdgemeenten.nl/producten/strategische-en-tactische-big/
[SM.5] ISF Standard of Good Practice: https://www.securityforum.org/tool/the-isf-standardrmation-security/
[SM.6] NIST Cybersecurity Framework: http://www.nist.gov/cyberframework/
[SM.7] IETF RFC 2196 Site Security Handbook: https://www.ietf.org/rfc/rfc2196.txt
[SM.8] AICPA SSAE 16: http://ssae16.com/SSAE16_overview.html
[SM.9] CSA Cloud Controls Matrix: https://cloudsecurityalliance.org/group/cloud-controls-matrix/
Security Technologie
[ST.1] NCSC Whitepapers: https://www.ncsc.nl/actueel/whitepapers
[ST.2] NIST SP-800 Series: http://csrc.nist.gov/publications/PubsSPs.html
[ST.3] IETF RFCs: https://www.ietf.org/rfc.html
[ST.4] IETF RFC 3631 Security Mechanisms for the Internet: https://tools.ietf.org/html/rfc3631
[ST.5] ETSI Digital Signature: http://www.etsi.org/technologies-clusters/technologies/security/digital-signature
Veilige Software
[SW.1] OWASP Application Security Verification Standard: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project
[SW.2] OWASP Top Ten: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
[SW.3] SANS top 25 Most dangerous software errors: https://www.sans.org/top25-software-errors/
[SW.4] CIP Grip op SSD: https://www.cip-overheid.nl/downloads/grip-op-ssd/
Cloud Security
[CS.1] CSA Security Guidance: https://cloudsecurityalliance.org/group/security-guidance/
[CS.2] CSA SecaaS Implementation Guidances (10!): https://kevinfielder.wordpress.com/2012/11/01/security-as-a-service-implementation-guidance-documents-published/
[CS.3] CSCC Cloud Security Standards: http://www.cloud-council.org/deliverables/CSCC-Cloud-Security-Standards-What-to-Expect-and-What-to-Negotiate.pdf
Privacy
[P.1] AP Richtsnoeren beveiliging persoonsgegevens: https://autoriteitpersoonsgegevens.nl/sites/default/files/downloads/rs/rs_2013_richtsnoeren-beveiliging-persoonsgegevens.pdf
[P.2] AP Beleidsregels melkplicht datalekken: https://autoriteitpersoonsgegevens.nl/sites/default/files/atoms/files/richtsnoeren_meldplicht_datalekken.pdf
Security Documentatie en Audit
[DA.1] Boek SIVA: http://vuuniversitypress.com/15-nederlands/overige-content/99-siva
[DA.2] Twee bronnen over SIVA: https://www.deitauditor.nl/beroepsontwikkeling-reglementering/siva-methodiek-voor-de-ontwikkeling-van-auditreferentiekaders/ & http://www.norea.nl/readfile.aspx?ContentID=68278&ObjectID=940136&Type=1&File=0000036004_Referentiekaders.pdf
Security Certificaties
[SC.1] Beroepsprofielen Informatiebeveiliging: https://www.pvib.nl/download/?id=17696376
[SC.2] ISC2 CISSP: https://www.isc2.org/cissp/
[SC.3] ISACA CISM: http://www.isaca.org/certification/cism-certified-information-security-manager/pages/default.aspx
[SC.4] SABSA Chartered Security Architect: http://www.sabsa.org/certification
[SC.5] Cloud Security - CSA CCSK & ISC2 CCSP: https://cloudsecurityalliance.org/education/ccsk/ en https://isc2.org/ccsp-how-to-certify/default.aspx

Friday, October 7, 2016

Meldplicht datalekken: de stand van zaken per 7 oktober 2016

Meldplicht datalekken: de stand van zaken

De Meldplicht datalekken, onderdeel van de Wet bescherming persoonsgegevens die sinds januari 2016 van kracht is, moet ervoor zorgen dat u bewuster omgaat met de opslag van persoonsgegevens en de beveiliging ervan. Sterker nog, indien u persoonsgegevens bewaart binnen uw hostingomgeving bent u sinds dit jaar verplicht om een bewerkersovereenkomst af te sluiten met uw hostingprovider waarin afspraken worden gemaakt over aanvullende beschermingsmaatregelen voor uw omgeving.

Deze overeenkomst zorgt ervoor dat uw hostingprovider beter op de hoogte is van de data die u verzamelt in uw hostingomgeving waardoor zij u eenvoudiger en sneller van dienst kan zijn in het geval er passende extra maatregelen omtrent beveiliging moeten worden genomen.
Naast het afsluiten van een bewerkersovereenkomst is men verplicht om datalekken te melden bij de Autoriteit Persoonsgegevens (voorheen College Bescherming Persoonsgegevens, CBP) zodra er een ernstig datalek wordt waargenomen. Ook moeten betrokkenen worden ingelicht zodat zij passende maatregelen kunnen nemen (denk aan het wijzigen van een wachtwoord). Bij overtreding van de meldplicht datalekken uit de Wet bescherming persoonsgegevens (Wbp) kan een boete worden opgelegd van maximaal 820.000 euro is te lezen op de website van de Autoriteit Persoonsgegevens.

3400 meldingen

We zijn inmiddels negen maanden verder sinds de invoering van de meldplicht datalekken, hoog tijd om een tussentijdse balans op te maken. Houden organisaties zich aan de vernieuwde meldplicht en sluiten zij ook daadwerkelijk een bewerkersovereenkomst af?
Sinds de inwerkingtreding van de meldplicht datalekken, op 1 januari 2016, blijkt de Autoriteit Persoonsgegevens al 3400 meldingen van organisaties te hebben ontvangen. Wilbert Tomesen, vicevoorzitter van de Autoriteit Persoonsgegevens, bij BNR Nieuwsradio: ‘Wij gaan ervan uit dat er in Nederland 135.000 bedrijven, instanties, overheden en ziekenhuizen omgaan met persoonsgegevens en dus potentieel door een lek kunnen worden getroffen. Als wij het aantal meldingen van 3400 afzetten tegen dat aantal vinden wij het aantal meldingen nog niet overdonderend veel.’
Daarnaast geeft Tomesen aan dat er sinds de invoering van de meldplicht nog geen boetes zijn uitgedeeld. Een boete wordt enkel opgelegd indien een datalek niet (tijdig) wordt gecommuniceerd naar betrokkenen terwijl dat wel zou moeten in verband met de gevoeligheid van het datalek.

Gegevens op straat

Meldingen die worden gedaan bij de Autoriteit Persoonsgegevens worden in eerste instantie niet openbaar gemaakt. Betrokkenen worden alleen ingelicht indien een datalek ernstige gevolgen voor hen zou hebben. Toch zijn er de afgelopen maanden zaken in de openbaarheid gekomen doordat betrokkenen ontevreden waren over het tijdsbestek voordat zij werden ingelicht of door media die zich beroepen op de Wet openbaarheid van bestuur (Wob).
Zo blijkt de gemeentelijke database met persoonsgegevens van de gemeente Ede gehacked te zijn tussen januari 2015 en juli 2016. De bron van de hack is afkomstig uit Oost-Europa. Een persoon of organisatie heeft gedurende anderhalf jaar toegang gehad tot de opgeslagen persoonsgegevens van de gemeente Ede. Binnen de gemeente is er momenteel een discussie gaande of inwoners niet te laat zijn geïnformeerd over het datalek, ook wordt in twijfel getrokken of de gemeente Ede een instantie is waar burgers met vertrouwen gegevens aan kunnen toevertrouwen.

Gemeente Utrecht

Een andere gemeente waar zich een incident heeft voorgedaan in 2016 is de gemeente Utrecht. In totaal stonden 316 pagina’s met namen en bijbehorende burgerservicenummers op intranet. Het gaat om minimaal vijfduizend en maximaal 140.000 persoonsgegevens. De betrokkenen zijn in dit geval niet op de hoogte gesteld door de gemeente Utrecht, omdat zij van mening is dat misbruik van de gegevens onwaarschijnlijk lijkt te zijn. De gegevens waren namelijk alleen toegankelijk voor medewerkers van de gemeente Utrecht die toegang hadden tot het intranet. Bij de gemeente werken een kleine vierduizend personen.
Dit laatste incident is aan het licht gekomen doordat De Telegraaf een beroep heeft gedaan op de Wet openbaarheid van bestuur. Het datalek blijkt op 3 maart te zijn opgemerkt door een ambtenaar. Vervolgens is er melding van gemaakt bij de Autoriteit Persoonsgegevens. Vooralsnog hebben zij geen boete gekregen voor het niet inlichten van betrokkenen over dit incident.

Datalek in energiesector

Dat de beveiliging niet alleen bij gemeenten voor verbetering vatbaar is blijkt uit het datalek wat onlangs in de openbaarheid is gekomen uit de energiesector. Het gaat om de naw-gegevens van twee miljoen huishoudens met daarnaast informatie over het energieverbruik per jaar, het type aansluiting en de einddatum van het contract. De gegevens zouden door een oud-medewerker van een energieleverancier zijn gestolen uit een centraal register. Dit register is toegankelijk voor alle energieleveranciers in Nederland. Tot op heden is niet bekendgemaakt om welke energieleverancier het gaat. De energieleverancier zelf heeft op dit moment geen toegang meer tot het register. De Autoriteit Persoonsgegevens is momenteel nog bezig met het onderzoek naar dit datalek.

Europese wetgeving

Nederland is het eerste Europese land met wetgeving omtrent datalekken. Steeds meer Europese bedrijven worden echter geconfronteerd met cybercrime, waardoor de noodzaak voor een degelijk beleid ook meer en meer duidelijk wordt. De bewustwording omtrent security bij organisaties wordt vergroot door de invoering van de meldplicht. Naast dat betrokkenen sneller ingelicht moeten worden bij datalekken wordt de vrees voor reputatieschade ook steeds groter. Hierdoor investeren organisaties meer in de veiligheid van hun omgevingen en gaan zij bewuster om met persoonsgegevens.
Deze aanpak wordt vanuit Europa, maar specifiek vanuit België geprezen. De roep voor invoering van een soortgelijk meldplicht wordt steeds groter, blijkt uit diverse artikelen in de Belgische media. Nemen België, en mogelijk andere Europese landen, een voorbeeld aan Nederland en zien we binnen afzienbare tijd invoering van een dergelijke meldplicht ook in andere landen gebeuren? De toekomst zal het uitwijzen.

Bewerkersovereenkomst

Sven Visser, commercieel directeur van Cyso en voorzitter van de DHPA, is blij met de toenemende aandacht voor de problematiek rondom security door de komst van de meldplicht datalekken. Visser heeft zich vanuit de DHPA, als leider van de werkgroep, in 2015 beziggehouden met de ontwikkeling van de gestandaardiseerde bewerkersovereenkomst in samenwerking met ICTRecht. Visser: ‘Zowel vanuit Cyso als de DHPA merk ik dat het vraagstuk, rondom security en de meldplicht datalekken, bij bedrijven erg leeft. Wat ik echter ook merk, is dat organisaties de perceptie hebben dat een bewerkersovereenkomst alle risico’s afdekt, maar dit is slechts het begin. De overeenkomst bevordert de samenwerking omtrent veiligheid tussen de provider en de klant, maar dit is zeker niet het eindpunt.’

https://www.computable.nl/artikel/achtergrond/management/5848798/1444691/meldplicht-datalekken-de-stand-van-zaken.html?utm_source=nieuwsbrief&utm_medium=email&utm_campaign=dagelijks_07_10_2016&utm_content=topblok