ID: S202605291304
Status: school
Tags: avans 2-4, avans 2-4 LU2, avans 2-4 software security en compliance les

avans 2-4 sscl1 wet en regelgeving en compliance

⇐ Les ⇒

Deze lessen gaan veel over een komen met de cybersecurity keuzenmodule.

Dit is een overzicht van deze lessen.

Workshop	Thema	Deliverable
WS01	Wet- & regelgeving, NEN-7510, audit mindset	Begrippenkader
WS02	Hardening CI/CD pipeline (CodeQL, Dependabot, SBOM)	Beveiligde pipeline
WS03	Healthcare Risk Assessment (risicomatrix, bow-tie)	Risicorapport
WS04	Compliance Scanning (CVE/CVSS, Snyk, security backlog)	Scanrapport + backlog
WS05	Secure Coding & Privacy by Design	Logging + tests
WS06	Formeel auditrapport	Definitief auditrapport

• ISO27001 mentioned 🫶

Wet en regelgeving

Je moet je in nederland houden aan je wetten, zowel als individuen en organisaties. Dit kan consequenties hebben als je dat niet doet.

Verschillen tussen termen

• Wet: Deze wetten zijn alndelijk en EU breed afdwingbaar.
  • “ik wist het niet” zal je niet redden in de rechtzaak.
  • vastgesteld door landelijke overheid
  • altijd bindend
  • overtreden → sancties
  • voorbeelden:
    • wetboek van strafrecht
    • wegenverkeerswet
    • grondwet
    • wet computercriminaliteit
  • zorg voorbeelden:
    • wkkgz
    • Wet aanvullende bepalingen verwerking persoonsgegeven
• Verordering: Gedetailleerde regels, vaak lokaal of EU, ook juridisch afdwingbaar.
  • geldt binnen een gebied
    • bijv gemeente of provincie
  • overtreding → sancties
  • voorbeelden:
    • APV
  • EU:
    • Wet geldig in alle EU lidstaten, lidstaten hoeven zelf geen wet meer te maken, zoals AVG
• Richtlijn: stelt een doel vast.
  • stelt doel vast
  • lidstaten mogen zelf een wet maken om het doel te berijken
  • bijv software richtlijnen:
    • Richtlijn 2009/24/EG betreffende de rechtsbescherming van computerprogramma’s
    • Verplicht EU-landen om computerprogramma’s te beschermen onder het auteursrecht
    • In NL wetgeving: auteurswe
• Norm: Afspraken over hoe iets gedaan wordt.
  • normalisatie instellingen
    • NL: NEN, EU: ETSI, globaal: ISO/ IEC / ITU
  • beroepsgropen
  • beschrijft best practices
  • op zichzelf niet juridisch verplicht
    • kan vereist worden vanuit beroepsgroep / aannemer
      • gekoppeld aan certificering
  • ook interoperabiliteit
  • ISO 27002
  • NEN-7510

Aspect	Wet	Verordening	Richtlijn	Norm
Definition	Eindige, afdwingbare wett(en)	Gedetailleerde regels	Stelt een doel vast	Afspraken (best practices)
Bron	Nationale regering	Lokale/EU autoriteiten	EU	Standaardisatie-instellingen (NEN, ETSI, ISO/IEC/ITU)
Geografisch bereik	Nationaal/EU-breed	Lokaal (gemeenten, provincies) of EU	EU lidstaten	Professionele groepen, globaal
Bindend	Altijd bindend	Ja, binnen regio	Nee - lidstaten maken eigen wetgeving	Nee, maar kan verplicht via certificering
Handhaving	Overtreding → sancties	Overtreding → sancties	Lidstaten implementeren via eigen wet	Gekoppeld aan beroepsgroep/aannemer
Voorbeelden	Strafrecht, wegenverkeerswet, grondwet, WKKGZ	APV	Richtlijn 2009/24/EG (auteursrecht), AVG	ISO 27002, NEN-7510
Toepassing	Direct van toepassing	Direct van toepassing	Omgezet in nationale wet	Geleidraad/richtlijn

Medische gegevens:

• Diagnoses
• Dossiers
• Behandelplannen Deze gegevens zijn erg gevoelig, en mag niet zomaar gebruikt worden daar alle instanties. Hiervoor moet je bijv de HL7 standaarden volgen.

Klein overzicht aan wetten

• AVG / GDPR
• AI Act
• Cyber Resilience Act - CRA
• Cyber Beveiligings Wet - CBW, implementatie van NIS2
  • zorgplicht, meldplicht
