AG DI Meeting vom 18. August 2013¶

• SimonRupf
• jowi
• LuckyLuke
• oschad
• Tuor

• Exception

Absent

Other present parties

Ort: Mumble
Leitung:Oli
Protokollant: jowi
Beginn: 19:01

Messages¶

Oli: Ich bin heute krankheitsbedingt ausgefallen. OTRS mit Simon konnte daher nicht erledigt werden.

Traktanden / Varia¶

SPO Pflichtenheft¶

Aktuelles Pflichtenheft
Art 1 Fundamentals

1 The Security and Privacy Officer is an independent audit institution responsible only to the Board.
2 The Security and Privacy Officer is not bound by any instructions except this ordinance and superior regulations.

Art 2 Election and removal

1 The Security and Privacy Officer is elected for a term of one association year by the Board.
2 When the office becomes vacant during the term, a by-election is held by the Board.
3 The Security and Privacy Officer may not be a member of the Board, the Control Committee or any organ, office or outsourced activity that might have security or privacy issued.
4 The Security and Privacy Officer may be dismissed by a two-thirds majority of the Board.

Art 3 Tasks

1 The Security and Privacy Officer shall inspect all organs, offices and outsourced activities of the Pirate Party Switzerland where security or privacy issues might arise.
2 The committees and the Pirate Court are excempt from the activities of the Security and Privacy Officer. They may however request the services of the Security and Privacy Officer at their discretion.
3 The Security and Privacy Officer shall analyze threats, concerns and problems and shall recommend improvements directly to the head of the organ, office or outsourced activity.
4 The Security and Privacy Officer shall put forward his recommendations in formal motions to the organ, office or outsourced activity if they are not otherwise heeded.

Art 4 Reporting

1 The Security and Privacy Officer shall report orally and in written summary to the Board once a month. In the absence of a board meeting the report is made both to the Presidium and Direction.
2 The regular report shall cover any thread, concerns and problems encountered, any recommendations given and any progress made in mitigation. The regular report shall recommend to the Board any additional measures deemed necessary in mitigation.
3 The Security and Privacy Officer shall report in writing to the Pirate Assembly anually.

Art 5 Emergencies

1 In case of clear and present danger to security or privacy, the Security and Piracy Officer shall inform the head of the corresponding organ, office or outsourced activity without delay and demand immediate mitigation.
2 Should the organ, office or outsourced activity fail to mitigate the problem in a reasonable time the Security and Privacy Officer shall inform the President and the Director immediately.

Art 6 Sources

1 The Security and Privacy Officer has the right to sit in on meetings, review documents and inspect physical data storage of the organs, offices and outsourced activities.
2 The Security and Privacy Officer is forbidden from disclosing any information received in this capacity except as necessary in the reports.

Art 7 Access

1 The Security and Privacy Officer has read access to all systems and services. Where read access is not feasible, the Security Officer has full access. The Security and Piracy Officer is forbidden from modifying any system or service using his privileges.
2 Any access requested by the Security and Privacy Officer must be granted as soon as possible.

Art 8 Organization

1 The Security and Privacy Officer shall autonomously organize his activities.
2 The Security and Privacy Officer may appoint and dismiss deputies and delegate any power or task except his duty to report.

Vergangene Diskussion

• Oli: Hat jemand das Pflichtenheft nicht gelesen oder gibt es generelle Fragen, Anmerkungen, etc?
• Simon: Art. 1.1 würde ich eher so sehen: «The Security and Privacy Officer is part of the workgroup Digital Infrasture.» Ich finde der SPO sollte Teil der AG DI sein, damit er eben nicht von aussen in die AG DI eingreift sondern aus dieser heraus.
• Stefan: War meines Wissens nicht der Wunsch des Vorstandes.
• Oli: Genau aus dem Gund, dass es eben Reibereien gibt, sollte der SPO genau NICHT Teil der DI sein. Auch unter anbetracht dessen, dass er keine Rechte hat auf den Systemen.
• Jonas: Ich glaube für diese Aufgabe braucht man doch zugriff auf die Systeme, oder?
• Oli: Nein, normalerweise nicht, die Datenschutzbeauftragte sind normalerweise nicht Teil des teschnischen Teams. Sie beraten lediglich sind aber nicht berechtigt auf das System zu zu greifen.
• Lukas: Ich denke auch dass ein SPO mehr beratende und nicht eingreiffende Tätigkeiten mahcen sollte.
• Simon: Sobald jemand zugriff bekommen sollte, kann das recht mühsam sein, nur lesend auf Logfiles etc. zugriff zu geben. Wir könnten einfach einen zentralsn syslog server einrichten.
  Lukas: Das ist doch aber eher ein Sicherheitsverantworktlicher und kein Datenschutzverantworlicher der sieht ob und von wo z.B. ein Hackingversuch stattfindet.
