​

Stell dir eine IT-Messi-WG vor. Überall liegt Dreck herum, Zettel stapeln sich, Laptops türmen sich zwischen Servern und Geräten, die noch in Verwendung sind – oder auch nicht. Wer weiß das schon?

Irgendwann erbarmt sich jemand und startet eine Aufräumaktion. Auf die Frage “Wem gehört dieser Server?” folgt nur Stille. In Filmen würde ein Dornenbusch von links nach rechts rollen, aber dafür ist hier einfach kein Platz.

Irgendwann reißt der Geduldsfaden, der Stecker wird gezogen und in einer Ecke verstaut.

Einige Tage später kam dann ein Schrei aus dem Nichts: “Meine WICHTIGE Anwendung funktioniert nicht mehr!!! Wie kann man nur so grausam sein … ohne Bescheid zu geben!!!!”

Klingt radikal, ist es aber auch.

Was ist ein Scream-Test?

Wie eingangs im Beispiel erwähnt, ist es eine bewusste Unterbrechung eines Systems, um herauszufinden, ob und von wem es noch gebraucht wird. In kleineren Umgebungen ist das eher unüblich, aber in größeren Firmen mit globalen Teams und ständig wechselnden Mitarbeitern manchmal unvermeidbar.

Ich vergleiche den Scream-Test gerne mit einem Elektro-Schaltschrank in einem alten Haus. Wer weiß schon genau, welche Sicherung, welche Steckdose oder welches Licht schalten? Ob ihr wirklich richtig steht, seht ihr, wenn das Licht ausgeht. 😬

In einer perfekten Welt mit perfekter Dokumentation bräuchten wir den Scream-Test nicht. Aber in der Praxis sieht das oft anders aus. Deshalb ist es ein gutes Werkzeug, wenn man mal festsitzt und nicht weiterweiß. Er ist eine brutal ehrliche Methode, um Klarheit zu schaffen.

Bitte nicht falsch verstehen. Der Scream-Test ist keine pragmatische und einfache Lösung, sondern der letzte Ausweg. In diesen Fällen kann er ein guter Helfer sein:

• Legacy-Systeme ohne verantwortliche Personen
• Altlasten vor dem großen “Asset Management Projekt”
• VMs die ohne Prozess mal schnell erstellt wurden, nur um etwas zu testen
• Nach Firmen-Zusammenschlüssen (Merger & Acquisition)
• User- und Service-Accounts die nicht mehr in Verwendung sind

Meine persönlichen Erfahrungen

Projekt 1

Ich wurde für ein interessantes Security-Projekt bei einem DAX-Konzern gebucht. Ich sollte das Schwachstellenmanagement aufbauen und in die bestehenden Prozesse des Konzerns integrieren.

Der erste globale Scan hat mehr als eine Million Schwachstellen gefunden. Der IT-Infrastruktur-Chef ist fast vom Sessel gekippt. Es hätte mich brennend interessiert, wie er das dem Vorstand beigebracht hat. 😂

Das Ziel war klar: Die kritischsten Schwachstellen finden und eliminieren. Teilweise hatten einzelne Server bereits mehrere hundert Schwachstellen. Diese Superspreader bekamen natürlich Vorrang.

Das Problem: Niemand fühlte sich dafür zuständig. In einem Konzern mit mehr als 5.000 IT-Mitarbeitern und teilweise 20 Jahre alten Systemen ist das eine echte Sisyphusarbeit. Als neuer Externer sogar noch mehr – selbst mit den alten Hasen an Bord.

Wir hatten viele Ideen, wie wir unser Ziel erreichen können, und in 98 % der Fälle hat es auch funktioniert. Diese Methoden haben wir verwendet:

• User-Anmeldungen auf den Systemen überwachen, aber auch die Leute befragen, die bereits mal auf dem Server angemeldet waren.
• Die uralten Notes Datenbanken aus dem uralten Bestell-Formular auswerten. Denn, wer den Server bestellt und bezahlt hat, der weiß üblicherweise, wofür er gebraucht wird. Spoiler: Teilweise haben sich die Agents vom Service-Desk selbst als “Owner” eingetragen, weil sie die Infos nicht hatten und sonst das Ticket nicht schließen konnten. 🤦‍♂️ Das war oft eine Sackgasse.
• Firewall-Freischaltungen analysiert. Wer auf den Server zugreifen darf, weiß vielleicht mehr darüber. Aber auch, wenn der Server ausgehende Verbindungen zu anderen Systemen hat.
• Die lokalen IT-Verantwortlichen aus über 100 Ländern befragt und gebeten ihre Leute zu fragen, ob sie etwas über die Systeme wissen.

