Der Frühjahrputz kommt: Hat Ihre IT-Architektur auch Staub angesetzt?

Autor
Markus Pfister
Veröffentlicht
22. Februar 2021

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.

Hier können Sie die Hausapotheke downloaden!

Wenn Sie eines der nachfolgenden Krankheitsbilder bezogen auf Ihr Unternehmen feststellen, könnte dies ein Anzeichen für IT-Sicherheitsarchitektur «Smells» sein:

  • Lange Entwicklungszeiten, eine grosse Arbeitsbelastung und ergo hohe Fehlerraten
  • Fehlende Dokumentation und mangelndes Wissen über die Komponenten
  • Shadow-IT, weil es auf dem ordentlichen Weg zu lange oder gar nicht geht
  • Analysis Paralysis: Projekte kommen nicht über die Analysephase hinaus

«Smells» entwickeln sich schleichend

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.

Das Problem an der IT-Wurzel packen: Ursachenforschung

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
Zielbild

 

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.

Auswirkungen der Altlasten: Schwerfälligkeit…

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.

  • Welche Anwendungen und Systeme verwenden den zu ersetzenden Algorithmus?
  • Wer kann den Sicherheitsfix implementieren?
  • Welchen Verwendungszweck haben die betroffenen Systeme und Anwendungen?
  • Welche Datenflüsse erfolgen über die betroffenen Systeme und Anwendungen?

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 &
Application
Owners finden

Konsultieren der Komponenten Owner-Liste.

Herumfragen

Betroffene
Komponenten finden

  1. Abfragen der Konfigurationsmanagement-Tools.
  2. Analyse der zentral verwendeten Krypto-Infrastruktur
  3. Einsatz von Scanning Tools, z.B. Analyse TLS-Handshake
  1. Code analysieren
  2. Code analysieren
  3. Herumfragen

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.

Langwierige Genesung

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.

Nachdenken hilft

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 ist Ihr kompetenter Partner in punkto IT-Sicherheitsarchitektur

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.

Jetzt Kontakt aufnehmen!

Artikel teilen