WCG im Unternehmen: abgelehnt aus Sicherheitsgründen.

[Grodahn]

Hallo,

vor einiger Zeit habe ich bei uns im Unternehmen WCG vorgeschlagen, siehe
http://www.rechenkraft.net/phpBB/viewto ... 12&t=12199
Heute bekam ich dann schriftlich bescheid mit folgendem Wortlaut:
"Abgelehnt aus Sicherheitsgründen"

Da es bei uns die Möglichkeit gibt gegen abgelehnte Verbesserungsvorschläge in Berufung zu gehen was ich auch gerne in Angriff nehmen würde.

Hierbei würde ich gerne wie folgt vorgehen:
- möglichst objektiv analysieren ob / wie hoch die Gefahr auf Industriespionage und -Sabotage durch BOINC/WCG ist
- falls es als sicher anzusehen ist, dies möglichst sachlich, leicht verständlich und belegt zusammenzufassen.

Für Tips, Hinweise, Ideen oder ein Brainstorming wäre ich dankbar.
Immerhin geht es um ein paar Tausend PC.

[Dunuin]

Naja, kann deren Admins schon verstehen.

1.) muss man für BOINC einen Port offenhalten, da es ja eine Inet-Verbindung benötigt, was eine Angriffsstelle bietet
2.) kann jedes Programm Bugs haben, wodurch Hacker potenziellen Zugriff auf den PC bekommen können
3.) läd und installiert sich BOINC eigenständig neue Projekt-Software
4.) Hardware nutzt sich mehr ab, was dann im schlimmsten Fall zum Totalverlust des Rechners führt. Ich hab schon aufgehört die defekten Grafikkartenlüfter und Netzteile zu zählen.

Auf einen Rechner mit sensiblen Daten oder einem Server, der nie ausfallen darf, würde ich persönlich auch kein BOINC installieren.

[ChristianB]

Achtung es folgt eine persönliche Meinung:
Solange man die Gründe nicht genau kennt ist es schwierig dagegen vorzugehen. Sicherheitsgründe kann man immer vorschieben wenn andere Gründe nicht stichhaltig genug sind. Es gibt durchaus die Möglichkeit Schadsoftware über einen BOINC Client einzuschleußen. Grundsätzlich sind aber bestimmte Mechanismen eingebaut die das erschweren (aber nicht unmöglich machen) bzw. die man zusätzlich ergreifen kann um das ganze sicherer zu machen. Das bedeutet aber das jemand dafür Arbeitszeit aufwenden muss und das ist bekanntlich Geld was nicht gerne ausgegeben wird.

Auch eine Analyse über das Gefahrenpotential ist schwierig zu bewerkstelligen. Alles was wir als Laien hier anbringen, würde von einem Fachmann sicher anders Interpretiert werden. Es gibt nicht ohne Grund Experten die eine IT-Risikoanalyse für viel Geld erstellen (auch wenn sicherlich die Qualität des ein oder anderen zu wünschen übrig lässt).

Nichtsdestotrotz möchte ich hier mal ein paar Einfallstore bezüglich des BOINC Client (mit WCG als Projekt) auflisten.

• als ScienceApp getarnte Schadsoftware, ist nur möglich wenn der Angreifer den privaten Schlüssel des Projektes zum signieren der Anwendung besitzt. Dies ist somit ein externes Risiko was man nicht beeinflußen kann. Es weiß schließlich keiner ob IBM diesen Schlüßel auch genügend geheim hält. Es gab bisher auch nur einen Vorfall wo ein BOINC-Projekt nur mit dem Ziel aufgebaut wurde Schadsoftware auf die Rechner zu verteilen. Das wurde jedoch sehr schnell von der Community erkannt und entsprechend bekannt gemacht. Die Nutzung von bekannten vertrauenswürdigen Projekte hilft hier das Risiko zu minimieren.
• Bugs im Client die eine Kontrolle durch den Angreifer erlauben, solch eine Schwachstelle ist noch nie bekannt geworden und durch ein paar Mechanismen gesichert. So ist die Steuerung eines Clients von einem anderen Computer nur möglich wenn man ein entsprechendes Passwort besitzt was lokal in einer Datei gespeichert ist (Das ist teilweise ein internes Risiko, wie gut das eindringen in den Rechner abgesichert ist). Auch das Sandboxing ist mittlerweile auf Windows möglich so das der Client mit einem eigenen Benutzeraccount ausgeführt wird der keine Adminrechte hat. Somit wäre der Schaden den ein Angreifer anrichten könnte lokal begrenzt, wenn man davon ausgeht das die andere Software auf dem PC entsprechend gesichert ist.
• ein offener ManagementPort auf jedem PC, ist erforderlich damit der Admin per Manager (BoincView o.ä.) die Clients auch steuern kann. Das muss natürlich in einer entsprechenden Firewallrichtlinie verankert sein. Bei normalen PCs wird meist ein sehr strikter Maßstab angesetzt da hier ja keine eingehenden Verbindungen erforderlich sind sondern immer nur nach außen die Kommunikation aufgebaut wird. Das kann man aber auch entsprechend absichern, kostet nur wieder Zeit und Geld.

