ISO 27001 und TISAX konkret: Firewall-Anforderungen mit XGS und M365 umgesetzt

ISO-27001-Firewall-Anforderungen, TISAX-Netzwerksicherheit — wer vor Zertifizierung oder Assessment steht, sucht keine Norm-Nacherzählung, sondern die Übersetzung: Welcher Control heißt was für die XGS-Konfiguration, und womit weise ich es nach? Die Kurzantwort vorab: Der Auditor will keine Feature-Liste, sondern gelebte Controls — und gelebt heißt konkret: Es gibt eine Richtlinie, die es sagt, eine Konfiguration, die es tut, und ein Protokoll, das es beweist. Ein aktiviertes IPS ohne Richtlinie und Alarmnachweis ist auditlogisch kein umgesetzter Control, sondern ein Feature im Leerlauf. Dieser Artikel liefert die Übersetzungsarbeit komplett: die netzwerknahen Controls des Annex A im Überblick (mit der TISAX-Einordnung für die Automotive-Welt), das Mapping auf XGS- und M365-Funktionen samt Nachweisform, die Segmentierung als notorisches Dauerbrenner-Finding, das Änderungs- und Regelwerks-Management, den Ablauf des Audit-Tags — und die typischen Findings samt Gegenmaßnahmen, damit sie im eigenen Bericht gar nicht erst auftauchen.

Die netzwerknahen Controls im Überblick

Der Annex A der ISO 27001 umfasst in der 2022er Fassung 93 Controls in vier Themenfeldern — und für die Firewall-Welt relevant ist ein gutes Dutzend, das sich sinnvoll in fünf Cluster ordnet, wie die Mapping-Skizze zeigt. Cluster eins, die Netz-Architektur: Netzwerksicherheit (8.20), Sicherheit von Netzwerkdiensten (8.21) und die Netztrennung (8.22) — das Segmentierungs-Thema, dem Kapitel 3 gehört. Cluster zwei, die Verkehrs-Kontrolle: der Schutz gegen Schadsoftware (8.7) und — bemerkenswert — die Web-Filterung (8.23), die mit der 2022er Revision zum eigenständigen Control wurde: Was früher unter Sammelbegriffen lief, fragt der Auditor heute explizit ab, womit die klassischen XGS-Disziplinen von Web-Schutz bis [LINK: A7]-Inspection auditrelevanter geworden sind denn je. Cluster drei, Sichtbarkeit und Zeit: Protokollierung (8.15), Überwachung (8.16) und die Zeitsynchronisation (8.17) — die [LINK: C4] bereits als Beweisgrundlage seziert hat. Cluster vier, Zugang und Privilegien: sichere Authentifizierung (8.5) und privilegierte Zugriffsrechte (8.2) — für die Firewall heißt das Admin-MFA und Rollen statt Sammelkonto. Cluster fünf, Betrieb und Änderung: Konfigurationsmanagement (8.9), Änderungssteuerung (8.32) und dokumentierte Betriebsverfahren (5.37) — Kapitel 4. Wer Automotive-Kunden bedient, liest das alles doppelt — der Faktenkasten ordnet TISAX ein.

Das Mapping: Control → XGS-/M365-Funktion → Nachweis

Damit zur Kernarbeit — und zur wichtigsten Lesehilfe vorab: Die dritte Spalte der Tabelle ist die entscheidende. Auditoren prüfen nicht, ob eine Funktion existiert, sondern ob die Kette steht, die die Dreiklang-Skizze am Beispiel der Web-Filterung durchspielt: die Richtlinie, die das Vorgehen festlegt (welche Kategorien, warum, wer entscheidet Ausnahmen — mit Bezug zur Betriebsvereinbarung aus [LINK: C3]); die Konfiguration, die exakt das umsetzt (und im Live-Blick zeigbar ist); und das Protokoll, das den gelebten Betrieb belegt — Block-Ereignisse, Review-Protokolle, Change-Belege. Fehlt ein Glied, ist der Control nicht »teilweise«, sondern nicht nachweisbar umgesetzt — die Skizze zeigt die drei klassischen Halbheiten, an denen Ketten reißen. Die Mapping-Tabelle ordnet die wichtigsten Controls ihren Umsetzungen und Nachweisdokumenten zu — sie ist zugleich die Gliederung für den Nachweis-Ordner am Audit-Tag. Und sie zeigt nebenbei: Die Zertifizierung erntet, was die Artikel dieses Clusters gesät haben.

