Schlagwort-Archive: threat model

Attack Scenario ≠ Threat

Anforderungen – Requirements, Bedrohung, English, How to, Security, Video,

The below video gives an example of what some people would call a threat model. For all I can tell the video leaves out some detail but is otherwise accurate. Why does it appear hilarious or silly rather than reasonable?

As a joke the video exploits a mismatch between the sensible, even verifiable analysis it presents and the ridiculous assumptions it implies. If this attack scenario manifested itself it would play out pretty much as presented. However, the implied very narrow and specific mode of operation – firing cannon rounds at computers – does not correspond with the behavior of any reasonably imaginable threat agent. Any agent with the capability to deploy main battle tanks is facing a wide range of possible uses and targets. Shooting individual personal computers remains not only far from being one of the more profitable applications of this capability, but guarantees a negative return. The cost is high and destruction of specific, low-value items promises rather limited gains. There are also much cheaper methods to effect any desired condition on the specific type of target, including its complete destruction.

While the attack scenario is accurate, it lacks, therefore, a corresponding threat that would produce actual attacks. Such a threat would exist, for example, if the assumed target were other main battle tanks rather than personal computers.

Scheinriese Cross-Site-Scripting

Bedrohung, Risiko, Security, Vulnerability, , ,

Wer sich mit IT-Sicherheit beschäftigt, kennt Cross-Site-Scripting (XSS) und hält es wahrscheinlich für eine Klasse schwerwiegender Verwundbarkeiten. Das ist plausibel, aber vielleicht dennoch übertrieben.

Eine Webanwendung ist anfällig für Cross-Site-Scripting, wenn Angreifer ihr HTML- und JavaScript-Code unterjubeln können, welchen der Browser eines Nutzers nicht vom echten Code der Anwendung unterscheiden kann. Damit gewinnen Angreifer die Möglichkeit, im Sicherheitskontext fremder Benutzersitzungen zu agieren. So könnte ein Angreifer beispielsweise im Namen einen angemeldeten Benutzers Daten abrufen und ändern, aber auch im Kontext der Webanwendung mit dem Benutzer interagieren – ein Man-in-the-Middle-Angriff zwischen Benutzer und Anwendung.

Große Aufmerksamkeit wird dem Cross-Site-Scripting aus mehreren Gründen zuteil:

  1. Cross-Site-Scripting-Verwundbarkeiten kommen häufig vor. Wer interaktive Webanwendungen entwickelt und nicht von Anfang an stringente Maßnahmen dagegen ergreift, wird früher oder später unweigerlich XSS-Verwundbarkeiten in seine Anwendung haben.
  2. Cross-Site-Scripting ist leicht zu erklären und zu verstehen. Die einfachsten Varianten lassen sich mit rudimentären HTML- und JavaScript-Kenntnissen unter Verwendung eines gewöhnlichen Webbrowsers demonstrieren – die ideale Fallstudie für jede Sicherheitsschulung.
  3. Cross-Site-Scripting unterläuft mehrere Sicherheitmechanismen – zum Beispiel die Same-Origin-Policy und jede Benutzerauthentisierung – und gewährt dem erfolgreichen Angreifer volle Kontrolle über jede betroffene Benutzersitzung. Verwundbarkeiten sind daher für vielfältige Ziele ausnutzbar und die Auswirkungen lassen sich kaum wegdiskutieren.

Cross-Site-Scripting taucht deshalb zu Recht von Anfang an als eigene Kategorie in den OWASP-Top-10 („The Ten Most Critical Web Application Security Risks“) auf, obwohl es sich rein technisch eigentlich um eine Spezialfall der allgemeineren Kategorie „Injection“ handelt.

✽✽✽

In einem Artikel vom 25. Oktober berichtet Golem.de, man habe in mehreren Online-Shops – allesamt Träger des „Safer Shopping“-Siegels eines bekannten Plakettenkonzerns – Cross-Site-Scripting-Verwundbarkeiten gefunden. Nahezu dieselbe Geschichte war in anderer Besetzung, aber mit demselben Protagonisten bereits neun Jahre zuvor erschienen. Das nimmt nicht Wunder, denn die technische Sicherheit der Shopsoftware gehört gar nicht zum Prüfumfang des Safer-Shopping-Siegels.

