Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

'Problemen rond internetbeveiliging zijn op te lossen, we doen het alleen niet'

Door , 102 reacties

Daniel Castro van denktank ITIF sprak tijdens de NCSC One-conferentie over de problemen rond internetbeveiliging en stelde dat deze op te lossen zijn, maar dat het huidige beleid faalt. Hoogleraar Michel van Eeten presenteerde zijn eigen incentives om beveiligingsproblemen aan te pakken.

Castro trok in zijn presentatie op de conferentie in Den Haag de vergelijking met de aanpak van de ziekte pokken in de twintigste eeuw. Hij stelde dat als landen zich eenmaal als doel stellen om een probleem uit te bannen in plaats van alleen maar de symptomen te bestrijden, er een geheel andere strategie ontstaat. Daarom is het belangrijk dat de vraag wordt gesteld wat er bijvoorbeeld gedaan kan worden om de oorzaak van beveiligingsproblemen aan te pakken in plaats van alleen botnets te bestrijden.

Hij beargumenteerde dat het huidige overheidsbeleid op het gebied van internetbeveiliging heeft gefaald. Hij uitte kritiek op het feit dat overheden niet aansprakelijk zijn voor hun eigen tekortschieten op beveiligingsgebied: "Na een incident worden er misschien hier en daar enkele wijzigingen aangebracht en wordt er iemand ontslagen, maar na een paar weken is het weer business as usual."

Daarnaast bekritiseerde hij het streven naar 'cyber superiority', waardoor overheden bijvoorbeeld kwetsbaarheden in software gaan verzamelen. Hij zei dat het argument dat dit noodzakelijk is voor de bescherming van de nationale veiligheid geen hout snijdt: "Dat zou betekenen dat de nationale veiligheid afhankelijk is van programmeerfouten van Microsoft. Dan kan geen steekhoudend argument zijn.” Bovendien zouden door kwetsbaarheden alle systemen gevaar lopen, waardoor er geen ‘wij tegen hen’ bestaat.

Een oplossing is volgens Castro bijvoorbeeld het informeren van consumenten, zodat zij weten hoe het met de beveiliging van een product gesteld staat. Daarnaast moet de overheid nieuwe technieken snel in gebruik nemen en op die manier degelijke beveiliging afdwingen, waarvan consumenten vervolgens weer kunnen profiteren. Ten slotte moet de overheid het bedrijfsleven intensiever ondersteunen, bijvoorbeeld door bug bounties te financieren en responsible disclosure te stimuleren.

In een aparte presentatie sprak TU Delft-wetenschapper Michel van Eeten over manieren om organisaties zover te krijgen om iets te ondernemen tegen gebrekkige beveiliging. Zijn onderzoek richt zich op het verzamelen van gegevens, waardoor zogenaamde performance metrics opgesteld kunnen worden. “Daaraan is bijvoorbeeld te zien wie het goed doet en wie het slecht doet op beveiligingsgebied”, legde hij uit.

Vervolgens kan die data gebruikt worden om organisaties zover te krijgen om actie te ondernemen. Een manier om dat te bereiken is peer pressure en inspelen op de reputatie van organisaties. Dat werkte bijvoorbeeld door isp’s in een gesloten bijeenkomst te confronteren met het aantal botnetinfecties per isp. Daardoor kwam er eentje als slechtste uit de bus, waardoor deze partij zich in gaat zetten om zijn positie te verbeteren. Dat deze aanpak werkt, blijkt uit cijfers die een daling laten zien in het aantal botnetinfecties. Een samenwerking met de politie om bad hosters aan te pakken had daarentegen gemengde resultaten.

Een andere manier is juridische aansprakelijkheid. Daarbij haalde Van Eeten het voorbeeld van de zaak tussen de Consumentenbond en Samsung aan: “Als Samsung beveiligingspatches moet uitbrengen die nota bene al door Google zijn ontwikkeld, dan gaat dat blijkbaar te ver. Maar als een telefoon in de fik vliegt dan is Samsung snel met het uitbrengen van een patch, omdat het duidelijk is dat er aansprakelijkheid is voor schade die daardoor ontstaat."

Daarom zou het op beveiligingsgebied meer de kant van productaansprakelijkheid op moeten gaan. Hetzelfde geldt voor tussenpersonen, bijvoorbeeld voor isp’s die botnets tegengaan. Zij hebben het probleem niet gecreëerd, maar inmiddels accepteert iedereen dat zij in een positie zijn om er iets aan te doen en daarom ook een zorgplicht hebben, aldus de onderzoeker. Dit is bijvoorbeeld ook van toepassing op de beveiliging van internet-of-things-apparaten. Andere oplossingen zijn sociale normen en aanpak via certificaten.

In de presentatie kwam het WannaCry-incident eveneens aan bod. Daarover zei Van Eeten: “WannaCry was niet geavanceerd, het is duidelijk dat het hierbij ging om amateur hour. De kwetsbaarheid in kwestie was al maanden oud en er was al een patch, de vraag is waarom er dan zoveel schade aangericht kan worden. Het komt erop neer dat dit een probleem rond het uitvoeren van patches is. Patches maken dingen stuk en zijn soms de hoofdoorzaak van de uitval van diensten. Daarom is het een economische afweging. Bovendien is het vaak onduidelijk wat er dan gepatcht moet worden. In 2016 waren er 15.000 kwetsbaarheden en om onderscheid te maken is de cvss-score niet behulpzaam, omdat die te veel als ‘kritisch’ wordt bestempeld.”

Moderatie-faq Wijzig weergave

Reacties (102)

Reactiefilter:-11020101+172+218+31Ongemodereerd15
Ik zie een hoop verstandige opmerkingen waar ik het helemaal mee eens ben.

Ten eerste moeten we zorgen dat onze software fundamenteel beter wordt zodat er minder beveiligingsfouten gemaakt worden. Liever nog zie ik de software zo verbeteren dat het makkelijker wordt om goede code te schrijven dan slechte. Denk bijvoorbeeld aan hoe bufferoverflows en pointermanagement in C een dagelijkse problemen waren, terwijl modernere talen die problemen min of meer hebben afgevangen en overbodig gemaakt.
Met name in de systeembibliotheken en ander lowlevel spul dat veel hergebruikt wordt zou zo net betrouwbaar moeten zijn als de software uit de vliegtuigindustrie. Daar weten ze namelijk wel hoe het (relatief) veilig moet. Het kost wat en het gaat allemaal niet zo snel, maar dat hebben ze er voor over.

Ten tweede kan dat alleen als er ook een financiele stimulans is om het goed te doen. Te vaak is software de sluitpost in de begroting. Geld voor onderhoud is er al helemaal niet, terwijl onderhoud over de hele levensduur van een programma al snel duurder is dan het ontwikkelen van de eerste versie.
Zodra bedrijven niet worden afgerekend op de software die ze leveren (en de ondersteuning daar op) zal die stimulans achterwege blijven. Ik vind dat updates voor je OS onder de garantie zouden moeten vallen. Als batterij na 6 maanden begint te lekken krijg je garantie, maar als je telefoon onbruikbaar wordt door lekke software dan heb je geen poot om op te staan.

Overigens denk ik dat het op termijn goedkoper is om het nu een keer goed te doen in plaats van aan te blijven modderen. Nu blijven we met z'n allen maar het wiel opnieuw uitvinden en maken we steeds weer dezelfde beginnersfouten. Een stel echt veilige en betrouwbare basiscomponenten zouden al veel verschil kunnen maken.
"Overigens denk ik dat het op termijn goedkoper is om het nu een keer goed te doen in plaats van aan te blijven modderen."

Big bang conversies zijn ook geen haarlemmerolie, maar men is er wel volslagen onterecht veel te bang voor. Vaak kiest men dan toch voor incrementeel refactoren van oude meuk. Wat op zichzelf prima kan, als het project niet te groot is en zich er voor leent.

Recent voorbeeld wat ik zelf gezien heb was een volle dochter van PostNL die als wens uitsprak een setup op basis van Java/Oracle/Marklogic (niet mijn keuze, maar soit, wie betaalt bepaald) en op dat moment een setup had draaien met PHP, Mysql, Redis, Elasticsearch en Cassandra. Mijn advies was dus vrij simpel: begin opnieuw. Gebruik het bestaande als prototype voor de nieuw in java te ontwikkelen applicatie.

