Autor:in:
Dr. Sebastian Krings | Axivion GmbH | Germany
Sprache:
deutsch
Zielgruppe:
Entwickler, Architekten, Sicherheitstester
Voraussetzungen:
Grundsätzliche Kenntnisse der Softwareentwicklung
Überblick und Zusammenfassungen:
Mit dem weiterhin wachsenden Einsatz eingebetteter Software in sicherheitskritischen Systemen sind Safety und Security von steigender Bedeutung. Dieser Vortrag befasst sich mit dem Thema "Security". Im Bereich der Security haben sich dabei verschiedene Entwicklungsrichtlinien wie etwa CertC/CertC++, C Secure Coding Guidelines (ISO 17961) und Common Weakness Enumeration (CWE) etabliert.
Durch die zunehmende Vernetzung auch eingebetteter Software durch Themen wie autonomes Fahren, Telemetrie-Anforderungen, Fernwartung (OTA) rücken immer mehr auch die Security Schwachstellen in den Vordergrund. Die CWE bilden dabei eine Wissens-Datenbank über aufgetretene Sicherheitsprobleme und mögliche Gegenmaßnahmen. Dadurch ist CWE herausfordernd, da sie Schwachstellen auflistet statt konkrete Vorgaben zum Code zu machen. Während diese Flexibilität zu einer gründlichen Abdeckung möglicher Schwachstellen führt,
verhindert Sie gleichzeitig die effiziente out-of-the-box Prüfung von Regeln durch eine statische Analyse.
Im Kompaktseminar werden wir die Teilnehmenden in die Lage versetzen, für ihr eigenes Projekt einen Plan für die Prüfung von Sicherheitsregelwerken zu erstellen und anzuwenden.
Dazu werden wir die folgenden Punkte ansprechen:
* Überblick CWE
* Bedrohungsanalyse für ein fiktives Projekt
* Auswahl und Konfiguration von Regeln für eine Prüfung
* Anpassung der Regeln auf die Projektsituation
* Einsatzplan für CWE Prüfungen erstellen (Prüfmittel, Methoden, Zeitplan, ...)
Art der Vermittlung:
Projektseminar 3h, Projektbeispiel, praktische Anwendung
Nutzen:
Die Teilnehmenden
- bekommen einen Überblick über die CWE und was sie von anderen Sicherheitsregelwerken unterscheidet.
- können entscheiden, welches Regelwerk zu ihren jeweiligen Projekten passt.
- erfahren, wie eine Bedrohungsanalyse ablaufen kann.
- erfahren, warum eine solche für die Auswahl und Konfiguration von Regeln notwendig sein kann.
- haben einen Eindruck, wie ausgewählte Regeln geprüft und nach Bedarf angepasst werden können und müssen.
- kennen die Grenzen automatischer Codeprüfung und können Einsatzfelder von manuellem Review, statischer Analyse, Architekturanalyse, etc. abgrenzen.