Home      Themenübersicht / Sitemap      Notizen      Webmaster      

Der eigentliche Kern des IT-Sicherheitsproblems

26.10.2005 - Philipp Schaumann

Angeregt durch Fragen (z.B. ob das mangelnde Benutzerbewusstsein der Kern des Sicherheitsheitsproblem in der IT sei), hier mein 7-Punkte Programm zum Kern dessen, was in der IT-Sicherheit schief läuft:

Link-Konventionen:
Fette Links öffnen ein fremde Seite in einem neuen Fenster
Blau hinterlegte Links bleiben auf der sicherheitskultur.at
  • Unsere Technik um Angriffe zu blockieren beruht fast nur auf dem Black-List Prinzip (verbieten, was böse ist) statt auf White-Lists (das wenige erlauben, was wirklich auf dem Rechner ausgeführt werden soll)
  • Das Problem dieser Vorgehensweise ist, dass die Liste der "bösen Dinge", seien es Viren, Würmer, Spyware, Adressen von bösen Websites, Angriffspattern in Computernetzen, etc. immer länger wird. Und dabei haben die meisten Benutzer meist nicht mehr als 30 Anwendungen, die sich wirklich brauchen. Und es gibt Technologien die es erlauben, genau diese gewünschten Anwendungen zu spezifizieren. Diese Aufzulisten, wäre nicht sonderlich schwer, die Aktualisierung der "bösen Sachen" wird zu einem immer größeren Problem. Mehr dazu bei den dümmsten Ideen der Computer-Sicherheit

  • Die Software, die wir heute einsetzen und immer weiter entwickeln beruht auf Programmiersprachen, die in Bezug auf Sicherheit ein großer Rückschritt gegen über den 70-iger Jahren darstellen und sicheres Programmieren wird kaum gelehrt
  • Heute wird der größte Teil der Anwendungen in der Sprache C entwickelt, die es sehr leicht macht, unsauber und riskant zu programmieren. Feldüberläufe, d.h. in ein Speichergebiet werden mehr Daten geschrieben, als hineinpassen, sind die häufigste Ursache für Sicherheitsprobleme in Programmen und Betriebssystemen. Die ließen sich leicht verhindern, indem Sprachen verwendet würden, wo diese Programmierfehler nicht möglich sind. Und an den Unis gibt es spezielle Vorlesungen zu Computersicherheit, aber sicheres Programmieren ist sehr selten ein integraler Bestandteil der Programmiervorlesungen. Und viele Programmierer weigern sich ganz einfach, ihre Programme so zu schreiben, dass die Compiler keine Warnungen ausgeben, obwohl die Programme dann sicherer wären. Mehr dazu unter lausige Software

  • Wir basieren unsere Sicherheitskonzepte oft auf unrealistischen Annahmen, z.B. beruht die Sicherheit von Internet-Banking darauf, dass die Rechner der Kunden nicht infiziert sind
  • Die Statistiken über infizierte Heimrechner, d.h. Rechner, auf denen Schadsoftware aktiv ist, schwanken zwischen 50% und 70%. Das bedeutet, dass wir nicht davon ausgehen können, dass die Zugangscodes, die die Benutzer von Internet-Banking oder von eBay eingeben, geheim bleiben, egal wie sehr wir über die Gefahren beim Umgang mit e-Banking oder e-Commerce informieren. D.h. unsere Sicherheitskonzepte müssen davon ausgehen, dass der Anwender nicht unbedingt Herr über seinen Rechner ist und z.B. Hilfestellung beim "Säubern" des Rechners anbieten, oder Implementierungen empfehlen, die trotz Infektion ein hohes Maß an Sicherheit bieten. Mehr dazu unter Phishing Misere

  • Viele IT-Spezialisten implementieren Sicherheit als Insellösung. Da steht dann ein ausfallsicherer Firewall-Cluster in einem IT-Netz aus lauter Single-Point of Failures und weit offenen Systemen
  • Oder ich lese in einer ansonsten recht interessanten Studie über die Problematik des e-Votings (PDF, 300K), die im Auftrag der Regierung durchgeführt wurde, dass als eine der Sicherheitsmaßnahmen, zwischen ansonsten sehr guten organisatorischen Vorschlägen, dass Firewalls eingesetzt werden sollen. No na, klar werden Firewalls eingesetzt, aber der Text legt nahe, "dann wird es schon sicher sein, es wird ja ein Firewall eingesetzt". Das ist eine Scheinsicherheit, die leicht täuscht. Eine schwache Stelle in der Sicherheitskette reicht aus, das Gesamtsystem unsicher zu machen. Und schlecht oder falsch konfigurierte Firewalls (PDF) sind auch in Großunternehmen die Regel, wie eine isrealische Studie zeigt. Die Lösung muss in einer gesamthaften Betrachtung des Risikos (entweder der jeweiligen Anwendung, oder des gesamten Unternehmens) liegen, d.h. Risikoanalyse und dann Erstellung einer Sicherheitspolicy.

  • Weil die oft insuläre Implementierung der Sicherheitstechnologien das Problem nicht löst, wird die Verantwortung dann auf das Sicherheitsbewusstsein des Endbenutzers verschoben, ohne ihm einen Rechner zur Verfügung zu stellen, der Schadsoftware einfach nicht ausführt
  • Wir sollten dem Anwender im Unternehmen (und auch dem Heimnutzer) Rechner zur Verfügung stellen, die sich z.B. weigern, Schadsoftware auszuführen, z.B. weil der Benutzer dafür nicht genügend "Rechte" hat oder weil die Schadsoftware nicht in der Liste der Anwendungen für diesen Benutzer enthalten ist. Solche Konzepte gibt es bereits, z.B. appsense, werden aber nur selten genutzt. Wir sollten Internet-Browser anbieten, die leicht so einstellbar sind, dass der Benutzer bei jedem Zugriff zur Festplatte vorher gefragt wird. Auch die Apple-Rechner haben bessere Sicherheitskonzepte als die Windows-Systeme, d.h. wir wissen heute theoretisch, wie wir Systeme bauen können, die nicht dem Sicherheitskenntnissen der Anwender ausgeliefert sind.

  • IT-Spezialisten, die es besser machen wollen, kämpfen oft mit mangelnder Unterstützung von "oben", entweder werden zu wenige Ressourcen zur Verfügung gestellt, oder, genauso häufig, scheut das Management harte Entscheidungen, z.B. "sichere Passworte für alle" oder "keine Administrationsrechte für Endbenutzer" oder "keinen Wildwuchs an PDAs"
  • Das erlebe ich immer wieder, die IT-Spezialisten wissen, dass es viel sicherer wäre, wenn die Anwender eingeschränkte Administrationsrechte auf "ihren" Rechnern hätten, aber je höher die Anwender in der Hierarchie sind, desto schwieriger ist es, die Rechner sicher zu gestalten. Auch das "Verbot" von WLAN-Nutzung in Flughafen oder Starbucks-Cafés ist, abhängig von der Stellung in der Hierarchie, oft kaum durchzusetzen. Selbst so wichtige Sachen wie Verschlüsselung der Festplatten der Laptops der Vorstandsmitglieder sind oft nicht durchzusetzen, weil dies natürlich eine gewissen Unbequemlichkeit ist.

  • Zu späte Implementierung von "Sicherheit" in den Projekten der Unternehmen. Sicherheit muss bereits bei der Definition der Projektanforderungen ein Thema sein, nicht erst, wenn bereits etwas angebrannt ist
  • Sicherheitsüberlegungen müssen integraler Bestandteil der gesamten Projektdurchführung sein, von der Konzeption bis zur Implementierung und Wartung. Und das betrifft alle Arten von Projekten, von der Software-Entwicklung bis zum Umbau des Verwaltungsgebäudes. Nachträgliches Berücksichtigen von Sicherheitsaspekten ist entweder nicht mehr möglich (das Massagebecken über dem Rechenzentrum eines Krankenhausneubaus) oder sehr teuer.

Ähnliche Erkenntnisse finden sich in ironischer Form auf techrepublic.com.

 


Philipp Schaumann http://sicherheitskultur.at/


Home

Copyright-Hinweis:
Das Copyright des Materials auf diesen Webseiten liegt, falls kein anderer Autor genannt wird, bei Philipp Schaumann. Creative Commons License
Diese Texte sind lizensiert unter der Create Commons Attribution-Noncommercial-Share Alike 2.0 Austria Lizenz. Natürlich gelten auch die Regeln des Fair Use und über Ausnahmen bzgl. der Lizenz kann jederzeit mit den Autoren gesprochen werden.