Im Kampf gegen Cybercrime

von Dr. Hubert B. Keller

Software ist ein Produkt mit hohem Potenzial – als Innovationsfaktor wie auch als Kostenfaktor. ­In allen technischen Bereichen wirkt Software als massiver Innovationstreiber. Gleichzeitig birgt der Einsatz ­dieser Funktionalität Kostenrisiken. Innovationssteigerungen von 35% durch Software stehen gleich­zeitig ­Kosten in gleicher Höhe – oder mehr – dagegen. Hinzu kommt seit einiger Zeit die massive Anfälligkeit im Security­bereich. Die Absicherungen gegen Cybercrime-Attacken führen zu weiteren Kosten­steigerungen. Worin liegen diese Effekte ursächlich begründet und wie sieht eine solide ingenieursmäßige Lösung der Problematik aus?

Software ist ein Produkt mit hohem Potenzial­ – als Innovationsfaktor wie auch als Kostenfaktor. In allen technischen Bereichen­ wirkt Software als massiver Innovations­treiber. Gleichzeitig birgt der Einsatz dieser Funktionalität Kostenrisiken. Innovationssteigerungen von 35% durch Software stehen gleichzeitig Kosten in gleicher­ Höhe – oder mehr – dagegen. Hinzu kommt seit einiger Zeit die massive Anfälligkeit­ im Securitybereich. Die Ab­sicherungen­ gegen Cybercrime-Attacken führen zu weiteren Kostensteigerungen. Worin liegen diese Effekte ursächlich begründet­ und wie sieht eine solide ingenieursmäßige­ Lösung der Problematik aus?

Software muss als Produkt mit entsprechend­ notwendigen Produktionsprozessen und eingesetzten Materialien auf Basis einer adäquaten­ Konzeption verstanden werden. High Level Features in Programmier­sprachen sind unnütz, wenn nicht die grundlegende mathematische Eigenschaft elementarer Objekte, z.B. eines Vektors, durch die eingesetzte Programmiersprache gesichert werden kann. Bereichsverletzungen sind das grundlegende Übel, warum­ Viren und Ähnliches überhaupt funktionieren. Gegenüber der Trennung von Daten und Anweisungen in den frühen Jahren der Informatik zur Erhöhung der Sicher­heit führt dies zu „offenen Scheunentoren“ von Software.

Produktion als Sicherheitsgarant

Die Produktion von Software erfordert eine gesicherte Vorgehensweise, einen definierten Prozess, die richtigen Methoden und Werkzeuge und auch adäquate Sprachen­ und Laufzeitsysteme zur Implementierung sowie Betriebssysteme zum Einsatz der Software. Bei automatisierungstechnischen Systemen kommen zeitliche Randbedingungen hinzu wie beispiels­weise der Führung exothermer Prozesse oder der Regelung beim ESP (elektronisches Stabilitätsprogramm).

Die Entwicklung von Software ist ein komplexer Herstellungsprozess, der weit vor einer Programmierung beginnt. Vorgehensmodelle definieren, welche Schritte wann zu erfolgen haben. „If you don’t know where you’re going, you’re unlikely to end up there.” Das Zitat aus Forrest Gump zeigt, dass wir erst einmal wissen müssen, was wir wollen.

Dies betrifft die Analysephase, die oft zu kurz und mit zu geringem Aufwand erfolgt. Das Ergebnis zeigt die HSE-Analyse von Softwarefehlern: „44% had inadequate specification as their primary cause.“ [3] Die Fehler werden in der frühen Phase injiziert und produzieren massiv späte Kosten, d.h., früher Aufwand reduziert Kosten und erhöht­ entsprechend den Gewinn [4].

Solide Basis – fester Kern

Die Schwierigkeit besteht in der Erkennung­ der Kernrequirements einer software­basierten Problemlösung, um eine solide Architektur, die Bausteine und deren gegen­seitigen Bezüge zu definieren. Dies ist Grundvoraussetzung für weitere effiziente Entwicklungen in der Zukunft. Manche­ Architekturen werden mit „Balkone an Balkone­ bauen“ charakterisiert, was nicht dem Bild eines soliden Hauses entspricht.

Nach dem Erarbeiten der Kernrequirements wird das Modell der Lösung mit seiner­ Logik in der gewählten Struktur beschrieben­, unter anderem den modellierten Abläufen. In dieser Phase müssen Anforderungen aus Security und Safety berück­sichtigt und konzeptionell vor­gesehen werden. Werden Methoden wie UML (Unified Modeling Language) zur Beschreibung eingesetzt, kann das Modell über Transformationen zur automatisierten Codeerzeugung (Programmierung) verwendet werden. Zufällige Fehler eines Programmierers oder „geniale Lösungen“ eines Einzelnen sind hier ausgeschlossen. Damit wird auch im Softwarebereich aktives Knowledge Management betrieben, da alle Kenntnis über alles haben.

Robuste Programmiersprachen einsetzen

