Internet security by numbers

English, Zahlenspiele

For the collectors and slide producers among you:

SANS Cyber Security Survey 2009
The survey found that Web server-side applications are the target of more than 60% of all Internet attacks and that “Web application vulnerabilities such as SQL injection and cross-site scripting flaws in open source as well as custom-built applications account for more than 80% of the vulnerabilities being discovered. Despite the enormous number of attacks and despite widespread publicity about these vulnerabilities, most Web site owners fail to scan effectively for the common flaw.” http://www.sans.org/top-cyber-security-risks/

(See Making Sense of the SANS “Top Cyber Security Risks” Report at The New School of Information Security for a critique of the report.)

X-Report von IBM 2009
According to the report, criminals are leveraging insecure Web applications to target users of legitimate Web sites. These attacks intended to steal and manipulate data and take command and control of infected computers. The report states that SQL injection attacks rose 50 percent from Q4 2008 to Q1 2009 and then nearly doubled from Q1 to Q2.
http://www-935.ibm.com/services/us/iss/xforce/trendreports/

Sophos Security Threat 2009
23,500 new infected webpages are discovered every day. That’s one every 3.6 seconds, four times worse than in 2007.

http://www.sophos.com/sophos/docs/eng/papers/sophos-security-threat-report-jul-2009-na-wpus.pdf

Unterschätzte Risiken: Milchbauern

Unterschätzte Risiken, ,

»Rund eine Tonne toter Fische wurde am Kloster Helfta, dem Tagungsort der Agrarminister, seit Samstag geborgen. Die Fische verendeten vermutlich wegen der von Bauern ausgekippten Milch. Am Freitag hatten Landwirte aus Protest gegen die niedrigen Milchpreise mehrere zehntausend Liter Milch aus Güllefahrzeugen vor das Kloster gekippt.«

(Welt Online:
Niedrige Milchpreise: Milchbauern bringen durch Protest Fische um)

Madrid im Hinterkopf

Angst, Security, Unterwegs, , , ,

Eben sollten wir noch Angst haben angesichts der Videodrohung eines bartlosen Islamisten. Gleich darauf dürfen wir uns aber wieder sicher fühlen. Auf dem Frankfurter Flughafen und dem Hauptbahnhof blicken wir in die Mündungen von Maschinenpistolen, und es sind die Maschinenpistolen unserer Freunde und Helfer:

»Seit Freitag müssen sich Reisende in der Main-Metropole an ein neues Bild gewöhnen: Bundespolizisten mit schweren Schutzwesten und Maschinenpoistolen schreiten in den Hallen des Frankfurter Flughafens und an den Gleisen des Frankfurter Hauptbahnhofs umher. „Es geht um die Präsenz, wir wollen den Reisenden Sicherheit geben“, rechtfertigt eine Sprecherin des Bundespolizeipräsidiums die verschärften Sicherheitsmaßnahmen.«

(HR: Nach Terror-Drohung: Bewaffnete Polizisten patrouillieren)

Gegen eine angemessene Bewaffnung der Polizei ist nichts einzuwenden, sie ist manchmal leider nötig. Dennoch ist von dieser plakativen Maßnahme kaum ein Sicherheitsgewinn zu erwarten. Man habe »Madrid im Hinterkopf,« heißt es wenig später im Text, aber das ist doppelt falsch: erstens hat man es nicht oder nur sehr vage, und zweitens würde das auch nichts nützen.

Wir erinnern uns. In Madrid fuhren die Bomben in Nahverkehrszügen in den Bahnhof. Wer das im Hinterkopf hätte, verspräche sich von Maschinenpistolen auf den Bahnsteigen des Hauptbahnhofes wohl wenig. Ein Terrorist könnte sie getrost ignorieren und an irgendeinem Vorortbahnhof mit seiner Bombe in die S-Bahn steigen. Und selbst wenn er das nicht könnte, warum sollte ein Terrorist auf Züge, Bahnhöfe oder Flughäfen fixiert sein? Wer viele Menschen auf einen Schlag treffen möchte, kann auch Samstags auf die Zeil gehen. Oder zur IAA aufs Messegelände. Oder in die Oper. Oder zur Konsumtempeleröffnung nach Weiterstadt. Oder, oder oder.

Weder gibt es eine besonders große Bedrohung; selbst wenn sich tatsächlich gerade entschlossene Terroristen auf ihren großen Tag vorbereiten, bleibt das individuelle Risiko gering. Noch tragen die Polizisten mit Maschinenpistolen nennenswert zur Risikoreduktion bei. Sie helfen nur den Verantwortlichen, ihre Verantwortung zu tragen.

Digital Cold Reading: The CSS History Hack

English, IT, Phishing, Security, Wahrnehmung, ,

[See only posts in English]

Cold reading is a technique used by mentalists to simulate psychic powers and impress people. Essentially, the cold reader is supplying words and the other person supplies their meaning as well as hints for the reader.

The CSS history hack, which seems to impress quite a few people, is nothing more than the Web’s version of cold reading. Your impression is that any Web site can read your browser history. Now there is indeed an information leak and no Web site should get access to history information. But this leak is very small. It doesn’t reveal the history altogether to anyone daring to ask. The CSS history issue only gives us an oracle. We can ask the oracle whether a particular URL is in the history or not. So to find out that you’ve read this blog post we would have to ask the oracle about the precise URL of this post.

