Was Computerhersteller von Landwirten lernen können

Gastbeitrag von | 04.11.2019

Zu meiner Schulzeit fuhr der Milchkutscher noch mit Pferd und Wagen durch das Dorf, hielt bei jedem Bauern an, um die von ihm bereitgestellten Milchkannen aufzuladen. Dann ging es im Trab zur Molkerei im nur einen Kilometer entfernten Nachbarort, wo die Milch abgenommen und weiterverarbeitet wurde. Heute fährt ein Lastwagen mit mehreren Tausend Litern Tankvolumen von Hof zu Hof, pumpt die Mich in den Tank und bringt sie zur zig Kilometer entfernten Zentralmolkerei. Am Nachmittag fährt derselbe Lastwagen zur Tankstelle, pumpt Diesel in den Tank, um am nächsten Tag die gleiche Tour – oder eine andere mit dem gleichen Zweck – unternehmen zu können. So geht das Tag für Tag. Doch dann gibt es lange Gesichter: Bei den Kunden der Molkerei, weil Butter, Milch und Käse nach Diesel schmecken – und beim Fahrer des Milchtankers, weil der Motor nicht mehr rund läuft.

So etwas gibt es nicht? – In der Milchwirtschaft Gott sei Dank nicht. Dort hat man Schritt für Schritt die Weiterentwicklung des Metiers vollzogen: Erst wurden die Pferde durch einen Traktor ersetzt, dann die Milchkanne durch einen gemeinsamen Tank, und der wurde eines Tages einer Zugmaschine aufgesattelt. Doch in einem anderen Wirtschaftszweig herrscht genau diese Situation vor: In Datenverarbeitung und Informationstechnik.

Der gemeinsame Laderaum

Die historische Entwicklung in der Datenverarbeitung und Informationstechnik lief etwas anders als beim Milchtransport: Um im Bild zu bleiben, kann man sich vorstellen, dass der Milchkutscher, den ich als Kind kannte, den Hafer für seine Rosse in einem Sack auf dem Milchwagen mitnahm. Wohlgemerkt: In einem separaten Behälter, der auch mit der Nutzlast, eben den Milchkannen, nicht verwechselt werden konnte. Die Computer – also bildlich gesehen: die Fahrzeuge der EDV – haben nicht nur in ihrer Frühzeit – auch dieselbe Ladefläche für Nutzlast und Betriebsmittel genutzt: Den Speicher. In ihm waren Nutzlast – die zu bearbeitenden Daten – und Betriebsmittel – die dazu erforderlichen Programme – nur durch virtuelle Grenzen voneinander getrennt, nämlich die jeweils gelegten Adressräume.

Bei der Weiterentwicklung der Rechner wurden zwar die Pferde nach und nach gegen schnellere Zugmaschinen ausgetauscht, und auch die Zuladung wurde erhöht, doch die Trennung zwischen Nutzlast und Betriebsmittel wurde nicht vollzogen. Okay, um bei der Wahrheit zu bleiben: Es gab einmal eine Zeit, in der man beides trennte, das nannte man „Harvard-Architektur“, doch diese blieb ein kurzes Intermezzo. Die heute gebräuchlichen Rechner – einschließlich ihrer Varianten, mögen sie auch Controller oder anders genannt werden – haben wieder nur oder immer noch einen „Laderaum“, den sich Nutzlast und Betriebsmittel teilen.

Vorteil Angreifer

Diese Situation ermöglicht es Angreifern, einem Rechner auf verschiedenen Wegen Daten (Nutzlast!) unterzuschieben, die in Wirklichkeit Programme (Betriebsmittel!) sind. Die Bezeichnung für diese untergeschobenen Betriebsmittel ist Schad-Software. Diese tut im Rechner das, was der Hacker ihr vorgegeben hat – und das ist meistens etwas, das der Nutzer nicht will.

Was lässt sich dagegen tun? Diese Frage beschäftigt inzwischen Heere von Cyber-Security-Spezialisten. Die gängigen Verteidigungsstrategien erweisen sich immer wieder als unzureichend, denn in diesem Szenario sind die Hacker die innovative Partei, deren täglich neue Produkte an statischen Merkmalen oder ihrer Funktion erkannt werden müssen.

Anti-Viren-Programme bieten hier nur unzureichenden Schutz: Mit dem Erkennen allein, das schon schwierig genug ist, ist es nicht getan: Es muss noch ein Gegenmittel programmiert und vom Nutzer installiert werden. Bis dahin wird so viel Zeit vergangen sein, dass der Hacker wahrscheinlich schon längst erreicht hat, was er erreichen wollte.

Wiederholte Ermahnungen an die Nutzer, bestimmte Aktivitäten zu tun oder zu unterlassen, verfangen auch nicht immer: Zum Beispiel sind Nachrichten von falschen Neukunden oder gefälschte Internet-Seiten für Nicht-IT-Forensiker nicht ohne Weiteres zu erkennen.