De externe partij (Finalist, in dit geval) was het daar niet mee eens. Die wilden incrementeel gaan refactoren en aanpakken. Hoe erg ik ook het proberen uit te leggen aan het management dat je PHP niet KUNT refactoren naar java, de externe partij wilde dt en risico, angstcultuur, geen ballen, dus drie keer raden wat ze deden. Dat was 2 jaar geleden. Finalist is nu nog steeds in PHP bezig.

Maar ja, dat snap ik ook wel, jarenlang in kleine stappen niets doen, levert aardig wat meer geld op dan in n keer iets goed maken.

Ook leuk; het budget; er zal sinds die tijd zo'n 3 ton in geinvesteerd zijn. Terwijl wat er online draait, als je dat aan een willekeurige javapartij aanbied als nieuw project, ben je voor 10-20k klaar. Ook dat heb ik aangegeven, waarop de managers direct boven mij een beetje witjes uitsloegen, omdat er op dat moment al meer dan een miljoen in geinvesteerd was.

Ook zaken als dingen niet bij een goede externe partij aanbesteden, maar bij een zogenaamde externe partij die toevallig de dag ervoor net door het eigen personeel opgericht was. Ja echt.

15 analisten, security officers, managers, product owners, marketing, vormgevers, stylisten.. en 3 developers. Tsja als je dat fulltime aan de slag zeg, wil het geld wel opgaan.

Dat is het hele probleem. Er wordt gepraat, er worden managementsspelletjes gespeeld, er worden stempeltjes gedrukg, CV's gebouwd, poltiek bedreven.. maar daadwerkelijk keuzes maken of developen, ho maar.

Deze man uit dit artikel doet er dus net zo hard aan meer. Weer imagobuilding, CV bouwen, naamsbekendheid, aandacht, egostrelerij.. maar in de uiteindelijke praktijk? Niets.
Software = politiek. De meeste technici zien dit niet.
Ik neem aan dat dit sarcastisch of trollend bedoeld was. Software is technisch en de meeste politicy (managers) zien dat niet.
Software is technisch, software ontwikkelprojecten zijn politiek. Een succesvol resultaat is zowel van techniek als politiek afhankelijk.
Nee, dus niet. Software is zuiver technisch en software ontwikkeltrajecten ook. Een succesvol resultaat is afhankelijk van het weren van de politiek. Dat is juist mijn hele punt, en dat is jouw denkfout.

Projecten mislukken doordat er een politiek spel van gemaakt wordt waarbij de technische kant ondersneeuwt. Juist dat is mijn hele punt.

Wat wl waar is, en ook als politiek omschreven zou kunnen worden, is dat het voor gebruikersacceptatie belangrijk is dat er naar gebruikers geluisterd wordt. Maar dan wel zuiver functioneel inhoudelijk.
Het is maar net wat je definieerd als succes. Foutloze code is bijvoorbeeld alleen zinnig als je een service levert. Als product wil je dit echt niet. Met software kunnen super mooie dingen gedaan worden. Uiteindelijk draait het toch om de bucks.
Ik zie een hoop verstandige opmerkingen waar ik het helemaal mee eens ben.
Flauw gesteld, ik eigenlijk niet. Niet omdat de opmerkingen onverstandig zijn, maar omdat het maar hele kleine stapjes zijn. Deze beroepsdenkers komen met hele kleine stapjes waarvan het een goede vraag is --en zeker gerechtvaardigd aan beroepsdenkers, zeker gerechtvaardigd aan academici en strategen in dit veld-- waarom we daar twintig jaar geleden ons niet druk over gemaakt hebben. Degenen in the know wisten al hoezeer we afhankelijk waren van al dat digitale moois, en dat dit in rap tempo alleen maar erger zou worden.

Met andere woorden, dit is veel te weinig, en de vooruitgang op dit gebied gaat veel te langzaam. Nu gaat het nog twintig jaar kosten voor de volgende paar stapjes, twintig jaar die we wellicht niet hebben. Ook deze bollebozen denken simpelweg niet groot genoeg en komen niet met practische zaken die voldoende ingrijpend zijn om serieus zoden aan de dijk te zetten, die dus niet voldoende grote scheppen zijn om deze hele grote berg ellende weg te scheppen.

Simpel vraagje: Waarom blijven we maar dezelfde rotte software gebruiken? Software die niet te onderhouden is en maar lekken blijft hebben. Software die niets anders kan want daar is de architectuur naar gemaakt en de fabrikanten zijn vaak expliciet onwillig om er echt iets aan te doen. Is er echt niets anders? Waarom wordt die vraag zelfs maar niet gesteld? Zien we dan niet dat de kraan open staat terwijl we naar nieuwe dweilen blijven zoeken?

En het is niet of de opmerking al niet eerder gemaakt is. Wijlen E.W. Dijkstra heeft zich er uitgebreid over verbaasd dat we zulke vreselijk rotte software maar gewoon accepteren. Vandaar dus mijn conclusie: Er wordt ook hier, ook weer, gewoon niet groot genoeg gedacht.
Als je software gedurende de hele levensduur van een apparaat moet onderhouden zijn er enkele leveranciers die al meteen afvallen, met op nummer een MS. Ziekenhuis apparatuur gaat soms wel 25 jaar mee, en daarna belandt het vaak bij de dierenarts (oude Rontgen appafatuur bijvoorbeeld). Hardware interfaces kunje vaak niet zomaar overzetten van de ene naar de andere windows versie, dus dan zou MS haar OSen minstens 30, 40 jaar moeten ondersteunen OF de nieuwe versie backwards compatible houden. Aangezien ze dat vertikken en iemand anders het ook niet kan wegens closed source is een MS OS dus onder deze eisen ongeschikt voor embedded apparatuur.
Het lijkt mij ook niet eerlijk om te eisen dat softwareleveranciers ondersteuning moeten bieden voor een x aantal jaar.

Wel lijkt het mij goed om te stellen dat niet ondersteunde software niet gebruikt mag worden. En dat geupdate moet worden volgens de regels van de software leverancier.

Dit legt de verantwoordelijkheid bij de bedrijven die gebruik blijven maken van niet ondersteunde software. Eventueel met boetes (een niet APK gekeurde auto mag ook de weg niet op)
Als de software door de leverancier ondersteund wordt en er wordt gepatched binnen de termijn die door de software leverancier stelt, dan ligt de verantwoordelijkheid bij de software leverancier. Anders mag je het niet gebruiken.

En als je als bedrijf niet de kosten kunt maken om genoeg resources in te zetten om je applicaties te testen en updaten na een patch, dan is de software niet voor jouw als bedrijf in te zetten.

Deze regels zullen er vast voor zorgen dat er veel efficienter en betere testtools en processen worden geimplementeerd.
Je maakt een paar goede punten, ik ben het er helemaal mee eens maar zie wel een paar fikse consequenties.

Ten eerste kan geen enkel bedrijf garanderen dat ze nog 35 jaar blijven bestaan, iedereen kan failliet gaan. In principe kan de support op ieder moment wegvallen. Als klant van zo'n bedrijf moet je daar dus rekening mee houden. Aangezien je praktisch gezien niet van de ene op de andere dag naar andere software kan overstappen is overstappen naar een andere leverancier geen optie.

Ik zie twee mogelijkheden. Ofwel voer je alles dubbel uit van twee volledig gescheiden leveranciers, zodat je een tijd hebt om over te stappen als een van de twee er mee stop,
Je zal op een of andere manier moeten zorgen dat je op een of andere manier toegang hebt tot de source, desnoods via een escrow service. Als het dan mis gaat kun je zelf een programmeer(bedrijf) inhuren om de software te onderhouden.

Met zo'n proces komt een hoop administratie en coordinatie kijken en dat kost veel geld. Dat lukt alleen als je het bijzonder goed van te voren plant. De gemiddelde zeemeeuwmanager krijgt dat nooit goed opgezet.
Een goede mogelijkheid is inderdaad dat als een bedrijf failliet gaat, dat het de sourcecode open source moet maken (en dan zijn de bedrijven die de software gebruiken er zelf verantwoordelijk voor) of ze verkopen de sourcecode aan een ander bedrijf (die er dan verantwoordelijk voor is).
Mooi in theorie, maar in de praktijk betekent dat dat nog goed werkende apparatuur na 10 jaar weggedaan wordt want de leverancier heeft er geen zin meer in, of doet dat alleen als er zo'n dure onderhoudscontracten afgesloten worden dat de klant het niet wil. Uiteindelijk is iedereen dan veel duurder uit, met als enig resultaat een (beetje?) extra veiligheid.

