/ Fachartikel, Corporate

Was bei der Werkzeugauswahl in Bezug auf Cybersecurity und Funktionale Sicherheit zu beachten ist

OEM&Lieferant | August 2023

Von Marc Maußner, Senior Engineer, infoteam Software Gruppe

Funktionale Sicherheit und Cybersecurity sind heutzutage nicht mehr nur im Automotive-Sektor in aller Munde. Sie halten Einzug in vielen Bereichen des täglichen Lebens. Beide Fachbereiche stellen hohe Anforderungen an (Entwicklungs-)Werkzeuge – vom Serienstart bis zum Projektende (End of Production oder End of Product). Nach einer etwas genaueren Vorstellung der beiden Fachbereiche geht dieser Artikel auf Gemeinsamkeiten und Unterschiede in den Anforderungen an die Werkzeugauswahl in beiden Disziplinen ein. Den Abschluss bildet ein Fazit mit Empfehlungen zur eigenen Umsetzung in Projekten.

Beim Fachbereich Cybersecurity geht es um das Betrachten und Schützen von Assets, also von schützenswürdigen Werten aller Art, in Bezug auf die CIA-Kriterien (Confidentiality, Integrity, Availability). Welche Risiken von Angriffen auf Assets es gibt und wie hoch sie sind, wird in einem TARA (Threat and Risik Assessment) bewertet. Im Zuge dessen wer den Gefährdungsszenarien beschrieben und es wird darauf eingegangen, welche Kenntnisse ein möglicher Angreifer besitzen muss, um Angriffe auf Assets erfolgreich durchzuführen. Im Anschluss werden Gegenmaßnahmen zur Risikoreduzierung identifiziert und können danach im Projekt umgesetzt werden.

Der Fachbereich Funktionale Sicherheit ist darauf ausgerichtet, Risiken für Leib und Leben auf ein „akzeptables“ Niveau zu reduzieren. Die Funktionale Sicherheit befasst sich mit Anforderungen an Entwicklungsprozesse, Produktion, Inbetriebnahme und Außerbetriebnahme sowie mit Maßnahmen, um Anzahl und Auswirkungen zufällig auftretender Hardwarefehler im Produkt zu minimieren.

Die erste Gemeinsamkeit der beiden Fachbereiche liegt in der übereinstimmenden Forderung, sich um alle im Projekt verwendeten Werkzeuge zu kümmern. Dabei soll die Dokumentation der Tools mit Verwendung und der verwendeten Version erfolgen. Weiterhin ist beiden Fachbereichen gemein, dass die Werkzeugauswahl mit umso erheblicheren Mehraufwänden einhergeht, je später die Tätigkeiten während des Projektlebenszyklus abgeschlossen werden, da Änderungen in den Tools normalerweise auch zu Änderungen in Prozessen und Handlungsanweisungen führen.

Die Unterschiede liegen in der Betrachtung der Werkzeuge: Bei der Funktionalen Sicherheit geht es um den Werkzeugeinfluss auf das zu erstellende Produkt und um dessen Gefahren für Leib und Leben, wohingegen die Cybersecurity den Blick auf die Assets mit ihren CIA-Attributen richtet. Ein weiterer wichtiger Unterschied liegt in der Lebensdauer der Projekte und damit dem Zeitraum, über den hinweg auch die Werkzeuge zu warten sind. Die Funktionale Sicherheit gibt hier den Zeitpunkt End of Production oder der Stilllegung an, wohingegen die Cybersecurity vom End of Product spricht. In der Automotive-Domäne kann der Unterschied 10–20 Jahre oder gar darüber hinaus von der Produktion bis zur Stilllegung betragen.

Um Aufwände in Bezug auf Werkzeuge, Qualifikation und Wartung zu minimieren, ist es wichtig, beide Fachbereiche gleich zu Beginn eines Projekts miteinzubeziehen. Dann können sich die Fachbereiche sowohl inhaltlich als auch zeitlich hinsichtlich ihrer Aktivitäten abstimmen. Außerdem kann das Projektteam von Beginn an bezüglich der „Dos“ und „Don’ts“ der Werkzeugauswahl geschult werden.

Eine weitere Best Practice ist die Zusammenstellung der BOM (Bill of Materials) auch für Software-Werkzeuge. Sie sollte in einem standardisierten Dateiformat (abseits von Excel) erfolgen und zentral für alle Projekte abgelegt sein. Damit ist es möglich, unmittelbar ab Meldung von Zero-Day-Exploits in Werkzeugen unternehmensweite und zentrale Prüfungen ihrer Verwendung, eventuell auch automatisiert, in allen Projekten durch zuführen. Die BOM reduziert folglich nicht nur die Reaktionszeit und damit das potenzielle Risiko, dass Angreifer Schwachstellen in Produkten ausnutzen, sondern minimiert auch den Aufwand einer sonst dezentralen Prüfung in den Projekten.

Erschienen in "OEM&Lieferant" - hier geht´s zum Online-Artikel (Seite 32).