5 Fragen an…Andreas Zeller
Jede Software der Welt gegen Cyberangriffe schützen
Einen Roboter bauen, der jedes Softwaresystem testen, Fehler beheben und sicherer machen kann, das ist die Vision von Andreas Zeller. Für seine herausragende Forschung erhielt er einen ERC Advanced Grant über 2,5 Millionen Euro - zum zweiten Mal, was kaum ein Wissenschaftler schafft. Wie er das möglich machte, erzählt er uns im Interview.
Herr Zeller, Sie sind einer der ganz wenigen Forscher, die zum zweiten Mal Europas höchste Forschungsförderung erhalten haben: den ERC Advanced Grant über 2,5 Millionen Euro. Wie haben Sie das geschafft?
Mit viel Vorbereitung, Geduld und starken Nerven. Zunächst gab es einen großen „Haken“: Bereits im Jahr 2011 habe ich einen ERC Advanced Grant erhalten. Bei der ersten Bewerbung wird das Gremium denken, dass man die Förderung verdient hat als ambitionierter Forscher. Möchte man diesen Preis aber erneut bekommen, ist man frech. Die Gunst der Panel-Mitglieder, die über die ERC Grants entscheiden, hat man sozusagen verspielt.
Für die zweite Bewerbung muss man in meiner Vorstellung zwei Dinge beachten: Man braucht eine richtig gute Idee, die sofort überzeugt und man darf sich keine Schwäche erlauben. So habe ich mir das jedenfalls vorgestellt. Ob das wirklich so ist, weiß ich nicht. Laut den Richtlinien muss das Panel unabhängig entscheiden und darf die Vorgeschichte des Forschers oder der Forscherin nicht miteinfließen lassen. Für mich war klar, dass ich auf jeder Ebene einen völlig makellosen Eindruck hinterlassen muss. Das war anstrengend.
Den Antrag, den ich für die Bewerbung verfassen musste, haben sicher 30 Leute gegengelesen. Beim Schreiben musste ich bedenken, sowohl die Experten meines Fachs anzusprechen als auch die fachfremden Panel-Mitglieder. Denn gemeinsam müssen sie über ein Preisgeld von zweieinhalb Millionen Euro entscheiden – also möchten sie auch verstehen, worum es geht. Das war eine Herausforderung. Weiteres Feedback erhielt ich vom Bundesministerium für Bildung und Forschung, das die Gruppe „Nationale Kontaktstelle Europäischer Forschungsrat“ eingerichtet hat. Diese offizielle Stelle schaut sich die Anträge im Vorfeld an und beurteilt sie.
Nachdem ich die Bewerbung abgeschickt hatte, erhielt ich vom Europäischen Forschungsrat (ERC) eine Einladung für ein Zoom-Interview. Zehn Minuten hatte ich Zeit, den Antrag vor dem Gremium vorzustellen. Anschließend folgte eine Frage-Antwort-Sitzung über 20 Minuten. Die Präsentation und die Frage-Antwort-Runde habe ich etliche Male geprobt. Das war schon exzessiv. Immer, wenn ein Kollege zu mir ins Büro kam, hieß es: „Hast du mal 10 Minuten?“ Dann hat das Helmholtz Zentrum eine Probesitzung arrangiert mit zwei früheren Panel-Membern des ERC, Kollegen von mir, die sich meinen Vortrag anhörten und mich nach allen Regeln der Kunst auseinandergenommen haben. Klar, sie werden angeleitet, möglichst kritische Fragen zu stellen. Aber denen konnte ich gut entgegnen. An einer Veranstaltung des Bundesministeriums für Bildung und Forschung habe ich auch noch teilgenommen. Vier Kollegen saßen in der Runde, die ebenfalls für Interviews eingeladen waren. Wir haben uns gegenseitig unsere Vorträge gehalten. Ein professioneller Coach war dabei, und hat wichtige Tipps gegeben, zum Beispiel, wie lang meine Sätze sein dürfen.
Offensichtlich haben Sie alles richtig gemacht. Können Sie erklären, worum es in Ihrem eingereichten Projekt geht?
Mal angenommen, Sie möchten wissen, ob eine Software funktioniert. Dafür muss sie getestet werden – und zwar von Menschen, die das manuell tun. Der Haken ist, dass man händisch zwar prüfen kann, ob das Ganze für den Standardfall läuft, aber nicht, ob es auch in Sonderfällen funktioniert. Hinzukommt: Jedes Mal, wenn man die Software ändert, muss man erneut testen. Das alles zu prüfen ist sehr viel Arbeit, kostenintensiv und wird häufig nicht gemacht. Sobald man die Software ans Internet anschließt, und sie öffentlich zugänglich ist, ist sie nicht sicher. Möglicherweise schafft es zum Beispiel jemand, Informationen aus der Datenbank zu hacken.
Mein Vorschlag, den ich in meinem Antrag ausführe, ist der: Ich möchte das Testen von Software vollständig automatisieren, indem ich einen Roboter baue, der in der Lage ist, alle möglichen Variationen von Eingaben zu erzeugen – auch während die Software läuft. Wenn die Software etwas Falsches tut, soll der Roboter automatisch diagnostizieren können, warum etwas schiefgegangen ist. Diese drei Sorten von Werkzeugen, also eines zum Testen, zum Überprüfen im laufenden Betrieb und für die Fehlersuche, sind Programme, die auf dem Rechner mitlaufen.
Die Grundlage für solche Werkzeuge ist die Spezifikationssprache mit Namen S3, die mein Team und ich entwickeln. Eine Sprache ist aus informatischer Sicht eine Beschreibung, wie eine korrekte Programmeingabe aussieht. Entwickler können damit Grammatiken und Rechtschreibregeln spezifizieren. Wir möchten genau diese Regeln, die ausdrücken, was eine gültige Ein- und Ausgabe ist, für jedes Programm lernen können. Das wollen wir wiederum nutzen, um das Programm mit allen möglichen Ein- und Ausgaben automatisch zu prüfen. So können wir eine riesige Bandbreite von Software sehr viel umfassender auf ihre Funktion testen als das jemals der Fall war – und zwar immer wieder aufs Neue. Nach Möglichkeit bevor die bösen Buben da draußen anfangen, die Software auf ihre Art und Weise zu „testen“.
Gibt es außer dem Thema Sicherheit noch weitere Punkte, die Sie mit Ihrer Idee abdecken können?
Das ganz große Thema ist die Verlässlichkeit von Software und die Frage, wie man systematisch überprüfen kann, ob eine Software das Richtige tut oder nicht. Mit unserem Verfahren können wir zum ersten Mal einen Weg aufzeigen, wie wir in Zukunft Software bauen, die vollautomatisch und sehr umfassend geprüft wird – nicht zu 100 % perfekt, aber zu 99 %. Damit ist schon sehr viel gewonnen. Die umfassende Testung sorgt für eine größere Verlässlichkeit und indirekt für eine höhere Sicherheit, weil es die Software gegen Angriffe schützt. Ein Nebeneffekt unserer Arbeit ist, dass wir auch herausfinden, unter welchen Bedingungen eine Software das Falsche tut. Wir können analysieren, welche Teile einer Programmeingabe für Fehler verantwortlich sind und Programmierern wie Anwendern Hinweise zur Fehlervermeidung liefern. Und sogar Eingaben frühzeitig abfangen, von denen wir vorhersagen können, dass sie zu Problemen führen werden. Dieses Vorgehen wird längerfristig zu Korrekturen und Verbesserungen von Software führen.
Haben Sie schon eine Vorstellung, wo S3 als Erstes zum Einsatz kommen könnte?
Wir werden S3 für eine Vielzahl von Open-Source-Software einsetzen, weil sie besonders anfällig ist für Angriffe aus dem Internet. Mein Team und ich wollen aber auch in kritische Infrastrukturen vordringen und sie auf Herz und Nieren prüfen. Ein großer Bereich ist die öffentliche Verwaltung. Dort werden viele sensible Daten ausgetauscht und diese Systeme sind unserer Kenntnis nach nicht in dem Maße getestet worden, wie man es tun sollte. Der Großteil dieser Verwaltungssoftware arbeitet in geschützten Netzen, die von außen nicht direkt zugänglich sind. Es ist aber so, dass mit fortschreitender Digitalisierung diese Systeme mehr und mehr dem Internet ausgesetzt sind, immer mehr Dienste nach außen getragen werden. Das ist ein großes Sicherheitsrisiko. Diese bestehende Software würden wir testen und nach Möglichkeit verbessern.
Wenn Sie in die Zukunft schauen könnten: Was wäre das Best-Case-Szenario für Ihre Forschung?
Für mein Team und mich wünsche ich mir, dass möglichst vielen Firmen unsere Arbeiten aufgreifen, um ihre eigene Software zu verbessern. Und auch, um noch smartere Werkzeuge zu bauen fürs Testen, die Fehlersuche und Prüfung von Software. Stellen Sie sich vor, was passiert, wenn eine Firma wie Microsoft oder SAP unsere Techniken übernehmen und in ihre Produkte einbauen. Dann kann ich meiner Mutter eines Tages erzählen: Guck mal, mein Algorithmus läuft auf hunderten Millionen Rechnern jeden Tag. Dann ist sie stolz.
Leser:innenkommentare