Loe raamatut: «Unbemannte Systeme und Cyber-Operationen», lehekülg 3

•Die Software konnte 2018 in einem Wettbewerb sechs andere konkurrierende Produkte in der Fähigkeit übertreffen, Sicherheitslücken in der Software auf dem eigenen Rechner und auf fremden Rechnern zu erkennen und wahlweise zu schließen bzw. zu verkleinern oder für Angriffe auf fremde Rechner auszunutzen.

•Die Software braucht keine fertigen Muster für bekannte Sicherheitslücken, sondern entdeckt neue Muster und findet eigenständig Lösungen. Sie agiert ohne aktives Eingreifen der Operateure in einer Geschwindigkeit, die für ein Team von IT-Sicherheitsexperten schlicht unmöglich ist. Sie nutzt dafür aktuell verfügbare Varianten der schon lange bewährten Methode des „Fuzzing“ zur Softwareanalyse⁵³ in Kombination mit der Fähigkeit, aus den einmal entdeckten Sicherheitslücken eigenständig weiter zu lernen.

•„Fuzzing“ ist schon seit Langem bewährt, es bereitet das gezielte manuelle Testen von Software vor durch ein fortlaufendes automatisches Konfrontieren mit Zufallsdaten, um Fehlleistungen und Abstürze zu provozieren und mögliche Sicherheitslücken deutlich schneller als in normalen Programmtestläufen aufzudecken. Der Einsatz von Software für das „Fuzzing“ ist schon lange unverzichtbar, um vernetzte Systeme gegen Angriffe sicherer zu machen. Mayhem eröffnet eine neue Dimension des Testens dadurch, dass es laufend dazulernt und das Stopfen oder Ausnutzen von Sicherheitslücken selbst übernimmt – also den IT-Sicherheitsexperten die „Handarbeit“ im Einzelfall abnimmt und damit den Vorgang exponentiell beschleunigt.

•Mayhem ist nur eines von vielen Softwareprojekten zum Schutz von IT-Infrastrukturen, als Beispiel sei noch CHASE von BAE Systems genannt.⁵⁴

16.ALPHAGO:⁵⁵ selbst lernendes neuronales Netzwerk, Software, die seit 2016 das traditionelle chinesische Strategiespiel Go⁵⁶ spielt.

•Das Spiel Go zeichnet sich durch wenige und einfache Regeln in Kombination mit komplexen Spielsituationen aus.

•AlphaGo lernt ständig dazu, mittlerweile spielt es Strategien, von denen selbst ausgewiesene Meister des Spiels bekannten, diese Varianten noch nicht gespielt zu haben und von der Software neue bis dato nicht praktizierte Taktiken gelernt zu haben.

Welche von den beispielhaft genannten Systemen sind im Sinne der UK-Definition eher der Kategorie „automatisiert“ zuzuordnen, welche eher zu „autonom“? In welche Grade der „Autonomie“ der Stufen nach IMO passen die maritimen Systeme? Welche Interaktion mit Menschen findet statt während des Agierens des Systems?

1.2.2.Einordnung in das Raster der Definitionen – „autonome Killerdrohnen“ existieren nicht

Systeme wie Patriot sind im Sinne der UK-Definition automatisiert, selbst wenn sie im vollautomatischen Modus betrieben werden, denn ihre Abläufe folgen Algorithmen und realisieren damit allein vorprogrammierte Absichten.

Nach der Industriedefinition ist der Torpedo Zaunkönig klar ein automatisiertes System. Wenn man von umgangssprachlichen Kategorien ausgeht, könnte man ihn schon als „autonom“ bezeichnen, denn er spulte sein mechanisch determiniertes Programm ohne Eingriff des Operators ab, sobald er von diesem in Marsch gesetzt war – zudem konnte der Zaunkönig nicht gestoppt werden. Aus den IMO-Definitionen wäre der Grad 4 auf den Zaunkönig anwendbar. Doch die Entscheidung über das Ob des Einsatzes liegt allein beim Menschen, der Zaunkönig ist also schon deshalb nicht autonom im Sinne der UK-Definition. In der Bindung an das vom Hersteller festgelegte Handlungsprogramm liegt eine weitere Beschränkung, die dieses und andere Systeme klar von dem Begriff der Autonomie trennen – der Zaunkönig hatte keine Auswahl unter Handlungsoptionen, er folgte einfach dem lautesten akustischen Signal.