Dan komt uiteindelijk de vraag "is die extra veiligheid ons dat geld waard"? Grote kans dat het antwoord nee is.
Waarom? Andere OS'en zouden aan dezelfde eisen moeten voldoen.

Ik zie het eerder zo: Dit dwingt een MS (of wie dan ook) om robuuste software te ontwikkelen en beter een splitsing van mogelijkheden te creren.
Dus niet een kaalgestripte windows 'embedded' versie die de exact zelfde kernel gebruikt als het volwaardige OS op een pinautomaat van Q Park (om maar even een voorbeeld te noemen) maar een specifiek stukje software dat niet meer, niet minder, doet en kan wat nodig is.

Goedkoop is duurkoop. Als jij een 3e hands auto voor 500 piek koopt is dat leuk en aardig maar je moet toch wel elk jaar dokken om dat ding APK gekeurd en weg-legaal te houden.. waarom bestaat er geen 'APK' achtige keuring voor op het internet aangesloten software/apparaten?
We vinden het allemaal prima om 1000 piek neer te leggen bij die APK om onze 20 jaar oude auto te fixen maar software/hardware bedrijven dwingen om ook een 'APK' te nemen elk jaar dt willen we dan weer niet doen??? Slaat echt totaal nergens op.

[Reactie gewijzigd door Ayporos op 16 mei 2017 18:38]

Waarom? Andere OS'en zouden aan dezelfde eisen moeten voldoen.
Natuurlijk. Er staat ook niet van niet. Opmerken dat OS A niet aan de eisen voldoet die er eigenlijk aan gesteld zouden moeten worden maar dat gebeurt niet, impliceert niet dat deze eisen niet voor OS B gelden. Het zegt dat OS A onterecht in gebruik is en dat dit in de weg staat van een beter OS, ongeacht de fabrikant.
Ik zie het eerder zo: Dit dwingt een MS (of wie dan ook) om robuuste software te ontwikkelen en beter een splitsing van mogelijkheden te creren.
Dit is niet iets wat dat bedrijf kan. Heel raar, maar zo rollen ze gewoon niet.

Het is verder geen onredelijk idee en je zou het gewoon kunnen doen, maar degenen die zulke beslissingen nemen pakken toch iedere keer weer die desktop emulator. Waarom? Vraag het ze en vertel het ons.
Als je software gedurende de hele levensduur van een apparaat moet onderhouden zijn er enkele leveranciers die al meteen afvallen, met op nummer een MS.
Ik wilde het niet zeggen, maar inderdaad, compatabiliteit met wat- en wie-dan-ook is niet hun sterkste punt, inclusief zichzelf. En ze zijn zo groot dat iedereen daar last van heeft. Maar tegelijkertijd zijn ze zo dominant dat de meeste gebruikers niet snappen dat ze hier een loer wordt gedraaid. Ze hebben gewoon nooit iets anders ervaren.

Ook een effect van "monocultuur".
Hardware interfaces kunje vaak niet zomaar overzetten van de ene naar de andere windows versie,
Zolang de interface netjes gedocumenteerd is, kun je zelfs andere software (laten) maken. Open standaarden zijn wat mij betreft de eerste keuze, maar je zou ook kunnen zeggen, als institutionele koper, we kopen de hardware hier, en krijgen de documentatie erbij. De software laten we iemand anders maken aan de hand van de documentatie, weten we gelijk of de documentatie klopt. Dat we dus niet na zoveel jaar erachter komen dat de hardware onbestuurbaar is want de documentatie klopt niet.

Sla de handen ineen als groep afnemers en je kan ineens best veel.
dus dan zou MS haar OSen minstens 30, 40 jaar moeten ondersteunen OF de nieuwe versie backwards compatible houden. Aangezien ze dat vertikken en iemand anders het ook niet kan wegens closed source is een MS OS dus onder deze eisen ongeschikt voor embedded apparatuur.
Een vrij directe conclusie die desondanks niet getrokken wordt. Raar, niet?

Zeker als je bedenkt dat grotendeels dezelfde redenatie opgaat voor bijvoorbeeld iedereen die een kantoor draait met een archiefeis. Je digitale bestandjes na dertig jaar en tien nieuwe softwareversies nog openen? Zelfs als je aan nieuwe versies van hetzelfde pakket vasthoudt? Ik geef het je te doen.

Dit geldt des te harder hoe meer er "papierloos!" gepreveld wordt. Papier houdt zich makkelijk tweehonderd jaar goed, en tweeduizend lukt met een beetje goede wil ook nog wel. Probeer dat eens met... nouja, al het digitale, en niet alleen de opslag maar ook de lezers, want anders dan met papier kun je zonder specifieke leesapparatuur de datadragers niet lezen. Dus zorg om te beginnen maar dat je al je formaten gedocumenteerd hebt... op papier.
Een van de problemen hierbij zijn niet de producenten van software, maar de consumenten, die eigenlijk helemaal niet willen betalen voor die veiligheid.
Als je een levenslange garantie wilt geven op software, moet dat ook commercieel haalbaar zijn.
Het antwoord op de vraag waarom rotte software is: politiek en CV bouwen. Lees mijn voorbeeld eens door, het heeft mij ook even tijd gekost om de vinger er achter te krijgen, maar wat bleek.. zoals ik aangaf was er al meer dan een miljoen geinvesteerd wat een product opleverde wat nog geen 20k waard was. Zou men dat moeten toegeven, en het dan structureel goed opnieuw laten maken in de talen en databases die men wl wilde, voor 20k, dan zou het management een gigantische flater slaan (immers, dan doen ze nu ineens voor 20k waar ze in het verleden meer dan een miljoen aan uitgegeven hebben).

Dus.. om gezichtsverlies te voorkomen durft men niet de waarheid onder ogen te komen, en blijft men maar doormodderen. Toegeven dat je in het verleden iets fout gedaan hebt, is voor heel veel mensen heel erg moeilijk.

Ander punt is verantwoordelijkheid. Zolang je rotzooi hebt kun je de vertrokken mensen er de schuld van geven. Je kunt dan de rol van 'reddende oplosser' spelen. Als je een nieuw project start, ben je ineens zelf verantwoordelijk en aanspreekbaar.
Sorry hoor, maar je fakkelt nu de spreker af op n uit z'n verband gerukt zinnetje.
Voor iemand die "groot denken" adviseert, vind ik dat een beetje klein

De spreker heeft aangegeven dat het huidige beleid niet meer is dan symptoombestrijding en roept op tot uitbanning van onveilige software, vergelijkbaar met de Wereldgezondheidsorganisatie die halverwege de vorige eeuw opriep tot uitbanning van pokken.

Dat-ie daarbij geen concreet uitgewerkt plan presenteerde, kun je 'm niet kwalijk nemen. Zo'n plan moet door zoveel partijen worden geamendeerd, dat kun je niet in je eentje
Jij accepteert ook een droge boterham als er geen vers brood is.
Zelfs software in vliegtuigen is niet vrij van bugs. Recent zijn op korte tijd verschillende verhalen van piloten op Airbus toestellen opgedoken die hun toestel ooit een onverwachte duikvlucht heeft gemaakt. Enige manier om controle terug te krijgen was telkens de controle volledig afnemen van de computer.

Daarnaast is een vliegtuig weer net iets eenvoudiger om voor te programmeren omdat je een zeer beperkte hoeveelheid hardware hebt aan te sturen en een zeer beperkt aantal programmas hebt te draaien. Een general purpose OS zal altijd een heel stuk complexer zijn.

Nog niet zolang geleden (jaartje of 2-3?) passeerde hier een artikel over het eerste "bugvrije" OS. Functionaliteit zo goed als nul, een zeer beperkt aantal lijnen code (iets van een 100k?) maar wel heel wat jaren aan ontwikkeld om toch maar zeker te zijn dat de bugs eruit zijn.

Vele bedrijven geven ook voldoende ondersteuning (of gaan eraan failliet door te veel bugs), maar je rolt die veranderingen niet altijd zomaar uit in een productieomgeving. Dat is vaak een stuk complexer en ook weer niet goedkoop.