Was dies über kommerzielle Gütesiegel aussagt, deren Verfechter sich gerade zu einem neuen Anlauf formieren, sei dahingestellt. Interessanter finde ich die darin verborgene Beobachtung, dass sich offenbar eine Dekade lang niemand ernsthaft an immer wieder auftretenden Cross-Site-Scripting-Verwundbarkeiten in deutschen Online-Shops stört.

Wo Verwundbarkeiten spürbare Auswirkungen haben, also tatsächlich ausgenutzt werden, tut man für gewöhnlich etwas dagegen oder macht öffentlich Radau, falls die Verantwortlichen andere sind als die Opfer. Wo man nichts sieht und hört, gibt es hingegen augenscheinlich kein wirkliches Problem. Gewiss, dies ist nur eine Heuristik, doch sie hat eine ökonomische Grundlage: Je höher die Schäden, desto größer der mögliche Nutzen von Sicherheitsmaßnahmen; je geringer die Schäden, desto weniger lohnt sich Sicherheit.

Dass eine „klaffende Sicherheitslücke“ (WichtigtuerExpertenjargon) dennoch nicht ausgenutzt wird, kommt häufiger vor als gedacht, denn für den Angreifer muss sich der gesamte Angriff lohnen und nicht nur im Prinzip möglich sein. Die Verfügbarkeit ausnutzbarer Verwundbarkeiten ist dabei nur ein Faktor unter mehreren. Auf den zweiten Blick zeigen sich einige Einschränkungen, die prinzipiell mögliche Cross-Site-Scripting-Angriffe auf die Nutzer von Online-Shops unattraktiv machen können.

Als Angriffsziele in einem Online-Shop kommen für ökonomisch motivierte Angreifer insbesondere das Auslösen von Transaktionen und damit Lieferungen sowie der Zugriff auf einsetzbare Zahlungsdaten (z.B. vollständige Kreditkartendatensätze) oder Kundenpasswörter in Frage. Gegen lukrative Angriffe auf der Grundlage von Cross-Site-Scripting sprechen:

  1. Der begrenzte Wirkungsbereich von Cross-Site-Scripting-Angriffen:
    Die Auswirkungen bleiben auf eine Anzahl von Benutzersitzungen und Benutzern beschränkt. Eine Rechteausweitung über die Möglichkeiten eines angemeldeten Benutzers hinaus – etwa zum uneingeschränkten Zugriff auf gespeicherte Kundendaten und Zahlungsmittel – ist von dort aus normalerweise nicht möglich.
  2. Die Gefahr, aufzufallen:
    Betrügerische Bestellungen bleiben nur dann nachhaltig möglich, wenn sie im Rauschen des normalen Shopbetriebes nicht auffallen. Bestellen jedoch auf einmal binnen kurzer Zeit Hunderte Nutzer das teuerste Produkt, wird sich darüber wahrscheinlich jemand wundern. Hinzu kommen Logfiles, in denen Cross-Site-Scripting-Angriffe wahrscheinlich Spuren hinterlassen. Anfangs weniger auffällig wäre der Zugriff auf Zahlungsdaten, deren späterer Missbrauch jedoch bald auffällt und zur Sperrung aller potenziell betroffenen Zahlungsmittel führen kann.
  3. Logistikanforderungen an den Angreifer:
    Wer sich auf fremde Rechnung Waren liefern lassen möchte, steht vor einem Problem: Er muss Lieferungen annehmen können, ohne sich erwischen zu lassen. Das wird mit jeder Wiederholung schwerer. Wer Zahlungsmittel missbraucht, steht später vor demselben Problem. Direkt das eigene Konto aufzufüllen, ist weniger schlau.
  4. Abhängigkeit von der Kooperation der Betroffenen:
    Wer Cross-Site-Scripting-Verwundbarkeiten ausnutzt, ist auf die Kooperation seiner Opfer angewiesen. Jeder betroffene Nutzer muss wenigstens einmal auf einen vom Angreifer präparierten Link geklickt oder bestimmte Funktionen des Shops besucht haben und möglicherweise in derselben Sitzung auch noch bestimmte Handlungen (z.B. Login oder Bestellvorgang mit Eingabe von Zahlungsdaten) vorgenommen haben, damit der Angriff Erfolg hat. Wer sich aktiv um diese Kooperation bemüht, fällt leichter auf. Hinzu kommt unter Umständen die Schwierigkeit, Nischenzielgruppen wie die aktiven Nutzer eines bestimmen deutschen Online-Shops überhaupt anzusprechen.