Die fliegenden Systeme LRASM oder Harpy sind einzuordnen in die Kategorie „automatisiert“ der UK-Definition. Sie exerzieren vorprogrammierte Optionen durch – sie treffen keine eigenen Entscheidungen, auch wenn sie im Operationsgebiet unabhängig vom Operator ihre Aufgabe erledigen. Anders gewendet: Eigenständiges Operieren genügt nicht für „Autonomie“, wenn das System allein seinen mechanischen Zwängen oder Algorithmen folgt, denn es hat keinerlei Entscheidungsfreiheit, sondern realisiert programmierte Absichten im konkreten Einzelfall. Solche Systeme sind als „automatisiert“ einzuordnen.

MQ-9 wird ferngesteuert, kann aber auch automatisiert im Sinne der UK-Definition fliegen, wenn es verlangt wird oder eine Notwendigkeit besteht, etwa bei Ausfall der Funkverbindung. Dem System sind spezifische Verhaltensweisen einprogrammiert als „lost-link procedure“,⁵⁷ z.B. Aufsteigen auf größere Flughöhe, um die Funkverbindung neu zu etablieren, wenn das nicht gelingt, Rückflug zur Basis. Die einprogrammierten Verhaltensoptionen sind konform zu den internationalen Luftfahrtverkehrsregeln und sichern die Kontrolle über die Drohne nach Verbindungsausfall. Das gilt gleichermaßen für fliegende Systeme wie Airbus VSR700, Skeldar V-200, Black Hornet PRS, schwimmende Systeme wie Protector, Seagull und Seahunter sowie Landsysteme wie die vorgestellten russischen Beispiele.

Von einigen Systemen können Kampfaufträge vorprogrammiert automatisiert ausgeführt werden – sofern es sich um programmierbare Aufträge handelt, bei denen keine Adaption des Systems auf geänderte Lagebilder notwendig ist, z.B. Angriff auf nicht mobile Ziele. Die Wingfighter des FCAS ab etwa 2040 werden wegen zunehmender Komplexität und Tempo im Kampfgeschehen ihre Aufgaben noch weitgehender automatisiert erledigen müssen. Der Pilot des bemannten Kampfflugzeugs wird aber am Auslöseknopf als „Man in the Loop“ beteiligt sein oder zumindest als Kontrollinstanz „Man on the Loop“. Dies wird u.a. auch davon abhängen, wie viele unbemannte Wingfighter einem bemannten Flugzeug zugeordnet werden.

Für schwimmende Kampfsysteme wie Protector, Seagull und Seahunter ist die Einteilung der IMO nicht gemacht, sondern allein im Hinblick auf zivile Seefahrzeuge. Die drei genannten Systeme gehören in den Grad drei nach IMO, solange sie ferngesteuert werden, in den Grad vier „fully autonomous“, wenn sie ihre Arbeit aufgrund ihrer Programmierung verrichten. Diese Autonomie ist aber nicht zu verwechseln mit der für militärische Systeme definierten Autonomie, deren Kern gerade die Entscheidung über das Ob eines Einsatzes ausmacht. Der vierte Grad nach IMO deckt sich nicht mit dem Autonomiebegriff für militärische Systeme der UK-Definition. Es ist davon auszugehen, dass die IMO mit ihrer „Autonomie“ den Vollzug von vorab programmierten Aufträgen meint, da nicht anzunehmen ist, dass zivile Schiffe eigenständig entscheiden, ob sie überhaupt aktiv werden und welches Ziel sie ansteuern.

