Die Andreas Stihl AG & Co KG aus Waiblingen-Neustadt in der Metropolregion Stuttgart ist für ihre Motorsägen weltbekannt – und gilt bereits seit über 50 Jahren als Marktführer. Wie funktioniert die IT bei einem Unternehmen, das weltweit über 20.000 Mitarbeiter hat? Im Gespräch mit heise online gibt Jürgen Sitzler, der für Plattformsysteme zuständige Manager des großen Mittelständlers, Einblick in seine Arbeit.

heise online: Herr Sitzler, welche Aufgaben verantworten Sie bei Stihl?

Sitzler: Ich bin Manager Plattformsysteme. In meinem Team bündeln wir im Kern das, was man klassisch als Endpoint-Management für Windows versteht: die Plattformen für Windows-Clients und Windows-Server, inklusive Softwareverwaltung und Softwareverteilung als Standardsystem. Darüber hinaus liegen auch angrenzende Plattformthemen bei uns, etwa Intune als MDM-Komponente sowie Virtualisierung und Applikationsbereitstellung mit VMware und Citrix. Es geht dabei nicht nur um den Betrieb einzelner Tools, sondern vor allem um stabile, nachvollziehbare Prozesse: Standardisierung, Rollout, Lifecycle-Management, Patchen, Inventarisierung und die Fähigkeit, im Störungs- oder Sicherheitsfall schnell belastbare Aussagen treffen zu können.

heise online: In welchen Dimensionen bewegen Sie sich dabei?

Sitzler: Insgesamt sprechen wir über rund 25.000 Endpunkte. Je nachdem, wie man mobile Clients mitrechnet, kann das in der Praxis auch darüber liegen. Auf der klassischen Client-Seite haben wir ungefähr 17.000 Windows-Geräte. Macs spielen bei uns eine deutlich kleinere Rolle; wir liegen da bei etwa 50 MacBooks. Das allein macht den Schwerpunkt klar: Die Prozesse und das Tooling sind sehr stark auf Windows ausgerichtet, weil die Masse der Arbeitsplätze und viele Fachanwendungen dort verankert sind.

heise online: Viele Unternehmen sprechen derzeit über den Konflikt zwischen Operational Technology, also der Datenverarbeitung produzierender Systeme, und der restlichen IT. Ist das bei Ihnen ebenfalls ein Thema?

Sitzler: Ja, das ist bei uns sehr konkret. Wir arbeiten derzeit in einem Projekt daran, OT und IT stärker zu trennen. Historisch ist das oft zusammengewachsen; in der Realität ist das dann nicht selten ein gemeinsamer Verbund mit zu vielen Übergängen. Aus Security-Sicht ist diese klare Segmentierung ein wichtiger Schritt. Gleichzeitig ist es ein anspruchsvolles Vorhaben, weil Produktionsumgebungen eine andere Stabilitätsanforderung und häufig auch andere Update- und Wartungsfenster haben als klassische Office-IT.

heise online: Sie kommen aus der Ivanti-DSM-Welt. Warum ist das jetzt in Bewegung?

Sitzler: Wir nutzen aktuell noch Ivanti DSM in zentralen Teilen unserer Softwareverteilung und -verwaltung. Der wesentliche Treiber ist: DSM ist zum 31.12.2026 abgekündigt. Es gibt zwar ein Nachfolgesystem, aber aus unserer Sicht ist es derzeit funktional noch nicht auf dem Niveau, das für eine große Umgebung erforderlich ist. In der Folge sehen wir, dass viele DSM-Kunden den Markt neu bewerten. Auch wir prüfen, wie wir langfristig eine moderne, tragfähige Plattform aufstellen, die sowohl Client- als auch Server-Anforderungen abdeckt.

heise online: Welche Erwartungen haben Sie an ein Nachfolgesystem?

Sitzler: Entscheidend ist für uns die durchgängige Abdeckung: Server und Clients dürfen nicht in getrennten Welten landen, mit unterschiedlichen Datenmodellen, unterschiedlichen Agenten oder unterschiedlichen Betriebslogiken. Zusätzlich müssen Inventar, Konfigurationszustand, Compliance und Verteilung verlässlich skalieren. Es reicht nicht, dass etwas „irgendwie“ funktioniert; bei der Größenordnung müssen Aussagen reproduzierbar, Reports belastbar und Änderungen sauber steuerbar sein. Und nicht zuletzt ist die Geschwindigkeit relevant: Wie schnell sieht man den tatsächlichen Zustand im Feld, und wie schnell lassen sich Maßnahmen umsetzen?

