Meine Bürogenossin muss monatlich eine große Menge PDFs ausdrucken, die anderweitig erzeugt wurden. Diese manuell über Adobe Reader, FoxitReader, etc zu öffnen und dann zu drücken ist umständlich. Alleine das eigentliche drucken Drucken dauert mehrerer 10 Sekunden pro PDF. (Windows Printer ist langsam für Farbdrucker). Außerdem soll immer nur die erste Seite gedruckt werden.

Eine Lösung für Windows ist gar nicht so einfach zu finden. die meisten Tipps laufen darauf hinaus, dann doch den PDF-Reader mit dem Ausdrucken zu beauftragen. Egal ob per VB-Script, Com-Schnittstelle, print()-Funktion, etc. Aber genau das möchte ich ja vermeiden! Ich möchte eine Stapelverarbeitung, bei der am Ende nur evtl. aufgetreten Fehler gemeldet werden.

Nach einigem Suchen bin ich auch zwei Lösungen gestoßen und habe einen eigene programmiert (mich dann aber doch für eine der anderen entschieden):

a) GSBatchPrint hat ein paar nette Feature, z.B. kann einen Input-Ordner überwachen oder Output-Schacht angeben. Aber es verschiebt Dateien in Ordner, wobei nicht ganz immer klar ist, wo diese Ordner angelegt werden. Kostenlos, aber Source ist nicht verfügbar.

b) Mein Versuch, GSBatchPrint neu zu programmieren (natürlich in Python) ist prinzipiell gelungen. Nicht gelungen ist mir, dabei anzugeben, welche Seiten ausgedruckt werden sollen — es soll ja nur die erste Seite sein. Habe aber viel über mswinpr2 gelernt. Als Nebenprodukt ist ein Python-Interface für Ghostscript entstanden, über das ich letzte Woche berichtet habe.

c) GSPrint brachte die Lösung. Kann alles Wichtige, was meine Büroenossin braucht. Ich hätte es gleich nehmen sollen. Habe noch einen kleinen Wrapper herum gestrickt (ein droplet aka Batch-Skript), um die restliche Funktionen zu ergänzen und die gewünschten Parameter an GSPrint zu übergeben.

BTW: Unter Linux (und Unix generell) braucht man das alles nicht. lp dateiname genügt. Wenn das Drucksystem CUPS installiert ist (das ist inzwischen Standard), kann man auch allerlei Druckoptionen auswählen. Beispielswiese eben die erste und die letzte zu druckende Seite.

Für ein kleines Progrämmchen möchte ich die Ghostscript-Bibliothek (.dll bzw. .so) verwenden. Es ist mir nicht ganz einsichtig, weshalb man dafür immer Ghostscript als eigenen Prozess startet und den Output umständlich aus einer Pipe liest.

Daher habe ich ein kleines Python-Package geschrieben, das Ghostscript direkt über die C-API anspricht. Es verwendet ctypes, daher muss nichts kompiliert werden, und ist plattformunabhängig (ebenfalls durhc ctypes möglich). Lizenz: GPL v3. Das mercurial-Repository findet sich auf bitbucket.

Mit dabei sind auch ein paar kleine Beispielprogramme, die unter anderem gs und ps2pdf nachbilden. Dafür sind faszinierend wenige Zeilen nötig.

Wir halten unsere Benutzer an, für jede Anwendung ein anderes Kennwort zu verwenden. Das soll mindestens acht Zeichen lang sein, Groß- und Kleinbuchstaben, Sonderzeichen und Zahlen enthalten – wobei acht Zeichen inzwischen schon fast zu kurz sind. Die Realität sieht allerdings anders aus: Aus Bequemlichkeit verwenden die Nutzer immer wieder das gleiche Passwort, im besten Fallen noch Variationen davon: Susi, SusiSusi1, SusiSchmussi42, SusiSchatzi99 und so weiter. Und zugegeben, unsere Security-Zunft versäumt es zu häufig, den Menschen geeignete Tools zur Verfügung zu stellen.

Was also tun, damit Ihre Mitarbeiter mit sicheren Passwörtern arbeiten und Ihre Firmensicherheit nicht aufs Spiel setzen? Eine praxistaugliche und schlaue Lösung sind sogenannte Passwort-Safes. Damit können die Nutzer für jede beliebige Anwendung, gleichgültig ob im Web oder xxx, ganz einfach auf Kopfdruck sichere Passwörter erzeugen und inklusive URL, Benutzername, Kommentar etc. übersichtlich in Gruppen verwalten.

