Informatiebeveiliging voor kwaliteitsmanager

Informatiebeveiliging voor kwaliteitsmanager

SYSQA B.V. Almere

Datum Status Versie Opgesteld door

: 10-04-2013 : Definitief : 1.0 :

Organisatie Titel

SYSQA B.V. Informatiebeveiliging voor kwaliteitsmanager

Pagina Versie Datum

2 van 22 1.0 10-04-2013

Inhoudsopgave 1

Inleiding ................................................................................. 3 1.1 1.2 1.3 1.4

2

Informatiebeveiliging voor kwaliteitsmanager ........................ 5 2.1 2.2 2.3 2.4 2.5 2.6 2.7

3

Relatie tussen kwaliteitszorg en informatiebeveiliging ....................... 5 Organisatie van informatiebeveiliging .............................................. 6 Informatiebeveiligingsbeleid .......................................................... 6 Security awareness....................................................................... 7 Vatbaarheid van medewerkers voor misbruik ................................... 8 Veranderingen van informatiebeveiligingsrisico’s .............................. 8 Positie van kwaliteitsmanager in de organisatie ............................. 9

Informatiebeveiliging en de lijnorganisatie ........................... 10 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8

4

Doel en veronderstelde voorkennis ................................................. 3 Relatie met andere documenten van expertisegroep Security ............. 3 Indeling van het document ............................................................ 4 Gerelateerde documenten ............................................................. 4

Managementsysteem voor informatiebeveiliging (ISMS) .................. 10 Risicomanagement ..................................................................... 10 Informatiebeveiliging incidentenbeheerproces ................................ 11 Wijzigingenbeheer ...................................................................... 11 Beheer ...................................................................................... 11 Documentatie ............................................................................ 13 Functiescheiding ......................................................................... 13 Contractmanagement ................................................................. 13

Informatiebeveiliging en projecten ....................................... 15 4.1 Quality reviews (review van programma- en projectplan) ................ 15 4.2 Project initiatie ........................................................................... 16 4.3 Inrichting projectteam en –middelen............................................. 16 4.4 Opstellen requirements ............................................................... 17 4.5 Ontwikkelproces ......................................................................... 18 4.6 Testen ...................................................................................... 18 4.7 Testdata .................................................................................... 19 4.8 Testomgeving ............................................................................ 19 4.9 Defect beheer ............................................................................ 20 4.10 Overdracht naar beheer............................................................ 20 4.11 Afronding project ..................................................................... 20

5

Bijlage 1 ................................................................................ 22 5.1 Bronvermelding en overige informatie ........................................... 22 5.2 Verwante documenten ................................................................ 22 5.3 Woordenlijst .............................................................................. 22

Almere © 2013

Proud of it

Organisatie Titel


Pagina Versie Datum

3 van 22 1.0 10-04-2013

1 Inleiding 1.1 Doel en veronderstelde voorkennis Dit document is bedoeld om kwaliteitsmanagers meer handvatten te geven bij het uitvoeren van deze rol. Er wordt verondersteld dat de kwaliteitsmanager basiskennis heeft van informatiebeveiliging op het niveau van “Information Security Foundation based on ISO/IEC 27002” van EXIN. Op de kennisbank van SYSQA staat een document “Informatiebeveiliging Algemene Basis” waarin de basisbegrippen en principes worden toegelicht. Dit documenten verstrekt de benodigde basiskennis. Verder kunnen de documenten voor requirementsanalist, testmanager en functioneel beheer als aanvulling worden gezien. Daarin worden per rol specifieke zaken beschreven waarvan een kwaliteitsmanager op z’ n minst de hooflijnen van behoord te weten. In dit document staan geen uitputtende beschrijvingen. Er worden vooral aandachtspunten benoemd waardoor de kwaliteitsmanager vanuit zijn achtergrond en ervaring wordt aangespoord meer kritische vragen op het gebied van informatiebeveiliging stellen in zijn/haar opdracht. Informatiebeveiliging wordt in dit document afgekort tot IB om de leesbaarheid te verhogen. In veel organisaties heeft men het over security. De term “security” heeft ook associaties met fysieke beveiliging. Bewust is voor de term “informatiebeveiliging” gekozen omdat in dit document vooral over beveiliging van informatiesystemen en – processen wordt gesproken.

1.2 Relatie met andere documenten van expertisegroep Security De expertisegroep Security van SYSQA B.V. heeft een set van documenten over informatiebeveiliging opgeleverd. Introductie Informatiebeveiliging

Basiskennis Informatiebeveiliging

Informatiebeveiliging voor Requirementsanalist

Informatiebeveiliging voor Testmanagement

Informatiebeveiliging voor Functioneel Beheer

Informatiebeveiliging voor Kwaliteitsmanager

In donkerblauw is het voorliggende document weergegeven.

Almere © 2013

Proud of it

Organisatie Titel


Pagina Versie Datum

4 van 22 1.0 10-04-2013

1.3 Indeling van het document De opzet van dit document is als volgt. Als eerste wordt het IB beleid behandeld. Een aantal tips en aandachtspunten worden aangereikt om het IB beleid helder te krijgen. Aanvullend wordt de lijnorganisatie behandeld. Focus van de lijnorganisatie is op stabiliteit en continuïteit van de bedrijfsprocessen. Hier gelden een aantal specifieke zaken rondom IB waar een kwaliteitsmanager rekening mee dient te houden. Vervolgens wordt ingegaan op projecten en op welke zaken een kwaliteitsmanager moet letten. Focus van projecten is op veranderen en vernieuwen waardoor voor IB een aantal aanvullende aandachtsgebieden gelden. Als laatste zijn referenties opgenomen naar interessante en relevante artikelen in relatie tot IB.

1.4 Gerelateerde documenten Bij dit document zijn nog 2 andere documenten van belang. Het Risk Treatment Plan en de Security Baseline. In beide documenten staan checklists en vragen die verder verdiepen op de onderwerpen die in dit document worden behandeld. Beide documenten zijn op te vragen bij product management. In de bijlage is een lijst met verwijzingen naar relevante artikelen, websites en boeken opgenomen.

Almere © 2013

Proud of it

Organisatie Titel


Pagina Versie Datum

5 van 22 1.0 10-04-2013

