Archiv der Kategorie: IT

Information Technology

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.

Management ohne Metriken

IT, O-Ton, Risiko, , , ,

Der eine oder andere dürfte es mitbekommen haben. Tom DeMarco, dem wir die Manager-Faustregel: “You can’t control what you can’t measure.” verdanken, macht einen Rückzieher. An Software Engineering will er nicht mehr so recht glauben, und an Metriken auch nicht. In seinem Artikel Software Engineering: An Idea Whose Time Has Come and Gone? erläutert er seinen Sinneswandel unter anderem an diesem Beispiel:

»Imagine you’re trying to control a teenager’s upbringing. The very idea of controlling your child ought to make you at least a little bit queasy. Yet the stakes for control couldn’t be higher.
(…)
Now apply “You can’t control what you can’t measure” to the teenager. Most things that really matter—honor, dignity, discipline, personality, grace under pressure, values, ethics, resourcefulness, loyalty, humor, kindness—aren’t measurable.«

Von der Vorstellung, wir könnten ausgerechnet in der IT-Sicherheit Risiken anhand von Metriken steuern, sollten wird uns schnell verabschieden. Zusätzliche Unbekannte und Rückkopplungen vereinfachen das Problem sicher nicht.

Ach ja, und hört nicht auf Gurus.

Unterschätzte Risiken: Killerspiele

IT, Unterschätzte Risiken, ,

Wer solche Dienstleister beschäftigt (und kein Backup hat), der braucht keine Feinde mehr:

»Er hatte seinen Sohn mit zu einem Firmenkunden genommen. Während der Verurteilte seiner Arbeit nachging, machte sich sein Sohn an einem Kundenrechner zu schaffen und löschte dabei beim Versuch ein Computerspiel zu installieren, versehentlich wichtige Datenbestände.«

(Blog zur IT-Sicherheit: Sind Ihre Daten wirklich sicher?)

Mehr Spaß mit SSL (in Firefox 3)

Freundlich zum Nutzer, IT, Security, ,

Dieser Tipp ist nicht neu, aber mein Leidensdruck war nicht so groß, dass ich aktiv danach gesucht hätte. Das Verhalten von Firefox bei formal ungültigen SSL-Zertifikaten lässt sich etwas weniger nervig gestalten:

  • about:config aufrufen
  • browser.xul.error_pages.expert_bad_cert auf true setzen
  • browser.ssl_override_behavior auf 2 setzen

(gefunden hier, Erklärung da).

Damit spart man sich ein paar unnötige Mausklicks.

Unterschätzte Risiken: Hackerwettbewerbe

Hackmeck, IT, Phishing, Security, Testlabor, Unterschätzte Risiken, , ,

Lehrreiches Scheitern:

»A Webmail service that touts itself as hack-proof and offered $10,000 to anyone who could break into the CEO’s e-mail has lost the challenge.
(…)
The hacking team of Aviv Raff, Lance James and Mike Bailey set up the attack by sending an e-mail to the company’s CEO Darren Berkovitz. When he opened the e-mail, the team exploited an XSS flaw to take control of the account.«

(Zero Day: StrongWebmail CEO’s mail account hacked via XSS)

Die 10.000 Dollar hätten sie auch gleich bei einem fähigen Security-Tester anlegen können, dann hätten sie für dasselbe Geld wahrscheinlich mehr über ihre Irrtümer gelernt. Allzu weit kommt man mit diesem Betrag zwar nicht, aber die Tester arbeiten wenigstens bis zum Ende des Geldes weiter, statt mit dem ersten gefundenen Problem den Preis abzuräumen. Damit sinkt auf lange Sicht der Preis pro gefunder Verwundbarkeit, während er bei einer Folge von Hackerwettbewerben vielleicht sogar steigen würde.

Digitalräuberpistole

Gadget, Geschäft, Hackmeck, IT, Phishing, Security, Verschwörung, , ,

Erinnert sich noch jemand an die Story von vor sechs Wochen, derzufolge es mit einem manipulierten Nokia 1100 möglich sei, Kurznachrichten an GSM-Teilnehmer abzufangen? Kriminelle würden bis zu 25.000 Euro für ein solches Gerät bieten, weil auf diese Weise mTAN-Sendungen abzufangen seien. Glauben wollte das keiner so recht.

