Meine größte berufliche Errungenschaft der jüngeren Zeit ist wohl, dass mein Vorgesetzter mich mittlerweile überzeugt auf Rettungsmission zu Kunden schickt, die aus irgendwelchen Gründen nicht mehr ganz zufrieden mit der Arbeit meiner Firma sind - im Glauben, dass ich das rausreißen kann. Wenn ich das so schreibe, klingt das ein wenig nach Himmelfahrtskommando in den Burnout, aber tatsächlich ist es harmlos. Ich bin gut darin, mit Menschen umzugehen und zu kommunizieren, und darum geht es bei diesen Missionen.
Die neueste dieser Geschichten hat mich interessanterweise in einen Bereich der IT-Sicherheit geworfen, mit dem ich vorher so gut wie gar keine Berührungspunkte hatte, nämlich Schwachstellenmanagement. Zur Erinnerung: Mein Standbein ist Log Management / SIEM. Da ich aber nicht mit dem Schwachstellenscanner selbst arbeite, sondern mit dessen Ergebnissen, brauche ich keine spezifischen technischen Kenntnisse hierfür, sondern muss im Grunde nur, wieder mal, kommmunizieren. Mein Input ist eine riesige Tabelle mit offenen Schwachstellen, die der Scanner ausgespuckt hat, mein Output sind Mails an die Verantwortlichen für kritische Schwachstellen und Telefonate mit ihnen.
Meine ersten Lektionen daraus sind die folgenden:
- Es ergibt ziemlich wenig Sinn, Ressourcen in das Design eines Priorisierungsverfahren für neue Schwachstellen zu stecken, solange es zwei Jahre alte offene kritische Schwachstellen im Netzwerk gibt.
- Schwachstellenmanagement in einer großen Organisation mit regulatorschen Auflagen ohne umfassende Automatisierung zu betreiben, ist aussichtslos und verschwendet Ressourcen.
- Wenn man den Prozess des Schwachstellenmanagements nicht Ende-zu-Ende dokumentiert hat, kann man mit der Automatisierung noch nicht einmal beginnen.
- Wie in jedem IT-security relevanten Prozess gilt: Wenn eine Excel-Tabelle dabei eine zentrale Funktion erfüllt, fehlt es an passenden Tools.
- Ohne das Erheben und Auswerten von Metriken weiß man noch nicht einmal, ob der aktuelle Prozess mit den neuen Schwachstellen überhaupt mithalten kann.
- Ich bezweifle, dass es für die Bewertung einer Schwachstelle tatsächlich relevant ist, ob bereits ein Exploit für sie existiert.
Die Organisation, bei der ich eingesetzt werde, hat ihr Schwachstellenmanagement kurz vor meinem Eintreten in das Projekt umgestellt und die Zeiten für das Einspielen eines Patches drastisch verkürzt. Grund dafür ist die Panikmache rund um Anthropics Modell “Mythos”, das angeblich rasend schnell Schwachstellen finden und Exploits für diese entwickeln kann. Die Aussicht auf eine schnellere Verfügbarkeit von Exploits hat die Organisation bewegt, den Patchzyklus zu kürzen. Immerhin - eine Automatisierung der Prozesse im Schwachstellenmanagement ist dafür aber aus meiner Sicht noch wichtiger. Mal sehen, ob ich den Kunden davon überzeugen kann.