Hallo miteinander, hallo Stefan
Bisher habe ich mich zu diesem Thema auch eher zurückgehalten. Aber wenn nun schon danach gefragt wird, denn eben.
Wir leben im Zeitalter von DevOps (oder GitOps oder welches Buzzword man auch dafür verwenden mag). Von daher gilt für mich ganz klar die Prämisse, dass Security-Patches so schnell wie möglich ausgerollt werden sollten. Dabei kann natürlich eine gewisse Wertung bzw. Gewichtung nach CVE-Score gemacht werden aber Security-Patches nicht auszurollen, weil sie "nicht kritisch" sind ist für meine Begriffe der falsche Weg. Ein Security-Patch hat den Grund, ein bestimmtes Sicherheitsproblem zu korrigieren, sonst wäre es kein Security-Patch. Je mehr Wölfe da draussen in Betrieb sind, desto grösser ist die Chance, dass es
die eine Konstellation gibt, bei welcher dieses Problem tatsächlich ausgenutzt wird und dann steht ElabNET im Worstcase ganz schlecht da.
Ich bin mit diesem Thema täglich konfrontiert und es ist absolut nachvollziehbar, dass das die eher unschöne Seite der Softwareentwicklung ist. Aber heutzutage muss es nahezu zwangsläufig einen entsprechenden Prozess resp. eine Vorgehensweise geben, wie Security-Patches unabhängig von der eigentlichen Software ausgerollt werden können. Spätestens seit dem Log4Shell-Desaster Dezember 2021 gehört das einfach dazu.
Wenn dafür die gesamte Entwicklung still steht, dann ist i.d.R. am gewählten Verfahrensmodell oder der Infrastruktur etwas nicht für so einen Fall geeignet. Und selbst wenn dann mit dem Patch ein Problem auftritt, sollte die Entwicklung immer weiter vorwärts sein. Die schmerzfreiste Variante ist schlussendlich immer, wenn das Ausrollen von Patches nichts besonderes mehr ist, wenn es zum Daily-Business wird.
Mit anderen Worten, für das Patching muss entweder separate Test-Infrastruktur zur Verfügung stehen oder die bestehende Infrastruktur muss einen entsprechenden Wechsel erlauben. Nun ist das mit "dem Wechsel" bei einem Hardware-Lieferanten natürlich eine Herausforderung, völlig klar. Aber auch hier wächst man bekanntlich mit seinen Herausforderungen und kann bspw. unterschiedliche Test-Sets je nach CVE-Schweregrad fahren. Also bspw. ein monatliches Patch-Fenster für schwerere CVEs und ein viertel- oder halbjährliches für allgemeine System-Updates. Wenn das fix so eingeplant wird, kann es auch sehr viel besser kalkuliert werden. Wichtig ist aber, dass das losgelöst von den eigenen, also den ElabNET- resp. TW-Features ist!
Nachdem Stefan nach einem OS-Update und IPv6 gefragt hat: Natürlich erwarte ich das einfach so! Als Kunde interessiert mich nicht, welches System darunter läuft. Aber ich erwarte, dass es
a) funktional aktuell und
b) sicher
ist.
Das präzisiert m.M.n. das Dilemma recht gut: Die OS-Version ist total egal, solange sie sicher ist! Will heissen, bei einem Security-Scan sollten keine Alarmglocken losschrillen. Aber zudem sollten aktuelle Funktionen unterstützt werden und damit wären wir bei so Themen wie IPv6, welche ganz klar in die Kategorie "Feature" und nicht "Sicherheit" fallen.
Gut, bei Features wie eigenen Zertifikaten kann man sich auch streiten, ob das nun "Feature" oder "Security" ist...
Also unterm Strich: alles was die Sicherheit betrifft, insbesondere die Sicherheit des OS, wird je nach Gewichtung asap oder in einem planbaren aber fixen Zeitrahmen ausgerollt. Die Argumentation "internes Gerät, Sicherheit egal" kann ich nicht nachvollziehen. Schon allein aus Unternehmer- resp. Stefans Sicht ist das doch viel zu heiss bei einem allfälligen Problem in einem entsprechenden Presseartikel einen TW als Einfallstor zu sehen. Wenn die Wurzeln von ElabNET bei der Security liegen, dann liegt das aber auf der Hand.
Wenn ich nun von "Security" in Richtung "Features" gehe, dann bewegen wir uns zwangsläufig vom OS "unten drunter" in Richtung dessen, was das Gerät eigentlich macht, also welche eigene Software darauf läuft und welche Funktionalitäten zur Verfügung gestellt werden. Dass es an dieser Stelle weiter kompliziert wird, steht ausser Frage. Oder anders gesagt, genau das ist die Herausforderung und diese Herausforderung lässt sich nur mit immer weiter ausgebauter Testautomatisierung bewältigen.
Beispiel aus dem Job: Da das Projekt mittlerweile derartige Dimensionen angenommen hat, dass man es als Entwickler nicht mehr vernünftig lokal laufen lassen kann, hat jeder Entwickler und selbst jeder Test-Engineer einen eigenen, vollständigen Namespace auf OpenShift. Damit entspricht jeder dieser Namespaces in den relevanten Eckdaten nahezu der produktiven Umgebung. Zusätzlich gibt es noch verschiedene Umgebungen/Namespaces, welche gewisse Sonderkonstellationen abbildern. Am Anfang dieser Vorgehensweise hat man über die zu erwartenden Kosten die Hände über dem Kopf zusammengeschlagen. Diese Stimmen sind mittlerweile komplett verstummt, nachdem die Geschwindigkeit des Teams sowohl in Entwicklung als auch in allfälligem Bugfixing die Erwartungen übertroffen hat.
Will heissen, Testing hat seinen Preis aber es macht sich immer bezahlt und genau jetzt sind wir hier am "wunden Punkt". Ich würde es begrüssen, hinsichtlich der Ankündigung von Releases sehr viel kleinere Brötchen zu backen und diese Brötchen dafür sehr viel öfter zu verteilen. Es ist doch wesentlich angenehmer, wenn es "zwischendurch" ein kleines Update gibt, welches ein paar Interna auf den aktuellen Stand bringt, als damit zu warten, bis das nächste "grosse" Update-Paket geschnürt ist. Genau durch kleine Deliveries wird das Testing doch vereinfacht! Genau das ist auch die Idee davon, die monolithischen Systeme aus dem letzten Jahrtausend durch kleine, separate Komponenten zu ersetzen. Dass sich der Cloud-Ansatz bei einem System wie dem TW nicht 1:1 übertragen lässt, brauchen wir nicht zu diskutieren. Aber über den Tellerrand schauen, hat noch niemandem geschadet.
In diesem Sinne, just my two cents.
Schon in der nächsten 1.18.0 gab es zwei Security-Fixes, bei 1.19.0 wieder eines, ... 