computec.ch

Die perfekte Leistung - Unm�glich?

Marc Ruef - marc.ruef@computec.ch — Mo, 23 Jan 2012 01:12:00 GMT

Meine Eltern sind begeisterte Sportler, beides ausgezeichnete Tennisspieler. Nach einer l�ngeren Pause habe ich vor etwa 5 Jahren wieder mit dem Spiel angefangen, stehe seitdem jeweils 4 Mal pro Woche auf dem Platz. Tennis hat mein Leben in vielerlei Hinsicht - auch k�rperlich, psychisch und taktisch - enorm bereichert. Nur Knie- und R�ckenprobleme verhindern, dass ich noch mehr spielen w�rde.

Meine Mutter hat f�r die Schweiz mehrfach an der Weltmeisterschaft gespielt und mir also zig Jahrzehnte Spielerfahrung voraus. Als ich wieder seit langem ein Racquet in der Hand hielt, fragte ich sie, ob die Top 10-Spieler einen Match ohne einen eigenen Fehler durchspielen k�nnen. Sie verneinte dies, was mich erstaunte. Weder Federer noch Nadal - das damalige Spitzenduo - sollten dazu in der Lage sein? Ich dachte mir, dass ich ja bei der Arbeit den ganzen Tag konzentriert sein m�sse. Und da passieren mir auch nur sehr wenige Fehler.

Ich musste einige Tausend B�lle schlagen, bis ich verstand, warum meine �berlegung nicht auf den weissen Sport �bertragbar ist. Einerseits sollte es keinen zweimalig identischen Schlag geben. Zu viele Variablen sind involviert: Die eigene K�rperhaltung, die Anspassungen der Muskeln, die mentale Verfassung und die eingesetzten Winkel von Fussgelenk bis zur Schulter.

Zwar gibt es auch bei meiner Arbeit viele Eventualit�ten und Variablen. Doch ich habe den Vorteil, dass ich meistens nicht sofort eine Handlung vollziehen muss. Meistens kann ich dar�ber nachdenken, sie ausf�hren und �berpr�fen. Dadurch werden Korrekturen m�glich, die beim Tennis nach ausgef�hrtem Schlag schlichtweg nicht mehr nachzuholen sind.

Bei der t�glichen Arbeit wird es erforderlich, dass man diese M�glichkeiten des �berdenkens und Ausbesserns zu nutzen weiss. Denn dadurch kann Qualit�t gew�hrleistet und die eigenen Fehler kaschiert werden.

Sicherheits�berpr�fungen sind ein Werkzeug, um genau solche Korrekturen bei sicherheitskritischen Systemen angehen zu k�nnen. Zeitfenster f�r erfolgreiche Angriffe, die die eigene Fehlbarkeit vorzuf�hren in der Lage w�ren, k�nnen so minimiert werden.

Wer sich einer Analyse verweigert, diese behindert oder verf�lscht, der beraubt sich der M�glichkeit, eine verbesserte Qualit�t erlangen zu k�nnen. Meines Erachtens ist aber Qualit�t genau das, was eine Arbeit auszeichnen sollte. Ohne diese wird jedes Schaffen zur willk�rlichen und zuf�lligen Handlung, die dem Gl�ck unterworfen ist. In Krisensituationen sollte man sich aber nicht auf Gl�ck verlassen m�ssen.

Hacktivismus nicht zu Ende denken

Marc Ruef - marc.ruef@computec.ch — Mo, 09 Jan 2012 07:47:00 GMT

Dezember 2011 wurde mitunter vom sogenannten Stratfor Hack beherrscht. Dabei wurde das US-amerikanische Unternehmen Stratfor Opfer eines Einbruchs, bei dem Kreditkarteninformationen, Passw�rter, Telefonnummern und Mailadressen ihrer Kunden entwendet wurden. Einige dieser Daten wurden vermeintlich durch Anonymous bereitgestellt, wodurch sich f�r eine breite Mehrheit die M�glichkeit klassischen Kreditkartenmissbrauchs erschloss.

Einige vermeintliche Mitglieder von Anonymous haben Screenshots publiziert, in denen sie Spenden an Hilfswerke mittels der gestohlenen Kreditkarteninformationen initiierten. Dazu geh�rten bekannte Hilfswerke wie Rotes Kreuz, CARE, Save The Children und die African Child Foundation. Auf den ersten Blick eine Aktion, die aufgrund der fehlenden Eigenn�tzigkeit als nobel tituliert werden k�nnte.

Doch so einfach ist das alles nicht. Viele der gesch�digten Personen werden um eine R�ckzahlung bem�ht sein. F�r die Empf�nger, Kreditkartenfirmen, Finanzinstitute und Kunden wird ein Mehr an Aufwand entstehen. Vor allem die Hilfswerke werden keinen Vorteil aus dieser Aktion gewinnen, da sie sich mit den R�ckzahlungen herumschlagen m�ssen, anstelle von den vermeintlichen Spenden profitieren zu k�nnen.