Skizze 1: Richtlinie sagt es, Konfiguration tut es, Protokoll beweist es — am Beispiel Web-Filterung (8.23). Fehlt ein Glied, reißt die Kette.

Netzwerksegmentierung: der Dauerbrenner unter den Findings

Kein netzwerkbezogener Control produziert so zuverlässig Findings wie die Netztrennung — und die Treppen-Skizze zeigt, warum: Viele gewachsene Mittelstandsnetze stehen auf Stufe null, dem flachen Netz, in dem Clients, Server, Drucker und Produktionsmaschinen eine große Broadcast-Familie bilden; für den Auditor ist das kein Detail-, sondern ein Konzept-Finding, denn 8.22 verlangt die Trennung nach Schutzbedarf ausdrücklich. Der Weg nach oben: Stufe eins etabliert die Basiszonen (LAN, Server, Gast, WAN) mit Regeln dazwischen — solide, aber der Auditor fragt sofort nach OT, WLAN und dem Management-Zugang. Stufe zwei, die realistische Zielmarke fürs Audit, ergänzt die Funktionszonen: Produktion und OT isoliert (bei TISAX mit den Prototypen-Bereichen als eigenständig geschützten Segmenten), ein Management-Netz für die Admin-Interfaces der Infrastruktur — inklusive des Firewall-WebAdmin selbst —, saubere WLAN-Trennung. Stufe drei ist die Kür aus Feinsegmentierung, benutzerbasierten Regeln ([LINK: B9]) und Heartbeat-Isolation — sinnvoll, wo der Schutzbedarf den Pflegeaufwand trägt. Das Architektur-Handwerk dazu liefert [LINK: A1]; fürs Audit zählt die doppelte Wahrheit aus der Skizze: Das Zonenkonzept muss dokumentiert sein und das Regelwerk muss es leben — der Auditor prüft beides gegeneinander, per Stichprobe. Und die realistische Erwartung: Stufe zwei sauber gelebt schlägt Stufe drei halb gepflegt — jederzeit.

Skizze 2: Vom flachen Netz zur Funktionszonen-Architektur — Stufe 2 ist die realistische Audit-Zielmarke; TISAX verlangt die Prototypen-Trennung ausdrücklich.

Änderungs- und Regelwerks-Management dokumentieren

Der zweite große Prüfkomplex ist der Betrieb — Konfigurationsmanagement und Änderungssteuerung —, und hier entscheidet sich, ob die Firewall als geführtes System oder als gewachsener Wildwuchs wahrgenommen wird. Die vier Bausteine der auditfesten Praxis: Erstens der Change-Prozess — jede nicht-triviale Regeländerung läuft über einen Antrag (das Ticketsystem genügt völlig): Anlass, Genehmigung, Umsetzung, bei kritischen Änderungen ein zweites Augenpaar; der Beleg dafür ist im Zweifel wichtiger als die Perfektion des Prozesses. Zweitens die Kommentar-Disziplin: Jede Regel trägt im Kommentarfeld Zweck und Ticket-Nummer — die unscheinbarste Maßnahme dieses Artikels und zugleich der zuverlässigste Auditor-Liebling, denn sie beantwortet die Stichprobenfrage »Erklären Sie diese Regel« in fünf Sekunden statt in fünf peinlichen Minuten. Drittens der Regelwerks-Review im festen Zyklus — halbjährlich oder jährlich, mit Protokoll: verwaiste Regeln identifiziert, Ausnahmen auf Aktualität geprüft, das Ergebnis dokumentiert; das Review-Protokoll ist der Nachweis, dass 8.9 gelebt wird und nicht nur existiert. Viertens die Flankierung aus dem Cluster: Das Admin-Audit-Log der XGS belegt jede Änderung mit Konto und Zeitstempel, und via Entra-SSO ([LINK: B1]) hängt daran der MFA-Beweis — die [LINK: C4]-Nachweiskette für die Frage, wer wann was geändert hat. Was passiert, wenn diese Disziplin fehlt, zeigt die Warnung — an einem Regelnamen, den jeder Auditor kennt.

