Grip op Secure Software Development (SSD) SIVA Beveiligingseisen. voor (web)applicaties

Grip op Secure Software Development (SSD)

SIVA Beveiligingseisen voor (web)applicaties

Versie: 1.00

Opdrachtgever Auteur Rapportnummer Classificatie Datum Filenaam

A. Reuijl CIP R. Paans Noordbeek W. Tewarie UWV M. Koers UWV UWVSSD4-2 Publiek CIP-becommentarieerde praktijk 10 januari 2014 Grip op SSD SIVA Beveiligingseisen

Tenzij anders vermeld valt dit werk onder een Creative Commons Naamsvermelding-GelijkDelen 4.0 Internationaal-licentie. Http://creativecommons.org/licenses/by-sa/4.0/

1 van 55

Secure Software Development SIVA Beveiligingseisen

Inhoud

1. Inleiding ....................................................................................................................... 4 1.1. De scope: (Web)applicaties ................................................................................ 4 1.2. De drie domeinen ................................................................................................... 5 1.3. Comply or Explain .................................................................................................. 6 1.4. De actoren ................................................................................................................. 7 1.5. Verantwoordelijkheid van de software leverancier ................................... 7 1.6. Controle en toezicht, aanpak en verantwoordelijkheden ........................ 7 2.

SIVA-syntax voor de beveiligingseisen ..................................................... 8

3. Beveiligingseisen voor de (web)applicatie ............................................. 9 3.1. Beheersbaarheid en beveiliging van de (web)applicatie ......................... 9 3.1.1. SWA-1: Risicobeheer .................................................................................... 9 3.1.2. SWA-2: Gegevensclassificatie ................................................................. 10 3.1.3. SWA-3: Functiescheiding .......................................................................... 11 3.1.4. SWA-4: Least Privilege .............................................................................. 12 3.1.5. SWA-5: Onweerlegbaarheid .................................................................... 13 3.1.6. SWA-6: (Web)applicatie logging ............................................................ 15 3.1.7. SWA-7: Borgen van Sessie Authenticiteit .......................................... 16 3.1.8. SWA-8: Concurrent Session Control .................................................... 17 3.1.9. SWA-9: Session lock................................................................................... 18 3.1.10. SWA-10: Session termination ............................................................ 19 3.2. Identificatie, authenticatie en toegangsbeheersing ................................ 20 3.2.1. SWA-11: De identiteit van een externe gebruiker vaststellen ... 20 3.2.2. SWA-12: De identiteit van een interne gebruiker vaststellen .... 21 3.2.3. SWA-13: Registreren van Unsuccessful Login Attempts .............. 22 3.2.4. SWA-14: System Use Notification ......................................................... 23 3.2.5. SWA-15: Beheerinterface ......................................................................... 24 3.3. Veilige invoer en uitvoer .................................................................................... 25 3.3.1. SWA-16: Invoer validatie ......................................................................... 25 3.3.2. SWA-17: Invoer normalisatie .................................................................. 26 3.3.3. SWA-18: Geparameteriseerde queries ................................................ 27 3.3.4. SWA-19: File includes ................................................................................ 28 3.3.5. SWA-20: Codering van dynamische onderdelen ............................. 29 3.3.6. SWA-21: Error handling ............................................................................ 30 4. Beveiligingseisen voor het voortbrengingsproces............................ 31 4.1. Het voortbrengingsproces ................................................................................. 31 4.1.1. SDW-1: Screening ....................................................................................... 31 4.1.2. SDW-2: Integriteit van de broncode .................................................... 33 4.1.3. SDW-3: Wijzigingenbeheer voor (web)applicaties ......................... 34 4.1.4. SDW-4: Wijzigingenbeheer voor middleware en platformen...... 36 4.1.5. SDW-5: Comments ..................................................................................... 37 4.2. OTAP en testen ...................................................................................................... 38

2 van 55


4.2.1. 4.2.2. 4.2.3.

SDW-6: Scheiding in OTAP-omgevingen ............................................ 38 SDW-7: Transport tussen OTAP-omgevingen................................... 39 SDW-8: Representatieve testsets ......................................................... 40

5.

Beveiligingseisen voor de infrastructuur voor de (web)applicaties ................................................................................................... 41 5.1. Hardware en software instellingen en configuratie ................................. 41 5.1.1. SIN-1: Scheiding van Presentatie, Applicatie en Gegevens ........ 41 5.1.2. SIN-2: Netwerkzonering ........................................................................... 42 5.1.3. SIN-3: Hardening van technische componenten ............................. 43 5.1.4. SIN-4: Standaard stack............................................................................. 45 5.1.5. SIN-5: Beveiliging van Mobile code ...................................................... 46 5.1.6. SIN-6: Data versleuteling ......................................................................... 47 5.1.7. SIN-7: Directory listing ............................................................................. 48 5.2. Veilige HTTP-sessies ............................................................................................ 49 5.2.1. SIN-8: Gebruik van veilige cookies ...................................................... 49 5.2.2. SIN-9: Sessie versleuteling ..................................................................... 50 5.2.3. SIN-10: HTTP validatie .............................................................................. 51 5.2.4. SIN-11: Beperking van te versturen HTTP-headers ...................... 52 5.2.5. SIN-12: Beperken van te tonen HTTP-header informatie ............ 53 5.2.6. SIN-13: HTTP methoden ........................................................................... 54

3 van 55


1.

Inleiding Dit document beschrijft een aantal standaard beveiligingseisen die van toepassing zijn bij de ontwikkeling en aanschaf van (web)applicaties.

1.1. De scope: (Web)applicaties Wanneer dit document spreekt over een webapplicatie dan gaat het om een applicatie die bereikbaar is via een webbrowser of via een andere client die ondersteuning biedt voor het Hypertext Transfer Protocol (HTTP). De kern van deze definitie is dat een webapplicatie altijd bereikbaar is op basis van HTTP of de versleutelde vorm hiervan, namelijk HTTP Secure (HTTPS). De scope van deze definitie is door NCSC hieronder aangegeven met een rode lijn om de webhosting omgeving: NCSC afbakening van de webhosting omgeving

Client LAN

Koppelingen Partners

Server LAN DMZ

Internet

Webhosting omgeving

Reguliere infrastructuur

Buitenwereld

SSD SIVA Beveiligingseisen

Figuur 1

Ook de bij (web)applicaties behorende infrastructuur, de koppeling met internet, de opslag van de gegevens en de netwerkservices worden in het document beschouwd als een aandachtsgebied. Voorbeelden van componenten, die volgens deze definitie onder de noemer webapplicatie vallen, zijn de Demilitarized Zone (DMZ), internetsites, extranetten, intranetten, SaaS-applicaties, webservices en webapi’s. De eisen in dit document richten zich niet alleen op de webapplicaties, maar ook op andere applicaties en de hierboven genoemde componenten van de infrastructuur die van belang zijn voor het functioneren van een (web)applicatie. De beveiligingseisen die gesteld worden aan bijvoorbeeld de rest van de infrastructuur, de werkplek of het personeel wat met het systeem moet werken zijn buiten de scope van dit document.

4 van 55


1.2. De drie domeinen Voor de beveiligingseisen wordt de onderstaande driedeling gehanteerd: (Web)applicaties en hun context Domein X Klant bedrijfsprocessen

WAARDE Financieel Privacygevoelig Vertrouwelijk

Klanten en partners van de klant

Voortbrengingsproces

IT diensten

Leveranciersmanagement Diensten Ontwikkeling & Onderhoud

Web applicaties

OTAP

Arch IA DS FO TO Bouw Test Accep

Applicaties

GEGEVENS

Infrastructuur DMZ

Netwerk Operating Centrum

Netwerk (WAN en LAN’s)

Functioneel & Technisch Beheer

IDS & IPS

Kantoor Automatisering & Mobiel AV

SSD SIVA Beveiligingseisen

Internet Buitenwereld

Data

Koppelingen Partners

Rekencentra APP APP MW MW AC AC AV OS OS HW HW

Storage Storage

Figuur 2

De beveiligingseisen zijn gegroepeerd als drie voor de leveranciers herkenbare domeinen. Hierbij is rekening worden gehouden met de actors, die de voorgestelde maatregelen daadwerkelijk moeten ontwikkelen en implementeren. De domeinen voor de beveiligingseisen zijn: Beveiligingseisen voor de (web)applicatie (Secure (Web) Applicatie, afgekort SWA): Beheersbaarheid en security van de webapplicatie; Identificatie, authenticatie en toegangsbeheersing; Veilige invoer en uitvoer. Beveiligingseisen voor het voortbrengingsproces (Secure Development (Web)applicatie, afgekort SDW): Het voortbrengingsproces; OTAP en testen. Beveiligingseisen voor de infrastructuur voor de webapplicatie (Secure Infrastructuur, afgekort SIN): Hardware en software instellingen en configuraties; Veilige HTTP-sessies.

5 van 55


1.3. 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: Op basis van een risicoanalyse, dat de maatregel niet in verhouding staat tot de te maken kosten; Dat eerder geïmplementeerde maatregelen het aan de eis ten grondslag liggende risico tot een acceptabel niveau hebben beperkt. De in dit document beschreven ‘voorgestelde maatregelen’ zijn een handreiking (best practice) hoe de maatregel ingevuld zou kunnen worden. Afhankelijk van de situatie kunnen mogelijk alternatieve maatregelen beter op hun plaats zijn. De voorgestelde maatregelen zijn daarom op zichzelf geen harde vereiste.

6 van 55


1.4. De actoren Bij de beveiligingseisen zijn de volgende rollen omschreven: De opdrachtgever voor een applicatie; De interne of externe software leverancier, 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. 1.5. Verantwoordelijkheid van de software leverancier De primaire verantwoordelijkheid voor het implementeren van de beschreven eis ligt bij de interne of externe software leverancier. Als onderdeel van de oplevering van een release, die klaar is voor productie, dient deze leverancier te rapporteren over de wijze waarop aan de gestelde eisen is voldaan. 1.6. Controle en toezicht, aanpak en verantwoordelijkheden De controle en toezicht op de werking en implementatie van de gestelde beveiligingseisen is belegd bij de leverancier, de hostingpartij, de ontvangende partij, haar test team en haar security team. Deze controle gebeurt, afhankelijk van de eis, op een van de volgende manieren: Controle door het ontwerp inhoudelijk te reviewen, door de ontvangende partij; Controle door de code inhoudelijke te reviewen, door de leverancier die hierover rapporteert aan de ontvangende partij; Controle van de werking van specifieke functionaliteit, door de ontvangende partij; Controle door te verifiëren of de applicatie kwetsbaar is voor een specifieke aanval, door de leverancier die hierover rapporteert aan de ontvangende partij; Controle door te verifiëren of de configuratie voldoet aan de ontwerpspecificatie, door de leverancier in samenwerking met de hostingpartij; Controle door bij software aangeleverde rapportage te beoordelen, door de ontvangende partij.

7 van 55


2.

SIVA-syntax voor de beveiligingseisen Per beveiligingsvereiste wordt in de volgende hoofdstukken kort aangegeven wat de onderbouwing voor de eis is en een voorstel voor de te implementeren maatregelen. Bij de beschrijving wordt gebruik gemaakt van het SIVA-raamwerk. Dit bevat vier componenten: Structuur; Inhoud; Vorm; Analyse. De opbouw per beveiligingseis is in de SIVA-syntax, namelijk: SSD-x

Naam

Context

Een beschrijving van het mechanisme.

Risico

Een beschrijving van mogelijk misbruik of schade.

Criterium

De norm, namelijk ‘wie’ en ‘wat’.

Doelstelling

Het gewenste resultaat, namelijk ‘waarom’.

Maatregelen

De mogelijke maatregelen, namelijk het ‘hoe’.