Diese ganze Aktion zeigt einmal mehr, dass wenn Hacktivismus nicht zu Ende gedacht wird, ungewollter Schaden angerichtet werden kann. Vor allem wenn pers�nliche Daten missbraucht und digitale G�ter gekauft werden, sind Interventionen und zus�tzliche Kosten vorprogrammiert. Das Prinzip, das wir von Robin Hood her kennen, ist in einer digitalen Welt an zus�tzliche Gesetze gebunden. Denn rechtm�ssige Besitzer eines Goldst�cks lassen sich nur schwierig ermitteln - Der rechtm�ssige Besitzer einer digitalen Zahlung l�sst sich hingegen zweifelsfrei ausmachen.

Hacktivismus mag gut und Recht sein, wobei aber auch hier der Zweck niemals die Mittel heiligen darf. So ist es nach wie vor fragw�rdig, ob und inwiefern die Stratfor-Kunden mit ihren Kreditkarteninformationen - auch mit zus�tzlichen pers�nlichen Daten (z.B. Anschrift, Mailadresse) exponiert sein sollen. Eine Scheibe einzuschlagen, um zu beweisen, dass man sie kaputtmachen kann, das erscheint mir nach wie vor zu einfach.

2011: Was war? 2012: Was wird?

Marc Ruef - marc.ruef@computec.ch — Mo, 19 Dez 2011 09:10:00 GMT

Wie jedes Jahr m�chte ich eben dieses mit einem reflektierenden Blog-Eintrag abschliessen - �ber Vergangenes sinnieren und zu Zuk�nftigem tr�umen. Einen rein technischen Ausblick auf das Jahr 2012 werde ich diese Tage im scip Labs Blog ver�ffentlichen.

Vortr�ge

Wie auch schon das Jahr zuvor, sollte 2011 f�r mich ein Jahr der Konferenzen und Vortr�ge sein. Neben prestigetr�chtigen Events (Hashdays in Luzern und Symposium von BKA/LKA/Fedpol in Wiesbaden) war ich ebenfalls an kleineren und geschlossenen Veranstaltungen anzutreffen. Es macht mir nat�rlich immer Spass, neue und interessante Leute kennenzulernen. Dennoch ist es im gut gebuchten Arbeitsalltag nicht immer einfach, sich gen�gend Raum f�r die erforderlichen Vorbereitungen schaffen zu k�nnen. Ich nehme an, dass ich im kommenden Jahr nicht mehr so viele Auftritte auf mich nehmen k�nnen werde. Obschon ich selbst schon jetzt einige Zusagen getroffen habe ...

Fachbeitr�ge

Besonders viel Spass hat mir das Publizieren von Fachbeitr�gen im firmeninternen Blog bereitet. Beispielsweise die beiden Artikel zur systematischen Umsetzung von Firewall Rule Reviews und Config Reviews. Nebenher habe ich auch einige gr�ssere Artikel, wie zum Beispiel zum Thema Cloud Computing, in entsprechenden Fachzeitschriften publiziert. Diese Rhythmik versuche ich auch ins kommende Jahr zu tragen. Es liegen einige Entw�rfe vor, die f�r den einen oder anderen Leser durchaus von Interesse sein k�nnten.

Medienauftritte

Neben Vortr�gen und Fachpublikationen war ich dieses Jahr auch sehr stark in den Medien vertreten. Dazu geh�ren Expertenkommentare und Interviews in Zeitungen, Radio und Fernsehen. Das Jahr hatte fulminant angefangen, als wir im Januar bekannt geben konnten, dass wir das deutsche Kryptosystem X-pire! erfolgreich angreifen konnten. Der mediale H�hepunkt war aber sicher der Beitrag von Welt der Wunder, der unseren Arbeitsalltag portraitiert hat. Rund 1 Million Zuschauer haben die Sendung auf RTL2 gesehen und die Resonanz fiel sehr positiv aus. Informationssicherheit ist zweifelsfrei bei der breiten �ffentlichkeit angekommen.

Entwicklung

Entwicklungstechnisch habe ich meine Zeit in erster Linie in ein bis dato noch nicht bekannt gemachtes Projekt investiert. Es handelt sich um eine wirklich interessante Sache, die ich gerne ver�ffentlichen w�rde. Leider bin ich dabei von den Daten einer Organisation abh�ngig, die mir keine Lizenzierung erteilen m�chte. Sinngem�ss widergegeben, f�rchte man sich vor der Durchschlagskraft meines Projekts, die sich indirekt negativ f�r ihre Arbeit auswirken k�nne. Ich bedauere diese Einschr�nkung sehr und suche fieberhaft nach einer alternativen L�sung. Vielleicht wird mich 2012 in dieser Hinsicht mit mehr Gl�ck segnen.

