Hiervoor gaat ook op: Alles kan gesloopt worden, zo ook vaak de code. Er is maar één methode, en dit is waar het begint; nog beter testen en secure development methodes gebruiken. De kleine foutjes die met diepere en uitgebreidere tests naar voren komen.

Niet alles is lek, dat is een grove overdrijving. Als je in de informatiebeveiliging werkt weet je dat er zoiets bestaat als een 'risk appetite' (risicoprofiel). Als de data voldoende goed beschermd is om te allen tijde aan dat profiel te voldoen is er geen sprake van een lek, zelfs niet als een systeem "gekraakt" wordt. Veel data hoeft ook helemaal niet zo extreem goed beschermd te worden, maar is publiek en nie van groot belang. De meeste systemen voldoen uitstekend en aantoonbaar binnen het risico-profiel van de organisatie waar die data voor is.

En toch zijn ook daar gradaties in. Een bankje in het park kapotmaken kost meer werk dan de bank thuis.

Uh, nee. Het begint veel eerder, met begrijpen wat je aan het doen bent, de materie snappen, op een solide basis bouwen, en zo verder. Er is net zo goed niet maar één methode om veilig gebouwen te bouwen, ook al bestaan er ondertussen grote stapels bouwvoorschriften die vaak (maar niet altijd) geleerde lessen uit het verleden belichamen. Die zijn best nuttig, maar ook die zijn vaak arbitrair. Als bouwkundige ben je er ook nog lang niet als je alle geldende bouwvoorschriften kunt opdreunen, je hebt echt meer nodig dan dat. Van bouwkundigen verwachten we dat ze weten hoe gebouwen te ontwerpen die tegen een stootje kunnen. Van (zekere grote) softwarebouwers verwachten we eigenlijk dat hun software spontaan inelkaar zakt en dan mag je er vaak ook nog eens niets van zeggen. Dan krijg je "jamaar alles kan stuk" terug. Ja, en toch zitten daar gradaties in.

Er is inderdaad te veel laaghangend fruit en daar wordt automatisch voortdurend op het gehele net naar afgestruind.
Veiligheid is nog te vaak sluitpost op de begroting, maar de "eindafrekening zit dan altijd onder in de zak".

Er is inderdaad verschil tussen een A+ graad website, een website in de F-graad klasse en een T-graads webstek.
De laatstgenoemde moet zich klaar maken voor een plaatsje in de hall of shame.
Nog te weinig bevinden zich binnen de rijen van de hall of fame.

Nog te veel outdated en non-upgraded, te veel met verkeerde instellingen, ontbrekende veilgheidsheaders etc.
Te veel met af te voeren of zelfs voorgoed verlaten code.

Maar ook veel stiekem gedoogde onveiligheid ook via obfuscatie, dus security through obscurity.
Waarom? Omdat het zo lekker geld in het laatje laat vloeien bij de grote stakeholders.

Ik probeer steeds ervoor te zorgen, dat mensen er hun oogjes langzaam voor open gaan doen
en dat is een langdurig en vaak ontmoedigend gevecht in de hoop dat het eens beter gaat worden.

luntrus

Het maakt niet uit wat je gebruikt want alles is lek. Behalve de corona App van minister de Jonge want die man heeft een visie en inzicht in de materie. De Jonge heeft zoveel vertrouwen in de App dat er zelfs een aparte wet voor komt. Een land als de onze met zulke leiders is werkelijk gezegend. Samen zijn we sterk tegen corona.

Nou nou nou, niet zo negatief over onze toekomstige minister president.

Moge god ons hopelijk hiervoor behoeden..

Gekozen voor ja: merendeel zal lek zijn.

Alles? Ik zit hier droog binnen, en buiten regent het. Dak is niet lek! Stelling debunked.

cve-2020-1350: Alles is lek.

Wacht nog 30 jaar: het is lek.

Alles is lek en tegelijkertijd niet lek. Pas als het onderzocht wordt krijg je duidelijkheid. #Schrödinger

Eind vorige eeuw werkte ik bij het project millennium overheid. Daarvoor nam ik o.a. in Londen deel aan een driedaagse workshop over de milleniumbug. Één van de specialisten, ik meen van systeme evolutif, overtuigde ons met vele voorbeelden ervan dat softwareontwikkelaars meestal wel testen of de software doet wat ‘ie moet doen, maar zelden of die dingen doet die juist nièt mogen. Dat kost tijd en geld. Kennelijk is er nog maar weinig vooruitgang geboekt.