Referenties Bij de referenties wordt, voor zover relevant, aangegeven waar in de volgende standaarden en richtlijnen additionele informatie is te vinden: NCSC: ‘ICT Beveiligingsrichtlijnen voor webapplicaties’, deel 1 en 2, NCSC, januari 2012; NIST: Special Publication SP800-53 ‘Recommended Security Controls for Federal Information Systems’, NIST; ISO27002: NEN-ISO/IEC 27002 ‘Code voor informatiebeveiliging’, 2005. Voor de relevante referenties kan ook gebruik worden gemaakt van de ‘Baseline Informatiebeveiliging Rijksdienst’ (BIR).

8 van 55


3.

Beveiligingseisen voor de (web)applicatie

3.1. Beheersbaarheid en beveiliging van de (web)applicatie 3.1.1.

SWA-1: Risicobeheer SWA-1

Risicobeheer

Context

Risicobeoordelingen identificeren en kwantificeren risico’s, en kennen prioriteit toe aan de hand van de criteria voor risicoacceptatie en doelstellingen die relevant zijn voor de organisatie. De resultaten geven richting bij het bepalen van passende managementactie en prioriteiten voor het beheersen van risico’s voor de informatiebeveiliging en voor het implementeren van passende beheersmaatregelen, om tegen deze risico’s te beschermen.

Risico

Zonder risicobeheer loopt de organisatie het risico verkeerde prioriteiten te zetten, waardoor men of te kwetsbaar is of onnodige kosten worden gemaakt doordat men minder dringende maatregelen implementeert.

Criterium

De risicobeoordeling dient te bestaan uit de systematische aanpak van het schatten van de omvang van de risico’s (risicoanalyse) en het vergelijkingsproces van de ingeschatte risico’s met risicocriteria om zo het belang van de risico’s te bepalen (risico-evaluatie).

Doelstelling

Compliance met dit criterium zorgt dat de organisatie ‘in control’ is met het overzien en beheersen van de risico’s.

/01

risicoanalyse

/01.01

De opdrachtgever identificeert voor de functionaliteit van de (web)applicatie de dreigingen met hun mogelijke kans van optreden en impact.

/01.02

De opdrachtgever identificeert de kwetsbaarheden in de ondersteunde bedrijfsprocessen, de (web)applicaties en de onderliggende infrastructuur.

/02

risico-evaluatie

/02.01

De opdrachtgever zet prioriteiten bij het tegengaan van de dreigingen op basis van de te verwachten schade per dreiging, rekening houdend met de kwetsbaarheden.

/02.02

De opdrachtgever stelt attack patterns op en abuse casuïstiek, die wordt gebruikt voor het testen van de (web)applicatie.

/02.03

De opdrachtgever selecteert de minimale verzameling aan te treffen maatregelen om het totale risico onder een vooraf gedefinieerd niveau te brengen.

Referentie

NCSC BO-2

NIST

ISO27002 4.1

9 van 55


3.1.2.

SWA-2: Gegevensclassificatie SWA-2

Gegevensclassificatie

Context

Verschillende typen gegevens kunnen in meer of mindere mate gevoelig of kritisch zijn. Voor bepaalde typen kan een extra niveau van bescherming of een speciale verwerking nodig zijn. Een gegevensclassificatieschema is nodig om adequate niveaus van bescherming te definiëren en de noodzaak voor aparte verwerkingsmaatregelen te communiceren.

Risico

Indien gegevens onjuist of niet zijn geclassificeerd, kunnen deze niet op de juiste wijze worden beveiligd.

Criterium

Gegevens dienen te worden geclassificeerd met betrekking tot de waarde, wettelijke eisen, gevoeligheid en onmisbaarheid voor de organisatie.

Doelstelling

Compliance met dit criterium zorgt dat de gegevens een geschikt niveau van bescherming krijgen.

/01

geclassificeerd

/01.01

De opdrachtgever specificeert de classificaties en de bijbehorende beschermende beheersmaatregelen voor de verschillende typen gegevens, rekening houdend met de zakelijke behoefte aan het delen van informatie of het beperken ervan en de invloed van deze behoeften op de organisatie.

/01.02

De opdrachtgever neemt in de richtlijnen voor classificatie de conventies op voor initiële classificatie en herclassificatie door de tijd heen.

/01.03

De eigenaar van de gegevens definieert wat de classificatie is van de gegevens, beoordeelt deze periodiek en houdt deze op het juiste niveau.

/01.04

De eigenaar van de gegevens houdt rekening met het feit dat gegevens na verloop van tijd vaak minder gevoelig of kritiek zijn, om overclassificatie tegen te gaan.

Referentie

NCSC

NIST

ISO27002 7.2.1

10 van 55


3.1.3.

SWA-3: Functiescheiding SWA-3

Functiescheiding

Context

Bij het inrichten van functiescheiding wordt vastgesteld of een medewerker besluitvormende, uitvoerende of controlerende taken heeft. Indien noodzakelijk vanuit het bedrijfsproces of beheerproces worden dergelijke taken gesplitst, om risico’s voor de organisatie te verminderen. Hierbij wordt tevens vastgesteld welke toegang een medewerker nodig heeft tot functionaliteiten en gegevens en vanuit welke taak of rol die moeten worden gebruikt. Het principe van functiescheiding dient te worden toegepast bij kritische of fraudegevoelige taken, waarbij de uitgevoerde handelingen dienen te worden vastgelegd in een logbestand. Dit dient te zijn uitgewerkt in het functioneel ontwerp en procesontwerp.

Risico

Het ontbreken van een adequate implementatie van functiescheiding kan leiden tot een verhoogde kans op fraude of misbruik van bedrijfsmiddelen bij kritische of fraudegevoelige taken. Het verstrekken van onnodige toegang vergroot het risico dat informatie opzettelijk of onopzettelijk wordt gebruikt, gewijzigd of vernietigd.

Criterium

De (web)applicatie dient de door de opdrachtgever voorgeschreven functiescheiding af te dwingen door middel van toegekende autorisaties.

Doelstelling

Compliance met dit criterium zorgt dat een medewerker alleen het aan hem of haar toegewezen deel van de totale procescyclus kan beïnvloeden.

/01

functiescheiding

/01.01

De opdrachtgever stelt de rollen, taken en verantwoordelijkheden vast, conform de gewenste functiescheidingen om conflicten te vermijden.

/01.02

De (web)applicatie richt de autorisaties dusdanig in dat de door de opdrachtgever gespecificeerde functiescheiding wordt geborgd.

/02

autorisaties

/02.01

De (web)applicatie zorgt dat gebruikers alleen die noodzakelijke autorisaties en privileges hebben die nodig zijn om de hen toegewezen taken uit te voeren.

/02.02

De (web)applicatie legt de uitgevoerde handelingen gerelateerd aan kritische of fraudegevoelige taken vast in een logbestand.

/02.03

De opdrachtgever zorgt voor het verzamelen van de logrecords over de vastgelegde handelingen en voor analyses en rapportages om compliance met de eigen regelgeving te verifiëren.

Referentie

NCSC

NIST

ISO27002

11 van 55


AC-5

3.1.4.

10.1.3 10.6.1 10.10.1

SWA-4: Least Privilege SWA-4

Least Privilege

Context

Volgens het principe van ‘Least privilege’ worden de rechten van gebruikers gelimiteerd tot de minimale set van rechten die nodig zijn om de functie naar behoren uit te voeren. Dit principe is naast de rechten van medewerkers ook van toepassing op applicaties en processen.

Risico

Als een gebruiker over te hoge rechten beschikt kan daar bedoeld of onbedoeld misbruik van worden gemaakt. Tevens is er een risico dat bij compromittatie van een gebruikersaccount of systeemaccount onnodige schade ontstaat indien dit account over te hoge rechten beschikt.

Criterium

De (web)applicatie dient de door de opdrachtgever voorgeschreven beperkende set van rechten en privileges met alleen de voor de gebruiker noodzakelijke toegang af te dwingen.

Doelstelling

Compliance met dit criterium zorgt dat een medewerker alleen de aan hem of haar opgelegde specifieke taken kan uitvoeren.

/01

rechten en privileges

/01.01

De opdrachtgever stelt, op basis van een risicoanalyse, vast welke rechten en privileges worden toegekend aan gebruikers voor de aan hen toegekende rollen.

/01.02

De (web)applicatie zorgt via de toekenning van autorisaties dat niet meer dan de toegewezen rechten en privileges beschikbaar komen voor de gebruikers.

Referentie

NCSC

NIST AC-5

ISO27002 10.1.3 10.6.1 10.10.1

12 van 55


3.1.5.

SWA-5: Onweerlegbaarheid SWA-5

Onweerlegbaarheid

Context

Voor bepaalde daartoe door de opdrachtgever aangewezen transacties moet onweerlegbaar worden vastgelegd wie deze heeft uitgevoerd, zoals financiële transacties of transacties die bepaalde rechtsgevolgen hebben. Bij de vaststelling van de identiteit van de gebruiker en de onweerlegbaarheid van de transacties wordt een cryptografische techniek gebruikt met een elektronische handtekening. Bij deze vastlegging kan er sprake zijn van het verwerken van persoonsgegevens, waarbij wettelijke verplichtingen in acht dienen te worden genomen.

Risico

Indien een aangewezen transactie niet onweerlegbaar aan een persoon kan worden gekoppeld, kan die later zijn of haar betrokkenheid ontkennen.

Criterium

De (web)applicatie dient voor daartoe aangewezen transacties de onweerlegbaarheid via cryptografische technieken te ondersteunen en de transacties te loggen en monitoren.

Doelstelling

Compliance met dit criterium zorgt dat onweerlegbaar wordt vastgelegd welke transacties door welke individuele gebruikers zijn uitgevoerd.

/01

aangewezen transacties

/01.01

De opdrachtgever bepaalt voor welke typen transacties onweerlegbaarheid nodig is. Denk hierbij onder andere aan het verwerken van financiële, persoonsgerelateerde en andere vertrouwelijke gegevens.

/01.02

Tijdens de ontwerpfase worden de aangewezen transacties nader gedefinieerd en wordt bepaald op welke wijze de onweerlegbaarheid wordt geïmplementeerd.

/01.03

De (web)applicatie dwingt de onweerlegbaarheid af voor de aangewezen transacties.

/02

cryptografische technieken

/02.01

De opdrachtgever specificeert welke cryptografische technieken als veilig worden bestempeld voor het borgen van de onweerlegbaarheid.

/02.02

De opdrachtgever specificeert op welke wijze het beheer van sleutels en certificaten wordt ingericht voor de gebruikte cryptografische techniek.

/02.03

De (web)applicatie gebruikt de voorgeschreven cryptografische techniek voor de aangewezen transacties.

/03 /03.01

loggen en monitoren De (web)applicatie legt de aangewezen transacties vast in een logbestand.

13 van 55


14 van 55


Referentie

3.1.6.

NCSC

NIST AU-10

ISO27002 10.8.2 10.9.1 12.3.1

SWA-6: (Web)applicatie logging SWA-6

(Web)applicatie logging

Context

De handelingen van gebruikers en beheerders op een (web)applicatie moeten worden vastgelegd in een logbestand, zodat later is te reconstrueren wie wat heeft gedaan. Dit geldt met name voor belangrijke transacties van gebruikers, die financiële of andere consequenties kunnen hebben. De opdrachtgever bepaalt welke transacties op welke (web)applicaties moeten worden vastgelegd. Om te voorkomen dat kwaadwillende sporen uitwissen moeten logbestanden zo zijn ingesteld dat deze achteraf niet kunnen worden aangepast. Deze beveiligingseis is essentieel bij reconstructies in relatie tot opgetreden issues of incidenten. De opdrachtgever bepaalt of de loginformatie centraal moet worden opgeslagen, zodat centrale archivering, monitoring en bewaking mogelijk is.

