1 Sicherheit ist ein Zustand.

1.1 Er sieht eine wohldefinierte Anzahl an erlaubten Handlungen vor.

1.1.1 Eine Handlung ist eine ausgeführte Tätigkeit.

1.1.2 Eine Handlung kann sowohl aktiv (aktionär) als auch passiv (reaktionär) erfolgen.

1.1.3 Eine aktive (aktionäre) Handlung ist eine freiwillige Aktion ohne vorausgehenden Reiz.

1.1.3.1 Nur Menschen können freiwillige Aktionen durchführen. (Vielleicht noch nicht mal diese.)

1.1.3.2 Provozierte Reaktionen sind hingegen vorzugsweise durch Computer, Maschinen und Roboter gegeben.

1.1.4 Eine passive (reaktionäre) Handlung ist eine provozierte und unausweichliche Reaktion auf einen vorangegangenen Reiz.

1.1.4.1 Der vorangegangene Reiz kann entweder selber eine aktive oder eine passive Handlung gewesen sein.

1.1.4.2 Ein Reiz lässt sich im Computerbereich am ehesten als Eingabe oder Anfrage (z.B. HTTP Request) beschreiben.

1.1.4.2.1 Eine Eingabe (Reiz) führt zu einer Datenverarbeitung (Reaktion).

1.1.4.2.2 Oft wird eine Ausgabe als die eigentliche Reaktion verstanden. In der Regel liegt dabei jedoch eine transparente Verarbeitung dazwischen (Datenannahme und Berechnungen). In der Psychologie wird dies als S-O-R-Paradigma bezeichnet (Robert S. Woodworth, 1929).

1.1.4.2.3 Auf die HTTP-Anfrage "GET / HTTP/1.0\n\n" wird die Rückgabe für die entsprechende Ressource / generiert.

1.1.4.3 Ein Reiz, der eine Antwort generiert, die wiederum ein Reiz ist, der die gleiche Antwort generiert, wird als Loop bezeichnet.

1.1.4.3.1 Durch Loops lassen sich Ressourcen belegen und damit eine Denial of Service-Attacke (Ping-Pong) umsetzen.

1.1.4.3.2 Populär sind Routing-Loops, bei denen Pakete im Kreis weitergeleitet werden und deshalb nie die eigentliche Destination erreichen können.

1.1.4.3.3 Loops, bei denen schlussendlich eine Blockierung des Systems stattfindet, sind eine spezielle Form von Race Conditions. Sie werden Deadlocks oder Livelocks genannt.

1.1.4.3.4 Bei intelligenten Systemen werden Mechanismen eingesetzt, die Loops und Deadlocks erkennen und auf sie reagieren können.

1.2 Die produktive Sicherheit eines Systems (im Betrieb) wird in erster Linie an der Unterbindung unerwünschter Handlungen gemessen.

1.2.1 Eine Möglichkeit ist der Spielraum einer Handlung.

1.2.2 Das Ausbleiben jeglicher Möglichkeiten lässt absolute Sicherheit erlangen.

1.2.2.1 Ein System ohne Möglichkeiten erfüllt jedoch keinen Nutzen.

1.2.2.2 Ein produktives System muss mindestens eine Möglichkeit bereitstellen, um einen Nutzen gewähren zu können.

1.2.2.3 Viele Systeme bieten eine Vielzahl an Möglichkeiten.

1.2.2.4 Die Qualität und der Nutzen eines Produkts wird oftmals gar an seinen Möglichkeiten gemessen.

1.2.3 Sind alle unerwünschten Handlungen unterbunden, kann mit grösstmöglicher Wahrscheinlichkeit von einem sicheren Produkt ausgegangen werden.

1.2.3.1 Werden ausschliesslich gewünschte Handlungen und Zugriffe gewährleistet, spricht man vom "need to know" Prinzip.

1.2.3.2 Spätestens das Erlangen einer unerwarteten und unvorhergesehenen Möglichkeit mündet also in reaktionärer (nach Reiz) oder aktionärer (ohne Reiz) Unsicherheit.

1.2.4 Auch eine ursprünglich vorgesehene Möglichkeit kann eine Unsicherheit darstellen.

1.2.4.1 Nur weil eine Möglichkeit vorgesehen ist, heisst es nicht, dass sie sich bei näherer Betrachtung nicht doch als unsicher herausstellt.

1.2.4.1.1 Bei der Entwicklung eines Systems könnte eine umfassende Fehlermeldung als unkritisch vorgesehen werden.

1.2.4.1.2 Im Rahmen eines Angriffsversuch könnte sich eine akzeptierte Nichtigkeit als wichtiges Element zur Beweisbarkeit oder Ausnutzung der Unsicherheit herausstellen.

1.2.4.1.3 Der gewollte Handlungspielraum erfüllt sich damit mit einer indirekten Unsicherheit.

1.2.4.2 Die gegebene Unsicherheit einer vorgesehenen Möglichkeit hat sich schon bei ihrer Realisation manifestiert und war stetig präsent (im Hintergrund).

1.2.4.2.1 Eine Unsicherheit generiert sich also nicht erst dann, wenn sie als solche beobachtet werden kann.

1.2.4.2.2 Wird ein Produkt X im Januar 2000 veröffentlicht und im Januar 2005 eine Schwachstelle darin gefunden, so ist sie im Januar 2006 nicht ein Jahr alt sondern derer gar sechs.

2 Unsicherheit gewährt eine nicht zugelassene Handlung.

2.1 Unsicherheit sowie Sicherheit existieren auf theoretischer (ℑ) und auf praktischer (ℜ) Ebene.

2.1.1 Eine (praktische) Unsicherheit lässt sich stets theoretisch erfassen.

2.1.1.1 Theoretische Unsicherheit erfordert, dass in erster Linie ausserhalb der Praxis eine nicht zugelassene Handlung möglich ist.

2.1.1.2 Praktische Unsicherheit erfordert, dass auch in der Praxis die nicht zugelassene Handlung umgesetzt werden kann.