heise online: Microsoft ist bei vielen Unternehmen gesetzt. Warum reicht das nicht?

Sitzler: Microsoft ist als strategischer Partner natürlich präsent, und auf der Client-Seite gibt es moderne Ansätze. In Gesprächen wird dann für Server-Themen jedoch häufig auf klassische Werkzeuge verwiesen, insbesondere SCCM, also der Microsoft Endpoint Configuration Manager. Für uns war das kein überzeugender Weg, weil wir eine zukunftsfähige Plattform suchen, die sich in den operativen Alltag gut einfügt und den heutigen Anforderungen entspricht. Unsere Ausgangslage war, dass wir bereits ein leistungsfähiges System hatten. Wenn man ablöst, sollte das Zielbild mindestens gleichwertig sein, in wichtigen Punkten besser, und langfristig tragfähig.

heise online: Wir sprechen mit einander auf Taniums Hausmesse Converge. Wie ist Stihl zu Tanium gekommen?

Sitzler: Tanium war in unserem Partner- und Marktkontext präsent, und wir haben die Lösung in der Evaluation konkreter betrachtet. Der zentrale Punkt war der Realtime-Ansatz. Viele Werkzeuge arbeiten stark datenbankgetrieben: Endpunkte melden in festen Intervallen, Daten werden gesammelt, verarbeitet und stehen dann im Reporting zur Verfügung. Das ist für viele Zwecke ausreichend, aber es hat einen Haken: Die Daten sind zum Zeitpunkt der Betrachtung häufig bereits veraltet. In ruhigen Zeiten ist das tolerierbar, aber in kritischen Situationen möchte man nicht mit dem Gefühl arbeiten, dass die letzten verlässlichen Informationen „vor fünf Minuten“ oder „vor einer Stunde“ waren.

heise online: Was bedeutet „Realtime“ für Ihren Alltag?

Sitzler: Realtime bedeutet nicht, dass jede Entscheidung automatisiert ist, sondern dass Abfragen und Sichtbarkeit näher an der Wirklichkeit liegen. In der Praxis heißt das: Wenn ich wissen muss, ob eine bestimmte Schwachstelle, ein bestimmtes Softwarepaket oder ein bestimmter Konfigurationszustand tatsächlich auf den Geräten vorhanden ist, möchte ich eine Antwort, die nicht primär eine historische Momentaufnahme aus einer Datenbank ist. Gerade im Sicherheitskontext ist das ein Unterschied.

Angriffe werden professioneller und schneller, und damit steigt der Wert aktueller Telemetrie. Außerdem ist auch die Bedienlogik relevant: Statt starre Reports zu bauen, kann man sich über gezielte Fragen schrittweise an eine Antwort herantasten. Diese Form des Arbeitens ist für viele Use Cases effizienter, weil sie den realen Diagnoseprozess besser abbildet.

heise online: Sie sind seit vielen Jahren bei Stihl. Wie hat sich das Thema Softwareverteilung historisch entwickelt?

Sitzler: Ich bin seit 2001 im Unternehmen. Interessant ist, dass es bei uns tatsächlich eine Historie gibt, die bis in frühe Softwareverteilungsansätze zurückreicht. Ein sehr frühes Produkt, das damals „NetInstall“ hieß, ist im Umfeld Stihls entstanden. Über verschiedene Stationen und Zusammenschlüsse ist das letztlich in der Produktlinie gelandet, die später als DSM bei Ivanti geführt wurde. Man könnte sagen: Das Thema ist bei uns seit langem präsent, und die Ablösung ist daher nicht nur eine Toolfrage, sondern auch eine Frage eingespielter Prozesse.

heise online: Welche Security-Werkzeuge sind bei Ihnen im Einsatz?

Sitzler: Wir arbeiten mit Microsoft Defender und CrowdStrike. Wichtig ist dabei weniger das Label des Produkts, sondern dass Abdeckung, Betrieb und Lizenzmodell zur Realität der unterschiedlichen Systemklassen passen.

heise online: Wie steuern Sie die Verwaltung von Macs und mobilen Endgeräten?

Sitzler: Macs verwalten wir über Intune. Allerdings muss man realistisch sagen: Bei uns ist macOS eine Ausnahme, weil viele Arbeitsprozesse, Vorlagen und Automatisierungen sehr stark auf Windows und Microsoft-Ökosysteme ausgerichtet sind. Bei mobilen Endgeräten setzen wir strategisch auf iOS und iPadOS und verwalten diese ebenfalls über Intune. Android gibt es bei uns vor allem im Shopfloor-Umfeld. Dort nutzen wir Soti, weil es im jeweiligen Anwendungsfall oft kostenseitig und organisatorisch besser passt, Geräte statt Benutzer zu registrieren und zu verwalten.

