IT-Experten kennen Regeln, die Zielkonflikte zusammenfassen. Beliebt ist eine Dreierkombination von Zielen, mit dem Satz „take any two of the three“. Nun möchte ich eine bereits bestehende Kombination aus zwei Konsonanten und einem Vokal in der Mitte umdeuten. Einige Programmierer haben bereits das SEF-Theorem für „Structured, Extensible, and Forward Compatible“ aufgestellt. Die Bezugnahme auf diese Regel ist so selten (36 Google-Treffer), dass eventuell die von mir vorgeschlagene andere Ausschreibung des Akronyms bald die Oberhand gewinnen könnte: Security, Economy und Functionality.
Sicherheit, Wirtschaftlichkeit und Funktionalität bilden bisher einen typischen Zielkonflikt. Von diesen drei Zielen sind in einer IT-Infrastruktur nur zwei gleichzeitig erreichbar. Natürlich: diese drei Ziele sind keine binären Zustände (ja oder nein). Daher kann ich mein SEF-Theorem nicht mit Mitteln der Logik oder Mathematik beweisen, aber mit Empirie, also gestützt auf einige Jahre Erfahrung.
Abbildung 1: Peer-to-Peer-Kommunikation über Firewall
Wie definiere ich aber Sicherheit, Wirtschaftlichkeit und Funktionalität, um daraufhin zu behaupten, dass nur zwei von diesen drei Zielen erreichbar sind? Da es sich bei keinem dieser Ziele a priori um einen binären Zustand handelt, muss ich aus jedem Ziel quasi einen binären Zustand machen. Ich lege mich hiermit fest: Ausschlaggebend ist der Vergleich des Zustands eines einzelnen Anwenders bzw. einer einzelnen Anwenderin (nennen wir die Einheit vereinfachend „User“) mit dem Marktdurchschnitt. Wenn ein User hinsichtlich Betroffenheit von Sicherheitsvorfällen besser gestellt ist als 80% aller User im Markt, dann befindet er oder sie sich in einer sicheren IT-Infrastruktur. Gleiches bei Wirtschaftlichkeit, die erreicht wird, wenn die Kosten pro User im Vergleich zu mindestens 80% aller User im Markt niedriger sind. Und schließlich wird das Ziel Funktionalität erreicht, wenn die IT-Infrastruktur die denkbare Funktionalität weniger behindert als bei mindestens 80% aller User im Markt. Ich habe bewusst einen bestimmten Markt (zum Beispiel einen nationalen Markt) als Bezugsgröße gewählt, damit ich mich bei der Kostenbetrachtung nicht mit solchen Problemen wie Kaufkraftdisparität verschiedener Märkte herumschlagen muss.
Zwei Beispiele aus der Praxis sollen mein SEF-Theorem belegen.
Beispiel Nummer 1:
Sicherer Internetzugriff
Immer mehr Endgeräte wollen „nach Hause telefonieren“, können dies aber nicht uneingeschränkt tun, wenn sie sich in einer Umgebung befinden, aus der eine Kommunikation mit dem Internet nur über Proxies möglich ist. Der Hersteller Apple beschreibt dieses Problem für die eigenen Geräte im Support-Dokument HT203609. Die Empfehlung von Apple ist, bestimmte TCP-Ports für die Kommunikation mit dem ganzen IP-Adressbereich 17.0.0.0/8 zu erlauben, damit macOS- und iOS-Clients den Apple-Push-Benachrichtigungsdienst (APNs) nutzen können. Im besagten Apple-Artikel ist ausdrücklich erwähnt, dass APNs über Proxies nicht möglich ist.
Wenn das Beispiel Schule macht und immer mehr Hersteller von Endgeräten und Software die Öffnung von Ports für große Adressbereiche fordern, verlieren Sicherheitskomponenten wie Proxies teilweise ihren Sinn. Was tun?
Von einer Vielzahl an Möglichkeiten, mit dem Problem umzugehen, nenne ich hier nur drei:
- Die Umgehung von Proxies bleibt verboten. Das ist der Verzicht auf Funktionalität.
- Die Empfehlung von Apple und ähnliche Empfehlungen anderer Hersteller werden befolgt. In letzter Konsequenz wird das interne Netz zur Verlängerung des Internets. Das ist ein Verzicht auf Sicherheit. Auf das Argument, Perimeter-Security ist nur eine scheinbare, antworte ich mit der Frage nach der Bereitschaft, etwa die Roboter in der Fabrikhalle ins Internet zu stellen. Ist die Antwort nein, folgt daraus, dass Perimeter-Sicherheit doch keine so blöde Idee ist.
- Auf den Komponenten der Perimeter-Sicherheit werden die Regeln für neue Bedarfsfälle wie APNs konfiguriert, aber mit einer ständigen Protokollierung und Prüfung kombiniert. Zum Beispiel kann Machine Learning dazu eingesetzt werden, die Verkehrsprofile bei der Kommunikation mit dem Internet zu analysieren, um Auffälligkeiten festzustellen. Viele Daten müssen aufgezeichnet und mit komplexen Algorithmen analysiert werden. Auf Alarme muss reagiert werden. Aufgrund des Analyseergebnisses kann die Kommunikation verhindert werden. Das löst bei legitimer Kommunikation ein Ticket aus. Das Ticket muss bearbeitet und eine Abhilfe gefunden werden. Die Abhilfe kann eine komplexere Regel sein. Das alles kostet Geld und Aufwand, also Verzicht auf ein Stück Wirtschaftlichkeit.
Beispiel Nummer 2: Voice over IP
Immer mehr Netze müssen mandantenfähig sein. Stellen Sie sich ein in verschiedene Mandantenbereiche aufgeteiltes Netz vor. Endgeräte werden anhand von bestimmten Merkmalen (vorzugsweise Zertifikaten) den Mandantenbereichen zugeordnet. Firewalls verbinden die Mandantenbereiche miteinander und mit Netzen, in denen sich zentrale Ressourcen für allgemeine Dienste und Applikationen zur Nutzung durch alle Mandanten befinden. Eine allgemein genutzte Applikation kann Voice over IP (VoIP) sein. VoIP ist meistens mit direkter UDP-Kommunikation zwischen Endgeräten verbunden. Dies bedeutet, dass zwischen einem und allen anderen Mandantenbereichen über einen relativ großen Bereich von UDP-Ports kommuniziert werden muss. Auf der Firewall, die Mandanten voneinander trennt, ist entsprechend zu konfigurieren, dass viele UDP-Ports für die Kommunikation mit den IP-Adressen der Endgeräte aller Mandanten zu öffnen sind (siehe Abbildung 1).
Auch hier nur drei Möglichkeiten unter vielen:
- Mandantenübergreifende VoIP-Kommunikation wird nicht eingesetzt, also auf Funktionalität verzichtet.
- Die UDP-Ports werden auf der Firewall geöffnet. Wird ein Mandantenbereich von einer Malware befallen, die diese Ports missbraucht, kann sich der Schaden lateral ausbreiten und andere Mandanten infizieren. Weniger Sicherheit.
- Pro Mandantenbereich übernimmt ein Session Border Controller (SBC) die Mediatorrolle bei der VoIP-Kommunikation mit anderen Mandanten. Das geht in der Regel auch damit einher, dass in jedem Mandantenbereich eigene zentrale VoIP-Ressourcen aufzustellen sind, die den jeweiligen SBC steuern. Die Wirtschaftlichkeit leidet darunter, vielleicht sogar auch die Funktionalität, nämlich wenn nicht alle gewünschten Leistungsmerkmale über SBC-Grenzen hinweg genutzt werden können.
Ersetzen Wissen und Erfahrung teure Werkzeuge?
Vor meinem geistigen Auge sehe ich schon Kritiker, die auf ihr Wissen und ihre Erfahrung im Umgang mit IT-Risiken hinweisen, und darauf, dass bei Nutzung ebensolchen Wissens und solcher Erfahrung teure Sicherheitswerkzeuge nicht notwendig seien.
Ich unternehme nicht einmal den Versuch des Widerspruchs. Ich frage nur: Was ist Wissen und Erfahrung, wenn nicht abstrakte Arbeit? Ökonomen des 18. und 19. Jahrhunderts haben Maschinerie als „materialisierte Arbeit“ bezeichnet. In Maschinen steckt Kapital, und Kapital ist angehäufte Arbeit. Vor 200 Jahren war die Industrie vor allem die verarbeitende Industrie, die aus Rohstoffen Fertigprodukte herstellte. Heute ist an die Seite der klassischen auch eine Industrie getreten, die Daten verarbeitet. Dazu werden Algorithmen eingesetzt, die heutigen Maschinen. Vielleicht kann man sie nicht materialisierte Arbeit nennen, weil Materie etwas Fassbares ist. Aber Algorithmen, Wissen und Erfahrung sind durchaus abstrakte Arbeit, wie eine Maschine auch.
Menschen werden nicht mit Wissen und Erfahrung geboren. Sie eignen sich Wissen durch Arbeit an. Ja, Wissen und Erfahrung können teure Werkzeuge ersetzen (allerdings nicht immer). Aber wie viel Arbeit, wie viel Arbeitszeit, steckt als abstrakte Arbeit im Wissen und Erfahrungsschatz eines Sicherheitsexperten, der eine IT-Umgebung wirksam vor Risiken schützt? Man wird nicht zum IT-Sicherheitsexperten, wenn man einmal im Monat eine solche Kolumne liest (oder schreibt; setzen Sie an diese Stelle einen Zwinker-Smiley).
Damit Sie nachvollziehen können, wie viel abstrakte Arbeit im Urteilsvermögen eines IT-Sicherheitsexperten steckt, hier ein weiteres Beispiel aus der Praxis:
Ein Mitarbeiter der US-amerikanischen Democratic National Convention (DNC), also des demokratischen Parteiapparats, erhielt mitten im Vorwahlkampf der Präsidentschaftskandidaten dieser Partei eine E-Mail, die ihm verdächtig vorkam. Er zeigte diese Nachricht einem IT-Administrator, der die Bedenken des Empfängers mit dem Urteil zerstreute, die Nachricht sei unbedenklich. Das war aber das Einfallstor für einen Trojaner, der interne E-Mails des Clinton-Lagers kompromittierte. Die Folgen sind bekannt. Offenbar steckte im Wissen des befragten IT-Administrators nicht sehr viel abstrakte Arbeit.
Ist das SEF-Theorem eine Plattitüde?
Zugegeben, hier wird nichts Neues berichtet. Security ist Arbeit. Oder teuer. Oder beides. Wer weiß das nicht?
Offenbar diejenigen, auf deren Erwartungshaltung ich immer wieder stoße. Sie erwarten, dass das eigene Unternehmen mit zunehmender IT-Durchdringung immer effizienter wird, also mehr erwirtschaftet. Das tut es auch. Aber die zunehmende IT-Durchdringung ist ein zunehmend riskantes Geschäft. Investieren Unternehmen, Verwaltungen und andere Organisationen zumindest einen Teil des mit IT erwirtschafteten Vorteils in IT-Sicherheit? Leider nicht in ausreichendem Maße, wie wir fast täglich den Berichten über Sicherheitsvorfälle entnehmen können.
Also Plattitüde hin, Plattitüde her: Wir, die wir das Problem kennen, sollten nicht müde werden darauf hinzuweisen. Sichere Nutzung von möglichst vielen Funktionen der IT ist aufwändig. Die Kombination aus Effizienz und Sicherheit erfordert die Reinvestition eines Teils des Effizienzgewinns.
Mein Kollege Dr. Hoff hat mich darauf hingewiesen, dass das SEF-Theorem nicht ewig gelten muss, sondern auch der Insuffizienz von Bestandstechnologien geschuldet ist. Wenn Security als treibende Kraft für bessere und sogar wirtschaftlichere (weil qualitativ langfristig bessere) Produkte verstanden wird, können wir hoffentlich in ein paar Jahren das SEF-Theorem begraben. Wie das gehen kann, möchten wir mit Ihnen diskutieren. Das ComConsult-Team wird die neuesten Möglichkeiten für mehr Effizienz und Sicherheit auf der diesjährigen Sommerschule in Aachen vorstellen: von Digitalisierung und Cloud-Nutzung über effiziente Teamarbeit und Mobilität bis zur operativen IT-Sicherheit ist alles dabei, was uns in den Projekten der letzten Monate beschäftigt hat. In der Veranstaltung steckt viel Arbeit und Erfahrung; nutzen Sie sie!