Unterhält man sich mit IT-Security Experten bleiben oft zwei Eindrücke hängen: Schwarzmalerei und eine gewisse Überschätzung, die IT-Security stünde im Mittelpunkt des Universums. Dies äußert sich zum Beispiel in der blinden Anwendung von IT-Vorgehensweisen, z.B. ISO 27000 bzw. Grundschutz, auf Produktionsumgebungen. Selbst grundlegende Dinge wie Funktionale Sicherheit (IEC61508 und abgeleitete Normen) sind oft schlichtweg unbekannt. Kommt dann noch eine fehlende Unterscheidung zwischen Safety und Security hinzu, verhärten sich womöglich die Fronten von Anfang an. Doch im Zuge von Smart Factory, Industrie 4.0 und (I)IoT müssen Produktion und IT, und damit IT-Security, zusammenarbeiten. Aber wie wichtig ist IT(-Security)? Nachdem das Thema IT in der Produktion lange Zeit eher diffus reguliert war, gibt es seit einiger Zeit vermehrt Vorgaben, Richtlinien und Normen, die den Umfang, den Stellenwert aber auch die Anforderungen an IT-Security im Produktionsumfeld klarer formulieren. Im Rahmen des Vortrags werden wir sowohl einen kurzen historischen Abriss auf das Spannungsfeld von Safety und Security werfen – insbesondere um die heutige Situation und „Gemütslage“ von Beteiligten zu verstehen. Wichtiger ist aber der Blick in die Zukunft, bei der aktuelle Normen und Richtlinien immer klarer die Rolle und Wichtigkeit der IT-Security in der Produktion definieren – aber auch deren Grenzen und Verantwortlichkeiten. Damit einher geht auch ein Blick auf aktuell verfügbare Technologien, Lösungen und Prozesse, um IT-Security sinnvoll in bestehende und neue Anlagen zu integrieren.

Derzeit gibt es eine kontroverse Diskussion um eine sinnvolle und effektive Behandlung von Security-Risiken für Produkte und Systeme. Der Vortrag beleuchtet mögliche Ansätze und vergleicht diese mit den Empfehlungen des Rahmenwerkes zu Safety / Security der IEC TR 63069.

Safety 4.0 macht sichere Prozesse bei der Produktentwicklung notwendig. Die IEC 62443-4-1 legt die Prozessanforderungen für die sichere Entwicklung von Produkten fest, die in industriellen Automatisierungs- und Steuerungssystemen verwendet werden. Diese Spezifikation ist Teil einer Reihe von Normen, die sich mit dem Thema Sicherheit für die Industrielle Automatisierungs- und Steuerungssysteme (IACS) befassen. Daher hat Pilz seine Produktentwicklung unter dem Gesichtspunkt der Security in einem TÜV-zertifizierten Prozess weiterentwickelt. Dabei werden von vornherein Aspekte wie Bedrohungsszenarien, Stärken und Schwachstellen von Protokollen oder Verschlüsselungsverfahren berücksichtigt.

Die internationalen Standards IEC 61511 und IEC 61508 fordern eine Risikoanalyse auch für Security. Im Gegensatz zu Safety sind Security-Risiken jedoch weniger gut statistisch fassbar. Wie lässt sich die Security-Risikoanalyse trotzdem technisch fundiert und pragmatisch umsetzen? Und wie betrachtet man sowohl Safety- als auch und Security-Risiken, ohne redundante Arbeit zu machen? Das im Vortrag vorgestellte Layered-Blueprints-Denkmodell gibt Antworten und zeigt, was Security von der Safety lernen kann. Es wurde entwickelt, damit PLT-Ingenieure Verantwortung für die Security ihrer Systeme selbst übernehmen, Security-Probleme und -Ziele selbst definieren sowie verschiedene Security-Lösungen selbst vergleichen, bewerten und in den Betrieb integrieren können. Das Denkmodell basiert auf vier Etagen eines Turms. Jede Etage funktioniert nur auf Basis der darunterliegenden, und das Erklimmen jeder Etage verschafft zusätzlichen Überblick sowie zusätzliche Security. Die vier Etagen stehen für Funktion, Risiko, Anforderung und Implementierung. Das Turmmodell strukturiert und systematisiert Security Engineering, gibt jedoch nicht die konkrete Methode für die einzelnen Etagen vor. Es soll vielmehr helfen, unterschiedliche Methoden und deren Ergebnisse zu vergleichen, zu diskutieren und einzubinden. Der Fokus liegt dabei auf der technischen Analyse und Definition der sicherzustellenden Funktionalität eines Automatisierungsnetzes. Sie beginnt mit der Erstellung eines Netzmodells, das die Komplexität des real betrachteten Netzwerks auf die für die Security relevanten Aspekte reduziert und gleichzeitig alle Annahmen für die weitere Betrachtung explizit macht.

Der Vortrag fokussiert auf die Wünsche und Probleme in Alltag eines Maschinenbauers oder Betreibers und zeigt anhand konkreter Beispiele auf, welche praktische Anforderungen an sichere Bewegungen aus applikativer (z.B. gefährlichen Betrieb vermeiden) und konstruktiver Sicht (z.B. kein Platz für Drehgeber) gestellt werden. In einem nächsten Schritt wird analysiert mit welchen sicheren Antriebsfunktionen welche der Anforderungen grundsätzlich lösbar sind. Da die technischen Anforderungen an die einzelnen sicheren Antriebsfunktionen stark variieren, zeigt der Referent zudem auf, welche Konsequenzen sich daraus aus normativer und konstruktiver Sicht ergeben - für Sensorik, Logik sowie die Abschaltmechanismen der Antriebe. Nicht zuletzt geht er auf die in der Praxis immer wieder auftauchenden technologischen Grenzen von Überwachungsmechanismen ein und stellt in diesem Kontext mögliche Abwägungen zwischen Aufwand, Sicherheitslevel, Reaktionsgeschwindigkeit und Verfügbarkeit dar.

In der Mensch-Roboter-Kollaboration und in den Zukunftsszenarien dynamisch variabler Produktionsumgebungen sind angepasste Implementierungskonzepte zur Gewährleistung von Safety notwendig, da der klassische Zaun entfällt. Die im Rahmen des Forschungsprojekts „Roboshield“ entwickelten Safety Devices bieten eine – zu den Standard-Kommunikationskanälen – unabhängige Infrastruktur für die Verteilung von Not-Halt-Informationen. Basierend auf robusten CE-zertifizierten Kleincomputern, die kompatibel zu den verbreiteten RaspBerry Pi sind und eine durch Zertifikate abgesicherte und gehärtete Virtualisierungsbasis aufweisen, wird in einem automatisch erzeugten Ad-hoc-Netzwerk der Safety-Status aller vorhandenen Devices permanent ausgetauscht. Durch dieses Konzept der Nothalt-Vernetzung ist es nicht notwendig, Safety-Einrichtungen in dynamischen, mit dem Menschen interagierenden Produktionsumgebungen zu zentralisieren.

In vielen Betriebsanleitungen zu Maschinen wird zu Tode gewarnt. Das führt dazu, dass relevante Informationen kaum noch wahrgenommen werden. Das Ende vom Lied ist der Verlust der Lust am Lesen der Betriebsanleitungen, ggf. mit fatalen Folgen für Mensch und Maschine. Im Vortrag wird gezeigt, wie Warnhinweise auf Grundlage der Risikobeurteilung entstehen, wie Restrisiken beschrieben werden können und wie durch ein Mehr an Erklärungen deutlich weniger Warnhinweisen erforderlich sind – ohne dass das Risiko der Produkthaftung steigt.

Die Funktionale Sicherheit ist inzwischen in vielen Firmen angekommen. Erste Projekte wurden umgesetzt, Prozesse für die Entwicklung sicherer Komponenten wurden definiert. Das ein oder andere Lehrgeld wurde auf diesem Weg gezahlt. Und in vielen Entwicklungsabteilungen haben sich ein paar wenige Experten herauskristallisiert, die „Safety-Gurus“. In deren Köpfen ruht das Safety-Know-how der Abteilung, wenn nicht sogar der ganzen Firma, während die meisten Entwickler nur so weit über Safety-Know-how verfügen, wie sie es sich in ihren jeweiligen Aufgabengebieten aneignen konnten – begrenzt und projektbezogen. Wenn nun die Safety-Aufgaben zunehmen, die Gurus sich aber dem Rentenalter nähern – dann stellt sich früher oder später die Frage: Wie lassen sich neue Experten heranziehen? Wie lässt sich das vorhandene Know-how auf weitere Köpfe verteilen? Auch bei embeX, seit über 15 Jahren in der Entwicklung sicherer Komponenten unterwegs, hat sich diese Frage irgendwann gestellt. Vor diesem Hintergrund wurde vor zweieinhalb Jahren, das embeX Functional Safety Program (XFSP) gestartet. Der Vortrag berichtet von den Erfahrungen aus diesem Programm und zeigt, wie sich die Vervielfältigung von Erfahrung organisieren lässt, sodass daraus anwendbares Wissen entsteht.