heise online: Wie wichtig ist aus Ihrer Sicht Security-Awareness?

Sitzler: Awareness ist wichtig, aber es ist kein Zustand, den man einmal erreicht und dann „abhakt“. Es braucht Wiederholung, Training und auch überprüfbare Formate, etwa Kampagnen und Tests. Gleichzeitig muss man die Realität im Unternehmen berücksichtigen: Mitarbeitende haben unterschiedliche Rollen, unterschiedliche digitale Vorerfahrung und vor allem einen klaren Arbeitsauftrag. Sicherheit steht oft im Spannungsfeld zur Nutzbarkeit. Deshalb ist aus meiner Sicht entscheidend, wirksame Maßnahmen so umzusetzen, dass sie den Betrieb möglichst wenig behindern. Ein Beispiel ist Patchen: Eine kurze Zielvorgabe, etwa innerhalb weniger Tage, ist sinnvoll. Gleichzeitig kann man den Zeitpunkt eines Neustarts in vielen Fällen flexibel halten, damit Arbeitsabläufe nicht unnötig gestört werden.

heise online: Wie sieht Ihre operative Sicherheitsorganisation im Hintergrund aus?

Sitzler: Es gibt eine eigene Cyber Security Abteilung. Diese stellt neben der entsprechenden Governance ebenfalls Services wie Threat Intelligence & Posture Management, Cyber Defense und Security Architecture. Außerdem werden hier Maßnahmen zur weiteren Stärkung der Security Culture umgesetzt und mit regelmäßigen Trainings untermauert.

Zur Sicherstellung der Wirksamkeit unserer Bemühungen sind regelmäßige externe Auditierung (beispielsweise Red-Team-Assessment und PenTests) vorgesehen, da die interne Wahrnehmung von der Realität abweichen kann.

heise online: Wie bewerten Sie die aktuelle Bedrohungslage?

Sitzler: Sie ist aus meiner Sicht deutlich ernster geworden. Operativ hilft es nicht, in Alarmismus zu verfallen, aber man muss das Thema mit großem Respekt behandeln. Durch Large Language Models sinkt die Einstiegshürde für das Erstellen von Code erheblich. Früher scheiterte manches daran, dass Angreifende Skripte zumindest verstehen und anpassen mussten. Heute kann das durch generative Systeme deutlich schneller gehen. Wenn Angriffe stärker KI-gestützt stattfinden, wird die Verteidigung ebenfalls stärker KI-gestützt sein müssen, allein um Geschwindigkeit und Skalierung halten zu können.

Das Interview wurde auf der Tanium Converge 2025 geführt. Der Autor reiste auf Einladung von Tanium.

(bsc)

Der große KI-Deal zwischen Apple und Google ist offensichtlich besiegelt: Google-Technik stellt künftig die Basis für Apples Foundation-Modelle, wie der iPhone-Konzern am Montag gegenüber CNBC mitteilte und zugleich betonte, das sorge für „innovative neue Erlebnisse“. Die Entscheidung sei nach eingehender Prüfung getroffen worden, hieß es weiter. Es handelt sich um eine auf mehrere Jahre angelegte Partnerschaft, die sowohl Googles Gemini-Modelle als auch Googles Cloud-Technik umfasst, schreibt CNBC. Konkrete weitere Details sind bislang noch nicht durchgedrungen.

Apples eigene Foundation-Modelle praktisch gescheitert

Der Schritt wäre ein stilles Eingeständnis, dass Apple die Eigenentwicklung wettbewerbsfähiger Foundation-Modelle offenbar nicht stemmen konnte. Aktuell setzt der Konzern für Apple Intelligence auf zwei hauseigene Sprachmodelle: Ein kompaktes, das lokal auf den Geräten läuft, sowie ein mittelgroßes in Apples Cloud. Fähigkeiten und Funktionsumfang sind begrenzt. Als Erweiterung ist über die Apple-Intelligence- und Siri-Bedienoberfläche außerdem ChatGPT verfügbar – läuft dafür aber auf OpenAIs Servern.

Nach dem verstolperten Start von Apple Intelligence und aufgeschobenen Neuerungen bei Siri hat Apples KI-Chef seinen Posten im Dezember geräumt, dieser wird auf höchster Ebene nicht mehr nachbesetzt. Apple hat aber einen neuen AI-Manager angeheuert, der zuvor als Engineering-Chef des Gemini-Chatbots bei Google gearbeitet hatte. Der Schritt untermauerte bereits ältere Gerüchte, dass KI-Modelle auf Gemini-Basis letztlich Siri auf neue Beine stellen sollen.