Inzwischen macht die Meldung die Runde, der Firma UltraScan – die das Thema damals in die Nachrichten brachte – sei es gelungen, die Sache (ein einzges Mal) nachzuvollziehen. Von löschbarem ROM in einigen Modellen der Serie aus dem Bochumer Nokia-Werk ist die Rede und von Schlüsseln für eine verschlüsselte Firmware, die in falsche Hände geraten seien. Dann wird es wirr: man könne durch Firmware-Hacking neben der IMEI, die das Gerät identifiziert, auch die IMSI, die Identität der SIM-Karte, manipulieren – wozu man allerdings eine SIM-Karte klonen müsse, was aber trivial sei.

Alles verstanden? Ich auch nicht. Und die Websites von Ultrascan erwecken nicht gerade den Eindruck hoher Kompetenz und Seriosität.

Compliance leicht gemacht

Freundlich zum Nutzer, Geschäft, IT, Regierungsviertel, Security, Wahrnehmung, , ,

Microsoft hat den .NET Messenger für Nutzer in Kuba, Syrien, Iran, Sudan und Nordkorea gesperrt. Diese Länder unterliegen einem Embargo der Vereinigten Staaten; US-Firmen dürfen mit ihnen keine Geschäfte machen. Manche finden das hirnrissig (das ist es auch, aber es ist Gesetz), während andere die Umsetzung für hirnrissig halten. Microsoft benutzt nämlich einfach die im Profil hinterlegte Landeseinstellung des Nutzers, und die ist frei wählbar.

Diese Implementierung ist aber nicht hirnrissig, sondern vollständig rational und typisch für Compliance-Probleme. Security dreht sich um die Lösung eigener Probleme, die Durchsetzung eigener Interessen mit technischen und organisatorischen Mitteln. Diese Mittel sollen – im Rahmen des jeweils vertretbaren Aufwandes – effektiv sein, also böswillige Angriffe tatsächlich abwehren. Dabei besteht ein direkter Zusammenhang zwischen den erwarteten Schäden durch Angriffe und dem vertretbaren Aufwand.

Compliance hingegen erfordert die Wahrung fremder Interessen, auferlegter Regeln und Anforderungen. Zu eigenen Interessen eines Unternehmens werden sie erst aufgrund angedrohter Zwangsmaßnahmen. Effektivität ist auch hier das Ziel, aber maßgeblich sind nun nicht mehr die direkten Auswirkungen, sondern die angedrohten. Die sind willkürlich festgelegt.

Ein Unternehmen, das Compliance erzielen möchte beziehungsweise muss, wird deshalb jeweils zum einfachsten und billigsten Mittel greifen, das die angedrohten Zwangsmaßnahmen genügend zuverlässig abwehrt. Dieses Mittel muss keinen realen Effekt haben. Es muss lediglich die Kontrolleure zufriedenstellen. Die Lösung von Microsoft für das Compliance-Problem des Messengers leistet dies vermutlich.

Das tatsächliche Problem ist damit vorerst gelöst. Ob Kubaner, Sudanesen oder Nordkoreaner mit dem .NET Messenger chatten, ist dagegen nur ein Scheinproblem. Ohne Compliance-Zwänge wäre es Microsoft einfach egal. Aus geschäftlicher Sicht gäbe es keinen Grund darüber auch nur nachzudenken.

Heilig’s Maßnähmle

Angst, IT, Security, , , , ,

Großes Palaver unter IT-Verantwortlichen. Es geht um die unternehmensweit auf allen Arbeitsplätzen eingesetzte Antivirus-Software. Beim Zugriff auf eine bestimmte interne Web-Anwendung verursacht sie Performance-Probleme. Jemand hat vorgeschlagen, gezielt für diese Situation und nur dafür eine Teilfunktion des Virenscanners zu deaktivieren.

Im Grunde genommen ist man sich einig und hält den Vorschlag für ein Sakrileg. Sicherheitsmechanismen zu deaktivieren komme überhaupt nicht in Frage. Rationale Erwägungen über das Risiko sowie über Sinn, Zweck und Wirkung der Maßnahme spielen keine Rolle. Statt dessen versucht man einander zu übertreffen im Ringen um die schönste Begründung. Der Tenor: wenn man bei der Sicherheit einmal einen Kompromiss mache, gehe sicher bald das Abendland unter.

In diesem Fall war es nicht allzu schwer, den Weg zurück zu einer sachlichen Betrachtung zu weisen. Wovor ein Antivirus-Programm schützt beziehungsweise eben nicht schützt, ist schnell erklärt, und was danach an Szenarien übrig bleibt, gehört in die Kategorie Movie Plot.

