Grip op Secure Software Development/Inleiding

Uit NORA Online
Naar navigatie springen Naar zoeken springen
”Dit plaatje duidt aan dat de pagina's met betrekking tot deze Thema-uitwerking in bewerking zijn”
Deze Thema-uitwerking is in onderhoud
Thema-uitwerking Grip op Secure Software Development is in onderhoud, zolang er bij de status Concept staat.
Versie 3.0 van deze Thema-uitwerking van 20 juli 2020 wordt namelijk op dit moment voor het eerst opgevoerd.

Versie 3.0 maar ook versie 2.0 in PDF-formaat is op de website CIP-overheid/producten gepubliceerd.

Logo ISOR (vier hangsloten die in elkaar geklikt zitten met de tekst Information Security Object Repository)

Deze thema-uitwerking beschrijft voor organisaties de belangrijkste beveiligingseisen die van toepassing zijn bij de ontwikkeling en aanschaf van applicaties. Samen met het document "Grip op SSD – de methode", waarin de aanpak "hoe grip erop te krijgen" is beschreven, wordt met de eisen de opdrachtgever een oplossing geboden om tot veilige software te komen. De eisen beperken zich daarvoor tot de applicatielaag van een systeem. Beveiligingseisen die gesteld worden aan bijvoorbeeld de infrastructuur, de werkplek of het personeel zijn niet meegenomen. Hiervoor kunnen bestaande frameworks voor informatiebeveiliging gebruikt worden, zoals ISO 27002.
Om blijvend de belangrijkste bedreigingen te kunnen afdekken is het van belang dat onderhoud op de lijst plaatsvindt. De lijst is en wordt daarom samen door opdrachtgevers en de leveranciers die software ontwikkelen actueel gehouden.
Door het hanteren van juist een beperkte lijst is voorkomen dat er een overkill aan eisen is ontstaan. Zodoende is een goede governance mogelijk geworden. De wijze waarop governance mogelijk wordt is in de methode 'Grip op SSD' aangegeven.

Verwijzingen naar internetpagina's zijn klikbaar in PDF versies van deze thema-uitwerking. Voor afgedrukte versies kan in plaats van klikken worden gezocht op de zoektermen bij de link.

Scope: web- en backend-applicaties

Wanneer deze thema-uitwerking spreekt over een applicatie gaat het om een applicatie die bereikbaar is via een webbrowser of via een andere cliënt (bijvoorbeeld een mobiele of desktop applicatie). Kenmerkend is HTTP als communicatie-protocol en de versleutelde variant HTTPS. Applicaties kunnen ook opengesteld worden via een vooraf afgesproken interface (API). Voor mobiele applicaties zijn aparte SSD-mobile normen beschikbaar. Deze publicatie is samen met andere Centrum Informatiebeveiliging en Privacybescherming (CIP) publicaties (zoals de SSD-Methode) te vinden op www.cip-overheid.nl

Per eis is weergegeven voor wat voor soort software deze toepasselijk is. Veel van de eisen zijn van toepassing voor software in het algemeen.

Comply or Explain

Ten aanzien van de gestelde beveiligingseisen geldt het principe 'pas toe of leg uit'. Een maatregel behorende bij een beveiligingseis is niet van toepassing, indien kan worden aangetoond dat:

  • op basis van een risicoanalyse de maatregel niet in verhouding staat tot de te maken kosten;
  • de overige geïmplementeerde maatregelen het aan de eis ten grondslag liggende risico tot een acceptabel niveau hebben beperkt.

Belangrijk is steeds dat de genomen maatregelen en de risico's die geaccepteerd worden steeds inzichtelijk zijn en aansluiten op de "risk appetite" van de opdrachtgever en dus bewaakt wordt in een governance proces.
De in deze thema-uitwerking beschreven beveiligingseisen zijn een handreiking (best practice) en geven aan hoe de maatregel ingevuld zou kunnen worden. Afhankelijk van de situatie kunnen mogelijk alternatieve maatregelen beter op hun plaats zijn. De voorgestelde exacte maatregelen zijn daarom op zichzelf geen harde vereiste. Wel moeten steeds de bij de eisen genoemde risico's zijn afgedekt.

De betrokken partijen

Bij de beveiligingseisen zijn de volgende rollen omschreven:

  • De opdrachtgever voor een applicatie;
  • De softwaremaker: een interne of externe softwareleverancier die het ontwerp, de ontwikkeling, het testen en vaak ook het implementeren verzorgt;
  • De hostingpartij, die voor de productie en het technisch beheer zorgt;
  • De ontvangende partij, namelijk de gebruikersorganisatie die de applicatie in gebruik neemt en voor het functioneel beheer zorgt. Veelal is dit de opdrachtgever, daarom is bij de normen niet het onderscheid ontvangende partij en opdrachtgever aangehouden.


Het uitgangspunt is, dat de hostingpartij zorgt voor een omgeving die "secure bij default" is. Dat betekent dat de installatie van operating system, services, security software en/of appliances, etc., plaatsvindt volgens de functionele en beveiligingsinstructies van de producenten van die hard- en software. De hostingprovider zorgt er eveneens voor dat patches in de omgeving worden geïnstalleerd.

Om te waarborgen dat de applicatie naar behoren functioneert en daarbij zo veilig mogelijk is, legt de softwaremaker in de configuratiebeschrijving uit wat nodig is om de applicatie goed en veilig te laten functioneren. De softwaremaker beschrijft welke poorten, protocollen, connecties, diensten, authorisaties etc., door de omgeving ondersteund moeten worden. Ook legt de softwaremaker uit hoe de applicatie gehardend moet worden, zonder dat de functionaliteit van de toepassing in gevaar komt.