Eine Reihe denkbarer Angriffserfolge wird damit unwahrscheinlich, das unbemerkte, massenhafte Auslesen von Zahlungsdaten oder Benutzerkennungen nebst Passwörtern ebenso wie betrügerische Warenbestellungen im großen Maßstab.

Weit verbreitete und vielfältig ausnutzbare Verwundbarkeiten zu vermeiden, ist sicher dennoch eine gute Idee, schon weil sich das Gefüge der Risikofaktoren schwer überblicken lässt. Dass sich offensichtliche Nachlässigkeiten nicht in spektakulären Angriffen niederschlagen, halte ich jedoch für plausibel. Insofern liegen der Plakettenkonzern und seine Kunden möglicherweise richtig, wenn sie dem Thema Cross-Site-Scripting wenig Aufmerkamkeit widmen.

Beschränkter Horizont

Anforderungen – Requirements, By Design, Datenschutz, Nerds, Risiko, Security, , , , , ,

Die Forderung nach Ende-zu-Ende-Sicherheit für das besondere elektronische Anwaltspostfach (beA) und andere Dienste geht auf missverstandene Anforderungen und eine eingeschränkte Sicht auf den Lösungsraum zurück. Die missverstandene Anforderung liegt in der Vorstellung, der rechtlicher Schutz der Kommunikation verlange nach technischen Garantien. Die eingeschränkte Sicht auf den Lösungsraum berücksichtigt nur ausgewählte technische Mechanismen, deren Wirkung sie überschätzt, und lässt andere Aspekte des Risikomanagements außer Acht.

✹✹✹

Die Befürworter der Ende-zu-Ende-Verschlüsselung argumentieren, der Schriftverkehr von Rechtsanwältinnen sei besonders sensibel und man müsse ihn deshalb technisch besonders gut vor unbefugter Kenntnisnahme schützen. Die besondere Sensibilität mag man annehmen, wenngleich das beA nicht der Kommunikation zwischen Anwältinnen und ihren Mandantinnen dient, sondern dem Schriftwechsel zwischen Anwältinnen und Gerichten sowie der Anwältinnen untereinander. Jedoch steht die Telekommunikation ganz allgemein unter rechtlichem Schutz durch das Telekommunikationsgeheimnis. Selbst wer sie abhören könnte, darf dies nicht und wird andernfalls verfolgt und bestraft.

Ein wirksamer rechtlicher Schutz macht kann technische Maßnahmen überflüssig machen. Umgekehrt sind individuelle Schutzmaßnahmen dort nötig, wo keine Hilfe zu erwarten ist. Im Alltag verstehen wir das auch und verzichten zum Beispiel meist darauf, unsere leicht verwundbaren Körper besonders gegen Angriffe zu schützen. Wir wissen, dass die Wahrscheinlichkeit eines körperlichen Angriffs gering ist, denn dafür sorgen Polizei und Justiz. Anders verhalten sich etwa Menschen in Kriegsgebieten, die mit solchem Schutz nicht rechnen können.Im Spektrum zwischen diesen Extremen gibt es Mischlösungen, deren Schwerpunkt auf der einen oder anderen Seite liegt. Das Ziel ist letztlich ein akzeptables Restrisiko, ganz gleich mit welchen Mitteln es erreicht wird.

Die Motivation für technische IT-Sicherheit entspringt der eingeschränkten Möglichkeit zur Strafverfolgung im Netz. Zwar gelten Gesetze auch online, doch können sich Täter leichter verstecken und selbst bekannte Täter entgehen der Verfolgung, wenn sie im Ausland sitzen. Ganz ohne Sicherheitstechnik wird ein Anwaltspostfach also nicht auskommen. Allerdings muss man sich sowohl den Schutzbedarf als auch die Sicherheitsstrategie genauer anschauen.

