- Implementieren Sie niemals Ihre eigene Kryptographie.
- Verwenden Sie immer TLS.
- Sicherheit durch Dunkelheit ist schlecht.
Und dergleichen. Die meisten von ihnen sind im Allgemeinen richtig. Es scheint mir jedoch, dass die Menschen diesen Axiomen blind als Frachtkult folgen. Und viele denken nicht wirklich über Ausnahmen von der Regel nach. In diesem Artikel werde ich meine Einwände gegen die Idee erheben, dass Sicherheit durch Dunkelheit schlecht ist.
Risiko, Schichtverteidigung und Schweizer Käse
Eine der Hauptaufgaben der Informationssicherheit ist die Risikominderung. Gemäß der OWASP-Methodik wird das Risiko eines Problems anhand der folgenden Formel berechnet:
Risiko = Wahrscheinlichkeit * Auswirkung
Durch diese Formel stellt das Problem der Remotecodeausführung (RCE) ein größeres Risiko dar als das Problem der standortübergreifenden Skripterstellung, da die RCE eine größere Auswirkung hat. Hier ist alles einfach. Aber was ist mit der Wahrscheinlichkeitsmetrik? Laut OWASP ist die Wahrscheinlichkeit wie folgt definiert:
Auf höchster Ebene handelt es sich um eine grobe Schätzung der Wahrscheinlichkeit, dass eine bestimmte Sicherheitsanfälligkeit von einem Angreifer aufgedeckt und ausgenutzt wird.
Wenn wir also die Wahrscheinlichkeit verringern, verringern wir das Gesamtrisiko. Das ist gut. Tatsächlich ist es dem bekannten Konzept der "Tiefenverteidigung" sehr ähnlich. Es wird auch als "Schweizer Käsemodell" bezeichnet.
Nach diesem Modell müssen Sie Verteidigungsmechanismen in einem Schichtmodell so aufbauen, dass ein Angreifer, selbst wenn er das erste Level passiert, bei anderen gestoppt wird.
Sicherheit durch Dunkelheit
Sprechen wir also über Sicherheit durch Dunkelheit. Es ist eine schlechte Idee, es als Ihre einzige Schutzschicht zu verwenden. Wenn der Angreifer daran vorbeikommt, schützt Sie nichts anderes. Aber als "Extra" -Level ist es eigentlich ganz gut. Weil es niedrige Implementierungskosten hat und normalerweise gut funktioniert.
Betrachten wir verschiedene Szenarien:
- Auf meinem Server wird SSH auf dem Standardport 22 und den Anmeldeinformationen ausgeführt
root:123456. Wie hoch ist die Wahrscheinlichkeit eines Kompromisses?
Die Wahrscheinlichkeit liegt bei fast 100%, da Hacker im gesamten Internet Brute-Force-Dienste mit Standardanmeldeinformationen sind.
- SSH läuft auf Port 22 und den Anmeldeinformationen
utku:123456. Wie hoch ist die Wahrscheinlichkeit eines Kompromisses?
Nun, wir haben die Gefahr von Brute-Force mit Standardausweisen beseitigt. Die Wahrscheinlichkeit und das Risiko werden reduziert. Wir sind jedoch immer noch mit einer Menge gezielter Angriffe konfrontiert. Jemand könnte den utku-Benutzernamen erraten, da dies mein richtiger Name ist.
- SSH läuft auf Port 64323 und Anmeldeinformationen
utku:123456. Wie hoch ist die Wahrscheinlichkeit eines Kompromisses?
Wir haben die Standardportnummer geändert. Wird es helfen? Erstens haben wir die Gefahr von Standard-Brute-Force erneut beseitigt, da nur gemeinsame Ports gescannt werden. Was ist mit dem Rest? Ich habe auf meinem Twitter eine kleine Umfrage durchgeführt, um das Verhalten von Personen beim Scannen von Ports herauszufinden.
Wie Sie sehen können, scannen viele nur die Standard- und beliebtesten Ports. Wenn Sie also den Port von 22 auf 64323 ändern, werden Sie einige der potenziellen Angriffe eliminieren. Sie reduzieren die Wahrscheinlichkeit und das Risiko.
Gleiches gilt für Software-Schwachstellen. Wenn im Microsoft Remote Desktop Protocol eine Sicherheitsanfälligkeit gefunden wird, beginnt das gesamte Internet mit dem Scannen von Port 3389. Sie können die Risiken einfach durch Ändern des Standardports verringern.
Andere Anwendungen
Abgesehen von der Änderung der Standardwerte können Sie natürlich auch in anderen Bereichen dieselbe Methode verwenden. In einigen Fällen (nicht immer) können die folgenden Ideen angewendet werden.
- Code-Verschleierung : Dies ist natürlich allgemein bekannt. Hacker sind auch Menschen. Wenn Sie Ihren Code gut verschleiern, müssen sie mehr Zeit damit verbringen, nach Problemen zu suchen. Schließlich können sie aufgeben.
- Zufällige Variablennamen für eine Webanwendung : Sie können zufällige Zeichen anstelle benutzerfreundlicher Variablennamen verwenden. Dies kann genauso helfen wie die Verschleierung von Code.
- :
encryption_algorithm(data, key). , —decryption_algorithm(data, key). , , , . - - , (, SQL-), .
Sicherheit durch Dunkelheit wird häufig in der physischen / realen Sicherheit eingesetzt. Zum Beispiel fährt der Präsident mit einer Wagenkolonne von 30 Autos von Punkt A nach Punkt B. Aber er sitzt nicht in seinem Präsidentenauto, damit er nicht zu einem leichten Ziel wird. Es kann sich in jeder Maschine im Tupel befinden, was das Risiko eines Angriffs verringert.
Tiere nutzen Sicherheit auch durch Dunkelheit aus - es ist Tarnung. Stealth verringert die Wahrscheinlichkeit, getötet zu werden. Daher haben sie im Verlauf der Evolution diese Fähigkeit erworben.
Ausgabe
Sicherheit durch Dunkelheit allein reicht nicht aus. Best Practices sollten immer angewendet werden. Aber wenn Sie Ihr Risiko ohne Kosten reduzieren können, sollten Sie es tun. Dunkelheit ist eine gute Schicht im gesamten Sicherheitssystem.