Microsoft-topman Brad Smith erkent gemaakte fouten rondom beveiliging

Brad Smith, de president van Microsoft, heeft toegegeven dat Microsoft fouten heeft gemaakt rondom de beveiliging van zijn producten. Dat zei hij tijdens een hoorzitting van de Amerikaanse Commissie Binnenlandse Veiligheid.

Brad Smith is door de Commissie op het matje geroepen vanwege een cyberaanval in 2023, schrijft IT Daily. Chinese hackers wisten vorig jaar via Microsoft Exchange Online in te breken op e-mailaccounts van verschillende bedrijven, West-Europese overheden en de Amerikaanse overheid. In april stelde de VS in een rapport dat Microsoft die aanval had kunnen voorkomen. Smith moet zich hier namens Microsoft nu over komen verantwoorden.

In een schriftelijke getuigenis voorafgaand aan de hoorzitting liet Smith al weten dat Microsoft de verantwoordelijkheid voor de door de VS benoemde problemen 'zonder enige twijfel of aarzeling' aanvaardt. Ook schrijft hij dat Microsoft bezig is om alle aanbevelingen uit het rapport over te nemen en aan nog eens achttien andere beveiligingsdoelstellingen te werken. Tijdens de hoorzitting erkende Smith nogmaals dat het bedrijf bij dit incident tekort is geschoten.

Kritiek over SolarWinds-aanval

Eerder deze week verscheen meer kritiek op het handelen van Microsoft op het gebied van security. ProPublica publiceerde donderdag een getuigenis van voormalig Microsoft-werknemer Andrew Harris, die tot 2020 in het beveiligingsteam van het bedrijf werkte. Harris stelt dat Microsoft een bedenkelijke rol speelde bij de SolarWinds-aanval in 2020.

De voormalige werknemer ontdekte naar eigen zeggen in 2016 een potentieel ernstige kwetsbaarheid in Azure AD FS, waarmee ingelogd kan worden in de Azure cloud. Volgens Harris konden aanvallers de kwetsbaarheid misbruiken om via een on-premises server in te breken in de cloudomgeving van klanten. Microsoft was destijds echter bang dat het erkennen van die kwetsbaarheid de reputatie van de destijds vrij nieuwe cloudafdeling zou schaden, waarop het in de doofpot werd gestopt, zegt Harris. Jarenlang probeerde de voormalige werknemer Microsoft zo ver te krijgen om de fout op te lossen, maar daar werd niets mee gedaan.

In augustus 2020 stapte Harris over naar CrowdStrike, slechts enkele maanden voordat de SolarWinds-aanval plaatsvond. Bij die aanval werd de fout die Harris in 2016 al had gevonden misbruikt, aldus ProPublica. Smith moest zich in 2021 al verantwoorden voor de SolarWinds-aanval, maar hij zei toen dat er geen kwetsbaarheid in Microsoft-producten of -diensten misbruikt was voor die aanval.

Reacties (66)

[Arckedo]

Letterlijk gisteren nog zei diezelfde Brad Smith nog tegen het US House dat Recall een goed voorbeeld van "secure by design" was. Lekker bezig, Brad!

[Reactie gewijzigd door Arckedo op 23 juli 2024 02:07]

[Bor]

Het een sluit het ander niet uit. Recall kan best volgens secure by design principes zijn ontwikkeld ondanks dat men elders duidelijk steken heeft laten vallen.

[Arckedo]

Dat is zo, maar in dit geval gaat dat simpelweg niet op.

De hele security industrie stond al weken te schreeuwen; Recall is niet secure by design: Het slaat letterlijk JPEG screenshots op in een user-accessible directory, en dat terwijl de feature nog niet eens officieel echt uigerold is. Je hoeft als gebruiker niet eens net zoals met sommige applicaties "Ja" te klikken op een admin-toegangsvenster of iets.

- https://www.wired.com/story/total-recall-windows-recall-ai/
- https://github.com/xaitax/TotalRecall

Windows Recall stores everything locally in an unencrypted SQLite database, and the screenshots are simply saved in a folder on your PC. Here’s where you can find them:

C:\Users\$USER\AppData\Local\CoreAIPlatform.00\UKP\{GUID}

The images are all stored in the following subfolder:

.\ImageStore\

Dat is naar mijn mening niet ergens een steekje laten vallen. Dit is een trui die uit elkaar is gevallen, in twee hoopjes verspreid over de tafel ligt, en doen alsof alles prima is omdat je nog een deeltje mouw over hebt.

Zelfs een beginnend ontwikkelaar zou bij het ontwikkelen van zoiets vragen krijgen mbt. of dit wel oke is zo, laat staan de team leads, seniors en managers die zo'n project goedkeuren en shippen.

