Verwendung von ISO Controls

Hallo zusammen,

wir sind noch relativ am Anfang der Umsetzung von verinice.Pro, um uns auf die ISO27k vorzubereiten.
Daher ist meine Frage noch eher zum Grundlegenden Umgang mit den ISO Controls. Leider hatte ich nichts passendes gefunden.

Im Webinar wurde uns gezeigt, dass man am Besten den Risiko-Katalog importiert und entsprechend die Assets mit den Szenarien und Controls verlinkt. Das funktioniert auch alles und erscheint mir Logisch.
Wenn ich nun jedoch eine vielzahl verschiedener Assets habe, die alle vom selben Szenario/ der selben Control betroffen sind, dann m├╝sste ich doch das entsprechende Control f├╝r jedes dieser Assets neu importieren und zuweisen?

Als Beispiel habe ich Asset A, welches Benutzer A als Eigent├╝mer hat (der sich dann auch um die Umsetzung der Controls k├╝mmern muss) und Asset B mit Benutzer B.
Jetzt sind beide Assets von Control X betroffen. Somit br├Ąuchte ich zum Erstellen von Tasks und zum Tracken der Umsetzung hier zwei mal das Control X oder ├╝bersehe ich hier etwas ganz Grundlegendes?

Ich hoffe auf Ihre Hilfe.
Beste Gr├╝├če,
Steffen

Hallo SteffenS,

eine kleine Richtigstellung vorab, damit ich hoffentlich etwas weiterhelfen kannÔÇŽ

Man verkn├╝pft (in verinice) relevante Assets mit relevanten Szenarien.
Erst im zweiten Schritt werden die Controls wahlweise:

  • mit dem Szenario verkn├╝pft, wenn sie die Eintrittswahrscheinlichkeit reduzieren. Dies ist ├╝brigens bei ca. 80% der Controls der Fall.
  • mit dem Asset verkn├╝pft, wenn sie die m├Âgliche Auswirkung (Business Impact) hinsichtlich Vertraulichkeit, Integrit├Ąt und/oder Verf├╝gbarkeit reduzieren.

Das bedeutet auch, jedes Szenario liegt nur einmal vor und ist meistens mit mehreren Assets verkn├╝pft. Ein Szenario dupplizieren w├╝rde man nur dann, wenn es mit unterschiedlicher Eintrittswahrscheinlichkeit auf unterschiedliche Assets anzuwenden ist. Ein anschauliches Beispiel w├Ąre hier das Szenario Hochwasser, einmal niedrig f├╝r den Standort auf der Zugspitze und einmal hoch f├╝r den Standort im Hamburger Hafen.

Es empfiehlt sich, auch um den Aufwand insgesamt gering zu halten, (Umsetzungs-)Verantwortliche je Control zu verkn├╝pfen, die dann wie oben beschrieben:

  • die ├╝berwiegende Anzahl der Controls umsetzen, welche die Eintrittswahrscheinlichkeit der Szenarien reduzieren.
  • die kleiner Anzahl an Controls umsetzen, die die Auswirkung an den Assets reduzieren.

Letztlich wird man aber immer wieder mehrere Verantwortliche haben k├Ânnen, die ein Control an unterschiedlichen Stellen umzusetzen haben. Um den Aufwand im Rahmen zu halten empfiehlt es sich hier aber nicht das Control f├╝r jede einzelne Umsetzungsinstanz zu kopieren sondern die Bearbeitung zusammenzufassen.

Beides k├Ânnte letztlich in verinice abgebildet werden, unsere Best Practice Empfehlung ist ganz klar die Abstraktion und nicht die detailgetreue Abbildung der Realit├Ąt.

Ich hoffe das hilft Ihnen bei Ihren n├Ąchsten Schritten!

MfG mflue

1 Like

Hallo mflue

und vielen Dank f├╝r die schnelle und ausf├╝hrliche Antwort.

Wenn ich die beschriebene Herangehenswei├če richtig verstehe, sind wir wohl von Grund auf etwas zu detailreich / umst├Ąndlich an die Sache herangegangen.

Unser Ziel ist eine erste Zertifizierung von Systemen (eher veschiedenen Anwendungen), die bestimmte Kriterien erf├╝llen (bei weitem nicht alle vorhandenen Systeme).
Aktuell h├Ątten wir f├╝r jede Anwendung die im ersten durchlauf zertifiziert werden sollen (ca. 250 Stk.) ein eigenes Asset angelegt. Hintergrund war die Annahme, dass jede Anwendung einen anderen Eigent├╝mer und einen anderen Implementierungsstatus hat und somit nicht zusammengefasst werden kann.

Im Endeffekt sollten diese Anwenundungen so gut es geht zusammengefasst werden, wenn ich Sie richtig verstanden habe. Des weiteren sollten dann die Controls einen oder mehrere ÔÇ×eigene VerantwortlicheÔÇť bekommen und nicht jede Control vom Anwendungs-Eigent├╝mer separat gepflegt werden?

Vielen Dank nochmals.
MfG SteffenS

Hallo SteffenS,

ich antworte Ihnen hier gerne, weill es sicher auch viele andere Anwender interessiert.

Beim Aufabu eines ISMS gilt es immer ein Model der Realit├Ąt abzubilden, wobei zwei konkurrierende Anforderungen zu erf├╝llen sind:
Zum einen m├Âchte man m├Âglichst detailiert sein, um ein Maximum an Informationssicherheit zu erzielen, zum andern m├Âchte man abstrahieren, um den Aufwand im ISMS(-Tool) selbst m├Âglichst gering zu halten.

Es gibt folglich nicht die eine Vorgehensweise, jede Organisation hat einen gewissen Spielraum.

Eine sinnvolle Empfehlung findet sich im Hinblick auf die Strukturanalyse beim BSI, ich zitiere aus dem Kapitel 8.1.1 Komplexita╠łtsreduktion durch Gruppenbildung des BSI-Standard 200-2 IT-Grundschutz-Methodik:

Objekte ko╠łnnen dann ein und derselben Gruppe zugeordnet werden, wenn die Objekte alle

  • vom gleichen Typ sind,
  • a╠łhnliche Aufgaben haben,
  • a╠łhnlichen Rahmenbedingungen unterliegen und
  • den gleichen Schutzbedarf aufweisen.

Bei technischen Objekten bietet sich eine Gruppenbildung au├čerdem immer dann an, wenn sie

  • a╠łhnlich konfiguriert sind,
  • a╠łhnlich in das Netz eingebunden sind (z. B. im gleichen Netzsegment) und
  • a╠łhnlichen administrativen und infrastrukturellen Rahmenbedingungen unterliegen,
  • a╠łhnliche Anwendungen bedienen und
  • den gleichen Schutzbedarf aufweisen.

Diese Vorgehensweise ist prinzipiell auch f├╝r die ISO-Welt anwendbar.

MfG mflue

1 Like