ISOR/totaaltabel

Tabel met alle elementen in het normenkader Grip_op_Secure_Software_Development.
Een element kan zijn: Beveiligingsprincipe, Hoofdstuk normenkader, Norm, Normenkader, Normenkader-aspect, Privacyprincipe
Tip: klik op het pijltje naast 'ID' voor een logische volgorde.

ID	ElementtypeDeze speciale eigenschap maakt deel uit van SmartCore. Gebruik deze eigenschap niet voor andere doeleinden.	Versieaanduiding	Status actualiteit	Redactionele wijzigingsdatum	Publicatiedatum	Beschrijving	Toelichting	Conformiteitsindicator	Criterium	Doelstelling	Risico	Beveiligingsaspect	Invalshoek	Grondslag	Stelling	Grondslag opmerkingen	Realiseert	Afbeelding	Onderschrift	Px	Alt-tekst	Wijzigingsdatum“Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>” is een voorgedefinieerde eigenschap die overeenkomt met de datum van de laatste wijziging van een onderwerp. Deze eigenschap wordt geleverd door Semantic MediaWiki.
SSD_INL SB	Hoofdstuk normenkader	3.0	Concept	26 augustus 2022	20 juli 2020	ISO/IEC 25010:2011 is dé standaard voor softwarekwaliteit en definieert beveiliging op een technologie-onafhankelijke manier. Het is de basis van het SIG beveiligingsmodel volgens welke de SSD beveiligingseisen zijn gestructureerd. Dit model harmoniseert bestaande standaarden in een uniform en logisch overzicht van verantwoordelijkheden, zodat duidelijk is wat geregeld moet worden bij het maken van afspraken, bij implementatie en bij toetsing. In ISO/IEC 25010 bestaat beveiliging uit vijf kenmerken: Vertrouwelijkheid: gegevens zijn alleen toegankelijk voor geautoriseerden. Integriteit: aanpassing van computerprogramma's of gegevens alleen voor geautoriseerden. Onweerlegbaarheid: er kan worden bewezen dat acties of gebeurtenissen hebben plaatsgevonden. Verantwoording: acties van een entiteit kunnen uniek worden getraceerd. Authenticiteit: de identiteit van een onderwerp of bron kan worden aangetoond als degene die wordt geclaimd. De vijf kenmerken zijn door middel van onderstaand model elk gerelateerd aan een aantal verantwoordelijkheden voor software-ontwikkeling en -beheer. Merk op dat 'beschikbaarheid' (availability) in twee delen is gesplitst in ISO/IEC 25010: een deel dat valt onder de softwarekwaliteit 'betrouwbaarheid' (door maatregelen voornamelijk buiten de software: anti-ddos, dubbele uitvoering, etc.), en een deel dat valt onder 'Integriteit' (zoals verificatie van invoer en uitvoer om 'denial of service' te voorkomen). Hoe de verantwoordelijkheden een rol spelen in veilige software Een applicatie zorgt dat functies en gegevens alleen toegankelijk zijn voor diegenen die daarvoor goedkeuring hebben op de manier dat de applicatie bedoeld is. Voordat het systeem aan de vragen van gebruikers voldoet, voert het eerst Toegangscontrole uit.  Dit bestaat uit: Authenticatie: zekerheid dat een identificatie deugt en Autorisatie: controle per actie dat die geoorloofd is voor die specifieke gebruiker. Sessiebeheer: sessies voorkomen dat een gebruiker zich voor elke actie opnieuw moet identificeren. Sessies vertegenwoordigen de identiteit van de gebruiker en dit moet dan ook deugdelijk verlopen. In elk systeem vinden logische stappen plaats van gegevens die in- en uitvloeien. In die logische verwerking hoort het systeem alle invoer en uitvoer te controleren: dit is het domein van Invoer- en uitvoer validatie. Om uiteindelijk deugdelijke werking te kunnen aantonen (tijdens en achteraf), is Logging nodig. Voor en na verwerking van gegevens worden die gegevens getransporteerd en opgeslagen. De communicatie tussen gebruiker en systeem en met andere systemen hoort beschermd te zijn zodat er niet met de communicatie geknoeid kan worden. Het systeem forceert daarvoor veilige Datacommunicatie. Ook (tijdelijk) bewaarde gegevens horen weerstand te bieden tegen onderschepping of wijziging met veilige Dataopslag. Rondom het systeem bestaat een 'operatieschil', grofweg te scheiden in techniek (Infrastructuur) en proces (Gebruikersbeheer, Externe componenten etc.). Tot slot is er een aantal architectuurprincipes die bijdragen aan een veilige applicatie. De structuur van de verantwoordelijkheden helpt om te bepalen op welk moment een bepaalde eis van toepassing is; afhankelijk van het type ontwikkelwerk of testactiviteit. Op deze manier hoeven alleen de van toepassing zijnde SSD normen per moment worden meegenomen. Hiervoor zijn per SSD-eis zogenaamde triggers gespecificeerd: een omschrijving van de situatie waarin de eis van toepassing is.																26 augustus 2022 10:50:12	Grip op Secure Software Development/Structuur beveiligingseisen
SSD_TOEL W2	Hoofdstuk normenkader	3.0	Actueel	2 augustus 2022	9 augustus 2022	Hieronder volgt een overzicht van de belangrijkste wijzigingen die in deze versie (3.0) van Grip op SSD Beveiligingseisen zijn doorgevoerd. De oude versie (2.0) blijft nog beschikbaar op de site www.cip-overheid.nl voor organisaties die op basis daarvan nog lopende afspraken hebben. Overzicht van de wijzigingen Honderden verbeteringen en verduidelijkingen in tekst: Verzamelde input van de community is verwerkt. Reviews door de werkgroepleden. Meer duidelijke teksten. SSD-2 is bijvoorbeeld van titel veranderd naar "Veilige gegevensopslag" omdat het eigenlijk daarover ging. SSD-3 is om dezelfde reden van titel veranderd naar "Veilige externe componenten". Meer opgesteld als samenhangende gids: De normen waren eerder willekeurig geordend. In v3.0 zijn de normen gestructureerd naar verantwoordelijkheden en ook zo benoemd, zodat het document de lezer meer aan de hand neemt hoe de verschillende verantwoordelijkheden worden ingevuld. Per norm is beschreven in welke situaties de norm van toepassing is. Per eis zijn een aantal klikbare verwijzingen opgenomen naar praktische handreikingen/details. Gapanalyse is uitgevoerd met OWASP ASVS en enkele zaken zijn aangevuld. Up to date gebracht met onder meer nieuwe ISO27002- en NCSC-richtlijnen. Verwijzingen zijn aangebracht. SSD-6 (interne gebruikers) is opgegaan in SSD-5 die nu gaat over alle gebruikers. SSD-10 Concurrent Session Control is vervallen. SSD-12A Session lock Vervalt als eis (staat geheel los van de applicatie). SSD-11: System use notification is verwijderd. Dit is slechts in speciale gevallen een criterium - die dan typisch al onderdeel uitmaakt van de functionele eisen. SSD-18 is vervallen vanwege duplicatie in onder meer SSD-22. SSD-25 Beperken van te tonen headers is opgenomen in SSD-24 Beperken van te sturen headers. SSD-32 is nieuw en bevat alle normen voor het configureren van HTTP response headers. Eerder stond dat overal verspreid. SSD-33 (XML injectie) toegevoegd omdat deze ook in de SSD-mobiele eisen staat en in de laatste versie van de OWASP top 10 wordt genoemd omdat het een veel voorkomend issue is.																9 augustus 2022 08:40:31	Grip op Secure Software Development/Wijzigingen ten opzichte van de versie 2
	Hoofdstuk normenkader		Concept	29 juli 2022	20 juli 2020																	29 juli 2022 08:23:19	Grip op Secure Software Development/Voorwoord en leeswijzer