[Reactie gewijzigd door Arckedo op 23 juli 2024 02:07]

[Loller1]

Het slaat letterlijk JPEG screenshots op in een user-accessible directory, en dat terwijl de feature nog niet eens officieel echt uigerold is.

En daar stopt je argument dus eigenlijk. Recall was onveilig... op basis van een onvolledige versie die notabene door enkele Windows Insiders bij elkaar is gehacked. We weten ondertussen dat dat niet is hoe Recall daadwerkelijk gaat werken...

[jmignolet]

Heb je een bron? Gewoon curieus.

[Blokker_1999]

Er is geen bron buiten de verklaringen van Microsoft, maar waarom zou je wel enkele mensen geloven die de functionaliteit bij elkaar hebben lopen te hacken, functionaliteit die officieel nog niet is uitgebracht en waarvan niemand dus weet hoe deze in een productieversie zal werken.

[SunnieNL]

Secure by design… en…
Unencrypted database
Wachtwoorden die tijdelijk plaintext zichtbaar zijn voor verwerking

Die dingen gaan niet samen. Ook niet als wat mensen de functionaliteit bij elkaar schrapen.
Secure by design houdt in dat je vanaf het allereerste begin, nog voor er een lijn aan code staat al zorgt dat je beveiliging meeneemt in het proces. In de allereerste prototypes is dan alles al secure en gebruik je geen plaintext databases om die data in op te slaan en zouden paswoorden niet zomaar in de log mogen komen.

[Aaargh!]

op basis van een onvolledige versie die notabene door enkele Windows Insiders bij elkaar is gehacked.

Security is niet iets wat je achteraf er bovenop plakt. Dat is iets dat je vanaf dag 1 meeneemt in je design. CoPilot+ komt op 18 Juni uit, je denkt dat de feature die in een preview build zat nog compleet opnieuw ontworpen zou worden in de paar weken tot de release?

We weten ondertussen dat dat niet is hoe Recall daadwerkelijk gaat werken...

Dit is pas aangepast nadat er externe kritiek kwam, waardoor MS genoodzaakt was de feature uit te stellen en terug te gaan naar de tekentafel. Ze waren 100% van plan de feature in z'n huidige vorm te releasen.

Of anders gezegd: als het altijd al het plan was Recall in een veel veiligere vorm te releasen, waarom is dan uitstel nodig? In dat geval had MS gewoon kunnen zeggen dat de versie die op 18 Juni gereleased zou worden compleet anders werkt en wel veilig is om het vervolgens gewoon volgens plan te releasen.

[Alex3]

Zo'n ontwikkelingsmethode zou ik niet by design durven te noemen.

[latka]

Het kan ook gewoon insecure zijn by design maar het management roept iets anders. Dat doen ze vaker.

[Nozmordre]

Uit het artikel: "Waarop het in de doofpot werd gestoken. Jarenlang probeerde de voormalige werknemer Microsoft zo ver te krijgen om de fout op te lossen, maar daar werd niets mee gedaan."
Dat is geen fout, dat is een zeer bewuste keuze om je product en klanten kwetsbaar te houden.

[Triblade_8472]

Iets andere bewoording: "dat is een zeer bewuste keuze waardoor je producten en klanten kwetsbaar blijven"

Woorden doen er toe.

[kimborntobewild]

Woorden doen er zeker toe. Maar ik zie geen verschil in betekenis.

[Triblade_8472]

"Een bewuste keuze om je klanten kwetsbaar te houden" toont een actie gericht bewust tegen die klanten.
"Een bewuste keuze waardoor je klanten" toont een keuze gericht op iets anders met als gevolg dat die klanten ...

Een beetje hetzelfde als doodslag en dood door schuld.

[Nozmordre]

Als Microsoft hier voor nu eens een boete krijgt van 20% hun wereldwijde jaaromzet dan zouden bedrijven het misschien eens serieus nemen....

[cariolive23]

Welke wetten hebben ze dan overtreden?

[Nozmordre]

Je klanten, waaronder overheid, laten hacken door een kwetsbaarheid waar je al jaren vanaf weet maar weigert te fixen. Dat valt vast onder een of andere wet.

[cariolive23]

Het maken van fouten is nog geen overtreding, dat doen jij en ik dagelijks. Ik ga er dan even van uit dat jij een menselijke vorm hebt

Software zit vaak zo barstens vol fouten, dat het bijna een wonder is dat het überhaupt werkt. Daarnaast "laat" Microsoft hun klanten niet hacken, hun klanten wórden gehackt. Dat is in eerste, tweede en derde instantie toch echt de verantwoordelijkheid van de dader.