Privates

Ansonsten habe ich sehr viel Tennis gespielt. Eine kleine Statistik zu meinem Tennisjahr habe ich auf Twitter - mittlerweile habe ich die Marke von 1'000 Follower geknackt - gepostet. Und dank Spotify habe ich eine Vielzahl neuer Interpreten, Alben und Songs gefunden. In meinem Privatleben hat sich auch viel Positives getan ... Ich kann mich deshalb so gar nicht beklagen. In diesem Sinne bedanke ich mich bei all meinen Weggef�hrten f�r die sch�ne Zeit und hoffe, dass uns die Zukunft weiterhin viel Positives bringen wird - Denn auch im n�chsten Jahr wird mein Motto lauten: "Erarbeite Dir M�glichkeiten und nutze sie!"

Whitehate

Marc Ruef - marc.ruef@computec.ch — Mo, 28 Nov 2011 10:04:00 GMT

F�r Aussenstehende klingt der Begriff "Whitehate" nach einer rassistischen Tendenz. Tats�chlich handelt es sich hier um einen alten Ausdruck, der von Kriminellen im "Untergrund" genutzt wird, um ihren Unmut �ber professionelle Sicherheitsexperten zum Ausdruck zu bringen. Die Blackhat-Hacker zeigen damit ihren Hass gegen�ber den Whitehat-Hackern.

Ich habe mich nie als Blackhat verstanden, denn f�r mich stand beim Thema Informationssicherheit stets der wissenschaftliche und soziale Aspekt im Mittelpunkt. Es ist unvermeidbar, dass wir uns heutzutage in einer Informationsgesellschaft wiederfinden und Informationssicherheit deshalb zu einem zentralen Aspekt des Zusammenlebens geworden ist. Ethische und moralische Tugenden sollen deshalb auch auf virtueller Ebene verteidigt werden.

Aus diesem Grund habe ich sehr fr�h davon abgesehen, mit einem Pseudonym aufzutreten. Stattdessen habe ich von Beginn weg Artikel unter meinem echten Namen publiziert. Ich wollte damit die Grundlage schaffen, um irgendwann professionell im Bereich der Informationssicherheit arbeiten zu k�nnen. Im Jahr 2000 habe ich das dann auch geschafft, als ich beim deutschen Unternehmen Biodata Information Technology AG als IT Security Expert anfangen konnte.

Schon damals wurde ich in diversen Foren als Verr�ter dargestellt, der sich f�r Geld prostituiert. Zudem sei mein Wissen mangelhafter Natur und damit sowieso bewiesen, dass sogenannte "professionelle Computersicherheit" nichts taugt. Ich kann diese Argumentation bis heute nicht nachvollziehen. Ich verdiene schliesslich mein Geld lieber mit etwas, das mir Spass macht. Zudem haben wir uns bei scip AG mittlerweile einen derart guten Namen geschaffen, dass wir durchaus auch mal "uninteressante" Auftr�ge ablehnen k�nnen. Prostitution w�rde ich das also nicht nennen.

Als viel schwerwiegender verstehe ich hingegen das offensichtlich zur Schau getragene Unwissen, wie Informationssicherheit beschaffen ist. Viele Kiddies denken, dass Coding und Exploiting die Hauptpfeiler dieses Themengebiets sind. Tats�chlich ist es bedeutend vielschichtiger und komplexer. Wer nur auf diesen beiden Gebieten bewandert ist, wird in unserer Firma noch nicht einmal zu einem Vorstellungsgespr�ch eingeladen.

Unsere Kunden erwarten, dass wir s�mtliche Aspekte der Informationssicherheit verstehen k�nnen. Dazu geh�rt beispielsweise auch das in technischen Kreisen gerne vernachl�ssigte Thema Risikomanagement. Bevor man �ber Exploits und Patches spricht, sollte man �ber Bedrohungen und Risiken reden. Denn das Hauptziel ist stets das Eliminieren von Risiken.

Ein gutes Beispiel, warum ein Blackhat nicht einfach die Arbeit eines Whitehat machen kann, findet sich im Bereich der Backdoor Tests. Durch das Entwickeln einer kundenspezifischen Malware soll ein m�glichst realistischer Angriff durchgespielt werden. Durch diesen wird es m�glich, s�mtliche Facetten der etablierten Sicherheitsmassnahmen betrachten zu k�nnen.

Ein Blackhat wird in den meisten F�llen eine Malware programmieren, um seiner Experimentierfreudigkeit und Kreativit�t freien Lauf zu lassen. Ob und inwiefern etwas bei der Ausf�hrung mal nicht reibungslos funktioniert, ist eher zweitrangig, sofern es �berhaupt funktioniert. Bei einer professionellen Sicherheits�berpr�fung sind jedoch ganz andere Anforderungen gegeben.

