5.3.2. Minimale maatregelen voor ontwikkeling en beheer van toepassingen 3.0

PAS TOE

• Implementatie van een SDLC (System Development Lifecycle), inclusief beveiligingsoverwegingen (CyFun PR.IP-2.1): 

  • Planning, 

  • Behoefteanalyse, 

  • Ontwerp, 

  • Ontwikkeling, 

  • Testen, 

  • Implementatie, 

  • Onderhoud. 

• Uitvoeren van een risicoanalyse op nieuwe versie van een toepassing

• Werken volgens de “security by design” en “privacy by design” principes

• Kosten-baten-analyse

• Het uitvoeren van Veiligheidstesten

• Het uitvoeren van Security Monitoring-activiteiten, cf. 5.2. Minimale maatregelen - logging en monitoring (SIEM) 3.0

• Ondersteuning van de toepassing en haar onderliggende componenten, cf. 4.7. Minimale maatregelen - Release- en deploymentbeheer

• Scheiding van ontwikkel-, test-, en productieomgeving (CyFun PR.DS-7) 

Alle maatregelen van Klasse 1 +

• Input validatie (manueel en automatisch)

• Output validatie op statische en niet-statische data

• Output validatie: controle op inputvelden

Alle maatregelen van Klasse 1 + Klasse 2 +

• Expliciete garantie op betrouwbaarheid van de informatiebronnen

• Output validatie: controle op inputvelden via bijvoorbeeld “4-ogen-principe”

• Monitoring van ongeoorloofde wijzingen aan data

• Output verificatie door ontvangende toepassing/proces  

• Testgegevens uit productie anonimiseren of vertrouwelijkheid beveiligen.

PAS TOE OF LEG UIT

Alle maatregelen van Klasse 1 + Klasse 2 + Klasse 3 +

• Geen bijkomende maatregelen zijn gedefinieerd

• De uitvoering en thresholding ervan kan wel verschillen, gelet op de potentieel grotere impact van een gebrek aan integriteit 

• Testgegevens anonimiseren of cryptografische maatregelen voor vertrouwelijkheid toepassen

Alle maatregelen van Klasse 1 + Klasse 2 + Klasse 3 + Klasse 4 +

• Het ontwikkelingsproces voor kritieke systemen en systeemcomponenten moet de volledige ontwerpcyclus omvatten en voorziet in een beschrijving van de functionele eigenschappen van veiligheidscontroles, en in ontwerp- en uitvoeringsinformatie voor veiligheidsrelevante systeeminterfaces (CyFun PR.IP-2.1); 

• Geen bijkomende maatregelen zijn gedefinieerd;

• De uitvoering en thresholding ervan kan wel verschillen, gelet op de potentieel grotere impact van een gebrek aan integriteit;

• Testgegevens uit productie altijd anonimiseren.

Klasse 1 t/m Klasse 5 kennen dezelfde maatregelen: 

• Logbeheer moet meegenomen worden vanaf het design tijdens de ontwikkeling of bij de bepalingen van aankoopcriteria van toepassingen of systemen om “security/privacy by design” te realiseren (Ref. KSZ 5.9.5). 

• Elke organisatie moet een efficiënte en constructieve communicatie opzetten tussen de verschillende bij het project betrokken partijen (inclusief klanten en leveranciers), in het bijzonder met de veiligheidsconsulent(en). Dit moet een adequaat niveau van informatieveiligheid en privacy garanderen gekend door iedereen (Ref. KSZ 5.11.1). 

• Wanneer een programma ontwikkeld wordt waarin de sociale zekerheidsinstelling een programmanummer overneemt in een bericht dat ze aan de KSZ richt, maar een natuurlijk persoon aan de basis van dit bericht ligt, in staat zijn zelf de relatie te leggen tussen dit programmanummer en de identiteit van de natuurlijke persoon die het bericht verstuurt (Ref. KSZ 5.11.2). 

• Elke organisatie dient altijd een controlelijst te voorzien voor de projectleider zodat de projectleider er zich kan van vergewissen dat het geheel van de beleidslijnen informatieveiligheid en privacy correct geëvalueerd en indien noodzakelijk geïmplementeerd worden tijdens de ontwikkelingsfase van het project (Ref. KSZ 5.11.4). 

• Elke organisatie moet zich via de verantwoordelijke van de opvolging, de project leider, en bij de in productiestelling van het project er van vergewissen dat de veiligheids- en privacy-vereisten die bij het begin van het project werden vastgelegd ook daadwerkelijk geïmplementeerd werden. (Ref. KSZ 5.11.5). 

