Schlagwort-Archive: Test

Production-safe Testing

[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.

Plattenverschlüsselung: viermal mangelhaft

Delivering bad news since 2004:

Meine Kollegen aus dem Testlabor IT-Sicherheit haben sich wieder einmal mit Verschlüsselungssoftware beschäftigt. Diesmal im Auftrag der Zeitschrift Computerbild, in deren aktuelles Heft die Ergebnisse eingeflossen sind. Ausgabe 20/2008 berichtet ab Seite 70 über den Test, zu dem unser Institut die Sicherheitsuntersuchung und -bewertung beigetragen hat.

Vier von acht untersuchten Programmen sind durchgefallen. Ich gratuliere. Den Kollegen, nicht den Programmen. Wir haben so etwas vor drei Jahren schon einmal gemacht, damals waren es nur zwei. Eines davon ist jetzt allerdings wieder auf einem der hinteren Plätze gelandet. So einfach ist das eben nicht mit der Sicherheit.

ClearSwift, das war wohl nix (oder Ihr seid Spielverderber)

Vor einer Woche hatte mich eine Werbemail der Firma ClearSwift zu diesem Ad-hoc-Test inspiriert. Versprochen war Data Loss bzw. Data Leak Protection und ich wollte wissen, ob der Anbieter schnell merkt, dass jemand über ihn bloggt. Erbeten war eine schnelle Reaktion hier im Blog oder auf anderem Wege. Einen festen Termin gab es nicht, aber eine Woche sollte wohl genügen. Reaktionen gab es keine. Das könnte verschiedene Gründe haben:

  1. Ich habe das Konzept der angebotenen Lösung nicht verstanden und der ganze Kram hilft gar nicht gegen Blogger, die unerlaubt über die Firma bloggen. Dann stellte sich allerdings die Frage, warum Blogs und Web 2.0 in der Werbung vorkommen.
  2. Vielleicht hilft die Lösung tatsächlich gegen unerlaubte Firmenblogger, aber nur unter bestimmten Randbedingungen. Sie könnte zum Beispiel erfordern, dass der Blogger aus dem Firmennetz bloggt oder dass Geheimnisse erst registriert werden müssen, damit die Sicherheitstechnik sie entdecken kann. In diesem Fall wäre der Nutzen zweifelhaft, wie diese kleine Demonstration zeigt.
  3. Oder wir haben es mit Spielverderbern zu tun: sie haben uns gesehen, aber absichtlich nicht reagiert. Das gäbe ein Sehr Gut für die Methodik der Krisen-PR – aber leider ein Ungenügend für Nachdenken, denn in diesem Fall wäre eine Reaktion richtig gewesen.

Zum Mitspielen hätte man übrigens überhaupt keine Sicherheitslösung gebraucht, weil es ja Google gibt und Google gern Benachrichtigungen zu beliebigen Anfragen verschickt. Jeder, der auch nur eine Spur von Eitelkeit zu seinem Wesen zählt, hat einen Google Alert auf seinen Namen bestellt. Tja.

Mal schnell getestet: Data L{oss|eak} Prevention von Clearswift

Aus meiner SpamInbox:

»Stellen Sie sich vor, Ihre Finanzabteilung versendet versehentlich vertrauliche Business-Pläne an einen externen Emailverteiler, ein verärgerter Mitarbeiter verrät im Online-Chat Firmengeheimnisse oder ein anderer verschickt im Namen Ihres Unternehmens unseriöse Emails an Ihre Kunden.«

Tja, was mache ich denn dann? Die Mail, aus der dieses Zitat stammt, empfiehlt mir, mich rechtzeitig über die Produkte und Dienstleistungen der schreibenden Firma zu informieren. Ich würde ja einfach die Finanzabteilung feuern, wenn sie sich das so redlich verdient; verärgerten Mitarbeitern rechtzeitig genügend Angst machen; und die unseriösen E-Mails selber verschicken, um sie später dementieren zu können und so zweimal billig Aufmerksamkeit zu bekommen. Statt dessen soll ich mich also über MIMEsweeper informieren und darüber, was man im Web 2.0 damit so alles verhindern kann.

Da ich solche Probleme nicht habe und meine Hauptbeschäftigung darin besteht, die Sicherheit von allem möglichen zu testen und zu bewerten, tue ich genau das: testen. Mal schnell getestet: Data L{oss|eak} Prevention von Clearswift weiterlesen