27001 – Odyssee im Sprachraum : Wie linguistische Textanalyse bei Komplexitätsbewertung und Verständnis der ISO/IEC 27001 hilft
Auf den ersten Blick sieht die ISO/IEC 27001 übersichtlich und wohl strukturiert aus – bei einem genaueren Blick erweisen sich jedoch viele Stellen als unklar oder unnötig kompliziert. Missverständnisse können aber zur ungenügenden Implementierung geforderter Sicherheitsmaßnahmen führen und im Rahmen eines Zertifizierungsaudits problematisch werden. Überdies verschleiert die sprachliche Gestaltung die tatsächliche Komplexität der Norm und kann dadurch sowohl zu Fehlplanungen bei Projekten als auch Mängeln in der Dokumentation führen.
Von Sebastian Klipper, Hamburg, und Steffen Hessler, Bochum
Vor dem Hintergrund der sprachlichen Eigenheiten der ISO/IEC 27001 ist ein interdisziplinäres Forschungsprojekt der beiden Autoren entstanden. Am Center for Advanced Internet Studies (CAIS) beschäftigen sie sich seit November 2020 mit der Anwendbarkeit von Industrienormen im Bereich der Informationssicherheit. Dabei fokussiert sich das Projekt vor allem auf die sprachliche Analyse und Möglichkeiten, eine einfachere Verständlichkeit herzustellen.
Dass die ISO/IEC 27001 nicht so einfach zu verstehen ist, wie man vielleicht denkt, fiel bei der interdisziplinären Zusammenarbeit der beiden Autoren schnell auf: Während für den 27001-Praktiker Sebastian Klipper der Sprachjargon der ISO-Informationssicherheit gewohntes Terrain war, stieß der Sprachwissenschaftler Steffen Hessler auf einige Schwierigkeiten.
So unterscheiden sich zum Beispiel viele verwendete Verben in ihrer Bedeutung teilweise so wenig, dass kaum verständlich ist, worin die Unterschiede liegen. In Abschnitt 9.2 der ISO/IEC 27001 heißt es etwa: „The organization shall plan, establish, implement and maintain an audit programme.“ Sind „establish“ und „implement“ also zwei verschiedene Aufgaben? Warum wird hier explizit „maintain“ gefordert und an anderer Stelle nicht? Reicht es beispielsweise bei 8.3 aus, ein Information-Security-Risk-Treatment zu implementieren, ohne es zu „maintainen“? Was ist der Unterschied zwischen „implement and maintain“ (9.2) und „implement and control“ (8.1)? Und warum fordert die Norm in Abschnitt 4.4 nach „establish, implement“ und „maintain“ zusätzlich „continually improve“? Sollte „continually improve“ nach 10.2 nicht eigentlich für alle Anforderungen der ISO/IEC 27001 gelten? Was sind „normative Verweisungen“ und warum ist „Telearbeit“ nicht überall einfach Telearbeit?
Im Rahmen der Untersuchungen wurden alle Anforderungen der ISO/IEC 27001 nach sprachwissenschaftlichen Kriterien detailliert erfasst und analysiert. Die Anforderungen für ein Managementsystem für Informationssicherheit (ISMS) ergeben sich aus dem englischsprachigen Original der ISO/IEC 27001 beziehungsweise seiner deutschen Übersetzung DIN EN ISO/IEC 27001. Bei der Anwendung der Norm ist zudem auch die (DIN EN) ISO/IEC 27000 als „normative Verweisung“ umzusetzen.
Wie viel ist „alle“?
Verwirrung entsteht schon bei einer sehr grundlegenden Frage: Was genau bedeutet es, alle Anforderungen umzusetzen? Wie viele Anforderungen sind das und wie hoch ist der Koordinierungsaufwand innerhalb einer Organisation?
In ihrer groben Struktur setzt sich die (DIN EN) ISO/IEC 27001 aus einem Textteil mit 10 sogenannten Clauses und dem Annex A zusammen. Der Textteil ist bei einer Zertifizierung zwingend und ohne Ausnahme umzusetzen, während die individuelle Gültigkeit der Controls aus Annex A vom zu erstellenden Statement of Applicability abhängt.
Die Anforderungen im Textteil und in Annex A sind überwiegend als vollständige Sätze formuliert. Dabei sind drei Fälle zu unterscheiden:
- einzelne Anforderung in einem nicht-komplexen Satz
- mehrere und/oder-verknüpfte Anforderung in einem komplexen Satz
- mehrere und/oder-verknüpfte Anforderungen in einem komplexen Satz in Form einer Aufzählung
Einzelne Sätze sind wiederum in Absätzen, Tabellen, Abschnitten und Unterabschnitten gruppiert: Im Textteil werden sie als Absätze dargestellt und in einer Überschriftenhierarchie zusammengefasst, ohne dass die Norm Tabellen zur Gliederung nutzt. Annex A stellt die Sätze tabellarisch dar und bezeichnet sie als „Control“. Diese Controls wiederum sind in einer Überschriftenhierarchie aus 14 Gruppen unter 34 „Control Objectives“ tabellarisch zusammengefasst.
Beispiel zur Komplexitätsreduktion in Teilanforderungen
Das Control A.11.1.4 ist ein Beispiel für mehrere und/oder-verknüpfte Anforderungen in einem komplexen Satz:
Protecting against external and environmental threats
Control: Physical protection against natural disasters, malicious attack or accidents shall be designed and applied.
Dieser Satz lässt sich in die folgenden sechs Teilanforderungen aus jeweils nicht-komplexen Sätzen zerlegen:
- Physical protection against natural disasters shall be designed.
- Physical protection against malicious attack shall be designed.
- Physical protection against accidents shall be designed.
- Physical protection against natural disasters shall be applied.
- Physical protection against malicious attack shall be applied.
- Physical protection against accidents shall be applied.
Lassen sich Anforderungen – wie die im Beispiel gezeigten – nicht in weitere Teilanforderungen zerlegen, bezeichnen wir sie im Folgenden als kanonische Teilanforderungen. Es ist aus zwei Gründen sinnvoll, Anforderungen auf diese Weise zu zerlegen: Zum einen gehören die Teilanforderungen (1) bis (3) als Teil eines zyklischen Vorgehens zur Planungsphase und die Teilanforderungen (4) bis (6) zur Umsetzungsphase (Stichwort: Plan–Do–Check–Act-Zyklus, PDCA). Und zum anderen liegen Naturkatastrophen, bösartige Angriffe oder Unfälle in vielen Organisationen in der Zuständigkeit mehrerer verschiedener Abteilungen. Bei der Steuerung eines ISMS ist es gegebenenfalls wichtig zu wissen, in welcher ISMS-Phase sich ein Control aktuell befindet und wer rechenschaftspflichtig für seine Umsetzung ist.
Außerdem kann die Planung von Schutzmaßnahmen gegen Naturkatastrophen bereits fertig konzipiert und in Anwendung sein, während die Konzeption von Schutzmaßnahmen bei Unfällen noch unvollständig ist. Meist spricht man in der Implementierung und bei Audits dann davon, dass ein Control „teilweise erfüllt“ ist. Dieser Vermerk ist aber ungenau, da nicht klar ist, welche der kanonischen Teilanforderungen erfüllt sind und welche nicht. In einer relationalen Verknüpfung des gesamten Controls mit der Zuständigkeit und dem Erfüllungsgrad gerät man schnell an die Grenzen des Machbaren – in ISMS-Tools wie verinice, Instant ISMS auf Confluence-Basis oder komplexen Excel-Tabellen bewirkt das dann einen Informationsverlust oder Verzerrungen in der Gesamtbewertung.
Probleme komplexer Sätze
Die Interpretation einzelner oder mehrerer Sätze eines Controls als zusammenhängende Einzelmaßnahme führt zu folgenden Problemen:
- Die Verwendung der Control-Bezeichnung eignet sich bei der elektronischen Verarbeitung in Datenbanken und Tabellen nicht als Primärschlüssel.
- Eine eindeutige Zuweisung von Zuständigkeiten ist nicht immer möglich, in vielen Fällen aber nötig – im genannten Beispiel sind etwa Konzeptionierung und Anwendung von Schutzmaßnahmen gegebenenfalls unterschiedlichen Personen(gruppen) zuzuweisen.
- Eine eindeutige Erfassung des Status für ein einzelnes Control ist nicht möglich und führt gegebenenfalls zu Fehlinterpretationen. Im genannten Beispiel würde etwa „A.11.1.4 teilweise erfüllt“ gelten, wenn zwar (1) erfüllt, aber (2) bis (6) nicht erfüllt wären – dasselbe wäre allerdings der Fall, wenn nur (1) nicht erfüllt, aber (2) bis (6) allesamt erfüllt wären. Der zweite Fall würde jedoch offensichtlich meist ein höheres Sicherheitsniveau bedeuten. Die Frage, in welchem Maß ein Control erfüllt ist, wenn eine oder mehrere, aber nicht alle kanonischen Teilanforderungen erfüllt sind, lässt sich letztlich kaum beantworten.
- In der Überblicksauswertung fallen Controls unabhängig davon ins Gewicht, wie viele kanonische Teilanforderungen sie jeweils enthalten. Bei der durchgeführten Analyse aller 114 Controls zeigten sich jedoch große Unterschiede: Ein Control enthält demnach mindestens eine, im Durchschnitt 4,4 und maximal bis zu 35 kanonische Teilanforderungen.
- Bei den Oder-Verknüpfungen handelt es sich in der überwiegenden Anzahl der Fälle um ein aufzählendes, nicht um ein ausschließendes Oder. Hier kommt die Analyse der vorliegenden Bedeutung (Semantik) nicht ohne eine fachliche Interpretation aus.
Kanonische Teilanforderungen
Für die durchgeführte Analyse wurden die Sätze der ISO/IEC 27001 jeweils als kanonische Teilanforderungen betrachtet. Ausgehend von dieser Interpretation lassen sich diese dann mit einem Primärschlüssel versehen und einzeln managen. So wird eine eindeutige Zuweisung von Zuständigkeiten ebenso ermöglicht wie eine aussagekräftige Verknüpfung des Status kanonischer Teilanforderungen mit einem Erfüllungsgrad des zugehörigen Controls. Die Verzerrung einer Überblicksauswertung wird dadurch zwar nicht gänzlich ausgeräumt, aber verringert.
Annäherung an die tatsächliche Komplexität
Durch die unzureichende Aufgliederung der Anforderungen in der ISO/IEC 27001 kann beim unbedarften Lesen leicht der falsche Eindruck entstehen, es seien maximal „nur“ 114 Einzelmaßnahmen zu erfüllen. Dabei entspricht jede Teilanforderung in kanonischer Form mindestens einer Maßnahme, die im Rahmen des Information-Security-Managements zu steuern ist.
Durch konsequente Zerlegung haben die Autoren über 800 kanonische Teilanforderungen ermittelt: Für den Textteil wurden 321 Anforderungen in kanonischer Form identifiziert – für Annex A 501 kanonische Teilanforderungen. Diese Zahlen übersteigen die vermeintlich geringe Anzahl von 10 Clauses und 114 Controls um ein Vielfaches.
Zusätzlich spielt der Scope des ISMS eine beträchtliche Rolle, weil einzelne Controls sich auf mehrere Zielobjekte beziehen können (z. B. Gebäude, Systeme, Prozesse, Applikationen). Umfasst der Scope des ISMS beispielsweise fünf Produktionsstandorte, wäre das Beispiel-Control A.11.1.4 jeweils für alle fünf Standorte zu betrachten. Das Gleiche gilt für Controls, die sich auf mehrere Prozesse beziehen oder mehrere Applikationen betreffen. In diesem Fall muss man die Controls und ihre kanonischen Teilanforderungen im ISMS jeweils mehrfach betrachten, denn Konzeption und besonders der Stand der Umsetzung könnten dabei jeweils unterschiedlich ausfallen.
Geht man im Fall des Beispiel-Controls A.11.1.4 davon aus, dass die Konzeption der Maßnahmen für alle einheitlich erfolgt und nur die Anwendung je Standort mehrfach zu dokumentieren ist, ergeben sich dennoch schon 3 + 3 × 5 = 18 Dokumentationsobjekte. Wenn die Umsetzung des Controls aus zehn Einzelmaßnahmen besteht, die im Rahmen der kanonischen Teilanforderungen (1) bis (3) geplant werden, ergeben sich – für ein einziges Beispiel-Control – bereits 3 + 3 × 5 × 10 = 153 Prüfpunkte. Dieses Beispiel verdeutlicht, dass für die Beurteilung der Komplexität der ISO/IEC 27001 neben der Anzahl der kanonischen Teilanforderungen ein weiterer Komplexitätsfaktor zu berücksichtigen ist, der sich direkt aus dem Scope des ISMS ergibt. Hierzu sind allem voran die Zahl kritischer Betriebsprozesse sowie von Gebäuden, Systemen oder Applikationen zu betrachten – diese sollen im Folgenden als Komplexitätstreiber bezeichnet werden.
Verdeckte Multiplikatoren
Zur Ermittlung der Komplexitätstreiber haben die Autoren für alle kanonischen Teilanforderungen bewertet, ob diese weitestgehend einmalig oder eher parallel für mehrere Zielobjekte betrachtet werden müssen – dabei wurde zwischen 15 Kategorien von Komplexitätstreibern unterschieden (siehe unten).
Dieser Schritt ist in vielen Punkten bereits eine Interpretation des Standards bezüglich seiner praktischen Umsetzung: Ob man eine einzelne Anforderung eher als einmalige Planungsaufgabe oder doch als sich wiederholende Durchführungsaufgabe betrachtet, lässt sich nicht immer eindeutig entscheiden – einzelne Teilanforderungen mussten auch mehrfach markiert werden, weil sie beispielsweise nicht nur für IT-Systeme, sondern auch für Applikationen zu berücksichtigen waren. Verschiedene Anwender:innen der ISO/IEC 27001 könnten hier bei gleichem Grundgedanken zu unterschiedlichen Ergebnissen kommen. Die folgenden Zahlen können daher nur als exemplarische Modellbetrachtung gelten, die je nach der betrachteten Organisation abweichen kann.
Aus dem Pool der rund 800 ermittelten kanonischen Teilanforderungen haben die Autoren 388 identifiziert, die je nach Scope des ISMS mehrfach anzuwenden wären. Dabei handelt es sich um 47 Fälle, die sich auf Clauses aus dem Textteil beziehen, und 341 Fälle, die Controls aus Annex A betreffen.
Für die Modellrechnung, die verdeutlicht, wie der Scope die Komplexität des ISMS beeinflusst, wurden 15 Komplexitätstreiber-Kategorien und die folgenden Annahmen bezüglich des Scopes eines ISMS beispielhaft zugrunde gelegt:
- 3 × kritische Betriebsprozesse
- 10 × Security-Prozesse
- 10 × Policies
- 3 × Gebäude
- 5 × Informationssysteme
- 3 × Applikationen
- 500 × Personalfälle
- 50 × On-/Cross-/Off-Boarding von Personal
- 3 × Audits
- 5 × Lieferantenbeziehungen
- 5 × Interested Parties
- 5 × Rollen
- 25 × Risiken und Chancen
- 10 × Nichtkonformitäten
- 10 × Events und Incidents
Unter diesen Annahmen müssen 13 126 Einzelpunkte im ISMS gesteuert werden – teils wiederum mit mehreren Einzelmaßnahmen je Teilanforderung. Davon entfallen 11 150 auf 43 kanonische Teilanforderungen, die jeweils für alle Personalfälle und -veränderungen anzuwenden sind – rund 2000 Einzelpunkte hängen nicht direkt von Personalfällen ab.
Komplexität in der Praxis
Für die Implementierung eines ISMS nach ISO/IEC 27001 werden unterschiedliche Zeiträume angegeben: Üblicherweise geht man je nach Scope des ISMS von einem Zeitansatz von bis zu zwei Jahren aus [1,2]. Viele Quellen von Beratungsunternehmen weisen darüber hinaus auf die Gefahr gescheiterter Implementierungsprojekte hin (vgl. etwa www.google.com/search?q=isms+projekt+sc heitern). Laut einer Studie aus der Energiewirtschaft ist gerade einmal gut die Hälfte der Befragten, die bereits in der Umsetzungsphase eines zertifizierten ISMS sind, mit den Mindestanforderungen voll und ganz vertraut, wobei diese ja aus einer Lektüre der ISO/IEC 27001 eigentlich hervorgehen sollten [3].
Mit der hier vorgestellten Methode lässt sich der Aufwand zur Implementierung eines ISMS anhand der Anzahl von Einzelmaßnahmen recht präzise abschätzen. Vor dem Hintergrund der über 800 dabei ermittelten kanonischen Teilanforderungen oder mehreren tausend Einzelpunkten der Modellrechnung sind Zeitansatz und praktische Probleme in der Implementierung gerade auch für Führungskräfte und das Top-Management viel leichter zu erklären. Die Anzahl von mehreren tausend Betrachtungsobjekten für den Beispiel-Scope zeigt deutlich, was viele Praktiker:innen bereits wissen: Eine ISMS-Implementierung ist eine komplexe und sehr aufwendige Aufgabe. Vor allem die schiere Anzahl der Einzelpunkte, die für alle Personalfälle zu betrachten sind, verdeutlicht den enormen Aufwand bezüglich der umzusetzenden Awareness-Maßnahmen (vgl. [4]).
Empfehlungen für Normen, Richtlinien & Co.
Die folgenden, aus der Analyse der Autoren abgeleiteten Empfehlungen zur Verbesserung der (DIN EN) ISO/IEC 27001 lassen sich auch auf jede andere Form von Dokumenten übertragen, die Anforderungen beschreiben. Dazu gehören etwa organisationsinterne Leitlinien, Richtlinien oder Konzepte und weitere Normen für Managementsysteme wie die ISO 9001 oder ISO/IEC 20000.
Anforderungen sollten nach Möglichkeit so formuliert sein, dass
- sie bereits als kanonische Teilanforderung vorliegen,
- jeder Satz als Aktivsatz formuliert ist,
- beim Gebrauch von Verben, Substantiven, Adjektiven und weiteren Wortarten möglichst wenige, dafür aber semantisch klar voneinander abzugrenzende Begriffe Verwendung finden sowie
- alle Sätze über eine möglichst einheitliche und wenig verschachtelte Satzstruktur verfügen.
- Allgemein empfiehlt sich eine Orientierung an der sogenannten „einfachen Sprache“ (siehe etwa https://portaleinfach.org/abc-der-einfachen-sprache/).
Darüber hinaus müssen Übersetzungen in größerem Umfang der Bedeutung der Originalbegriffe Rechnung tragen und sollten unübliche Neologismen vermeiden. In vielen Fällen ist anzuraten, englische Fachbegriffe im Original zu belassen (aus gutem Grund ist nie jemand auf die Idee gekommen, den Begriff „Internet“ mit „Zwischennetz“ zu übersetzen).
Bessere Industrienormen
Aus dem sprachwissenschaftlich geprägten Forschungsansatz der Autoren wurden auch Konzepte entwickelt, um Industrienormen wie die ISO/IEC 27001 zu verbessern – drei davon werden im Folgenden kurz vorgestellt. Ziel der Umsetzung solcher Konzepte ist die Vereinfachung und Vereinheitlichung auf der Basis einer leichteren Verständlichkeit und Zugänglichkeit. Gleichzeitig lässt sich so auch für eine höhere Akzeptanz von Industrienormen in der jeweiligen Zielgruppe sorgen.
Abbau von Ungenauigkeit
Die Verwendung einer Vielzahl von Verben mit ähnlicher Bedeutung zur Erläuterung der Anforderungen im Textteil der ISO/IEC 27001 führt, wie eingangs angesprochen, zu Ungenauigkeiten beziehungsweise Widersprüchen. So treten beispielsweise verschiedene Kombinationen (Prädikate) aus dem Modalverb „shall“ mit verschiedenen Vollverben auf, die der Formulierung zwingend umzusetzender Anforderungen dienen.
Der Textteil der ISO/IEC 27001 führt insgesamt 27 verschiedene Prädikate auf: Die meisten Nennungen entallen auf „shall be“ (12), „shall retain“ (10), „shall determine“ (9), „shall implement“ (7) und „shall ensure“ (5) – mit je drei bis vier Nennungen folgen „shall take“, „shall establish“, „shall review“, „shall plan“, „shall include“ und „shall define“. Jeweils zweimal formuliert die Norm „shall maintain“, „shall evaluate“, „shall control“, „shall continually improve“, „shall conduct“ und „shall apply“, jeweils einmal „shall select“, „shall provide“, „shall perform“, „shall make“, „shall keep“, „shall demonstrate“, „shall deal“, „shall consider“, „shall assign“ und „shall address“.
Nun ist es die Aufgabe einer Industrienorm, Anforderungen an ein Verfahren festzulegen. Am besten gelingt das durch eine eindeutige Sprache. Es sollte für Anwender:innen klar und verständlich gemacht werden, worin etwa der Unterschied zwischen „implement“ und „establish“, „implement and maintain“ oder „implement and control“ besteht.
Die detaillierte Analyse aller Prädikate wirft wie bei den genannten Beispielen inhaltliche Fragen auf, die eine Industrienorm durch eine klare und verständliche Sprache zweifelsfrei beantworten sollte. Um Ungenauigkeiten aufzulösen, die sich aus dem Gebrauch von 27 verschiedenen Prädikaten ergeben, erscheint eine Reduktion der verwendeten Vollverben notwendig. Eine Möglichkeit dazu wäre, sich bei semantisch stark ähnlichen oder sogar gleichbedeutenden Verben auf nur eines festzulegen – so ließen sich einzelne Anforderungen vereinfachen, ohne Präzision zu verlieren. Für die verbleibenden Prädikate kann eine Art Glossar mit Erläuterungen dabei helfen, die Anweisungen besser zu verstehen und so eine optimale Umsetzung zu ermöglichen. So wäre sowohl für unerfahrene Organisationen als auch bestehende Managementsysteme besser zu klären, was zur Erfüllung eines Controls konkret zu tun ist.
Abbau von Mehrdeutigkeiten
Mehrdeutigkeit ist ein sprachliches Phänomen, das im Alltag häufiger auftritt. Beispielsweise ist nur aus dem Zusammenhang eines Satzes beziehungsweise innerhalb eines Gesprächs (Kontext) erkennbar, ob es sich bei einer „Bank“ um eine Sitzgelegenheit oder ein Kreditinstitut handelt. Dabei kann es zu lustigen Missverständnissen kommen – bei bestimmten Anweisungen können mehrdeutige Sätze aber auch für Probleme oder Gefahren sorgen.
Zur Verdeutlichung ein plakatives Beispiel aus einer fiktiven Dienstvorschrift für den Blaulichteinsatz eines Krankenwagens: „Bei Menschenmengen auf der Fahrbahn – bitte umfahren!“ Bei gesprochener Sprache würde schnell ersichtlich, dass man die Menschen umfahren, also an ihnen vorbeifahren soll. Im geschriebenen Satz ist aber mangels Betonung nicht zweifelsfrei ersichtlich, ob „umfahren“ oder „umfahren“ gemeint ist.
Darüber hinaus können bestimmte Begriffe in einer Fachsprache andere Bedeutungen als in der Standardsprache haben: Wenn beispielsweise in der Standardsprache von einer „Untiefe“ die Rede ist, wird damit eher eine sehr große Tiefe bezeichnet – im fachsprachlichen Bereich der Schifffahrt bezeichnet eine „Untiefe“ jedoch geringe Tiefen eines Gewässers, die für fahrende Schiffe eine Gefahr darstellen können. Dieses Beispiel zeigt, dass es möglich ist, dass gleichlautende Begriffe sogar das genaue Gegenteil bedeuten können (vgl. auch „Quantensprung“ usw.). Solche sprachlichen Eigenheiten können ein großes Problem für die Verständigung darstellen – vor allem, wenn Personen unterschiedlicher Fachbereiche miteinander arbeiten und kommunizieren.
Auch für die ISO/IEC 27001 existieren fachsprachliche Begriffe, die teils so ungebräuchlich sind, dass selbst Fachkreise sie nur in direkter Anwendung der Norm verwenden und Laien sie überhaupt nicht oder falsch verstehen. Das trifft besonders auf die deutsche Übersetzung DIN EN ISO/IEC 27001 zu, was direkt zu einem dritten Punkt führt:
Vermeidung unüblicher beziehungsweise falscher Übersetzungen
Ein Beispiel dafür ist der Begriff „Telearbeit“ für das englische „Teleworking“. Hier konkurrieren die Begriffe „Telecommuting“, „Remote Working“, „Telework“, „Teleworking“, „Working from Home“ und „Mobile Work“ mit den deutschen Termini „Telearbeit“, „Teleheimarbeit“, „alternierende Telearbeit“ und „mobile Telearbeit“. Die wörtlichen Übersetzungen bezeichnen dabei jeweils etwas dezent anderes als die englischen Originalbegriffe – die Bedeutungen der Begriffe sind also nicht deckungsgleich. Die Linguistik spricht davon, dass hier eine unterschiedliche Semantik vorliegt.
Das betrifft auch den Begriff „Policy“, der im Englischen eine größere semantische Breite hat als der deutsche Begriff „Politik“. Politik ist im Deutschen in seiner Bedeutung sehr festgelegt und daher darf „Policy“ nicht einfach mit „Politik“ übersetzt werden. Es ist missverständlich, wenn die DIN EN ISO/IEC 27001 von „Politik“ spricht, aber „Richtlinie“ oder „Leitlinie“ meint. Auch die „interessierten Parteien“ als Übersetzung von „interested Parties“ haben natürlich nichts mit Politik zu tun – hier sollte man besser von „relevanten Interessengruppen“ sprechen.
Wissen Sie, was „Zutrittsstellen“ sind? Orientiert man sich am englischen Original „Access Points“, fällt auf, dass im Control A.11.1.6 wohl eher „Gebäudeeingänge“ oder kurz „Eingänge“ gemeint sind. Auch wenn in der deutschen Grammatik Wortzusammensetzungen wie „Zutrittsstelle“ gebildet werden dürfen – ein gebräuchlicher Begriff oder gar im Duden verzeichnetes Wort ist das natürlich nicht. Auch die Übersetzung von „Premises“ mit dem enger gefassten Begriff „Räumlichkeiten“ ist unglücklich: Hier würde man besser mit dem Begriffspaar „Betriebsgelände und Räumlichkeiten“ übersetzen, um die Semantik möglichst wenig zu verändern.
Auch der englische Begriff „Access“ hat eine größere semantische Breite als seine Entsprechungen im Deutschen – hier sind im Wesentlichen die Begriffe „Zugang“, „Zutritt“ und „Zugriff“ von Bedeutung. Wenn in ISO/IEC 27001 unter A.9.2 von „User Access Management“ die Rede ist, dann ist damit nicht nur eine „Benutzerzugangsverwaltung“, also eine Verwaltung von Zugängen gemeint, wie die DIN EN ISO/IEC 27001 vermuten lässt. Um in der deutschen Übersetzung eine vergleichbare semantische Breite zu erreichen, sollte man besser von einem „Berechtigungsmanagement“ sprechen, wenn man die Semantik möglichst weitgehend erhalten will.
Industrienormen sollten generell so formuliert sein, dass sie nur auf eine einzige Art verstanden werden, um die Anforderungen optimal umsetzen zu können. Die ISO/IEC 27001 weist jedoch an einigen Stellen Mehrdeutigkeiten auf, die besser vermieden werden sollten. Eine Problematik zeigt sich bei der offiziellen Übersetzung der ISO/IEC 27001 zur DIN EN ISO/IEC 27001 in der unüblichen und aus linguistischer Perspektive irreführenden Übersetzung bestimmter englischer Fachbegriffe.
Beim Umgang mit fremdsprachlichen Fachbegriffen kann man auf zwei Strategien zurückgreifen: Entweder belässt man die Begriffe so, wie sie sind. Im Rahmen dieses Artikels sprechen die Autoren daher beispielsweise von „Controls“. Der englischsprachige Begriff wird also auch in einem deutschsprachigen Artikel beibehalten, da weder die wörtliche Übersetzung „Kontrollen“ noch die offizielle Übersetzung „Maßnahmen“ die Semantik des englischsprachigen Begriffs treffen – es geht ja gerade darum, dass eine Organisation aus den Controls erst noch Maßnahmen ableiten muss. Die englische Entsprechung wäre hier eher „measure“ – in der Rückübersetzung wird deutlich, dass „Maßnahme“ nicht etwa eine wörtliche Übersetzung ist, sondern den semantischen Inhalt des Begriffs verändert.
Eine weitere Möglichkeit besteht darin, entsprechende Fachbegriffe sinnerhaltend zu übersetzen. Dabei ist darauf zu achten, dass die Übersetzungen sich an der Standardsprache orientieren und keine Unklarheiten oder Mehrdeutigkeiten entstehen. Wörtliche Übersetzungen können hingegen Probleme verursachen, die mit unterschiedlichen Bedeutungen oder einer abweichenden semantischen Breite von Begriffen in den verschiedenen Sprachen zu tun haben. Nicht jeder Begriff ist eindeutig und nur mit einem einzelnen Wort übersetzbar! In diesem Sinne ist jede Übersetzung (auch eine wörtliche) eine Interpretation des Originaltexts. Man sollte also nicht dem Trugschluss unterliegen, dass wörtliche Übersetzungen präziser sind als umschreibende Übersetzungen.
Diesen Grundsatz berücksichtigt die ISO/IEC 27001 noch nicht ausreichend. So ist es nicht sinnvoll, „Normative References“ als „normative Verweisungen“ zu übersetzen, da es den Ausdruck Verweisung im standardsprachlichen Gebrauch schlicht nicht gibt. Solche Neologismen, also Wortneuschöpfungen, sind im Rahmen von Industrienormen nur dann sinnvoll, wenn sie von den Anwendern verstanden, akzeptiert und verwendet werden. Denn die Akzeptanz eines Fachbegriffs innerhalb einer bestimmten Gruppe ist ein wichtiger Faktor: Die Menschen, die sich in der entsprechenden Fachsprache bewegen und sich täglich mit Problemen beispielsweise der Informationssicherheit auseinandersetzen, sind bei der Etablierung neuer Begriffe zu berücksichtigen.
Um herauszufinden, welche fachsprachlichen Begriffe – ob nun übersetzt oder in der Originalsprache belassen – in der Informationssicherheit „üblich“ sind, haben die Autoren eine Umfrage entwickelt. Damit sollen die in diesem Artikel getroffenen Aussagen verifiziert und weitere Forschungsansätze und Empfehlungen ableitbar werden. Alle Leser sind eingeladen, unter https://cyclesec.com/umfrage-cais an dieser Umfrage teilzunehmen.
Anhand der Ergebnisse sollen Formulierungen gefunden werden, die dabei helfen, die Anforderungen der ISO/IEC 27001 zu vereinheitlichen, klarer zu gestalten und gleichzeitig die Akzeptanz der Anwender zu erhöhen. Das Ziel soll dabei sein, betriebliche Abläufe zu optimieren und vermeidbare Fehler, die auf Verständigungsproblemen basieren, zu verhindern.
Fazit
Zum jetzigen Stand des Forschungsprojekts wurden bereits wichtige Erkenntnisse zur Sprachstruktur der ISO/IEC 27001 gewonnen. Mit der Bildung kanonischer Teilanforderungen besteht eine Möglichkeit, komplexe Satzgefüge einer Industrienorm in leichter verständliche Einheiten aufzubrechen. Dabei wurde einerseits die Komplexität einer ISMS-Implementierung deutlich und ein Maß zur Komplexitätsbestimmung für ein konkretes ISMS gefunden. Und andererseits hat diese detaillierte Analyse auch sprachliche Unklarheiten aufgedeckt, die aus inhaltlicher und linguistischer Perspektive verbesserungswürdig sind. Hierzu zählen allem voran verschachtelte Sätze, lange Aufzählungen, sprachliche Mehrdeutigkeiten und ungewöhnliche Übersetzungen. Die Autoren haben einige Empfehlungen zusammengestellt, die im Rahmen der weiteren Forschung überprüft und vertieft werden sollen.
Sebastian Klipper (sk@cyclesec.com) ist Fachbuchautor und Geschäftsführer der Unternehmensberatung für Informationssicherheit CycleSEC sowie Kursautor für Informationssicherheit und Tutor an der Wilhelm Büchner Hochschule, Private Fernhochschule Darmstadt. Steffen Hessler (steffen.hessler@ruhr-uni-bochum.de) ist Doktorand und wissenschaftlicher Mitarbeiter am Germanistischen Institut an der Ruhr-Universität Bochum und Absolvent des Forschungskollegs SecHuman – Sicherheit für Menschen im Cyberspace.
Literatur
[1] Bundesdruckerei GmbH, Einführung eines Informationssicherheits- Management-Systems (ISMS) bei Energieversorgern, Whitepaper, April 2018, www.bundesdruckerei.de/de/whitepaper/download/877/whitepaper-isms.pdf.pdf
[2] Jürgen Mauerer, Das sollten Unternehmen beim Aufbau eines ISMS beachten, ComputerWeekly TechTargetNetzwerk, November 2018, www.computerweekly.com/de/ratgeber/Das-sollten-Unternehmen-beim-Aufbaueines-ISMS-beachten
[3] Dirk Stieler, Torsten Beyer, Endspurt! Für Stadtwerke & Co gilt: ISMS-Einführung für Energieversorger ist Pflicht,
Februar 2017, https://axxcon.com/einblicke-und-wissen/endspurt-fuer-stadtwerke-co-gilt-isms-einfuehrung-fuerenergieversorger-ist-pflicht/
[4] DIN e. V. (Hrsg.), Wolfgang Böhmer, Knut Haufe, Sebastian Klipper, Thomas Lohre, Rainer Rumpel, Bernhard C. Witt, Managementsysteme für Informationssicherheit (ISMS) mit DIN EN ISO/IEC 27001 betreiben und verbessern, Beuth, Dezember 2017, ISBN 978-3-410-26032-5