Symantec geeft overheden geen inzage in broncode meer

Symantec geeft overheden geen inzage meer in de broncode van zijn software. Dat zegt Greg Clark, de ceo van het bedrijf. Volgens hem vormt het geven van inzage een te groot risico voor de veiligheid van de software.

Clark doet de uitspraken in een interview met Reuters. Datzelfde persbureau maakte in juni bekend dat verschillende bedrijven, waaronder IBM, Cisco en SAP overheden op verzoek inzage geven in hun broncode. Destijds werd Symantec ook genoemd, maar het bedrijf zou daarmee gestopt zijn. Dat bevestigt de ceo nu voor het eerst officieel.

Overheden willen de broncode van software inzien om uit te kunnen sluiten dat er backdoors aanwezig zijn. Volgens Reuters vraagt Rusland aan alle Westerse techbedrijven die beveiligingsproducten zoals firewalls en antivirussoftware maken om inzage in de broncode, voordat de producten in het land verkocht mogen worden.

Symantec zegt dat het veiligheidsrisico dat inzage in de broncode met zich meebrengt niet opweegt tegen eventuele gemiste inkomsten. Clark geeft toe dat het marktaandeel van Symantec in Rusland relatief klein is en dat dit de beslissing eenvoudiger maakte dan voor concurrenten.

Vorige week bracht Reuters naar buiten dat HP Enterprise een Russisch bedrijf dat handelde in opdracht van de overheid inzage heeft gegeven in de broncode van ArcSight. Diverse grote bedrijven, banken en overheidsinstanties gebruiken ArcSight, waaronder het Pentagon. HPE stelt dat alleen onder toezicht inzage is gegeven, op een locatie buiten Rusland.

Reacties (56)

[jiquera]

Ik werk zelf als security analist... en ja als je het alleen van obscurity moet hebben is het geen goede zaak. Maar het maakt hacken echt heeel veel moeilijker als je 0.0 extra informatie hebt. Dus ja security by obscurity is van deze tijd en zal het altijd blijven.

In iedere software zit fouten, open source software rekent op het goede in mensen om deze fouten te melden en te fixen. Dat is uiteraard niet van toepassing in deze gevallen. Dus ik snap heel goed dat deze keus gemaakt wordt.

Eg. Open source software beter te vertrouwen? Heartbleed? Shellshock? Die bugs zaten er jaren in en geheid dat overheden er van wisten en dus toegang hadden tot een gigantisch groot deel van producten in de security markt. Ik zeg niet dat closed source per definitie beter is, maar puur vertrouwen op open source mechanismen is wat mij betreft net zo naïef als denken dat een hacker er niet in komt om dat ie de source niet heeft gezien.

Ik denk dat grote security gerelateerde bedrijven beter security labs (die ze vertrouwen) kunnen vragen om regelmatig code reviews te doen dan het open source te maken.

edit: typos

[Reactie gewijzigd door jiquera op 25 juli 2024 04:36]

[jurroen]

Security by obscurity is geen 'best practice'. Dat overheden broncode kunnen inzien waar wij als 'burger' geen inzicht in hebben, geeft mij ook geen goed gevoel. Ja, natuurlijk is het logisch dat ze willen weten dat er geen backdoor in zit. Maar dat is natuurlijk alles behalve een garantie!

HPE stelt dat alleen onder toezicht inzage is gegeven, op een locatie buiten Rusland.

Deze uitspraak bijvoorbeeld. Theoretisch kan er een extra module mee-gecompiled worden, waar de backdoor in zit. Of kan de compiler zelf backdoored zijn en het toevoegen. Er is inzage gegeven in de broncode - ofwel, de broncode is niet meegegeven. Daarmee vervalt de mogelijkheid om de code die men heeft ingezien, zelf te compilen, om zeker te weten dat dit ook de applicatie is die in productie draait. Een vrij extreem en irregulier voorbeeld: Stuxnet wist de compilers van de SCADA systematiek te 'infecten' waardoor elke output de malware met zich meedroeg.

Eg. Open source software beter te vertrouwen? Heartbleed? Shellshock?

