From b6190d39c389a2bd12ee3f2c6c01b575495c52a6 Mon Sep 17 00:00:00 2001 From: Frank Niessink Date: Fri, 6 Dec 2024 16:18:41 +0100 Subject: [PATCH] Toegevoegd in NFE-template, paragraaf 8.1, eis 17 dat de software alleen producten gebruikt of ondersteunt waarvoor de leverancier security patches uitbrengt. Closes #113. --- Content/Templates/NFE/Template-Inhoud.md | 4 ++-- Content/Templates/PvA-Realisatiefase/Template-Inhoud.md | 2 -- Content/Wijzigingsgeschiedenis.md | 4 ++-- 3 files changed, 4 insertions(+), 6 deletions(-) diff --git a/Content/Templates/NFE/Template-Inhoud.md b/Content/Templates/NFE/Template-Inhoud.md index 4be0f223..11ed471a 100644 --- a/Content/Templates/NFE/Template-Inhoud.md +++ b/Content/Templates/NFE/Template-Inhoud.md @@ -184,9 +184,9 @@ BIO en SSD bevatten ook een aantal maatregelen ten aanzien van software en/of de | 12 | Een applicatie heeft een instelbare maximale sessieduur en een maximale duur van inactiviteit. Na deze periode wordt een sessie automatisch afgesloten, alsof de gebruiker zelf de sessie beëindigd heeft | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} | | 13 | De maximale sessieduur en maximale inactiviteit zijn door (of namens) de opdrachtgevende organisatie in te stellen. De instelbare waarden zijn per default begrenst op 10 uur (sessieduur) en 15 minuten (inactiviteit). Alleen op expliciet aangeven van de opdrachtgevede organisatie kan hiervan worden afgeweken | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} | | 14 | Applicaties maken gebruik van gangbare protocollen en cryptografische technieken, versleutelen informatie volgens de maatregelenselectie in het IB-plan en borgen de onweerlegbaarheid van daartoe aangewezen transacties via cryptografische technieken. De gebruikte cryptografische algoritmen voor versleuteling zijn als open standaard gedocumenteerd en zijn door onafhankelijke betrouwbare deskundigen getoetst. De cryptografische beveiligingsvoorzieningen en componenten voldoen aan algemeen gangbare beveiligingscriteria (zoals FIPS 140-2 en waar mogelijk NBV) | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} | -| 15 | (Web)applicatie voorkomen de mogelijkheid van dynamische file includes. Indien gebruik gemaakt wordt van een applicatieserver sluit de serverconfiguratie file includes uit. Mocht het niet mogelijk zijn aan hieraan te voldoen, dan wordt voor de includes gebruik gemaakt van een vertrouwde locatie en een expliciete whitelist voor de files | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} | +| 15 | (Web)applicaties voorkomen de mogelijkheid van dynamische file includes. Indien gebruik gemaakt wordt van een applicatieserver sluit de serverconfiguratie file includes uit. Mocht het niet mogelijk zijn aan hieraan te voldoen, dan wordt voor de includes gebruik gemaakt van een vertrouwde locatie en een expliciete whitelist voor de files | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} | | 16 | Applicaties hebben geen run-time afhankelijkheid van externe codebronnen | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} | -| 17 | Applicaties zijn gemaakt met de op het moment van uitleveren meest recente en/of door de leverancier aanbevolen versies van externe bibliotheken, raamwerken of andersoortige bouwblokken | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} | +| 17 | Applicaties zijn gemaakt met de op het moment van uitleveren meest recente en/of door de leverancier (lees in het geval van open source: de community) aanbevolen versies van externe bibliotheken, raamwerken of andersoortige bouwblokken. Applicaties gebruiken alleen externe bibliotheken, raamwerken of andersoortige bouwblokken waarvoor de leverancier beveiligingsupdates uitbrengt. Applicaties ondersteunen alleen besturingssystemen of browsers waarvoor de leverancier beveiligingsupdates uitbrengt | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} | | 18 | Een applicatie vangt interne fouten (excepties) af op hoofdniveau, zonder ongecontroleerd te falen (crash). Afgevangen fouten worden vastgelegd (log) en aan gebruikers wordt een melding getoond die geen inhoudelijke details bevat. Een betekenisloze referentie (code) van de fout ten behoeve van communicatie over de fout mag wel getoond worden | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} | | 19 | Een applicatie heeft een uniforme en veilige wijze van applicatie-logging. De logging bevat geen inloggegevens (credentials) of vertrouwelijke gegevens over personen. Referenties (bv identifiers) zijn wel toegestaan | {prio} | De logging zorgt voor traceerbaarheid van gebeurtenissen en activiteiten in relatie tot ten minste personen, systemen, applicaties en tijd | {software, hardware, combinatie} | {partij} | {bewijs} | | 20 | Een applicatie beperkt de gebruikte protocollen, parameters (headers) en functionaliteit tot wat nodig is. Hieronder vallen ook HTTP-headers en HTTP-methoden (liefst niet meer dan GET en POST): | {prio} | {rationale} | {software, hardware, combinatie} | {partij} | {bewijs} | diff --git a/Content/Templates/PvA-Realisatiefase/Template-Inhoud.md b/Content/Templates/PvA-Realisatiefase/Template-Inhoud.md index 96a96201..fa1afba7 100644 --- a/Content/Templates/PvA-Realisatiefase/Template-Inhoud.md +++ b/Content/Templates/PvA-Realisatiefase/Template-Inhoud.md @@ -95,8 +95,6 @@ Vertegenwoordigers van het project nemen deel aan de volgende overleggen met {op De realisatiefase bestaat uit {aantal} sprints. Tijdens elke sprint verwerkt het Scrumteam door de product owner geselecteerde functionaliteit in de software. Geselecteerde functionaliteit die niet afkomt tijdens de sprint kan door de product owner opnieuw geselecteerd worden voor de volgende sprint, of voor een latere sprint. Als er na afronding van de realisatiefase nieuwe wensen of fouten aan het licht komen, dan kan {opdrachtgevende organisatie} deze later alsnog verwerken of ICTU vragen dit in een eventuele vervolgopdracht uit te voeren. -Het Scrumteam controleert de software voor oplevering op beveiligingskwetsbaarheden en lost deze waar mogelijk op. Na oplevering van de software kunnen er nieuwe kwetsbaarheden worden ontdekt in de software of kunnen er oplossingen beschikbaar komen voor bekende kwetsbaarheden. Het is tot {kies: een datum, x weken na oplevering, moment van acceptie, moment van uitrol in de productieomgeving} de verantwoordelijkheid van ICTU om de opgeleverde software te controleren op beveiligingskwetsbaarheden en deze te repareren. Na dit moment is het de verantwoordelijkheid van {kies: opdrachtgevende organisatie, beheerorganisatie} om de opgeleverde software te controleren op beveiligingskwetsbaarheden en deze te repareren. - {Beschrijf hier de afspraken tussen ICTU en de opdrachtgevende organisatie over de opzet van vrijgaveadvies, release notes en goedkeuringsproces.} ## Kwaliteitsbeheersing diff --git a/Content/Wijzigingsgeschiedenis.md b/Content/Wijzigingsgeschiedenis.md index 9dcdcdb3..4270e60b 100644 --- a/Content/Wijzigingsgeschiedenis.md +++ b/Content/Wijzigingsgeschiedenis.md @@ -1,8 +1,8 @@ # Versie 4.1.0, nog niet gereleased -## Template Plan van Aanpak Realisatiefase +## Template Niet-Functionele Eisen -* In de paragraaf "Oplevering software" afspraken toegevoegd over het controleren van opgeleverde software op beveiligingskwetsbaarheden. +* Toegevoegd in paragraaf 8.1, eis 17 dat de software alleen producten gebruikt of ondersteunt waarvoor de leverancier security patches uitbrengt. # Versie 4.0.3, 6 december 2024