Security Professionals - ipfw add deny all from eindgebruikers to any

Proces aanpak kwetsbaarheden (ISO27001)

12-02-2015, 16:42 door Anoniem, 5 reacties
Dag allemaal,

Ik ben zeer geinteresseerd in de proces aanpak die u hanteert bij het vinden van een kwetsbaarheid.
Dagelijks komen er nieuwe kwetsbaarheden aan het licht, die zowel betrekking kunnen hebben op software en/of hardware. Kwetsbaarheden kunnen op verschillende manieren ontdekt worden:
– pentesting
– interne of externe audit
– externe bronnen, etc.

Het proces om van dreigingen naar risico’s en naar beveiligingsmaatregelen te gaan heet risicomanagement. Risicomanagement is een continu proces waarin risico’s worden geïdentificeerd, onderzocht, en gereduceerd tot een acceptabel niveau.

Gezien vanuit de rol van Security Officer (SO) ben ik benieuwd naar u ervaring in:
– proces aanpak (beoordelen of maatregelen voldoende zijn of nieuwe maatregelen nodig zijn)
– formules (risk = vulnerability x threat of risk = impact x likelihood)
– verantwoordelijkheden van SO en andere functies/rollen
– borging (externe audit)
– rapport richting directie (in control)

Alvast vriendelijke bedankt voor de reacties.
Reacties (5)
13-02-2015, 00:56 door Anoniem
Het vinden van een kwetsbaarheid staat in principe los van het gevoerde risicomanagement (of eigenlijk continuïteitsmanagement) en de daaruit voortvloeiende beveiligingsmaatregelen. Technische kwetsbaarheden hebben veel meer raakvlak met de dagdagelijkse operatie en incidentmanagement.

Want als je het goed voor elkaar hebt heb je immers:
1) Een goede analyse gemaakt van de grootste risico's
2) Maatregelen genomen om die risico's te mitigeren.

Vind men dus een kwetsbaarheid dan hoeft men in theorie alleen nog maar een afweging te maken of de kosten die gepaard gaan met het oplossen van de kwetsbaarheid in verhouding staan tot de waarde van het te beschermen goed.

Een kwetsbaarheid is immers letterlijk een waardeoordeel wat je geeft aan een bepaald gegeven. Waar de één dubbel glas in een raamkozijn veilig genoeg vindt, wil de ander inbraakwerend glas met een extra beschermende coating.
17-02-2015, 10:20 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?
17-02-2015, 11:16 door Preddie - Bijgewerkt: 17-02-2015, 11:49
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.
18-06-2015, 13:26 door Anoniem
weet iemand hoe je de dreigingen/kwetsbaarheden kunnen inschatten?
01-07-2015, 16:58 door Anoniem
Door Anoniem: weet iemand hoe je de dreigingen/kwetsbaarheden kunnen inschatten?

Vergelijk de volgende twee stappen, en je bent al en eind op weg:

1. inschatten zonder maatregel:
- kans van de dreiging
- Impact (schade) als die dreiging een feit is geworden
- kosten (tijd, geld, effort) voor herstel

2. inschatten met maatregel:
- kans van de dreiging na maatregel
- Impact (schade) als die dreiging een feit is geworden
- kosten (tijd, geld, effort) voor herstel
- kosten (tijd, geld, effort) van de maatregel
- kosten eventueel extra gebruikersongemak
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.