• Oli: Das eine ist eher organisatorisch, das andere eher technisch umsetzend.
• Stefan: Nun sind es schon drei Jobs, Techisch umsetzend, Aufsichtsmässig und organisatorisch. Hier geht es eher um die Aufsicht, nicht um die anderen beiden.
• Oli: Lasst uns mal zwei Fälle diskutieren: 1. Jemand der technisch versiert ist und sich bemüht; 2. Jemand der sich nicht so darum bemüht und nicht so sehr kooperativ ist. Es geht hier nun um Art. 7, also die Rechte. Bei Person 1 gäbe es hier keine Probleme, bei Person 2, der Unkooperativen, sehe ich schon eher Probleme. Deswegen sollte der SPO eher keinen Zugriff habe da Person zwei die Arbeit der DI verunmöglichen könnte.
• Simon: Wenn ein SPO als Aufsicht gewünscht ist, hat er keinen Zugriff auf unsere Systeme und erhält nur Leserechte auf Logs und die Konfigurationsdateien.
• Jonas: Oder man teilt es auf in einen Security Officer und einen Privacy Officer der nur von aussen schaut.
• Simon, Oli: Finden den Vorschlag gut!
• Lukas: SO Sollte eigentlich nicht notwendig sein da dass die Personen in der DI machen sollten.
• Simon: Ich wäre aber froh wenn jemand doch noch mal über die Schulter schaut etc. und Tips gibt.
• Jonas: Warum veröffentlichen wir nicht einfach unsere Konfigurationen damit sich diese alle anschauen können? Ohne sensible Daten sondern mit dummy daten.
• Oli: Dann müssen wir das irgendwie automatisieren, denn zwei configs pflegt niemand. Meistens sind es ja auch Folgen von verschiedenen Configs und Rehcten, etc. Im ersten fand ich die Idee gut, aber bei genauerem überdenken müsste man eher das System veröffentlichen damit man alle Zusammenhänge sieht.
• Oli: Wir wären durchaus dafür die Rollen zu trennen und vorerst aus dem SPO nur einen Privacy Officer zu machen. Das bedingt, dass Artikel 7 gestrichen werden sollte, der Rest passt so wie es aktuell ist. Das bedingt, dass alle AGs und deren Mitglieder aktiv mit dieser Person zusammenarbeiten müssen zwecks Auskunft etc.
• Stefan: Ich sage noch ncihts dazu, weil es aktuell etwas ganz anderes ist als ursprünglich gedacht.
• Oli: Wir können das ja mal als Vorversions-Vorschlag / Zwischenergebniss so stehen lassen und das nächste Woche nochmals besprechen.

Alle einverstanden dass das so nächste Woche nochmals besprochen wird.

• SimonRupf: Soweit ich Exception verstanden habe, findet er die Trennung der Aufgaben eine schlechte Idee.
• Oli: Der Datenschutz verantwortliche legt lediglich Richtlinien fest. Er ist organisatorisch tätig und nicht Technisch.
• SimonRupf: So wie ich das verstanden habe befürchtet Exception, dass ein Datenschützer ausserhalb der AG DI machtlos ist. Er kann nur Bestimmungen vorgeben aber schlimmstenfalls nichts ändern.
• Oli: Wir können auch einen Sicherheitsbeauftragten aus der AG DI bestimmen, aber das ist schwierig, da wir Kapazitätsprobleme haben. Ich habe den Vorstand darüber informiert, dass ich mich jetzt schon um die Sicherheit bemühe. Es ist also nicht so, dass wir uns nicht um die Sicherheit kümmern.
• SimonRupf: Der Vorstand möchte über die Sicherheit informiert sein, wir wollen aber nicht von unseren Aufgaben abgehalten werden.
• LuckyLuke: Es gab bzgl. der Begründung des Vorstandes einige Kommunikationsschwierigkeiten.
• SimonRupf: Für die historische Perspektive: Früher hatte mindestens eine Person aus dem Vorstand auf alle Server root-Zugriff, in der Regel der Präsident.
• Oli: Wie ist da eigentlich die rechtliche Lage? Verpflichten uns die Statuten dazu auf die Weisungen des Vorstands zu hören?
• LuckyLuke: Die Statuten sind rechtskräftig, solange sie nicht gegen bestehende Rechte verstossen. Als Arbeitsgruppe der AG DI sind wir dem Vorstand untergeordnet.
• SimonRupf: Ich vermute, einigen Personen wäre es lieber, wenn der Vorstand Zugriff auf die Infastruktur hätte, falls die AG DI aus irgenwelchen Gründen einmal handlungsunfähig sein sollte.
• Tuor: Man könnte bspw. die Zugriffsdaten in einem verschlossenen Kuvert hinterlegen.
• Oli: Ich vermute es geht hier vorallem darum, dass die AG DI uns überprüfen kann. Das kann man auch umsetzten, indem man jmd. aus dem Vorstand Root-Zugriff gewähren, welcher aber nur im Notfall eingesetzt werden darf.
• SimonRupf: Wir protokolieren bereits alles, der Vorstand hat bereits die Möglichkeit uns zu überprüfen.
• Oli: Ich schlage vor, wir weissen den Vorstand darauf hin, dass wir bei der Trennung der beiden Aufgaben bleiben und für den Notfall einen Root-Zugriff für den Vorstand einrichten.
• SimonRupf: Ich finde wir sollten noch eine klare Begründung abgeben, warum wir diese Trennung wollen.
• Oli: Misstraut den der Vorstand uns?
• SimonRupf: Ich vermute, Moira misstraut uns.
• Tuor: Ich hätte Zeit um das mit dem Vorstand zu diskutieren.
• Oli: Eigentlich sind ja bereits Vorstandsmitglieder in der AG DI, aber wir können auch problemlos ein weiteres Mitglied in die AG DI aufnehmen.
• Oli: Lasst uns mal über den Root-Zugriff für den Vorstand abstimmen. Hat noch jmd. Einwände oder ergänzungen?
• jowi: Wäre dies dann ein normaler Zugriff oder hinterlegen wir die Zugangsdaten?
• Oli: Ich denke wir richten da einen Key ein, so können wir die Zugriffe auch protokolieren. Die technischen Details können wir aber später noch ausarbeiten.

