Met bovenstaande hebben ze het wel erg klunzig aangepakt. Ook hier weer: Eerst doen dan denken. en dat dan 2x:
eerste keer bij de ontwikkeling van operating systemen en internet:
'gebruik van meerdere toen nog onbekende kwetsbaarheden (zogenaamde zero-day-lekken) in Windows'

2e keer bij de ontwikkeling van de functie die je wilt realiseren.
'als een computer eenmaal toegang had om de PLC te programmeren, vertrouwde de PLC erop dat de aangeboden code legitiem was. '

eerst doen:
'maar dat de beveiliging van het volledige systeem onvoldoende was. De combinatie van kwetsbare Windows-computers, het ontbreken van cryptografische verificatie van PLC-programma's en het vertrouwen tussen alle onderdelen'

dan denken: 'extra beveiligingsmaatregelen ingevoerd, zoals digitale ondertekening van software, strengere toegangscontrole, netwerksegmentatie en betere controle op wijzigingen'

Ja, als je centrifuge gaat bouwen kan je niet alles van nul opbouwen, dat zou onbetaalbaar zijn. Hieronder wat meer details over de aanval.

--------------------------

Stuxnet infecteerde eerst Windows-computers waarop de Siemens Step7-programmeersoftware was geïnstalleerd. Daarbij maakte de malware gebruik van meerdere toen nog onbekende kwetsbaarheden (zogenaamde zero-day-lekken) in Windows om zich te verspreiden en zichzelf uit te voeren. Zodra een geïnfecteerde computer verbinding maakte met een Siemens-PLC, kon Stuxnet de programmacode op die PLC aanpassen.

De PLC controleerde destijds niet of de nieuwe programmacode afkomstig was van een betrouwbare of geautoriseerde bron. Met andere woorden: als een computer eenmaal toegang had om de PLC te programmeren, vertrouwde de PLC erop dat de aangeboden code legitiem was. Dat was in die tijd een gebruikelijke ontwerpkeuze, omdat industriële netwerken meestal als afgesloten en veilig werden beschouwd.

Het bijzondere aan Stuxnet was dat de malware niet alleen de PLC-code wijzigde, maar ook de communicatie tussen de PLC en de programmeersoftware manipuleerde. Daardoor zagen technici op hun scherm de oorspronkelijke, ongewijzigde code en normale meetwaarden, terwijl de PLC in werkelijkheid een aangepast programma uitvoerde. Hierdoor bleef de sabotage lange tijd onopgemerkt.

De aangepaste PLC-software liet de centrifuges in de uraniumverrijkingsinstallatie afwisselend veel sneller en veel langzamer draaien dan normaal. Deze wisselende snelheden veroorzaakten mechanische slijtage en uiteindelijk defecten, terwijl de operators dachten dat het systeem normaal functioneerde.

De belangrijkste les van Stuxnet is daarom niet dat er een eenvoudige programmeerfout in de Siemens-PLC zat, maar dat de beveiliging van het volledige systeem onvoldoende was. De combinatie van kwetsbare Windows-computers, het ontbreken van cryptografische verificatie van PLC-programma's en het vertrouwen tussen alle onderdelen van het industriële netwerk maakte de aanval mogelijk. Sindsdien hebben veel fabrikanten extra beveiligingsmaatregelen ingevoerd, zoals digitale ondertekening van software, strengere toegangscontrole, netwerksegmentatie en betere controle op wijzigingen aan PLC-programma's.

[quote=wnvl1 post_id=1278517 time=1781896410 user_id=83230]
Die centrifuges zijn afgesloten van het internet. Ze hebben echter een virus verspreid over heel Iran. Dat is via een USB stick op de Siemens plcs van de sturing van de centrifuges gekomen. Dat was wel een projectje dat rechtstreeks opgevolgd werd door de president.
[/quote]
Een goed stuk software is zo geschreven dat het ongevoelig is voor virussen. Maar het probleem is dat er vaak gebruik wordt gemaakt van standaard software onderdelen die je niet goed begrijpt onder de motorkap. oplossing is helemaal vanaf scratch beginnen om iets op te bouwen wat wel robuust is. maar dat kost heel veel programmeer urenm dus uiteindelijk is geld weer het probleem waarom ''Elke Software kan gehackt / gekraakt worden.''