Interessanterweise haben Juristen in dieser Hinsicht realistischere Vorstellungen als Hacker, die perfekte Sicherheit fordern. Juristen gehen ganz selbstverständlich davon aus, dass man Sicherheitsanforderungen nicht überspitzen darf. Das Schutzniveau soll dem alternativer Kommunikationsmittel wie Telefax und Briefpost entsprechen. Auf ein theoretisches Ideal kommt es nicht an. Aus rechtlicher Sicht interessant sind dann rechtliche Implikationen, die sich beispielsweise aus der zeitversetzten Kommunikation ergeben.

Ende-zu-Ende-Verschlüsselung erfüllt keine reale Sicherheitsanforderung, sondern sie strebt ein technisch motiviertes theoretisches Ideal an. Wie ich im vorigen Beitrag erläutert habe, ist dieses theoretische Ideal im realen System kaum zu erreichen. Das ist jedoch kein Problem, da sich die realen Sicherheitsanforderungen am Sicherheitsniveau realer Kommunikationsmittel wie Post, Fax und Telefon orientieren.

✹✹✹

Den Lösungsraum verengt die Forderung nach Ende-zu-Ende-Sicherheit auf scheinbar ideale kryptografische Ansätze. Diese Ansätze sind jedoch nicht nur nicht sinnvoll, wenn man – im Gegensatz zur Gesundheits-Telematik – in endlicher Zeit ein funktionsfähiges System bauen möchte. Es gibt auch Alternativen und Aspekte, von denen die Fokussierung auf das theoretische Ideal ablenkt.

Die Befürworter der kryptografischen Ende-zu-Ende-Sicherheit kritisieren die Umschlüsselung von Nachrichten in einem Hardware-Sicherheitsmodul (HSM). Bei der Umschlüsselung wird eine Nachricht ent- und mit einem anderen Schlüssel verschlüsselt. Auf diese Weise lassen sich die Zugriffsrechte auf der Empfängerseite von der ursprünglichen Verschlüsselung auf der Absenderseite entkoppeln. So kann man Beispielsweise Vertretern Zugriff auf Nachrichten geben, die bereits vor Beginn der Vertretung vom Absender verschlüsselt wurden.

Dies schaffe einen Single Point of Failure, der das ganze System „extrem verwundbar“ mache, argumentieren die Kritiker. Das ist insofern richtig, als ein erfolgreicher Angriff auf die entsprechende Systemkomponente, ein Hardware-Sicherheitsmodul (HSM), tatsächlich sämtliche Kommunikation beträfe. Solche Angriffspunkte gäbe es freilich auch bei einer Ende-zu-Ende-Lösung noch. Alle Kommunikation ausspähen könnte beispielsweise, wer den beA-Nutzerinnen eine manipulierte Version der Software unterjubelt oder wer in die Produktion der zur Nutzung erforderlichen Smartcards eingreift.

Die damit verbundenen Restrisiken nehmen wir jedoch notgedrungen in Kauf und ergreifen Maßnahmen, um sie zu klein zu halten. So wird man beispielsweise die Smartcard-Produktion durch Zugangskontrollen und Überwachung so gut wie eben praktikabel vor unbefugten Eingriffen schützen. Nichts spricht grundsätzlich dagegen, dies auch für die Umschlüsselung zu tun – deswegen unter anderem das Sicherheitsmodul. Die Fokussierung auf das vermeintliche Allheilmittel Ende-zu-Ende-Verschlüsselung verstellt jedoch den Blick auf solche Maßnahmen, die zum Risikomanagement beitragen.

Falls wir in einem Single Point of Failure ein grundsätzliches Problem sähen und die damit verbundenen Risiken für nicht beherrschbar hielten, müssten wir jedoch nach ganz anderen Wegen Ausschau halten. Wir müssten dann nämlich nach einer organisatorischen und technischen Architektur suchen, welche die Auswirkungen eines einzelnen erfolgreichen Angriffs auf einen Teil des Systems, der Nutzer und der Inhalte begrenzt und verlässlich dafür sorgt, dass der Aufwand für erfolgreiche Angriffe proportional zu ihren Auswirkungen wächst.