Als een batterij na 6 maanden begint te lekken heb je vaak trouwens geen garantie meer omdat een batterij nu net is uitgesloten van de wettelijke minimumtermijn in de EU van 2 jaar. Batterijen hebben vaak maar 6 maanden garantie. En wat ga je doen met een handelaar die na enkele jaren alsnog een restpartijtje verkoopt? Moet de fabrikant dan ondersteuning blijven bieden omdat een handelaar zo vriendelijk is geweest er enkele achter te houden?

Security is complex en duur en die kostprijs vormt de grootste hindernis en het is net een hindernis die je er nooit uit zult kunnen halen omdat een goede ITer nu eenmaal veel geld kost. Bedrijven verplichten dingen te doen drijft de kost op waarmee de consument niet gediend is, dus overheden zullen dat ook niet snel doen.
Een vliegtuig eenvoudiger om te programmeren? waar haal je die onzin vandaan? Het is juist behoorlijk lastiger en complexer. Want heel veel variabelen die er ook cht iets to doen, en realtime.

Zet dat idee maar snel uit je hoofd. Het is eenvoudiger een OS voor consumenten te maken, of een app voor zo'n OS, dan datgene wat in een vliegtuig zit.
En daar heb je een denktank voor nodig.
is t werkelijk zo slecht gesteld met t gemiddelde IQ?

Nee, een denktank is onafhankelijk.
Daar zit de kracht. Geen politiek maar feiten en efficiente oplossingen gent op die feiten.

Straks hebben we daar AI voor :)

Wacht...
Aankomende maanden/jaren zullen danktanks veel prominenter naar voor worden geschoven in media berichten. Uiteindelijk om de transitie naar de Ai denktank te versoepelen.

Aldus mijn denktank :)

[Reactie gewijzigd door biebelebons op 16 mei 2017 18:45]

@Reactie: Het zou wel fijn zijn om de naam van deze verstandige man 2x correct te spellen.
Michel van *Eeten*, heet hij.
Ik ken m toevallig.
http://www.tbm.tudelft.nl...fdr-mjg-michel-van-eeten/

[Reactie gewijzigd door Geekomatic op 16 mei 2017 21:04]

Deze man maakt deel uit van het probleem. Het allergrootste probleem in NL is de angstcultuur. Men durft gewoon niet. 99,9999 van de hacks en problemen zijn gewoon verwijtbaar, denk aan niet geinstalleerde updates (zie recente ransomware), niet updaten van systemen/drivers/talen/enzovoort.

Als voorbeeld kom ik nog dagelijks servers tegen die PHP 5.3 draaien. De ontwikkelaars wilden het wel veranderen, de beheerders wel, maar dan kwam men bij iemand die management gestudeerd had en de ballen verstand heeft van IT, die vraagt of er risico is, het antwoord daarop is ja, en dan is de keuze nee.

Zo simpel is het in de basis. Dit fenomeen zit verankert in heel de IT wereld in NL. Men kiest structureel voor wat ik de 'doodlopende weg' oplossing noemt. Bakken vol smoesjes en excuses. Ja maar dat <legacy device> of dat <legacy software> heeft die oude versie nodig. Dan had je dus al dat legacy device of die legacy software moeten vervangen.

Ik heb een ziekenhuis gezien waarbij 1 oud echoapparaat het hele ziekenhuis op een oude versie hield. Men kon niet upgraden, want dat apparaat zou het dan niet doen. Dit bleek nog knulliger te zijn dan het al klinkt, want er was voor dat apparaat gewoon een update. Maar was die er niet geweest, dan nog waren er betere oplossingen denkbaar geweest, door bv. dat apparaat in een eigen VLAN te zetten en de rest van het ziekenhuis wl te updaten.

Maar dat zijn risico's en, ook niet onbelangrijk, kosten waar men niet iets voor terugziet. Dus wil geen enkele manager er aan.

De hele IT industrie in NL is gewoon door-en-door kapotgemanaged en incompetent. Zeker de grote partijen zoals een Cap Gemini, Sogeti, Finalist, PWC, enz, enz, noem ze maar, er komt louter hele dure rommel uit. Zie ook overheids IT projecten. Niet n is er geslaagd of komt zelfs maar in de buurt. En dt zijn die grote partijen aan het werk.
Sorry, maar als de manager vraagt: is er een risico dan mag je niet zomaar met ja antwoorden. Dan moet je alle risicos oplijsten. Niet enkel die dat bij de upgrade horen, maar ook die dat bij het niet upgraden horen.

Waar het aan ontbreekt zijn mensen met de juiste visie en dat hoeven niet noodzakelijk managers te zijn. Een degelijke manager luisterd naar je argumenten en als jij die goed kan brengen zal die je mening overwegen en vaak ook volgen. Alleen zie ik zelf te vaak mensen die zeggen: dat beargumenteren das mijn job niet, das voor de manager die er geen verstand van heeft.
Gedeeltelijk ben ik het met je eens, al is mijn ervaring dat het probleem meestal bij het management zit. Men heeft in NL nu eenmaal het belachelijke idee dat je iemand kunt opleiden tot manager zonder vakinhoudelijke kennis. Een manager hoort imo te zijn die doorgroeit vanuit de uitvoerende takken, iemand die wl inhoudelijk kennis heeft. Tenminste, in de IT wel. Omdat er zoveel meningen zijn, vraag 10 developers iets, en je krijgt 10 verschillende meningen. Dan MOET een manager inhoudelijk beslagen zijn om het aan te kunnen.

Het verhaal is heel simpel, even een platgeslagen voorbeeld.

Nerd: Boas, we moeten upgraden. We draaien nu windows A.1 maar moeten naar B.2 toe.
Baas: Waaarom? Wat zijn de risico's?
Nerd: Voor A.1 komen geen updates meer uit en die kan kwetsbaar zijn voor hackers
Baas: ok, en het risico van upgraden naar B.2?
Nerd: Het kan zijn dat er dingen kapot gaan, dat persoon X z'n werk even niet zal kunnen doen, of dat we ook andere zaken moeten upgraden.

10 op de 10 managers zullen er in dat voorbeeld voor kiezen niet te upgraden.
Ik ben het met Blokker eens. Een manager hoeft niet technisch onderlegd te zijn om te kunnen managen. Een manager moet ervoor zorgen dat hij mensen in dienst neemt die technisch genoeg onderlegd zijn om te kunnen runnen wat er gerund moet worden.

Als je als IT'er dus niet voldoende de risico's van het wel of niet updaten met elkaar kunt afwegen en deze kunt communiceren dan moet je ook niet raar staan te kijken als management zegt: Nee.

Nu zijn er natuurlijk flut managers die met leuk praten manager zijn geworden (is ook een kunst natuurlijk) maar als je een goede manager hebt zal deze prima kunnen achterhalen van ITers wat de voor en nadelen zijn. Ook als hij/zij niet technisch onderlegd is.

[Reactie gewijzigd door michaelboon82 op 16 mei 2017 20:25]

"Ik ben het met Blokker eens. Een manager hoeft niet technisch onderlegd te zijn om te kunnen managen."

Ja, dat moet hij dus wel. Dat toont de praktijk al jarenlang glashard aan. Nu moet je wel onderscheid maken, dat ben ik met jullie eens. Een lijnmanager die gaat over people management, hoe laat je op je werk bent, functioneringsgesprekken, enzovoort, die hoeft geen technische onderbouwing te hebben.

Echter een manager die gaat over technische keuzes, MOET technisch onderbouwt zijn. Dat is gewoon glashard nodig om te kunnen begrijpen wat de mensen onder je van je verlangen.

Juist dat volstrekt debiele idee dat zo'n manager niet technisch onderbouwt hoeft te zijn, maar de informatie van ondergeschikten moet krijgen, is n van de hoofdredenen waarom IT in NL zo gigantisch hard faalt.

Je moet namelijk soms ook onpopulaire beslissingen nemen. Nu noem ik weer het voorbeeld PHP vs Java. Als jij een PHP devver in dienst hebt maar een project waar Java eigenlijk veel geschikter voor is, zal jouw PHP devver je dat niet gaan vertellen, immers dat kost hem z'n baan. Daarom MOET een manager ook weten waar het technisch inhoudelijk over gaat.
Het allergrootste probleem in NL is de angstcultuur. 99,9999 van de hacks en problemen zijn gewoon verwijtbaar, denk aan niet geinstalleerde updates (zie recente ransomware), niet updaten van systemen/drivers/talen/enzovoort.
Deels ook angstcultuur doordat men heeft ervaren dat updates voor het ene probleem nieuwe problemen schept.

