| M | D | M | D | F | S | S |
|---|---|---|---|---|---|---|
| « Aug | ||||||
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 | |||||
Was für eine Überraschung … ISACA hat festgestellt, dass viele Mitarbeiter in den Unternehmen die Policies und Regelungen zur IT-Sicherheit schlicht ignorieren.
Bin ich jetzt der einzige, den das nicht überrascht? Ich muss vielleicht doch mal einen größeren Abschnitt zu Awareness hier einstellen
Das SANS Institute hat den Monat Oktober zum Cyber Security Awareness Monat ausgerufen und zu diversen Themen ein paar Artikel veröffentlicht:
Nicht alle lohnen sich zu lesen, aber #11 finde ich z.B. spannend.
SIPVicious hat ein paar coole Tools zum VoIP-Hacken veröffentlicht:
und ein PDF „How to get the job done„.
(via Security4All)
Die European Expert Group for IT Security (EICAR) hat eine Stellungnahme zum StGB § 202c (PDF) veröffentlicht, nach der Sicherheitsexperten weiterhin Hacking-Tools und Exploits einsetzen dürfen. Voraussetzung sei, dass die Tätigkeit ausreichend dokumentiert wird.
Klingt doch super. Stellt sich nur die Frage … wer oder was sind Sicherheitsexperten? Bin ich einer? Ist mein Azubi einer? Noch nicht? Darf er die Tools dann (noch) nicht verwenden? Wie will er dann damit umgehen lernen?
Ich zitiere dazu Ludwig Thoma (aus der Kurzgeschichte „Der Vertrag“ über den königlichen Landgerichtsrat Alois Eschenberger):
und das zugehörige Urteil vom LAG Baden-Württemberg, AZ 9 Ta 2/07. Dann vielleicht doch lieber frei nach Obelix:
🙂
Eine URL zum merken: Grundsicherung für PHP-Software bei Heise
die wichtigst Keys:
Ich bin jetzt etwas beruhigt, auf dieser PHP-Installation sind die alle so gesetzt.
Nach langer Zeit mal wieder eine kleine Buchempfehlung:
Das Buch erklärt, welche Fehler in Software existieren, wie man diese Fehler vermeidet und wie man sie findet. Es ist in folgende Kapitel geglieder:
Auf der Taossa-Webseite findet man Ergänzungen und Errata zum Buch.
Und wenn man sich sowieso schon damit beschäftigt … Secure Programming for Linux von David Wheeler. Seine Dokumentation gehört zum Linux Documentation Project und ist deshalb komplett kostenlos aber wirklich nicht umsonst!
Und nein, ich verlinke nicht zu Amazon. Geht gefälligst zu Eurem Buchhändler um die Ecke, der freut sich wenn er auch mal ein Buch verkauft denn ansonsten gibt es irgendwann keine Buchhändler mehr.
RSA SecurID Token, diese komischen kleinen Teile mit dem 6-Ziffern-Display auf dem alle 60 Sekunden ein neues Passwort erscheint sind, obwohl teuer, immer noch erste Wahl wenn es um die Authentisierung von Remote Access Usern geht.
Ich gebe ja zu, wir verkaufen selbst RSA und gerade auch als Administrator sind die Teile sehr einfach und schnell eingerichtet und funktionieren einfach. Leider kostet ein Token so ca. 50 Euro und alle drei Jahre darf man ein neues kaufen.
Seit einiger Zeit versuche Anbieter von sogenannten Authentication Grids jedoch, mit extrem günstigen Preisen in den Markt der Authentisierungstoken einzudringen. Zu den Anbietern gehören beispielsweise Masabi aber auch Entrust mit IdentityGuard. Eine IdentityGuard Grid-Karte sieht so aus:
Der Anwender wird dann wie bei Schiffe versenken nach D4, A3 und H5 gefragt und antwortet dann mit „440“. Die Nummer gilt als Einmalpasswort, wenn diese Kombination nur einmal verwendet wird.
Ich sehe dabei zwei grundsätzliche Probleme:
RSA Token haben den Vorteil, dass das Hardware-Token nicht kopiert werden kann. Wenn es weg ist bemerken das die Anwender meist recht schnell. Außerdem ändert sich (zeitsynchronisiert, nicht eventsynchronisiert) alle 60 Sekunden das Passwort, man kann es also gefahrlos herzeigen. Ich persönlich halte die Grid-Token ja weiterhin für eine Spielerei. In etwa einer Stunde kann man sowas z.B. für eine Webserver-Authentisierung auch selbst programmieren. Aber die Karten sind halt extrem günstig (so ab 1 Euro pro Stück) und auf die Rückseite kann man sogar noch Werbung drucken.
Lassen wir also Masabi in seiner Illusion, RSA ersetzen zu können.
Ich hatte ja vorgestern die Frage gestellt, ob bzw. ab wann man inoffizielle Patches einspielen kann. Natürlich fliegt mir das Thema heute schon um die Ohren, weil der Patch offensichtlich grottenschlecht ist.
Aber die Frage bleibt im Raum stehen: In welcher Situation würde man so einen inoffiziellen Patch einspielen? Was sagt das Risikomanagement dazu?
Das Microsoft ist-gar-kein-Microsoft-Problem-ach-doch-jetzt-hat-es-auch-Outlook-erwischt-aber-wir-tun-trotzdem-nichts Problem mit der Ausführung unsicheren Codes über URIs hat jetzt dazu geführt, dass mal wieder ein Programmierer einen inoffiziellen Patch bereitgestellt hat.
Das wirft die interessante Frage auf: Einspielen oder nicht?
Klar, im allgemeinen ist die Antwort immer: natürlich nicht. Aber rein theoretisch, wie groß muss die Gefahr sein und wie lange die Verweigerungshaltung von Microsoft ein von ihnen verursachtes Problem auch zuzugeben, bevor die Bereitschaft vorhanden ist, so einen Patch einzuspielen?
Natürlich wäre es besser, den Entwicklern ihren Code um die Ohren zu schlagen bist der Fehler behoben ist, aber wenn die nichts tun hat man halt verloren. Meinen Open Source kann ich notfalls auch selbst patchen und den Linux-Kernel neu kompilieren. Bei Closed Source sieht das leider anders aus.
Also … wie seht Ihr das?
Mit Viren und Schadprogrammen kann man bekanntlich richtig viel Spaß haben.
Dazu gehört beispielsweise der Download gängiger Construction Kits bei VX Heavens, die man dann gegen ein nicht besonders geschütztes System laufen lassen kann. Spezielle aktuelle Schadprogramme lassen sich oft bei Offensive Computing herunterladen und natürlich gibt es auch noch den üblichen Schadprogramme-Spam. Zum ausprobieren und rumspielen bietet sich ein virtuelles System in VM-Ware an, da kann man am wenigsten kaputt machen.
Bei dieser Gelegenheit kam die Frage auf, was einen guten Virus auszeichnet und wir haben uns da ein paar Gedanken gemacht:
Alles weitere in der Mitternachtshacking-Präsentation Spaß mit Viren (PDF, 960 KB)