2.1.1.3 Praktische Unsicherheit lässt sich theoretisch erfassen. Theoretische Unsicherheit manifestiert sich hingegen nicht zwangsweise in der Praxis.

2.1.1.4 Nur die praktische Unsicherheit (theoretisch bewiesen oder praktisch ermittelt) gibt Aufschluss über die produktive Sicherheit des Systems.

2.1.1.4.1 Die produktive Unsicherheit eines Systems wird ihm frühstmöglich bei der Umsetzung/Aktivierung dessen anhaften.

2.1.1.4.2 Die produktive Unsicherheit verschwindet gänzlich spätestens dann, wenn das System komplett deaktiviert wird.

2.1.2 Der maximale Aufwand des Erkennens der Sicherheit eines Systems erfordert das Erkennen und Bewerten sämtlicher möglichen Zustände dessen.

2.1.2.1 Der Aufwand einer solchen Erfassung ist immer grösser als Null, da es mindestens immer einen Zustand (die Existenz als solche) gibt.

2.1.2.1.1 Ein System bestehend aus einem Bit, welches zwei Zustände 0 und 1 annehmen kann, muss für diese beiden Zustände [1]b = {0, 1} geprüft werden.

2.1.2.1.2 Ein System mit zwei Bit weist schon 4=2^2 Zustände der Form [2]b = {00, 01, 10, 11} auf. Bei drei Bit sind es 8=2^3, usf.

2.1.2.1.3 Der Aufwand der Prüfung eines Systems mit gleichem poliadischem Zahlensystem steigt mit der Zunahme jeder Zustandsstelle exponentiell an. Ein System mit n Bit kennt 2^n Zustände.

2.1.2.4 Je komplexer ein System ist, desto mehr Zustände lässt es zu.

2.1.2.4.1 Es sei davon auszugehen, dass unser Universum endlich ist.

2.1.2.4.2 Die Endlichkeit des Universums sieht vor, dass es ebenso eine endliche Anzahl an Zuständen in diesem gibt.

2.1.2.4.3 Da wir sowie die zu prüfenden Systeme ein Teil dieses endlichen Universums sind, kennen also auch wir lediglich eine endliche Anzahl an Zuständen.

2.1.2.4.4 Ein Computersystem kann aufgrund der Endlichkeit unseres Universums niemals eine unendliche Anzahl an Zuständen und damit eine unendliche Komplexität der Form x^∞ (infinity) aufweisen.

2.1.2.4.5 Die Prüfung eines Systems ist aufgrund seiner Endlichkeit ebenso mit endlichen Aufwänden durchführbar.

2.1.2.5 Je mehr Zustände ein System zulässt, desto aufwendiger wird die Prüfung eben dieses.

2.1.2.5.1 Auch der einzelne Zustand kann unterschiedliche Komplexitäten mitbringen. Der Zustand 0 ist weniger schwierig zu überblicken weder der Zustand 010011.

2.1.2.5.3 Es ist anzunehmen, dass die beiden Zustände 010011 und 001010 in Bezug auf ihre eigene Komplexität gleichwertig sind.

2.1.2.6 Das Durchführen einer absoluten Prüfung aller möglicher Zustände ist bei heutigen Computersystemen aufgrund der vielfältigen und umfassenden Ressourcen (CPU, Festplatte, RAM, ...) wohl nie wirtschaftlich rechtfertigbar.

2.1.2.6.1 Aus diesem Grund wird gerne davon gesprochen, dass es nie 100 %ige Sicherheit gibt.

2.1.2.6.2 Richtig muss es aufgrund dessen heissen, "dass sich 100 %ige Sicherheit in der Praxis in der Regel wirtschaftlich nicht beweisen (oder erreichen) lässt".

2.1.2.6.3 Statistisch gesehen vermag es durchaus in der absoluten Mehrheit der Fälle (~99,9 %) gegeben sein, dass Sicherheit weder vorhanden noch beweisbar ist.

2.2 Eine Gefahr generiert sich dadurch, dass die gegebene Unsicherheit auch ausgenutzt werden wird. Dies wird als Risiko bezeichnet.

2.2.1 Das Ausnutzen einer Unsicherheit kann verschiedene Motive haben.

2.2.1.1 Es wird in der Gegenwart und Zukunft immer jemanden geben, der mit einem entsprechenden Motiv daherkommen wird.

2.2.1.1 In populistischen Diskussionen wird fälschlicherweise gerne angenommen, dass Geldgier das zentrale Motiv der meisten Übergriffe darstellt.

2.2.1.2 Spieltrieb und Neugierde sind wohl die wichtigsten Motive vieler Errungenschaften, auch im Bereich der Computersichersicherheit.

2.2.1.3 Es zeichnet sich der Trend ab, dass die meisten effektiv ausgenutzten Unsicherheiten aus Gründen des Gelds angegangen werden.

2.2.2 Je einfacher ein Handlungsspielraum ist, desto eher werden sich Leute in diesem bewegen wollen.

2.2.2.1 Deshalb werden statistisch und längerfristig auch mehr in diesem agieren.

2.2.2.2 Die Einfachheit einer Umgebung führt zu mehr Akzeptanz. Die Popularität vieler Produkte ist auf ihre Einfachheit zurückzuführen.

2.2.2.2.1 Neben Funktionalität ist Ergonomie längerfristig die treibende Kraft für den Verkauf von Produkten.

2.2.2.2.2 Microsoft konnte ihre Windows-Plattform mitunter wegen der damals herausragenden Einfachheit der Bedienung etablieren.

2.2.2.2.3 Apple konnte ihre Produkte (z.B. iPod und iPhone) als Stilmittel etablieren und damit eine ungeahnte Akzeptanz für sich gewinnen.

2.2.2.3 Mit einem Mehr an Akzeptanz für eine Umgebung wird automatisch ein Mehr an potentiellen Angreifern erschlossen. Wer in einer Umgebung agieren kann, ist ein potentieller Angreifer.

2.2.2.3.1 Unpopuläre Betriebssysteme und Applikationen sehen sich mit einer geringen Anzahl an interessierten Angreifern konfrontiert.