Ich hätte aber schon gerne ein Werkzeug, eine Methode, um den Verzicht auf eine Sicherheitsmaßnahme nicht nur im Einzelfall gut zu begründen. So etwas brauchen wir dringend, denn Verantwortliche entscheiden selten unvoreingenommen. Für sie ist eine Maßnahme stets besser als keine Maßnahme. Kommt es wider Erwarten zu einem Vorfall, dann wird er in der befürchteten Interpretation trotz der ergriffenen Maßnahmen geschehen, aber wegen der nicht ergriffenen.

Wie also begründet man sauber, dass man eine verfügbare Sicherheitsmaßnahme nicht ergreift, ohne sich auf phantasievolle Kosten- und Risikoschätzungen zu stützen?

10 Essential Security Checks

English, IT, Security, Zwischenruf,

[Get only posts in English]

A few days ago Oliver presented his 10 essential Web site checks. Except for a few very basic things I didn’t see security on his list, so here are a few essential security checks for your Web site. You will have to scale them to your needs; the Web site of your local juggling club won’t need the same level of security as an Internet business built around a Web application.

  1. Understand your threat profile
    Understand who might be your enemy and what would be the impact on your Web site and the users of your Web site if an attack succeeds. Don’t be overly paranoid but be honest to yourself.
  2. Use SSL
    Although it has its limitations, SSL is a standard security mechanism today and there is almost no excuse for not offering it to your users. It won’t solve all your security problems but it is useful.
  3. Have a person in charge of security
    Security requires continuous attention throughout the life cycle of your site. Somebody should be responsible for security, and this person must have sufficient authority to be more than a fig leaf.
  4. Baseline protection
    Don’t forget the simple things: backup, patches, secure configuration, etc. Be aware, however, that baseline protection will not make your applications and your own code any more secure.
  5. Build security in
    If your Web site serves more than a set of static pages, you must build secure software. Security is not a box in your architecture diagram, it is a set of rules and best practices for software development.
  6. Test early and often
    Everybody makes mistakes, and so will you. Have somebody to point out those mistakes to you before the bad guys find and exploit them. Do not rely on automated scanners too much. They are useful but limited.
  7. Be hacker-friendly
    The best security testers you can get are white-hat hackers who happen to find issues on your site. Be accessible, properly credit those who helped you, and don’t sue the messenger. Don’t be too proud of not having been hacked, though.
  8. Don’t annoy your users
    The point of security measures is to make attacks hard. Their point is not to make legitimate use of the site hard. Putting unnecessary burdens upon your users will likely reduce your security—and the number of users.
  9. Plan ahead for failures and disasters
    They are out to get you and eventually they will. Know what to do if your security failed despite all your efforts. Have plans for incident handling, business continuity and disaster recovery.
  10. Compliance is just that
    Do not assume that compliance with whichever standard or regulation would be a replacement for actual security.

Homework assignment: pick one item and expand it into another list of 10.

How much security do we gain from Trusted Computing?

English, Forschung, IT, Security, Testlabor, Trusted Computing, , , , , , ,

My colleague Jan is going to present our paper Attacking the BitLocker Boot Process at Trust 2009 (Oxford, 6th – 8th April). The paper is an improved version of the draft we presented at ETISS.

BitLocker is the volume encryption function built into recent versions of MS Windows. It is capable of using a Trusted Platform Module if the PC has one. Our paper describes five attack scenarios that using the TPM does not prevent from succeeding. Some are based on particular features of BitLocker while others rely on the implementation of authenticated booting that is currently used in Trusted Computing.

All five scenarios seem suitable for targeted attacks and require that the attacker can access the target system twice. Executing such attacks is thus roughly as complex as installing a hardware keylogger in the system and returning later to retrieve the sniffed password along with the encrypted data – or just the machine in a condition that permits decrypting the data on disk.

What makes our attacks interesting is the fact that they can be implemented in software. Ideally, Trusted Computing should reliably prevent such attacks from succeeding. However, a TPM does not prevent software from being modified. The TPM only compares measured states with stored reference data. This leaves several holes. For instance one can temporarily modify software and later restore the reference state, or modify boot components before the reference state is determined and stored inside the TPM. While such actions are useless in an opportunisitc attack where the attacker just grabs an unattended machine unprepared, a dedicated attacker might take advantage of them.

Update 2009-12-03: There is a more comprehensive explanation in a later post.

Wahlcomputer und die behauptete Fälschung

IT, Nebenwirkung, Security, Vertrauen, Wahlcomputer, , ,