[Nozmordre]

Uit het artikel: "Waarop het in de doofpot werd gestoken. Jarenlang probeerde de voormalige werknemer Microsoft zo ver te krijgen om de fout op te lossen, maar daar werd niets mee gedaan."
Dat is geen fout, dat is een zeer bewuste keuze om je product en klanten kwetsbaar te houden.

[cariolive23]

Dat heb ik gelezen, maar welke wet overtreed je daarmee? Ik durf wel te wedden dat er duizenden bedrijven zijn die dit doen. Zo niet honderdduizenden of miljoenen...

Mensen stellen nu eenmaal prioriteiten en zolang ze daarmee geen wetten overtreden, is dat niet strafbaar. En daarom mag je niet lukraak een boete gaan uitdelen. Geen overtreding = geen boete.

Lees de licentie ook maar eens door, staat keurig in dat er geen enkele garantie wordt gegeven en dat je nergens recht op hebt. (beetje kort door de bocht, maar is een aardige samenvatting van een willekeurige software licentie)

[klakkie.57th]

Er zijn toch bedrijven die boetes opgelegd krijgen wanneer data gelekt wordt , dit is op zijn minst hetzelfde en hier kan mijn dan nog eens aantonen dat het bedrijf op de hoogte was

Vb in de US:

https://www.ftc.gov/enfor...ax-data-breach-settlement

[Reactie gewijzigd door klakkie.57th op 23 juli 2024 02:07]

[cariolive23]

Klopt, dat is wettelijk vastgelegd. Dat is met bugs en veiligheidslekken bij mijn weten (nog) niet het geval.

Je wilt niet weten hoeveel software er anno nu wordt geschreven waar "gewoon" SQL injection mogelijk is. De desbetreffende "software ontwikkelaars" zouden imho op 'n minst een beroepsverbod moeten krijgen voor de rest van hun leven. Wanneer je na een 25 jaar hier nog niet van hebt gehoord, dan is er weinig hoop dat je de komende 25 jaar nog iets zult (bij-) leren. En SQL Injection is maar één voorbeeld van bekende foute structuren in software.

[SunnieNL]

Er zit natuurlijk wel een verschil in een bug in de code en het jaren niet oplossen ervan als je er op gewezen bent.
Met de nieuwe EU wetgeving komt daar overigens wel verandering in (cra) en zou Microsoft echt wel een probleem krijgen als ze nogmaals een beveiligingsproblemen waar ze van af weten en misbruikt kan worden, jaren niet oplossen.

[Bor]

Het maken van fouten is menselijk maar zodra je er vanaf weet behoor je er ook iets aan te doen (en dan doel ik niet op het in de doofpot stoppen). Door de slechte omgang met beveiliging hebben meerdere klanten risico gelopen en zijn een aantal slachtoffer geworden van misbruik.

[Blokker_1999]

En zij hebben het recht om Microsoft hiervoor aan te klagen en hun schade te verhalen. Maar dat betekend nog niet dat Microsoft strafrechterlijk iets misdaan heeft. Alleen dat het vertrouwen in dat bedrijf bij vele mensen weer een deuk krijgt.

[rneeft]

Niet alleen zit software vol fouten. Er kunnen ook onderliggende fouten zijn. Ik kan perfect sofware maken maar als er een fout in .Net zit ga ik alsnog nat.

[fruitbakje]

Het maken van fouten is nog geen overtreding

Als het grove nalatigheid is, dan wel. Daar lijkt (met de zeer beperkte info die we natuurlijk hebben als amateurs ) wel een argument voor te maken in dit geval.

[Powermage]

Wanneer je van een kritiek lek op de hoogte bent gebracht, maar die uit commerciele overwegingen niet oplost dan ben je gewoon zeer kwalijk bezig hoor, dat is niet "een foutje"

[Houtenklaas]

Dat is nogal een boude stelling. Bij een niet bekende zero-day kan ik daarin meegaan. Maar een fout die al jaren bekend is, kom op zeg. Alsof je autofabrikant weet dat 1 op de 1000 keer je remmen weigeren, maar bang is voor reputatieschade en daarom maar geen terugroepactie doet. Dit zou in mijn optiek onder grove nalatigheid vallen en een enorme boete tegenover mogen staan.

[kimborntobewild]

Het maken van fouten is nog geen overtreding, dat doen jij en ik dagelijks.

Veiligheidsgaten bewust laten zit, is wel degelijk een overtreding. Sterker nog, daarmee overtreed je wetten.

