Sind Firewalls noch zeitgemäß?
Die meisten restriktiven Security Policies haben inzwischen ein Alter von drei bis fünf Jahren erreicht. Damals hat man das als Policy niedergelegt, was im gerade führenden Fachbuch stand, und somit auch schon einige Jahre auf dem Buckel hatte. Auf solch einer alten Policy aufgesetzte Sicherheitsmaßnahmen, die typischerweise das böse Internet mit einer (!) Firewall von dem einen (!) internen Netz abtrennen und bestenfalls eine kleine Handvoll Servicenetze (vulgo "DMZ", wobei "mehr als ein Servicenetz" immer noch mit "Respekt! Das ist aber gut durchdacht!" kommentiert wird) beinhalten, sind in der heutigen Welt kaum mehr zeitgemäß; es ist Zeit, hier anzusetzen.
Mit Policies auf dem technischen Stand von vor fünf Jahren ist heute ein messbarer Sicherheitsgewinn kaum mehr erreichbar. Zu sehr verschwimmen in den letzten Jahren die Netzgrenzen, werden durch Inter-, Extra- und Intranet, VPN-Tunnel, UMTS, Wireless LAN, Mobile Devices, Suspendmodi und andere Dinge immer weiter aufgeweicht, so dass eine einzige klassische Firewall am Unternehmenseingang heute nicht mehr zeitgemäß ist. Mit solchen Lösungen erreicht man nur, dass die Leute, die die Arbeit machen, bei ihrer Leistungserbringung massiv behindert werden, was die IT-Kosten in ihrer Gesamtheit in astronomische Höhen treibt. Außerdem bauen die Leistungsträger sich in so einer Umgebung policykonforme Workarounds, die nur deswegen policykonform sind, weil es sie zum Zeitpunkt der Policyerstellung schlicht noch nicht gab und sie deswegen in der Policy nicht verboten sind. Interessant finde ich übrigens, dass es kaum eine Security Policy gibt, die die in der Technik seit 20 Jahren übliche Maxime "Es ist alles verboten, was nicht ausdrücklich erlaubt ist" (vulgo "default deny") zur Grundlage hat. Nein, die meisten Policies ergehen sich in seitenlangen Listen von Dingen, die bei sofortiger Entleibung niemalsnie passieren dürfen. Das Ergebnis ist der GAU: Hohe Kosten bei nur mäßigem Sicherheitsniveau.
Nun, wie schon so oft: Kris Köhntopp hat das schon vor Jahren ausgeforscht. Seine Präsentation über Mobile Devices spricht mir aus der Seele, und er hat natürlich Recht. Besonders seine Aussage, dass die Benutzer immer kreativer werden, je restriktiver die Policy ist, ist eine viel zu selten in dieser Deutlichkeit ausgesprochene Wahrheit.
Was lernen wir daraus? Eine Security Policy ist nur dann sinnvoll, wenn man sie aktuell hält. Wobei "aktuell" nicht nur heißt, dass man die technischen Weiterentwicklungen, die den Sinn der alten Policy in Frage stellen, verbietet - nein, das wird man eh nicht durchhalten können, weil viele dieser technischen Weiterentwicklungen als Spielzeug für die Entscheider taugen und man deren Verbot deswegen eh nicht wird durchhalten können. Es ist vielmehr sinnvoll, die existierende Policy in regelmäßigen Abständen - am besten innerhalb eines formellen Review-Prozesses - zu hinterfragen und zu modernisieren. Das bedeutet freilich auch, dass manche Verbote aufgehoben oder abgeschwächt gehören und man sich nach anderen Wegen zur Reduktion des Risikos umsehen muss. Die Security wird in den nächsten Jahren wieder näher an die Daten selbst, also an die Server, heranrücken müssen, und dafür wird Geld in die Hand genomen werden müssen. Als Belohnung winken schneller ablaufende, weniger kostende IT-Projekte in der Zukunft.
Viele Unternehmen werden externen Rat nötig haben, und zwar sowohl im Prozess der Policyanpassung als auch bei der Umsetzung der neuen Policy. Es wird viel zu tun geben - fragen Sie bitte jemanden, der sich auskennt!
Trackbacks
No Trackbacks
Comments
Display comments as Linear | Threaded
Andreas Rauer on :
Willkommen im Review&Improve-Abschnitt eines ISMS...
Gut ist, das ISO 27001 regelmässiges Prüfen der aktuellen Policies und Massnahmen fordert, sowie angemessene Reaktion bei der dadurch angestossenen Risikoanalyse.
Gut ist, das ISO 27001 inzwischen stark in "automotive", "telco" und "financial" gefordert wird.
Und hoffentlich bleibt ISO27001 das Schicksal von 9001 als zahnlose "Werbeplakette" erspart...
Marc 'Zugschlus' Haber on :
ISO9001 ist (leider) mehr als eine zahnlose Werbeplakette. Es ist die Ausrede um mitdenkende Mitarbeiter auszubremsen und freiwillig auf Flexibilität (und damit auch aufs Nachdenken) zu verzichten.
Andreas Rauer on :
Tja, das ist das Problem, wenn der QMB stur auf seinem einmal erstelltem QMS beharrt und keinerlei Input mehr akzeptiert -> ergo, kein Review angestossen wird oder werden kann.
Das ist aber meines Erachtens keine Schwäche des Standards, sondern die des dafür Verantwortlichen...
Axel on :
Im Prinzip gebe ich dir recht, Marc. Allerdings fuchst es mich, daß immer neue gadgets auf den Markt geschmissen werden und sich niemand jemals Gedanken über deren Sicherheit macht. So nette Themen wie "Network Admission Control" sind wiederum so hoffnungslos komplex (insbesondere fürs Troubleshooten), daß es in den meisten Unternehmen unrealistisch ist, sie einzuführen.
Marc 'Zugschlus' Haber on :
Dankeschön!
Aber so ist es (leider?) nun mal. Und unsereins hat als Dienstleister die Aufgabe "make it work". Es ist deutlich einfacher, dieses ohne übergroßes Risiko zu bewerkstelligen, wenn die Infrastruktur zeitgemäß designed ist.
Die Gadgets werden nachgefragt werden, und wenn es nur dafür ist, dass die Entscheider auf dem Golfplatz was zum protzen haben, und dieser Herausforderung müssen wir uns stellen.
Freilich müssen wir bei der Einführung neuer Gadgets unsere Bedenken äußern und dokumentieren, damit man uns nicht auch noch an den Karren fährt, wenn das Kind doch mal in den Brunnen fällt. Die Arbeit des Scherben zusammenkehrens haben wir ja eh. Verhindern können wir sowas nicht, denn wenn wir da nicht spuren, wird ab dem nächsten ersten ein neuer Dienstleister das tun, was wir nicht wollen und wir haben ein Problem.
Eine klassische Firewall ist ebenfalls hoffnungslos komplex und für die meisten Unternehmen unrealistisch. Und trotzdem haben alle eine.
Wenn man die interne Security vereinfacht, weil man die Komplexität nicht beherrscht, ist es wirtschaftlich sinnvoll, das durch die vereinfachte Security reduzierte Sicherheitsniveau konsequent überall durchzuziehen und unnötig gewordenen Aufwand auch wirklich wegzusparen. Und mit dem daraus entstehenden Risiko zu leben.
Axel on :
Ähm. Eine klassische Firewall ist ein single point of control/failure. NAC ist ein Zusammenspiel aus dezentralen Zugangspunkten (Switches) und Authentisierungssystemen mit den unterschiedlichsten Protokollen und ggg. Netzwerkübergängen.
Da würde ich schon noch die eine oder andere Größenordnung Unterschied in der Komplexität sehen.
Natürlich ist es eine Abwägungssache, ob man lieber komplexere Technik einsetzt oder mit einem höheren Risiko fahren möchte. Aus meiner Erfahrung heraus ist es aber häufig so, daß komplexe Systeme, auf die immer noch mehr draufgepackt wird (z.B. vom Layer 2-Switch zu den heutigen Software-Monstern, bei denen auch noch gleich ein IDS und ein Virenscanner darufsitzen kann) ein viel höheres Risiko haben auszufallen als kleine und dedizierte Geräte. Alleine für das Troubleshooting sind diese All-in-One-Black-Boxes doch ein Horror. Was ich damit sagen will: ich halte Komplexität für den allergrößten Feind der Sicherheit. Daß es natürlich absolut sinnlos ist, nur die Außengrenzen abzusichern, ist selbstverständlich: Defense in Depth ist das Schlagwort (naja, eigentlich 'die Schlagworte'), aber darauf sollte man auch kommen, wenn man sich die Funktionsweise von A/V und Firewalls und und und... mal anschaut - selbst wenn man nicht der Meinung sein sollte, daß es keine 100%ige Sicherheit gibt.
Marc 'Zugschlus' Haber on :
Ja, aber diese Komplexität ist beherrschbar. Da gibt es Management-Frontends, wenn es das partout sein soll, und dank RADIUS kann man die auf den verteilten Komponenten notwendige Konfiguration auch hinreichend trivial halten.
Und jemand, der nicht weiß, was er tut, ist auch mit einer klassischen Firewall überfordert. Natürlich steigt die Komplexität, aber das tut die Komplexität der -eigentlichen- Systeme auch.
Da braucht man dann halt Redundanzen, und die übrigens noch aus anderen Gründen. Das Netz ist halt fürs Funktionieren der IT unbedingte Voraussetzung; das ist noch nicht soooo lange der Fall.
Es gibt gute und schlechte Produkte.
Ja, aber das gilt für die Komplexität der zu schützenden Systeme genauso. Und diese Komplexität werden wir nicht los. Und einfache Sicherheit gibt es in einer vernetzten Welt leider nicht. Was - glücklicherweise - bedeutet dass die Krauter langsam überfordert sind und die Profis wieder zum Geld verdienen kommen.
Tobias Crefeld on :
Naja, sei mir ned bös, aber aus dem Text spricht in erster Linie der Frust über die Inkonsequenz von Verantwortlichen in Sachen Security, die ständigen Anforderungen der User ("ich will aber") und leider auch der Beginn einer Tendenz, Hürden und Verbote im betrieblichen Alltag als kostenintensiv zu brandmarken, ohne dies zu belegen.
Vor etlichen Jahren gab es mal nen zielich guten Vortrag auf der Systems über die Möglichkeiten, mit Security-Management Geld zu sparen. Das hat zunächst einmal etwas mit dem Verständnis von Arbeitsabläufen zu tun.
Warum läßt man die einen mit ihren $Winword und $Outlook rumwurschteln und die anderen bedienen ihr $SAP, das vorne Scannerdaten, Mails und XML-Feeds liest und hinten vollautomatisiert Briefe, Reports und Mails raushaut? Und welche der beiden Anwendungen ist wohl effizienter - ausreichend großer Maßstab vorausgesetzt?
Um hier eine Antwort zu bekommen, muß man anfangen zu rechnen, wieviel % ihrer Zeit die Mitarbeiter mit fehlgeleiteten Telefonaten, Bearbeitung von Mail, task switching und Desk-to-Desk-support beschäftigt sind. Aber natürlich muß man auch einrechnen, ob diese MA in derselben Zeit aus Sicht der Firma hätten produktiver sein können - ist bei weitem nicht selbstverständlich.
Der Redner nannte dann ein paar Beispiele für Konsequenzen. So wurden in einer Firma Mailzeiten eingeführt. Also Mails werden nicht mehr ad hoc zugestellt, sondern nur noch 3 x am Tag. Klingt erstmal verrückt, weil man es im Postbereich als nachteilige Einschränkung empfindet, aber reduziert die Task-Wechselzeiten und leitet die MA zu einer genaueren Selbstkontrolle über ihren Zeitaufwand für Mailverkehr an. Ist jetzt nur ein Beispiel, daß in einen konkreten Fall sinnvoll war, aber der Nebeneffekt war neben der sorgfältigeren Formulierung natürlich auch die langsamere Ausbreitungszeiten von virulenten Mails. Andere wirtschaftliche Effekte, speziell von Security-Maßnahmen sind ja bekannter und mittlerweile allgemein anerkannt - Spam- und Content-Filter ersparen neben Bandbreite und Serverleistung insbesondere Manpower beim Bearbeiten der Mails oder beim Websurfen. Noch ein Beispiel: Bei einem Betrieb werden nur bestimmte Websites zugelassen. Kann man natürlich umgehen, aber erspart mitunter viel Arbeitszeit, wenn Leute weniger durch "schnell mal eben gucken" abgelenkt werden.
Auch klar: Wenn man Gimmick-Sammler als "Kundschaft" hat, für die auf der anderen Seite Geld keine Rolle spielt, dann braucht man sich darüber keine Gedanken zu machen. WENN allerdings Geld doch ne gravierende Rolle spielt, dann hat man ein "Controlling-Problem" zu lösen und hier ist gute Argumentation ebenso wie ein Grundstock an wirtschaftlichen Basisdaten vonnöten. Der durchschnittliche Sysop wird da eher überfordert sein und ebenso wie der durchschnittliche Berater sich überlegen dürfen, wie weit er bereit ist, zwengs dem schnöden Mammon irgendwelches Bastelzeuchs zu verinstallieren.
Gruß, Tobias.