2.2.2.3.2 Nur weil für ein Produkt wenige Schwachstellen publiziert wurden, heisst dies nicht, dass es auch wenige Schwachstellen in diesem gibt. Ebenso könnte es sein, dass sich halt nur wenige auf die Suche nach diesen gemacht haben.

2.2.3 Je wertvoller die erreichbaren Möglichkeiten sind, desto eher werden sich die Leute diesen nähern wollen.

2.2.3.1 Der Wert einer Möglichkeit ist nur bedingt objektiv.

2.2.3.1.1 Die Existenz ihrer wird sich noch am ehesten objektiv mit dem dualen Zustand {gegeben, nicht gegeben} bestimmen lassen.

2.2.3.1.2 Spätestens bei der Quantisierung wird es schwierig, einen Konsens zu finden.

2.2.3.2 Wohl in den meisten Fällen ist der absolute Wert vollumfänglich subjektiv definiert.

2.2.3.2.1 Eine Information A kann für eine Person X sehr wertvoll sein. Für Person Y ist sie es hingegen nicht.

2.2.3.2.2 Das Stehlen von Ressourcen (z.B. CPU-Leistung) kann für einen Schüler sehr wertvoll sein. Für einen Mathematiker mit freiem Zugang ins akademische Rechenzentrum jedoch eher weniger.

2.2.3.2.3 Die Möglichkeit des Abbuchens von sFr. 10'000.- kann für Person Y sehr viel sein. Für Person X jedoch nicht (da sie sowieso mehr Geld besitzt oder sich weniger für dieses begeistern kann).

2.2.4 Das potentielle Risiko orientiert sich an der Qualität und Quantität der drohenden Gefahr.

2.2.4.1 Die Qualität der Gefahr ist durch ihre Mächtigkeit definiert. Diese ist aus den verfügbaren Ressourcen (Zeit und Wissen) beschaffen.

2.2.4.1.1 Zeit ohne Wissen ist genauso unbrauchbar wie Wissen ohne Zeit.

2.2.4.1.2 Wissen und Zeit kann man sich in beschränktem Masse "erkaufen". Es wird sich meistens jemanden finden lassen, der etwas kann sowie machen will und auch die Zeit dafür hat.

2.2.4.2 Die Quantität der Gefahr ist durch die Anzahl potentieller Angreifer definiert.

2.2.4.2.1 Ein jeder Mensch gilt im weitesten Sinn theoretisch als potentieller Angreifer.

2.2.4.2.2 Die Anzahl der effektiven potentiellen Angreifer kann nie die Anzahl der existierenden Nutzer (potentiell agierende Entitäten eines Systems) übersteigen.

2.2.4.2.3 Die Anzahl der effektiven Angreifer kann nicht ermittelt werden, bevor sie nicht einen Angriffsversuch unternommen haben.

3.1.1 Ein Angriffsversuch erfordert die Möglichkeit mindestens einer Handlung.

3.1.2 Ein Angriffsversuch, der mit ausschliesslich einer Handlung initiiert wird, wird als One-Shot bezeichnet.

3.1.2.1 Ein misslungener One-Shot Angriff sagt lediglich etwas über die Sicherheit bezüglich des spezifischen Angriffsversuchs aus.

3.1.3.1 Mittels Iteration wird zum perfekten Angriff konvergiert.

3.1.3.2 Es gibt immer mindestens einen perfekten Angriff.

3.1.3.2.1 Ein Angriff ist dann perfekt, wenn er ausschliesslich und unmittelbar das ihm vorgegebene Ziel erreicht.

3.1.3.2.2 Zwei Angriffsvarianten zur Ausnutzung einer Schwachstelle können bezüglich ihres Perfektionismus gleichwertig sein.

3.1.3.3.1 Für die Erkennung von Angriffsversuchen ist traditionell ein Intrusion Detection-System (IDS) zuständig.

3.1.3.3.3 Ein Intrusion Prevention-System kann entweder durch Unterbinden von Kommunikationsübertragungen oder Unterbinden von Kommunikationsmöglichkeiten funktionieren.

3.2 Ein erfolgreicher Angriff erfordert die Möglichkeit einer erfolgreichen Handlung ausserhalb des vorgesehenen Handlungsspielraums.

3.2.1 Er beweist die praktische Unsicherheit des Systems im gegenwärtigen Zustand.

3.2.2 Ist nach dem Durchspielen aller erdenklichen Angriffsversuche kein erfolgreicher Angriff erreicht, kann das System punktuell (bezüglich der Angriffstechnik und des Angriffszeitpunkts) als sicher eingestuft werden.

3.3 Ein erfolgreicher Angriff kann zu einem späteren Zeitpunkt in gleicher Weise wiederholt werden. In manchen Fällen ist dies aber nicht möglich.

3.3.1 Nur weil sich ein Angriff zu einem späteren Zeitpunkt nicht mehr wiederholen lässt, heisst dies nicht, dass eben diese Unsicherheit nicht bestand, nicht mehr besteht oder nicht mehr bestehen wird.

3.3.1.1 Sicherheit ist und bleibt ein Zustand, der sofort wieder verfallen kann.

3.3.1.1.1 Die Sicherheit verfällt unter Umständen dann, wenn sich etwas am System ändert.

3.3.1.1.2 Die Sicherheit kann aber auch erst dann verfallen, wenn mit dem System interagiert wird (Faktor Mensch).

3.3.1.2 Sicherheit muss als fortwährenden Prozess verstanden werden.

3.3.1.2.1 Dieser erdachte Prozess versucht einzelne Zustände der erreichten Sicherheit aneinanderzureihen.

3.3.1.2.2 Dadurch wird der Schein der stetigen Sicherheit erschaffen und gewahrt.

3.3.2 Eine geringe Änderung im System kann dazu führen, dass ein Angriff nicht mehr erfolgreich sein kann.

3.3.2.1 Zur Erhöhung der Sicherheit müssen Massnahmen ergriffen werden, die den Handlungsspielraum derartig anpassen, dass kein erfolgreicher Angriff mehr erfolgen kann. Ist eine Massnahme erfolgreich, wird sie als Gegenmassnahme (Gegen die Unsicherheit) bezeichnet.

