Hermann Gottschalk Thomas Birnthaler
© 2004 OSTC Open Source Training and Consulting GmbH eMail: info@ostc.de
Web: http://www.ostc.de
Open Source und Datensicherheit
- ein Widerspruch?
Inhaltsverzeichnis
1 Was ist...
...(Daten)Sicherheit?
...Open Source?
...Linux?
2 Bekannte Beispiele für Open Source 3 Anforderungen an zentrale Software 4 Open Source und Sicherheit
1 Was ist (Daten)Sicherheit?
z Ziele von Datensicherheit
¾ Verfügbarkeit
¾ Integrität
¾ Vertraulichkeit
¾ Decodierbarkeit
¾ Transferierbarkeit
z Maßnahmen
¾ Physische / räumliche Sicherung
¾ Zugriffskontrolle
¾ Fehlertoleranz
¾ Kryptographie
¾ Standards
Absolute (Daten)Sicherheit ist nicht erreichbar!
1 Was ist Open Source?
z Open Source Software (oder auch Free Software) genügt folgenden 10 Regeln:
¾ (Kosten)freie Weitergabe des Programms
¾ Quellcode frei verfügbar
¾ Veränderungen / Ableitungen zulässig
¾ Veränderungen erkennbar
¾ Keine Diskriminierung von Personen / Gruppen
¾ Keine Beschränkung des Einsatzfeldes
¾ Software-Weitergabe = Lizenz-Weitergabe
¾ Keine Beschränkung auf Produkt-Kombinationen
¾ Uneingeschränkte Weitergabe mit anderer Software
¾ Technologie-neutral
1 Was ist Open Source?
z Unterschiedliche Lizenz-"Spielarten"
¾ GNU General Public License (GPL)
¾ GNU Library or "Lesser" Public License (LGPL)
¾ BSD License
¾ MIT License
¾ IBM Public License
¾ W3C License
z Software unter einer dieser Lizenzen erfüllt die 10 Open Source Regeln
z Copyright an der Software
bleibt uneingeschränkt beim Urheber
1 Was ist Linux?
z Linux = vollständige Neuprogrammierung von UNIX
¾ Beginn: 1990
¾ Autor: Finnischer Student Linus Torvalds
¾ Besonderheit: Sofortige Freigabe unter der GPL
¾ Basis: GNU-Projekt der Free Software Foundation (steht ebenfalls unter der GPL)
¾ UNIX-Standards wie SVID und POSIX erfüllt
z Das Paradebeispiel für Open Source Software
z Ohne offene UNIX-Standards wäre
¾ dieses Projekt kaum möglich gewesen bzw.
¾ hätte wesentlich länger gedauert
2 Bekannte Beispiele für Open Source
z Open Source ist kein neuer Gedanke:
¾ Kryptographie
– Security by obscurity doesn't work! (Bruce Schneier) – Klassisches Beispiel "Enigma"
Konstruktion nicht offengelegt
"Knackbar" aufgrund Kombination von - Systematischen Schwächen
- Anwendungsfehlern
¾ Firma GRUNDIG
– Radio-Bausatz "Heinzelmann"
– Schaltpläne zu jedem Gerät
¾ Internet
– Welche Technik war je erfolgreicher?
3 Anforderungen an zentrale Software
z Zu zentraler Software zählen
¾ Programmiersprachen
¾ Betriebssysteme
¾ Firewalls / Virenscanner
¾ Mail-Server
¾ DNS-Server
¾ Web-Server
¾ Internet-Browser
¾ Grafische Oberflächen
¾ Office-Pakete
z Es gibt ausgereifte Open Source Software für diese Zwecke!
3 Anforderungen an zentrale Software
z Anforderungen an zentrale Software
¾ Erfüllt Standards
¾ Funktionalität verifizierbar
¾ Sicher
¾ Gut dokumentiert
¾ Möglichst fehlerfrei
¾ Herstellerunabhängig
¾ Plattformunabhängig
z Open Source Software erfüllt diese Anforderungen perfekt!
4 Open Source und Sicherheit
Pro: Sicherheit durch offene und geteilte Entwicklung
z Viele unabhängige Entwickler / Tester / Anwender
¾ Prüfen sich gegenseitig ("Peer Review")
¾ Teilen sich die Last des Testens
z Gesamter Erstellungsprozess sichtbar
¾ Probleme gut erkennbar und korrigierbar
z Öffentlicher Code verpflichtet zu
¾ Offenheit
¾ Qualität
¾ Dokumentation
4 Open Source und Sicherheit
Pro: Schnelles Beheben von Fehlern
z Fehler sind bei komplexer Software nicht ausschließbar
z Quellcode verfügbar und änderbar
¾ Fehler gut kommunizierbar
¾ Fehler gut suchbar
¾ Fehler von jedem behebbar (im Prinzip)
z Entwicklungshistorie verfügbar
¾ Nachvollziebar, wann von wem welcher Fehler behoben wurde
4 Open Source und Sicherheit
Pro: Volle Kontrolle der Funktionalität
z Quellcode verfügbar
¾ Funktionalität sichtbar
¾ Eigene Version selbst herstellbar
¾ Unerwünschte Funktionalität weglassbar
z Beiträge anderer Entwickler / Anwender
¾ Leicht integrierbar
¾ Expertise und Ressourcen anderer nutzen
4 Open Source und Sicherheit
Pro: Enthält nur wirklich nötige Funktionalität
z Beruht auf dem unmittelbaren Anwenderbedarf
¾ Nur nützliche Funktionalität enthalten
¾ Sparsamer Ressourcenverbrauch
¾ Hohe Zuverlässigkeit
¾ Benutzerfreundliche Anwendungen
z Zusätzlich benötigte Funktionalität leicht ergänzbar
4 Open Source und Sicherheit
Pro: Kontinuierliche Anpassung statt teurer Releases
z Weiterentwicklung in kleinen Schritten
¾ Änderungen überschaubar
¾ Wahl ob mitmachen oder nicht
¾ "Jetzt-oder-Nie"-Problematik gering
z Alte Versionen werden weiterhin gepflegt
¾ Solange Bedarf besteht
¾ Im Extremfall selbst übernehmen
4 Open Source und Sicherheit
Pro: Unabhängigkeit von Anbietern
z Viele unabhängige Support-Anbieter
¾ Freie Wahl
¾ Wechsel vom ursprünglichen Anbieter möglich
¾ Bedarf anpassbar an eigenes Know-How
z Quellcode vorhanden
¾ Im Notfall selber eingreifen oder
¾ Externen Dienstleister eingreifen lassen
4 Open Source und Sicherheit
Pro: Erfüllt offene Standards
z Austauschbarkeit
¾ der Hardware-Plattform
¾ der Betriebssystem-Umgebung
¾ der Software-Komponenten
z Unabhängigkeit von
¾ Herstellern / Lieferanten
¾ Hardware
z Bei Bedarf schrittweiser Wechsel möglich
4 Open Source und Sicherheit
Pro: Effiziente Ressourcen-Nutzung
z Anwenderbedarf entscheidet über Funktionalitäten
¾ Schlanke Software
¾ Geringer Hardware-Anforderungen
z Hard- und Softwareneutralität
¾ Zwingt zu klaren Konzepten
z Einhaltung von Standards
¾ Erlaubt Wiederverwendung von Komponenten
4 Open Source und Sicherheit
Pro: Fördert
z Wettbewerb
z Standards
z Dokumentation
z Know-How-Transfer
z Lernen
z Unterrichten
z Freie Produktwahl
4 Open Source und Sicherheit
Pro: Günstige Anschaffung und TCO (Total Cost of Ownership)
z Open Source Lizenz
¾ Erlaubt nur geringfügige Kaufkosten
¾ Einsatz auf beliebig vielen Systemen
¾ Keine Kosten bei Releasewechsel
z Gespartes Geld investieren in
¾ Anwenderschulung
¾ Weiterentwicklung
¾ Sicherheitstechnik
z Häufigstes Argument, aber eigentlich wenig relevant.
4 Open Source und Sicherheit
Kontra: Software-Entwicklung
z Kein rechtlich Verantwortlicher
¾ Haftung gibt es bei normaler Lizenz-Software auch nicht
z Entwicklungsrichtung ist nicht festlegt.
¾ Von Anwendern / Entwicklern gemeinsam entschieden
z Pflege der Software nicht gesichert
¾ Bei Firmenaufkauf / -konkurs ebenfalls nicht
¾ Im Prinzip kann man dies selber übernehmen
z Know-How ist nicht geschützt
¾ Man kann daraus lernen
¾ Urheberrecht / Copyright bleibt uneingeschränkt gültig
4 Open Source und Sicherheit
Kontra: Kommerzielle Nutzung
z Man kann kein Geld damit verdienen
¾ Mit Lizenzverkauf in der Tat nicht
¾ Mit Support / Dienstleistung sehr wohl
z Kein Marketing, das das Produkt vorantreibt
¾ Führt häufig zu "Featuritis" (ständiger Releaswechsel)
¾ Erhöht die Kosten
z Kommerzielle Unterstützung schlecht
¾ Dienstleister sind an zufriedenen Kunden interessiert, da sie sich nicht über das Lizenzgeschäft interessieren
¾ Das regelt der Markt (IBM, HP, SUN, Oracle, SAP, ...)
4 Open Source und Sicherheit
Kontra: Sicherheit
z Open Source liefert nicht automatisch Sicherheit und Qualität
¾ Gilt für viele andere Entwicklungs-Methoden auch
z Fehler in Open Source Programme liegen offen zu Tage
¾ Von jedermann sofort ausnutzbar
z Weltweit verteilte Entwickler sind nicht kontrollierbar
¾ Einbau von "subversiven" Funktionalitäten
z Kurzfristig stimmt das, langfristig gilt aber immer noch:
"Security by obscurity doesn't work" (Bruce Schneier)
Quellen zum Thema Open Source
z Open Source (www.opensource.org)
z Open Source Deutschland (www.opensource.co.at)
z Free Software Foundation (www.fsf.org)
z Free Software Foundation Europe (www.fsf-europe.org)
z Linux-Kern (www.kernel.org)
z GNU (www.gnu.org)
z FreeBSD (www.freebsd.org)
z NetBSD (www.netbsd.org)
z OpenBSD (www.openbsd.org)
z Homepage von Richard M. Stallman (www.stallman.org)
z Homepage von Eric S. Raymond (catb.org/~esr)