Heartbleed was een enorm nasty lek. Uiteraard kan een lek van die proporties ook in closed software zitten, maar dan is het vinden ervan wat complexer. Ik vertrouw zelf OpenSSL niet meer; niet vanwege het feit dat Heartbleed heeft kunnen ontstaan of zo lang onopgemerkt is gebleven, maar vanwege de gehele library en skills van de ontwikkelaars. Ted Unangst, LibreSSL/OpenBSD devver heeft hier een erg interessante presentatie over gegeven, waarbij hij ook ingaat op de codebase van OpenSSL en de fouten hierin: https://www.youtube.com/watch?v=WFMYeMNCcSY

Voor mij is de bottomline: het is vooral voorkeur en vertrouwen. Closed source of open source, een is niet per definitie beter. Het hangt voor een heel groot deel af van het vertrouwen in de partij die het ontwikkeld. Met reguliere audits door een externe partij is dat vertrouwen te toetsen, maar zelfs dan blijft het altijd een kwestie waarvan vertrouwen de fundering vormt.

Toevoeging: Ook al zit er geen bewuste backdoor in, een antivirus kan ook een attack vector vormen. Daar wordt de laatste tijd steeds meer aandacht aan besteed. Zie bijvoorbeeld deze presentatie van 44con (PDF alert): http://joxeankoret.com/do...ing_av_software_44con.pdf

[Reactie gewijzigd door jurroen op 25 juli 2024 04:36]

[Verwijderd]

Security by obscurity is geen 'best practice'.

Wel, dat is Symantec dus niet met je eens. En op congressen hoor ik meer en meer dat firma's geen inzage meer willen geven omdat dat teveel gevaren oplevert.

[ronn0]

Ik ga er wel vanuit dat ze (de overheden) na het zien van de broncode de software zelf zullen compilen en niet laten doen door het betreffende bedrijf dat de broncode ter inzage heeft gegeven.

[Fireshade]

Security by obscurity is geen 'best practice'.

Dat is natuurlijk heel erg subjectief, afhankelijk van wie je het vraagt, en wie wel of geen baat heeft bij obscurity

Re artikel:

HPE stelt dat alleen onder toezicht inzage is gegeven, op een locatie buiten Rusland.

Ik vraag me af hoe zoiets dan gaat. Zitten wat Russische analisten met enkele developers van HPE op een kamertje te spitten in de code?

[Paul]

Security by obscurity is geen 'best practice'.

Alleen security by obscurity is niet slim, maar hoe meer werk mensen moeten doen ergens achter te komen / binnen te komen hoe groter de kans dat ze opgeven of gesnapt worden.

Strict genomen is een wachtwoord ook security through obscurity: Het is veilig omdat de aanvaller iets niet weet, maar ik weet zeker dat je de aanvallers je wachtwoord(en) niet geeft

[bkor]

Open source software beter te vertrouwen?

Als je je broncode publiek beschikbaar maakt dan maak je er als ontwikkelaar gewoonlijk minder een zooitje van. Gaat gaat niet echt dat het automatisch ervoor zorgt dat meer mensen naar de broncode kijken.

Verder investeren overheden tegenwoordig enorm veel in aanvalsteams. Hierbij verzamelen ze beveiligingsproblemen in plaats van deze te melden. Aangezien software wereldwijd is zorgt dit in de praktijk dat de veiligheid van alle software juist slechter is. Dit komt o.a. omdat steeds minder beveiligingsproblemen worden gemeld aangezien je enorm veel geld kan verdienen met het verkopen van zulk soort problemen.

Ter info: ik lees samen met wat anderen [e-mail]

[Berrick]

Het gaat hier niet eens om de afweging tussen open en closed source. De software is "gewoon" closed source, maar met inzage door overheden. Op die manier heb je dus mogelijk het slechste van twee werelden: Geen publieke controle van een hopenlijk welwillende groep gebruikers, maar wel het risico dat een kwaadwillende overheid een bug vind, en deze niet meldt maar gaat exploiten.

Ik kan me dus helemaal vinden in het besluit van Symantec

[johnkeates]

Open Source software is beter te vertrouwen om dat er geen software geheim gehouden wordt. Iets wat je niet kan testen kan je ook niet vertrouwen.