Kürzlich deutete ich in ein paar Nebensätzen die Möglichkeit an, Computerwahlen nicht tatsächlich zu fälschen, sondern eine Fälschung lediglich zu behaupten. Die Intransparenz wesentlicher Abläufe würde dafür sorgen, dass solche Anschuldigungen zwar nicht per se glaubwürdiger, aber schwerer zu widerlegen wären. Nun tut die CIA genau dies für einige der üblichen Verdächtigen, darunter zum Beispiel Venezuela. Kann ja sein, dass die Berichte alle korrekt sind, aber wenn ein Geheimdienst etwas verbreitet, weiß man nie so genau, was die Ziele sind und wieviel vom Gesagten wahr ist.

Security Annoyances

English, IT, Risiko, Security

[Get only posts in English]

Stuart King has blogged a list of his top 5 information security annoyances:

  1. Security awareness programs
  2. Compliance = security
  3. Risk modelling
  4. Where are all the analysts
  5. It’s not my fault

By and large I agree with his list, not least because he seems to have annoyed a few of those who are overconfident about risk trivia and business school quadrant diagrams.

I’d like to add to the list two of my own favorite annoyances:

  1. Just make it hard – for the legitimate users and uses of a system. Attempts to improve information security often make it harder for the users of a system, for the employees of an organization to do their legitimate jobs. Sometimes this is unavoidable, we all know there is often a tradeoff betwen usability and security. The tradeoff turns into a fallacy where the primary impact of security measures is reduced usability while actual security remains more or less the same.
  2. Alice’n’Bob thinking. Academic researchers might be particularly prone to this: thinking and arguing in the Alice’n’Bob world of security textbooks as if it was a suitable model of the real world and the real security issues. It isn’t, which we somethimes forget when we name abstract entities after humans.

Eine Runde TÜV-Bashing

Geschäft, IT, Risiko, Security, ,

Was der TÜV – eigentlich die TÜV, denn unter dieser Dachmarke macht sich ein etwas unübersichtliches Firmengeflecht breit – so alles zertifiziert, wissen aufmerksame Leserinnen dieses Blogs bereits. Die technische Seite habe ich damals nicht explizit diskutiert. Das nimmt mir jetzt ein anderer ab und schafft es bis in den Heise-Ticker mit dem Hinweis: TÜV-Siegel schützt nicht vor Cross Site Scripting. Damit haben wir schon zwei Dinge beisammen, vor denen ein TÜV-Siegel nicht schützt, ausnutzbare Fehler in der Technik und zweifelhafte Geschäftsmodelle. Geht da noch was?

Klar geht da noch was. Vor bekloppten Konzepten schützen TÜV-Siegel nämlich auch nicht. Bekloppte Konzepte, damit meine ich zum Beispiel die Idee, irgendeiner Wald-und-Wiesen-(bzw. Titten-und-Schwänze-)Website zur Altersverifikation ausgerechnet die PIN vom Online-Banking auszuhändigen. Darf’s vielleicht noch eine TAN-Liste sein? Sofortident nennt sich dieses Verfahren und dahinter steckt dieselbe Firma, die sich bereits die Sofortüberweisung nach ähnlichem Schema ausgedacht hat. Technisch gesehen geht die PIN nicht an die Titten-Website, sondern an Sofortident, aber der Sicherheitsgewinn dadurch ist marginal. Und wer pappt sein Siegel drauf? Einer von den TÜVs natürlich:

Sofortident mit TÜV-Siegel

Formal ist das sicher alles korrekt, der TÜV hat ja nur den Datenschutz (== die Einhaltung gesetzlicher Anforderungen an die Erhebung und Verarbeitung personenbezogener Daten) geprüft und mehr wird nicht behauptet. Das macht es aber noch lange nicht zu einer guten Idee, Leuten beim Pornogucken die Banking-PIN abzuknöpfen. Selbst wenn die Sofortler ihre Technik im Griff haben und sich an ihre Zusicherungen halten, wogegen es derzeit keinerlei Anhaltspunkte gibt, bleiben zwei Probleme. Erstens vermischt das Verfahren, ähnlich wie Giropay, Kontexte, die man besser getrennt hält. Online-Banking und Altersverifikation haben nichts miteinander zu tun und das Online-Banking ist hinreichend sensibel, um dabei zu bleiben.

Zweitens gewöhnt es den eifrigen Nutzer daran, seine Banking-PIN bei allen möglichen Gelegenheiten zu allen möglichen Zwecken einzusetzen. Das kann auch dann zum Problem werden, wenn aus ganz anderen Gründen ein Schaden eintritt, etwa wenn sich der Sofort*-Nutzer eine Schadsoftware einfängt und daraufhin Geld von seinem Konto verschwindet. Wenn die Bank dann erfährt, was ihr Kunde mit seiner PIN so alles getan hat, dürfte ihr Kulanz schwer fallen. Ein TÜV-Siegel macht dann auch keinen Eindruck.