Solche Ansätze hätten erst einmal überhaupt nichts mit Kryptografie zu tun, sondern mit Organisationsprinzipien. Man könnte beispielsweise ein Ökosystem verschiedener unabhängiger Lösungen und Anbieter schaffen und die Haftung angemessen regeln.  Angriffe auf einen Anbieter beträfen dann nur dessen Nutzer. Mit DE-Mail gibt es sogar bereits ein solches Ökosystem, welches weitgehend brachliegt und sich nach Anwendungen sehnt.

Auf solche Fragen und Ansätze – deren Nutzen und Notwendigkeit allerdings erst nach einer gründlichen Bedrohungs- und Risikoanalyse klar wird – kommt man gar nicht erst, wenn man eine Abkürzung nimmt und blind die Anwendung bestimmter technischer Entwurfsmuster fordert.

Mit Sicherheit ins Desaster

Anforderungen – Requirements, By Design, Risiko, Security, security-industrial complex, So geht das, , , , ,

Als wäre das Desaster um das besondere elektronische Anwaltspostfach (beA) nicht schon schlimm genug, kommen nun auch noch Aktivisten aus ihren Löchern und fordern eine „echte Ende-zu-Ende-Verschlüsselung“.

Kann diesen Cypherpunks mal jemand das Handwerk legen? Eine „echte Ende-zu-Ende-Verschlüsselung“ ist für ein beA technisch eben nicht möglich, sondern als Anforderung das Rezept für ein Desaster.

Unter Laborbedingungen lässt sich gewiss ohne große Schwierigkeiten eine Public-Key-Infrastruktur (PKI) aufbauen und auf beliebig viele Teilnehmer skalieren, so dass jeder mit jedem verschlüsselt kommunizieren kann. So eine Labor-PKI löst aber nur das halbe Problem – und macht es schwer, die andere Hälfte zu lösen, die unter den idealisierten Bedingungen der Laborumgebung keine Rolle spielt.

Drei Teilprobleme, mit denen eine Lösung für die Anwaltskommunikation zurechtkommen muss, sind (1) komplizierte Zugriffsrechte, (2) der Konflikt zwischen Vertraulichkeit und Verfügbarkeit sowie (3) Veränderungen im Zeitverlauf.

  1. Komplizierte Zugriffsrechte
    Anwaltskommunikation ist nicht einfach Kommunikation von Person zu Person. Anwälte haben Gehilfen für administrative Tätigkeiten, die beispielsweise Post holen und verschicken. Diese Gehilfen brauchen ausreichende Zugriffsrechte, um ihre Arbeit zu verrichten, aber sie haben keine Prokura. Anwälte haben außerdem Vertreter für Urlaub, Krankheit usw., die von der Anwältin oder der Rechtsanwaltskammer bestellt werden. Alleine der Versuch, § 53 BRAO in eine PKI und eine Ende-zu-Ende-Verschlüsselung zu übersetzen, dürfte Entwicklern einiges Kopfzerbrechen bereiten.
  2. Vertraulichkeit vs. Verfügbarkeit
    Vertraulichkeit der Anwaltskommunikation ist wichtig, aber zweitrangig. Wichtiger ist die Verfügbarkeit. Fragen des Zugangs von Erklärungen und der Einhaltung von Fristen können einen Rechtsstreit unabhängig davon entscheiden, wer in der Sache eigentlich Recht hätte. Vor allem anderen werden Anwältinnen Wert darauf legen, dass sie unter allen Umständen verlässlich kommunizieren können. Demgegenüber genügt hinsichtlich der Vertraulichkeit oft das Schutzniveau „Telefon“.
  3. Zeitliche Dynamik
    Ein reales System zur Anwaltskommunikation muss nicht zu einem Zeitpunkt funktionieren, sondern über einen langen Zeitraum, währenddessen sich die Welt ändert. Das betrifft neben den offensichtlichen Aspekten – Hinzukommen und Ausscheiden von Nutzern in den verschiedenen Rollen, veränderte Vertretungsregelungen usw. – auch die Technik, zum Beispiel den Schlüsseltausch. Damit muss ein beA unter Berücksichtigung von (1) und (2) zurechtkommen. Darüber hinaus können sich auch gesetzliche Regelungen jederzeit ändern.