2 Informatiebeveiliging voor kwaliteitsmanager Een kwaliteitsmanager krijgt met veel aspecten van IB te maken. IB zit in alle lagen en uithoeken van de organisatie. Belangrijk is dat de kwaliteitsmanager goed inzicht krijgt en heeft in hoe het beleid vanuit de top wordt opgesteld, de mate waarin of de manier waarop het wordt uitgedragen en de traceerbaarheid tot aan de werkvloer. Vragen die de kwaliteitsmanager hoort te stellen:  Is de gehele organisatie van IB op de hoogte?  Wordt het IB beleid ook goed toegepast?  En houdt men bij wijzigingen voldoende rekening met IB?

2.1 Relatie tussen informatiebeveiliging

kwaliteitszorg

en

De gehele organisatie moet doordrongen zijn van het nut en de noodzaak van kwaliteit wil de kwaliteitsmanager goed werk kunnen verrichten. Hetzelfde geldt voor IB. Als men zich niet integraal met IB bezighoudt ontstaan er zwakke schakels die op zich weer een risico vormen voor IB. De zwakste schakel bepaalt het niveau van volwassenheid van de kwaliteitszorg en IB. Het controleren en bewaken van verband tussen de verschillende onderdelen en systemen is een kwaliteitsmanager dus niet vreemd. Kwaliteit is afhankelijk van een integrale aanpak, net als IB. Bij het verkennen van de organisatie kan de kwaliteitsmanager zowel naar kwaliteit als naar IB kijken. Ook in de kwaliteitsattributen wordt meer aandacht besteed aan IB. Zo is in de nieuwe ISO 25010 – die de oude ISO 9126 vervangt- een aparte hoofdgroep 5. Beveiligbaarheid (Security) opgenomen. In deze hoofdgroep zijn een aantal nieuwe kwaliteitsattributen toegevoegd:  Vertrouwelijkheid (Confidentiality)  Integriteit (Integrity)  Onweerlegbaarheid (Non-repudiation)  Verantwoording (Accountability)  Authenticiteit (Authenticity) Zoals in de ISO 25010 is te zien zijn er meer attributen dan de 3 standaard elementen van IB: beschikbaarheid, integriteit en vertrouwelijkheid. Zo is er ook de Parkerian Hexad die een uitbreiding is op de drie standaard elementen van IB:  Vertrouwelijkheid (Exclusiviteit)  Bezit of controle  Integriteit  Authenticiteit  Beschikbaarheid  Utiliteit (Bruikbaarheid) Deze aanvullingen van ISO 25010 en de Parkerian Hexad zijn relevant. Zo kan een bestand goed worden beschermd door een versleuteling toe te passen, maar als de sleutel zoek is kan je niets meer met de data in dat bestand. Verlies van de sleutel is dus een ander aspect die niet gedekt wordt door Beschikbaarheid. Zelfde geldt voor “bezit of controle”. Als een USB-stick met gegevens zoek is wilt dat niet zeggen dat de informatie ook daadwerkelijk wordt misbruikt. Er is dan geen controle meer over de data.

Almere © 2013

Proud of it

Organisatie Titel


Pagina Versie Datum

6 van 22 1.0 10-04-2013

Tip: De 3 beveiligingsaspecten worden in de meeste documentatie over IB genoemd. Het is aan te bevelen om aanvullingen van ISO 25010 en de Parkerian Hexad mee te nemen. Daarmee wordt de IB meer volledig toegepast. Zie ook hier de relatie tussen IB en functionaliteit. Bij het opstellen van requirements lopen discussies over functionele, performance en IB requirements veelal door elkaar heen. In die discussies zijn deze aanvullingen nuttig. Zie ook het document Basiskennis informatiebeveiliging, hoofdstuk 3.1.

2.2 Organisatie van informatiebeveiliging De kwaliteitsmanager moet weten hoe de organisatie waarin hij acteert de IB organisatie heeft ingericht. Het IB beleid wordt door de leiding van de organisatie opgesteld waarna verschillende rollen dat verder uitwerken en uitvoeren. Een kwaliteitsmanager dient dus op zoek te gaan naar de security officer en met hem of haar een kennismakingsgesprek voeren. Tijdens het gesprek kan worden besproken wat van eenieder wordt verwacht. Door aan te sturen op een gesprek met de security officer geeft de kwaliteitsmanager aan dat IB belangrijk voor hem/haar is. Tijdens de opdracht komt de kwaliteitsmanager geregeld in contact met de security officer. Het is daarom belangrijk te weten wat de security officer bezig houdt.

2.3 Informatiebeveiligingsbeleid In de organisatie is uiteindelijk één persoon verantwoordelijk voor het IB beleid. Zijn werkgebied en die van de kwaliteitsmanager liggen in elkaars verlengde en hebben op bepaalde zaken een overlap. Als het goed is wordt de kwaliteitsmanager door de opsteller van het IB beleid als partner gezien. Zowel kwaliteit als IB worden beïnvloed door compliancy. Voor beide vakgebieden kunnen er regels en wetten zijn waar organisaties aan moeten voldoen. Dus ook vanuit kwaliteitsoogpunt moet naar compliancy, continuïteit (bedrijfszekerheid) en IB worden gekeken. Een kwaliteitsmanager kan hier niet omheen. Het informatiebeleid is input voor het kwaliteitssysteem en het kwaliteitssysteem wordt gebruikt om het IB beleid te borgen. In het IB beleid staat aangegeven wie waar voor verantwoordelijk is. Een aantal vragen die de kwaliteitsmanager kan stellen:         

Wie stelt het IB beleid op? Wie borgt het IB beleid? Is voor iedereen helder welke wetten, regels en standaarden van toepassing zijn? Zijn er specifieke richtlijnen voor IB? Hoe ziet men de kwaliteitsmanager rol in het IB beleid en IB processen? Is het IB beleid traceerbaar? (rollen, instructies en acties) Hoe wordt het IB beleid vertaald door de rollen requirementsanalist/business analist en testmanager? Wordt het IB beleid consequent toegepast? Is er goed overzicht en inzicht in de systemen, risico’s en dreigingen?

In toenemende mate wordt in organisaties meer aandacht besteed aan IB. Een hefboom die dat versterkt is de politiek. Er wordt continu gewerkt aan nieuwe wetgeving die bedrijven en instellingen verplicht voldoende maatregelen te treffen. Organisaties zijn verplicht ernstige IB incidenten openbaar te maken. Indien onverhoopt blijkt dat men dat Almere © 2013

Proud of it

Organisatie Titel