Daarbij is veel Open Source software op het product zelf niet gebouwd om geld te verdienen. Symantec's closed source software is bijvoorbeeld wel gebouwd om geld te verdienen. Niet om dat ze eerst software gingen maken en daarna geld vragen, maar om dat ze een commercieel bedrijf zijn dat puur bestaat om geld te verdienen en toevallig software maakt. De software is ook alleen maar closed source om dat ze bang zijn dat andere mensen anders van hun werk profiteren zonder dat ze er zelf rijker van worden. Gezien hun eerste bestaansrecht dus geldverdienen is kan je stellen dat iedereen die genoeg geld heeft, of genoeg macht heeft om geld tegen te houden invloed uit kan oefenen op Symantec. Dat maakt het kwetsbaar.

Daar is natuurlijk niks nieuws aan, maar software is dus niet closed source om dat het veiliger is, maar om dat het in principe meer geld oplevert. Dat het niet 'veiliger' is of beter laat microsoft graag maandelijks zien op elke dinsdag: nieuws: Microsoft dicht lekken in Outlook en dns-client

[Reactie gewijzigd door johnkeates op 25 juli 2024 04:36]

[dwarfangel]

Zou je niet 99% kunnen vrijgeven, en die ene % inderdaad top secret houden. Even vergelijking met de Coca Cola formule? Iedereen weet wat erin zit, maar niet precies de verhouding. Zou je een dergelijke logica niet als Symantec bijvoorbeeld kunnen doen?

Nadeel van een Lab onderzoek is dat het super veel geld kost. Open-Source is deels ook ontstaan, om dat er genoeg mensen zijn die er wel tijd in willen stoppen. Zonde om die niet te gebruiken. Want denken dat die Labs dat allemaal op orde hebben, is ook naïef volgens mij? Zeker als je die kleine groep daarmee meer "machtspositie" geeft. Gevolg is dat er meer Labs komen, en meer labs is automatisch concurrentie, en zolang het succes van zo'n bedrijf in winstmarges worden uitgedrukt - is dat dus ook geen optimale situatie.

Mooiste zou dus zijn, het beste van 2 werelden, samen maar gescheiden te houden.

Maar dat zeg ik "ff" makkelijk als niet security-baas

[remielowik]

Ja is leuk dat jij die 1% achterhoudt maar als ik een backdoor wil plaatsen dan ga ik dat natuurlijk in die 1% doen . Oftewel hierdoor zal een audit 0% nut hebben en zal geen enkele overheid hier dan ook mee akkoord gaan.

[dwarfangel]

Die 1% laat je dan door de Labs keuren uiteraard. Alleen die hebben dan aanzienlijk minder werk, dus lagere kosten. Niet gek toch?

[remielowik]

Leuk maar welke "Labs" hebben we het hier dan over? Want de Russische overheid gaat natuurlijk nooit een Amerikaans lab vertrouwen(en terecht want de us overheid heeft toch verrassend vaak ene vinger in de pap bij Amerikaanse bedrijven) en als je het door een Russisch lab laat doen heb je eenzelfde probleem.

[dwarfangel]

Om eerlijk te zijn: geen idee. Het werd elders in de reacties geopperd. En ook snap ik wel het argument dat alles open-source doen ook niet ideaal is. Daar tussen zocht ik naar compromissen. En vroeg vervolgens aan iemand waarvan ik dacht dat die er wel iets zinnigs over kon zeggen, of dat een optie zou zijn.. maar nooit meer wat van vernomen

[SuperDre]

En vergeet niet dat closed source 'gewoon' decompiled kan worden en daarmee dus de source beschikbaar komt (vooral als het om .NET applicaties gaat, een hoop developers hebben helemaal niet door dat je die heel simple kunt decompileren naar de originele code, behalve als men echt een specifieke obfuscator gebruikt die niet standaard meegeleverd/beschikbaar is).

[mhkool]

Het grote probleem is dat Symantec een Amerikaans bedrijf is en dat de Amerikaanse wetgeving de Amerikaanse agencies volledige macht geven: ze krijgen via een rechter altijd toegang tot alle data en alle software van elk Amerikaans bedrijf. En dus gaan de agencies gewoon door met hun code reviews en nieuwe hack-tools maken. Ook al zegt de Symantec CEO dat het niet zo is, de wet is aan de kant van de agencies en dwingt iedereen tot geheimhouding over hun code reviews.

[Eagle Creek]

Hoewel het maar de vraag is hoeveel bedrijven kunnen doen als overheden hen verplichten vind ik het een heel goed iets om te zien dat allerhande techbedrijven een vuist durven te maken in dergelijke principiële kwesties.