Der Audit-Tag: was gezeigt werden muss

Der Audit-Tag selbst verliert seinen Schrecken, wenn klar ist, was auf den Tisch kommt — und das ist erfreulich vorhersehbar. Der typische Ablauf am Netzwerk-Baustein: Zuerst die Konzept-Ebene — Zonenkonzept, Protokollierungskonzept, die Richtlinien zu Web-Filterung und Fernzugang; der Prüfer liest quer und markiert sich Stichproben. Dann der Live-Blick: gemeinsam ins Regelwerk, und die Stichprobenfrage »Erklären Sie mir diese Regel« — hier zahlt die Kommentar-Disziplin aus Kapitel 4 in Echtzeit aus. Dann die Kette an einem Beispiel: zu einer jüngeren Änderung den Change-Beleg, den Admin-Audit-Eintrag und idealerweise die zugehörige Anmeldung mit MFA — die C4-Nachweiskette als Fünf-Minuten-Demo. Dazu der Monitoring-Beweis (ein Alarm und sein Weg zur Reaktion), das jüngste Review-Protokoll, die Zugriffsregelung auf die Firewall selbst und die Konfigurationssicherung. Zwei Verhaltensregeln aus vielen begleiteten Audits: Ehrlich bleiben — eine bekannte Schwachstelle mit dokumentiertem Maßnahmenplan ist ein normaler Befund, eine vertuschte und entdeckte ein Vertrauensproblem fürs ganze Audit. Und nicht schwafeln — die Frage beantworten, das Dokument zeigen, fertig; wer ungefragt Nebenkriegsschauplätze eröffnet, lädt zu Vertiefungsfragen ein, auf die niemand vorbereitet ist.

Typische Findings und ihre Vermeidung

Zum Abschluss die Abkürzung, die dieser Artikel verspricht: die Findings, die in Netzwerk-Audits immer wieder auftauchen — und ihre Vermeidung, bevor der Bericht sie festhält. Die Tabelle versammelt die Klassiker; der Faktenkasten kürt die drei häufigsten. Das Muster dahinter ist auffällig einheitlich: Fast nie fehlt die Technik — die XGS kann alles, was die Controls verlangen. Was fehlt, ist eines der drei Kettenglieder: die Richtlinie (es wird gefiltert, aber nirgends steht, nach welchen Grundsätzen), die Konsequenz der Konfiguration (das Konzept verspricht Zonen, das Regelwerk kennt Ausnahmen »aus historischen Gründen«) oder der Betriebsnachweis (Reviews, die keiner protokolliert, sind auditlogisch nie passiert). Die gute Nachricht liegt im selben Muster: Die Gegenmaßnahmen sind selten Projekte und meist Disziplinen — ein Kommentarfeld füllen, ein Review terminieren, ein Konzept auf zwei Seiten schreiben. Wer die Tabelle als Checkliste vor dem Audit abarbeitet, nimmt dem Prüfer die einfachen Treffer — und verschiebt das Gespräch dorthin, wo es hingehört: zur Substanz.

FAQ — häufige Fragen zu ISO 27001, TISAX und Firewall

Welche ISO-27001-Controls betreffen die Firewall?

