aufmacher-istock-000026311928xxlarge.jpg

Während in der Forschung die beiden Themen Safety und Security in den letzten Jahren zusammengewachsen sind, ist das in der Industrie leider noch nicht der Fall. Das grundsätzliche Vorgehen ist bei Safety und Security jedoch ähnlich, nur der Betrachtungswinkel ändert sich. Sowohl Safety als auch Security betreffen nicht nur einzelne Phasen der Entwicklung, sondern die gesamte Entwicklung, ja sogar den kompletten Produktlebenszyklus. Security betrifft zusätzlich jedoch auch die gesamte Organisation des Unternehmens. Das hat etwas mit der Perspektive zu tun: Security betrachtet den Schutz des Produktes vor der Umwelt (Angreifer, Stromausfall und Ähnliches), während Safety den Schutz der Umwelt vor dem Produkt im Fokus hat. Genauer gesagt untersucht die Safety im Sinne von ISO 26262 den Schutz von Menschen vor physischen Verletzungen oder Gesundheitsschädigungen.

aufmacher-istock-000026311928xxlarge.jpg

iStock

Safety-Prozess nach ISO 26262

Gerade im Automotive-Bereich bietet es sich an, für Security ein ähnliches Vorgehen wie bei Safety nach ISO 26262 aufzubauen. Insbesondere für die Entwicklungsphasen, die mit Konzepten, Anforderungen und Design zu tun haben, ist das empfehlenswert. Im grundsätzlichen Vorgehen nach ISO 26262 gibt es eine Konzeptphase, die typischerweise beim Automobilhersteller ablaufen sollte. Basierend auf einer Item Definition, die das betrachtete System genauer beschreibt, ist eine Gefährdungsanalyse (Hazard Analysis) und eine Risikobewertung durchzuführen. Ein gefährdendes Ereignis beispielsweise wäre, wenn die mechanische Verriegelung der Lenkradsperre eines Fahrzeugs während der Fahrt auslöst, sodass das Fahrzeug unlenkbar wird.

Nach dieser Analyse sind Safety Goals zu definieren, die sicherstellen sollen, dass jedes gefährdende Ereignis abgedeckt ist, zum Beispiel „Die Lenkradsperre darf während der Fahrt nicht verriegeln“. In einem nächsten Schritt ist das Functional Safety Concept zu erstellen, das die Ableitung funktionaler Safety-Anforderungen aus den Safety Goals als Ziel hat.

Bild 1: Die drei Säulen der Security-Praktiken.

Bild 1: Die drei Säulen der Security-Praktiken.Method Park

Diese Item Definition, Hazard Analysis, Safety Goals und Functional Safety Requirements sollte der Zulieferer vom Automobilhersteller erhalten. Die Praxis zeigt allerdings, dass dies nicht immer der Fall ist oder nicht in der richtigen Qualität stattfindet. Hier muss der Zulieferer eventuell nacharbeiten. Seine Aufgabe ist es, die Functional Safety Requirements in konkretere Technical Safety Requirements zu überführen und ein Technical Safety Concept sowie das Systemdesign zu erstellen.

Wie lässt sich dieses Vorgehen auf einen Security-Prozess übertragen? Die Gefährdungsanalyse und Risikobewertung sind um eine Bedrohungsanalyse zu ergänzen, um die Bedrohungen zu analysieren, die von außen auf das Produkt einwirken und die Informationsvertraulichkeit, Datenintegrität oder Verfügbarkeit des Produktes beeinträchtigen können. Analog zur Definition von Safety Goals, aus denen Safety Requirements über verschiedene Ebenen abgeleitet werden, sollten entsprechende Security Goals definiert und in Security Requirements konkretisiert werden.

Grundlegende Security-Praktiken aus Reifegradmodellen

Schrittweise zur Security

Eine ganzheitliche Security lässt sich schrittweise erreichen: Zunächst besteht auf grober Prozessebene die Möglichkeit, ein Security-Vorgehen analog dem Safety-Vorgehen nach ISO 26262 zu wählen. Im nächsten Schritt wird auf Reifegradmodelle für Security zurückgegriffen, die wiederum als Ausgangsbasis für einen sogenannten Security-Engineering-Prozess dienen. Da Security nicht nur die Entwicklung sondern das ganze Unternehmen betrifft, rundet eine Zertifizierung nach ISO 27001 für ein Informationssicherheitsmanagement-System die Einführung einer ganzheitlichen Security ab.

