ESE Fachwissen
Kriminelle Energie: Treibstoff für das Software Engineering
Autor: Jürgen Belz, PROMETO GmbH
Beitrag - Embedded Software Engineering Kongress 2017
Welche Randbedingungen müssen erfüllt sein, um Security sinnvoll in die Entwicklung einfließen lassen zu können? Hacker arbeiten stets team- und lösungsorientiert. Sie benötigen für ihre Arbeit Expertise, Ausrüstung und Zugänge zum System. Security-Entwickler können lediglich den Zugang so beschwerlich wie möglich machen. Das setzt aber voraus, dass Entwickler detailliert und ständig aufs Neue lernen, wie Hacker sich Zugänge verschaffen – und dies bedeutet, selbst zu hacken. Dabei beginnt ein Wettlauf gegen die Zeit, denn Bedrohungen müssen innerhalb weniger Tage ausgeschaltet werden können. Der normale Entwicklungszyklus von 1-3 Jahren greift nicht mehr.
Hacker sind nicht automatisch kriminell
Hacking wird allgemein mit digitalem Vandalismus, Erpressung, Datendiebstahl und anderen Straftaten assoziiert. Hacking ist im Wortsinn aber die Gabe, sehr ungewöhnliche und alles andere als naheliegende Lösungsansätze zu finden.
Security-Engineering-Prozesse alleine bieten keinen ausreichenden Schutz
Die Entwicklungsprozesse der meisten Unternehmen zielen auf die sog. best practices ab, also auf bewährte Konstruktionsprinzipien. Sie sind in Normen und Standards niedergeschrieben. Jeder Entwickler wählt bei der Lösung einer Aufgabe die gleichen Methoden aus einem Standard aus. Der starre, lineare Ansatz der Unternehmensprozesse ist exakt das Gegenteil von der besonderen Gabe der Hacker, alternative Anwendungsmöglichkeiten zu sehen. Daher haben Security-Engineering-Prozesse in der Praxis nicht die erhoffte Wirkung. Trotzdem sollte man nicht darauf verzichten – man sollte sich allerdings der Grenzen der Prozesse klar bewusst sein.
Das Minimum an Engineering-Prozessen
Abbildung 1 (siehe PDF) zeigt ein einfaches Beispiel eines Lasten- und Pflichtenheftsatzes, das in PTC Integrity abgebildet wurde. Oben findet sich das Lastenheft eines OEMs wieder, unten das korrespondierende Pflichtenheft mit vier Pflichten. Security-Prozesse sollten stets in die normalen Entwicklungsprozesse eingebettet und nicht nebenläufig vom Rest des Geschehens abgekoppelt werden. Security stellt auch und vor allem ein inhaltliches Element des Requirements-Engineerings dar.
Besonders Pflicht 4 – Sperren der Zugänge der internen Bereiche der ECU – löst einen Konflikt aus, denn die Ansätze von Design for Manufacturing sind vollkommen entgegengesetzt zu den Anforderungen der Security. Bei Reparaturen möchte man auf die Zustände im Inneren der ECU zugreifen. In der Security möchte man bewusst diese Zugänge dichtmachen. Meist gewinnt der, der die geringsten sichtbaren Kosten verursacht, also Design for Manufacturing und damit der Hacker.
Naivität, Arroganz, Ignoranz und Selbstüberschätzung
Viele sagen: "Design for Manufacturing ist unproblematisch, denn Hacker kommen da sowieso nicht hinein, weil sie ja nichts über die verwendeten Mechanismen wissen." Das ist naiv und zeigt ein falsches Feindbild: der Hacker, das singuläre Wesen. Diese Simplifizierung ist tückisch, denn es gibt solche Cracks so nicht. Es sind drei Hacker-Gruppen erkennbar. Zum einen sind es Forscher, die Sicherheitslücken veröffentlichen. Zum anderen nutzen manche IT-Sicherheitsunternehmen Veröffentlichungen zu Marketing-Zwecken. Die dritte Gruppe sind gewinnorientierte Unternehmen, die auch den Rand der Legalität nicht scheuen. Es liegt in deren wirtschaftlichem Interesse, Anwendern möglichst einfach zu nutzende Werkzeuge an die Hand zu geben, so kann auch ein Kleinkrimineller ohne ausreichende Sachkunde in IT diese einsetzen. Das Internet ist voll mit Anleitungen und Werkzeugen, die in wenigen Stunden für digitale Raubzüge einsatzbereit sind. Auch vernetzen sich Hacker, tauschen sich aus und arbeiten somit team- und lösungsorientiert zusammen.
Grob zwei Drittel aller Taten schreibt man Insidern zu. Die Abbildung 2 (siehe PDF) zeigt zwei unterschiedliche Statistiken. Die Summe >100% erklärt sich dadurch, dass manchmal Innen- und Außentäter zusammenarbeiten. Bei gezielten Angriffen verlassen sich die Angreifer nicht nur auf ihr technisches Können, sondern sie nutzen auch menschliche Schwächen, wie das Bedürfnis nach Anerkennung, Habgier, Sucht etc. aus. Diesen Aspekt der Cyber Security nennt man Social Engineering.
Insider verfügen grundsätzlich über die notwendige Expertise, um ein System zu hacken. Unternehmen können folglich die Expertise, die für einen Hackerangriff erforderlich ist, nicht beeinflussen, denn Experten für ein Thema lassen sich schnell über soziale Medien finden. Mit Methoden des Social Engineerings macht ein Angreifer dann deren Expertise nutzbar.
Ebenso wenig kann ein Unternehmen nicht die Ausrüstung, die für einen Hack erforderlich ist, beeinflussen – die meisten Werkzeuge lassen sich günstig beschaffen. Allerdings existieren im Bereich der Security für Embedded Systems nur wenige Werkzeuge, die sich direkt einsetzen lassen. Ein wesentliches Merkmal der Hacker ist die Fähigkeit, sich die erforderlichen Betriebsmittel selbst zu bauen.
Security bedeutet, Angriffe unwirtschaftlich zu machen
Hacker benötigen für ihre Arbeit Expertise, Ausrüstung und Zugänge. Expertise und Ausrüstung sind nicht beeinflussbar. Es bleibt einzig, den Zugang so beschwerlich wie möglich zu machen. Das setzt aber voraus, dass Entwickler detailliert und ständig aufs Neue lernen, wie Hacker sich Zugänge verschaffen. Die Analyse im Bereich Automotive in Abbildung 3 (PDF) zeigt, dass sich die zur Verfügung stehenden Ressourcen von günstig bis teuer eingruppieren lassen. Der Aufwand steht dem Nutzen gegenüber. Security ist folglich gegeben, wenn der Aufwand gegenüber dem Nutzen unwirtschaftlich wird. Das Perfide dabei ist, dass der tatsächliche Aufwand mit den Fähigkeiten der Hacker stark variiert.
Mit jeder Stufe steigen der Anspruch an die Fertigkeiten und gleichermaßen die Kosten. Ob der Aufwand sich lohnt, hängt einzig und allein vom Business-Modell der Hacker ab.
Wahre Experten findet man sporadisch
Experten aller Fachrichtungen sind in diesen Tagen rar - auch Security-Experten. Man findet sie im wahrsten Sinne des Wortes spielerisch. Wir raten Unternehmen, den Mitarbeitern eine Reihe von Herausforderungen zu stellen. Abbildung 4 (siehe PDF) zeigt z.B. einen Assembler-Code. Wer detailliert die Schwachstelle erklären kann, ist eine Runde weiter. Wer viele Runden meistert, eignet sich für eine Tätigkeit im Schwerpunkt Cyber Security.
Cyber Security ist ein Spiel
Security sollte weniger als Teil eines Entwicklungsprozesses verstanden werden, sondern als Wettkampf, den man gewinnt oder verliert. Meistens gilt: Wenn man den Gegner kennt, kann man den Kampf gewinnen – das Überraschungsmoment muss ausgenutzt werden! Hackern sollte der Zugang erschwert werden. Security ist kein Selbstzweck, sondern es braucht die kriminelle Energie der Hacker als Treibstoff. Wer im Wettkampf Hacker vs. Industrie bestehen will, muss vor allem ständig neue Angriffstechniken lernen und praktizieren.
Die Anpassung der Prozesse
Das aktuelle Wissen um Angriffstechniken leistet einen Beitrag zur Security von rund 50%. Die anderen 50% teilen sich der Security-Entwicklungsprozess sowie die Verifikations- und Validierungsmaßnahmen inkl. Reviews. Ein Blick in die IT zeigt, dass z.B. Microsoft mittlerweile über sehr gute und vor allem auch nach außen transparente Prozesse verfügt. Der grüne Anteil in Abbildung 5 (siehe PDF) zeigt den klassischen Verlauf einer Entwicklung. Das normale Vorgehen wurde um Security-Aspekte ergänzt. Entwickler müssen als Eingangsvoraussetzung ein Security-Training absolviert haben (blaue Spalte).
Eine wichtige Erkenntnis der Security lautet, dass es keine sicheren Systeme gibt. Daher braucht man einen Notfallplan, den man im Fall der Fälle ausführt. Vor allem die zeitlichen Aspekte eines Hacks werden zum Verhängnis. Anstelle der üblichen Reaktionszeit in Monaten muss ein Security-Problem innerhalb von Tagen gefixt werden. Das geht nur, wenn man einen Notfallplan aus der Schublade ziehen kann. Abbildung 5 (siehe PDF) markiert den Notfall-Prozess grün als incident response plan. Seine Erstellung muss mit der Produktfreigabe abgeschlossen sein. Deshalb findet er sich auch im Release-Prozess wieder.
Zusammenfassung
Viele Hersteller vertrauen bei den eingeleiteten Security-Maßnahmen allein auf formale Security-Prozesse, die jedoch weder effektiv noch effizient vor Hackern schützen. Dieses Handeln ist bestenfalls naiv und fahrlässig. Warum das so ist, erschließt sich schnell, wenn man Cyber Security aus dem Blickwinkel eines Hackers betrachtet.
Die Entwicklungsprozesse der meisten Unternehmen basieren auf standardisiertem Vorgehen. Der starre, lineare Ansatz der Unternehmensprozesse ist exakt das Gegenteil von der besonderen Gabe der Hacker, alternative Anwendungsmöglichkeiten zu sehen. In der Folge entfalten die Security-Engineering-Prozesse in der Praxis eine deutlich geringere Wirkung als erhofft.
Auch wenn diese Prozesse keinen besonders signifikanten Beitrag bei der Entstehung sicherer Produkte leisten, sollte man nicht darauf verzichten, sich aber klar der Grenzen der Prozesse bewusst sein. Im Kern sollte nie versucht werden, ein absolut sicheres Produkt zu entwickeln, sondern zur Produktfreigabe einen Notfallplan parat haben.
Ein Entwickler wird kein sicheres Produkt entwickeln können, solange er keine konkrete Vorstellung davon hat, was Sicherheit bedeutet. Daher lautet eine weitere Empfehlung, für alle Entwickler Security-Schulungen durchzuführen. Security sollte nicht als Teil eines Entwicklungsprozesses gesehen werden, sondern vor allem als Wettkampf zwischen Herstellern und Hackern, den man gewinnt oder verliert. Erst wenn man den Gegner kennt, kann man gegen ihn den Kampf gewinnen!
Weder Können noch Ausrüstung der Hacker lassen sich von den Herstellern beeinflussen. Was bleibt, ist den Zugang zu erschweren. Dies geht nur, wenn Entwickler detailliert und stets aufs Neue lernen, wie Hacker vorgehen. Security braucht die kriminelle Energie der Hacker als Treibstoff. Wer im Wettkampf Hacker vs. Industrie bestehen will, muss vor allem ständig neue Angriffstechniken lernen und praktizieren.
Neben dem Grundverständnis für Security bei allen Entwicklern werden eigene wenige Experten im Unternehmen gebraucht. Diese lassen sich finden, in dem man sie spielerisch herausfordert. Allerdings gelingt das nur, wenn bei diesen Personen "kriminelle Energie" vorhanden ist und sich diese auch frei entfalten kann.
Unsere Trainings & Coachings
Wollen Sie sich auf den aktuellen Stand der Technik bringen?
Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Qualität, Safety & Security.
Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.
Qualität, Safety & Security - Fachwissen
Wertvolles Fachwissen zum Thema Qualität, Safety & Security steht hier für Sie zum kostenfreien Download bereit.
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.