Risico

Zonder logging kunnen issues of incidenten niet worden onderzocht.

Criterium

De (web)applicatie dient over een door de opdrachtgever gespecificeerd mechanisme voor logging te beschikken en dient het mechanisme en het logbestand adequaat te beveiligen.

Doelstelling

Compliance met dit criterium zorgt dat activiteiten herleidbaar zijn naar individuele gebruikers en beheerders.

/01

logging

/01.01

De opdrachtgever bepaalt welke transacties op welke (web)applicaties moeten worden vastgelegd.

/01.02

De leverancier legt in de ontwerpdocumentatie vast hoe de logging is ingericht en is beveiligd.

/01.03

De (web)applicatie legt de daartoe aangewezen transacties vast in een logbestand.

/01.04

Het logbestand is beveiligd tegen wijzigen.

/01.05

De hostingpartij koppelt het logbestand aan de centrale opslagvoorziening voor loginformatie, indien zo opgegeven door de opdrachtgever.

15 van 55


Referentie

3.1.7.

NCSC B7-7 B7-8

NIST IR-4 IR-5 IR-6 IR-7

ISO27002 6.1.6 13.2.1 13.2.2 6.1.6 6.2.2 6.2.3 13.1.1 13.1.2 14.1.3

SWA-7: Borgen van Sessie Authenticiteit SWA-7

Borgen van Sessie Authenticiteit

Context

Een sessie tussen de webapplicatie en de gebruiker krijgt een unieke sessie ID. Na het uitloggen van de gebruiker dient de sessie actief te worden beëindigd door de webapplicatie om te voorkomen dat een andere persoon de nog openstaande sessie kan oppakken en hiermee verder kan werken. In dit kader wordt ook aan het sessie ID eisen gesteld, onder andere dat deze onvoorspelbaar is. Hiertoe wordt een nummer gebruikt met voldoende lengte en wordt een volgend sessie ID random gekozen.

Risico

Als een andere persoon een nog openstaande sessie kan oppakken, geeft dit de mogelijkheid van misbruik van de identiteit van de oorspronkelijke gebruiker.

Criterium

De webapplicatie dient de sessie op een onvoorspelbare wijze te nummeren en actief te beëindigen bij het uitloggen van de gebruiker.

Doelstelling

Compliance met dit criterium voorkomt misbruik van een nog openstaande sessie, die door de oorspronkelijke gebruiker niet meer wordt gebruikt.

/01

onvoorspelbare wijze te nummeren

/01.03 /02

Een sessie ID is voldoende sterk, namelijk een lang random nummer, om deze onvoorspelbaar te maken. beëindigen

/02.01

De webapplicatie vernietigt actief de sessie bij het uitloggen van een gebruiker.

/02.02

De webapplicatie genereert steeds een nieuw random sessie ID bij het inloggen en het opnieuw inloggen van een gebruiker.

Referentie

NCSC B4-2

NIST SC-23

ISO27002

16 van 55


3.1.8.

SWA-8: Concurrent Session Control SWA-8

Concurrent Session Control (standaard slechts een sessie per gebruiker)

Context

Het technisch afdwingen van de mogelijkheid om het aantal gelijktijdige sessies binnen eenzelfde (web)applicatie te beheersen wordt aangeduid als ‘Concurrent Session Control’. De opdrachtgever stelt via een functionele analyse, samen met een risicoanalyse, vast of er meer dan een gelijktijdige sessie van een gebruiker nodig is. Indien daar geen noodzaak toe is, kan worden volstaan met het beperken van het aantal tot één gelijktijdige sessie per gebruiker.

Risico

Het ongecontroleerd toestaan van meerdere gelijktijdige sessies verhoogt de kans op fouten door gebruikers en maakt de logica van de (web)applicaties ingewikkeld, doordat deze logica rekening moet houden met handelingen via meerdere sessies met dezelfde gebruiker.

Criterium

Een (web)applicatie dient te zijn voorzien van Concurrent Session Control, die bij voorkeur slechts één sessie per gebruiker toestaat, tenzij meer noodzakelijk is.

Doelstelling

Compliance met dit criterium zorgt dat het gebruik van accounts en sessies op een ordelijke wijze verloopt.

/01

Concurrent session control

/01.01

De opdrachtgever stelt via een functionele analyse, samen met een risicoanalyse in de ontwerpfase, vast of er één, dan wel meer dan een gelijktijdige sessie van een gebruiker nodig is.

/01.02

De opdrachtgever legt de argumentatie vast indien er meer dan een sessie per gebruiker nodig blijkt te zijn.

/01.03

De (web)applicatie limiteert het aantal gelijktijdige sessies per gebruiker conform de specificatie van de opdrachtgever.

Referentie

NCSC

NIST AC-10

ISO27002

17 van 55


3.1.9.

SWA-9: Session lock SWA-9

Session lock

Context

Als een werkstation onbeheerd wordt achtergelaten met of zonder open sessies, kan hiervan misbruik worden gemaakt door andere personen. Een session lock zorgt ervoor dat het werkstation ontoegankelijk wordt gemaakt na een door de opdrachtgever voorgeschreven tijdsinterval van inactiviteit. Veelal gebeurt dit door een screen saver, die alleen met een wachtwoord of via two-factor authenticatie kan worden ontgrendeld. Het werkstation en de daarop geopende sessies worden, nadat de gebruiker het authenticatieproces heeft doorlopen, weer toegankelijk gemaakt zonder verlies van gegevens.

Risico

Het ontbreken van een session lock kan als gevolg hebben dat het werkstation en de daarop geopende sessies worden misbruikt.

Criterium

Het werkstation dient te zijn voorzien van automatische session lock.

Doelstelling

Compliance met dit criterium zorgt dat een werkstation slechts gedurende een beperkte tijd onbeheerd toegankelijk is voor andere personen als de gebruiker het werkstation onbeheerd heeft achtergelaten.

/01

automatische session lock

/01.01

Het werkstation activeert automatisch een session lock na een door de opdrachtgever voorgeschreven tijdsinterval van inactiviteit.

/01.02

De session lock op het werkstation kan alleen worden ontgrendeld door de geautoriseerde gebruiker, via een wachtwoord of two-factor authenticatie.

/01.03

Het werkstation en de daarop geopende sessies worden, na ontgrendeling van de session lock, weer toegankelijk gemaakt zonder verlies van gegevens.

Referentie

NCSC

NIST AC-11

ISO27002 11.3.2

18 van 55


3.1.10. SWA-10: Session termination SWA-10

Session termination

Context

Als een sessie met een (web)applicatie onbeheerd wordt achtergelaten door de gebruiker, kan hiervan misbruik worden gemaakt door andere personen. Session termination zorgt ervoor dat de sessie wordt beëindigd na een door de opdrachtgever voorgeschreven tijdsinterval van inactiviteit.

Risico

Het ontbreken van een session termination kan als gevolg hebben dat de reeds geopende sessie door een kwaadwillende wordt misbruikt.

Criterium

De (web)applicatie dient een sessie te beëindigen via automatische session termination, na een vooringestelde periode van inactiviteit van de gebruiker.

Doelstelling

Compliance met dit criterium zorgt dat een sessie slechts gedurende een beperkte tijd onbeheerd toegankelijk is voor andere personen, nadat de gebruiker de sessie onbeheerd heeft achtergelaten.

/01

automatische session termination

/01.01

De (web)applicatie activeert automatisch session termination na een door de opdrachtgever voorgeschreven tijdsinterval van inactiviteit.

/01.02

Session termination komt overeen met het uitloggen van de gebruiker en de (web)applicatie vernietigt daarbij dienovereenkomstig de sessie.

Referentie

NCSC

NIST AC-11

ISO27002 11.3.2

19 van 55


3.2. Identificatie, authenticatie en toegangsbeheersing 3.2.1.

SWA-11: De identiteit van een externe gebruiker vaststellen SWA-11

De identiteit van een externe gebruiker vaststellen

Context

De opdrachtgever levert elektronische diensten aan externe gebruikers. De toegangsvoorziening tot deze diensten is gebaseerd op strikte beveiligingseisen. Zo wordt de identiteit van een externe gebruiker vastgesteld met behulp van een bewezen, door de opdrachtgever daarvoor aangewezen mechanisme voor (wederzijdse) identificatie, authenticatie en autorisaties. Uitsluitend in overleg met de opdrachtgever mag hiervan worden afgeweken.

Risico

Het risico is misbruik van identiteit. De gevolgen kunnen zijn ongeautoriseerde onthulling van informatie, ongeautoriseerde modificatie of onterechte invoer van transacties uit naam van valide gebruikers.

Criterium

(Web)applicaties en informatiesystemen dienen de identiteit van externe gebruikers vast te stellen op basis van een mechanisme voor identificatie en authenticatie.

Doelstelling

Compliance met dit criterium zorgt dat ongeautoriseerde externe toegang tot (web)applicaties wordt voorkomen.

/01

externe gebruikers

/01.01

Externe gebruikers zijn geregistreerde gebruikers, die niet aansluiten via het interne netwerk of de kantoorautomatisering.

/01.02

De externe gebruiker wordt alleen op basis van het door de opdrachtgever vastgestelde wijze geïdentificeerd, geauthenticeerd en geautoriseerd op basis van externe rollen.

/02

mechanisme voor identificatie en authenticatie

/02.01

De opdrachtgever stelt vast welk mechanisme moet worden gebruikt voor de identificatie en authenticatie van externe gebruikers, conform de door haar vastgestelde authenticator eisen.

/02.02

De opdrachtgever geeft aan, op basis van haar beleid, als het gebruik van two-factor authenticatie via DigiD en SMS nodig is.

/02.03

De (web)applicatie maakt uitsluitend gebruik van de door het opdrachtgever gespecificeerde mechanisme voor identificatie en authenticatie.

Referentie

NCSC B0-12 B3-2

NIST IA-1 IA-2

ISO27002 15.1.1 11.2.3 11.4.2 11.5.2

20 van 55


3.2.2.

SWA-12: De identiteit van een interne gebruiker vaststellen SWA-12

De identiteit van een interne gebruiker vaststellen

Context

De opdrachtgever levert elektronische diensten aan de interne gebruikers. De toegangsvoorziening tot deze diensten is gebaseerd op strikte beveiligingseisen. Zo wordt de identiteit van een interne gebruiker vastgesteld met behulp van een bewezen, door de opdrachtgever daarvoor aangewezen mechanisme voor (wederzijdse) identificatie, authenticatie, autorisaties en rollen. Uitsluitend in overleg met de opdrachtgever mag hiervan worden afgeweken.

Risico

Het ontbreken van adequate aanpak voor identificatie en authenticatie kan leiden tot ongeautoriseerde onthulling of mutatie van privacygevoelige informatie. Daarnaast dient te worden voorkomen dat kwaadwillende transacties uit naam van valide gebruikers uitvoeren.

Criterium

(Web)applicaties en informatiesystemen dienen de identiteit van interne gebruikers vast te stellen op basis van een mechanisme voor identificatie en authenticatie.

Doelstelling

Compliance met dit criterium zorgt dat ongeautoriseerde toegang door interne gebruikers tot (web)applicaties wordt voorkomen.

/01

interne gebruikers

/01.01

Interne gebruikers zijn geregistreerde gebruikers, die aansluiten via het interne netwerk, de kantoorautomatisering of via faciliteiten voor mobiel werken.

/01.02

De interne gebruiker wordt alleen op basis van een door de opdrachtgever vastgestelde wijze geïdentificeerd, geauthenticeerd en geautoriseerd op basis van rollen of functieprofielen.

/02

mechanisme voor identificatie en authenticatie

/02.01