Hoe bedreven moet men eigenlijk zijn om een informatica virus . zoals een trojaan ....... te maken?
Worden die echt gemaakt door anti virus ontwerpers ..... omdat de gepaste anti virus software te ontwikkelen / aan te passen. ?

Die centrifuges zijn afgesloten van het internet. Ze hebben echter een virus verspreid over heel Iran. Dat is via een USB stick op de Siemens plcs van de sturing van de centrifuges gekomen. Dat was wel een projectje dat rechtstreeks opgevolgd werd door de president.

Ik kan me niet voorstellen dat er niet iets slims te bedenken is wat ongewenste toegang onmogelijk maakt voor zulke kritische systemen.

[quote=ukster post_id=1278511 time=1781865814 user_id=76233]
Al in 2010 lieten de VS en Israël met de Stuxnet-worm zien dat software fysieke centrifuges in een Iraanse nucleaire installatie letterlijk kapot kon laten draaien.
[/quote]
Ja, dat vind ik een geweldig verhaal. Daar zijn goede boeken over geschreven. Je vindt er ook veel youtube films over.

De essentie van oorlogsvoering en sabotage is in de kern niet veranderd, alleen het slagveld is verplaatst van fysieke bronnen naar digitale netwerken. Wat de Romeinen deden met fysiek gif, kan vandaag de dag inderdaad digitaal worden nagebootst door vitale infrastructuur plat te leggen of te manipuleren.

Vroeger had je fysieke toegang nodig om schade aan te richten; tegenwoordig kan dat vanaf de andere kant van de wereld. Dit is een reëel scenario waar inlichtingendiensten en cybersecurity experts dagelijks mee bezig zijn:

Cyberaanvallen op nutsvoorzieningen: Waterzuiveringsinstallaties, elektriciteitsnetwerken en ziekenhuizen draaien op zogenaamde ICS/SCADA-systemen (industriële besturingssystemen). Als hackers binnendringen, kunnen ze in theorie chemische doseringen in het drinkwater aanpassen of de stroom uitschakelen.

In 2021 was er een bekend incident in Oldsmar, Florida, waarbij een hacker probeerde de hoeveelheid natriumhydroxide (loog) in het drinkwater naar een gevaarlijk niveau te verhogen. Gelukkig merkte een oplettende operator de cursor live op zijn scherm en greep meteen in.

Al in 2010 lieten de VS en Israël met de Stuxnet-worm zien dat software fysieke centrifuges in een Iraanse nucleaire installatie letterlijk kapot kon laten draaien.

@Ukster,

Dank U,

Mijn intuitie voor het formuleren van de twee stellingen wordt bevestigd.
Ben tevreden dat mijn intuitie en een beetje Biologische Inteligentie mijn gebrek aan parate kennis compenseert ! 8-)

[b]Al bij al gaat de mensheid een gevaarlijk pad op door alles te willen informatiseren![/b]
Vroeger vergiftigden de Romeinen het drinkwater van de vijand ....... nu kan "de vijand" de complete maatschappij ontregelen en menigvuldige systemen onbruikbaar maken.

De beschrijving van ukster is in hoofdzaak van toepassing op grote, complexe en algemeen inzetbare computersystemen, zoals besturingssystemen, bedrijfsnetwerken en internetdiensten. Voor kleinere en sterk afgebakende systemen ligt de situatie genuanceerder. Wanneer een systeem slechts een beperkte taak uitvoert, weinig programmacode bevat en geen onnodige functionaliteit of externe toegang heeft, wordt het veel eenvoudiger om het volledige gedrag van dat systeem te analyseren. In zulke gevallen kunnen voor bepaalde eigenschappen zelfs formele, wiskundige bewijzen worden geleverd dat het systeem zich altijd volgens de specificatie gedraagt. Daar wordt veel onderzoek naar gedaan.

