Gestion des correctifs d’urgence

Systèmes Windows

NICE CXone doit appliquer des correctifs aux systèmes CXone affectés dès que possible dans les situations suivantes :

  • Un code de preuve de concept est disponible au grand public concernant un exploit potentiel

  • Un nouveau correctif de sécurité critique est disponible

Ces correctifs ont pour finalité de supprimer immédiatement les vulnérabilités présentes dans l’environnement cloud de l’organisation. Les mises à jour critiques Microsoft et autres correctifs sont soumis à un cycle de test et appliqués suivant un calendrier régulier. Ce calendrier prévoit généralement un cycle de correctif de 30 jours à partir du Patch Tuesday de Microsoft. NICE CXone observe également un calendrier de correctifs Linux avec un niveau de priorité semblable. Les correctifs critiques ne doivent pas être reportés au cycle du mois suivant.

Les correctifs et mises à niveau sont documentés dans un enregistrement de contrôle du changement. Ils doivent être examinés par le Comité de gestion du changement NICE CXone sur les aspects suivants :

  • Impact

  • Analyse du risque

  • Mesures indispensables prises avant approbation

Les correctifs et mises à niveau doivent également être soumis à des validations techniques et des évaluations par les pairs.

Les correctifs et mises à niveau sont d’abord testés dans le laboratoire NICE CXone, puis dans des clusters alpha et bêta, et enfin en production. NICE CXone suit un processus de gestion du changement d’urgence en cas de problèmes critiques inattendus.

Les tests s’effectuent sur les mises à jour par un service d’assurance qualité dédié. Ce service suit des pratiques entrant dans les directives NICE CXone. Ces directives se trouvent dans les éléments suivants :

  • Cycle de vie du développement de sécurité (SDLC)

  • Documents de politiques et procédures

Les équipes opérationnelles NICE CXone mettent à jour ou corrigent tous les périphériques CXone concernés. L’opération s’effectue sur une fenêtre de maintenance définie, qui correspond normalement à un créneau de trois heures creuses de nuit, selon la situation géographique. La fenêtre de maintenance est énoncée dans le contrat du client. La maintenance peut entraîner une brève interruption pendant le redémarrage des serveurs ou le basculement des clusters.

Systèmes et logiciels autres que Windows

Les périphériques et systèmes d’exploitation autres que Windows, notamment Linux, sont corrigés suivant un calendrier défini et au cas par cas. Ils suivent les processus et cycle du Comité de contrôle du changement indiqués ci-dessus. Les versions actives sont connues et comparées aux vulnérabilités et expositions courantes (CVE), puis la remédiation est engagée.

L’équipe Sécurité des informations évalue les logiciels tiers ou autres que Windows. Pour ce faire, elle utilise :

  • L’analyse axée sur l’assurance qualité

  • Le Centre de sécurité

  • D’autres contrôles et rapports de détection

L’équipe Sécurité des informations communique ces vulnérabilités aux responsables et groupes concernés, tels que le SysOps ou la R&D. Les vulnérabilités classées Critique ou Élevée doivent être corrigées dans un délai de 30 à 90 jours. Certaines menaces parmi ces vulnérabilités doivent être gérées dans un délai impératif de 30 jours.

Outils

Infra-Tools est un outil interne utilisé sous Windows. Il se charge de la découverte automatisée des statuts logiciels et matériels. Cet outil est exécuté par les groupes Opérations système. Il s’assure que les ordinateurs et logiciels non corrigés soient repérés et corrigés.

Les pare-feu effectuent une inspection approfondie des paquets pendant l’IDS/IPS avec protection contre les menaces.

NICE CXone utilise en interne d’autres outils administratifs de sondage des menaces. Les systèmes SIEM de journalisation inspectent les journaux des serveurs appropriés afin de détecter des anomalies.

Objectifs de niveaux de service

NICE CXone utilise des objectifs de niveaux de service lors de l’application des correctifs. Ces objectifs veillent à ce que :

  • les vulnérabilités connues soient corrigées à temps ;

  • les correctifs soient en conformité avec :

    • PCI DSS ;

    • d’autres exigences d’infrastructure de sécurité visées.

Une échelle est utilisée pour décrire le risque des événements et correctifs. En interne, le groupe responsable des périphériques qualifie la vulnérabilité de « Critique », « Élevée », « Moyenne » ou « Faible ».

  • Les vulnérabilités critiques doivent être corrigées dans un délai de 30 jours.

  • Les vulnérabilités élevées doivent être corrigées dans un délai de 60 jours.

  • Les vulnérabilités moyennes doivent être corrigées dans un délai de 90 jours.

  • Les vulnérabilités faibles doivent être corrigées dans un délai fixé par le groupe responsable des périphériques en interne.

L’équipe Sécurité des informations transmet au Centre de sécurité les informations relatives aux points faibles. Elle le fait au moyen de rapports d’inspection des vulnérabilités.

Cycle de remédiation

L’analyse des menaces critiques commence immédiatement au moment de la découverte. La définition des menaces et le plan d’action sont déterminés dans un délai de 72 heures. Ensuite, le plan entre dans le cycle de remédiation. Le cycle de remédiation comprend les étapes suivantes :

  1. Architecture d’une solution

  2. Conception technique de la solution

  3. Mise en œuvre en laboratoire pour les tests

  4. Transmission de la solution à l’assurance qualité

  5. Planification de la mise à disposition

  6. Évaluation par les pairs et approbation par le Comité de contrôle du changement

  7. Déploiement

L’analyse, la définition, le plan d’action et le cycle de remédiation doivent se dérouler dans les 30 jours suivant la détection. Si un service unité d’exploitation est concerné, la/le unité d’exploitation reçoit des mises à jour sur l’avancement du processus. Ces mises à jour sont livrées lorsque chaque étape du cycle de remédiation est mise en œuvre. Lorsque la remédiation aboutit, selon la nature de l’incident, une analyse des causes premières est remise aux unité d’exploitations concerné(e)s.

Exceptions

Une remédiation et un catalogage manuels sont effectués pour les serveurs et périphériques qui :

  • ne communiquent pas avec les serveurs WSUS ;

  • ne sont pas en mesure de récupérer les mises à jour.

Des rapports sur les serveurs non corrigés sont fournis à l’équipe Sécurité des informations à des fins de visibilité, de suivi et de remédiation.