Operators of critical infrastructures from the transportation domain such as air traffic management, railways and vessel traffic services have a strong focus on safety and productivity. They are responsible for keeping airplanes safe (in the air, during landing and on the ground), for ensuring safety of vessels and for safe operation of high-speed trains. Successful cyber attacks can disrupt such critical procedures. Security threats have become a root cause for safety hazards, hence there is no safety without security. Existing safety assurance procedures should therefore be considered incomplete if they do not call for appropriate measures to mitigate security risks. At the same time, several established IT security best practises contradict safety requirements. New legal frameworks, such as the NIS directive in Europe put new liabilities on infrastructure operators and they now find themselves in a dilemma. For example, in certain scenarios, software-assurance regulations may conflict with security best practices around deploying critical system updates as soon as they are available. Should system operators disregard internal regulations by deploying non-certified software, or should they ignore critical security patches and run the risk of a serious incident? Concrete challenges to be overcome are: a) “once safe always safe” versus security adjustments on a daily basis b) safety-conform usability design versus strong authentication and access control c) “fail safe” versus “fail secure” d) redundancy / diversity versus attack surface minimization. Tackling such challenges is (still) additionally hampered by today's state of standardization: As there was minimal potential for an IT security risk to have a tangible impact on safety, safety management was historically treated as a completely separate topic from IT security, with virtually no coordination at the architectural or organisational levels. Safety and security were two disconnected schools of thought which is still reflected by two disconnected worlds of standardisation for safety (represented e.g. by IEC 61508 or by EUROCAE ED-153 and ED-109A specifically for air traffic management) and security (represented e.g. by NIST SP 800, BSI Grundschutz or ISO 27001). Only recently, new standards started to emerge which integrate safety and security practises to a common concept. Examples are IEC TR 63069, IEC TR 63074, partly IEC 62443, or the draft standard EUROCAE ED-205 for air traffic management ground systems. We propose a harmonized approach, which is based on three pillars: (a) at the security side on moving away from an undifferentiated and pure compliance-based security approach towards a differentiated and risk-based approach; (b) on the safety side on moving away from a static safety understanding (“once safe, always safe”) towards an understanding which considers security threats as possible root causes for safety hazards within the assurance model and (c) on practical engineering level on a segmentation of the system into different protection zones where specific safety and security regimes can then be applied for each zone to mitigate the overall safety and security risk in an adequate manner. This approach paves the way towards an integrated safety and security approach, as it is for example foreseen in the draft standard EUROCAE ED-205 for air traffic management ground systems. For many organizations, it will remain advisable to maintain separated responsibilities for safety and security on organizational level to ensure the required focus on both topics. However, new procedures and a new culture of collaboration between these dedicated departments shall be established. This will finally allow - together with new, upcoming standards - to overcome the conflicts and to integrate these two disconnected schools of thought. The security collaboration which needs to be established is required in two dimensions: horizontally (between safety and security departments) and vertically (between system operators, integrators and vendors). It has to cover all phases of the system lifecycle: from initial specification via development, delivery, integration to operation and finally - at the end of the system lifetime - disposal. During the first phases, the system vendor bears the main responsibility for system security. The future system operator has a duty to cooperate by specifying the future technical and operational environment of the system, by identifying security risks and requirements and by verifying them during acceptance testing. After integration and handover of the system, the system operator takes over the main responsibility for system safety and security. The vendor is supporting with security support services as they are requested by the system operator. During all phases, safety and security need to work together to balance security measures in a way to ensure system safety at all times.

Als Tester sind wir häufig mit Anforderungen konfrontiert, die sich nicht oder nur schlecht testen lassen - eine Gefahr für die Sicherheit unserer Systeme! Weitere Konsequenzen sind: - Tests schlagen fehl, weil sie nicht zu den Anforderungen passen, - Tests sind nicht vollständig und Fehler rutschen durch, - Rückfragen bei den Anforderungsautoren sind nötig; diese sind aber vielleicht schon mit dem nächsten Projekt beschäftigt, - Anforderungen müssen aufwendig überarbeitet werden. In diesem Vortrag zeige ich, wie man die Testbarkeit von Anforderungen mit Hilfe von Requirements Smell Analysen schon bei der Entstehung von Anforderungen verbessern kann. Requirements Smell Analysen sind leichtgewichtige, flexibel anpassbare Analysen, die schon früh in der Entstehungsphase von Anforderungen auf Testbarkeitsprobleme hinweisen. Ich setze seit mehreren Jahren solche Analysen in der Industrie in realen Projekten ein. In dem Vortrag gehe ich auf die folgenden Punkte ein: - Wie lassen sich schwammige oder unpräzise Anforderungen mit Requirements Smells aufdecken? - Kann man die Vollständigkeit von Anforderungen überprüfen? - Wie lässt sich die Einhaltung von Mustern für gute Testbarkeit prüfen? - Welche Analysen haben sich in der Praxis bewährt? - Verbessern automatische Analysen die Testbarkeit wirklich? Zum Schluss zeige ich Tools, mit denen solche Analysen dann tatsächlich in der Praxis umgesetzt werden können.

It is common knowledge that over half of all engineering errors originate in the requirements (result of several studies, like "An Information Systems Manifesto" from J. Martin). In addition, study from the NASA in 2004 shows that the cost to fix errors rose exponentially with each successive phase of the project lifecycle through which the error remained undetected. However, most systems and software defects are checked and found more later in the product lifecycle. Why? The reason is sadly simple: it is hard and time consuming to defect issues in requirements, as they are mostly written in natural language, and teams lacks automatic tools for this purpose. But today, computational advances in Natural Language Processing is allowing modern requirements quality analysis tools to become viable for use in development environments. The presentation would follow this agenda : - Results of several studies showing that the cost to fix errors increases exponentially the later these are found in the development lifecycle ; - Explaining deeper why teams do not spend enough time in detecting defects during the requirements conception ; - Why model based solutions have not taken the leading place of requirements testing; - A quick presentation of several requirements engineering best practices and industrial standards from the IREB, INCOSE or NASA ; - Different industry solutions that permits detecting vague or unclear requirements, inconsistencies and ambiguities, showing when they can help and also their limits.

In real-time systems the overall correctness depends on the correct timing behavior: each real-time task has to finish before its deadline. All current safety standards require reliable bounds of the worst-case execution time (WCET) of real-time tasks to be determined. With end-to-end timing measurements timing information is only determined for one concrete input. Due to caches and pipelines the timing behavior of an instruction depends on the program path executed before. Therefore, usually no full test coverage can be achieved and there is no safe test end criterion. Techniques based on code instrumentation modify the code which can significantly change the cache and pipeline behavior (probe effect): the times measured for the instrumented software do not necessarily correspond to the timing behavior of the original software. One safe method for timing analysis is static analysis by Abstract Interpretation which provides guaranteed upper bounds for WCET of tasks. Static WCET analyzers are available for complex processors with caches and complex pipelines, and, in general, support single-core processors and multi-core processors. A prerequisite is that good models of the processor/System on-Chip (SoC) architecture can be determined. However, there are modern high performance SoCs which contain unpredictable and/or undocumented components that influence the timing behavior. Analytical results for such processors are unrealistically pessimistic. A hybrid WCET analysis combines static value and path analysis with measurements to capture the timing behavior of tasks. Compared to end-to-end measurements the advantage of hybrid approaches is that measurements of short code snippets can be taken which cover the complete program under analysis. Based on these measurements a worst-case path can be computed. In this presentation we will focus on the hybrid WCET analyzer TimeWeaver which avoids the probe effect by leveraging the embedded trace unit of modern processors, like Nexus 5001, Infineon TriCore MCDS, or ARM CoreSight, and allows a fine-grained observation of a core’s program flow. It reads the executable binary, reconstructs the control-flow graph and computes ranges for the values of registers and memory cells by static analysis. This information is used to derive loop bounds and prune infeasible paths. Then the trace files are processed, the trace coverage is shown, and the path of longest execution time is computed. The computed time estimates provide valuable feedback for assessing system safety and for optimizing worst-case performance. In this presentation we give an overview of timing predictability in general and provide criteria for selecting suitable WCET analysis methods. We will outline the methodology of hybrid WCET analysis and report on practical experience with the tool TimeWeaver.

In the talk we present the requirements from the safety standards on tool qualification and the corresponding processes. Tool Qualification can sometimes be replaced by using tool safety manuals to gain the required confidence into the usage of software tool. The required “qualification need” is determined during tool classification and documented. Classification levels differ within different safety standards (IEC 61508, EN 50128, IEC 61508, DO-178/DO-330) and also the required qualification methods vary a bit. In the talk we compare standards and qualification methods for tools from the point of tool providers and tool users. We present different strategies for handling known bugs and their consequences for the users of the tool. In addition to the requirements we also present testing methods and criteria how to qualify a tool by validation. In addition we show the contents of a typical standard compliant qualification kit: user guide, document templates, test cases, test environment, safety guidelines, known bugs, compliance reports and we provide insights into the development of QKits. We present many practical examples for qualified tools and failures caused by unqualified tools.

Wir motivieren den Einsatz von zertifizierten bzw qualifizierten Codegeneratoren durch die Betrachtung des klassischen V-Modells, und wie es durch den Einsatz zertifizierter Tools transformiert wird. Im Detail gehen wir auf die Prinzipien modellbasierter embedded Applikationsentwicklung ein, und wie ein Codegenerator wie der ANSYS SCADE KCG graphische Modelle in serialisierten C-Code übersetzt. Es wird folgend beleuchtet, mit welchen Entwicklungsstrategien die Zertifizierung eines Codegenerators nicht nur als „Fit for purpose“-Tool, sondern als vollwertiges Entwicklungswerkzeug, dessen korrekte Funktion nicht mehr überprüft werden muss, erreicht wird. Wir betrachten im Anschluss dann den gesamten Software-Entwicklungsprozess und motivieren, an welchen Stellen im Prozess zertifizierte bzw qualifizierte Tools Sinn machen, inklusive der Erkenntnis, dass ein zertifizierter Codegenerator nicht nur bei der reinen Code-Erstellung eine wichtige Rolle spielt, sowie dass für maximale Effizienz im Prozess weitere zertifizierte Tools eine wichtige Rolle spielen, die aber zum Großteil wieder auf dem Fundament der Qualifizierung des Codegenerators beruhen. Wir schliessen mit Beispielen aus der Praxis und Metriken hinsichtlich Effizienzsteigerung