Het valt me op dat de laatste jaren een toename is in nieuwsberichten waarin multinationals een standpunt innemen tegen overheidsinstanties, met vaak rechten en/of veiligheid voorop. Uiteraard hebben ook bedrijven eigen belangen maar het is goed dat men kritische blijft en publiekelijk de discussie opstart van steeds verdergaande middelen en maatregelen die overheden wensen toe te passen. Dit zorgt voor een noodzakelijke belans in het speelveld van bevoegdheden en belangen om de burger en eigen staat te beschermen versus niet-proportioneel handelen.

Een gevolg hiervan kan natuurlijk versterkt protectionisme zijn. Echter verwacht ik ook dat de euforische mondialisering van een vijftig jaar geleden tot heden in de toekomst meer afgebrokkeld zal worden. Waarbij we Amerikaanse, Europese, Aziatis/Chinese en Russische (en mogelijk Afrikaanse) markten zien die voor en door zichzelf willen produceren. Eigen hardware, software, protocollen en standaarden. Alles om maar uit te sluiten afhankelijk te zijn van een andere natie.

We zien dit al gebeuren met de tal van GPS-alternatieven die afgelopen jaren zijn gelanceerd. Elke zichzelf respecterende grootmacht denkt het zelf beter te kunnen en moeten doen.

[Reactie gewijzigd door Eagle Creek op 25 juli 2024 04:36]

[bantoo]

Ik ben anders niet zo een fan van deze vuist. Closed source is per definitie minder te vertrouwen dan open. Dat een overheid hier zelfs niet bij komt maakt duidelijk dat een bedrijf nul interesse heeft om een case te maken dat hun software legitiem is.

[InsanelyHack]

En wat nu als er exploits gevonden worden? Als Rusland een dergelijke exploit vindt gaan ze echt niet dat tegen Symantec zeggen. Dan houden ze Symantec buiten de eigen deur en kunnen ze het elders misbruiken. Inzage in je code legt ook de kwaliteit bloot. Het is zoiets als je werk laten nakijken door een professor die niet zegt het is goed of fout maar doet ermee wat ie wil.

[remielowik]

Vervang Rusland met de USA en je hebt wat er laatst aan het licht gekomen is door een lek bij een bepaalde 3 letterige Amerikaanse overheidsinstantie, Hint: NSA & wannacry. Het grappige is juist dat wij in het westen steeds maar weer naar Rusland wijzen, echter is het de USA die steeds maar weer gepakt wordt tijdens het uitvoeren van deze praktijken. Ik wil natuurlijk niet beweren dat Rusland ook maar 1 haar beter is maar wij in het westen vergeten toch eigenlijk de grootste speler iedere keer maar weer.

[Skimmiks]

Software wordt niet open source door een overheid toegang te geven tot de broncode. Ik ben ook een voorstander van Open Source en inzichtelijkheid van code, maar dit is niet te vergelijken met wat hier gebeurt.

[Tha_Butcha]

Ik ben voorstander van OSS, maar overheden inzage geven in je code heeft daar IMHO weinig mee van doen. De overheden die dit eisen lijken mij vooral dezelfde overheden te zijn die worden beschuldigd van massa spionage en andere onwenselijke tactieken.

Zoals @toet-toet al aangeeft: Als Rusland een exploit vindt, gaan ze dat heus niet doorgeven. En de Amerikanen gaan zelfs nog een stapje verder: die wilden de makers verbieden om exploits gelijk bekend te maken, dan wel fixes uit te brengen.

Daarbij, zelfs al zou je de code kunnen zien, wie zegt dat de software die draait op jouw computer/appliance ook dezelfde versies is, aangezien je toch alles als binary blob krijgt aangeleverd?

[mashell]

Closed source is per definitie minder te vertrouwen dan open.

Niet per definitie maar in principe. In de praktijk kan iedereen een open source controleren, maar omdat het bijna niemand doet is het niet onmogelijk dat er flinke bugs voor jaren in open source software blijven zitten. Het is pas veilig als er een review gedaan is en jij de kwaliteit van die review kunt beoordelen.

[SuperDre]

En zelfs met die reviews is nog steeds niets zeker, genoeg fouten/exploits die onopgemerkt blijven.

[LOTG]

