🌵OldMartijntje

avans 2-2 m2 w3 hoe wordt je weerbaar tegen cybercriminelen

7 min read

ID: S202603091233
Status: school
Tags: Avans 2-2 Keuzenmodule, Cybersecurity

avans 2-2 m2 w3 hoe wordt je weerbaar tegen cybercriminelen

Wanneer is software veilig?

Kernel level anti-cheat mentioned verbally.

Sleutelingrediënten:

  • Unsanitized inputs
  • Sandboxing

The CIA Triad mentioned in the slides.

Veilige software is software die de opgestelde security doelstellingen heeft behaald. Deze doelstellingen beschrijven de eisen van het softwaresysteem op het gebied van vertrouwelijkheid, beschikbaarheid en integriteit - The CIA Triad Security doelstellingen en eisen worden door een ridicoanalyse inzichtelijk gebracht.

Security bijt vaak met andere afwegingen. Denk bijvoorbeeld aan privacy of usability. Dit is een trade-off.

Developers zijn vaker dan ze zelf toegeven het target en de sjaak van Phishing.

Opstellen van securityeisen

(must-haves)

  • Intarnationale (security) standaarden (IEC62443, ISO27002)
  • Wetgeving (NIS, CRA, AI Act, …)
  • Stakeholders
  • Gebruikers
  • Maatschappelijke belangen
  • Ethiek: normen en waarden

Cyber Resilience Act - CRA

  • Secure-by-design: Beveiliging moet vanaf de ontwerpfase worden meegenomen
  • Verplichte beveiligingsupdates: Gedurende de hele levenscyclus van het product
  • Beoordeling van externe parties: Voor kritieke producten is een externe veiligingsbeoordeling vereist
  • CE-markering: Producten die voldoen aan de CRA krijgen een CE-label als bewijs van naleving
  • Meldplicht: Actief misbruikte kwetsbaarheden moeten binnen 24 uur gemeld worden bij de ENISA
  • Verantwoordelijkheid ligt bij fabrikanten, importeurs en distribiteurs om te zorgen dat producten veilig zijn en blijven

NEN connect mentioned.

Veilige software is niet alleen coderen

  • Management commitment
  • Organisatie cultuur, het willen delen van fouten die je (bijna) maakte om de rest van het bedrijf te helpen
  • Veilige omgeving
  • Securitytesten (SAST en DAST)
  • Secure deployment, je wilt dat het automatishc gebeurt, en dat je een hash hebt van je nieuwste built zodat je kan checken of het correct is.
  • Secure code practices

Na deployment:

  • Vinden en monitoren (ook op externe libraries) van kwetsbaarheden
  • Bug bounty programs
  • Incident response
  • Update en patch management
  • Herstelplannen en procedures

Kwetsbaarheden met mogelijke grote gevolgen

  • Onvoldoende testen op een software update
    • Crowdstrike AV blue screen of death
  • Eenvoudig te raden wachtwoorden / standaard wachtwoorden
    • Administrator account van een nucleaire raketinstallatie.
  • ransomeware downloaden omdat je een cracked game wilt
  • backdoors geïmplementeerd door hackers

Common vulnerability Scoring System - CVSS

  • Een gestandaardiseerd raamwerk om de ernst van beveiligingslekken gevonden in software te beoordelen en te communiceren
  • CVSS is een numerieke waarde die de ernst van een beveiligings-kwetsbaarheid beoordeelt, gebaseerd op verschillende criteria zoals uitvoerbaarheid, impact en complexiteit
  • Score van 0.0 tot 10.0

Relevante links:

Secure Software Development Lifecycle & Secure Devops

Een Secure Software Development Life Cycle (SSDLC) is belangrijk omdat het helpt om beveiliging in elke fase van het software- ontwikkelingsproces te integreren, waardoor de kans op kwetsbaarheden en beveiligingsincidenten in de eindproducten wordt verminderd.

Security training

Wat? Het herhalen van de basis security training, van vaak voorkomende problemen en de indicatoren van kwetsbaarheden.

Waarom? Schaalbare manier om kennis te delen en medewerkers de mindset geven, en de security cultuur te brengen.

Wanneer? Nieuwe medewerkers, maar ook jaarlijks als opfrissing.

Architectuur review

Wat? Het onderzoek naar technologie, analyseren van attack surface en het voorkomen van kwetsbaarheden vanaf het 1e ontwerp

Waarom? Meeste kwetsbaarheden worden tijdens het ontwerp geïntroduceerd, architectuur problemen zijn achteraf lastiger aan te passen. Ook moet het Secure-by-default.

Wanneer? Tijdens productplanning.

Security requirements

Wat? Het opzoeken van de best practices in de context van jouw applicatie met op maat gemaakte software.

Waarom?

  • Afvinken van een checklist
  • Afronden van tickets
  • meenemen in sprints
  • realisatie tijdens bouwen van software

