Concern Informatiebeveiliging

Gemeente Rotterdam
Concern Informatiebeveiliging
Component Architectuur
Van
P. Verhuist
Datum
15 december 2014
Inhoudsopgave
1 Inleiding
4
DEEL 1: Security raamwerk Rotterdam
5
2 Uitgangspunten van concern informatiebeveiliging
6
3 Hoofdprincipes van informatiebeveiliging
4 Classificaties
8
1
0
4.1 Vertrouwelijkheid
1
4.2 Integriteit
1
1
2
4.3 Beschikbaarheid
1
3
DEEL 2: Beheersmaatregelen
1
5 L o g i s c h e toegang
4
1
5.1 Identificatie
5
1
5.2 Authenticatie
5
1
5.3 Autorisatie
6
1
7
6 Z o n e r i n g en filtering
2
0
6.1 Z o n e r i n g
2
0
6.2 F i l t e r i n g
2
0
6.3 Versleuteling
2
6.4 Sleutelbeheer
1
2
2
7 Application controls
2
7.1 F u n c t i e - en processcheiding
7.2 Invoercontrole
2
7.3 Uitvoercontrole
2
5
2
8 Systeemintegriteit
5
2
8.1 I n t e g r i t e i t van gegevensverwerkingen
8.3 M o b i l e code
3
4
7.4 C o n t r o l e van gegevensverwerking
8.2 H a r d e n i n g
3
2
6
2
2
2
6
6
7
Comern Informatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
2
n
a
van 34
8.4 Beperking systeemhulpmiddelen
2
9 Onweerlegbaarheid van transacties
2
9.1 Integriteitscontrole
8
2
10 Continuïteit
2
8
9
10.1 H e r s t e l van verwerkingen
2
10.2 Redundantie
9
2
9
10.3 Vo o r k o m e n discontinuïteit
3
11 L o g g i n g en monitoring
11.2 Monitoring
8
2
9.2 Wederzijdse authenticatie
11.1 L o g g i n g
7
0
3
3
1
1
3
2
Bijlage 1: Samenhang uitgangspunten, principes en maatregelen
Bijlage 2: Referentie
3
3
3
4
Concern Informatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
3
n
a
van 34
1Inleiding
Deze component architectuur is opgesteld als referentie voor concern informatiebeveiliging (IB) in
Rotterdam en is daarmee een praktische uitwerking van het concern IB beleid.'
Doelen
Deze IB architectuur:
• b e s c h r i j f t de gewenste (veelal wettelijk vereiste) situatie;
• i s een leidraad voor ontwerp beslissingen, (technische) oplossingen en investeringen in IB;
• s t r e e f t naar adoptie van 'best-practices' en standaarden;
• b e o o g t reductie van kosten en verhogen van flexibiliteit door inzet van herbruikbare en
generieke oplossingen.
Deze IB architectuur is een instrument voor verdere inrichting van concern IB. De weg daar naartoe
is beschreven in het meerjarenplan concern IB (concerndirectie, 2014).
Scope
De scope omvat alle informatie (gegevens) die de Gemeente Rotterdam verwerkt en uitwisselt, intern
en extern.
Werking
De IB architectuur is voorschrijvend. De richtlijnen zijn niet vrijblijvend. Afwijking van de richtlijnen is
alleen acceptabel op basis van een zorgvuldige risicoafweging. Bijvoorbeeld omdat de kosten te
hoog zijn of de techniek niet beschikbaar. Het uitgangspunt is net als bij concern IB beleid: comply or
explain, pas toe of leg uit waarom wordt afgeweken van de norm. Deze afweging is altijd een
expliciet besluit van verantwoordelijk management.
Met de vaststelling van deze architectuur komt de component architectuur 'authenticatie, autorisatie
en beveiliging' (2011) te vervallen.
Leeswijzer
• D e e l 1 is bedoeld voor een bredere doelgroep (management, vakspecialisten) en beschrijft
het security raamwerk van de gemeente Rotterdam. Dit deel gaat vooral in op de vraag
waarom we beveiligen (wat heeft de organisatie er aan) en welke doelen we daarbij
nastreven.
• H2 beschrijft de uitgangspunten voor beveiliging
• H3 beschrijft de hoofdprincipes
• H4 beschrijft de classificatieniveaus
• D e e l 2 is bedoeld voor specialisten (zoals: architecten, security functionarissen, ontwerpers,
beheerders, etc.) en beschrijft beheersmaatregelen in meer detail.
• H5 - 11 is een nadere uitwerking van de vereiste maatregelen
Concern Informatiebeveiligingsbeleid, college B&W, 2014
Concern informatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
4
n
a
van 34
DEEL 1: Security raamwerk Rotterdam
In dit deel zijn de uitgangspunten, principes en classificaties beschreven. Samen met het concern IB
beleid vormen deze het raamwerk van de Rotterdamse security architectuur. Dit is de basis voor
beheersmaatregelen zoals beschreven in deel 2, alsook de technische architectuur (technische
oplossingen) en security processen.2
• Uitgangspunten beschrijven waarom we IB realiseren en wat de organisatie er aan heeft.
• P r i n c i p e s beschrijven de grondregels van IB: wat beogen we?
• Classificatie definieert de vereiste maatregelen per classificatieniveau (laag, midden, hoog).
2De security processen zullen in 2015 separaat worden uitgewerkt.
concern informatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
5
n
a
van 34
2 U i t g a n g s p u n t e n van concern informatiebeveiliging
De concern IB architectuur beschrijft richtlijnen en maatregelen voor informatiebeveiliging (IB) en
geeft daarmee invulling aan het concern IB beleid. Elke richtlijn en elke maatregel dient een
organisatiedoel. In onderstaande tabel staan de belangrijkste waarden en doelen samengevat. Deze
zijn afgeleid uit het concern IB beleid aangevuld met best practices' volgens het Information Security
Forum (ISF), toegespitst op relevantie voor Gemeente Rotterdam.
IB-01
Ondersteun
_. de organisatie
Rationale
1B beoogt de risico's van het werken met gevoelige informatie te beheersen.
Consequentie
1. Informatieveiligheid is een integrale taak en verantwoordelijkheid en
randvoorwaardelijk voor een goede bedrijfsvoering. Informatiebeveiliging is
het proces dat dit beoogt.
2. Informatiebeveiliging is een enabler en maakt nieuwe manieren van werken
op verantwoorde wijze mogelijk. Hierdoor zijn we in staat producten en
diensten te leveren op innovatieve wijze, die voldoen aan zowel de
functionele eisen als gangbare normen voor informatieveiligheid.
3. H e t voldoen aan beveiligingseisen is van groot belang voor het beschermen
van rechten van burgers en bedrijven (een betrouwbare overheid).
Landelijke en Europese wet- en regelgeving, standaarden en richtlijnen zijn
leidend.
4. Informatieveiligheid is een kwaliteitsaspect van het werkproces. De
beheersing is vergelijkbaar met die van planning en control (P&C) en gericht
op risicobeheersing.
5. N i e u w e dreigingen en risico's dienen zich voortdurend aan. Analyse en
beoordeling daarvan is een essentiële taak.
6. W e beveiligen niet meer dan noodzakelijk. Dit beperkt de beheerlast,
voorkomt onnodige kosten (efficiëntie) en zorgt tegelijkertijd voor een
gerichte aanpak (effectiviteit). We streven naar standaardisatie en
hergebruiken wat we hebben, als het werkt.
113-02
e
r
d
e
-1drig9113.11r—gd
emanlaalle
Rationale
IB beoogt de organisatie te beschermen tegen beveiligingsincidenten.
Consequentie
1. Beveiligingsmaatregelen zijn gericht op de bescherming van gevoelige
informatie (zoals persoonsgegevens, justitiële informatie, gegevens over
zorg, etc.).
2. N i e t alles kan 100% worden beveiligd, keuzes zijn nodig. Dit vergt een
afweging van risico's, kosten en technische mogelijkheden. Dit is een
beslissing van verantwoordelijk management.
3. Oplossingen hebben altijd een duidelijk organisatiebelang. Door activiteiten
in samenhang en cyclisch (plan, do, check, act) te sturen ontstaat een
continu verbeterproces, gebaseerd op het beheersen van risico's.
4. Rotterdam hanteert een heldere baseline: stabiliteit, afnemersgerichtheid,
transparantie, flexibiliteit en betrouwbaarheid staan centraal.
Concern Informatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
6
n
a
van 34
Rationale
I
Consequentie
B
beoogt risicobewustzijn te vergroten
1. Risicobewustzijn en integriteit zijn essentieel voor informatieveiligheid. Om
als Rotterdam 'in control' te zijn, is het van belang dat iedere medewerker
bewust omgaat met risico's.
2. Informatiebeveiliging is een taak van ons allemaal: ga zorgvuldig om met
gevoelige informatie, geef zelf het goede voorbeeld.
IB beleid, personeelsregelingen, architectuur en meerjarenplan concern IB vormen samen één
logisch geheel:
• H e t concern IB beleid beschrijft de algemene kaders voor informatiebeveiliging, gebaseerd
op wet- en regelgeving.
• Personeelsregelingen zoals de 'regeling ICT en informatiegebruik' gaat dieper in op
gedragsaspecten.
• D e IB architectuur gaat dieper in op de inrichting van concern IB aan de hand van
principes, richtlijnen en beheersmaatregelen en is de basis voor andere architecturen.
• H e t meerjarenplan (ontwikkelpad) concern IB beschrijft de weg naar realisatie van deze
gewenste situatie en maakt zichtbaar waar de prioriteiten liggen, mede op basis van het
actuele dreigingsbeeld.3
Wet- en regelgeving
Dreigingsbeeld
Rotterdam
Concern
Informatiebeveiligingsbeleid
Regelingen personeel en
organisatie
Com • onent architectuur
Meerjarenplan
Informatiebeveiliging
Andere architecturen en ontwerpen,
'Dreigingsbeeld uit Cybersecuhtybeeld Nederland, 2014 (NCSC, AIVD) vertaald naar de Rotterdamse situatie. Dit is
onderdeel van het meerjarenplan concern IB 2015.
Concern Informatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
7
n
a
van 34
3 H o o f d p r i n c i p e s van informatiebeveiliging
Informatiebeveiliging is het geheel van preventieve, detectieve, repressieve en correctieve
maatregelen alsmede procedures en processen die de vertrouwelijkheid, integriteit en
beschikbaarheid van alle vormen van informatie binnen een organisatie garanderen, met als doel
de continuiteit van de informatie en de informatievoorziening te waarborgen en de eventuele
gevolgen van beveiligingsincidenten tot een acceptabel, vooraf bepaald niveau te beperken
(bron: wikipedia.n1).
Dit leidt tot de volgende hoofdprincipes voor informatiebeveiliging:
VERTROUWELIJKHEID: De data-eigenaar verschaft alleen geautonseerde
VO».
Rationale
Het beperken van de bevoegdheden en de mogelijkheden tot muteren,
kopiëren, toevoegen, vernietigen of kennisnemen van informatie tot een
gedefinieerde groep van gerechtigden.
Consequentie
De vertrouwelijkheid van gegevens wordt o.a. gegarandeerd door: logische
toegangsbeveiliging (1-15.); versleuteling, zonering en filtering (H6).
INTEG RIT t • dats-verantwoordelliKe waarborgt de Integriteit van
gave
Rationale
HetHetin overeenstemming laten zijn van informatie met de werkelijkheid en
garanderen dat niets ten onrechte is achtergehouden of verdwenen (juistheid,
volledigheid en tijdigheid).
Consequentie
De integriteit van gegevens en systemen wordt o.a. gegarandeerd door:
logische toegangsbeveiliging ( I - ) ; zonering en filtering ( I - ) ; application controls
systeemintegriteit (H8) en onweerlegbaarheid (H9).
AARHEID: De beschikbaarheid van 1-t- F M
en IT voldoet aa
Rationale
Informatie is toegankelijk en kan gebruikt worden.
Consequentie
De beschikbaarheid van gegevens en systeemfuncties wordt o.a. gegarandeerd
door verhogen continuïteit, o.a.herstelbaarheid en beheersing van verwerkingen,
en redundantie (H10).
Voor alle 3 hoofdprincipes geldt controleerbaarheid door middel van logging en monitoring (H11).
Afgeleide principes
Een belangrijke richting die volgt uit het concern IB beleid en past bij de uitgangspunten van
"verdedig de organisatie" is het hanteren van een zogenaamde "Defence in Depth" strategie:
Concern Intormatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
8
n
a
van 34
'
• p a s beveiliging op meerdere lagen toe;
• f o c u s op zowel mens (gedrag, processen) als techniek (ICT infrastructuur).
P-IB-01 G e m e e n t e Rotterdam hanteert een "Delence Depth".stratpgle.
Rationale
Door een gelaagde benadering is Gemeente Rotterdam beter in staat om zich te
beveiligen tegen een verscheidenheid aan risico's.
Consequentie
Een gelaagde beveiliging vermindert het risico op een "single point of
vulnerability". Dit betekent dat beveiliging in meerdere lagen wordt ingericht
(administratief, fysiek, technisch (netwerk, hardware, software, etc)).
De IB architectuur is onderdeel van de concern architectuur. De concern procesarchitectuur
beschrijft een aantal belangrijke uitgangspunten voor de IB architectuur:
• Bedrijfsprocessen hebben een eigenaar (van belang voor bijvoorbeeld autorisatie).
• D e architectuur is service georiënteerd (IB moet hierin kunnen voorzien).
• Bedrijfsprocessen zijn niet organisatie gebonden (de scope is breder dan Rotterdam!).
Rationale
H o e hoger het abstractieniveau waarop beveiliging plaats vindt (d.w.z. geringe
differentiatie in te beveiligen componenten), hoe lager de beheerlast en hoe
lager de kosten, maar tegelijkertijd: hoe lager de mogelijkheden tot hergebruik.
Consequentie V e r l a g e n van de beheerlast verdient de voorkeur, maar niet te koste van de
passendheid van maatregelen.
Binnen de Rotterdamse architectuur wordt beveiliging bij voorkeur als onafhankelijke generieke
functie ingericht los van systemen of services. Daarbij geldt dat beveiliging van geautomatiseerde
services ook geautomatiseerd plaats moet kunnen vinden.
gevat van gedeelde maatregelen en
Rationale
Centralisatie van beveiliging geeft minder beheerlast door hergebruik.
Centralisatie verkleint de kans op fouten in beveiligingsmaatregelen.
Consequentie
Het toepassen van algemene beveiligingsmaatregelen zoals het gebruik van
firewalls gebeurt centraal en niet voor elk IT-component afzonderlijk.
Concern Informatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
9
n
a
van 34
4 Classificaties
De beveiligingsclassificatie is een logische groepering van systemen en services waarvoor dezelfde
beveiligingsmaatregelen gelden. Er wordt geclassificeerd op basis van de 3 hoofdprincipes:
vertrouwelijkheid, integriteit, beschikbaarheid. Concern IB beleid onderscheidt de volgende niveaus:
eieheld
g i a l a r o
Geen
,
Openbaar
Niet zeker
Niet nodig
informatie mag door iedereen
informatie mag worden veranderd
gegevens kunnen zonder
worden ingezien
(templates en sjablonen)
gevolgen niet beschikbaar zijn
Bedrijfsvertrouwelijk
Beschermd
Nodig
informatie is toegankelijk voor alle
het bedrijfsproces staat enkele
informatie mag (incidenteel) niet
medewerkers van de organisatie
(integriteits-)fouten toe
beschikbaar zijn
(het intranet)
(rapportages)
(administratieve gegevens)
Vertrouwelijk
Hoog
Belangrijk
informatie is alleen toegankelijk
het bedrijfsproces staat zeer
informatie moet vrijwel altijd
voor een beperkte groep
weinig fouten toe
beschikbaar zijn
(de gemeentelijke website)
LAAG
MIDDEN
HOOG
(tools)
(de belastingadministratie)
(vergunningverlening)
(sociale dienst systeem)
Geheim
Absoluut
Essentieel
informatie is alleen toegankelijk
het bednjtsproces staat geen
informatie mag alleen in
voor direct geadresseerde(n)
fouten toe
uitzonderlijke situaties uitvallen
(de basisregistratie personen)
(de gemeentelijke website)
(gegevensmagazijn)
De eigenaar van de data bepaalt de classificatie.
Rationale
De data-eigenaar is verantwoordelijk voor classificatie.
Consequentie
• D e data-eigenaar bepaalt wie toegang krijgt tot welke gegevens en kiest op
basis van beveiligingseisen passende beheersmaatregelen.
• D e data-eigenaar is bekend met specifieke wet- en regelgeving t.a.v.
gegevensbescherming (bijv. Suwi) en de beveiligingseisen die hieruit
voortvloeien. Dit is onderdeel van de classificatie.
We beveiligen niet meer dan nodig is.
P-12-05
Rationale
[Consequentie
A
l
l
1
7
v
zlijc
a
fn
s
e
tg
d
o
rw
E
Te hoge classificatie leidt tot onnodige kosten en verstoring van de
prioriteitstelling bij het nemen van beheersmaatregelen.
Informatie wordt niet meer beveiligd dan strikt noodzakelijk.
Concern Informatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
1
n
0
a
van 34
4.1 Ve r t r o u w e l i j k h e i d
In onderstaande tabel staan de belangrijkste maatregelen voor vertrouweliikheid. Deze zijn in
hoofdstuk 5, 6 en 11 verder uitgewerkt. De kolommen (niveaus) zijn cumulatief.
LAAG
(bodrijtswertrouwetijk)
laag +
laag en midden +
Identificatie
• Gebruikers zijn uniek herleidbaar
• Gescheiden beheer en gebruikers
accounts
• Identiteit informatie is actueel en
wordt jaarlijks geverifieerd door
leidinggevende
• Geen 'gedeelde functionele
identiteiten'
• Identiteiten worden 2 x per jaar
geverifieerd door leidinggevende
• Identiteiten worden 4 x per jaar
geverifieerd door leidinggevende
Authenticatie
• Authenticatie obv 'informatie'
(naam/wachtwoord)
• Wachtwoorden versleuteld
• Authenticatie obv 'informatie en
'eigenaarschap' (2-factor) vanuit
(semi)onvertrouwde zone
• Sessie time-out bij inactieve
sessie
• Authenticatie obv 'eigenschap'
(biometrie) optioneel
• Geen SSO toegestaan
• Absolute sessie time-out
Autorisatie
• Autorisatie obv 'lid van organisatie'
• Autorisatie wordt jaarlijks
geverifieerd onder
verantwoordelijkheid eigenaar
• Aanvragen door bevoegde
aanvrager
Autorisatie obv vooraf
gedefinieerde functionele rol
(doelbinding, noodzakelijkheid)
Autorisaties vallen aantoonbaar
samen met begin en einddatum
van een dienstverband of
functiewijziging.
Autorisaties worden vooraf
geaccordeerd door data-eigenaar
Versleuteling
• Versleuteling tijdens transport
buiten netwerk van Gemeente
R'dam via transportbeveiliging of
bericht beveiliging
• Lifecycle management van
cryptosleutels dient gewaarborgd
te zijn
• Cryptosleutels worden beschermd
Versleuteling van webverkeer
(intern en extern)
Zonering
• Aparte zone voor classificatie laag
vereist
• Aparte zone voor classificatie
midden vereist
• Geen lokale opslag van data
Filtering
• Filtering op verkeersstromen en
content (malware, spyware, etc.)
m.b.t. inkomend verkeer vanuit
externe/onvertrouwde zone
• Filtering op verkeersstromen van
en naar andere zones
•
Logging &
Monitoring
• Logging tbv fouten, niet
toegestane acties en werking van
maatregelen
• Actieve monitoring op 'reguliere'
dreigingen
• Aanvullende logging
traceerbaarheid op natuurlijk
persoon
• Actieve monitoring en aterling bij
inbreuk op beveiliging
• Bewaren conform wettelijke eisen
en/of contractuele afspraken (voor
zover niet in strijd met wetgeving)
Concern Intormatiebeveiliging
Component Architectuur
• Versleuteling tijdens transport EN
bij opslag van gegevens
• Bescherming sleutels met
gecertificeerde cryptohardware
• Aparte zone voor classificatie
hoog vereist
• Transport van gegevens
minimaliseren
Datum
12 december 2014
Pagina
11 van 34
'
4.2 I n t e g r i t e i t
In onderstaande tabel staan de belangrijkste maatregelen voor integriteit. Deze zijn in hoofdstuk 5, 6,
7, 8, 9 en 11 verder uitgewerkt. De kolommen (niveaus) zijn cumulatief.
laag +
laag en midden +
Identificatie
• Zie tabel vertrouwelijkheid
• Zie tabel vertrouwelijkheid
• Zie tabel vertrouwelijkheid
Authenticatie
• Zie tabel vertrouwelijkheid
• Zie tabel vertrouwelijkheid
• Zie tabel vertrouwelijkheid
Autorisatie
• Zie tabel vertrouwelijkheid
• Geeft invulling aan de eisen voor
functiescheiding
• Geeft invulling aan de eisen voor
functiescheiding
Versleuteling
• Zie tabel vertrouwelijkheid
• Zie tabel vertrouwelijkheid
• Zie tabel vertrouwelijkheid
Zonering
• Zie tabel vertrouwelijkheid
• Zie tabel vertrouwelijkheid
• Zie tabel vertrouwelijkheid
Filtering
• Zie tabel vertrouwelijkheid
• Zie tabel vertrouwelijkheid
• Zie tabel vertrouwelijkheid
Functie
scheiding
• Procestaken zijn gescheiden
• Beheer en gebruik zijn gescheiden
• Aparte goedkeuring taak bij
verwerkingen
• Proces ontwerp aanwezig
•
Invoer
controle
• Invoercontrole op volledigheid en
consistentie
• Pre-fill van bekende gegevens
• Inzage en recht op wijzigen van
gegevens door klant
• Ingevoerde klantgegevens worden
bevestigd aan klant met optie tot
correctie
• Kritische gegevenselementen
worden verplicht ingevuld
•
Uitvoer
controle
• Controle op overbodige
systeeminformatie
• Uitvoer beperkt tot voor de functie
noodzakelijke gegevens.
• Afdrukken van gegevens via
applicatietaak
• Uitvoer voldoet aan wettelijke
vormvoorschriften
• Controle van de juistheid van de
uitvoer
Systeemintegriteit
• Hardening vereist
• Uitvoeren van toegestane 'mobile
code' in geisoleerde omgeving
• 'Persistant messaging' vereist
• Noodstop mechanisme
• Generatievalidatie en
herstelmechanisme
•
Onweerlegbaarheid
• geen
• Elektronische handtekening
vereist bij formele communicatie
- Wederzijdse authenticatie vereist
• Gekwalificeerde elektronische
handtekening vereist bij formele
communicatie
• Audit-trail is onweerlegbaar
Logging &
Monitoring
• Zie tabel vertrouwelijkheid
• Vastleggen relevante input en
output validatie
• Vastleggen oude staat van te
wijzigen gegevens.
Concern informatiebeveiliging
Datum
Component Architectuur
12december 2014
P
a
g
i
1
n
a
2
van 34
4.3 B e s c h i k b a a r h e i d
In onderstaande tabel staan de belangrijkste maatregelen voor beschikbaarheid. Deze zijn in
hoofdstuk 10 en 11 verder uitgewerkt. De kolommen (niveaus) zijn cumulatief.
laag +
l
a
a
g
en midden +
Herstel van
verwerkingen
• Back-up & restore
• Handmatige fail-over —standby in
tweede datacenter
• Calamiteiten plan (disaster
recovery)
• Herstel op werkdagen tijdens
kantooruren
• Buffering van tussenbestanden bij •
langere ketens
• Automatische fail-over en laad
balancing
•
• Business continuity plan
• Beperkt herstel buiten kantooruren •
Real-time fail-over en via load
balancing op beide datacenters
actief
Jaarlijks getest calamiteiten en
business continuity plan
Herstel 24x7
Redundantie
• geen
• Dubbele uitvoering voorzieningen •
• Zo mogelijk gescheiden locaties
Applicaties zijn geschikt gemaakt
voor automatische fail-over
• Geen SPOF
Voorkomen
van discontinuïteit
• Melding van overschrijding van
drempelwaarden
• Maatregelen tegen doelbewuste
verstoring ICT van buiten, denk
aan anti-DDOS maatregelen
(preventief)
• Controle op weerbaarheid via
technisch onderzoek op het
niveau van netwerken, protocollen
en applicaties
•
Systeemintegriteit
• Onnodige en ongebruikte functies
zijn uitgeschakeld
• Gebruik systeemhulpmiddelen
beperkt
• Uitvoering mobile code wordt
voorkomen
• 'Persistant messaging vereist
• Remote beheer niet toegestaan
Logging &
Monitoring
• Zie tabel vertrouwelijkheid
• Loggen verstoren productieproces
• Loggen performance en resource
gebruik
• Trending uitvoeren op logging
• Verantwoording voor alle error
logs.
Concern Informatiebeveiliging
Component Architectuur
Datum
12 december 2014
Pagina
13 van 34
DEEL 2: Beheersmaatregelen
In de volgende hoofdstukken zijn de beheersmaatregelen zoals in classificatietabellen opgenomen
verder uitgewerkt en toegelicht. De beheersmaatregelen zijn gebaseerd op versie 4 van het
beveiligingskatern van de Nederlandse Overheid Referentie Architectuur (NORA).
Concern informatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
1
n
4
a
van 34
5 L o g i s c h e toegang
Logische toegangscontrole door middel van identificatie, authenticatie en autorisatie zorgt ervoor dat
een persoon, organisatie of IT-voorziening uitsluitend gebruik kan maken van functies, waarvoor
deze door middel van een aanvraagproces toegangsrechten heeft verkregen (HP-IB-01, HP-IB-02).
5.1 Identificatie
IG•01
Gebruikers van systemen en Informatk: u n i e k herleidbeter.
270012013 9.1 •
Alle gebruikers van gegevens of systeemfuncties zijn uniek herleidbaar tot één
natuurlijke persoon, organisatie of IT-voorziening.
Rationale
• N a t u u r l i j k e personen organisaties of IT-voorzieningen worden
geidentificeerd door een unieke identificatie.
• Vr i j g e s t e l d van identificatie zijn gebruikers met toegang tot systemen die
alleen algemeen toegankelijke informatie ontsluiten (classificatie: geen).
• Systeemprocessen hebben een eigen gebruikersnaam voor zover deze
processen handelingen verrichten voor andere systemen of gebruikers.
• B e h e e r d e r s hebben naast een regulier account zonder administrator
rechten ook een persoonlijk administrator account voor beheer taken. In de
operatie worden beheerwerkzaamheden en werkzaamheden als gewone
gebruiker onder twee verschillende gebruikersnamen uitgevoerd.
• H e t gebruik van algemene beheeraccounts (root, administrator) is
uitgeschakeld, als gebruik onvermijdelijk is moet herleidbaarheid,
doelbinding én onweerlegbare logging gecombineerd toegepast worden.
• Toegangsbeveiliging is geimplementeerd op alle middelen die gegevens
bevatten of verwerken.
• Identiteitsinformatie is actueel en wordt jaarlijks gecontroleerd door de
leidinggevende. De frequentie is afhankelijk van de classificatie.
Consequentie
Ike identiteit gewerkt (voorclassifIcatienlveau Ia g).
Rationale D o e l is minimaliseren van de beheerlast.
Consequentie D e externe partij is verantwoordelijk voor het beveiligen van toegang tot het
juiste niveau en het intern zorg dragen van authenticatie en autorisatie. Dit zal
formeel vastgelegd moeten worden als onderdeel van de SLA/contract.
(Afhankelijk van het classificatieniveau wordt gekozen voor R-18-02 of R-I8-03).
classificatIen
Rationale
O
m te kunnen voldoen aan hogere classificatieniveaus is het belangrijk dat een
identiteit is terug te voeren op een individu.
Consequentie E r mogen bij hogere classificatieniveaus geen algemene functionele identiteiten
zoals stagiair of extern worden gebruikt.
(Afhankelijk van het classificatieniveau wordt gekozen voor R-18-02 of R-18-03).
Concern Intormatiebeveiliging
Datum
Pagina
Component Architectuur
12 december 2014
15 van 34
Rationale
Gegevensuitwisseling ondersteunt virtualisatie, provisioning en realtime
identificatie.
Consequentie
Gegevensuitwisseling biedt, gebruikmakend van de bronsystemen, de volgende
mogelijkheden voor identificatie:
• Virtualisatie op basis van één service waarmee gezocht kan worden binnen
alle verschillende identiteitstypen en bronnen. Wijzigingen op identiteiten
gebeurt in de bronsystemen zelf.
• Provisioning via het geautomatiseerd doorsturen van wijzigingen met
betrekking tot identiteiten vanuit bronsystemen naar externe
hostingproviders (het is niet toegestaan rechtstreeks te integreren met de
concernvoorzieningen voor authenticatie en autorisatie).
• H e t aanbieden van een real-time interface per identiteitstype die de
authenticatie- en autorisatievoorzieningen gebruiken om
identiteitsgegevens te ontsluiten.
Rationale
D
e initiële aanvrager wordt geautoriseerd voor het gebruik van systemen, niet
het tussenstation. Afhankelijk van de classificatieniveaus is het voor logging- en
monitoringdoeleinden vereist dat de initiële aanvrager bekend is.
Consequentie Tu s s e n s t a t i o n s zoals de gegevensuitwisseling component moeten in staat zijn
identiteitsgegevens van de initiële aanvrager door te sturen (propagatie) aan
achterliggende systemen die authenticatie en autorisatie uit laten voeren.
Rationale
Gebruik van bestaande voorzieningen voorkomt dat we het wiel opnieuw
uitvinden, verhoogt herkenbaarheid voor gebruikers en verlaagt de kans op
beveiligingsrisico's als gevolg van lokale realisatie.
Consequentie V o o r d a t beveiligingsvoorzieningen gerealiseerd worden, wordt eerst gekeken
naar bestaande voorzieningen.
5.2 Authenticatie
.
•
e
•
111•1
Rationale
Alvorens toegang wordt verleend, wordt de identiteit van de gebruiker of ander
sub-ct dat om to- !an. vraast, vast!esteld door middel van authenticatie.
Consequentie
• B i j het intern gebruik van IT-voorzieningen worden gebruikers minimaal
geauthentiseerd op basis van wachtwoorden (classificatieniveau laag).
• V o o r de classificaties midden en hoog wordt sterke authenticatie (2-factor)
gebruikt (zie R-IB-08).
• Wachtwoordbestanden worden gescheiden opgeslagen van gegevens van
de toe..ssin! en zin alti. versleuteld.
Concern Informatiebeveiliging
Datum
Pagina
Component Architectuur
12 december 2014
16 van 04
• H e t wachtwoord wordt niet getoond op het scherm.
• A u t o m a t i s c h inloggen van gebruikers (via bijv. cookies) is niet toegestaan.
• Expiratiedatums van accounts vallen samen met de einddatum van de
contracten van de medewerkers.
• N a d a t voor een gebruikersnaam meerdere keren een foutief wachtwoord
gegeven is wordt het account geblokkeerd.
• Netwerksessies worden na een vastgestelde periode van inactiviteit
afgesloten (sessie time-out). Bij classificatie hoog geldt een absolute sessie
time-out.
• H e t systeem toont uitsluitend voor de aanmeldina noodzakelijke informatie.
Rationale
Authenticatie vindt afhankelijk van de classificatie plaats via de volgende
mechanismen:
• I n f o r m a t i e : kennis die alleen bij die bepaalde identiteit bekend is ('iets wat
hij weet'), bijvoorbeeld inlognaam en wachtwoord.
• Eigenaarschap: een attribuut ('iets wat hij heeft) dat een identiteit bezit;
bijvoorbeeld een certificaat of token.
• E i g e n s c h a p : een unieke eigenschap van een identiteit zoals stem, iris en
vingerafdruk (iets wat hij is')
Consequentie E r
•
•
•
zijn 3 authenticatieniveaus:
L a a q : mechanisme gebaseerd op "informatie".
M i d d e n : mechanisme gebaseerd op "informatie" en "eigenaarschap".
H o o q : mechanisme gebaseerd op "informatie" en "eigenaarschap" en
(optioneel) "eigenschap"
Rationale I n t e r c e p t i e en misbruik van authenticatiegegevens is een beveiligingsrisico met
mogelijk grote gevolgen.
Consequentie G e g e n e r e e r d e tokens en handtekeningen hebben de voorkeur boven een
statisch versleutelde inlognaarn/wachtwoord combinatie.
Rationale
SSO wordt ingezet t.b.v. gebruikersvriendelijkheid maar is ondergeschikt aan
beveiliging. Inzet is beperkt tot classificatieniveaus laag en midden.
Consequentie
SSO neemt de verschillende authenicatieniveaus in acht, houdt zich aan de
(absolute) sessie-timeout, is niet toegestaan op classificatieniveau hoog en
wordt periodiek geëvalueerd op beveiligingsrisico's.
Autorisatie
Rationale
Autorisaties zijn ingesteld op basis van een autorisatiematrix, waarin
aan! - !even is welke rollen welke rechten ontvan!en
Concern informatiebeveiliging
Datum
Pagina
Component Architectuur
12 december 2014
17 van 34
Consequentie
• D e technische implementatie van autorisaties naar autorisatiegroepen is in
overeenstemming met de ontwerp- of systeemdocumentatie.
• S p e c i a l e (systeem)bevoegdheden zijn in aparte autorisatiegroepen
opgenomen.
• D e registratie van gebruikers en verleende toegangsrechten is zoveel
mogelijk centraal geregeld (single-point-of-administration).
• V o o r groeperingsmechanismen geldt een naamgevingconventie die
aansluit op stabiele en concernbrede uitgangspunten.
• To e p a s s i n g e n mogen niet onnodig en niet langer dan noodzakelijk onder
een systeemaccount (een privileged user) draaien.
De taken die met (tijdelijk) hogere rechten uitgevoerd worden kunnen niet
onderbroken of afgebroken worden met als gevolg dat deze hogere rechten
voor andere doeleinden gebruikt (misbruikt) kunnen worden.
Gebruikers krijgen geen algemene commando-omgeving tot hun
beschikking.
• B i j het overnemen van werkstations door beheerders om te kunnen
meekijken op het werkstation wordt technisch afgedwongen dat hiervoor
eerst toestemming aan de gebruiker wordt gevraagd. De gebruiker kan op
elk moment de verleende toestemming intrekken.
• S y s t e e m d a t a programmatuur en toepassingsgegevens zijn van elkaar
gescheiden. Dat wil zeggen dat de bestanden zoveel mogelijk in eigen
directory's of partities geplaatst worden.
• E r zijn in productiezones geen hulpmiddelen toegankelijk die het systeem
van logische toegangsbeveiliging doorbreken of de integriteit van de
productieverwerking kunnen aantasten.
Rationale
Consequentie
Een rolgebaseerd autorisatiemodel vermindert de beheerlast door identiteiten
niet meer rechtstreeks aan permissies te koppelen, maar autorisatie op basis
van andere attributen toe te passen.
• O m autorisaties te kunnen herleiden wordt autorisatie uitsluitend verleend
aan de initiële aanvrager van het systeem, service of gegeven.
• R o l l e n onderkennen organisatorische eenheden en functies. Dit zorgt in
combinatie met rolgebaseerde autorisatie voor een vermindering van de
beheerlast en betere aanpasbaarheid.
• Hiërarchische en organisatorische verhoudingen resulteren niet in
overerving van autorisaties.
• H e t autorisatiemodel moet het 4-ogen principe middels functiescheiding
ondersteunen.
• H e t autorisatiemodel moet machtigingen ondersteunen.
Rationale
De data-eigenaar is eindverantwoordelijke voor autorisaties en overziet het
proces van uitgifte van autorisaties.
Consequentie
• A u t o r i s a t i e s worden periodiek gecontroleerd onder verantwoordelijkheid
van de data-eigenaar, ten minste 1 x per jaar, afhankelijk van de
Concern informatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
1
n
a
8
van 34
classificatie.
• Autorisatiecontroleurs zijn leidinggevenden die inhoudelijke kennis hebben
van zowel de geautoriseerde medewerkers als de risico's van onbevoegde
toegang.
• P e r i o d i e k wordt door functioneel beheer gerapporteerd over de
verschillende autorisatieprofielen inclusief de identiteiten die hieraan
gekoppeld zijn, ten minste 1 x per jaar, afhankelijk van de classificatie.
• A a n v r a g e n worden geverifieerd.
Rationale
Consequentie
In de loop der tijd kunnen "verworven" rechten ontstaan buiten de normale
autorisatieregels om. Het ontstaan van opstapeling van rechten moet
voorkomen worden.
• E l k e identiteit heeft "just enough" autorisatie voor de uitvoering van zijn
taak.
• Hierarchische en organisatorische verhoudingen resulteren niet in
overerving van autorisaties.
• V o o r tijdelijke werkzaamheden buiten de normale taak om, worden tijdelijke
autorisaties toegepast, waarbij een expiratiedatum verplicht is.
• E r wordt onderscheid gemaakt tussen beheer- en gebruikerspermissies.
Concern Intormatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
1
n
a
9
van 34
6 Z o n e r i n g en filtering
Zonering verdeelt de IT-infrastructuur in zones op basis van classificaties om isolatie van onderdelen
mogelijk te maken. Filtering beschermt zones tegen aanvallen, indringers, ongewenste inhoud en
virussen, waardoor diensten onbereikbaar worden of onrechtmatige toegang tot gegevens of
systemen wordt verkregen (HP-IB-01, HP-IB-02).
6.1 Z o n e r i n g
Rationale
D
Consequentie
e indeling van zones binnen de technische infrastructuur vindt plaats volgens
een vastgesteld inrichtingsdocument (configuratiedossier) waarin is vastgelegd
welke uitgangspunten gelden voor de toepassing van zonering.
•
E e n zone heeft een gedefinieerd beveiligingsniveau.
• D e maatregelen van logische toegangsbeperking zijn van toepassing op
alle IT-voorzieningen in een zone.
• E r zijn aparte zones voor de drie verschillende classificatieniveaus laag,
midden en hoog.
• I n zone hoog wordt elk systeem geïsoleerd.
• Uitwisseling van gegevens tussen zones vindt uitsluitend plaats via een
gedefinieerd koppelvlak.
• E r zijn aparte zones voor Ontwikkeling, Test, Acceptatie en Productie.
• I n t e r n e systemen wisselen gegevens uit met ketenpartners en klanten via
een centrale interne zone (DMZ) en een vertrouwde externe zone.
• V o o r de uitwisseling van gegevens met derden (niet openbare gegevens)
worden besloten en gescheiden externe zones (vertrouwde derden)
gebruikt.
• I n een DMZ worden alleen openbare gegevens van een organisatie
opgeslagen die in het uiterste geval verloren mogen gaan.
• H e t DMZ bestaat uit verschillende zones op basis van classificaties en/of
scheidi • van externe ko. .elin
6.2
Filtering
Rationale
Consequentie
a_Igest
D
i
n
g
iren d a m e g i r
te varbruaaan ovatsclai in bevellkilnissrateeau...—
— i. .
.
Er vindt controle plaats op protocol en richting van de communicatie en op
gegevensuitwisseling. Niet toegestane verbindingen worden geblokkeerd of er
wordt verhinderd dat deze tot stand komen.
• I n koppelpunten met externe of onvertrouwde zones worden maatregelen
getroffen om aanvallen te signaleren en te kunnen blokkeren.
• A l het gegevensverkeer vanuit externe of onvertrouwde zones wordt realtime inhoudelijk geinspecteerd op inbraakpogingen. Een update van
aanvalspatronen vindt frequent plaats.
• D e uitvoer van systemen waarmee gevoelige informatie wordt verwerkt
Concern Informatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
2
n
a
0
van 34
•
•
•
•
•
•
wordt alleen verzonden naar computers en locaties met een autorisatie.
Ve r s l e u t e l d e gegevensstromen van en naar de externe zone kunnen
worden ontsleuteld voor inhoudelijke controles t.b.v. informatieveiligheid.
E -mailberichten met bijlagen worden uitsluitend doorgelaten op basis van
geformaliseerde afspraken over de coderingsvorm (extensie) van de
bijlage. De codering wordt gecontroleerd.
B e r i c h t e n en bestanden met een omvang boven een vastgestelde
grenswaarde worden geblokkeerd om problemen met beschikbaarheid te
voorkomen.
E r is programmatuur actief die e-mailberichten en webpagina's blokkeert
met kwaadaardige code. Een update van antivirusdefinities vindt dagelijks
(of zo vaak als nodig) plaats.
E r is een spam en phishing filter geactiveerd voor zowel ontvangen als
verzonden berichten. Een update van het filter vindt dagelijks (of zo vaak
als nodig) plaats.
O p alle werkstations en daarvoor in aanmerking komende servers is antimalware programmatuur resident actief. Een update van malware definities
en/of programmatuur kan op ieder moment (handmatig) uitgevoerd worden.
Voor anti-malware wordt programmatuur van verschillende leveranciers
toe•e•ast in overeenstemmine met het 'defense in de th' r i n c i e
IT beheer dient aan te kunnen tonen dat de zonering gecontroleerd wordt op
uiste inhoud.
Consequentie Z o n e s worden periodiek gecontroleerd onder verantwoordelijkheid van de dataeigenaar.
6.3 Ve r s l e u t e l i n g
R-I13-18 G e g e v e n s
hiannlifflegelWn
v e r s l e u t
classificatie
ro I S O 270012013 10,1
De communicatie en de opslag van gegevens die buiten de invloedsfeer van de
logische en fysieke toegangsbeveiliging maar wel binnen de eigen
Rationale
beheeromgeving vallen of waarvoor onvoldoende beheersmaatregelen
bestaan, zijn door versleuteling beschermd afhankelijk van classificatie.
Consequentie
•
A f h a n k e l i j k van de classificatie dient versleuteling te worden toegepast in
de volgende situaties:
o b i j beheersessies over het eigen netwerk;
o b i j datatransport over (semi)onvertrouwde netwerkwerken of om
een hoger beveiligingsniveau te bereiken;
o b i j datatransport via mobiele datadragers buiten de reikwijdte van
de (logische en fysieke) toegangsbeveiliging van een organisatie;
o b i j draadloze datacommunicatie;
o v o o r wachtwoorden die worden opgeslagen of verzonden.
De gebruikte cryotografie is conform 'best ractices'.
Concern Informatiebeveiliging
Datum
Pagina
Component Architectuur
12 december 2014
21 van 34
• E r is in het kader van de naleving van de relevante contracten, wetten en/of
voorschriften rekening gehouden met de beperkingen op de import en/of
export van apparatuur en programmatuur met cryptografische functies en
het gebruik van versleutelingstechnieken.
6.4 S l e u t e l b e h e e r
R-113-19 C r y p t o g r a f i s c h e sleutels zijn vertroinvele en tpteg
Brom ISO 27001:201310,1 —
Rationale D e vertrouwelijkheid en integriteit van cryptografische sleutels is gewaarborgd
tijdens het gehele proces van generatie, transport, opslag, archivering en
vernietininc van de sleutels.
Consequentie
•
•
•
•
•
Cryptografische sleutels en certificaten kennen een geldigheidstermijn die
is afgestemd op het kritische gehalte van de toepassing.
Sessie-encryptie met een unieke sessiesleutel heeft de voorkeur boven
encryptie met periodiek te wijzigen sleutels.
G e n e r a t i e en installatie van private keys, master keys en root certificates
vinden plaats binnen een beschermende omgeving van cryptohardware.
Cryptohardware is lamper-resistant. Dit betekent dat er bijzondere
voorzieningen zijn getroffen tegen onbevoegde kennisname van de
opgeslagen cryptosleutels bij een fysieke inbreuk op de hardware.
Interactieve bediening van cryptohardware vindt plaats volgens het vierogen-principe.
Concern informatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
2
n
a
2
van 34
7 A p p l i c a t i o n controls
Applications controls (administratieve controles in programmatuur) waarborgen de volledige en
accurate gegevensverwerking van input tot output (HP-IB-02).
7.1 F u n c t i e - en processcheiding
Rationale
Consequentie
Niemand in een organisatie of proces mag in staat worden gesteld om een
gehele procescyclus te beheersen.
• B e w a r e n d e , registrerende, uitvoerende, controlerende en beschikkende
taken zijn gescheiden.
• I n d i e n dezelfde gegevens in meer gegevensverzamelingen voorkomen
worden mutaties altijd vanuit één gebruikersorganisatie in één
gegevensverzameling gemuteerd waarbij die mutaties automatisch en als
zodanig herkenbaar in de audittrail worden overgebracht (gekopieerd) naar
de andere gegevensverzamelingen.
• S t a m g e g e v e n s hebben een doorlopende betekenis in processen.
• B i j massale data-invoerprocessen worden eerste invoer, controle-invoer en
het aanbrengen van correcties n.a.v. uitgevoerde applicatiecontroles of —
signaleringen als afzonderlijke (applicatie)taken onderkend.
• B i j gegevens met een algemeen belang voor de integriteit van de gehele
verwerking of bij het vaststellen van gegevens met een aanzienlijk
financieel belang wordt een aparte applicatietaak voor het goedkeuren
gecreëerd om de beschikkende functie beter te ondersteunen. De
verwerking van de ingevoerde gegevens vindt pas plaats nadat
goedkeuring (door een andere gebruiker) heeft plaatsgevonden.
• A l s applicaties bestemd zijn voor gebruikersorganisaties waarin kortcyclische taakroulatie aan de orde is worden de historie van gebruiker-id's
en uitgevoerde applicatietaken per 'zaak" (dossier) vastgelegd en op
onverenigbaarheid van taken gecontroleerd voordat een taak voor een
bestaande "zaak" voor een gebruiker ter beschikking komt. Workflow
Management Systemen zijn speciaal toegerust om dit te realiseren.
• I n d i e n verschillende behandelgroepen binnen een centrale
gegevensverzameling zijn te onderscheiden worden de applicatietaken
afhankelijk gemaakt door de identificatie van deze groepen te controleren
met de inhoud van de gegevens.
• S y s t e e m - en applicatiebeheertaken zijn gescheiden van de overige
gebruikerstaken.
• V o o r de betrouwbaarheid van processen en de gegevensverwerking kan
het noodzakelijk zijn dat bepaalde processtappen in een bepaalde volgorde
plaatsvinden.
• O m de verantwoordelijkheden voor gegevens eenduidig in een organisatie
te kunnen toewijzen, is voor het muteren van gegevens een zodanig
j
consistente set applicatietaken aanwezig dat mutatiebevoegdheden
Concern intormatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
2
n
a
3
van 34
eenduidig binnen één organisatiedeel van gebruikers toegewezen kunnen
worden. Alleen een batchgewijze eerste opvoer vanuit een andere
applicatie of een systeemvreemde omgeving mag hierop (in de audittrail
herkenbaar) inbreuk maken.
• V o o r alle bovenstaande zaken zijn procesbeschrijvingen en workflows
gedocumenteerd en beschikbaar.
7.2 I n v o e r c o n t r o l e
Consequentie
Alle ingevoerde gegevens vanuit een systeemvreemde omgeving worden op
juistheid, tijdigheid en volledigheid gecontroleerd voordat verdere verwerking
plaatsvindt.
• E r bestaan verschillende applicatietaken voor invoeren, wijzigen en
verwijderen om de juiste invoercontroles (geautomatiseerd of handmatig)
mogelijk te maken.
• E r bestaan voldoende mogelijkheden om al ingevoerde gegevens te
kunnen corrigeren door er gegevens aan te kunnen toevoegen en/of te
verwijderen.
• I n een keten van verwerkingen worden invoercontroles zoveel mogelijk bij
de bron uitgevoerd.
• D e invoervelden van elektronische formulieren worden zoveel mogelijk
tevoren ingevuld met al vastgestelde gegevens.
• I n g e v o e r d e klant gerelateerde gegevens worden aan de klant als apart
proces bevestigd met het verzoek de gegevens te controleren en meteen te
(laten) wijzigen bij fouten.
• K l a n t e n hebben inzage in hun eigen gegevens en worden gestimuleerd hun
gegevens op eigen initiatief te wijzigen indien nodig.
• T e n behoeve van de controle op tijdigheid van ontvangst en verdere
verwerking wordt per verwerking de datum vastgelegd op basis van de
(centraal gesynchroniseerde) systeemdatum.
• D e ingevoerde gegevens vormen een complete en consistente
gegevensset in de context van de applicatie. De toegestane waarden van
de ingevoerde gegevens worden op juistheid gecontroleerd om de
volgende fouten te ontdekken:
o w a a r d e n die buiten het geldige bereik vallen;
o o n g e l d i g e tekens in invoervelden;
o ontbrekende of onvolledige kritische gegevens;
o overschrijding van boven- en ondergrenzen voor gegevensvolumes
(buffer overruns/overflows);
o inconsistentie ten opzichte van andere gegevens binnen invoer dan
wel in andere gegevensbestanden. Foutieve invoer wordt
geweigerd. Onwaarschijnlijke invoer wordt gesignaleerd. Dubbele
invoer wordt voorkomen.
Gegevens die kritisch zijn voor de toepassing worden verplicht ingevuld.
Concern Informatiebeveiliging
Datum
Pagina
Component Architectuur
12 december 2014
24 van 34
7.3 U i t v o e r c o n t r o l e
R-113-22
Bij gegevensverweridnwordt ullvoer
Rationale
:.-=1.0 .112 De uitvoerfuncties van programma's maken het mogelijk om de juistheid,
gheid en/of volledigheid van de gegevens te kunnen vaststellen.
Co- nsequentie
• D e uitvoer (elektronisch of op papier) bevat alleen die gegevens die nodig
zijn voor de doeleinden van de ontvanger.
Uitvoer wordt gecontroleerd op overbodige systeeminformatie zoals bij
foutmeldingen.
Het maken van een afdruk van gegevens mag alleen plaatsvinden via een
applicatietaak en niet via een generieke hardcopy (print screen) functie van
de werkstations.
• A u t o m a t i s c h gegenereerde bescheiden voor klanten voldoen aan de
wettelijke vereiste vormvoorschriften.
• B i j variabele instelmogelijkheden worden de selectiecriteria die gebruikt zijn
om de uitvoer te bepalen, op de desbetreffende uitvoerlijsten afgedrukt.
• B i j verzending van berichten waarbij risico's op juridische geschillen
mogelijk zijn worden voorzieningen getroffen die volledige verzending en
authenticiteit kunnen aantonen.
• B a t c h u i t v o e r bevat controletellingen die zijn gebaseerd op tijdens de
computerverwerking opgebouwde tellingen. Indien tellingen worden
overgenomen uit bestanden is dat kenbaar gemaakt op de uitvoerlijsten.
7.4 C o n t r o l e van gegevensverwerking
Rationale A p p l i c a t i e s bieden de mogelijkheden om te constateren dat alle ter verwerking
a a n g e b o d e n invoer juist, volledig en tijdig is verwerkt.
• D e risico's van verlies van transactionele integriteit bij het verwerken van
Consequentie
gegevens in lange ketens wordt opgevangen op applicatieniveau als
verwerkingszekerheid vereist is.
• I n de verwerkingsverslagen wordt bij batch-gewijze informatieverstrekking
aan derden naast de uitvoertellingen tevens de ontvangende instantie
vermeld.
• D e audit trail bevat voldoende gegevens om achteraf te kunnen herleiden
welke essentiële handelingen wanneer door wie of vanuit welk systeem met
welk resultaat zijn uitgevoerd. Tot essentiële handelingen worden in ieder
geval gerekend: opvoeren en afvoeren posten, statusveranderingen met
wettelijke, financiële of voor de voortgang van het proces, de zaak of de
klant beslissende gevolgen.
• D e aud it trail wordt bewaard conform wet- en regelgeving.
Concern Informatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
2
n
a
5
van 34
8 Systeemintegriteit
Systeemintegriteit betreft een verzameling van maatregelen die waarborgen dat IT-voorzieningen
binnen voorgeschreven operationele en technische grenzen functioneren en deze niet overschrijden
(bijvoorbeeld door bugs of onjuiste configuratie), (HP-IB-02).
8.1 I n t e g r i t e i t van gegevensverwerkingen
De technische infrastructuur voor berichtverwerking is zodanig ontworpen en
ingericht, dat foutsituaties worden voorkomen of herkend en dat functioneel
beheer over foutbestanden mogelijk is.
• Infrastructuur bevat logica die beheer van foutbestanden mogelijk maakt.
• Bericht verwerkende infrastructuur past foutloze berichtenverwerking toe
(Persistent Messaging).
• Foutbestanden worden niet gebruikt als opslagmechanisme (buffering).
• V o o r tijdelijke opslag van berichten in verwerkingsketens worden aparte
tussenbestanden gebruikt.
• Stapelen van fouten wordt voorkomen door toepassing van noodstop'
mechanismen. Juist verwerkte resultaten worden hierdoor niet
noodgedwongen naar een foutief verwerkingsproces gestuurd.
• D e planning van reguliere batchprogramma's is gebaseerd op de
aangegeven tijdstippen en volgorde volgens de systeemdocumentatie en
houdt rekening met de afhankelijkheden die er tussen verwerkingen en met
andere applicaties kunnen bestaan, start van de eerste taak en beeindiging
van de laatste taak.
• Onderdelen voor verwerking van batches worden pas opgestart nadat
voorafgaande verwerkingen succesvol zijn beëindigd.
• Generatievalidatie- en herstelmechanismen voorkomen dubbele of
onvolledige verwerkingen en borgen onderlinge verwerkingsrelaties bij het
oplossen van productiefouten.
• B i j uitwisseling van bestanden tussen centrale en decentrale servers of met
externe partijen wordt met een apart file-transfermechanisme zeker gesteld
dat uitwisseling niet achterwege blijft of dubbel plaatsvindt tenzij beheersing
geheel kan plaatsvinden volgens generatievalidatie- en
herstelmechanismen.
• E r wordt een logbestand aangemaakt van de activiteiten die tijdens de
verwerking plaatsvinden.
Rationale
Consequentie
8.2 H a r d e n i n g
Rationale
I
T
systemen die vitale beveiligingsfuncties vervullen, bevatten geen onnodige
en ongebruikte functies.
Concern Intormatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
2
n
a
6
van 34
Consequentie
• O n n o d i g e en ongebruikte functies (in besturingssystemen, servers) zijn
uitgeschakeld.
• Beheermogelijkheden zijn zoveel mogelijk afgesloten.
• E r is zoveel mogelijk gebruik gemaakt van versleutelde
beheermechanismen.
• B e h e e r is alleen toegestaan vanaf vooraf gedefinieerde IP-adressen.
• V o o r toegang tot switches wordt gebruik gemaakt van Virtual LAN's (VLAN)
en de toegang tot netwerkpoorten wordt beperkt op basis van MAC-adres
(port security).
eillgIngsfuncties van Infrastructu
*
oveel m I I Ingeschakeld. '
Rationale B e v e i l i g i n g s f u n c t i e s in infrastructurele programmatuur en apparatuur worden
waar mogelijk ingezet.
Consequentie V o o r apparatuur en programmatuur wordt onderzoek gedaan naar
hardeningsrichtlijnen en op basis van risico en impactanalyses worden
richtlijnen wel of niet geimplementeerd.
8.3 M o b i l e c o d e
71"9"
Rationale
Als gebruik van 'mobile code wordt toegelaten, dan zorgt de configuratie ervoor
dat de geautoriseerde 'mobile code' functioneert volgens een vastgesteld
inrichtingsdocument (configuratiedossier) en voorkomt de configuratie dat niettoegelaten 'mobile code' wordt uitgevoerd.
Consequentie O v e r w e g i n g e n bij toegestane 'mobile code' in een geisoleerde omgeving;
• b l o k k e r e n van elk gebruik van niet geautoriseerde 'mobile code';
• b l o k k e r e n van ontvangen van niet geautoriseerde 'mobile code';
• a c t i v e r e n van technische maatregelen die beschikbaar zijn op een specifiek
systeem om te waarborgen dat toegestane 'mobile code' wordt beheerd;
• b e h e e r s e n van de bronnen die beschikbaar zijn voor toegang tot
toegestane 'mobile code';
• cryptografische beveiligingsmaatregelen om toegestane 'mobile code' uniek
te authenticeren.
8.4 B e p e r k i n g s y s t e e m h u l p m i d d e l e n
8-28 G e b r u l k van systeemhulpmIddelen wordt beperkt
Rationale
H e t gebruik van hulpprogrammatuur waarmee maatregelen in systeem- en
applicatiesoftware zouden kunnen worden gepasseerd, wordt zoveel mogelijk
beperkt.
Consequentie
•
Identificatie-, authenticatie- en autorisatiemechanismen zijn ook voor
systeemhulpmiddelen van toepassing.
• Systeemhulpmiddelen en applicaties zijn gescheiden.
• O n n o d i g e hulpprogramma's en systeemprogrammatuur zijn verwijderd.
Concern informatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
2
n
a
7
van 34
9 Onweerlegbaarheid van transacties
Onweerlegbaarheid van transacties betreft waarborgen van authenticiteit en van
gegevensuitwisseling (HP-IB-02).
9.1 Integriteitscontrole
R-113-29
Rationale
Consequentie
De Integriteit (authenticiteit) van het verzonden b e r i e t wordt vastgesteld
met behulp van een elektronische handtekening.
Bron: ISO 27001:2013 13.2
De onweerlegbaarheid via PKI kan verkregen worden door middel van
wederzijdse authenticatie van zender en ontvanger aangevuld met controle op
de inte a riteit van het bericht.
• B i j een vertrouwd netwerk:
o E r is een betrouwbare berichtendienst. Verzending en ontvangst
van berichten worden bevestigd door de berichtendienst of hiervoor
worden in de applicaties extra functies opgenomen.
• B i j een onvertrouwd netwerk:
o E r wordt gebruik gemaakt van PKI-Overheid.
o D e elementen die het bewijs vormen van een elektronische
handtekening worden in de vorm van een juridisch logbestand
zodanig samen met de originele data bewaard dat datzelfde bewijs
in de normale werkstroom van het bedrijfsproces altijd weer is te
reproduceren.
o D e ontvangen en verzonden berichten worden onmiddellijk na
ontvangst in de juridische logging vastgelegd voordat enige
bewerkin m e t de a c a t i e aan de orde is.
9.2 W e d e r z i j d s e authenticatie
Rationale A l v o r e n s een transactie mogelijk is, worden de identiteit van de ontvanger of het
ontvangend systeem en de identiteit van de zender van het bericht vastgesteld
door middel van authenticatie.
Conseauentie Z i e R-16-29
Concern Informatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
2
n
a
6
van 34
10 C o n t i n u ï t e i t
Continuiteitsvoorzieningen voorkomen dat de dienstverlening door storingen en calamiteiten
onaanvaardbaar lang stil komt te liggen (HP-IB-03).
10.1 H e r s t e l van verwerkingen
B-31
Maak ver Wedringen herstelbaar.
Rationale
Waarborg de continuiteit van IT-voorzieningen.
Consequentie
• D e bediening van IT-voorzieningen is niet gebonden aan één fysieke
locatie.
• Datacommunicatievoorzieningen beschikken over automatisch werkende
alternatieve routeringmechanismen om uitval van fysieke verbindingen op
te vangen.
Systemen met hogere beschikbaarheidseisen dan het basisniveau
beschikken over voorzieningen op het gebied van automatic fail-over en
load balancing waarbij de verwerking gespreid is over twee locaties.
• I n d i e n op grond van deze hogere beschikbaarheidseisen de verwerking is
gespreid over twee locaties is de afstand enerzijds zodanig groot dat de
kans minimaal is dat beide locaties getroffen worden door dezelfde
calamiteit, anderzijds zodanig klein dat herstel van communicatiefouten niet
leidt tot nieuwe onherstelbare fouten.
• E r zijn routines voor back-up en recovery van databestanden en software,
voor herstart en foutherstel van verwerkingen.
• B e r i c h t e n die van derden zijn ontvangen en naar derden zijn verzonden
worden minimaal gebufferd totdat er voldoende zekerheid is over de
integere verwerking.
• E r is voldoende buffering van tussenbestanden bij langere
verwerkingsketens.
• D e eisen aan continuiteit zijn vastgelegd in het calamiteitenplan.
10.2 R e d u n d a n t i e
Rationale
Bepaal op basis van de eisen die voortvloeien uit de plannen voor
bedrijfscontinuïteit in hoeverre delen van de technische infrastructuur
meervoudiz_worden uitgevoerd om single-points-of-failure te v e r m i e n .
Consequentie
• D u b b e l e uitvoering van voorzieningen: CPU's, de productieversie van de
software, gegevensopslag zoals RAID op fileservers en databaseservers,
hot of cold stand-by van beheervoorzieningen, clustering technologie van
servers, fysieke verbindingen m.u.v. bekabeling binnen kantoorruimten.
• Z o d a n i g e plaatsing van dubbele IT-voorzieningen dat deze niet op één
fysieke plaats zijn samengebracht (gescheiden kabels niet via één
concern informatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
2
n
9
a
van 34
aansluitpunt) en dat er een veilige afstand tussen locaties bestaat.
• I T -voorzieningen zo mogelijk geografisch spreiden en op dezelfde
technologie baseren.
• S n e l l e beschikbaarheid van reserve-voorzieningen is gewaarborgd.
• E r zijn uitwijkcontracten.
10.3 Vo o r k o m e n discontinuïteit
ft-IB-33
Signaleer discontinultelt voortijde.
,Bron: S O 270012013 12.4
Rationale
Probeer in IT-voorzieningen dreigende discontinuiteit van die voorzieningen te
voorspellen dan wel te signaleren in een zo vroeg mogelijk stadium.
• E r worden standaard voorzieningen geimplementeerd om de
beschikbaarheid van IT-voorzieningen te bewaken op basis van
aanwezigheidssignalen en gebruiksmetingen.
• Overschrijdingen van drempelwaarden worden doorgegeven aan een Event
Console. Deze drempelwaarden kunnen een voorspellende (zoals storage
capaciteit) of een signalerende werking (een cyberaanval) hebben. Er is
een mechanisme en proces om dergelijke overschrijdingen direct te kunnen
signaleren en verwerken.
• E r worden beperkingen opgelegd aan gebruikers en systemen ten aanzien
van het gebruik van gemeenschappelijke resources zodat enkele
gebruikers of een systeem niet een overmatig deel van resources kunnen
opeisen en daarmee de beschikbaarheid van systemen in gevaar kunnen
brengen.
Consequentie
Concern Informatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
3
n
a
0
van 34
11 L o g g i n g en monitoring
Eisen die erop gericht zijn te kunnen vaststellen dat de IT-voorzieningen in overeenstemming met
het vastgestelde inrichtingsdocument (configuratiedossier) functioneren en te signaleren wanneer dit
niet het geval is of kan worden (HP-16-01, HP-16-02, HP-IB-03).
11.1 L o g g i n g
B-34
Rationale
Consequentie
BevelligIngsgerelateerde gebeurtenissen worden vastgelegd.
Bron:1SO 27001:201312.
Handelingen in en meldingen van systeemfuncties in de technische
infrastructuur worden vastgelegd in logging ten behoeve van o.a. foutopsporing,
traceerbaarheid van niet-toegestane acties, werking van maatregelen en
forensisch onderzoek.
De volgende uitgevoerde handelingen worden in ieder geval opgenomen in
de logging:
o g e b r u i k van beheerfuncties en systeemhulpmiddelen;
o handelingen van beveiligingsbeheer;
o beveiligingsovertredingen;
o verstoringen in het productieproces.
In een te schrijven logregel wordt in ieder geval weggeschreven:
o d e naar een natuurlijke persoon herleidbare gebruikersnaam die
verzocht een handeling uit te voeren;
o h e t soort handeling; het gegeven commando met de parameters;
o w a a r mogelijk de identiteit van het werkstation of de locatie;
o h e t middel waarop de handeling werd uitgevoerd of waar een event
optrad;
o h e t resultaat van de handeling indien dit niet uit het soort handeling
is af te leiden;
o d e datum en het tijdstip van een handeling of event;
In een te schrijven logregel worden in geen geval gegevens opgenomen
waardoor de beveiliging doorbroken kan worden.
Log-informatie wordt bewaard totdat de bewaartermijnen verstreken zijn.
Het overschrijven of verwijderen van logbestanden wordt gelogd in de
nieuw aangelegde log.
Bij het schrijven en opslaan van log-regels wordt zoveel mogelijk gebruik
gemaakt van hiervoor ingerichte generieke beveiligingsvoorzieningen.
De volledigheid en juistheid van de logging kan worden vastgesteld.
Het raadplegen van logbestanden is voorbehouden aan geautoriseerde
gebruikers waarbij de toegang is beperkt tot leesrechten.
Beheerders kunnen instellingen van de logging niet wijzigen of
logbestanden verwijderen, tenzij het specifiek hiervoor bevoegde
beheerders zijn. Wanneer een systeem een specifieke rol voor auditing
kent, dan wordt hiervan gebruik gemaakt bij het raadplegen.
Bij de hoogste classificatie wordt de oude staat van gegevens vastgelegd.
Concern intormatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
3
n
1
a
van 34
Rationale B e h e e r s m a a t r e g e l e n worden waar mogelijk gelogd om de werking te kunnen
controleren en afwijkingen te kunnen constateren.
Consequentie
•
Z i e R-IB-34
n te worden door de dateRationale L o g g i n g op verzoek van de data-eigenaar dient expliciet te worden
Consequentie
•
aangevraagd en ingericht.
Z i e R-IB-34
11.2 M o n i t o r i n g
gebeurtenissen w o r n
' . .
8lOgg180 270012013
_
. .
.
Rationale L o g b e s t a n d e n worden periodiek geanalyseerd en gecorreleerd om
beveiligingsincidenten en de juiste werking van het systeem te detecteren.
Consequentie • P e r i o d i e k worden er automatisch analyses uitgevoerd op verschillende
gebeurtenissen, zoals vastgelegd in logging.
Periodiek worden er trendanalyses uitgevoerd en wordt gerapporteerd over
relevante gebeurtenissen in de logbestanden.
4 . oogzoLwaimwm--1 orinifflifflo
.••••
Rationale
Consequentie
3
1
• •
•
.
1
V
•
W
«
• r
-
-
w
a
s
De hoogstehogsteclassificatie laat nauwelijks foutmarges toe, real-time monitoring
voorkomt dat fouten onopgemerkt blijven of zich gedurende langere tijd
manifesteren.
•
R e a l - t i m e worden er automatisch analyses uitgevoerd op verschillende
gebeurtenissen, zoals vastgelegd in logging.
• P e r i o d i e k worden er trendanalyses uitgevoerd en wordt gerapporteerd over
relevante gebeurtenissen in de logbestanden.
Concern Informatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
3
n
a
2
van 34
Bijlage 1: Samenhang uitgangspunten, principes en maatregelen
Uitgangspunten Informatiebeveiliging
Hoofdprincipes Informatiebeveifiging
nte
Logische
Logging en
toegangsbeveiliging
Monitoring
Zonering en
filtering
Continuiteit
Application Controls
Systeem integriteit
Onweerlegbaarheid
van transacties
Informatiebeveiligingseisen
Informatiebeveiligingsmaatregelen
Concern Informatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
3
n
a
3
van 34
Bijlage 2: Referentie
• N O R A , concept beveiligingskatern 2014
http://www.noraonline.nl/wiki/Beveiliqinq
• N E N / I S O 27002:2013, Code voor Informatiebeveiliging
• B a s e l i n e Informatiebeveiliging Gemeenten, KING
https://www.ibdqemeenten.nl/producten/strategische-en-tactische-big/
• R o t t e r d a m s e procesarchitectuur, Gemeente Rotterdam
• C o n c e r n Informatie Architectuur, Gemeente Rotterdam
• C o n c e r n Informatiebeveiligingsbeleid, Gemeente Rotterdam, 2014
• Componentarchitectuur GegevensUitwisselingComponent (GUC), Gemeente Rotterdam
• Componentarchitectuur Basisregistraties en Gegevensmagazijn
• R a a m w e r k e n , richtlijnen, whitepapers Nationaal Cyber Security Centrum (NCSC):
https://www.ncsc.nl/dienstverlenireexpertise-advies/kennisdelinci/whitepapers
• O p e n standaarden:
http://www.forumstandaardisatie.n1/
• Richtsnoeren beveiliging van persoonsgegevens, CBP, 2013
http://www.cbpweb.nl/Pages/pb 20130219 richtsnoeren-beveiligingpersoonSCleclevens.aspx
Concern informatiebeveiliging
Datum
Component Architectuur
12 december 2014
P
a
g
i
3
n
a
4
van 34