Auf Wunsch generieren die Passwort-Safes kryptische Passwörter beliebiger Länge und aus wählbarem Zeichenvorrat. Die Bedienung ist super-einfach und bewährt sich auch im täglichen Leben: Anwendung starten, Passwort-Safe-Kennwort eingeben, Benutzername in die Zwischenablage kopieren, zur Anwendung wechseln, Benutzername einfügen. Das Gleiche für das Passwort wiederholen. Fertig. Wer mit Tastenkürzeln arbeitet, braucht dafür gerade mal acht Tastendrücke. Dass Passwort wird dabei gleich wieder aus der Zwischenablagen entfernt, damit es niemand auslesen kann.

Wenn Sie sich für ein Open-Source-Tool entscheiden, können sie es auch an Ihre Bedürfnisse anpassen. Beispielsweise die Passwort-Vorgaben festlegen oder die Anwendung an das Corporate Design Ihres Konzerns anpassen – das kommt bei den Benutzern gut an.

Mein Favorit für Passwort-Safes ist die „Keepass“-Familie. Neben dem Original (nur für Windows) gibt es Umsetzungen für Linux und Mac („KeepassX“) sowie PDAs. Sie sind alle gleich zu bedienen und verwenden das gleiche Dateiformat. Die neuere Version 2 lässt sich auch mit Plugins erweitern. Allerdings ist diese Version in der proprietären und mit Patenten bewaffneten Programmiersprache C# geschrieben...

Bei der Auswahl von Passwort-Safe-Programmen sollten Sie allerdings genau prüfen, für was Sie sich entscheiden: Einige Tools kann man guten Gewissens als „unnütz“ abstempeln: Beispielsweise der „Thinkvantage Password Manager“ von Lenovo. Dessen Safe lässt sich bequem mit dem Fingerabdruck-Scanner des Thinkpad-Notebooks öffnen. Dummerweise können darin auch nur Passwörter gespeichert werden, wenn das Tool einen dazu auffordert – und das tut es nur, wenn es die Anwendung kennt. Kennwörter für selbst entwickelte Anwendungen bleiben damit ebenso außen vor wie die für Archive und PDFs.

Noch eine Bitte: Sorgen Sie als IT-Verantwortlicher dafür, dass das Tool wirklich auf allen PCs und Notebooks standardmäßig installiert ist. Sonst geht es auch anderen so wie mir: Nach einem Rechnerwechsel stand ich ohne Passwort-Tool da. Die nächsten drei Wochen lief ich zwangsläufig ich mit einem Zettel herum, auf dem meine wichtigsten Passwörter standen. So soll es nicht sein!

Manch einer beginnt auf diese Weise gar Passwörter zu lieben: Meiner Bürogenossin habe ich auch einen Safe verpasst. Seither hat sie sich von ihrem Standardpasswort „Girls“ verabschiedet und erzeugt mit Begeisterung für jedes Webportal ein neues sicheres Kennwort. Und ich freue mich, dass ich meine Mission als Security-Beauftragter unserer Bürogemeinschaft erfüllt habe.

In loser Folge blogge ich über unsinnige Kennzahlen, neudeutsch Key Performance Indicators (PKIs). Folge 1: Anzahl der gefundenen Viren

Gerade in meinem Metier ist es schwer, den "Erfolg" von IT-Security-Maßnahmen zu messen. Auf einigen Treffen der Fachgruppe Security Management der GI war dies bereits Thema. Ein sinnvolles, rundes Kennzahlensystem für IT-Security hat leider noch niemand dort vorgestellt. Dafür kam beim letzten Workshop eine neue unsinnige Kennzahl hoch: Es gibt allen Ernstes Unternehmen, die die Anzahl der gefundenen Viren messen. Viel gleich gut.

Aber was sagt die Zahl denn aus? Ist es besser, wenn die Zahl niedrig ist, oder wenn sie hoch ist?

Meines Erachtens sagt diese Zahl leider gar nichts aus. Beziehungsweise nur, wieviele Viren die Virenscanner gefunden haben. Leider sagt sie nichts aus, wieviele Viren nicht gefunden wurden, oder wieviele Viren erst gefunden wurden, nachdem sie Schaden angerichtet haben.

Auch als Vergleichszahl ist sie unbrauchbar: Ist der neue Virenscanner besser als der alte, oder sind einfach mehr Viren im Umlauf? Hat sich die Erkennungsrate des Virenscanners verbessert (wobei in "Rate" ja selbst schon ein Verhältnis steckt), oder sind unsere Mitarbeiter nur öfters in gefährlichen Ecken unterwegs? Werden bei uns weniger Viren erkannt, als im Branchenschnitt (wobei es eine solche Angabe wohl nie geben wird), oder sind die Anderen lediglich mehr Wirtschaftsspionage ausgesetzt?