Offen ist das angestrebte und realisierbare Maß an Eigenständigkeit von in Entwicklung befindlichen tauchenden Systemen, speziell den von den USA und China projektierten UUVs mit langer Seeausdauer und komplexen Aufgaben wie Aufklärung und Bekämpfung gegnerischer U-Boote. Funkverbindungen zu tauchenden Systemen sind limitiert – Übermittlung von kurzen Befehlen ist allerdings machbar, wie sich in Kapitel 1.4.3. zeigt, etwa Zielzuweisung und Angriffsbefehl. Es läuft also auf möglichst weitgehende Automatisierung hinaus, möglicherweise auf eine Form künstlicher taktischer Intelligenz, wie sie sich bei AlphaGo zeigt.

Ist ein über Monate aktives Schadprogramm wie Stuxnet als „autonom“ anzusehen? Denn immerhin operierte Stuxnet in vom Internet abgetrennten IT-Systemen und damit ohne Eingriffsmöglichkeit seines Operators. Schon deshalb nicht, weil es vom Menschen aktiviert wurde, dabei kommt es nicht darauf an, wie viel Zeit es bis zum Zielobjekt braucht. Zudem wurden dem Schadprogramm keine Entscheidungsfreiheiten eingebaut, sondern Algorithmen, die keine Spielräume zugelassen haben – und zugleich eine „Bremse“ auf der Zeitschiene, damit eine zeitlich unbegrenzte weitere Tätigkeit von vornherein ausgeschlossen werden konnte. Genügt es für das Prädikat „autonom“, wenn es für das System keine Abschaltfunktion gibt, keine Option, durch Eingriff des Operators die Mission abzubrechen? Ganz klar nein, wenn das System einer starren Programmierung folgt und keine Ausbruchsoption aus dem vorprogrammierten Rahmen hat.

Im Saldo ist festzustellen, dass keines der oben untersuchten Systeme ein „autonomes“ System im oben definierten Sinne ist, das ohne Eingriff eines Menschen unter Verständnis von „higher level intent“, also unter Einbeziehung komplexer Situationen und Absichten der Akteure, eigenständig situationsangepasste Aktionen planen und durchführen kann. Möglicherweise befindet sich die technische Entwicklung aber auf dem Weg zu echter technischer Autonomie durch künstliche Intelligenz (KI), neuronale Netzwerke (NN) oder maschinelles Lernen (ML).

Mayhem kann man eine gewisse Entscheidungsfreiheit in dem engen Rahmen seiner Tätigkeiten attestieren, insbesondere weil menschliche Kontrolle angesichts des Tempos und der Fülle an einzelnen Arbeitsvorgängen des Systems nicht mehr möglich ist. Aber echte Entscheidungsfreiheit auf Basis des Verständnisses von „higher level intent“ ist bei Mayhem nicht gegeben.

Lediglich AlphaGo kommt in die Nähe des oben definierten Begriffs technischer Autonomie, denn es lernt eigenständig dazu und erfindet kreativ neue taktische Varianten, die so noch kein Mensch vorher gespielt hat. Das System hat Entscheidungsfreiheit für Spielzüge und deren Abfolgen, also hat es begrenzte Autonomie auf dem schmalen Pfad eines einzelnen Spiels. Derartige Softwareprodukte könnten insbesondere durch ihre Lernfähigkeit in Bezug auf komplexe Situationen, Entscheidungsprozesse und anzuwendende Regeln erstmals echte Autonomie für militärische Systeme ermöglichen. Allerdings: Die Fülle der Regeln von Politik, Strategie, Taktik, Recht und Ethik und deren Unschärfe sowie die Menge der Ausnahmen stellen eine gänzlich andere Herausforderung an ein solches System dar als ein Brettspiel. Voraussetzung für solch ein „autonomes“ System, das in der komplexen Welt von Politik, Militär und Konflikt agieren soll, wäre eine exponentiell gesteigerte Verarbeitungskapazität der Rechnerhardware, eine unglaublich komplexe Programmierungsleistung sowie eine enorme Lernfähigkeit des Systems, die auch voraussetzen müssten, grundlegende Werte und Maßstäbe und deren Hierarchien auf der Metaebene immer wieder neu zu bewerten.

