ID: S202603091233
Status: school
Tags: Avans 2-2 Keuzenmodule, Cybersecurity
avans 2-2 m2w3 hoe wordt je weerbaar tegen cybercriminelen
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.
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.
STAP 1: SCOPE VAN THREAT MODELING
ā¢ De eerste stap is de scope van de applicatie of service ā¢ Data Flow Diagram (DFDs) wordt vaak gebruikt om inzicht te krijgen waar het over gaat ā¢ Met een DFD krijg je goed inzicht hoe de applicatie de informatie verwerkt en wat het aanvalsoppervlak is
Let op: Niet geschikt voor een afdeling of organisatie!
STAP 2: BEPALEN VAN KWETSBAARHEDEN EN BEDREIGINGEN
ā¢ Identificeren van de bedreigingen en kwetsbaardheden ā¢ Vaak wordt hiervoor STRIDE toegepast ā¢ Spoofing ā¢ Tampering ā¢ Repudiation ā¢ Information Disclosure ā¢ Denial of Service ā¢ Elevation of privilege
ā¢ Alternatieven: DREAD, PASTA, LINDDUN, OCTAVE, VAST ā¢ āduckduck itā voor meer info over afkorting ā¢ Het doel is om de aanvalsmogelijkheden vanuit een aanvaller te bekijken zoals data bronnen, processen, datastromen en interactie met gebruikers
STAP 3: BEPALEN VAN (TEGEN)MAATREGELEN
ā¢ Een kwetsbaarheid kan worden gemitigeerd met maatregelen ā¢ Maatregelen zijn heel organisatie en context specifiek ā¢ Prioriteer de kwetsbaarheden/bedreigingen door bijvoorbeeld ā¢ Kans op aanval ā¢ Impact van de aanval ā¢ Complexiteit of kosten van de aanval
ā¢ Uiteindelijk kan dezelfde risicobeoordeeling gedaan worden: Accepteer, elimineer, mitigeer of overdragen.
STAP 4: VALIDEER
ā¢ Valideer of de maatregelen effectief zijn ā¢ Is alles aanwezig en compleet? ā¢ Diagrammen ā¢ Ontwerpen ā¢ Lijst bedreigingen en maatregelen ā¢ ā¦ ā¢ Heb je niets gemist? ā¢ Introduceert een maatregel een nieuwe kwetsbaarheid? ā¢ EDR software ā SPF (zie CrowdStrike, Kaseya)
SecDevops
Herhaling
- Secure-by-design: iets is veilig bij het ontwerp van het systeem.
- Secure-by-default: standaard staan niet alle poorten en services open, waardoor het standaard veilig is
- Privacy-by-design: iets is ontworpen om het privacy secure te houden
- Privacy-by-default: standaard is je privacy instellingen goed ingesteld
- hardening
Data flow Diagram
This is basically the threat model.
Een datastroomdiagram (DFD) is een visuele weergave van de informatiestroom binnen een proces of systeem. DFDās helpen je om de werking van processen of systemen beter te begrijpen, mogelijke problemen te ontdekken, de efficiĆ«ntie te verbeteren en betere processen te ontwikkelen.
ā¢ System description ā¢ System environment ā¢ Scenarios ā¢ Permissions ā¢ Cloud provider ā¢ Operating system ā¢ First- and third-party ā¢ Accounts ā¢ Identity & access control ā¢ Tokens & sessions ā¢ Bypass ā¢ Logging, monitoring and backing up ā¢ Network ā¢ Data ā¢ Secrets management
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)
Attack Surface Analysis
Printers, my beloved :LiMessageCircleHeart:
ATTACK SURFACE ANALYSIS HELPT OM ā¢ Identificeren van functies en onderdelen van een systeem die reviewed en getest moeten worden op security kwetsbaarheden. ā¢ Identificeren van onderdelen met een hoog risico dat defense-in-depth noodzakelijk maakt en welke onderdelen beschermd moeten worden. ā¢ Identificeren van aanpassingen wanneer opnieuw een attack surface analyse noodzakelijk is.
ATTACK SURFACE OF AN APPLICATION ā¢ Alle paden van data/commands naar en van de applicatie. ā¢ De code die deze paden beschermd (inclusief koppelingen met resources, authentication, authorization, activity logging, data validation en encoding). ā¢ Alle waardevolle data die wordt gebruikt in een applicatie, inclusief geheimen en sleutels, intellectual property, kritische business data, persoonlijke data, etc. ā¢ De code die deze data beschermd (inclusief encryptie, checksums, audit logs van toegang, data integriteit en operationele security controls. ā¢ Voeg de verschillende gebruikers toe (rollen en privileges), die toegang hebben tot het systeem geautoriseerd of niet, aan het model. ā¢ Focus op de twee extremen: ungeautoriseerd/anonieme gebruikers en gebruiker met de hoogste privileges (admin). ā¢ Groepeer iedere aanvalstype ā¢ Gebruik een aantal voorbeeldcasussen voor ieder type ā¢ Review/asses de casussen
Verplichtingen
DIT IS VANAF EIND 2027 GEWOON VERPLICHT!
ā¢ Cybersecurity is taken into account in planning, design, development, production, delivery and maintenance phase ā SDLC ā¢ All cybersecurity risks are documented ā ISO27005, Bowtie ā¢ Manufacturers will have to report actively exploited vulnerabilities and incidents ā Vulnerability management, incident response ā¢ Once sold, manufacturers must ensure that for the duration of the support period, vulnerabilities are handled effectively ā¢ Clear and understandable instructions for the use of products with digital elements ā¢ Security updates to be made available to users for the time the product is expected to be in use
References
- dit zijn de slides van deze les.
- hier zijn nog 4 bronnen op brightspace die relevant kunnen zijn.
- Something mentioned in the lesson: Operation Grim Beeper
- Irius Risk the threat modelling tool.
- https://nvd.nist.gov/vuln-metrics/cvss
- https://www.cvedetails.com/