Ein gutes Dutzend aus dem Annex A der 2022er Fassung, sinnvoll in fünf Clustern gedacht: die Netz-Architektur mit Netzwerksicherheit (8.20), Sicherheit von Netzwerkdiensten (8.21) und der Netztrennung (8.22) als Segmentierungs-Control; die Verkehrs-Kontrolle mit dem Schadsoftware-Schutz (8.7) und der Web-Filterung (8.23), die seit der Revision ein eigenständiger Control ist und die Firewall-Themen spürbar aufgewertet hat; die Sichtbarkeit mit Protokollierung (8.15), Überwachung (8.16) und Zeitsynchronisation (8.17); der Zugang mit sicherer Authentifizierung (8.5) und privilegierten Zugriffsrechten (8.2) — für die Firewall-Verwaltung selbst gedacht; und der Betrieb mit Konfigurationsmanagement (8.9), Änderungssteuerung (8.32) und dokumentierten Verfahren (5.37). Zwei Einordnungen dazu: Erstens ist die Liste keine Prüf-Reihenfolge — Auditoren denken in Risiken und Prozessen, die Controls sind ihr Raster; wer die fünf Cluster als zusammenhängende Geschichte erzählen kann (Architektur, Kontrolle, Sichtbarkeit, Zugang, Betrieb), wirkt souveräner als jeder Nummern-Jongleur. Zweitens gilt für jeden einzelnen Control der Dreiklang aus Richtlinie, Konfiguration und Protokoll — die Mapping-Tabelle im Artikel ordnet allen dreien ihre konkreten XGS-/M365-Umsetzungen und Nachweisdokumente zu und taugt damit direkt als Gliederung für den Nachweis-Ordner.

Reicht eine XGS für die TISAX-Netzwerkanforderungen?

Als technische Plattform: ja — als Antwort auf die Anforderungen: nur zusammen mit Konzept und Betrieb. Die Funktionsseite ist unkritisch: Zonen und Segmentierung, Web-Filterung, IPS und Schadsoftware-Schutz, VPN mit MFA, Protokollierung mit Syslog-Export, rollenbasierte Verwaltung — die XGS deckt das Anforderungsprofil des ISA-Katalogs an die Netzwerktechnik vollständig ab, eine zweite Appliance verlangt niemand. Was TISAX darüber hinaus verlangt, ist das, woran Assessments tatsächlich scheitern: die konsequente Umsetzung — allen voran die Trennung der besonders schützenswerten Bereiche, im Automotive-Kontext namentlich der Prototypen-Umgebungen, die als eigenständige Segmente mit eigenen Regeln, eigenem WLAN und kontrollierten Übergängen zu führen sind; dazu das dokumentierte Zonenkonzept, das gelebte Änderungswesen mit Kommentaren und Reviews, die Protokollierung mit Konzept statt Zufall und der privilegierte Zugriff mit MFA. Kurz: Die Frage »reicht die XGS?« stellt sich im Assessment nie — gefragt wird »zeigen Sie Ihr Zonenkonzept, erklären Sie diese Regel, belegen Sie das letzte Review«. Wer darauf antworten kann, besteht mit jeder aktuellen Firewall; wer es nicht kann, mit keiner. Die Praxis-Geschichte im Artikel zeigt den Weg von zwei dicken Gaps zum Label in acht Wochen — mit exakt einer XGS.

Wie weise ich Regelwerks-Reviews nach?

Mit einem Protokoll, das vier Fragen beantwortet — und mit einem Zyklus, der es regelmäßig erzeugt. Das Protokoll: Wann fand das Review statt und wer hat es durchgeführt (Datum, Namen, bei kritischen Umgebungen im Vier-Augen-Prinzip)? Was wurde geprüft (der Scope — Vollständigkeit schlägt Stichprobe, aber eine dokumentierte Stichproben-Systematik schlägt den undokumentierten Vollanspruch)? Was wurde gefunden (verwaiste Regeln, fehlende Kommentare, zu weite Freigaben, abgelaufene Ausnahmen — mit Zählung)? Und was folgt daraus (die Maßnahmenliste mit Verantwortlichem und Termin — plus im nächsten Protokoll der Abgleich, ob sie umgesetzt wurde; genau dieser Schluss der Schleife unterscheidet gelebte Reviews von Papier-Ritualen). Der Zyklus: halbjährlich oder jährlich als fester Termin, ausgelöst zusätzlich bei größeren Änderungen — und schriftlich in den Betriebsverfahren (5.37) verankert, damit der Turnus selbst nachweisbar ist. Zwei Praxis-Verstärker: Die Kommentar-Pflicht mit Ticket-Bezug macht jedes Review um Größenordnungen schneller, weil der Zweck jeder Regel dasteht statt erforscht werden zu müssen; und das XGS-Admin-Audit belegt flankierend, dass die im Protokoll notierten Bereinigungen tatsächlich stattfanden. Ein so geführtes Protokoll beantwortet die Auditor-Frage nach 8.9 in einer Minute — und ist nebenbei das wirksamste Mittel gegen die Temp-Regel-Verrottung aus der Warnung.

