Kontext der Organisation – Teil 1

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 zweiten Teil des Beitrags werden verschiedene mögliche Geltungsbereichsdefinitionen analysiert.

Was macht ein gutes internes Audit aus?

Jedes Managementsystem sollte auf kontinuierliche Verbesserung ausgelegt sein. Ein Managementsystem, dass nur den Status Quo aufrechterhält ist kaum erstrebenswert. So ist kontinuierliche Verbesserung auch eine Kernanforderung eines Informationssicherheits-Managementsystems nach ISO/IEC 27001.
Ein Werkzeug zur Identifikation von Verbesserungspotential kann das interne Audit sein. Per Definition ist ein Audit ein systematischer, unabhängiger und dokumentierter Prozess zur Erlangung von Auditnachweisen und zu deren objektiven Auswertung, um zu ermitteln, inwieweit Auditkriterien erfüllt sind. Als „intern“ wird ein Audit bezeichnet, wenn es in der Verantwortung der Organisation selbst liegt, die Auditkriterien und den Umfang des Audits festzulegen. Die obengenannte Definition klingt erst mal nach einer simplen schwarz-weiß Angelegenheit. Vielfach wird unter einem Audit tatsächlich das simple Abhaken von Checklisten verstanden. Dem ist aber nicht so. Die Vorgaben der ISO/IEC 27001 sind bewusst so generisch gestaltet, dass sie von Organisationen aller Art unabhängig von Größe, Struktur und Branche umgesetzt werden können. Dieser enorme Gestaltungsspielraum verlangt vom Auditor eine fachmännische Einschätzung der Umsetzung. Zudem fordert die Norm an vielen Stellen die wirksame Umsetzung. Der Auditor muss daher die Wirksamkeit der Umsetzung beurteilen.
Ein erfahrener Auditor kann also nicht nur erkennen, ob die Anforderungen umgesetzt sind, sondern kann auch die Wirksamkeit der Umsetzung beurteilen und hierzu Verbesserungsvorschläge liefern. Zudem kann er auch die Effizienz der Umsetzung bewerten und Hinweise liefern, die zu tatsächlichen Einsparungen führen. Effizienz wird in der Norm ISO/IEC 27001 nicht berücksichtigt, spielt aber natürlich in vielen Implementierungen eine Rolle und ist zumindest erwünscht, wenn nicht sogar eine Managementvorgabe.
Das Ziel ist demnach ein internes Audit durchführen zu lassen, dass nicht nur die Normkonformität bestätigt, sondern auch Verbesserungsvorschläge zu Effektivität und Effizienz liefert. Wie kann dieses Ziel erreicht werden?
An erster Stelle steht dabei natürlich die Auswahl des richtigen Auditors. Den richtigen Auditor zu finden ist nicht einfach, den falschen dagegen schon. Die Norm fordert in Kapitel 9.2 d) von der Organisation bei der Auswahl von Auditoren auf die Objektivität und Unparteilichkeit des Auditors zu achten. Ein Auditor der nicht unparteilich und objektiv das Audit durchführen kann ist demnach der falsche Auditor. Das kann durchaus auf Mitarbeiter der eigenen Organisation zutreffen. Unter Umständen sind eigene Mitarbeiter nicht unparteilich und objektiv. Dazu zählen Mitarbeiter die selbst an der Implementierung der Norm beteiligt waren. Ganz sicher trifft das auf Berater zu, die im Auftrag der Organisation die Implementierung unterstützt oder sogar verantwortet haben. Den Berater das interne Audit machen zu lassen ist eine wirklich schlechte Idee. Wie wird er wohl seine eigene Arbeit bewerten? Wird er tatsächlich relevante Abweichungen feststellen und Verbesserungspotential identifizieren? Dasselbe mag auch auf einen von ihm persönlich ausgewählten und empfohlenen Auditor zutreffen. (Auditoren die Zertifizierungsaudits durchführen müssen der Zertifizierungsstelle gegenüber erklären, dass sie in den vergangenen 2 Jahren nicht beraterisch für diese Organisation tätig waren, um die Objektivität und Unparteilichkeit des Auditprozesses sicherzustellen. Dasselbe sollte auch auf Auditoren im internen Audit zutreffen.) Es darf nicht vergessen werden, dass ein unparteilich und objektiv durchgeführtes internes Audit eine Normforderung ist und sich daher auf das Ergebnis des Zertifizierungsaudits auswirkt.
Ungeeignet sind auch Auditoren, die mit den Methoden der Audits von Managementsystemen nicht ausreichend vertraut sind und über kein ausreichendes Verständnis der Informationssicherheit verfügen. Leider ist der Begriff „Auditor“ nicht geschützt. Jeder darf sich Auditor nennen, Auditor auf seine Visitenkarte schreiben und in seinem Xing-Profil den Titel Auditor führen. Auch die Begriffe „Lead Auditor“ und „ISO 27001 Auditor“ sowie diverse Variationen davon sind nicht geschützt und werden auch sehr großzügig verwendet. Über die Qualifikation des Auditors geben sie sehr wenig Auskunft. Woran lässt sich die Qualifikation eines Auditors erkennen? Auf diese Frage gibt es keine Pauschalantwort. Sicher lässt sich aber einiges dazu herleiten.
Unter 9.2 c) fordert die Norm ein Auditprogramm in dem unter anderem die Auditmethoden festgelegt sind. Die übliche Methode ist beschrieben in der Norm ISO 19011. Ein qualifizierter Auditor ist mit dieser Norm vertraut und kann über entsprechende Zertifikate seine Fachkenntnis nachweisen. Eine weitere, unabhängige Bestätigung ist die Akkreditierung durch die Dakks, die Deutsche Akkreditierungsstelle. Ein akkreditierter Auditor hat nicht nur seine Kenntnis der Methode nachgewiesen, sondern verfügt über eine ausreichende Berufserfahrung im Bereich der Informationssicherheit.
Die Wahl des richtigen Auditors und der richtigen Methode wirkt sich maßgeblich auf die Qualität des Audits aus. Aber es gibt weitere Aspekte zu berücksichtigen.
In 9.2 werden zwei weitere Aspekte genannt: Auditkriterien (9.2d) und Berichterstattung (9.2c). Üblicherweise liefert die Norm selbst die Auditkriterien für interne Audits, sofern es dabei rein um Normkonformität geht. In vielen Fällen wird auch die Maßnahmenumsetzung oder Konformität zum eigenen Regelwerk als Auditkriterium herangezogen. In beiden Fällen spielt Effizienz eine höchstens untergeordnete Rolle. Gerade im internen Audit kann aber Effizienz als Auditkriterium definiert werden und die Organisation kann den Auditor beauftragen nicht nur Konformität und Wirksamkeit zu bewerten sondern auch ein Auge auf die Effizienz der Prozesse zu haben. Bewertung der Effizienz bzw. Identifikation von Verbesserungspotential kann auch als Auditziel festgelegt werden. Die Auditziele sollten im Vorfeld mit dem Auditor festgelegt werden und der Auditor wird diese nach ISO 19011 sowohl im Auditplan explizit aufführen sowie im Auditbericht bestätigen, dass die Auditziele erreicht wurden (oder auch nicht.)
Das führt zum dritten Aspekt nämlich der Berichterstattung. Ein qualifizierter Auditor liefert einen entsprechend aussagekräftigen Bericht. Die Anforderungen an die Berichterstattung muss aber die Organisation selbst definieren. Wenn mit dem Auditor keine Anforderungen vereinbart wurden, liegt die Auswahl der Inhalte beim Auditor. Die Norm ISO 19011 liefert eine Liste an Mindestbestandteilen eines Auditberichts sowie weitere sehr nützliche Anregungen. Eine dieser Anregungen: „Empfehlungen für Verbesserungen“. Es macht hochgradig Sinn im Auditprogramm festzulegen was in einem Auditbericht alles enthalten sein muss. Der Auditor wird das dann berücksichtigen und den Bericht entsprechend gestalten.
Ein Audit, dass von einem qualifizierten, unabhängigen Auditor durchgeführt wurde, mit dem Auditziel u.a. Möglichkeiten zur Verbesserung zu identifizieren und entsprechend zu berichten kann einen wesentlichen Beitrag zur kontinuierlichen Verbesserung des Managementsystems leisten und erfüllt nicht nur die Anforderung der Norm ein internes Audit durchzuführen. Ein hochwertiges internes Audit liefert auch eine gute Grundlage für das Zertifzierungsaudit und schafft Vertrauen in die Leistung des Managementsystems. Ein hochwertiges internes Audit mag Mehraufwand sowohl intern wie auch extern bedeuten, aber es kann Impulse für Verbesserungen und Effizienzsteigerung liefern, welche wiederum Einsparungen an anderen Stellen bedeuten können.