Dit, hier, dit is nog steeds een van de hele grote heikele punten en reden waarom "security consultants" nog jaaaaaaren werk zullen hebben. Veelal met eindeloos broodkruim zoeken in de vorm van "exploits" zonder ooit werkelijk grote verbeteringen aan te (kunnen) wijzen, zodat er altijd wel een volgend kruimpje te vinden zal zijn.

En toch hoeft het niet zo moeilijk te zijn. Stel invarianten vast, bijvoorbeeld "de invoer voldoet aan deze eisen" en hou die religieus vast. Zolang je dat doet kun je veilig die invariant als aanname gebruiken. Zolang je 'm niet vastgepind hebt, kun je dat niet.

Dus iedere keer dat je een aanname doet (en dat gebeurt vaak binnen programmacode) moet je die articuleren en dan nakijken of je dat wel mag gezien je vastgestelde invarianten, of je moet een nieuwe invariant vaststellen. Heel simpel, wel net even formeel, en het gebeurt bijna nooit. Maar je zou dus in feite voor elk stukje code moeten kunnen vertellen welke invarianten er op dat moment gelden.

Kun je dat, dan kun je niet alleen vertellen wat er wel mag, maar ook wat er niet mag, en dan is daarop testen lang zoveel extra moeite niet meer. Kun je dat niet, dan blijft het gissen en moet je maar hopen dat er niet ergens iemand op een verkeerd knopje drukt, de telefoon verkeerd vasthoudt, of iets in die trant.

Helaas is alles lek, wat voor uitleg er ook maar is. Offline of online, je bent te hacken. Helaas. Hoezo Offline?!? Denk aan verborgen camera's.

@ anoniem van 18:38 gister,

Fijne bespiegelingen en dit zet ook aan tot verder (over)denken.

We zouden al kunnen praten over het langer dan te verwachten aflopen van scripts,
dat kan duiden op potentieel oveilig zijn. Het voldoet dan niet aan de te verwachten normering in ieder geval.

Dit gegeven zou dus ook zo'n soort van gepredefineerde vastgestelde invariant kunnen zijn.
Voorbeeldje - serverless AWS Lambda invoke:

Het moet dus zo zijn, dat code niet kan doen wat het niet zou moeten kunnen doen.

Nu is het vaak zo dat men dat niet van de 'code sec' vraagt in normale omstandigheden, onder tijddruk etc.,
maar door een aantal opgebouwde protocollagen tracht te bereiken in de vorm van verdere veiligheidslagen.
(onder meer server client monitoren, header security, enz.; veelal toch vaak security through obscurity).

Deze nieuwe directe code-achtig preventieve afbakening is moeilijk, omdat er nooit zo mee omgegaan is,
zeker niet door "knippers en plakkers" en hun decision-makers.

Maar voortgezet misbruik dwingt ons wel die kant op. Het kost gewoon te veel om het anders te willen doen.

Kijk in een omgeving waar je er van uit kan gaan, dat niemand de voorgestelde code echt misbruikt,
zoals bij de universiteiten in den beginne van voor het Internet het geval, is een veiligheidsgarantie gemakkelijker.

In alle andere gevallen is het vaak een ondoenlijke zaak of verloopt via een glijdende schaal.
Er is nu eenmaal niet altijd een compleet betrouwbare gebruikerspool om het zo uit te drukken.
Het vraagt dus om een compleet andere benadering dan we tot nu toe gewend zijn.

J.O.

Mijn afwasteil is niet lek, maar daar zit ook geen software in.

Als lucht ontsnapt uit een opgepompte, niet echt lekke fietsband,
moet hij toch op een bepaalde manier een beetje lek zijn.
Hij lekt blijkbaar via niet direct zo in het oog springende kanalen. ("poreus")

Daarom moet je ook stikstof (N2) gebruiken. Rubber is voor poreus voor lucht, maar gesloten voor N2.

"Lucht" voor autobanden is dan ook N2, vandaar het groene dopje op het ventiel.

Als mijn ondergoed nat is, wat lekt er dan?

Heb ik ook altijd als mijn data weer eens is gelekt.

Aangezien lucht voor 78% bestaat uit N2, en aangenomen de tweede bewering, is de eerste bewering maar voor maximaal 22% waar. Dat zou dus een maximum op het kunnen leeglopen van een opgepompte band laten zien, d.w.z. een goed opgepompte band loopt voor maximaal eenvijfde leeg en blijft viervijfde opgepompt.

Ik denk dat het probleem veeleer is dat ouder rubber poreuzer is dan nieuwer rubber. Vandaar dat je een oude band (veel) vaker moet oppompen, en dat is een teken dat'ie aan vervanging toe is.

Welk groene dopje?

Volgens mij wordt de bandenoppompinstallatie bij de benzinepomp gewoon gevoed door een compressor, geen grote N2-tank.