Notfallpatchmanagement

Windows-Systeme

NICE CXone muss so bald wie möglich Patches auf die betroffenen CXone-Systeme anwenden, wenn:

  • Proof-of-Concept-Code bezüglich eines möglichen Exploit öffentlich verfügbar ist.

  • Ein neues kritische Sicherheitspatch veröffentlicht wird.

Zweck dieser Patches ist, Schwachstellen in der Cloud-Umgebung der Organisation umgehend zu entfernen. Kritische Microsoft-Updates und andere Patches durchlaufen einen Testzyklus und werden regelmäßig angewendet. Der Zeitplan ist üblicherweise ein 30-tägiger Patchzyklus, beginnend mit dem Microsoft Patch-Dienstag. NICE CXone pflegt außerdem einen Linux Patching-Zeitplan mit einer ähnlichen Prioritätseinstufung. Bei kritischen Patches sollte nicht auf das Patching des nächsten Monats gewartet werden.

Patches und Upgrades werden in einem Change Control Record (CCR) dokumentiert. Sie sollten vom NICE CXone Change Management Board auf Folgendes geprüft werden:

  • Auswirkung.

  • Risikoanalyse.

  • Vor der Genehmigung zu ergreifende nötige Aktionen.

Patches und Upgrades sollten außerdem Peer-Reviews und technischen Überprüfung durchlaufen.

Patches und Upgrades werden zuerst im NICE CXone Lab, dann in Alpha- und Beta-Clustern und anschließend in der Produktion getestet. NICE CXone pflegt einen Notfall-Changemanagementprozess für unerwartete kritische Probleme.

Die Tests werden durch eine dedizierte Qualitätssicherungsabteilung an Updates durchgeführt. Diese Abteilung nutzt die Vorgehensweisen der NICE CXone-Richtlinien. Diese Richtlinien sind zu finden in:

  • Security Development Life Cycle (SDLC).

  • Dokumenten zu Richtlinien und Vorgehensweisen.

Die NICE CXone Operations-Teams führen Updates und Patches auf allen zutreffenden CXone-Geräten durch. Das Patching findet während eines festgelegten Wartungsfensters statt, das normalerweise drei Stunden außerhalb der Geschäftszeiten nachts abdeckt. Das Wartungsfenster wird als Teil des Kundenvertrags mitgeteilt. Wartung kann zu einer kurzen Unterbrechung während des Neustarts der Server oder eines Failovers der Cluster führen.

Nicht-Windows-Systeme und -Software

Das Patching für Linux und andere Nicht-Windows-Betriebssysteme und -Geräte wird nach Kalender und auf Ad-hoc-Basis durchgeführt. Dabei wird derselbe Change Control Board (CCB)-Prozess und Zyklus wie oben befolgt. Aktuelle Versionen sind bekannt und werden mit relevanten häufigen Schwachstellen und Risiken (CVEs) verglichen und anschließend behoben.

Information Security bewertet Fremdanbieter- und Nicht-Windows-Software. Dabei wird Folgendes genutzt:

  • QA-gesteuertes Scannen.

  • Das Security Center.

  • Andere detektive Kontrollen und Berichte.

Information Security teilt diese Schwachstellen den jeweiligen Besitzern und Gruppen mit, z. B. SysOps oder F&E. Das Patching von als "Kritisch" oder "Hoch" eingestuften Schwachstellen sollte innerhalb von 30 bis 90 Tagen erfolgen. Bestimmte Bedrohungen innerhalb solcher Schwachstellen sollten innerhalb des 30-tägigen Mandats verwaltet werden.

Extras

Infra-Tools ist ein internes Tool in Windows. Es führt eine automatische Erkennung des Software- und Hardwarestatus durch. Das Tool wird von der System Operations-Gruppe ausgeführt. Es stellt sicher, dass nicht gepatchte Maschinen und Software gekennzeichnet und gepatcht werden.

Firewalls führen Deep Packet Inspection während IDS/IPS mit aktiviertem Bedrohungsschutz aus.

NICE CXone nutzt intern weitere administrative Tools zur Untersuchung der Bedrohungslandschaft. Protokollierung-SIEMs prüfen Protokolle von entsprechenden Servern auf Anomalien.

Servicelevel-Ziele

NICE CXone verwendet bei der Anwendung von Patches Servicelevel-Ziele. Diese Ziele stellen sicher, dass:

  • Bekannte Schwachstellen rechtzeitig gepatcht werden.

  • Patches kompatibel sind mit:

    • PCI-DSS

    • Weitere Sicherheitsinfrastrukturanforderungen im Umfang.

Zum Beschreiben des Patch- und Ereignisrisikos wird eine Skala verwendet. Die interne Gerätebesitzergruppe stuft die Schwachstelle als "Kritisch", "Hoch", "Mittel" oder "Niedrig" ein.

  • Kritische Schwachstellen müssen innerhalb von 30 Tagen gepatcht werden.

  • Hohe Schwachstellen müssen innerhalb von 60 Tagen gepatcht werden.

  • Mittlere Schwachstellen müssen innerhalb von 90 Tagen gepatcht werden.

  • Niedrige Schwachstellen müssen innerhalb einer Zeit gepatcht werden, die von der internen Gerätebesitzergruppe festgelegt wird.

Information Security gibt die Informationen über die Schwächen an das Security Center weiter. Dies erfolgt durch Schwachstelleninspektionsberichte.

Behebungszyklus

Die Analyse kritischer Bedrohungen beginnt sofort nach Entdeckung. Die Bedrohungsdefinition und der Aktionsplan werden innerhalb von 72 Stunden bestimmt. Anschließend geht der Plan in den Behebungszyklus. Der Behebungszyklus besteht aus Folgendem:

  1. Entwurf einer Lösung.

  2. Ausführung der Lösung.

  3. Implementierung im Lab für das Testen.

  4. Weitergabe der Lösung an QA.

  5. Freigabeplanung.

  6. Change Board Peer-Review- und Genehmigungsprozess.

  7. Bereitstellung.

Analyse, Definition, Aktionsplan und Behebungszyklus müssen innerhalb von 30 Tagen nach Entdeckung erfolgen. Wenn ein Mandant-Service betroffen ist, wird der Mandant über die neuesten Fortschritte informiert. Aktuelle Informationen werden bei Implementierung jedes Schritts des Behebungszyklus geliefert. Nach erfolgreicher Behebung wird, je nach Vorfall, ein RCA an die betroffenen Mandanten geliefert.

Ausnahmen

Manuelle Behebung und Katalogisierung werden für Server und Geräte durchgeführt, die nicht:

  • Mit WSUS-Servern kommunizieren.

  • Aktualisierungen abrufen können.

Berichte ungepatchter Server werden Information Security zum Zweck der Sichtbarkeit, Verfolgung und Behebungsaktionen geliefert.