Dieser Vortrag bietet Neuanwendern einen Einstieg in das Thema "Code Coverage". Fortgeschrittene Nutzer erhalten einen systematischen Überblick über die verschiedenen theoretischen Ansätze und deren praktische Umsetzung. Im Einzelnen werden folgende Themen behandelt: Verschiedene Code-Coverage-Maße Die gängigen Maße werden vorgestellt und an praktischen Beispielen erläutert, von der Statement Coverage über verschieden Ausprägungen der Branch bzw. Decision Coverage bis hin zur Modified Condition/ Decision Coverage (MC/DC). Anforderung in den verschiedenen Sicherheitsnormen Verschiedene Sicherheitsnormen wie die IEC 62304 (Medizintechnik), die ISO 26262-6 (Automotive) oder die DO-178C (Luftfahrt) setzen unterschiedliche Anforderungen an die Messung der Code Coverage. Diese Anforderungen und ihre Unterschiede werden diskutiert. Grundlegende Ansätze zur Messung der Code Coverage Es existieren zwei wesentlich verschiedene Ansätze, um die Codeabdeckung eines Programms zu messen: Die Anreichung des Quellcodes mit Zählern (Instrumentierung) oder die nachgelagerte Analyse im Rahmen des Debugging. Jeder Ansatz hat spezifische Vor- und Nachteile für den Anwender. Einsatz von Tools in der Praxis Jenseits der Theorie und der Normen gibt es eine Reihe ganz praktischer Herausforderungen, wenn in einem bestehenden Entwicklungsprozess die Coverage-Messung eingeführt wird: - Integration in bestehende Toolchain, - Nebenwirkungen bei der Testausführung, - Interpretation und Konsequenz der Ergebnisse. Werden diese Herausforderungen frühzeitig reflektiert, können sie im Auswahlprozess für ein Coverage Tool berücksichtigt werden. Inhaltliche Bedeutung im Entwicklungs- und Testprozess Über die reine Erfüllung von Sicherheitsanforderungen hinaus kann die systematische Messung der Code Coverage eine Verbesserung des Testprozesses bieten. Gleichzeitig existieren aber auch eine Reihe von Mythen und vereinfachten Darstellungen über die Aussagekraft von „100% Code Coverage“. Der Vortrag geht diesen Mythen auf den Grund und stellt differenziert dar, welche Vorteile tatsächlich entstehen.

Aufgrund einer Analyse in Software-Entwicklungsabteilungen haben wir festgestellt, dass fast 100% aller Entwicklungsorganisationen zu wenige Unit Tests erstellen. Sehr oft ist die Situation sogar dramatisch schlecht, indem nicht mal 20% der eigentlich erforderlichen Unittests erstellt werden. Sogar im Industrie- und Safety-Umfeld ist die Abdeckung des Codes meist nicht ausreichend, obwohl dies hier durch Normen gefordert wird und somit auch große Haftungsrisiken bestehen, wenn die erforderliche Abdeckung nicht eingehalten wird. Trotzdem wiegen sich Entscheidungsträger dieser Entwicklungsorganisationen oft in Sicherheit, da ja im Continuous Integration System die (wenigen) erstellen Unittests „grün“ anzeigen und erfolgreich durchlaufen. Dass aber nur ein Teil der erforderlichen Tests erstellt wurde, wird oft nicht betrachtet. Fakt ist, dass eine vollständige Abdeckung durch manuelle Tests sowieso nicht erreichbar ist und auch die heute übliche Programmierung von automatischen Unit Tests wirtschaftlich kaum durchsetzbar ist, da hier dann ein krasses Missverhältnis besteht zwischen dem Aufwand, der für den produktiven Code aufgewendet wird, und dem Aufwand für die Absicherung dieses Codes, der dann ein Vielfaches höher ist. Die einzige Lösung für dieses Dilemma ist es, die benötigte Absicherung weitestgehend automatisch herzustellen, um so den Aufwand in der Testerstellung dramatisch zu reduzieren. In dem Vortrag wird eine Lösungsmöglichkeit gezeigt, die es dem Test-Entwickler einerseits ermöglicht, Testfälle für eine komplette funktionale Codeabdeckung sehr schnell halbautomatisch zu erstellen und dann aus diesen Testfällen auf Knopfdruck vollautomatisch ablaufbaren Testcode zu erstellen. Damit wird eine Aufwandsreduktion bei der Testautomatisierung von ca. 50-75% erreicht und zusätzlich die funktionale Abdeckung durch passende Testfälle gesteigert.

This presentation will discuss commonalities and differences of safety and security in automotive systems. Focusing on software security the main issues of security will be discussed, followed by guidelines of how to make sure that a secure system is developed. It will be shown why choosing the right operating system is vital, not only but especially for connected vehicles.

Das Thema Security ist in vielfältiger Weise in aller Munde. Viele neue Standards, die Security tangieren, sind in der Vorbereitung oder bereits verabschiedet und wirksam. In diesem Vortrag sollen für Security relevante (neue) Normen und Ideen aus Safety-Sicht betrachtet werden. Die Kombination von Methoden, Schnittstellen und insbesondere zusätzliche Ansätze, Grenzen, Gegensätze und Anforderungen an die Beziehung zwischen Safety und Security werden beispielhaft vorgestellt. Die Beispiele stammen u.a. aus der Recherche bzgl. folgender Normen Die 2nd edition der Safety-Norm [ISO26262-2nd] formuliert im informativen Anhang E des zweiten Bandes die Wichtigkeit der Betrachtung von Security zum Erreichen funktionaler Sicherheit in unterschiedlichen Entwicklungspha-sen ohne dabei genaue Vorgaben and Security-Methoden zu machen. Die neue Norm SOTIF [ISO/PAS21448] fordert auf Use Cases sowohl für die korrekte als auch für die nicht korrekte Nutzung, sowie für den vorhersehbaren Missbrauch von Fahrzeugen zu betrachten. Security wird in dieser Norm aller-dings nicht weiter adressiert. Die amerikanische Automotive Security Norm [SAE3061] beschreibt in mehreren Abschnitten ausführlich die Beziehung zwischen Safety und Security sowohl für das Engineering als auch die Organisation beider Themen. Insbesondere gibt sie Beispiele bei denen klar wird, dass Security für Safety-Funktionalität alleine durch Safety-Maßnahmen nicht abgedeckt werden kann. Die Norm benennt insbesondere für Risiko Assessment und Bedrohungs-Analysen zusätzlich zu betrachtende Faktoren wie z.B. notwendiges Wissen, Erfahrung, Zugriffsmöglichkeiten oder benötigtes Equipment von Angreifern. Während Safety ausschließlich safety-kritische Systemen behandelt, ist bei security-kritischen Systemen Safety immer als eine mögliche Auswirkung dabei. Im Gegensatz zu Safety-Themen werden Security-Themen Teil der Homologation. Nach einem ersten Draft der UNECE [UNECE19] und einer beginnenden Testphase werden in dieser Regulierung die von den Automobilbauern und Zu-lieferern erwarteten und einzuhaltenden Security-Prinzipen (u.a. eine Erweite-rung der Security-Kategorien) erläutert. In diesem Dokument wird einmal mehr deutlich, welche organisatorischen Vorgaben zusätzlichen zu den für Engineering für Security-relevante Entwicklungen Security erfordert. Ein wesentlicher Bestandteil der momentan am Entstehen befindlichen ISO/ SAE 21434 ist die Durchführung des Risiko Assessments. Die Durchführung von Analysen der Schadensszenarien, Bedrohungsszenarien, Schwachstellen und Verwundbarkeit wird mit einem integral entsprechenden Prozess unterlegt. I.G. zu Safety sind wegen der unterschiedlichen Schutzziele wie Safety, Finan-zen, Operationalität und Privacy (Datenschutz), auch unterschiedliche Schadensszenarien zu betrachten.

Safety related requirements for a security subsystem There is an increasing demand for security inside automotive applications. Items like secure communication, SW IP protection, authentic OTA updates and others get more and more important. But how far will security and safety interact which each other? Can security be guaranteed in a safety environment? Is there safety without security? These questions very much depend on the system you are talking about. This presentation will discuss the impact of safety on a security subsystem of a SoC. It will sketch safety relevant use cases and discuss their impact on security. Security related reactions of the subsystem will be judged against safety of the overall system.

Meist historisch bedingt wurden Fahrzeuge von den Automobilherstellern lange Zeit nicht als IT-System betrachtet. Darum stand bis jetzt auch die funktionale Sicherheit (Safety) im Vordergrund, die Betrachtung von IT-Risiken hat sich oft nur auf das Backend beschränkt. Durch einige medienwirksame Angriffe auf Fahrzeuge (z.B. Jeep-Hack durch Miller/Valasek) ist das Thema IT-Sicherheit im Fahrzeug stärker in den Fokus der OEMs und Zulieferer gerückt. Trotzdem laufen die Safety- und die IT-Sicherheitsprozesse zumeist noch ohne Schnittstelle parallel nebenher, statt Hand in Hand. Durch eine bessere Abstimmung untereinander können schon frühzeitig Abhängigkeiten und Risiken erkannt und in Fahrzeugentwicklungsprojekten berücksichtigt werden. Im Vortrag zeigt Georg Graupner, wie eine Methodik dazu aussehen könnte.

In den modernen Fahrzeugarchitekturen werden vermehrt Performance Controller für sicherheitsrelevante Funktionen und Infrastruktur eingesetzt. Dadurch wir die Verwendung von Open Source Software attraktiv, da viele Software Elemente frei verfügbar sind. Diese folgen aber üblicherweise keinen Safety Entwicklungsprozess z.B. nach der ISO26262. In diesem Vortrag soll an zwei Beispielen gezeigt werden, wie sich Open Source Software einsetzen lässt, einmal unter dem Aspekt Rückwirkungsfreiheit (Freedom from interference), andererseits ob und wie sich Sicherheitsanforderungen auf Software Komponenten mappen können und eine Sicherheitsargumentation geführt wird. Um dem Konferenz Thema gerecht zu werden, wird eine der Komponenten eine häufig verwendete Security Bibliothek sein. About EB: Elektrobit – Driving the future of software Elektrobit (EB) ist ein führender Anbieter von Automotive Software. Das Unternehmen steht für eine rund drei Jahrzehnte andauernde Erfolgsgeschichte in der Entwicklung von Embedded- und Connected- Softwarelösungen. EB ist ein kompetenter und engagierter Partner für Automobilhersteller und –lieferanten, und unterstützt sie mit Technologien, flexiblen Softwareplattformen, Tools und Dienstleistungen dabei den Produkt- und Serviceerwartungen von anspruchsvollen Autofahrern gerecht zu werden. In partnerschaftlicher Zusammenarbeit mit Branchenführern wie NVIDIA, NXP, Infineon, Argus und QNX entwickelt EB die nächste Generation intelligenter, flexibler und kosteneffizienter Softwarelösungen für das Fahrzeug. EB ist aktiv an der Weiterentwicklung wichtiger Industriestandards wie AUTOSAR und NDS beteiligt. Darüber hinaus unterstützt EB alle branchenrelevanten Betriebssysteme und Standards: Ethernet, funktionale Sicherheit, HTML5, GENIVI, Linux sowie Windows Embedded. EB verfügt über langjährige Erfahrung im Bereich Connected Services in sicherheitskritischen Umgebungen. Diese reicht von Navigation und Infotainment über ECUs bis hin zu Fahrerassistenz.