Pagina Versie Datum

7 van 22 1.0 10-04-2013

niet heeft gedaan staan daar sancties op. Een organisatie kan zich niet meer veroorloven om IB buiten de directiekamer of boardroom te houden. Het hoogste management niveau is voor het IB beleid verantwoordelijk. Iedereen (elke rol) dient zich bewust te zijn van de consequenties van het IB beleid en iedereen behoort er naar te handelen. Maar gebeurt dat ook? Indien het IB beleid niet consequent en consistent is of niet strikt wordt uitgevoerd, ontstaan er zwakheden (zwakke schakels) wat weer een risico op zich vormt. Bij het niet naleven van het IB beleid wordt de kans verhoogd dat een bedreiging werkelijkheid wordt. Het bedrijf loopt dan een verhoogd risico waarvan het juist gevrijwaard wilt blijven.

2.4 Security awareness Bij de start van de opdracht kan de kwaliteitsmanager al een goede indruk krijgen van het beleid. Als er een IB beleid is dan komt dit ook tot uiting tot een aantal concrete maatregelen. Deze maatregelen moeten, veelal via een training, aan de medewerkers kenbaar worden gemaakt. Dus zelfs voordat de opdracht goed en wel begonnen is, is al vast te stellen of er een IB beleid is. Tip: Vraag om welke trainingen voor een externe medewerker verplicht zijn. Is de security awareness training niet aanwezig of niet verplicht, dan is dit een indicatie dat men geen focus op IB heeft. Tip: Als na verloop van tijd een uitnodiging voor een security awareness training of toets uit blijft kan worden gevraagd waarom dat het geval is. Dat is tevens een goede gelegenheid om door te vragen over het informatiebeveiligingsbeleid. De volgende vragende vragen zijn relevant bij de start van de opdracht om inzicht te krijgen in het IB beleid:      

Is bijvoorbeeld een security awareness training voor iedere externe medewerker verplicht of hoeven alleen de interne medewerkers de training te volgen? Heeft er een screening plaatsgevonden? Moet er een geheimhoudingsverklaring worden ondertekend? Worden de huisregels toegelicht, nageleefd en wordt toegezien op de naleving daarvan? Is er een beleid voor het gebruik van social media? Zijn er regels voor thuiswerken?

De eerste dagen/weken van de opdracht dient men op enige wijze proactief vanuit de organisatie de nieuwe (externe) medewerkers moeten trainen of inzicht verschaffen op de genomen IB maatregelen. Of dit nu via een training of via het laten ondertekenen van documenten gebeurt, de informatie moet gedeeld en bij de betreffende medewerker(s) getoetst worden. Het moet aantoonbaar zijn dat men de informatie tot zich genomen heeft. Anders is het achteraf, bij een incident, niet aan te tonen dat men willens en wetens niet volgens de regels heeft gehandeld.

Almere © 2013

Proud of it

Organisatie Titel


Pagina Versie Datum

8 van 22 1.0 10-04-2013

2.5 Vatbaarheid van medewerkers voor misbruik Social engineering en social media verdienen speciale aandacht. In een tijd dat steeds meer via internet wordt gecommuniceerd en gedeeld bestaat hier toch wel een groot risico. Medewerkers zijn voor hackers gemakkelijk op te sporen en te manipuleren. In goed vertrouwen kunnen medewerkers onbedoeld heel veel waardevolle informatie delen met hackers. Ook “het nieuwe werken” brengt risico’s met zich mee. Denk aan “shoulder surfing” waarbij een medewerker in een publieke ruimte werkt. Zonder er erg in te hebben kijkt iemand anders de inloggegevens af of kijkt mee in belangrijke gegevens. Eigen apparatuur worden steeds vaker voor werkzaamheden ingezet, scheiding tussen privé en werk wordt daarmee steeds kleiner. Gemakkelijk voor de medewerker, een kopzorg voor de IB. Er zijn veel manieren waarop medewerkers onbewust en onbedoeld toch informatie buiten de organisatie kunnen brengen. Hier moet het IB beleid op anticiperen. Veel organisaties zijn zich niet bewust van de bovengenoemde risico’s en hebben geen goede of onvoldoende tegenmaatregelen opgesteld.           

Staan in de huisregels iets over toegang verlenen aan vreemden? Hoe worden de huisregels nageleefd? Wordt aan een vreemde gevraagd of die zich wilt legitimeren? Is er een clean desk policy? Werkt men met beveiligd printen? Mag men documenten mee naar huis nemen? Worden vertrouwelijke documenten vernietigd? Zijn er spelregels voor social media opgesteld? Gaan de regels voor het gebruik van social media verder dan het niet toestaan tijdens kantooruren? Wordt er vanuit de organisatie de social media berichten van de medewerkers gevolgd? Worden eigen apparatuur toegestaan voor het uitvoeren van werkzaamheden?