Muss ich jede Firewall-Änderung dokumentieren?

Jede nicht-triviale — und die ehrliche Antwort steckt in der Abgrenzung. Der Maßstab der Änderungssteuerung (8.32) ist risikobasiert: Änderungen, die Sicherheitswirkung haben — neue oder geänderte Freigaben, Zonen-Übergänge, VPN- und NAT-Anpassungen, Ausnahmen von Filterrichtlinien — brauchen den nachvollziehbaren Weg aus Anlass, Genehmigung und Umsetzung; das Ticketsystem genügt dafür völlig, ein eigenes Change-Board braucht der Mittelstand nicht. Triviale Betriebshandgriffe ohne Regelwirkung — Objektname, Beschreibung, Berichtseinstellung — verlangen keinen Antrag; wer auch sie dokumentiert, überzieht und sorgt nur für Prozess-Umgehung. Die pragmatische Doppel-Absicherung, die sich in Audits bewährt: Erstens die Kommentar-Pflicht — jede Regel trägt Zweck und Ticket-Nummer, womit die Dokumentation an der Regel selbst klebt und die Stichprobenfrage des Prüfers in Sekunden beantwortet ist. Zweitens das Admin-Audit-Log als lückenloses Sicherheitsnetz: Es protokolliert ohnehin jede Änderung mit Konto und Zeitstempel — und über die Entra-SSO-Kette hängt daran der MFA-Beweis; selbst wenn ein Ticket einmal fehlt, ist die Änderung damit rekonstruierbar, nur eben mit schlechterem Eindruck. Die Merkregel: Der Prüfer erwartet keinen bürokratischen Overkill, sondern die Antwort auf drei Fragen zu jeder relevanten Änderung — warum, wer hat es genehmigt, wer hat es gemacht. Ein Ticket plus ein Regel-Kommentar beantworten alle drei.

Was prüft der Auditor konkret an der Firewall?

Die Kette, nicht das Gerät — und der Ablauf ist erfreulich vorhersehbar. Baustein eins, die Konzepte: Zonenkonzept, Protokollierungskonzept, Richtlinien zu Web-Filterung und Fernzugriff — quergelesen und mit Stichproben-Markierungen versehen. Baustein zwei, der Live-Abgleich: gemeinsamer Blick ins Regelwerk mit der Klassiker-Frage »Erklären Sie mir diese Regel« — geprüft wird, ob die Realität das Konzept lebt, und Kommentare mit Ticket-Bezug entscheiden hier über Sekunden oder Schweigen. Baustein drei, die Änderungskette an einem Beispiel: zu einer jüngeren Änderung der Change-Beleg, der Admin-Audit-Eintrag, idealerweise die Anmeldung mit MFA-Nachweis — die komplette Wer-wann-was-Kette in fünf Minuten. Baustein vier, der Betriebsbeweis: ein Alarm und sein Weg bis zur Reaktion, das jüngste Review-Protokoll, die Konfigurationssicherung. Baustein fünf, die Meta-Ebene: Wer darf an die Firewall (Rollen, MFA, kein Sammelkonto), und wie ist der Zugriff selbst protokolliert. Dazu die zwei Verhaltensregeln aus der Audit-Begleitung: Ehrlichkeit schlägt Fassade — ein bekannter Schwachpunkt mit Maßnahmenplan ist ein normaler Befund, ein vertuschter und entdeckter beschädigt das Vertrauen fürs gesamte Audit; und Präzision schlägt Redseligkeit — Frage beantworten, Dokument zeigen, schweigen. Wer die fünf Bausteine vorab selbst durchspielt, kennt seine Lücken vor dem Prüfer.

