Niemand ist eine Insel. Auch ein Unternehmen oder eine Organisation ist keine Insel. Es gibt immer einen Kontext, ein Umfeld, Schnittstellen und Abhängigkeiten.Eine Organisation die ein Informationssicherheits-Managementsystem aufbauen möchte muss diese Themen berücksichtigen.
Die Norm ISO/IEC 27001 greift diese Themen richtigerweise gleich zu Beginn der Implementierung auf. In Kapitel 4.1 „Verstehen der Organisation und ihres Kontextes“ wird dazu gesagt: „Die Organisation muss externe und interne Themen bestimmten, die für ihren Zweck relevant sind und sich auf ihre Fähigkeiten auswirken, die beabsichtigten Ergebnisse ihres Informationssicherheits-Managementsystems zu erreichen“
Warum steht dieses Verständnis am Anfang, was gehört zum Kontext und welche Auswirkung hat es auf die Implementierung?
Wie die Norm selbst sagt, wirkt sich der Kontext auf die Fähigkeit einer Organisation aus, ihre Ziele bzw. beabsichtigten Ergebnisse zu erreichen. Die Ziele müssen aufgrund des Kontextes nicht angepasst werden, aber die Planung zur Erreichung der Ziele muss den Kontext berücksichtigen. Um eine realistische Planung zu machen (und die sollte am Anfang der Implementierung stehen) muss der Kontext verstanden und ausreichend berücksichtigt werden.
Der Kontext selbst wird an zwei wesentlichen Stellen der Norm wieder aufgegriffen. Zum einen können sich aus dem Kontext Risiken und Chancen ergeben, auf die die Organisation angemessen reagieren muss. Zum anderen beeinflusst der Kontext den Geltungsbereich des ISMS. Auf diese beiden Punkte wird in dieser Artikelserie noch eingegangen.
Was ist der Kontext?
Die Norm nennt hier „externe und interne Themen … die relevant sind“. Was das für Themen sein könnten wird in der Norm nicht weiter ausformuliert. Ein Blick über den Tellerrand in Richtung ISO 31000 und ISO 9001 lehrt uns folgendes:
1. „Themen“ können grundsätzlich sowohl positiv als auch negativ, d.h. förderlich oder hinderlich für die Informationssicherheit sein. Beides sollte berücksichtigt werden.
2. Um den externen Kontext zu verstehen sollten folgende Themen betrachtet werden:
a. Gesetze
b. Technologien
c. Wettbewerb
d. Markt
e. Kultur
f. Soziales Umfeld
g. Wirtschaftliches Umfeld
h. International, national, regional oder lokal.
3. Folgende Themen können den internen Kontext erläutern:
a. Unternehmenswerte
b. Kultur
c. Wissen
d. Leistungskultur
Um den Kontext zu verstehen ist es hilfreich diese Themen in einer offenen Diskussion aufzulisten. Dabei sollte großzügig und kreativ gearbeitet werden (was auch sehr lustig sein kann). Es ist immer möglich Themen im Nachgang als irrelevant zu verwerfen. Das ist besser als relevante Themen zu übersehen. Wurden Themen identifiziert, sollte bestimmt werden, inwieweit ein Thema tatsächlichen Einfluss auf die Zielerreichung haben kann. Dabei wird man vielleicht feststellen, dass manche Themen doch nicht so relevant sind, wie zuerst gedacht. Vielleicht werden dabei aber auch weitere relevante Themen identifiziert, die vorher nicht so offensichtlich waren.
Der nächste Schritt der Kontextbetrachtung ist die Identifikation der interessierten Parteien und deren Anforderungen an das Informationssicherheits-Managementsystem der Organisation (Kapitel 4.2 „Verstehen der Erfordernisse und Erwartungen interessierter Parteien“) Oft ergeben sich die interessierten Parteien aus den zuvor identifizierten Themen. Wird z.B. das ISMS in einem regulierten Umfeld umgesetzt, dann könnte die Aufsichtsbehörde zu den interessierten Parteien gezählt werden. Ein bestimmter Kunde mag Anforderungen an das ISMS der Organisation formuliert haben und wird so zur interessierten Partei. In einem anvisierten Marktsegment ist ein bestimmter Standard oder ein Sicherheitsniveau etabliert, das die Organisation mindestens erreichen muss um in diesem Segment Kunden zu gewinnen. Aus solchen Überlegungen ergeben sich die interessierten Parteien und deren Anforderungen. Um diese Anforderungen zu konkretisieren eignet sich eine Einfluss/Auswirkungsmatrix.
Das Verständnis der Organisation und des Kontextes muss bei der Definition des Geltungsbereichs berücksichtigt werden (4.3). Die Norm fordert von der Organisation die Grenzen des Geltungsbereichs zu bestimmen und zu dokumentieren und dabei die Erkenntnisse aus den Schritten 4.1 und 4.2 zu berücksichtigen. Zusätzlich müssen noch Schnittstellen und Abhängigkeiten berücksichtigt werden. Bei diesen geht es explizit um Tätigkeiten die von der Organisatin selbst durchgeführt werden und solchen, die außerhalb der Organisation durchgeführt werden. Hier kann Organisation im Sinne des Geltungsbereichs eher eng gefasst werden. Die Schnittstellen und Abhängigkeiten ergeben sich wiederum aus dem Kontext und den Anforderungen der interessierten Parteien.
Niemand ist eine Insel. Auch ein Unternehmen oder eine Organisation ist keine Insel. Ein Beispiel soll das verdeutlichen.
Ein Unternehmen, dass Software im Kundenauftrag entwickelt, denkt über die Implementierung eines ISMS nach. Die Kontextbetrachtung ergibt folgendes:
Das Unternehmen besteht seit 3 Jahren und wächst schnell. Zur Zeit sind dort über 50 Mitarbeiter beschäftigt. Es gibt mehrere Entwicklerteams, die verschiedene Technologien abdecken und Auftragsentwicklung für verschiedene Kunden machen. Ein Team entwickelt ein Standardprodukt dass in den nächsten Jahren auf den Markt gebracht werden soll. Zusätzlich gibt es den Bereich Projektmanagement, Vertrieb und HR, sowie die Bereiche Marketing, Controlling, Finance und Geschäftsführung. Die interne IT ist an eine lokale IT-Firma outgesourced. Die Betreuung der Anwender der Auftraggeber übernimmt ein externes Callcenter. Dessen Mitarbeiter pflegen auch die Dokumentation der Software und machen die User Acceptance Tests.
Der Branche ist nicht reguliert aber es gibt anwendbare Gesetze wie BDSG (EU-DSGVO), TMG und TKG, da Kunden des Unternehmens bei der Anwendung der entwickelten Software in den Geltungsbereich dieser Gesetze fallen. In der Branche etabliert sich die Norm ISO/IEC 27001 als Standard und einige Kunden haben beim Vertrieb bereits nach einer Zertifizierung gefragt. Es zeichnet sich ab, dass einer der größten Kunden die Zertifizierung für Zulieferer demnächst fordern wird.
Das Unternehmen hat seinen Sitz in einem großen Bürokomplex und teilt sich die Fläche mit einem weiteren Unternehmen, dass einer der Geschäftsführer gegründet hat. Zwei dort beschäftigte Softwaretester unterstützen die Entwickler bei der Qualitätskontrolle. Die Zutrittskontrollen, ebenso wie Versorgungsleitungen (Strom, Wasser, Telefon) werden von der Gebäudeverwaltung gestellt. Das Softwarerepository liegt auf einem GitHub Server bei einem großen RZ-Betreiber. Entwickler verwenden z.T. Funktionen aus zugekauften oder frei verfügbaren Bibliotheken. Die Entwickler stammen aus verschiedenen europäischen Ländern und sprechen untereinander hauptsächlich englisch.
Hier einige Beispiele, welche Auspekte aus dieser kurzen Betrachtung abgeleitet werden können.
Interne Themen:
internationales Entwicklerteam
Mehrsprachigkeit
Fremdfirma in den selben Räumlichkeiten
Externe Themen:
Branchenstandard ISO 27001
Wesentliche Sicherheitsfunktionen werden extern geliefert
Kunden fordern ISMS
Zugriff auf Kundendaten im Rahmen von Softwareentwicklung
Interessierte Parteien und deren Anforderungen
Aufsichtsbehörden – Kontrolliert die Einhaltung von Regulatorien und gibt Orientierungshilfen heraus
Kunden (evtl. ein besonderer Kunde) – möchte Informationssicherheit in ausgegliederter Softwareentwicklung sicherstellen und fordert ein ISMS nach ISO 27001 (Frage: Gibt es einen Sicherheitskatalog des Kunden, der eingehalten werden muss?)
Mitarbeiter – benötigen Unterlagen und Training in verschiedenen Sprachen
Geschäftsführung – Möchte Prozesse und Methoden auch in anderen Unternehmen übernehmen, Forciert Lean Management, Wirtschaftlichkeit soll bei der Implementierung ISMS berücksichtigt werden, macht konkrete Time/Budget Vorgaben
Schnittstellen/Abhängigkeiten:
Gebäudeverwaltung – stellt Zutrittskontrollen und Versorgungsleitungen zur Verfügung
RZ-Betreiber – hostet GitHub
Hersteller – liefern Bibliotheken für die Softwareentwicklung
Fremdfirma – Qualitätssicherung in der Softwareentwicklung
Fremde IT-Firma – Betreut die lokale IT
Callcenterbetreiber – Anwenderbetreuung, Dokumentation und User Acceptance Test
Bei der Gestaltung des Geltungsbereichs müssen die identifizierten Themen, interessierte Parteien sowie Schnittstellen und Abhängigkeiten berücksichtigt werden.
Im nächsten Beitrag werden verschiedene mögliche Geltungsbereichsdefinitionen analysiert.