Dat betekent echter niet dat kleine systemen automatisch honderd procent veilig zijn. Een formeel bewijs bewijst alleen dat het systeem voldoet aan de eigenschappen die in de specificatie zijn vastgelegd. Wanneer de specificatie zelf onvolledig of onjuist is, kan het systeem nog steeds ongewenst gedrag vertonen, ondanks het formele bewijs. Bovendien kunnen fouten in de compiler, de hardware of de processor de garanties van de software ondermijnen. Ook fysieke aanvallen, zoals manipulatie van de hardware of side-channel-aanvallen, vallen vaak buiten het model waarop het bewijs is gebaseerd.

[quote=Regor post_id=1278497 time=1781809277 user_id=88665]
Nu ga ik graag een stap verder.
Stelling 2: Men kan geen beveiligingen / firewalls maken die niet gekraakt kunnen worden ! 8-)
[/quote]

In de informatica wordt het streven naar "100 procent zekerheid" of "absolute veiligheid" algemeen beschouwd als onhaalbaar. Enkele kernpunten uit de literatuur die dit onderbouwen:

* **Fundamentele onmogelijkheid:** Er is geen 100 procent garantie dat een computersysteem volledig te vertrouwen is of vrij is van kwetsbaarheden (Arbaugh, 2004). Ondanks decennia aan onderzoek naar cybersecurity zijn er geen systemen die als "onkraakbaar" kunnen worden bestempeld (Chiueh, 2003).
* **Beperkingen van firewalls:** Firewalls zijn essentieel voor netwerkbeveiliging, maar ze zijn niet onkraakbaar en kunnen fouten bevatten (Chary, 2023). Aanvallers vinden voortdurend nieuwe manieren om firewalls en netwerkbeveiliging te omzeilen (Chary, 2023). Bovendien kunnen firewalls een vals gevoel van veiligheid geven, omdat ze vaak kwetsbaarheden hebben die door hackers worden uitgebuit (Shaikh, 2010).
* **Menselijke en operationele factoren:** Veel beveiligingslekken ontstaan niet alleen door technische fouten, maar ook door menselijke factoren, zoals sociale engineering (het misleiden van gebruikers om wachtwoorden of informatie prijs te geven) (Chary, 2023), (Chiueh, 2003). Daarnaast kan de complexiteit van het correct configureren en beheren van beveiligingssystemen de capaciteiten van gebruikers overstijgen, wat leidt tot nieuwe kwetsbaarheden (AlFayyadh, 2010).
* **Een voortdurende wapenwedloop:** Cybersecurity is een dynamisch veld. Zodra een beveiligingsmethode wordt verbeterd, ontwikkelen aanvallers nieuwe technieken om deze te omzeilen (Cheswick, 2003), (Singleton, 2002).

Vanwege deze realiteit verschuift de focus in de cybersecurity vaak van het streven naar absolute ondoordringbaarheid naar **risicobeheer** en **intrusiereactie** (het verminderen van de schade en het snel kunnen herstellen van systemen na een inbreuk) (Chiueh, 2003), (Singleton, 2002). Een gelaagde verdedigingsstrategie, waarbij firewalls worden ondersteund door andere beveiligingstechnologieën en best practices, is noodzakelijk voor een betere bescherming, maar zelfs dan blijft een restrisico bestaan (Putra, 2025).

