Advertisement

Industrial Security by Design

Nachverfolgbare Informationssicherheit für Cyber-Physische Produktionssysteme
  • Christopher GerkingEmail author
  • Eric Bodden
  • Wilhelm Schäfer
Living reference work entry
  • 424 Downloads
Part of the Springer Reference Psychologie book series (SRP)

Zusammenfassung

Das Zukunftsszenario der Industrie 4.0 ist geprägt durch einen massiven Anstieg der unternehmensübergreifenden Vernetzung. Um einer Bedrohung durch unautorisierte Weitergabe oder Sabotage vertraulicher Daten entgegenzuwirken, muss der Informationssicherheit bereits im Entwurf der cyber-physischen Produktionssysteme ein hoher Stellenwert eingeräumt werden. Dieses Paradigma wird als Security by Design bezeichnet. Über den gesamten Entstehungsprozess hinweg muss nachverfolgt werden können, ob die Systeme spezifische Anforderungen an die Informationssicherheit erfüllen und damit die Eigenschaft der Industrial Security gewährleisten. Dieser Beitrag stellt einen Entwurfsansatz zur Nachverfolgung der Informationssicherheit vor, der durch Integration softwaretechnischer Methoden in das Systems Engineering eine Entwicklung nach dem Paradigma Security by Design ermöglicht.

Schlüsselwörter

Nachverfolgbarkeit Industrial Security Security by Design Systems Engineering Cyber-Physical Systems 

1 Einleitung

Die Industrie 4.0 verspricht massive Fortschritte bei der Individualisierung industrieller Produktionsprozesse. Diese Individualisierung ermöglicht es, die Prozesse vollautomatisch und in Echtzeit an äußere Umstände anzupassen. Produktionssysteme werden den Einsatz von Personal und Produktionsmitteln vollautomatisch an Faktoren wie etwa der aktuellen Auftragslage oder der preislichen bzw. zeitlichen Verfügbarkeit von Ressourcen ausrichten. Während die durchgängige Automatisierung den Unternehmen eine massive Effizienzsteigerung bei der Produktionsplanung und -steuerung in Aussicht stellt, ergeben sich auch aus Kundensicht neuartige Zukunftschancen. So ermöglicht die Individualisierung auch eine Berücksichtigung von spezifischen Kundenwünschen als zusätzlichen individuellen Parameter der Produktion, und ebnet so den Weg für eine preiswerte Fertigung von Endprodukten in kleiner Stückzahl bis hin zur Losgröße 1.

Voraussetzung für diesen hohen Grad der Individualisierung ist eine stark zunehmende Digitalisierung und ein massiver Austausch von Informationen. Dieser muss Produktionsanlagen, Produktionsmittel, sowie die Mitarbeiterinnen und Mitarbeiter mit einbeziehen, um eine Zugänglichkeit der relevanten Informationen sowie die darauf aufbauende Koordination der Produktionsverfahren sicherzustellen. Die auszutauschenden Informationen umfassen beispielsweise die aktuelle Auftragslage, die Verfügbarkeit von Materialien und Personal, oder den Status von Produktionsanlagen. Wird zudem der Rohling des zu fertigenden Produktes selbst mit den für die Produktion relevanten Informationen ausgestattet, so kann das Produkt in den Informationsaustausch mit einbezogen werden und dadurch seine eigene Fertigung steuern (Kagermann et al. 2011). Durch diese Dezentralität der Produktion kann eine Nachvollziehbarkeit der gesamten Produktionshistorie für jedes individuelle Produkt begünstigt werden, und damit die Qualitätssicherung und Fehlerverfolgung auch ohne eine zentrale Datenhaltung gewährleistet werden.

1.1 Vernetzung

Sollen die oben genannten Vorteile entlang der gesamten Wertschöpfungskette des produzierenden Gewerbes zur Entfaltung kommen, so darf der Informationsaustausch keinen Halt vor den Grenzen eines einzelnen Unternehmens machen (Bachlechner et al. 2016). Vielmehr muss die Vernetzung auf ganze Lieferketten ausgedehnt werden, um die Auslagerung bestimmter Prozessschritte in externe Unternehmen, bis hin zur Fertigung und Zulieferung ganzer Teilprodukte, ebenfalls flexibel und vollautomatisch koordinieren zu können. Im Zuge dieser horizontalen Integration zu globalen Wertschöpfungsnetzwerken sind die Produktionsanlagen der Zukunft unternehmensübergreifend in Form von sogenannten Cyber-Physical Systems verbunden. Wie im Fall traditioneller Produktionsanlagen sind solche Systeme mit Aktorik und Sensorik ausgestattet, um einzelne Schritte des Produktionsvorgangs auszuführen und auf diese Weise mit der physikalischen Umgebung zu interagieren. Über diese physikalische Wechselwirkung hinausgehend sind cyber-physische Produktionssysteme durch Kommunikationstechnik miteinander vernetzt und so in der Lage, die Ausführung von Prozessschritten flexibel untereinander und ggf. auch untemehmensübergreifend koordinieren zu können. Cyber-Physical Systems verschmelzen somit die physikalische mit der virtuellen Welt (acatech 2011).

Die unternehmenssübergreifende Interaktion, z. B. um eine Zulieferung von Teilprodukten zu koordinieren, ist in der Industrie 4.0 nicht an eine feste Struktur gebunden. Vielmehr ermöglicht die Vernetzung einen jederzeitigen dynamischen Aufbau von Geschäftsbeziehungen (Bachlechner et al. 2016) in Abhängigkeit von individuellen kundenspezifischen Kriterien für das Produkt und seine Fertigung. Solche Kriterien können beispielsweise die garantierte Lieferzeit, die anfallenden Produktionskosten, oder die Umweltverträglichkeit des Produktionsvorgangs umfassen. Voraussetzung für eine vollautomatische Aushandlung solcher Geschäftsbeziehungen ist die Bildung von Dienstmärkten, auf denen konkurrierende Zulieferer ihre Produktionsdienste global und unter Angabe der von ihnen garantierten Qualitätskriterien anbieten (Diedrich et al. 2014; Kagermann et al. 2014). Zulieferer werden somit vermehrt zu Dienstleistern. Auf Seiten der Endhersteller kann daraufhin ein automatischer Abgleich der angebotenen Qualitätskriterien mit den spezifischen Kundenwünschen durchgeführt werden. Ein Dienstleistungsgesuch für die Fertigung eines bestimmten Teilproduktes kann somit global ausgeschrieben und je nach aktueller Marktsituation an genau den Dienstleister übergeben werden, der die Kundenanforderungen unter allen Wettbewerbern optimal erfüllt. Durch eine bestmögliche Abstimmung von Produktangebot und -nachfrage kann so ein Beitrag zu einer globalen Optimierung von Geschäftsbeziehungen geleistet werden.

1.2 Angriffsrisiko

Beteiligt sich ein produzierendes Unternehmen an den Dienstmärkten der Zukunft, so führt die dynamische Aushandlung der Geschäftsbeziehungen zu einem massiven Anstieg des unternehmensübergreifenden Datenaustausches (Bachlechner et al. 2016). Zunächst steigt das Kommunikationsvolumen selbst stark an, da potenziell jede Geschäftsbeziehung nach Bedarf ausgehandelt wird. Darüber hinaus ist auch die Anzahl der potenziellen Geschäftspartner, mit denen ein Unternehmen sensitive Informationen austauscht, wesentlich höher als im Fall von traditionellen, im Vorhinein festgelegten Zulieferbeziehungen. Aufgrund der Globalität und Flexibilität der Märkte sind die Dienstleister, mit denen Informationen ausgetauscht werden, dem Endhersteller nicht mehr notwendigerweise bekannt. Die Industrie 4.0 wirft daher Fragen nach der Vertrauenswürdigkeit von Geschäftsbeziehungen auf. Die unternehmensübergreifende Vernetzung stellt einen neuartigen Angriffsvektor auf sensitive Unternehmensdaten dar, die potenziell eingesehen oder manipuliert werden könnten.

Um dem stark erhöhten Angriffsrisiko entgegen zu wirken, kommt der IT-Sicherheit die Rolle eines kritischen Erfolgsfaktors für die Einführung der Industrie 4.0 zu. Eine Vielzahl an Veröffentlichungen belegt die Relevanz des Themas aus industrieller Sicht sowie die sich bietenden Forschungspotenziale (Eckert und Fallenbeck 2015; Lass und Kotarski 2014; Junker 2015; Hänisch und Rogge 2017). Industrial Security wird als eine Schlüsselqualifikation angesehen und stellt Unternehmen vor die Herausforderung, neue Kompetenzen auf diesem Gebiet zu schaffen (Gausemeier et al. 2016; Kobes 2016). In einer durch das Bundesministerium für Wirtschaft und Energie in Auftrag gegebenen Studie widmet sich ein Expertenbeirat dem Thema der IT-Sicherheit für die Industrie 4.0 und zeigt entsprechende Handlungsfelder auf (Bachlechner et al. 2016).

1.3 Beitrag und Struktur

Dieser Beitrag nimmt den Standpunkt ein, dass Maßnahmen zum Schutz vor Angriffen bereits im Entwurfs- und Entwicklungsprozess neuartiger Systeme ansetzen müssen, um Industrial Security effektiv zu gewährleisten. Entsprechend dem Paradigma Security by Design (Bodden et al. 2013a) wird das Ziel verfolgt, Anforderungen an die Informationssicherheit eines Systems zu Beginn des Entstehungsprozesses zu erfassen und ihre Erfüllung bis über die Inbetriebnahme hinaus nachzuverfolgen. Übergeordnete Zielstellung des Beitrages ist somit die Erkennung einer Vielzahl von Schwachstellen bereits vor Inbetriebnahme eines Systems, ohne dass kostspielige Gegenmaßnahmen im laufenden Betrieb ergriffen werden müssen. Dazu beleuchtet Abschn. 2 die neuartigen Bedrohungsszenarien aus Sicht von Mitarbeiterinnen und Mitarbeitern, sowie die sich daraus ergebenen Anforderungen an die Informationssicherheit. Abschn. 3 stellt einen Ansatz zur Nachverfolgbarkeit solcher Anforderungen vor. In Abschn. 4 werden existierende Methoden hinsichtlich der Integrierbarkeit in unseren Ansatz bewertet, bevor in Abschn. 5 ein Fazit der ausstehenden Forschungsarbeiten gezogen wird.