[cariolive23]

Klinklare onzin en dat weet je zelf ook wel. Toon mij maar eens een wet die jou verplicht om fouten in software te repareren en dan ook nog eens binnen een bepaalde tijd.

Geen enkel softwarebedrijf zou dat overleven, zouden allemaal kapot gaan aan de boetes. Het is ook maar de vraag of opensource dat zou overleven, want voor wie is dan de boete?

[Pietervs]

Bewust fouten negeren is wel degelijk strafbaar.
Zou wat zijn als autobouwers weten dat de remmen niet goed werken op een model maar het negeren “want het is toch niet strafbaar”

Iets concreter: waarom denk je dat er boetes opgelegd worden als er data gelekt wordt? Juist: om af te dwingen dat data beveiligd wordt. En als dat betekent dat je je software moet herschrijven, is dat toch echt een gevolg van een software fout.

[cariolive23]

Verkeerd voorbeeld want auto’s zijn juist wél gereguleerd. Je mag helemaal niet zomaar een auto maken en mee op de openbare weg gaan rijden. Met software mag dat wel. Ik kan vanochtend nog een stuk software schrijven en vanmiddag zonder enige vorm van testen op de markt brengen. Daarmee overtreed ik geen enkele wet

[Pietervs]

Wie heeft het over nieuwe auto’s? Ook op bestaande auto’s kunnen fouten gemaakt zijn waardoor remmen na x kilometer niet goed meer zouden kunnen functioneren…

Maar hoe kijk je tegen het concretere voorbeeld aan dat ik erbij heb gezet?

[cariolive23]

Voor auto's is wetgeving van toepassing wanneer ze wel of niet de weg op mogen. Een kapotte lamp is al voldoende om de wet te overtreden, kun je een boete voor krijgen. Of die auto nou nieuw is, 10 jaar oud of zelfs 100 jaar oud, zonder de juiste goedkeuring (of uitzondering!) mag die niet op de openbare weg rijden.

Het lekken van data is wetgeving over, maar dat heeft op zich niets met fouten in software te maken. Of je nu data lekt doordat je processen niet op orde zijn of dat de beveiliging niet op orde is, dat doet niet ter zake. Laptops met grote data verzamelingen, exports van databases via Excel en email versturen, met een verkeerde adreslijst, iets in "aan" zetten ipv "bcc", allemaal beruchte voorbeelden die niets met bugs in software te maken hebben.

En ik geloof er helemaal niets van dat het bewust negeren van fouten in software, strafbaar is. Je gaat dan ook een discussie krijgen over hoe bewust "bewust" nou daadwerkelijk is. Software bevat (vrijwel) altijd bugs en vele van deze bugs zijn bekend en staan in een bugtracker. Worden ze volgende week allemaal opgelost? Denk het niet. Ze krijgen verschillende prioriteiten en op basis daarvan wordt besloten wanneer iets wordt opgelost. Maar krijgt het dan de juiste prioriteit? Geen idee. En één melding van een bug, is vaak een melding van een symptoom met onderliggend vele bugs. In daarin kan een bug zitten die een veel groter gevaar is dan dat ene symptoom waar je een melding van hebt. Zo kan ik mij genoeg voorbeelden herinneren met javascript waarvan data uit een database kwam, wat niet goed ging. Gedoe met quotes bij het aanmaken van de SQL statements. En na 5 minuten doorgraven in de code blijkt dan dat er sprake is van SQL injectie. Daar ging de bug alleen niet over. Dit komen we 1 a 2 keer per jaar bij nieuwe klanten tegen, wat slechts een fractie is van het totaal aantal organisaties in deze wereld. En dat een 25 jaar na de "ontdekking" van SQL injection.

Persoonlijk denk ik dat 9 van de 10 programmeurs zich helemaal niet bezig houden met beveiliging. En managers die zelf geen IT opleiding hebben, nog minder. Het lezen van requirements vindt men al moeilijk.

[Pietervs]

Dat programmeurs beveiliging maar lastig vinden, is bekend. Dat is ook niet hun primaire doel: ze moeten een product opleveren. Zelfde geldt voor applicatiebeheerders. Begrijpelijk, maar wel jammer natuurlijk.

Maar of je wel of niet gelooft dat bewust fouten negeren strafbaar kan zijn doet er niet toe: als er data lekt kun je een boete krijgen, en naarmate de fouten groter zijn (lees: weten dat er een lek is en daar niks aan doen) zal de boete hoger uitvallen.
Overigens mogen daar wat mij betreft wel vaker boetes voor gegeven worden, want het idee “het is software dus we moeten maar aanvaarden dat het kan lekken” vind ik te gemakkelijk.

