Statussynchronisierung zwischen Change-Anforderungen und Korrekturaufgaben
Es gibt eine synchronisierte Beziehung zwischen den Statusfeldern von Korrekturaufgaben (VULs) und den Statusfeldern von Change-Anforderungen (CHG) in Vulnerability ResponseProdukt. Während eine Change-Anforderung ihren Lebenszyklus durchläuft, verschiebt sie auch den Status aller zugehörigen Korrekturaufgaben automatisch.
Statussynchronisierung
Der Korrekturaufgabendatensatz wird in den folgenden Abschnitten als UNGÜLTIG bezeichnet. In vorherigen Versionen von Vulnerability Response, Korrekturaufgaben wurden aufgerufen, Schwachstellen-Gruppen (VG). In den folgenden Bildern VG= Korrekturaufgabe oder ein ANGREIFBARER Datensatz.
Die Statussynchronisierung wird standardmäßig durch eine Systemeigenschaft (sn_vul.cr_state_synch) in Ihrer Instanz aktiviert, wenn Sie herunterladen Vulnerability ResponseAnwendung.
Wenn die Statussynchronisierung aktiviert ist, ändert das Feld „CHG-Status“ das Feld „Status der Korrekturaufgabe“ in den folgenden Fällen automatisch:
- Wenn eine neue CHG für eine Korrekturaufgabe (VUL) erstellt wird, wenn sie sich nicht in befindet Warten Auf Implementierung , Der Status „UNGÜLTIG“ wird weiter zu verschoben Warten Auf Implementierung .
- Wenn ein vorhandenes CHG einem VUL zugeordnet ist, wenn es sich nicht in befindet Warten Auf Implementierung , Der Status „UNGÜLTIG“ wird weiter zu verschoben Warten Auf Implementierung .
- Nachdem die Aufgaben für ein CHG abgeschlossen sind ( Implementiert ), und das CHG wird in verschoben Überprüfen status, in den die ABLEHNUNG verschoben wird Gelöst .
Weitere Informationen und Beispiele für die Statussynchronisierung finden Sie in den folgenden Abschnitten.
Statussynchronisierung weiterleiten
Das folgende Bild veranschaulicht, wie CHG-status „ANGREIFBARE status“ automatisch in einem Vorwärtslebenszyklus verschieben, d. h. von „aus“ Offen Bis Gelöst .
Sie können neue Change-Anforderungen für jede Korrekturaufgabe in einem anderen Status als erstellen Geschlossen . Die Statussynchronisierung verschiebt die ANGREIFBAREN Elemente automatisch bidirektional durch Offen , Wird Untersucht , Warten Auf Implementierung , Und Gelöst status. Diese Bewegung basiert auf bestimmten Werten des Statusfelds in der Change-Anforderung. Die Statussynchronisierung zwischen der Change-Anforderung und der Korrekturaufgabe wird automatisch aufgerufen, es sei denn, das Kontrollkästchen ( Fügen Sie der CR CIs hinzu ) Wird in einem Formular angezeigt, und Sie deaktivieren das Kontrollkästchen.
Der FEHLER wird nicht zu verschoben Gelöst Wenn sich ein CHG im status „Offen“ befindet. Beliebige CHG in status vor Überprüfen In seinem Lebenszyklus, z. B. Neu , Bewerten , Autorisieren , Geplant Oder Implementieren Wie in der vorangehenden Abbildung gezeigt, werden als offene status für das CHG betrachtet. Offene status verschieben das Statusfeld auf der VUL nicht, da Untersuchungen oder Aufgaben im CHG nicht abgeschlossen sind. Die Statussynchronisierung wird aufgerufen, wenn eine CHG für die ANGREIFBARE Beziehung erstellt oder ihr zugeordnet wird oder sich der Status einer vorhandenen Beziehung auf der CHG ändert. Die status der abgeschlossenen CHG sind Überprüfen Und erfolgreich Geschlossen . Wenn ein CHG erfolgreich geschlossen wird, lauten seine geschlossenen Codes: Erfolgreich , Oder Erfolgreich mit Problemen , In diesem Fall wird die ABLEHNUNG zu verschoben Gelöst .
Statussynchronisierung rückwärts
Da ein CHG während seines Lebenszyklus verarbeitet wird, kann es irgendwann abgebrochen werden. In diesem Fall, wenn die CHG lautet Abgebrochen , Oder Geschlossen (Mit einem Abschlusscode von Nicht Erfolgreich ), wird die ANNULLIERUNG automatisch zurück zu verschoben Wird Untersucht . Die ANNULLIERUNG wird zurück zu verschoben Wird Untersucht , Da kein aktiver Plan zur Behebung der Schwachstelle vorhanden ist.
Wenn sich eine ABLEHNUNG in einem befindet Gelöst status, und Sie erstellen eine neue CHG oder ordnen sie einer vorhandenen CHG in einem der anfänglichen offenen statuszu , wird die ÄNDERUNG automatisch zurück zu Warten Auf Implementierung . Die ABLEHNUNG wird in diesen Status zurückversetzt, da jetzt dem CHG mehr Arbeit zugewiesen ist.
VULs mit mehr als einem CHG
| CHG-Nummer | CHG-Status |
|---|---|
| 1 | Implementieren |
| 2 | Abgebrochen |
| 3 | Geschlossen (Abschlusscode von Nicht Erfolgreich ) |
| 4 | Geschlossen (Abschlusscode Erfolgreich ) |
Die Statussynchronisierung zwischen CHG und VUL in diesem Fall basiert auf CHG1, das sich im frühesten Status der vier CHG befindet, ( Implementieren ). In diesem Fall verbleibt die ABLEHNUNG in Warten Auf Implementierung .
In einem anderen Beispiel, wenn sich ein FEHLER in befindet Gelöst status und hat eine vorhandene CHG, die implementiert wurde und sich in befindet Überprüfen status und ein neues CHG wird erstellt, aus dem der WIDERRUF zurückverschoben wird Gelöst Bis Warten Auf Implementierung . Die Statussynchronisierung basiert auf dem CHG in Neu status: Das CHG im frühesten Status.
| CHG-Nummer | CHG-Status |
|---|---|
| 1 | Prüfung |
| 2 | Neu |
Wenn VULs mehr als ein CHG haben, wechselt der Status der ANFECHTUNG in den folgenden Fällen automatisch:
- Wenn ein CHG zu weitergeht Überprüfen , Wenn sich alle anderen CHGs, die dem VUL zugeordnet sind, in befinden Überprüfen Oder Geschlossen status (mit erfolgreichem Abschlusscode),in den die ANFECHTUNG automatisch übergeht Gelöst . Alle anderen zugehörigen CHGs, die abgebrochen oder nicht erfolgreich geschlossen wurden, werden ignoriert.
- Wenn ein CHG zu verschoben wird Abgebrochen Oder Geschlossen (Abschlusscode von Nicht Erfolgreich ), wenn sich alle anderen dem VULL zugeordneten CHGs im gleichen Status befinden, wird der VULL automatisch zurück zu verschoben Wird Untersucht .
Weitere Informationen zu den status der Korrekturaufgabe und zu den Aktionen in den einzelnen Status finden Sie unter Vulnerability Response status der Korrekturaufgabe und angreifbarer Elemente.