Risicoanalyse Informatiebeveiliging (NEN 7510)
Versie 1.0.0 - juni 2026
Dit document bevat de toegepaste risicoanalyse conform NEN 7510, gericht op de bescherming van informatie-assets binnen Remedice. Dit is de uitkomst (de geidentificeerde risico's, behandeling en restrisico's). De herhaalbare methode waarmee deze analyse tot stand komt is vastgelegd in de Risicobeoordelingsprocedure (NEN 7510-1, H6.1).
1. Methodiek
Risico's worden geevalueerd op basis van:
- BIV-classificatie per asset (Beschikbaarheid, Integriteit, Vertrouwelijkheid)
- Dreigingsmodellering op basis van NEN 7510-2 Bijlage A
- Risicoscore: Kans (1-5) x Impact (1-5). Acceptabel: <= 6, Aandacht: 7-12, Onacceptabel: >= 13
- Risico-eigenaar: Remedice is een eenmanszaak. De risico-eigenaar voor alle geidentificeerde risico's is de verantwoordelijke voor informatiebeveiliging (zie Leiderschap & rollen), die ook de restrisico's accepteert. Bij groei van de organisatie worden eigenaren per domein toegewezen volgens de risicobeoordelingsprocedure.
2. Asset-inventaris en BIV-classificatie
| Asset | Beschrijving | B | I | V |
|---|---|---|---|---|
| Patientgegevens (medicatiebeoordeling) | Naam, geboortedatum, medicatie, CI, allergieen, labwaarden | M | H | H |
| Analyseresultaten | STOPP-NL, ACB, dubbelmedicatie, etc. | M | H | H |
| Chatgegevens (Atlas) | Berichten, bronnen, optioneel gepseudonimiseerde patientcontext (leeftijdsbucket, geslacht, medicatie, CI's, labwaarden) voor RAG-retrieval | L | M | M |
| Accountgegevens medewerkers | Naam, e-mail, rollen, authenticatie | M | H | H |
| OIDC-koppelingen (ZORG-ID/Google/Apple) | Provider en subject-identifier (UserOidcIdentity) |
L | H | M |
| Authenticatie-secrets | Wachtwoord-hashes, TOTP-secrets | L | H | H |
| Audit logs | Beveiligings- en toegangsgebeurtenissen | M | H | M |
| Facturatiegegevens | AGB-code, adres, e-mail | L | M | M |
| Applicatie-infrastructuur | Servers, database, cache, S3 | H | H | M |
| Versleutelingssleutels | FIELD_ENCRYPTION_KEY, KMS keys | L | H | H |
B = Beschikbaarheid, I = Integriteit, V = Vertrouwelijkheid. L = Laag, M = Middel, H = Hoog.
3. Dreigingen en risicobeoordeling
3.1 Externe dreigingen
| # | Dreiging | BIV | Kans | Impact | Score | Maatregelen | Restscore |
|---|---|---|---|---|---|---|---|
| N1 | Phishing / gestolen credentials | V | 3 | 4 | 12 | Verplichte 2FA (TOTP), rate limiting, audit logging mislukte logins, security awareness | 4 |
| N2 | Brute-force aanval op authenticatie | V | 2 | 4 | 8 | Rate limiting (10/min login, 5/min TOTP), account lockout, audit logging | 3 |
| N3 | SQL-injectie of applicatie-exploit | V, I | 2 | 5 | 10 | Django ORM (geparametriseerde queries), inputvalidatie, CSRF-bescherming, regelmatige updates | 3 |
| N4 | DDoS-aanval | B | 2 | 3 | 6 | AWS infrastructuur, auto-scaling, rate limiting | 3 |
| N5 | Ransomware | B, I | 2 | 5 | 10 | Dagelijkse backups, gescheiden backup-opslag (S3), incidentresponsplan | 4 |
| N6 | Man-in-the-middle aanval | V | 1 | 4 | 4 | TLS 1.2+, HSTS, certificate pinning (mobiel) | 2 |
| N7 | Social engineering | V | 3 | 3 | 9 | 2FA, beveiligingsbewustzijn, uitnodigingsgebaseerd accountbeheer | 4 |
3.2 Interne dreigingen
| # | Dreiging | BIV | Kans | Impact | Score | Maatregelen | Restscore |
|---|---|---|---|---|---|---|---|
| N8 | Onbevoegde toegang door medewerker apotheek | V | 2 | 4 | 8 | RBAC, audit logging, least privilege, permission gating in UI | 4 |
| N9 | Opzettelijk datamisbruik door insider | V, I | 1 | 5 | 5 | Audit logging (HIGH-severity), geheimhouding, accountdeactivatie, beperkte admin-toegang | 3 |
| N10 | Onjuiste data-invoer door gebruiker | I | 3 | 3 | 9 | Inputvalidatie, ATC-verrijking via G-Standaard, handmatige correctiemogelijkheid | 4 |
| N19 | Verkeerd geadresseerde interne uitnodiging geeft verkeerde persoon toegang | V | 2 | 5 | 10 | Patientdata-toegang vereist een RBAC-permissie plus step-up (verse tweede factor binnen 30 minuten); uitnodiging via SHA256-gehasht token met 7 dagen geldigheid; HIGH-severity audit logging; intrekken en deactiveren van accounts | 4 |
3.3 Leveranciersrisico's
| # | Dreiging | BIV | Kans | Impact | Score | Maatregelen | Restscore |
|---|---|---|---|---|---|---|---|
| N11 | Datalek bij AWS (incl. Bedrock/Transcribe) | V | 1 | 5 | 5 | DPA, ISO 27001/27017/27018, SOC 2, veldversleuteling (data onleesbaar zonder key), Bedrock zero-retention en geen modeltraining, EU-region eu-central-1 |
2 |
| N12 | Datalek bij Google (Cloud Text-to-Speech, TTS-only) | V | 1 | 3 | 3 | DPA, SCCs, uitsluitend werkafspraken-podcast-script (geen patientdata) naar Google | 2 |
| N13 | Uitval AWS-regio | B | 1 | 4 | 4 | Dagelijkse backups, S3-replicatie, disaster recovery plan | 3 |
| N14 | Stripe datalek | V | 1 | 2 | 2 | PCI-DSS Level 1, geen kaartnummers opgeslagen door Remedice | 1 |
3.4 Technische risico's
| # | Dreiging | BIV | Kans | Impact | Score | Maatregelen | Restscore |
|---|---|---|---|---|---|---|---|
| N15 | Verlies versleutelingssleutel | V, B | 1 | 5 | 5 | Key management via AWS KMS, key rotation, backup van FIELD_ENCRYPTION_KEY | 3 |
| N16 | Database-corruptie | I, B | 1 | 5 | 5 | Dagelijkse backups, PostgreSQL WAL, transaction isolation | 2 |
| N17 | Cross-tenant data lekkage | V | 1 | 5 | 5 | Schema-isolatie (django-tenants), ORM-afscherming, integratietests | 2 |
| N18 | Uitgaand netwerkverkeer naar externe integraties | V, B | 2 | 3 | 6 | Least-privilege egress, geen inkomend verkeer behalve via de load balancer; IaC-beheerd en peer-reviewed. Geen integratie vereist source-IP-allowlisting. Onderbouwing in 5.2. | 3 |
4. Statement of Applicability (SoA)
De SoA volgt de controlstructuur van NEN 7510-2:2024 (gebaseerd op ISO/IEC 27002:2022), aangevuld met de zorgspecifieke HLT-beheersmaatregelen. Statuswaarden: Geimplementeerd, In voorbereiding (onderdeel van het certificeringstraject), of N.v.t. met justificatie. De technische statussen zijn geverifieerd tegen de Terraform-stack (infra/) en de Django-settings (backend/config/settings/).
A.5 Organisatorische beheersmaatregelen
| Control | Status | Implementatie / justificatie |
|---|---|---|
| A.5.1 Beleidsregels informatiebeveiliging | Geimplementeerd | Dit document + beveiligingsbeleid, goedgekeurd door topmanagement |
| A.5.2 Rollen en verantwoordelijkheden | Geimplementeerd | Verantwoordelijke informatiebeveiliging benoemd, zie Leiderschap & rollen |
| A.5.3 Functiescheiding | In voorbereiding | Eenmanszaak: compenserende maatregelen gedocumenteerd in Leiderschap & rollen; scheiding bij eerste medewerker |
| A.5.7 Informatie en analyses over dreigingen | Geimplementeerd | Dreigingsmodellering in dit document; bronnen in risicobeoordelingsprocedure |
| A.5.9-A.5.10 Inventarisatie en aanvaardbaar gebruik | Geimplementeerd | Asset-inventaris hierboven; informatiestromen in communicatiebeveiliging |
| A.5.12-A.5.14 Classificatie, labelen, overdracht | Geimplementeerd | BIV-classificatie; gezondheidsinformatie uniform als vertrouwelijk |
| A.5.15-A.5.18 Toegangsbeveiliging, identiteit, authenticatie, toegangsrechten | Geimplementeerd | RBAC per tenant, zie toegangsbeleid |
| A.5.19-A.5.23 Leveranciersrelaties en clouddiensten | Geimplementeerd | DPAs, subverwerkersregister |
| A.5.24-A.5.28 Incidentbeheer | Geimplementeerd | Datalekkenprotocol, incidentenregister, leren van incidenten |
| A.5.29-A.5.30 Continuiteit en ICT-gereedheid | Geimplementeerd | Back-ups en PITR; hersteltest in voorbereiding (zie A.8.13) |
| A.5.31, A.5.36 Wettelijke eisen en naleving | Geimplementeerd | Nalevingsregister |
| A.5.33 Beschermen van registraties | Geimplementeerd | Audit logs met Object Lock, zie logbeleid |
| A.5.34 Privacy en bescherming persoonsgegevens | Geimplementeerd | AVG-dossier (privacyverklaring, DPIA, verwerkingsregister) |
| A.5.35 Onafhankelijke beoordeling | In voorbereiding | Externe penetratietest/audit gepland in certificeringstraject |
| A.5.37 Gedocumenteerde bedieningsprocedures | Geimplementeerd | Runbooks en deployment-procedures, zie change management |
| A.5.38-A.5.43 (HLT) Zorgspecifiek | Geimplementeerd | Beveiligingseisen in ontwikkeling (A.5.38), unieke patientidentificatie (A.5.39), externe meldplicht incidenten (A.5.43) |
A.6 Mensgerichte beheersmaatregelen
| Control | Status | Implementatie / justificatie |
|---|---|---|
| A.6.1 Screening | In voorbereiding | Eenmanszaak zonder personeel; screening (VOG) wordt ingevoerd bij eerste medewerker, zie Personeelsbeveiliging |
| A.6.2 Beveiligingsrollen in functiebeschrijving | In voorbereiding | Procedure vastgelegd; toepassing bij eerste medewerker |
| A.6.3 Bewustwording en training | In voorbereiding | Programma vastgelegd in Competentie & bewustwording |
| A.6.4 Disciplinaire procedure | In voorbereiding | Vastgelegd in Personeelsbeveiliging; van kracht bij personeel |
| A.6.5-A.6.6 Verplichtingen na beeindiging, geheimhouding | In voorbereiding | Geheimhoudingsverplichting vastgelegd; ondertekening bij eerste medewerker |
| A.6.7 Werken op afstand | Geimplementeerd | Versleutelde verbindingen, MFA, beheerde endpoints |
| A.6.8 Melden van gebeurtenissen | Geimplementeerd | Meldkanaal via datalekkenprotocol |
| A.6.9 (HLT) Managementtraining | In voorbereiding | Zie Competentie & bewustwording |
A.7 Fysieke beheersmaatregelen
| Control | Status | Implementatie / justificatie |
|---|---|---|
| A.7.1-A.7.14 Fysieke beveiliging | N.v.t. (gedelegeerd) | Geen eigen datacenter; gedelegeerd aan AWS eu-central-1 (ISO 27001, SOC 2, fysieke datacenterbeveiliging) |
| A.7.10 Opslagmedia (HLT-versleuteling) | Geimplementeerd | Geen verwijderbare media; gezondheidsinformatie altijd versleuteld at rest |
A.8 Technologische beheersmaatregelen
| Control | Status | Implementatie / justificatie |
|---|---|---|
| A.8.1-A.8.5 Endpoint, speciale rechten, toegang, broncode, authenticatie | Geimplementeerd | RBAC, verplichte 2FA (A.8.5 HLT) voor alle gebruikers van gezondheidsinformatie |
| A.8.6 Capaciteitsbeheer | Geimplementeerd | AWS auto-scaling, monitoring |
| A.8.7 Bescherming tegen malware | N.v.t. (gedelegeerd) / In voorbereiding | Beheerde Fargate-images; GuardDuty/WAF opt-in bij eerste betalende klant |
| A.8.8 Beheer van technische kwetsbaarheden | Geimplementeerd | bandit + ruff (harde CI-poort), ECR scan_on_push; Dependabot voorzien |
| A.8.9 Configuratiebeheer | Geimplementeerd | Infrastructure-as-Code (Terraform), peer-reviewed |
| A.8.10-A.8.12 Wissen, maskeren, datalekpreventie | Geimplementeerd | Erasure-flows, pseudonimisatie, veldversleuteling |
| A.8.13 Back-up van informatie (HLT-versleuteling) | Geimplementeerd (back-up); hersteltest in voorbereiding | Aurora PITR 35d (prod), KMS-versleuteld; geregistreerde hersteltest wordt ingericht |
| A.8.15-A.8.16 Logging en monitoren | Geimplementeerd | CloudWatch met expliciete retentie, zie logbeleid |
| A.8.17 Kloksynchronisatie | Geimplementeerd (AWS-beheerd) | Fargate synchroniseert met AWS-tijdbronnen |
| A.8.20-A.8.23 Netwerkbeveiliging en -segmentatie | Geimplementeerd | TLS 1.2+, security groups, beveiligingsheaders (HSTS/CSP); WAF opt-in |
| A.8.24 Gebruik van cryptografie | Geimplementeerd | Fernet (AES-128-CBC + HMAC) veldversleuteling, TLS 1.2+, KMS (AES-256) at rest |
| A.8.25-A.8.31 Veilige ontwikkeling | Geimplementeerd | IEC 62304, code review, gescheiden omgevingen, beveiligingstesten in CI |
| A.8.32 Wijzigingsbeheer | Geimplementeerd | Zie change management |
| A.8.33 Testgegevens | Geimplementeerd | Staging bevat geen echte patientdata |
| A.8.34 Bescherming tijdens audits | Geimplementeerd | Auditactiviteiten op operationele systemen vooraf afgestemd |
| A.8.35 (HLT) Zero-trust-beginselen | Geimplementeerd | Tenant-isolatie, least-privilege security groups, per-request authenticatie |
5. Restrisico-acceptatie
Na implementatie van alle maatregelen zijn alle restrisicoscores <= 4 (acceptabel). De eigenaar van Remedice accepteert de restrisico's. De verwerkingsverantwoordelijke (apotheek) wordt via deze documentatie geinformeerd over het restrisicoprofiel.
5.1 Bewuste risicoacceptatie: WebLogin strikte modus
De WebLogin-functionaliteit (QR-gebaseerde device-registratie) heeft optionele strikte validatie van user-agent en IP-adres. Deze zijn bewust uitgeschakeld in productie (WEBLOGIN_STRICT_UA=False, WEBLOGIN_STRICT_IP=False).
Reden: Mobiele netwerken wisselen regelmatig van IP-adres (carrier-grade NAT, WiFi/4G-switching). Strikte IP-validatie leidt tot veel fout-negatieve afwijzingen, wat de bruikbaarheid ernstig vermindert.
Compenserende maatregelen: - TOTP-verificatie verplicht bij elke WebLogin-sessie - Device trust via HMAC challenge-response - Rate limiting op WebLogin-endpoints (start: 10/min, status: 120/min, confirm: 30/min) - Audit logging van alle WebLogin-pogingen - Automatische sessie-expiratie
5.2 Bewuste risicoacceptatie: uitgaand netwerkverkeer
Het uitgaand netwerkverkeer naar externe integraties is bewust beperkt tot wat functioneel nodig is, via least-privilege netwerkregels die als Infrastructure-as-Code worden beheerd en bij wijziging peer-reviewed.
Reden: geen enkele externe integratie vereist source-IP-allowlisting. De gekozen opzet levert op deze schaal gelijkwaardige beheersing zonder extra vaste kosten en failure-modes.
Compenserende maatregelen: - Least-privilege egress, geen inkomend verkeer behalve via de load balancer - Infrastructure-as-Code beheert alle netwerkregels, peer-reviewed bij wijziging - Geen langdurige inkomende verbindingen op de taken zelf - De afweging wordt herzien zodra een integratie expliciet source-IP-whitelisting eist
6. Review
Deze risicoanalyse wordt jaarlijks herzien, of eerder bij:
- Wezenlijke wijzigingen in de technische architectuur
- Nieuwe dreigingsinformatie
- Beveiligingsincidenten
- Wijzigingen in het subverwerkerlandschap