[wilhelmtux-discussion] Argumente fuer Eidg. Datenschutzbeauftragen

[S.Aeschbacher]

Hi
danke fuer die kommentare.
die Typos hab ich schon mal korrigert, die restlichen Fragen sollte noch
etwas diskutiert werden. Meine Kommentare zu den Kommentaren im Text.

Ich habe mich noch gefragt in welcher Form wir OpenSource praesentieren
wollen, als Verteilkonzept von Software, oder wollen wir konkrete
Beispiele geben (was die Sache warscheinlich anschaulicher machen
wuerde)?

Gruss
Ste

On Tue, Jul 09, 2002 at 11:11:21AM +0200, Daniel Boos wrote:
> Hallo zaeme,
> 
> hier meine ersten Gedanken. Ich frage mich im Moment ob es Sinn macht,
> dass ganze in Frage und Antwort Form festzulegen.Und falls es in Frage
> und Antwort-Form gemacht wird, denke ich, dass es Sinnvoll waere sich
> genau die Formulierung der Frage zu ueberlegen und eher weniger Fragen
> mit langen Antworten zu nehmen. Kategorien sind sicher auch nuetzlich.

Was fuer eine andere Form stellst du dir vor? In Form eines Papers,
Essay, ...?
Ich finde, zumindest zum Ausarbeiten des Dokuments ist die FAQ Form
nicht schlecht geignet, dies kann dann immer noch in einen Fliesstext
umgewandelt werden.
Eine allfaellige Kategorisierung wuerde ich ins Auge fassen wenn wir
uns ueber die Form einig sind (wenn wir beim FAQ bleiben finde ich
so was in der von dir vorgeschlagenen Richtung ne gute idee).
> 
> So waere es moeglich zwischen Datensicherheit und Schutz vor
> Ueberwachung (Korrekte Begriffe sind mir  gerade entfallen) zu
> Unterscheiden.
> 
> 
> Unter Datensicherheit waeren dann die Fragen zu: Sicherheitsluecken, Fix
> von Sicherheitsloechern, Art der eingesetzten Kryptographie
> 
> Unter Schutz fuer Ueberwachung die Fragen zu: Spionageprogramme (zb
> Marketingzwecken etc.), nicht einstellbare oder unbekannte
> Log-Aktivitaet von Programmen, "Abhoerschnittstellen", Foerderung von
> Transparenz, Vertrauen in ein Informatiksystem
> 
> Ein bisschen gesondert koennte dann noch die allgemeineren Vorteile von
> Open Source beschrieben (oder verlinkt werden)
> 
> Noch einige Kommentare zu den einzelnen Fragen:
> 
> On Mon, 2002-07-08 at 15:07, S.Aeschbacher wrote:
> 
> > 
> > FAQ zu Datenschutz und Opensource
> > *********************************
> > 
> > Begriffe
> > ++++++++
> > ClosedSource Software bei der nur das Programm, nicht aber der
> > 	Source-Code zur Verfuegung steht
> > 
> > Kryptographie Die Wissenschaft des Verschluesselns von Informationen,
> > 	so das sie von dritten nicht gelesen werden koennen.
> > 
> > OpenSource Software bei der der Source-Code frei zugaenglich ist.
> Wuerde dies eventuell noch erweitern
> 
> Open Source Software bei der der Source-Code frei verfuegbar ist,
> beliebig verbreitet werden kann und Modifikationen erlaubt sind.

hab ich mal uebernommen, man koennte evtl noch was ueber die Lizenzen sagen,
das liefe aber dann sehr schnell auf eine Eigene Sektion "was ist OpenSource"
heraus, da doch einiges dazu zu sagen ist.

> 
> > 	
> > Source	Der Code aus dem die lauffaehigen Programme generiert werden
> >         (die Bauplaene der Programme), auch Source-Codge genannt
> 
> Typo: Source-Code
> 
> Allgemein: Wie waere es von Quellcode anstelle von Sourcen, Source Code
> zu sprechen?

Ich muss dir recht geben, wenn wir schon ein deutsches Wort dafuer haben
warum es nicht verwenden. Wie machen wir es mit den Begriffen OpenSource
und ClosedSource (oder wie man sie auch schreiben will), welche in meinen
Augen eher schwer zu uebersetzen sind?