2 Bedrohungsszenarien

Das erhöhte Ausmaß der unternehmensübergreifenden Vernetzung zieht auch eine erhöhte Anzahl an Kommunikationsschnittstellen nach sich, über die ein Unternehmen Informationen mit anderen Unternehmen austauscht. Jede dieser Schnittstellen ermöglicht potenziell den Zugriff auf sensitive Daten eines Unternehmens. An dieser Stelle wirkt sich die Offenheit und Globalität der Dienstmärkte in der Industrie 4.0 nachteilig aus. So ist nicht auszuschließen, dass einzelne Marktteilnehmer nur zum Vorwand bestimmte Produktionsdienstleistungen anbieten, in Wahrheit jedoch ausschließlich verbrecherische Absichten verfolgen, indem sensitive Daten abgegriffen werden. Dass ein Missbrauch von Marktstrukturen ein realitätsnahes Szenario darstellen kann, wurde in der Vergangenheit bereits durch den automatisierten Hochfrequenzhandel mit Wertpapieren belegt. Dieser Abschnitt thematisiert im Folgenden neuartige Bedrohungsszenarien für Unternehmensdaten (Abschn. 2.1) sowie auch für Mitarbeiterdaten (Abschn. 2.2).

2.1 Unternehmensdaten

Zum Ziel von Cyberattacken können in erster Linie solche Informationen werden, die einem Unternehmen bestimmte Wettbewerbsvorteile gegenüber der Konkurrenz verschaffen. Solche Informationen umfassen geistiges Eigentum wie beispielsweise Know-How in Bezug auf die Produktionsprozesse, oder sonstige Geschäftsgeheimnisse wie Konstruktionspläne, Patente, oder Produktstrategien. Ein unautorisierter Zugriff auf solche Daten befähigt Wettbewerber dazu, sich diese Informationen zunutze zu machen indem beispielsweise Produktpiraterie betrieben wird.

Betroffen von einer solchen Entwicklung wären wiederum auch die Mitarbeiterinnen und Mitarbeiter, deren Arbeitsplätze und Lohngefüge essenziell an die Wirtschaftlichkeit ihrer arbeitgebenden Unternehmen gekoppelt sind. Während die Industrie 4.0 einer Verlagerung der Produktion in Niedriglohnländer grundsätzlich entgegen wirken kann und damit nicht zuletzt auch eine Erhaltung des Hochlohnstandortes suggeriert, werden diese wirtschaftlichen Fortschritte durch eine mangelnde Informationssicherheit wiederum in Frage gestellt.

Besonders kritisch stellt sich aus Sicht von Unternehmen sowie Mitarbeiterinnen und Mitarbeitern das Zusammenspiel der Informationssicherheit mit Aspekten der funktionalen Sicherheit (Safety) dar (Bachlechner et al. 2016). So könnte durch das Eindringen in ein System bewusst ein Fehlverhalten bei der Steuerung physikalischer Prozesse hervorgerufen werden. Schwachstellen der Informationssicherheit können sich somit zu einer Gefährdung der funktionalen Sicherheit ausdehnen, die im schlimmsten Fall ein Gesundheitsrisiko bzw. eine Lebensgefahr für Mitarbeiterinnen und Mitarbeiter darstellen kann.

2.2 Mitarbeiterdaten

Mit der steigenden Digitalisierung in der Industrie 4.0 ändert sich auch die Rolle von Mitarbeiterinnen und Mitarbeitern. Routinemäßige Arbeitsschritte fallen oftmals nicht mehr in den menschlichen Aufgabenbereich, sondern werden größtmöglich autonom durch das Produktionssystem selbst ausgeführt. Dem Menschen kommt daher zunehmend die Rolle einer „Steuerungsinstanz“ (Gorecky et al. 2014) zu. Mitarbeiterinnen und Mitarbeiter bringen ihre Kompetenzen verstärkt zur Überwachung und Bewertung der Funktionsweise ein und greifen auf dieser Basis vor allem in Störungsfällen aktiv in den Produktionsprozess ein. Eine Anpassung von Produktionssystemen an menschliche Belange ist daher von großer Wichtigkeit, um einer steigenden menschlichen Verantwortung gerecht werden zu können.

Essenziell für eine adäquate Involvierung des Menschen sind Systeme, die eine Adaptivität der Benutzerschnittstelle zugunsten der persönlichen Bedürfnisse oder Vorlieben der einzelnen Mitarbeiterinnen und Mitarbeiter vorsehen (Paelke und Röcker 2015). Eine Adaption der Schnittstellen eröffnet die Möglichkeit der Rücksichtnahme auf Altersunterschiede, kulturelle bzw. sprachliche Disparitäten, oder körperliche Einschränkungen. Solche Systeme sind daher Grundvoraussetzung für „demografie-sensible“ Arbeitswelten (Kagermann et al. 2013). Die Basis einer solchen Anpassung sind individuelle Systemeinstellungen, die jedoch potenziell auch Rückschlüsse auf personenbezogene Daten (z. B. Alter, Sehstärke, oder Rechts- bzw. Linkshänder) zulassen. Hierdurch sind personenbezogene Daten genauso der Bedrohung durch Cyberattacken ausgesetzt, wie es bei Unternehmensdaten der Fall ist. In Abb. 1 ist ein solches Bedrohungsszenario exemplarisch dargestellt. Ein Mitarbeiter eines Produktionsunternehmens interagiert mit einem Produktionssystem, dessen adaptive Benutzerschnittstelle durch ein Tablet gegeben ist. Das Unternehmen ist gleichzeitig vernetzt mit einem Cloud-basierten Dienstmarkt für Produktionsdienstleistungen. Auf diesem offenen Markt agiert ein Dienstleister mit verbrecherischen Absichten, der wie im Szenario dargestellt, Rückschlüsse auf personenbezogene Daten des Mitarbeiters ziehen kann.
Abb. 1

Bedrohung durch Weitergabe von Mitarbeiterdaten an einen Cloud-basierten Dienstmarkt

Dabei kann das Datenaufkommen noch viel größere Dimensionen annehmen, als es bei Systemen mit adaptiven Benutzerschnittstellen der Fall ist. Solche Systeme bieten zunächst lediglich alternative Formen der Ein- bzw. Ausgabe von Informationen an, während der Produktionsprozess selber unberührt bleibt. Soll jedoch menschlichen Faktoren eine erhöhte Geltung eingeräumt werden, so sind Systeme vorausgesetzt, die eine Adaption der Produktionsprozesse zugunsten menschlicher Belange zulassen. Beispiele für diese Art der Adaption sind flexible Taktzeiten, die individuell auf die jeweilige Verfassung und Leistungsfähigkeit von Mitarbeiterinnen und Mitarbeitern abgestimmt sind, oder eine vielfältige Aufgabenverteilung durch Job Rotation, um dem Aufkommen von Monotonie im Arbeitsalltag gezielt entgegen zu wirken. Um diese Form der Adaption zu ermöglichen, benötigen Systeme allerdings Zugriff auf wesentlich weitreichendere Informationen wie beispielsweise Leistungsdaten.

Ein weitere Steigerung des Datenaufkommens ist dann zu erwarten, wenn die ausgetauschten Informationen nicht mehr durch die Mitarbeiterinnen und Mitarbeiter selbstbestimmt werden können, sondern von Systemen automatisch erfasst werden. Solche Systeme sind im Zeitalter der Industrie 4.0 besonders naheliegend, da Cyber-Physical Systems durch Aktorik und Sensorik bereits über eine inhärente Wechselwirkung mit ihrer Umwelt verfügen und diese ohne Weiteres auf den Menschen ausdehnen können (Gorecky et al. 2014). Solche Systeme interagieren also nicht nur mit physikalischen Prozessen, sondern müssen auch Bedürfnisse und Verfassung der Mitarbeiterinnen und Mitarbeiter verarbeiten sowie vollautomatisch eine Anpassung der Produktionsprozesse anstoßen. Unerlässlich für die Automatisierung der Adaption ist dabei die Erfassung physiologischer Daten durch den Einsatz von Körpersensorik. Darauf aufbauend kann eine Verarbeitung der Daten in Form einer Emotionserkennung oder der Feststellung von Ermüdungserscheinungen erfolgen.

Wie die obigen Bedrohungsszenarien zeigen, können Mitarbeiterinnen und Mitarbeiter von Mängeln im Bereich der Informationssicherheit nicht nur indirekt, d. h. durch Weitergabe oder Manipulation von Unternehmensdaten betroffen sein. Ebenfalls unmittelbar gefährdet sind personenbezogene Mitarbeiterdaten, die in die Systeme eingespeist werden. Ein Unternehmen das sich zur Industrie 4.0 öffnet, ist damit der Gefahr eines Missbrauchs sensitiver Daten ausgesetzt. Die von der Industrie 4.0 suggerierte Chance auf menschenzentrierte Arbeitsbedingungen steht dabei in massivem Kontrast zu einer möglichen Verletzung der Persönlichkeitsrechte von Mitarbeiterinnen und Mitarbeitern durch den unkontrollierten Missbrauch ihrer personenbezogenen Daten.

3 Nachverfolgung der Informationssicherheit

Vor dem sicherheitskritischen Hintergrund unterliegen industrielle Produktionsanlagen bestimmten Richtlinien und Standards, aus denen Vorgaben an die funktionale Sicherheit hervorgehen. Diese beschreiben den Einsatz gefahrensenkender Maßnahmen und ziehen dabei den gesamten Lebenszyklus der Systeme mit ein. Insbesondere umfassen sie Maßnahmen die bereits im Entwicklungsstadium ansetzen. Sicherheitsaspekte fungieren somit als Kriterien für die Konformität zu den relevanten Normen. Nur Systeme, die einen Nachweis über die im Entwicklungsstadium getroffenen Sicherheitsvorkehrungen erbringen können, werden mit dem entsprechenden Zertifikat bedacht.

Heutige Forschungsansätze gehen dabei von engen Wechselwirkungen zwischen funktionaler Sicherheit und Informationssicherheit aus und treiben einen einheitlichen Umgang der beiden Aspekte voran (Winzer et al. 2010). Beispielsweise stellen die in Abschn. 2 geschilderten Bedrohungen durch Sabotageakte eine Gefährdung von Menschenleben dar, die durch Schwachstellen im Umgang mit der Informationssicherheit ausgelöst werden können. Die Informationssicherheit gehört dabei aktuell noch zu den „deregulierten“ Bereichen (Bachlechner et al. 2016), für die kaum verbindliche und präzise Standards existieren. Existierende Prüfstandards (Bundesamt für Sicherheit in der Informationstechnik 2016) lassen jedoch bereits erahnen, dass in der Zukunft verpflichtende Regularien auch im Bereich der Informationssicherheit aufgestellt werden.