Hier geht es darum, ein Maximum an Zuverl�ssigkeit, Nachvollziehbarkeit und Transparenz zu erreichen. Die Entwicklungs-Phase ist in den meisten F�llen schnell abgeschlossen (�blicherweise 2-3 Manntage). �berproportional viel Aufwand wird hingegen in das Testing gesteckt (im Extremfall bis zu 30 Manntagen). Schliesslich wird man mit der Malware eine produktive Umgebung infiltrieren und dabei darf ja nichts schief gehen. Zudem muss zu jedem Zeitpunkt klar ausgewiesen werden k�nnen, welche Systeme infiziert sind und wie weit die Infizierung fortgeschritten ist. Im Notfall muss unverz�glich eine Desinfektion stattfinden k�nnen. Fremd-Infektionen von Systemen anderer Firmen sind dabei genauso zu verhindern, wie ein Verlust der Kommunikationsm�glichkeit mit dem C&C-Server. Diese Funktionalit�ten einzubringen erfordert zus�tzlichen Aufwand.

Erweiterte Anforderungen dieser Art gibt es bei allen Projekten, egal ob es sich nun um Backdooring, Exploiting oder Auditing handelt. In der Gesch�ftswelt in produktiver Weise und mit Verl�sslichkeit zu agieren, ist bedeutend schwieriger, als sich die meisten Hobby-Hacker vorstellen. Denn da gibt es immer jemanden, bei dem man sich f�r seine Fehler rechtfertigen muss. Und im schlimmsten Fall hat dies gar finanzielle oder juristische Auswirkungen. Denn wer �bernimmt die Kosten, wenn die Malware keine eigenst�ndige Desinfektion mehr umsetzen kann und stattdessen auf 120'000 Rechnern in verschiedenen L�ndern eine manuelle S�uberung stattzufinden hat?

Die Zeiten �ndern sich wohl nie und so habe ich gerade vor einigen Wochen eine Foren-Diskussion mitgekriegt, in der meine Arbeit mit "Whitehate" abgespiesen wurde. Schade, dass die Schreiberlinge sich nicht die M�he gemacht haben, meinen gesamten Artikel zu lesen. Weil dann h�tten sie ihre Fehlbarkeit bemerken m�ssen. Es zeugt nicht gerade von Professionalit�t der selbsternannten "Blackhats", wenn sie sich nicht einmal die M�he machen, die einfachen Fakten zu pr�fen. So jemanden w�rde ich ebenfalls nie zu einem Vorstellungsgespr�ch einladen wollen.

Meine erste Denial of Service-Attacke

Marc Ruef - marc.ruef@computec.ch — Mo, 14 Nov 2011 08:58:00 GMT

Als leichter Einstieg in das Thema Computersicherheit gelten gemeinhin Denial of Service-Attacken. Bei einer DoS wird sich darum bem�ht, die Funktionsweise oder Erreichbarkeit einer Komponente einzuschr�nken. Typischerweise geschieht dies mit einer �berlastung der bereitgestellten Ressourcen. Zum Beispiel, indem eine Internet-Anbindung durch eine Vielzahl an Anfragen geflutet werden. Dieses Prinzip wird auch mit "David gegen Goliath" bezeichnet.

Die Primitivit�t dieser Angriffstechnik macht sie auch f�r Einsteiger erschwinglich. Diese Eigenschaft und die Destruktivit�t solcher Zugriffe f�hren dazu, dass die meisten Sicherheitsexperten eine starke Abneigung gegen solche Attacken und Angreifer mit entsprechend destruktiver Natur haben. Ich bin da keine Ausnahme. Und dennoch habe ich auch schon DoS-Angriffe durchgef�hrt - Von einem speziellen Fall m�chte ich nun erz�hlen.

Und zwar war ich bekanntermassen ein schlechter Sch�ler. Die Motivation, mich mit vorgekauten L�sungen f�r "an den Haaren herbeigezogenen Prolemen" auseinanderzusetzen, war eher gering. Und so war dann entsprechend auch meine schulische Leistung, die unweigerlich an schlechte Noten gebunden war. Es war sodann keine Ausnahme, dass die Lehrer bei meinen Eltern vorstellig wurden und sich �ber das Nichtvorhandensein meiner Arbeitsmoral emp�rten.

Dies war stets - aber nicht nur - jeweils vor Abgabe der Zeugnisse der Fall. Bevor uns Sch�lern diese nach Hause gegeben wurden, haben die Lehrer das Gespr�ch mit den Eltern gesucht. Der Termin f�r ein Telefonat war vorg�ngig angek�ndigt (nur das Datum, nicht die Uhrzeit). Ein solcher Dialog wollte ich in meiner kindlichen Naivit�t verhindern, ohne mir wirklich eingestehen zu wollen, dass ich damit das Unausweichliche eigentlich nur hinausz�gern k�nnen w�rde.

