Schritte zum Verhindern doppelter oder verwaister Datensätze nach dem Ausführen von Vulnerability Response CI-Suchregeln

  • Freigeben Version: Washingtondc
  • Aktualisiert 1. Februar 2024
  • 2 Minuten Lesedauer
  • Ergreifen Sie Maßnahmen, um doppelte oder verwaiste Datensätze zu verhindern, die aus dem Abgleich von (Konfigurationselementen (CIs) innerhalb von CMDBresultieren).

    Das Importieren von Schwachstellendaten kann eine Instanz belasten, und Leistungsprobleme mit Ressourcen können auftreten, wenn Regeln nicht sorgfältig erstellt werden. Die Logik, die zum Durchlaufen und Abgleichen in der CMDB verwendet wird, kann zu langen Verarbeitungszeiten führen. Gründliches Testen und Debuggen von Verarbeitungsskripts in den Regeln trägt dazu bei, das Risiko später im Prozess auftretender Probleme zu verringern.

    Doppelte oder verwaiste Datensätze werden verhindert

    • Verwenden Sie kleine Teilmengen von Daten, die für die getestete CI-Suchregel spezifisch sind.
      • Setzen Sie alle CI-Suchregeln, mit Ausnahme der getesteten, auf Inaktiv.
      • Analysieren Sie die importierten CIs, um sicherzustellen, dass Sie das erwartete Verhalten beobachten und die Übereinstimmung ordnungsgemäß erfolgt.
    • Überprüfen Sie die übereinstimmenden CIs
      • Untersuchen Sie die Anzahl der übereinstimmenden im Vergleich zu nicht übereinstimmenden CIs. Stellen Sie sicher, dass der Prozentsatz akzeptabel ist. Schauen Sie sich nicht nur die erste Seite an, das ist wahrscheinlich die erste eingefügte.
      • Suchen Sie manuell nach CIs.
      • Überprüfen Sie, ob Benennungs- oder Feldprobleme vorliegen (z. B. Suche nach einer bestimmten Domäne).

        Wenn es angemessen erscheint, fügen Sie zusätzliche Übereinstimmungsregeln hinzu.

    • Überprüfen Sie nicht abgeglichene CIs
      • Navigieren Sie zur Tabelle Nicht abgeglichene CIs.
      • Nach Klasse des Konfigurationselements gruppieren.
      • Überprüfen Sie alle Klassen, die nicht richtig aussehen (Zertifikate, Netzwerkkarten, Images).
        • Finden Sie heraus, warum sie nicht mit dem richtigen CI übereinstimmten.
        • Soll die Klasse ausgeschlossen werden?
        • Soll die Klasse auf eine zugehörige Klasse hochgestuft werden?
    • Überprüfen Sie CI-Status wie Deaktiviert.
    • Entfernen Sie die Testdaten
      • Sobald Sie das richtige oder erwartete Verhalten bei der CI-Übereinstimmung beobachten, beginnen Sie von vorne.
      • Neu beginnen durch: Löschen der zum Testen verwendeten Daten: (siehe Abschnitt „ Daten aus Tabellen löschen“)
        • Erkannte Elemente
        • Angreifbare Elemente
        • Korrekturaufgaben
      • Alle CI-Übereinstimmungsregeln werden manuell erneut ausgeführt.

    Weitere Informationen zu CI-Suchregeln und Qualysfinden Sie im Artikel KB0750656.

    Weitere Informationen zu CI-Suchregeln und Rapid7finden Sie in KB0818096.

    Daten werden aus Tabellen gelöscht

    Manchmal haben Sie Daten importiert und feststellen, dass etwas nicht stimmt. Wenn in einer Entwicklungs- oder Leistungsumgebung etwas nicht stimmt, können Sie aus einer besseren Umgebung erneut klonen, aber das ist nicht immer eine Option.
    Hinweis:
    Das Ausführen dieser Aktionen erfordert ServiceNow.
    Es gibt vier Optionen zum Löschen von Daten aus Tabellen:
    • Verwenden von „Alle Datensätze löschen“ in der Tabellenkonfiguration.
    • Konfigurieren Sie die Tabellenbereinigung, indem Sie zu Auto Flushes (sys_auto_flush.list) navigieren und einen neuen Auto-Flush- Datensatz erstellen.
    • Kürzen Sie gs.truncateTable mit einem Hintergrundskript.

      Wenn Sie truncateTable verwenden, müssen Sie das Kontrollkästchen Datensatz für Rollback in den Hintergrundskripts deaktivieren. Andernfalls wird eine Kopie der Tabelle und zugehöriger kaskadierender Tabellen erstellt, was zu lange dauert und höchstwahrscheinlich fehlschlägt.

      Hinweis:
      Verwenden Sie truncateTable niemals in einer Produktionsumgebung. Wenden Sie sich an Ihren Support-Mitarbeiter, bevor Sie große Löschungen in Produktions- oder freigegebenen Umgebungen ausführen.