Security by obscurity

[troll]

Es ist immer wieder ein Diskussionsthema und wird in flammenden Reden verteidigt, oder abgelehnt.
Ich würd gerne mal ne gemässigte Diskussion darüber anfangen, da ich es weder ablehne, noch ausschliesslich befürworte.

Dazu mal eine Grundlage, die nie zur Sprache kommt: Wir alle nutzen Security by obscurity - Passwörter, pub-Keys, etc.
Die Sicherheit ist auch hier dadurch gegeben, dass der Angreifer die Zugangsdaten nicht kennt und versucht zu erraten.
Das ist definitiv eine andere Schicht, als das offenlegen von Quellcode, aber in meinen Augen in die Überlegungen mit einzubeziehen.
In dem Thread über das Defacement von Wolles Seite wurde auch der Punkt genannt, dass man mehr Sicherheit durch die Verwendung eines unbekannten CMS erreichen kann. Dem stimme ich zu, es kann höhere Sicherheit bringen.

Ein populäres Beispiel ist Portknocking. Ein Sicherheitsgewinn wird hier via Security by obscurity erzielt. Der mögliche Angreifer weiss nicht, ob er einen Angriffspunkt hat, oder nicht, was einen Angriff(der ausser bei mitm immer über BF erfolgen wird) sehr unwahrscheinlich macht.
Geheimgehalten wird nur die Sequenz, die einen Port öffnet. Der Angreifer kann nur durch einen erfolgreichen, zeitaufwändigen und erfolgreichen Angriff herrausfinden, ob diese Sicherheitsschwelle vorhanden ist.
Wenn er es weiss, bietet Portknocking kaum Sicherheit mehr. Die Sequenz ist nichtmal verschlüsselt. Via MitM-Attack ist Portknocking ein Lacher.

Für mich folgt aus dem Geschriebenen, das Security by obscurity nicht grundsätzlich abzulehnen ist, sondern durchaus mehr Sicherheit bringen kann.

Einen wichtigen Faktor für einen Sicherheitsgewinn sehe ich in der Verbreitung der eingesetzten Software. Bei einem Programm, dass von den Massen genutzt wird, sehe ich fast ausschliesslich Nachteile in Closed Source.
Die Gründe - Klar, eine grosse Community findet mehr Fehler, als ein verhältnismässig kleiner Hersteller.

Anders bei Spezialsoftware, die nur in kleinen Stückzahlen eingesetzt wird. Hier würde ein offener Quellcode keine höhere Sicherheit bieten, weil es in der Natur der Sache liegt, dass keine grosse Community existiert, die Fehler findet.
Hier greift das Argument der Closed-Source-Befürworter. Einem motivierten Angreifer wird die Funktionsweise und mögliche Fehler offengelegt, obwohl im Gegenzug dazu keine höhere Codequalität vorhanden ist, die durch eine hohe Zahl von Entwicklern und Supervisoren erreicht werden kann.

OK, zerfleischt mich

 

[surfer]

Generell bin ich der Meinung: Es gibt keine 100%ige Sicherheit

Man kann z.B. Verteidigungsmechanismen in seine Software einbauen um die Sicherheit zu erhoehen, ein potentieller Angreifer der diese Mechanismen genau studieren kann hat es natuerlich einfacher sich zu ueberlegen wie er Sie umgehen kann, wenn er sie genau kennt.
Andererseits sehen 4 Augen meist mehr als 2 wodurch man Mechanismen verbessern und noch sicherer gestalten kann.

Generell wuerde ich auch sagen, dass wenn ich eine Spezialloesung brauche, welche nicht atraktiv genug fuer die Masse ist um genug freiwillige Manpower zu mobilisieren die "alle" Angriffspunkte eliminieren kann, es sicher vorteilhafter ist nicht jedem zu erzaehlen wie es Funktioniert.
Dadurch das ich weiss wie ein Schloss funktioniert, ist es recht einfach einen Weg zu finden es zu picken.
Der Schluss wenn ich nicht sage wie etwas Funktioniert, dann wird es dadurch aber immer direket viel sicherer ist imho aber auch unfug.

Security by obscurity ist eines der Mittel die helfen koennen die Sicherheit zu erhoehen, und wie jede Sicherheitsmasnahme macht es nicht immer Sinn.

 

[DevilsRightHand]

Security by obscurity ist in meinen Augen das Eingeständnis, nicht genug Kompetenz zu haben, das eigene Produkt auf Sicherheitslücken zu prüfen.

