Frage:
Die gültige Rolle der Dunkelheit
Bell
2011-03-07 02:31:11 UTC
view on stackexchange narkive permalink

Dass Sicherheit durch Dunkelheit eine schlechte Sache ist, ist Weisheit und Dogma in der Informationssicherheit. Menschen zu sagen, warum etwas vermieden werden soll kann erheblich schwieriger sein, wenn es keine Linie gibt, die beschreibt, was Sie von scheinbar wirksamen Strategien verbannen möchten.

Zum Beispiel - Das Ausführen von ssh auf einem nicht standardmäßigen Port und Port Knocking werden beide als Möglichkeiten zur Verbesserung der SSH-Sicherheit vorgeschlagen, und beide werden als ineffektive Sicherheit durch Dunkelheit kritisiert.

In In diesem speziellen Fall reduzieren beide Lösungen die Sichtbarkeit des Systems auf automatisierte Versuche. Dies trägt nicht dazu bei, die Effektivität von ssh als Tool zu verbessern oder den Bedarf an anderen ssh-Sicherheitsmaßnahmen zu verringern. Es bietet jedoch eine Möglichkeit, ernsthafte Versuche von automatisierten Passanten zu trennen, was die Verwaltbarkeit des Systems verbessert.

  • Welche Unterschiede beschreiben neben Verwaltbarkeit / Effektivität die Grenze zwischen gültigen / ungültigen Verwendungen von Dunkelheit?
  • Welche Analogien beschreiben die effektive Nutzung von Dunkelheit oder unterscheiden zwischen dieser und der ineffektiven Nutzung?
  • Welche Analogien, die anscheinend die Wirksamkeit von Dunkelheit unterstützen, halten nicht stand und warum?
  • Welche anderen spezifischen Implementierungen sind Beispiele für die gültige Rolle der Dunkelheit?
Drei antworten:
#1
+41
Rory McCune
2011-03-07 03:46:49 UTC
view on stackexchange narkive permalink

Interessante Frage. Meine Gedanken dazu sind, dass das Verschleiern von Informationen in vielen Fällen für die Sicherheit hilfreich ist, da sie einen Angreifer dazu zwingen können, mehr "Rauschen" zu erzeugen, das erkannt werden kann.

Wo Dunkelheit eine "schlechte Sache" ist, kann wo sein Der Verteidiger verlässt sich auf diese Unklarheit als kritische Kontrolle, und ohne diese Unklarheit schlägt die Kontrolle fehl.

Zusätzlich zu der oben angegebenen könnte eine effektive Verwendung der Unklarheit darin bestehen, den Namen und die Version der Software zu entfernen Informationen von Internetdiensten. Dies hat folgende Vorteile:

Das heißt, es sollte niemals die einzige Verteidigungslinie sein. Im obigen Beispiel sollte der Dienst weiterhin gehärtet und gepatcht sein, um die Sicherheit zu gewährleisten.

Wo ich denke, dass Dunkelheit versagt, ist es, worauf man sich verlässt. Dinge wie fest codierte Passwörter, die nicht geändert werden, die Verschleierung von Geheimnissen mit "hausgemachter Verschlüsselung" oder die Entscheidung, ob ein Dienst gepatcht werden soll, basieren auf der Idee, dass niemand ihn angreifen wird. Die Art von Idee, dass niemand dies finden / wissen / angreifen wird, schlägt im Allgemeinen fehl, möglicherweise weil die Verteidiger ihr Konzept einschränken, wer ein gültiger Angreifer sein könnte. Es ist alles sehr gut zu sagen, dass sich ein unmotivierter externer Angreifer möglicherweise nicht die Zeit nimmt, um eine obskure Kontrolle zu enträtseln. Wenn sich der Angreifer jedoch als verärgerter ehemaliger Mitarbeiter herausstellt, kann dieses fest codierte Kennwort einige schwerwiegende Probleme verursachen.