3.1 Nachverfolgbarkeit

Essenziell für eine Zertifizierung ist das Konzept der Nachverfolgbarkeit (engl. Traceability) von Anforderungen, die zu Beginn der Systementwicklung als Vorgaben für das System aufgestellt werden. Anforderungen können funktionaler Natur sein, allerdings auch nichtfunktionale Aspekte wie zum Beispiel die Informationssicherheit betreffen. Die Nachverfolgbarkeit beschreibt dabei die Fähigkeit, den Lebenslauf einer Anforderung in Vorwärts- und Rückwärtsrichtung über alle Phasen des Lebenszyklus eines Systems hinweg zu verfolgen (Cleland-Huang et al. 2012), einschließlich der Anforderungsspezifikation und der Entwurfs-, Entwicklungs- und Testphasen, sowie letztendlich bis über die Inbetriebnahme hinaus. Basis der Nachverfolgbarkeit ist somit eine präzise und explizite Verknüpfung von Artefakten die in den verschiedenen Lebenszyklusphasen entstehen. Darunter fallen zum Beispiel Anforderungsspezifikationen, Entwurfselemente, Entwicklungserzeugnisse wie etwa Programmcode, oder Testfälle. Die Verknüpfung der Artefakte muss dabei durch eine entsprechende technische Infrastruktur im Entwicklungsprozess ermöglicht und durch eine geeignete Organisation des Prozesses sichergestellt werden (Sünnetcioglu et al. 2014). Sind diese Voraussetzungen gegeben, kann die Nachverfolgbarkeit vielfältige Nutzen bringen:
  • Ändern sich die Anforderungen an ein System während des Entwicklungsprozesses, können die Folgen einer solchen Änderung im Vorhinein abgeschätzt werden, indem die betroffenen Entwurfs- oder Entwicklungsartefakte direkt nachverfolgt werden können. Aus einer automatisierten Change Impact Analysis (Bohner 2002) ergeben sich so Vorteile bei der Abschätzung von Änderungsaufwänden, sowie eine erhöhte Planungssicherheit im Entwicklungsprozess.

  • Ausgehend von einer spezifizierten Anforderung, kann durch eine Nachverfolgung der hierzu in Bezug stehenden Entwurfs- oder Entwicklungsartefakte die Erfüllung der Anforderung unmittelbar belegt werden. Durch die Ausführung von Testfällen oder alternativer Analyseverfahren, die mit der Anforderung verknüpft sind, wird die Erfüllung automatisch nachweisbar.

  • Umgekehrt kann ausgehend von einem Entwurfs- oder Entwicklungsartefakt eine konkrete Daseinsberechtigung abgeleitet werden, indem die dazu in Bezug stehenden Anforderungen nachverfolgt werden. Es kann so sichergestellt werden, dass alle vorhandenen Artefakte einen belegbaren Nutzen haben und keine Artefakte vorhanden sind, die aufgrund einer fehlenden Daseinsberechtigung die Qualität eines Systems in Frage stellen. Gerade im Bereich der Informationssicherheit können solche Artefakte als Angriffsvektoren für Schadsoftware fungieren. Weiterhin kann durch die Nachverfolgbarkeit ein unbeabsichtigtes Entfernen von Artefakten ausgeschlossen werden, indem die zugeordneten Anforderungen unmittelbar erkennbar werden.

Die oben genannten Nutzungsmöglichkeiten machen die Nachverfolgbarkeit von Anforderungen zu einem essenziellen Bestandteil des Entwurfs- und Entwicklungsprozesses von Produktionsanlagen. Im Kontext der Industrie 4.0 ist zu erwarten, dass sich auch die neu aufkommenden Anforderungen im Bereich der Informationssicherheit diesen rigorosen Regularien unterziehen müssen. Beginnend mit der Anforderungsspezifikation muss die Informationssicherheit über den kompletten Lebenszyklus der Systeme hinweg betrachtet werden, damit spezifische Anforderungen aus diesem Bereich nachverfolgbar sind (Breu et al. 2016).

3.2 Informationssicherheit im Systems Engineering

Bei der Sicherstellung der Nachverfolgbarkeit gilt es jedoch, spezifischen Eigenschaften von cyber-physischen Produktionssystemen in der Industrie 4.0 Rechnung zu tragen. Als mechatronische Produkte setzen sich die Systeme aus Erzeugnissen verschiedener Fachdisziplinen zusammen, wie etwa der Mechanik, der Elektrotechnik, der Regelungstechnik, oder auch der Softwaretechnik. Im Zusammenspiel dieser Disziplinen fungiert die Softwaretechnik zunehmend als Innovationstreiber (Gausemeier et al. 2013a) und verleiht den Systemen die nötige künstliche Intelligenz, die ein Einsatz im Umfeld der Industrie 4.0 voraussetzt.

Um die steigende Komplexität an den Schnittstellen zwischen den beteiligten Fachdisziplinen zu bewältigen, werden Methoden des Systems Engineerings herangezogen (Gausemeier et al. 2013b). Dieser Ansatz trägt dem interdisziplinären Charakter der heutigen Systementwicklung Rechnung, indem die Spezifikation nicht aus Sichtweise einer einzelnen Fachdisziplin heraus angegangen wird. Stattdessen wird eine disziplinübergreifende Herangehensweise praktiziert, die die einzelnen Disziplinen im Rahmen einer ganzheitlichen Methodik integriert, jedoch gleichzeitig einen nahtlosen Übergang hin zu den fachspezifischen Entwurfs- und Entwicklungsmethoden für die verschiedenartigen Erzeugnisse ermöglicht. Prädestiniert für die Integration der Fachdisziplinen ist ein virtueller, rechnergestützter Entwurf im Rahmen eines modellbasierten Systems Engineerings (Dumitrescu et al. 2015). Nicht umsonst wird das modellbasierte Systems Engineering als ein „Schlüssel für Industrie 4.0“ (Alt 2014) betrachtet.

Die Spezifikationstechnik Consens1 greift dieses Paradigma auf und stellt eine disziplinübergreifende Entwurfsmethodik für das modellbasierte Systems Engineering intelligenter technischer Systeme zur Verfügung (Gausemeier et al. 2008). Dadurch ist die Spezifikationstechnik speziell geeignet für die Systeme der Industrie 4.0, die ihre inhärente Teilintelligenz in die globalen Wertschöpfungsnetzwerke einbringen. Im Kern der Spezifikationstechnik steht die Modellierung einer Prinziplösung. Diese umfasst die grundlegenden Systemelemente und ihre Wechselwirkungen sowohl untereinander, als auch mit externen Elementen des Systemumfelds. Dazu beschreibt die Prinziplösung die Flussbeziehungen zwischen den Elementen in Form von Material-, Energie-, oder Informationsfluss. Abb. 2 greift das Beispiel aus Abschn. 2.2 auf und stellt die Wechselwirkungen eines vernetzten Produktionssystems mit seinem Umfeld dar. Diese Wechselwirkungen umfassen zunächst den Informationsaustausch zwischen System und Produktionsarbeiter. Für Bestellungen von Teilprodukten besteht ein Informationsfluss zwischen dem System und dem Dienstmarkt, aus dem wiederum ein Materialfluss zurück zum System vorliegt, der die Zulieferung der Teilprodukte darstellt. Zusätzlich greift das System lesend auf einen Fertigungsplan zu, dargestellt als einseitiger Informationsfluss.
Abb. 2

Modellierung der Wechselwirkungen zwischen Produktionssystem und Umfeldelementen

Der Informationsfluss beschreibt dabei den für die Funktionsweise des Systems essenziellen Austausch von Daten. Ein solcher Datenaustausch legt allerdings ein besonderes Augenmerk auf den Umgang mit der Informationssicherheit. Vorschriften für diesen Umgang werden in Form einer Sicherheitsrichtlinie oder Security Policy (Schneider 2000) spezifiziert. Anhand unterschiedlicher Schutzziele (Bedner und Ackermann 2010) können Sicherheitsrichtlinien wie folgt klassifiziert werden (Schneider 2012):
  • Vertraulichkeit betrifft den Schutz vor unautorisierter Einsicht in Daten.

  • Integrität bezieht sich auf den Schutz vor unautorisierter Datenmanipulation.

  • Verfügbarkeit beschreibt den Schutz vor mutwilligen Systemausfällen.

Im Beispiel könnte die Sicherheitsrichtlinie vorschreiben, dass die Schutzziele Vertraulichkeit und Integrität durch Ausschluss unerwünschter Informationflüsse sichergestellt werden müssen. Beispielsweise ist für das in Abb. 2 spezifizierte System ein Informationsfluss zwischen dem Produktionsarbeiter und dem Dienstmarkt unerwünscht, da personenbezogene Mitarbeiterdaten als vertraulich gelten und gleichzeitig der Umgang mit Daten durch die Teilnehmer des Dienstmarktes nicht kontrolliert werden kann. Im vorliegenden Fall muss daher das Produktionssystem das Schutzziel der Vertraulichkeit sicherstellen, indem ein Informationsfluss zwischen Produktionsarbeiter und Dienstmarkt ausgeschlossen wird. Gleichzeitig dürfen keine Informationen vom Dienstmarkt oder dem Mitarbeiter zum Fertigungsplan fließen, um dessen Integrität zu gewährleisten. In den nachgelagerten Phasen der Systementwicklung müssen also entsprechende Maßnahmen ergriffen werden um eine Informationsflusskontrolle (Hedin und Sabelfeld 2012) zu gewährleisten und so die spezifizierte Sicherheitsrichtlinie zu erfüllen.

3.3 Entwurfsmethodik