Die Trennung von Daten und Software

Wer bis hierher gelesen hat, der wird schon erkannt haben, dass der Milchlaster, den unsere IT-Geräte repräsentieren, dringend einen zweiten “Tank” benötigt; also einen für die zu bearbeitenden Daten, die “Milch”, und einen für die Nutz-Software, die “Betriebsmittel”. Mitdenker haben auch schon erkannt, dass zusätzliche „Leitungen“ erforderlich sind, damit “Diesel” und “Milch” sauber voneinander getrennt bleiben. Vordenker haben sich schon technische Lösungen dafür ausgedacht, wie außerhalb des eigentlichen Rechners mit dieser Trennung von Daten und Nutz-Software umzugehen ist, bis hin zur Beschreibung einer cyber-sicheren Nutzung des Internets.

Welche Konsequenzen sind zu ziehen – und von wem?

Auf den Konsum von Molkereiprodukten, sprich digitalen Geräten, zu verzichten, dürfte wohl nur für einzelne Personen ein Ausweg sein. Deshalb wird auf die Vermeidung von Störungen bei deren Produktion und Bereitstellung gesetzt. Akteure, die hier gefragt sein könnten, sind:

  • In erster Linie die Hersteller der Milchtransporter, sprich der Rechner-Hardware. Doch deren Geschäftsmodelle laufen derzeit so gut, dass sie ohne Druck von außen kaum geneigt sein dürften, aufwändigere Geräte herzustellen. Die wären dann ja – wer will schon auf Gewinne verzichten? – teurer als die Geräte der Mitbewerber. Und Marktanteile aufgeben? Das ist in den Geschäftsplänen nicht vorgesehen.
  • In zweiter Linie der Fuhrhof der Zentralmolkerei, also die Nutzer der Rechner-Hardware. Bei denen ist es relativ unverständlich, dass sie nicht nach sicheren Produktionsmitteln verlangen. Möglicherweise fallen die immer noch auf die blumigen Versprechen von Verkäufern und Beratern herein, die es vielleicht auch nicht besser wissen. Oder das Fehlen besserer geeigneter Komponenten lässt ihnen keine andere Wahl.
  • In dritter Linie sind es die Bauern, pardon, die Erzeuger von Daten. Sie möchten die Qualität ihrer Produkte gerne garantieren, doch was beim Empfänger ankommt, das liegt leider nicht allein in der Hand der Erzeuger.
  • In vierter Linie sind es die Verbraucher. Auch sie haben ein Interesse daran, dass die gelieferten Produkte das sind, was sie bestellt haben, und nicht – von wem auch immer – verfälschte Waren.

Schade ist, dass sowohl Erzeuger wie Verbraucher häufig in Unkenntnis der Zusammenhänge nicht wissen, wie sie ihre Anforderungen formulieren sollen, und an wen sie sich wenden müssten.

So wird es wohl noch eine Weile dauern bis die Henne-Ei-Frage geklärt sein wird, ob eine mangelhaft formulierte Anfrage das richtige Angebot verhindert, oder vollmundige Angebote ernsthaft formulierte Forderungen unterdrücken.

Dann gibt es auch noch Verbände, wie zum Beispiel das BSI (Bundesamt für Sicherheit in der Informationstechnik) oder Bitkom (Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e. V.), die unter anderem die Interessen auch der Verbraucher vertreten sollen. Von denen sind keine Forderungen an die Hardware-Hersteller zu hören – zumindest nicht mit er gebotenen Lautstärke und dem erforderlichen Nachdruck.

Der Milchlaster in dieser Geschichte würde übrigens vom TÜV keine Plakette erhalten – aber gibt es nicht auch einen TÜV für IT-Geräte?

 

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Friedhelm Becker hat einen weiteren Beitrag im t2informatik Blog veröffentlicht:

t2informatik Blog: Defizite der Computerarchitektur

Defizite der Computerarchitektur

Friedhelm Becker
Friedhelm Becker

Friedhelm Becker wurde 1952 geboren. Er ist verheiratet und hat drei Töchter und vier Enkelkinder. Nach erfolgreichem Abschluss seines Chemie-Studiums arbeitete er drei Jahre in einem Labor für Baustoffprüfung und anschließend acht Jahre in der Bundeswehr. Er ist ein pensionierter Marineoffizier.

Nach seinem Ausscheiden aus dem Militärdienst arbeitete Herr Becker für namhafte Unternehmen in den Bereichen Rechnerbau (Univac, Sperry, UNISYS) und Luft- und Raumfahrt (Lockheed-Martin). Seit 1974 arbeitet er auf dem Gebiet der computergestützten Sensor-Effektor-Integration ohne nennenswerte Unterbrechungen. Seit 2013 ist er Inhaber der DCB Distribution & Consulting Becker.