Ich habe oft gehört, wie Administratoren etwas Ähnliches sagten wie "Dieses System ist so alt, dass niemand mehr weiß, wie man danach sucht." beim Versuch zu rechtfertigen, nicht zu patchen. Schöne Diskussion OtherRory.
Gute Antwort. Der Ausdruck "Sicherheit durch Dunkelheit ist schlecht" muss erweitert werden auf "Sicherheit durch Dunkelheit ist schlecht, wenn es die einzige Sicherheit ist, die Sie haben". Machen Sie die Arbeit des Angreifers auf jeden Fall schwieriger, indem Sie Details verschleiern. Sie sollten jedoch auch davon ausgehen, dass der Angreifer alle Details kennt (mit Ausnahme genau definierter Geheimnisse wie Kennwörter (die geändert werden müssen)), und Ihre Sicherheit in diesem Zusammenhang überprüfen.
Gut gesagt und gut kommentiert @Cameron. Das bekannte Prinzip wird fälschlicherweise als "Vermeiden Sie jegliche Sicherheit durch Dunkelheit" anstelle von "Verlassen Sie sich nicht nur auf Sicherheit durch Dunkelheit" bezeichnet. In der Tat würde ich es fördern, da es Ihre potenziellen Angreifer einschränken kann. Sie sind zwar auf die gefährlichen, sachkundigen beschränkt, aber Sie können sich auf sie konzentrieren, anstatt sich mit all dem Lärm von Drehbuchkindern und dergleichen zu befassen. "Machen Sie es zuerst sicher, * dann * machen Sie es dunkel."
Aus meiner persönlichen Erfahrung ist das, was Rory erwähnte, ziemlich interessant, "könnte das Entfernen von Software-Namen und Versionsinformationen aus internetfähigen Diensten sein". Diese Informationen werden hauptsächlich von der Support-Organisation benötigt. Normalerweise fügt Entwickler es hinzu und es landet in Google. Trotzdem kann ich sagen, dass Kunden und Support dies als äußerst wertvolle Information empfinden und noch mehr das Patch-Level anfordern ... Daher empfahl ich, diese Informationen auf der Grundlage des Grundsatzes der Notwendigkeit zu kennen.
@AviD: ** "Erst machen Sie es sicher, * dann * machen Sie es dunkel." ** Ich mag das sehr und ich werde mich daran erinnern. Wenn Sie Ihr System in großem Umfang bewerben, bevor Sie zum zweiten Schritt übergehen, fällt es Ihnen natürlich schwer, "es dunkel zu machen". :) :)
@AviD Ist das ein Zitat von irgendwoher?Ich habe diese Worte gegoogelt und dieser Thread war das einzige Ergebnis.
@AviD Das eigentliche Problem ist, dass die Leute, die "obskure Systeme" entwerfen, oft keine Ahnung haben, wie ein Angreifer auf sie reagieren wird.Ich habe unzählige Beispiele von Menschen gesehen, die absolut sicher sind, dass ihre selbstgebaute Sprengfalle jeden Angreifer fängt, obwohl sie in Wirklichkeit selbst von den minimal ausgebildeten Sicherheitsexperten sofort bemerkt werden.Die Version der Dunkelheit eines echten Profis beinhaltet Dinge wie stark verschleierte ausführbare Anti-Debugging-Dateien, die das seltsame CPU-Verhalten ausnutzen, um ausgeführt zu werden._Das_ ist tatsächlich nützlich und erfordert möglicherweise einen erfahrenen Reverse Engineer, um zu brechen.
#2
+15
D.W.
2011-03-09 11:21:23 UTC
view on stackexchange narkive permalink

Sie haben die konventionelle Weisheit falsch charakterisiert. Die konventionelle Weisheit sagt nicht, dass Dunkelheit schlecht ist. Es heißt, dass es schlecht ist, sich durch Dunkelheit auf Sicherheit zu verlassen: Dies führt normalerweise zu fragilen oder unsicheren Systemen. Beachten Sie den Unterschied. Dunkelheit kann zusätzliche Sicherheit bieten, aber Sie sollten sich nicht darauf verlassen, und es sollte nicht Ihre primäre Verteidigung sein. Sie sollten darauf vorbereitet sein, dass die Dunkelheit durchbohrt wird, und sicher sein, dass Sie über ausreichende Abwehrkräfte verfügen, um diesen Fall zu behandeln.