Aufgrund der Abstraktheit der Prinziplösung ist die Einhaltung der Sicherheitsrichtlinie natürlich abhängig von der Verfeinerung des disziplinübergreifenden Entwurfs innerhalb der einzelnen Fachdisziplinen. Die Softwaretechnik ist hierbei diejenige Disziplin, in der die Informationsverarbeitung des Systems implementiert wird und die somit einen inhärenten Umgang mit der Informationssicherheit pflegt. Gleichzeitig stellt die Softwaretechnik bereits konkrete Methoden und Werkzeuge bereit, mit Hilfe derer sich die Informationssicherheit bereits ab dem Entwurfsstadium von Softwaresystemen berücksichtigen lässt. Dieses Paradigma wird als Security by Design bezeichnet (Bodden et al. 2013a) und ermöglicht es, bereits im Entwicklungsprozess eines Softwaresystems verlässliche Aussagen über die Informationssicherheit zu treffen.

Jedoch operieren existierende Methoden naturgemäß auf disziplinspezifischen Artefakten der Softwaretechnik wie zum Beispiel dem Programmcode. Ein Bezug zu den abstrakten, disziplinübergreifenden Methoden des Systems Engineerings besteht nicht. Die Nachverfolgbarkeit der Informationssicherheit ist somit nicht gegeben, da kein Bezug zwischen der abstrakten Sicherheitsrichtlinie und konkreten, softwaretechnisch analysierbaren Eigenschaften besteht. Eine Integration dieser softwaretechnischen Methoden mit der Ebene des modellbasierten Systems Enginerings ist somit unerlässlich, um analysierbare Eigenschaften aus den abstrakten Informationsflussanforderungen ableiten zu können, sowie aus den Analyseergebnissen wiederum Rückschlüsse über die Erfüllung der abstrakten Anforderungen ziehen zu können. Dem Paradigma Security by Design entsprechend stellen wir im Folgenden eine schrittweise Methodik für die Nachverfolgung der Informationssicherheit cyber-physischer Systeme mit Mitteln der Softwaretechnik vor.

3.3.1 Identifikation von Bedrohungen

Um die Spezifikation von Anforderungen an die Informationssicherheit zu begünstigen, muss zunächst ein Bewusstsein für schutzbedürftige Informationen sowie relevante Gefahren, Schwachpunkte und mögliche Angriffsvektoren geschaffen werden. Nur unter dieser Voraussetzung können in den nachgelagerten Phasen des Systems Engineerings effektive Schutzmaßnahmen ergriffen werden. Die modellbasierte Herangehensweise legt dabei die Möglichkeit einer Bedrohungsmodellierung (Shostack 2014) nahe, die wie in Abb. 3 dargestellt, dem disziplinübergreifenden Systementwurf vorgeschaltet werden muss. Die Bedrohungsmodellierung verfolgt das Ziel, relevante Angriffsszenarien frühzeitig und strukturiert zu identifizieren und in Form eines Bedrohungsmodells zu erfassen. Beispielsweise könnten an dieser Stelle die Mitarbeiterdaten oder der Fertigungsplan als schutzbedürftige Informationen definiert werden, sowie die Identifizierung des offen zugänglichen Dienstmarktes als eine potenzielle Gefahrenquelle erfolgen.
Abb. 3

Nachverfolgbarkeit in den Entwurfs- und Entwicklungsphasen des Systems Engineerings

Aus den erfassten Bedrohungen können wichtige Bestandteile einer Sicherheitsrichtlinie abgeleitet werden, die im Folgenden auf Ebene der Prinziplösung spezifiziert werden muss, zum Beispiel in Form von unzulässigen Informationsflüssen. Im Beispiel könnte ein Informationsfluss zwischen Mitarbeiter (bzw. Fertigungsplan) und Dienstmarkt als unzulässig spezifiziert werden. Wie in Abb. 3 dargestellt, muss im Sinne der Nachverfolgbarkeit eine explizite Verknüpfung zwischen Bedrohungsmodell und Prinziplösung erreicht werden, aus der detailliert hervorgeht, inwiefern die relevanten Bedrohungen durch die spezifizierten Anforderungen abgedeckt werden.

Einer effektiven Spezifikation der Anforderungen steht jedoch die Tatsache entgegen, dass der Informationssicherheit im disziplinübergreifenden Entwurf bislang nicht hinreichend Rechnung getragen wird. Einerseits wird Security mit dem Ausbleiben erfolgreicher Angriffe assoziiert (Haley et al. 2008). Formulierungen wie beispielsweise „personenbezogene Mitarbeiterdaten können niemals durch Teilnehmer des Dienstmarktes eingesehen werden“ sind typische Nutzeranforderungen. Da Security demnach durch „negative Eigenschaften charakterisiert wird“ (Breu et al. 2016), sind alternative Formen der Anforderungsspezifikation notwendig. Andererseits muss im disziplinübergreifenden Sinne des Systems Engineerings eine Integration inkompatibler Fachsprachen aus einzelnen Disziplinen erfolgen (Bodden et al. 2013a), um Anforderungen an die Informationssicherheit effektiv spezifizieren zu können.

3.3.2 Formalisierung und Analyse von Sicherheitsrichtlinien

Nach dem Übergang vom disziplinübergreifenden in den disziplinspezifischen Entwurf ist die Softwarearchitektur (Garlan 2014) das früheste Stadium, in dem Aussagen über die Informationssicherheit getroffen werden können. Die Softwarearchitektur modelliert den strukturellen Aufbau des Softwareanteils eines Systems, sowie Bezüge zwischen verschiedenen Elementen innerhalb dieser Struktur. Das modellbasierte Vorgehen legt nahe, die Softwararchitektur mit einem Sicherheitsmodell (McLean et al. 2002) zu integrieren. Ein solches Modell ermöglicht die Formalisierung von Sicherheitsrichtlinien. Es kann so formal analysiert werden, ob die Softwarearchitektur den Anforderungen der Sicherheitsrichtlinie genügt. Durch eine wie in Abb. 3 dargestellte Architekturanalyse (Dobrica und Niemelä 2002) kann dann bereits vor der realen Implementierung des Systems eine Aussage darüber getroffen werden, ob die Softwarearchitektur bestimmte Eigenschaften der Informationssicherheit erfüllt. Sieht die Sicherheitsrichtlinie beispielsweise vor, dass keine Informationen vom Produktionsarbeiter zum Dienstmarkt fließen dürfen, so kann diese Eigenschaft durch ein geeignetes Sicherheitsmodell formalisiert und die Softwarearchitektur auf einen unzulässigen Informationsfluss hin untersucht werden. Um Architekturanalysen im Kontext sicherheitskritischer Systeme auszuführen, bieten Methoden der formalen Verifikation (Gabmeyer et al. 2017) gewisse Vorzüge gegenüber einer Simulation. Während in der Simulation nur ausgewählte Ausführungsszenarien eines Softwaresystems untersucht werden, beziehen formale Verifikationstechniken immer alle möglichen Systemzustände in die Analyse mit ein und können so umfassendere, fundierte Sicherheitsgarantien geben.

Um eine zielgenaue Analyse zu ermöglichen, muss jedoch nachverfolgbar sein, wie sich die Sicherheitsmodellierung zu der Sicherheitsrichtlinie verhält, die auf Ebene der Prinziplösung spezifiziert wurde. Durch die in Abb. 3 dargestellte Nachverfolgbarkeit zwischen Modellelementen der Prinziplösung sowie der Softwarearchitektur, können die Ergebnisse der Architekturanalyse in einen unmittelbaren Bezug zu den Anforderungen der Sicherheitsrichtlinie gesetzt werden. Somit können konkrete Aussagen darüber getroffen werden, ob die spezifizierten Anforderungen durch die Softwarearchitektur erfüllt oder verletzt werden.

3.3.3 Enforcing von Sicherheitsrichtlinien

Die Implementierung auf Codeebene muss sicherstellen, dass die spezifizierte Sicherheitsrichtlinie durch das finale Softwaresystem nicht außer Kraft gesetzt wird. Maßnahmen mit diesem Ziel werden als Enforcing der Sicherheitsrichtlinie bezeichnet (Schneider 2000). Hierbei ist der Einsatz einer Laufzeitüberwachung (Runtime Monitoring) möglich (Delgado et al. 2004), um das System während seiner Ausführung zu beobachten sowie Verletzungen der Sicherheitsrichtlinie zu identifizieren und zu verhindern. Als komplementärer Ansatz, der zudem dem Paradigma Security by Design entspricht, ist auch der Einsatz einer Codeanalyse (Binkley 2007) denkbar. Wie in Abb. 3 dargestellt, kann so der implementierte Code bereits vor seiner Ausführung auf Inkonsistenzen zur Sicherheitsrichtlinie hin untersucht und gegebenenfalls mit Hinweisen zur Fehlerbehebung ausgestattet werden. Im Sinne der Nachverfolgbarkeit muss an dieser Stelle erneut eine enge Kopplung mit der vorgelagerten Entwurfsebene ermöglicht werden. So müssen Ergebnisse der Codeanalyse in direkten Bezug zum Sicherheitsmodell auf Ebene der Softwarearchitektur gesetzt werden, so dass die Analyseergebnisse unmittelbare Erkenntnisse über die Erfüllung bzw. Verletzung der modellierten Sicherheitseigenschaften liefern können. Schließt die Softwarearchitektur beispielsweise einen Informationsfluss zwischen bestimmten Strukturelementen aus, so kann eine Verletzung dieser Eigenschaft durch einen unzulässigen Datenfluss auf Codeebene identifiziert werden.

Ebenfalls denkbar ist eine Automatisierung der manuellen Entwicklungsarbeiten durch eine eine automatische Codegenerierung (Czarnecki 2005). Wie in Abb. 3 dargestellt, kann so Programmcode erzeugt werden, der dem zuvor analysierten Sicherheitsmodell per Konstruktion genügt. Hierzu kann der Code einerseits so generiert werden, dass Unzulänglichkeiten (die andernfalls durch eine Codeanalyse aufgedeckt werden müssten) von vornherein ausgeschlossen sind. Andererseits kann der Programmcode durch die Generierung auch mit Codenanteilen angereichert werden, die eine Laufzeitüberwachung implementieren und so unsicheres Verhalten während der Ausführung identifizieren und verhindern.

4 Stand der Technik

In diesem Abschnitt werden vorhandene Methoden beleuchtet, die nach dem Paradigma Security by Design zu einer Nachverfolgbarkeit der Informationssicherheit beitragen können. Dazu erfolgt eine Bewertung der Anwendbarkeit im Umfeld der Industrie 4.0, sowie die Benennung offener Problemstellungen.

4.1 Bedrohungsmodellierung