Wir brauchen deshalb keine Ende-zu-Ende-Sicherheit, sondern im Gegenteil endlich die Einsicht, dass Sicherheit:

  • sekundär ist und der Funktion nicht vorausgeht, sondern folgt,
  • keine theoretischen Ideale verfolgen, sondern reale Risiken reduzieren soll,
  • nicht durch formale Garantien und einzelne Wunderwaffen entsteht, sondern aus der Kombination verschiedener partieller Maßnahmen resultiert,
  • nicht perfekt sein muss, sondern nur gut genug.

Die Vorstellung, man könne konkurrenzfähige Anwendungen um starke Kryptographie herum konstruieren, ist vielfach gescheitert und diskreditiert. Als um die Jahrtausendwende der Online-Handel wuchs, entwickelte man kryptografische Bezahlverfahren von eCash bis SET – den Markt gewannen jedoch Lastschrift, Kreditkarte, Nachnahme und Rechnung. Das Online-Banking wollte man einst mit HBCI / FinTS sicher machen – heute banken wir im Browser oder auf dem Händi und autorisieren Transaktionen mit TANs und Apps. Das vor gut zwanzig Jahren entstandene Signaturgesetz ist in seiner ursprünglichen Form Geschichte und elektronische Signaturen haben sich bis heute nicht auf breiter Front durchgesetzt.

Wer dennoch weiter an die heile Scheinwelt der Ende-zu-Ende-Sicherheit glauben möchte, der möge sich seine Lösungen von den Experten der Gematik entwickeln lassen. Die kennen sich damit aus und sobald ihr Flughafen ihre Telematikinfrastruktur läuft, haben sie sicher Zeit für neue Projekte.

Rezeptdatenhandel

Bedrohung, Datenschutz, Geschäft, Risiko, Security, Wahrnehmung, , ,

Wer Gesundheitsdaten missbraucht, will bestimmt Patientenprofile anlegen und damit irgend etwas böses tun. Das scheint plausibel, wenngleich irgend etwas böses selten klar definiert wird, und spielt im Bedrohungsmodell der mühsam im Inkubator am Leben gehaltenen Gesundheitskarte eine zentrale Rolle. Nur halten sich Angreifer nicht an Angreifermodelle:

»Mit den Rezeptdateien, die nicht anonymisiert worden waren, konnten die Unternehmen eventuell nachvollziehen, welche Medikamente von bestimmten Arztpraxen verschrieben wurden. Derartige Informationen würden es ermöglichen, die Arbeit von Außendienstmitarbeitern zu kontrollieren. So könnte man demnach überprüfen, ob Ärzte nach den Besuchen von Vertretern der Pharmaindustrie häufiger bestimmte Medikamente verschreiben.«

(Heise Online: Bericht: Illegaler Handel mit Rezeptdaten)

Warum das verboten ist, spielt keine so große Rolle. Interessanter finde ich die Frage, ob man solche Angriffe im Entwurf unserer Gesundheits-IT berücksichtigt hat. Mehrseitige Sicherheit ist ja kein völlig neues Konzept.

Juristen sind Pragmatiker

Begriffe, IT, Nerds, Rechtsabteilung, Security, ,

Wenn Security- beziehungsweise Kryptographie-Nerds über die Welt reden, benutzen sie gerne Begriffe wie Beweisbarkeit und Nichtabstreitbarkeit. Diese Begriffe haben eine spezifische technische Bedeutung, sie werden aber auch von anderen verwendet, etwa von Juristen – in anderer Bedeutung. Vermischt man die Bedeutungen in verschiedenen Kontexten, so kommt man leicht auf die Idee, dass elektronische Signaturen oder elektronische Personalausweise eine unheimlich wichtige Sache seien. Nur durch die Hinterlegung landläufiger oder juristischer Begriffe mit gleich benannten, aber inhaltlich verschiedenen technischen Begriffen könne man IT-gestützte Dienste und Abläufe so gestalten, dass sie technisch und rechtlich sicher seien.