There is a current industry trend to build fully autonomous systems. To reach this goal, industry must manage complex software systems with high performance, safety and security requirements. The operating system is non-differentiating in these systems and it is intended to be used multiple times over the whole product portfolio for a long time span. These conditions make it appealing to use Linux as robust open-source operating system. OSADL’s SIL2LinuxMP project has done initial investigations to use Linux in safety-related systems and provides first results to the public, but also identified open issues and areas where foundations for assessment of pre-existing software are missing. Its successor, Linux Foundation's ELISA Project, continues this work enlarging the research activities in SIL2LinuxMP to an collaboration development project to provide an attractive solution to the overall industry. The talk will describe the project results from SIL2LinuxMP, and sketch goals and started activities from the ELISA collaboration and development. Addressing the use of Linux in safety applications requires assessing conformance to current functional safety standards. The challenge is mapping the intent of functional safety standards to the concrete properties, capabilities and limits of Linux. This talk shows the currently developed approach for compliance and its definition and development of adequate methodologies. Companies interested in using Linux in their safety-related systems are informed about the availability of current results and the participation in this new collaborative project. The presentation will highlight the following key points: - Motivation to use Linux in safety-critical systems - Introduction to OSADL’s SIL2LinuxMP and Linux Foundation’s ELISA collaboration project - Understanding of the safety standards' activities with regard to pre-existing software in general and the Linux kernel development specifically - Identification of open technological aspects Benefits to the industry from a commercial perspective A number of companies, especially partners in the previous SIL2LinuxMP and new Linux Foundation ELISA collaboration project, have been discussing how collaboration and business models around Linux for the use in safety-critical systems could potentially look like and could be established. As the Linux operating system is available as open-source and licensed under GPL, any modifications to Linux must be made publicly available anyway. Furthermore, making assessments on the rigor of the Linux kernel development process behind closed doors puts single companies under a much higher risk of wrong assessments than coming to a industry-wide common conclusion on such questions. Nevertheless, various development activities, such as system engineering, will be specific to the different systems. This talk shall address the need to sketch and discuss a collaboration, its boundaries and a possible ecosystem around it. Benefits to the industry from a technical perspective That Linux is becoming relevant for safety-related systems is clear, at the same time, safety standards do not seem to immediately address the specifics of how to initially develop and then manage safety properties of Linux. This is an increasing point of concern to be addressed even if there is not yet a definitive answer. Nevertheless, pointing out the requirements that safety-related and high-assurance systems have to the general development community would help prepare a safe future. The talk explains the importance of procedural issues and how many requirements for safety-related systems can be handled if considered during development. This talk outlines these procedures that well may benefit the general robustness and reliability of Linux beyond safety-related systems only. These efforts will increase its quality in general, and this can only be done with the community.

Agile Methodik hat ihren Siegeszug in der Softwareentwicklung angetreten. Aber wie lassen sich die strengen Anforderungen der Normen für die funktionale Sicherheit mit Prinzipien wie "lauffähige Software über umfangreiche Dokumentation" oder "Entscheidungen zum spätest möglichen Zeitpunkt" vereinbaren? Wann ist es überhaupt sinnvoll im Automotive Umfeld auf agile Methodik zu setzen? In diesem Vortrag werden zunächst die Vorteile der agilen Arbeitsweise vorgestellt, um dann die Herausforderungen im Umgang mit Gefährdungen und der Risikoanalyse im Kontext der ISO 26262 zu benennen. Anschließend wird anhand eines Beispiels im Rahmen des autonomen Fahrens ein Scrum-basierter Prozess vorgestellt. Dieser Prozess ermöglicht es, die in der ISO 26262 geforderten Artefakte inkrementell zu erstellen. Beginnend mit der Initialisierung des Projekts, wird der User Story Lifecycle bis zur Abnahme eines Inkrements Schritt für Schritt erklärt. Notwendige Aufgaben, die aus den Anforderungen der Norm anfallen, werden in den Prozess integriert und die verantwortlichen Rollen zugewiesen. Darunter fällt die Verwaltung der Gefährdungen, sowie die inkrementelle Erstellung des funktionalen sowie technischen Sicherheitskonzepts. Dabei werden die Prinzipien der agilen Entwicklung, wie z. B. den starken Fokus auf den Mehrwert für den Endanwender, auch auf die Artefakte der Norm angewendet. Begleitend wird am Beispiel der Backend-Softwareentwicklung im vom Bundesministerium für Wirtschaft und Energie (BMWi) geförderten Forschungsprojekt MEC-View beispielhaft ein Projektsetup mit entsprechenden Werkzeugen vorgestellt.

Accelerating product delivery times are forcing safety-critical companies to adopt Agile/DevOps practices. With this pressure to move away from traditional sequential processes comes the challenge to manage risks and to maintain development maturity and compliance in regulated markets. Join Intland's talk as we analyze the findings of independent analyst firm Ovum's recent report on Achieving Safety-Critical Development Maturity with Agile/DevOps ALM. The report analyzes emerging best practices and tooling that leading companies in the automotive, medical, and avionics sectors are adopting to keep pace with evolving methodologies. Taking the example of German carmaker BMW, this Ovum report examines strategies to adopt end-to-end Agile/DevOps development while maintaining compliance with regulations and standards. In this talk, Intland Software's topic expert will analyze how development maturity is achieved in the Agile/DevOps era. With BMW's best practices, the talk will also cover the use of Agile scaling frameworks in the development of high-quality safety-critical products.

The majority of functional safety standards that pertain to software development (i.e. ISO 26262, IEC 61508, DO 178B/C, or EN 50128) require qualification of the software tools used in development of the code, in order to certify the reliability of the code itself. All tools that are used to generate, structure, or verify the software have to go through the process of qualification, which can be a necessary evil for development teams. This is for good reason – the qualification process (especially in projects with a high level of risk, like SIL3, ASILD, or SLA) requires a significant amount of preparation. The qualifier needs to define the tool operational requirements, create a set of test cases validating defined requirements, analyze known problems affecting tool functionality, and prepare mitigation strategies, wherever correctness of the tool operation cannot be proven. Overall, it is a time and resource-consuming task, which doesn’t contribute directly to the core functionality of the developed product. In this presentation, we will discuss the solutions to some of the typical problems and challenges that development teams are facing when trying to move through this process to qualify the software tools, specifically highlighting how to reduce the most time-consuming aspects of the process, including experience-based strategies that can be used to mitigate burden related to this process.

In autonomen Systemen sind Cyberangriffe allzu unvermeidlich. Wie schützen sich erweiterte verteilte Systeme vor unbekannten Bedrohungen und behalten gleichzeitig die erforderliche Skalierbarkeit und Leistung bei? Der Aufbau und die Sicherung skalierbarer autonomer Systeme erfordert mehr als nur die Sicherung der Geräte oder Datenverbindungen. Ein optimaler Sicherheitsansatz erfordert die uneingeschränkte Berücksichtigung der Systemanforderungen, Leistungsanforderungen, Datenkritikalität, Linkverhalten und -eigenschaften, Verfügbarkeit und Systemrisiken. In heutigen Systemen werden Daten schnell zwischen Subsystemen ausgetauscht, wodurch Daten in Bewegung erzeugt werden, die ebenfalls gesichert werden müssen. Beispielsweise erhalten Anwendungen Befehle, um bestimmte Aktionen auszuführen, sie sollten jedoch selbst keine Befehle senden, da für diese Aktion eine höhere Sicherheitsstufe erforderlich ist. Genau hier, auf Datenebene, ist eine feingranulare Sicherheitskonfiguration erforderlich. In diesem Vortrag wird beschrieben, wie skalierbare und leistungsstarke verteilte Systeme die Sicherheit mithilfe des DDS-Standards (Data Distribution Service der OMG) und seiner DDS-Sicherheitserweiterung integrieren können. Anhand von Beispielen aus der Praxis wird gezeigt, wo dies erfolgreich implementiert wurden.

Sicherheitsverstöße im Gesundheitssektor gehen nicht nur Sicherheitsfachleute etwas an. Ihre Auswirkungen machen sich in der gesamten Wertschöpfungskette bis hin zum Patienten bemerkbar. Deshalb muss jeder seinen Teil dazu beitragen und potenzielle Schwachstellen vermeiden.

