Wichtige Info

Die Inhalte, die du hier siehst stelle ich dir ohne Werbeanzeigen und ohne Tracking deiner Daten zur Verfügung. Trotzdem muss ich die Server bezahlen sowie Zeit in Recherche, Umsetzung sowie Mail Support stecken.
Um dies leisten zu können, verlinke ich in einigen Artikeln auf die Plattform Amazon. Alle diese Links nennen sich Afiliate Links. Wenn du dir mit diesem Link etwas kaufst, dann erhalte ich eine kleine Provision. Dies ändert jedoch NICHT den Preis, den du bezahlst!
Falls du mich also unterstützen möchtest, kannst du auf den Link zum Produkt klicken und hilfst mir dabei, dieses Hobby weiter zu betreiben.
Da ich Keine Werbung schalte und keine Spenden sammle, ist dies die einzige Möglichkeit, meine Systeme und mich zu finanzieren. Ich hoffe du kannst das verstehen :)


ISMS im Alltag - Betriebskonzept am Beispiel Windows 11


ISMS - Ein Betriebskonzept für Windows 11 Clients

Einleitung

Mein Job bringt mich häufig dazu, in Rollen zu schlüpfen, die mir zuvor unbekannt waren, und über Dinge nachzudenken, die man doch eher selten im Kopf hat. In Zeiten des Betriebssystemwechsels, von Windows 10 auf Windows 11, gibt es bei größeren Unternehmen, ggf. mit eigenem ISMS, die Thematik des Betriebskonzepts – sprich, wie betreibe ich ein System in einer Weise, die allen Regulatorien, sei es extern oder intern, gerecht wird. Derzeit möchte ich dabei helfen, ein solches Betriebskonzept aufzusetzen. Dieser Artikel soll ein wenig meine Gedanken aufzeigen und im besten Fall am Ende eine Art Blueprint für ein Betriebskonzept bereitstellen.

Wie immer: Keine Garantie auf Vollständigkeit oder Richtigkeit...

Hauptteil

Als blutiger Anfänger ist es mir ein Anliegen, dass auch andere Neulinge von diesem Beitrag profitieren können. Daher möchte ich ganz am Anfang beginnen und einige grundlegende Prinzipien definieren.

Was ist eine Dokumentation?

Zuerst sollte geklärt werden, was eine Dokumentation ist. In meinem beruflichen Alltag habe ich bereits bemerkt, dass es große Unterschiede in der Definition geben kann. Daher folgt nun meine Auffassung davon, was eine Dokumentation sein sollte.

Eine Dokumentation ist eine systematische Sammlung von Informationen, die Prozesse, Systeme oder Produkte detailliert beschreibt, um Benutzern oder Entwicklern das Verständnis und die Nutzung zu erleichtern. Eine gute Dokumentation zeichnet sich durch Klarheit, Vollständigkeit und einfache Zugänglichkeit aus, sodass Leser schnell die gesuchten Informationen finden und verstehen können. Zudem (und das ist mit das Wichtigste) bleibt sie stets aktuell, indem sie regelmäßig überprüft und an Veränderungen oder neue Anforderungen angepasst wird.

Eine Dokumentation sollte somit Nutzern (gerade auch neuen Benutzern) die Möglichkeit geben, schnell und informiert ein neues System verwenden zu können. Die Qualitätsfrage einer Dokumentation ist also: „Kann ein unbeteiligter Dritter mit dieser Dokumentation das Produkt verwenden, den Prozess ausführen oder das System bedienen?“ Sollte der Benutzer nachfragen müssen, ist die Dokumentation nicht vollständig.

WICHTIG: Eine Dokumentation sollte nach folgendem Grundsatz verfasst werden: So viel wie nötig, so wenig wie möglich. Zu viel Dokumentation ist ebenso schädlich wie keine Dokumentation. Zu viele Details können Prozesse lähmen und eine Dokumentation im schlechtesten Fall unbrauchbar machen, wenn diese zu unübersichtlich ist.

Gibt es neben den Anforderungen an der Dokumentation, auch Anforderungen an den Leser?