> 
> > Fragen und Antworten
> > ++++++++++++++++++++
> > 
> > F: Wird das Auffinden von Sicherheitsloechern bei offenliegendem
> >    Source nicht massive vereinfacht und so der Missbrauch
> >    gefoerdert?
> 
> Typo: Massiv vereinfacht
> 
> 
> > 
> > F: Der Source liegt zwar offen, wird er aber von jemandem nach
> >    Sicherheitsproblemen durchsucht?
> > 
> > A: Diese Frage kann nicht eindeutig beantwortet werden. Es gibt
> >    Projekte welche laufend von kompetenten Personen nach 
> >    Sicherheisproblemen durchsucht werden (z.B. [OpenBSD]) und es
> >    gibt Projekte bei denen der Source von niemand anderem als dem
> >    Autor gelesen wurde. Bei einem ClosedSource Projekt muss man dem
> >    Hersteller vertrauen, das er Kompetent seinen Source analysiert
> >    und korrigiert hat. Der grosse Unterschied besteht darin, das
> >    bei OpenSource Software jederzeit die Moeglichkeit besteht den
> >    Source zu analysieren.
> 
> Kann da auch was gesagt werden zur Architektur von gewissen Open Source
> Programmen? Einerseits koennte auf grundsaetzliche Designentscheidungen
> aufmerksam gemacht werden, welche das System sicher machen. Ich bin
> nicht Informatiker, nur wenn ich es richtig verstanden habe, laufen
> unter 

Allgemeine Aussagen sind im Bereich Design eher schwer. Architektur
spezifische Aussagen kann man fast nur auf einzelne Produkte bezogen
machen. Viele gute Konzepte die in OpenSource Betriebsystemen
eingesetzt werden stammen von Kommerziellen Systemen (und umgekehrt).
Was genau hat dir vorgeschwebt in Punkto Architektur? (du hast deinen
Satz nich fertig gemacht ;)
Die Designmethoden von OpenSource-Projekten sind voellig anders als
die im Industriellen Umfeld (du hast weiter unten bereits nicht
schlechte links dazu gepostet).
In gewissen Punkten widersprechen die OpenSource Methoden den gaengigen
Grundregeln von Softwaredesign. (z.B. weitgehend fehlende Spezifikationen)

> 
> > F: Wer garantiert die Reparatur eines Programmes im Falle eines
> >    Sicherheitsproblems in einer Software?
> > 
> > A: Ein grosser Teil der OpenSource Entwickler legen grossen Wert auf
> >    die Qualitaet ihrer Programme. Meistens genuegt eine kurze
> >    Benachrichtigung an den/die Autor/en des betroffenen Programmes
> >    und das (Sicherheits-)Problem wird geloest. Bei den meisten
> >    kommerziellen (Gross-)Firmen, kann es Monate dauern bis sich
> >    jemand dem Fehler annimmt (wenn ueberhaupt).
> >    Falls der Autor eines Programmes den Fehler nicht korrigieren will
> >    oder kann, kann ein OpenSource Programm von jedem anderen Programmierer
> >    repariert werden. Bei ClosesSource besteht diese Moeglichkeit nicht.
> 
> Da koennten wir auch noch mit folgender Untersuchung argumentieren:
> 
> V.a S.36 mit der Hypothese 5 ist interessant:
> "Defect density in open source releases will generally be lower than
> commercial code that has only been feature-tested, i.e., received a
> comparable level of testing."
> 
> Auch Hypothese 7  "OSS developments exhibit very rapid responses to
> customer problems." ist teilweise im Sinne von Open Source.
> 
> http://www.ics.uci.edu/~wscacchi/Software-Process/Readings/mozilla-apache-case-study-TOSEM-2002.pdf
> und 
> http://opensource.mit.edu/papers/mockusapache.pdf

sieht brauchbar aus, muss man schauen was man zitieren/referenzieren
will.

> 
> 
> 
> > F: OpenSource wir von Hobby-Programmierern gemacht, kann man da
> >    guten und sichere Programme erwarten?
> > 
> > A: Es mag sein das ein grosser Teil der Programmierer die OpenSource
> >    Software schreiben, dies als ihr Hobby tun. Die meisten davon
> >    sind aber sehr erfahrene Programmierer die in ihrem Berufsleben
> >    auch Programmieren.
> >    Die Qualitaet von OpenSource Software ist durchwegs sehr hoch,
> >    da die Entwicklung nicht wie in einem kommerziellen Betrieb durch
> >    finanzielle Interessen vorangetrieben wird sondern durch die
> >    Motivation ein gutes Programm zu schreiben.
> 
> Dies wuerde ich eventuell ganz weglassen. 
> Es beduerfte da naemlich weitere Klaerung. So entwickeln auch Firmen
> Open Source Programme oder stellen Personen zur Verfuegung, welche
> dafuer programmieren. Weiters sind die Motivationen durchaus komplexer.