3.3.2.1.1 Eine Massnahme kann auf unterschiedlichen Ebenen angesetzt werden.

3.3.2.1.3 Eine effektive Massnahme bringt lediglich solche Änderungen ein, die die Möglichkeiten des Angriffs verändern. Nicht jedoch die Möglichkeiten der erlaubten Handlungen.

3.3.2.1.4 Das Erhöhen der Kompliziertheit bzw. Komplexität eines Systems kann als Massnahme verstanden werden.

3.3.2.2 Es gibt Situationen, in denen soll oder kann die Sicherheit durch Massnahmen nicht erhöht werden.

3.3.2.2.1 Eine exakte Risikokalkulation hilft zu erkennen, ob und inwiefern das Akzeptieren eines Risikos die richtige Entscheidung ist.

3.3.2.2.1 Eine umfassende Gegenmassnahme adressiert ebenfalls die Varianten eines Angriffs.

3.3.2.2.2 Handelt es sich um die richtige Entscheidung auf eine technische Massnahme zu verzichten, wird das Risiko als gegeben akzeptiert.

4 Unsicherheiten und Angriffe sind unter sich nicht gleichwertig.

4.1 Die Qualität einer Unsicherheit ist von der erforderlichen Effizienz und Eleganz, die für einen erfolgreichen Angriff unabdingbar ist, abhängig.

4.1.1 Die Qualität einer Unsicherheit hat in einem gewissen Rahmen Einfluss auf die Qualität eines Angriffs.

4.1.2 Die Qualität einer Unsicherheit ist umso grösser, je mehr Handlungspielraum sie ungewollt zur Verfügung stellen kann.

4.1.3 Die Einstufung einer Unsicherheit muss objektiv erfolgen.

4.1.3.1 Leider ist das Erstellen eines metrischen Systems in höchstem Mass einer Subjektivität unterworfen.

4.1.3.1.1 Es gibt verschiedene metrische Systeme zur Bewertung von Unsicherheiten.

4.1.3.1.2 Ein Metrisches System kann eine Skala von 1 bis 100 aufweisen. Alternativ kann es vier Abstufungen Low (L), Medium (M), High (H) und Emergency (E) haben.

4.1.3.1.3 Je mehr Stufen eine Skala zulässt, desto genauer lassen sich Fehler klassifizieren.

4.1.3.1.4 Je genauer sich ein Fehler klassifizieren lässt, desto schwieriger und aufwendiger wird dieser Prozess.

4.1.3.2 Eine Unsicherheit kann in den Phasen der Risikoanalyse und Risikobewertung nach verschiedenen Gesichtspunkten klassifiziert werden.

4.1.3.2.1 Typischerweise wird das Risiko (risk) einer Unsicherheit eruiert.

4.1.3.2.2 Alternativ wird der Schweregrad (severity) einer Unsicherheit eruiert.

4.1.3.2.3 Granulare Bewertungen berücksichtigen Eigenschaften wie Eintrittswahrscheinlichkeit (frequency), Schadensauswirkung (impact), Einfachheit (simplicity) und Popularität (popularity) einer Unsicherheit.

4.1.4 Eine Unsicherheit A kann als Grundlage für eine Unsicherheit B dienen.

4.1.4.1 Die Grundlage A kann dabei eine niedrige oder gleichwertige Einstufung wie die weiterführende Unsicherheit B haben.

4.1.4.1.1 Beispiel für eine niedrige Voraussetzung und eine mittlere Konsequenz: (1) Ein System ist über das Internet erreichbar. (2) Das Betriebssystem kann mittels TCP/IP-Fingerprinting identifiziert werden.

4.1.4.1.2 Beispiel für eine mittlere Voraussetzung und eine mittlere Konsequenz: (1) Ein Dienst wird mit dem Klartextprotokoll HTTP bereitgestellt. (2) Über diesen Dienst werden kundenspezifische Daten übertragen.

4.1.4.2 Es ist jedoch nicht möglich, dass eine Grundlage A höher eingestuft wird, weder die weiterführende Unsicherheit B.

4.1.4.3 Ebenso ist es nicht möglich, dass in symmetrischer und zeitgleicher Weise sowohl die Unsicherheit A die Grundlage für Unsicherheit B als auch die Unsicherheit B die Grundlage für Unsicherheit A ist.

4.2 Die Qualität eines Angriffs kann, unabhängig vom charakteristischen Erfolg dessen, unterschiedlich ausfallen.

4.2.1 Ein Angriff gilt als effizient, wenn er mit einem Minimum an Bewegung im auferlegten Handlungsspielraum durchgeführt werden kann.

4.2.2 Ein Angriff gilt als elegant, wenn er den auferlegten Handlungspielraum in unerwarteter und kreativer Weise nutzt.

4.2.2.1 Die Definition von Kreativität ist vom gegebenen Handlungsspielraum abhängig.

4.2.2.2 Je grösser der Handlungsspielraum ist, desto mehr Möglichkeiten gibt es für Komplexität, nicht jedoch automatisch ebenso für Kreativität.

4.2.2.3 Kreativität ist verbrauchbar. Ein erfolgreicher und bekannter Angriff mit einem gewissen Mass an Kreativität verliert mit zunehmender Durchführung eben diese.

4.2.2.3.1 Ein erstmalig ausgeführter Angriff wird als 0-Day (Zero-Day) bezeichnet.

4.2.2.3.2 Ein Angriff in seiner gegebenen Form kann keine Kreativität gewinnen [+], sondern diese nur erstellen [*] oder wahren [=].

4.2.2.3.3 Erst Varianten und Weiterführungen können weitere Kreativität wieder bzw. weiter aufbauen [+].

4.2.2.4 Ein fortwährend erfolgreich durchführbarer Angriff hat in seiner Rohform keine Kreativität mehr.

4.2.2.4.1 Subkulturell gesehen werden Angriffe ohne Kreativität nicht mehr als "Hack" verstanden.