Mein Ansatz bestand darin, dass ich die Telefonleitung des Hauses kappte. Keine sonderlich komplexe Sache, musste ich doch lediglich die Verdrahtung entfernen. Mein dubioses Ziel des Verhinderns eines Telefonats konnte ich zwar so durchsetzen. Doch fr�her oder sp�ter sollten meine Eltern dahinter kommen, was ich da getan hatte. Es wurde sodann zur Methode, dass sie regelm�ssig die Erreichbarkeit des Anschlusses pr�ften. Entweder warteten sie auf das Freizeichen am Ger�t oder bem�hten sich um eine Leitungskontrolle mit einem externen Anruf.

Erstaunlicherweise waren mir meine Eltern nicht b�se, dass ich mich um das Verhindern der Kommunikation bem�ht hatte. Vielleicht aber auch nur deswegen, weil sie sich viel mehr ab meiner schlechten schulischen Leistunegn ge�rgert haben. Wie dem auch sei, musste ich mich diesem Problem nur bis zum 18ten Lebensjahr annehmen. Denn ab da war ich als vollj�hriger Sch�ler nicht mehr dazu verpflichtet, meine Zeugnisse den Eltern vorzulegen. Stattdessen konnte ich sie nun selber unterschreiben ... Meine Motivation und die daran gebundene schulische Leistung blieben leider unabh�ngig davon aber �ber die Jahre gleich.

Missverstandene Authentisierungsmechanismen

Marc Ruef - marc.ruef@computec.ch — Mo, 31 Okt 2011 11:00:00 GMT

Im Juli dieses Jahres hatte ich Gelegenheit, am Davis Cup in Bern beizuwohnen. Im Rahmen des Tennis-Ereignisses standen sich die beiden L�nder Portugal und Schweiz gegen�ber. Eine spannende Sache, die ganz im Kontrast zu meinem Besuch in Wimbledon wenige Wochen zuvor stand. In erstgenanntem herrscht eine Stimmung, wie man sie von Fussballspielen her kennt. in letztgenannten ist hingegen Ruhe und Disziplin, auch und vor allem von den Zuschauern, verlangt.

Im Rahmen meines Aufenthalts in Bern weilte ich in einem Hotel. Beim Checkin wurde mir ein handgeschriebenes Zettelchen gegeben, auf welchem meine Zimmernummer vermerkt war. Mir wurde aufgetragen, dass ich beim Verlangen des Zimmerschl�ssels stets diesen Zettel vorzuweisen habe. Die Herausgabe des Schl�ssels sei nur mit diesem m�glich und selbst das Vorweisen eines amtlich beglaubigten Ausweises w�rde das nicht ersetzen k�nnen.

Ich musste schmunzeln, denn hier wurde ich gerade Zeuge eines klassischen Fehlers, wie ein solider Authentisierungsmechanismus durch einen propriet�ren und anf�lligen Prozess ersetzt wurde. Eine Authentisierung hat zum Ziel, dass sich der Benutzer m�glichst eindeutig identifizieren und damit beglaubigen lassen kann. Dies wird erreicht, indem m�glichst schwer zu f�lschende oder vorzut�uschende Berechtigungsnachweise (engl. credentials) eingesetzt werden.

Quizfrage - Was ist einfacher zu f�lschen: Ein amtlich beglaubigter Ausweis (z.B. Pass, F�hrerschein) oder ein handgeschriebener Zettel?

Ich konnte mir dieses prozesstechnische Missverst�ndnis nur so erkl�ren. Und zwar pflegt das Hotel nur zwei Nachtportiers einzusetzen. Diese kennen wohl die Schrift und den Schreibstil des jeweilig anderen. Das F�lschen eines Zettels wird damit schwierig. Hingegen kann ein Ausweis gestohlen und ein �hnliches Passbild als das eigene Abbild vorgehalten werden.

Dieses Konzept klingt nicht mal so schlecht. Dennoch zeigt es im Endeffekt auf, welche Auswirkungen die Ignoranz bei der Auswahl propriet�rer Mittel haben kann. Denn ist ein Angreifer halbwegs geschickt, kann er den Zettel mit kalkulierbarem Aufwand f�lschen. Dies gel�nge ihm beim Pass hingegen nicht. Und zudem kann auch ein Zettel gestohlen werden. Aufgrund der fehlenden Identifikationsmerkmale wird es f�r den Portier - besonders bei einer hohen Anzahl unterschiedlicher G�ste - nahezu unm�glich, eine klare Identifikation vorzunehmen. Ich kann also nur zum Schluss kommen, dass hier ein klassisches Prinzip grundlegend verschlimmbessert wurde.