Het door de opdrachtgever voorgeschreven toegangsmechanisme omvat Identity en Access Management, rollenbeheer en een technische implementatie, zoals gebruik van de Active Directory. Afhankelijk van de gebruikte techniek kan dit ook omvatten het runtime verifiëren van autorisaties op basis van een autorisatietabel, het wel of niet gebruik maken van (delen van) de (web)applicatie etc.

/02.02

De (web)applicatie maakt uitsluitend gebruik van het door de opdrachtgever gespecificeerde mechanisme voor identificatie en authenticatie, waarbij tevens het beleid van de opdrachtgever voor wachtwoorden en accounts wordt gevolgd.

Referentie

NCSC B0-12 B3-2

NIST IA-1 IA-2

ISO27002 15.1.1 11.2.3 11.4.2 11.5.2

21 van 55


3.2.3.

SWA-13: Registreren van Unsuccessful Login Attempts SWA-13

Registreren van Unsuccessful Login Attempts

Context

Door tijdig te acteren op mislukte login pogingen kan een mogelijke aanval, zoals een brute force attack, worden tegengegaan. Een brute force attack is een aanvalsmethode die bestaat uit het proberen van alle mogelijke opties tot een inbraak, net zolang tot er een optie is gevonden die succesvol is. Door de mislukte login pogingen vast te leggen, te monitoren en hierop te reageren kan schade worden voorkomen of worden beperkt.

Risico

Indien mislukte login pogingen niet worden gesignaleerd en bewaakt, is er een risico dat onbevoegden ongezien in de systemen kunnen binnendringen.

Criterium

De (web)applicatie dient mislukte login pogingen te registreren.

Doelstelling

Compliance met dit criterium zorgt dat het voor de opdrachtgever mogelijk is tijdig te signaleren dat een aanval plaatsvindt en daarop actie te ondernemen.

/01

mislukte login pogingen

/01.01

De (web)applicatie en de webserver leggen mislukte login pogingen vast in logbestanden.

/01.02

De opdrachtgever zorgt voor het verzamelen van de logrecords over mislukte login pogingen en voor analyses, monitoring en rapportages om dreigingen adequaat aan te pakken.

Referentie

NCSC

NIST AC-7

ISO27002 11.5.1

22 van 55


3.2.4.

SWA-14: System Use Notification SWA-14

System Use Notification

Context

Een System Use Notification is een meldtekst die is vereist voor (web)applicaties met een interactieve login interface. Een gebruiker die wil inloggen krijgt een tweeledige melding. Eerst wordt benadrukt dat de (web)applicatie alleen mag worden gebruikt voor activiteiten die door de opdrachtgever zijn toegestaan. In aanvulling hierop wordt gesteld dat de uitgevoerde handelingen worden vastgelegd en door de opdrachtgever kunnen worden geanalyseerd.

Risico

Het risico van het ontbreken van een System Use Notification is dat een kwaadwillende achteraf kan beweren dat deze niet op de hoogte was van de regels voor het correcte gebruik van de (web)applicatie, of bezwaar kan maken tegen het vastleggen van de uitgevoerde handelingen.

Criterium

Een (web)applicatie dient aan de gebruiker een geautoriseerde melding te tonen tijdens een interactief inlogproces, waarmee de gebruiker op de rechten en plichten wordt gewezen.

Doelstelling

Compliance met dit criterium zorgt voor een ontmoediging voor ongewenste handelingen en voor een juiste basis om te kunnen loggen en monitoren.

/01

geautoriseerde melding

/01.01

De opdrachtgever stelt de tekst vast die wordt opgenomen in de System Use Notification.

/01.02

De (web)applicatie toont de System Use Notification tijdens de interactieve inlogprocedure aan de gebruiker.

/01.03

De (web)applicatie zorgt dat de gebruiker een handeling moet verrichten om de System Use Notification van het scherm te verwijderen, bijvoorbeeld door een Enter te geven.

Referentie

NCSC

NIST AC-8

ISO27002 11.5.1 15.1.5

23 van 55


3.2.5.

SWA-15: Beheerinterface SWA-15

Beheerinterface

NCSC

B1-2. Scheiding beheer en productie

Context

Op (web)applicaties, gegevensverzamelingen en platformen wordt beheer uitgevoerd. Voor de activiteiten van beheerders dient een beveiligde beheerinterface aanwezig te zijn, om te zorgen dat de beheeractiviteiten op een gecontroleerde en gestructureerde wijze plaatsvinden. Hierbij vindt ook logging plaats. Beheeractiviteiten omvatten een groot aantal activiteiten, zoals het aanpassen van configuraties, het toekennen, muteren en intrekken van rechten, het bekijken van logbestanden etc.

Risico

Zonder een beheerinterface is het moeilijk na te trekken of er bedoeld of onbedoeld onjuiste beheerhandelingen zijn uitgevoerd of dat buitenstaanders zich toegang hebben weten te verschaffen tot beheerbevoegdheden.

Criterium

Beheeractiviteiten dienen plaats te vinden via een beveiligde beheerinterface.

Doelstelling

Compliance met dit criterium zorgt dat er inzicht bestaat in wie welke beheerhandelingen heeft uitgevoerd.

/01

Beheerinterface

/01.01

De opdrachtgever bepaalt welke beheeractiviteiten door de hostingpartij, de leverancier en de ontvangende partij mogen worden uitgevoerd.

/01.02

De beheerinterface borgt via autorisaties en vooraf gedefinieerde functionaliteit dat de door de opdrachtgever gespecificeerde functiescheiding wordt gerealiseerd.

/01.03

Externe toegang tot de beheerinterface is alleen mogelijk via een geautoriseerde en beveiligde verbinding.

/01.04

De beheerinterface legt alle beheerhandelingen vast in een logbestand, inclusief identificatie van degene die de handeling uitvoert.

/01.05

De beheerinterface is niet toegankelijk voor reguliere gebruikers.

Referentie

NCSC B1-2

NIST SC-2

ISO27002 11.4.5

24 van 55


3.3. Veilige invoer en uitvoer 3.3.1.

SWA-16: Invoer validatie SWA-16

Invoer validatie

Context

De (web)applicatie ontvangt invoer van de gebruiker. Hierbij is een belangrijke vuistregel dat de (web)applicatie geen enkele invoer mag vertrouwen. Het is mogelijk dat de gebruiker werkt vanaf een geïnfecteerd werkstation of dat de gebruiker een kwaadwillende is die probeert in te breken op de (web)applicatie. Het is tevens mogelijk dat de kwaadwillende geen gebruik maakt van een standaard browser, maar van eigen instrumenten voor het aanvallen van de (web)applicatie. Een kwaadwillende kan zo ook eventuele beperkingen in de invoer aan de clientzijde omzeilen. De (web)applicatie moet ‘defensief’ worden geprogrammeerd, waarbij alle van de gebruiker ontvangen inhoud eerst wordt gevalideerd, alvorens die wordt gebruikt. Denk aan het beperken van de lengte van een string die in een veld kan worden ingevoerd, het disablen van invoervelden of het verbergen van variabelen in hidden parameters.

Risico

Zonder validatie van de ontvangen inhoud kunnen kwaadwillenden kwetsbaarheden benutten om gegevens te bemachtigen, te muteren of toe te voegen.

Criterium

De (web)applicatie dient alle invoer die door de gebruiker aan de (web)applicatie wordt aangeboden, aan de serverzijde te valideren.

Doelstelling

Compliance met dit criterium zorgt dat alleen gecontroleerde invoer wordt verwerkt.

/01

valideren

/01.01

De (web)applicatie voert validatie van de invoer uit aan de serverzijde en vertrouwt niet op de maatregelen aan de clientzijde.

/01.02

Voor elke controle die de (web)applicatie uitvoert aan de clientzijde, is er een equivalent aanwezig aan de serverzijde.

/01.03

De (web)applicatie valideert alle invoer die de gebruiker aan de (web)applicatie verstrekt.

Referentie

NCSC B3-6

NIST SI-10

ISO27002 10.7.3 12.2.1 12.2.2

25 van 55


3.3.2.

SWA-17: Invoer normalisatie SWA-17

Invoer normalisatie

Context

De (web)applicatie ontvangt invoer van de gebruiker en van andere (web)applicaties. Deze invoer kan verschillende vormen hebben. De (web)applicatie dient eerst de invoer te normaliseren, alvorens een validatie van de invoer kan worden uitgevoerd via de mechanismen voor filtering. Via normalisatie voorkomt de (web)applicatie dat malafide verzoeken abusievelijk de filters voor validatie kunnen passeren. Normalisatie staat ook wel bekend als anti-evasion of canonicalization.

Risico

Zonder normalisatie van de ontvangen inhoud kunnen kwaadwillenden kwetsbaarheden benutten om gegevens te bemachtigen, te muteren of toe te voegen.

Criterium

De (web)applicatie dient alle ontvangen invoer te normaliseren alvorens die te valideren.

Doelstelling

Compliance met dit criterium zorgt dat afwijkende vormen van de invoer niet aan de validatie ontsnappen.

/01

normaliseren

/01.01

De (web)applicatie controleert de invoer op verdachte karakters of commando’s.

/01.02

De (web)applicatie verzorgt onder andere: Het omzetten van NULL karakters naar spaties; Het coderen van bijzondere karakters naar een uniforme codering, zoals UTF-8; Het normaliseren van padverwijzingen zoals ‘/./’ en ‘/../’; Het verwijderen van overbodige spaties en regeleinden; Het verwijderen van onnodige witruimtes; Het omzetten van backslashes naar forward slashes; Het omzetten van mixed case strings naar lower case strings.

Referentie

NCSC B3-3

NIST

ISO27002

26 van 55


3.3.3.

SWA-18: Geparameteriseerde queries SWA-18

Geparameteriseerde queries

Context

De (web)applicatie vraagt gegevens op uit een gegevensverzameling of schrijft daar gegevens naartoe. Veelal verloopt dit via een database query. Indien hierbij invoer van een gebruiker moet worden ingesloten, kan dit via het opnemen van een dynamische string of door het gebruik van parameters in de query. Bij het gebruik van een dynamische string plakt de ontwikkelaar een vaste string, bijvoorbeeld de start van een SELECT-statement, aan een variabele, bijvoorbeeld de inhoud van de WHERE-clause. In dit laatste deel kan invoer van de gebruiker worden opgenomen. Bij het gebruik van parameters gebruikt de ontwikkelaar een vaste string, waarbij een vaste plek is ingeruimd voor iedere variabele. Bij een geparameteriseerde query is de syntax van de query statisch en wordt invoer van de gebruiker alleen gebruikt om vooraf gedefinieerde variabelen te vullen.

Risico

Een aanvaller kan in de invoer een malafide commando voor de database opnemen. Bij het gebruik van een dynamische string is het mogelijk dat dit commando wordt doorgegeven aan de database. Dit is SQL-injectie, waarbij de inhoud van de database wordt gecompromitteerd.

Criterium

De (web)applicatie dient een database query samen te stellen op basis van geparameteriseerde queries, in tegenstelling tot het gebruik van dynamische strings.

Doelstelling

Compliance met dit criterium verkleint de kans op een aanval via SQLinjectie.

/01

geparameteriseerde queries

/01.01

De (web)applicatie filtert de invoer op commando’s voor de database en verwijdert die.

/01.02

De (web)applicatie gebruikt geen dynamische strings voor het samenstellen van een database query.

/01.03

De (web)applicatie stelt een database query samen op basis van geparameteriseerde queries.

Referentie

NCSC B3-5

NIST

ISO27002

27 van 55


3.3.4.

SWA-19: File includes SWA-19

File includes

Context