• Electronic Identification Authentication and trust Services - eIDAS
  • juridisch kader voor identificatie en vertrouwensdiensten
• Wegiz (gegevensuitwisseling)
• WGBO (behandelovereenkomst)

CRA

Dit is een verordening. het verplicht fabrikanten van producten met digitale elementen om Cybersecurity te borgen gedurende de hele levenscyclus. Van ontwerp tot einde van ondersteuning DIt raakt alle software die als product op de makrt komt (soms dus ook open-source)

Kernverplichtingen

• secure-by-design
  • kwetsbaarheden minimaliseren
  • standaard veilige configuraties
  • bewijs: risicoanalyse, threat model, SAST
• Software Bill of Materials - SBOM
  • formaten: CycloneDX of SPDX
• Kwetsbaarheidsmelding
  • 72 uur volledig rapport
• Support periode
  • voor kritike software is dit ene alngere verwachte ondersteuning
  • einde support: verplichte melding

NEN-7510:2024

Dit is te mappen naar de ISO27001 en ISO 27002.

• Deel 1 van NEN is → ISO27001, Management systeem ISMS
• Deel 2 van NEN is → ISO 27002, Beheersmaatregelen
  • specefieke handelingen
  • vier categorieen
    • organisatie
    • mens
    • fysiek
    • technisch
• extra details specefiek voor zorg.

Gebruik xplora databanken en dan NEN CONNECT om het te bekijken

8.3. Beperking van toegang en rechten

• “Breaking the glass” procedure voor als je buiten je gebruiks rechten iets moet doen in nood, dit moet wel ge-logged en ge-Audit worden 8.4. Toegangsbeveiliging op broncode
• Role based access control
• Gebruik SSH-keys en MFA
• disable force push
  • zie Trivy compromise
• protected branches
• PR only
• code signing
• Audit logging 8.5. Beveiligde authenticatie
• MFA
  • wat je weet, wat je bent, wat je hebt
    • biometrics mag niet de enige methode zijn.
• Wachtwoord beleid
• Controle op lekken
• bescherming tegen brute force
• geen gedeelde accounts
• sessie timeout
• Single Signon - SSO 8.8 Technische kwetsbaarheden
• Software Bill of Materials - SBOM / SCA
  • autmoatische scanning
• patch management
  • balans, direct updaten is mogelijk issues voor supply chain attacks
• Z-CERT
  • computer emergency responce team voor zorg
• Operational Technology - OT
  • patchen is vaak lastig
  • Compenserende maatregelen bijv losse netwerken 8.15 Logging
• wie, wat, waar, wanneer, hoe
  • NEN-7513
  • maatregel: leg voor elke handeling in het EPD / ECD de identiteit van de gebruiker, de identiteit van de patient , het tijdstip en de aard van de handeling vast
  • concrete acite: Zorg dat logs antwoord geven op: Welke zorgverlener (Wie) heeft op welke datum/tijd (Wanneer) welk specifiek onderdeel van het dossier (Wat) van deze patiënt (Bij wie) ingezien of gewijzigd?
• Centraal opslaan
  • Security Information and Event Management - SIEM
• Immutable, append-only
• bewaartermijn 8.16 Monitoring
• Herkennen van verdachte patronen
• Security Orchestration Automation and Response - SOAR
  • als je een service zoals Slack gebruikt, neem het mee in je Threat modelling.
• Beschikbaarheid
  • alarmering bij offline
• alarmering bij gebruik beheer accounts
• threat intelligence
  • koppeling aan Z-CERT
  • Alertheid van grootschalige campagnes 8.17 Kloksynchronisatie
• NTP Servers
• Linken ana logging
• ‘Master’ servers inrichten
  • synchroniseren met autoriseerde bron zoals VSL in nederland

CRA ←> NEN-7510

CRA Verplichting	NEN-7510:2024 Control	Toelichting
Security by design	8.25 – Beveiliging in ontwikkellevenscyclus	Beveiligingseisen vanaf ontwerp documenteren
SBOM-verplichting	8.8 – Beheer van technische kwetsbaarheden	SBOM als bewijs van componentbeheer
Kwetsbaarheidsmeling	6.8 / 5.24 – Informatiebeveiligingsincidenten	Meldtermijn: 24 uur early warning, 72 uur rapport
Support periode	8.8 – Patchbeleid	Minimale ondersteningsperiode vastleggen