Um eine bestmögliche Sicherheit zu erhalten sind halt bestimmte Maßnahmen zu treffen.

• Das Benutzerkonto für den BOINC Client muss entsprechend konfiguriert werden, das kein Zugriff auf andere Daten möglich ist. Auch muss der Zugriff des normalen Mitarbeiters auf den Client eingeschränkt werden. Denn jeder der lokal den Manager startet könnte ja ein potentiell schädliches Projekt hinzufügen.
• Eventuell müsste der Festplattenspeicher, die Performance der PC überwacht werden. In einer Unternehmensumgebung gibt es garantiert bereits Tools die das Übernehmen und den Admin bei Problemen informieren. Hier muss aufgepasst werden das diese nicht plötzlich Alarm schlagen weil die CPUs auf 100% laufen oder der HDD I/O einen Schwellwert übersteigt der auf einen Virenbefall hinweist.

Zu den Punkten von Dunuin:

1. der Port ist nur für das Managen des Clients erforderlich. Die Internetverbindung erfolgt ausschließlich über Port 80 oder 443 (oder einen entsprechenden Proxy) und auch dann wird die Verbindung vom Client nach außen initiiert (wie bei einem Browser auch).
2. Dieses Risiko muss man bei Fremdsoftware (so auch Office o.ä.) immer hinnehmen. Bei OpenSource Software hätte man den Vorteil das hier bereits ein Peer-Review stattgefunden hat und man selbst auch jederzeit den Code überprüfen kann und notfalls sogar selbst die Software erzeugen kann (kompilieren). Wenn man z.B. MS Office einsetzt kann man das nicht.
3. siehe Schutzmechanismen die ich in der ersten Auflistung genannt habe
4. sehe ich nicht als Sicherheitsgrund, da ich sensible und hochverfügbare Systeme von vornherein für DC ausschließe. Damit ist der erhöhte Verschleiß ein reines Ressourcenproblem.

Wie man sieht trifft ein Großteil der Tätigkeiten zur Absicherung den IT-Administrator (bzw. die IT-Administratoren). Und der hat natürlich eine grundsätzliche Abneigung gegen potentiell unbezahlte Überstunden für etwas was ihn nicht interessiert.

[Michael H.W. Weber]

Soweit ich weiß findet Kommunikationsinitiation immer nur von innen (BOINC) nach außen (Internet) statt. Hat man also ein festes Projekt, wie beispielsweise WCG (=IBM) sehe ich kein Sicherheitsrisiko. Selbst die Nutzung eines Nicht-Adminaccounts für BOINC, den man simpel einrichten kann, halte ich in solch einem Szenario bereits für überzogen, schadet aber gewiß nicht.

Der Typ vom Rechenzentrum möge sein Sicherheitsrisiko mal bitte wissenschaftlich fundiert begründen.

Das Argument, der Rechner nutze sich ab bei Benutzung, ist meiner Ansicht nach lächerlich. BOINC wird da nur laufen, wenn die Maschinen ohnehin an sind und das Zuschalten von BOINC wird wohl kaum nachweislich die Lebensdauer der Maschinen im Zeitrahmen ihrer regulären Dienstzeit innerhalb eines Unternehmens reduzieren.