Wirklich interessant wäre die Kennzahl: "Anzahl nicht (oder zu spät) gefundener Viren". Aber die unbekannten kann ich nicht messen. Schade!

Sind Sie anderer Meinung? Oder haben Sie Ideen für gute Kennzahlen in der IT-Security? Ich freue mich auf Ihren Kommentar oder Ihre Mail (siehe Kontakt) und diskutiere gerne darüber.

„Wenn Du in Berlin bist, musst Du unbedingt ins Restaurant 'Zur vollen Molle' gehen, das ist hervorragend und günstig“, legte mir ein Kollege ans Herz, der bestimmt seit zehn Jahren nicht mehr in der Bundeshauptstadt gewesen war. Es stimmte dann insoweit, dass es dort noch immer günstig war. Das servierte Menü verursachte mir jedoch heftigstes Bauchweh.

PDF hat sich die letzten Jahre als eines der wichtigsten Dokumenten-Formate durchgesetzt und wurde als ISO-Standard geadelt. Mit Recht und zum Glück, denn damit verschwanden die komplizierten doc-Dateien von den Internet-Sites und komfortable PDF-Dateien traten an ihre Stelle.

Damit auch jeder Website-Besucher die PDFs lesen kann, geben viele Unternehmen eine Empfehlung, wo der geschätzte Kunde ein PDF-Anzeigeprogramm erhalten kann und oft auch gleich den Link dazu liefern: „Hier kann man den ´Adobe Acrobat Reader´ kostenlos herunterladen. Denn „PDF-Reader“ ist bei den meisten gleich „Acrobat Reader“. Besonders Gründliche belassen es nicht bei der Empfehlung, sondern „verordnen“ das Produkt der Firma Adobe – wie etwa der Kulturverein Unterhaching, dessen Website-Besucher den Acrobat Reader „benötigen“, um ihre PDFs zu lesen oder auch der Provider Schnell im Netz.

Das ist soweit okay. Bauchschmerzen verursacht es jedoch, dass in beiden Fällen den Kunden die veraltete und gefährliche Version 7 von Acrobat zum Download an die Hand gegeben wird – direkt als Download von der eigenen Website, nicht etwa verlinkt auf den Hersteller. Und da fällt mir wieder mein Kollege mit seinem Berliner Restaurant-Tipp ein: Wissen die Besitzer dieser Websites überhaupt, was sie da empfehlen, oder riskiert der Besucher der Website bei Befolgen des gutgemeinten Tipps empfindliches Bauchweh?

Der Adobe Reader lieferte sich in den letzten eineinhalb Jahren mit Microsoft einen rasanten Wettlauf um die meisten Schwachstellen. Die Exploits dazu trudeln im Monats-Rhythmus ein, alte Versionen des Adobe Acrobat Readers sind deshalb reiner Zündstoff für die IT-Sicherheit. Dazu ist der Reader ein fettes, unhandliches Monstrum geworden, mit vielen Plugins und Schnickschnack, den die meisten Leute nicht benötigen.

Dazu frage ich mich oft, weshalb Unternehmen so unbedenklich und freiwillig Marketing für andere machen, ohne irgendetwas dafür zu kriegen. Denn jeder dieser Links ist Marketing-Geld, das sich Adobe spart. Bei manchem, wie etwa der IHK Nürnberg, verkehrt sich die freiwillige Marketing-Hilfe sogar zum Eigentor: Denn Adobe Deutschland sitzt in München, Nürnberg gilt als das „Linux Valley“, in dem ebenfalls flotte, kostenlose PDF-Reader entwickelt werden. Statt also die Entwickler der eigenen Region mit Werbung in Form von Empfehlungs-Links zu unterstützen, hilft die IHK Nürnberg mit ihre Empfehlung für Acrobat Reader lieber dem Mitbewerb in München.

Gefährliche Monokulturen als Brückenkopf für Angriffe

