IT-Service Walter
ISW Operations Center
Prüfen, bewerten, reparieren – für Windows-Serverlandschaften und Active Directory. Ein Werkzeug, das nicht nur sagt, was falsch ist, sondern es auf Anforderung auch in Ordnung bringt: mit Trockenlauf vorher, Nachprüfung danach und – bei 70 der 99 Maßnahmen – einer Rücknahme auf Knopfdruck.
Warum ein Prüfwerkzeug allein nicht reicht
Berichte gibt es genug. Der Aufwand entsteht danach: Jemand muss aus zweihundert Zeilen ableiten, was zuerst dran ist, den passenden Registrierungswert nachschlagen, ihn auf dreißig Servern setzen und hinterher prüfen, ob es geholfen hat. Genau diese vier Schritte nimmt das Werkzeug ab – ohne dabei eigenmächtig zu werden.
Vom Befund zur Maßnahme
Zu 134 der 437 Prüfungen ist eine ausführbare Maßnahme hinterlegt. Wo keine existiert, sagt das Werkzeug das – statt einen Ratschlag zu geben, den niemand umsetzen kann.
Vom Einzelfall zur Flotte
Derselbe Eingriff auf allen Systemen, auf denen der Befund tatsächlich vorliegt – wellenweise, mit Nachprüfung nach jeder Welle.
Von der Behauptung zum Nachweis
Nach jeder Änderung laufen genau die zugehörigen Prüfungen erneut. Die Ampel wird grün, wenn es belegt ist – nicht, wenn das Skript durchgelaufen ist.
Vom Eingriff zurück
70 Maßnahmen bringen eine Rücknahme mit, die das Werkzeug selbst ausführt – wertvergleichend, also nur, solange der Wert noch der von ihr gesetzte ist.
Drei Aufgaben, eine Kette
Erkennen, erklären, vorführen, ausführen, nachprüfen. Jeder Schritt hat seinen Platz, und keiner wird übersprungen. Eine Maßnahme, deren Wirkung niemand nachsieht, ist nur eine Behauptung.
Prüfen
437 Prüfungen von Active Directory über DNS, DHCP, Zertifikate, SMB, Kerberos und Gruppenrichtlinien bis zu Datensicherung, Cluster und Hardware-Frühwarnung. Der Katalog liegt als Daten vor, nicht im Programmcode – eigene Prüfungen lassen sich ergänzen, ohne neu zu übersetzen.
Je System wird zuerst die Rolle ermittelt. Prüfungen für Domänencontroller laufen deshalb nicht auf Mitgliedsservern und verfälschen deren Bewertung nicht.
Und eine Prüfung darf sagen, dass sie hier nichts zu messen hat. Ein Server ohne USV mit Datenanschluss bekommt dafür keinen grünen Punkt, sondern „nicht anwendbar“ mit Begründung – heraus aus Zähler und Nenner. Das ist etwas anderes als „nicht prüfbar“: Dort gab es eine Messlücke, die jemand schließen soll.
Bewerten
Ampeln und Schwellwerte statt Rohwerte, dazu acht Dimensionen der Betriebsbereitschaft, eine Langzeitbewertung der Stabilität, Ranglisten und die Frage, was sich seit dem letzten Lauf verändert hat.
Wahrscheinliche Ursachen ordnen die Befunde: nicht dreißig Meldungen, sondern eine Ursache und neunundzwanzig Folgen.
Reparieren
99 Maßnahmen zu tatsächlichen Befunden, ausgeführt über WinRM. Vorher ein Trockenlauf, der nichts schreibt und meldet, was vorgefunden wird. Danach laufen genau die Prüfungen erneut, die zur Maßnahme gehören.
70 Maßnahmen bringen eine Rücknahme mit, die das Werkzeug selbst ausführt. Wo das nicht geht, steht es dort – statt es zu verschweigen.
Was der Prüfkatalog abdeckt
437 Prüfungen in 56 Bereichen, verteilt auf 69 Katalogdateien. Nach Schweregrad: 65 kritisch, 181 hoch, 137 mittel, 54 niedrig. Der Katalog liegt als Daten vor – eigene Prüfungen und Maßnahmen lassen sich ergänzen, ohne das Programm neu zu übersetzen.
| Themenfeld | Prüfungen | Bereiche |
|---|---|---|
| Active Directory und Verzeichnis | 80 | Active Directory · AD-Design · AD-Hygiene · Replikation · DFS und SYSVOL · Gruppen · Gruppenrichtlinien · Kerberos · LDAP |
| Server, Dienste und Leistung | 82 | Serverzustand · Dienste · Leistung · Startzeiten · Ereignisprotokolle · Windows Updates · Features · Lizenzierung · WMI · IIS · Druckdienste · Exchange · Benutzererfahrung · Änderungen |
| Sicherheit und Härtung | 65 | Sicherheit · Registry-Härtung · SMB · Plattformsicherheit · PowerShell-Härtung · Windows-Internals · Compliance |
| Speicher, Sicherung und Hochverfügbarkeit | 38 | Dateiserver · Datensicherung · Cluster · Redundanz · Virtualisierung und Hyper-V |
| Netzwerk und Namensauflösung | 36 | DNS · DNS-Qualität · DHCP · DHCP-Optionen · Netzwerkpfad · Netzwerkverkehr · RPC und DCOM · Antwortzeiten |
| Kapazität und Hardware | 24 | Erschöpfung von Grenzwerten · Hardware-Frühwarnung · Firmware · Fristen und Ablaufdaten |
| Zertifikate und PKI | 16 | Zertifikate und AD CS · Zertifikatsqualität |
| Betrieb, Vorgänge und Nachweis | 48 | Betrieb und Selbstprüfung · Vorgänge · Betriebsabweichung · Wiederherstellung · Einzelfehlerpunkte · Technische Schulden · Lebensende und Fristen |
Der zweite Katalog: 372 Einstellungen – und woher ihr Wert kommt
Neben dem Prüfkatalog steht ein zweiter, der etwas ganz anderes misst. Der Prüfkatalog fragt nach einem Betriebszustand: Läuft die Replikation, ist die Sicherung aktuell, antwortet der Dienst. Der Härtungskatalog vergleicht 372 Registrierungseinstellungen – 357 davon eingeschaltet – gegen den Sollwert eines vereinbarten Profils. Das eine ist ein Zustand, das andere eine Empfehlung.
Die Frage, an der die meisten Werkzeuge vorbeimessen
Die Gruppenrichtlinie ist korrekt konfiguriert. Der Wert steht trotzdem falsch. Wer nur den Istwert liest, sieht eine Abweichung und keinen Grund – und sucht dann im Richtlinieneditor nach einem Fehler, den es dort nicht gibt.
Deshalb zeigt jede Einstellung vier Angaben statt einer: den Wert, den Windows tatsächlich liest, die Vorgabe des Richtlinien-Hive, den Sollwert – und die Herkunft.
Die Rangfolge
MDM schlägt Richtlinien-Hive schlägt direkt gesetzten Wert schlägt Windows-Standard. Steht in der Spalte Herkunft „MDM (Intune)“, ist das die Erklärung: Eine Intune-Richtlinie übersteuert dieselbe Einstellung, und die GPO greift ins Leere.
Auf einem Domänenmitglied wird zusätzlich gpresult ausgewertet und der Name der GPO genannt, die den Wert gesetzt hat. Der Wechsel der Herkunft ist dabei die aussagekräftigste Meldung überhaupt: Stammt ein Wert plötzlich lokal statt aus der Richtlinie, hat jemand von Hand eingegriffen – auch wenn der Wert derselbe geblieben ist. Das findet keine reine Wertprüfung.
Warum der Härtungsgrad niedriger ist, als Sie erwarten
„Nicht gesetzt“ zählt in den Nenner und nicht in den Zähler. Gemeint ist der Fall, in dem der wirksame Zustand zwar der Empfehlung entspricht, aber allein aus der Windows-Vorgabe folgt, weil niemand etwas gesetzt hat.
Das ist die Leitregel des Grundschutzes: Gefordert sind Richtlinien, die gesetzt sind. Eine Windows-Vorgabe beweist nichts – sie kann sich mit dem nächsten Funktionsupdate, einem anderen Abbild oder einer fremden Richtlinie ändern, ohne dass jemand es merkt. Ein gemessener Server 2025 fiel durch diese Regel von 26 auf 9 Prozent. Die 9 waren die ehrlichere Zahl.
Drei Wege zum Ausrollen – mit Sicherung
Registrierung direkt für Einzelgeräte und zum Prüfen, lokale Gruppenrichtlinie für Geräte ohne Domäne, Domänen-GPO für alles Übrige. Vor dem Anwenden steht die Simulation: dieselbe Liste mit Vorher- und Nachher-Wert, ohne dass etwas geschrieben wird.
Vor jeder Änderung legt das Werkzeug eine Sicherung an – eine Datei zum Doppelklicken und eine für die Rücknahme im Werkzeug. Ohne Sicherung wird nichts geschrieben; das ist keine Einstellung, die sich abschalten lässt.
Was Sie vereinbart haben, wird gemessen
Basis, Erhöht oder Hoch: Das Profil entscheidet, welche Einstellungen ein Lauf überhaupt anfasst. Wer von Hoch auf Basis wechselt, nimmt Einträge aus der Messung – und der Härtungsgrad steigt, ohne dass an einem System etwas geschehen wäre.
Das ist gewollt, aber es muss dabeistehen. Deshalb nennt jeder Bericht das gemessene Profil im Kopf, und zwei Berichte mit verschiedenem Profil sind ausdrücklich nicht vergleichbar.
Zwei Kataloge, zwei Zahlen – keine Vermischung
Die Abweichungen des Härtungskatalogs zählen nicht in die Befunde des Lagebilds, und sie erscheinen nicht in der Flottenreparatur. Wer viele Abweichungen sieht und wenige Maßnahmen, sieht keinen Fehler, sondern zwei getrennte Kataloge mit zwei getrennten Wegen.
Auch eine Ausnahme wirkt nur dort, wo sie gesetzt wurde: Wer eine Prüfung hinnimmt, bewegt den Betriebszustand – den Härtungsgrad rührt es nicht an. Die beiden teilen sich keinen einzigen Eintrag.
Das Lagebild über die Flotte
Die interessante Sicht ist nicht „Server A hat zwölf Befunde“, sondern „diese eine Prüfung schlägt auf dreißig Servern fehl“. Daraus wird eine Maßnahme statt einer Fleißaufgabe.
Handlungsbedarf nach Dringlichkeit
Schweregrad mal Verbreitung. Oben steht, was zuerst gehört – nicht, was alphabetisch zuerst kommt.
Betriebsbereitschaft in acht Dimensionen
Verzeichnis, Netzwerk, Sicherheit, PKI, Datensicherung, Hochverfügbarkeit, Serverbetrieb, Compliance – je System und über die Flotte gemittelt, jeweils nur über die Systeme, auf denen die Dimension gilt.
Stabilität über die Zeit
Der Betriebszustand sagt, wie es gerade steht. Diese Auswertung sagt, auf welches System über die Läufe hinweg Verlass war.
Veränderungen und Vorhersage
Was ist seit dem letzten Lauf neu, was hat sich verschlechtert, und wann läuft ein Datenträger voll – aus dem gespeicherten Verlauf, nicht aus einer Momentaufnahme. Prüfungen, die auf dasselbe Laufwerk zulaufen, stehen als eine Zeile: Vier Meldungen über dieselben freien Gigabyte lassen die Lage viermal so bedrohlich aussehen, wie sie ist. Die übrigen sind einen Doppelklick entfernt, verloren geht keine.
Keine erfundenen Zahlen in der Reihe
Manche Prüfung meldet einen Zustand als Zahl, damit er rot wird – „keine Schattenkopie vorhanden“ etwa als 9999 Stunden. Als Befund ist das richtig, in einer Messreihe wäre es Gift: Ein Sprung von 12 auf 9999 erzeugt eine Hochrechnung, die niemand gemessen hat. Solche Werte werden gar nicht erst fortgeschrieben. Es entsteht eine Lücke – und die ist ehrlich.
Sprechende Betroffenenlisten
Bei wenigen Systemen die Namen, bei vielen eine Aussage über Menge und Art: „42 von 47 Systemen · 5 Domänencontroller, 37 Server“. Die vollständige Liste ist einen Doppelklick entfernt.
Durchgriff bis zur einzelnen Maschine
Vom Befund über die Flotte zum betroffenen System, von dort zu allen seinen Prüfungen und zum tatsächlich ausgeführten Skript.
Wenn zwei Systeme sich unterscheiden sollten – und es nicht tun
Zwei Domänencontroller, zwei Clusterknoten, zwei gleich aufgesetzte Server: Einer verhält sich anders, und niemand weiß warum. Der Systemvergleich stellt beide nebeneinander und führt nur auf, worin sie sich unterscheiden.
Nur die Unterschiede
Bei 437 Prüfungen und 357 Einstellungen wäre eine vollständige Gegenüberstellung unlesbar – und Übereinstimmung ist ohnehin die Antwort, die niemand sucht. Zwei Reiter: Prüfungen für den Betriebszustand, Härtung für die Einstellungen.
Gleicher Wert, andere Quelle
Der unauffälligste Fall ist der wichtigste: Auf dem einen System steht die Einstellung per Gruppenrichtlinie, auf dem anderen zufällig lokal gesetzt. Heute verhalten sich beide gleich, und jeder Vergleich, der nur Werte prüft, meldet Übereinstimmung. Nach dem nächsten Neuaufsetzen trägt die Einstellung nur noch eines der beiden Systeme.
Schwellwerte, die zu Ihrem Haus passen
329 der 437 Prüfungen tragen eine Warngrenze, 325 davon zusätzlich eine kritische. Ob 15 % freier Plattenplatz knapp sind, hängt davon ab, ob die Platte 200 GB oder 8 TB hat. Eigene Grenzen lassen sich im Werkzeug setzen – mit Begründung, im Protokoll festgehalten und in einer eigenen Datei neben dem Katalog, damit der nächste Katalogstand sie nicht überschreibt. Die Vorgabe bleibt daneben sichtbar.
Der Vorschlag aus Ihren eigenen Messwerten
Die Katalogwerte sind an einer Umgebung geeicht. In Ihrer stehen andere Plattengrößen, andere Benutzerzahlen, andere Lastprofile – und ein Wert, der anderswo eine sinnvolle Warnung ist, ist bei Ihnen womöglich jeden Tag rot. Eine Ampel, die immer rot ist, sieht nach vier Wochen niemand mehr an; der Schaden ist nicht die falsche Zahl, sondern die abgestumpfte Aufmerksamkeit.
Nach einigen Läufen rechnet das Werkzeug deshalb einen Vorschlag aus dem, was es bei Ihnen selbst gemessen hat: die Warngrenze am Rand des Gewohnten, die kritische Grenze eine volle Bandbreite dahinter – nicht am höchsten Ausreißer, der eine Prüfung für immer stumm schalten würde. Gesetzt wird nichts von selbst, und wo ein Vorschlag großzügiger wäre als der Katalog, steht es dabei.
Der Befund, den Sie gerade nicht beheben
Ein Altsystem, das erst nach dem Jahresabschluss angefasst wird. Eine Einstellung, die eine Fachanwendung braucht. Ein Server, der in sechs Wochen ohnehin abgelöst wird. Ohne einen Umgang damit bleiben nur zwei Zustände – beheben oder rot lassen –, und rot lassen endet zuverlässig in Abstumpfung.
Nur mit Begründung, Namen und Frist
Ein Befund lässt sich bewusst hinnehmen, aber nicht stumm schalten: Es braucht eine Begründung, wer die Entscheidung trägt, und bis wann sie gilt. Aus einem liegengebliebenen Befund wird damit eine getroffene Entscheidung mit Wiedervorlage.
Die Frist läuft von selbst ab
Am Tag danach zählt der Befund wieder mit – es muss niemand aufräumen. Der Eintrag bleibt sichtbar stehen, damit der zurückgekehrte Befund nicht wie eine neue Verschlechterung aussieht.
Fristen nach Ihrem Haus
Welche Fristen zur Auswahl stehen, legen Sie in den Einstellungen fest – ab Werk 30, 60, 90 und 180 Tage; das freie Datumsfeld bleibt daneben bestehen. Unbefristetes Hinnehmen ist möglich, muss aber erst freigeschaltet werden: Eine befristete Ausnahme ist eine Entscheidung mit Wiedervorlage, eine unbefristete ist ein vergessener Befund mit besserer Presse.
Die Zahl bleibt ehrlich
Hingenommene Befunde fallen aus dem Zustandswert heraus – sonst brächte die Ausnahme im Betrieb nichts. Für sich allein wäre der Wert damit manipulierbar. Deshalb wird er zusätzlich OHNE Ausnahmen mitgeführt, und sobald überhaupt eine läuft, steht im Protokoll beides nebeneinander.
Im Bericht steht er weiter
Ausdrücklich nicht ausgeblendet: mit Begründung, Namen und Frist. Dazu ein eigener Bericht über alle laufenden und abgelaufenen Ausnahmen – die Gegenprobe zum Lagebild, denn er nennt genau das, was dort nicht mehr auftaucht.
Die Reparaturplattform
Ausgeführt wird nie von selbst, sondern immer auf ausdrückliche Anforderung – und erst, nachdem jemand den Plan gelesen hat.
Risikostufen statt Bauchgefühl
Jede Maßnahme trägt eine Stufe:
- gering wiederholbar, ohne dauerhafte Änderung
- mittel ändert die Konfiguration, Rücknahme im Werkzeug ausführbar
- hoch braucht einen Neustart oder lässt sich nicht zurücknehmen
Bei hohem Risiko verlangt der Reparaturplan einen Grund, bevor der Knopf überhaupt anspricht. Der Text landet im Ereignisprotokoll und in der Reparaturhistorie.
Reparatur über die Flotte, wellenweise
Ein Fehler auf einem Server ist ein Vorfall, derselbe Fehler auf dreißig Servern ist ein Ausfall. Deshalb wird gestaffelt gearbeitet: Eine Welle wird vollständig ausgeführt und nachgeprüft, bevor die nächste beginnt.
Meldet ein System in einer Welle einen Fehler, laufen die folgenden Wellen nicht mehr an. Die übersprungenen Posten bleiben sichtbar.
Reparaturketten nach Ursachen
Eine abweichende Systemzeit, ein volles Systemlaufwerk, eine gestörte Namensauflösung – daraus folgen zehn weitere Meldungen. Repariert wird zuerst die Ursache.
Danach prüft das Werkzeug nach, welche Folgefehler die Ursache mitgenommen hat. Was sich erledigt hat, wird gar nicht erst angefasst. Jeder ersparte Eingriff ist ein Eingriff, der nicht schiefgehen kann.
Historie und Erfahrung
Was wann auf welchem System geändert wurde, wer es angeordnet hat und ob es geholfen hat – dauerhaft gespeichert, als CSV auswertbar.
Der Plan zeigt zu jeder Maßnahme, was frühere Läufe bewirkt haben: „drei von vier nachgeprüften Läufen behoben“. Bewusst keine erfundene Erfolgswahrscheinlichkeit.
Was das Werkzeug bewusst nicht tut
Ein Wartungswerkzeug wird an der Stelle gefährlich, an der es mehr darf, als jemand überblickt. Diese Grenzen sind fest verdrahtet, nicht abschaltbar.
| Grenze | Warum |
|---|---|
| Nichts läuft automatisch | Es gibt keinen Selbstheilungsmodus. Jede Änderung braucht eine ausdrückliche Anforderung und einen bestätigten Plan. Prüfläufe dagegen lassen sich planen – sie ändern nichts. |
| Keine Objekte löschen | Keine Maßnahme entfernt Benutzer, Gruppen, Zertifikate, Dateien oder Datenbanken. Wo ein Befund nur durch Löschen zu beheben ist, sagt das Werkzeug das und überlässt es einem Menschen. |
| Keine Neustarts auslösen | Änderungen, die erst nach einem Neustart wirken, sind gekennzeichnet. Der Neustart selbst gehört in ein Wartungsfenster, nicht in einen Knopfdruck. |
| Keine Software installieren | Weder Rollen noch Features noch Anwendungen. Windows-Updates spielt das Werkzeug auf ausdrückliche Anforderung ein – je System, nach einer Rückfrage, nie über die Flotte auf Knopfdruck und nie mit einem Neustart von selbst. |
| Keine Bereinigung über die ganze Flotte auf Knopfdruck | Löschen ohne Sichtung der Ergebnisse ist der Punkt, an dem ein Wartungswerkzeug gefährlich wird. Bereinigt wird je System, nach einer Bestätigung, die jeden Posten einzeln nennt. |
Nachweis und Rahmenwerke
Was geprüft und was geändert wurde, muss sich hinterher belegen lassen – gegenüber einem Auditor genauso wie gegenüber dem Kollegen, der am Montag fragt, warum der Server anders eingestellt ist.
Lückenlose Protokollierung
Jede Aktion – Prüflauf, Vorschau, Ausführung, Rücknahme, Berichtsversand – geht in ein eigenes Windows-Ereignisprotokoll mit fester Ereigniskennung. Zentral auswertbar durch ein SIEM, unabhängig davon, ob interaktiv oder geplant gearbeitet wurde.
Reparaturhistorie
Wer wann auf welchem System was geändert hat, mit welcher Begründung und ob die Nachprüfung es bestätigt hat. Dauerhaft gespeichert und als CSV auswertbar.
Der Nachweis je Kontrolle
Dieselben Verweise, andere Blickrichtung: nicht „welche Rahmenwerke berührt diese Prüfung“, sondern „wie steht es um diese Kontrolle – und welche Prüfungen belegen das“. 1224 Verweise auf 173 Kontrollen in sieben Rahmenwerken, je Kontrolle einer von fünf Ständen: erfüllt, teilweise, verletzt, hingenommen oder nicht geprüft.
Der Erfüllungsgrad rechnet nur über die BEURTEILTEN Kontrollen. Was sich technisch nicht messen lässt – Schulung, Vertretungsregelung, Verträge –, steht unter „nicht geprüft“ und nicht unter „erfüllt“. Eine Zertifizierung ist das nicht und will es nicht sein; es ist die Auskunft darüber, was sich belegen lässt.
Übergabe an die Compliance-Kette
Ein Klick schreibt den Lauf als Evidenz heraus: je Kontrolle und System ein Erfüllungsgrad und ein Kurzbefund im Klartext, verankert an genau einem Control aus NIST SP 800-53. 418 der 437 Prüfungen tragen einen solchen Anker; das Auffächern auf ISO 27001, BSI, CIS und NIS2 übernimmt das ISW Compliance Cockpit. Ein weiteres Rahmenwerk kostet damit eine Zuordnungstabelle statt 437 neuer Verweise.
Ein hingenommener Befund wird dabei ausdrücklich nicht als erfüllt gemeldet, und was sich nicht messen ließ, gilt als nicht bewertet – nicht als in Ordnung. Der Zeitstempel ist der der Messung, nicht der der Ausfuhr.
Bezug auf Rahmenwerke
Jede der 437 Prüfungen trägt einen Normbezug: BSI IT-Grundschutz, ISO/IEC 27001:2022 Anhang A, NIST SP 800-53 Rev. 5 und, wo sie zutrifft, die CIS-Maßnahme. Die Angabe steht am Befund, nicht in einer separaten Tabelle – und in CSV und JSON, damit ein Prüfer sie nach seinem Baustein durchsuchen kann.
Berichte, die man weiterreichen kann
Jede Auswertung gibt es als HTML und als PDF, und jede lässt sich per Mail versenden – im selben Layout, mit dem PDF im Anhang.
Lagebericht über die Flotte
Betriebszustand, Handlungsbedarf nach Dringlichkeit, Bereiche, betroffene Systeme je Befund, Betriebsbereitschaft.
Prüfbericht des Einzelsystems
Alle Prüfungen mit Wert, Ampel, Begründung und Empfehlung – als Nachweis für ein Ticket oder eine Abnahme.
Stabilität und Bereitschaft
Die Langzeitbewertung je System und die acht Dimensionen über die Flotte, jeweils als eigener Bericht.
Versand über den eigenen Mailserver
SMTP mit STARTTLS oder SSL, das Kennwort AES-256-verschlüsselt gespeichert. Kein fremder Dienst dazwischen.
Alarmierung im eigenen Takt
Neun Regelarten – Befund, nicht erreichbar, Agent stumm, Kennzahl, Schlüsselwechsel, Messwert über Schwelle, Härtungsgrad, Ausnahme läuft ab und Verlässlichkeit. Gemeldet wird nur, was seit dem letzten Lauf NEU ist; ein bekannter Befund schweigt und meldet sich als Entwarnung zurück. Der Alarmlauf hat einen eigenen Takt und fährt nur die Prüfungen, die die aktiven Regeln nennen – deshalb sind Minutenabstände möglich, ohne die Zielsysteme mit dem vollständigen Katalog zu belasten.
Datenabfluss in Minuten statt Stunden
Eine eigene Schwelle auf den Ausgangs- oder Eingangsverkehr wird gegen das laufende Betriebsbild geprüft, nicht gegen eine stündliche Stichprobe. Ehrlich eingeordnet: Ein Schwellwert sieht viel Verkehr, nicht gestohlene Daten – er ist der erste Blick, kein Ersatz für NDR oder EDR.
Nichtwissen ist keine Entwarnung
Was ein Lauf nicht gemessen hat, beurteilt er nicht. Ein Lauf ohne ein einziges geprüftes System fasst den Meldestand gar nicht an, und ein Lauf über einen Ausschnitt des Katalogs entwarnt nichts außerhalb dieses Ausschnitts. Genau an dieser Stelle verlieren Werkzeuge sonst still ihre Aussagekraft.
Nachweis, was hinausging
Neben den offenen Meldungen führt das Werkzeug eine Rückschau: was tatsächlich verschickt wurde, mit Zeitpunkt, Empfänger und Zustellstand – auch dann noch, wenn der Vorfall längst erledigt ist.
Alarme auch nach Teams
Neben der Mail gehen Alarme wahlweise als Adaptive Card nach Microsoft Teams oder als JSON-Webhook an Slack, ntfy, n8n oder ein Ticketsystem. Nur über HTTPS, wahlweise nur bei Rot – wer nachts geweckt wird, soll geweckt werden, weil etwas kaputt ist.
Betrieb rund um die Uhr
Ein Prüfwerkzeug, das nur läuft, wenn jemand davor sitzt, sieht nur, was zwischen neun und siebzehn Uhr passiert. Der Wachdienst ist derselbe Prüfkern als Windows-Dienst – im eigenen Takt, ohne angemeldeten Benutzer, mit Alarm per E-Mail.
Der Wachdienst
Läuft als Dienst auf der Arbeitsstation und prüft die Flotte im eingestellten Takt. Neun Regelarten entscheiden, was gemeldet wird – Befund, System nicht erreichbar, Agent stumm, Kennzahl über Schwelle, Schlüsselwechsel, Härtungsgrad, ablaufende Ausnahme und mehr. Jede Regel hat eine Schonfrist, damit ein Flackern keine Mail wird.
Bedienen ohne Administratorrechte
Wer das Werkzeug öffnet, braucht keine Erhöhung: Läufe, Berichte und Einstellungen gehen über einen lokalen Kanal an den Wachdienst, der sie ausführt. Der Bediener sieht dasselbe Bild wie ein Administrator – nur ändern kann er nur, was ihm die Bedienergruppe erlaubt. Jeder Auftrag steht mit dem Namen des Aufrufers im Ereignisprotokoll.
Die Betriebsschau
Das Betriebsbild des Moments, im Takt abgefragt: fehlgeschlagene Anmeldungen, angemeldete Konten, über Freigaben gehaltene Dateien, interne und externe Verbindungen mit Durchsatz, knappster Datenträger, höchste Last, kritische Ereignisse und Verdachtsmuster. Jede Karte lässt sich in ein eigenes Fenster vergrößern; Betriebswertregeln machen aus einer Kennzahl einen Alarm.
Der Sammelpunkt
Für Systeme, die nicht angerufen werden dürfen – DMZ, Außenstandorte, Arbeitsgruppen – kehrt sich die Richtung um: Der Agent meldet sich beim Sammelpunkt des Werkzeugs und holt sich seine Aufträge ab. Eingehend muss auf dem Zielsystem nichts geöffnet werden. Beide Betriebsarten laufen nebeneinander, je System.
Der Agent pflegt sich selbst
Der Prüfkatalog liegt auf dem Agenten und wird bei einer Änderung von allein neu verteilt; ein Lauf schickt nur noch den Rahmen, nicht mehr hunderte Skripte. Eine neue Fassung des Agenten bietet das Werkzeug den markierten Systemen an – der Agent nimmt sie nur signiert, mit passendem Prüfsummenwert und vom selben Herausgeber an, tauscht sich selbst und startet neu. Von Hand installiert wird nur das erste Mal.
Nichts geschieht im Verborgenen
Was der Wachdienst prüft, meldet und ausführt, steht im selben Ereignisprotokoll wie die Arbeit am Bildschirm – mit Kennung, Zeit und Aufrufer, auswertbar durch ein SIEM. Ein Lauf, der ein System nicht erreicht, sagt warum; ein Alarm nennt die Regel, die ihn ausgelöst hat.
Technik und Voraussetzungen
Eine Arbeitsstation, von der aus gearbeitet wird. Auf den Zielsystemen wird im Regelfall nichts installiert.
| Punkt | Anforderung |
|---|---|
| Arbeitsstation | Windows 10/11 oder Windows Server ab 2016, .NET 10; erhöhte Rechte nur zum Einrichten – der Betrieb geht über den Wachdienst auch ohne |
| Bildschirm | Mindestens 2560 × 1440 Bildpunkte, empfohlen 27 Zoll oder größer – Lagebild, Flotte und die Befundtabellen sind auf diese Breite ausgelegt; darunter werden Spalten abgeschnitten |
| Zielsysteme | Windows Server ab 2016, PowerShell-Remoting über WinRM – im Regelfall agentenlos, auf den Zielsystemen ist nichts zu installieren |
| Wo WinRM ausscheidet | Optionaler ISW-Agent als Windows-Dienst – für DMZ, Arbeitsgruppen-Server und Häuser, in denen WinRM untersagt ist. Aufträge signiert mit ECDSA P-256, Freigabe über den Fingerabdruck; Abhol- oder Meldebetrieb je System, Prüfkatalog auf dem Agenten, Fernaktualisierung aus dem Werkzeug (Authenticode-geprüft) |
| Verbindung | WinRM, HTTPS über Port 5986 bevorzugt; auf einem Domänencontroller wird lokal gearbeitet |
| Anmeldungen | Angemeldeter Windows-Benutzer oder benannte Anmeldungen, Kennwörter AES-256-verschlüsselt |
| Verzeichnis | RSAT-Modul für Active Directory, wo Verzeichnisprüfungen gefragt sind |
| Kataloge | Prüfungen, Maßnahmen, Ursachenregeln und Wissensdatenbank liegen als Daten vor und sind erweiterbar |
| Nachvollziehbarkeit | Jede Aktion geht in ein eigenes Windows-Ereignisprotokoll – auswertbar durch ein SIEM |
| Rahmenwerke | Alle 437 Prüfungen mit Bezug auf BSI IT-Grundschutz, ISO/IEC 27001:2022, NIST SP 800-53 und CIS |
Bezug und Kontakt
Das Werkzeug wird als Lizenz erworben und läuft vollständig in Ihrer eigenen Umgebung. Fragen zum Umfang, zur Lizenzierung oder zum Einsatz in Ihrer Domäne beantworte ich am schnellsten am Telefon.
Support: support@it-service-walter.com
Schreiben Sie kurz, wie viele Systeme und welche Rollen – dann fällt die Antwort konkreter aus.
Shop
Die Werkzeuge der ISW-ADTools-Reihe werden über den Shop von IT-Service Walter vertrieben – Lizenz ohne Abonnement, unbegrenzte Laufzeit. Alle Angaben zu Ausstattung und Lizenzierung stehen auf der Produktseite.
