Sabotage Programmierer baute Fehler in Siemens-Software ein, um Job zu behalten

Anbieter zum Thema

PANDUIT

DataCore Software GmbH

FNT GmbH

Einem von Siemens beauftragten Software-Entwickler drohen zehn Jahre Haft: Der Programmierer hatte Logikbomben in seinen Auftragscode eingebaut, so dass das Unternehmen ihn regelmäßig neu beauftragen musste. Der Vorfall wirft Fragen über Stellen- und Finanzwert von Code auf.

Siemens zerrt in den USA einen externen Entwickler vor Gericht. Der Vorwurf: Der Auftragsprogrammierer soll bewusst Malware in den von ihn geschriebenen Code eingebaut haben, um das Unternehmen zu zwingen, ihn stets aufs Neue wieder zu beschäftigen. Für diese vorsätzliche Sabotage drohen ihn nun, nach Aussage der zuständigen Staatsanwaltschaft, vor einem Bundesgericht in Pennsylvania bis zu zehn Jahre Haft und eine mögliche Geldstrafe von 250.000 Dollar, wie „Business Insider“ meldet.

Immer wieder angeheuert, um den eigens gelegten Fehler zu beseitigen

David Tinley, heute 62 Jahre alt, war von der US-Außenstelle von Siemens über mehrere Jahre hinweg als externer Auftragsarbeiter beschäftigt worden. Die Aufgabe des Programmierers erscheint nicht übermäßig aufwändig: Tinley sollte automatisierte Kalkulationstabellen (‚spreadsheets‘) erstellen. Siemens USA verwendete diese Tabellen unter anderem, um Bestellungen für elektronische Ausrüstung zu koordinieren und verwalten.

Also nur ein einmaliger, ausgelagerter Job für die Erstellung einer automatisierten Tabellenkalkulation? Nicht, wenn es um die Beauftragung Tinleys ging. Denn Siemens musste den externen Programmierer über zwei Jahre hinweg wiederholt beauftragen, um plötzlich auftretende Fehler und Glitches zu beseitigen. Die Rechtsberichtsplattform Law 360 spricht unter anderem von nicht nachvollziehbaren Fehlermeldungen, Abstürzen oder Schaltflächen, die ihre Größe veränderten. Und immer, wenn es zu den Fehlern kam, heuerte Siemens den Programmierer erneut an, um sie zu beseitigen.

Der Vorwurf

Die Staatsanwaltschaft wirft Tinley vor, nie ernsthaftes Interesse daran gehabt zu haben, diese Fehler zu beseitigen. Stattdessen habe der Programmierer ganz bewusst so genannte Logikbomben in seinen Code eingebaut. Bei dieser Malware werden gezielt Fehler in der Software „gezündet“, wenn bestimmte vorher festgelegte Ereignisse eintreten, wie beispielsweise das Erreichen eines bestimmten Datums.

Anstatt diese Bugs zu beseitigen, verschob Tinley regelmäßig nur das Auslösedatum seiner Logikbomben – und zwang das Unternehmen somit, ihn erneut zu holen, wenn die Fehler später wieder auftraten. Da der Code für die von ihm geschriebene Tabelle passwortgeschützt war, hatten Siemens-Mitarbeiter keinen direkten Einblick darauf. Grund für den Passwortschutz sei nach Angabe des Entwicklers gewesen, dass er den von ihm geschriebenen proprietären Code schützen wollte.

Die Auswirkungen

Zwei Jahre lang kam der Programmierer mit der Masche durch. Dann wurde ihm sein eigenes schlechtes Timing zum Verhängnis: Als im Mai 2016 seine Logikbombe einmal wieder zündete, befand er sich gerade im Urlaub. Da Siemens allerdings dringende Aufträge abzuwickeln hatte, zwang das Unternehmen den Entwickler schließlich dazu, der IT-Abteilung sein Passwort für den geschützten Code auszuhändigen. Dadurch stießen die Mitarbeiter schließlich auf die gezielt platzierte Malware.

Insgesamt habe Siemens für die Untersuchung der wiederholt auftretenden Schäden etwa 42.000 Dollar ausgegeben – was in den USA den Bestandteil einer Straftat erfüllt, wenn durch vorsätzliche Handlungen mehr als 5.000 Dollar Schaden entstehen. Tinley’s Anwälte argumentierten hingegen, dass der Entwickler durch seine Taten kein Geld verdient hätte; seine Absicht sei einzig und allein gewesen, seine selbstentwickelte Arbeit zu schützen.

Letztendlich bekannte sich der Programmierer allerdings vor Gericht schuldig. Über die endgültige Höhe der Strafe soll in den kommenden Tagen entschieden werden.

Ab wann bekommt gute Software einen echten Wert?

Ob das Vorgehen des Programmierers illegal und unethisch war, sollte keine Frage darstellen. Aber das Verfahren wirft eine ganze Reihe weiterer Fragen auf:

• Warum verlässt sich ein Unternehmen wie Siemens auf Tabellenkalkulation zur Automatisierung seiner Prozesse?

• Wenn das Unternehmen letztendlich doch intern die Möglichkeit hatte, den Code auf Schwachstellen zu überprüfen, warum wurde der Auftrag überhaupt an einen externen Entwickler gegeben?

• Warum wurde die Situation zwei Jahre lang einfach toleriert?

• Und auch wenn (abgesehen von den von Siemens-Anwälten bezifferten Schaden) nicht bekannt ist, wie viel Siemens an Tinley letztlich für seine Arbeiten zahlte: wie viel war dem Unternehmen ein Stück Code für die Automatisierung einer wahrscheinlich lästigen, aber letztlich doch essentiellen Aufgabe wert?

• Wie kann oder darf ein Unternehmen sich zwei Jahre lang mit der Qualität von Code abfinden, der regelmäßig und häufig von Fehlern befallen wird?

Möglicherweise kam Tinley so lange mit seiner Logikbombe im Code durch, weil das Produkt, dass er abliefert, ein Stück Softwarecode zur reinen internen Verwendung war – eine Kleinigkeit, auf das man intern keine Ressourcen verwenden wollte. Der Auftrag selbst war offenbar zu wenig Wert – weswegen er auf die Idee verfiel, sich immer wieder für kleine Beträge zum Reparieren der selben kleinen Arbeit anheuern zu lassen. Selbst wenn es effektiv nur um ein Makro ging: Offenbar ist auch großen Unternehmen ordentliche, gute Software immer noch viel zu teuer – oder einfach zu wenig wert.

Verantwortung und Regeln in der IT

Digitale Transformation heißt Produkthaftung

Hinweis:Den Beitrag haben wir vom Partnerportal „Elektronik Praxis“ übernommen.

(ID:46051911)