Nonetheless demonstrations of the history hack impress people. The trick is simple and similar to the cold reading technique. History hack demos use a set of URLs that leads to a hit for almost every Internet user on the world: Google, YouTube, Microsoft, Wikipedia, Flickr, Apple, Slashdot, Amazon, and so on. A mentalist would guess and suggest these until you start giving feedback on which to hook. The CSS history hack replaces this interaction with asking the oracle to avoid wrong guesses. The trick is really to use a set of Web sites that guarantees a hit, and use a minor information leak to remove the wrong guesses from the set that would spoil the effect. This works well with the top 20/top 50/top 1000 sites on the Web, but it won’t scale to arbitrary URLs.

Unterschätzte Risiken: Mallorca

Safety, Unterschätzte Risiken, Unterwegs,

Was die Frankfurter Rundschau berichtet, ist bis zur nächsten Badesaison sicher wieder vergessen:

»Innerhalb von rund zwei Wochen sind auf der Ferieninsel elf Menschen beim Schwimmen oder Tauchen im Meer ums Leben gekommen – acht der Opfer waren deutsche Touristen.«

(Frankfurter Rundschau: Badeunfälle: Tod vor Mallorca)

Alles übers Ertrinken erfahren Sie unter www.blausand.de. Insgesamt kommen jedes Jahr einige Hundert Deutsche bei Badeunfällen ums Leben.

Swiss Cheese Security

Classifier Security Model, English, Forschung, IT, Security, Unterwegs, , , , ,

I’m off for the New Security Paradigms Workshop in Oxford, where I will present what I currently call the Swiss Cheese security policy model. My idea is to model security mechanisms as classifiers, and security problems in a separate world model as classification problems. In such a model we can (hopefully) analyze how well a mechanism or a combination of mechanisms solves the actual problem. NSPW is my first test-driving of the general idea. If it survives the workshop I’m going to work out the details. My paper isn’t available yet; final versions of NSPW papers are to be submitted a few weeks after the workshop.

Gute Ingenieure haben keine Visionen

Geschäft, Propaganda, Stammtisch, , , , , , ,

Kein technischer Fortschritt ist je aus einer Anwendungsvision hervorgegangen. Stets waren es Bastler und Tüftler, die ein Stück Technik um seiner selbst willen schufen und optimierten, die universelle Technologien entwickelten und der Menschheit zum Fortschritt verhalfen. Die Dampfmaschien war Auslöser der Industrialisierung, aber sie entstand nicht mit der Industrialisierung als Ziel; der Verbrennungsmotor ermöglichte Autos, Panzer und Flugzeuge, wurde aber nicht für Autos, Panzer und Flugzeuge geschaffen; der Weg zum Internet führte über die Entwicklung der Glühbirne und des Telegraphen, ohne dass dabei jemand an ein Internet gedacht hätte.

Genau umgekehrt stellt man sich die Sache vor, wo man versucht, den Fortschritt zu bürokratisieren. Wer schon einmal Fördergelder für die Forschung beantragt hat, der kennt dieses Spiel. Da kommt erst die Vision und dann die Technik. Das Ergebnis ist oft ziemlicher Käse, der schlichteren Naturen – Anforderungsanalyse ist anspruchsvoll – gleichwohl plausibel erscheint. Gute Ingenieure haben keine Visionen weiterlesen →

Production-safe Testing

English, IT, Safety, Security, Testlabor, , , , , ,

[See only posts in English]

Software testers increasingly have to deal with production systems. Some tests make sense only with production systems, such as Nessus-style vulnerability scanning. And an increasing number of systems is hard to reproduce in a test bed as the system is really a mashup of services, sharing infrastructure with other systems on various levels of abstraction.

Testing production systems imposes an additional requirement upon the tester, production safety. Testing is production-safe if it does not cause undesired side-effects for the users of the tested or any other system. Potential side effects are manifold: denial of service, information disclosure, real-world effects caused by test inputs, or alteration of production data, to name just a few. Testers of production systems therefore must take precautions to limit the risks of their testing.

Unfortunately it is not yet very clear what this means in practice. Jeremiah Grossman unwittingly started a discussion when he made production-saftey a criterion in his comparison of Website vulnerability assessment vendors. Yesterday he followed up on this matter with a questionnaire, which is supposed to help vendors and their clients to discuss production-safety.

The time is just right to point to our own contribution to this discussion. We felt a lack of documented best practice for production-safe testing, so we documented what we learned over a few years of security testing. The result is a short paper, which my colleague and co-author Jörn is going to present this weekend at the TAIC PART 2009 conference: Testing Production Systems Safely: Common Precautions in Penetration Testing. In this paper we tried to generalize our solutions to the safety problems we encountered.

The issue is also being discussed in the cloud computing community, but their starting point is slightly different. Service providers might want to ban activities such as automated scanning, and deploy technical and legal measures to enforce such a ban. They have good reason to do so, but their users may have equally good reason to do security testing. One proposal being discussed is a ScanAuth API to separate legitimate from rogue scans. Such an API will, however, only solve the formal part of the problem. Legitimate testing still needs to be production-safe.