Ein wichtiges Konzept hier ist das Kerckhoff-Prinzip. Bereits im 19. Jahrhundert hat Kerckhoff die Gründe formuliert, warum wir der Sicherheit durch Dunkelheit skeptisch gegenüberstehen sollten und wie man eine Grenze zwischen angemessener und unangemessener Verwendung der Kryptographie ziehen kann. Der Wikipedia-Artikel über Kerckhoffs Prinzip ist sehr gut und ein ausgezeichneter Ausgangspunkt.

Hier einige Punkte zum Nachdenken:

  • As In dem Wikipedia-Artikel heißt es: "Je weniger und einfacher die Geheimnisse sind, die zur Gewährleistung der Systemsicherheit aufbewahrt werden müssen, desto einfacher ist die Aufrechterhaltung der Systemsicherheit." Wenn alle anderen Dinge gleich sind, ist es möglicherweise einfacher, das System zu sichern, je weniger Dinge wir geheim halten müssen.

  • Im Allgemeinen gibt es wenig Hoffnung, das System zu bewahren Design oder Algorithmen, die im Systemgeheimnis von dedizierten Angreifern verwendet werden. Daher ist jedes System, dessen Sicherheit von der Geheimhaltung seines Entwurfs abhängt, auf lange Sicht zum Scheitern verurteilt - und auf kurze Sicht geht es ein unnötiges Risiko ein.

  • Das schlimmste Geheimnis kann nicht geändert werden, wenn es kompromittiert oder an Unbefugte weitergegeben wird. Das beste Geheimnis ist eines, das leicht geändert werden kann, wenn der Verdacht besteht, dass es durchgesickert ist. Der Aufbau eines Systems, bei dem die Sicherheit darauf beruht, dass das Design des Systems geheim gehalten wird, ist eine der schlechtesten Verwendungsmöglichkeiten der Geheimhaltung, da es nach der Bereitstellung des Systems sehr schwierig ist, Änderungen vorzunehmen, wenn das Geheimnis des Systems leckt (Sie müssen alle bereitgestellten Kopien des Systems ersetzen) System mit einer völlig neuen Implementierung, die normalerweise extrem teuer ist). Es ist besser, ein System aufzubauen, bei dem die Sicherheit darauf beruht, dass jeder Benutzer eine zufällige Passphrase auswählt, denn wenn das Kennwort durchgesickert ist (z. B. wenn der Benutzer sein Kennwort in eine Phishing-Site eingibt und dann "Ups!" Sagt), ist es relativ einfach zu ändern das Passwort des Benutzers, ohne andere zu belästigen.

  • Oder, wie Kerckhoff im 19. Jahrhundert schrieb, muss das Design eines Kryptosystems nicht geheim sein und es kann fallen ohne Unannehmlichkeiten in die Hände des Feindes. Dies ist im Grunde eine Wiederholung meines vorherigen Punktes in einem bestimmten Bereich.

Aus diesen Gründen versuchen gut konzipierte Systeme im Allgemeinen, das Ausmaß zu minimieren, in dem sie sich auf Geheimnisse stützen ;; und wenn Geheimnisse notwendig sind, entwirft man sie normalerweise, um die gesamte erforderliche Geheimhaltung auf einen kryptografischen Schlüssel oder eine Passphrase zu konzentrieren, die bei Kompromittierung leicht geändert werden kann.

