Wenn man sich einmal anschaut, was an wie vielen Stellen in Sachen Security immer wieder schiefgeht, könnte man sich fast schon fragen: Sind wir eigentlich zu dumm für IT-Sicherheit? Zumindest zeigen sich an etlichen Stellen über den gesamten Lebenszyklus von IT-Lösungen erhebliche Know-how-Defizite – und zwar auch in Organisationen, bei denen man das eigentlich nicht erwarten würde. Umso stärker trifft es Unternehmen, die (noch) weniger Know-how zu IT und IT-Sicherheit besitzen.
Verschiedenste – anonymisierte – Beispiele und Überlegungen aus der Praxis sollen im Folgenden zeigen, wo es überall hapert. Nur wenn man um die Defizite weiß, kann man ja mittelfristig für entsprechende Fortbildung oder Abhilfe sorgen und gegebenenfalls kurzfristig nach Workarounds Ausschau halten – langfristig sind ohnehin „größere“ Lösungen gefragt.
Kulturelle Defizite
Denn letztlich scheinen wir heute noch ein gesamtgesellschaftliches Problem mit der IT-Sicherheit zu haben: zu wenig Ausbildung, zu wenig Bewusstsein, zu wenig Stellenwert et cetera. Ein Mitarbeiter der Inneren Sicherheit, der leider ungenannt bleiben muss, forderte einmal in kleiner Runde, dass wir uns als Kultur damit auseinandersetzen müssten, welche Abbildung gesellschaftlich etablierte Schutzmechanismen der traditionellen Welt in der IT-Sicherheit finden könnten und sollten.
Doch auch dazu braucht es Know-how an allen möglichen Stellen. Denn ein adäquater Schutz entsteht ja erst durch die Robustheit eingesetzter, passender Verfahren – und schon, um das richtige Schutzniveau und die benötigte Robustheit richtig einschätzen zu können, braucht es gute Kenntnisse.
In der „analogen“ Welt glaubt sich jeder hierzulande gut geschützt – Deutschland gilt als sehr sicher, was ein positiver Aspekt für den Standort ist. Zweifelsohne wäre es ein Wettbewerbsvorteil, wenn Deutschland und in der Folge auch Europa die Sicherheit in der digitalen Welt ebenfalls als attraktiven Standortfaktor besetzen könnten.
Doch wie soll das gehen, wenn es „überall“ an Know-how um die IT-Sicherheit fehlt? Dieser Mangel ist an sich bekannt und an vielen Stellen bemerkbar (s. u.) – aktuelle Zahlen gehen davon aus, dass nur rund 1 % der Beschäftigten in der Informations- und Telekommunikationstechnik (ITK) Spezialwissen in IT-Sicherheit besitzen. IT-Sicherheit ist überall notwendig, passendes Know-how aber längst nicht überall vorhanden.
Wissens-Defizite
Bevor man auf die gesellschaftliche Breite abzielt, sollte man den Blick zunächst auf die „Avantgarde“ richten – auf Unternehmen und Organisationen, die bereits in Sachen Sicherheit aktiv sind, wo Einsicht und Wille vorliegen und auch schon gehandelt wird. Und selbst bei dieser Gruppe und ihren Partnern, die doch eigentlich als Vorbild dienen müssten, findet man noch mehr als genug Defizite. Denn auch dort, bei sicherheitssensitiven KMU und auch vielen größeren Organisationen, sind jede Menge Stakeholder daran beteiligt, die IT wirklich sicherer zu machen – oder bei diesem Versuch ins Stolpern zu geraten oder gar zu scheitern.
Dabei gilt es, den gesamten Lebenszyklus und die gesamte Handlungskette von der Bedarfsermittlung über Ausschreibung, Herstellung, Marketing, Vertrieb, Kauf, Installation und Betrieb zu betrachten. Entlang eben dieser Handlungskette soll im Folgenden anhand realer Beispiele aus jüngerer Zeit aufgezeigt werden, wo Akteure spezifisches Know-how benötigen, das in den beschriebenen Fällen eben nicht verfügbar war oder aus anderen Gründen nicht „zum Tragen kam“.
Zusammenstellen der Anforderungen
Beispiele für „Scheitern auf hohem Niveau“ fi ndet man bisweilen bereits in den Anforderungen für neue Lösungen. So wird für moderne IT-Systeme – auch getrieben durch die ISO-27000er-Normen – die Klassifi kation von Daten gefordert. Das Ziel dieser Klassifi kation oder des „Labelings“ ist es, eine bestimmte Information (dauerhaft) mit einem Sicherheitsmerkmal wie „fi rmenvertraulich – Nur für den Dienstgebrauch“ oder „vertraulich“ zu verbinden.
Viele Lösungen auf dem Markt binden Klassifi kationsinformationen jedoch in den so genannten „Alternate Data Stream“ (ADS) ein – eine Art Attribut einer Datei, den das zugrunde liegende Dateisystem (z. B. NTFS) als Standard kennt. Diese Eigenschaft einer Datei geht jedoch bei der Übertragung per E-Mail oder auf bestimmte andere Dateisysteme (z. B. auf USB-Sticks), die ADS nicht unterstützen, einfach verloren.
In Anforderungslisten zur Klassifi kation von Daten fi ndet sich dennoch das „sichere, nachhaltige und dauerhafte Koppeln der Klassifi kationsinformation“ nur selten, auch wenn die Klassifi kation später als Sicherheitsmerkmal verwendet werden soll. Auf konkrete Nachfrage erfährt man dann meist, dass dieser Zusammenhang entweder unbekannt war oder dass man eine ohnehin komplexe Projektierung nicht noch schwieriger gestalten wollte.
Solche Antworten zeugen von Know-how-Defi zit, das in der frühen Phase der Anforderungen eventuell bereits durch eine Marktsichtung hätte behoben werden können – wenn es denn Vorlagen gäbe, was aus einem bloßen Labeling eine echte Sicherheitsfunktion macht, die man später auch als Grundlage für DLP-Projekte einsetzen kann.
Lieferketten von IT-Sicherheitsprodukten
Viele IT-Sicherheitsprodukte greifen auf weit verbreitete De-facto-Standards zurück und integrieren diese – etwa bei SSL und TLS. Mit Heartbleed gab es plötzlich einen Angriff, der auf eine Schwachstelle in einer gängigen SSL-Implementierung aufgesetzt hat. Diese war häufi g auch in Drittprodukten enthalten, ohne dass dies den Endkunden bekannt war. Zum großen Teil wird auch gar nicht erst danach gefragt, welche Technik real in einem angebotenen Produkt „verbaut“ ist.
Spätestens Heartbleed hat aber gezeigt, dass es sinnvoll sein kann, zu wissen, in welchem System welche Open Source oder welche Bibliothek von Dritten (z. B. als OEM) enthalten ist: Ein Grund, schneller handeln zu können, wenn neue Angriffe auf diese Elemente bekannt werden. Ein weiterer Grund ist, bereits beim Kauf besser einschätzen zu können, auf was man sich einlässt. Dieser Punkt ist mehrdimensional, denn sowohl die rechtlichen Abhängigkeiten, Fragen der Haftung als auch technische wie juristische Hintertüren können die eigene Einschätzung der „digitalen Souveränität“ des Käufers beeinfl ussen.
Insofern sollte man sich zugekaufte oder mitgenutzte Komponenten in einem Produkt per Herstellererklärung aufl isten und den Lieferanten für die Korrektheit dieser Eigenerklärung Haftung übernehmen lassen – dabei ist die Offenlegung der gesamten Lieferkette bedeutsam. Neben dem grundlegenden Know-how um die positiven Auswirkungen solcher Transparenz in der Lieferkette fehlt es häufi g auch am Bewusstsein zu entsprechenden K.-o.- Kriterien für den Einsatz bestimmter Lösungen.
Die Fähigkeit, Informationen zur Lieferkette aller eingesetzten Produkte im Sinne einer Gesamtsicherheit im Unternahmen zu managen, erfordert weiteres Knowhow, das ebenfalls selten ist. Erst wenn eine fl ächige Aufmerksamkeit entsteht und die haftungsunterlegte Angabe der vollständigen Lieferkette in großen Beschaffungen berücksichtigt würde, könnte dieser Punkt jedoch zum gelebten Standard werden – und so auch (mit einfachen Kriterien unterlegt) eine Entscheidungshilfe darstellen. Eine von neutraler Stelle kommentierte Vorlage für einen „Lieferketten-Fragenkatalog“ würde helfen, derartiges Know-how zu bündeln.
Ausgestaltung von Ausschreibungen
Eine Ausschreibung für eine Verschlüsselungslösung, die der Autor gesehen hat, umfasste weit über einhundert funktionale und ergonomische Kriterien, die eine potenzielle Lösung zur Verschlüsselung von Dateien erbringen musste; insgesamt ließen sich 1000 Punkte erreichen. Eine Frage lautete: „Kann das kryptografische System umgangen oder gebrochen werden?“ – die möglichen Ergebnisse: „mit einfachen Mitteln“ = 0 Punkte und „nicht möglich“ = 10 Punkte (also 1 % der erreichbaren Gesamtpunktzahl für die Vergabe). So hätte also ein Produkt, das zu umgehen oder zu brechen ist, im Prinzip 990 von 1000 Punkten erzielen und die Ausschreibung gewinnen können – ein Produkt, das Geld und Aufwand sicher nicht wert gewesen wäre.
Ausschreibungen müssen offensichtlich anders aussehen, wenn sie die Sicherheit verbessern sollen: Zuerst hätte man einen unteren Schwellenwert der Robustheit defi nieren müssen – und nur Produkte, die diesen Wert nachweislich überschreiten, dürfte man später anhand von Standardkriterien (z. B. Funktionalität, Preis usw.) vergleichen.
Bei der Robustheit von Verschlüsselungsverfahren ist aber auch zu berücksichtigen, dass es nicht nur um die Kryptografi e geht – gute Zufallszahlen, Schlüsselgenerierung, -verwaltung und -lagerung, ein starker Algorithmus et cetera sind nicht alles. Vielmehr geht es auch um die Einbettung in das Zielsystem: Denn wenn beispielsweise in einer transparenten Verschlüsselungslösung jeder laufende Prozess (auch „remote“) die Entschlüsselung anfordern kann, dann ist zwar möglicherweise das Kryptosystem in sich robust, aber das Gesamtsystem hat dennoch keinen oder nur geringen Schutz (vgl. [1]).
Ein großes Problem stellt hier bereits die Defi nition des unteren Schwellenwertes für die Robustheit des Gesamtverfahrens dar, denn es gibt dazu keine Maßeinheit oder Metrik. Hier ist vielfältiges Know-how nötig, das nur sehr spärlich in der ITK anzutreffen ist. Hilfreich wäre es, wenn Organisationen mit höherem Schutzbedarf ihre Ergebnisse zur Robustheit von Produkten und ihre Erfahrungen bei deren Betrieb detailliert beschreiben und veröffentlichen würden, sodass Dritte hiervon profi tieren könnten – bis hin zu einer Liste von Produkten mit geeigneten Betriebskonzepten und Integratoren.
Organisationen mit höherem Schutzbedarf möchten jedoch verständlicherweise nicht offenlegen, welche Produkte mit welchen Betriebskonzepten bei ihnen im Einsatz sind. Deshalb benötigte man eine Art Tauschbörse, die es einerseits ermöglicht, praktische Erfahrungen zu kommunizieren, ohne dass deren Urheber publik wird – andererseits müsste aber dennoch sichergestellt sein, dass Qualität und Integrität der transportierten Informationen überprüfbar und nachvollziehbar bleiben. So würde man etwa sicherlich einen eintägigen Kurztest anders berücksichtigen als eine umfassende Marktuntersuchung mit praktischen Tests auf Basis etlicher Manntage, die parallel in kurzer Zeit durch ein großes Team eines namhaften Marktteilnehmers erstellt wurde. Weitere Hindernisse eines solchen Erfahrungstransfers blieben aber dennoch Fragestellungen der Haftung und möglicher Wettbewerbsverzerrungen.
Bewertung von IT-Sicherheitslösungen
Die praktische Nutzbarkeit einer Lösung ist von wesentlicher Bedeutung. Trotzdem bleibt es noch wichtiger, dass eine implementierte Lösung tatsächlich einen besseren Schutz verwirklicht als es ihn ohne sie gegeben hat – sonst sollte man besser gar nicht investieren.
Man stelle sich eine Organisation vor, die ihre Mitarbeiter zum wöchentlichen Wechsel eines 12 Zeichen langen Passworts für den Systemzugang (natürlich mit komplexen Nebenanforderungen) zwingt, ohne dafür Sorge zu tragen, dass die vergebenen Passwörter gegen ein Ausspähen mit Keyloggern geschützt sind. Die Mitarbeiter würden sich zu Recht gegängelt vorkommen und der betriebene Aufwand, der zu signifikanten Kosten im Helpdesk führen dürfte, wäre nicht gerechtfertigt. Eine parallele Maßnahme zum technischen Passwort-Schutz gegen Ausspähen würde die Maßnahme hingegen sinnvoll begleiten und man könnte die Wechselfrequenz reduzieren, was zu einer höheren Benutzerakzeptanz führt.
In verschiedenen Bewertungen wird eine „All-in- One“-Lösung mit komfortablem Remote-Management aus praktischen Erwägungen heraus favorisiert – zumeist, da so etwas aus Fachanwendungen heraus als State-of-the-Art betrachtet wird. Dass ein Remote-Management aller Systemeigenschaften von außerhalb (evtl. sogar über unsichere Betriebssysteme oder BYOD-Elemente) praktische Vorteile in der Handhabung hat, ist evident – aber Nachteile für die IT-Sicherheit sollten ebenso evident sein: Remote- Interfaces zur Verwaltung von beliebigen Drittsystemen senken die Sicherheit und müssen selbst wieder aufwändig überwacht werden. Der zusätzliche Aufwand, den man in den Schutz der Konfigurationsdaten und administrativen Einstellungen solcher Sicherheitssysteme steckt, muss in der Gesamtkalkulation Berücksichtigung finden.
Weitere Betrachtungen dieser Art sind die Entwicklungswerkzeuge, mit den ein IT-Sicherheitsprodukt programmiert wurde, und seine Verankerung im System: C# ist beispielsweise leichter angreifbar als auf gut geprüften Compilern erstellter C-Code – und Systeme, die im Applikationskontext oder als Dienste laufen, sind leichter angreifbar als solche, die mit einem im Betriebssystem- Kern verankerten Treiber arbeiten (Kernel-Mode-Driver).
Diese Problematik wird noch komplexer, weil man ein Defizit (z. B. geringe Robustheit des Compilers gegen Angriffe) auch durch andere Sicherheitsmaßnahmen wieder wettmachen kann (z. B. Isolation des Produkts auf einem gehärteten System). Betriebskonzepte können ebenso positive wie negative Auswirkungen auf die Sicherheit des Gesamtsystems haben. Das benötigte Know-how: IT-Risiken entschärfen (Mitigation), neue Risiken durch neue Produkte erkennen und reduzieren.
Auch hier sind all diese Aspekte (und noch mehr) für hochsichere Umgebungen schon vorgedacht, aber keine einfachen Checklisten und prüfbaren Kriterien, Auswahl-Listen oder gar fertige Prüfberichte verfügbar. Bestätigungen über Herstellungsprozesse erweitern die Fähigkeiten zur Sicherheitseinschätzung und könnten zusammen mit dem Fragenkatalog zur Lieferkette als Fragen an die Hersteller/Anbieter in die Beschaffung mit aufgenommen werden. Doch sowohl für das Erstellen der richtigen Fragen (ein einfaches Kopieren der ISO 27001 ist hier nicht zielführend) als auch für deren Auswertung ist spezifisches Know-how erforderlich. Und darüber hinaus möchten (oder dürfen) Hersteller auch längst nicht jedem potenziellen Kunden tiefe Einblicke, etwa in die Sicherheitsüberprüfung ihres Personals und ihrer Prozesse, geben.
Auch hier wäre deshalb eine Vertrauensbörse wichtig, welche die Ergebnisse von Prüfungen verbindlich darstellt, ohne die Anonymität der handelnden Personen und die Vertraulichkeit von Herstellungsprozessen zu gefährden. In Verschlusssache-Umgebungen existiert zu diesem Zweck die Sicherheitsüberprüfung des Herstellers oder relevanter Teile von Hersteller und Lieferant. Doch diese Unternehmen unterliegen dem Geheimschutz: Hat ein Hersteller eine solche Prüfung positiv hinter sich gebracht, darf darüber nicht öffentlich gesprochen werden – wesentliche (bereits geleistete) Anstrengungen zur Identifikation vertrauenswürdiger IT-Systeme und Unternehmen bleiben somit weithin ungenutzt. Wieder wäre es hilfreich, einen Weg zur breiteren Nutzung zu finden, der die Interessen aller Stakeholder – also auch der öffentlichen Hand, die den Aufwand des Geheimschutzes betreibt – geeignet berücksichtigt, aber dennoch Dritte von den Ergebnissen profitieren lässt.
Marketing, Vertrieb und Marktmacht
Kaum ein potenzieller Kunde interessiert sich für die Kostenverteilung zwischen Forschung, Entwicklung, Marketing und Vertrieb. Dabei könnten diese Strukturen Anhaltspunkte dafür geben, dass Produkte mit den teuersten Marketingprozessen und den meisten Vertriebsstandorten nicht unbedingt die robustesten ITSicherheitsverfahren implementieren, weil womöglich weniger Ressourcen in die Forschung und Entwicklung von Schutzmechanismen fließen.
Auch bei den Produkten, die unter IT-Sicherheits- Flagge vertrieben werden, verbergen sich bisweilen schwarze Schafe – sogar wenn legitimerweise „IT-Security made in Germany“ als Label verwendet wird [2]. Um solche schwarzen Schafe zu erkennen, ist erheblicher investigativer Rechercheaufwand nötig – den kann natürlich längst nicht jeder Beschaffer betreiben. Der Endkunde kann meist mangels geeigneter Informationen nicht einmal beurteilen, welche Komponenten wo programmiert oder gebaut wurden und welche Beteiligten eventuell sogar nachrichtendienstlichen Hintergrund haben (vgl. den Abschnitt zur Lieferkette).
Natürlich kann ein Produkt nur dann gekauft werden, wenn es beworben und vermarktet wird – Ausgaben in Marketing und Vertrieb sind zwingend notwendig. Nicht selten sind solche Ausgaben aber gerade bei Lösungen, die stark auf Sicherheit setzen, so gering, dass diese für viele Marktteilnehmer quasi unsichtbar bleiben.
Auf der anderen Seite könnte man denken, dass große Firmen, weil sie überall bekannt und präsent sind, auch besonders stabile und sichere Produkte mit nachhaltigen Strategien anbieten. Dass das nicht der Fall sein muss, zeigen jedoch viele reale Beispiele: der Cisco Security Agent wurde aufgekündigt, Check Point hat seine nach dem Kauf von pointsec und DiskNetPro entwickelte Endpoint-Strategie mehr oder weniger ganz aufgegeben, die in Deutschland recht bekannten Produkte von utimaco sind nach der Übernahme durch Sophos zum Teil aufgekündigt worden, zum Teil durch ein Wechselbad der Strategien gegangen ...
Wo das nötige Know-how zur exakten Beurteilung fehlt, wird man eher zu einer vom Marketing gepushten Lösung greifen, anstatt sich für eine eventuell noch unbekanntere, aber womöglich nachhaltig robuste Lösung mit strategischen Vorteilen zu entscheiden. Denn die handelnden Marktteilnehmer sind notwendigerweise umsatzgetrieben. Ähnlich wie beim Umweltschutz wird aber ein völlig frei entwickelter Markt wenig in echte IT-Sicherheit und mehr in gut verkaufte Scheinsicherheit investieren!
Im Markt fehlen heute Dirigenten, die das gesamte Orchester mit der geeigneten Information versorgen und so auch Unternehmen mit weniger IT-/IT-Security-Knowhow den Zugang zu wichtigen Informationen barrierefrei und leicht konsumierbar (also frei von Fachbegriffen und langen Detailtexten), dafür aber von vertrauenswürdiger neutraler Stelle beglaubigt ermöglichen. Wie schon beschrieben, wäre eine geeignete Vertrauenskette oder Vertrauensbörse ein mögliches Medium, um Erfahrungen und Erkenntnisse zu transportieren und dann auch in die geeigneten, konsumierbaren Informationspakete zu übersetzen.
Eine Umfrage zum KMU-Markt auf der it-sa 2014 hat beispielsweise ergeben, dass viele Unternehmen gerne in IT-Sicherheit investieren würden, wenn der Zugang für sie barrierefrei und kalkulierbar wäre – man wünscht sich offenbar eine von neutraler Stelle befürwortete Zusammenstellung verschiedener Produkte mit einem geeigneten Betriebskonzept, zusammengefasst zu einem einzigen „Mach-mich-sicher“-Paket, zu einem festen Preis. Natürlich dürfen Verfügbarkeit und Ergonomie des Gesamtsystems nicht leiden und der Anbieter muss für dieses Paket auch in diesen Aspekten eine Haftung übernehmen (die ggf. an die Hersteller durchzureichen ist). Integratoren und Beratern fehlt aber eine verlässliche Information, mit welchen Lösungen sie solche Pakete aus welchen Gründen für welche Märkte schnüren sollten – Zusammenstellungen sind daher auf eigene Untersuchungen angewiesen, die sich wiederum auch kommerziell tragen müssen, was eine klare Begrenzung von Ressourcen bedeutet.
Zu guter Letzt ist auch an anderer Stelle die Frage nach dem Geld wesentlich: Ein Händler wird Produkte, bei denen er einen höheren Anteil vom Verkaufserlös erhält, aus einsichtigen Gründen lieber verkaufen als andere – Produkte mit geringer Marge oder kleinen Absatzmärkten werden häufig gar nicht erst ins Portfolio genommen. Jeder an der Handelskette Beteiligte muss naturgemäß entweder über die Quantität der abgenommenen Stückzahlen oder über eine hohe Marge beim einzelnen Verkauf seine internen Kosten decken. Beides spricht dagegen, dass so genannte Best-of-Breed-Lösungen in weit verbreiteten Handelsketten landen, da hierbei (zumindest zu Beginn der Vermarktung) für gewöhnlich geringe Margen und kleine Absatzmärkte die Regel sind. Hilfe verspricht dem Anbieter dann Venture-Capital (VC) – doch VC-Gesellschaften geben Kapital meist nur gegen Beteiligung an Patenten und „Intellectual Property“ (IP) der Unternehmen, wodurch die Eigenständigkeit und zum Teil auch die Innovationskraft der Geförderten leidet.
Die Fortsetzung dieses Beitrags folgt in der nächsten <kes>.
Ramon Mörl ist Geschäftsführer der itWatch GmbH.