Regel dan ook de claimcultuur, zodat men verhaal kan halen na riante downtime van een bedrijf.
Als je na een update problemen krijgt, bedenk je je wel drie keer.
Ik wel.
Stresstak: en precies DIE kortzichtigheid nekt de industrie.

Nieuwe problemen maken is beter dan oude problemen behouden. Dat is wat men consequent over het hoofd ziet. Ja maar als we iets nieuws maken, risico. Ja, dat is waar. Maar als je het oude behoudt, veel groter risico. En vroeger of later zul je toch echt wel MOETEN.

Juist vanwege dit soort redenaties, moet de overheid in al haar incompetentie nog contracten afsluiten om anno 2017 godbetert nog windows XP te ondersteunen. Terwijl ze die ondersteuning niet eens gebruiken, ook nog.
Dat - en er is ook nog echt een angstcultuur rond het melden van een eigen misstap. Als je per ongeluk een bijlage opent, van een mailtje dat achteraf gezien toch niet zo legitiem kan zijn, meld het direct! En managers, IT'ers, probeer die meldingen te belonen, al is het maar een simpele 'dankjewel voor het melden' - zelfs bij de tiende false positive op een ochtend.
"Na een paar weken is het weer business as usual". Dt is de kern van een hle hoop van de ellende. Zolang de Capgemini's van deze wereld aan kunnen blijven rommelen en een puinzooi van alles kunnen maken (waarbij de schuld echt niet alln bij de ontwikkelaars ligt maar ook zker bij onkunde vanuit de overheden, met alle managementlagen, budgetten en tussentijds wijzigingsverzoeken) en we vast blijven houden aan vriendjespolitiek (want Pietje kent Jantje goed, 'dus' Jantje mag het klusje opknappen) komt het simpelweg niet goed. Punt.
Dat komt door de overheid zelf die absurde eisen stelt voor omzet om een project bij diezelfde overheid te mogen doen. Dan komen altijd weer de 'usual suspects' in aanmerking. En het zijn nog eens buitenlandse bedrijven ook. Die vragen hier veel te veel en sluizen de woekerwinsten naar Frankrijk zodat ze daar met 62 met pensioen kunnen. Hier laten ze verschroeide aarde achter.

En de overheid wil altijd enorme Big-Bang projecten doen in plaats van kleinere deelprojecten die ook door NL'se bedrijven uitgevoerd kunnen worden.

De schuld ligt feitelijk bij de NL'se overheid en de Tweede Kamer. Die kunnen er wat aan doen, maar verzuimen.

[Reactie gewijzigd door ArtGod op 16 mei 2017 17:33]

Tja. Maar die kiezen vervolgens niet voor 'de India-route' zoals de CapGemini's en een dozijn anderen dat doen. Zonder dat controle mogelijk is en dergelijke.

Beiden hebben schuld..
Mja... moet je beginnen bij de bron denk ik.....
Helaas is de bron te ver terug waar geen verandering in te maken is. Waar is de tijd dat een reclamebanner een simpel plaatje of een animated gif was? Nu moet het allemaal in Flash oid met allemaal runbare scripts op de achtergrond. Waar is de tijd van simpel text in de mail? Door het accepteren van oa. VBS scripts was outlook op zich een bron van ellende. En al een tijd kunnen zelfs runbare scripts in films en plaatjes weggewerkt worden. Allemaal mooie technieken om de boel op te leuken en vooral reclame in weg te proppen maar helaas ook zaken om kwaadaardig gebruik van te maken. Als men een viewer echt alleen een viewer heeft gelaten zou het niet mogelijk zijn geweest.

En dan, je koopt als leek een nieuwe PC en er zit al een virusscanner bij, heel leuk maar soms zijn het van die 30 dagen trial versies waar mensen soms geen weet van hebben die dus na 30 dagen geen updates meer binnen haalt. Natuurlijk de opmerking van dat merk je toch? Ik denk dat er genoeg mensen wel die ervaring hebben bij kennisen en familie dat eventuele meldingen worden genegeerd. En dan maar te zwijgen hoe moeilijk het soms is om dergelijk troep weg te krijgen voor de installatie van een fatsoenlijk pakket.

En zo kunnen we wel door gaan met het gemakkelijk installeren van je eigen WiFi router maar niet weten hoe die dicht te gooien.

Het is een combinatie van te moeilijke materie waar te makkelijk mee om wordt gegaan, kun je dat de mensen kwalijk nemen? Misschien moet digitale beveiliging en oplettendheid een verplichte schoolvak worden.
Hoe kan je "gaten" dichten waar je het bestaan niet vanaf weet als eindgebruiker?
De overheid speurt naar deze "gaten" en gebruikt deze voor "(inter)nationale veiligheid", zij willen dat deze "gaten" openblijven met als reden (inter)nationale veiligheid en delen deze informatie niet.
De ontwikkelaar wil deze "gaten" graag gemeld/gedicht krijgen, vanaf welke partij deze informatie de ontwikkelaar toekomt interesseert hen in de 1e instantie niet..
De "hacker" weet van het bestaan van deze "gaten" door (doet er niet toe) en misbruikt dezelfde "gaten" die door de overheid gebruikt worden voor "(inter)nationale veiligheid".

Windows updates, applicatie updates, AV updates, allerlei andere crappy updates, hoeveel zero days komen er wel niet binnen met al deze updates die er eigenlijk voor horen te zorgen dat het oude "gat" gedicht werd... iets met water naar zee dragen? Ik ben 1 en al voor security en het verkleinen van risico's op voorhand, het totaal wegnemen van risico's zie ik niet gebeuren...
Je had dit kunnen voorspellen natuurlijk: dat allerlei 'experts' ons nu gaan vertellen hoe we het probleem moeten oplossen om het einde van de wereld te vermijden. Dat zag je bij de kredietcrisis ook.

Ik heb al eerder opgemerkt dat de problemen grotendeels komen door de C programmeertaal. Oplossing is of de C taal aanpassen of overschakelen naar 'veilige' talen zoals C++, C#, Java, Rust, Go etc. etc.

Verder voorzie ik dat het internet gaat fragmenteren, in netwerken die wel met internet protocollen werken, maar niet vanaf het internet benaderbaar zijn. Een voorbeeld is het LORA netwerk van KPN voor IoT apparaten. Er zullen aparte netwerken ontstaan voor IoT, ziekenhuizen, huisartsen, accountants, overheidsinstellingen en meer.

[Reactie gewijzigd door ArtGod op 16 mei 2017 17:07]

de problemen grotendeels komen door de C programmeertaal
Onzin, imho. Neem de SMB bug die door wannaCry wordt gebruikt. Dat is geen programmeerfout maar een design-error in het protocol. De programmeurs hebben dat keurig volgens de specs geprogrammeerd, maar als de specs fout zijn, is je software dat ook
Nope, het is een C buffer overflow.
Waarom zouden de problemen grotendeels komen door de C programmeertaal?
Het ligt niet perse aan de taal denk ik, maar aan onkunde van de programmeur en omslachtigheid van programmeertalen om iets veilig te krijgen; noem het gemak van het genereren van bufferoverflows en een geheugenlekje etc... Maar ook wanneer een high-level taal als PHP niet goed wordt gebruikt door bijvoorbeeld inputs niet te sanitizen, dan is er netto ook nog niets opgelost.

De waarschijnlijkheid op fouten ligt wel anders tussen verschillende talen/frameworks. Ik heb geen rijtje paraat, maar ik denk dat we ons er allemaal wel wat bij voor kunnen stellen.
Bij PHP kan je over het algemeen geen code injection doen. En zowel dan komt dit weer doordat de PHP interpreter zelf in C is geschreven.

Bij niet sanitizen van inputs krijg je meestal dat men willekeurige commando's kan uitvoeren omdat men de input rechtstreeks naar een SQL database of command shell stuurt.
Omdat de C programmeertaal geen bounds-checking heeft waardoor je willekeurig geheugen kan overschrijven en zo code injection kan toepassen. Met de meeste andere computer talen kan dat niet.

Het scheelt een beetje performance, maar de impact op computerbeveiliging is enorm. Onze hele maatschappij wordt er door ontwricht.