[cariolive23]

Overigens mogen daar wat mij betreft wel vaker boetes voor gegeven worden, want het idee “het is software dus we moeten maar aanvaarden dat het kan lekken” vind ik te gemakkelijk.

Je kunt pas straffen wanneer een wet wordt overtreden. Het zal per land en per lek verschillen of daar sprake van zou kunnen zijn. Er is in vele landen wetgeving rondom het lekken van data, maar hoe die data wordt gelekt, is irrelevant. Of er nou een bug in de code zit van de software die je hebt aangeschaft of dat iemand een database backup op GitHub heeft gepubliceerd, de boete is hetzelfde. En dan ook echt hetzelfde, want de boete is voor de eigenaar van de data. Niet voor de leverancier van de software.

En dat laatste is jammer, want daar ontstaat (te) vaak het probleem. Dat programmeurs beveiliging maar lastig vinden, is wat mij betreft volkomen irrelevant. Dat is het hetzelfde als een chirurg die hygiene maar lastig vindt. Zo iemand is ongeschikt voor het werk en gaat maar een andere baan zoeken.

Boetes voor de leverancier lijkt een goed plan, maar heeft mogelijk ook wel wat haken en ogen. Want aan wie ga je die boete geven? De werkmaatschappij waar de klant zaken mee doet? De holding in een ander land waar de klant géén zaken mee doet? De IP houder in weer een ander land waar de klant evenmin zaken mee doet? Of moeten we er een (extra) verzekering voor afsluiten? En hoe zit het met het gebruik van libraries? Denk aan Log4j, wat open source is, maar met een gapend gat in vele vele applicaties verborgen zat. Wie is er dan juridisch verantwoordelijk?

Zelf leveren wij ook software aan onze klanten, maar dat is niet onze primaire business. Veiligheid is echter wel een primaire eis aan onze software. En dus een keiharde eis aan de medewerkers. Wanneer ik een sollicitatiegesprek heb met een potentiële programmeur en deze brengt ervaring mee, zal hij/zij moeten uitleggen wat hij/zij doet om de veiligheid te garanderen. Wanneer je dan niet met een goed verhaal komt, ben je óf junior of je ligt er uit. toch verwacht ik niet dat wij zo'n fout zoals in Log4j gaan vinden.

[Pietervs]

Verantwoordelijkheid is meestal wel te herleiden.

Stel je laat een huis bouwen. Dan neem je een architect in de arm, die weer een aannemer inschakelt, die een electricien, stenen legger, badkamerspecialist en loodgieter inhuurt.
Nu maakt 1 van die ZZP-ers een fout waardoor het huis instort. Jij als opdrachtgever hebt maar met 1 persoon te maken: de architect. Die stel je aansprakelijk. Of die op zijn beurt de aannemer aansprakelijk stelt, die weer de loodgieter aanspreekt, is voor jou niet interessant.

Zelfde geldt voor software. Als bedrijf laat je een app bouwen. Die blijkt lek te zijn. Bedrijf krijgt een boete van de AP, en stelt vervolgens het bedrijf in gebreke die de app gebouwd heeft. Heeft dat bedrijf een executable of DLL gebruikt die lek blijkt te zijn, is dat natuurlijk knap l*lig voor dat bedrijf. Maar zolang er geen overkoepelende, wereldwijde rechtspraak is om dit soort dingen aan te kunnen pakken, zal dat toch echt op die manier moeten gebeuren.
Overigens verwacht ik wel dat (zeker in Nederland) de rechters/AP er rekening mee zullen houden: redelijkheid en billijkheid zijn een groot onderdeel van de rechtspraak hier.

Maar ik vrees dat het doorschuiven van de aansprakelijkheid in Nederland te weinig gebeurt. Mensen aanvaarden dat software soms lek kan zijn, zien de boete als iets wat erbij hoort en gaan over tot de orde van de dag.
Volgens toenmalig staatssecretaris Dijkhoff is de “softwareproducent” in ieder geval aansprakelijk. Maar ik heb niet het idee dat er hier echt bedrijven voor de rechter gedaagd worden omdat ze lekke software geleverd hebben.

[cariolive23]

Verantwoordelijkheid is meestal wel te herleiden.

Maar volkomen irrelevant: Klant doet zaken met de werkmaatschappij, laat ik de werkmaatschappij toch ploffen? Dat is precies de reden dat zo'n structuur bestaat!