Gemini-Modelle sollen Siri aufmöbeln

Vor zwei Jahren hat Apple einen massiven Neuanfang für das als vollkommen überaltert geltende Sprachassistenzsystem Siri in Aussicht gestellt: Siri sollte demnach mit persönlichen Daten des Nutzers arbeiten und Aktionen über Apps hinweg ausführen können. Erste Funktionen wurden bereits in einer Werbekampagne vermarktet, bis Apple schließlich einräumen musste, mehr Zeit für die Umsetzung zu benötigen. Die Features sollen nun im laufenden Jahr folgen.

Google hat mit seinem jüngsten Modell Gemini 3 für Wirbel in der Branche gesorgt und zum Jahresende OpenAI erstmals sichtlich unter Druck gesetzt. Dort wurde mit hektischen Modell- und Funktionsneuerungen rund um ChatGPT gekontert.

(lbe)

Noch im Dezember veröffentlichten die Entwickler von OpenZFS die Version 2.4.0 ihres selbstheilenden Dateisystems, das aus dem vor über 20 Jahren für Solaris entwickelten ZFS von Sun Microsystems hervorgegangen ist. Explizit werden Linux-Kernel 4.18 bis 6.18 sowie FreeBSD 14, das aktuelle Production-Release 15 und die in rund zwei Jahren kommende Version 16 („-current“) unterstützt.

Ein Patch von Ameer Hamza führt Standard-Quotas für Benutzer, Gruppen und Projekte in OpenZFS ein – inklusive Objekt-Quotas – und sorgt so für eine konsistente Begrenzung, auch wenn keine individuellen Limits gesetzt sind. Dazu werden Kernel- und Userspace-Werkzeuge (zfs {user|group|project}space) unter FreeBSD und Linux angepasst, so dass Standard-Quotas angezeigt werden, falls keine individuellen Quotas konfiguriert wurden.

Eine Änderung von Alexander Motin erweitert die ZIL-Allokation so, dass bei fehlendem SLOG auch Special-vdevs (typischerweise SSDs) für ZIL-Blöcke genutzt werden, um unlogische Zuordnungen mit höheren Latenzen auf HDDs zu vermeiden. Damit können HDD-Pools mit einem schnellen Special-vdev synchrone Workloads besser bedienen. Das geht dann ohne zusätzliches SLOG und erlaubt in gewissen Grenzen den Verschleiß von SSDs zu minimieren.

Joel Low hat bereits im Februar letzten Jahres Code von Googles BoringSSL nach OpenZFS portiert, was angeblich eine bis zu 80 Prozent schnellere Verschlüsselung bringen soll. Dazu verwendeten die Entwickler bei Google eine Vector-AES-optimierte AES-GCM-Implementation (Galois/Counter Mode), bei der auf AMD Zen3-CPUs das schnelle AVX2 statt AVX512/AVX10 eingesetzt wird.

Drei neue Befehle