Ein prominenter Vertreter im Kontext der Bedrohungsmodellierung ist der Ansatz STRIDE von Microsoft (Shostack 2014). Dieser umfasst eine Klassifizierung typischer Bedrohungssituationen in Form von sechs Kategorien:
  • Spoofing umfasst Bedrohungen, die durch Vortäuschung einer falschen Identität entstehen. Im Kontext der Industrie 4.0 besteht diese Art der Bedrohung beispielsweise dann, wenn die Identität eines vertrauenswürdigen Unternehmens vorgetäuscht wird um sich an dessen Daten zu bereichern.

  • Tampering ist eine Bedrohung durch unautorisierte Manipulation von Daten. Diese Form der Bedrohung ist im industriellen Kontext relevant, zum Beispiel wenn Unternehmensdaten zu Sabotagezwecken gezielt verfälscht werden.

  • Repudiation umschließt Bedrohungen, bei denen Akteure die Ausführung bestimmter Operationen im Nachhinein abstreiten können, da keine Möglichkeit des Nachweises besteht. Solche Szenarien sind aus dem Blickwinkel industrieller Unternehmen als besonders kritisch zu bewerten, da die Nachvollziehbarkeit der Entstehungshistorie jedes einzelnen Produktes (inklusive seiner einzelnen Produktionsschritte) ein zentrales Merkmal der Industrie 4.0 darstellt. Können jedoch Marktteilnehmer ihre Beteiligung an verteilten Produktionsprozessen erfolgreich verleugnen, um sich beispielsweise einer Regresspflicht zu entziehen, so wird die Nachweisbarkeit massiv in Frage gestellt.

  • Information Disclosure stellt eine Bedrohungssituation durch unautorisierten Zugriff auf bestimmte Informationsbereiche dar. Betroffen von solchen Bedrohungen können beispielsweise personenbezogene Mitarbeiterdaten oder Geschäftsgeheimnisse sein, die nicht von anderen Marktteilnehmern einsehbar sein sollen.

  • Denial of Service beschreibt Bedrohunsszenarien, in denen eine nach außen angebotene Funktionalität eines Systems außer Kraft gesetzt wird. Einer solchen Bedrohung können beispielsweise die nach außen hin angebotenen Produktiondienste eines Unternehmens ausgesetzt sein, etwa in Form mutwilliger Sabotageakte um den Marktzugang eines Wettbewerbers einzuschränken.

  • Elevation of Privilege bezieht sich schließlich auf die Ausweitung von Zugriffsrechten auf unzugängliche Systembereiche. Gerade der Aspekt der Zugriffsrechte und ihrer Einhaltung muss im Zuge der verstärkten Vernetzung industrieller Produktionsanlagen und der daraus resultierenden Vielzahl an zusätzlichen Kommunikationsschnittstellen völlig neu bewertet werden.

Gemessen an typischen, im Umfeld der Industrie 4.0 als kritisch aufgefassten Bedrohungsszenarien (Hertel 2015), weisen die Kategorien allesamt eine industrielle Relevanz auf. Die Klassifizierung ist so in der Lage, ein initiales Bewusstsein für die Bedrohungslage eines Systems zu schaffen. Dabei können das zu entwickelnde System bzw. einzelne Systemteile einer Beurteilung anhand der einzelnen Bedrohungskategorien unterzogen werden und so ein Prozess zum Schutz vor den identifizierten Bedrohungen angestoßen werden.

Aufgrund ihrer Abstraktheit und Allgemeinheit sind existierende Methoden der Bedrohungsmodellierung im Umfeld der Industrie 4.0 bereits grundsätzlich anwendbar. Gleichzeitig stellt sich der Stand der Technik als noch nicht ausgereift genug dar, um erprobte Lösungswege für konkrete, wiederkehrende Problemstellungen der Bedrohungsmodellierung aufzuzeigen. Da „keine allgemein anerkannte Herangehensweise“ (Bodden et al. 2013a) vorliegt, ist eine Vergleichbarkeit der verschiedenen Ansätze nicht gegeben. Dies führt zu der Situation, dass „intersubjektiv nachvollziehbare Ergebnisse“ (Bodden et al. 2013a) nicht erzielt werden können und somit ein erheblicher Forschungsbedarf besteht.

4.2 Sicherheitsmodellierung & Architekturanalyse

Als Grobstrukturierung eines Softwaresystems stellt die Softwarearchitektur einen ersten Ansatzpunkt für eine frühzeitige Analyse der Informationssicherheit dar. Mit der Unified Modeling Language (UML) existiert dabei ein De-facto-Standard für den modellbasierten Entwurf von Softwaresystemen und ihrer Architekturen (Object Management Group 2015). Jedoch verfügen oft weder Architekten noch Entwickler über die nötige Expertise, um der Informationssicherheit unter Einsatz der UML hinreichend Rechnung zu tragen. Selbst bei vorhandenem Expertenwissen wird Informationssicherheit oftmals als nachträglicher „Nebengedanke“ abgetan (Devanbu und Stubblebine 2000), da sie aufgrund ihres nichtfunktionalen Charakters als sekundär für die Nutzerakzeptanz gilt und sich daher vermeintlich Zeit und Kosten einsparen lassen.

Der Unzulänglichkeit der UML ungeachtet existiert ein großer Wissensbestand an formalen Sicherheitsmodellen (McLean et al. 2002). Diese zielen auf unterschiedliche Sicherheitseigenschaften wie zum Beispiel Zugriffskontrolle (Bell und LaPadula 1996; Biba 1975) oder Informationsflusskontrolle durch Noninterference (Goguen und Meseguer 1982) ab. Um Softwarearchitekturen hinsichtlicher solcher Eigenschaften analysierbar zu machen, müssen praxisrelevante Modellierungssprachen wie die UML mit der theorielastigen Sicherheitsmodellierung zusammengeführt werden. Mit UMLsec existiert eine Erweiterung der UML als Ansatz in diese Richtung (Jürjens 2005). UMLsec befähigt Softwarearchitekten, sicherheitsrelevante Aspekte in die Modellierung eines Systems zu integrieren. Darunter fallen zum Beispiel die Geheimhaltungsstufen bestimmter Informationen, eine Klassifizierung von Kommunikationsverbindungen anhand von Sicherheitsaspekten (z. B. lokale Netzwerke im Gegensatz zu öffentlichen Internetverbindungen), wie auch Sicherheitseigenschaften die das modellierte Softwaresystem einhalten muss. Um Aussagen über diese Eigenschaften treffen zu können, ermöglicht UMLsec auch die Modellierung etwaiger Angreifer. Diese Angreiferinformationen können in eine automatische Analyse der Modelle einfließen. Diese liefert Aussagen darüber, ob die modellierten Sicherheitsannahmen ausreichend sind, um die geforderten Sicherheitseigenschaften zu erfüllen.

Der Einsatz modellbasierter Methoden stellt sich als äußerst hilfreich dar, um den steigenden Anforderungen an die Informationssicherheit cyber-physischer Systeme nachzukommen (Nguyen et al. 2017). Jedoch hat UMLsec den Charakter einer Allzwecksprache, die nicht auf die spezifischen Eigenschaften einer bestimmten Anwendungsdomäne, wie z. B. der Industrie 4.0, zugeschnitten ist. Die Sicherheitsmodellierung muss diesem Aspekt jedoch Rechnung tragen und die spezifischen Eigenschaften cyber-physischer Produktionssysteme betrachten, damit die Analyse das reale System adäquat widerspiegelt. Eigene Forschungsarbeiten haben den Ansatz der MechatronicUML hervorgebracht (Schäfer und Wehrheim 2010), die eine Adaption der UML für den Einsatz im Umfeld cyber-physischer Systeme darstellt. Der Ansatz sieht jedoch keine spezifische Betrachtung der Informationssicherheit vor. Um im Kontext der Industrie 4.0 wahrheitsgetreue Architekturanalysen durchführen zu können, muss demnach eine Integration der Sicherheitsmodellierung (nach dem Vorbild von UMLsec) mit der domänenspezifischen Modellierung (nach .dem Vorbild von MechatronicUML) erfolgen. Zur Nachverfolgung der Informationssicherheit muss außerdem eine Integration der softwaretechnischen Architekturanalyse mit der Sicherheitsrichtlinie gewährlsietet sein, die auf Ebene des disziplinübergreifenden Systementwurfs spezifiziert wurde. Aus Anforderungen der Sicherheitsrichtlinie müssen konkrete Sicherheitseigenschaften abgeleitet werden, die auf Ebene der Softwarearchitektur analysierbar sind. Andererseits müssen die Analyseergebnisse wiederum Rückschlüsse darüber zulassen, ob die analysierte Softwarearchitektur die Anforderungen der Sicherheitsrichtlinie erfüllt, oder aber Schwachstellen offeriert. Vorstöße in diese Richtung sind bereits Gegenstand eigener Forschungsarbeiten (Gerking 2016).

4.3 Codegenerierung

Eine Codegenerierung muss sicherstellen, dass Annahmen der Sicherheitsmodellierung durch den erzeugten Programmcode nicht verletzt werden. Nur unter dieser Voraussetzung können sich Eigenschaften, die auf Modellebene nachgewiesen wurden, während der Ausführung des realen Systems bewahrheiten. Für das Enforcing der Sicherheitsrichtlinie ist diese Eigenschaft daher von essenzieller Wichtigkeit. Nicht umsonst unterliegen Codegeneratoren einer rigorosen Zertifizierung, um im Umfeld sicherheitskritischer Systeme zum Einsatz kommen zu können (Bärwald und Beine 2010).

Die Abstraktion der Modellierung (d. h. die Auslassung bestimmter Aspekte im Vergleich zum realen System) lässt jedoch einen Spielraum bei der Erzeugung des Programmcodes zu. Für Aspekte, die nicht Gegenstand der expliziten Modellierung sind, liegen dem Codegenerator keine unmittelbaren Vorgaben für die Umsetzung auf Codeebene vor. Existierende Verfahren beschränken sich so oftmals auf funktionale Aspekte, d. h. die Erhaltung der modellierten Systemfunktionalität. Nichtfunktionale Eigenschaften wie die Informationssicherheit sind oftmals nicht Teil der Modellierung und finden daher auch keine Berücksichtigung im erzeugten Code, der somit im Regelfall inhärent unsicher ist. Der vorgestellte Ansatz UMLsec schafft hier Abhilfe, indem die Informationssicherheit zum Gegenstand der Modellierung erhoben wird und entsprechende Codegenerierungsverfahren für sicherheitsrelevante Aspekte existieren, wie zum Beispiel die Zugriffskontrolle auf schutzbedürftige Ressourcen (Montrieux et al. 2010). Mit SecureUML (Basin et al. 2006) und ModelSec (Sánchez et al. 2009) liegen weitere Ansätze zur Modellierung sicherheitskritischer Systeme vor, die ebenfalls über Generierungsverfahren verfügen.