• Elke organisatie moet onder de supervisie van de projectleider de voorzieningen voor ontwikkeling, test en/of acceptatie en productie scheiden – inclusief de bijhorende scheiding der verantwoordelijkheden in het kader van het project. (Ref. KSZ 5.11.6). 

• Elke organisatie moet: 

  • a) Elke toegang tot persoonlijke en vertrouwelijke gegevens die sociaal of medisch van aard zijn, loggen in overeenstemming met de beleidslijnen “logging” en de toepasselijke wetgeving en regelgeving.  

  • b) In de specificaties van een project opnemen hoe de toegang tot en het gebruik van systemen en applicaties gelogd zal worden om bij te dragen tot de detectie van afwijkingen van de beleidslijnen informatieveiligheid en privacy. Het logbeheer moet minimaal beantwoorden aan de volgende doelstellingen : 

    • a. Glashelder, snel en eenvoudig kunnen bepalen wie, wanneer en op welke manier toegang heeft verkregen tot welke informatie 

    • b. De identificatie van de aard van de geraadpleegde informatie 

    • c. De duidelijke identificatie van de persoon 

  • c) rekening houden met reeds bestaande logbeheersystemen bij de evaluatie van logbehoeften in het kader van het project. 

  • d) De noodzakelijke tools ter beschikking hebben of ontwikkelen om toe te laten deze log gegevens uit te baten door de geautoriseerde personen. 

  • e) De algemene regel toepassen dat de transactionele/functionele log gegevens minimaal 10 jaar en de technische/infrastructurele log gegevens minimaal 2 jaar moeten bewaard blijven (Ref. KSZ 5.11.7). 

• Elke organisatie moet: a. In de loop van de ontwikkeling van een project de procedures met betrekking tot het incidentbeheer formaliseren en valideren. Dit moet toelaten het ontwikkelde systeem te integreren in het standaard incident beheerssysteem van de organisatie. b. ervoor zorgen dat de veiligheidsconsulent op de hoogte wordt gesteld van de veiligheids- en privacy-incidenten in de loop van de ontwikkeling van een project. (Ref. KSZ 5.11.10) 

• Elke organisatie moet de ‘secure project lifecycle’ toepassen zoals beschreven in de bijlage C van de beleidslijn ‘Aankopen, ontwerpen, ontwikkelen en onderhouden van toepassingen’(Ref. KSZ 5.11.14).  

• Bijlage C van de beleidslijn ‘Aankopen, ontwerpen, ontwikkelen en onderhouden van toepassingen’ omvat volgende stappen:  

  • Initiatie 

  • Planning 

  • Realisatie 

    • Ontwikkeling en test 

    • In productiestelling 

  • Afsluiting  

• Elke organisatie moet de nodige maatregelen treffen om de veiligheid te garanderen op toepassingsniveau teneinde eventuele informatieveiligheidsinbreuken te vermijden (vertrouwelijkheid, integriteit, beschikbaarheid) (Ref. KSZ 5.11.15). 

Klasse 1 t/m Klasse 5 kennen dezelfde maatregelen: 

• Logbeheer moet meegenomen worden vanaf het design tijdens de ontwikkeling of bij de bepalingen van aankoopcriteria van toepassingen of systemen om “security/privacy by design” te realiseren (Ref. KSZ 5.9.5). 

• Elke organisatie moet een efficiënte en constructieve communicatie opzetten tussen de verschillende bij het project betrokken partijen (inclusief klanten en leveranciers), in het bijzonder met de veiligheidsconsulent(en). Dit moet een adequaat niveau van informatieveiligheid en privacy garanderen gekend door iedereen (Ref. KSZ 5.11.1). 

• Wanneer een programma ontwikkeld wordt waarin de sociale zekerheidsinstelling een programmanummer overneemt in een bericht dat ze aan de KSZ richt, maar een natuurlijk persoon aan de basis van dit bericht ligt, in staat zijn zelf de relatie te leggen tussen dit programmanummer en de identiteit van de natuurlijke persoon die het bericht verstuurt (Ref. KSZ 5.11.2). 

• Elke organisatie dient altijd een controlelijst te voorzien voor de projectleider zodat de projectleider er zich kan van vergewissen dat het geheel van de beleidslijnen informatieveiligheid en privacy correct geëvalueerd en indien noodzakelijk geïmplementeerd worden tijdens de ontwikkelingsfase van het project (Ref. KSZ 5.11.4). 

• Elke organisatie moet zich via de verantwoordelijke van de opvolging, de project leider, en bij de in productiestelling van het project er van vergewissen dat de veiligheids- en privacy-vereisten die bij het begin van het project werden vastgelegd ook daadwerkelijk geïmplementeerd werden. (Ref. KSZ 5.11.5). 