Wenn ich meinen Quellcode offen lege, demonstriere ich schließlich, daß es meiner Meinung nach wasserdicht ist (auch wenn's natürlich bei komplexen Anwendungen Utopie ist).

 

[surfer]

Security by obscurity ist in meinen Augen das Eingeständnis, nicht genug Kompetenz zu haben, das eigene Produkt auf Sicherheitslücken zu prüfen.

Wenn ich meinen Quellcode offen lege, demonstriere ich schließlich, daß es meiner Meinung nach wasserdicht ist (auch wenn's natürlich bei komplexen Anwendungen Utopie ist).

Also was du sagst ist eher der Beweis dafuer das es Aroganz ist eigenen Quellcode offenzulegen weil ich davon ausgehe das es wasserdicht ist, was natuerlich Utopie ist.

Wie schon geschrieben, es gibt keine 100%ige Sicherheit und wenn ich z.B. in einem Chatserver Schutzmechanismen gegen Spammer einbaue, koennen diese nicht 100%ig greifen sonst wuerde niemand Chatten koennen.
Wird dieser Server also nur von wenigen eingesetzt ist es einfacher nur darauf zu reagieren wenn Spammer einen Mechanismus umgehen als alles offenzulegen und somit jedem einsicht zu geben wie er alles umgehen kann.

Eine pauschale Aussage zu treffen ist hier imho unmoeglich, wie so oft im Leben muss man in jedem Einzelfall die Vor- und Nachteile abwaegen.

/me, OpenSourceBefuehrworter seit mehr als einem Jahrzehnt.

 

[troll]

Security by obscurity ist in meinen Augen das Eingeständnis, nicht genug Kompetenz zu haben, das eigene Produkt auf Sicherheitslücken zu prüfen.

Wenn ich meinen Quellcode offen lege, demonstriere ich schließlich, daß es meiner Meinung nach wasserdicht ist (auch wenn's natürlich bei komplexen Anwendungen Utopie ist).

Der Umkehrschluss passt nicht.
Bei OpenSource-Projekten ist es im Normalfall erwünscht den Code zu studieren und Fehler aufzuspüren. Auch das ist ein Eingeständnis, nicht über die notwendigen Kompetenzen zu verfügen.
Was ich in keinerlei Weise verwerflich finde, sondern eher realistisch.

Eine wichtige Frage ist, ob das Thema zu komplex ist, um dogmatisch zu denken, oder ob gerade die Komplexität die Notwendigkeit für Dogmas darstellt.

Solche Dogmas würden die Opensource-Szene komplett aufwühlen. Kaum ein Admin gibt zum Beispiel seine Netzwerktopologie bekannt.
Ich sehe in der Geheimhaltung einer Netztopologie eine zusätzliche Sicherheitsschicht und nicht ein Eingeständnis von Unfähigkeit.

EDITH sagt, dass surfer schneller war, ich aber einen hervorragenden zweiten Platz hingelegt hab ;-)

 

[Daemotron]

In einem anderen Forum wurde die Obscurity vs. Security Diskussion recht heftig geführt (fing eigentlich sachlich an, ist dann aber etwas entglitten). Wen's interessiert: http://forum.rootforum.de/viewtopic.php?f=77&t=42663

Besonders hervorheben möchte ich dabei die beiden Beiträge von isotopp (http://forum.rootforum.de/viewtopic.php?f=77&t=42663#p268153), mit denen ist eigentlich alles gesagt.

 

[troll]

Danke, das ist wirklich gut geschrieben!

 

[Athaba]

Hallo,

ich denke der beste Beweiß dafür, dass Security by Obscurity Schwachsinn ist, ist die Realität.

Beispiele für SbO:
Ein Großteil der Anti-Cheat Software
Ein Großteil der Kopierschutzmechanismen
Stormworm, welcher manuell darauf ausgelegt wurde, dass man aus dem Debugger viel Schrott bekommt[1]
diverse Snakeoil-Hardware, die man in Bruce Schneier Blog und auf anderen Websites findet

[1] Man muss sich ja mal die Umstände vor Augen führen. Stormworm war sicherlich kein kleiner Fisch. Der Entwickler hat gewusst was er tut und seinen Code möglichst schwer leserlich gestaltet (verbessertes SbO). Sein einziger Fehler war, dass er nicht dachte, dass sich jemand die ganze Arbeit antut und dann noch auf einen Fehler im Design kommen.
Die Angreifer haben soweit mir bekannt "nur" für Ruhm gearbeitet und das ganze "einfach so" öffentlich gemacht. Ähnlich ist es ja auch bei der meisten gecrackten Software. Es sind also Angreifer, die meist nicht mal (materiell) für diese Arbeit entschädigt werden.

Dann noch Kryptographie. Niemand würde heutzutage noch ernsthaft geschlossene Verfahren zur Verschlüsselung verwenden. Trotz teilweise hoher Preise, sehr viel Beschäftigung damit und obwohl man meint, dass Serpent zum Beispiel sicherer sei (in der Theorie) wurde AES (offiziell und praktisch) noch nicht geknackt. Auch keiner der anderen Finalisten gilt als unsicher.

Passwörter als SbO zu bezeichnen ist schon etwas gewagt. Was ist schwieriger? Den kompliziertesten Assemblercode aus dem Debugger/Disasembler zu verstehen oder veraltete Algorithmen zu knacken, wie zum Beispiel distributed.net das tut? In der Realität, wo Sicherheit wichtig ist werden keine Passwörter verwendet (höchstens zum Schutz des private Keys), sondern Public Keys, womit die Chance dass der Key schnell gefunden wird nochmal um ein vielfaches kleiner wird.

Ich hatte zuletzt eine Diskussion mit einem Bekannten. Was fehlt wäre eine Foundation, die Geld für (grobe) Lücken zahlt. Der Betrag müsste natürlich in einem gewissen Verhältnis stehen und man müsste die Regeln für die Ausschüttung genau definieren. Ich könnte mir zum Beispiel vorstellen, dass OpenBSD einen anständigen Patzen Geld für eine weitere Remote Hole aufbringen könnte.

Jetzt könnte man meinen, dass dann jeder Entwickler darauf hin arbeitet, aber wer sagt, dass nicht jemand anderer ein inoffizielles Angebot macht und man kann ja auch darauf aufpassen nur loyale Commiter zu haben. Zumindest Releases sollten sicher sein.

Aber zurück zum Thema: SbO verhindert in den meisten Fällen das bekannt werden und fixen von Fehlern. Man sollte auch nicht glauben, dass Code nicht gelesen wird. Man liest ihn zum Lernen, beim anpassen, manchmal um das Programm zu verstehen oder eben um Bugs zu entdecken. Sobald jemand einen Bug entdecken will ist SbO wahrscheinlich die kleinste Hürde. Wenn alles offen ist, ist die Chance, dass den Bug jemand entdeckt, der ihn reportet größer. Schon allein, weil es für den "braven" Bugfinder nicht selten verboten ist die SOftware zu reverse engineeren.

Achja, ein nicht allzu kleiner Teil der Lücken in Closed Source Software wird nicht von Leuten mit Codezugriff endeckt.

Solang es keinen Angriff gibt ist auch SbO "sicher". Deshalb greift das Portknocking-Beispiel. Nur, wenn ich Sicherheit so definiere, dass mich keiner (direkt) Angreifen will mache ich schon den ersten richtig großen Fehler.

Zum Thema Spezialsoftware: Stimmt auch nur teilweise. Immerhin kann ich sie mir in den meisten fällen zum Beispiel auf Basis weit verbreiteter Bibliotheken oder anderen Programmen zusammenbasteln. Damit nutze ich auch viel Know-How, das einem selbst gar nicht zur Verfügung steht. Am Ende geht man wieder davon aus, dass es keinen "echten" Angriff gibt. Dieses Argument ist, wie die oben genannten Beipiele zeigen einfach nur lächerlich.

 

[surfer]

Der Entwickler hat gewusst was er tut und seinen Code möglichst schwer leserlich gestaltet (verbessertes SbO).

Solang es keinen Angriff gibt ist auch SbO "sicher". Deshalb greift das Portknocking-Beispiel. Nur, wenn ich Sicherheit so definiere, dass mich keiner (direkt) Angreifen will mache ich schon den ersten richtig großen Fehler.

Zum Thema Spezialsoftware: Stimmt auch nur teilweise. Immerhin kann ich sie mir in den meisten fällen zum Beispiel auf Basis weit verbreiteter Bibliotheken oder anderen Programmen zusammenbasteln. Damit nutze ich auch viel Know-How, das einem selbst gar nicht zur Verfügung steht. Am Ende geht man wieder davon aus, dass es keinen "echten" Angriff gibt. Dieses Argument ist, wie die oben genannten Beipiele zeigen einfach nur lächerlich.

Wie in dem oben verlinkten Artikel auch gesagt, _kann_ Security by obscurity helfen die Anzahl der Angreifer zu minimieren.
Selbstverstaendlich gibt es keinen 100%igen Schutz, und ein versierter Angreifer wird sich nicht durch einfache Verschleierrung abwehren lassen, aber die Anzahl der Angriffe zu verringern, verringert um ein gewisses Mass auch das Risiko eines erfolgreichen Angriffs.

Im Stormworm Beispiel waere es sicher einfacher gewesen das Ding zu knacken haette man den Code sauber vorliegen gehabt. Natuerlich hat es nicht geschuetzt, aber warscheinlich die Zeit bis es gecrackt wurde herrausgezoegert.

Wie schon geschrieben kommt es immer auf den Einzelfall an ob es Sinn macht das Werkzeug "Security by obscurity" zu nutzen. In meinem Beispiel mit dem Spam/Floodschutzt z.B. wuerde ich behaupten das es ein opportunes Mittel darstellt, ebenso wie Portknocking schonmal einen _Teil_ Angreifer abhalten kann.

Sich nur auf Verschleierrung zu verlassen ist natuerlich Naiv, es aber in _jedem_ Fall strickt abzulehnen ebenso.

 

[MrMarv]

Und dann stellt sich ja noch die frage vor welcher Angreifer du Angst hast:

1. Der 12 bis 18 jährige Jugendliche der auf seiner Windows Box in vorgefertigter Software rum klickt?
2. Der Angreifer mit technischen Verständnis, der weiß was er tut, aber selber keine Exloits etc entwickelt?
3. Der krasse codingcracker der explizit nach Lücken in deinem System sucht und dafür eigene Exploits entwickelt?
4. Die NSA / die Chinesen ?

Bei mir fangen die Bedenken auf den dritten Stufe an, die vierte Stufe ist gleich zu sehen, da ich davon ausgehe das da einfach nur Geld an die Leute aus 3 gezahlt wird.

Trotzdem ist es wichtig sein System zB auf aktuellem Patchlevel zu halten, sonst hat man schon Ärger mit Leuten die weiter unten in der Hackordnung (welch passendes Wort) stehen.
Dabei mangelt es dann aber auch schon bei vielen, viele Firmen die ich (leider) kenne haben keine oder nur schlechte Security Richtlinien. Risikoanalyse wurde gemacht und siehe da, Einbruch in die Infrastruktur steht ganz oben.

Eingeleitet wurde hier mit dem Schaeuble Cracking... das war in meinen Augen nur ein 1 bis 2 Angriff. $CMS Exploit downloaden, anklicken, freuen.

Um aber wieder auf das Topic zu kommen:
Ogion hat durch den Link hier die Diskussion quasi beendet, in dem Post wurde alles gesagt was SbO überhaupt ist und was es ausmacht sich darauf zu verlassen.

 

[Elwood]

http://www.heise.de/newsticker/Bericht-NSA-bietet-Milliarden-um-Skype-abzuhoeren--/meldung/132502 Passt ja zum Thema

 

[Athaba]

Wie in dem oben verlinkten Artikel auch gesagt, _kann_ Security by obscurity helfen die Anzahl der Angreifer zu minimieren.
Selbstverstaendlich gibt es keinen 100%igen Schutz, und ein versierter Angreifer wird sich nicht durch einfache Verschleierrung abwehren lassen, aber die Anzahl der Angriffe zu verringern, verringert um ein gewisses Mass auch das Risiko eines erfolgreichen Angriffs.

Im Stormworm Beispiel waere es sicher einfacher gewesen das Ding zu knacken haette man den Code sauber vorliegen gehabt. Natuerlich hat es nicht geschuetzt, aber warscheinlich die Zeit bis es gecrackt wurde herrausgezoegert.

Wie schon geschrieben kommt es immer auf den Einzelfall an ob es Sinn macht das Werkzeug "Security by obscurity" zu nutzen. In meinem Beispiel mit dem Spam/Floodschutzt z.B. wuerde ich behaupten das es ein opportunes Mittel darstellt, ebenso wie Portknocking schonmal einen _Teil_ Angreifer abhalten kann.

Sich nur auf Verschleierrung zu verlassen ist natuerlich Naiv, es aber in _jedem_ Fall strickt abzulehnen ebenso.

Hinauszögern bringt, wenn es um Sicherheit geht. Du willst ja nicht, dass du erst morgen erfolgreich angegriffen wirst, sondern, dass du gar nicht angegriffen wirst. Es ist nicht naiv auf Security by Obscurity zu verzichten. Es macht das Konzept ausschließlich komplexer. Wenn ich ein sicheres (im Sinne von sicher angelegt und nicht unhackable) System habe, dann kann es mir egal sein, ob jemand die Ports testet. Diese Möglichkeit kann ich ja auch zur Kontrolle der Sicherheit verwenden.

Portknocking zu verhindern ist ja so, als ob man eine drei Meter breite Mauer vor eine Festung baut, damit die, die zu Blöd zum außen rum zu gehen schon früher abwehrt. Klar bringt es was, aber das bei einem einigermaßen gesicherten System zu machen kann mehr Probleme verursachen, als es löst.

Ich gäbe dir ja recht. Ein komplett offenes, ungepatchtes Windows (vielleicht noch mit einem Trojaner versehen), was ja nicht so selten vorkommt ist mit nem Schutz vor portknocking sicherer. Aber in den meisten Fällen kommt es nur drauf an, wie genau gescannt wird. Aber das auch nur als einen Teil von _Sicherheit_ zu bezeichnen ist nicht gerade intelligent. Da kommt es aber auf den Fall und die Definition von Sicherheit an. Es stört mich ja auch nicht, wenn jemand so dumm ist das als Sicherheitsfeature zu bezeichnen, aber ich weiß dann, dass damit nicht das gemeint ist, was ich unter Sicherheit versteh bzw. der Anbieter eines Produkts wohl kaum Ahnung hat wovon er redet. Ich denke, dass das auch der springende Punkt bei den Diskussionen ist. SbO ist nichts, was man als Sicherheitsfeature eines Produktes anpreisen kann/soll. Zumindest nicht, wenn es wirklich um etwas geht. Ich meine, wenn man von Sicherheit spricht, meint man mehr als Schutz vor einem gelangweilten Kind, das gerade einen Portscanner entdeckt hat. Man spricht dann auch von mehr, als vom typischen Abgänger eines TG/einer HTL. Man spricht eben von jemanden, der sich schonmal ernsthaft mit dem Thema Sicherheit auseinandergesetzt hat. Das heißt jemand, der mindestens MrMarvs 2. Angreifertyp entspricht. Zumindest gilt das für das, was ich schreibe.

 

[troll]

Um aber wieder auf das Topic zu kommen:
Ogion hat durch den Link hier die Diskussion quasi beendet, in dem Post wurde alles gesagt was SbO überhaupt ist und was es ausmacht sich darauf zu verlassen.

Nein, eigendlich fängt das Thema für mich dadurch erst an.
Wenn nämlich beides aus Sicherheitsgründen eine Daseinsberechtigung hat fehlen bisher die Konsequenzen in Fallentscheidungen.
Und das ist auch der Grund, warum ich das Thema überhaupt erst angeschnitten habe.

Bisher gibt es kaum Fallentscheidungen. Die Entscheidung eine SW als Closed-Source zu vermarkten entspringt normaler Weise dem Wunsch sein Werk vor Diebstahl zu schützen, oder juristischen Gründen. Sicherheitstechnische Gründe sehe ich da überhaupt nicht, die Marketingsprüche, dass Closed-Source sicherer sei sehe ich als PR an, um sich gegen Open-Source zu behaupten und um sein Vorgehen zu rechtfertigen.
OK, das war jetzt ein Angriffspunkt - ich kann es nicht beweisen und bin auch dankbar, wenn jemand in diese Kerbe haut, weil sie eine Vorraussetzung für meine weiteren Gedankengänge ist.

Unterm Strich sehe ich nicht, dass Sicherheit bei der Entscheidung pro/contra einbezogen wird. Sicherheit nicht an erste Stelle zu stellen ist aber - äh - nicht so dolle? ;-)
Ich bin selbst OSS-Anhänger, aber ich möchte nicht pauschalisieren, dass meine Meinung allgemeingültig ist. Daher frage ich mich konkret in welchen Fällen es sicherheitstechnisch sinnvoll sein kann SW als Closed-Source zu veröffentlichen.
Ich frage mich, ob nicht ein gemischtes Modell überlegen wäre. Also CSS anzufangen und bei steigendem Interesse die Sourcen freizugeben.

 

[Vincent Vega]

Daher frage ich mich konkret in welchen Fällen es sicherheitstechnisch sinnvoll sein kann SW als Closed-Source zu veröffentlichen.

Meiner Meinung nach müsstest Du zuerst einmal klären, wem Du Sicherheit gegen was bzw. wen bieten möchtest.

Im Fall der viel diskutierten Treiber für WLAN Karten kann ein Closed Source Modell Sicherheit bringen. Zum Beispiel Rechtssicherheit für den Hersteller der Karte, der vielleicht nur so garantieren kann, dass die Karte nur im zugelassenen Frequenzspektrum verwendet wird.

Ähnliches gilt für den GSM Stack in Mobiltelefonen oder in Modemkarten. Closed Source Software kann dort z.B. den Netzbetreibern und damit auch den Netzbenutzern Sicherheit bieten, dass niemand das Netz mit dem Telefon bzw. der Karte stört.

Closed Source Software kann auch dem Anwender Sicherheit bieten, z.B. wenn der Hersteller für die Software Support bietet oder sogar für Fehlverhalten haftet. Das kann der Hersteller nur, solange er weiss, dass die Software vom Anwender nicht verändert wurde.

Außerdem kann Closed Source Software dem Softwarehersteller Sicherheit bieten, z.B. wenn er in der Software Verfahren anwendet, die er patentieren möchte. Normalerweise dauert das Patentverfahren länger, als man die Software vom Markt zurückhalten kann bzw. möchte. Eine Veröffentlichung als Open Source würde die Patentbemühungen zunichte machen.

Zugegeben, die Sicherheit in allen oben beschriebenen Beispielen lässt sich auch mit Open Source Software ggf. auf anderem Wege herbeiführen. Abgesehen davon ist die o.g. Sicherheit vielleicht gar nicht das, was Du im Kopf hast. Mein Punkt ist eigentlich, dass der Begriff Sicherheit eine ganze Menge Dinge umschreibt, die je nach Einzelfall anders gewertet werden.

Wenn's Dir um Sicherheit im Sinne von Geheimhaltung geht, dann bin ich übrigens dieser Meinung und denke daher, dass es egal ist ob Open- oder Closed Source Software verwendet wird.

 

[kili]

Im Fall der viel diskutierten Treiber für WLAN Karten kann ein Closed Source Modell Sicherheit bringen. Zum Beispiel Rechtssicherheit für den Hersteller der Karte, der vielleicht nur so garantieren kann, dass die Karte nur im zugelassenen Frequenzspektrum verwendet wird.

Mal abgesehen davon, dass Rechtssicherheit hier wohl weder gemeint ist, noch mit Sicherheit irgendwas zu tun hat: das Argument mit den zugelassenen Frequenzen etc. ist IMHO spaetestens seit dem ganzen Atheros-Drama widerlegt. Erst hiess es, sie muessten closed source verwenden, weil sie sonst irgendwelche Auflagen nicht erfuellen koennten, dann wurde das Zeugs von OpemBSD reverse engineered (und spaetestens da haette Atheros die ganze Produktlinie eigentlich vom Makrt nehmen muessen, wenn an dem Argument mit den zugelassenen Frequenzen irgendwas dran waere), dann gab's das grosse Drama mit dem Linux-Treiber, und AFAIK wirft Atheros das Zeugs inzwischen selbst open source auf den Markt. Kann aber auch sein, dass ich mich irre.

Auf jeden Fall gibt es die Moeglichkeit des reverse engineerings, und deshalb wird eben nicht effektiv verhindert, dass lokal nicht zugelassene Frequenzen verwendet werden. Dieses Argument war schon immer falsch und wird es auch immer bleiben.

Ähnliches gilt für den GSM Stack in Mobiltelefonen oder in Modemkarten. Closed Source Software kann dort z.B. den Netzbetreibern und damit auch den Netzbenutzern Sicherheit bieten, dass niemand das Netz mit dem Telefon bzw. der Karte stört.

Nein, kann er nicht. Gleicher Grund wie oben.

Ein Hersteller kann ein Geraet bestimmungsgemaess ausliefern, damit hat er seine Schuldigkeit getan. Wenn der Kunde am Geraet (oder, um etwas mehr beim Thema zu bleiben: am Treiber) herumpfuscht und damit lokal gueltige Bestimmungen aushebelt, dann haftet in keinem Fall der Hersteller. Es wuerde also voellig ausreichen, wenn der Hersteller seine Hardware nebst (open source) Treibersoftware ausliefert und in grossen roten Lettern auf die Verpackung (oder ins README) schreibt, dass die Software regionalen Bestimmungen unterliegt und jede Aenderung daran zum Erloeschen der Betriebserlaubnis fuehren kann.

Dieses Prinzip ist schon so was von uralt, das gab's (in DE) schon, als Telefone grundsaetzlich grau waren. Graupner und Robbe durften damals auch Funkfernsteuerungen im 27 MHz-Band und Modellflugzeuge verkaufen, auch wenn es definitiv verboten war, Modellflugzeuge auf 27MHz zu fliegen (oder andersrum Modellautos oder Schiffe oder sonstiges nicht luftgebundenes Geraffel im 35 MHz-Band zu betreiben). Oh, und das waren keine albernen Vorgaben von der Bundespost, sondern es gab wirklich gute Gruende, Modellfugzeuge gesondert zu behandeln (ich habe jedenfalls noch nie davon gehoert, dass jemand von einem Modellauto oder -Schiff ernsthaft verletzt wurde).

Das ganze war also eigentlich "Security by Dienstvorschrift." Juristisch fuer die Hersteller (die damals wirklich entsprechende Beipackzettel zur Fernsteuerung dazugeliefert hatten), und zivilrechtlich/versicherungstechnisch fuer potentielle Opfer.

Ich kann mich noch an einen Zeitungsbericht aus meiner Jugendzeit erinnern, in dem von einem Spinner die Rede war, der "just for fun" einen Stoersender (aus einer damals handelsueblichen Fernsteuerung) gebaut hatte, mit dem er die Flieger (Flugzeuge und Helikopter) des benachbarten Modellbauclubs zum unkontrollierten Absturz bringen konnte. Wenn meine grauen Zellen nicht komplett wirr sind, wurde dabei auch mal jemand ernsthaft verletzt. Und natuerlich wurde nicht der Hersteller der Fernsteuerung verknackt, sondern der Spinner (wg. Sachbeschaedigung, gefaehrlicher Koerperverletzung und Verstoss gegen das damals geltende wie-auch-immer-es-hiess-Fernmeldegesetz).

Closed Source Software kann auch dem Anwender Sicherheit bieten, z.B. wenn der Hersteller für die Software Support bietet oder sogar für Fehlverhalten haftet. Das kann der Hersteller nur, solange er weiss, dass die Software vom Anwender nicht verändert wurde.

Der Hersteller weiss aber nicht, ob der Anwender die Binaries veraendert oder in einem nicht vom Hersteller "zertifizierten" Betriebssystem verwendet hat.

Außerdem kann Closed Source Software dem Softwarehersteller Sicherheit bieten, z.B. wenn er in der Software Verfahren anwendet, die er patentieren möchte.

Zum Glueck ist Software hier (noch) nicht patentierbar. Ausserdem ist diese Art von Sicherheit wohl auch nicht gemeint.

Zugegeben, die Sicherheit in allen oben beschriebenen Beispielen lässt sich auch mit Open Source Software ggf. auf anderem Wege herbeiführen.

Ja, in Vertragsform. Juristische Sicherheit halt. Alles nur eine Frage der Haftung. Aus betriebswirtschaftlicher Sicht reicht es fuer viele Unternehmen, jemanden "zum Verklagen" zu haben. Mit Sicherheit im Sinne von zuverlaessiger und fehlerfreier Software hat das leider nichts zu tun. Du kannst z.B. das technisch absolut grottenschlechteste CMS auf den Tisch legen, solange Du Deinen Kunden nur vertraglich zusicherst, dass Du im Zweifelsfall haftest. Und wenn Du gute Rechts- und Marketingabteilungen hast, schaffst Du das auch, obwohl das kleingedruckte im Vertrag die Haftung dann doch irgendwie auf den Kunden abwaelzt. Auch eine Art von "Security by obscurity" ;-)

Abgesehen davon ist die o.g. Sicherheit vielleicht gar nicht das, was Du im Kopf hast. Mein Punkt ist eigentlich, dass der Begriff Sicherheit eine ganze Menge Dinge umschreibt, die je nach Einzelfall anders gewertet werden.

Ich weiss zwar nicht, was der OP im Kopf hatte, ich denke bei dem Begriff "Sicherheit" aber immer als erstes an Nobby "die Rente ist sicher" Bluehm. Exakt das gleiche Luftschloss wie die Sicherheit bei Atheros, wie bei Funkfernsteuerungen oder bei Vertraegen zwischen grossen Auftragnehmern und grossen Softwarekonzernen.

Ciao,
Kili

 

[Daemotron]

Unterm Strich sehe ich nicht, dass Sicherheit bei der Entscheidung pro/contra einbezogen wird. Sicherheit nicht an erste Stelle zu stellen ist aber - äh - nicht so dolle? ;-)
Ich bin selbst OSS-Anhänger, aber ich möchte nicht pauschalisieren, dass meine Meinung allgemeingültig ist. Daher frage ich mich konkret in welchen Fällen es sicherheitstechnisch sinnvoll sein kann SW als Closed-Source zu veröffentlichen.
Ich frage mich, ob nicht ein gemischtes Modell überlegen wäre. Also CSS anzufangen und bei steigendem Interesse die Sourcen freizugeben.