Eines der häufigsten Probleme beim Verfassen von Dokumentationen ist die Zielgruppendefinition. Eine Dokumentation muss nicht zwangsläufig für jeden allgemeinverständlich sein. Bei einer Systemdokumentation kann beispielsweise vorausgesetzt werden, dass der Leser gewisse Grundlagen beherrscht. Solche Voraussetzungen können in der Dokumentation definiert werden, um so die Zielgruppe klar abzugrenzen. Weiterhin kann eine Dokumentation auch voraussetzen, dass der Leser gegebenenfalls andere Dokumente zum Verständnis heranziehen muss. Gerade bei umfassenden Systemen ist es nicht sinnvoll, alle Informationen in einem Dokumentensatz zu packen, da die Dokumentation so schnell unübersichtlich werden kann. Zuletzt ist es auch einfach nicht sinnvoll, das Rad neu zu erfinden. Dokumentationen von gegebenenfalls eingebundenen Systemen können verlinkt werden. Ist das System in einem Störfall relevant, kann so auf das referenzierte Material zugegriffen werden. Sollte dies nicht notwendig sein, kann durch diese Komponenten keine Verwirrung entstehen.

Gibt es "zu viel Aufwand" für eine Dokumentation

Die kurze Antwort ist: Ja! Eine gute Dokumentation zeichnet sich nicht durch eine Informationsflut aus, sondern durch die kluge Abwägung kritischer Informationen, die den Benutzer leiten. Hierbei ist es wichtig zu betonen, dass an den Leser durchaus auch Ansprüche gestellt werden können. Wichtig ist jedoch, dass es sich bei den Voraussetzungen niemals um implizites Wissen handeln sollte. Das bedeutet, dass der Leser keine speziellen Erfahrungen (unternehmens- oder teamgebundenes Können) besitzen muss, um die Dokumentation nutzen oder verstehen zu können.

Beispiel einer Anfroderung, welche NICHT gestellt werden sollte - Implizites Wissen

Situation:
Ein Netzwerkadministrator erstellt einen Know-How Artikel für neue Kollegen. Der Titel des Artikels: "Effiziente Fehlerbehebung im Zentralen Netzwerkmanagement-System"

Kontext:
Der Systemadministrator, arbeitet seit Jahrzehnten im Unternehmen. Er kennt alle Systeme auswendig und kennt jeden Kniff, um jedes Problem innerhalb von Minuten zu beheben.
Um verschiedene Kundenanforderungen umzusetzten, wurden in der Vergangenheit unterschiedliche Anpassungen an der Infrastruktur gemacht, welche nicht Dokumentiert sind. Der Artikel soll helfen bestimmte Probleme zu beheben, falls der Administrator keine Zeit hat.

Beispiel für implizites Wissen:
In einem Abschnitt des Artikels über die Diagnose von Netzwerklatenzen wird erklärt:

"Bei ungewöhnlich hohen Latenzzeiten überprüfen Sie die Konfigurationen des CPE-Routers im Segment B12. Häufig führen inkorrekte Einstellungen, die wir aus historischen Gründen beibehalten haben, zu diesen Problemen. Denken Sie daran, die spezielle Anpassung zu nutzen, die wir für die dynamische Routenoptimierung implementiert haben."

Implizites Wissen, das vorausgesetzt wird:

Verständnis historischer Konfigurationen: Der Leser soll die "historischen Gründe" kennen und bei der Lösungsfindung beachten. Neue Mitarbeiter können diese historischen Entscheidungen und Situationen nicht kennen, dies kann dazu führen, dass Fehlentscheidungen getroffen werden. Hier muss entweder die Dokumentation überarbeitet werden oder die Einstellungen einem Standard angepasst, welcher durch andere Quellen nachvollziehbar ist.

Kenntnis der "speziellen Anpassung": Der Artikel geht davon aus, dass der Leser mit einer intern entwickelten, nicht dokumentierten Anpassung vertraut ist, die für die dynamische Routenoptimierung verwendet wird. Ohne Kenntnis dieser Anpassung ist es für neue Teammitglieder fast unmöglich, die Anweisungen effektiv umzusetzen.