Andere Verfahren zur Absicherung von Programmcode setzen oft erst zu einem späteren Zeitpunkt des Entwicklungsprozesses an und zielen nicht auf die Generierung, sondern auf die Härtung des bereits vorliegenden Programmcodes ab. Damit kann beispielsweise ein Schutz vor bewusst hervorgerufenen Pufferüberläufen (Stack Smashing) in den Code integriert werden (Pincus und Baker 2004). Angriffe mit dem Ziel des Einschleusens von Schadcode können so automatisch erkannt und durch das Ergreifen entsprechender Gegenmaßnahmen verhindert werden.

Unter Umständen kann der generierte Programmcode jedoch das Enforcing komplexer Sicherheitsrichtlinien nicht gewährleisten. Dies ist der Fall, wenn unsicheres Ausführungsverhalten nicht gänzlich verhindert werden kann. An dieser Stelle kommen Maßnahmen zur Laufzeitüberwachung des Systems zum Tragen, deren theoretische Grundlagen in ausgereifter Form vorliegen (Schneider 2000; Gay et al. 2012). Einen fortschrittlichen Ansatz zur Laufzeitüberwachung stellt die Auswertung von Prozessdaten dar, die eine automatisierte Anomalieerkennung (Chandola et al. 2009) nahelegen. Diese kann in Form von Angrifferkennungssystemen (Intrusion Detection Systems) genutzt werden, um Angriffe zur Laufzeit zu erkennen und abzuwehren (Lunt 1993). Da Prozessdaten im digitalisierten Kontext der Industrie 4.0 massiv anfallen, könnte erfolgreichen Angriffen auf dieser Basis noch effektiver entgegen gewirkt werden (Bachlechner et al. 2016; Niggemann und Frey 2015).

Jedoch fordern die oben genannten Maßnahmen zur Laufzeitüberwachung den Softwareentwicklern ein erhöhtes Maß an Expertise ab, wenn sie in gängigen Programmiersprachen manuell implementiert werden müssen. Wie in eigenen Forschungsarbeiten untersucht (Bodden et al. 2013b), weisen die Sicherheitsmechanismen dieser Sprachen oft eine hohe Komplexität auf, die zu Überforderung und Scheitern seitens der Softwareentwickler führen kann. Um auch weniger geschulte Entwickler zu unterstützen, muss die korrekte Implementierung von Schutzmaßnahmen daher verstärkt durch Codegenerierungen unterstützt werden. Entwickler könnten so automatisch Programmcode erzeugen, der die Umsetzung der Sicherheitsrichtlinie sicherstellt.

Dabei stellt eine Codegenerierung grundsätzlich eine Verfeinerung des Systems gegenüber der Softwarearchitektur dar. Existierende Sicherheitsmodelle können jedoch in der Regel nicht garantieren, dass Sicherheitseigenschaften durch eine Verfeinerung des Systemverhaltens erhalten werden (Mantel 2001). Dieses offene Grundsatzproblem wird als Refinement Paradox bezeichnet und stellt eine inhärente Herausforderung für die Generierung sicheren Programmcodes dar.

4.4 Codeanalyse

Statische Codeanalysen (Zheng et al. 2006) bieten die Möglichkeit, vorliegenden Programmcode auf Defizite im Umgang mit der Informationssicherheit zu überprüfen. Dabei bezieht die Analyse alle möglichen Ausführungspfade eines Programms mit ein und abstrahiert somit auch von den konkreten Nutzereingaben. Dadurch wird auch ein eventuelles Angreiferverhalten umfasst und kann durch die Analyse aufgedeckt werden. Codeanalysen liegen bereits in einer ausgereiften Form vor (Bodden et al. 2013a) und stellen somit ein mächtiges Instrument dar, um Verletzungen von Sicherheitsrichtlinien aufzudecken und Konsistenz zwischen Programmcode und Sicherheitsmodellierung zu gewährleisten.

In der industriellen Praxis stehen dennoch einzelne Aspekte einer Anwendung von statischen Codeanalysen entgegen. Da der Informationssicherheit im industriellen Umfeld lange keine hohe Priorität beigemessen wurde, zielen vorhandene Ansätze überwiegend auf Programmiersprachen ab, die für die Steuerung von Industrieanlagen nicht eingesetzt werden. Erste Ansätze existieren jedoch auch für die Codeanalyse von Sprachen, die im industriellen Kontext relevant sind (Prähofer et al. 2017). Außerdem ziehen die Systeme der Industrie 4.0 ein neues Ausmaß an Komplexität und Umfang des Programmcodes nach sich. Die Skalierbarkeit der Analysemethoden für reale Systemgrößen steht somit in Frage, so dass ein zusätzlicher Forschungsaufwand geleistet werden muss, um Codeanalysen effizient anwenden zu können. Eine zusätzliche Problemstellung ergibt sich durch die Vernetzung der Systeme und die daraus resultierende Verteilung des relevanten Programmcodes. Erste Lösungsideen zur Bewältigung dieser Herausforderung existieren (Ghassemi et al. 2017), während eine Umsetzung in Form industriell einsetzbarer Softwarewerkzeuge noch aussteht. Darüber hinaus erwächst aus der Verteilung des Programmcodes zusätzlich die Fragestellung, ob überhaupt alle Teile des Codes für die Analyse zugänglich sind. Kompositionale Methoden der Codeanalyse werden erforderlich sein, um das Verhalten eines Gesamtsystems zu analysieren, auch ohne auf alle Teile des Codes unmittelbar zugreifen zu können.

Im Zuge der Nachverfolgung der Informationssicherheit müssen Codeanalysen zudem stärker mit einer vorangehenden Sicherheitsmodellierung integriert werden. Vorliegende Regelsätze stellen oftmals allgemeingültige, jedoch unpräzise Anforderungen dar und stehen in keinem Zusammenhang zu konkreten Annahmen an die Informationssicherheit, die während der Sicherheitsmodellierung getroffen wurden. Erstrebenswert ist vielmehr eine Ableitung der auf Codeebene zu überprüfenden Anforderungen aus den zuvor modellierten Sicherheitseigenschaften, um Abweichungen zwischen Programmcode und Modellierung durch den Einsatz der Codeanalyse aufdecken zu können. Nur wenn der Programmcode frei von solchen Abweichungen ist, können sich die während der Architekturanalyse prognostizierten Sicherheitseigenschaften für das reale System bewahrheiten.

5 Fazit

Die unternehmensübergreifende Vernetzung von Produktionsanlagen in der Industrie 4.0 steht im Kontrast zur Wahrung der Sicherheit sensitiver Informationen und insbesondere personenbezogener Mitarbeiterdaten. Konzepte der IT-Sicherheit gelten daher als kritischer Erfolgsfaktor für Unternehmen, die sich der industriellen Vernetzung öffnen. Dieser Beitrag nimmt den Blickwinkel der Systementwicklung ein und beschreibt einen Entwurfsansatz für cyber-physische Produktionssysteme gemäß dem modellbasierten Systems Engineering. Mit dem Ziel einer nachverfolgbaren Informationssicherheit werden gezielt softwaretechnische Methoden in die unterschiedlichen Entwurfs- und Entwicklungsphasen des Systems Engineerings integriert und zueinander in Bezug gesetzt. Diese Integration zielt auf eine effektive Spezifikation zielgerichteter Anforderungen, sowie auf eine durchgängige Nachverfolgung entsprechender Schutzmaßnahmen in den nachgelagerten Modellierungsund Implementierungsschritten ab. Gemäß dem Paradigma Security by Design kann so ein Beitrag zu einer frühzeitigen Identifikation von Schwachstellen sowie der Einleitung adäquater Gegenmaßnahmen noch vor Inbetriebnahme eines Systems geleistet werden. Unternehmen sowie ihre Mitarbeiterinnen und Mitarbeiter profitieren gleichermaßen von einer frühzeitigen Fehlerbehandlung, indem Schwachstellen nicht erst im kritischen Fehlerfall während des laufenden Betriebes erkannt werden.

Zukünftige Forschungsarbeiten müssen sich mit der Integration der vorgeschlagenen Entwurfsmethodik in praxisrelevante Entwicklungsprozesse befassen, zum Beispiel aus dem Kontext der agilen Softwareentwicklung. Insbesondere muss die Nachverfolgbarkeit zwischen den verschiedenen Entwicklungsphasen durch geeignete Werkzeugintegrationen sichergestellt werden, um die Hemmschwelle für die Einführung in der industriellen Praxis zu senken.

Weiterhin stellt sich der Themenkomplex der Informationssicherheit für die Systeme der Industrie 4.0 als zu vielschichtig dar, um alleine durch Maßnahmen während des Entwurfs nachhaltig gelöst zu werden. So greifen die Maßnahmen nach dem Paradigma Security by Design nur dann, wenn Systeme im Anwendungsfeld so konfiguriert werden, dass die tatsächliche Ausführungsumgebung der zuvor in Betracht gezogenen Bedrohungslage entspricht. Nur unter dieser Voraussetzung bieten die im Entwurf getroffenen Vorkehrungen einen effektiven Schutz über den kompletten Lebenszyklus eines Systems. Eine besondere Herausforderung stellt hierbei die Evolution der Ausführungsumgebung von Systemen (Seifermann et al. 2016) dar. Solche Fälle müssen erkannt werden und eine erneute Beurteilung der Bedrohungslage nach sich ziehen, um den Systemschutz zu erhalten.

Ebenso müssen Forschungsarbeiten verstärkt eine Integration von Schutzmaßnahmen verschiedener Disziplinen fokussieren. Beispielsweise müssen auch physikalische Angriffe sowie entsprechende mechanische Schutzmaßnahmen ins Auge gefasst werden, um im Zusammenspiel mit softwaretechnischen Maßnahmen einen ganzheitlichen Systemschutz zu gewährleisten. Die Betrachtung der Informationssicherheit über den gesamten Lebenszyklus hinweg, unter Einbeziehung aller beteiligter Fachdisziplinen, ist unerlässliche Voraussetzung für eine sichere Beteiligung an den erfolgversprechenden Wertschöpfungsnetzwerken der Industrie 4.0.