Dieses kostenlose Empfehlungsmarketing hat aber auch für Adobe selbst eine unerfreuliche Kehrseite: Die Klientel seiner großteils unerfahrenen Privatnutzern setzt PDF gleich mit Adobe Reader und schafft damit eine gefährliche Monokultur. Wie Tausende Hektar Maisfelder für den Schädling Maiszünsler ein wahres Paradies sind, wird die Software-Monokultur „Adobe Acrobat Reader“ mit seinen vielen Schwachstellen von Angreifern als Ziel hoch geschätzt. Schließlich ist Windows deshalb das mit Abstand beliebteste Ziel für Programmierer von Schadsoftware, weil es auf über 90 Prozent aller PCs installiert ist und damit eine große Reichweite hat. Mit der Empfehlung von Acrobat schaffen Unternehmen bei ihren Kunden selbst die Brückenköpfe, von denen aus die Schadsoftware-Programmierer zuschlagen können – und sei es „nur“ als Spam oder Phishing-Aktion.

Diskussionsbedarf? Mailen Sie einfach an kolumne@goebel-consult.de

Google Analytics ist hip, modern, einfach und wahnsinnig nützlich. Ein paar Zeilen JavaScript in die Website eingebaut und ab sofort erhalten Sie jede Menge bunter Statistiken und viele viele viele Daten und sachdienliche Hinweise über Ihre Besucher. Denn jeder, der auf Ihre Webseite kommt, darf sich dank Ihres emsigen Analyse-Tools Google Analytics über ein lustiges Sortiment von Cookies freuen, die Google dann sammelt und Ihnen als Statistik zur Verfügung stellt. Deshalb ist Google Analytics das mit Abstand meist-verwendete Werkzeug für die Webanalyse.

Ich möchte jetzt niemand den Spaß verderben, aber Hand aufs Herz: Was nutzen Ihnen eigentlich die Daten, die sie über Google Analytics erfahren? Und sind diese Daten den Preis wert, dass Sie Ihre Kunden dafür mit Haut und Haaren an den professionellen Datensammler Google ausliefern?

Da habe ich nicht schlecht gestaunt: Die (ISC)² schickt mir einen Auszeichnung und ernennt mich zum "CSSLP Evangelist". Weil ich den Mut besessen habe, in ein neues Zertifikat zu investieren.

Bei einem neuen Zertifikat besteht ja immer die Gefahr, dass es keine kritische Masse erreicht, oder dass es nicht anerkannt wird. Und der Aufwand für ein CSSLP-Zertifikat ist nicht gering. Als CISSP wurde dafür lediglich "erlassen", erneut einen Bürgen zu finden.

Die Auszeichnungsmedaille (siehe Bild) ist irgendwie typisch amerikanisch, liegt wertig in der Hand und schmückt nun meinen Schreibtisch.

Mutig sind die Marktforscher. Die Cloud als ultimative Lösung – für alles, was IT heißt:

• wenn IT zu teuer ist,

• wenn IT zu aufwändig und zu personalintensiv ist,

• wenn IT skalieren muss.

Alles Argumente, die die man durchaus gelten lassen kann. Und die auch – mehr oder weniger – belegbar oder zumindest logisch scheinen, auch wenn man keine Kristallkugel besitzt.

Zwar sind auch diese Analysten so realistisch, Blockaden der Cloud zu erkennen: Die noch fehlenden Abrechnungsmodelle, das knappe Angebot, fehlende SLAs und eine noch schwierige rechtliche Situation, vor allem bei Anbietern aus USA.

Doch sie übersehen scheinbar völlig den Aspekt Sicherheit. Dabei ist doch die Cloud, der öffentliche Raum des Internet, in dem sich plötzlich alles abspielen soll, der Alptraum aller Sicherheitsspezialisten. Vielleicht haben wir als Security-Spezialisten aber auch nur einen zu engen Horizont. Ich wundere mich jedenfalls, wieso dieser Aspekt so wenig Gewicht hat.

Dabei lassen sich eine Latte von Risiken aufzählen, die mindestens so lang ist, wie alle genannten Vorteile. Hier ein paar Beispiele:

• Sie wissen nie, mit wem sich Ihre virtuelle Maschine den Host teilt. Und ob dieser andere nicht aus seiner virtuellen Maschine auf den Host ausbricht und Ihre Maschine kompromittiert. In einer komplett öffentlichen Cloud wären Sie dann nur das Zufallsopfer – wie heute beim Phishing. Aber ich sehe schon die ersten Angreifer, die gezielt Kunden bei großen Anbietern werden, um in deren „privaten Cloud“ zu angeln.

• Ein Sicherheitskonzept mit mehreren Klassen lässt sich in der Cloud nur schwer realisieren – und quasi gar nicht überprüfen. Vielleicht gelingt es Ihnen, per Cloud-Vertrag auszuschließen, dass virtuelle Maschinen unterschiedlicher Sicherheitsklassen auf dem gleichen Host laufen. Aber wie wollen Sie das jemals überprüfen? Die Revisionsabteilung wird sich freuen!

