ISO 27001. Risikoanalyse zur ISO 27001

# 3.80.5

ISO27001. Hinweise des BSI zur Ermittlung zusätzlicher Risiken

Stand: 20191217   20191216   20190521     20190517

Die folgenden Fragestellungen sollten bei der Ermittlung zusätzlicher Gefährdungen berücksichtigt werden:

  • Von welchen Ereignissen aus dem Bereich höhere Gewalt droht besondere Gefahr für den Informationsverbund?
     
  • Welche organisatorischen Mängel müssen vermieden werden, um die Informationssicherheit zu gewährleisten?
     
  • Welche menschlichen Fehlhandlungen können die Sicherheit der Informationen besonders beeinträchtigen?
     
  • Welche speziellen Sicherheitsprobleme können beim jeweils betrachteten Zielobjekt durch technisches Versagen entstehen?
     
  • Welche besondere Gefahr droht durch vorsätzliche Angriffe von Außentätern? Damit sind Personen gemeint, die nicht der eigenen Institution angehören und auch nicht durch besondere Vereinbarungen Zugang zu oder Zugriff auf interne Ressourcen haben.
     
  • Auf welche Weise können Innentäter durch vorsätzliche Handlungen den ordnungsgemäßen und sicheren Betrieb des jeweiligen Zielobjekts beeinträchtigen? Durch vorhandene Zugangs-und Zugriffsberechtigungen sowie durch Insiderwissen droht hier oft besondere Gefahr.
     
  • Drohen besondere Gefahren durch Objekte, die nicht dem betrachteten Informationsverbund zuzurechnen sind? Solche externen Objekte können beispielsweise fremde Anwendungen, IT-Systeme oder bauliche Gegebenheiten sein. Die Definition des betrachteten Informationsverbunds dient dazu, den Untersuchungsgegenstand für die Sicherheitskonzeption festzulegen. Dies darf jedoch nicht dazu führen, dass Gefahren, die von außerhalb des betrachteten Informationsverbunds ausgehen, bei der Risikoanalyse vernachlässigt werden. Quellen für diese speziellen Gefährdungen sind beispielsweise
    • die Dokumentation des Herstellers,
    • Warn-und Informationsdienste von Computer Emergency ResponseTeams (CERTs), wie dem des BSI unter https://www.cert-bund.de,
    • Publikationen über Schwachstellen im Internet (z. B. Threat Intelligence Feeds) und eigene Bedrohungsanalysen.
       

ISO27001. Behandlungsoptionen (Aufzählungsreihenfolge nach BSI.   Reihenfolge in opus i nach ISO 27001.)

A: Risikovermeidung / Risikoumgehung / Risk Avoidance:
Ist es sinnvoll, das Risiko durch eine Umstrukturierung des Geschäftsprozesses oder des Informationsverbunds zu vermeiden? Gründe für diesen Ansatz können beispielsweise sein:

  • Alle wirksamen Gegenmaßnahmen sind mit hohem Aufwand verbunden und damit sehr teuer, die verbleibende Gefährdung kann aber trotzdem nicht hingenommen werden
  • Die Umstrukturierung bietet sich ohnehin aus anderen Gründen an, z. B. zur Kostensenkung
  • Es kann einfacher und eleganter sein, die vorhandenen Abläufe zu ändern, als sie durch Hinzufügen von Sicherheitsmaßnahmen komplexer zu machen
  • Alle wirksamen Gegenmaßnahmen würden erhebliche Einschränkungen für die Funktion oder den Komfort des Systems mit sich bringen.

 