Wird der grobe Entwicklungsprozess im Hinblick auf Security analog dem Vorgehen bezüglich der Safety nach ISO 26262 angepasst, steht man immer noch vor der Frage, welche Praktiken im Unternehmen im Detail berücksichtigt werden müssen. Zur Erfüllung vieler Security Requirements werden insbesondere kryptografische Verfahren zur Verschlüsselung notwendig sein, deren Einsatz aber nicht ausreicht, um eine ganzheitliche Security zu erreichen. Reifegradmodelle, die grundlegende Praktiken für Prozesse fordern und in der Automobilbranche durch Automotive SPICE und CMMI verbreitet sind, stellen eine Möglichkeit dar, um Engineering-Prozesse zu definieren. Daher bietet es sich auch für Security an, auf entsprechende Modelle als Ausgangsbasis für einen Security-Engineering-Prozess zurückzugreifen:

  • System Security Engineering Capability Maturity Mode l (SSE-CMM, ISO/IEC 21827)
  • Security by Design with CMMI for Development, Version 1.3
  • Software Assurance Maturity Model (SAMM)

Bei einem Vergleich dieser Modelle stellt man fest, dass zum einen die verwendeten Begriffe und die Strukturierung der Praktiken teilweise unterschiedlich sind, und dass es zum anderen drei tragende Säulen gibt: Security im Unternehmen, Security-Management und Security-Engineering (Bild 1).

Security im Unternehmen

Bild 2: Ganzheitliche Security in drei Schritten.

Bild 2: Ganzheitliche Security in drei Schritten.Method Park

Security im Unternehmen betrachtet Praktiken, die das ganze Unternehmen betreffen. So ist, wie beim Qualitätsmanagement (QM), die Unterstützung des Managements als Sponsor für das Thema Security entscheidend, das heißt das Management trägt die Verantwortung für Security. Analog zum QM hat das Management Security-Policies zu definieren, die zum Beispiel den Umgang mit Daten und Passwörtern regeln. Im Unternehmen sind security-relevante Prozesse zu definieren und einzuführen, beispielsweise Security Requirements Engineering. Ganz wichtig sind auf der einen Seite Schulungen der Mitarbeiter, die das Bewusstsein für das Thema Security wecken und vertiefen, und auf der anderen Seite rollenspezifische Security-Schulungen zu den Unternehmensprozessen und den einzusetzenden Methoden. Außerdem muss eine geeignete Arbeitsumgebung geschaffen werden. Dies beinhaltet unter anderem Räume mit Zugangsberechtigungen und bestimmte Software-Werkzeuge wie beispielsweise Virenscanner, Verschlüsselungssoftware oder zertifizierte Compiler. Ein weiterer wichtiger Aspekt ist das Vulnerability Management, das unter anderem Aufgaben wie die Identifikation von Schwachstellen und den Reaktionsprozess bei Verletzungen der Security abarbeitet.

Security-Management

Security Management beinhaltet Praktiken, die mit dem Management von Produkt-Security-Risiken im Projekt zu tun haben. Dazu gehören die Planung der Security-Aktivitäten und projektspezifische Security-Schulungen. Sollte die Security im eigenen Produkt verletzt worden sein und damit eine Lücke bekannt sein, dann sind die Ursachen zu analysieren und Maßnahmen zu definieren, um diese Lücke zu schließen. Security-Management betrifft auch die Auswahl der richtigen Lieferanten: Hat der Lieferant Security im Unternehmen etabliert? Verfügt er über ein ISO 27001-Zertifikat? Sind die Mitarbeiter des Lieferanten in punkto Security geschult oder sogar zertifiziert? Werden fertige Komponenten eingekauft, die im eigenen Produkt verwendet werden sollen, zum Beispiel bestimmte Software-Bibliotheken oder Betriebssysteme? Dann sollten wie für die Lieferanten verschiedene Kriterien aufgestellt werden; mögliche Kriterien lauten beispielsweise so: Ist die Komponente zertifiziert? Wie schnell werden Security-Updates bereitgestellt?

Ein wichtiger Aspekt des Security Managements ist das Risikomanagement bezüglich der Produkt-Security. Dies beinhaltet Bedrohungsanalysen und Risikobewertungen, Planung der Gegenmaßnahmen und Risikoverfolgung.

Security-Engineering