Dort wo wir uns ziemlich sicher waren, dass die Server nicht mehr in Verwendung waren, haben wir sie vom Netzwerk getrennt und 30 Tage gewartet, ob sich jemand meldet. Wir wollten ja schließlich nichts kaputt machen und die Server schnell wieder online bringen können. Danach haben wir sie runtergefahren und nach 180 Tagen wurden sie schlussendlich gelöscht.

Wir hatten auch schon einen kuriosen Fall, da hat sich jemand nach 9 Monaten erst gemeldet, weil er den Server nur 1x pro Jahr benötigt hatte. 🤷‍♂️

Das war zwar nicht meine geschmeidigste Arbeit, aber bei über 100.000 Systemen insgesamt, war ein Scream-Test leider manchmal unvermeidlich.

Projekt 2

In einem anderen Projekt hat ein Konzern eine ganze Division verkauft und auf zwei eigenständige Konzerne aufgeteilt. Ich war bei diesem Carve-Out dabei und durfte das Active Directory migrieren und aufräumen. Es herrschte großer Zeitdruck, die IT-Abteilungen wurden zerrissen und damit auch die Kommunikationsbrücken.

Nach der Migration habe ich allein über zwei Jahre damit verbracht, das AD zu säubern. 🤦‍♂️ Das Szenario war ähnlich zum vorherigen Projekt. Ich musste die Verantwortlichen für User und Computer-Accounts identifizieren, den Verwendungszweck hinterfragen und in die neue Namenskonvention überführen.

Die User-Accounts konnte ich ganz gut mit den aktiven Mitarbeitern der Personaldatenbank abgleichen. Leider war nicht jede HR-Abteilung in jedem Land sauber gepflegt. Gerade in den USA, wo es immer wieder kurzfristige Anstellungen und Entlassungen gab, war es, sagen wir einmal eine “Herausforderung”. 😅

Die Computer-Accounts von Windows-Servern und Clients waren kein Problem. Bei 3rd-Party-Devices, also IoT-Geräten und Linux-Maschinen, gab es dann einige Schwierigkeiten. Die waren im Active Directory teilweise nur als Platzhalter angelegt. Das war echt nicht sauber.

Die größten Probleme hatte ich allerdings mit den Service-Accounts. In der Zeit des mehrjährigen Carve-Outs wurde dort gefühlt für ALLES ein Service-Account beantragt. Jemand benötigt einen Admin-Account? Der musste approved werden und dauert daher einige Tage. Service-Accounts hingegen gab's innerhalb weniger Stunden.

Ich habe Praktikanten, externe Projektmitarbeiter, Multi-User-Accounts, Admin-Accounts und noch vieles mehr, getarnt als Service-Accounts gefunden.

Die harten Nüsse habe ich dann so identifiziert, dass ich sie deaktiviert und gewartet habe. Das war zwar auch nicht die feine englische Art, aber in diesem Fall absolut notwendig.

Wie vermeidet man Scream Tests?

Kurze und knackige Antwort: Ein funktionierendes Asset Management. Am besten wäre es natürlich, wenn neue Netzwerkgeräte gleich automatisch erfasst werden. Über dieses Thema habe ich in diesem Beitrag bereits ausführlicher geschrieben.

Hier die Kurzfassung: Mach für jedes Gerät mit IP-Adresse einen Eintrag in der Asset-Datenbank und schreib dazu, wer dafür zuständig ist.

Wenn die Person das Unternehmen verlässt oder die Abteilung wechselt, kannst du diese Geräte bei der Übergabe auch mitberücksichtigen.

Das Gleiche solltest du auch bei deinem Identity Management machen. Verknüpfe jeden User- und Computer-Account, und jede Gruppe mit einer Person, die du im Notfall fragen kannst.

Fazit

Ordnung schafft Sicherheit

Wenn du nicht mal weißt, wem die Systeme gehören, dann wirst du sie auch nicht warten, oder mitbekommen, wenn sie von Hackern genutzt werden.

Andernfalls wird es bald nicht nur die IT sein, die schreit. 😜