Wer OpenZFS 2.4.0 einsetzt, sollte sich mit drei neuen Befehlen vertraut machen: „zfs rewrite -P“ versucht beim erneuten Schreiben von Blöcken die Birth Time beizubehalten und so Zeit und Ressourcen einzusparen, da sich die eigentlichen Daten ja nicht ändern. Mit „zpool scrub -S -E“ kann das Scrubbing auf bestimmte Zeiträume (basierend auf Transaction Groups / TXG) begrenzt werden – im Commit [ werden aber einige Probleme gemeldet. Mit „zpool prefetch -t brt“ schließlich sollen die Metadaten der BRT (Block Reference Table) vorab in den ARC (Adaptive Replacement Cache) eingelesen werden, um Block Cloning und das Freigeben von Blöcken zu beschleunigen (dazu unten mehr).

Die Mehrheit der Commits kommen von Rob Norris (229 Commits) und Alexander Motin (119 Commits), beide arbeiten für das auf FreeBSD, ZFS und ARM spezialisierte Unternehmen Klara. Acht Entwickler haben Commits im zweistelligen Bereich, der überwiegende Teil beschränkt sich auf genau einen Commit.

Ohne Cache schneller schreiben und Ärger mit den „Gang Blocks“

Während obige Neuerungen aus einzelnen Commits bestehen, bestehen vier Bereiche des neuen OpenZFS 2.4.0 aus einer ganzen Reihe von zusammengefassten Detailverbesserungen: Uncached I/O, Gang Blocks, Deduplication und Block Cloning. Alexander Motin arbeitet an der Optimierung von Uncached I/O-Operationen, die von der Performance her zwischen dem schnellen Direct I/O (mit Beschränkungen wie page alignment) und dem regulären Cached I/O liegen. Scheidet Direct I/O in bestimmten Szenarien aus, soll es einen Fallback auf Uncached I/O statt wie bisher auf das noch langsamere Cached I/O geben.

Mehrere Fixes sollen den Einsatz von „Gang Blocks“ verbessern. Gang Blocks sind eine Art Notfallmechanismus von ZFS, der greift, wenn für einen großen Daten- oder Metadatenblock kein zusammenhängender freier Speicherplatz mehr verfügbar ist. In diesem Fall zerlegt ZFS den Block in mehrere kleinere physische Blöcke und speichert zusätzlich mindestens zwei redundante Gang Block Header, die auf diese Teilblöcke verweisen, sodass der Block logisch weiterhin als Einheit behandelt werden kann. Eine der Verbesserungen ist, die Größe der Gang Block Header von fixen 512 Byte auf eine beliebige dynamische Größe zu verändern.

Die ins Gigantische wachsende Datensammelwut von Konzernen und Regierungen macht Optimierungen bei der Deduplizierung von OpenZFS besonders notwendig. Alleine acht Commits sollen OpenZFS 2.4.0 dabei helfen, Speicherplatz zu sparen.

Sorgenkind Block Cloning gefixt – oder doch nicht?

Wie Alexander Motin klarstellt, wurde bei der ursprünglichen Implementation des Block Clonings ein struktureller Fehler gemacht, der die „BRT ZAP Entries“ betrifft, nun aber korrigiert ist. Block-Cloning erlaubt es, Dateien oder Teile davon zu kopieren, indem nur Referenzen zu bestehenden Blöcken angelegt werden, statt Daten zu duplizieren. Das spart Platz und Zeit, weil die Daten nicht erneut geschrieben werden müssen.

Die Block Reference Table (BRT) ist ein neues Metadaten-Objekt in OpenZFS (eingeführt in 2.2), das Block-Cloning beziehungsweise „Reflinks“ unterstützt. OpenZFS speichert die BRT-Einträge in einem ZAP-Objekt. ZAP (ZFS Attribute Processor) ist eine flexible On-Disk-Struktur für Schlüssel/Wert-Daten, beispielsweise Verzeichnisse, Eigenschaften oder eben Referenztabellen. Weitere Fixes sollen das Block Cloning von OpenZFS stabiler und weniger fehleranfällig machen. Fehlerhaftes Block Cloning sorgte bereits bei OpenZFS 2.2.0 für Datenverluste.

Ist manche NVMe-Hardware nicht OpenZFS-kompatibel?

Neben den Problemen durch Block Cloning scheint OpenZFS auch mit NVMe-Pools ein wenig auf Kriegsfuß zu stehen. Neben Kommentaren bei OpenZFS-Postings oder Foreneinträgen gibt es auch lange Diskussionen, beispielsweise auf Github. In fast allen diesen Diskussionen wird auf Probleme insbesondere mit NVMe-Laufwerken hingewiesen, SATA- und SAS-HDDs/SSDs scheinen weniger betroffen zu sein. Ob der Fehler dabei im OpenZFS zu suchen ist, oder ob es sich um Hardware-Probleme handelt, ist nicht immer klar und sorgt für teilweise hitzige Auseinandersetzungen.

Eine weitere Möglichkeit wäre, dass manche NVMe-Hardware von OpenZFS unter hoher Last einfach überfordert ist. Wenn diese Hardware mit anderen Dateisystemen oder sogar älteren ZFS-Varianten funktioniert, und wenn auch das aktuelle OpenZFS auf anderen Systemen fast überall sauber läuft – ist dann die spezielle Kombination das Problem? Vielleicht ist auch ein genauer Blick auf die eingesetzte NVMe-Controller-Hardware und dessen Firmware sinnvoll? Vor allem Consumer-Hardware wird oft hart an der Spezifikationsgrenze gebaut und könnte dann unter härteren Bedingungen von OpenZFS zu Fehlern neigen. Das Problem sollte genau analysiert werden, da vor allem leistungsfähige OpenZFS-Installationen gerne auf NVMe-Hardware aufbauen.

OpenZFS ist verfügbar für GNU/Linux, FreeBSD, NetBSD, macOS, OpenSolaris, Illumos und OpenIndiana. Der Quellcode von OpenZFS 2.4.0 liegt zusammen mit einer ausführlichen Liste aller Neuerungen und Änderungen auf Githuv.

(axk)