Wie hängen NIS2 und ISO 27001 zusammen?

Als Pflicht und Gerüst — und wer beides vor sich hat, sollte die Reihenfolge kennen. NIS2 ist Gesetz: Es verpflichtet betroffene Unternehmen auf Risikomanagement-Maßnahmen, Meldeprozesse und Nachweisfähigkeit — ohne eine bestimmte Norm oder ein Zertifikat zu verlangen; die Betroffenheitsprüfung und der Maßnahmen-Fahrplan stehen in [LINK: C1]. ISO 27001 ist ein Managementsystem-Standard: freiwillig, zertifizierbar, mit dem Annex-A-Katalog als Maßnahmenraster. Die Verwandtschaft ist eng und kein Zufall — die NIS2-Maßnahmenfelder (Risikoanalyse, Vorfallsbewältigung, Zugriffskontrolle, Kryptografie, Lieferkette …) lesen sich wie eine Kurzfassung der Annex-A-Themen, und ein gelebtes ISMS nach ISO 27001 deckt die NIS2-Anforderungen materiell weitgehend ab — inklusive der Wirksamkeitsbewertung, die NIS2 ausdrücklich verlangt und die das ISMS-Audit-Regime frei Haus liefert. Umgekehrt gilt: NIS2-Konformität ersetzt kein Zertifikat, wo Kunden eines verlangen. Die pragmatische Staffelung: erst die NIS2-Pflichtwellen aus C1, dann — wenn Kunden, Ausschreibungen oder TISAX es verlangen — das ISMS als Dach; die Doppelverwertung ist maximal, denn jede Kette aus Richtlinie, Konfiguration und Protokoll zahlt in beide Welten ein. Wer dagegen das Zertifikat vor die Substanz stellt, kauft teures Papier — die Warnung aus dem NIS2-Artikel gilt spiegelbildlich.

Fazit: Der Auditor prüft Ketten — und Ketten kann man vorbereiten

Die Übersetzungsarbeit dieses Artikels mündet in einer beruhigenden Erkenntnis: Nichts an den netzwerknahen Controls von ISO 27001 und TISAX verlangt Exotisches — verlangt wird das konsequente Zuendedenken dessen, was dieser Cluster ohnehin beschreibt: Zonen statt flachem Netz (Stufe zwei der Treppe reicht), Web-Filterung mit Richtlinie statt Bauchgefühl, Protokollierung mit Konzept und Korridor, Admin-Zugang mit MFA und Rollen, Änderungen mit Ticket und Kommentar, Reviews mit Protokoll. Jeder Control folgt demselben Dreiklang — Richtlinie sagt es, Konfiguration tut es, Protokoll beweist es —, und fast jedes typische Finding ist eine gerissene Kette, keine fehlende Technik. Die Vorbereitung ist damit planbar: Mapping-Tabelle als Ordner-Gliederung, Findings-Tabelle als Checkliste, die eigene Änderung von letzter Woche als Generalprobe durch alle Kettenglieder. Und der schönste Nebeneffekt: Alles davon ist keine Audit-Kosmetik, sondern schlicht guter Betrieb — das Zertifikat bescheinigt am Ende nur, was ein ordentlich geführtes Netz ohnehin ist.

Von hier aus weiter im Cluster: Das Gesamtbild der XGS in Microsoft-Umgebungen zeichnet der Pillar-Artikel [LINK: Pillar]. Die gesetzliche Schwester-Pflicht samt Betroffenheits-Selbsttest und Dreiwellen-Fahrplan behandelt [LINK: C1]. Das Handwerk der Nachweisketten über XGS, Entra und M365 — die Beweisführung hinter jedem dritten Kettenglied — liefert [LINK: C4]. Und die Segmentierungs-Architektur, die aus Stufe null Stufe zwei macht, steht in [LINK: A1].