B: Risikoreduktion / Risikomodifikation / Risikobehandlung / Risk Modification):
Ist es sinnvoll und möglich, das Risiko durch weitere Sicherheitsmaßnahmen zu reduzieren?
Das Risiko durch die verbleibende Gefährdung kann möglicherweise gesenkt werden, indem eine oder mehrere ergänzende Sicherheitsmaßnahmen erarbeitet und umgesetzt werden, die der Gefährdung entgegenwirken. Als Informationsquellen über ergänzende Sicherheitsmaßnahmen kommen beispielsweise folgende infrage:

  • die Dokumentation und der Service des Herstellers, wenn es sich bei dem betroffenen Zielobjekt um ein Produkt handelt
  • Standards und Best Practices, wie sie beispielsweise von Gremien im Bereich der Informationssicherheit erarbeitet werden
  • andere Veröffentlichungen und Dienstleistungen, die beispielsweise im Internet oder von spezialisierten Unternehmen angeboten werden
  • Erfahrungen, die innerhalb der eigenen Institution oder bei Kooperationspartnern gewonnen wurden.
    Der hypothetische Aufwand und mögliche Kosten für gegebenenfalls erforderliche Sicherheitsmaßnahmen und Informationen über bereits vorhandene Sicherheitsmechanismen sind wichtige Entscheidungshilfen.

 

C: Risikotransfer / Risikoteilung / Risk Sharing:
Ist es sinnvoll, das Risiko an eine andere Institution zu übertragen, beispielsweise durch den Abschluss eines Versicherungsvertrags oder durch Outsourcing? Gründe für diesen Ansatz können beispielsweise sein:

  • Die möglichen Schäden sind rein finanzieller Art
  • Es ist ohnehin aus anderen Gründen geplant Teile der Geschäftsprozesse auszulagern
  • Der Vertragspartner ist aus wirtschaftlichen oder technischen Gründen besser in der Lage, mit dem Risiko umzugehen.

Wenn im Rahmen der Risikobehandlung zusätzliche Sicherheitsanforderungen identifiziert werden, muss die Risikoeinstufung (siehe nachfolgende Beispiele) für die betroffenen Zielobjekte entsprechend angepasst werden. Zu beachten ist dabei, dass neue Anforderungen unter Umständen nicht nur Auswirkungen auf das jeweils analysierte Zielobjekt haben, sondern auch auf andere Zielobjekte. Die zusätzlichen Anforderungen und die daraus resultierenden Sicherheitsmaßnahmen werden im Sicherheitskonzept dokumentiert.

Wenn im Rahmen der Risikobehandlung Änderungen an den Geschäftsprozessen oder am Informationsverbund vorgenommen wurden, etwa durch Risikovermeidung oder Risikotransfer, müssen diese insgesamt im Sicherheitskonzept berücksichtigt werden. Dies betrifft im Allgemeinen auch Arbeitsschritte, die in der IT-Grundschutz-Vorgehensweise gemäß BSI-Standard200-2 dargestellt sind, beginnend bei der Strukturanalyse. Selbstverständlich kann dabei aber auf die bisher erarbeiteten Informationen und Dokumente zurückgegriffen werden.

Beim Risikotransfer ist die sachgerechte Vertragsgestaltung einer der wichtigsten Aspekte. Besonders bei Outsourcing- Vorhaben sollte hierzu auf juristischen Sachverstand zurückgegriffen werden. Die Entscheidung wird von der Leitungsebene getroffen und nachvollziehbar dokumentiert.

 

D:Risikoakzeptanz / Risikobeibehaltung / Risk Retention:
Können die Risiken auf Basis einer nachvollziehbaren Faktenlage akzeptiert werden?
Die Schritte der Risikoeinstufung und Risikobehandlung werden so lange durchlaufen, bis die Risikoakzeptanzkriterien der Institution erreicht sind und das verbleibende Risiko („Restrisiko“) somit im Einklang mit den Zielen und Vorgaben der Institution steht.

Das Restrisiko muss anschließend der Leitungsebene zur Zustimmung vorgelegt werden (Risikoakzeptanz). Damit wird nachvollziehbar dokumentiert, dass die Institution sich des Restrisikos bewusst ist. Idealerweise akzeptiert eine Institution nur Risiken der Stufe „gering“. In der Praxis ist dies aber nicht immer zweckmäßig. Gründe, auch höhere Risiken zu akzeptieren, können beispielsweise sein:

  • Die entsprechende Gefährdung führt nur unter ganz speziellen Voraussetzungen zu einem Schaden
  • Gegen die entsprechende Gefährdung sind derzeit keine wirksamen Gegenmaßnahmen bekannt und sie lässt sich in der Praxis auch kaum vermeiden
  • Aufwand und Kosten für wirksame Gegenmaßnahmen überschreiten den zu schützenden Wert.

 

 