Ortsbezogenes Wissen über Netzwerksegmente: Die Erwähnung von "Segment B12" ohne weitere Erläuterung setzt voraus, dass der Leser mit der physischen und logischen Struktur des Netzwerks vertraut ist, was für neue Mitarbeiter ohne umfassende Einarbeitung eine Herausforderung darstellen könnte. Hier kann bereits der Verweis auf einen Netzwerkplan ausreichen, um auch neue Teammitglieder abzuholen.

Zusammenfassung: In dieser Situation erfordert die effektive Nutzung der Dokumentation nicht nur technisches Wissen und Erfahrung, sondern auch ein tiefes Verständnis der unternehmensspezifischen Praktiken, historischen Entscheidungen und internen Anpassungen. Ohne dieses implizite Wissen könnten neue Teammitglieder oder externe Berater die Anleitungen schwer nachvollziehen und anwenden.
Dieses Beispiel zeigt, wie bereits ein Absatz, dazu führen kann, dass eine Dokumentation für Bediener nicht verwendbar ist.

Der Weg zum Betriebskonzept - Was sollte man beachten?

Dieser Artikel kann keine allgemeingültige Auskunft darüber geben, wie jedes Betriebskonzept auszusehen hat. In jedem Unternehmen gibt es unterschiedliche Herausforderungen und Ansprüche. Deshalb ist es Aufgabe jeder Organisation, die notwendigen Bausteine individuell zusammenzustellen. Aus diesem Grund bemühe ich mich, mich so allgemein wie möglich zu halten und das Konzept in "Module" zu unterteilen. Es gibt Module, die zwingend enthalten sein sollten, es sei denn, es gibt explizite Gründe dagegen, und Module, die nur verwendet werden sollten, wenn der entsprechende Anwendungsfall vorliegt. Im Folgenden entwickeln wir nun ein Betriebskonzept am Beispiel der Einführung von Windows 11 und schauen, wohin uns das führt.

Wichtig: Auch dieses Beispiel dient nur als Orientierung! Jede Organisation gibt eigene Vorgaben und Maßnahmen vor. Eventuell fehlen technische Vorkehrungen oder auch Prozesse. Diese können nur intern ergänzt werden!

Betriebskonzept - Module

Modul - Einleitung (Mandatory)

Im Modul Einleitung sollten die Grundsätze definiert werden. Die Einleitung beschreibt, was wir hier überhaupt gerade machen, wer verantwortlich ist und für wen die Dokumentation gilt.

In diesem Fall sollten folgende Punkte in der Einleitung abgehandelt werden:

  • Definition der Dokumentation
    • z.B. Das vorliegende Betriebskonzept definiert die Grundlagen für den sicheren Betrieb von Windows 11 Clients in der Organisation. Die definition eines klaren Rahmens zum Betrieb von Windows 11 Clients ist notwendig um einen reibungslosen Betrieb sicherzustellen und Richtlinien, Best Practices und Sicherheitskonfigurationen zu implementieren.
    • ggf. Notwendigkeit des Projekts -> Warum muss zu Win11 migriert werden?
  • Scope
    • z.B. alle Windows Clients der Organisation
  • Leservoraussetzung
    • z.B. Um das vorliegende Betriebskonzept nutzen und umsetzten zu können, werden die folgenden Voraussetzungen definiert, sodass die beschriebenen Konzepte nicht nur verstanden sondern auch praktisch umgesetzt werden können
      • Technisches Verständnis vom Windows Betriebssystem
        • z.B. Nutzer- und Systemverwaltung auf Basis von GPO/Active Directory
        • z.B. WSUS, MECM
      • Technisches Verständnis von Basis Netzwerkdiensten
        • z.B. NTP, DHCP, DNS
  • Gültigkeit / PDCA Einordnung
    • In welchem Intervall wird die vorliegende Dokumentation überprüft?
  • Versionierung (am besten in einer Tabelle innerhalb des Dokuments)
    • Ersteller
    • Änderungsdatum
    • Letzer bearbeiter
    • Verantwortlicher Product Owner/Information Asset Owner -> Hiermit ist eine klare Verantwortung sichergestellt, welche im Notfall dafür sorgt, dass schnell Ansprechpartner verfügbar sind.