2.6 Veranderingen van informatiebeveiligingsrisico’s In de loop van de tijd worden bestaande risico’s vaak minder en verschijnen er nieuwe risico’s. De technologische vernieuwingen en veranderingen maar ook veranderend gedrag, denk bijvoorbeeld aan meer thuis werken, moeten elke keer weer opnieuw worden afgewogen op risico’s voor de organisatie. Het opstellen van een IB beleid is niet iets wat éénmalig wordt gedaan. Er moet een proces aanwezig zijn waardoor het IB beleid op gezette tijden tegen het licht wordt gehouden. Bij onafhankelijke organisatie zoals OWASP (The Open Web Application Security Project, http://www.owasp.org) en ISF (Information Security Forum, http://www.securityforum.org) is informatie te verkrijgen over de nieuwste trends en ontwikkelingen op het gebied van IB. OWASP is voor iedereen vrij toegankelijk. Bij ISF dient de organisatie lid te zijn alvorens informatie kan worden opgevraagd. Tip: Kijk eens op internet naar de top 10 van IB risico’s en zie of die in het IB beleid worden meegenomen en met IB maatregelen worden afgedekt. Zie bijvoorbeeld: https://www.owasp.org/index.php/Top_10_2013-T10

Almere © 2013

Proud of it

Organisatie Titel

2.7


Pagina Versie Datum

9 van 22 1.0 10-04-2013

Positie van kwaliteitsmanager in de organisatie

Een kwaliteitsmanager kan binnen een organisatie op verschillende posities actief zijn: 1. In de lijnorganisatie, boven de programma’s en projecten. Dit heeft een continu karakter. 2. In een programma of project. Dit heeft meer een tijdelijk karakter. In de twee volgende hoofstukken wordt op beide specifieker ingegaan.

Almere © 2013

Proud of it

Organisatie Titel


Pagina Versie Datum

10 van 22 1.0 10-04-2013

3 Informatiebeveiliging en de lijnorganisatie In het voorgaande deel over projecten is al veel genoemd dat ook betrekking heeft op de lijnorganisatie. Projecten zijn vooral bezig met wijzigingen op de bestaande situatie terwijl de lijnorganisatie zich bezig houdt met die bestaande situatie. Ook voor de huidige situatie geldt dat deze moet voldoen aan de IB eisen. Om aan deze eisen te voldoen moeten ook noodmaatregelen opgesteld en ingevoerd worden. Bij het in beheer nemen van producten die door projecten worden opgeleverd moet de lijnorganisatie een aantal zaken inregelen. Voordat maatregelen worden ingesteld worden eerst de risico’s in kaart gebracht.  Hoe gaat de organisatie met risico’s om?  Hoe is risicomanagement ingericht?  Hoe komt men tot mitigerende maatregelen?  En hoe bewaakt men deze maatregelen?  Hoe monitort men de triggers?  Heeft men noodprocedures opgesteld?

3.1 Managementsysteem (ISMS)

voor

informatiebeveiliging

In de NEN 27001:2005 wordt in de eerste 5 hoofstukken aandacht besteed aan het managementsysteem voor IB. Information Security Management System (ISMS) genaamd. Ook bij ITIL v3 (zie bijlage Foundations van ITIL v3, par 10.6, pag. 221-225) wordt hier aandacht aan geschonken. Daarbij wordt aangegeven dat het van belang is dat het ISMS aansluiting heeft bij andere management systemen. Belangrijk is de betrokkenheid en van de directie bij dit systeem. Tip: In het informatiebeleid moet beschreven staan hoe het ISMS wordt ingezet en wie ervoor verantwoordelijk is.

3.2 Risicomanagement Startpunt voor kwaliteit is veelal een risicoanalyse. Zeker bij het testen is dat het geval. Vanuit het risicoprofiel en risicogedrag van de organisatie wordt de testen opgezet. Hoogste risico’s worden het eerst en met een hogere dekking getest. Past men alleen een risicoanalyse toe bij het testen? Ook IB is risico gedreven, vanuit de risico’s wordt bepaald welke maatregelen worden getroffen en bewaakt. Een risicoanalyse kan volgens verschillende methoden worden uitgevoerd. Als kwaliteitsmanager is het handig aan te sluiten bij de methode die men al voor IB toepast. Een aantal vragen in relatie tot risicomanagement:  Inventarisatie van strategische security en continuïteitsrisico’s, het opstellen van security en continuïteitsbeleid en het coördineren en faciliteren van de implementatie van dit beleid.  Welke methodieken worden gebruikt? o Analyse  Opstellen van Risk Treatment Plan (zie bijlagen) o Management  Risicomatrix  Risicoregister / Administratie  Bewaking / monitoring  Noodprocedure starten bij IB incident  Achterhaal het risicogedrag van de organisatie en afdeling. Zijn die in lijn met elkaar?  Welke risico’s vindt men belangrijk en welke maatregelen zijn genomen? Almere © 2013

Proud of it

Organisatie Titel




Pagina Versie Datum

11 van 22 1.0 10-04-2013

Tot hoever is risicomanagement doorgevoerd? Tip: Zoek uit welke risicomanagement systemen en methoden de organisatie gebruikt. Het is handig als men voor IB, compliancy, business continuity en risicoanalyse bij testen een vergelijkbare werkwijze/methode gebruikt.

Risicomanagement is een vakgebied op zich. Er zijn meerdere standaarden, COSO, M_o_R en NEN/ISO 31000 zijn voorbeelden hiervan. In bijlage 1 zijn referenties opgenomen.

3.3 Informatiebeveiliging incidentenbeheerproces Is er een incidentenbeheerproces aanwezig? En wat voor incidenten worden daar geregistreerd? Voor IB incidenten is veelal een aparte helpdesk ingericht met een apart registratiesysteem. IB incidenten moeten meestal vertrouwelijk worden behandeld.  

Hoe worden incidenten omgezet naar kwaliteitsmaatregelen? Hoe leiden kwaliteitsincidenten tot terugkoppeling naar maatregelen?

IB

beleid

en

-

Net als bij kwaliteitsmaatregelen geldt voor IB maatregelen dat de organisatie moet leren van haar fouten. Soms kan één incident aanleiding zijn tot een wijziging, soms kan een problem (bundeling van gelijksoortige incidenten) de aanleiding zijn. Ook ervaringen van andere organisaties kan aanleiding zijn tot het herzien van bepaalde IB maatregelen.

3.4 Wijzigingenbeheer In hoeverre wordt IB gerelateerde afdelingen opgeschakeld bij het uitwerken en invoeren van wijzigingen in de werkwijzen, systemen, infrastructuur of organisatie? Bij het opstellen en beoordelen van wijzigingen moet naar IB worden gekeken. Is er inzicht in de huidige en toekomstige IB risico’s voor/door:  Gegevenseigenaar  Systeemeigenaar  Proceseigenaar Tip: Neem in het wijzigingsjabloon een aparte paragraaf voor IB op.

3.5 Beheer De beheerders hebben veel met de uitvoering van IB processen te maken. Zij voeren de IB maatregelen en controles uit. Daarnaast onderkennen zij ook vaak als eersten een IB incident. Technisch beheerders installeren en onderhouden de detectiesystemen. Het is van belang dat ze weten hoe ze moeten handelen als een IB incident zich voordoet. Beheerders moeten daarom goed geschoold zijn om het IB beleid om te zetten in effectieve IB maatregelen. Beheerders worden veelal ook betrokken bij de corrigerende maatregelen tijdens/na een IB incident. Een simpele corrigerende IB maatregel is het terugplaatsen van een back-up. Daarmee kan data dat verloren is gegaan of corrupt is geraakt worden hersteld. Een ander aspect van beheer is het doorvoeren van patches. Hoe is het patchbeleid? Loopt men ver achter of voert beheer een gebalanceerd beleid: niet meteen alle patches installeren i.v.m. risico’s, wacht men totdat uit het veld/de markt genoeg zekerheid is. Almere © 2013

Proud of it

Organisatie Titel


Almere © 2013

Pagina Versie Datum

12 van 22 1.0 10-04-2013

Proud of it

Organisatie Titel


Pagina Versie Datum

13 van 22 1.0 10-04-2013

Uit het bovenstaande blijkt dat beheerders betrokken zijn bij het voorkomen en oplossen van IB incidenten. Vandaar een aantal vragen over IB en beheer:  Zijn de beheerders (functioneel/applicatie/technisch) bekend met het IB beleid en kennen ze het IB incidentenbeheerproces?  Is er een patchbeleid?  Weten beheerders hoe ze een IB incident moeten melden?  Zijn er geautomatiseerde signaleringen voor misbruik ingericht?  Is er back-up beleid?  Wordt het restoren van een back-up ook geregeld geoefend?

3.6 Documentatie Het blijkt dat in veel sjablonen geen aandacht wordt besteed aan IB. En als er al aandacht aan wordt besteed en ingevuld dan ontbreekt de security officer in de verzendlijst. Een aantal vragen over documenten:  Staat op documenten een classificatie (bijvoorbeeld: vertrouwelijk)?  Staan in sjablonen hoofstukken benoemd specifiek voor security?  Worden de IB paragrafen ingevuld?  Staan er referenties naar IB gerelateerde documenten zoals de Security Baseline?  Is er een aparte IB checklist?  Worden in SLA’s IB richtlijnen meegegeven?  Worden de documenten door de security officer gereviewd?  Geeft de security officer een apart akkoord op het document?

3.7 Functiescheiding Functiescheiding zorgt voor een betere grip op IB. Het zorgt ervoor dat er geen belangenverstrengeling plaats vindt. Denk hierbij bijvoorbeeld aan de verdeling van gebruiker, systeemeigenaar, proceseigenaar en gegevenseigenaar. Stel dat een beheerder worden gevraagd een SQL query te maken om bepaalde gegevens uit het systeem te halen. Wordt dan goedkeuring aan de gegevenseigenaar gevraagd? En bij herhaaldelijke verzoeken, wordt dan de proceseigenaar ingeschakeld? Blijkbaar kan een proces geen voortgang vinden als de informatie ontbreekt. Een herziening van het proces is dan nodig. Een goede RACI-matrix kan helpen bij het inzichtelijk krijgen en houden van de verantwoordelijkheden. De juiste rollen en taken moeten goed zijn verdeeld over de mensen zodat er minimaal 2 mensen nodig zijn bij een besluit. Tip: Functiescheiding privileges.  

voorkomt

misbruik

van

rechten

en

Zijn er RACI-matrixen? Worden de RACI-matrixen opgevolgd?

3.8 Contractmanagement Ook bij contracten moet men rekening houden met het IB beleid. In de contracten moet bijvoorbeeld worden vast gelegd hoe men handelt in geval een IB incident optreedt. In het document “Security Baseline” is een lijst met vragen en aandachtpunten voor contracten opgenomen.

Almere © 2013

Proud of it

Organisatie Titel


Pagina Versie Datum

14 van 22 1.0 10-04-2013

3.8.1 Outsourcing Wanneer werkzaamheden worden uitbesteed aan een andere partij behoort deze partij minimaal dezelfde beveiligingsregels na te leven. Outsourcing kan ook tot een hogere IB leiden wanneer de uitvoerende partij een goed IB beleid heeft en juiste maatregelen heeft getroffen. Aan de andere kant wordt er meer informatie worden uitgewisseld of bij de partner ondergebracht. Het is dus zaak om goede afspraken te maken en na te komen.  

Staat in het contract/SLA richtlijnen voor IB? Rapporteert de partner ook over IB maatregelen en -incidenten? Tip: Loop het contract met de partner eens door op informatiebeveiligingsaspecten en KPI’s op dit vlak.

3.8.2

ESCROW

ESCROW is een betrouwbare, onafhankelijke partij ingeschakeld om bijvoorbeeld de broncode van software in bewaring te geven. Daarmee heeft de klant/opdrachtgever de zekerheid dat bij een faillissement van de softwareleverancier, de klant/opdrachtgever toch over de broncode kan beschikken. Hierdoor loopt de klant/opdrachtgever een verminderd risico. De condities waaronder de broncode beschikbaar wordt gesteld staan in het contract. Net als de frequentie waarin de leverancier nieuwe versies van de broncode beschikbaar stelt.    

Wordt de broncode goed opgeslagen bij de ESCROW agent? Is gecontroleerd dat de set van broncode compleet is? Kan men in eigen beheer de broncode bewerken? Kan men in eigen beheer de software verder ontwikkelen? Tip: Bij een backup wordt een restore uitgevoerd om te zien of een backup proces goed werkt. Doe dit ook eens voor het ESCROW proces. Heeft men werkelijk alles om ontwikkeling van de software in eigen beheer voort te zetten?

Almere © 2013

Proud of it

Organisatie Titel


Pagina Versie Datum

15 van 22 1.0 10-04-2013

4 Informatiebeveiliging en projecten Projecten zijn er voor om innovatie door te voeren, nieuwe bedrijfsprocessen in te richten of bestaande te wijzigen. Als gevolg hiervan worden vaak geautomatiseerde systemen aangepast. Ook kunnen als gevolg van verbeteringen in een systeem de processen worden aangepast door bijvoorbeeld een workaround te verwijderen.  

Houdt men gedurende het project genoeg oog voor IB? Brengt men voldoende de risico’s in kaart en werkt men ook risico gedreven?

In projecten heeft de projectmanager vaak een doel: het project op tijd en binnen budget afronden. De eerste zaken die bij een project sneuvelen zijn: beheergemak en IB. Functioneel beheer wil een product opgeleverd krijgen dat aansluit bij de bedrijfsprocessen. Een technisch beheerder wil een goed beheersbaar systeem met een goede performance. Daarnaast wilt de testmanager de kwaliteit van het op te leveren product aantonen en adviseren over de risico’s die men loopt. Er zijn zoveel rollen, met ieder nog meer verschillende eisen. Het is zaak om een goede balans te vinden tussen functionaliteit, gebruikersgemak, performance én IB. Soms zijn zaken goed te combineren en leveren ze gemakkelijk meerwaarde. Maar soms is het lastig om een goede afweging te maken. Bijvoorbeeld Single Sign On (het eenmalig inloggen) is heel handig voor de gebruikers. Ze hoeven zich maar één keer aan te melden en hebben dan toegang tot alle, voor hen relevante applicaties. Maar vanuit het oogpunt van IB is het beter als men voor elke applicatie apart inlogt met verschillende inlogcodes en wachtwoorden. Veiligheidsrisico’s en gebruikersgemak moeten in dit voorbeeld tegen elkaar worden afgewogen. Security

Functionaliteit

Gebruikersgemak

Zo zijn er tal van voorbeelden te bedenken waarbij functionaliteit, gebruikersgemak, performance en IB ieder een andere oplossing vereisen. Het is zaak hier goed de risico’s in kaart te brengen en de juiste afwegingen te maken. Deze beslissing moet door iedere rol van het project worden gedragen.

4.1 Quality reviews projectplan)