Het is technisch nog ingewikkelder want de C taal en het Unix besturingssysteem zijn onlosmakelijk met elkaar verbonden. Bijvoorbeeld de C 'malloc' aanroep is eigenlijk een Unix API call. En dit is weer heel erg gerelateerd aan use-after-free programmeerfouten.

[Reactie gewijzigd door ArtGod op 16 mei 2017 17:06]

Taal is compleet irrelevant. Je ziet bijvoorbeeld ook stapels exploits in het in PHP geschreven WordPress. Hele botnets van spammailers onstaan daardoor. Hetzelfde geldt voor Java, Python, Ruby en C#.

C is krachtig en je moet er verstandig mee omgaan. Het heeft ook een relatief steile leercurve waardoor veel onervaren programmeurs het links laten liggen, met een taal als PHP of Python kan je veel makkelijker onveilige code produceren die ook nog werkt (maar dus niet alleen zoals de programmeur bedoeld had).

Slechte code in C of welke programmeertaal is, net als de meeste beveiligingsproblemen een probleem tussen stoel en toetsenbord, niet inherent aan de gebruikte middelen.
Taal is NIET compleet irrelevant, dat is alle subtiliteit uit de discussie slaan.

Natuurlijk is het zo dat exploits in alle talen mogelijk zijn, maar de verschillen daarin doen er toe. De aard van een taal als C staan bufferoverflows toe, iets wat in hogere talen technisch gezien simpelweg onmogelijk is.

Een hogere taal is ongevoelig of minder gevoelig voor dat type exploit, maar heeft wellicht weer andere lekken. Over het algemeen geldt, hoe hoger de taal, hoe kleiner de kans op menselijke fouten omdat de abstractielaag meer afhandeld.

Helaas is het zo dat het niet echt opschiet met de abstractie van programmeren.
Daar heb je tegenwoordig codecheckers voor. Dat webontwikkelaars te dom zijn om in C en C++ te programmeren is niet de schuld van de mensen die dat wel kunnen.
Daarom zou het op beveiligingsgebied meer de kant van productaansprakelijkheid op moeten gaan. Hetzelfde geldt voor tussenpersonen, bijvoorbeeld voor isp’s die botnets tegengaan. Zij hebben het probleem niet gecreerd, maar inmiddels accepteert iedereen dat zij in een positie zijn om er iets aan te doen en daarom ook een zorgplicht hebben, aldus de onderzoeker. Dit is bijvoorbeeld ook van toepassing op de beveiliging van internet-of-things-apparaten.
Ik denk dat dit een heel gezonde uitgangspositie is in een wereld die steeds verder digitaliseerd. Nu zie je dat fabrikanten van allerlei producten die aan het internet verbonden zijn de verantwoordelijkheid vaak naast zich neerleggen.

Het eisen dat een fabrikant zorg moet dragen voor een digitaal veilig product, kan ook een boost geven voor consumentenproduct. Een fabrikant die stage-fright-exploits ruim baan geeft door oudere telefoons niet up te daten moet dan effectief kiezen. Wel een goed updatebeleid, of het risico lopen op grote claims (of vervangingskosten) van bedrijven en consumenten als de hardware slachtoffer wordt van hacks als Stagefright.
[...]


Ik denk dat dit een heel gezonde uitgangspositie is in een wereld die steeds verder digitaliseerd. Nu zie je dat fabrikanten van allerlei producten die aan het internet verbonden zijn de verantwoordelijkheid vaak naast zich neerleggen.

Het eisen dat een fabrikant zorg moet dragen voor een digitaal veilig product, kan ook een boost geven voor consumentenproduct. Een fabrikant die stage-fright-exploits ruim baan geeft door oudere telefoons niet up te daten moet dan effectief kiezen. Wel een goed updatebeleid, of het risico lopen op grote claims (of vervangingskosten) van bedrijven en consumenten als de hardware slachtoffer wordt van hacks als Stagefright.
Maar als mensen een update naar de nieuwste Windows versie krijgen gaan ze allemaal lopen piepen en blijven ze op een verouderde versie zitten, zelfs als hier geen support meer voor is. Wie is er dan verantwoordelijk?
Een (Europese) wetgever kan prima termijnen opstellen voor hoe lang een fabrikant een product zou moeten blijven ondersteunen. Net als ze dat eerder hebben gedaan voor de wettelijke garantietermijnen op andere defecten.

Als een gebruiker kiest zijn software niet te onderhouden, lijkt dat zijn eigen keuze en dus eigen verantwoordelijkheid. Een beetje hetzelfde als dat de garantie van een auto ook vaak vervalt als je geen onderhoud pleegt volgens de onderhoudstermijnen.

Een ander probleem zit denk ik ook in dat het gemeengoed is geworden voor zoveel mogelijk partijen om gebruikersinformatie, en persoonlijke gegevens te verzamelen. Je hebt als simpele internetter tientallen partijen die allemaal een verdienmodel hebben waarbij ze permanent informatie proberen te verzamelen, en die opslaan. Bij belaste, of duurdere informatieverzameling zorg je er in ieder geval voor dat minder partijen persoonlijke informatie hebben en dat die informatie meer waard is, dus verklein je risico's.
Dat lost het probleem dus niet op. Gebruikers moeten in dit geval dus duidelijk tegen zichzelf beschermd worden. Het is toch idioot dat iemand kan kiezen om een compleet digitaal systeem zwak te houden om dat wat nieuws leren te veel gevraagd is. Stel dat je auto niet door de APK komt, dan mag je gewoon niet meer rijden, punt. Misschien dat software die niet door de APK komt dan ook maar gewoon niet meer genetwerkt mag worden.

Stel dat je zo'n APK opstelt, dan kan je iets als metasploit, openvas en nessus inzetten om te kijken of een systeem voor bekende kwetsbaarheden vatbaar is.

[Reactie gewijzigd door johnkeates op 16 mei 2017 17:09]

Maar dat is omdat je met je auto op de openbare weg zit en dan anderen schade kan toebrengen. Als jij niet je software bijwerkt waardoor je vatbaar bent voor bijvoorbeeld ransomware, dan is dat je eigen probleem. Zolang anderen hun software wel op orde hebben vormt jouw besmetting geen bedreiging. Net zoals je met die afgekeurde auto wel nog op je eigen terrein mag rijden en evt jezelf in gevaar mag brengen.
Nee, dan is dat dus niet 'je eigen probleem', dat is een probleem van iedereen. Je stelt software nu gelijk aan mensen met een immuun-systeem en vaccinaties, maar dat is het dus niet.

Als jouw computer misbruikt wordt en je bijvoorbeeld documenten hebt die iets over andere mensen zeggen, of een adresboek hebt, of op een netwerk zit waar andere systemen op aangesloten zijn, dan is jouw computer per direct een probleem voor heel veel andere mensen. Het netwerk of het internet kan je in dit geval dan wel weer als 'de openbare weg' beschouwen.

Als je apparaat (zij het een computer, telefoon, slimme frituurpan of WC-met-WiFi) misbruikt kan worden is het eigenlijk te vergelijken met een vliegtuig kaping. Stellen dat het daarmee alleen een probleem is voor de eigenaar van het vliegtuig gaat dan niet op. De inzittenden zullen er niet heel gelukkig mee zijn, en stel dat het vliegtuig een gebouw in gevlogen wordt heb je je probleem meteen vrij stevig opgeschaald.
niet helemaal waar, je bent connected. Als jouw pc infected is, heeft 'de herd' daar net zo goed last van (bv. jouw systeem wordt een zombie in een ddos-netwerk).

De pc die je hebt bevind zich dan wel in je woonkamer/huis/whatever, maar wat je ermee kunt doen is basically wereldwijd :)