Komt nog bij dat de werkmaatschappij helemaal geen software produceert en geen eigenaar is van de software. De werkmaatschappij koopt software licenties in, en verkoopt deze weer door met een marge. Krijgt de werkmaatschappij een grote claim en blijkt de werkmaatschappij hiervoor verantwoordelijk te zijn, dan gaat deze failliet. 5 minuten later is er echter een nieuwe werkmaatschappij die verder gaat daar waar de oude was gebleven.

Zelfs de handelsnaam die de werkmaatschappij gebruikt, is bij ons niet in handen van de werkmaatschappij.

Bij maatwerk heb je nog een ander probleem, de opdrachtgever... Die vraagt vandaag om A, morgen om B, overmorgen om C, om vervolgens toch weer terug te gaan naar A. Dat maakt ontwikkelen moeilijker en vergroot de kans op fouten. De opdrachtgever vergroot willens en wetens de kans op fouten en dan wil je de opdrachtnemer verantwoordelijk stellen wanneer er fouten zijn? Wie heeft daar ook al weer op gestuurd? Precies, de opdrachtgever.

[Pietervs]

Ik ben het met je eens dat er altijd malafide figuren zullen zijn die misbruik maken van de systemen. En dat er altijd bedrijven (en overheden!) zijn die voortdurend de doelen verschuiven omdat er weer iemand anders een “goed idee” had om “nog even” toe te voegen aan het project.

overigens kun je als opdrachtnemer wel degelijk aangeven wat de gevolgen zijn als de de opdracht tussentijds gewijzigd wordt en bij een dergelijke wijziging een papier neerleggen dat de opdrachtgever aansprakelijk wordt voor alle mogelijke fouten in de software. Daarmee zullen veel opdrachtgevers afzien van tussentijdse wijzigingen…

Maar wat is dan de oplossing? Niks doen? Je zal ergens moeten beginnen, lijkt mij.
Moedermaatschappijen aansprakelijk maken voor wat dochterbedrijven uitvreten zou (ook op andere terreinen) behoorlijk kunnen schelen. Maar ongetwijfeld dat er dan weer allerlei andere vage constructies uit de grond gestampt worden door degenen die echt kwaad willen.

[cariolive23]

Moedermaatschappijen aansprakelijk maken voor wat dochterbedrijven uitvreten zou (ook op andere terreinen) behoorlijk kunnen schelen. Maar ongetwijfeld dat er dan weer allerlei andere vage constructies uit de grond gestampt worden door degenen die echt kwaad willen.

Daarmee haal je het complete juridische systeem onderuit. Op zich ben ik daar niet op tegen, mits je met een beter alternatief komt. En gezien de enorme complexiteit daar van, is de kans nihil dat je dit lukt. Vergeet niet dat dit is gebaseerd op honderden jaren ervaring.

Wanneer een juridische constructie voor jou of mij vaag is, zegt dat misschien meer onze kennis dan over de constructie. Dit soort constructies zorgen er ook voor dat bedrijven kunnen blijven bestaan wanneer ergens iets fout gaat. En dat "kwaad willen" werkt ook verschillende kanten op, klanten zullen nu wellicht minder snel een bedrijf aanklagen omdat er minder is te halen. Zo zit de waarde van een bedrijf echt niet in de werkmaatschappij, dat breng je elders onder om het te beschermen.

Moet een complete holding kapot gaan omdat één dochteronderneming een probleem heeft?

[Pietervs]

Dat zijn natuurlijk goede vragen: waar trek je de grens? Laat je Tata steel bestaan, ondanks dat je weet dat een dochterbedrijf inmiddels honderden doden op zijn naam heeft staan en de levensduur van omwonenden aantoonbaar verkort?
Tegelijkertijd: laat je een Albert Heijn failliet gaan en daarmee duizenden mensen werkeloos worden omdat een dochterbedrijf spullen laat maken in een land waar kinderarbeid de norm is?

Mooie filosofische discussies

Dank voor je inzichten, ik zou willen dat ik je bijdragen omhoog kan stemmen.

[kimborntobewild]

Klinklare onzin en dat weet je zelf ook wel. Toon mij maar eens een wet die jou verplicht om fouten in software te repareren en dan ook nog eens binnen een bepaalde tijd.

Geen enkel softwarebedrijf zou dat overleven, zouden allemaal kapot gaan aan de boetes. Het is ook maar de vraag of opensource dat zou overleven, want voor wie is dan de boete?

"Mag je software op een website aanbieden, als je weet dat er veiligheidsgaten in zitten?"

ChatGPT:
Het is over het algemeen niet ethisch of juridisch verantwoord om software op een website aan te bieden als je weet dat er beveiligingslekken in zitten. Hier zijn enkele overwegingen:

