Analogie

Dass IT-Sicherheit nicht wie Krieg ist, schrieb ich schon. Aber wie was ist sie dann? Ein Versuch:

IT-Sicherheit ist wie Deichbau. Baut oder erhöht man nur auf einer Seite des Gewässers, läuft das Wasser auf der anderen trotzdem über. Was man am Oberlauf erfolgreich eingedämmt hat, ist als Problem nicht einfach verschwunden, sondern es macht sich dann eben ein Stück den Fluss hinunter um so stärker bemerkbar. Wenn der Deich ein Loch hat, dann wird das Wasser dieses Loch finden und ausnutzen. Ob ein Deich Standards einhält, kümmert das Wasser nicht. Halten muss er, und formale Vorschriften sind höchstens ein Hilfsmittel, um das zu erreichen.

Passt das? Wenn nein, warum nicht?

Advertisements

2 thoughts on “Analogie

  1. Schwierig. Mal schauen:

    Das Wasser sieht man kommen, Angreifer nicht. Was heisst es, dass wir, sagen wir, 12 Monate keinen Einbruch hatten? Sind wir so sicher? Waren die die Einbrecher, die’s versucht haben, minderbemittelt? Oder sind wir kein lohnendes Ziel? Und werden wir das in 12 Monaten noch sein?

    Wasser ist berechenbar, simulierbar. Angreifer haben (i. d. R.) menschliche Intelligenz. Wasser kennt kein social engineering und macht keine Finten. Naja, nicht ganz – man kann Fuzzing als eine einfache Simulation der anstürmenden Horden interpretieren.

    Wasser trägt Material ab, mit immer gleichen Wellen. Menschen können ihr Angriffsmuster adaptieren und mit neuen Versuchen die gleiche Stelle attackieren. Menschen können Information hier gewinnen und dort einsetzen.

    Material altert, rostet, erodiert, langsam und kontinuierlich, und wir wissen recht gut, wie und wie schnell unter welchen Umständen. Software kann nicht altern, höchstens abstürzen (was die Sicherheit durchaus erhöht :). Andererseits taucht regelmässig neues Wissen über Sicherheitslöcher von Software auf, quasi schlagartig. Den Deich kann ich morgen ausbessern oder nächste Woche, und das wusste ich schon seit Monaten – eine einzige CERT-Meldung kann mich (verantwortlich wie ich ja bin) zwingen, den Laden dicht zu machen, bis ein funktionierender Patch da ist.

    Standards? Doch, brauchen wir. Dass wir aktuell keine (oder kaum welche) haben, die sinnvoll sind, ändert da nichts dran. Wir haben (zu wenig) Prinzipien (least priviledge, http://tinyurl.com/sqlinjectionfree, http://tinyurl.com/sanserrors und andere), und deren Einhaltung hilft. Die Einhaltung formaler Vorschriften kann man nie vollständig überprüfen, hier nicht und dort nicht, aber Prüfung muß sein. Ich würde sogar erwarten, daß man eine bestimmte Kategorie an Vorschriften mit Code-Analyse-Werkzeugen sehr gut – und vor allem zerstörungsfrei[*] prüfen kann.

    Also, nee, auch nicht. Gut, das mit dem Krieg war aber auch nicht gut, hatte aber immerhin böse, menschliche Feinde. Wasser passt noch schlechter, fürchte ich.

    [*] Abgesehen von dem Ego des einen oder anderen Entwicklers, natürlich.

  2. So, jetzt ist Zeit für eine Antwort. Ich versuche mal bewusst, eine Gegenposition einzunehmen. Mal sehen, was am Ende herauskommt.

    Das Wasser sieht man kommen, Angreifer nicht. Was heisst es, dass wir, sagen wir, 12 Monate keinen Einbruch hatten? Sind wir so sicher? Waren die die Einbrecher, die’s versucht haben, minderbemittelt? Oder sind wir kein lohnendes Ziel? Und werden wir das in 12 Monaten noch sein?

    Was heißt es, dass wir 12 Monate keine Überschwemmung hatten? Lag es an der Regenmenge, an ihrer Verteilung über die Zeit, am Management der Talsperren oder an guten Deichen? Da kann es durchaus Überraschungen geben, wie das Elbehochwasser 2002 gezeigt hat. Über lange Zeiträume kommt man durch Beobachtungen aber wohl zu einem guten Modell des möglichen Geschehens.

    Wasser ist berechenbar, simulierbar. Angreifer haben (i. d. R.) menschliche Intelligenz. Wasser kennt kein social engineering und macht keine Finten. Naja, nicht ganz – man kann Fuzzing als eine einfache Simulation der anstürmenden Horden interpretieren.

    Wasser sucht sich aber auch seinen Weg, und wenn ich die realen Schwachstellen nicht genau kenne, dann nützt mir die Simulation wenig. Bringt die Intelligenz des Angreifers wirklich mehr mit sich als nur die Fähigkeit, sich den Bedingungen anzupassen?

    Material altert, rostet, erodiert, langsam und kontinuierlich, und wir wissen recht gut, wie und wie schnell unter welchen Umständen. Software kann nicht altern, höchstens abstürzen (was die Sicherheit durchaus erhöht 🙂 .

    Software altert auch, oder besser gesagt Systeme, die aus Software bestehen. Ein seit Jahren genutztes System wird anders aussehen als ein frisch aufgesetztes, auch wenn beide denselben Versionsstand haben. Am gebrauchten System werden Administratoren und Nutzer immer mal wieder gefummelt habem, am neuen nicht. Wobei erst mal offen bleibt, welcher der Zustände sicherer ist und ob man das überhaupt allgemein sagen kann.

    Andererseits taucht regelmässig neues Wissen über Sicherheitslöcher von Software auf, quasi schlagartig. Den Deich kann ich morgen ausbessern oder nächste Woche, und das wusste ich schon seit Monaten – eine einzige CERT-Meldung kann mich (verantwortlich wie ich ja bin) zwingen, den Laden dicht zu machen, bis ein funktionierender Patch da ist.

    Vielleicht ist das auch nur eine Illusion, die vor allem darauf beruht, dass etwas tun sich meistens richtiger anfühlt als nichts zu tun. Wie lange ich ein Loch im Deich lassen kann, sagt mir letztlich eine Risikobewetung. Die Meteorologen können mir sagen, wie häufig welches Wetterereignis und welche Wetterlage vorkommt und wie lang die Vorwarnzeit normalerweise ist. Mit diesen Daten kann ich das Risiko einschätzen. Eigentlich gibt es keinen Grund, das in der IT-Sicherheit anders zu handhaben — nur fehlen uns die Daten.

    Gegen Standards sage ich nichts, sie haben Grenzen, sind aber wohl nützlich, solange man sich nicht allein auf Compliance verlässt.

Comments are closed.