• Elke organisatie moet onder de supervisie van de projectleider de voorzieningen voor ontwikkeling, test en/of acceptatie en productie scheiden – inclusief de bijhorende scheiding der verantwoordelijkheden in het kader van het project. (Ref. KSZ 5.11.6). 

• Elke organisatie moet: 

  • a) Elke toegang tot persoonlijke en vertrouwelijke gegevens die sociaal of medisch van aard zijn, loggen in overeenstemming met de beleidslijnen “logging” en de toepasselijke wetgeving en regelgeving.  

  • b) In de specificaties van een project opnemen hoe de toegang tot en het gebruik van systemen en applicaties gelogd zal worden om bij te dragen tot de detectie van afwijkingen van de beleidslijnen informatieveiligheid en privacy. Het logbeheer moet minimaal beantwoorden aan de volgende doelstellingen : 

    • a. Glashelder, snel en eenvoudig kunnen bepalen wie, wanneer en op welke manier toegang heeft verkregen tot welke informatie 

    • b. De identificatie van de aard van de geraadpleegde informatie 

    • c. De duidelijke identificatie van de persoon 

  • c) rekening houden met reeds bestaande logbeheersystemen bij de evaluatie van logbehoeften in het kader van het project. 

  • d) De noodzakelijke tools ter beschikking hebben of ontwikkelen om toe te laten deze log gegevens uit te baten door de geautoriseerde personen. 

  • e) De algemene regel toepassen dat de transactionele/functionele log gegevens minimaal 10 jaar en de technische/infrastructurele log gegevens minimaal 2 jaar moeten bewaard blijven (Ref. KSZ 5.11.7). 

• Elke organisatie moet de deliverables van het project integreren in het backup beheersysteem van de organisatie zoals opgelegd in de beleidslijnen. Dit omvat niet alleen de gegevens die verwerkt worden maar ook de documentatie die hierop betrekking heeft (broncode, programma’s, technische documenten, …). De backup dient regelmatig getest te worden via een herstel (“restore”) oefening om na te gaan of de informatie überhaupt wel recupereerbaar is en hoelang dergelijke herstel opdracht duurt (Ref. KSZ 5.11.8). 

• Elke organisatie moet:

  • a. In de loop van de ontwikkeling van het project de behoeften met betrekking tot continuïteit van de dienstverlening formaliseren, conform met de verwachtingen van de organisatie.  

  • b. In de programma’s de te definiëren herstartpunten duidelijk integreren om het hoofd te bieden aan operationele problemen. Deze informatie maakt deel uit van het exploitatie dossier.  

  • c. Tijdens de ontwikkeling van een project bijzondere aandacht besteden aan backup en herstel (“restore”) van informatie

  • d. In de productie omgeving rekening houden met de eisen van de instelling met betrekking tot probleemtolerantie en redundantie van de infrastructuur

  • e. Het continuïteitsplan en de bijhorende procedures actualiseren in functie van de projectevolutie, met inbegrip van continuïteitstesten  

  • f. een risico analyse in het begin van het project uitvoeren om de noodprocedures te definiëren. Deze moeten bevatten :  

    • 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 kerntaken en kernprocedures in geval van systeemonderbreking 

    • De taken, de sleutelrollen en de in te zetten middelen om tot een optimale beschikbaarheid te komen (Ref. KSZ 5.11.9). 

• Elke organisatie moet:  

  • a. In de loop van de ontwikkeling van een project de procedures met betrekking tot het incidentbeheer formaliseren en valideren. Dit moet toelaten het ontwikkelde systeem te integreren in het standaard incident beheerssysteem van de organisatie(Ref. KSZ 5.11.10). 

  • b. ervoor zorgen dat de veiligheidsconsulent op de hoogte wordt gesteld van de veiligheids- en privacy-incidenten in de loop van de ontwikkeling van een project (Ref. KSZ 5.11.10). 

• Elke organisatie moet de ‘secure project lifecycle’ toepassen zoals beschreven in de bijlage C van de beleidslijn ‘Aankopen, ontwerpen, ontwikkelen en onderhouden van toepassingen’(Ref. KSZ 5.11.14).  

• Bijlage C van de beleidslijn ‘Aankopen, ontwerpen, ontwikkelen en onderhouden van toepassingen’ omvat volgende stappen:  

  • Initiatie 

  • Planning 

  • Realisatie 

  • Ontwikkeling en test 

  • In productiestelling 

  • Afsluiting  

• Elke organisatie moet de nodige maatregelen treffen om de veiligheid te garanderen op toepassingsniveau teneinde eventuele informatieveiligheidsinbreuken te vermijden (vertrouwelijkheid, integriteit, beschikbaarheid) (Ref. KSZ 5.11.15).