Hintergrund/Fragestellung Die Anzahl der verfügbaren Medizin-Apps steigt stetig. Über 50% der Ärzte greifen laut Umfragen auf entsprechende Apps während der Arbeit zurück. Aber auch Privatleute setzen zunehmend auf Medizin-Apps. Sei es zur Diagnose oder um sein eigenes Krankenprofil immer dabei zu haben, welches dann auch Ärzten vorgelegt werden kann. Aktuell ist hier als Beispiel eine Krankenkassen- App zu nennen die mit ihren – zwar wohl zügig gepatchten/korrigierten Sicherheitslücken – aber gleichwohl in den Schlagzeilen stand [1]. Bei medizinischen Daten ist es von höchster Priorität, dass diese sicher sind: Unverändert und nur von Berechtigten lesbar. Es stellt sich daher die Frage, ob Medizin-Apps diese Daten schützen. Auch Anfragen zu Services, auf eine Krankheit (Symptome) schließen lassen, müssen entsprechend abgesichert und anonymisiert sein. Darüber hinaus muss die Verfügbarkeit der gespeicherten Daten gegeben sein! Methoden Mittels einem Man-in-the-Middle Angriff wurden die Daten, die zwischen App und Server verschickt werden, soweit möglich gelesen und ausgewertet. Außerdem wurde getestet, ob die Daten von der App unerkannt manipuliert werden können. Ebenfalls wurde untersucht wo die Daten auf dem Smartphone gespeichert werden. Je nach Speicherort können neben der Medizin-App auch andere Apps die sensiblen Medizindaten lesen und diese wiederrum ins Internet senden. Ergebnisse Die Ergebnisse fielen naturgemäß je nach App-Entwickler unterschiedlich aus. Wenige Apps erscheinen sicher, denn bei vielen konnten Medizindaten gelesen und oft sogar verändert werden. Trotz der sensiblen Daten, die bei Veränderungen im schlimmsten Fall sogar Leben kosten können, sind also viele Apps unsicher. Stand der Technik Um solche Sicherheitslücken zu vermeiden, ist ein ganzheitlicher Prozess erforderlich. Dieser sichert nicht nur die Medizin-App ab, sondern alle Kommunikationswege der App. Um dies zu erreichen muss von Grund auf sicher entwickelt werden. Stand des Security Testing der Einsatz eines Security Testing Prozesses gem. ISO 27034 [2] mit 6 Methoden über den gesamten Life Cycle der Software- Entwicklung: (1) Security Requirements Analysis, (2) Threat Modeling des Security Designs, (3) Conformance Testing, (4) Überprüfung des Quellcodes mit Static Source Code Analysis, (5) Penetration Testing und (6) Dynamic Analysis Fuzzing. Jede dieser Methoden identifiziert andersartige Sicherheitslücken. Im Vortrag werden über die Erfahrungen mit dem (ergänzten) ISO 27034-basierten Security Testing Process berichtet und es wird auch auf anderweitige Bewertungskriterien [3] eingegangen – insbesondere wie weit sie auch die technische Ebene abdecken und sicherheitstechnische Methoden zur Prüfung behandeln.

.

Wie verwalte ich Zugriffsrechte in einer vernetzten Welt? Die vernetzte Welt stellt Hersteller und Betreiber vor große Herausforderungen. Allein das Verwalten einer immer größer werdenden Anzahl von vernetzten Geräten und Dingen ist eine Herausforderung. Die tatsächlichen Anforderungen gehen jedoch weit über das simple Verwalten vernetzter Geräte hinaus. Wer darf welche Daten sehen? Ist der Mitarbeiter noch im Unternehmen? Ist er autorisiert diese Daten abzufragen, und darf er ggf. Rechte delegieren oder managen? Eine Grundvoraussetzung ist hier die Datenintegrität und die Frage, ob diese für unternehmenskritische Entscheidungen genutzt werden können und dürfen. Des Weiteren ist es in vielen Branchen notwendig durchgeführte Arbeiten nachweisen zu können. Der protokollierte Zugriff aller beteiligten Akteure (lückenlose Authentisierung und Autorisierung) erlaubt es nicht nur einzelne Aktionen nachzuvollziehen sondern die weitere Berechtigung (Autorisierung) davon nahezu in Echtzeit abhängig zu machen. Diese Herausforderungen stellen sich in nahezu allen Industriezweigen von ‘Open Banking’ bis zu ‘Software Defined Manufactuing’. In diesem Vortrag sehen sie exemplarische Beispiele aus der Industrie, dem Medizinbereich sowie vernetzter Mobilität und erhalten einen Einblick wie ein leistungsfähiges Digital Identity & Access Management System hilft, die neuen und alten Herausforderungen einer vernetzten Welt zu meistern und das Unternehmen digital zu transformieren.

In der Vergangenheit arbeiteten Medizingeräte als isolierte, allein agierende Geräte mit fester Funktionalität, während heutzutage die Geräte zunehmend miteinander vernetzt sind und sich auch untereinander austauschen. Zusätzlich nutzen sie Software- und Hardware-Standardplattformen und bieten nachrüstbare Funktionen. Dadurch wird es immer wichtiger, Maßnahmen zur Cybersecurity und Schutz vor Manipulation anzuwenden und Geschäftsmodelle sicher umzusetzen. Die zunehmende Vernetzung medizinischer Geräte bringt enorme Effizienzgewinne beim Einsatz in der Klinik oder in der Arztpraxis. Allerdings steigt das Risiko der Manipulation von außen, beispielsweise durch unberechtigte Veränderung von Geräteeinstellungen. In den letzten Jahren gab es Datenpannen und Hackerangriffe auf die IT deutscher Krankenhäuser. Deshalb sind Schutzmaßnahmen, die bis zu allen vernetzten Endgeräten durchgängig sein müssen, geboten. Ebenso wichtig ist der Schutz der Vertraulichkeit der Patientendaten wie die Fälschungssicherheit derselben.

Für viele Industrieunternehmen steht die Informationssicherheit noch nicht mit an erster Stelle - eine Gefahr im Zeitalter der digitalen Transformation: Fertigungsumgebungen (ICS / SCADA) enthalten viele unsichere Komponenten mit unbekannten Cybersicherheitsrisiken. Ein Angriff auf ICS / SCADA-Geräte ist viel einfacher als der Angriff auf hochsichere IT-Komponenten. Cyberangriffe können große Auswirkungen auf Unternehmen haben, vor allem, wenn unklar ist, welche Komponenten in OT-Netzen miteinander verbunden sind und welche Risiken und Schwachstellen im Hinblick auf Cybersicherheit bestehen. In diesen Umgebungen wird häufig das gesamte geistige Eigentum von Produktionsprozessen gespeichert. Der Referent Security wird im Vortrag hilfreiche Tipps und innovative Ansätze, Methoden und Technologien zur Sicherung der Produktionsumgebungen und zum strukturierten Umgang mit Cybersicherheitsrisiken aufzeigen.

Erleben Sie einen Live-Hack eines IoT-Geräts und eine Demonstration, wie Sie über eine einzige Sicherheitslücke vollen Zugriff auf das interne Unternehmensnetzwerk erhalten.

Zunehmende Vernetzung und intelligente Systeme sind die treibenden Kräfte hinter Industrial Internet of Things (IIoT) und Industrie 4.0. Bei der Planung sogenannter Smart Manufacturing Anlagen oder der Modernisierung bestehender Anlagen zu einer intelligenten Produktion wird die IT-Sicherheit leider sträflich vernachlässigt. So können mit dem Internet verbundene, aber nicht ausreichend gesicherte, Steuerungskomponenten als Einstiegspunkt in das Unternehmen verwendet werden. Oder ein Fernwartungszugang eines Mitarbeiters wird für den initialen Zugriff ins Netzwerk missbraucht. Um solche Vorgänge möglichst schnell zu erkennen, werden Maßnahmen benötigt, die über rein signaturbasierte Verfahren hinausgehen. Im Vortrag wird eine Intrusion Detection System (IDS) Architektur vorgestellt, mit der Angriffe auf industrielle Netzwerke schnell erkannt und entsprechende Warnungen generiert werden können. Durch eine verteilte IDS Architektur und den Einsatz von unsupervised Machine Learning Algorithmen kann das System auch bis dato nicht bekannte Angriffe schnell erkennen. Kernkonzept ist dabei, dass Sensoren (Embedded Systems) dezentral Daten sammeln und diese Daten geeignet verarbeiten. Besonderes Augenmerk liegt dabei auf einer effizienten Feature-Vorverarbeitung. Komprimiert werden die gesammelten Features dann zu leistungsfähigeren Knoten gesendet, die entsprechende Kapazitäten besitzen, um aus den Daten Modelle zur Anomalieerkennung zu berechnen.

Der Vortrag zeigt live anhand eines praktischen Beispiels (Live), wie die Kommunikation zwischen einer SPS und HMI manipuliert werden kann, ohne dass dafür einen Internetzugang benötigt wird. Ebenso vermittelt der Referent, dass die angezeigten Daten an einem HMI nicht immer vertrauenswürdig sind. Ein solcher Angriff kann jederzeit aus dem Kommunikationsnetz von SPS und HMI erfolgen und erfordert wenig technische Ressourcen. Im Vortrag wird konkret gezeigt wie ein solcher Angriff erfolgen kann und mit welchen Maßnahmen er zu verhindern ist. Die entsprechenden Hilfsmittel zur Absicherung, wie Paket-Firewall zur Mikro-Netzwerksegmentierung werden erklärt und die wichtigsten technischen Parameter am Manipulations-Beispiel aufgezeigt.

In Fertigungsunternehmen leisten Industrie-PCs die Kommunikation mit der Maschine und steuern Produktionsprozesse. Integrität und Verfügbarkeit der Daten werden unter anderem auf der Basis von Datensicherung gewährleistet. Dabei werden regelmäßig Backups erstellt, die bei einem Datenverlust die Wiederherstellung ermöglichen. Die in der klassischen IT genutzten Verfahren der Datensicherung können für die Sicherung von IPCs nicht genutzt werden, da sie auf die erzeugten Daten ausgerichtet sind, während für die Steuerung von Maschinen insbesondere auch die Daten wiederhergestellt werden müssen, die die Funktionalität abbilden. Diese Daten findet sich auf der Ebene der Treiber / Programme und des Betriebssystems, die von herkömmlichen Sicherungslösungen nicht erfasst werden. Eine Wiederherstellung ist nur dann möglich, wenn Sicherungslösungen direkt auf den Datenträger des IPC zugreifen und die Daten basierend auf Sektorenvergleichen unabhängig von ihrer Art, vom Betriebssystem, von der Hardware oder der Konstellation aus Betriebssystem und weiterer Software sichern können. Auf die Funktionalität bezogene betriebssystemunabhängige Sicherungsverfahren stellen somit einen wesentlichen Baustein für den Erhalt von Integrität und Verfügbarkeit der Daten dar und ein wesentliches Element industrieller IT-Security und Safety.