Bild 3: Überblick über den Inhalt der ISO 27001:2013.

Bild 3: Überblick über den Inhalt der ISO 27001:2013.Method Park

Ein anderer Begriff für Security-Engineering ist „Security by Design“. Diese Säule betrachtet die Praktiken, die im Rahmen der Entwicklung umzusetzen sind, also die Prozesse ENG.1 bis ENG.10 von Automotive SPICE. Die betrachteten Modelle orientieren sich eher an Automotive SPICE und CMMI, aber es bietet sich an, das Security-Engineering am Safety-Engineering nach ISO 26262 anzulehnen. Natürlich gilt es, andere Methoden einzusetzen, um ein Produkt secure zu machen, als um es safe zu machen, aber auf der Prozessebene (Rollen, Phasen, Aktivitäten, Arbeitsprodukte) lässt sich ein analoges Vorgehen definieren.

Security-Engineering beinhaltet somit die Definition von Security-Requirements und einer Security-Architektur. Dabei sind Prinzipien für Secure-Design einzuhalten. Eines davon ist das Prinzip der minimalen Rechte, das folgendes besagt: Man bekommt nur die zur Ausführung einer Funktion minimal notwendigen Rechte. Weiterhin gehören Security-Design-Reviews und Security-Tests zum Security-Engineering.

An dieser Stelle soll die Bedeutung der Entwicklung nachgelagerter Phasen herausgestrichen werden. Ihre Bedeutung ist für Safety groß, aber für Security noch größer, weil es bei Security darum geht, das Produkt vor der Umwelt zu schützen, insbesondere vor Angriffen auf die Informationsvertraulichkeit, Datenintegrität oder Verfügbarkeit des Produktes. Diese Angreifer sind kontinuierlich auf der Suche nach neuen Schwachstellen und Lücken, die sie für ihre Zwecke ausnutzen können. Daher ist das im Projekt begonnene Risikomanagement bezüglich der Produkt-Security auch nach Abschluss der Produktentwicklung weiterzuführen.

Aufbau eines Informationssicherheitsmanagement-Systems

Die genannten Modelle haben den Vorteil, den Blick nicht nur auf die Produktentwicklung sondern auch auf organisatorische Aspekte im Unternehmen zu richten (Security im Unternehmen). Damit fehlt nicht mehr viel zu einem Informationssicherheitsmanagement-System (Bild 2). Nachdem es diesen letzten Schritt gegangen ist, hat das Unternehmen eine ganzheitliche Security etabliert. Die Anforderungen an ein Informationssicherheitsmanagement-System sind beispielsweise in der Norm ISO 27001 zu finden (Bild 3). In Deutschland kann auch auf den IT-Grundschutz vom Bundesamt für Sicherheit in der Informationstechnik zurückgegriffen werden, der allerdings mittlerweile etwas veraltet ist und sich daher derzeit in Überarbeitung befindet.

Einige der Anforderungen an ein Informationssicherheitsmanagement-System finden sich auch in den Reifegradmodellen wieder. Hinzu kommt zum Beispiel eine Organisationsstruktur mit Rollen und Verantwortlichkeiten. Eine wichtige Rolle für ein derartiges System ist der Beauftragte für das Informationssicherheitsmanagement; er nimmt hinsichtlich Security eine ähnliche Rolle ein wie der Qualitätsmanagementbeauftragte in punkto Qualität. Des Weiteren sind das Security-Management und insbesondere das Risikomanagement auf das ganze Unternehmen auszuweiten. Es reicht nicht aus, nur die schützenswerten Informationen eines zu entwickelnden Produktes zu betrachten; man muss vielmehr auch alle anderen Informationen und Ressourcen im Blick behalten, die damit zu tun haben, einschließlich des Umgangs mit diesen Dingen. Analog zu den meisten anderen Managementsystemen (Qualität, Umwelt und Ähnliches) sind interne Audits, Management-Reviews und eine kontinuierliche Verbesserung gefordert. Sind die entsprechenden Prozesse überarbeitet und ergänzt, rundet eine Zertifizierung nach ISO 27001 für ein Informationssicherheitsmanagement-System die Reorganisation dieser Prozesse ab.

Jens Palluch

ist für Method Park als Trainer und Berater zu den Themen Requirements Engineering, Systems Engineering, Safety und Security tätig.

(av)

Sie möchten gerne weiterlesen?