Soms levert een (web)applicatie aan gebruikers te mogelijkheid bestanden te uploaden. Hierbij kan een kwaadwillende ook executables of andere gevaarlijke bestanden aanbieden, waardoor hij of zij willekeurige code kan laten executeren op de webserver. Mocht men toch op basis van een besluit van de opdrachtgever bestanden willen inlezen, dan moet worden voorkomen dat de eindgebruiker directe invloed heeft op het type bestand dat kan worden gebruikt, bijvoorbeeld door whitelisting.

Risico

Wanneer kwaadwillenden via malafide invoer willekeurige bestanden kunnen laten executeren op de (web)server, bestaat de mogelijkheid dat zij op een ongeautoriseerd wijze de databases op een server kunnen benaderen.

Criterium

De (web)applicatie dient geen dynamische file includes toe te staan voor door gebruikers aangeleverde bestanden of de keuzemogelijkheid van de gebruiker te beperken.

Doelstelling

Compliance met dit criterium voorkomt dat schadelijke bestanden van gebruikers worden geupload naar de webserver.

/01

file includes

/01.01

De opdrachtgever beschikt over de broncode van de programmatuur en over een verklaring van de leverancier dat de (web)applicatie alleen uploaden toestaat op een veilige wijze.

/01.02

De (web)applicatie maakt geen gebruik van dynamische file includes voor alle typen van bestanden.

/01.03

De (web)applicatie beperkt de keuzemogelijkheid voor het uploaden van bestanden, bijvoorbeeld via whitelisting.

Referentie

NCSC B3-7

NIST

ISO27002

28 van 55


3.3.5.

SWA-20: Codering van dynamische onderdelen SWA-20

Codering van dynamische onderdelen

Context

Vrijwel elke webpagina bevat naast statische ook dynamische informatie. Deze dynamische informatie kan bijvoorbeeld afkomstig zijn uit databases of externe bronnen, maar kan ook gebaseerd zijn op invoer van de gebruiker. Hoe de webapplicatie dynamische pagina-inhoud codeert is afhankelijk van de plek op de pagina waar deze dynamische inhoud verschijnt. Uitvoervalidatie voorkomt dat de webapplicatie ongewenste opdrachten geeft aan de client, bijvoorbeeld in het geval van XSS. Uitvoervalidatie kan worden geïmplementeerd voor het coderen van alle dynamische inhoud van een webpagina. Veel scripting- en programmeertalen hebben standaard bibliotheken waarmee deze codering en filtering kan worden uitgevoerd.

Risico

Bij de codering van dynamische pagina-inhoud kunnen gevaarlijke karakters en opdrachten worden opgenomen, die door een malafide bron zijn aangeleverd. Bij onvoldoende filtering kunnen aanvallers hier misbruik van maken.

Criterium

De webapplicatie dient alle dynamische onderdelen van de uitvoer te coderen en filteren.

Doelstelling

Compliance met dit criterium voorkomt dat de webapplicatie via haar uitvoer ongewenste tekens en opdrachten geeft aan de client.

/01

coderen en filteren

/01.01

De webapplicatie gebruikt de functionaliteit voor uitvoervalidatie.

/01.02

Via uitvoervalidatie worden de dynamische onderdelen van de uitvoer dusdanig gecodeerd en gefilterd dat er geen ongewenste tekens terechtkomen in de uitvoer.

/01.03

Via uitvoervalidatie worden ongewenste opdrachten aan de client verwijderd uit de uitvoer.

Referentie

NCSC B3-4

NIST

ISO27002

29 van 55


3.3.6.

SWA-21: Error handling SWA-21

Error handling

Context

Op het moment dat zich een probleem voordoet binnen een (web)applicatie zal de webserver veelal een statuscode ‘500 Internal Server Error’ terugsturen. Dit wijst op een exceptie. Hierbij is het mogelijk dat de webserver gevoelige informatie over de (web)applicatie openbaart, zoals databasenamen, gebruikersnamen, bestandsnamen, interne IP-adressen etc. Om het lekken van technische informatie te voorkomen zou bijvoorbeeld een application-level firewall een dergelijke statuscode kunnen detecteren. De firewall kan het gedetailleerde antwoord van de webserver negeren en een standaard foutmelding terugsturen naar de client. Dit kan bijvoorbeeld zijn ‘Er heeft zich een onbekende fout voorgedaan’. Ook webservers zelf bieden functionaliteit om standaard meldingen te laten genereren aan de hand van specifieke statuscodes.

Risico

Indien gedetailleerde foutmeldingen worden getoond aan de gebruiker, bestaat de mogelijkheid dat een kwaadwillende de foutmelding benut om zwakheden uit te buiten.

Criterium

De webserver dient in een foutmelding aan de client geen inhoudelijke foutinformatie op te nemen die kan worden misbruikt.

Doelstelling

Compliance met dit criterium zorgt dat zo min mogelijk technische informatie over de (web)applicatie naar buiten lekt, zodat een aanvaller daar geen misbruik van kan maken.

/01

inhoudelijke foutinformatie

/01.01

De hostingpartij legt in de configuratiedocumentatie vast hoe de webserver is geconfigureerd om alleen standaard foutmeldingen te tonen en versturen.

/01.02

De hostingpartij legt in de configuratiedocumentatie vast op welke wijze de application-level firewall is geconfigureerd om gedetailleerde antwoorden van de webserver te blokkeren.

/01.03

De leverancier onderbouwt en beschrijft eventuele noodzakelijke afwijkingen van de standaard configuratie op de webserver en de application-level firewall, die nodig zijn voor het goed functioneren van de (web)applicatie.

/01.04

De webserver toont bij een fout geen gedetailleerde informatie aan de client, maar alleen een standaard foutmelding.

Referentie

NCSC B3-10

NIST SI-11

ISO27002 12.2.1 12.2.2 12.2.3 12.2.4

30 van 55


4.

Beveiligingseisen voor het voortbrengingsproces

4.1. Het voortbrengingsproces 4.1.1.

SDW-1: Screening SDW-1

Screening

Context

Indien (web)applicaties worden ontwikkeld waarin financiële of gevoelige gegevens worden verwerkt, dient de achtergrond van alle kandidaten voor een dienstverband, ingehuurd personeel en externe gebruikers te worden geverifieerd. De screening moet worden uitgevoerd conform relevante wetten, voorschriften en ethische overwegingen, en behoort evenredig te zijn aan de bedrijfseisen, de classificatie van de informatie waartoe toegang wordt verleend, en de waargenomen risico’s.

Risico

Ontwikkelaars van (web)applicaties hebben de mogelijkheid ongewenste of schadelijke code te integreren in software, zoals Trojans, man-in-the-middle etc., waarmee de vertrouwelijkheid en integriteit van bijvoorbeeld financiële informatie of gevoelige informatie kan worden geschaad.

Criterium

De leverancier dient een screening uit te voeren voor alle medewerkers die betrokken zijn bij de ontwikkeling, onderhoud, testen en hosten van (web)applicaties die financiële of gevoelige gegevens verwerken.

Doelstelling

Compliance met dit criterium vermindert de kans dat schadelijke of frauduleuze software aan de (web)applicatie wordt toegevoegd.

/01

screening

/01.01

De leverancier heeft een proces voor screening, waarbij de criteria en beperkingen zijn gedefinieerd, zoals wie is gerechtigd om personen te screenen en hoe, wanneer en waarom de screening wordt uitgevoerd.

/01.02

De screening houdt rekening met alle relevante weten regelgeving op het gebied van privacy, bescherming van persoonsgegevens en arbeidswetgeving, en neemt, mits toegelaten, het volgende mee: Beschikbaarheid van positieve referenties, bijvoorbeeld één zakelijke en één persoonlijke; Controle van (de volledigheid en nauwkeurigheid van) het curriculum vitae van de sollicitant; Bevestiging van vermelde academische en professionele kwalificaties; Onafhankelijke identiteitscontrole (paspoort of vergelijkbaar document); Meer gedetailleerde controles, zoals op kredietwaardigheid of strafblad.

31 van 55


/01.03 Referentie

De leverancier maakt aantoonbaar dat het proces voor screening effectief is. NCSC

NIST

ISO27002 8.1.2

32 van 55


4.1.2.

SDW-2: Integriteit van de broncode SDW-2

Integriteit van de broncode

Context

Broncode is door programmeurs geschreven code, die wordt gecompileerd en gekoppeld om uitvoerbare code te verkrijgen, of die resulteert in het aanmaken van uitvoerbare code op het moment van activering. De toegang tot broncode en daarmee verbonden zaken zoals ontwerpen, specificaties, verificatie- en validatieplannen behoort nauwgezet te worden beheerst om het invoeren van onbevoegde functionaliteit te voorkomen en onbedoelde wijzigingen te vermijden. Dit kan worden bereikt met behulp van een beheerste centrale opslag van de code, bij voorkeur in broncodebibliotheken.

Risico

Ontwikkelaars van (web)applicaties kunnen fouten maken of opzettelijk ongeautoriseerde wijzigingen aanbrengen, waarmee de vertrouwelijkheid en integriteit van bijvoorbeeld financiële informatie of gevoelige informatie, of de beschikbaarheid van de (web)applicatie kan worden geschaad.

Criterium

De leverancier beperkt de toegang tot broncode van programmatuur.

Doelstelling

Compliance met dit criterium vermindert de kans op het abusievelijk of opzettelijk ongeautoriseerd wijzigen van broncode.

/01

toegang

/01.01

De leverancier heeft een proces om de integriteit van broncode te borgen.

/01.02

De leverancier beheerst de toegang tot de broncode door: Waar mogelijk broncode niet in productiesystemen op te slaan; De broncode te beheren volgens vastgestelde procedures; Onderhoudspersoneel geen onbeperkt toegang te verlenen tot broncode; Het updaten van broncode en daarmee verbonden zaken, en het afgeven van broncodes aan programmeurs alleen te laten uitvoeren nadat daarvoor de juiste autorisatie is ontvangen; Programma-uitdraaien te bewaren in een beveiligde omgeving; Een auditlogbestand bij te houden waarin elke toegang tot broncode wordt geregistreerd; Het bijhouden en kopiëren van broncode te onderwerpen aan strikte procedures voor wijzigingsbeheer.

/01.03 Referentie

De leverancier maakt aantoonbaar dat het proces voor beheersing van de broncode effectief is. NCSC

NIST

ISO27002 12.4.3

33 van 55


4.1.3.

SDW-3: Wijzigingenbeheer voor (web)applicaties SDW-3

Wijzigingenbeheer voor (web)applicaties

Context

Het invoeren van nieuwe systemen en het aanbrengen van wijzigingen in bestaande systemen moet een formeel proces volgen van documentatie, specificatie, testen, kwaliteitscontrole en een beheerste implementatie. Dit proces moet een risicobeoordeling, een analyse van de gevolgen van wijzigingen en een specificatie van de benodigde beveiligingsmaatregelen bevatten. Het proces moet ook waarborgen dat bestaande beveiligings- en beheersingsprocedures niet worden gecompromitteerd, dat ondersteunende programmeurs uitsluitend toegang wordt verleend tot die onderdelen van het systeem die zij voor hun werk nodig hebben en dat formele instemming en goedkeuring is verkregen voor alle wijzigingen.

Risico

Het aanbrengen van wijzigingen kan leiden tot het corrumperen van informatiesystemen en gegevens.

Criterium

De leverancier dient te borgen dat wijzigingen in (web)applicaties op een beheerste en gecontroleerde wijze plaatsvinden.

Doelstelling

Compliance met dit criterium zorgt dat zo min mogelijk verstoringen optreden als gevolg van wijzigingen aan de (web)applicaties.

/01

wijzigingen

/01.01

De leverancier heeft een proces voor het beheren van wijzigingen in de (web)applicaties.

/01.02