(review

van

programma-

en

Wordt tijdens de quality reviews van programma’s en projecten voldoende aandacht geschonken aan security, usiness continuity en compliancy? Of wordt er alleen op kwaliteit van de eindproducten en projectresultaten (meestal tijd en geld) gestuurd? Tip: Zorg dat naast de gebruikelijke aspecten tijd, geld, scope en kwaliteit ook de aspecten security en compliancy worden behandeld.

Almere © 2013

Proud of it

Organisatie Titel


Pagina Versie Datum

16 van 22 1.0 10-04-2013

Zoals eerder gesteld is de leiding van de organisatie verantwoordelijk voor een goed IB beleid en uitvoering daarvan. Tijdens de quality reviews moet hier aandacht aan worden geschonken. Steeds meer wordt vanuit compliancy oogpunt meer gefocust op IB. Tip: Laat bij de quality review naast de programma manager, de project managers en kwaliteitsmanagers ook de security officer aanschuiven.

4.2 Project initiatie Wordt bij het opstarten van een project van meet af aan al rekening gehouden met IB? Bij veel projecten richt men zich in eerste instantie op de (nieuwe) functionaliteit en zijn performance en IB onderbelicht. Tenzij het project iets moet doen aan de ondermaatse IB. De projectmanager is er voor verantwoordelijk dat het gehele projectteam in de geest van het IB beleid opereert en ook producten oplevert die aan de IB eisen voldoen. Projectmanagers worden veelal extern aangetrokken en het is dus zaak dat zij, voordat zij aan de slag gaan, voldoende afweten van het IB beleid en de te nemen IB maatregelen. Een kwaliteitsmanager moet dit stimuleren en zo nodig de projectmanager bijsturen. Een optie is dat de kwaliteitsmanager samen met de projectmanager en security officer frequent om tafel zit. Tip: Controleer bij de review van het PID of IB risico’s worden benoemd en of het IB beleid goed wordt vertaald in projectdoelen. De projectdoelen mogen niet strijdig zijn met het IB beleid.

Tip: Laat het PID ook door de security officer reviewen.  

Wordt in het PID ook verwezen naar het IB beleid? Wordt in de opstartfase al een dossier opgebouwd waarin men bijhoudt welke gevoelige gegevens men opbouwt en wijzigt?

4.3 Inrichting projectteam en –middelen IB begint al voordat het project van start gaat. Voor sommige organisaties of projecten worden de medewerkers vooraf gescreend. Zeker bij projecten waar men met zeer gevoelige informatie of kritische systemen werkt gebeurt dat. Het is goed te weten of mensen gevoelig zijn voor chantage doordat ze een achtergehouden verleden hebben of met schulden zitten. Ook de te gebruiken hulpmiddelen moeten vooraf worden beoordeeld. Gebruik van Skype en Dropbox is af te raden. Beter is het om middelen te gebruiken die in het afgeschermde, interne netwerk beschikbaar zijn, zoals de equivalenten Microsoft Lync (chat) en Sharepoint (documenten delen). Waar staan bijvoorbeeld de bevindingen? Als die via een internetapplicatie worden gedeeld met een externe leverancier dan kan een hacker heel gemakkelijk de zwakheden van de systemen achterhalen en benutten door in te breken in de bevindingenbeheertool. In defects staan namelijk de zwakheden vermeld en hoe je die kunt creëren of kunt uitbuiten. Veelal met inlogcodes, url’s, servernamen en voorbeelden. Tip: Ook de door het team gebruikte tools en communicatiemiddelen moeten minimaal op een zelfde niveau van IB zijn als het te maken eindproduct. Almere © 2013

Proud of it

Organisatie Titel


Pagina Versie Datum

17 van 22 1.0 10-04-2013

Draadloos werken zorgt er voor dat berichten kunnen worden onderschept zonder dan men toegang tot het pand heeft. Ook bij thuiswerken kunnen aanvullende beveiligingsmaatregelen worden genomen. Wat gebeurt er met oude documenten? Nemen medewerkers die mee naar kantoor voor vernietiging? Blijven bij thuiswerken digitale kopieën achter op de privé computer? Testomgevingen moeten ook goed worden beveiligd. Als een hacker daar toegang toe krijgt kan hij leren en proberen hoe de productie omgeving werkt. Door een goede beveiliging op de testomgeving toe te passen kan dat worden bemoeilijkt. Tip: Zorg ervoor dat alleen specifieke rollen toegang krijgen tot testomgevingen en dat men alleen bijbehorende toegang krijgt. Tester behoren géén toegang tot productiesystemen te krijgen! Net als testomgevingen zijn ontwikkelomgevingen zeer interessant voor indringers. Wat is er leuker voor een hacker om in de code rond te snuffelen en eventueel aan te passen? Veiliger is het om de broncode in encryptie op te slaan. Zie ook paragraaf 3.8.2 over ESCROW.    

Worden mensen gescreend? Welke onveilige hulpmiddelen worden ingezet? Waar en hoe wordt de broncode opgeslagen? Worden defects afgeschermd?

4.4 Opstellen requirements Voordat requirements worden opgesteld wordt een stakeholderanalyse gedaan. Controleer of hierbij ook voldoende wordt gekeken naar rollen die inhoudelijk meer kunnen zeggen over bedrijfscontinuïteit en IB. De vraag is ook of de requirementsanalist of business analist voldoende van deze onderwerpen afweten en er ook voldoende focus op hebben en zo nodig de mensen met kennis op deze gebieden opschakelen. Denk bijvoorbeeld aan security officer of functioneel beheerder. Tip: Zorg dat bij het opstellen van requirements de rollen security officer, functioneel-, applicatie- en technisch beheerder betrokken zijn. Staat men genoeg stil bij de risico’s wanneer een security requirement niet wordt gehaald? Tip: Een requirementsanalist hoort ook te kijken naar wat voor risico’s men loopt als een requirement niet of niet goed wordt ingevuld. De Brainstorm-paradox elicitatietechniek is hierbij goed te gebruiken. Bij reviews leest men vaak alleen de tekst, het uitwerken in diagrammen geschied veelal in de ontwerpfase. Waarom niet meteen tijdens de review? Diagrammen helpen om niet gespecificeerde paden op te sporen. En als een pad niet is gedefinieerd ligt het aan de programmeur hoe het systeem omgaat met dit soort potentiële zwakheden van een systeem. Tip: maak bij reviews ook diagrammen om open einden en ontbrekende flows op te sporen. Alleen lezen van tekst is niet afdoende om deze potentiële beveiligingslekken te vinden. Almere © 2013

Proud of it

Organisatie Titel


Pagina Versie Datum

18 van 22 1.0 10-04-2013

Een andere benadering is om de requirements en werkwijze van het systeem eens vanuit het oogpunt van misbruik te benaderen. Nieuwe requirements komen dan zeker naar voren. Tip: Gebruik van abuse cases kan helpen IB problemen vooraf te vinden en op te lossen. Zie het document Test manager voor meer uitleg over Abuse Cases.

4.5 Ontwikkelproces Tijdens het ontwikkelen van de oplossing -hoeft niet altijd geautomatiseerd te zijn- is het zaak dat men voldoende stil staat bij aspecten op het gebied van IB. De laatste versies van de ontwikkelsuite hoort op de ontwikkelomgevingen te staan. Leveranciers dichten de beveiligingslekken in patches en nieuwe releases. Indien oude versies van de ontwikkelomgeving wordt gebruikt, loopt de organisatie een veiligheidsrisico. Dit wordt niet altijd onderkend. Daarnaast kunnen ontwikkelomgevingen ook met virussen te maken krijgen wat kan leiden tot desastreuze gevolgen. Tip: Vraag eens naar het patchbeleid van de ontwikkelomgeving. Wanneer heeft men de laatste versie van de ontwikkelsuite geïnstalleerd?        

Wordt van de softwarecode ook dagelijks een backup gemaakt? Hebben de designers en ontwikkelaars voldoende training gehad om IB en bedrijfscontinuïteit te kunnen waarborgen? Wordt tijdens de reviews van de designs ook een security-expert en beheerders ingeschakeld? Houden de ontwikkelaars zich voldoende bezig met IB? Houden ze er rekening mee bij het maken van de oplossing/hun (tussen)product? Worden technieken/middelen zoals code-review en tooling ingezet om de code op potentiële fouten te checken? Checkt men de designs ook op ontbrekende stappen/paden? Gebruikt men ook abuse cases? Tip: Veel informatiebeveiligingslekken kunnen al tijdens de ontwikkelfase worden opgespoord en hersteld. Dit scheelt veel tijd en geld later in het traject.

Zie ook hoofdstuk 2 van het document Informatiebeveiliging voor Testmanagement.

4.6 Testen Testen is risicogedreven, net zoals IB en business continuity. Met het testen van een informatiesysteem wil men inzicht krijgen in de risico’s die men loopt bij het ingebruik nemen ervan. De risico’s worden geïnventariseerd, gecategoriseerd en geprioriteerd. Vervolgens wordt van de hoogste risico’s door toetsen en testen bepaald of deze risico’s door voldoende tegenmaatregelen zijn afgedekt. Een vrijgaveadvies geeft aan welke risico’s men nog loopt.

Almere © 2013

Proud of it

Organisatie Titel


Pagina Versie Datum

19 van 22 1.0 10-04-2013

Veelal worden tijdens de risico analyse door de betrokkenen gefocust op functionaliteit. Performance en IB zijn vanuit de gebruikers over het algemeen minder belangrijk. Voordat men gaat testen een specificeren wordt een Product Risico Analyse uitgevoerd met alle relevante stakeholders. Dus daar horen dan ook beheerders en een security officer bij te zijn.        

Waar ligt de focus tijdens de PRA? Welke kwaliteitsattributen van ISO 25010 vindt men belangrijk? Kent men de security attributen? Heeft de testmanager de (security) kwaliteitsattributen uitgelegd/toegelicht? Is de security officer aanwezig bij PRA? Wordt het IB beleid goed in de PRA sessie meegenomen en wordt dit ook in de uitwerking van de PRA goed verwerkt? Zijn de systeem-, gegevens- en proceseigenaren zich voldoende bewust van de IB risico’s? Richt het testen zich op invoergegevens, interne verwerking en uitvoergegevens?

Op de kennisbank van SYSQA staat het document testmanagment dat dieper ingaat op het testen van IB.

Informatiebeveiliging

voor

4.7 Testdata Bij het gebruik van productiedata als testdata komt men al snel in contact met Wet Bescherming Persoonsgegevens (WBP), zeker als het gevoelige informatie betreft. Tip:

Voer

de

WBP

quickscan

uit,

te

vinden

http://www.cbpweb.nl/Pages/ind_wetten_zelfr_compliance_qs.aspx

op:

Voordat productiedata voor testen wordt gebruikt, moet worden afgevraagd of op andere manieren testdata gegenereerd kan worden. Als er toch productiedata nodig is dan zijn er diverse manieren om productiedata te anonimiseren, te mixen of te maskeren. Hiervoor zijn diverse tools en methoden beschikbaar, denk aan scrambling, shuffling, replacing en gebruik maken van seedlists en persona (klant profielen). Tip: Vraag eens aan de testers welke tools zij gebruiken om testdata te genereren. Als ze die niet gebruiken of productiedata inzetten dan is hier mogelijk een IB probleem die meer aandacht behoeft. Naast het aanmaken van testdata kan ook testdata en testomgevingen worden gebruikt om de vatbaarheid voor SQL injections op te sporen. Bij het invoeren van verkeerde data kan men testen of i.p.v. testdata SQL statements kan invoeren. Dit is te doen door “;” voorafgaand aan het SQL statements te geven. Deze SQL injection test kan men dus bij functionele testen als bij het genereren van testdata toepassen.

4.8 Testomgeving Testomgevingen worden veelal minder beveiligd dan productieomgevingen terwijl ze voor hackers juist heel interessant kunnen zijn, zoals in paragraaf 4.3 al gesteld. Een testomgeving kan door een hacker als leeromgeving worden gebruikt. In sommige gevallen worden productiesystemen aan een testomgeving gekoppeld omdat van dat systeem een testomgeving ontbreekt. Hiermee kan (on)bewust door testers de

Almere © 2013

Proud of it

Organisatie Titel


Pagina Versie Datum

20 van 22 1.0 10-04-2013

productieomgeving worden beïnvloed. Productiedata kan corrupt raken, performance kan achteruit gaan. Tip: Productiesystemen en testsystemen horen ontkoppeld te zijn om IB incidenten te voorkomen. In een repository moet worden bijgehouden welke systemen op welke wijze aan elkaar zijn gekoppeld. Ook in structured oriented architecture (SOA) testomgevingen moet een controle plaatsvinden of het systeem dat een serviceverzoek indient dit mag doen.

4.9 Defect beheer Zoals in paragraaf 4.3 is aangegeven verdiend de bevindingentool ook speciale aandacht. Wanneer een hacker toegang kan krijgen heeft deze een schat aan informatie over zwakheden van de systemen tot zijn beschikking. Bevindingen bevatten vaak hele specifieke en gedetailleerde informatie waarmee beveiliging is te omzeilen of om het systeem eenvoudig vast te laten lopen. Niet iedereen is zich bewust van dit risico. Vandaar dat niet iedereen zomaar toegang tot de bevindingen mag hebben. Tip: Bevindingen bevatten zwakheden van een systeem en daarom moeten de bevindingentool en –database goed beveiligd zijn.

4.10 Overdracht naar beheer Het is belangrijk dat (nieuwe) bedrijfsprocessen en (niet-)geautomatiseerde systemen voldoen aan de IB richtlijnen. Bij het opstellen of wijzigen van deze processen en systemen moet hierop worden getoetst. Een beheerder die een nieuw of gewijzigd proces of systeem in gebruik neemt moet zich ervan bewust zijn wat dat voor consequenties heeft voor de IB. Naast de beheerders zijn ook gegevens-, systeem- en proceseigenaren in het beheerproces betrokken. Zijn zij zich bewust van de nieuwe risico’s die het gewijzigde of nieuwe systeem met zich meebrengt? Zodra het nieuwe of gewijzigde informatiesysteem wordt overgedragen naar de beheerorganisatie spelen de in hoofdstuk 3 van voorliggend document genoemde zaken een rol. 

Wordt bij de overdracht rekening gehouden met het aanpassen van de backup? Denk aan aangepaste configuratie of databasestructuur.

4.11 Afronding project Bij afronding van een project horen de documentatie netjes te worden overgedragen aan de lijnorganisatie. Bij het opstarten worden veel zaken ingeregeld. Tijdens het project wordt er van alles geproduceerd en gewijzigd. Tip: Zoek het proces voor afronden van een project op en kijk of daar voldoende maatregelen in staan. Denk bijvoorbeeld aan verwijderen van testaccounts.  

Is er een proces om een project af te ronden en wordt dat ook gevolgd? Worden bij afronding van een project o de inloggegevens en rechten van de medewerkers verwijderd? o de testomgevingen en testdata overgedragen of verwijderd? Almere © 2013

Proud of it

Organisatie Titel

   


Pagina Versie Datum

21 van 22 1.0 10-04-2013

Is er een opschoningsproces wanneer een projectmedewerker tussentijds het project verlaat? Is er een automatisch proces om accountgegevens op te schonen als een account langere tijd niet wordt gebruikt? Wordt documentatie vernietigd die alleen tijdens het project nuttig was en daarna niet meer? Worden geleende materialen door/aan externe partij teruggegeven of vernietigd?

Almere © 2013

Proud of it

Organisatie Titel


Pagina Versie Datum

22 van 22 1.0 10-04-2013

5 Bijlage 1 5.1 Bronvermelding en overige informatie 5.1.1 Gebruikte richtlijnen en standaarden: De volgende richtlijnen en standaarden worden in dit document benoemd:  ISO 17799 Information technology – security techniques – code for information security management  ISO 25010 http://nl.wikipedia.org/wiki/ISO_25010  ISO 27001 Information Security Management System  ISO 27002 Informatietechnologie - Beveiligingstechnieken - code voor informatiebeveiliging  ISO 31000 Risico management

5.1.2 Bronvermelding De volgende bronnen zijn gebruikt:  Basiskennis informatiebeveiliging op basis van ISO27001 en ISO27002, Hans Baars, Jule Hintzbergen, Kees Hintzbergen, Andre Smulders. ISBN 978-90-8753567-4  Informatiebeveiling onder controle, Paul Overbeek, Edo Roos Lindgreen, Marcel Spruit, ISBN 978-90-430-0692-7  Risicomanagement op basis van M_o_R® en NEN/ISO 31000, Douwe Brolsma, Mark Kouwenhoven. ISBN: 978-90-8753-656-5  Requirements Engineering Fundamentals, Klaus Pohl, Chris Rupp. ISBN 978-1933952-81-9  Foundations van ITIL v3, Jan van Bon e.a., ISBN 978-90-8753-056-3  Certified Ethical Hacker Practice Exams, Matt Walker, ISBN 978-0-07-181026-5  http://en.wikipedia.org/wiki/Parkerian_Hexad  http://nl.wikipedia.org/wiki/Escrow  http://www.social-engineer.org/polls/social-engineering-poll-endearment-vsauthority/  http://www.cbpweb.nl  http://www.cbpweb.nl/Pages/ind_wetten_zelfr_compliance_qs.aspx  https://www.owasp.org

5.2 Verwante documenten Bij dit document horen 2 documenten die via product management op te vragen zijn: 1. Security Baseline 2. Risc Treatment Plan

5.3 Woordenlijst Gebruikte afkortingen: IB Informatiebeveiliging ISF Information Security Forum ISMS Information Security Management System OWASP The Open Web Application Security Project PID Project Initiatie Document PRA Product Risico Analyse RACI Responsible, Accountable, Consulted, Informed SOA Structured Oriented Architecture WBP Wet Bescherming Persoonsgegevens

Almere © 2013

Proud of it

Informatiebeveiliging voor kwaliteitsmanager

Recommend Documents