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:
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
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.
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
No comments:
Post a Comment