Het proces voor wijzigingenbeheer voor (web)applicaties omvat: Het bijhouden van een registratie van de overeengekomen autorisatieniveaus; Het borgen dat wijzigingen alleen worden doorgevoerd in opdracht van bevoegde gebruikers; Het identificeren van alle programmatuur, informatie, databases en apparatuur die wijziging behoeven; Het beoordelen van beheersmaatregelen en integriteitsprocedures om te voorkomen deze door de wijzigingen worden gecompromitteerd; Het vooraf door de bevoegde gebruikers laten goedkeuren van de wijzigingen; Het bijwerken van de systeemdocumentatie na elke wijziging en het archiveren of verwijderen van oude documentatie; Het uitvoeren van versiebeheer voor alle wijzigingen op programmatuur; Het bijhouden van een ‘audit trail’ van alle wijzigingsaanvragen; Het aanpassen van de bedrijfsdocumentatie en gebruikersprocedures, voor zover noodzakelijk om toepasbaar te blijven;

34 van 55


Het waarborgen dat de implementatie van wijzigingen op het juiste moment plaatsvindt en de betrokken bedrijfsprocessen niet verstoort. /01.03 Referentie

De leverancier maakt aantoonbaar dat het proces voor de beheersing van wijzigingen in de (web)applicaties effectief is. NCSC

NIST

ISO27002 12.5.1

35 van 55


4.1.4.

SDW-4: Wijzigingenbeheer voor middleware en platformen SDW-4

Wijzigingenbeheer voor middleware en platformen

Context

Bij wijzigingen in middleware en platformen moeten bedrijfskritische toepassingen worden beoordeeld en getest om te voorkomen dat er nadelige gevolgen optreden voor de bedrijfsprocessen of voor de beveiliging van gegevens.

Risico

Een onbeheerste wijziging kan de beschikbaarheid, integriteit en vertrouwelijkheid in gevaar brengen.

Criterium

De hostingpartij dient te borgen dat wijzigingen in middleware en platformen geen negatieve effecten hebben op bedrijfskritische toepassingen.

Doelstelling

Compliance met dit criterium zorgt dat zo min mogelijk verstoringen optreden als gevolg van wijzigingen aan de middleware en platformen.

/01

wijzigingen

/01.01

De hostingpartij heeft een proces voor het beheren van wijzigingen in de middleware en platformen.

/01.02

Het proces voor wijzigingenbeheer voor middleware en platformen omvat: Het vooraf beoordelen dat de werking van (web)applicaties niet zal worden verstoord door de wijzigingen; Het tijdig aankondigen van wijzigingen, zodat de noodzakelijke tests en beoordelingen kunnen worden uitgevoerd voordat de wijzigingen worden geïmplementeerd; Het aanbrengen van de relevante wijzigingen in de plannen voor bedrijfscontinuïteit.

/01.03 Referentie

De hostingpartij maakt aantoonbaar dat het proces voor de beheersing van wijzigingen in de middleware en platformen effectief is. NCSC

NIST

ISO27002 12.5.2

36 van 55


4.1.5.

SDW-5: Comments SDW-5

Comments

Context

Het gebruik van commentaarregels in scripts is normaal gedurende de ontwikkelen testfase, maar is ongewenst in een productieomgeving omdat de commentaarregels onnodig informatie vrijgeven aan buitenstaanders. Application-level firewalls zijn in staat om commentaarregels uit HTML- en scriptcode te verwijderen en zodoende ‘gefilterde’ antwoorden terug te geven aan de client.

Risico

Indien commentaarregels beschikbaar worden gesteld aan de gebruiker, bestaat de mogelijkheid dat een kwaadwillende deze informatie benut om zwakheden op te sporen.

Criterium

De (web)applicatie dient geen commentaarregels te tonen aan de gebruikers.

Doelstelling

Compliance met dit criterium zorgt dat zo min mogelijk inhoudelijke informatie over de (web)applicatie naar buiten lekt, zodat een aanvaller daar geen misbruik van kan maken.

/01

commentaarregels

/01.01

De leverancier verwijdert alle commentaarregels uit de voor de gebruiker zichtbare code.

/01.02

De leverancier laat een scan uitvoeren op de scripts voordat deze in de productieomgeving worden geplaatst, ter verificatie dat alle commentaarregels zijn verwijderd.

/01.03

De application level firewall is zo geconfigureerd dat commentaarregels uit de HTML- en scriptcode worden verwijderd en een gefilterd antwoord wordt teruggegeven aan de client.

Referentie

NCSC B3-11

NIST

ISO27002

37 van 55


4.2. OTAP en testen 4.2.1.

SDW-6: Scheiding in OTAP-omgevingen SDW-6

Scheiding in OTAP-omgevingen

Context

Voor de verschillende soorten werkzaamheden binnen het voortbrengingsproces worden verschillende omgevingen ingericht, zoals voor ontwikkelen, testen en accepteren. Deze worden veelal gescheiden ten opzichte van elkaar en ten opzichte van de omgeving voor productie.

Risico

Ontwikkel- en testactiviteiten kunnen onbedoelde wijzigingen in software en gegevens veroorzaken als dezelfde IT-omgeving wordt gedeeld. Als ontwikkelen testmedewerkers toegang hebben tot de productieomgeving en productiegegevens, kunnen zij ongeoorloofde en niet geteste software invoeren of productiegegevens wijzigen.

Criterium

De leverancier dient de omgevingen voor Ontwikkel, Test en Acceptatie te scheiden van de omgevingen voor Productie (OTAP).

Doelstelling

Compliance met dit criterium zorgt dat het risico van onbedoelde wijzigingen of ongeautoriseerde toegang tot productiesystemen en bedrijfsgegevens wordt verkleind.

/01

OTAP

/01.01

De leverancier zorgt voor gescheiden omgevingen voor Ontwikkel, Test, Acceptatie en Productie, voor zover noodzakelijk gezien de gebruikte ontwikkelmethodiek, het belang van de (web)applicatie en de daarmee verwerkte gegevens.

/01.02

De leverancier bepaalt welke hulpmiddelen voor ontwikkelen, debuggen, patchen, testen etc. zijn toegestaan in welke omgeving.

/01.03

De leverancier borgt dat in de omgevingen voor Acceptatie en Productie geen hulpmiddelen aanwezig zijn die schade toe kunnen brengen aan de software of productiegegevens.

/02

scheiden

/02.01

De leverancier bepaalt of de omgevingen logisch of fysiek moeten worden gescheiden.

/02.02

De leverancier bepaalt per omgeving welke medewerkers toegang nodig hebben en beperkt de toegang tot deze medewerkers.

/02.03

De leverancier borgt de vereiste scheiding tussen de omgevingen en maakt aantoonbaar dat deze effectief is.

Referentie

NCSC BO-6

NIST

ISO27002 10.1.4

38 van 55


4.2.2.

SDW-7: Transport tussen OTAP-omgevingen SDW-7

Transport tussen OTAP-omgevingen

Context

In de omgeving voor Acceptatie wordt vastgesteld of de software voldoet aan de specificaties voor functionaliteit en kwaliteit, en of deze veilig is en geen schadelijke of frauduleuze onderdelen bevat. De aanpak via OTAP fungeert als een filter om mogelijke dreigingen vanuit de ontwikkelomgeving of testomgeving te mitigeren.

Risico

Indien er onvoldoende grip is op de transportstromen binnen de omgevingen voor OTAP, kunnen virussen, malware, Trojans en andere schadelijke vormen van software worden doorgegeven aan de omgevingen voor Productie.

Criterium

De leverancier dient te transporten te beheersen binnen de diverse omgevingen van de OTAP.

Doelstelling

Compliance met dit criterium zorgt dat schadelijke of frauduleuze software vanuit de ontwikkelomgeving zoveel mogelijk wordt onderschept en niet doordringt tot productiesystemen en bedrijfsgegevens.

/01

transporten

/01.01

De leverancier zorgt dat procedures zijn vastgesteld en gedocumenteerd voor het overdragen van software en gegevens van de ene naar de andere omgeving.

/01.02

De leverancier maakt aantoonbaar dat er geen ongeautoriseerde transporten plaatsvinden aan de hand van autorisaties, vastleggingen en rapportages over de wijzigingen in de relevante omgevingen en de transporten.

Referentie

NCSC BO-6

NIST

ISO27002 10.1.4

39 van 55


4.2.3.

SDW-8: Representatieve testsets SDW-8

Representatieve testsets

Context

Voordat een (web)applicatie in productie wordt genomen, is het van belang dat eerst een uitgebreide test wordt uitgevoerd op de (web)applicatie en de omliggende infrastructuur. Hierbij moeten alle aspecten worden meegenomen die volgen uit de risicoanalyse en risico-evaluatie, zoals relevante attack patterns en abuse cases, en de normatiek die in dit boek is beschreven voor veilige (web)applicaties. Al deze aspecten dienen terug te komen in de representatieve testset die wordt gebruikt bij acceptatie.

Risico

Wijzigingen kunnen een onvoorziene negatieve impact hebben op de werking van de infrastructuur en de (web)applicaties.

Criterium

De leverancier dient een wijziging in een (web)applicatie eerst met een representatie testset in een representatieve testomgeving te accepteren, voordat de wijziging in een productieomgeving wordt toegepast.

Doelstelling

Compliance met dit criterium zorgt dat wordt geverifieerd dat de (web)applicaties en de infrastructuur, na het effectueren van een wijziging, goed en veilig blijven functioneren.

/01

accepteren

/01.01

De leverancier stelt acceptatiecriteria op voor nieuwe (web)applicaties.

/01.02

De leverancier zorgt voor een representatieve testomgeving.

/01.03

De leverancier zorgt dat gevoelige gegevens niet worden gebruikt voor het testen.

/01.04

De leverancier zorgt dat de (web)applicatie wordt getest voordat deze in de productie wordt genomen, maar eerst onherleidbaar worden gemaakt.

/01.05

De leverancier legt vast: De datasets en testscripts die worden gebruikt om de tests uit te voeren; De resultaten van de uitgevoerde tests.; De autorisatie dat de tests met goed gevolg zijn doorlopen en dat de wijziging in productie mag worden genomen.

/01.06

Referentie

De leverancier maakt aantoonbaar dat er geen ongeautoriseerde wijzigingen plaatsvinden aan de hand van autorisaties, vastleggingen en rapportages. NCSC BO-6

NIST

ISO27002 10.1.2 12.5.1

40 van 55


5.

Beveiligingseisen voor de infrastructuur voor de (web)applicaties

5.1. Hardware en software instellingen en configuratie 5.1.1.

SIN-1: Scheiding van Presentatie, Applicatie en Gegevens SIN-1

Scheiding van Presentatie, Applicatie en Gegevens

Context

Door compartimentering of gelaagdheid toe te passen in de architectuur van (web)applicaties, wordt voorkomen dat het compromitteren van een server, applicatie of toepassing in één compartiment, directe gevolgen heeft voor servers, (web)applicaties en toepassingen in een ander compartiment. Binnen de architectuur worden de buitenwereld, de presentatielaag, de applicatielaag en de gegevens zoveel mogelijk van elkaar gescheiden.

Risico

Bij onvoldoende compartimentering of gelaagdheid heeft een aanvaller, die zich toegang weet te verschaffen tot de presentatielaag, ook direct toegang heeft tot de gegevens.

Criterium

De architectuur voor (web)applicaties dient te zijn ontwikkeld volgens een gelaagde structuur voor de presentatielaag, de applicatielaag en de gegevens.

Doelstelling

Compliance met dit criterium zorgt dat er meerdere barrières zijn tussen de buitenwereld en de gegevens.

/01

gelaagde structuur

/01.01

De opdrachtgever bepaalt de structuur voor de gelaagdheid.

/01.02

Gegevens dienen bij voorkeur buiten de DMZ te worden opgeborgen binnen het beschermde interne netwerk, met uitzondering van de gegevens die de (web)applicatie direct nodig heeft binnen de DMZ.

Referentie

