Autor: Dr. Thomas Liedtke, ICS AG Der steigende Anteil an Software-realisierter Anforderungen f\u00fchrt zu einer immer gr\u00f6\u00dfer werdenden Anzahl von Verwundbarkeiten und m\u00f6glichen Angriffsvektoren, um Schwachstellen auszunutzen. Safety-Risiken werden h\u00e4ufig durch deduktive (ofmtals mathematische) Ans\u00e4tze unter Anwendung bew\u00e4hrter Methoden und Wahrscheinlichkeiten bestimmt. Sehr unwahrscheinliche und damit in ihrer Auswirkung kaum einsch\u00e4tzbare Risiken k\u00f6nnen aufgrund ihrer geringen Auftretenswahrscheinlichkeit vernachl\u00e4ssigt werden. „Nur“ mit aller Vernunft vorstellbare Ursachen m\u00fcssen in Risikoanalysen betrachtet werden. Im schlimmsten Fall wird versucht, einen als Fail-Safe definierten Zustand einzunehmen.<\/strong><\/p>\n Bei der Betrachtung von Security-Risiken geh\u00f6ren auch sehr unwahrscheinliche Bedrohungen und kompexe Verwundbarkeiten zu potentiellen Gef\u00e4hrdungen. Durch den Interessenkonflikt bei Angriffen m\u00fcssen zur Risikoanalyse insbesondere auch induktive und zuf\u00e4llige Szenarien durchdacht werden. Dazu kommen m\u00f6gliche Sicherheitsl\u00fccken durch emergente Systemeigenschaften. Antifragilit\u00e4t wird zur notwendigen Eigenschfat, um vorbereitet zu sein.<\/strong><\/p>\n „Es kommt nicht darauf an, die Zukunft vorauszusagen, sondern auf die Zukunft vorbereitet zu sein.“<\/em>\u00a0Perikles (490 – 429 v. Chr.)<\/p>\n Der Begriff der Sicherheit ist in der deutschen Sprache mehrdeutig belegt:<\/p>\n Sowohl die Komplexit\u00e4t der Anforderungen an technische Systeme (z.B. Dezentralisierung von Steuerungen, unterschiedlichste zu unterst\u00fctzende Endger\u00e4te und Bedienungskonzepte, immer intelligenter werdende Aktoren und Sensoren, erh\u00f6hte Anzahl von Schnittstellen, immer raffiniertere Services) als auch die Komplexit\u00e4t der Entwicklungsprozesse (wechselnde Infrastrukturen, unterschiedlichste zu unterst\u00fctzende Standards) steigen rasant.<\/p>\n War die Systemarchitektur bislang eher einfach, im Sinne von einer zentralen Steuerung, die von einer unabh\u00e4ngigen Kontrolleinheit \u00fcberwacht wurde [IEC61508], sind Komponenten eines modernen Systems selbst f\u00fcr Sicherheit zust\u00e4ndig (z.B. Fahrerassistenzsysteme im Automobil) [ISO26262]. Hinzu kommt, dass sich Produkte offen und dynamisch zur Betriebszeit selbst konfigurieren k\u00f6nnen m\u00fcssen und nicht mehr nur geschlossen statisch sind (Stichworte Industrie 4.0, Losgr\u00f6\u00dfe 1).<\/p>\n Safety ist definiert als der Schutz vor (unbeabsichtigter) Fehlfunktion (bei bestimmungsgem\u00e4\u00dfer Verwendung) und der Abwesenheit von unzumutbaren Risiken. Die realisierte Ist-Funktionalit\u00e4t entspricht der spezifizierten Soll-Funktionalit\u00e4t.<\/p>\n Bei der Entwicklung sicherheitsgerichteter Systeme werden in den azuwendenden Normen bew\u00e4hrte Vorgehenswesien gefordert:<\/p>\n Vorgehensweisen und Methoden im Safety-Prozess sind h\u00e4ufig Top-Down-orientiert, mathematisch und mit viel Disziplin und Flei\u00df durchzuf\u00fchren. Aus fragilen Systemen sollen robuste werden, die bei entsprechenden Geschehnissen das System notfalls in einen sicheren Zustand f\u00fchren.<\/p>\n Security ist definiert als der Schutz vor (absichtlichen) Angriffen (und Zuf\u00e4llen\/Ungl\u00fccken). Security bedeutet die funktionale Korrektheit bei aktiven Attacken.<\/p>\n Sp\u00e4testens seit Stuxnet [Stuxnet] gibt es in der Security-Welt eine Zeitenwende. Die gro\u00dfe Motivation, die Breite des Angriffs, die hohe Komplexit\u00e4t und der enorme Aufwand waren vorher so nie da gewesen. Auch dass man derart tief in vermeintlich propriet\u00e4re Systeme eingreifen kann, war vorher nicht erwartet worden.<\/p>\n Security-Risiken k\u00f6nnen reduziert, vermieden (System wird so umstrukturiert, dass die Gef\u00e4hrdung wegf\u00e4llt), \u00fcbernommen (akzeptiert) oder delegiert werden. Im Unterschied zu Safety gibt es bei Security zun\u00e4chst keinen definierten sicheren Zustand. Ein sicheres System soll stets am Laufen gehalten werden, ein Denial of Service unter allen Umst\u00e4nden vermiden werden.<\/p>\n Nachdem f\u00fcr Safety das Schutzziel immer Leib und Leben ist, m\u00fcssen f\u00fcr Security System-abh\u00e4ngig Schutzziele definiert werden. Je nach Schutzziel sind unterschiedliche Design-Prinzipien (wie z.B. „Sichtbarkeit und Transparenz“) und Design-Strategien (wie z.B. „Datensparsamkeit“) anzuwenden.<\/p>\n Durch den (bei Safety fehlenden) Interessenskonflikt zwischen Angreifer und Betreibern sind bei der Security-Risiko- und Bedrohungsanalyse eine ganze Reihe zus\u00e4tzlicher Themen abzusichern. So sind z.B. Implementierungsangriffe, Seitenkanalangriffe (Re-Engineering) viel st\u00e4rker zu ber\u00fccksichtigen. Security-Angriffe haben au\u00dferdem h\u00e4ufig die Eigenschaft, mit gro\u00dfem Einsatz an Ressourcen aus der Ferne gef\u00fchrt zu werden (z.B. Industriespionage). Kommunikationskan\u00e4le und Schnittstellen des Systems nach au\u00dfen stellen besonders gef\u00e4hrdete Sicherheitsl\u00fccken dar.<\/p>\n Bei der Entwicklung sicherheitsgerichteter Systeme mit Safety- und Security-Anforderungen muss zwischen orthogonalen Zielwerten priorisiert werden [LiHo16]. Privacy (Datenschutz) und KRITIS (Sicherung kritischer Infrastrukturen) k\u00f6nnen als weitere Dimensionen gesehen werden (s. Bild 1,\u00a0PDF<\/a>).<\/p>\n Von der Methodik her gibt es \u00e4hnliche Vorgehensweisen, so dass auch Security als paralleler Managementprozess zur Entwicklung verstanden wird. Das „Verweben“ mit Safety ist Thema vieler aktueller Berichte (s. z.B. [GGH+15]).<\/p>\n Bei der traditionellen Gefahren- und Risikoanalyse geht man von einer identifizierten Gefahr aus, um zur Auswirkung und Eintrittswahrscheinlichkeit zu gelangen (z.B. [Sto09]). Entsprechende Risikoakzeptanzkriterien bestimmen die weiteren Ma\u00dfnahmen in der Entwicklung. Im n\u00e4chsten Kapitel wird aufgezeigt, dass f\u00fcr Security ein anderer Weg eingeschlagen werden muss.<\/p>\n Die Norm IEC62443 [IEC62443-3] gibt zur Risikobetrachtung eines Systems zun\u00e4chst eine Top-Down-Zerlegung vor. Das System wird dazu in Komponenten (Zonen) und Kan\u00e4le (Conduits) zerlegt. Die Komponenten und Kan\u00e4le werden dann einzeln f\u00fcr sich analysiert.<\/p>\n Emergente Eigenschaften komplexer Systeme erfordern das Umgehen mit unbekannten Systemeigenschaften. Systeme m\u00fcssen mehr als robust ausgelegt werden: Sie m\u00fcssen antifragil [Tal14] sein.<\/p>\n Antifragilit\u00e4t wird als das Gegenteil von Fragilit\u00e4t definiert. Dazwischen wird im Sinne einer Triade der Begriff Robustheit eingeordnet. M\u00f6gliche Charakteristika sind in Tabelle 1 (siehe\u00a0PDF<\/a>) angegeben.<\/p>\n Eine Reihe von Beispielen zeigt, wie vorteilhaft sich der Gedanke an Antifragilit\u00e4t auswirken kann und wie w\u00fcnschenswert diese Eigenschaft f\u00fcr sichere (Security-) Systeme ist. Antifragilit\u00e4t ist mehr als das H\u00e4rten von Systemen, es ist die \u00dcberkompensation und das „fit“ machen, um f\u00fcr zuk\u00fcnftige Anforderungen (Angriffe) gewappnet zu sein. Nicht alle durch Emergenz entstehende Sicherheitsl\u00fccken sind zur Entwicklungszeit bekannt. Sie werden (u.U. durch Trial und Error) erst im Laufe der Zeit „gefunden“. Das bedeutet, dass Systeme mit Security-Vorkehrungen st\u00e4ndig aktualisiert und geh\u00e4rtet werden m\u00fcssen.<\/p>\n Bei der Betrachtung von Security-Analysen sind u.a. folgende Trugschl\u00fcsse zu vermeiden:<\/p>\n Im Gegensatz zur Fragilit\u00e4t ist Antifragilit\u00e4t nicht messbar. Die Anf\u00e4lligkeit eines Porzellantellers gegen\u00fcber einem Plastikteller, die Gesundheit eines alten Menschen gegen\u00fcber eines jungen k\u00f6nnen bewertet werden. Wie gut ein System gegen Zuf\u00e4lle und seltene (bislang unbekannte) Ereignisse gesch\u00fctzt ist, ist wesentlich schwieriger zu bewerten.<\/p>\n Nachdem man mit sch\u00e4dlichen Folgen besser umgehen kann als mit der Vorhersage seltener Ereignisse, m\u00fcssen Vorhersagen und Risikomanagement auf den Kopf gestellt werden.<\/p>\n Ein m\u00f6gliches Beispiel f\u00fcr eine Risikoanalyse aus dem Bereich Transportation wird in Bild 2 (siehe\u00a0PDF<\/a>) aufgezeigt.<\/p>\n Im letzten Schritt wird eine detaillierte Risikoanalyse gegen potentielle bereits bekannte Bedrohungen durchgef\u00fchrt. Dabei spielen verwendete Quellen f\u00fcr Schwachstellen, Verwundbarkeiten und bekannte Angriffe eine wichtige Rolle.<\/p>\n Dem Zufall und Trial und Error von Angriffen k\u00f6nnen auf Dauer nur antifragile Systeme standhalten. Eine Reihe von m\u00f6glichen Betrachtungen\/ \u00dcberlegungen zur Emergenz aus Security-Sicht umfassen damit z.B.<\/p>\n Bew\u00e4hrte Safety-Betrachtungen und -Methoden sind nicht ausreichend, um auch Security zu garantieren. Die Komponenten Absicht, Interessenkonflikt, Zufall, Trial und Error sowie hohe Motivation von Angreifern m\u00fcssen sehr viel st\u00e4rker ins Kalk\u00fcl gezogen werden als bei reinen Gefahrenanalysen f\u00fcr Safety.<\/p>\n Um auf die Zukunft vorbereitet zu sein, sind starre Grenzen (z.B. Virenscanner auf PCs) nicht ausreichend. Dynamische Abwehrstrategien, die sich st\u00e4ndig erneuern und aktualisieren, m\u00fcssen implementiert werden.<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Qualit\u00e4t, Safety & Security steht\u00a0hier\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\n
\n<\/strong><\/p>\nBeitrag – Embedded Software Engineering Kongress 2016<\/h3>\n
\n<\/strong><\/p>\nEinleitung
\n<\/strong><\/h2>\n\n
\n
Safety vs. Security<\/h2>\n
\n
Zielkonflikte<\/h2>\n
Antifragilit\u00e4t und Emergenz<\/h2>\n
\n
\n
Zusammenfassung<\/h2>\n
Literatur<\/h2>\n
\n
\nUnsere Trainings & Coachings<\/h2>\n
\nQualit\u00e4t, Safety & Security – Fachwissen<\/h2>\n