Das kommt darauf an. Ich kann Dir ein Beispiel nennen, wo (so behaupte ich) eine Veröffentlichung potenziell eher keinen Sicherheitsgewinn bringt. Ich denke da an die Steuerungssoftware, die wir in unseren Flugzeugen einsetzen (Flight Guidance, Systems Management mal so als kritischste Komponenten). Abgesehen davon, dass ein guter Teil der Algorithmen in den hochkritischen Komponenten in Form von Schaltungen hart verdrahtet wird, dürfte es wohl kaum jemanden außerhalb des Business geben, der mit einem Peer Review beurteilen kann, ob die Software ihren Job richtig macht - dafür ist das Thema einfach zu speziell.

Ähnliches kann man auf sämtliche Steuerungssoftware für spezielle Anlagen übertragen - hier gilt einfach: Sicherheitsgewinn durch veröffentlichen: Null, Ideenklau durch Konkurrenz: Eins. Die Entscheidung ist damit wohl eher gegen Veröffentlichung. Übrigens: Einige führen bei solchen Systemen auch gerne das Argument an, eine Veröffentlichung würde das Sabotagerisiko steigern - das halte ich jedoch für nicht zutreffend. Wenn jemand dicht genug an die Eingeweide eines Flugzeugs rankommt, dass er die ROMs der FGCs austauschen könnte, kann er noch ganz anderen Unfug treiben...