(je redenering is trouwens gelijk aan hoe vacinatie werkt: er zijn wat mensen die niet gevaccineerd kunnen worden, maar die worden grotendeels beschermd doordat het merendeel om hun heen gevaccineerd is. Nu kun je dus zeggen 'goh dan hoef ik ook niet gevaccineerd te worden', maar je verzwakt dan de bescherming. Bij 1 persoon heeft dat natuurlijk niet zoeen impact, maar heel veel kleine beetjes maken de impact stiekem opeens groot. Het is geen garantie dat je er geen last van krijgt met bv exploits, maar hoe obscuurder de exploit toepasbaar is, hoe kleiner de kans omdat simpelweg minder mensen er interesse in hebben om het toe te passen).
Het is wel mijn probleem als jouw beveiliging niet op orde is, denk is aan bijvoorbeeld botnetwerken die Ddos aanvallen uitvoeren.
Zoals hieronder al aangegeven, vrijwel alle bot netwerken bestaan juist uit de zwakke broeders. Je bent letterlijk een gevaar voor anderen met je XP bak.
Het probleem met de APK vergelijking.. als je nu zo'n APK zou invoeren, zou de overheid zelf het zwaarst getroffen worden. En de banken. Je wil niet weten hoeveel oude rotzooi er nog bij de overheid en banken draait. Fortran en Cobol zijn daar nog hippe talen.
Ik weet dat het vol met rotzooi zit, dat is juist de reden dat het wel een goed idee zou zijn. Cobol en Fortran systemen zullen trouwens de APK beter doorstaan dan Windows, maar da's een andere zaak.
Je mist het punt een beetje. Diegenen die het hardst getroffen zouden worden door dit soort regels, zijn de mensen die die regels maken. Die zullen die regels dus nooit maken.
We zijn hier niet in Amerika he. De overheid werkt hier voor ons.
En sinterklaas bestaat!
[...]
Maar als mensen een update naar de nieuwste Windows versie krijgen gaan ze allemaal lopen piepen en blijven ze op een verouderde versie zitten, zelfs als hier geen support meer voor is. Wie is er dan verantwoordelijk?
Dat is omdat MS geen onderscheid (meer) maakt tussen (ongewenste) features en bugfixes. Alles moet tegenwoordig via big fat rollups gaan waardoor workflows van mensen breken :r

Dus ja, MS heeft het deels ook aan zichzelf te danken dat mensen niet de nieuwste Windows willen hebben.

[Reactie gewijzigd door RoestVrijStaal op 16 mei 2017 18:13]

Dat is omdat MS geen onderscheid (meer) maakt tussen (ongewenste) features en bugfixes. Alles moet tegenwoordig via big fat rollups gaan waardoor workflows van mensen breken
Dat doet Microsoft nog niet zo lang, en ook voor die tijd waren veel mensen al laks met updaten. Blijkbaar is dit dus niet de (hoofd) reden.
Met dat is het personaliseren naar eigen gebruik van het OS in mijn ogen ook als een vermoeiende strijd met een gezwel die resistent wordt tegen de remedies in de vorm van .reg en .bat files, waarvan de werking na een grote update steeds in twijfel moet worden gebracht.

Ik zit er bedrijfsmatig aan vast maar ik ben dat w10 OS zo ontiegelijk zat aan het worden...
Hoe veilige software je ook ontwikkelt, de zwakste schakel is de mens. Effectief is daar geen kruid tegen gewassen.

Voorbeeld: je software gaat je top-safe maken, gaat door allerlei procedures heen, externe audits, logos, certificatie, noem maar op (kost bij elkaar een vermogen). Biedt dat veiligheid? Mwa... niemand kan 100% betrouwbaarheid aantonen in 10-tallen miljoenen regels code.

Maar goed, veronderstel dat dit huzarenstukje tot een goed einde komt. Alle ontwikkelaars hebben handboeien om gekregen, zodat ze geen fouten meer kunnen maken. Software de deur uit. Genstalleerd op een PC om de hoek. Gevraagd: wachwoord instellen, minimaal 128 karakters lang waarvan 10 vreemde karakters + een 2e device voor 2-factor authentication. Arg, dat is last. Wachtwoord wordt maar in readme.wachtwoorden.txt op het bureaublad gezet. Geen CVE, en dag beveiliging.

Begrijp me goed: software fabrikanten moeten hun uiterste best doen. Maar meer testen, meer valideren, andere ontwikkelmethoden. Het zal allemaal helpen, maar uiteindelijk zitten er mensen achter (ook achter codegeneratoren) en die maken nu eenmaal fouten. Dat deel van het verhaal wordt nooit waterdicht, ook niet als er juridisch kaders komen.

Zolang veiligheid en gebruiksgemak tegengestelde belangen zijn, dan is er altijd een soort status quo. En zolang een nieuwe versie van de software getest moet worden (omdat de software door iedere klant op zijn/haar 'unieke' manier gebruikt wordt), gaat er tijd overheen voordat patches uitgerold kunnen worden. En alleen maar lastiger als bedrijven 24h/7d/wereldrond werken. Dus naast gebruiksgemak speelt ook geld een belangrijke rol.

Het hele artikel gaat er net iets te gemakkelijk van uit dat geld en tijd geen rol spelen. Wel is het triest dat een 'amateur hour' zo veel schade aan kan richten. Maar goed, ook die op afstand met een joystick bestuurde bommen-werpende drone zal bij die persoon weinig/geen gevoel opleveren als er doden vallen. Net zoals bij een hacker waar in een ziekenhuis doden vallen als de systemen uitvallen. Compassie/empathie daalt met de afstand. Helaas. Techniek is dus niet neutraal.
Voorbeeld: je software gaat je top-safe maken, gaat door allerlei procedures heen, externe audits, logos, certificatie, noem maar op (kost bij elkaar een vermogen). Biedt dat veiligheid? Mwa... niemand kan 100% betrouwbaarheid aantonen in 10-tallen miljoenen regels code.

Maar goed, veronderstel dat dit huzarenstukje tot een goed einde komt. Alle ontwikkelaars hebben handboeien om gekregen, zodat ze geen fouten meer kunnen maken. Software de deur uit. Genstalleerd op een PC om de hoek. Gevraagd: wachwoord instellen, minimaal 128 karakters lang waarvan 10 vreemde karakters + een 2e device voor 2-factor authentication. Arg, dat is last. Wachtwoord wordt maar in readme.wachtwoorden.txt op het bureaublad gezet. Geen CVE, en dag beveiliging.
Je voorbeeld geeft alleen maar aan dat IT'ers een handje er van hebben om verkeerde ontwerpkeuzes af te schuiven op de gebruikers. Als je vooraf al weet dat de gebruiker het wachtwoord gaat opslaan in plain text waarom implementeer je dan oplossing waar een wachtwoord vereist is? Waarom bedenk je dan niet een oplossing waarbij de gebruiker helemaal geen wachtwoord hoeft in te typen?
Nee. Ik gaf aan dat beide partijen hierin verantwoordelijkheid hebben. Bij de software maker zullen de kosten stijgen als er (veel) meer gedaan moet worden aan veiligheid. Verder zal daardoor de gebruiksvriendelijkheid op punten afnemen. En tevens - voor zover dat speelt - compatibiliteit afnemen (extra veiligheid kan zorgen voor een compatibiliteitsbreuk).

Van de kant van de gebruiker is zorgvuldigheid nodig. Die is er vaak niet, maar pleit hem of haar niet direct vrij van verantwoordelijkheid. Sterker nog, in de hele keten is vaak de gebruiker de zwakste schakel.

Er zijn inderdaad andere mogelijkheden voor authenticatie, maar om die in te bouwen heb je een hoop geld/tijd nodig c.q. voor het uitrollen ervan (door de IT-beheer afdeling). Als de consument daarvoor niet wil betalen (of niet wil gebruiken, of management de kosten voor uitrol te hoog vindt) dat gaat dit allemaal niet door. Dus ja: er zijn mogelijkheden, maar ook met een prijskaartje.

En praktisch: veiligheid is sterk gekoppeld aan voortschrijdend inzicht. 10 jaar geleden waren er hele andere authenticatiemethoden dan nu. Het is wel erg kort door de bocht om dat 'verkeerde ontwerpkeuze' te noemen. Dat klinkt heel erg als de beste stuurlui staan aan wal :-).
Security als probleem is in zijn geheel inderdaad nooit op te lossen. Het is geen binair probleem. Het is nooit helemaal opgelost en het is nooit helemaal klaar.

Daarom moeten we pragmatisch zijn. Je kunt niet van een consument of iemand in het MKB verwachten dat ze zich tot de tanden wapenen en het kat- en muisspel met de beste hackers ter wereld gaan winnen, dat gaat gewoon niet gebeuren. Daar is de competentie er gewoon niet voor, en al helemaal niet het geld.