• Dienste wie E-Mail in die Cloud zu verlagern ist auch keine gute Idee. Hier droht massiver Vertrauensschaden, wenn die Kunden das mitbekommen. Oder wollen Sie bei einem Konzern versichert sein, deren Mails bei Google-Mail liegen?

In einigen Bereichen hat die Cloud bestimmt ihre Berechtigung. Aber aus Security-Sicht wird sie nicht die Rolle der eierlegenden Wollmilchsau spielen – spielen können, die ihr die Analysten voraussagen. Es sei denn die Security-Industrie wartet ebenfalls mit einer „ultimativen Cloud-Security-Lösung“ auf, die alle Probleme verschwinden lässt.

„Session Fixation“-Angriffe funktionieren so: Ein Angreifer startet eine Verbindung mit dem Webserver und erhält damit eine Session-ID. Diese schiebt er (beispielsweise per XSS) einem Opfer zu, das sich auf dem Webserver authentifiziert. Die Session des Angreifers ist nun authentifiziert, der Angreifer kann mit den Rechten des Opfers auf das System zugreifen. Elegant.

Und ebenso elegant zu vermeiden: Die Authentifizierungsroutine erstellt für die authentifizierte Session eine neue Session-ID und verwirft die bisherige Session. Um genau dieses nicht ständig neu programmieren zu müssen, verwenden Entwickler Frameworks.

Bisher wiegten ich die Nutzer von bewährten Java-Frameworks in Sicherheit. Auf eine Programmierumgebung, die täglich eingesetzt wird von Hunderten erfahrenen Kollegen, sollte ja Verlass sein und sie sollte keine gefährlichen Hintertürchen öffnen. Ganz anders als bei den risikofreudigen PHP-Kollegen, die jede Funktion immer wieder neu erfinden.

Doch ein Artikel in der iX bereitete nun einer trügerischen Sicherheit ein Ende: Session Fixation ist mitnichten ein reines PHP-Problem. Einige der beliebtesten Java-Servlet-Container sind anfällig für diese Schwachstelle. Schockiert vernimmt der Programmierer die Namen bekannter Java-Frameworks wie Tomcat, JBoss und JOnAS. Und bei richtiger Interpretation der CWE-Liste (Common Weakness Enumeration) implementieren wohl auch ASP (Active Server Pages) und .net von Microsoft die Anmeldung falsch.

Eine Blamage für die Java-Gilde. Immerhin war diese Schwachstelle bereits 2004, also vor sechs Jahren, in den OWASP Top Ten erwähnt, wie sie zu beheben ist ebenso. Die CWE-Liste beschreibt Problem und auch Lösung in klaren Worten: „Invalidate any existing session identifiers prior to authorizing a new user session“. So einfach könnte es sein.

Die entscheidende Frage ist: Wie kann es geschehen, dass wichtige Komponenten, die tagtäglich zum Einsatz kommen, solch gravierende Fehler aufweisen? Die für mich naheliegendste Erklärung wäre, dass wahrscheinlich ehemalige PHP-Programmierer die Java-Frameworks entwickelt haben. Doch das wäre nicht fair. Gleichgültig wer die Entwickler der Framework-Bausteine sind: Sie sollten sich bewusst machen, dass es nicht nur darum geht, neue Features einzubauen, sondern dass die Ergebnisse auch sicher sind.

Übrigens: Ob Ihr Framework den Fehler enthält, können sie beispielsweise mit dem Firefox Add-On Live HTTP Headers oder etwas einfacher mit CookieSafe prüfen. Wenn die ID im Session-Cookie nach der Anmeldung die gleiche ist wie vorher, dann ist Ihre Anwendung anfällig. Gegenmaßnahmen für die Java-Frameworks beschreibt besagter Artikel.

Als Nebenprodukt der verteilten Massenscans mit OpenVAS habe ich ein Python-Interface für das OpenVAS Management Protocol (OMP) und das OpenVAS Administration Protocol (OAP) implementiert. Die beiden Pakete openvas.omp und openvas.oap sind unter der GPL 3.0 veröffentlicht und im Python Package Index zu finden. Dort finden sich auch weitere Informationen

Python Entwickler installieren die Pakete am einfachsten mit

easy_install openvas.omp openvas.oap

bzw.

pip openvas.omp openvas.oap