Door Anoniem: Het is een kwalijke suggestie dat dit soort verbieden uberhaupt zou kunnen.
Er is heel veel verboden waarvan bleek dat het schadelijk was voor de samenleving. Het verbieden van losgeld betalen lijkt me trouwens niet de beste aanpak (daar kom ik zo op terug).
Als je ransom wordt gewared dan tast dat het imago van je bedrijf aan. Het geeft ook een signaal af dat je gemakkelijk ransom gewared kan worden. Waardoor er nog meer gaan proberen om dat te doen. Vrij essentieel dus dat je om te beginnen vrij bent om al dan niet publiek te maken dat je ransom bent gewared. Laat staan er aangifte van zou moeten doen.
Een bedrijf zou er goed aan doen zich meer druk te maken over de reden voor het slechte imago dan om het slechte imago zelf. Wat jij voorstaat is niet de ellende voorkomen waar het imago een deuk van oploopt maar alleen wegmoffelen wat er misgaat. Van mij mag een bedrijf dat grote schade heeft omdat ze hun zaken niet op orde hadden publiekelijk onderuitgaan. Laat ze zich richten op het voorkomen van die ellende.
Als een bedrijf de kans op een ransomware-aanval weet te minimaliseren én het vermogen om snel weer op de been te zijn als het toch gebeurt weet te maximaliseren, wat beide een kwestie is van de IT en IT-security goed op orde hebben en van vooruitdenken over risico's (en niet alleen op imagoschade), dan maken ze qua imago juist een uitstekende beurt als blijkt hoe goed ze de aanval hebben weerstaan of hoe goed ze ervan weten te herstellen.
Dan heb je ook nog de vrijheid van wat je met je eigen (bedrijfs-)geld mag doen. Dat is nog een veel belangrijkere. En zo geschift als wensen dat mensen die beroofd zijn maar allemaal beboet moeten worden wegens het verstoren van de openbare orde. Anders gezegd spreekt er uit zulke verbodssuggesties een enorm onbenul van grondrechten uit.
Verwar bedrijven niet met mensen, dat is niet hetzelfde. En er is helemaal geen grondrecht dat maakt dat je voor de volle 100% over je geld kan beschikken of met je bezit kan doen en laten wat je wil. Als dat zo was zou belasting onmogelijk zijn, en dat kan duidelijk wel. En bedenk ook dat jij een huisdier kan bezitten maar daarmee niet het recht hebt om dat beest te mishandelen. Bedenk dat je een bedrijf kan hebben met machines en werknemers en daarmee niet het recht hebt om de veiligheid van je werknemers te negeren omdat je vindt dat jij mag bepalen dat je geen geld daaraan uitgeeft. Onbenul over (grond-)rechten zie ik vooral bij jou.
Ik schreef dat ik niet denk dat het verbieden van losgeld de beste aanpak is. Dat vind ik omdat het heel problematisch is om een mens of een organisatie die helemaal klem is gezet door een crimineel nog een trap na te geven als die de enige weg uit de shit die geen einde oefening is kiest.
Tegelijk is het wel zo dat deze ellende alleen maar bestaat omdat die lucratief is, en de beste manier om dit te bestrijden is om de winstgevendheid ervan onderuit te halen. Het betalen van losgeld verbieden is een manier om dat te bereiken, maar als je dat net als ik te ver vindt gaan dan is er volgens mij maar één andere optie: voorkomen dat het betalen van losgeld nodig is.
Aangezien bedrijven en andere organisaties duidelijk lang niet allemaal uit zichzelf doen wat daarvoor nodig is denk ik dat hun vrijheid om maar wat aan te modderen en zich bijvoorbeeld alleen op het afdekken van imagoschade te richten aangetast mag en moet worden. Moet? Ja, want je verwerkt nooit alleen gegevens die alleen jou aangaan. Je hebt klanten, leveranciers en andere relaties die ook benadeeld worden als je gegevens gejat worden (en ga daar maar van uit bij een ransomware-aanval). Die hebben ook rechten. Als je zo nodig IT moet toepassen zorg dan ook maar dat je het goed genoeg doet om de rechten van anderen te beschermen.
Daar hoort natuurlijk bij dat het voor met name kleine organisaties niet exorbitant moeilijk moet zijn om het goed te doen. Dat betekent dat de leveranciers van de software die ze gebruiken een grote verantwoordelijkheid hebben om hun systemen
veel robuuster te maken dan ze nu zijn.
Kan dat? Software is razend complex. Maar er zijn een hoop keuzes gemaakt in hoe IT er nu uitziet waar wel degelijk alternatieven voor bestaan en mogelijk zijn. Ik ben qua IT "opgegroeid' in een tijd dat computers in huiskamers alleen bij enthousiaste hobbyisten voorkwamen en serieuze administratieve verwerkingen op mainframes gebeurden. Ik ben COBOL-programmeur geweest in de mainframe-omgeving van een financiële instelling.
Mainframes zijn interessant omdat die in een vroeg stadium van de ontwikkeling van computers en besturingssystemen een andere weg zijn ingeslagen dan bijvoorbeeld Unix[*]. Een kenmerkende eigenschap van die ouderwetse mainframe-applicaties is dat gegevensvelden vaste lengtes hebben. En een bestand is niet, zoals in Unix, een "stream" van bytes maar een opeenvolging van records die gewoonlijk net als de velden erin een vaste lengte hebben. Record- en velddefinities in COBOL-programma's (en PL/1 en nog een aantal talen) zijn simpelweg maskertjes die over geheugen heen worden gelegd met veldformaten die rechtstreeks door de CPU verwerkt kunnen worden (inclusief decimale getalformaten). En verwerking gebeurde record voor record, er werden geen reusachtige aantallen records tegelijk in het programmageheugen geladen. Het effect was dat de volledige geheugenallocatie van een programma op compile-time al vaststond, er geen dynamische geheugenallocatie nodig was tijdens de uitvoering van het programma en dat er nooit data geïnterpreteerd moest worden om een verwerkbaar formaat op te leveren, zoals bij XML, JSON en noem maar op wel het geval is (die dingen
kunnen wel op een mainframe maar in bijvoorbeeld een COBOL-programma gaat dat opmerkelijk moeizaam). Ondanks de beperkingen van vaste veld- en recordlengtes levert die starre benadering een indrukwekkende performance op (mensen met een Windows-achtergrond kunnen zich vaak niet voorstellen dat een systeem met in hun ogen zeer bescheiden specificaties zo ontzettend veel kan verwerken) en slaat die een heleboel bronnen van kwetsbaarheden in software simpelweg over. Als de inhoud van een veld niet compatibel is met de formaatdefinitie van dat stukje geheugen kan een programma crashen, maar dat is geen buffer overflow of misbruik van een kwetsbaarheid in een JPEG- of JSON-library of zoiets, het heeft niet dat soort neveneffecten.
Het zou te ver gaan om te claimen dat mainframes onkwetsbaar zijn, dat moet je nooit claimen (al doen ze het indrukwekkend goed), en ik bedoel dit ook niet als pleidooi om terug te gaan naar die opzet — die starheid heeft duidelijk ook grote nadelen. Ik wil er wel mee aangeven dat de IT die we gewend zijn niet de enige mogelijkheid is, en zelfs niet het enige
soort mogelijkheid. Computers zijn flexibel genoeg om wezenlijk andere benaderingen dan we gewend zijn te ondersteunen, en ik denk dat onze problemen met ransomware en andere kwetsbaarheden voor een niet gering deel een gevolg zijn van de benaderingen die in de loop van de jaren zijn gekozen en die we nu gebruiken.
Een
general purpose-besturingssysteem als Windows of Unix/Linux is helemaal niet per definitie de beste keuze voor de kritische applicaties van bedrijven, overheden en andere organisaties. Je hebt het daar over kale gegevensverwerking, domweg wat er moet gebeuren zonder toeters en bellen. Dat kan op een behoorlijk spartaans besturingssysteem, met behoorlijk spartaanse software (een fancy UI kan dat daarbuiten bestaan met de juiste interface-software) en basale gegevenstypen. Zelfs de onderliggende bestandssystemen zouden wel eens veel simpeler kunnen[**]. Dat zou tot systemen kunnen leiden die inherent heel wat minder kwetsbaar zijn dan wat we nu gewend zijn.
Als de
kern van een administratie, met niet meer dan tekst en getallen en geen fancy dingen als plaatjes en filmpjes en muziek en dynamische formaten als XML, draait op een systeem dat zo simpel is dat, juist omdat het zo simpel is, niet kapot te krijgen is, dan heb je een basis die goed tegen ransomware en andere aanvallen te beschermen is
en waar je mee verder kan werken als het buiten die kern misgaat.
Ik denk dus dat het antwoord op de kwetsbaarheden die uit de hand aan het lopen zijn wel eens eenvoud kan zijn. Niet alleen maar toevoegen aan wat er al gebouwd is maar juist dingen loslaten die niet goed uitpakken en mogelijk simpelere benaderingen kiezen. Dat geldt op het niveau van besturingssystemen, en ook voor applicaties: maak een simpele, spartaanse kern die alles bevat wat essentieel is en draait op een systeem dat niet stuk te krijgen is. Gebruik voor gebruiksgemak aparte systemen die daar weer goed in zijn, maar accepteer ook dat ook dat wat spartaanser kan uitpakken dan je nu gewend bent als dat voor de veiligheid en robuustheid van je gegevens nodig is. Een werksysteem is geen recreatiesysteem.
Goed. We zitten hier enorm ver vanaf en ik verwacht niet dat het die kant opgaat. Maar ik vind eigenlijk wel dat de grote softwareleveranciers een plicht hebben om die kwaliteit te leveren. Anders is het voor kleinere organisaties
wel exorbitant moeilijk om hun IT goed te krijgen.
[*] Ik heb op deze website gezien dat menigeen denkt dat mainframes Unix-systemen zijn. Nee, de echte mainframebesturingssystemen zitten wezenlijk anders in elkaar, maar de architectuur is ondanks allerlei starre kanten wel flexibel genoeg om full-blown Unix- of Linux-
subsystemen te ondersteunen. IBM's Unix-subsubsysteem voor Z/OS voldoet aan alle eisen om een echte Unix genoemd te mogen worden (en is ook gecertificeerd), maar dat betekent in de verste verte niet dat Z/OS Unix
is, het is juist in een hoop opzichten zo verschillend van Unix als je je maar kan voorstellen — maar het draait wel Unix als subsysteem.
[**] Hoe bestanden werken op mainframes is weer een voorbeeld van hoe wezenlijk anders het kan. Vroeger, toen er nog schijven met diameters van pakweg een halve meter of meer werden gebruikt en geen raid-arrays met pc-schijven, alloceerde je in de Job Control Language voor een programma de benodigde
datasets, waarbij recordlengte, blokgrootte, en het aantal benodigde blocks, tracks of cilinders werd gespecificeerd. Een stukje schijf werd vervolgens volgens die specificaties geformatteerd, een low-level-format zoals we die niet eens meer kennen op moderne pc-hardware werd on-the-fly gedaan als programma's werden uitgevoerd. Daarmee was een dataset eigenlijk een mini-partitie waarin één bestand werd opgeslagen zonder dat er een filesysteem (zoals NTFS) tussen zat. Er was een "catalogus" per schijf waarin die op naam konden worden teruggevonden, en een "master catalog" over alle schijven heen waarin alle datasets op naam konden worden gevonden. Dat is een
totaal andere benadering dan hoe we op Unix/Linux, Windows en Mac gewend zijn dat bestanden werken. Alweer zeg ik niet dat dit is waar we naar terug moeten, maar wel dat het als voorbeeld kan dienen voor hoe wezenlijk anders je dingen ook kan benaderen — en andere benaderingen kunnen in het licht van ransomware en andere ellende mogelijk robuuster uitpakken dan wat we nu doen voor onze administratieve gegevens.