Warum soll „Entscheidungsfreiheit“ über Ob, Was und Wie letztlich Maßstab für die Schwelle zur „Autonomie“ sein, obwohl aktuell offensichtlich noch nicht erfüllbar? Keines der oben aufgeführten Systeme entscheidet über das Ob, Was und Wie eines Einsatzes, die Operatoren definieren das konkrete Einsatzziel, und die Programmierung determiniert das Vorgehen. Ein „autonomes“ System im Sinne der UK-Definition ist gerade nicht festgelegt auf die Realisierung programmierter Absichten, sondern bekommt abstrakte Entscheidungsgrundlagen und Handlungsmuster einprogrammiert, aus denen es für konkrete Situationen eigene Lösungen entwickeln kann. Aber möglicherweise haben schon in einigen Jahren oder Jahrzehnten Systeme deutlich erweiterte Aktionsoptionen und Entscheidungsfreiheiten über das Ob, Was und Wie einer Aktivität. Es kommt dabei nicht darauf an, ob sich Menschen die Entscheidungen über Ob, Was und Wie im Einzelfall tatsächlich vorbehalten werden. Die Definitionen müssen eine Abgrenzung autonomer Systeme von automatisierten Systemen zulassen, wenn sie über den heutigen Tag hinaus brauchbar sein sollen.

„Autonome Killerdrohnen“ existieren nicht. Es erweist sich, dass die in der Einleitung zitierten Wahrnehmungen und die aktuellen technologischen Realitäten, insbesondere unter dem Aspekt der Einbindung von Soldaten in die Arbeitsgänge von Systemen, weit voneinander entfernt sind. Keines der beispielhaft vorgestellten Systeme kommt auch nur in die Nähe einer eigenständigen Entscheidung über die Anwendung letaler Gewalt. Das Verdikt gilt ebenfalls für alle weiteren derzeit weltweit existierenden Systeme.

1.3.Automatisierte und virtuelle Systeme: Pleiten, Pech und Pannen

Systeme realisieren zuverlässig ihre programmierten Abläufe. Die Programmierung aller Systeme hängt vom Können des Menschen ab, bei automatisierten Systemen kommt das Zusammenwirken von System und Mensch im Einsatz als Fehlerquelle hinzu. Einige der vorausgehend aufgelisteten Systeme sind noch im Status von Technikdemonstratoren – und noch lange entfernt von der für die militärische Nutzung erforderliche Zuverlässigkeit. Hinzu kommt das Problem der Fehlleistungen komplex programmierter Systeme. Einige Beispiele für Fehlleistungen von und mit automatisierten Systemen aus der Auflistung in Kapitel 1.2.:

1.PATRIOT im Zweiten Golfkrieg 2003 und Abschuss von Flugzeugen der Koalitionsstreitkräfte:⁵⁸

•Durch dieses System wurden auch Kampfflugzeuge der gegen den Irak vorgehenden Koalitionsmächte abgeschossen (Patriot Fratricides).

•Die Untersuchungen offenbarten nicht nur mangelnde Information der Soldaten der Patriot-Batterien über Flugbewegungen der Koalitionsstreitkräfte. Zudem zeigte sich ein im Ergebnis fatales Vertrauen des Bedienpersonals in die vollautomatischen Abläufe, obwohl die angezeigten Bewegungen Zweifel erweckten. Die Soldaten hätten in den dokumentierten Fällen die Funktion ihres Systems stoppen und die Abschüsse verhindern können. Im Zweifel haben sie sich nachvollziehbar für die Sicherheit der eigenen Truppen am Boden und für den Abschuss entschieden.

•Für die Programmierung des Systems, die Gestaltung des Human Machine Interface, die Ausbildung des Bedienpersonals und dessen Information über Flugbewegungen eigener Einheiten wurden umfänglich Lehren gezogen.