Die Antwort die ich gegeben habe ist sicherlich zu allgemein gefasst. Die
Frage hoeren wir aber leider noch recht haeufig und sollte in meinen
Augen schon beantwortet werden. Genaue Daten ueber wer in welchem Rahmen
OpenSource entwickelt habe ich leider keine. Ich glaube aber schon das
der groesste Teil eher Hobbymaessig (d.h. ohne Bezahlung) gecoded wird.
Evtl muss man halt die Frage umformulieren (ich mach mal n vorschlag
im naechsten draft).

> 
> > 
> > 
> > F: Was passiert mit meinen Daten, wenn der/die Programmierer meines
> >    Programmes das Projekt einstellen?
> > 
> > A: Das einstellen eines Projektes kann im OpenSource wie im
> >    industriellen Umfeld genau so passieren. Die Konsequenzen eines
> >    eingestellten Software-Projektes sind vielfaeltig und koennen
> >    Probleme beim Betrieb einer Informatik-Infrastruktur bringen.
> >    Bei einem ClosedSource Projekt ist man als Anwender darauf
> >    angewiesen, das eine andere Firma das Projekt aufkauft und es
> >    weiterbetreibt.
> >    Bei OpenSource liegen alle noetigen Materialien vor, so das
> >    jederman das Projekt weiterfuehren kann.
> 
> Hier stellen sich meiner Meinung zwei Fragen, welche auch getrennt
> behandelt werden sollten. Einerseits geht es um die Daten selber und
> anderseits um das Programm. 
> Bei Daten ist die Loesung die Verwendung offener Standards, welche auch
> auf anderen Systemen verwendet werden koennen. Ermoeglicht auch, dass
> verschiedene Programme fuer die selben Daten verwendet werden koennen
> und wir wollen ja, dass es viele Programme gibt und nicht wie aktuell
> nur ein Word.
> Zu den Programmen stimmt deine Argumentation.

Da ein Programm der Verarbeitung von Daten dient haengen beide Fragen
zusammen. Offene Standards helfen, sobald die Daten in einer neuen
Software verwendet werden soll (d.h. ein Format-Konverter muss geschrieben
werden).
Solange die aktuelle Software ausreichend ist, sollte eher die
Weiterexistenz der Software betrachtet werden.
Offene Standards sind kein Privileg von OpenSource Projekten, so ist
z.B. xml ein offener Standard, wurde aber von rein kommerziellen
Firmen entwickelt.
Wie weit soll die Diskussion zu offenen Standards hier gefuehrt werden?

> 
> 
> > 
> > F: Das OpenSource Projekt verfuegt nicht ueber das Sicherheits-Zertifikat
> >    XY, kann ich ihm Vertrauen?
> > 
> > A: Es gibt eine vielzahl von Sicherheitszertifikaten die meistens fuer
> >    viel Geld erworben werden. Die meisten OpenSource Projekte haben nicht
> >    genuegend Geld um sich solch ein Zertifikat zu leisten.
> >    Die existierenden Zertifikate moegen einen Hinweis geben ob ein Produkt
> >    einen gewissen Standard erfuellt, nur leider wird kaum die Qualitaet
> >    des Source-Codes ueberprueft sondern nur das Vorhandensein von
> >    gewissen Sicherheitsfeatures.
> >    Die Abwesenheit eines Zertifikates macht keine Aussagen ueber die
> >    Sicherheit eines Produktes. Die "Sicherheitsvergangeheit" eines
> >    Programmes ist in vielen Faellen ein gutes Indiz, wie sicher ein
> >    Produkt wirklich ist.
> 
> Typo: Vielzahl
> Sicherheitsvergangenheit
> 
> -> Frage: Sind diese Zertifikate wirklich wichtig in der
> Informatikbranche? Was wird wirklich geprueft? 

Da Sicherheit schwer zu evaluieren ist, werden solche Zertifikate, vor allem
in heikleren Anwendungsbereichen sehr ernst genommen. Beispiele fuer solche
Zertifikationssysteme sind:
- Common Criteria
- Trusted Computer System Evaluation Criteria des Amerikanischen DoD
  (Orange Book, schon etwas veraltet)
Diese Zertifikationen Testen vor allem das Vorhandensein von gewissen
Sicherheitsfeatures, wie Security Policies, Audit-Trails oder Mandatory
Acces control. Design und Implementation werden kaum angeschaut
So wird zum Beispiel bei der Orange Book Zertifikation erst in der
hoechsten Sicherheitsstufe (A1) geprueft ob das Design formal verifiziert
wurde. 
Infos dazu unter:
http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.txt
http://www.commoncriteria.org/

> 
> gruss
> daniel
> 
> _______________________________________________
> wilhelmtux-discussion mailing list
> wilhelmtux-discussion at wilhelmtux.ch
> http://wilhelmtux.ch/mailman/listinfo/wilhelmtux-discussion