Aansprakelijkheid: Als je bewust software aanbiedt met bekende beveiligingslekken, kun je aansprakelijk worden gesteld voor eventuele schade die gebruikers ondervinden door deze kwetsbaarheden.

Vertrouwen: Gebruikers vertrouwen erop dat de software die ze downloaden veilig is. Het aanbieden van onveilige software kan dit vertrouwen ernstig schaden en je reputatie aantasten.

Wettelijke verplichtingen: In sommige rechtsgebieden zijn er wetten en voorschriften die je verplichten om veilige software aan te bieden, vooral als het gaat om software die persoonsgegevens verwerkt.

Verantwoordelijkheid: Als ontwikkelaar of distributeur heb je de verantwoordelijkheid om ervoor te zorgen dat je software veilig is voor gebruik. Dit betekent dat je bekende beveiligingslekken moet verhelpen voordat je de software aanbiedt.

[cariolive23]

Zeker niet ethisch, toch doet men dat dagelijks. Software zonder fouten zal nauwelijks bestaan en van de meeste fouten weet men niet eens dat je deze kunt misbruiken om een systeem in te komen. Meestal zijn er wat symptomen bekend die vervelend zijn en ergens op een lijstje worden gezet om tzt te worden opgelost. Het echte probleem komt pas veel later naar boven en of de complete impact ook wordt gezien, is maar de vraag.

Er is in veel landen inmiddels wetgeving rondom het lekken van data, maar dat staat los van bugs in software. Het zou mij zelfs niet verbazen dat de meeste data lekken ontstaan door fouten van gebruikers en niet door bugs. Denk aan het publiceren van een database backup op een openbaar GitHub account.

Aansprakelijkheid bij bugs in de code wordt keurig via de leveringsvoorwaarden afgewezen. Men repareert de bug, maar vergoed niet de schade.

Speelt ook nog mee dat schade zelden voor 100% wordt veroorzaakt door een bug in de software, maar dat ook andere componenten of processen een rol spelen. Hoe ga je dan het aandeel van de bug meten? Stel wij hebben de rollen en rechten van de database niet op orde die onze applicatie gebruikt. Hartstikke fout natuurlijk. Zijn wij dan 100% verantwoordelijk wanneer de data uit die database naar buiten lekt? Alles en iedereen heeft toegang tot het netwerk van de klant omdat ze hun netwerk niet goed hebben ingericht. En hackers zijn al jaren binnen dat netwerk actief. Zonder die toegang en zonder die hackers zou onze bug zelfs niet aan het licht zijn gekomen, daarmee is ons aandeel 0% ? Of een half promille? Ik zeg 0% want dezelfde data kan ook op een andere manier via dat netwerk weglekken, daarvoor ben je niet van onze bug afhankelijk.

Maar daar gaat het niet om. Bugs in software zijn niet strafbaar. Niet in de landen waar wij werken. Lekken van data is dat wel, daar is de eigenaar van de data juridisch verantwoordelijk voor.

[kimborntobewild]

...en van de meeste fouten weet men niet eens dat je deze kunt misbruiken om een systeem in te komen.

Ik heb 't meer over bewust software aanbieden terwijl de aanbieder weet dat er een security probleem mee is / een gat in zit.

[cariolive23]

de aanbieder

Wie is dat dan? De commercieel directeur? De CTO? De afdelingsmanager? Of een programmeur dit het probleem begrijpt? Daar heb je al 4 personen waarvan er naar alle waarschijnlijkheid maar eentje is die het issue begrijpt. De rest begrijpt het niet, hoort het niet en/of heeft andere prioriteiten.

Het grote probleem is dat security een stiefkindje is in vele organisaties. Het is een nice to have, geen must have. Ik zie dat graag veranderen, maar verwacht dit niet binnen enkele jaren.

[kimborntobewild]

Daar heb je al 4 personen waarvan er naar alle waarschijnlijkheid maar eentje is die het issue begrijpt

Of iemand het begrijpt, heeft er niks mee te maken.
Als Pietje besluit om afgewerkte olie in de sloot achter huis te kieperen omdat hij niet begrijpt hoe schadelijk dat is, maakt nog niet dat hij niet verantwoordelijk is voor de schade!
En voor prioriteiten geldt natuurlijk hetzelfde.

[cariolive23]

Dat heeft er àlles mee te maken, want dat bepaalt mede welke bugs prioriteit krijgen.

[Blokker_1999]

Kan je dan ook even de nodige wetgeving oplijsten die overtreden wordt?

[Alfa1970]

Er zitten wel hele grote verschillen tussen de wetten en regels in de VS in vergelijk met de EU/NL.
Dat wat voor "ons" zo klaar als een klontje is hoeft in de VS nog geen absolute waarheid te zijn.