•Die Reaktionszeiten für Eingriffe in den Ablauf des Systems sind indes gerade bei der Flugkörperabwehr extrem knapp. Neue Waffensysteme, insbesondere Hyperschallwaffen, werden zu weiterer Verkürzung der Entscheidungsspielräume beitragen.

2.AEGIS COMBAT SYSTEM, USS Vincennes und Iran Air Flug 655 (1988):⁵⁹

•Ende der 80er-Jahre herrschte ein nicht erklärter Konflikt zwischen dem Iran und den USA. Im Mai 1987 wurde die Fregatte USS Stark durch zwei von einer iranischen F-14 in Marsch gesetzte Seezielflugkörper schwer beschädigt, 37 Besatzungsmitglieder kamen dabei zu Tode.

•Am 3. Juli 1988 befand sich der mit Aegis ausgestattete Kreuzer USS Vincennes im Persischen Golf mitten in einem Scharmützel mit iranischen Schnellbooten, während die Radaranlagen zeitgleich Flugzeugstarts ausgehend von Bandar Abbas anzeigten. Dort befinden sich ein ziviler Flughafen und eine Luftwaffenbasis in unmittelbarer Nähe.

•Aufgestiegen von Bandar Abbas war u.a. ein Airbus mit 290 Passagieren mit Flugziel Dubai. Zeitgleich registrierte die USS Vincennes ein Signal, das als von einer iranischen F-14 stammend angesehen wurde, und detektierte ein iranisches Aufklärungsflugzeug vom Typ P3. Die Soldaten an den Bildschirmen ordneten das Echo des Airbus, der mittlerweile Kurs auf den aktuellen Standort der USS Vincennes genommen hatte als Kampfflugzeug ein. Die automatische Abfrage der Freund-Feind-Kennung brachte kein Ergebnis, da aber durchaus Zweifel bestanden, wurde das Flugzeug gezielt angefragt und nachfolgend mehrfach gewarnt – ohne jede Reaktion.

•Das Lagebild ließ in den wenigen Augenblicken, die dem Kommandanten für eine Entscheidung über den Abschuss blieben, keinen anderen Schluss zu, als dass ein Angriff mit Seezielflugkörpern bevorstand, ausgehend von dem Airbus, den seine Soldaten als Kampfflugzeug wahrnahmen.

•Im Untersuchungsbericht wurden neben den Aspekten des Lagebildes auch der Datenoutput des Aegis-Systems und Kommunikationsflüsse an Bord der USS Vincennes untersucht. Aegis selbst hatte isoliert betrachtet keine Fehler gemacht. Das Problem entstand im Zusammenwirken von Mensch und Maschine, durch die Interpretation und Einordnung der Informationen durch die Soldatin der Leitstelle. Der Untersuchungsbericht kam zu dem Schluss, dass Aegis bei vollautomatischer Funktion den Abschuss möglicherweise nicht autorisiert hätte.

3.FLASH CRASH, New York Stock Exchange, 6. Mai 2010:⁶⁰

•Mit automatisierten Handelsprogrammen platzieren Börsenhändler Handelswerte zum Kauf – normalerweise. Der mikrosekundenschnelle Börsenhandel öffnete seinerzeit die Tore zur digitalen Manipulation. Die Masche nannte sich Spoofing, die scheinbare Platzierung von Handelswerten für Millisekunden, um andere Börsenteilnehmer ebenfalls zur Platzierung zu provozieren. Den darauffolgenden Kursrückgang nutzte der Spoofer aus – um die Handelswerte nach Normalisierung gewinnbringend zu verkaufen.

•Die Masche des Londoner Händlers Navinder Singh Sarao ging mehrfach gut ohne Auffälligkeiten an den Börsen. Doch am 6. Mai 2010 löste der minutenschnelle Absturz etlicher Hundert Handelswerte einen Handelsstopp aus. Die Ursachen konnten erst in jahrelangen Untersuchungen und nur bedingt geklärt werden.