Modul - Verantwortlichkeit (Mandatory)

In diesem Modul sollte definiert werden, wer später für die Ausführung verantwortlich ist. Hier können zum Beispiel Teams definiert werden. Weiterhin sollten aber auch Notfallkontakte und entsprechende Rollen dokumentiert werden. Dieser Abschnitt muss zwingend aktuell gehalten werden und sollte zum Beispiel auch bei dem Mitarbeiter-Lifecycle-Prozess beachtet werden. Wenn ein Mitarbeiter das Unternehmen verlässt und dieser als Notfallkontakt definiert ist, muss auch außerhalb eines Prüfzyklus gehandelt werden.

Auch hier gilt, dass jede Organisation zum Beispiel aus dem ISMS heraus andere Anforderungen an die Dokumentation haben kann. Dadurch kann das Betriebskonzept am Ende stark abweichen.

In diesem Abschnitt könnten zum Beispiel folgende Daten stehen:

  • Hauptverantwortlichkeiten
    • Hauptverantwortlicher Betriebskonzept
    • Verantwortlicher für Pflege/Erstellung der Dokumentation
    • Verantwortlichkeiten auf Leitungsebene (z.B. IT Leiter oder CIO oder CTO)
  • Zuständigkeiten
    • Zuständigkeiten für z.B. Bestandteile des Systems (z.B. Netzwerk, Patch Management, Benutzerverwaltung)
  • Ansprechpartner für technsiche Unterstützung
    • Kontaktliste für Supportebenen oder Hotlines
    • ggf. Auflistung von externen Dienstleistern
  • Ansprechpartner für Sicherheitsbezogene Anfragen
    • Ansprechpartner für die Implementierung von Sicherheitsrichtlinien
    • Ansprechpartner für die Überwachung von Systemen
    • Ansprechpartner für Sicherheitsvorfälle
  • Datenschutzverantwortliche
    • Ansprechpartner für Datenschutzvorfälle und verarbeitung von Personenbezogenen Daten
  • Change Verantwortliche
    • Ansprechpartner für die genehmigung und Planung von Changes innerhalb des Betriebssystemumfelds
  • Notfall- und Krisenmanagement
    • Verantwortlichkeiten bei Krisen oder Notfällen
    • Verantwortlichkeiten für die Erstellung von Krisen- und Notfallplänen
  • Schulung und Weiterbildung
    • Verantwortlichkeit für die Schulung von Anwendern (ggf. auch Erstellung von Schulungsmaterial)
  • Compliance
    • Verantwortlichkeit für die Überwachung und Einhaltung von internen- und externen Richtlinien
    • Verantwortlichkeioten für die durchführung von Audits

Modul - Gültigkeit (Mandatory)

Dieses Modul definiert, ab wann die Dokumentation in Kraft tritt und in welchen Unternehmensbereichen diese Gültigkeit besitzt.

Modul - Architektur (Mandatory) -> Die "eigentliche Dokumentation"

Um eine Dokumentation anwenden zu können, ist es nötig zu wissen, wie das Produkt innerhalb der Organisation integriert ist. Das heißt, dass man wissen sollte, welche Dienste gegebenenfalls notwendig sind und wie das System mit anderen Systemen interagiert. Die Systemarchitektur zeigt genau das. Hier wird definiert, was gegeben sein muss, um die Dokumentation anwenden zu können (Anforderungen).

Wichtig: Dieser Abschnitt ist höchst individuell. Es macht hier keinen Sinn, alles abzuschreiben. Hier gelten nicht nur interne Richtlinien aus dem ISMS oder anderen internen Dokumenten. Gegebenenfalls müssen hier auch gesetzliche Rahmenbedingungen betrachtet werden, zum Beispiel wenn personenbezogene Daten über den Client verarbeitet werden (z. B. DSGVO) – Verschlüsselung und Zugriffssteuerung.

