Verwaltung der OWASP Top 10-Risiken

Alle Zugriffe werden von unserem Backend-System auf der Grundlage der erforderlichen Daten, einschließlich der Identität des Anrufers, des aufgerufenen Endpunkts und der Anfrageparameter, autorisiert, um sowohl eine vertikale als auch eine horizontale Eskalation der Rechte zu verhindern. Zugangskontrolllösungen werden nach Möglichkeit wiederverwendet. API-Aufrufe im Zusammenhang mit der Authentifizierung sind begrenzt, um das Risiko von DoS und automatisiertem Data Harvesting zu verringern.

Jede Verbindung zwischen Web-Clients oder neueren Geräten und unseren Servern unterstützt immer TLS. Dazu gehören Verbindungen von Client-Browsern zu unseren Webservern, aber auch Verbindungen von Geräten zu unseren Diensten. Klartextprotokolle werden nicht für die Gerätekommunikation auf Geräten verwendet, die sensible Daten übertragen, es sei denn, es handelt sich um eine spezielle Kundenanforderung für die Gerätekommunikation.

Die kryptografischen Algorithmen und die Stärke der Schlüssel werden regelmäßig überprüft und bei Bedarf aktualisiert.

Die in unseren SQL-Datenbanken ruhenden Daten werden auf verschlüsselten Datenträgern gespeichert.

Als erste Verteidigungslinie gegen Schwachstellen vom Typ Injektion implementieren unsere Webanwendungen eine Eingabevalidierung. Benutzereingaben werden auf Typ und Format geprüft, wo dies möglich ist.

Moderne Frameworks bieten auch eine geeignete Kodierung, um Injektionen bei der Erstellung bestimmter Objekte, einschließlich XML-Dokumenten, zu verhindern, was das Risiko solcher Schwachstellen verringert.

Das Risiko der SQL-Injektion wird durch die korrekte Verwendung eines ORM noch weiter verringert.

Das Risiko von OS Command Injection wird auch durch den zugrundeliegenden Java-basierten Technologie-Stack, bei dem OS-Befehle niemals von Code aus ausgeführt werden, stark reduziert.

Was XSS betrifft, so überprüfen wir unseren Code und unsere Testumgebungen manuell auf Cross-Site-Scripting. Einige Technologien und Frameworks, die wir verwenden, helfen dabei, XSS zu verhindern, indem sie standardmäßig eine geeignete Kodierung anwenden.

Unsere internen Coding Security Standards und unsere Secure Design Principles dienen als Liste von Sicherheitsanforderungen und stellen eine Liste von Regeln dar, die der gesamte Code und die Architektur befolgen müssen. Bei Entscheidungen über mögliche Verbesserungen berücksichtigen wir Quellen wie BSIMM und SAMM. Unser Sicherheitsrat sorgt für die Steuerung und Überwachung des Sicherheitsdesigns.

Wir sind bestrebt, das Prinzip der geringsten Privilegien auf allen Ebenen unseres Technologie-Stacks umzusetzen. Die Angriffsfläche wird auch dadurch verringert, dass nur die notwendigen Komponenten installiert werden. Die Serverkonfiguration wird durch automatisierte Lösungen verwaltet, um die Einhaltung der internen Richtlinien zu gewährleisten. Die Konfigurationen auf Anwendungsebene werden ebenfalls automatisch verwaltet und mittels Sicherheitscodeprüfung und statischer Analyse überprüft.

Bei der XML-Verarbeitung wird die Inline-DTD-Verarbeitung nach Möglichkeit deaktiviert, oder es werden geeignete Abhilfemaßnahmen angewandt, wenn dies erforderlich ist.

Wir überprüfen Komponenten von Drittanbietern und ihre Schwachstellen. Komponenten mit Schwachstellen werden bewertet, und wenn die Schwachstelle unsere Dienste beeinträchtigt, wird je nach Risiko eine Aktualisierung oder Behebung geplant. Im Falle von Open-Source-Komponenten wird dies auch durch GitHub-Benachrichtigungen über anfällige Komponenten unterstützt. Darüber hinaus führen wir regelmäßige Netzwerk-Scans durch, um anfällige Dienste in unseren Umgebungen zu finden.

Unsere Webanwendungen erfordern starke Passwörter gemäß den NIST-Empfehlungen (NIST 800-63-3).

Konten werden für exponentiell ansteigende Zeiträume nach einer Anzahl von erfolglosen Anmeldeversuchen gesperrt. Sowohl erfolgreiche als auch fehlgeschlagene Anmeldeversuche werden protokolliert. Die Wiederherstellung von Passwörtern erfolgt per E-Mail, wobei nur Token gesendet werden. Passwörter werden niemals per E-Mail verschickt. Die Passwörter in der Datenbank werden mit einer geeigneten Schlüsselableitungsfunktion (nicht mit einem einfachen kryptografischen Hash) unter Verwendung standardmäßiger, bekannter Implementierungen gehasht. Dies verhindert Brute-Force-Angriffe selbst bei einer bekannten Liste von Passwort-Hashes.

Unsere Webdienste werden über eine vertrauenswürdige, überprüfte CI-Pipeline aktualisiert. Schwachstellen in Modulen von Drittanbietern werden über eine teilweise von GitHub bereitgestellte Automatisierung überprüft. Die Geräte verwenden signierte Firmware-Updates und laden keine unsignierten oder nicht vertrauenswürdigen Images. Firmware kann nur über einen strengen, sorgfältig konzipierten Prozess signiert werden, der die Signierschlüssel angemessen schützt.

Überprüfbare Ereignisse werden protokolliert, und die Protokolle werden in einem zentralen Repository in Echtzeit gesammelt. Prüfpfade sind verfügbar. Wir haben eine Anwendungsüberwachung eingerichtet, um Anomalien zu erkennen. Die Protokollierung enthält niemals Geheimnisse und ist mit der GDPR konform.

Die Entwickler sind sich der SSRF bewusst, Codeüberprüfungen und statisches Scannen helfen, solche Probleme zu verhindern. Benutzereingaben werden bei Bedarf bereinigt, um SSRF abzuschwächen. Es ist auch Teil unserer Penetrationstests, speziell nach ähnlichen Problemen zu suchen.