Verpackungsmaschinen – jeder kennt sie oder hat sie schon einmal in Aktion gesehen. Sie arbeiten schnell, effektiv und wenn genügend Kartons vorhanden sind fast vollautomatisch. Diese Verpackungsmaschinen werden immer komplexer und heutzutage aus verschiedenen Gründen mehr und mehr mit integrierten Sicherheitssteuerungen ausgerüstet, damit man Safe Limited Speed (SLS) und andere Sicherheitsfunktionen flexibel einsetzen kann. Schnelle und flexible Formatwechsel stehen ebenso im Fokus wie der übergreifende Industrie-4.0-Gedanke. Im Vortag wird aufzeigt, wie man eine Kartonzuführung nicht nur funktional sicher macht, sondern wie sich mit einer hohen Diagnose ohne weitere Bauteile sogar den Füllstand detektieren und die Kartonzuführung gegen Manipulation schützt lässt.

Der Vortrag beschreibt die Aufgabenstellungen um zyklische Feldbusse wie Profinet, Profibus und Opensafety über eine Funkstrecke zuverlässig zu übertragen. Es werden unterschiedliche Lösungsvarianten und Funktechnologien vorgestellt und nach deren Eignung klassifiziert. Zum Hintergrund: Feldbusse über WLAN oder Bluetooth in industriellen Anwendungen zu übertragen stellen hohe Anforderungen an die Verfügbarkeit des Funkkanals und Latenzzeit der Telegrammübertragung. Schon kurze Unterbrechungen und Verzögerungen führen zum Anlagenstillstand. Durch eine Vorverarbeitung der zyklischen Feldbustelegramme in den Funksystemen können trotzdem hochverfügbare Anlagen realisiert werden. In der Präsentation werden einige Algorithmen der Vorverarbeitung und deren Auswirkung auf die Feldbuskommunikation sowie das Verhalten der Safety-Steuerung dargestellt. Beispiele von realisierten Applikationen in der Fabrikautomation, Logistik, Krananlagen etc. runden den Vortrag ab.

Ethernet-basierte Kommunikationsprotokolle setzen sich in der industriellen Automatisierung zunehmend durch – nicht zuletzt, da sie eine durchgängige Kommunikation vom Sensor bis in die Cloud ermöglichen. In diesem Zuge wachsen die einst voneinander abgeschotteten Bereiche Informations-technologie (IT) und Industrie-Automation (Operational Technology/OT) sukzessive zusammen. Dadurch benutzen neben den direkt an der Automatisierung beteiligten Maschinen und Anlagen weitere Applikationen wie Drucker, Energiemanagement oder die Überwachungskamera der Produktionshalle das gleiche Netzwerk. Zusätzlich zum zyklischen Prozessdatenverkehr belastet also immer mehr eine nicht vorhersagbare Menge azyklischen Datenverkehrs die Infrastruktur – die Netzlast steigt (mitunter nur situativ und sporadisch) und die rechtzeitige Ankunft zeitkritischer Telegramme ist gefährdet. Müssen sich Unternehmen nun zwischen hohem Komfort dank Vernetzung auf der einen Seite und Sicherheit durch zwei getrennte Netzwerke auf der anderen Seite entscheiden? Industrie 4.0 oder Steinzeit? Nein! Im Vortrag wird eine Netzwerkstruktur vorgeschlagen, die die beiden „Welten“ Automatisierung und IT geschickt verbindet, ohne Kompromisse bei der Sicherheit machen zu müssen. Durch diese Struktur lassen sich nicht nur Datenströme gezielt steuern und Netzwerke zentral managen. Werden an der Schnittstelle der beiden Bereiche moderne Switches mit integrierter Routing-Funktion eingesetzt, lassen sich einzelne Verbindungen zwischen IT- und Automatisierungsnetzwerk gezielt zulassen bzw. verbieten, ohne dass hierfür teure IT-Infrastruktur angeschafft werden muss.

Die Industrie 4.0 charakterisiert sich durch die globale Vernetzung aller Beteiligten eines Produktionsprozesses und schließt Hersteller und Kunden nicht nur ein, sondern bringt die verschiedenen Parteien näher zusammen. Besonders für klassische Maschi- nenbauunternehmen stellt diese Aufgabe eine große Herausforderung dar, da dieses Vorhaben mit immensen Investitionen im Bereich Personal- und Produktentwicklung sowie der Einführung neuer Technologien einhergeht. Die Arbeitsgruppe Safety und Security der Hochschule Hamm-Lippstadt knüpft genau an dieser Stelle mit einem neuen konzeptionellen Vorgehen an. Hierfür wurden die vorhandenen Erfahrungen eigener Projekte im industriellen Umfeld gebündelt, um ein Konzept in Form einer Best-Practice-Umsetzung für die Industrie zu entwickeln. Diese Blaupause inkludiert eine anfängliche Sicherheits- und Risikobewertung und erstreckt sich über alle Ebenen der Produktentwicklung sowie des Prozessmanagements hinweg bis hin zur Betrachtung sicherheitskritischer Komponenten und Daten im Produktlebenszyklus. Das bedeutet, dass sich dieses Modell direkt von Anfang an bei der Entwicklung und Produktion neuer Hard- und Software mit relevanten Sicherheitsthemen befasst und sich bis zur Einbettung sowie Wartung beim Kunden erstreckt und erst bei der Verschrottung und Entsorgung endet. Dabei kommen diverse strukturelle Probleme zum Tragen, wie beispielsweise die eines sicher funktionierenden Schlüsselmanagements und den zu Grunde liegenden Verschlüsselungsverfahren. Dieses Vorhaben schließt in der Industrie 4.0 auch Cloud-Systeme und Mobile Endgeräte mit ein. Ebenso gilt es neben den typischen Angriffsvektoren in der Industrie neue Schwachstellen durch Neubewertungen von Bedarfsmaßnahmen zu erfassen und passende Interventionsmaßnahmen durchzuführen. Dafür werden Verfahren und Werkzeuge an die Seite gelegt, die eine Grundsicherung im Rahmen von Penetrationstests gewährleisten. Alle hier entwickelten und definierten Prozesse werden im Kontext von etablierten nationalen und internationalen Normen durchgeführt, die dem Ziel einer Zertifizierung ermöglich. Der Fokus bezieht sich insbesondere auf die ISO 62443, welche sich besonders an Betreibern von Automatisierungssystemen wendet. Dieser Vortrag stellt das Vorgehensmodell für die Entwicklung, die Umsetzung und den Betrieb (IT-)sicherer Systeme in der Industrie 4.0 vor und präsentiert erste Ergebnisse einer prototypischen Umsetzung in einem Industriebetrieb. Das Vorgehensmodell ist im Rahmen eines Forschungsprojektes zur Umsetzung intelligenter, sicherer industrieller Produkte entwickelt worden und wurde vom Ministerium für Wirtschaft, Innovation, Digitalisierung und Energie des Landes Nordrhein-Westfalen gefördert. Ziel des Projektes ist neben der konkreten exemplarischen Umsetzung die Schaffung von Best-Practices und Blaupausen für smarte aber sichere industrielle Anwendungen der Zukunft.

Das Internet der Dinge birgt zweifellos ein enormes Potenzial für die Fertigungsindustrie, stellt Unternehmen jedoch gleichermaßen vor neue Herausforderungen: Nie zuvor war es für kriminelle Angreifer leichter, sich Zugang zum Unternehmensnetzwerk zu verschaffen. Spätestens seit Stuxnet, dem wohl bekanntesten Computerwurm, wissen wir, dass Anlagen der industriellen Automation und Leittechnik angreifbar sind. Was vielen nicht klar ist: Cyber Security beginnt im Kopf mit der Erkenntnis, dass das eigene Unternehmen ein mögliches Ziel für Angreifer sein könnte. Hier tun sich viele Unternehmen noch schwer: Das Bewusstsein um Schwachstellen, die sich durch zunehmende Vernetzung auftun, ist deutschlandweit vor allem im Mittelstand noch wenig ausgeprägt. Anhand von Praxisbeispielen zeigt Dr. Volker Baier, CISO Industrial Security bei TÜV SÜD Sec-IT, die potenziellen Einfallstore in Produktionsanlagen auf, erläutert die typischen Vorgehensweisen von Hackern und erklärt, welche Schutzmaßnahmen Unternehmen künftig angesichts der dynamischen Bedrohungslage treffen müssen. Insbesondere der Mittelstand steht dabei im Fokus.

Funktionale Sicherheit nach IEC 61508 erfordert bereits seit Jahren, das Cyber Security in Software Systemen berücksichtig werden muss. Hier verweist die Norm direkt auf die IEC 62443 für Handlungsanweisungen. Um – wie in der IEC 62443 und der ISO 27034 gefordert – ein Security-Level festzulegen und dies im Zuge des Software Entwicklungsprozess zu erreichen wird das Requirements Management um eine Security Ebene erweitert. Auf diese Weise werden Security-relevante Anforderungen parallel zu den übrigen Anforderungen erhoben, festgehalten und Ihre Erfüllung dokumentiert. Wir liefern in unserem Beitrag Beispiele, wie in unseren Projekten solche Anforderungen erhoben werden. Hierbei beachten wir sowohl die Reichweite möglicher Konsequenzen als auch die Angriffsfläche der entwickelten Software-Komponenten. Dabei stellen wir verschiedene gängige Methoden zur Anforderungserhebung für Security Systeme vor.