Zuletzt spielt hier auch das technische Setup hinein.

Dieser Abschnitt könnte zum Beispiel folgende Infos enthalten:

  • Hardware Anforderungen
    • ggf. eingesetzte Modelle vom Lieferanten
    • mindestanforderungen für zukünftige Modelle (z.B. TPM2)
  • Organisationseinordnung
    • Darstellung der aktuellen Landschaft (z.B. per Netzdiagramm)
      • Darstellung von Notwendigen Systemen (z.B. DNS Server, DHCP Server, Exchange Server (autodetect Systeme), PXE Server usw.)
  • Netzwerkkonfiguration
    • ggf. Standort abhängig
      • Beschreibung von Einbindung in das Netzweerk (VLAN, (W)Lan, WAN, VPN)
    • Eiinbindung in Netzwerke
      • z.B. Zuständige DHCP Server, Ausstellende Zertifizierungsstellen
      • Authentifizierungsmöglichkeiten im (W)LAN
        • z.B. IEEE 802.1x, NAC
  • Sicherheitsinfrastruktur
    • Sicherungsmaßnahmen
      • z.B. vorgeschaltene Firewalls, Endpoint Protection Systeme, IDS/IPS-Systeme
  • Identitäts- und Zugriffsmanagement
    • z.B. Anbindung an AD
    • Definition von GPOs
    • MFA -> Hier eher Link auf Anhang oder extra Dokumentation, je nach System
  • Basis Einstellungen
    • z.B. Datenträgerverschlüsselung, Client Zertifikate für Authentifizierung gegenüber dem Unternehmensnetzwerk
    • z.B. Basis Netzwerkkonfigurationen
    • z.B. Default Packages -> Eher als Anhang
  • Datenmanagement
    • z.B. Einbindung von Fileserver oder Cloud Systemen
    • Backup- und Wiederherstellungsstrategien
    • Prozesse für Datenhaltung -> Link zu Richtlienen -> z.B. Arbeitsdaten nicht auf lokalem Laufwerk speichern sondern auf Shares.
  • Software und Anwendungsmanagement
    • z.B. Softwareverteilung über Ansible oder MECM -> Link zu Dokumentation
    • Patch- und Softwaremanagement -> Entweder Link zu separater Dokumentation oder definition von z.B. Patchdays (Zyklen) sowie Verantwortlichkeiten.
    • Werden Aktualisierungen automatisch gemacht?
    • Planung für größere Upgrades -> Prozesse
      • Kommunikation an Anwender -> Prozesse
  • Lifecycle
    • Definition von Syst emlifecycles -> Link zu Doku oder hier
      • z.B. Nach 3 Jahren neuer Rechner -> Sollte es ein gesondertes Hardware management geben, ist dieser Punkt hier eher nicht nötig!
  • Kommunikationsdienste
    • Nutzung von Kommunikationsprotokollen
      • z.B. HTTP(S), SMTP, IMAP usw. -> Einschränkungen oder Basiskonfigurationen
  • Überwachung
    • Wie werden Systeme überwacht
    • Was wird überwacht?
    • Einsatz von Management Tools
      • Welche sind erlaubt und wie können diese verwendet werden?
  • Sonstiges
    • z.B. Disaster Recovery
    • z.B. BCM
    • z.B. Pläne für Notfallbeschaffung, bei flächenausfällen (Prozesse und Lagerbestände)
    • z.B. Standardsysteme
      • z.B. Drucker -> oder auch Systeme wie FollowMe Print
    • z.B. Definition von Standards
      • z.B. GPO für Definition von Standardprogrammen

Modul - Härtung (Optional)

Dieser Abschnitt könnte verwendet werden, um zum Beispiel gesonderte Härtungsmaßnahmen zu definieren

Dies könnte z.B. folgendes beinhalten

  • Allgemeine Härtungsmaßnahmen (Lose)
    • Link zu Dokumentation dieser Härtungen oder je kurze Aufschlüsselung
  • Härtungen nach Referenzdokumenten