NCSC

NIST

ISO27002

41 van 55


5.1.2.

SIN-2: Netwerkzonering SIN-2

Netwerkzonering

Context

De Demilitarized Zone (DMZ) is een bufferzone die interne systemen beschermt tegen dreigingen vanuit de buitenwereld. Via de DMZ wordt al het netwerkverkeer van en naar internet gecontroleerd.

Risico

Indien er sluipwegen bestaan naast de DMZ, worden dreigingen vanuit de buitenwereld direct manifest voor de interne systemen en gegevens.

Criterium

De DMZ dient de enige verbinding te zijn tussen het internet en het interne netwerk, en al het netwerkverkeer van en naar het internet dient via deze DMZ te lopen.

Doelstelling

Compliance met dit criterium zorgt dat alle verkeersstromen met internet kunnen worden bewaakt.

/01

DMZ

/01.01

De uitgangspunten en principes die gelden voor de toepassing van de DMZ zijn vastgelegd in een inrichtingsdocument.

/01.02

Het inrichtingsdocument voor de DMZ besteedt in ieder geval aandacht aan: Hoe het webverkeer verloopt; De toegepaste routepaden om het verkeer door de DMZ te kunnen routeren; De toegepaste beheermechanismen.

/01.03

De filters en regels binnen een DMZ zijn geconfigureerd conform het ontwerp van de DMZ en op basis van door de hostingpartij gespecificeerde configuratietemplates.

/01.04

De hostingpartij zorgt dat de rules voor de DMZ-componenten (firewalls) steeds up-to-date zijn.

/02

netwerkverkeer

/02.01

Alle verkeersstromen tussen interne netwerken en externe netwerken lopen via een DMZ en worden daar gecontroleerd en bij voorkeur ontkoppeld op applicatieniveau (sessiescheiding).

/02.02

Tussen zones lopen alleen de verkeersstromen die noodzakelijk zijn voor de beoogde diensten.

/02.03

De hostingpartij zorgt via hulpmiddelen, zoals IDS en IPS, dat de DMZ voortdurend wordt bewaakt en dat bij aanvallen wordt ingegrepen.

Referentie

NCSC B1-1

NIST

ISO27002

42 van 55


5.1.3.

SIN-3: Hardening van technische componenten SIN-3

Hardening van technische componenten

Context

(Web)applicaties gebruiken technische componenten, die diverse toegangsfaciliteiten leveren. Iedere toegang die actief is biedt een potentiële mogelijkheid van gebruik of misbruik. Met technische componenten worden hier bedoeld computers, servers (denk aan DNS-severs, mail-servers, webservers etc.), (web)applicaties, netwerkcomponenten zoals routers en switches, databases, firewalls en telefoonsystemen (VOIP). De betrokken partijen zijn de leverancier van de (web)applicatie en de hostingpartij.

Risico

Via een ongecontroleerde toegangsfaciliteit kan de (web)applicatie bedoeld en onbedoeld negatief worden beïnvloed, waardoor de vertrouwelijkheid, integriteit of beschikbaarheid van de functionaliteit of gegevens niet kan worden geborgd.

Criterium

Technische componenten dienen te zijn gehardend en dienen up-todate zijn op basis van hardeningsrichtlijnen en het patch-beleid.

Doelstelling

Compliance met dit criterium zorgt dat ICT-componenten zijn beveiligd tegen misbruik via zwakheden in ongebruikte functionaliteit.

/01

gehardend

/01.01

Op de technische componenten zijn alleen de noodzakelijke toegangsfaciliteiten actief, zoals services, netwerkprotocollen en poorten. De overige toegangsfaciliteiten zijn uitgeschakeld.

/01.02

De ontwerper gebruikt alleen veilige protocollen.

/02

hardeningsrichtlijnen

/02.01

De hostingpartij zorgt voor een hardeningstemplate waarin is vastgelegd welke services, netwerkprotocollen en poorten standaard beschikbaar zijn en welke zijn uitgeschakeld. Tevens wordt in de template aangegeven of en, zo ja, welke antivirus, antispyware, antispam en antiphishing software, en een lokale firewall nodig is.

/02.02

De hostingpartij neemt de gehardende componenten op in de periodieke vulnerability en compliance scans.

/02.03

De hostingpartij heeft een proces om afwijkingen op de hardeningstemplate te beoordelen, te accorderen en te borgen.

/02.04

De leverancier van de (web)applicatie geeft aan welke services, netwerkprotocollen en poorten benodigd zijn voor de goede werking van de applicatie.

/02.05

Indien meer toegangsfaciliteiten nodig zijn dan de hardeningstemplate levert, dient een afwijking op de template te worden aangevraagd voor de betreffende (web)applicatie.

43 van 55


/03

patch-beleid

/03.01

De hostingpartij maakt het patchbeleid inzichtelijk voor de opdrachtgever en rapporteert over het patchlevel en de aangebrachte patches.

/03.02

De hostingpartij zorgt dat de beveiligingspatches tijdig zijn geïnstalleerd.

/03.03

De hostingpartij zorgt dat de patchlevels actueel zijn.

Referentie

NCSC B0-6 B0-7

NIST

ISO27002

44 van 55


5.1.4.

SIN-4: Standaard stack SIN-4

Standaard stack

Context

De opdrachtgever specificeert de te gebruiken stack, namelijk de hardwarematige en softwarematige componenten en de toegestane onderhoudsniveaus, voor de ondersteuning van (web)applicaties. Stack is een manier om de verschillende lagen van componenten en services te beschrijven die worden gebruikt bij een softwarematige oplossing. De leverancier mag voor de ontwikkeling van een (web)applicatie alleen gebruik maken van systeemcomponenten, zoals platformen en middleware, die formeel zijn goedgekeurd en adequaat worden ondersteund. Verouderde beveiligingsstandaarden bieden namelijk verminderde bescherming tegen bedreigingen.

Risico

Het gebruik van ‘out of support’ hardware en software resulteert in beveiligingslekken door het gebrek aan ondersteuning en patches. Het gebruik van afwijkende componenten levert risico’s omdat deze mogelijk niet passen bij de te hanteren beveiligingsmaatregelen voor de stack.

Criterium

De leverancier dient alleen gebruik te maken van systeemcomponenten die formeel onderdeel zijn van de door de opdrachtgever gespecificeerde stack.

Doelstelling

Compliance met dit criterium zorgt dat integrale beveiliging mogelijk is om adequate bescherming te bieden tegen de actuele bedreigingen.

/01

systeemcomponenten

/01.01

De leverancier maakt uitsluitend gebruik van systeemcomponenten die zijn opgenomen in de stack.

/01.02

De leverancier maakt gebruik van de laatste beveiligingsmaatregelen, beleid en procedures.

/01.03

De leverancier onderbouwt en documenteert afwijkingen op de stack en laat dergelijke afwijkingen goedkeuren door de opdrachtgever.

Referentie

NCSC

NIST CA-1

ISO27002 6.1.4 10.3.2 15.1.1

45 van 55


5.1.5.

SIN-5: Beveiliging van Mobile code SIN-5

Beveiliging van mobile code

Context

Mobile code is programmatuur die kan worden overgedragen van de ene naar de andere computer, automatisch wordt uitgevoerd en een specifieke functie verricht zonder of met weinig tussenkomst van de gebruiker. Voorbeelden zijn ActiveX, Applets, Flash etc. Mobile code werkt samen met een aantal middelware diensten.

Risico

Mobile code, zoals plugins, kan virussen en malware bevatten. Zonder een beveiligingsmechanisme kan een (web)applicatie kwetsbaar zijn voor verscheidene vormen van aanvallen en virussen via mobile code.

Criterium

(Web)applicaties dienen te zijn beveiligd tegen ongeautoriseerde mobile code.

Doelstelling

Compliance met dit criterium zorgt dat enkel ondertekende code wordt gebruikt, waarbij de bron wordt geverifieerd en het risico op kwaadaardige code wordt beperkt.

/01

beveiliging

/01.01

De opdrachtgever stelt richtlijnen op voor het gebruik van mobile code bij (web)applicaties en informatiesystemen.

/01.02

De leverancier volgt de richtlijnen voor mobile code.

/01.03

De (web)applicatie gebruikt alleen vertrouwde en ondertekende mobile code.

Referentie

NCSC

NIST SC-18

ISO27002 10.4.1 10.4.2

46 van 55


5.1.6.

SIN-6: Data versleuteling SIN-6

Data versleuteling

Context

Gegevens van een (web)applicatie, zoals gebruikersgegevens, operationele gegevens en transacties, worden soms op een webserver opgeslagen. Als deze gegevens vertrouwelijk zijn, moeten deze worden beschermd tegen lezen en schrijven door legale of illegale gebruikers op die webserver.

Risico

Zonder versleuteling bestaat het risico van ongeautoriseerde onthulling of mutatie van de opgeslagen vertrouwelijke gegevens door legale of illegale gebruikers van de webserver.

Criterium

De (web)applicatie dient op veilige wijze haar vertrouwelijke gegevens op te slaan op de webserver.

Doelstelling

Compliance met dit criterium zorgt dat de vertrouwelijkheid en de integriteit van vertrouwelijke gegevens van een (web)applicatie worden geborgd.

/01

veilige wijze

/01.01

De opdrachtgever specificeert welke cryptografische technieken als veilig worden bestempeld voor opslag van gegevens op een webserver.

/01.02

De opdrachtgever specificeert op welke wijze het sleutelbeheer wordt ingericht voor versleutelde gegevens op de webserver.

/02

op te slaan

/02.01

De opdrachtgever specificeert welke typen gegevens vertrouwelijk zijn en moeten worden versleuteld tijdens de opslag op een webserver.

/02.02

De (web)applicatie versleutelt de opgeslagen vertrouwelijke gegevens met de voorgeschreven cryptografische techniek.

Referentie

NCSC B5-3

NIST SC-8 SC-9 SC-13

ISO27002 10.6.1 10.8.1 10.9.1

47 van 55


5.1.7.

SIN-7: Directory listing SIN-7

Directory listing

Context

Via een zogenaamde directory listing kan een gebruiker via internet de inhoud van een directory bekijken. Het opvragen van een directory listing via internet komt overeen met het lokaal uitvoeren van een dir commando in Windows of ls commando in Unix of Linux. Indien de interne listing van een directory inzichtelijk is voor de gebruiker, kan de gebruiker deze informatie benutten om verdere informatie te bemachtigen. De toegang tot bestanden in directories moet altijd verlopen via de (web)applicatie. De (web)applicatie bepaalt de paden voor bestanden die de gebruiker rechtstreeks mag benaderen, bijvoorbeeld voor afbeeldingen, en fungeert als medium voor bestanden die de gebruiker niet rechtstreeks mag benaderen, zoals gegevensbestanden.

Risico

Zodra een webserver de mogelijkheid biedt om directory-listings uit te voeren, bestaat de mogelijkheid dat een kwaadwillende de inhoud van vertrouwelijke directories raadpleegt, zoals de /etc/ directory op UNIX en Linux.

Criterium

De webserver dient interne informatie niet te tonen aan gebruikers, zoals directory listings.

Doelstelling

Compliance met dit criterium zorgt dat een buitenstaander geen kennis kan nemen van wat in de directories van de webserver is opgeslagen.

/01

directory listings

/01.01

De hostingpartij schakelt de directory listings uit, tenzij er bewust voor deze functionaliteit is gekozen.

/01.02

De hostingpartij legt in de configuratiedocumentatie vast hoe directory listings zijn uitgeschakeld. Indien de functionaliteit die directory listing biedt noodzakelijk is, dient dit expliciet in de configuratiedocumentatie te zijn aangegeven.

/01.03

De toegang tot bestanden in directories moet altijd verlopen via de (web)applicatie.

Referentie

NCSC B3-13

