Gruppierung von Verbünden


#1

Hallo Allerseits,

ist es vorgesehen die Verbundstruktur in verinice flexibler zu gestalten,
das heißt unter Verbünden oder einem Gesamtverbund weiter Teil-Verbünde/Strukturen anzulegen?
Und damit auch Verweise nicht nur auf Zielobjekte, sondern auch auf Verbünde zu realisieren.

Vielen Dank
Dirk


#2

Hallo,

in verinice lassen sich unterschiedliche Scopes/Verbünde abbilden und Verknüpfungen zwischen Objekten unterschiedlicher Scopes erstellen. Die Scopes sind dabei auf der selben Hierarchieebene angeordnet.

Prinzipiell kann ich so in einem Scope z.B. ein Rechenzentrum mit allen erforderlichen Strukturen abbilden und aus einem anderem Scope dann darauf verweisen, also etwa eine Anwendung in einem anderen Scope mit einem Server im RZ verknüpfen.

Die Frage ist an dieser Stelle, welche Bedeutung der “Verweis” genau haben soll und welche Funktion sich ggfs. daraus ergibt?

In meinem Beispiel ergibt sich aus der Verknüpfung Anwendung benötigt Server eben auch die Funktion vererbt Schutzbedarf bzw. Business Impact.

Um bei Ihrem Beispiel zu bleiben, in welcher Beziehung stehen der Gesamtverbund und die Teilstruktur, was genau haben die beiden miteinander zu tun?
Darauf aufbauend wäre zu bewerten was mit verinice-Bordmitteln und/oder Customizing noch nicht umgesezt werden kann und ggfs. neu zu entwickelt wäre.

Ich freue mich auf weitere Diskussion!

MfG Michael Flürenbrock


#3

Hallo Herr Flürenbrock,

für mich ist das erstmal ein Thema der Übersichtlichkeit. Wir haben sehr viele Verbünde und diese würde ich gerne in eine logischen Struktur gruppieren und nicht alles auf einer Ebene belassen.
Aber davon abgesehen, wäre es auch nett auf bspw. Frendverbünde(Outsourcing, Diensleister) nur auf den Verbund zu verweisen und nicht auf ein Zielobjekt, das ich ggf. ja so auch nicht kenne. Das wäre dann eine Art “Dummy Verbund”, welcher aber zu meinen Verbund gehört. Sie haben recht zwischen Verbünden die gemeinsame Schnittstellen haben müssen die Strukturen natürlich so erhalten bleiben (bspw. Verbund A: Anwendung XY braucht VerbundB: IT-System XY). Ich weiss auch nicht wie man sowas programmiert aber habe es schon bei anderen Tool Herstellern gesehen.

Viele Grüße
Dirk Retzlaff


#4

Hallo zusammen,
drei Punkte dazu:

  1. Sie können jederzeit in der SNCA.xml eine Relation zwischen zwei Verbünden hinzufügen. Für die ISM-Perspektive wäre das beispielsweise so zu realisieren: <huirelation to="org" id="rel_org_org_hierarchy" name="untergeordneter Verbund" reversename="uebergeordneter Verbund" tooltip="" /> (unter den Abschnitt <huientity name="Organization" id="org" >. Ungetestet. Da beide Objekte vom gleichen Typ sind, ist auf die Reihenfolge der Verknüpfung zu achten wie bei Assets).
    So kann ein Verbund/Scope mit einem anderen Verknüpft werden. Das hat aber keinerlei (erkennbare) Auswirkungen auf Berechnungen der Schutzbedarfe / Risikowerte und wird in keinem derzeitigen Report abgefragt (selbst hinzufügen)…
    Fügt man den Teil unter anderen Element-Typen ein (wie IT-GS-Elementen), können auch diese auf einem Verbund/Organisation etc. verweisen lassen.

  2. Falls die Bedenken darin liegen, dass alle Scopes auf derselben Hierarchieebene liegen, möchte ich an das Verinice-Team den Wunsch herantragen, die Scopes gruppieren zu lassen. Das Konzept dafür ist bereits (teilweise) umgesetzt, da “importierte Objekte” eine Gruppe ist. Jedenfalls wenn man einen CSV-Export auf die Scopes durchführt, sieht man Gruppen-IDs für die importierten Elemente, die evtl. auf den Knotenpunkt “importierte Objekte” verweisen.
    Eine Gruppierung kann ggf. auch für Tochterfirmen und logische Trennung nach Netzwerk/Datenschutzthemen sehr hilfreich sein!

  3. Zuletzt möchte ich eine konzeptionelle Lösung vorschlagen, die bei uns umgesetzt wird. Wir verwenden für technische Verbünde (in ISM-Perspektive, aber sollte sich auf IT-GS adaptieren lassen) Ersatzelemente. So haben wir Assets vom Typ “Service” semantisch definiert als “der gesamte Verbund darunter”.
    Haben Sie also bspw. einen Verbund für ihren FTP-Server-Bereich, so können Sie darin ein Asset definieren, das den gleichen Namen trägt. Immer wenn Sie auf den kompletten Scope verweisen möchten, verweisen Sie einfach auf dieses Asset. Hat den Vorteil, dass Sie bei der Reporterstellung nicht alle Sub-Elemente aufführen müssen, die ihren Fachbereich ggf. gar nicht interessieren. Weiterhin funktioniert die Schutzbedarfs-Vererbung und die Risikoberechnung wie zuvor.
    In dem konnkreten Fall haben wir das Attribut “Service” zweckentfremdet, um im Report auf diesen Fall zu prüfen und entsprechende Zusatzberechnungen/-markierungen durchzuführen. Welches Attribut Sie verwenden, welche besondere Relation oder welches Element (Statt Asset aus dem ISM-Bereich ggf. Server aus dem IT-GS, dort kenne ich mich aber nicht aus…) bleibt Ihnen ja offen. Es bleibt eine rein semantische Konvention.

Ich hoffe, mit diesen drei Möglichkeiten Anregungen geschaffen zu haben. Das Clustern von Verbünden interessiert mich ebenfalls und gern können wir uns darüber mehr austauschen. MfG


#5

Hallo Zusammen,

ich denke insbesondere die Lösung aus 3 wird von vielen Anwenderinnen und Anwendern gesucht, da Sie ermöglicht die Funktionalitäten (Schutzbedarfs-Vererbung und die Risikoberechnung) beizubehalten.

Vielleicht kann @Member123 mal einen Beispielverbund beisteuern?

Vielen Dank für die Anregungen!

MfG Michael Flürenbrock