Vier-Augen-Prinzip erzwingt . Keinem Entwickler ist es möglich , Code ungesehen und ungeprüft in ein Produktrelease zu bringen .
Mittels SonarLint erfolgt eine statische Codeanalyse innerhalb der Entwicklungsumgebung . Zur kontinuierlichen statischen Codeanalyse des Quellcodes und zum kontinuierlichen Testen der technischen Softwarequalität setzen wir die kommerzielle Version von SonarQube auf unserem Build-Server ein . SonarQube deckt mehr als 5.000 statische Analyseregeln ( MISRA- C , CERT C / C ++) ab und hilft dabei , wirklich sauberen Code zu schreiben . Compilerwarnungen und Ergebnisse der statischen Codeanalyse sind nach jedem Build verfügbar .
Die Überprüfung der Korrektheit der Anwendung zur Laufzeit wird von der dynamischen Codeanalyse übernommen . Dank Fuzzing werden viele Eingaben simuliert . Allein dadurch werden viele Sicherheitslücken von Hackern entdeckt , denen wir somit zuvorkommen . Eingesetzt werden unter anderem die Tools Radamsa , LibFuzzer , AFL , WinAFL sowie GCC , ASAN , UBSAN und Valgrind .
Für neue Implementierungen werden Unit- Tests entwickelt , damit wir Regressionen unter Kontrolle haben . Für Fehlerbehebungen passen wir Unit-Tests , aber auch die automatischen Integrationstests an . Wir haben das Konfigurationsmanagement und die Orchestrierung dank Ansible und Terraform unter Kontrolle . Insgesamt benötigen wir eine umfangreiche Infrastruktur zum Entwickeln und Testen , die als Code gehandhabt wird .
Unsere Build- und Testprozesse sind mit Jenkins und mit GitLab Runner automatisiert und wir erstellen jede Nacht einen Build , um die Ergebnisse der nächtlichen Tests unter verschiedenen Betriebssystemen in verschiedenen Anwendungsfällen am nächsten Arbeitstag zu haben . Werden bei den automatischen Tests Fehler entdeckt , werden die Fehlerursachen untersucht und die Probleme behoben . Sicherheitsrelevante Fehler erhalten unabhängig davon , wie sie gefunden wurden , ein entsprechendes Flag . Das stellt sicher , dass sie die höchste Aufmerksamkeit erhalten .
Sichere Produkte können nur von Softwareentwicklern produziert werden , die in der Lage sind , sicheren Code zu schreiben . Durch regelmäßige Schulungen zu Sicherheitsthemen wie den OWASP Top 10 , Best Practices in bestimmten Programmiersprachen , Betriebssystemen und Containern , Fuzzing und vielem mehr lernen Entwickler , wie sie typische Sicher- heitslücken im Code vermeiden können . Durch obligatorische Schulungen im Rahmen des Onboarding-Prozesses für neue Mitarbeiter stellen wir sicher , dass IT-Sicherheit und Sicherheitsbewusstsein nicht zu kurz kommen . Die regelmäßigen Schulungen zu verschiedenen Sicherheitsthemen werden sowohl intern als auch extern durchgeführt . Um die Verfügbarkeitsschwelle zu verringern und Nachverfolgung der Schulungsteilnehmer zu erleichtern , haben wir eine interne Wibu Academy eingeführt .
Third Party Software Zum Alltag jedes Softwareentwicklers gehört , dass Funktionalitäten nicht selbst entwickelt werden , sondern durch Bibliotheken erbracht werden , die von anderen Entwicklern stammen . Eine schlechte Auswahl dieser Bibliotheken kann die Sicherheit der Software gefährden . Auch Angreifer machen sich dies gerne zu Nutze und greifen nicht das Unternehmen , sondern seine Zulieferer an . Solcher Angriffe , auch Supply-Chain-Attacks genannt , ist sich Wibu- Systems bewusst und schützt seine Kunden durch eine gezielte Reduktion der Abhängigkeiten und der sorgfältigen Auswahl und eines engmaschigen Monitorings der übrig bleibenden Komponenten . Als besonders gefährlich erachten wir Build-Prozesse , die zum Build- Zeitpunkt die aktuelle Version aus dem Repository des Anbieters laden . Zwar wird dann die aktuelle Version mit allen Sicherheitspatches verwendet ; es besteht jedoch das Risiko , dass auch der noch unentdeckte Schadcode eines Angreifers integriert wird . Aus diesem Grund werden unsere Build-Systeme so entworfen , dass sie keinen Onlinezugang benötigen und demzufolge auch nicht haben .
Operation Wibu-Systems bietet neben Produkten auch Services an . Einige Produkte hosten wir für unsere Kunden . Die bei Wibu-Systems gehosteten Dienste werden permanent überwacht und gewartet , ebenso wie das Betriebssystem .
Reaktive Maßnahmen Durch all diese Maßnahmen sollte es doch möglich sein , Fehler auszuschließen . Wir wissen , dass wir den Zustand heute noch nicht erreicht haben , und die Autoren dieses Artikels glauben auch nicht daran , dass Fehler grundsätzlich ausgeschlossen werden können . Sie erinnern sich daran , dass ein Fehler in der Definition ebenfalls zu einer Schwachstelle führen kann , die so nicht vorhergesehen wurde ? Richtig , wer könnte Log4Shell so schnell vergessen ? Was da schiefgelaufen ist , müssen wir hier nicht erneut diskutieren .
Wenn wir nicht alle Fehler ausschließen können , müssen wir uns also damit beschäftigen , wie wir mit Fehlern umgehen . Der erste und wichtigste Aspekt ist , dass wir akzeptieren , dass Software Fehler enthält : die Software , die wir selbst entwickeln , und die Software , die wir von anderen Herstellern beziehen und einsetzen . Es geht weniger darum , ob ein Fehler gefunden wurde , sondern wie damit umgegangen wird . Unter der Annahme , dass Schwachstellen nicht absichtlich oder leichtsinnig in die Software gelangt sind , gibt es keinen Grund für Ärger oder Unhöflichkeit .
Ist der Fehler in der Software anderer Hersteller wünschen wir uns drei Dinge : Erstens , dass wir möglichst schnell und einfach eine Version ohne den Fehler erhalten , um uns und unsere Kunden vor Angriffen schützen zu können . Zweitens , dass wir als Betroffene möglichst viele Informationen über die möglichen Auswirkungen erhalten , damit wir selbst beurteilen können , wie wir mit dem Fehler umgehen wollen und müssen . Drittens , dass wir stets über den aktuellen Stand informiert werden .
Wie sieht jedoch die andere Seite aus ? Um einen möglichst guten Support für den Kunden zu ermöglichen , bedarf es einiger Struktur in der Firma , in deren Software die Schwachstelle gefunden wurde . Das beginnt bei einer Stelle , an der Kunden gefundene Schwachstellen melden können , geht über ein Team , das die Behandlung größerer Schwachstellen koordiniert ( CERT ), und die Etablierung fester Kommunikationsstrukturen innerhalb der Firma mit Ansprechpartnern in jedem Produkt , bis hin zu einer guten Koordination der Kommunikation zum Kunden .
Jeder dieser Aspekte verdient das gleiche Maß an Aufmerksamkeit . Und mit Details zu jedem dieser Aspekte lassen sich ganze Bücher füllen – oder für einen Überblick zumindest einen ganzen Artikel . Das haben wir auch bereits getan : Einen ausführlicheren Bericht über die reaktive Seite haben wir bereits letztes Jahr in der KEYnote 43 beschrieben .
https :// www . wibu . com / de / magazin / keynote-artikel / artikel / detail / professionelle-behandlungvon-sicherheitsvorfaellen . html
9