NIST

ISO27002

48 van 55


5.2. Veilige HTTP-sessies 5.2.1.

SIN-8: Gebruik van veilige cookies SIN-8

Gebruik van veilige cookies

Context

De webapplicatie verschaft zichzelf toegang tot een of meer cookies op het werkstation. Zo een cookie bevat een verzameling van voorgaande handelingen van de webapplicatie of de gebruiker op het werkstation. De flag ‘HttpOnly’ op een cookie zorgt ervoor dat de cookie uitsluitend via een HTTP en HTTPS verbindingen kan worden gebruikt en niet via bijvoorbeeld java scripts. De flag ‘secure’ limiteert de communicatie van cookies tot een beveiligde verbinding via HTTPS en voorkomt dat de inhoud van een cookie voor onbevoegden zichtbaar wordt. De inhoud van een cookie kan worden versleuteld, waarbij de sleutel alleen bekend mag zijn bij de webapplicatie.

Risico

Indien deze flags niet worden gebruikt kan de werking van de webserver of webapplicatie worden gemanipuleerd, waardoor deze onder controle kan komen van een aanvaller. Indien vertrouwelijke gegevens niet worden versleuteld, kunnen die ongeautoriseerd worden onthuld of gemanipuleerd.

Criterium

De webapplicatie dient alleen cookies te genereren die veilig kunnen worden gebruikt en veilig omgaan met vertrouwelijke gegevens.

Doelstelling

Compliance met dit criterium zorgt dat inzage, wijziging of verlies van gegevens door manipulatie van de logica van een cookie wordt voorkomen. Hierdoor kunnen zowel de gebruiker als ook een kwaadwillende vrijwel niets met het cookie.

/01

gebruikt

/01.01 /02

Alle cookies worden voorzien van de flag ‘HttpOnly’ en bij gebruik van HTTPS tevens van de flag ‘secure’. vertrouwelijke gegevens

/02.01

De opdrachtgever specificeert de classificatie van de gegevens in de cookie.

/02.02

De leverancier legt in een inrichtingsdocument of in het ontwerp vast welke uitgangspunten gelden voor het versleutelen van de gegevens in een cookie.

/02.03

Vertrouwelijke gegevens in een cookie worden versleuteld met een sleutel die alleen bekend is bij de webapplicatie.

Referentie

NCSC B3-16 B5-4

NIST

ISO27002

49 van 55


5.2.2.

SIN-9: Sessie versleuteling SIN-9

Sessie versleuteling

Context

Het versleutelen van een sessie beschermt de gegevens die worden getransporteerd tussen een (web)applicatie en het werkstation van de gebruiker.

Risico

Zonder versleuteling bestaat het risico van ongeautoriseerde onthulling of mutatie van gegevens, door ongewenste handelingen op tussenliggende componenten tijdens het transport.

Criterium

De (web)applicatie dient op veilige wijze met de eindgebruiker te communiceren.

Doelstelling

Compliance met dit criterium zorgt dat de vertrouwelijkheid, de integriteit en eventueel de onweerlegbaarheid van gegevensleveringen of transacties wordt geborgd.

/01

veilige wijze

/01.01

De opdrachtgever specificeert welke protocollen als veilig worden bestempeld, gezien de gebruikte cryptografische techniek.

/01.02

De opdrachtgever specificeert op welke wijze het beheer van sleutels en certificaten wordt ingericht voor gebruikte cryptografische techniek.

/02

communiceren

/02.01

De opdrachtgever specificeert welke typen sessies via een beveiligd protocol, zoals HTTPS, dienen te verlopen.

/02.02

De (web)applicatie versleutelt de communicatie tussen de browser van de eindgebruiker en de (web)applicatie met de voorgeschreven cryptografische techniek, inclusief eventuele privacygevoelige informatie in URL’s.

Referentie

NCSC B5-2

NIST SC-8 SC-9 SC-13

ISO27002 10.6.1 10.8.1 10.9.1

50 van 55


5.2.3.

SIN-10: HTTP validatie SIN-10

HTTP validatie

Context

De webapplicatie ontvangt invoer van de gebruiker en van andere (web)applicaties. Hierbij is een belangrijke vuistregel dat de webapplicatie geen enkele invoer mag vertrouwen. De webapplicatie moet ‘defensief’ worden geprogrammeerd, waarbij alle via HTTP-requests ontvangen inhoud eerst wordt gevalideerd, alvorens die wordt gebruikt.

Risico

Zonder validatie van de ontvangen inhoud kunnen kwaadwillenden kwetsbaarheden benutten om gegevens te bemachtigen, te muteren of toe te voegen.

Criterium

De webapplicatie dient de inhoud van een HTTP-request te valideren alvorens die te gebruiken.

Doelstelling

Compliance met dit criterium zorgt dat alleen gecontroleerde invoer wordt verwerkt.

/01

valideren

/01.01

De webapplicatie controleert de correcte authenticatie en autorisatie van de initiator van een HTTP-request.

/01.02

De webapplicatie controleert een HTTP-request op type, lengte, formaat, karakters en patronen.

/01.03

De webapplicatie controleert de binnenkomende: URL’s; Query parameters (variabelen die de client via een GET doorgeeft); Form parameters (variabelen die de client via een POST doorgeeft); Cookies; HTTP-headers; XML (hieronder vallen ook protocollen zoals SOAP, JSON en REST); Bestanden.

/01.04 Referentie

De webapplicatie verwijdert ongewenste invoer en maakt risicovolle karakters uit de invoer onschadelijk. NCSC

NIST SC-2

ISO27002 11.4.5

51 van 55


5.2.4.

SIN-11: Beperking van te versturen HTTP-headers SIN-11

Beperking van te versturen HTTP-headers

Context

Een HTTP-header bevat informatie die de gebruiker identificeert. Als de webserver antwoord geeft aan de gebruiker en daarbij de HTTPheader kopieert, wordt soms privacygevoelige informatie meegestuurd met het antwoord. Het lekken van informatie moet zoveel mogelijk worden voorkomen. Middels HTTP-headers kan onnodig informatie worden vrijgegeven. Het gebruik van de volledige HTTP-header dient daarom waar mogelijk te worden beperkt. Hoe bij beantwoording delen van informatie uit een HTTP-header kunnen worden verwijderd, is afhankelijk van het gebruikte type webserver.

Risico

Als het antwoord van de webapplicatie teveel informatie bevat, kan dit de privacy van de gebruiker schaden.

Criterium

De webserver dient bij een antwoord aan een gebruiker alleen de HTTP-headers mee te sturen die van belang zijn voor het functioneren van de (web)applicatie.

Doelstelling

Compliance met dit criterium zorgt dat zo min mogelijk overbodige informatie wordt opgenomen in een antwoord aan gebruikers.

/01

HTTP-headers

/01.01

De leverancier legt in de ontwerpdocumentatie vast welke HTTPheaders worden gebruikt door de webapplicatie en hoe HTTP-headers uit de antwoorden worden verwijderd.

/01.02

De hostingpartij legt in de configuratiedocumentatie vast welke HTTPheaders worden gebruikt door de webserver en hoe HTTP-headers uit de antwoorden worden verwijderd.

/01.03

De leverancier onderbouwt en beschrijft eventuele noodzakelijke afwijkingen van de standaard configuratie op de webserver, die nodig zijn voor het goed functioneren van de webapplicatie.

/01.04

De webserver selecteert de informatie uit een HTTP-header die van belang is om een antwoord te kunnen geven aan de gebruiker.

/01.05

De webserver verwijdert alle niet noodzakelijke informatie uit de HTTP-header, alvorens deze voor het antwoord te gebruiken.

Referentie

NCSC B3-8

NIST

ISO27002

52 van 55


5.2.5.

SIN-12: Beperken van te tonen HTTP-header informatie SIN-12

Beperken van te tonen HTTP-header informatie

Context

Als een webserver antwoord geeft aan een gebruiker, staat er soms te veel informatie in de HTTP-header. Overbodige technische informatie, zoals het type webserver of een versienummer, kan worden misbruikt door een kwaadwillende. Het is voor een client niet van belang om te weten welk type webserver antwoord heeft gegeven op het HTTP-request. In dit kader kan bijvoorbeeld de ‘Server’-header uit het antwoord worden verwijderd of worden vervangen door een nietszeggende inhoud.

Risico

Gedetailleerde informatie over de technische inrichting van de webserver kan worden misbruikt door aanvallers.

Criterium

De webapplicatie dient alleen noodzakelijke informatie in HTTPheaders te tonen, die van belang is voor het functioneren van HTTP.

Doelstelling

Compliance met dit criterium zorgt dat overbodige technische informatie in een antwoord wordt verwijderd, zodat een aanvaller daar geen misbruik van kan maken.

/01

HTTP-headers

/01.01

De leverancier legt in de ontwerpdocumentatie vast hoe overbodige informatie uit antwoorden wordt verwijderd of tot een minimum wordt beperkt door de webapplicatie.

/01.02

De hostingpartij legt in de configuratiedocumentatie vast hoe overbodige informatie uit antwoorden wordt verwijderd of tot een minimum wordt beperkt door de webserver.

/01.03

De leverancier onderbouwt en beschrijft eventuele noodzakelijke afwijkingen van de standaard configuratie op de webserver, die nodig zijn voor het goed functioneren van de webapplicatie.

/01.04

De webserver verwijdert de ‘Server’-header uit het antwoord of vult hiervoor een nietszeggende inhoud in.

Referentie

NCSC B3-9

NIST

ISO27002

53 van 55


5.2.6.

SIN-13: HTTP methoden SIN-13

HTTP methoden

Context

HTTP 1.1 en 2.0 ondersteunen verschillende functionaliteiten. In de praktijk gebruikt een webapplicatie alleen de functies GET en POST. Voor veel scripts en objecten geldt zelfs dat alleen de GET nodig is. De overige functionaliteiten zijn vrijwel nooit nodig binnen traditionele webapplicaties en vormen een extra beveiligingsrisico. Het is aan te raden om alle niet benodigde functionaliteiten via de configuratie van de webserver of via de application-level firewall te blokkeren.

Risico

Kwaadwillenden kunnen via de overtollige technische informatie uit HTTP-verkeer potentiële zwakheden vinden en deze misbruiken.

Criterium

De webserver dient alleen gebruik te maken van de HTTPfunctionaliteiten die nodig zijn voor het functioneren van de webapplicatie.

Doelstelling

Compliance met dit criterium zorgt dat zo min mogelijk technische informatie over de configuratie van de webserver naar buiten lekt, zodat een aanvaller daar geen misbruik van kan maken.

/01

HTTP-functionaliteiten

/01.01

De hostingpartij legt in de configuratiedocumentatie vast hoe de webserver is geconfigureerd om alleen noodzakelijke functionaliteiten toe te staan.

/01.02

De hostingpartij legt in de configuratiedocumentatie vast op welke wijze de application-level firewall is geconfigureerd om niet noodzakelijke functionaliteiten te blokkeren.

/01.03

De leverancier onderbouwt en beschrijft eventuele noodzakelijke afwijkingen van de standaard configuratie op de webserver en de application-level firewall, die nodig zijn voor het goed functioneren van de webapplicatie.

/01.04

Op de webserver worden, indien mogelijk, alleen de GET en POST geactiveerd.

Referentie

NCSC B3-12

NIST

ISO27002

54 van 55


Colofon Uitgever Auteurs Status Datum Versie Document

CIP Ronald Paans / Noordbeek Wiekram Tewarie / UWV Marcel Koers / UWV CIP categorie ‘Becommentarieerde Practice’ 10 januari 2014 1.00 Grip op SSD SIVA Beveiligingseisen

55 van 55

Grip op Secure Software Development (SSD) SIVA Beveiligingseisen. voor (web)applicaties

Recommend Documents