Dat onafhankelijke gaat nooit gebeuren omwille van de simpele reden dat niet overal alle grondstoffen beschikbaar zijn. Vooral China heeft een groot aantal zeldzame grondstoffen die elders bijna niet voor komen.

Dan zit je dus in een positie waarin je weldegelijk kunt eisen dat men dingen van jou gaat afnemen.
Je krijgt de grondstof niet, alleen een halffabrikaat voor je hardware. Of je krijgt alleen hardware met ingebakken software.

En we zitten hier in Europa sowieso niet in een goede positie om protectionisme te gaan voeren misschien wel op Europees niveau, maar als men uit de EU stapt heb je niets. Onze wester buren zitten al helemaal in een mooie positie. Weg van Europa, maar ze kunnen niet veel op hun eiland. Dus dat word importeren en daarmee zit je in een zwakke onderhadelings positie. Zelfde geld voor ons als wij de deur zouden dichtgooien. Waar halen we onze grondstoffen vandaan?

Alles zit vol met software en je bent gewoon gebonden aan wat de producent er op zet, tenzij die jou de keuze laat.

Je moet een sterke positie hebben wil je dingen kunnen eisen, en dat werkt beter als je groot bent.

[Iblies]

Correctie,
China heeft geen zeldzame metalen.


China doet heel vervuilend werk wat we hier (praktisch) niet meer toestaan en/of het is veel goedkoper om het uit China te halen waardoor we de faciliteiten niet meer hebben.

Voorbeeld zijn kolen en metaal.

En alles is eindig,
China is zelf naarstig op zoek in vb Afrika om daar aan middelen te komen, omdat het ginnen in China zelf steeds lastiger wordt, maar ook meer overlast veroorzaakt.

Waar we voor moeten waken is dat er geen monopolies ontstaan, maar ten alle tijden alternatieven blijven bestaan. Dan kun je mogelijk overschakelen. ARM als alternatief voor Intel, wat een monopolie leek, maar ondertussen moeten we als maatschappij niet op de louweren zitten.

Android of Apple voor mobiel,
en met name Android van Google is een groot donker zwart gat. Het is allang geen open-source zoals het was,
en wie of wat er inzage heeft, wat er met gegevens wordt gedaan, etc . Met bekend.

[LOTG]

China's rare earth industry makes up 97 percent of rare mineral trade worldwide.

Dat ze de mijnbouw willen verplaatsen is wat anders, maar ze hebben er veel en ze hebben veel voorraad die ze fijn kunnen reguleren.

En hoewel ik voor alternatieven ben, vind ik steeds het wiel opnieuw uitvinden ook de grootste onzin. Dan kom je nergens en zoals hier in NL vaak word aangetoond werken die systemen minder dan elders maar het moest hier opnieuw worden uitgevonden. Verzin dan ook daadwerkelijk iets nieuws.

[Iblies]

http://science.time.com/2013/12/20/rare-earths-are-too-rare/
Er is nog veel te vinden.
De metalen zijn niet schaars.

Het westen is er vanaf gestapt omdat het oa zo vervuilend is.

Maar er worden ook acties ondernomen om het te stoppen. Zo wil de US maar ook de EU geen metaal meer uit China en willen ze het extra belasten. Die wordt tegen kostprijs gedumpt en soms lager.
Dumpen in Afrika wordt problematisch,
als productie hier in Europa (op een schonere manier) wordt opgeschroefd krijg je vanzelf een tegenwicht.

[totaalgeenhard]

Vuist maken?

Het is eerder capitulatie.

Als je zo onzeker bent over je code waarom verkoop je het.

[Caayn]

Heeft niet zo zeer met onzekerheid te maken maar gewoon met verstandigheid. In alle software zitten bugs dus ook in deze pakketten.

Open-source is leuk, maar het is zeker niet de ultieme oplossing. Wie zegt dat gevonden bugs daadwerkelijk worden gemeld of dat ze niet al door iemand anders gevonden zijn en misbruikt zijn tegen de tijd dat ze gemeld worden.

[totaalgeenhard]

Elk huis kun je binnen komen.

Als je dat gaat verhullen maak je het juist erger.

Bovendien mag je van een "veiligheids" product verwachtten dat het niet onderdeel van probleem gaat worden.

[Chuk]

Volgens hem vormt het geven van inzage een te groot risico voor de veiligheid van de software.

Security through obscurity? Dit is niet meer van deze tijd. En al zeker niet voor een AntiVirus software.