Abstimmung:
Ja: Einstimmig
Nein: -
Enthaltung: -

Tuor: Ich bin das Thema auch langsam leid, wir diskutieren jetzt doch schon sehr lange darüber.

Aktuelle Tickets¶

Oli: Ich bin leider zu nichts gekommen.
LuckyLuke: Ich muss mich dir da leider anschliessen.

• Oli: Kennt sich da jmd. mit Wordpress aus?
• SimonRupf: Ich kann mir nicht vorstellen, dass das besonders schwierig sein sollte.
• Oli: Ich glaube auch nicht, dass dies so schwerwiegend ist.
• SimonRupf: Man müsste die Sprachdateien hochladen und die Config anpassen.

• Wird erledigt, wenn wir das OTRS umgezogen haben.

• Das bezieht sich auf ein älteres Ticket, welches bereits umgesetzt wurde, aber scheinbar nicht funktioniert hat.
• Es gibt noch unstimmigkeiten bzgl. des Namens der Liste. Lukas nimmt Kontakt mit dieser Sektion auf.

• SimonRupf: Da gab es noch Probleme, die sollten jetzt aber gelöst sein. Währt Ihr damit einverstanden, dass wir Ihnen einen Alias auch unter der Hauptdomäne geben?
• Oli: Marketingtechnisch ist das natürlich schöner, als unter einer Subdomain. Ist das eine temporäre Adresse für den Wahlkampf oder wird die nachher wieder gelöscht?
• Tuor: Mann könnte die Adresse ja weitergeben, falls jemals jmd. Anspruch auf diese Adresse erheben würde.
• Oli: Ich denke wir müssen eine fixe Laufzeit bestimmen, ansonsten gibt es nacher Probleme bei der Übergabe.
• SimonRupf: Ich denke 1-2 Monate bis nach der Kampagne sollten ausreichen.

• Ticket muss noch geschlossen werden.

• Wurde ausführlich besprochen...

• Prioritäten wurden gesetzt.

5429 Einrichtung Mailingliste "active@vs.piratenpartei.ch" LukyLuke k_in_progress
5317 MailMan setup LukyLuke k_in_progress
5278 Request for VMs oschad k_todo

• SimonRupf: Im Forum wurde gefragt wie weit wir da schon sind. Evt. sollten wir ein Ticket beim Präsidium erstellen?
• LuckyLuke: Ich habe Pascal Gloor bereits gefragt.

5195 Mailingliste für Mitglieder / Sympathisanten in Zürich und Winterthur LukyLuke k_in_progress

Allgemeine Fragen¶

• Jowi: Mit einem leeren Firefox Profil bekomme ich beim erstmaligen Zugriff auf das Projects einen Zertifikatfehler. Kann das jmd. nachvollziehen?
• Oli: Vermutlich liegt das am Browser. Wenn alles migriert ist können wir das nochmal überprüfen.
• Jowi: Wenn ich mich im Projects einlogge werde ich immer auf die Startseite weitergeleitet. Das ist ein bisschen nervig.
• SimonRupf: Dazu müsste man die gesammte URL beim Login übernehmen.
• Jowi: Im Forum wird bei einem englischsprachigem Browser die Zeitzone verändert. Ist das gewollt?
• LuckyLuke: Nein, das sollte eigentlich nicht sein. Dies ist wahrscheinlich ein Feature der Forensoftware.
• Jowi: Es würde auch Sinn machen, wenn sich die Sprache im Portal immer gleich dem Browser anpasst.
• Oli: Erstelle doch dazu mal ein Ticket im Backlog.

Vergangenes / Aussicht¶

• Oli: Es gibt zurzeit sehr viel zu tun, wenn es nicht anders geht müssen wir halt einige ins Backlog verschieben. Es ist auch nicht sehr motibierend wenn wir nie weiterkommen.
• jowi: Ich habe letzte Woche die Prioritäte beim mixed content gesetzt.
• LuckyLuke: Ich werde diese Woche die Mailinglisten anschauen.
• SimonRupf: Ich schaue mir das mit dem OTRS an.
• Tuor: Ich könne noch etwas übernehmen.

Letzte Worte¶

• Oli: Am 1. September treffen wir uns zum grillen.

Nächste Sitzung: 25. August 19:00
*Ende: 20:26 Uhr