Ich bin übernächste Woche zu einer Tages-Veranstaltung eingelanden bei der es um die Sicherheitsbilanz von Freier Software geht. Könntet ihr mir noch etwas Rückmeldung dazu geben, wie ihr die Punkte seht?
Zu der Veranstaltung: Im ersten Schritt soll herausgearbeitet werden, welche (für Sicherheit erheblichen) Charakteristika freie Software und proprietäre Software unterscheiden:
- Qualität der Entwicklung (Hierzu habe ich z.B. gestern den Interessanten Artikel gelesen: https://lwn.net/Articles/718411/ ) - Life-Cycle-Management - Bewertbarkeit von Sicherheit durch Dritte - Verfahren der Schließung von Sicherheitslücken, Reaktionszeit - Rechtliche Verantwortung
Im zweiten Schritt soll bei der Veranstaltung ein Raster entwickelt werden, das Anwender von Software anlegen können, um anwendungsspezifisch zu beurteilen, ob für die Sicherheitsanforderungen des jeweiligen Bereichs der Einsatz von freier oder proprietärer Software eine bessere Sicherheitsbilanz aufweist.
Freue mich über Eure Kommentare/Verweise/Anregungen.
Dankeschön Matthias
On Fri, 7 Apr 2017 10:00:43 +0200 Matthias Kirschner mk@fsfe.org wrote:
- Bewertbarkeit von Sicherheit durch Dritte
Das ist imho ein entscheidender Punkt. Proprietäre Software kann nur so sicher sein wie der Hersteller es bereit ist zuzulassen. Bei freier Software können Dritte - auch gegen den Wunsch des Herstellers - ein Audit veranlassen o.ä..
Dabei auch wichtig: Zwar ist es ebenfalls möglich, dass bei proprietärer Software Dritte nach Sicherheitslücken suchen, aber es bestehen zahlreiche Möglichkeiten der Bug-Suche nicht, die Sourcecode voraussetzen. Gerade bei modernen Bug-Finding-Tools (Coverage-basiertes Fuzzing, C Sanitizer) ist Sourcecode häufig die Voraussetzung.
- Rechtliche Verantwortung
Rechtliche Verantwortung für Sicherheitslücken gibt es de facto nie, da es keine Softwarehaftung gibt, unabhängig davon ob es proprietäre oder freie Software ist. (Anmerkung: Auch bei Sicherheits-Zertifizierungen gibt es praktisch nie rechtliche Verantwortung, weder für den Hersteller noch für die Zertifizierungsstelle.)
On 07.04.2017 10:00, Matthias Kirschner wrote:
Zu der Veranstaltung: Im ersten Schritt soll herausgearbeitet werden, welche (für Sicherheit erheblichen) Charakteristika freie Software und proprietäre Software unterscheiden: [...]
Ich würde noch aufnehmen, weil ja auch sicherheitsrelevant: Man ist nicht von /einem/ "Hersteller" abhängig. Nutzt man ein Open Source Produkt, so kann man im Zweifel selbst dafür sorgen, dass es weitergeführt wird, zB über Ausschreibungen an Dritte. Stirbt die Firma eines proprietären Produkts, ist auch das Produkt tot und muss ersetzt werden.
Lieber Matthias,
spontan will ich auch meine sichtweise hinzu fuegen.
- Qualität der Entwicklung
Ist nur nach vorgabe der kriterien bestimmbar. Das gilt auch bei propietaerer software.
Modularisierung, autonome bereiche, datenflusstrukturen, objektbildung, dokumentation der modellierung und implementierung, die textuelle struktur, laufzeit verhalten, vorhersagbarkeit der zeitlichen ablaeufe.
Das hat auch viel mit einzelaktion oder teamarbeit zu tun. Ebenso mit der gewuenschten lebenszeit und anwendungsdichte.
Nur auf der grundlage freier software ist dies ueberpruefbar, um der moeglichen kombinatorik gerecht zu werden. Bei propietaerer software nur mit Re-engineering.
- Life-Cycle-Management
Ich vermute, du meinst versionsverlaeufe. Die problematik ist an die kontinuitaet der entwickler(gruppe) gebunden. Allerdings sind wir nur mit freier software in der lage, selbst hand anzulegen.
- Bewertbarkeit von Sicherheit durch Dritte
Im eingeschraenkten funktionalen raum gilt es fuer beide bereiche. Auch fuer die kombinatorischen simulationen, die nicht real sein muessen. Also nicht in der anwendung entstehen. Wenn wir aber den raum der gesamten kombinatorik untersuchen wollen, brauchen wir den Source-Code, um das kombinatorische potential abschaetzen zu koennen, das auch intern vorhanden ist.
- Verfahren der Schließung von Sicherheitslücken, Reaktionszeit
Auch hier ist die basis bei freier und propietaerer software die gleiche. Erst wenn die entwickler(gruppe) nicht mehr existiert oder nicht reagiert, brauchen wir den Source-Code.
- Rechtliche Verantwortung
Das hat ja Hanne schon deutlich erklaert. Ich kenne mich damit nicht aus.
Generell:
Viele augen sehen mehr. Das setzt die teilnehmer voraus. Im propietaeren bereich ist das limitiert. Im freien bereich offen.
Unter der vorraussetzung, dass aktive anwender existieren, hat die propietaere software keine zukunft. Weder qualitativ, noch unter stabilitaet, noch unter anpassungsfaehigkeit.
Es ist aber nur ein potential. Wenn der konsumismus dominiert, ist es sowieso das gleiche. Dann koennen wir uns mit einer formalen checkliste behelfen, die immer nur einen kleinen teil des funktionalen raums pruefbar macht.
mit lieben gruessen, willi
On 7/4/2017 05:00, Matthias Kirschner wrote:
Ich bin übernächste Woche zu einer Tages-Veranstaltung eingelanden bei der es um die Sicherheitsbilanz von Freier Software geht. Könntet ihr mir noch etwas Rückmeldung dazu geben, wie ihr die Punkte seht?
Zu der Veranstaltung: Im ersten Schritt soll herausgearbeitet werden, welche (für Sicherheit erheblichen) Charakteristika freie Software und proprietäre Software unterscheiden:
- Qualität der Entwicklung (Hierzu habe ich z.B. gestern den Interessanten Artikel gelesen: https://lwn.net/Articles/718411/ )
- Life-Cycle-Management
- Bewertbarkeit von Sicherheit durch Dritte
- Verfahren der Schließung von Sicherheitslücken, Reaktionszeit
- Rechtliche Verantwortung
Im zweiten Schritt soll bei der Veranstaltung ein Raster entwickelt werden, das Anwender von Software anlegen können, um anwendungsspezifisch zu beurteilen, ob für die Sicherheitsanforderungen des jeweiligen Bereichs der Einsatz von freier oder proprietärer Software eine bessere Sicherheitsbilanz aufweist.
Freue mich über Eure Kommentare/Verweise/Anregungen.
Dankeschön Matthias
Hallo Matthias,
ich bin mir nicht sicher, ob sich das folgende brauchen lässt. Denn im wesentlichen kennen wir das alles bzw. ist ja der FSFE bekannt.
Ich arbeite meist in heterogenen Umgebungen, die aus freien und nicht-freien Komponenten bestehen. Dem Artikel auf LWN kann ich nur z. T. zustimmen. Das dort beschriebene "Review-Problem" besteht auch in der Entwicklung nicht-freier Software.
Was die Fragen der Qualität und Sicherheit Freier Software betrifft komme ich immer wieder auf David Wheelers' Artikel [1] zurück, obwohl dieser gerade was seine Zahlen aus der Sektion Security betrifft sehr alt ist. Die freien Software Entwicklungsmodelle haben für mich in Sachen Qualität einen nicht zu unterschätzenden Vorteil. - Die Entwickler die sich für ein Projekt entscheiden, und Code beisteuern leben für die Sache die sie tun. Sie haben sich in der Regel bewusst für das Projekt entschieden. Bei Entwicklung nicht-freier Software haben die meisten Entwickler nur einen "Job" - sie programmieren evtl. ein Stück Software, dass sie in keinster Weise interessiert.
Life-Cycle-Management - ein großer Begriff. Ich mache es mal kleiner Patch-Management (ein Teil von Life-Cycle-Management). Ist bei Applikationen die in die jeweilige Distribution eingebaut sind unproblematisch - solange man bei dem bleibt, was mitgeliefert wird. Hier wird einmal die Distribution aktualisiert und fertig. Das sieht bei MS Windows z. B. komplett anders aus. Sobald man mit Dritthersteller-Software auf einem Windows-Server arbeitet, muss separiert vom System jede Dritt-Software angepasst werden. Das wird i.d.R. durch weitere Software-Management/Rollout-Tools bei den proprietären System kompensiert. Kostet dennoch Geld und Zeit, und Kontrolle der System-Umgebung wird aufwändiger.
Generell denke ich, dass das Life-Cycle-Management eben durch die Vielfalt der Distributionen besser abgedeckt wird als bei proprietären Systemen, die sich nur auf den Kern beschränken. Das war alles ersteinmal durch die OS-Brille gesehen...
Die Bewertbarkeit durch Dritte kann bei prorietärer Software meiner Meinung nach nicht so effizient sein wie bei freier Software. Denn freie Software erlaubt Code-Audits, und damit verbunden _intensive_ Tests die bei vielen proprietären Produkten so nicht möglich sind. David Wheeler stellte seinerzeit die These auf, dass die meisten Sicherheitslücken bei Freier Software eben durch Code-Audits gefunden werden und wurden.
Das Thema "Rechtliche Verantwortung" kommt immer wieder auf. Insb. von Leuten die der Meinung sind, dass hinter den proprietären Produkten z. T. große Unternehmen stehen, die die Verantwortung übernehmen. Das stimmt in der Praxis nicht, denn diese Unternehmen entziehen sich dieser Verantwortung per Lizenz. Ich denke es gibt weder in der nicht-freien noch in der freien Software Welt diese rechtliche Verantwortung. Diese wird im Zweifel auf den Betreiber der Systemumgebung, Plattform oder auch "Cloud" abgewälzt, der dann mit Hilfe von Life-Cycle-Management alles aktuell halten und daneben regelmäßige Tests durchführen muß.
Wie auch immer, es gibt noch vieles mehr zu den Punkten zu sagen...
Ich möchte anregen ggf. einen Punkt zu Datenschutz per Verschlüsselung mit aufzunehmen, um aufzuzeigen, wie wichtig freie Algorythmen in Verbindung mit Freier Software sind. Kann mir aber auch Denke, dass Deine Veranstalung einen ganz anderen Ansatz verfolgt.
Viele Grüße, Volker
[1] https://www.dwheeler.com/oss_fs_why.html
-- Volker Dormeyer Systementwicklung volker@ixolution.de Lösungen mit Freier Software (http://www.ixolution.de) Berliner Strasse 9 :: 64331 Weiterstadt :: Telefon 06150-972982-10
On 04/07/2017 10:00 AM, Matthias Kirschner wrote:
Ich bin übernächste Woche zu einer Tages-Veranstaltung eingelanden bei der es um die Sicherheitsbilanz von Freier Software geht. Könntet ihr mir noch etwas Rückmeldung dazu geben, wie ihr die Punkte seht?
Zu der Veranstaltung: Im ersten Schritt soll herausgearbeitet werden, welche (für Sicherheit erheblichen) Charakteristika freie Software und proprietäre Software unterscheiden:
- Qualität der Entwicklung (Hierzu habe ich z.B. gestern den Interessanten Artikel gelesen: https://lwn.net/Articles/718411/ )
- Life-Cycle-Management
- Bewertbarkeit von Sicherheit durch Dritte
- Verfahren der Schließung von Sicherheitslücken, Reaktionszeit
- Rechtliche Verantwortung
Im zweiten Schritt soll bei der Veranstaltung ein Raster entwickelt werden, das Anwender von Software anlegen können, um anwendungsspezifisch zu beurteilen, ob für die Sicherheitsanforderungen des jeweiligen Bereichs der Einsatz von freier oder proprietärer Software eine bessere Sicherheitsbilanz aufweist.
Freue mich über Eure Kommentare/Verweise/Anregungen.
Dankeschön Matthias
Am 08.04.2017 um 13:58 schrieb Volker Dormeyer: Die freien Software Entwicklungsmodelle haben für mich in
Sachen Qualität einen nicht zu unterschätzenden Vorteil. - Die Entwickler die sich für ein Projekt entscheiden, und Code beisteuern leben für die Sache die sie tun. Sie haben sich in der Regel bewusst für das Projekt entschieden. Bei Entwicklung nicht-freier Software haben die meisten Entwickler nur einen "Job" - sie programmieren evtl. ein Stück Software, dass sie in keinster Weise interessiert.
Ich weiß nicht, ob ich als Dilettant eine Ausnahme bin: Aber wenn ich Code veröffentlichen will, arbeite ich sorgsamer, versuche nachvollziehbarer zu coden, kommentiere mehr etc., denn ich will mich ja nicht blamieren und beispielsweise beim Coderewiew in der Peergroup nicht zu schlecht dastehen.
Gruß Michael
On 08.04.2017 18:31, Dr. Michael Stehmann wrote:
Am 08.04.2017 um 13:58 schrieb Volker Dormeyer: Die freien Software Entwicklungsmodelle haben für mich in
Sachen Qualität einen nicht zu unterschätzenden Vorteil. - Die Entwickler die sich für ein Projekt entscheiden, und Code beisteuern leben für die Sache die sie tun. Sie haben sich in der Regel bewusst für das Projekt entschieden. Bei Entwicklung nicht-freier Software haben die meisten Entwickler nur einen "Job" - sie programmieren evtl. ein Stück Software, dass sie in keinster Weise interessiert.
Ich weiß nicht, ob ich als Dilettant eine Ausnahme bin: Aber wenn ich Code veröffentlichen will, arbeite ich sorgsamer, versuche nachvollziehbarer zu coden, kommentiere mehr etc., denn ich will mich ja nicht blamieren und beispielsweise beim Coderewiew in der Peergroup nicht zu schlecht dastehen.
Das würde ich nicht an Freie Software/unfreie Software festmachen. Das Entwicklungsmodell von vielen Projekten fördert natürlich einen gewissen Anreiz -- "meine Hand für mein Produkt" wenn das noch wer kennt, aber ist nicht einfach so da. Will sagen, es hängt sehr stark von anderen Faktoren wie QA in einer Firma und die Peergruppe ab.
Gruß Frank