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

Transcriptie

1 Grip op Secure Software Development (SSD) voor (web)applicaties Versie: 1.00 Opdrachtgever A. Reuijl CIP Auteur R. Paans Noordbeek W. Tewarie UWV M. Koers UWV Rapportnummer UWVSSD4-2 Classificatie Publiek CIP-becommentarieerde praktijk Datum 10 januari 2014 Filenaam Grip op SSD Tenzij anders vermeld valt dit werk onder een Creative Commons Naamsvermelding-GelijkDelen 4.0 Internationaal-licentie. 1 van 55

2 Inhoud 1. Inleiding De scope: (Web)applicaties De drie domeinen Comply or Explain De actoren Verantwoordelijkheid van de software leverancier Controle en toezicht, aanpak en verantwoordelijkheden SIVA-syntax voor de beveiligingseisen Beveiligingseisen voor de (web)applicatie Beheersbaarheid en beveiliging van de (web)applicatie SWA-1: beheer SWA-2: Gegevensclassificatie SWA-3: Functiescheiding SWA-4: Least Privilege SWA-5: Onweerlegbaarheid SWA-6: (Web)applicatie logging SWA-7: Borgen van Sessie Authenticiteit SWA-8: Concurrent Session Control SWA-9: Session lock SWA-10: Session termination Identificatie, authenticatie en toegangsbeheersing SWA-11: De identiteit van een externe gebruiker vaststellen SWA-12: De identiteit van een interne gebruiker vaststellen SWA-13: Registreren van Unsuccessful Login Attempts SWA-14: System Use Notification SWA-15: Beheerinterface Veilige invoer en uitvoer SWA-16: Invoer validatie SWA-17: Invoer normalisatie SWA-18: Geparameteriseerde queries SWA-19: File includes SWA-20: Codering van dynamische onderdelen SWA-21: Error handling Beveiligingseisen voor het voortbrengingsproces Het voortbrengingsproces SDW-1: Screening SDW-2: Integriteit van de broncode SDW-3: Wijzigingenbeheer voor (web)applicaties SDW-4: Wijzigingenbeheer voor middleware en platformen SDW-5: Comments OTAP en testen van 55

3 SDW-6: Scheiding in OTAP-omgevingen SDW-7: Transport tussen OTAP-omgevingen SDW-8: Representatieve testsets Beveiligingseisen voor de infrastructuur voor de (web)applicaties Hardware en software instellingen en configuratie SIN-1: Scheiding van Presentatie, Applicatie en Gegevens SIN-2: Netwerkzonering SIN-3: Hardening van technische componenten SIN-4: Standaard stack SIN-5: Beveiliging van Mobile code SIN-6: Data versleuteling SIN-7: Directory listing Veilige HTTP-sessies SIN-8: Gebruik van veilige cookies SIN-9: Sessie versleuteling SIN-10: HTTP validatie SIN-11: Beperking van te versturen HTTP-headers SIN-12: Beperken van te tonen HTTP-header informatie SIN-13: HTTP methoden van 55

4 1. Inleiding Dit document beschrijft een aantal standaard beveiligingseisen die van toepassing zijn bij de ontwikkeling en aanschaf van (web)applicaties 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 DMZ Server LAN Internet Buitenwereld Webhosting omgeving Reguliere infrastructuur SSD 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

5 1.2. De drie domeinen Voor de beveiligingseisen wordt de onderstaande driedeling gehanteerd: (Web)applicaties en hun context Domein X Voortbrengingsproces Leveranciersmanagement Diensten Ontwikkeling & Onderhoud Arch Klant bedrijfsprocessen OTAP IA DS FO TO Bouw Test Accep Web applicaties WAARDE Financieel Privacygevoelig Vertrouwelijk IT diensten Applicaties GEGEVENS Klanten en partners van de klant Netwerk Operating Centrum Functioneel & Technisch Beheer AV Infrastructuur Kantoor Automatisering & Mobiel Data DMZ Netwerk (WAN en LAN s) IDS & IPS APP APP MW MW AC AV AC OS OS HW HW Internet Buitenwereld Koppelingen Partners Rekencentra Storage Storage SSD 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

6 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

7 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 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 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

8 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 Doelstelling Maatregelen Referenties Naam Een beschrijving van het mechanisme. Een beschrijving van mogelijk misbruik of schade. De norm, namelijk wie en wat. Het gewenste resultaat, namelijk waarom. De mogelijke maatregelen, namelijk het hoe. 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 SP Recommended Security Controls for Federal Information Systems, NIST; ISO27002: NEN-ISO/IEC Code voor informatiebeveiliging, Voor de relevante referenties kan ook gebruik worden gemaakt van de Baseline Informatiebeveiliging Rijksdienst (BIR). 8 van 55

9 3. Beveiligingseisen voor de (web)applicatie 3.1. Beheersbaarheid en beveiliging van de (web)applicatie SWA-1: beheer SWA-1 beheer beoordelingen 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. 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. 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. BO van 55

10 SWA-2: Gegevensclassificatie SWA-2 Gegevensclassificatie 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. Indien gegevens onjuist of niet zijn geclassificeerd, kunnen deze niet op de juiste wijze worden beveiligd. 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 van 55

11 SWA-3: Functiescheiding SWA-3 Functiescheiding 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. 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. 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. 11 van 55

12 AC SWA-4: Least Privilege SWA-4 Least Privilege 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. 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. 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. AC van 55

13 SWA-5: Onweerlegbaarheid SWA-5 Onweerlegbaarheid 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. Indien een aangewezen transactie niet onweerlegbaar aan een persoon kan worden gekoppeld, kan die later zijn of haar betrokkenheid ontkennen. 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 loggen en monitoren /03.01 De (web)applicatie legt de aangewezen transacties vast in een logbestand. 13 van 55

14 14 van 55

15 AU SWA-6: (Web)applicatie logging SWA-6 (Web)applicatie logging 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. Zonder logging kunnen issues of incidenten niet worden onderzocht. 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

16 B7-7 B7-8 IR-4 IR-5 IR-6 IR SWA-7: Borgen van Sessie Authenticiteit SWA-7 Borgen van Sessie Authenticiteit 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. Als een andere persoon een nog openstaande sessie kan oppakken, geeft dit de mogelijkheid van misbruik van de identiteit van de oorspronkelijke gebruiker. 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 Een sessie ID is voldoende sterk, namelijk een lang random nummer, om deze onvoorspelbaar te maken. /02 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. B4-2 SC van 55

17 SWA-8: Concurrent Session Control SWA-8 Concurrent Session Control (standaard slechts een sessie per gebruiker) 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. 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. 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. AC van 55

18 SWA-9: Session lock SWA-9 Session lock 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. Het ontbreken van een session lock kan als gevolg hebben dat het werkstation en de daarop geopende sessies worden misbruikt. 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. AC van 55

19 SWA-10: Session termination SWA-10 Session termination 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. Het ontbreken van een session termination kan als gevolg hebben dat de reeds geopende sessie door een kwaadwillende wordt misbruikt. 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. AC van 55

20 3.2. Identificatie, authenticatie en toegangsbeheersing SWA-11: De identiteit van een externe gebruiker vaststellen SWA-11 De identiteit van een externe gebruiker vaststellen 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. 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. (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. B0-12 B3-2 IA-1 IA van 55

21 SWA-12: De identiteit van een interne gebruiker vaststellen SWA-12 De identiteit van een interne gebruiker vaststellen 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. 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. (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. B0-12 B3-2 IA-1 IA van 55