Fußnoten

  1. 1.

    CONceptual design Specification technique for the ENgineering of complex Systems.

Literatur

  1. acatech. (Hrsg.). (2011). Cyber-Physical Systems. Innovationsmotoren für Mobilität, Gesundheit, Energie und Produktion. (acatech POSITION 11). Berlin/Heidelberg: Springer. ISBN : 978-3-642-27566-1.Google Scholar
  2. Alt, O. (2014). Modellbasiertes Systems Engineering und seine Technologien als Schlüssel für Industrie 4.0. In M. Maurer und S.-O. Schulze (Hrsg.), Tag des Systems Engineering, Bremen, 12.–14. Nov. 2014 (S. 1–9). München: Carl Hanser. ISBN: 978-3-446-44357-0.Google Scholar
  3. Bachlechner, D. et al. (Hrsg.).(2016). IT-Sicherheit für die Industrie 4.0. Produktion, Produkte, Dienste von morgen im Zeichen globalisierter Wertschöpfungsketten. Abschlussbericht. Bundesministerium für Wirtschaft und EnergieGoogle Scholar
  4. Bärwald, A., & Beine, M. (2010). Sichere Codegenerierung. Modellbasierte Entwicklung sicherheitskritischer Systeme. Hanser Automotive, 2(1–2), 30–33.Google Scholar
  5. Basin, D. A., Doser, J., & Lodderstedt, T. (2006). Model driven security. From UML models to access control infrastructures. ACM Transactions on Software Engineering and Methodology, 15(1), 39–91.CrossRefGoogle Scholar
  6. Bedner, M., & Ackermann, T. (2010). Schutzziele der IT-Sicherheit. Datenschutz und Datensicherheit – DuD, 34(5), 323–328.CrossRefGoogle Scholar
  7. Bell, D. E., & LaPadula, L. J. (1996). Secure computer systems. A mathematical model. Journal of Computer Security, 4(2–3), 229–263.Google Scholar
  8. Biba, K. J. (1975). Integrity considerations for secure computer systems. Techn. Ber. MTR-3153. MITRE Corporation.Google Scholar
  9. Binkley, D. (2007). Source code analysis: A road map. In L. C. Briand & A. L. Wolf (Hrsg.), Future of software engineering, FOSE 2007, Minneapolis, 23.–25. Mai 2007 (S. 104–119). Los Alamitos: IEEE Computer Society. ISBN: 0-7695-2829-5.Google Scholar
  10. Bodden, E., et al. (2013a). In M. Waidner, M. Backes & J. Müller-Quade (Hrsg.), Entwicklung sicherer Software durch Security by Design. Trend- und Strategiebericht (SIT Technical Reports SIT-TR-2013-01). Stuttgart: Fraunhofer. ISBN: 978-3-8396-0567-7.Google Scholar
  11. Bodden, E., Hermann, B., Lerch, J., & Mezini, M. (2013b). Reducing human factors in software security architectures. In M. Lauster (Hrsg.), 8th future security. Security research conference. Proceedings, Berlin, 17.–19. Sep. 2013 (S. 275–285). Stuttgart: Fraunhofer. ISBN: 978-3-8396-0604-9.Google Scholar
  12. Bohner, S. A. (2002). Software change impacts. An evolving perspective. In International conference on software maintenance. Proceedings, ICSM 2002. Maintaining Distributed Heterogeneous Systems, Montreal, 3.–6. Okt. 2002 (S. 263–272). Los Alamitos: IEEE Computer Society. ISBN: 0-7695-1819-2.Google Scholar
  13. Breu, R., Sillaber, C., & Brunner, M. (2016). Security im Produkt-Lifecycle. Lästige Pflicht oder Chance? Informatik-Spektrum, 39(5), 353–361.Google Scholar
  14. Bundesamt für Sicherheit in der Informationstechnik. (2016). Zertifizierte IT-Sicherheit. Prüfstandards für IT-Sicherheit, Technische Richtlinien und Schutzprofile. Konformitätsbewertung, Zertifizierung und Anerkennung. Bonn.Google Scholar
  15. Chandola, V., Banerjee, A., & Kumar, V. (2009). Anomaly detection. A survey. ACM Computing Surveys, 41(3), 15.1–15.8.Google Scholar
  16. Cleland-Huang, J., Gotel, O., & Zisman, A. (Hrsg.). (2012). Software and systems traceability. Mit einem Vorw. von A. Finkelstein. London: Springer. ISBN: 978-1-4471-2238-8.Google Scholar
  17. Czarnecki, K. (2005). Overview of generative software development. In J. Banâtre, P. Fradet, J. Giavitto & O. Michel (Hrsg.), Unconventional programming paradigms. Revised selected and invited papers, International workshop UPP 2004, Le Mont Saint Michel, 15.–17. Sep. 2004. (Lecture notes in computer science, Bd. 3566, S. 326–341). Berlin/Heidelberg: Springer. ISBN: 3-540-27884-2.Google Scholar
  18. Delgado, N., Gates, A. Q., & Roach, S. (2004). A taxonomy and catalog of runtime software-fault monitoring tools. IEEE Transactions on Software Engineering, 30(12), 859–872.CrossRefGoogle Scholar
  19. Devanbu, P. T., & Stubblebine, S. G. (2000). Software engineering for security. A roadmap. In A. Finkelstein (Hrsg.), The future of software engineering, 22nd international conference on software engineering, Limerick, 4.–11. Juni 2000 (S. 227–239). New York: ACM. ISBN: 1-58113-253-0.Google Scholar
  20. Diedrich, C., Meyer, M., Evertz, L., & Schäfer, W. (2014). Dienste in der Automatisierungstechnik. atp edition – Automatisierungstechnische Praxis, 56(12), 24–35.CrossRefGoogle Scholar
  21. Dobrica, L., & Niemelä, E. (2002). A survey on software architecture analysis methods. IEEE Transactions on Software Engineering, 28(7), 638–653.CrossRefGoogle Scholar
  22. Dumitrescu, R., Bremer, C., Kühn, A., Trächtler, A., & Frieben, T. (2015). Modellbasierte Entwicklung von Produkten, Prozessen und Produktionsressourcen. Ein zustandsorientierter Ansatz für ein integriertes Systemmodell von Objekten, Prozessen und Systemen. at – Automatisierungstechnik. Methoden und Anwendungen der Steuerungs-, Regelungs und Informationstechnik, 63(10), 844–857.Google Scholar
  23. Eckert, C., & Fallenbeck, N. (2015). Industrie 4.0 meets IT-Sicherheit. Eine Herausforderung! Informatik-Spektrum, 38(3), 217–223.CrossRefGoogle Scholar
  24. Gabmeyer, S., Kaufmann, P., Seidl, M., Gogolla, M., & Kappel, G. (2017). A feature-based classification of formal verification techniques for software models. Software & Systems Modeling. https://doi.org/10.1007/s10270-017-0591-z.
  25. Garlan, D. (2014). Software architecture. A travelogue. In J. D. Herbsleb & M. B. Dwyer (Hrsg.), Future of software engineering. Proceedings, FOSE 2014, Hyderabad, 31. Mai–7. Juni 2014 (S. 29–39). New York: ACM. ISBN: 978-1-4503-2865-4.Google Scholar
  26. Gausemeier, J., Frank, U., Donoth, J., & Kahl, S. (2008). Spezifikationstechnik zur Beschreibung der Prinziplösung selbstoptimierender Systeme des Maschinenbaus (Teil 2). Konstruktion – Zeitschrift für Produktentwicklung und Ingenieur-Werkstoffe, 9, 4.Google Scholar
  27. Gausemeier, J., Dumitrescu, R., Steffen, D., Czaja, A. M., Tschirner, C., & Wiederkehr, O. (2013a). Systems Engineering in der industriellen Praxis. In Tag des Systems Engineering, 7.–9. Nov. 2013. München: Carl Hanser. ISBN: 978-3-446-43946-7.Google Scholar
  28. Gausemeier, J., Tschirner, C., & Dumitrescu, R. (2013b). Der Weg zu Intelligenten Technischen Systemen. Industrie Management, 29(1), 49.Google Scholar
  29. Gausemeier, J., Klocke, F., Dülme, C., Eckelt, D., Kabasci, P., Kohlhuber, M., Schön, N., & Schröder, S. (2016). Industrie 4.0. Internationaler Benchmark, Zukunftsoptionen und Handlungsempfehlungen für die Produktionsforschung. Paderborn und Aachen: Heinz Nixdorf Institut, Universität Paderborn und Werkzeugmaschinenlabor WZL der Rheinisch-Westfälischen Technischen Hochschule Aachen. ISBN: 978-3-942044-87-5.Google Scholar
  30. Gay, R., Mantel, H., & Sprick, B. (2012). Service automata. In G. Barthe, A. Datta & S. Etalle (Hrsg.), Formal aspects of security and trust. Revised selected papers, 8th international workshop, FAST 2011, Leuven, 12.–14. Sep. 2011. (Lecture notes in computer science, Bd. 7140, S. 148–163). Berlin/Heidelberg: Springer. ISBN: 978-3-642-29419-8.Google Scholar
  31. Gerking, C. (2016). Traceability of information flow requirements in cyber-physical systems engineering. In S. Nejati & R. Salay (Hrsg.), MoDELS-DS 2016. Doctoral symposium at MoDELS 2016. Proceedings of the Doctoral symposium at the 19th ACM/IEEE international conference of model-driven engineering languages and systems 2016 (MoDELS 2016), Saint Malo, 2. Okt. 2016. CEUR workshop proceedings 1735.Google Scholar
  32. Ghassemi, F., Meyer, M., Pohlmann, U., & Priesterjahn, C. (2017). Verteilte statische Analyse zur Identifikation von kritischen Datenflüssen für vernetzte Automatisierungs- und Produktionssysteme. In E. Bodden, F. Dressler, R. Dumitrescu, J. Gausemeier, F. Meyer auf der Heide, C. Scheytt & A. Trächtler (Hrsg.), Wissenschaftsforum Intelligente Technische Systeme (WInTeSys) 2017, Paderborn, 11.–12. Mai 2017. (Verlagsschriftenreihe des Heinz Nixdorf Instituts, Bd. 369, S. 373–384). Heinz Nixdorf Institut, Universität Paderborn. ISBN: 978-3-942-647-88-5.Google Scholar
  33. Goguen, J. A., & Meseguer, J. (1982). Security policies and security models. In IEEE. symposium on security and privacy, Oakland, 26.–28. Apr. 1982 (S. 11–20). Los Alamitos: IEEE Computer Society. ISBN: 0-8186-0410-7.Google Scholar
  34. Gorecky, D., Schmitt, M., & Loskyll, M. (2014). Mensch-Maschine-Interaktion im Industrie 4.0-Zeitalter. In T. Bauernhansl, M. ten Hompel & B. Vogel-Heuser (Hrsg.), Industrie 4.0 in Produktion, Automatisierung und Logistik. Anwendung · Technologien · Migration (S. 525–542). Springer Vieweg: Wiesbaden. ISBN: 978-3-658-04681-1.CrossRefGoogle Scholar
  35. Haley, C. B., Laney, R. C., Moffett, J. D., & Nuseibeh, B. (2008). Security requirements engineering. A framework for representation and analysis. IEEE Transactions on Software Engineering, 34(1), 133–153.CrossRefGoogle Scholar
  36. Hänisch, T., & Rogge, S. (2017). IT-Sicherheit in der Industrie 4.0. In V. P. Andelfinger & T. Hänisch (Hrsg.), Industrie 4.0. Wie cyber-physische Systeme die Arbeitswelt verändern (S. 91–98). Springer Fachmedien: Wiesbaden. ISBN: 978-3-658-15557-5.Google Scholar
  37. Hedin, D., & Sabelfeld, A. (2012). A perspective on information-flow control. In T. Nipkow, O. Grumberg & B. Hauptmann (Hrsg.), Software safety and security. Tools for analysis and verification (NATO science for peace and security series D: Information and communication security, Bd. 33, S. 319–347). Washington, DC: IOS Press. ISBN: 978-1-61499-027-7.Google Scholar
  38. Hertel, M. (2015). Risiken der Industrie 4.0. Eine Strukturierung von Bedrohungsszenarien der Smart Factory. HMD – Praxis der Wirtschaftsinformatik, 52(5), 724–738.CrossRefGoogle Scholar
  39. Junker, H. (2015). IT-Sicherheit für Industrie 4.0 und IoT. Datenschutz und Datensicherheit – DuD, 39(10), 647–651.CrossRefGoogle Scholar
  40. Jürjens, J. (2005). Secure systems development with UML. Berlin/Heidelberg: Springer. ISBN: 978-3-540-00701-2.Google Scholar
  41. Kagermann, H., Lukas, W.-D., & Wahlster, W. (2011). Industrie 4.0. Mit dem Internet der Dinge auf dem Weg zur 4. industriellen Revolution. VDI nachrichten, 2011(13), 2.Google Scholar
  42. Kagermann, H., Helbig, J., Hellinger, A., & Wahlster, W. (2013). Umsetzungsempfehlungen für das Zukunftsprojekt Industrie 4.0. Deutschlands Zukunft als Produktionsstandort sichern. Abschlussbericht des Arbeitskreises Industrie 4.0. Promotorengruppe Kommunikation der Forschungsunion Wirtschaft – Wissenschaft und acatech – Deutsche Akademie der Technikwissenschaften.Google Scholar
  43. Kagermann, H., Riemensperger, F., Hoke, D., Helbig, J., Stocksmeier, D., Wahlster, W., Scheer, A.W., & Schweer, D. (2014). Smart Service Welt. Umsetzungsempfehlungen für das Zukunftsprojekt Internetbasierte Dienste für die Wirtschaft. Arbeitskreis Smart Service Welt und acatech – Deutsche Akademie der Technikwissenschaften.Google Scholar
  44. Kobes, P. (2016). Leitfaden Industrial Security. IEC 62443 einfach erklärt. Berlin/Offenbach: VDE Verlag. ISBN: 978-3-8007-4165-6.Google Scholar
  45. Lass, S., & Kotarski, D. (2014). IT-Sicherheit als besondere Herausforderung von Industrie 4.0. In W. Kersten, H. Koller & H. Lödding (Hrsg.), Industrie 4.0. Wie intelligente Vernetzung und kognitive Systeme unsere Arbeit verändern. Schriftenreihe der Hochschulgruppe für Arbeits- und Betriebsorganisation e.V. (HAB) (S. 397–419). Berlin: GITO.Google Scholar
  46. Lunt, T. F. (1993). A survey of intrusion detection techniques. Computers & Security, 12(4), 405–418.CrossRefGoogle Scholar
  47. Mantel, H. (2001). Preserving information flow properties under refinement. In 2001 IEEE. symposium on security and privacy, Oakland, 14.–16. Mai 2001 (S. 78–91). Los Alamitos: IEEE Computer Society. ISBN: 0-7695-1046-9.Google Scholar
  48. McLean, J., Schell, R. R., & Brinkley, D. L. (2002). Security Models. In J. J. Marciniak (Hrsg.), Encyclopedia of Software Engineering. New York: Wiley. ISBN: 978-0-471-37737-5.Google Scholar
  49. Montrieux, L., Jürjens, J., Haley, C. B., Yu, Y., Schobbens, P., & Toussaint, H. (2010). Tool support for code generation from a UMLsec property. In C. Pecheur, J. Andrews & E. D. Nitto (Hrsg.), ASE 2010, 25th IEEE/ACM international conference on automated software engineering, Antwerpen, 20.–24. Sep. 2010 (S. 357–358). New York: ACM. ISBN: 978-1-4503-0116-9.Google Scholar
  50. Nguyen, P.H., Ali, S., & Yue, T. (2017). Model-based security engineering for cyber-physical systems. A systematic mapping study. Information & Software Technology, 83, 116–135.Google Scholar
  51. Niggemann, O., & Frey, C. (2015). Datengetriebene Anomalieerkennung in Cyber-Physischen Produktionssystemen. at – Automatisierungstechnik. Methoden und Anwendungen der Steuerungs-, Regelungs und Informationstechnik, 63(10.): Industrie 4.0. J. Beyerer, J. Jasperneite und O. Sauer (Hrsg.), 821–832.Google Scholar
  52. Object Management Group. (2015). OMG Unified Modeling Language (OMG UML). formal/März 2015. Version 2.5.Google Scholar
  53. Paelke, V., & Röcker, C. (2015). User Interfaces for cyber-physical systems. Challenges and possible approaches. In A. Marcus (Hrsg.), Design, user experience, and usability. Design discourse, 4th international conference, DUXU 2015. Proceedings, Part I, Los Angeles, 2.–7. Aug. 2015. (Lecture notes in computer science, Bd. 9186, S. 75–85). Cham: Springer. ISBN: 978-3-319-20885-5.Google Scholar
  54. Pincus, J. D., & Baker, B. (2004). Beyond stack smashing. Recent advances in exploiting buffer overruns. IEEE Security and Privacy, 2(4), 20–27.CrossRefGoogle Scholar
  55. Prähofer, H., Angerer, F., Ramler, R., & Grillenberger, F. (2017). Static code analysis of IEC 61131-3 programs. Comprehensive tool support and experiences from large-scale industrial application. IEEE Transactions on Industrial Informatics, 13(1), 37–47.CrossRefGoogle Scholar
  56. Sánchez, Ó., Molina, F., García-Molina, J., & Toval, A. (2009). ModelSec. A generative Architecture for model-driven security. Journal of Universal Computer Science, 15(15), 2957–2980.Google Scholar
  57. Schäfer, W., & Wehrheim, H. (2010). Model-driven development with MechatronicUML. In G. Engels, C. Lewerentz, W. Schäfer, A. Schürr & B. Westfechtel (Hrsg.), Graph transformations and model-driven engineering (Lecture notes in computer science, Bd. 5765, S. 533–554). Berlin/Heidelberg: Springer. ISBN: 978-3-642-17321-9.CrossRefGoogle Scholar
  58. Schneider, F. B. (2000). Enforceable security policies. ACM Transactions on Information and System Security, 3(1), 30–50.CrossRefGoogle Scholar
  59. Schneider, F. B. (2012). Blueprint for a science of cybersecurity. The Next Wave, 19(2), 47–57.Google Scholar
  60. Seifermann, S., Taspolatoglu, E., Reussner, R. H., & Heinrich, R. (2016). Challenges in secure software evolution. The role of software architecture. Softwaretechnik-Trends, 36(1), 8–11Google Scholar
  61. Shostack, A. (2014). Threat Modeling. Designing for Security. Indianapolis: Wiley. ISBN: 978-1-118-80999-0.Google Scholar
  62. Sünnetcioglu, A., Brandenburg, E., Auricht, M. & Stark, R. (2014). Durchgängiger Traceability-Prozess im Systems Engineering. In M. Maurer & S.-O. Schulze (Hrsg.), Tag des Systems Engineering, Bremen, 12.–14. Nov. 2014 (S. 133–142). München: Carl Hanser. ISBN: 978-3-446-44357-0.Google Scholar
  63. Winzer, P., Schnieder, E., & Bach, F.-W. (Hrsg.). (2010). Sicherheitsforschung. Chancen und Perspektiven (acatech DISKUTIERT). Berlin/Heidelberg: Springer. ISBN: 978-3-642-04980-4.Google Scholar
  64. Zheng, J., Williams, L. A., Nagappan, N., Snipes, W., Hudepohl, J. P., & Vouk, M. A. (2006). On the value of static analysis for fault detection in software. IEEE Transactions on Software Engineering, 32(4), 240–253.CrossRefGoogle Scholar

Copyright information

© Springer-Verlag GmbH Deutschland 2018

Authors and Affiliations

  • Christopher Gerking
    • 1
    Email author
  • Eric Bodden
    • 2
  • Wilhelm Schäfer
    • 3
  1. 1.Fachgruppe SoftwaretechnikUniversität Paderborn, Heinz Nixdorf InstitutPaderbornDeutschland
  2. 2.Fachgruppe SoftwaretechnikFraunhofer IEM & Universität Paderborn, Heinz Nixdorf InstitutPaderbornDeutschland
  3. 3.Universität PaderbornPaderbornDeutschland

Personalised recommendations