Wanneer? Zodra de architectuur is goedgekeurt, als de software taal bekend is of functionele eisen bekend zijn.

Threat modelling

Wat? Verbinden van assets, protectie en bedreigingen zodat je bedrijgingen makkelijker kan begrijpen.

Waarom? Het aansluiten van makkelijke aanvalsmogelijkheden

Wanneer? Als het architectuur is goedgekeurd, als de dataflow diagrammen beschikbaar zijn of het connectieontwerp beschikbaar is.

Tools?

  • Microsoft Threat Modeling Tool
  • OWASP Threat Dragon
  • Irius Risk
  • Handmatig tekenen kan ook

Zorg dat je applicatie specefieke threats kiest en niet de standaard shit.

Threat modeling is een gestructureerde aanpak om security risico’s te identificeren, kwantificeren en addresseren. Analyse vanuit het perspectief van de potentiële aanvaller Realiseren van een veilig ontwerp en software ontwikkeling Het verbetert de security van de applicatie / product

Hou in de gaten dat dit een iteratief process is.

Kopieer de stappen uit de slides :3

Update [[Threat Modelling Process]] to be like, more of an explenation.

SecDevops

Herhaling

Data flow Diagram

This is basically the threat model.

Ik moet dit nog bijwerken met de slides

Volwassenheids niveaus

Een belangrijke wijze waarop inzicht verkregen wordt in hoeverre een organisatie (of een persoon) een bepaald proces, standaard of wetgeving heeft geïmplementeerd. Voorbeeld is het Capability Maturity Model Integration (CMMI)

Ik moet dit nog bijwerken met de slides

Attack Surface Analysis

Printers, my beloved :LiMessageCircleHeart:

Ik moet dit nog bijwerken met de slides

Verplichtingen

Ik moet dit nog bijwerken met de slides

Opdrachten

Opdracht 1

Voor deze opdracht verdeel je de studiegroep in twee teams: Het audit- en developmentteam.

Auditteam:

  • Leg in je eigen woorden uit wat de CRA inhoudt.
  • Realiseer een vragenlijst om te toetsen of de software van het developmentteam voldoet aan de CRA en of hun software veilig is.

Developmentteam:

  • Kies met elkaar een software applicatie die je eerder hebt gerealiseerd.
  • Bereid de audit voor door de architectuur, ontwerpen en software code op orde te brengen.
  • Evalueer of de software applicatie in deze staat veilig is.
  • Welke secure-by-design principes jullie vooraf beter hadden moeten meenemen?

Gezamenlijk

  • Voor de audit uit met behulp van de vragenlijst en leg het resultaat en conclusie vast. Maak hiervan een paar slides voor de presentatie tijdens de terugkoppeling.

Opdracht 2

  • Kies met elkaar een software applicatie die je eerder hebt gerealiseerd.

  • Beschrijf de 3 belangrijkste design requirements die je in een nieuw project altijd zou meenemen om security by design te waarborgen.

  • Maak een architectuur-review van jullie huidige software en identificeer ten minste 2 designkeuzes die de security verbeteren en 2 die risico’s opleveren. Motiveer met onderbouwing waarom een keuze veilig of onveilig is.

  • Maak van het resultaat een aantal slides voor de presentatie tijdens de terugkoppeling.

Opdracht 3

Dit is een wat meer technische opdracht. Neem de niet-technische studenten mee in het verhaal en zorg dat zij ook mee kunnen discussiëren over de onderwerpen.

  • Kies met elkaar een software applicatie die je eerder hebt gerealiseerd.

  • Voer een attack surface analyse uit: maak een diagram van alle invoer/uitvoerpunten en bepaal waar een aanvaller zou kunnen binnenkomen.

  • Maak een threat model en beschrijf 3-5 realistische dreigingen.

  • Geef per dreigingen aan welke beveiligingsmaatregel jullie zouden implementeren of al hebben geïmplementeerd. Lever zowel een ontwerp als een beargumenteerde toelichting van deze maatregelen.

  • Wat valt je op in de samenwerking tussen technische en niet-technische studenten?

  • Maak van het resultaat een aantal slides voor de presentatie tijdens de terugkoppeling.

Opdracht 4

Dit is een wat minder technische opdracht. Ga met elkaar aan de slag en vul elkaar aan.

  • Kies met elkaar een software applicatie die je eerder hebt gerealiseerd.

  • Stel een voorstel van een ontwerp van een mini-trainingsmodule (max. 1 A4) op die toekomstige developers van jullie team zouden moeten volgen om veillig(er) te programmeren. Welke onderwerpen worden behandeld en waarom?

  • Welke secure coding practices moeten verplicht aan bod komen?

  • Hoe zorgen jullie dat het toepasbaar en meetbaar is in jullie project?

  • Eis: de module moet op maat zijn voor jullie softwarecontext, niet een generieke lijst.

  • Maak van het resultaat een aantal slides voor de presentatie tijdens de terugkoppeling.

References

Graph View

Backlinks