Juristen sehen das alles viel entspannter. Wie das Lawblog berichtet, hat das Oberlandesgericht Hamm eine Vereinssatzung für rechtmäßig erklärt, die Mitgliederversammlungen in einem Chatraum vorsieht. Dem Security-Nerd ist das ein Graus: Was da alles passieren könnte! Die Juristen hingegen gehen pragmatisch an die Sache heran. Wenn es keine offensichtlichen, konkreten Probleme gibt, lasst die Leute doch erst mal machen. Wenn’s dann doch Streit geben sollte, kann man sich immer noch vor Gericht treffen und über konkrete Vorwürfe reden.

Damit liegen die Juristen richtig, denn sie bedienen sich intuitiv eines statistischen Bedrohungsmodells. Theoretische Möglichkeiten interessieren den Juristen nicht so sehr, solange sie sich nicht in seiner Lebenserfahrung oder in konkreten Beweisen widerspiegeln. Damit werden theoretische Möglichkeiten, die in der Realität selten vorkommen, geringer gewichtet als erfahrungsgemäß tatsächlich auftretende Sachverhalte. Das so gebildete Modell kann in den zugrundeligenden Annahmen oder in seiner Anwendung auf einen Einzelfall falsch sein; dann haben wir was zu meckern. Aber es ist, gerade wenn es um Voraussagen über Risiken geht, angemessen. Was erfahrungsgemäß vorkommt, wird ernst genommen, weil genügend dokumentierte Fälle vorliegen. Bloße Möglichkeiten dagegen bleiben unberücksichtigt.

Abstrahiert man von den Details konkreter Abläufe, landet man damit genau bei der Definition einer Bedrohung. Eine Bedrohung setzt sich zusammen aus Interessen bzw. Zielen und Fähigkeiten. Beide Komponenten sind erforderlich: ohne Interesse sind die Fähigkeiten egal und ohne Fähigkeiten spielen die Ziele keine Rolle. Erst wenn beides zusammenkommt, wird ein Angriff daraus. Security-Nerds schauen nur auf die Fähigkeiten und ignorieren die Ziele.

Safe and sorry

English, Security, Unterwegs, Vulnerability, , , ,

A common delusion in security engineering is the idea that one could secure a system by identifying items that need protection (assets), describing the ways in which they might be damaged (threats or attacks, which are not synonymous but often confused), and then implementing countermeasures or mitigations such that all, or the most common, or the most damaging threats are covered. The system thus becomes secure with respect to the threat model, so the reasoning. This is the model underlying the Common Criteria, and it works fine as a descriptive model. To give an example from everyday life, consider a bicycle as an asset. If your bicycle gets stolen (the threat), your damage is the value of the bicycle plus any collateral damage that the loss may cause you, such as coming late to an appointment, having to pay for a taxi or public transport instead of riding your bicycle, and having to go to the gym for workout instead of getting a workout for free on your way to work. The typical countermeasure against this threat is locking the bicycle to a fence, pole, or other appropriate object. Locking your bicycle reduces the risk of it being stolen. What could possibly go wrong? Besides the obvious residual risk of your countermeasures not being strong enough, this could go wrong:

A bicycle frame locked to a fence, wheels and other parts stolen
Safe and sorry © 2012 Sven Türpe, CC-BY 3.0

 

This (ex-)bicycle was and remains properly locked and no vulnerability in the lock or in items the lock depends on have been exploited. Yet, somebody made a fortune stealing bicycle parts, and somebody else lost a bicycle to an attack. What’s the problem? The problem is the gross simplification in the asset-threat-countermeasure model, which neglects three important factors:

  1. Adaptive adversaries. A countermeasure does not oblige the adversary to stick to the original attack plan that the countermeasure is targeted at. Security measures change the threat model. They don’t force the adversary to give up, they force the adversary to change strategy and tactics.
  2. The victim’s loss and the adversary’s gain are not necessarily the same. In the case of the bicycle above, the lock may reduce the attacker’s gain to the black market value of the removed parts. The victim’s loss is still one bicycle.
  3. Asset dependencies. Thinking of a bicycle as one asset is an abstraction. A bicycle is really a collection of assets—its parts—and an asset by itself. Such dependencies, nested assets in this case, are common.