Modul - Softwaresammlung (Optional)

In diesem Abschnitt können Basissysteme definiert werden, also Systeme mit einem definierten Grundset an Software und Konfiguration.
Hier können z.B. Software White-/Blacklists definiert werden -> Alternativ kann dies Bestnadteil anderer Dokumente sein z.B. innerhalb des ISMS

  • Default Software
    • z.B. Basis Software
      • z.B.
        • Software Center
        • Endpoint Protection (z.B. Trendmicro)
        • VPN (z.B. ZScaler, Ivanti, NCP, OpenVPN etc.)
        • O365 Suite -> Word, Excel, Powerpoint, Teams, Outlook
        • Standard Browser
        • Standard Treiber
        • PDF Reader
  • Spezifische Software ->z.B. auf Kaufmännischen Endgeräten -> z.B. bei bestimmter AD Gruppe
    • z.B.
      • SAP
      • Datenbank Management Systeme
      • Ticketsystem
      • Debug Tools
      • SDKs

Modul - Benutzerverwaltung (Optional / Mandatory)

Wenn nicht anders geregelt, sollte hier alles bzgl. der Benutzerverwaltung definiert werden.

Das kann je nach Organisation unterschiedlich aussehen, könnte aber zum Beispiel folgendes beinhalten

  • Prozesse
    • Benutzererstellung
    • Benutzerverwaltung
    • Benutzerberechtigung
  • Rollen/Nutzer
    • Standardrollen
    • Backup Nutzer (z.B. lokaler Administrator -> Wo findet Passwortverwaltung statt -> In die Doku gehört kein Passwort!)
    • Richtlinien / Rechte
    • Profileinstellungen
  • Authentifizierung
    • MFA?
    • Verfahren zur sicheren Authentifizierung
    • Behandlung von "Altlasten" wie NTLM und SMBv1 bei z.B Windows
    • Anmeldeverfahren
    • Fernzugriffsmöglichkeiten
  • Tools zur Verwaltung

Modul - Richtlinien (Optional)

Sollte es interne Richtlinen geben, welche sich auf die Verwendung von Endpunkten beziehen, sollten diese hier erwähnt werden

  • z.B. Richtlinien für Mobiles Arbeiten
  • z.B. Inventarisierung / Asset Management -> Prozesse
  • z.B. Nachhaltigkeits- / Umweltbestimmungen

Modul - Externe Partner (Optional)

Sollte das System von externen Partner Abhängig sein, sollten die Partner und Rollen definiert sein. Hier können Dopplungen zwischen dem Modul "Verantwortlichkeiten" entstehen.
Jedoch sollte klar sein, welche Aufgaben externe Partner haben, ob diese Zugriffe auf Unternehmensdaten besitzen und wie diese Rechte verwaltet werden. Aber auch Punkte wie Kommunikation, Sicherheitsanforderungen, SLAs, Eskalationspfade und Datenaustauschsmöglichkeiten (sofern vorhanden)

Zusammenfassung

Damit hätte man eine ganz Grundlegende Dokumentation erstellt. Wie erwähnt könnte man noch viel mehr schreiben, aber auch die Gleiderung anders gestalten...
Als Beispiel könnte man Systemkonfigurationen spezifizieren -> z.B. welche Standard MS Programme beim aufsetzen des Systems entfernt werden (z.B. GameBar). Aber auch Prozesse zum Enduser Management, definierte SLAs, Compliance Vorgaben, Kostenmanagement und Verwendungsrahmen könnten definiert werden.

Diese Punkte müssen jedoch intern ausgearbeitet werden und können nicht einfach für jede Organisation gleich sein. Hier kommt zum tragen, dass jedes Unternehmen andere Richtlinien und Verpflichtungen hat.

Ich hoffe dir hat dieser Artikel geholfen. Falls du Anregungen oder Verbesserungsvorschläge hast, schreib mir gerne eine Mail an blog@pure-smart.de. Ich bin über externe Eindrücke sehr dankbar und würde mich über eine konstruktive Diskussion freuen ^^.

Back…