Check-list informatieveiligheid bij projektontwikkeling Information Security Policy Versie 2.00
03/11/20101
ISMS (Information Security Management System)
Check-list informatieveiligheid projektontwikkeling
bij
Version control – please always check if you’re using the latest version Doc. Ref. : isms_021_checklist_project_nl_2_00.doc Release
Status
Date
Written by
Approved by
NL_1.30
Final
10/10/2007
Johan Costrop
Werkgroep Informatieveiligheid
NL_2.00
Final
29/03/2011
Patrick Bochart
Werkgroep Informatieveiligheid
Opmerking: in dit document zijn de opmerkingen verwerkt van een werkgroep waaraan de volgende personen hebben deelgenomen: de heren Bochart (KSZ), Costrop (Smals), Noël (KSZ), Petit (FBZ), Quewet (FOD Volksgezondheid), Symons (RVA), Van Cutsem (RSZPPO), Van der Goten (RIZIV).
Check-list informatieveiligheid bij projektontwikkeling Information Security Policy Versie 2.00
03/11/20101
INHOUDSTAFEL 1.
INLEIDING.............................................................................................................................................. 3
2.
SCOPE ................................................................................................................................................... 3
3.
DEFINITIES ............................................................................................................................................ 3
4.
VEILIGHEIDSVEREISTEN BIJ PROJECTONTWIKKELING ............................................................... 3 4.1. CLASSIFICATIE VAN GEGEVENS ............................................................................................................... 3 4.2. REGLEMENTAIRE VEREISTEN .................................................................................................................. 4 4.2.1. Privacy wet en wet Kruispuntbank van de Sociale Zekerheidt .................................................... 4 4.2.2. Machtigingen van het Sectoraal Comité ...................................................................................... 4 4.2.3. Bewijskracht................................................................................................................................. 4 4.2.4. Uniek dossier ............................................................................................................................... 4 4.2.5. Toelatingen Kruispuntbank van de Sociale Zekerheid ................................................................ 4 4.3. MINIMALE VEILIGHEIDSNORMEN ............................................................................................................. 4 4.3.1. Uitbesteding aan derden.............................................................................................................. 4 4.3.2. Communicatie .............................................................................................................................. 4 4.3.3. Toegangsbeheer.......................................................................................................................... 5 4.3.4. Checklist....................................................................................................................................... 5 4.3.5. Controle voor in productiestelling ................................................................................................ 5 4.3.6. Gestructureerde aanpak .............................................................................................................. 5 4.3.7. Logging ........................................................................................................................................ 6 4.3.8. Back-up ........................................................................................................................................ 6 4.3.9. Continuïteitsbeheer...................................................................................................................... 6 4.3.10. Incidentenbeheer...................................................................................................................... 7 4.3.11. Documentatie ........................................................................................................................... 7 4.3.12. Inventaris.................................................................................................................................. 7 4.3.13. Audit ......................................................................................................................................... 7 4.4. PROJECT LIFE CYCLE ............................................................................................................................ 7 4.4.1. Initiatie.......................................................................................................................................... 7 4.4.2. Planning ....................................................................................................................................... 7 4.4.3. Realisatie ..................................................................................................................................... 8 4.4.4. Afsluiting....................................................................................................................................... 9
P2
Check-list informatieveiligheid bij projektontwikkeling Information Security Policy Versie 2.00
03/11/20101
1. Inleiding Dit document past in de ontwikkeling van het ISMS (Information Security Management System) . In het kader van een goede beveiligingsorganisatie is het nodig dat met veiligheidsvereisten rekening gehouden wordt en veiligheidsvereisten gedefinieerd worden vanaf de conceptfase van een projekt. Dit wordt voorgeschreven door de Information Security Policy (ISP). Naar de betreffende artikels van de ISP wordt verwezen (ISP). Van groot belang is ook rekening te houden met de Minimale veiligheidsnormen die moeten nageleefd worden door de Sociale Instellingen met het oog op hun aansluiting op het netwerk van de Kruispuntbank van de Sociale Zekerheid Deze worden in de tekst aangeduid met (minimumnorm).
2. Scope Dit document met betrekking tot de veiligheidsaspecten van ontwikkeling en onderhoud in het kader van ICT projecten, richt zich niet alleen tot de projectverantwoordelijken maar eveneens tot alle partijen die betrokken zijn bij de ontwikkeling van projecten (b.v. : de leden van de teams voor ontwikkeling, operationeel beheer en aankoop).
3. Definities Een aantal begrippen met betrekking tot de classificatie van gegevens die in dit document voorkomen worden verduidelijkt in het document “ISMS022 Policy data classificatie”, bijvoorbeeld : persoonsgegevens, vertrouwelijke gegevens.
4. Veiligheidsvereisten bij projectontwikkeling 4.1. Classificatie van gegevens In elke fase van de ontwikkeling zal bijzondere aandacht besteed worden aan de veiligheidsmaatregelen met betrekking tot de verwerking van gegevens, in overeenstemming met hun classificatie. Vanaf het opstarten van elk project is het noodzakelijk een risico analyse uit te voeren in functie van de classificatie van de gegevens. Deze analyse zal bijvoorbeeld de nood aan cryptografische methodes bepalen voor de vrijwaring van de vertrouwelijkheid, de authenticiteit en de integriteit van de gegevens. Deze technieken kunnen ook bijdragen aan de niet-weerlegbaarheid van de transacties (ISP). Bijzonder aandacht moet besteed worden aan de bescherming van de cryptografische basisgegevens (sleutels, certificaten,…) die nooit in een onbeveiligde vorm in een systeem opgeslgen mogen worden (ISP). Maatregelen worden genomen om te voorkomen dat informatie die wordt uitgewisseld met andere organisaties verloren gaat, gewijzigd of misbruikt wordt (ISP/minimale normen).
P3
Check-list informatieveiligheid bij projektontwikkeling Information Security Policy Versie 2.00
03/11/20101
4.2. Reglementaire vereisten 4.2.1.
Privacy wet en wet Kruispuntbank van de Sociale Zekerheidt
Er moet over gewaakt worden dat de wettelijke en anders overeengekomen beveiligingseisen waaraan de gebruikte informatiesystemen onderworpen zijn (ISP), nageleefd worden : voorbeelden hiervan zijn de bescherming van de persoonlijke levenssfeer en de wetgeving in het kader van de sociale zekerheid. 4.2.2.
Machtigingen van het Sectoraal Comité
Een machtiging van het bevoegd Sectoraal Comité is vereist om aan een instelling toe te laten persoonsgegevens uit te baten indien deze instelling niet de eigenaar van deze gegevens is. 4.2.3.
Bewijskracht
Wanneer de bewijskracht vereist is moet een dossier voorgelegd worden aan de bevoegde instanties. De bewijskracht context is gedefinieerd in Koninklijke besluiten. 4.2.4.
Uniek dossier
Binnen de sociale zekerheid is er een proces ingesteld om de wettelijke- en veiligheidsaspecten te controleren bij inproductiestelling van een toepassing. Deze validatie wordt geformaliseerd in een ‘Uniek Dossier (wettelijke aspecten bij het in productie brengen van een nieuwe toepassing)‘. Dit dossier centraliseert de noodzakelijke informatie om de systeembeheerders van de sociale zekerheid toe te laten om een toepassing in productie te stellen in overeenstemming met de regelgeving in verband met de informatieveiligheid en de beveiliging van gegevens. Dit dossier wordt opgesteld wanneer de verantwoordelijke voor de behandeling van de gegevens niet de enige eigenaar is van die gegevens.. 4.2.5.
Toelatingen Kruispuntbank van de Sociale Zekerheid
Indien elektronische diensten (vb. web services) gebruikt worden van de KSZ, moet hiervoor tijdig de toelating gevraagd worden.
4.3. Minimale Veiligheidsnormen De volgende punten worden opgelegd door de minimale normen inzake informatieveiligheid van de Sociale Zekerheid zoals vastgelegd door het Sectoraal Comité van de Sociale Zekerheid en de Gezondheid. 4.3.1.
Uitbesteding aan derden
Bij uitbesteding van ICT activiteiten,wordt extra aandacht besteed aan beveiligingsrisico’s. Het is belangrijk de beveiligingsaspecten contractueel vast te leggen (ISP). Vertrouwelijkheids- en continuïteitsclausules moeten voorzien worden. 4.3.2.
Communicatie
Een efficiënte en constructieve communicatie tussen de verschillende bij het project betrokken partijen (inclusief klanten en leveranciers)moet opgezet worden, in het bijzonder met de veiligheidsconsulent(en). Dit moet een adequaat veiligheidniveau garanderen gekend door iedereen. Deze communicatie laat toe de principe respecteren zoals beschreven in het kader van het Information Security Management System (ISMS), op basis van de Information Security Policy (ISP).
P4
Check-list informatieveiligheid bij projektontwikkeling Information Security Policy Versie 2.00
03/11/20101
De betrokkenen worden eveneens gewezen op hun persoonlijke verantwoordelijkheden zoals beschreven in de ISP en o.a. in de “Gedragscode voor de informatiebeheerders” of in een deontologische code inherent aan hun specifieke functie: •
de beperking van inzage van vertrouwelijke gegevens voor louter beroepsdoeleinden
•
de geheimhouding van vertrouwelijke gegevens. 4.3.3.
Toegangsbeheer
Alle medewerkers en in het bijzonder externe medewerkers (bijv. consultants) die werken met ICT middelen die door de instelling ter beschikking worden gesteld, doen dit op basis van minimale authorisaties voor de uitvoering van hun taak. Bij het ontwikkelen van de toegangsbeveiliging is het belangrijk rekening te houden met de reeds bestaande operationele systemen voor het toegangsbeheer (bijvoorbeeld het toegangsbeheerssysteem UAM) en hun evolutie. Het gebruik van deze systemen garandeert de onafhankelijkheid tussen dit beheerssysteem en het ontwikkelde systeem. Vereisten voor toegangsbeveiliging (identificatie, authentificatie, authorisatie) worden gedefinieerd en gedocumenteerd (ISP). Deze toegangsbeveiliging (bijv. aard van authenticatiemiddel) zal verschillen naargelang de toepassing (vb.graad van vertrouwelijkheid van behandelde gegevens) en van de bedreiging (vb.toegang via publieke netwerken) op basis van een risico analyse. Deze toegangen zullen gelogd worden. (zie paragraaf 4.3.7. Logging). (minimumnorm) Er moet rekening gehouden worden met de granulariteit (fijnkorreligheid) van de toegang tot de gegevens. In het kader van een toepassing moeten verschillende gebruikersgroepen verschillende rechten (vb. lezen, schrijven, wijzigen) kunnen hebben met betrekking tot gegevens met verschillende vertrouwelijkheidsgraad. Het beheer van de toegangen, intern in een applicatie, moet zo veel mogelijk vermeden worden. In uitzonderlijk voorkomend geval moeten formele procedures bestaan om alle fases in de levenscyclus van de toegangsbeveiliging te beheren (invoer, controle op basis van een inventaris, mutatie, schrapping) (ISP). Wanneer een programma ontwikkeld wordt waarin de socialezekerheidsinstelling een programmanummer overneemt in een bericht dat ze aan de Kruispuntbank richt, maar een natuurlijk persoon aan de basis van dit bericht ligt, moet deze instelling in staat zijn zelf de relatie te leggen tussen dit programmanummer en de identiteit van de natuurlijke persoon die het bericht verstuurt (minimumnorm). 4.3.4.
Checklist
Op basis van het geheel van aanbevelingen zoals voorgesteld in dit document, dient de projectleider een controlelijst te voorzien. Op deze basis kan hij zich vergewissen dat het geheel van deze aanbevelingen correct geëvalueerd en indien noodzakelijk geïmplementeerd worden tijdens de ontwikkelingsfase van het project. 4.3.5.
Controle voor in productiestelling
Bij de inproductiestelling van het project, moet de verantwoordelijke van de opvolging, project leider, zich vergewissen dat de veiligheidseisen die bij het begin van het project werden vastgelegd ook daadwerkelijk geïmplementeerd werden. 4.3.6.
Gestructureerde aanpak
Voorzieningen voor ontwikkeling, test en/of acceptatie en productie worden gescheiden (ISP) – inclusief de bijhorende scheiding der verantwoordelijkheden in het kader van het project. Dit alles gebeurt onder de supervisie van een enkele verantwoordelijke: de projectleider.
P5
Check-list informatieveiligheid bij projektontwikkeling Information Security Policy Versie 2.00
4.3.7.
03/11/20101
Logging
Elke toegang tot persoonlijke en vertrouwelijke gegevens die sociaal of medisch van aard zijn, moet gelogd worden in overeenstemming met de minimale normen, de logging policy (ISMS 026) en de toepasselijke regelgeving. In de specificaties van een project dient opgenomen te worden hoe de toegang tot en het gebruik van systemen en applicaties gelogd moet worden om bij te dragen tot de detectie van afwijkingen van het veiligheidsbeleid (ISP) zoals het toegangsbeleid of de detectie van anomalieën (ISP). Deze logging moet bijvoorbeeld beantwoorden aan de volgende objectieven : •
De verplichting om te kunnen bepalen wie, wanneer en op welke manier toegang heeft verkregen tot welke gegevens
•
De identificatie van de persoon verantwoordelijk voor een misdrijf
•
De identificatie van de aard van de geraadpleegde informatie
•
…
Er moet rekening gehouden worden met reeds bestaande loggingsystemen bij de evaluatie van loggingbehoeften in het kader van het project. Dit om te vermijden dat er per project een specifiek loggingsysteem ontwikkeld wordt. Zo wordt ook de onafhankelijkheid tussen het loggingsysteem en het project gegarandeerd. De noodzakelijke tools moeten beschikbaar zijn of ontwikkeld worden om toe te laten deze logging gegevens uit te baten door de geauthoriseerde personen. De algemene regel is dat de logging gegevens minstens 10 jaar moeten bewaard blijven. De vereisten inzake logging in verband met andere dan veiligheidsgegevens (ook gekend onder de benaming van technische logging of functionele logging) moeten eveneens nagegaan worden. 4.3.8.
Back-up
De projectleider moet er zich van vergewissen dat zijn project geïntegreerd kan worden in het backup beheersysteem van de instelling zoals opgelegd in de minimale normen. Dit omvat niet alleen de gegevens die verwerkt worden maar ook de documentatie die hierop betrekking heeft (sources, programma’s, technische documenten, …) 4.3.9.
Continuïteitsbeheer
In de loop van de ontwikkeling van het project moeten de behoeften met betrekking tot continuïteit van de dienstverlening geformaliseerd worden, conform met de strategie van de instelling. De volgende punten moeten verplicht nageleefd worden : •
In de programma’s moeten de te definiëren herstartpunten duidelijk geïntegreerd worden om het hoofd te bieden aan operationele problemen. Deze informatie maakt deel uit van het exploitatie dossier.
•
Tijdens de ontwikkeling van een project moet bijzondere aandacht besteed worden aan de verplichte back-ups en hun kwaliteit
•
In de productie omgeving moet rekening gehouden worden met de eisen van de instelling met betrekking tot probleemtolerantie en redundantie van de infratstructuur
•
Het continuïteitsplan en de bijhorende procedures moeten geactualiseerd worden in functie van de projectevolutie, met inbegrip van continuïteitstesten
In functie van de risico analyse die in het begin van het project werd uitgevoerd moeten noodprocedures gedefinieerd worden. Deze bevatten onder andere : P6
Check-list informatieveiligheid bij projektontwikkeling Information Security Policy Versie 2.00
03/11/20101
•
De werking bij verminderde beschikbaarheid van informatie systemen
•
De beschrijving van alternatieve informatie systemen met inbegrip van de uitrol, de exploitatie modaliteiten en de eventuele ontwikkeling van noodsystemen
•
De bedrijfsprocedures in geval van systeemonderbreking
•
De taken, de sleutelrollen en de in te zetten middelen om tot een optimale beschikbaarheid te komen. 4.3.10. Incidentenbeheer
In de loop van de ontwikkeling van het project moeten de procedures met betrekking tot het incidentbeheer geformaliseerd worden. Dit moet toelaten het ontwikkelde systeem te integreren in het standaard incident beheerssyteem van de instelling. De veiligheidsconsulent moet op de hoogte gesteld worden van de veiligheidsincidenten. 4.3.11. Documentatie Tijdens de levensloop van het project moet de documentatie (technisch, procedures, handleidingen, …) actueel gehouden worden. 4.3.12. Inventaris Alle bedrijfsmiddelen inclusief aangekochte of ontwikkelde systemen zullen toegevoegd worden aan het beheerssysteem van de bedrijfsmiddelen. 4.3.13. Audit Voor interne en externe audit van zal de gepaste medewerking verleend worden onder de vorm van het ter beschikking stellen van personeel, documentatie, loggings en andere informatie die redelijkerwijze beschikbaar is.
4.4. Project Life Cycle 4.4.1.
Initiatie
Zoals alle projectvereisten zullen ook de veiligheidsvereisten met de opdrachtgever besproken en vastgelegd worden vanaf het begin van het project. De veiligheidsconsulent(en) van de opdrachtgever(s) en de betrokken instelling(en) moet(en) hierin betrokken worden. 4.4.2.
Planning
In de planning van het project moet rekening gehouden worden met de nodige tijd en middelen om ook de veiligheidsaspecten te verwezenlijken. Het omzeilen van de veiligheidsrichtlijnen, om andere projectaspecten (bijvoorbeeld uit tijdsnood) te bevoordeligen, dient vermeden te worden en moet geargumenteerd en formeel bevestigd worden op basis van een risico analyse. Alle afwijkingen moeten gevolgd worden door verbeteringsmaatregelen om de oorspronkelijke veiligheidsdoelstellingen te behalen.
P7
Check-list informatieveiligheid bij projektontwikkeling Information Security Policy Versie 2.00
4.4.3. A.
03/11/20101
Realisatie Ontwikkeling en test
Bij de ontwikkeling en test dient rekening gehouden te worden met zwakke punten die kunnen uitgebaat worden om applicaties te compromitteren. Een opleidingsprogramma, aangepast aan de verschillende verantwoordelijkheden, moet bestaan om met name de risico’s in verband met web toepassingen te verduidelijken en de tegenmaatregelen toe te lichten. Het is dan ook van het grootste belang te verifiëren dat medewerkers de nodige opleiding krijgen om zich bewust te zijn van de bedreigingen voor en het belang van informatiebeveiliging en om de juiste middelen, kennis en vaardigheden tot hun beschikking te hebben om de systemen hiertegen te wapenen (ISP). De toewijzing van speciale, kritieke rollen/rechten tijdens de ontwikkelingsfase (vb. voor het beheer van softwareversies ) worden beperkt en het gebruik ervan gecontroleerd (ISP). •
Authentificatiemethodes (vb.wachtwoorden) en authorisatieniveaus (vb. administrator) worden beheerd aan de hand van een formeel proces (ISP).
•
Medewerkers worden gewezen op hun verantwoordelijkheid voor het handhaven van een effectieve toegangsbeveiliging, met name met betrekking tot het gebruik van wachtwoorden en beveiliging van gebruikersapparatuur (ISP).
Bij de ontwikkeling van systemen dient bijzondere aandacht besteed te worden aan de integriteit van de gegevens, bijvoorbeeld door de validatie van invoergegevens, de beveiliging van interne verwerking en de validatie van uitvoergegevens. Audit trails dienen ingebouwd te worden. (ISP) Bij de ontwikkeling van systemen wordt rekening gehouden met gekende zwakke punten op gebied van veiligheid, eigen aan programmeertalen. Het nazicht van software door andere partijen dan de ontwikkelaars is een methode om deze risico’s in te perken (ISP). Indien dit gebeurt door een externe partij, dient de deontologie van deze partij nagegaan te worden. Tijdens de ontwikkeling wordt de integriteit en consistentie van software gewaarborgd door een op procedures gebaseerd beheer van de softwareversies en de toegangsbeveiliging voor softwarebibliotheken (ISP). Maximale maatregelen worden genomen om te vermijden dat geheime communicatiekanalen (“covert channels”)1 en Trojaanse Paarden2 in ontwikkelde software verborgen worden (ISP). Met het oog op het continuïteitsbeheer, worden de programma’s opgebouwd met duidelijk afgebakende herstartpunten in het geval van operationele problemen. Toegang tot en gebruik van systemen wordt gemonitord om afwijkingen van het toegangsbeleid of anomalieën te detecteren (ISP) (minimumnorm,). De uitwerking van documentatie bij de ontwikkeling van nieuwe en het onderhoud van bestaande systemen wordt formeel opgelegd (minimumnorm, ). De uitwerking door de projectleider van een functionele en technische cartografie. Elk van deze cartografieën beschrijft tot op het gepaste niveau de verschillende gegevensstromen, de verschillende relevante elementen (servers, …) en hun rol in het project (applicatie-servers, databank,, ..),
1
Deze geheime communicatiekanalen laten toe dat deze software achteraf, via deze kanalen, kan gebruikt worden voor oneigenlijke doeleinden. 2
Trojaanse Paarden is de algemene term die gebruikt wordt voor een ongeoorloofde deelsoftware die de geoorloofde software (waarin deze deelsoftware verborgen wordt) andere functies laat uitoefenen dan deze waarvoor deze geoorloofde software oorspronkelijk bedoeld is. P8
Check-list informatieveiligheid bij projektontwikkeling Information Security Policy Versie 2.00
03/11/20101
Er dient zorgvuldig omgegaan te worden met testgegevens zodat geen gevaar bestaat op compromittering van vertrouwelijke gegevens (ISP). Voor ontwikkelingsdoeleinden mag alleen toegang gegeven worden tot daartoe bestemde testgegevens. (ISP). B.
In productie stelling
In dit stadium, zouden volgende aspecten met de personen verantwoordelijk voor inproductiestelling en exploitatie moeten behandeld, geanalyseerd en gevalideerd zijn, in overeenstemming met de eisen van de gebruikers. •
Het aanduiden van een medewerker met de rol van “Application Owner” die verantwoordelijk is voor het ontwikkelde systeem (evolutie, documentatie, aanspreekpunt, …).
•
De levering door de projectleider van een definitieve versie van de functionele en technische cartografie (as built). Deze documenten laten de systeembeheerders (netwerkbeheerders, DBA, …) toe hun eigen cartografie actueel te houden.
•
Overeenstemming van het project en de bijhorende gegevensstromen met de machtigingen afgeleverd door het Sectoraal Comité.
•
Overeenstemming van het project met de continuïteitseisen zoals gespecifieerd
•
Beschikbaarheid van documentatie en handboeken (o.a. het productiedossier).
•
Definitie van te archiveren gegevens, het opslagmedium, de bewaartermijnen, eventuele encryptie
•
Het respecteren van de veiligheidseisen in productie (confidentialiteit, integriteit, beschikbaarheid, bewijskracht), . Bij voorbeeld : •
Met de afdeling verantwoordelijk voor de productie en de veiligheidsconsulent moeten de middelen voorzien worden om de logging gegevens op te slaan en uit te baten (zie paragraaf 4.3.7. Logging).
De middelen om de door de klant bepaalde archivering uit te voeren dienen voorbereid te worden. Bijzondere aandacht dient gewijd aan de definitie welke gegevens moeten gearchiveerd worden, het opslagmedium, de bewaartermijnen, eventuele encryptie … Opmerking : met het oog op de naleving van de wettelijke bepalingen op de bewaring en het gebruik van gearchiveerde gegevens, moet bij elke evolutie van de informatica infrastructuur en het informatiesysteem die een weerslag kan hebben op de archivering, nagegaan worden of de gearchiveerde gegevens, de opslagmedia en de noodzakelijke applicaties nodig voor hun exploitatie, op elkaar afgestemd blijven. Daarenboven moeten, in voorkomend geval, de methodes zoals beschreven in het bewijskracht dossier strikt en blijvend gerespecteerd worden. Voor de goedkeuring tot het in productie stellen van een toepassing op het portaal van de Sociale Zekerheid dient een specifieke procedure van de KSZ gevolgd te worden (uniek dossier). De nodige middelen en competenties moeten ter beschikking staan om dringend in te grijpen in geval van moeilijkheden in de productiefase.
4.4.4.
Afsluiting
De projectverantwoordelijke, de verantwoordelijke voor de behandeling van de gegevens en de verantwoordelijke voor de gegevensverwerking moeten er samen over waken , dat het opgeleverde systeem in overeenkomst is met de toegekende machtiging (o.a. de te openen fluxen).
P9