Security concern in the connected world Since the advance of technology, especially the rise of the internet of things, more protocols have been specified, devices are getting smarter, connecting and communicating with each other. Consequently, a huge amount of data is generated and transferred to the network. Data is the new currency of the modern world, who has control of it could take control of the economy. Because of that, any device, system can be a victim of being compromised and data is stolen, particularly systems running in industrial, automotive and medical areas. A security breach impacts not only the business but also the company’s reputation and causes legal consequences. Therefore, security is getting more concern than ever. Embedded hardware security When applying security to the products, some embedded software developers are facing the challenges of new terminologies, knowledge, and standards in this area. Moreover, in the world of breaking is easier than protecting, online courses about “ethical hacking” can be found easily online, sniffing tools are better developed, the goals of developing a secure system is getting more complex. To cope with the increasing threats, new approaches must be created. One of the current trends is hardware security or embedded security with the implementation of secured elements. With the secured elements, one can be sure that the Confidentiality - protection against eavesdropping by encryption, Integrity - proof that data is not alternated, and Authentication – devices are genuine, of his system can be achieved. In addition to the data and the identity of the system, the Intellectual Properties (IP), i.e. the actual code running on the device and the communication stack also required protection. With ARM TrustZone Technology, important pieces of code or communication stack can be isolated and stored in secured memory of the microcontroller or microprocessor. Targets of this lecture To create a secure system, a lot of effort must be spent on integrating new security hardware and technology but the pressure of reducing the time to market remains the same. Not to mention, the chain of trust for the whole system, key management, and devices provisioning must be ensured. Therefore, this lecture aims to provide the audience with the general block function of the secure element, how they are implemented in the system, used cases, and good practices. Furthermore, the usage of ARM TrustZone, focused on the microcontroller, is also addressed. Finally, the lecture indicates the big picture of security implementation to give the audience a better understanding of what must be considered in their embedded design to achieve a secure system.

Integrated security solutions, which are a part of a larger System-on-Chip (SoC), raise new demands regarding the silicon manufacturing, the Secure Operating System design and the communication and management interfaces. This is the case, because in comparison to a “classical” smart card no dedicated security hardware is available. This article describes what impact the SoC integration of security has on the Silicon IP, the memory configuration, the Secure Operating System and the related security services. “Integrated” refers to a security enclave as a submodule, which is no longer located on a separated chip, but is part of the SoC of a larger device together with many other components on the same piece of silicon e.g. application/modem-processor cores, integrated memory and high-bandwidth I/O interfaces. Smart card technology grew over many years steadily with function-wise smaller evolution steps, because security had a higher priority than enhanced functionality. This is changing with new security solutions, which are inherent part of wearables, mobile phones or IoT devices. These integrated security solutions are used for a broad range of security support in the mobile device such as payment functions, device and content protection, network and service authentication and many more.

Die Security-Norm IEC 62443 fordert in ihrem Teil 3-3 für das Foundational Requirement „System integrity“ das System Requirement „Input validation“ (in Abschnitt 7.7). Beispielsweise soll die Einhaltung von Wertebereichen für Datenfelder oder die Wohlgeformtheit von Datenpaketen geprüft werden. Wie kann man dynamisch testen, ob solche Prüfungen implementiert sind und ob sie funktionieren? Eine geeignete Testmethode ist „Fuzz Testing“ bzw. „Fuzzing“. Durch Fuzz Testing werden mehr oder weniger zufällige Eingangsdaten an das zu testende System übertragen und dann beobachtet, ob eine Fehlfunktion ausgelöst wurde. Fuzz Testing wird auch explizit in Teil 4-1 der IEC 62443 genannt, und zwar in Abschnitt 9.4 „Vulnerability testing“. Fuzz Testing kann Zero-Day- Vulnerabilities aufdecken, also Security-Schwachstellen, die bis dato noch niemandem bekannt waren. Fuzz Testing ist ein Black-Box-Test und benötigt keinen Quellcode. Der Bezug von Fuzz Testing zum Robustheitstest und zum Fault-Injection-Test wird hergestellt.

Moderne Software Exposure Lösungen ermöglichen es Software von Anfang an sicher zu entwickeln. Unter Anfang verstehen wir den Zeitpunkt zu dem ein Entwickler ein Stück Code erstellt, was in den heute üblichen agilen Entwicklungsszenarien eigentlich kontinuierlich passiert. Wir zeigen auf, wie statische Quellcode Analyse (Sast), Open Source Analyse (Osa), Interaktive Applikations Analyse (Iast) und interaktives Entwicklertraining zusammenspielen müssen um das Ziel einer möglichst sicheren Software, bzw. einer möglichst geringen Software Exposure mit vernünftigem Aufwand zu erreichen. Im agilen Prozess folgen die Schritte Entwicklung, Build, Unit Test, Integrationstest, Deployment ununterbrochen aufeinander. Softwaresicherheit kann also nicht mehr einfach "am Ende" hinzugefügt werden, weil es ein solches "Ende" nicht mehr gibt. Entwicklertraining ist die eigentliche Grundlage von sicherer Software. Entwickler, welchen die Ideen der sicheren Softwareentwicklung bekannt sind, werden sichereren Code erstellen. Sast kommt beim eigentlichen Schreiben des Codes sowie beim Zusammenbauen des Codes zum Zug. Sast untersucht den Code auf potentielle Schwachstellen und zeigt dem Entwickler wo und wie er die Schwachstelle beheben kann. Open Source Analyse identifiziert verwendete Komponenten und prüft ob öffentlich bekannte Schwachstellen bekannt sind und ob die Lizenz den Unternehmensvorgaben entspricht. Die Interaktive Applikationsanlyse detektiert während des Integrationstests weitere Schwachstellen. Die Ergebnisse der einzelnen Analyseverfahren können in Relation gesetzt werden,um so zu bestimmen, welche Schwachstellen zuerst bereinigt werden sollten. All das muss vollständig automatisiert werden, so dass wirklich jeder Release den gleichen Sicherheitsstandard aufweist. In unserem Beitrag werden wir die einzelnen Technologien im Detail vorstellen und zeigen, welche Methologie erforderlich ist, um das Ziel der Reduktion der Software Exposure zu erreichen.

Embedded network security is the hot topic of today. Every day there are news about security breaches. Until recently security was a topic for IT only. Embedded systems where considered not vulnerable, because of its nature as you need physical access to exploit. But that changed as more systems are connected together for remote monitoring and control. Controller Area Network (CAN) is not different. CAN is mostly associated with automotive, trucks, and buses. Almost everybody heard of the Jeep Chrysler hack with full control of the car from a remote location. It is the classic example of an embedded system hooked up to the Internet, but not designed for it. It all boiled down to: CAN is unsecure. The IT industry has gone through the same cycle: Ethernet is unsecure by design. But nobody considers Ethernet as unsecure today. Because there are ways to make Ethernet secure. That can be applied to CAN, and other embedded networks. At CAN in Automation (CiA) together with our members and experts in the field of security, we are developing protocols, methods, and principles to secure CAN-based embedded systems. The first idea is a version of the Diffie-Hellman-Key exchange, which makes use of the unique features of CAN that anybody could transmit any message, but nobody really does know who transmitted it. Actually, the CAN-based implementation of that initial key exchange is so unique, that no Man-in-the-Middle (MITM) attack is possible and still it is much more efficient than any existing implementation. It is the in bit-time response that makes that happen. The second idea is to use embedded TLS with reused session IDs to secure transmission and allow certificate-based authentication. It is based on the standardized and widely used TLS version 1.3. TLS supports a diverse range of options to make it multipurpose. At the University Offenbach security experts developed ideas on how to limit TLS to make an embedded TLS and how to use that in CAN. The third idea is to allow distributed, authenticated broadcast transmission for embedded control. While embedded TLS is great for point-to-point communication and as such setting up the communication, CAN is an embedded network for control systems. With CAN outputs, hydraulics, pneumatics, electrical drives, and a diverse range of actuators are controlled reliable and robustly. To extend that we need authenticated control. All of which are only pieces of a puzzle and only work, when secure system design and system integration is done. Because, the weakest link in security, even IT security, is the system integration. CAN in Automation (CiA) want to discuss all solutions publically, because Auguste Kerckhoffs published 1883 in its essay entitled La Cryptographie Militaire the principles of cryptography, which are still true today. One of is strongest is: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

The rapid demanding development of driving assist / highly automated driving systems brings gerate challenge in hazard and risk analysis during design for driving automation system with different SAE-levels. This paper proposed a framework to achieve a structured hazard and risk analysis and enable the management of consistence and complexity of different SAE-levels by modular-based solution.

Das Ziel dieser Arbeit ist es, Entwicklern und Testern zu helfen, eine Anzahl von Schwachstellen zu erkennen, die bei der Implementierung von physikalischen Modellen in Controllercode für sicherheitskritische eingebettete Systeme immer wieder auftauchen. Die Trends bei automobiler Softwareentwicklung für eingebettete Systeme gehen in die Richtung von model-predictive control (MPC), virtuellen Sensoren oder modellbasierter Diagnose, welche vor allem im Bereich der erweiterten Fahrassistenzsysteme (ADAS) und des automatisierten Fahrens genutzt werden. Solche Applikationen nutzen physikalische Modelle in den Kontrollalgorithmen, um Aussagen über die kontrollierten Systeme treffen zu können. Die Einbindung physikalischer Modelle ist ein riskantes Unterfangen, da Schwachstellen, wie die Nutzung von Gleitkommaarithmetik und Diskretisierungsmethoden oder Modelleigenschaften wie Unstetigkeiten und Nichtlinearität, schnell ein Projekt zum Scheitern bringen oder Fehler im finalen Produkt etablieren. Die Verwendung erprobter Absicherungsmethoden ist oft nicht möglich oder vermittelt falsche Sicherheit. Diese Arbeit soll Entwicklern helfen, die Schwachstellen zu verstehen und neue Verifikations- und Validierungsmethoden zu entwickeln, die speziell auf physikbasierten Steuergerätecode ausgelegt sind. Dafür wurden diese Schwachstellen in aktuellen industriellen Projekten gesammelt, analysiert und nach Risiko bewertet. Auf dieser Basis werden Vorschläge und Techniken für die Identifikation, Diagnose oder die Vermeidung von potentiellen Fehlern präsentiert, um Tester und Qualitätsmanager zu ermutigen, neue Ansätze für die Absicherung und Fehleridentifikation von kritischem physikbasierten eingebetteten Code zu finden. Der Fokus hierbei liegt auf der gesammelten Erfahrung über die Herausforderungen der Integration physikalischer Modelle in eingebettete Systemen, sowie ersten Ideen, wie man trotz dieser Herausforderungen die Sicherheit der eingebetteten Systeme gewährleisten kann.