SSD_INL	Hoofdstuk normenkader	3.0	Actueel	5 augustus 2022	20 juli 2020	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.																5 augustus 2022 08:31:03	Grip op Secure Software Development/Inleiding
SSD_INL UOB	Hoofdstuk normenkader	3.0	Concept	22 juli 2022	20 juli 2020																	22 juli 2022 07:44:10	Grip op Secure Software Development/Uitleg van de opzet van de beveiligingseisen

De mate waarin de organisatie zich voor de informatievoorziening kan verlaten op een informatiesysteem. De betrouwbaarheid van een informatiesysteem is daarmee de verzamelterm voor de begrippen beschikbaarheid, integriteit en vertrouwelijkheid.

De mate waarin de organisatie zich voor de informatievoorziening kan verlaten op een informatiesysteem. De betrouwbaarheid van een informatiesysteem is daarmee de verzamelterm voor de begrippen beschikbaarheid, integriteit en vertrouwelijkheid.

Het bekend maken van de identiteit van personen, organisaties of IT-voorzieningen.

Iedere persoon, organisatie of functionele eenheid die gebruik maakt van een informatiesysteem

Het proces van vaststellen van de vereiste betrouwbaarheid van informatiesystemen in termen van vertrouwelijkheid, beschikbaarheid en integriteit alsmede het treffen, onderhouden en controleren van een samenhangend pakket van bijbehorende maatregelen.