Aber wie @Rory auch feststellte, ist Dunkelheit nicht unbedingt eine * schlechte * Sache für sich - es ist nur schlecht, wenn Sie sich zu Ihrer Sicherheit * darauf * verlassen. ** Wenn ** Ihr System ordnungsgemäß gesichert ist, ** gibt es ** Situationen (wie die ursprüngliche Frage), in denen es * nur ein bisschen mehr * helfen kann. Natürlich sollten Sie sich nicht darauf verlassen - und wir müssten vorsichtig sein, um ein falsches Sicherheitsgefühl zu vermeiden -, aber Dunkelheit * hat * einen gewissen Wert - betrachten Sie es als ein Element zur Minimierung der Angriffsfläche (oder einer Form davon). "Erst sicher machen - dann dunkel machen". (Ich werde diese Linie übernehmen ...)
@AviD, Ich verstehe Ihren Kommentar nicht. Warum hast du es als Antwort auf meine Antwort gepostet? Ich stimme mit allem überein, was Sie geschrieben haben, und ich denke, meine Antwort stimmt völlig mit dem überein, was Sie geschrieben haben (ich sehe nichts, was Sie geschrieben haben, was dem widerspricht, was ich geschrieben habe). Wenn Sie meine Antwort kritisieren wollten, verstehe ich nicht, was Sie konkret kritisieren.
Nun, nein, widerspricht nicht direkt etwas Bestimmtem. Ich ging davon aus, dass Sie, als Sie Kerckhoffs Prinzip zu einer Frage zitierten, "wann * Dunkelheit angemessen ist", sagten, dass Sie als Sicherheitskontrolle * überhaupt * keine Dunkelheit haben sollten. Vielleicht habe ich gerade zwischen den Zeilen gelesen ... Entschuldigung, wenn ich dich falsch verstanden habe :)
@AviD, guter Punkt. Nein, das wollte ich nicht implizieren - meine Schuld, dass ich nicht klarer geschrieben habe! Hier war der Punkt, den ich implizit anstrebte: Um zu verstehen, wann Sicherheit durch Dunkelheit angemessen ist / nicht angemessen ist, müssen Sie zuerst die Gründe verstehen, warum sie potenziell gefährlich ist und unter welchen Umständen sie gefährlich ist. In jeder konkreten Situation können Sie dann prüfen, ob diese Gründe für Ihre spezifische Situation zutreffen, und anhand dieser Gründe entscheiden, ob Sicherheit durch Dunkelheit einen Wert hat. Aber ich hätte das deutlicher machen sollen. Das tut mir leid.
Ah, jetzt kann ich dem zustimmen. Obwohl ich denke, dass das für typische Programmierer ein bisschen zu ... "schwer" sein könnte, als Leitprinzip zu haben. Obwohl ich theoretisch zustimme und für Sicherheitsprofis hilfreich sein kann, denke ich, dass die Erklärung von @Rory's (die im Grunde genommen auf dasselbe hinausläuft) für Nicht-Sicherheitsprofis "einfacher" ist ...
#3
+5
Bradley Kreider
2012-04-27 20:32:20 UTC
view on stackexchange narkive permalink

Sicherheit durch Dunkelheit ist der schlechte Teil. Dunkelheit kann die Sicherheit erhöhen, aber Sie können sich nicht allein auf Dunkelheit verlassen, um Sicherheit zu bieten.

Absolute Mantras sind immer schädlich. ;) Es ist wichtig, die Gründe für das Mantra und die damit verbundenen Kompromisse zu verstehen.

Zum Beispiel ist das Verstecken eines Schlüssels außerhalb Ihres Hauses, wenn Sie einen Lauf machen, Sicherheit durch Dunkelheit, aber es kann ein akzeptables Risiko sein, wenn Sie in 30 Minuten zurück sind (und nicht) ein Ziel mit hohem Risiko?).

Dasselbe gilt für "benutze niemals goto". Manchmal ist goto in bestimmten Situationen der beste Weg, um klaren Code zu schreiben. Als erfahrener Fachmann müssen Sie die Gründe für die Richtlinien verstehen, damit Sie die Kompromisse verstehen können.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 2.0-Lizenz, unter der er vertrieben wird.
Loading...