* (Arbaugh, 2004) Arbaugh, W (2004). A Patch in Nine Saves Time? Computer, 37, 82-83. <https://doi.org/10.1109/MC.2004.1>
* (Chiueh, 2003) Chiueh, T et al. (2003). How to Repair Compromised Information Systems Quickly ? <https://www.semanticscholar.org/paper/6b516364f3d2999b65c56bdbd9a419305549fb43>
* (Chary, 2023) Chary, G et al. (2023). Evaluating the Effectiveness of Tree-based Machine Learning Classifiers for Cybersecurity Threat Detection. 2023 IEEE International Conference on Contemporary Computing and Communications (InC4), 1, 1-6. <https://doi.org/10.1109/InC457730.2023.10262889>
* (Shaikh, 2010) Shaikh, Z, Ahmed, F (2010). Disarming firewall. 2010 International Conference on Information and Emerging Technologies, 1-6. <https://doi.org/10.1109/iciet.2010.5625739>
* (AlFayyadh, 2010) AlFayyadh, B et al. (2010). Vulnerabilities in personal firewalls caused by poor security usability. 2010 IEEE International Conference on Information Theory and Information Security, 682-688. <https://doi.org/10.1109/ICITIS.2010.5689490>
* (Cheswick, 2003) Cheswick, W et al. (2003). Firewalls and Internet Security: Repelling the Wily Hacker. <https://www.semanticscholar.org/paper/3dd8f482a6bd8811e4fd116443c24d352c9a2ab7>
* (Singleton, 2002) Singleton, T (2002). Managing the Most Critical Internet Security Vulnerabilities: One Effective Approach. EDPACS, 30, 1 - 11. <https://doi.org/10.1201/1079/43285.30.2.20020801/37807.1>
* (Putra, 2025) Putra, F P E et al. (2025). Firewall Implementation as a Computer Network Security Strategy for Data Protection. Brilliance: Research of Artificial Intelligence. <https://doi.org/10.47709/brilliance.v5i1.6162>

[quote=HansH post_id=1278505 time=1781819689 user_id=26240]
[quote=Regor post_id=1278501 time=1781815660 user_id=88665]
@HansH,

Neen Hans, helaas niet . onder geen enkel operating systeem !
[/quote]
de software in mijn horloge of fietscomputer is niet te kraken of te veranderen. het operating systeem daarvan is immers niet toegankelijk van buiten af.
[/quote]
Dan kan het mogelijk nog als je fysieke toegang hebt.

[quote=Regor post_id=1278504 time=1781819217 user_id=88665]
@wnvl1,

U schreef:
" Bij een kleine microkernel is zo'n formeel bewijs daarentegen wel haalbaar."

Wat is er daarentegen "wel" haalbaar ?
[/quote]

Met een formeel bewijs bedoel ik een wiskundig bewijs dat een programma aan een exact gespecificeerde eigenschap voldoet. Het is dus geen "we hebben veel getest", maar een bewijs zoals in de wiskunde: als de aannames kloppen, dan volgt de eigenschap onvermijdelijk.

Bij een microkernel kan men bijvoorbeeld bewijzen dat:

[list][*]Geheugenisolatie: een gebruikersproces kan nooit het geheugen van een ander proces lezen of overschrijven.
[*]Toegangscontrole: alleen processen met de juiste rechten kunnen een bepaalde systeemaanroep uitvoeren.
[*]Afwezigheid van bepaalde programmeerfouten: geen buffer-overflows, null-pointer-dereferences, gebruik van niet-geïnitialiseerd geheugen, enzovoort (voor de geverifieerde code).
[*]Correctheid van de kernel: elke systeemaanroep doet precies wat de formele specificatie voorschrijft.
[*]Informatiestromen: geheime informatie kan niet via de kernel naar een ongeautoriseerd proces lekken (non-interference).[/list]

[quote=Regor post_id=1278501 time=1781815660 user_id=88665]
@HansH,

Neen Hans, helaas niet . onder geen enkel operating systeem !
[/quote]
de software in mijn horloge of fietscomputer is niet te kraken of te veranderen. het operating systeem daarvan is immers niet toegankelijk van buiten af.

@wnvl1,

U schreef:
" Bij een kleine microkernel is zo'n formeel bewijs daarentegen wel haalbaar."

Wat is er daarentegen "wel" haalbaar ?