Wer kennt sie nicht: Die lästigen, teils «muffigen» Altlasten, die man vor sich hinschiebt. Nicht nur im Privaten, sondern auch in der IT hindern Altlasten, sogenannte Technical Debts, das Business. Höchste Zeit für einen IT-Frühlingsputz, um diese zu beseitigen. In diesem Blogbeitrag zeigen wir Ihnen, wo Altlasten lauern und wie Sie diese erkennen und beseitigen können.
In der Software-Entwicklung werden Code-Stellen, die nicht über alle Zweifel erhaben sind, als «Code Smells» bezeichnet. Auch in der IT-Sicherheitsarchitektur gibt es solche «Smells». Diese entstehen, wenn u.a. aus Sachzwängen, zu wenig Wissen oder Bequemlichkeit Best Practices nicht genügend befolgt werden. In unserer «InfoGuard Hausapotheke» werden die wesentlichen Komponenten einer IT-Sicherheitsarchitektur auf spielerische Art und Weise im Sinne von Organen, Krankheitsbildern, Erregern, Komplikationen und möglichen Medikamenten erläutert. Die folgenden Betrachtungen nehmen dieses Muster auf.
Wenn Sie eines der nachfolgenden Krankheitsbilder bezogen auf Ihr Unternehmen feststellen, könnte dies ein Anzeichen für IT-Sicherheitsarchitektur «Smells» sein:
Smell entwickelt sich mit zeitlicher Verzögerung. Unsachgemäss gelagerte Lebensmittel beginnen ja auch nicht am ersten Tag zu faulen… Unternehmen können eine Zeit lang die Pflege der IT-Sicherheitsarchitektur vernachlässigen. Die Auswirkungen sind meist erst nach einem oder mehreren Jahren sicht- und spürbar.
Bei Vernachlässigung der IT-Sicherheitsarchitektur entsteht eine zunächst unsichtbare Bugwelle, das sogenannte «Back Log». Bis die Folgen sichtbar werden, wird oft an mehreren Stellen gleichzeitig «gesündigt». Konsequenz: Die IT-Abteilung verliert die Fähigkeit, das Business zeitnah beim Betrieb und der Innovation von Services zu unterstützen. Die «Entsorgung» der Smells wird so lange zurückgestellt, bis die Bugwelle durch die bereits genannten unerwünschten Auswirkungen auftritt. Daher sollte die IT-Sicherheitsarchitektur im Unternehmen nicht nur nebenbei herlaufen, sondern erfordert aktive Aufmerksamkeit.
Die hier gezeigten Krankheitsbilder sind nicht abschliessend. Die Liste zeigt wichtige Ursachen von Smells in der IT-Sicherheitsarchitektur.
Krankheitsbild |
Erreger / Smells |
Komplikationen |
Medikament |
Copy / Paste
|
Funktionalität wird von Anwendung A in Anwendung B kopiert. |
Funktionalität muss doppelt (in Anwendung A und B) getestet werden.
|
Anwendung A stellt Anwendung B die Funktionalität über eine Schnittstelle (API) zur Verfügung. |
Zeitdruck
|
«Technical Debts» (Altlasten) werden aus Zeitmangel aufgebaut. |
Verlust der Fähigkeit, Technologien, die sich als «Commodity» etabliert haben, einzusetzen. |
Technologie-Stack so aktuell halten, dass marktübliche Technologien eingesetzt werden können. |
Wechselnde Anforderungen
|
Unklare Anforderungen führen zu vielen Scope-Änderungen. |
Zusätzliche Entwicklungs- und Testzyklen aufgrund ändernder Anforderungen; keine klaren Abnahmekriterien. |
Festlegen der Requirements und dem sich daraus ergebenden Scope. |
Fehlende Dokumentationen
|
Dokumentation wird später erstellt. |
Mitarbeitende können sich nicht effizient einlesen; fehlende Fähigkeit, neue Funktionalitäten zu erstellen. |
Funktionalität, Code und Dokumentation werden parallel erstellt und zugänglich gemacht. |
Fehlendes
|
Für jedes Projekt werden nur die spezifisch benötigten Komponenten erstellt; Insellösungen. |
Doppelspurigkeiten bei der Komponentenerstellung und Aufwand für deren Synchronisation; keine unternehmensweite Nutzung der Komponenten. |
Planmässiges Vorgehen mit Absprache in übergeordneten Gremien, z. B. IT-Sicherheitsarchitektur-Boards. |
Interne Interessens-konflikte
|
Unterschiedliche Auffassungen führen zu nicht kompatiblen Lösungsansätzen. |
Verschleiss von Energie und Frustration der Mitarbeitenden. |
Diskutieren der unterschiedlichen Auffassungen und Konsensfindung in Architektur-Gremien. |
Technologie-Gläubigkeit und Unwissen
|
Neu ist gut und löst alle Probleme, z.B. Cloud.
|
«Technologie-Zoo» und die Schwierigkeit, Mitarbeitende mit entsprechendem Know-how zu finden oder weiterzubilden; nicht zum Unternehmen passende Technologie-Stacks. |
Prüfen, ob die neuen Lösungsansätze in die bestehende IT-Sicherheitsarchitektur passen. |
Nehmen wir ein Szenario aus der Praxis, das sich auch in Zukunft absehbar wiederholen wird: Aufgrund einer Sicherheitsempfehlung soll ein schwacher kryptografischer Algorithmus nicht mehr verwendet und durch einen stärkeren ersetzt werden. Der CEO erachtet es als wichtig, die Kunden zeitnah zu informieren, dass die Sicherheitslücke erfolgreich geschlossen wurde. In der IT-Abteilung bricht Hektik aus: Task Forces und Eskalationen werden gestartet, die folgenden Aufgaben adressiert.
Wird Ihnen dieser Task zugewiesen? Dann besteht Ihre Aufgabe aus folgenden Teilschritten:
Ihre Aufgabe |
IT-Sicherheitsarchitektur ist... in gutem Zustand |
IT-Sicherheitsarchitektur ist... in schlechtem Zustand |
Komponenten finden
|
Konsultieren der unternehmensweiten Architekturbeschreibung mit den eingesetzten Komponenten. Konsultieren der CMDB. |
Herumfragen, «Reverse Engineering» |
System & |
Konsultieren der Komponenten Owner-Liste. |
Herumfragen |
Betroffene |
|
|
Abhängigkeiten identifizieren |
Konsultieren der unternehmensweiten Architekturbeschreibung mit den eingesetzten Komponenten. Konsultieren der CMDB. |
Herumfragen, Scannen |
Verletzlichen Algorithmus ersetzen |
Ändern der Konfiguration in der zentral verwendeten Komponente für Kryptografie. |
Korrektur im Code der Komponenten; Update der Systeme |
Testen und «deploy» (bereitstellen) |
Automatischer Build, Smoke Test und Deployment |
Manuelles Testen und Deployment |
Kundenkommunikation vorbereiten |
Konsultation der Komponentendokumentation (Anwendung A braucht Datenbank X) und Kunde Y hat diese Komponenten im Einsatz. |
Herumfragen |
Die Zusammenstellung zeigt: Abhängig vom Zustand der IT-Sicherheitsarchitektur im Unternehmen variiert das Vorgehen sowie der Aufwand. Je nach Zustand, kosten Sie diese Aufgaben viel Zeit, Energie und Nerven – oder ist lediglich ein «Standard-Task». Ist die IT-Sicherheitsarchitektur in einem guten Zustand, haben Sie die Gewissheit, keine wesentliche Komponente übersehen zu haben.
Wie bereits erläutert, können Unternehmen eine Zeit lang die Pflege der IT-Sicherheitsarchitektur vernachlässigen. Warten Sie jedoch zu lange, können die dadurch entstehenden Probleme Überhand nehmen und nur schwer bewältigt werden.
Oftmals werden Rufe laut wie «alles in die Cloud» oder Forderungen nach anderen radikalen Lösungsansätzen. Behandelt die Cloud-Migration die festgestellten «Krankheiten», kann die IT als Ganzes genesen. Andernfalls wird der Patient nur in ein anderes Krankenhaus verlegt.
Bei Fragen hinsichtlich der IT-Sicherheitsarchitektur bewährt sich wie so oft schlicht Nachdenken. Gefällte Architekturentscheide wirken langfristig. Darum sollten diese mit Bedacht und nicht unter Zeitdruck gefällt werden. Ebenso empfiehlt sich die umfassende Abstimmung mit betroffenen Stellen im Unternehmen. Damit werden gute Voraussetzungen für eine tragfähige Architektur und einen nachhaltigen Nutzen geschaffen.
Wann kann eine externe Unterstützung hilfreich sein? Ganz klar: Wenn das interne Wissen und die Erfahrung für IT-Sicherheitsarchitektur ungenügend ist oder ein Entscheid vor der Umsetzung auf den Prüfstand gestellt werden soll.
InfoGuard hat das Wissen und die Erfahrung aus verschiedenen Disziplinen der IT-Sicherheit. Ich und meine Kolleg*innen sind nicht nur in der IT-Sicherheit unterwegs, sondern auch in der Sicherheitsarchitektur zu Hause. Von diesem Wissensnetz profitieren bereits zahlreiche Kunden – vielleicht auch bald Sie?
Kontaktieren Sie uns! Wir beraten Sie gerne und finden die optimal passende, individuelle Lösung für ihre Bedürfnisse.