Ganz anders sieht es meiner Meinung nach allerdings bei Standard-Komponenten aus, wie sie millionenfach im Umlauf sind (WLAN-Chips, UMTS- oder GSM-Hardware, Steuergeräte im Automotive-Bereich). An die Komponenten kommt jeder relativ leicht ran, und bei entsprechender Aufmerksamkeit der Hackerszene ist es jeweils eher eine Frage der Zeit, bis Protokolle und Algorithmen durch Reverse Engineering auffliegen (siehe z. B. gehackter Smart). Hat bis dahin kein gründliches Audit (etwa durch ein Peer Review) stattgefunden (natürlich mit anschließender Abdichtung gefundener Lücken), werden sich sicherlich auch Personen finden, die das (wahrscheinlich durch Dritte) gewonnene Wissen zum Schaden anderer einsetzen werden.

Dabei ist allerdings der Zeitfaktor ein entscheidender. Würde man heute einen Designfehler im GSM-Stack feststellen, wäre es gar nicht ohne weiteres machbar, diesen zu beheben - wenn dafür die Implementierung auf den Endgeräten angepasst werden muss, würde daraus wohl die größte Rückrufaktion aller Zeiten (was natürlich erklärt, warum die Hersteller und Netzbetreiber wenig erpicht darauf sind, den GSM-Stack für eine Überprüfung durch jedermann zu öffnen). Insofern sind Audits und Peer Reviews bei Embedded Systemen dann am nützlichsten, wenn die fragliche Komponente noch nicht in Umlauf geraten ist.

 

[troll]

Natürlich gehts um Steuerungsanlagen.
Im vorliegenden Fall allerdings um Anlagen, die übers Netz gesteuert werden, wodurch ich auch Sabotagepotential sehe.
Dank dir für deine Ausführungen, das bringt mich erst mal ein ganzes Stück weiter!