Door Anoniem: Nu ik deze topic lees, hierbij een vraag die te maken heeft met de IS)27001/2.
Wat zijn de stappen die genomen moeten worden tot de certificering, en welke stappen na de certificering tot aan de hercertificering?
Dat heeft niks te maken met de certificering. Overigens ISO 27002 kun je niet certificeren. ISO27001 de norm van een management systeem en ISO27002 zijn die je zou kunnen gebruiken om de beheersmaatregelen van ISO27001 in te vullen...
Overigens kom je in de praktijk veel organisaties tegen die het over ISO 27002 certificering hebben of werken conform ISO27002 maar die weten feitelijk niet zo goed waar ze het over hebben.
De stappen die genomen dienen te worden om een tot een certificering te komen, hangen helemaal af van de organisatie. De eerste stap is het aanschaffen van de norm bij de NEN en als u geen ervaring heeft met de implementatie van de norm adviseer ik u een consultant in te huren die uw organisatie door licht en daar waar mogelijk met hem mee te lopen om te leren.
@ topic; mijn ervaring met het geen uw beschrijft, is dat het vaak allemaal theoretisch geneuzeld is dat weinig waarde heeft als u het niet op de juiste manier uit voert. Een voorbeeld is zogenaamde formule die u geeft, daar heeft u weinig aan door dit gewoon uit de voeren, de formule is namelijk onderdeel van EEN vorm van risicoanalyse. 9 van de 10 mensen kennen de formule, maar als ze vraag het concreet te maken en aan te geven wat dit voor de bedrijfsvoering betekent zijn er maar zeer beperkt mensen die daar invulling aan kunnen geven.
Mogelijk het belangrijkste aspect wordt bij veel organisaties niet goed uitgevoerd, namelijk; wijzigingsbeheer. Pentesten, interne audits, externe audits enz. enz. zijn allemaal moment opnames, terwijl bij wijzigingen men nieuwe risico's kan introduceren.
Daarom vindt ik het persoonlijk belangrijk dat wijzigingen - van welke grote dan ook - worden beoordeeld en kunnen worden goedgekeurd, beïnvloed of afgekeurd door Security. Immers moeten niet alleen maatregelen worden genomen, maar dienen ze ook op de juiste wijze te worden geïmplementeerd, om dit concreet te maken in een voorbeeld dat veel mensen snappen;
Een auto dient te beschikken over een auto gordel. Maar een auto met een gordel is niet per definitie veilig, deze kan immers ook in de achterbak zijn gemonteerd (wijze van implementatie). Wanneer de auto gordel op een juiste wijze is geïmplementeerd en getest is de auto door (bij wijze van spreken) door de audit heen gekomen. Een dag na de auto begint een creatieve monteur (of in de IT systeembeheer, werkplekbeheer, netwerkbeheerder enz. enz.) de gordel los te schroeven en in de achterbak te monteren. De genomen maatregelen is zo niet langer doeltreffend, echter draagt de auto wel de stempel "goedgekeurd door Security". Voor dat deze monteur dus zijn wijziging gaat door voeren is het belangrijk dat zijn plan vooraf wordt beoordeeld door Security en na implementatie wordt getest/gecontroleerd (audit).
Dit zelfde geldt voor kwetsbaarheden die in levencyclus van de software of in de hardware aan het ligt komen waardoor de feitelijke status van "veilig" kan wijzigen. Aan de hand van een risicoanalyse zal bepaalt moeten worden welke maatregelen genomen dienen te worden.