Jede Art programmtechnischer Realisierung erfordert den Einsatz einer Programmiersprache und deren Laufzeitsystem. Hier zeigt sich die Fähigkeit einer Sprache, die modellierten Objekte in ihren Eigenschaften­ sauber umzusetzen, beispielsweise sind für numerische Berechnungen die Darstellungsgenauigkeiten explizit und unab­hängig von Betriebssystem und Rechner­architektur anzugeben. Vektoren besitzen Indexbereiche, deren Einhaltung es zu prüfen­ gilt. Die Trennung von Daten und Anweisungen, die Einführung von Basis­registern und Grenzregistern zur Absicherung der Speicherbereiche sind von der Sprache einzusetzen. Dann werden Texte als Daten und Anweisungen nicht beliebig tausch- und veränderbar. Die Welt des Cyber­crime lebt von Buffer Overflow und der Manipulation von eigentlich zu schützenden­ Programmbereichen. Die „Nationale­ Roadmap Embedded Systems“ des ZVEI fordert: „Herstellung und Aufrechterhaltung des Vertrauens in Embedded Systems sind unabdingbare Voraussetzung für die Akzeptanz von komplexen, vernetzten, eingebetteten Systemen, wie sie zur Lösung der gesellschaftlichen und ökonomischen Herausforderungen benötigt­ werden. Bisherige ­IT-Sicherheitskonzepte sind hier nützlich, aber nicht ausreichend, da sie oft auf den Aspekt Security fokussieren­.“ [5]

Softwareprogramme, die einen Zahlen­überlauf ignorieren und damit korrekte Ergebnisse­ suggerieren, sind untragbar, in sicherheitskritischen Systemen lebens­gefährlich. Auch Testen oder eine betriebsbedingte Bewährung hilft hier nicht weiter. Erstens treffen Tests nur eine Aussage hinsichtlich der getesteten Daten, zweitens ist die Betriebsbewährung nur in Routine­nutzungen vorhanden und drittens treten die Fehler meist in kritischen Situationen auf, wenn eine besondere Verlässlichkeit der Software notwendig ist. Komplexe Software mit vielen Verzweigungen kann nicht erschöpfend getestet werden. Eine Modellrechnung des SEI (Software Engineering­ Institute) für Programme mit einem bestimmten Umfang an Anweisungen und entsprechend typischer Zahl von Verzweigungen zeigt, dass für ein Softwaresystem mit 400 Verzweigungen typisch etwa 1.38 E +11 mögliche Pfade im Ablauf zu testen wären. Ein Pro­gramm­ mit 100 Mio. Programmzeilen ist damit in endlicher Zeit nicht testbar. Die Aussage „With the test-based software quality­ strategy, large-scale life-critical systems­ will be least reliable in emergen­cies – and that is when reliability is most important …” fordert also konstruktive Maßnahmen, um Zuverlässigkeit zu erreichen­ [6].

Auch die Schlussfolgerung über Reifegradmodelle, dass Software bei langem Einsatz und abnehmendem Fehlverhalten stabil und zuverlässig sei, scheitert an der unzulässigen Extrapolation über die betrachteten Einsatzprofile im Gegensatz zur klassischen­ Mechanik. Die erhöhte Durchbiegung eines Balkens bei erhöhter Be­lastung kann hochgerechnet werden, da das Kontinuumsgesetz gilt. Dies ist bei Software nicht gegeben, hier haben wir ein eher chaotisches Verhalten. Die Zuverlässigkeit von Software ist also konstruktiv zu sichern – logisch korrekt, einfach in der Struktur und nach Prinzipien erstellt, welche­ Fehler vermeiden. Robustes Verhalten­ hilft, Restfehler zu beherrschen.

Verlässliche Betriebssysteme

Rechenprozesse in Betriebssystemen werden durch Prioritäten in ihrem gegenseitigen Vorrang festgelegt. Dies setzt aber voraus, dass das Betriebssystem sich selbst in Prozessen organisiert hat und das Scheduling, also das Einplanen und Ausführen von Prozessen, nur von den zugehörigen Prozesseigenschaften abhängt. Wenn Funktionen im Kern des Betriebssystems das Scheduling unvorhersehbar verändern, können höchstpriore Echtzeitprozesse blockiert­ werden. Bei Automatisierungs­systemen kommen zeitliche Randbedingungen für die Ausführung von Funktionen hinzu. Damit ergibt sich eine weitere Komplexitätsdimension. Echtzeitanforderungen müssen den worst case mit einem beweisbaren deterministischen Verhalten beherrschen. Dazu sind mathematische Nachweise erforderlich. Interessant ist dabei, dass Multi-Core-Systeme schlechter beweisbar beziehungsweise einsetzbar sind als einfache Single-Core-Systeme. Caches als schnelle Zwischenspeicher führen in der worst case-Betrachtung zu zeitlichen Verzögerungen, welche die Beweisrechnung negativ beeinflussen. Statistische Betrachtungen dürfen hier nicht eingesetzt werden.

Schlüsseltechnologie Echtzeitsysteme

