Moet exploit code gepubliceerd worden?
Security professionals kwamen afgelopen zaterdag op de Stanford University Law School bijeen om te discussieren over het publiceren van code die gebruikt kan worden om lekken te demonstreren. Bijna alle aanwezigen waren het erover eens dat ontwikkelaars eerst over een lek moeten worden ingelicht en de tijd moeten krijgen om een patch te ontwikkelen, voordat het lek aan het publiek wordt bekend gemaakt. Men was het echter oneens of onderzoekers proof-of-concept code moeten publiceren om een lek aan te tonen. Als het aan Microsoft ligt wordt er helemaal geen code gepubliceerd, maar de gigant uit Redmond vraagt eerder om medewerking dan dat ze iets probeert op te leggen. In dit artikel komen verschillende security onderzoekers aan hun woord die hun visie op het publiceren van exploit code geven.
eerst b.v. 1 maand de tijd moet krijgen om deze issue op te lossen.
Trage bedrijven zullen qua productsecurity dan binnen de korste keren
aangemerkt worden als security onveilige bedrijven.
Gevolg hiervan is dus dat bedrijven minder snel de software van deze
leverancier zullen aanschaffen, maar eerder geneigd zijn een oplossing van
een concurrent aan te schaffen welke wel veilig is.
belang is om zo weinig mogelijk mensen te laten weten dat er
een exploit gevonden is. Anderzijds, zo lang het geen common
knowledge is ben je dus zonder het te weten vulnerable, en
kun je dus ook geen preventieve maatregelen nemen (services
(tijdelijk) uitschakelen, firewall rulesets aanpassen, IDS
signatures schrijven en dergelijke).
Ik ben er persoonlijk van overtuigd dat de "bad guys" net zo
snel weten dat er een exploit bestaat als de "good guys" en
misschien nog wel sneller.
onmiddellijk te worden gepubliceerd om partijen geen voordeel van
die mogelijke kennis te geven.
Wat denken jullie ervan om "het algemeen belang" zelfde
wetgeving (& toezicht houder) in te voeren voor
beveiligingsinformatie? (Kan evt. met een korte vertraging, bijv. 2
weken).
Dan verplicht de wetgever alle partijen de informatie publiek te
maken ipv dat er discussie gevoerd wordt over hoeveel vertraging
(& onveiligheid in al onze systemen) we dienen te accepteren.
waarde. je zorgt enkel voor een boel problemen.
mijn mening een naief beeld dat alleen maar leid tot een ilusie van veiligheid.
Als iemand met goede bedoelingen lek A kan vinden, dan kan iemand zonder
goede bedoelingen dat ook.
Natuurlijk is het netjes om eerst de leverancier van de software op de hoogte
te stellen, en dit moet ook altijd gedaan worden. Als deze echter niet reageert
(of niet snel genoeg) heeft het publiek het recht om te weten wat er mis is met
software. Het is immers beter om te weten dat je niet veilig bent, dan om te
denken dat je wel veilig bent!
Deze posting is gelocked. Reageren is niet meer mogelijk.
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
No more ransomware!
De nieuwe Ransomware Awareness Experience training biedt een realistische maar vooral leuke introductie in de wereld van ransomware. De deelnemers ervaren hoe eenvoudig een organisatie het slachtoffer kan worden van ransomware en leren meteen hoe een besmetting kan worden voorkomen!