4.2.2.4.2 Angriffe ohne Kreativität werden vorzugsweise durch Skriptkiddies durchgeführt.

4.2.2.4.3 Die Möglichkeit der fortwährenden Ausführbarkeit eines Angriffs bildet die Grundlage für das systematische Automatisieren dessen.

4.2.3 Ein Angriff gilt als einfach, wenn für die erfolgreiche Durchführung ein Minimum an Effizienz und Eleganz erforderlich ist.

4.2.3.1 Eine grosse Unsicherheit erfordert lediglich einen kleinen Angriff.

4.2.3.2 Die kleinste Unsicherheit erfordert hingegen den effektivsten Angriff.

4.2.4 Das Messen der Qualität eines Angriffs an der Qualität des Angreifers ist subjektiv und damit minderwertig.

4.2.4.1 Es lassen sich vier unterschiedliche Angreifertypen definieren.

4.2.4.1.1 Der Angreifertyp mit dem niedrigsten technischen Verständnis ist der normale Endanwender (User).

4.2.4.1.2 Interessiert sich ein Endanwender ein bisschen für Sicherheit und versucht er mit Tools und Exploits zu hantieren, spricht man von einem Skriptkiddie (SK). (Eric S. Raymond, The New Hacker's Dictionary. 1996, ISBN 0-262-68092-0)

4.2.4.1.3 Das intensive Auseinandersetzen mit einem spezifischen Fachgebiet führt zu einem semi-professionellen Fachspezialisten.

4.2.4.1.4 Das grösste technische Verständnis erlangen professionelle Angreifer.

4.2.4.2 Ein kleiner Angriff eines professionellen Angreifers kann nämlich ein grosser Angriff eines unbedarften Skriptkiddies darstellen.

4.2.4.3 Die Vergleichbarkeit der Qualität von Angriffen auf einzelne Unsicherheiten erfordert eine objektive Messung in Relation zur tangierten Unsicherheit als solche.

5 Eine Programmcode mit unerwünschten Nebeneffekten gilt als korrupter Programmcode.

5.1 Ein korrupter Programmcode ist nur dann korrupt, wenn er unerwünscht ist. Jeglicher andere Code ist bis zu dieser Definition entweder legitim oder unnötig.

5.1.1 Programmcode ist dann legitim, wenn er eine Arbeit ausführt, die ausgeführt werden will und soll.

5.1.2 Programmcode ist dann unnötig, wenn er Arbeit ausführt, die nicht ausgeführt werden muss oder müsste.

5.1.2.1 Unnötiger Programmcode ist für die Ineffizienz von Anwendungen und Computersystemen verantwortlich.

5.1.2.2 Ein Computersystem ist umso ineffiizenter, desto mehr unnötiger Programmcode ausgeführt wird.

5.1.2.3 In gewissem Sinne ist also auch eine NOP-Anweisung ineffizient. Es sei denn, sie wird für eine höhere Aufgabe (z.B. Synchronisation von Threads) genutzt. Wie zum Beispiel ein Leerlaufprozess (Idle Task).

5.1.3 Um einen korrupten Programmcode als solchen erkennen zu können, muss man sich seiner Nützlichkeit/Erwünschtheit bewusst werden.

5.2 Es gibt verschiedene Arten korrupten Programmcodes.

5.2.1 Die populärste Form korrupten Programmcodes sind Computerviren.

5.2.1.1 Computerviren waren zu Zeiten des Computer-/Internet-Booms am meisten verbreitet, sind aufgrund dessen am meisten diskutiert und auch von der breiten Öffentlichkeit am ehesten verstanden.

5.2.1.2 Die kleinste Definition eines Computervirus lautet, dass es sich dabei um sich selber reproduzierenden Programmcode handelt.

5.2.1.2.1 Die offensichtlichste und einfachste Replikation liegt im Anlegen einer Kopie.

5.2.1.2.2 Ein Computervirus, der sich selbst in den Programmcode anderer Dateien kopiert und die Original-Datei damit (teilweise) überschreibt, wird als Overwriting-Virus bezeichnet.

5.2.1.2.3 Ein Computervirus, der sich selbst an den Programmcode einer bestehenden Datei anhängt, wird als Appending-Virus bezeichnet.

5.2.1.2.4 Ein Computervirus kann auch alternative Bereiche eines Computers als Brutstätte gebrauchen (z.B. RAM als TSR-Virus oder Bootsektor als Bootsektor-Virus).

5.2.1.3 Die Schadensroutine eines Computervirus ist optional und nicht als Kardinaleigenschaft eines solchen anzusehen.

5.2.1.3.1 Es gibt bewusste dedizierte Schadensroutinen, die Daten manipulieren oder löschen können.

5.2.1.3.2 Je nach Definition und Umsetzung kann aber auch die Reproduktion des Virus selbst als Schadensroutine verstanden werden (Ressourcen verbrauchen: Speicherplatz und CPU-Zeit). Nach dieser Definition ist also jeder Computervirus schädlich.

5.2.1.3.3 Die Schadensroutine ist massgeblich für die Risikoeinstufung und Popularität vieler Viren verantwortlich.

5.2.2 Fast so populär wie Computerviren sind Trojanische Pferde.

5.2.2.1 Trojanische Pferde werden im Volksmund auch als Trojaner bezeichnet.

5.2.2.2 Trojanische Pferd gehören einer gänzlich anderen Familie korrupten Programmcodes an. Es ist nicht selbst um eine Reproduzierung von sich selbst bemüht.

5.2.2.3 Ein Trojanisches Pferd führt im Hintergrund ohne das Wissen oder Einwilligen des Anwenders Operationen durch.

5.2.2.3.1 Ein Trojanisches Pferd, welches Tastatureingaben aufzeichnet, wird als Keylogger bezeichnet.

5.2.2.3.2 Moderne Trojanische Pferde fungieren als Remote-Control-Utilities und erlauben damit die Fernsteuerung eines kompromittierten Systems (z.B. NetBus oder BackOrifice).

5.2.2.4 Ein Trojanisches Pferd kann aber auch zu rein zerstörerischen Zwecken eingesetzt werden.

5.2.2.4.1 In klassischer Hinsicht werden ANSI-Bomben erstellt, um bei einer speziellen Tastatureingabe eine destruktive Aktion durchzuführen (z.B. Löschen von Dateien).

5.2.2.4.2 Es gibt Remote-Control-Utilities, mit denen sich Distributed Denial of Service-Attacken orchestrieren lassen (z.B. TFN und Trin00).

5.2.3 Im weitesten Sinne lässt sich auch ein Exploit als korrupten Programmcode bezeichnen.

5.2.3.1 Ein Exploit ist eine Anleitung oder eine Software, die das Ausnutzen einer Schwachstelle erleichtert oder automatisiert.

5.2.3.1.1 Im weitesten Sinn ist also auch ein Advisory als Exploit (Anleitung) zu verstehen.

5.2.3.1.2 Exploits lassen sich sowohl für bösartige als auch für gutartige Zwecke einsetzen.

5.2.3.1.3 Exploits helfen dabei, Schwachstellen systematisch auszunutzen. Dadurch wird in Sicherheitsüberprüfungen effizient ihre Existenz bewiesen sowie ihre Tragweite determiniert.

5.2.3.1.4 Das pauschale Verbieten von Exploits verhindert, dass Penetration Tester effizient und zuverlässig Sicherheitslücken analysieren können.

5.2.3.2 Will ein Anwender einen Exploit nutzen, ist er für ihn selbst nicht als korrupter Programmcode zu verstehen. Jedoch gegenüber dem System, welches damit angegriffen wird.

5.3 Korrupter Programmcode lässt sich unter gewissen Umständen als solchen erkennen.

5.3.2 Viele Antiviren-Lösungen benutzen eine patternbasierte Methode, um typische Zeichen bekannter Schädlinge zu entdecken.

5.3.2.1 Dies setzt voraus, dass der Schädling und seine Struktur bekannt sind, analysiert und in der Pattern-Datenbank vermerkt wurden.

5.3.2.1.1 Ein Pattern kann also immer nur nach der Entwicklung eines korrupten Programmcodes erstellt werden.

5.3.2.1.2 Durch diese naturbedingte Latenz handelt es sich hier zwangsweise um ein reaktionäres Verfahren.

5.3.2.1.3 Das Umsetzen von präventiven Patterns ist zwar theoretisch möglich, in der Praxis jedoch nicht anwendbar, da man nicht im Vornherein wissen kann, welche Struktur neue Schädlinge aufweisen werden.

5.3.2.2 Starre Pattern-Mechanismen sehen sich ausser Stand, Varianten von korruptem Programmcode ebenfalls als solchen zu erkennen.

5.3.2.2.1 Hersteller von Antiviren-Lösungen pflegen Varianten von korruptem Programmcode mit Buchstaben-Codes zu nummerieren (z.B. W32.Troj.a, W32.Troj.b, ...).

5.3.2.2.2 Polymorpher Programmcode ist explizit darum bemüht, sein Auftreten (jedoch nicht zwingend auch sein Verhalten) bei unterschiedlichen Ausführungen zu ändern, um einem Pattern-Matching entgegenzuwirken.

5.3.3 Bei einer heuristischen Analyse wird das Verhalten einer Software auf potentiell schädliche Routinen hin geprüft (z.B. Funktion zum Löschen ganzer Datenträger).

5.3.3.1 Ein heuristisches Verfahren sieht sich in der Lage, die Latenz des patternbasierten Ansatzes wettzumachen, indem sich auch neue und unbekannte Schädlinge aufgrund ihres dubiosen Verhaltens identifizieren lassen.

5.3.3.2 Auch eine heuristische Analyse kann man kompromittieren, indem absichtlich scheinbar legitime Kommandoabfolgen programmiert werden.

5.3.3.2.1 Soll mittels Heuristik eine destruktive Routine zum Löschen ganzer Laufwerke der Form delvolume("C:\") entdeckt werden, kann mit mehrmaligem Aufrufen dedizierter Löschbefehle while(sleep 1); delfile(volume, directory, file); die Mächtigkeit der Schadensroutine verschleiert werden.

5.3.3.2.2 Durch das Überdecken von Verhaltensmustern können die wahren Absichten verschleiert werden. Das Löschen von Dateien kann zum Beispiel auffälliger sein weder das Überschreiben dieser. Letzteres ist nämlich das legitime Verhalten der meisten Applikationen.

5.3.3.3 Da bei einer heuristischen Analyse jeder Funktionsaufruf des Programms geprüft werden muss, hat dies entsprechend negative Auswirkungen auf Ressourcen und Performance des Systems.

5.3.4 Korrupter Programmcode lässt sich entfernen.

5.3.4.1 Um korrupten Programmcode entfernen zu können, muss dieser eindeutig als solcher identifiziert und vom legitimen Programmcode getrennt werden können.

5.3.4.1.1 Hat ein korrupter Programmcode legitimen Programmcode zerstört (z.B. gelöscht oder überschrieben), kann durch das Entfernen des korrupten Programmcodes nicht wieder automatisch eine saubere und voll funktionstüchtige Umgebung gewährleistet werden.

5.3.4.1.2 Bei bekannten Schädlingen, die Daten mutwillig zerstören, können gewisse Antiviren-Lösungen mit eigenen Patches aufwarten, um beschädigte Datenteile wieder herstellen zu können.

5.3.4.2 Nur weil ein korrupter Programmcode A als solcher identifiziert und entfernt wurde, muss das desinfizierte System nicht zwangsweise komplett gesäubert sein. Ein anderer korrupter Programmcode B könnte übersehen worden sein.

5.3.4.2.1 Ein kompromittiertes System kann nur mit absoluter Sicherheit gesäubert werden, wenn es komplett und unter strengster Beobachtung neu aufgesetzt wird.

6 Sensitive Daten müssen vor Manipulationen geschützt werden.

6.1 Eine unerwünschte Manipulation ist die unerlaubte Einsicht durch Dritte. Die Daten verlieren dadurch ihre Vertraulichkeit.

6.1.1 Das Mitlesen einer Kommunikation wird umgangssprachlich als Lauschangriff bezeichnet.

6.1.1.1 Als "Grosser Lauschangriff" werden Überwachungen staatlicher Dienste (Strafverfolgungsbehörden und Nachrichtendienste) bezeichnet.

6.1.1.1.1 Echelon ist der Name eines der bekanntesten Spionagenetzes der Welt.

6.1.1.1.2 Mit Onyx wird das Satellitenabhörsystem der Schweiz bezeichnet.

6.1.2 Um eine unerwünschte Einsicht zu verhindern, kann ein abgeschotteter (dedizierter) Kanal genutzt werden.

6.1.2.1 Ein Kanal gilt als abgeschottet, wenn er nicht durch andere Medien benutzt wird oder werden kann.

6.1.2.2 Mit einem VPN (Virtual Private Network) lässt sich auch über geteilte Leitungen (vorwiegend dem Internet) ein abgeschotteter Kanal realisieren.

6.1.3 Ist das Einsetzen eines dedizierten Kanals nicht möglich, muss eine Verschlüsselung ihre Anwendung finden.

6.1.3.1 Daten, die ohne Verschlüsselung übertragen werden, werden als Klartext (Cleartext oder Plaintext) bezeichnet.

6.1.3.2 Daten, die mit einer Verschlüsselung übertragen werden, werden als Geheimtext (Ciphertext) bezeichnet.

6.1.3.3 Eine symmetrische Verschlüsselung benutzt den gleichen Schlüssel K. Für die Verschlüsselung der Nachricht M wird die Funktion EK(M) = C verwendet. Die Entschlüsselung findet sodann mit der Funktion DK(C) = M statt.

6.1.3.3.1 Die Funktionen für die Verschlüsselung und die Entschlüsselung sind invers, weshalb DK(EK(M)) = M sowie EK(DK(C) = C gelten.

6.1.3.3.2 Da die Sicherheit einer symmetrischen Verschlüsselung auf der Geheimhaltung des Schlüssels basiert, wird sie auch als Private-Key Encryption bezeichnet.

6.1.3.3.3 Ist einem Angreifer der Schlüssel sowie die mit diesem verschlüsselten Geheimtexte bekannt, kann er sie nach Belieben wieder entschlüsseln.

6.1.3.3.4 Ist einem Angreifer der Schlüssel bekannt, kann er nach Belieben eigene Geheimtexte generieren (Forgery).

6.1.3.3.5 Lange Zeit wurde DES (Data Encryption Standard) als Standardverschlüsselung eingesetzt. Im Oktober 2000 wurde er jedoch vom NIST durch AES (Advanced Encryption Standard) abgelöst.

6.1.3.4 Eine asymmetrische Verschlüsselung benutzt für die Verschlüsselung und die Entschlüsselung zwei unterschiedliche Schlüssel.

6.1.3.4.1 Es wird ein sogenanntes Schlüsselpaar (Key Pair) mit den Schlüsseln K1 und K2 verwendet.

6.1.3.4.2 Mit dem eigenen geheimen Schlüssel K1 (Private Key) werden Daten durch EK1(M) = C verschlüsselt.

6.1.3.4.3 Mit dem öffentlichen Schlüssel einer anderen Person (Public Key) K2 werden die Daten durch DK2(M) = M wieder entschlüsselt. Damit gilt DK2(EK1(M)) = M.

6.1.3.4.4 Da eine asymmetrische Verschlüsselung die Weitergabe des öffentlichen Teils des Schlüsselpaars erfordert, wird sie auch als Public-Key Encryption bezeichnet.

6.1.3.4.5 Die grössten Nachteile asymmetrischer Verschlüsselungen sind die Performance sowie der Schlüsselaustausch.

6.1.3.4.6 Es gibt eine Reihe asymmetrischer Kryptosysteme.

6.1.3.5 Es gibt verschiedene Methoden, wie eine verschlüsselte Kommunikation angegriffen werden kann. Dies wird als Kryptoanalyse (cryptanalysis) bezeichnet.

6.1.3.5.1 Bevor eine verschlüsselte Nachricht angegriffen werden kann, muss man in den Besitz dieser kommen.

6.1.3.5.2 Man unterscheidet zwischen sechs Angriffsmethoden auf kryptgrafische Systeme.

6.1.3.5.3 Man unterscheidet zwischen vier unterschiedlichen Stufen der erfolgreichen Kryptoanalyse.

6.1.3.6 Durch Quantenkryptografie kann ein auf physikalischer Ebene abhörsicherer Kanal erreicht werden.

6.1.3.6.1 Das rein passive und damit unidentifizierbare Mithören des quantenkryptografisch geschützten Datenaustauschs ist aufgrund der heisenberg'schen Unschärferelation nicht möglich.

6.1.3.6.2 Die Quantenkryptografie ist aufgrund ihrer Komplexität und Instabilität in erster Linie nur für einen sicheren Schlüsselaustausch vorgesehen.

6.1.3.6.3 Das BB84-Protokoll ist in der Quantenkryptografie das wohl bekannteste Verfahren zur Schlüsselerzeugung (Charles H. Bennett, Gilles Brassard, 1984).

6.2 Eine weitere unerwünschte Manipulation ist die Veränderung. Die Daten verlieren dadurch ihre Integrität.

6.2.1 Typischerweise werden digitale Signaturen eingesetzt, um die Integrität (Fälschbarkeit) und Authentizität (Herkunft) von Daten verifizieren zu können.

6.2.1.1 Bei einer digitalen Signatur wird der private Schlüssel nicht direkt auf die Nachricht angewendet, sondern auf deren Hash-Wert, der mittels einer Hash-Funktion (wie z. B. SHA-1) aus der Nachricht berechnet wird.

6.2.1.2 Bei deterministischen digitalen Signaturverfahren ist die digitale Signatur durch die Nachricht und den Schlüssel eindeutig festgelegt.

6.2.1.3 Bei probabilistischen digitalen Signaturverfahren gehen Zufallswerte in die Signaturberechnung ein, so dass die digitale Signatur zu einer Nachricht und einem Schlüssel viele verschiedene Werte annehmen kann.

6.2.2 Es gibt auch hier verschiedene Verfahren zur Generierung elektronischer Signaturen.

6.2.2.1 Das mit Abstand und seit Jeher bekannteste Verfahren ist RSA, welches sich die Schwierigkeit der Faktorisierung grosser Primzahlen zunutze macht.

6.2.2.1.1 Es gibt verschiedene Arten, Primzahlen zu generieren.

6.2.2.1.2 Bei der Primfaktorzerlegung wird eine natürliche Zahl als Produkt von Primzahlen dargestellt (z.B. 30 = 2 × 3 × 5).

6.2.2.1.3 Es ist in der Regel viel einfacher eine Primzahl zu generieren, weder auf diese eine Primfaktorzerlegung anzuwenden.

6.2.2.2 Alternativ werden DSA, El-Gamal und Schnorr-Signaturen eingesetzt, die einen diskreten Logarithmus in endlichen Körpern anwenden.

6.2.2.3 ECDSA, ECGDSA oder Nyberg-Rueppel-Signaturen verwenden einen diskreten Logarithmus in elliptischen Kurven.

6.2.2.3.1 Systeme auf der Basis elliptischer Kurven (Elliptic Curve Cryptosystems, ECC) wurden immer populärer, da sie mit wesentlich kleineren Schlüssellängen auskommen.

6.2.3 Das Gewährleisten der Integrität kann ebenso durch eine Verschlüsselung realisiert werden.

6.2.3.1 Um die Daten bewusst zu verändern, müsste die Verschlüsselung dem Angreifer bekannt und durch ihn reproduzierbar sein.

6.3 Eine andere unerwünschte Manipulation ist das Verzögern oder Unterbinden des Datenflusses. Die Daten verlieren dadurch ihre Verfügbarkeit.

6.3.1 Eine destruktive Attacke auf einen Dienst wird als Denial of Service (DoS) bezeichnet.

6.3.1.1 Werden verschiedene Systeme eingespannt, um eine Denial of Service-Attacke durchzusetzen, spricht man von einer Distributed Denial of Service Attacke (DDoS).

6.3.1.1.1 Um orchestrierte DDoS-Attacken durchzuführen, wird ein Multi-Tier-Modell angestrebt.

6.3.1.1.2 DDoS-Attacken werden in der Regel von einem Management-System orchestriert.

6.3.1.1.3 In einem 3-Tier-Modell werden die Anweisungen des Management-Systems von einem Handler entgegengenommen und an die jeweiligen Agents verteilt. Der Handler agiert dabei quasi als intelligenter Proxy.

6.3.1.1.4 Das Durchführen der eigentlichen DoS-Attacke wird durch die unterschiedlichen Agents vorgenommen.

6.3.1.1.5 Zu den klassischen Implementierungen von DDoS-Lösungen gehören Trinoo, TFN (Tribe Flood Network) und Stacheldraht. Sie wurden teilweise seit Ende der 90er Jahren öffentlich gemacht, jedoch erst zu Beginn des neuen Jahrtausends breitflächig eingesetzt (CERT® Incident Note IN-99-04).

6.3.2 Die einfachste und direkteste Methode einen Dienst unbrauchbar zu machen, ist diesen zu überlasten.

6.3.2.1 Das Überlasten eines Dienstes mittels einer Vielzahl an (grossen) Anfragen wird als Flooding bezeichnet.

6.3.2.2 Das erfolgreiche Überlasten eines Dienstes erfordert, dass man mit den eigenen verfügbaren Ressourcen die bereitgestellten Ressourcen des Ziels aufbrauchen kann.

6.3.2.2.1 Davon ist grundsätzlich jegliche Ressource betroffen, die limitiert und und alloziiert werden kann.

6.3.2.2.2 Klassisches Beispiel aus dem Betriebssystem-/Netzwerkumfeld ist ein SYN-Flooding, bei dem die Backlog Queue für TCP-Verbindungen aufgebraucht wird. (W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols)

6.3.2.3 Da Überlastungsangriffe keine intelligente Interaktion mit einem Zielsystem erfordern, werden sie als besonders einfach und primitiv angesehen. (Marc Ruef, Die Kunst des Penetration Testing, 2007)

6.3.3 Schlecht umgesetzte oder gewartete Dienste lassen sich unter Umständen als Drittperson einfachso deaktivieren.

6.3.3.1 Im Rahmen von TCP/IP kann beispielsweise ein ARP-Segment mit falscher Adresse für ein Drittsystem verschickt werden, um die Netzwerkkommunikation abrupt abzubrechen. Dies funktioniert jedoch naturbedingt nur in lokalen Netzen (LAN).

6.3.3.2 ICMP-, TCP- und UDP-Kommunikationen lassen sich ebenfalls mit diversen ICMP-Fehlermeldungen (z.B. ICMP port unreachable) beenden.

6.3.3.2.1 Die meisten Verbindungen lassen sich mit spezifischen ICMP-Fehlermeldungen unterbrechen.

6.3.3.2.2 Eine etablierte TCP-Verbindung kann, sofern die TCP-Sequenznummern richtig erraten werden, mit einem TCP-Verbindungsabbau (RST oder FIN) beendet werden.

6.3.3.2.3 Eine UDP-Verbindung kann in vielen Fällen mit einem gefälschten Verbindungsabbau des Anwendungsprotokolls beendet werden.

6.3.3.3 Wird der Zugriff auf administrative Bereiche möglich (z.B. da eine Authentisierung fehlt), können die Deaktivierungen ganz normal umgesetzt werden.

6.3.3.3.1 Dienste/Systeme können heruntergefahren bzw. deaktiviert werden, um Nutzungsmöglichkeiten zu entziehen.

6.3.3.3.2 Zugriffsmöglichkeiten/-rechte können entzogen oder erweiterte Authentisierugen forciert werden, um Zugriffsmöglichkeiten zu entziehen.