Aspect	NEN-7510:2024	CRA (2024/2847)
Scope	Informatiebeveiliging in zorginstelling	Producten met digitale elementen op EU-markt
Doelgroep	Zorgorganisaties (zorginstelling)	Fabrikanten / ontwikkelaars van software
SBOM	Impliciet via 8.8 (componentbeheer)	Expliciet verplichting
Patchbeleid	8.8 – tijdige patch	Minimale supportperiode vastgelegd
Meldplicht	6.8 – interne incidentmelding	24/72u melding aan ENISA
Certification	NEN-certificering door auditor	CE-markering vereist
Sancties	Geen directe boetes (wel aansprakelijkheid)	Tot €15M of 2,5% omzet

Audit mindset

• Niet gelogd is niet gebeurt
• Denken en werken als een Auditor

Pijler	Betekenis
Transparant	Zichtbaar wat er gedaan is en waarom
Aantoonbaar	Bewijs is beschikbaar (logs, documenten, reviews)
Controleerbaar	Een derde partij kan het verifiëren

• Traceerbaarheid (WS 5)
  • Elke wijziging is herleidbaar (wie, wat, waar, wanneer, waarom)
  • (hoe)
• Documenteerbaarheid (WS 4 /5)
  • Beslissingen, ontwerpkeuzes en risico’s zijn vastgelegd
  • ADR’s, commit messages
• Herhaalbaarheid
• Bewust (van risico’s) (WS 3)
• Bewijsgeriecht werken
  • “If it’s not documented, it didn’t happen”
• Principe van ‘Least surprise’ (WS 2)
  • Code en infra zijn voorspelbaar ingericht (consistent)
• Compliant by design
  • Regelgeving vanaf begin meegenomen als ontwerpeis

Logging

• who

• what

• where

• when

• why

• how?

• Technische logging vs audit logging.

  • Spanning met Privacy-by-design
    • gevoelige gegevens

• Denk aan Security vs Privacy

  • wat log je niet?

• Retentie

  • hoe lang ga je het bewaren?

• Beschikbaarheid

  • zelfde host of log server
  • formaat
  • populair: ELK Stack (ElasticSearch, LogStash, Kibana)

• Append-only

• Threat modelling: risico’s van de logs

  • root / admin rechten

Tooling voorzetje:

• RFC 5424 (syslog)
• Populaire stack: ELK Stack
  • ElasticSearch, LogStash, Kibana
• Log4J

Gap Analyse

Een analyse over het verschil tussen de huidige situatie, en de gewenste situatie. Vanuit het oogbunt van NEN-7510. Hoe:

• bepaal doel
• breng huidige situatie in kaart
• beschrijf gewenste situatie
• bepaal verschil tussen huidig en gewenst
• analyseer oorzaken
• maak actieplan

Opdracht

Voor woensdag kiezen welke module je wilt, daarna mag niet meer weizigen. Kies een die niet te makkelijk is, want dan heb je niks meer te doen.

Marcels aanrader:

• phir2
• reporting kies voor de meest complexe, dat maakt het het makkelijkste om dingen te vinden.

Maak niet alleen een repo voor het project, maar echt een github omgeving.

• Richt alvast een GitHub omgeving in
• Tip: Neem als groep even de tijd. Voor dit project is een simplele git omgeving NIET genoeg
• https://github.blog/developer-skills/github/github-for-beginners-getting-started-with- github-issues-and-projects/
• Neem de presentatie van WS 2 alvast door

Vindt en bestudeer drie controls in de NEN-7510-2 norm die van toepassing zijn op jullie project

• B.v. (maar kunnen andere controls zijn)
  1. Beveiliging van logbestanden
     • Worden logs beschermd tegen wijzigingen / unnen superusers (admins) de logs wijzigen?
     • Welke maatregelen kunnen nog meer genomen worden?
  2. Toegangsrechten
     • Hoe dwingt OpenMRS het ‘need-to-know’ principe af?
     • Is dit granulair genoeg voor de dagelijkse gang van zaken binnen een ziekenhuis?
  3. Wachtwoordbeleid
     • Voldoet de standaard configuratie aan moderne eisen?
     • Welke maatregelen kunnen nog meer genomen worden?
     • Zijn er functies (rollen) waarbij een compromis tussen veiligheid en gemak valide is?
• Zoek in de OpenMRS Wiki, github of de broncode op of en zo ja hoe deze controls zijn geïmplementeerd.
• Opleveren
  • Overzicht met ‘Control || OpenMRS oplossing || Risico als het faalt

---

References

• dit is de les van vandaag.