Welches Level von Sicherheit kann man erwarten?

Marc Ruef - marc.ruef@computec.ch — Mo, 17 Okt 2011 07:56:00 GMT

Ohne jetzt unabsichtlich altklug wirken zu wollen, jedoch die Zeiten �ndern sich. Im Bereich der Computersicherheit wage ich zu behaupten, dass in Zyklen von 5 Jahren mit neuen Technologien und anderer Wahrnehmung dieser gearbeitet wird. Zu Meilensteinen geh�ren bisweilen die Diskussion des Puffer�berlauf (1996), der Durchbruch von Google und breitfl�chige Wahrnehmung von Virtualisierung im professionellen Umfeld (2000), Durchsetzung von Voice-over-IP (2004), explosionsartiger Wachstum von Social Media und Cloud Computing (2009).

R�ckblickend erscheinen viele Trends und Hypes als offensichtlich, ja manchmal gar zwingend erforderlich. Doch wie sagt man so sch�n: Im Nachhinein ist man immer kl�ger. Dieser Satz ist k�rzlich in einem technischen Gespr�ch zu den Resultaten eines von mir geleiteten Penetration Tests gefallen. Die Besprechung fokussierte sich auf die Problematik gefundener Cross Site scripting-Schwachstellen, die eine ernstzunehmende Gefahr f�r die sicherheitskritische Applikation darstellen sollte. Der Projektleiter auf der Kundenseite sagte, dass er am liebsten schon im Jahr 2006, als die Entwicklung der Applikation begonnen hat, mit der Thematik vertraut gewesen w�re - Aber auch damals w�re ihm das Verst�ndnis f�r die Risiken zu weit in der Zukunft gelegen.

Obschon ich sehr gut nachvollziehen kann, warum eine Person mit wenig technischem Hintergrund zu einer solchen Aussage neigt, kann und will ich sie nicht gutheissen. Cross Site scripting ist beim besten Willen kein neues Problem. Zur Jahrtausendwende wurde es langsam breitfl�chig als Sicherheitsrisiko wahrgenommen und hat mit stetiger Steigung im Jahr 2006 den H�hepunkt seiner Popularit�t erreicht. Ich hingegen habe aber schon im Jahr 1997 diese Angriffstechnik, also noch Jahre bevor sie �berhaupt einen allgemein g�ltigen Namen erhalten sollte, zu meinem Vorteil ausgenutzt. Und das ist mittlerweile schon �ber 15 Jahre her!

Ist es deshalb nicht mittlerweile sehr dreist, diesen Angriffsvektor bei der Entwicklung und dem Betrieb einer L�sung zu vernachl�ssigen - Und stattdessen zu behaupten, dass es sich um eine exotische oder neuartige M�glichkeit handelt, die man deshalb vernachl�ssigen musste? Solche Aussagen h�ren wir n�mlich immerwieder und ich muss gestehen, dass meine Reaktion stets von Irritation bis Aggression reichen. Denn oftmals spielen die schuldigen Personen den Vorteil aus, dass ihre Kunden weniger �ber technische Hintergr�nde wissen und deshalb in diesem Punkt nachsichtig sind. Das empfinde ich gleich als doppelte Dreistigkeit.

F�r mich ist es offensichtlich, dass man von einer modernen L�sung, die im professionellen Rahmen f�r viel Geld entwickelt wurde, ein Mindestmass an Sicherheit erwarten kann. Dazu geh�rt eine durchdachte und zentralisierte Eingabe�berpr�fung, die einen Grossteil bekannter Angriffstechniken abzuwehren in der Lage ist. Und der Einsatz bew�hrter Mechanismen - wie zum Beispiel Authentisierung- und Verschl�sselungs-Methoden -, die zur betrieblichen Absicherung w�hrend der Nutzung beitragen. Werden solche Mindeststandards nicht eingehalten, f�llt die L�sung meines Erachtens durch die grundlegende Qualit�tspr�fung durch. Leider m�ssen wir auch heute noch viel zu vielen Produkten ein "ungen�gend" oder "mangelhaft" ausstellen.

News mit vollumf�nglichem RSS Feed

Marc Ruef - marc.ruef@computec.ch — So, 09 Okt 2011 08:49:00 GMT

Ich selber bin seit langem darum bem�ht, das Lesen von News, Blog-Posts, Artikeln und News m�glichst effizient zu gestalten. RSS-Feeds spielen dabei eine zentrale Rolle, da sich durch sie viele Vorteile erschliessen lassen. Einerseits k�nnen diese von vielen Ger�ten, gerade auch portable L�sungen wie dem Mobiltelefon oder Tablet, gelesen werden. Zudem erlauben viele L�sungen, wie zum Beispiel Google Reader, ein synchronisieren der schon gelesenen Artikel.