Meiner Ansicht nach gibt es nur einen guten Grund, BOINC nicht zuzulassen: Das Unternehmen ist nicht bereit, die zusätzlichen Energiekosten zu tragen. Dieses Investment muss man dann dem Publicity-Effekt der Unterstützung gemeinnützger Forschung gegenüber stellen und sich fragen, was einem wichtiger ist. Und sollte man zu dem Ergebnis kommen, dass einem der Publicity-Effekt wichtig ist, sollte man sich überlegen, wie man den maximieren kann (also umfassend bekannt machen, dass das Unternehmen sich hier engagiert).

Michael.

[Grodahn]

Danke euch.

Meine bisherige Struktur für den Widerspruch sieht ca wie folgt aus:

- Erneut Erläuterung der Zusammenhänge von BOINC / WCG / ScienceApp in Bild und Schrift
- Beschreibung des Bewerbungsprozess von ScienceApp bei IBM/WCG
- Beschreibung der ScienceApp-Sicherheit. Erklärung der Signierung, sowohl prinzipiell als auch unter genauer erklärung des Verfahrens (algorithmen, deren Sicherheit usw). Hinweis auf die Teilnahme ausschließlich bei nicht-neuen Projekten mit mindestens xyz Benutzern usw.
- Beschreibung des Fetch/Flush - Vorgangs des Clients für neue/fertige Pakete. Was wird wann wie und wohin übertragen, wie ist es gesichert, wo liegen Angriffspunkte, entweder gezielt auf ein Unternehmen oder allgemein. Wie gefährlich können korumpierte Arbeitspakete sein.
- Beschreibung der Clientsicherheit. Dies beinhaltet verstecken / schützen des clients vor ungewollter oder absichtlich schadhafter Benutzerinteraktion, benötigte Kommunikationsports, Kommunikationsstruktur, ist Zugriff von außen erforderlich? Sandboxing usw.
- Erwähnung der OpenSource-Struktur und ihrer Sicherheitsaspekte.

Desweiteren habe ich folgende Punkte in meinem Vorschlag zwar abgearbeitet, werde sie aber erneut vorheben:
- PC werden grundsätzlich nach höchstens 3 Jahren ausgetauscht. ein Zeitraum in dem sich elektrischer Verschleiß garnicht und mechanischer so gut wie garnicht bemerkbar machen sollte.
- Von der Verwendung des WCG-Clients auf Server, Echtzeitsystemen, Steuercomputern und anderen kritischen Komponenten wurde strikt abgeraten.
- GPU-Computing und Notebookeinsatz wurde zwar erwähnt, aus Gründen der Geräusch- und Hitzeentwicklung ebenfalls davon abgeraten.

@Totschlagargument Sicherheit

Ich werde auf jeden fall nachfragen wo exakt die sicherheitstechnischen Bedenken liegen, jedoch erst nachdem ich eine möglichst umfangreiche Schriftliche Sicherheitsanalyse habe. Sicher ist sicher.

Weiß jemand etwas entsprechendes schonmal diskutiert wurde? Vielleicht in der CT oder anderen zitierbaren Medien?

[ChristianB]

Eine Sicherheitsanalyse zu BOINC ist von einer entsprechenden Firma bisher nur einmal gemacht wurden (zumindest was öffentlich bekannt wurde). Allerdings wurde dabei nichts publiziert sondern alle erkenntnisse sind in den Quellcode gefloßen. Das ist aber schon wieder mindestens 2 Jahre her. IBM hat sicherlich eine Abschätzung diesbezüglich gemacht. Ob man die bekommt und , da auf englisch, ob die dann auch einer liest ist fraglich.

[hias]

Das war eben einfach nur die standardmäßige Argumentation des Sys Admins. Wer sich nicht für Wissenschaft interessiert hat eben kein Bock sich die Mühe zu machen und eine "unnötige" Software auf allen Rechnern zu installieren.

[Michael H.W. Weber]

Genau. Und deshalb gilt es das zu bemängeln. Der verdient da Geld, um sich z.B. über solche Dinge Gedanken zu machen und Lösungen zu erarbeiten. Nicht für's Sesselfurzen.

Michael.

[Grodahn]

Hm ich hatte ein ähnliches Gefühl. Tatsächlich hätte ich mich mit "Nette Idee, leider fehlen uns die personellen Ressourcen" als Antwort auch zufrieden gegeben. Aber so hat es meinen Trotz geweckt ,-)

[Michael H.W. Weber]

Probiere mal dran zu bleiben. Auch wenn es wohl Anrennen gegen Windmühlen ist.

Michael.