[JT]

Toch werken de meeste producenten van antivirussoftware op dergelijke wijze. Want welke producent brengt de software uit onder een open source licentie? Alleen een overheid inzage geven is nog steeds security through obscurity want slechts een heel klein aantal mensen kunnen de broncode inzien.

[Chuk]

Wil niet zeggen dat er geen communities mee bezig zijn, bvb http://www.clamwin.com/
Akkoord, je hebt geen bedrijf waar je de schuld aan kan geven als er iets misloopt maar in ruil krijg je hier wel volledig transparant overzicht over de werkwijze van het programma.

[--Andre--]

De Windows port van https://www.clamav.net/ Dat is de enige open source anti virus die ik ken. Zijn er eigenlijk nog meer?

[JT]

Klopt, ik zei dan ook de meeste

[foppe-jan]

Nee, hij zegt feitelijk dat het gevaarlijk is om overheden inzage te geven omdat zij die informatie vervolgens misbruiken om 0days te kunnen ontwikkelen, ipv de problemen te melden. Dat gezegd hebbende geloof ik er geen zak van dat Symantec de Amerikaanse overheid gaat weerstaan als zij "verzoeken" tot inzage indient, en gaat dit waarschijnlijk alleen maar over niet-Amerikaanse overheidsinstanties.

[Reactie gewijzigd door foppe-jan op 25 juli 2024 04:36]

[LOTG]

Ben het eens dat het geen goed security beleid is, maar wie zegt dat er gemeld word wat voor problemen er gevonden zijn.

Dan is het inderdaad veiliger als ze geen inzage krijgen en je product niet zo makkelijk voor spionage doeleinden kunnen gebruiken.

Daar bij kunnen er ook nog landen tussen zitten die je product niet af nemen maar ineens een erg vergelijkbaar product hebben.

[CAPSLOCK2000]

Symantec vertrouwt z'n eigen code dus niet. Inzage in de broncode is zo'n beetje de enige manier waarop we vertrouwen in een software kunnen krijgen.

[Trommelrem]

Symantec vertrouwt Rusland niet. En terecht.

[CAPSLOCK2000]

Als Symantec z'n software op orde had dan hoefden ze Rusland niet te vertrouwen. Als je zegt dat de veiligheid van je product afhankelijk is van geheimhouding dan is dat een sterke aanwijzing dat het niet echt veilig is. "Security by Obscurity" noemen we dat. Voor de duidelijkheid, dat is geen compliment. Het is zo'n beetje de tegenhanger van het "Kerckhoffs Principe" dat juist stelt dat je de werking van een systeem moet kunnen inspecteren zonder de veiligheid te compromitteren.

[Trommelrem]

Rusland is een zwaarwegender belang dan alle andere belangen. Normaliter ben ik juist voorstander van openstelling, maar we hebben het hier wel over Rusland.

[Verwijderd]

Het gaat natuurlijk ook om het feit dat perfecte software niet bestaat. Er zitten altijd bugs in en vroeger of later komen die uit, als het closed-source is duurt dat vele malen langer of gebeurt het misschien nooit. Als het open-source is maar niet op tijd wordt gefixed (lees: niet binnen minuten) dan breekt ook de hel los.

[kdekker]

Je hebt gelijk dat security by obscurity niet de goede weg is, echter beschikbaar stellen van je sources vergroot wel de kennis van degene die toegang krijgt tot die source code.

Als je source code hebt, die een zwak encryptie algoritme gebruikt (en dat weten ontwikkelaars heus wel) kan dan nog dat zwakke algoritme volstaan voor het doel waarvoor het gebruikt wordt. Niet alles hoef onkraakbaar versleuteld te worden. Sterker nog: je versleutelt zo sterk zodat het met de huidige stand van zaken meer tijd kost om te decrypten dan dat de data zijn waarde heeft. Publiceren van sources verplicht je sterkere encryptie methoden te gebruiken, omdat de drempel om te ontcijferen lager wordt. Daardoor moet in de code overgestapt worden op een sterker algoritme. Dat heeft ook nadelen (o.a. meer rekenkracht nodig, compatibiliteitsbreuk).