Das Thema Echtzeitsysteme ist eines der zentralen Zukunftsthemen [7]. 16 Mrd. eingebettete Systeme, also 99% aller existierenden Prozessoren, sind weltweit im Einsatz­. Embedded Systeme wie ABS (Anti-Lock Bracking) oder ESP sind Komponenten­, bei denen der Benutzer keine Eingriffsmöglichkeit besitzt und auch keine Benutzer­schnittelle mehr existiert. Wenn Signale der Lenkwinkelgeber falsch interpretiert werden und die Lenkung verhärtet oder Probleme mit dem Antiblockiersystem wegen fehlerhaften Software-Updates auftreten, sind deutlich die momentanen Grenzen aufgezeigt.

Durch Cyber Crime-Attacken tritt eine weitere­ Dimension hinzu. Die Angriffe auf sicherheitskritische Strukturen zeigen die gegenseitige Abhängigkeit von Safety- und Security-Aspekten. Ein Remote Motor Control­ per SMS über Car2Car- Kommunikation zum Bremsen und Beschleunigen fremder Fahrzeuge ist ein Hinweis auf die Problematik. Dies gilt analog auch für andere Anlagen und erfordert konzeptionell Architekturen, welche diese Aspekte berücksichtigen. Die Konsequenz wäre sonst, dass die Batterie eines Elektroautos ab Werk eine als eine durch Viren zündfähige Bombe­ zu betrachten ist. Die Entwicklungen in den Programmiersprachen wie Ada und in den Normen wie IEC 61508, die Möglichkeit der logischen Modellierung mit beispielsweise UML, sowie das Verständn­is für die Prozesse bei der Entwicklung­ von Software z.B. nach CMMI (Capability Maturity Model Integration) oder V-Modell (Vorgehens­modell), bieten die notwendigen Grundlagen­ zur Konstruktion zuverlässiger Software. Aller­dings dürfen kaufmännische Vorgaben dies nicht verhindern. Dass eine Software freigeschaltet wird und dann in 45 Minuten 440 Mill. Euro durch den falschen Kauf von 4,5 Mrd. Euro Aktien vernichtet, ist eigentlich unvorstellb­ar.

Der zentrale Fokus muss auf konstruktiven und organisatorischen Maßnahmen zur Sicher­stellung der Zuverlässigkeit liegen. Es ist eine integrative Betrachtung von Safety­ und Security Aspekten notwendig. Zur Beherrschung der Komplexität ist Wert auf eine mental beherrschbare Funktio­nalität zu legen. Intelligentes Verhalten muss vorhersagbar und verlässlich sein. Dies­ gilt insbesondere für die Kombination von komplexen Funktionen. Programmiersprachen sollten semantisch und syntaktisch vollständig definiert sein und die Umsetzung des logischen Modells in allen Eigenschaften umfassend unterstützten. Dies erfordert eine strenge Typisierung, die Prüfung auf Indexbereiche mit Ausnahmeauslösung, eine syntaktische Klammerung für lesbare Strukturen und eine Fehlerdistanz in der Grammatik, welche Einfachfehler nicht als syntaktisch korrekt einstufen kann. Schreibfehler sollten keinen syntaktisch korrekten Code ergeben, hierzu müssen mindestens zwei oder mehr Fehler auftreten [8].

Sicherheitskritische Systeme erfordern die konzeptionelle Umsetzung von Fehlertoleranzmechanismen, um einen definierten sicheren Zustand zu erreichen. Hierzu sind die Aspekte von Safety und Security von Beginn an gemeinsam zu analysieren und in das Systemkonzept zu integrieren.

Methoden zur Erhöhung der Zuverlässigkeit wie diversitäre Software können gleichzeitig für die Analyse des Verhaltens als auch für Vergleiche an Inspektionspunkten unter Security Aspekten eingesetzt werden [9].

Nach der kaufmännischen Entscheidung auf Basis einer Wirtschaftlichkeitsrechnung gilt nur noch das ingenieurgemäße Vorgehen. Kaufmännische Optimierungen in einer laufenden Entwicklung haben bis dato immer nur Geld gekostet.

Literatur

[1] Abschlussbericht DFG-Schwerpunktprogramm 1040: Entwurf und Entwurfs- methodik eingebetteter Systeme, Wolfgang Rosenstiel, Universität Tübingen, 1997 – 2003 / BMW AG
[2] F.A.S.T., TU München, 2005
[3] Health and Safety Executive: Out of Control, 2003
[4] CROSSTALK The Journal of Defense Software Engineering, December 2005, p. 16
[5] Nationale Roadmap Embedded Systems. ZVEI - Zentralverband Elektrotechnik und Elektronikindustrie e. V., Kompetenzzentrum Embedded Software & Systems, Frankfurt, Dezember 2009
[6] Watts S. Humphrey: The Software Quality Challenge. Software Eng. Institute
[7] Integrierte Technologie-Roadmap Automation 2015+. ZVEI Automation 2006
[8] Information Technology - Programming Languages – Guidance to Avoiding Vulnerabilities in Programming Languages through Language Selection and Use. ISO/IEC TR 24772 Edition 2 (TR 24772 WG 23/N 0389), ISO/IEC JTC 1/SC 22/WG 23, 2012
[9] A. Gherbi et al.: Software Diversity for Future Systems Security. CrossTalk, September/October 2011, p. 10ff

Foto: © panthermedia | Hermin Utomo