• CWE-636: Not Failing Securely ('Failing Open')

Wenn das Produkt auf einen Fehlerzustand oder einen Ausfall stößt, erfordert sein Design, dass es in einen Zustand zurückfällt, der weniger sicher ist als andere verfügbare Optionen. Dies kann beispielsweise die Auswahl des schwächsten encryption algorithm oder die Anwendung der großzügigsten access control restrictions beinhalten.

CWE-Referenz › CWE-636: Not Failing Securely ('Failing Open')

CWE-636: Not Failing Securely ('Failing Open')

CWE ID: 636
Name: Not Failing Securely (‘Failing Open’)

Beschreibung

Wenn das Produkt auf einen Fehlerzustand oder einen Ausfall stößt, erfordert sein Design, dass es in einen Zustand zurückfällt, der weniger sicher ist als andere verfügbare Optionen. Dies kann beispielsweise die Auswahl des schwächsten encryption algorithm oder die Anwendung der großzügigsten access control restrictions beinhalten.

Erweiterte Beschreibung

Durch den Übergang in einen weniger sicheren Zustand erbt das Produkt die Schwächen, die mit diesem Zustand verbunden sind, was eine Kompromittierung erleichtert. Im Minimum führt dies dazu, dass Administratoren ein falsches Sicherheitsgefühl entwickeln. Diese Schwäche entsteht typischerweise durch den Wunsch, “fail functional” zu implementieren, um die administration und support costs zu minimieren, anstatt “fail safe” zu wählen.

Risikominderungsmaßnahmen

Maßnahme (Architecture and Design)

Effektivität: Unknown
Beschreibung: Teilen Sie die Struktur auf und weisen Sie Ressourcen und Komponenten so zu, dass ein Fehler in einem Teilbereich nicht das gesamte Produkt beeinträchtigt.

Ist Ihre IT-Infrastruktur betroffen?

Schwachstellen wie CWE-636: Not Failing Securely ('Failing Open') werden von Angreifern gezielt gesucht — meist automatisiert und ohne Rücksicht darauf, wie groß das betroffene Unternehmen ist. Ob eine solche Lücke bei Ihnen tatsächlich offen steht, lässt sich nur durch Prüfung feststellen:

  • Schwachstellen-Scan — wiederkehrende Prüfung Ihrer Infrastruktur auf bekannte Lücken wie diese
  • Penetrationstest — manuelle Prüfung eigener Software auf Schwachstellen, die kein Werkzeug findet
  • Threat Modeling — Schwachstellenklassen im Entwurf vermeiden, statt sie später zu suchen
Kostenloses Erstgespräch Für mittelständische Unternehmen