Im Produkt selbst
Speicherunsichere Sprachen (C, C++ usw.)
Nach Möglichkeit sollten speichersichere Sprachen verwendet werden, und bestehende Programme, die das nicht tun, sollten bis Ende 2025 schrittweise ersetzt werden.
Direkte Ausführung von SQL-Anweisungen
Verwenden Sie parametrisierte Queries, vorbereitete Statements oder ein ORM.
Direkte Ausführung von Betriebssystembefehlen
Benutzereingaben dürfen nicht selbst der Befehl sein. Statt Befehle direkt auszuführen, sollten eingebaute Bibliotheksfunktionen verwendet werden, oder die Eingabe sollte auf Buchstaben/Ziffern/Unterstriche beschränkt werden.
Verwendung von allzu bekannten Passwörtern
Dies sollte nach Möglichkeit mit Methoden wie den folgenden vermieden werden.
- Von Anfang an ein individuelles Passwort bereitstellen.
- Während der Installation verlangen, dass der Benutzer ein starkes Passwort erstellt.
- Dem Passwort eine zeitliche Begrenzung geben, etwa wie bei MFA.
- Physischen Zugriff verlangen, um verlässliche Anmeldedaten zu erhalten.
- Kampagnen durchführen oder auf sicherere Authentifizierungsmethoden als bisher umstellen.
Bekannte Schwachstellen unbehandelt lassen
Die auf dieser Seite aufgeführten Schwachstellen sollten „alle“ verhindert werden. Wenn neue Schwachstellen gemeldet werden, müssen sie zeitnah behoben werden, und Benutzer, die nicht auf eine behobene Version aktualisieren, sollten gewarnt werden.
Open-Source-Bibliotheken mit Schwachstellen
Zu den verwendeten Bibliotheken sollte verantwortungsvoll informiert und beigetragen werden. Dazu gehören auch Maßnahmen wie die folgenden.
- Erstellung eines SBOM: zeigt, welche Bibliotheken die Software verwendet.
- Punkte, die für abhängige Open-Source-Bibliotheken gelten
- Sicherheitsprüfungen durchführen.
- Kontinuierliche, gut geschützte, gut gepflegte und qualitativ hochwertige Projekte auswählen. Es ist auch sinnvoll, solche Sicherheitsprinzipien einzuhalten.
- Fortlaufend prüfen, ob bekannte Schwachstellen vorliegen.
- Der Hersteller sollte im Voraus eine Kopie besitzen und nicht von nicht verifizierten Quellen aktualisieren.
- Die Kosten für Updates auf neue Hauptversionen oder für das Einspielen von Sicherheitspatches berücksichtigen.
Wenn eine Schwachstelle das Produkt nicht betrifft, sollte öffentlich erklärt werden, warum sie keine Auswirkungen hat.
Verwundbare oder unbekannte kryptografische Algorithmen (TLS 1.0/1.1, DES, MD5 usw.)
Es sollten aktuelle Algorithmen verwendet werden. Zusätzlich sollte gemäß den Richtlinien des NIST auch die Standardisierung quantensicherer Kryptografie vorbereitet werden.
Geheimschlüssel im Quellcode
Es sollte ein Secret Manager verwendet werden, damit das Programm Geheimschlüssel sicher abrufen kann. Außerdem sollte geprüft werden, ob sich Geheimschlüssel im Quellcode befinden.
Bei Sicherheitsfunktionen
Keine Unterstützung für MFA (einschließlich der ausschließlichen Unterstützung von Passkeys)
Außer bei Dingen, bei denen Verzögerungen gefährlich sind, etwa medizinischen Geräten in der Notaufnahme, sollte standardmäßig entweder MFA direkt implementiert oder ein externer Authenticator verwendet werden. Dies sollte von Administratoren verlangt werden, und Administratoren sollten es von den Benutzern innerhalb der Organisation verlangen.
Keine Bereitstellung von Nachweisen für Eindringversuche
- Als sehr grundlegende Funktion sollten Logs zu Änderungen oder Abfragen von Einstellungen, zur Login-Historie und zu informationsbezogenen Zugriffen erzeugt werden.
- Im Fall von Cloud-Anbietern sollten diese Logs mindestens 6 Monate lang ohne zusätzliche Kosten aufbewahrt und für Benutzer einsehbar gemacht werden.
Bei organisatorischen Prozessen und Richtlinien
Kein CVE veröffentlicht
Kritische oder stark wirksame Schwachstellen sollten sofort offengelegt werden.
Keine Offenlegung eines VDP (Vulnerability Disclosure Program)
Richtlinien wie die folgenden sollten veröffentlicht werden.
- Genehmigung von Tests durch die Allgemeinheit
- Zusage, keine rechtlichen Schritte gegen Personen zu unternehmen, die in guter Absicht handeln
- Ein klarer Kanal für Meldungen
- Best Practices für CVD (Coordinated Vulnerability Disclosure) und internationale Standards
Gemeldete Schwachstellen sollten zeitnah und nach Risiko priorisiert behoben werden.
(Im On-Premises-Fall) Unklare Supportlaufzeit
Die Supportlaufzeit sollte klar kommuniziert werden, und in diesem Zeitraum sollten Sicherheitsupdates bereitgestellt werden.
- One-Click-Exploit in KakaoTalk
- GN⁺: NIST (US National Institute of Standards and Technology) verbietet Vorgaben für die Zusammensetzung von Passwortzeichen
- Weißes Haus fordert Entwickler auf, C und C++ zu meiden und „speichersichere“ Sprachen zu verwenden
- Mein Auto hacken: Hyundai Ioniq: Im Quellcode wurde ein per Google auffindbarer RSA-Chiffretext entdeckt
7 Kommentare
Sicherheit ist so ein Ding – im entscheidenden Moment macht es zack …! (Ich glaube, so etwas habe ich beim Militär gesehen.)
Unbeugsam!
Da wird wohl wieder darüber gesprochen, ORM nicht zu verwenden..
Man kann einfach Prepared Statements statt ORM verwenden.
zzz
Für alles gibt es Prinzipien, man kann sie nur schwer einhalten ...
Gefällt mir, ich stimme zu
Zu verlangen, dass Nutzer ein starkes Passwort erstellen != Sonderzeichen, Groß- und Kleinbuchstaben sowie Zahlen müssen zwingend enthalten sein
Schon eine angemessen große Länge allein ergibt ein starkes Passwort.