Risikorestwert von Prozess bei Report für Risikobehandlung nicht nachvollziehbar

PMJarosch · 13. März 2019 um 13:16

Moin,

ich versuche Nachzuvollziehen, warum der Risikorestwert eines Prozesses nicht durch Maßnahmen reduziert wird.

Der Risikorestwert setzt sich immernoch aus der Bewertung des Prozesses zusammen + die Eintrittswarscheinlichkeit aus dem Szenario. Maßnahmen, welche die Reduktion des Risikorestwerts aufzeigen sollte (wie es das auch beim Asset tut) tut es aber nicht.

Meine Frage dazu ist: Soll der Restrisikowert des Prozesses gar nicht reduziert werden oder wird er es nur nicht weil ich irgend etwas nicht gemacht habe (oder liegt eventuell ein Bug in der Reporterstellung vor).

anon91942928 · 13. März 2019 um 14:27

Hallo!
Dem Anbilick nach funktioniert alles “wie es soll”. Die Rechnung ist folgendermaßen zu lesen:

Der Client geht mit einem Grundwert an Schutzbedarf (vermutlich hier Vertr.=3, Integr.=2 aber unbetrachtet, Verfüg.=4 - alles vererbt vom Prozess(?) “Erbringung der mdex …”) in die Rechnung ein (kann im Verinice bei der Verknüpfung betrachtet werden).
Auf diese Werte wird der Wert der “Wahrscheinlichkeit” (=6) des Szenarios (“Angriff auf …”) aufaddiert und es erscheinen die Rohwerte ohne jegliche Behandlung. Da diese als 9,0,10 angezeigt werden, vermute ich, dass dein Szenario die Integrität nicht betrifft - dann wird der Wert genullt.

Ein Control, das mit einem Szenario verbunden wird, geht nur mit seinem Feld “Reduktion der Eintrittswahrscheinlichkeit” (hier Wert/“Effektivität”=2) ein und es kann a) nur abgezogen werden, wenn das Control implementiert ist (ja) und b) es kann in der Summe nicht mehr abgezogen werden, als das Szenario mitbringt (weil ja nur dessen Wahrscheinlichkeit reduziert wird).
Der Finale Vektor für das Asset im Bezug auf dieses Szenario wird also berechnet (für C,I,A) durch Asset(3,0,4) + (Szen(6,6,6) - Control(2,2,2)) = “Risiko”(7,0,8).

Zur weiteren Reduktion kannst du nun a) Controls finden, die die Wahrscheinlichkeit des Szenarios beeinflussen und sie mit diesem verbinden, oder b) Controls finden, die die Schutzparameter (Vertr., Integr., Verfüg.) direkt positiv unterstützen (Verschlüsselung unterstützt ggf. die Vertraulichkeit, Hardwar-Cluster/-Spiegelungen die Verfügbarkeit) und diese Controls mit dem Asset verknüpfen.
Genereller also:
Schutzbedarfswerte + (Szenariowert - Summe(ControlsAmSzenario)) - Summe(ControlsAmAsset/Prozess) = Endrisiko.

Für weitere Ausführungen gern noch einmal nachfragen - die Rechnung ist eigentlich recht interessant!

Achtung Bug: Wenn du zyklische Abhängigkeiten/Verknüpfungen geschaffen hast (A hängt ab von B hängt ab von C hängt ab von A) dann kann die Berechnung etwas anderes ergeben als erwartet und es stehen ‘falsche’ Werte im Report. Manchmal hilft hier öfters die Risikoanalyse durchführen, noch besser den Haken zum Leeren des Caches vor Erstellung des Reportes (im Reportdialog) anwählen aber noch besser ist, Kreise zu vermeiden und sie anders zu modellieren!

// Edit: Ich kann aus dem Auszug nicht erkennen, ob das Szenario mit einem Asset oder mit dem Prozess verbunden ist. Es gilt jedoch dieselbe Rechnung (ggf. nur mit Prozess statt Asset). Zum Reduzieren der Werte am Prozess selbst, müssen Controls mit Werten für Vertr./Integr./Verfügb. mit dem Prozess verbunden werden und implementiert sein.

PMJarosch · 13. März 2019 um 15:08

Moin,

Die Einzige Verknüpfung des Prozesses ist mit dem Asset.

Weitere Reduktionen wirken sich ja aber nur auf den Wert des Assets aus und nicht auf den Wert des Restrisikos des Prozesses (7 0 8 statt 9 0 10).

Den Punkt verstehe ich nicht.

Lässt sich z.B. durch verknüpfen von Control o.ä. der Wert des Prozesses (Gesamtes Restrisiko des Prozesses) weiter vermindern? Oder wie ist das zu verstehen?

mflue · 13. März 2019 um 15:47

Hallo,

sehr schön beschrieben, ich ergänze graphisch:

Das Control reduziert also:

den Business Impact ,wenn mit dem Asset verknüpft
die Eintrittswahrscheinlichkeit wenn mit dem Szenario verknüpft

Achtung: In beiden Fällen muss der Control Level entsprechend gesetzt sein.

MfG mflue

anon91942928 · 13. März 2019 um 15:50

Ich probiere es mit grafischer Unterstützung:

Ich habe mir erlaubt, ein neues Control “ESX-Virtualisierung” hinzuzufügen, das die Verfügbarkeit um 2 modifiziert. Es ist direkt mit dem Asset verbunden und reduziert folglich das “Risiko” direkt am Asset.

Der Prozess wird weiterhin mit 3,2,4 eingehen, da an ihm kein Control (wie das eingefügte) verknüpft ist.

In dem Reporttemplate von VN werden aber die Risiken aufsummiert und an den Prozess geheftet. Hätte man das gleiche Asset mit denselben Szenarien und Controls einzweites mal mit dem Prozess verknüpft, würde als Risiko statt [7,0,8] (bzw. [7,0,6]) respektive [14,0,16] (bzw. [14,0,12]) stehen.
Das Risiko für den Prozess ist dann Summe(R2-Werte aller untergeordneten Elemente).

Folglich muss man alle Assets, die mit Szenarien verknüpft sind, entsprechend mit solchen Controls ausstatten.

// edit: danke Herr Flürenbrock

anon91942928 · 13. März 2019 um 16:06

Noch ein wichtiger Hinweis zu einem Bug im Reporttemplate: Wenn die Werte [9,0,10] direkt in der Spalte „Restrisiko mit umgesetzten Controls“ gemeint sind:

Es wird hier das unbehandelte Risiko aufsummiert, also ohne die Reduktion durch Controls (das war einer der Gründe, eigene Reports zu entwickeln)!

Im englischen Report ist es richtig formuliert (nämlich ohne „mit umgesetzten Controls“).

mflue · 15. März 2019 um 12:27

Hallo Zusammen,

vielen Dank für den Hinweis!

Die Risikoreports für die ISM-Perspektive befinden sich gerade in Überarbeitung. Primär stellen wir auf die LTR-Technik um, was nach ersten Tests wie erwartet eine erhebliche Performance-Steigerung bewirkt.

Gerne werden wir die oben genannten Fehler dabei untersuchen und ggfs. beheben.

Die neuen Reports werden voraussichtlich im Laufe der kommenden Woche hier als Beta-Versionen bereitgestellt.

MfG Michael Flürenbrock