RSS-Feeds sind aber nur dann wirklich sinnvoll, wenn der volle Text eines Posts in eben diesem gelesen werden kann. Aus diesem Grund habe ich mich darum bem�ht, auch auf computec.ch per sofort diese Funktionalit�t zu unterst�tzen. Vielen Dank an @_juame, der explizit darum gebeten hat.

An dieser Stelle m�chte ich gerne darauf hinweisen, dass ich auch auf Twitter sehr aktiv bin und dort News und Artikel zum Thema Informationssicherheit verteile. Ebenso erscheint in der Regel einmal w�chentlich ein technischer Artikel aus meiner Feder in den scip Labs, die ebenfalls �ber umfangreiche Feeds verf�gen. Diese werden mitunter auch auf dem Feed meiner privaten Webseite zusammengefasst. In diesem Sinne w�nsche ich viel Spass beim Lesen!

Sinnlose Vergleichbarkeit

Marc Ruef - marc.ruef@computec.ch — Mo, 03 Okt 2011 09:13:00 GMT

Lieber Leser, versuchen Sie ohne gross nachzudenken die folgende Frage zu beantworten: "Was ist sicherer, Windows oder Linux?" Und, was haben Sie gesagt? Konnten Sie sich "spontan" festlegen? Falls ja, dann eine weitere Frage, die dem gleichen modus operandi unterworfen werden soll: "Was ist besser, Mercedes oder BMW?" Konnten Sie auch diese beantworten? Falls ja, dann sind Sie an Entscheidungsfreudigkeit wohl kaum zu �berbieten. Das mag okay sein, wenn man als US-amerikanischer Pr�sident mal eben nebenbei ein unterentwickeltes Land im nahen Osten einnehmen will. Weitsichtigkeit und Differenziertheit gestalten sich aber anders - Tut mir leid!

Sicherheit ist ein weit gedehnter Begriff. Sicher gegen�ber was? Sicher gegen�ber wem? Sicher in welcher Situation? Sicher f�r wie lange? Auch Fort Knox kann unsicher betrieben werden, wenn ungeschultes Personal f�r die Absicherung des Gel�ndes zust�ndig ist. Genauso verh�lt es sich bei Computersystemen, die im Betrieb gewartet werden wollen. Ein ungeschulter Administrator wird jedes System in unsicherer Weise betreiben k�nnen. Und ein unbedarfter Benutzer wird fr�her oder sp�ter zu einer kompromittierenden Handlung getrieben werden.

Keine Angst, denn vielleicht wollte ich ja nur wissen, welches System "von Haus aus" sicherer ist. Da kann man statistische Mittel zuhilfe nehmen, um anhand von Codequalit�t und ver�ffentlichten Patches R�ckschl�sse auf die Sicherheit eines Systems zu ziehen. Also nochmal: "Was ist sicherer: Windows, Linux oder MacOS X?" Konnten Sie sich noch immer entscheiden? Falls ja, dann sind sie entweder ein Savant mit der g�ttlichen Gabe der statistischen Hochrechnung in Rekordzeit. Oder Sie wohnen in Texas und behaupten auch in ihren Memoiren, dass s�mtliche Ihrer vorschnellen Entscheidungen richtig waren.

Nehmen wir als statistischen Hilfswert die Anzahl der Advisories, die zu einem Produkt erschienen sind. Ist eine hohe Anzahl in negativer Weise bez�glich der Sicherheit des Produktes auszulegen? Schliesslich gibt es eine Vielzahl an Fehlern. Oder ist es vielleicht nicht positiv anzusehen, dass sich a) viele Leute mit dem Produkt auseinandersetzen und b) durch das Aufdecken von Fehlern eben diese beseitigen lassen. Haben Sie schon mal vom Betriebssystem QNX geh�rt oder gar ein Advisory dazu gesehen? Nein? Ist dieses System nun extrem sicher?

Auf meinem iPad speichere und lektoriere ich meine Blog-Beitr�ge. Sollte das Ger�t kompromittiert und diese fr�hzeitig ver�ffentlicht werden, erachte ich den Schaden als sehr gering. Das Ger�t ist in diesem Fall sicher genug, um meinen Anforderungen gerecht werden zu k�nnen. Ich betrachte es jedoch nicht als sicher genug, um die Launch-Codes f�r atomare Raketen zu verwalten. Ist das iPad nun sicher oder nicht? Sicherheit ist ein Bed�rfniss, das im Kontext der individuellen Anforderungen betrachtet werden muss.