•Im Kern hat eine nicht legale Variante des in Sekundenbruchteilen durch Algorithmen exerzierten Anbietens und Zurückziehens von Kaufgelegenheiten Kurse nach unten getrieben. Am 6. Mai 2010 einmalig jedoch nicht nur für kurze Zeit, sondern ungewollt fortgesetzt und sehr nachhaltig. Ursache für diese außergewöhnliche Entwicklung war die Interaktion von Saraos Programm mit den Programmen anderer Händler, die Fehler aufwiesen. Zudem herrschte an der Börse erhöhte Nervosität, weil es in Griechenland zu Protesten gegen die Regierung gekommen war.

•Die beteiligten Softwareprogramme haben sich in Mikrosekunden sozusagen duelliert – menschliches Eingreifen in die einzelnen Vorgänge war unmöglich, es half nur noch die Notbremse des automatischen Handelsstopps, bis dahin waren dennoch unvermeidlich Verluste bei etlichen am Börsenhandel Beteiligten zu verbuchen.

4.KNIGHTMARE ON WALL STREET, 1. August 2012:⁶¹

–Das bis dahin erfolgreiche und kapitalstarke Unternehmen Knight Capital ruinierte sich innerhalb von wenigen Minuten komplett mittels einer von ihm eingesetzten neuen und fehlerhaften Handelssoftware.

•Die Software bot in Mikrosekunden nicht nur bereits gehandelte Posten in großer Zahl neu an, sondern kaufte Handelswerte teurer ein, als sie sie verkaufte. Als Menschen reagierten, war es zu spät. Die Verluste von Knight Capital summierten sich auf über 400 Millionen US-Dollar.

Algorithmen stellen hohe Ansprüche an die sachlich „richtige“ Programmierung unter Einbeziehung jeder denkbaren Situation, auf die das System reagieren können muss. Eigentlich erforderlich ist das Testen nicht nur einer Software allein, sondern auch im Zusammenwirken voneinander unabhängig tätiger Programme, wie sich am Flash Crash deutlich zeigt. Das ist jedoch bei Börsensoftware schon wegen des berechtigten Interesses an der Wahrung von Geschäftsgeheimnissen nicht durchsetzbar. Die längst an allen Börsen eingerichtete, schnell reagierende, automatische Notbremse stellt in diesem Umfeld eine ausreichende Sicherung dar, auch wenn sie nicht alle Risiken ausschließen kann. Beim Anleger bleibt das ungute Gefühl, dass man nicht mehr allein abhängig ist von Fähigkeit und Redlichkeit des Börsenhändlers, dem man seine Orders anvertraut, sondern zusätzlichen Gefahren ausgesetzt ist durch potenzielle Softwarefehler oder unglückliche Interaktionen verschiedener Softwareprodukte.

Bei militärischen Anwendungen liegt es in der Natur der Sache, dass eine sorgfältige Vorbereitung der Interaktion der eigenen Systeme geboten ist. Hohe Ansprüche an die Hardware und an die Software sind ohnehin zu stellen im Hinblick auf den Kampf gegen schwer berechenbare Gegner unter Einbeziehung der militärischen Kunst des Tarnens, Tricksens und Täuschens. Vor diesem Hintergrund ist an Einsatz von künstlicher Intelligenz im militärischen Bereich nur unter der Kautel der Aufsicht („Man on the Loop“) denkbar. Kreativität und Fehlbarkeit machen einen gänzlich autonomen Gebrauch („Man out of the Loop“) aktuell und für absehbare Zeit nur eingeschränkt möglich.

In allen Bereichen des Einsatzes von Informationstechnologie entscheidet die Kommunikation von Mensch und Maschine wesentlich darüber, ob die Ergebnisse der Arbeit der Algorithmen im Einzelfall das gewünschte und richtige Ergebnis herbeiführen (können), wie die oben gezeigten Erfahrungen insbesondere mit Patriot und Aegis zeigen.