Daarnaast heb je nog het probleem (dat is ook hety manco van Kerkhoffs Principe) dat wat vandaag veilig is, dat morgen niet meer zo hoeft te zijn. Zodra je op een ander (veiliger) algoritme moet overstappen komt compatibiliteit om de hoek kijken. En daar houdt Kerkhoffs principe geen rekening mee.

In het leven van een software engineer moet security zeker de aandacht hebben, maar is toch altijd een afweging tussen allerlei zaken als kosten/baten, compatibiliteit, tijd, prioriteit etc. Aangezien iedereen (ook ontwikkelaars) fouten maken, maar klanten min of meer altijd compatibiliteit eisen, heb je hier 2 dingen die strijdig zijn.

Daarnaast is dan uiteraard nog het argument van Symantec: diezelfde overheid die de broncode wilt inspecteren op veiligheid, heeft soms belang bij ontdekte onveiligheden.

Overigens: al is werk je met open source: je moet over zeer serieuze kennis beschikken (en tijd) om in een grote codebase security lekken te vinden. Uiteindelijk is het een kwestie van centen dat onveiligheden ontstaan (en blijven bestaan). Waar het ontstaan zowel bij ontwikkelaars als beheerders/gebruiker kan liggen idem het oplossen ervan.

[CAPSLOCK2000]

Als je source code hebt, die een zwak encryptie algoritme gebruikt (en dat weten ontwikkelaars heus wel) kan dan nog dat zwakke algoritme volstaan voor het doel waarvoor het gebruikt wordt. Niet alles hoef onkraakbaar versleuteld te worden. Sterker nog: je versleutelt zo sterk zodat het met de huidige stand van zaken meer tijd kost om te decrypten dan dat de data zijn waarde heeft.

Heb je daar een realistisch voorbeeld van? In deze context?
Als zwakke crypto volstaat voor je doel dan hoef je het niet geheim te houden. Als je het wel geheim moet houden dan volstaat die zwakke crypto dus niet.

In de meeste gevallen kost sterke crypto niet significant meer dan zwakke crypto. Er is geen reden om voor zwakke crypto te kiezen anders dan dat de programmeur geen tijd heeft of niet weet wat hij doet.

Je hebt crypto wel of niet nodig. Geheim houden is geen acceptabele manier om slechte crypto te gebruiken.

Publiceren van sources verplicht je sterkere encryptie methoden te gebruiken, omdat de drempel om te ontcijferen lager wordt. Daardoor moet in de code overgestapt worden op een sterker algoritme. Dat heeft ook nadelen (o.a. meer rekenkracht nodig, compatibiliteitsbreuk).

Nee, zo werkt het niet. Dat is nu net de kern van het Kerckhoffs Principe. De sources lezen maakt het niet mogelijk om het algoritme te ontcijferen.

Daarnaast heb je nog het probleem (dat is ook hety manco van Kerkhoffs Principe) dat wat vandaag veilig is, dat morgen niet meer zo hoeft te zijn. Zodra je op een ander (veiliger) algoritme moet overstappen komt compatibiliteit om de hoek kijken. En daar houdt Kerkhoffs principe geen rekening mee.

Nee. Overstappen naar veilige crypto zal toch moeten. Geheim houden is geen alternatief voor goede crypto, niet in deze context.

In het leven van een software engineer moet security zeker de aandacht hebben, maar is toch altijd een afweging tussen allerlei zaken als kosten/baten, compatibiliteit, tijd, prioriteit etc. Aangezien iedereen (ook ontwikkelaars) fouten maken, maar klanten min of meer altijd compatibiliteit eisen, heb je hier 2 dingen die strijdig zijn.

We hebben het hier over een virusscanner. Veiligheid en betrouwbaarheid zijn de allerbelangrijkste eisen. Ik kan echt geen enkele reden bedenken waarom je in deze context slechte crypto zou accepteren. Wat win je daar mee? Welke onderdeel is zo perfomance-critical dat je geen goede crypto kan gebruiken?

[kdekker]

Ik sprak meer in algemene context. Maar idd. in deze context vraag ik me uberhaupt af wat een virusscanner aan security aan boord heeft. Virusscannen = pattern matching met de AV definities. De virusscanner zelf hooked op een kernel hook, waardoor iedere file handeling onderschept wordt en ieder netwerk pakket gefilterd kan worden. Ik denk dat voor een AV product de 'geheime' meerwaarde zit in technologie achter de heuristics herkenning. Dat is meer bedrijfsgeheim dan dat het met security te maken heeft.