Die Hardwaremetriken SPFM, LFM und PMHF werden nach wie vor von der Edition 2 der ISO 26262-5 für Systemsicherheitsnachweise (Safety Case) verlangt. Mit der neuen Ausgabe bzw. der Vorbereitung auf diese sind einige Änderungen bei der Berechnung und Betrachtung zu beachten. Mit der neuen Edition 2 sind die Fahrzeuge der Kategorie „Trucks & Busses“ (T&B) mit unter die ISO26262 gefallen, ebenso Motorräder. Da Motorräder eher saisonal verwendet werden und außerdem überwiegend in privater Anwendung sind, sind sie wie Pkw zu betrachten. Bei T&B steht man Nutzfahrzeugen gegenüber, die als Investition eine deutlich stärkere zeitliche Auslastung auszuhalten haben. Die Anforderung §9.4.2.4 gibt Auskunft über die üblichen Annahmen von Nutzungszeiten, bei Pkw bleibt der Betrachtungsrahmen von 1 h Autofahrt, bei T&B ist der Betrachtungsrahmen auf eine Benutzungszeit von 10 h ausgedehnt. Diese höhere Exposition soll nun auch im PMHF betrachtet werden: §9.x.x. verlangt die operation time over life cycle bei der Berechnung des PMHF mit zu verwenden. Nur wie? Die bisherige ISO26262 hat zur Berechnung des PMHF keine genauen Angaben gemacht. Es hatte sich ab 2012 eingebürgert, den PMHF als Summe der Singlepoint fault, residual fault und aller „undetected“-Beiträge der Multi-Point faults zu berechnen. Den Sinn dieser Berechnung, die auch in den objectives zum Kapitel 9 der der ISO26262-5 Edition 2 vermerkt ist, sagt, dass die Metrik der Verletzung des Safety Goal durch zufällige Hardwarefehler eher als Vergleichsangabe zur Verbesserung des Designs gelten sollte. Somit ist es dem Hersteller auch nach wie vor überlassen, nach welcher Vorschrift eine Vorgabe beispielsweise für den PMHF zu nehmen sei. Üblicherweise orientieren sich die meisten Hersteller an den üblichen Barrieren, die als 100 bzw. 10 Fit Schranken bekannt wurden. Der Vergleich mit vorigen Designs steht nun in den objectives und würde der tradierten Berechnung des PMHF entsprechen. Die Anforderung 9.x.x.x ist für ASIL C und D verpflichtend („required“), für den ASIL B durch Klammersetzung empfohlen („recommended“). Weiterhin bietet die ISO326262-5 in den Annexes F und G Formeln für die Berechnung des PMHF an: (einzusetzende Formel) Nun sind diese Formeln alle unter der Rubrik „informative“ zu finden und somit kann man Ihnen folgen, man muss es nicht. Weitere Berechnungsarten zum PMHF werden im Band ISO26262-10 im Kapitel XX diskutiert. Auch diese sind „informative“. Es sieht so aus, als würde die Definition zur Berechnung des PMHF jeder Organisation selbst überlassen. Das ist grundsätzlich kein Problem, es wird möglicherweise mit der Zeit auch wieder eine gemeinsame Lösung nach dem common sense geben. Für ASIL B könnte die tradierte Berechnung weiterhin Bestand behalten, auch für T&B, die bislang dem Regime der IEC61508 mit einer ähnlichen Berechnung unterlagen. Solange allerdings die Berechnung des PMHF, insbesondere für ASIL C und D, der Festlegung des Auftraggebers obliegt, solange sollten genau diese Festlegungen auch frühzeitig dem Zulieferer verbindlich mitgeteilt werden. Ein guter Ort für diese Festlegungen ist das DIA.

Until recently, embedded software applications in vehicles tended to be static, fixed-function, device-specific implementations. In the current environment of ever-quickening technological change, morphism and evolution are the order of the day. Now we see manufacturers and service providers seeking to monitor, upgrade, enhance and supplement software implementation on a continuous basis. As vehicle systems become more complex, and safety and security considerations are addressed by the standards community, developers need applicable guidance to achieving those requirements. ISO 26262 remains a constant foundation in the midst of this flux, defining the benchmark standard for functional safety across the vehicle life-cycle. The second edition of ISO 26262 has seen an enhancement and revamp of Part 6, which presents extensive recommendations for the software development phase. The use of a language subset to eliminate language-level vulnerabilities lies at the heart of these recommendations. From its inception, MISRA C has been inextricably linked to the need to meet automotive functional safety requirements. This relationship is reflected in the two editions of ISO 26262, both of which suggest the use of MISRA C. In this presentation the chairman of the MISRA C Working Group, Andrew Banks, will discuss the relationship between ISO 26262 and MISRA C. He will explain how MISRA C helps achieve the ISO 26262 goal of safer and more secure automotive software. And he will detail how adherence to MISRA C contributes to the development of the safety case required by ISO 26262 for systems whose malfunction may lead to an unreasonable level of risk.

All safety standards advocate the use of proven components as long as they can be suitably qualified. In medical applications, for instance, these software components are referred to as software of unknown provenance/pedigree (SOUP) and in industrial, as custom-off-the-shelf (COTS) software. In the automotive industry, ISO 26262 has created a clean definition of using proven components called Safety Elements out of Context (SEooC). While SEooCs are more commonly understood as hardware components such as microcontrollers or subsystems, the model provides an ideal approach for developing high-quality software elements out of context. These software elements are designed to provide a specific functionality and meet a required safety level with no awareness of how the software will be used (or even what parts of it will be used) in the final target system. This presentation will discuss how the SEooC model applies to safety-critical software and the advantages it offers developers, the options for implementing SEooCs, and how software SEooCs can be integrated into the automotive supply chain. While the concept is derived from an automotive standard, it can also be applied to other safety-conscious industries such as in aerospace, industrial, and medical device markets.

For the validation of the functional safety of automotive E/E systems and their embedded software proper workflows and virtual test methods are necessary. This need for virtual testing and efficient collaboration in the automotive domain is evermore increasing because of new challenges coming from the development of advanced driver assistance systems (ADAS) and autonomous driving (AD). At the same time the requirements for a process reliability of virtual testing increase as the ADAS/AD systems becoming more and more safety-critical. The presentation outlines necessary development and test strategies which are compliant to ISO 26262 and ISO/PAS 21448 to ensure the proper functionality and safety goals of ADAS/AD functions.

Security is becoming more and more important – especially for connected, (semi-)autonomous vehicles. Already during the design phase of the automotive development process, security needs to be taken into consideration. But how to achieve “security by design” in the automotive domain? We will look at the following aspects: What are the fundamental differences between the safety and security in the development and lifecycle process? What are the external parameters influencing the security design process (e.g. norms, external and internal requirements)? What are the security relevant aspects of the solution that need to be taken into consideration when designing the system (e.g. functions, components, connections and data)? How to systematically identify assets, potential attacks and controls to mitigate attacks? Why it is important to perform the security design in an iterative process and how requirements, functional design and system design influence one another? How to achieve traceability of security design aspect across the entire development process? In the presentation will look at methods and tools that allow a model based security risk analysis approach as an essential part of security by design. This can be applied during the requirements and design phase for all vehicle components and software. Based on the defined functions, components and data, security related damages, threats and controls can be modeled and evaluated. In a scenario based, iterative approach, suitable controls can be chosen for the subsequent implementation and test process. In the presentation we share best practice approaches based on our experience from past 3 years of working in this area.

Immer mehr Betreiber und Systemintegratoren verlangen von Ihren Lieferanten, Komponentenherstellern und Entwicklungspartnern einen Nachweis für ein im Unternehmen etabliertes Informationssicherheits-Managementsystems und nach IT-Sicherheitsstandards entwickelte Produkte (z.B. – TISAX-Label im Bereich Automobilzulieferindustrie). Stellt sich zu allererst die Frage, welche Standards sollen dabei unterstützen werden? Ähnlich dem QM-System nach ISO 9001 hat sich die Umsetzung eines Informationssicherheits-Managementsystems nach ISO 27001 etabliert. In der Automobilzuliefererindustrie wird ein Nachweis nach VDA ISA gefordert, der auf der ISO 27001 basiert und über die ENX - TISAX Plattform ausgetauscht wird. Bei der IT-Sicherheit für industrielle Automatisierungssysteme ist die IEC 62443 der sich etablierende Standard im Markt. Dementsprechend wird der Ruf, durch die Betreiber, nach IEC 62443 zertifizierten Produkten immer lauter. Wie soll man hier vorgehen? In der Regel gibt es eine ganze Palette an erfolgreichen Produkten, denen ohne Zertifizierung sogar das AUS droht? Kann ich diese Produkte nachträglich zertifizieren lassen und mit welchen Aufwänden ist das verbunden. Produktentwicklungen werden in den meisten Unternehmen nach wie vor mit "klassischen", etablierten Entwicklungsprozessen durchgeführt, die sich noch nicht an Vorgaben der IT-Sicherheit und den damit verbundenen Implementierungsanforderungen halten. Für ein Label „IEC 62443 Certified“ müssen Produkt und Prozessanforderungen berücksichtigt werden. Der Vortrag beschreibt eine mögliche Vorgehensweise wie ein Produkt dieses Label erlangen kann und welche Anpassungen an Produkt und Entwicklungsprozess notwendig werden. Dabei werden die Aufgaben der neuen Elemente der IT- Sicherheit wie z.B. Bedrohungsmodell, Defense-in-Depth-Konzepts, Penetration-Test, Codierungsnormen für IT-Sicherheit dargestellt und ihre Bedeutung im Lebenszyklus für eine sichere Produktentwicklung und für die Zertifizierung erläutert. Anhand eines Beispiels wird erläutert wie vorhandene Produktanforderungen auf generische IT-Sicherheitsanforderungen abgebildet und weiterentwickelt werden können.