Lesen Sie hier, wie CERT Java die Sicherheit in der Automobilindustrie revolutioniert hat:
Sicherheit wird zu einem immer wichtigeren Thema für Entwickler von eingebetteten Systemen – insbesondere von vernetzten eingebetteten Systemen und IoT-Geräten (Internet of Things). Nirgendwo wird dies deutlicher als in Branchen wie der Automobilsoftware, in denen vernetzte Autos, Telematiksysteme, IVI-Systeme (In Vehicle Infotainment) und Konnektivität im Allgemeinen in einem erstaunlichen Tempo wachsen.
Für die Automobilindustrie soll die Norm ISO/SAE 21434 die wachsenden Bedenken hinsichtlich der Sicherheit – von denen es viele gibt – für diese neuen vernetzten Geräte an Bord adressieren.
Funktionale Sicherheit und ISO 21434
ISO/SAE 21434: Road vehicles – Cybersecurity Engineering, soll, wie der Titel schon sagt, dazu beitragen, die Herausforderungen der Cybersicherheit für Kraftfahrzeuge zu bewältigen. Ähnlich, wie es die ISO 26262 für die funktionale Sicherheit getan hat.
Die ISO 21434 wurde 2021 veröffentlicht. Ähnlich wie andere Normen – wie IEC 81001-5-1 und IEC 62443 – für andere Embedded-Branchen, in denen die Sicherheit vernetzter Systeme ein wachsendes Problem darstellt, empfiehlt ISO 21434 die Verwendung sicherer Codierungsrichtlinien, um Entwicklern zu helfen, robusteren und sichereren Code von Grund auf zu erstellen.
Das Wachstum von Java in Automotive-Systemen
IVI- und zentrale Dashboard-Systeme in der Automobilindustrie sind bestrebt, die Art von Benutzeroberfläche und Konnektivität zu reproduzieren. Verbraucher sind es von ihren Mobiltelefonen und Home-Entertainment-Systemen ebenfalls gewohnt, daher ist der Bedarf an Betriebssystemen wie Android schnell gestiegen. Heute basieren fast alle High-End-IVI-Systeme auf der Android AOSP (Android Open Source Platform).
In ihren neuesten Versionen besteht die Android-Plattform aus über 15 Millionen Zeilen C- und C++-Code, aber fast 30 Millionen Zeilen Java-Code, Tendenz steigend. Um Anpassungen und Erweiterungen der Plattform zu entwickeln, ist es notwendig, Code sowohl innerhalb des C++- als auch des Java-Codes hinzuzufügen und zu modifizieren, Änderungen und Ergänzungen müssen auf Sicherheitsauswirkungen überprüft werden.
CERT Java
Während ISO 21434 und ähnliche Standards die Verwendung von CERT C oder MISRA C:2012 für die sichere Entwicklung von C-Code empfehlen, gibt es keine solchen Empfehlungen für die Verwendung der Programmiersprache Java. Was sollte man also wählen?
CERT C und CERT C++ – kuratiert und gepflegt von der Carnegie Mellon University – sind sehr stark auf die sichere Codierung für die Sprachen C bzw. C++ ausgerichtet, und so scheint CERT Java unweigerlich eine offensichtliche Wahl für die Programmiersprache Java zu sein.
Der OWASP (Open Web Application Security Project) Top 10 Codierungsstandard, der unabhängig zur Programmiersprache ist, aber im Allgemeinen für Web- und mobile Technologiesprachen wie Java gilt, ist eine weitere Option. Da sich OWASP jedoch mehr auf den Web- und mobilen Anwendungsbereich konzentriert, bietet es möglicherweise weniger Wert für einen eingebetteten Softwarekontext, den On-Board-Automotive-Systeme darstellen und CERT Java bietet.
Was benötigt CERT Java?
Dieser Codierungsstandard enthält 19 Top-Level-Regeln – eigentlich Regelkategorien –, die die Hauptklassen von Sicherheitslücken darstellen und jeweils mehrere spezifische Unterregeln enthalten.
Die obersten Regelkategorien sind:
- 1. Regel 00. Eingabevalidierung und Datenbereinigung (IDS)
- 2. Regel 01. Deklarationen und Initialisierung (DCL)
- 3. Regel 02. Ausdrücke (EXP)
- 4. Regel 03. Numerische Typen und Operationen (NUM)
- 5. Regel 04. Zeichen und Zeichenfolgen (STR)
- 6. Regel 05. Objektorientierung (OBJ)
- 7. Regel 06. Methoden (MWB)
- 8. Artikel 07. Außergewöhnliches Verhalten (ERR)
- 9. Regel 08. Sichtbarkeit und Atomarität (VNA)
- 10. Regel 09. Verriegelung (LCK)
- 11. Regel 10. Thread-APIs (THI)
- 12. Artikel 11. Threadpools (TPS)
- 13. Artikel 12. Gewindesicherheit Sonstiges (TSM)
- 14. Artikel 13. Eingang Ausgang (FIO)
- 15. Artikel 14. Serialisierung (SER)
- 16. Artikel 15. Plattformsicherheit (SEC)
- 17. Artikel 16. Laufzeitumgebung (ENV)
- 18. Artikel 17. Java Native Interface (JNI)
- 19. Artikel 49. Sonstiges (MSC)
Es gibt insgesamt 183 Unterregeln für diese 19-Regelkategorien.
Erzwingen von CERT-Java-Codierungsregeln
Der einfachste und kostengünstigste Weg, einen Codierungsstandard durchzusetzen, ist die Verwendung von statischen Codeanalysetools – oder SAST-Tools (Static Application Security Test), wie sie im Sicherheitskontext genannt werden. Diese können den Prozess der Überprüfung des Quellcodes anhand von vielen hundert Regeln in kürzester Zeit automatisieren.
Derzeit gibt es nur sehr wenige Tools auf dem Markt, die in der Lage sind, den Codierungsstandard durchzusetzen.
Ein Tool, das dazu in der Lage ist, ist das Understand by SciTools Codecheck-Tool, das derzeit alle 19 Regelkategorien und über 60% der einzelnen Unterregeln abdeckt.
Messen Sie Ihre Konformität mit Understand by SciTools
Bitte kontaktieren Sie uns , wenn Sie eine kostenlose Testversion von Understand by SciTools wünschen, um Ihre Konformität mit noch heute zu überprüfen!