[Reactie gewijzigd door Alfa1970 op 23 juli 2024 02:07]

[qbig1970]

ja klopt. De Warenwet. Ook in Amerika moet je product (fysiek dan wel digitaal) deugdelijk en veilig zijn. Ook Cyberveiligheid valt daar tegenwoordig onder!

[Loller1]

Als dat zo zou werken zou niemand nog maar durven om software te schrijven.

[kimborntobewild]

Per ongeluk een security gat creëeren is minder erg dan het bewust laten zitten als je er op bent gewezen.
Als je je gewoon aan best practices houdt, dan verschijnen er geen security-gaten in je software.

[yatogami28]

Zelfs als je het serieus neemt zijn veel dingen niet te dichten. Lekken ontstaan regelmatig. Hackers vinden uiteindelijk wel een manier. Je kan wel de kans verkleinen

[kimborntobewild]

Als je het serieus neemt, houdt je je aan best practices en verschijnen er technisch gezien geen gaten.
Moeilijker te bestrijden dan technische onveiligheden: social engineering en blackmailing.

[josttie]

Hoe betrouwbaar is die harris? Een beetje raar verhaal... microsoft kan toch ook een lek dichten zonder het te publiceren? Waarom een lek niet repareren omdat je bang bent voor publiciteit? Wellicht heeft hij het lek wel met anderen gedeeld, goed getimed om net weg te zijn als de hack gebeurd....

[Dick Ravestein]

Ah, is dat tegenwoordig het nieuwe normaal om data lekken gauw te dichten en niet te melden?
Gaat goed met de zelfregulatie van bedrijven!

[josttie]

"Er gaan verhalen rond" betekent vrij weinig. Microsoft is een beetje het ajax van de software makers: meeste fans maar ook meeste haters. Dus er moet natuurlijk wel bewijs zijn.

[Pietervs]

Microsoft heeft anders nogal een reputatie opgebouwd, zeker in de jaren 90:
- het bestaat niet.
- het bestaat wel, maar het is niet belangrijk
- het is geen bug maar een feature
Om het bij een volgende patchronde toch maar te fixen…

Gelukkig is dat wel beter geworden. Maar de ouderen onder ons die al wat langer meelopen in de IT (zoals ik ) zullen dat zeker herkennen.

[Dennisb1]

Er gaan verhalen rond dat MS bepaalde lekken/exploits voor expres heeft achtergelaten.

Je eigen platform en naam schade is ook echt iets wat je expres zou willen doen

[kimborntobewild]

Je eigen platform en naam schade is ook echt iets wat je expres zou willen doen

Dat is dit inderdaad. Als je iets expres in de doofpot probeert te stoppen, kan ik het niet anders zien dan dat je expres naamschade aan het uitlokken bent.

[mutley69]

Microsoft moet na de bekentenissen van de eigen top-jurist aangeklaagd, beoordeeld en veroordeeld worden. Ze moeten betalen voor die slordigheden!

[Dennisb1]

Ah, dat is fijn en ik ben nu gerustgesteld dat ze ervan geleerd hebben.

Mensen zeuren zo over Recall, maar het doet hun echt iets. Ik vind dat men moet stoppen om MS in een kwaad daglicht te zetten, het zijn echte goede gasten en iedereen maakt fouten.

Ik mag hopen dat dit bericht sarcastisch is?

[Reactie gewijzigd door Dennisb1 op 23 juli 2024 02:07]

[HollowGamer]

Ja, maar je zult versteld staan hoeveel mensen dit geloven. 😉

Zie reacties hieronder voor een voorbeeld. MS is een miljarden bedrijf in de US, de schade die ze oplopen hiermee is nihil, en de overheden zijn een goede klant van MS. Uiteindelijk zullen zij een beetje in een grijs gebied blijven zitten en wat vaag blijven.

Ben echt verre van een complot denker, maar dit bericht en genoeg andere bronnen, hebben al aangegeven dat er wel bewuste foutjes worden gemaak. Dat geldt overigens niet alleen voor MS, je kunt dezelfde dingen vinden over vrijwel elk groot Amerikaans bedrijf.

Ik vertrouw MS voor geen meter. Het zijn nog niet een complottheorieën, er is al vaker geweest dat MS bewust exploits niet heeft gefixed, heeft doorgegeven of opeens kon het niet direct worden gedicht.

MS komt er mee weg. Ze hebben de grootste userbase (enterprise dus ook), en mensen willen niet veranderen, dus ontkennen of labelen ze andere als een wappie.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 02:07]