Hinweis:
Auch diejenigen IT-Grundschutz-Anforderungen, die im IT-Grundschutz-Kompendium als Anforderungen bei erhöhtem Schutzbedarf aufgeführt sind sowie die zugehörigen Maßnahmen, können als Anhaltspunkte für weiterführende Sicherheitsmaßnahmen im Rahmen einer Risikoanalyse herangezogen werden. Dabei handelt es sich um Beispiele, die über das dem Stand derTechnik entsprechende Schutzniveau hinausgehen und in der Praxis häufig angewandt werden. Zu beachten ist jedoch, dass Anforderungen bei erhöhtem Schutzbedarf grundsätzlich empfehlenswert sind, aber auch bei hohen Sicherheitsanforderungen nicht automatisch verbindlich werden. Somit müssen sie auch nicht zwingend in eine Risikoanalyse einbezogen werden.

Zusätzliche Risiken (Gefährdungen) KÖNNEN bei der geltenden Risikomatrix, also der Bezugs-Risikomatrix, angelegt werden. Für den Fall, dass diese Risiken (Gefährdungen) in weiteren ISO-Prozessen gebraucht werden, KÖNNEN diese auch in anderen Ordnern (aber innerhalb des Mandanten) erfasst und abgelegt werden.

Wir empfehlen diese Risiken (Gefährdungen) in einen Container zu legen.

Diese Risiken (Gefährdungen) werden über das Popup-Menü angelegt:

Zusaetzliches Risiko erfassen

ISO27001. Erfassung zusätzlicher Risiken (Gefährdungen)

Zusätzliche Risiken (Gefährdungen) werden automatisch in die Gefahrenübersicht ZUSÄTZLICHE GEFAHREN (SOLL, Schritt2, Tabelle unten) eingebunden.

opus i bindet ALLE im Mandanten verfügbare Risiken selbsttätig in die untere Tabelle (SOLL, Schritt 2) ein.
Zusaetzliche Risiken werden automatisch eingebunden


Dieses gilt auch für die ZU BEOBACHTENDE RISIKEN auf der Registerkarte RISIKEN UNTER BEOBACHTUNG
Zusätzliche Risiken werden auch in die Tabelle der zu beobachtenden Risiken eingebunden




Risiken können aber auch direkt vom Anwender selbst hinzugefügt werden.

              

ISO27001. Einbindung zusätzlicher Risiken (Gefährdungen)

Klicken für "home"
kronsoft3-mit-WZ

Bitte richten Sie Ihre Supportanfrage online an uns oder direkt aus opus i heraus über die implementierte Support-Mail-Funktion.
Sie erreichen uns zu normalen Bürozeiten unter der Telefonnummer +49  6858  6370
                                    
     kronsoft e.K.    Schillerstraße 10     66564 Ottweiler     Deutschland
                                                                    Datenschutzerklärung

ISO 27001 Control
ISO 27001 Eigene Control
ISO 27001 Eigene Control
Risikomatrix
Risikobewertung
Hilfe
Benutzer Ordner
Allgemeiner Ordner
ISO 27001 Ordner
ISO 14001 Ordner
ISO 9001 Ordner
Container
ISO 27001 Control
ISO 27001 Eigene Control
Verarbeitung des Verantwortlichen
Software
implementiert
teilweise implementiert
nicht implementiert
Prozessstruktur Startelement
Kernprozess
Managementprozess
Unterstuetzungsprozess
Verarbeitung des Dienstleisters
Organisationseinheit
IT-Verbund
Prozess
Fachaufgabe
Warnung
wichtiger Hinweis
ISO 27001 Ordner
ISO 27001 Control
ISO 27001 Eigene Control
ISO 27001 Eigene Control
Eigenschaft
rBenutzer
rMitarbeiter
rPerson
rMandant
rLKWZwei1616
rPKWZwei1616

Neu
20210506

VDA-ISA (TISAX) Ordner
VDA-ISA (TISAX) Control
VDA-ISA (TISAX) Eigene Control
BCM-Ordner
ICS-Startelement
Turtle-Objekt

www.kronsoft.de     Impressum     Datenschutzerklärung
Die Version der WEB-Seite ist  63   (2023-06-27)