Wel kan een overheid misbruik maken van de scannings algoritmes (en dan bedoel ik de heuristics). Voor bekende viruspatronen denk ik niet dat er veel geheim te houden is. Dat is ook de zwakte van ieder AV product: je kunt alleen maar op patronen scannen van bekende virussen...

[CriticalHit_NL]

Ik denk dat ieder land op bepaalde vlakken niet te vertrouwen is, it's hunt or be hunted.
Elk land wil zijn status, economie en veiligheid veilig stellen, dus tja.

[The Zep Man]

Volgens hem vormt het geven van inzage een te groot risico voor de veiligheid van de software.

Dus indirect geven zij toe dat met publicatie van de broncode fouten sneller opgespoord kunnen worden. Er valt nog wat te zeggen voor open-source, want dan kan iedereen die fouten vinden ongeacht of ze uitgebuit of opgelost worden. Andersom valt er ook wat te zeggen voor security through obscurity, omdat Symantec aangeeft dat het niet delen van broncode veiliger is.

Overheden willen de broncode van software inzien om uit te kunnen sluiten dat er backdoors aanwezig zijn.

Men krijgt geen garantie dat de broncode die men ontvangt toebehoort aan gebruikte binaries. Ook zullen de broncode en de binaries van elke nieuwe versie niet gecontroleerd worden, omdat dat niet te doen is. De gegeven reden om de broncode in te willen zien is dus onzin.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 04:36]

[rbr320]

Sterker nog, het is prima mogelijk om een backdoor te krijgen in een binary waarvan de broncode geen backdoor bevat. Dit doe je uiteraard door de compiler zo te manipuleren dat hij een backdoor inbouwt zodra hij een specifiek stukje code tegen komt. Om dus echt zeker te zijn van je zaak zou je ook de compiler moeten analyseren, zowel de broncode van de compiler als de binaire versie er van omdat bovenstaande stap ook prima gemaakt kan worden in een eerdere versie van de compiler waarmee je de broncode van je compiler compileert. Zo blijf je dus bezig.

Ik ben het met je eens dat dit een onzin reden is om de broncode in te willen zien. Ik ben het echter niet met je eens dat er iets te zeggen valt voor security through obscurity, dat vind ik namelijk te allen tijde een fundamenteel verkeerde aanpak.

[The Zep Man]

Ik ben het met je eens dat dit een onzin reden is om de broncode in te willen zien. Ik ben het echter niet met je eens dat er iets te zeggen valt voor security through obscurity, dat vind ik namelijk te allen tijde een fundamenteel verkeerde aanpak.

Helemaal mee eens. Ik bedoelde het vanuit het perspectief van Symantec.

[Tha_Butcha]

Andersom valt er ook wat te zeggen voor security through obscurity, omdat Symantec aangeeft dat het niet delen van broncode veiliger is.

Kan me ook voorstellen dat daarnaast de heuristieken/algoritmes die worden gebruikt, je nou niet echt wil laten zien aan je concurrent.

[janbaarda]

Het gebruik van Symantec software begint een steeds groter risico te worden. Het is een Amerikaans bedrijf en per definitie verdacht (Petriot Act). NSA/CIA,etc. overheids beïnvloeding kan niet uitgesloten worden (op grond van de onthullingen van Edward Snowden zelfs waarschijnlijk).

Nederland / Europa heeft dringen behoefte aan zelf ontwikkelde en beheerde beveiligingsprogrammatuur.

[Maurits van Baerle]

Er zo'n ook best goede Europese alternatieven verkrijgbaar, F-Secure, Sophos en BitDefender bijvoorbeeld.

[CriticalHit_NL]

Ach de broncode ligt vroeg of laat toch op straat

https://tweakers.net/nieu...-pcanywhere-gestolen.html
https://www.security.nl/p...over+broncode+diefstal%22

[Reactie gewijzigd door CriticalHit_NL op 25 juli 2024 04:36]

[Verwijderd]

The only secrets source code can hide are comments

[THA_ErAsEr]

Ik lees dit eerder als: 'Broncode mag enkel nog door de Amerikaans overheid worden bekeken'. Geen idee of andere overheden ook de eis hebben om broncode te mogen inzien. Ik denk niet dat een overheid die eis uit het raam gaat gooien, als die er is.