Worum geht es?
Vielleicht abgesehen von fehlerhafter Aufstellung oder Konstruktionsmängeln an Hardware, die beispielsweise zur Überhitzung oder anderen Störungen führen können, entscheiden sich Fragen der Informationssicherheit in aller Regel nicht an der gegenständlichen IT, sondern an der Software, mit der diese betrieben wird. Angriffe zielen im Grunde ausschließlich auf Schwachstellen, die über die eingesetzte Software überhaupt erst möglich werden.
Was empfiehlt die ISO 27002?
Um die Risiken zu minimieren, macht die ISO 27002 in Kapitel 8.19 einige Vorschläge, die hier zusammengefasst werden:
- Wie auch in anderen Bereichen, sollten Änderungen an Betriebssoftware nur durch geschultes Personal erfolgen und nur nach Genehmigung umgesetzt werden. Installationen durch Anwender sollten sich auf begründete und dringende Ausnahmen beschränken.
- Genehmigungen sollten nur sehr restriktiv erteilt werden und sich immer auf bestimmte ausführbare Programme beziehen. Entwicklerversionen oder Compiler dürfen nicht eingesetzt werden. In die Entscheidung zur Genehmigung sollten die eigenen geschäftlichen Anforderungen einfließen und auch die mit der in Frage stehenden Version verbundenen oder auch neu entstehenden Risiken betrachtet werden.
- Patches und Updates, die dazu dienen, die Sicherheit zu erhöhen, sollten grundsätzlich angewandt werden. Auch sonst sollten Hinweise von Herstellern und Lieferanten berücksichtigt werden. Soweit Wartungen notwendig sind, sollten sie auch erfolgen.
- Installationen oder Aktualisierungen von Software in operativen Umgebungen sollten nur nach angemessenen Tests erfolgen. Ggf. müssen erst Proben in einer Staging-Umgebung erfolgen.
- Soweit Software von externen Quellen bezogen wird, müssen Lieferanten und die diesen möglicherweise gewährten Zutritts- und Zugriffsmöglichkeiten angemessen gesteuert und kontrolliert werden.
- Bei Aktualisierungen müssen auch alle relevanten Programmbibliotheken berücksichtigt werden.
- Zur einfacheren Kontrolle der Betriebssoftware, aber auch zur Dokumentation, ist der Einsatz einer Software zur automatischen Konfiguration über Netzwerke sinnvoll.
- Jede Änderung sollte sich notfalls rückgängig machen lassen.
- Jede Änderung sollte sich durch entsprechende Protokolle im Detail nachvollziehen lassen.
- Ältere Versionen von Software sollten inklusive aller dazugehörigen Anleitungen und Dokumentationen aufbewahrt werden, insbesondere, solange es noch notwendig werden könnte, auf archivierte Daten zuzugreifen.
Fazit
Die wesentlichen Grundsätze sind vielen IT-Mitarbeitern in der Regel bekannt. Oft scheitert die konsequente Umsetzung aber am Alltag, den zu knappen Ressourcen oder aber an Begehrlichkeiten und Befindlichkeiten. Ergänzende Details werden gern übersehen.
Aber auch ohne die genannten Hürden entsteht bei größeren, wachsenden oder sehr agilen Umgebungen schnell Überforderung. Werden die notwendigen Prozesse nicht frühzeitig etabliert und ggf. mit Tools unterstützt, entstehen leicht Schieflagen, die sich nicht mehr ohne Weiteres korrigieren lassen.
In der Praxis lassen sich daher doch sehr oft Mängel beim Management entsprechender Changes feststellen. Ein klarer Genehmigungsprozess fehlt oder besteht nur ganz rudimentär. Zu viel geschieht auf Zuruf. Änderungen werden schnell, ohne Bewertung ihrer Kritikalität, ohne vorherigen Test und ohne Fallback-Möglichkeit durchgeführt. Und selbst wenn die gerade genannten Schritte grundsätzlich eingehalten werden, fehlt es am Ende meist an einer geeigneten Dokumentation. Falls sich überhaupt noch etwas nachvollziehen lässt, ist das erst nach einer langen und mühseligen Suche in E-Mails möglich. Ein gepflegtes Ticketsystem wäre deutlich einfacher.
Organisationen sollten daher auch hier auf einen klaren und detaillierten Changemanagement Prozess zurückgreifen, der insbesondere vorsieht: Genehmigung, Kritikalitätseinstufung, Installationstest und Prüfung der Fall Back Möglichkeiten, Umsetzung, Test, Dokumentation und Lessons-learned.