Das Darlegen einer subjektiven Vergleichbarkeit von Betriebssystemen und Software-L�sungen ist unsinnig. Eine Aussage, dass PCs nun sicherer sind als Macs ist in etwa genauso sinnvoll und solid, wie wenn ich behaupten w�rde, dass das Messer das bessere Esswerkzeug ist als der L�ffel. Ich will mal jemanden sehen, der mit einem Messer eine Bouillonsuppe isst. Genauso m�chte ich sehen, wie jemand einen sicheren Webserver mit Windows NT 4.0 zu betreiben in der Lage ist (Ja, ich habe das tats�chlich schon gesehen!). Manche Dinge sind mit dem falschen Werkzeug nur sehr schwierig umzusetzen - Und manche Dinge sind effektiv einfach nur noch unm�glich.

Schlechte Sicherheitsmassnahmen

Marc Ruef - marc.ruef@computec.ch — Mo, 19 Sep 2011 07:46:00 GMT

Ich befasse mich nun seit vielen Jahren mit dem Thema Informationssicherheit. Leute, die darum wissen, pflegen stets zu sagen: "Eine aufwendige Sache, da st�ndig auf dem neuesten Stand zu bleiben." Doch ich entgegne jeweils mit einem lapidaren: "Nein, nicht wirklich. Denn die Grundprinzipien sind seit Tausenden von Jahren fortw�hrend gleich geblieben." Jedes Mal merke ich, wie es in den K�pfen der Leute zu arbeiten beginnt, sie aber schnell einsehen, dass meine Antwort nicht unwahr schien.

Informationssicherheit ist ein komplexes Thema, das man meines Erachtens eigentlich der klassischen Philosophie anh�ngen m�sste. Denn auch in diesem Fachbereich gibt es eine Vielzahl an Diskussionen, die einen Diskurs verlangen und je nach Weltsicht in einem Disput enden k�nnen. Die Entscheidungen innerhalb der Informationssicherheit sind genauso philosophisch, wie die Frage nach dem Sinn des Lebens, der Existenz der Seele oder dem Vorhandensein von Gerechtigkeit.

Aus eben diesem Grund wird Informationssicherheit von vielen Laien g�nzlichlich falsch verstanden. Durch das Mischen von Halbwahrheiten und Binsenweisheiten werden Postulationen aufgestellt und Konstrukte verteidigt, die jedem Spezialisten die Haare zu berge stehen lassen. Dies m�chte ich an einem erlebten Beispiel illustrieren.

Nach dem Tsunami in Japan und der daraus drohenden atomaren Katastrophe um Fukushima ging ich im Rahmen einer milit�rischen �bung ein Kernkraftwerk in der Schweiz besuchen. Es sollte uns der Aufbau und die Funktionsweise, die Sicherheit und Risiken eben dieser Anlage vorgef�hrt werden. Im stark abgesicherten Kommandoraum fanden sich 5 Leute, die f�r die zentrale Steuerung der Anlage zust�ndig waren.

Die Dame, welche uns durch die R�umlichkeiten f�hrte, erkl�rte uns, dass aus Sicherheitsgr�nden stets f�nf Leute anwesend sein m�ssen. Es schien mir klar, dass Redundanzen ein wichtiges Element der Risikominimierung sein w�rden. Als sie gefragt wurde, ob und inwiefern eine Notabschaltung initiiert werden kann, entgegnete sie: "Eine solche ist nur dann m�glich, wenn zwei der f�nf Personen zeitgleich einen Schl�ssel drehen. Diese sind 15 Meter voneinander positioniert, so dass nicht einer alleine diese Massnahme ergreifen kann." Sie f�gte an, dass dies aus Sicherheitsgr�nden so gehandhabt sei.

Die Stabsoffiziere meiner Gruppe erfreuten sich ob dieser Sicherheitsmassnahme. Ich hingegen empfand mich selbst als f�r dumm verkauft. Denn diese vermeintliche "Sicherheitsmassnahme" bem�ht sich nicht um die Sicherheit der potentiellen Explosions- und Strahlenopfer. Viel mehr ist sie angelegt worden, um die monet�ren Interessen der Anlagebetreiber wahren zu k�nnen! Denn das versehentliche oder fr�hzeitige Abschalten der Anlage hat f�r die Bev�lkerung nur sicherheitstechnische Vorteile, tr�gt diese aber immer als finanzielle Nachteile der Betreiber aus (eine Anlage kann dann erst wieder nach mehreren Wochen in Betrieb genommen werden).

Es schien also, als ob meine Mith�rer suggestiv zur Annahme verleitet wurden, als ob die "Sicherheitsmassnahmen" in ihrem Interesse getroffen wurden. Keiner von ihnen stellte die Aussage - deren Kern der "Erh�hung der Sicherheit" auch stimmte - in Frage. Und so zeigt es sich, dass Sicherheitsmassnahmen und Risikoanalysen nicht in die H�nde von Laien geh�ren. Und im Fall von Atomkraftwerken ebenso nicht in die H�nde von Personen, die sich mehr um Geld als um Menschenleben scheren.