Daarom moeten we ons richten op de grote risico gebieden. Windows is een goede, maar ook het Android probleem.
Je kunt niet van een consument of iemand in het MKB verwachten dat ze zich tot de tanden wapenen en het kat- en muisspel met de beste hackers ter wereld gaan winnen, dat gaat gewoon niet gebeuren.
Uiteraard niet. Maar het is wat anders dan te verwachten dat fabrikanten de volledige verantwoordelijkheid op zich nemen, of helemaal schuldig zijn als er iets misgaat. Van consumenten mag je ook wel een kritische houding verwachten, tot een bepaald niveau. Als voorbeeld een NAS, die maar al te vaak wordt verkocht als een datakluis. Als je daar al je data naar toe backupt, mag er best van je verwacht worden dat je vraagt hoe het nu eigenlijk met de beveiliging daarvan zit.

Dat gebeurd nu niet, maar is mijn inziens ook weer niet de schuld van de consument, door gebrekkige educatie/voorlichting.

De oplossing voor een deel van het probleem is multi-disciplinair. In een ideale situatie wordt er meer aandacht besteed aan het security aspect:
  • De overheid licht consumenten voor: "waarop dien je te letten als je een NAS/IoT device koopt en waarom zou je daarop letten"? Voorlichting zonder de angst factor te fuelen.
  • Providers leveren CPE met een veilige standaard config. UPnP standaard uit. Actie ondernemen als er een responsible disclosure binnenkomt.
Dit zijn maar enkele voorbeelden. Daarbij wil ik wel vermelden dat bovenstaand een deel is van een ideale situatie, maar dat ik mij afvraag hoe reel het is. Het vergt een behoorlijke verandering van attitude, gedrag, etcetera. Niet iets wat binnen afzienbare tijd te doen is, in ieder geval.
"Van consumenten mag je ook wel een kritische houding verwachten, tot een bepaald niveau"

Dat zou je denken, en je zou het willen. Maar nee, ook dat gaat niet werken. Het internet en zijn vele vertakkingen worden door vrijwel iedereen gebruikt, inclusief miljoenen mensen die zelfs met goede wil zichzelf niet kunnen beveiligen.

Als voorbeeld mijn moeder. Het is haar niet aan het verstand te brengen hoe de boel te updaten. Of om duidelijk te maken dat die "vriendelijke" tip op die webpagina om haar virusscanner te updaten eigenlijk juist malware is. Ze is te naief, heeft moeite met abstracte concepten, en kan dit niet aan.

Oftewel, alles moet dummy proof zijn, en automatisch. Het is de enige oplossing...voor een significant aantal gebruikers.
Ik denk dat dit onvermijdelijk is, maar dan moet er wel een uitzondering gemaakt worden voor open-source software. Zo moet alleen de eindfabrikant verantwoordelijk worden gehouden.

Ik zie dat ze nu steeds als voorbeeld Microsoft en Google noemen, maar waarom hoor ik steeds niets over het aanpakken van de Chinese fabrikanten die absolute troepzooi op de markt gooien? Ik denk dat we moeten uitkijken dat we geen handelsoorlog hiermee beginnen, want de Amerikanen gaan dit niet pikken denk ik. Ik zie uit Europese hoek toch meer animo om de Amerikaanse bedrijven aan te pakken omdat men hier jaloers is op de enorme winsten die deze bedrijven binnenhalen en vanwege de frustratie dat er geen Europese tegenhangers zijn.

De Chinese fabrikanten prutsen gewoon letterlijk wat in elkaar en bekommeren zich totaal niet over de beveiliging van hun product. Laat ze die maar eerst eens aanpakken. Als ik bijvoorbeeld lees dat van een Chinese IP camera fabrikant maar liefst 1250 (!) modellen totaal onveilig zijn dan houd ik mijn hart vast. Dit soort dingen zouden echt verboden moeten worden en liefst zo snel mogelijk.
Ik denk dat dit een heel gezonde uitgangspositie is in een wereld die steeds verder digitaliseerd.
Voer het te ver door en het zal een ongezonde werking hebben op innovatie... wie durft er nog iets nieuws uit te brengen als fouten hard gestraft worden?
'Problemen rond migratie zijn op te lossen, we doen het alleen niet'
'Problemen rond het klimaat zijn op te lossen, we doen het alleen niet'
'Problemen rond losliggende tegels zijn op te lossen, we doen het alleen niet'

Kwestie van vraag/aanbod.
De enige limitatie van de mensheid? De mensheid. Niemand houdt ons tegen.
'Problemen rond migratie zijn op te lossen, we doen het alleen niet'
'Problemen rond het klimaat zijn op te lossen, we doen het alleen niet'
'Problemen rond losliggende tegels zijn op te lossen, we doen het alleen niet'

Kwestie van vraag/aanbod.
De enige limitatie van de mensheid? De mensheid. Niemand houdt ons tegen.
Het grote verschil is dat niemand een echt goed plan heeft om problemen rond migratie of het klimaat fundamenteel aan te pakken. Er zijn wel extreme plannen (bv alle migratie verbieden, of alle CO2 uitstoot verbieden) maar die zijn niet realistisch.

Daarmee vergeleken is het veiliger maken van software kinderspel. Vrijwel iedereen in de industrie weet wel zo'n beetje wat er moet gebeuren en dat het een fundamenteel goed idee is, maar we doen het niet omdat het op korte termijn te duur is en niemand op lange termijn in IT wil investeren.
Daarmee kom je op het terrein van de overheid. Net zoals de overheid betaalt voor fundamenteel onderzoek en infrastructuur, omdat de industrie niet kan betalen voor projecten met een terugverdientijd van 100 jaar.
't Punt is dat die overheid waar jij het over hebt, er niet is. Er is geen wereldwijd gezagsorgaan dat zoiets kan afkondigen.

Je denkt toch niet dat Mark Rutte naar Redmond kan bellen met de mededeling "jongens, vanaf nu mogen er geen bugs meer zitten in de software die jullie hier verkopen"
Natuurlijk niet, nergens werkt het zo. Hoe het wel werkt is dat de overheid zegt "Vanaf nu valt software onder garantie. Je hebt twee jaar lang recht op patches voor alle securitybugs (binnen 48 uur) en anders krijg je geld terug."
Vervolgens gaat de rechter er dan voor zorgen (met boetes) dat de leveranciers hun gedrag aanpassen.

Of de overheid zet haar leveringsvoorwaarden in, dat doen ze ook op andere gebieden. De overheid stelt gewoon voorwaarden op en eist dat alle leveranciers daar aan voldoen, geen uitzonderingen. In die voorwaarden zou je een vergoeding kunnen eisen voor bugs.

Misschien dat er dan niemand meer software wil verkopen tegen de oude prijzen maar dat alle prijzen 10 keer omhoog gaan. Als dat nodig is dan moet het maar, iemand moet voor de veiliigheid en kwaliteit zorgen. Als dat niet in de aanschafprijs zit dan komen die kosten achteraf bij de klant, die daar waarschijnlijk helemaal geen rekening mee heeft gehouden.
Inderdaad;
Als al het geld dat is verdampt door oeverloos vergaderen en commissies in het leven roepen die alleen maar plannen produceren waar niemand iets mee doet, nu eens nuttiger werd besteed waren een aantal van allerlei problemen al een eind op weg naar een oplossing.....
Ik lees hier goede dingen en een juiste houding.
Ga zo door NCSC.
(oh ja, en jaag die fossielen de deur uit met hun absurde data verzamel gedrag, focus op beveiligen van burgers en plaats van extra risico creren)
Er zijn gelukkig ook goede initiatieven: check out Storro, zelfs van Nederlandse bodem. Deze slaat je bestanden op, verdeeld over meerdere devices. Je cloud-in-eigen-beheer zeg maar. Maar Storro doet meer, en slaat bestanden op in een private blockchain. Hierdoor is het mogelijk om terug te gaan naar lke voorgaande versie van een bestand. Dus ook naar een niet-gegijzelde versie.

Zelfs in het geval dat crypto ransomware niet bestanden zelf gijzelt, maar de Storro database of een compleet besturingssysteem, dan blijven gedeelde documenten op de machines van contacten (de andere devices in je private cloud) onaangetast, en die data dus beschikbaar. Hierdoor is de impact van cryptoransomware op informatie in Storro beperkt.

Op dit item kan niet meer gereageerd worden.


Nintendo Switch Google Pixel XL 2 LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*