The bicycle lock, it turns out, is not really a bicycle lock, it’s a bicycle frame lock. It protects only one sub-asset of the bicycle, and an economically motivated adversary can make a gain that seems worth the risk without breaking the lock.

Prescriptive threat modeling—threat modeling done with the aim of finding a proper set of security features for a system—needs to take these issues into account. A good threat model anticipates changes in attacker behavior due to security measures. A good threat model considers not only damages to the victim but also gains of the adversary, as the latter are what motivates the adversary. And good security engineering is biased towards security, always overestimating adversary capabilities and always underestimating the effect of security measures, systematically.

Unterschätzte Risiken: Sicherheitsbewusstsein – und Kindergartenbedrohungsmodelle

Angst, IT, Propaganda, Security, Unterschätzte Risiken, , , , , , ,

Die Vorgeschichte:

Jemand hat eine Schadsoftware verbreitet, die den Datenverkehr befallener Systeme umleitet. Das FBI hat die dafür verwendeten Server unter seine Kontrolle gebracht und zunächst weiterlaufen lassen, will sie aber demnächst abschalten. Das BSI stellt zusammen mit der Telekom eine Website bereit, mit der man seinen PC auf Befall prüfen kann und ggf. ein Tool zur Bereinigung angeboten bekommt.

Das Ergebnis:

»Verwirrung um die Schadsoftware DNS-Changer: User fürchten nach dem Aufruf zum Rechner-Selbsttest des Bundesamtes für Sicherheit in der Informationstechnik, sie könnten sich den Staatstrojaner einfangen. Die Behörde weist die Vermutung zurück.«

(Focus Online:
Angst vor Hacker-Angriff und dem Staatstrojaner: Internetnutzer trauen dns-ok.de nicht)

Kinder, das ist doch blöd. Wenn ich einen Staatstrojaner unter die Leute bringen will, dann mache ich das nicht so, dass mein Werk nach drei Stunden aufgeflogen und durchanalysiert ist. Und überhaupt, woher habt Ihr Euer Angreifermodell? Was muss man geraucht haben, um bei jeder Handlung der Behörden eines demokratischen Rechtsstaates zuerst eine gegen sich selbst gerichtete Verschwörung zu vermuten? Sicher, Behörden machen manchmal Mist, zuweilen auch richtig großen und mit Vorsatz. Aber so eine plumpe Verteilaktion, wie Ihr sie unterstellt? Ihr seid ja nicht ganz dicht.

Threat Modeling in Action

English, Freundlich zum Nutzer, Security, , , ,

After the videos on threat modeling an example seems in order. Securology provides us with a good one in Selecting a Pistol Safe as (part of) the basis of a procurement decision. This is his set of requirements:

So, I needed a way to „securely“ (that’s always a nebulous word) store a firearm– namely a pistol– such that it could meet the following criteria:

  1. Keep children’s and other family members‘ hands off of the firearm
  2. Stored in, on, or near a nightstand
  3. Easily opened by authorized people under stress
  4. Easily opened by authorized people in the dark
  5. Not susceptible to power failures
  6. Not susceptible to being „dropped open“
  7. Not susceptible to being pried open
  8. Not opened by „something you have“ (authentication with a key) because the spouse is horrible at leaving keys everywhere.
  9. For sale at a reasonable cost
  10. An adversary should not know (hear) when the safe was opened by an authorized person

But I didn’t care a lot about the ability to keep a dedicated thief from stealing the entire safe with or without the firearm inside.

Read on at Securology to see how various products fail to fulfill this set of requirements. This example is illustrative in that it addresses several distinct threat aspects and tradeoffs. The pistol is not simply an asset needing protection, it is also by itself a security mechanism against certain threats. The resulting optimization problem is pretty interesting: keeping (some) unauthorized people from accessing the pistol while maintaining availability to the authorized in a practical sense.