Release Notes – Device Manager

Release Notes – Device Manager

Release Notes – Device Manager

Version : v.2.2.0

Release Date : 31.01.2022

Dans cette version, nous introduisons de nouvelles fonctionnalités telles que la gestion des QKViews et des data groups, ainsi que des améliorations sur les iRules. Le menu des devices a été peaufiné visuellement et nous avons amélioré les performances des menus « Local Traffic » et « Where Used ».

 

Nouvelles Fonctionnalités

QKViews

Les QKViews sont nécessaires lorsqu’il s’agit de résoudre un problème d’un device F5. C’est pourquoi, ils peuvent maintenant être facilement générés directement à partir de la vue « Devices ». Après avoir déclenché la création du qkview, il apparaîtra dans un tableau avec le statut, la taille et la date de création. Selon la taille, le processus de génération peut prendre quelques minutes. Lorsque l’état passe à « Success », il est possible de télécharger le fichier qkview.
En arrière-plan, le fichier est d’abord créé sur un device F5, puis téléchargé sur le stockage local du « Device Manager » et enfin supprimé du device F5.

Data groups

Les data groups sont situés dans le menu « Local Traffic » dans un nouvel onglet. À partir de cet onglet, nous pouvons facilement afficher et gérer les data groups. Pour l’instant, seuls les data groups « internes » sont pris en charge.
Comme les autres objets Local Traffic, ils sont organisés dans un tableau qui permet la recherche et le filtrage. Il est possible d’ajouter un nouvel objet data group ainsi que d’afficher, de modifier et de supprimer ceux qui existent déjà.

iRules

La vue iRules a été améliorée en permettant plus d’opérations sur les iRules existantes et la possibilité d’en créer de nouvelles. Désormais, vous pouvez également les modifier ou les supprimer facilement.
L’historique des modifications est conservé et, si nécessaire, l’iRule peut être restaurée à l’une des versions précédentes. Pour que tout reste propre et net, les anciennes versions qui ne sont plus nécessaires peuvent être supprimées. Il est important de noter que tous les changements qui se produisent à partir du Device Manager sont toujours conservés, mais cela n’est pas garanti avec des changements provenant d’ailleurs. Les iRules sont récupérées périodiquement et si plusieurs éditions se produisent entre cette période, seule la dernière sera visible dans l’historique.
La dernière amélioration sur les iRules est la prise en charge des tags dans l’action « Send to… » pour permettre l’envoi de l’iRule dans un ensemble de device F5.

Améliorations

Devices

Le menu « Devices » a reçu quelques améliorations :

  • Les alertes de sécurité peuvent être triées et filtrées,
  • La date dans la cellule « Backed up » est bien formatée,
  • Le petit bug qui provoquait l’affichage d’un statut erroné du device est maintenant corrigé.

Tâches

Lorsqu’un iscript est exécuté à partir d’une tâche, ses journaux sont désormais imprimés à la fois dans les logs d’exécution des tâches et dans les logs des applications. Avant, ils n’étaient imprimés que dans les logs applicatifs. Grâce à ce changement, il est maintenant plus facile de trouver le problème en cas d’échec de l’iscript.

Performance

Nous avons remarqué que pour de nombreux devices avec un grand nombre d’objets LTM, le menu Local Traffic peut devenir lent. Pour améliorer l’expérience utilisateur et économiser certaines ressources, nous avons amélioré la pagination et cessé de charger les données qui ne sont pas directement visibles dans les tableaux. Seule la visualisation des détails d’objets spécifiques récupère des informations complètes – par exemple, seule une liste d’iRules contenant des noms, des noms de devices et des partitions est récupérée et après avoir cliqué sur « afficher » ou « modifier », son code et son historique sont récupérés.
Une autre amélioration des performances se trouve dans le menu « Where Used ». Ici, les requêtes sont déclenchées de manière asynchrone pour chaque appareil. Pour éviter de surcharger à la fois le côté serveur de l’application et un navigateur, en déclenchant trop de requêtes à la fois, elles sont mises en file d’attente et seules quelques-unes d’entre elles peuvent s’exécuter simultanément.

 

Correctifs

  • Dans le menu « Where used » les résultats sont parfois erronés
  • Les politiques ASM étaient parfois écrasées, ce qui faisait que seules celles du dernier device étaient visibles
  • Problème de navigation dans les onglets pour les utilisateurs sans autorisations complètes.
[ Bulletin Sécurité ] Multiples vulnérabilités Apache Log4J – DEV

[ Security Bulletin ] Multiple Apache Log4J vulnerabilities - DEV

[ Security Bulletin ] Multiple Apache Log4J vulnerabilities - DEV

Le 9 décembre dernier, Apache a publié une vulnérabilité zero-day (CVE-2021-44228) pour Apache Log4j appelée « Log4Shell ». Cette vulnérabilité a été classée comme « Critique » avec un score CVSS de 10.0, permettant l’exécution de code à distance avec des privilèges au niveau du système.

Lorsqu’elle est exploitée, cette vulnérabilité permet à un attaquant d’exécuter du code arbitraire sur l’appareil, donnant un contrôle total à l’attaquant. Tout appareil exploité doit être considéré comme compromis, ainsi que tout appareil ayant fait confiance à l’appareil compromis.

Les équipes e-Xpert ont investigué les produits développées par nos soins pour identifier l’impact de cette vulnérabilité pour nos clients. Les produits et composants suivants ne sont PAS concernés par cette vulnérabilité:

  • Device Manager
  • Analytics tool for APM (Insight)
  • SSLCert
  • Esas
  • Account
  • IP Reputation

Toute l’équipe se tient à disposition pour toute demande d’information.

Update 16.12.2021 : Les produits développés par e-Xpert Solutions n’implémentent pas Java. Nos produits ne sont non plus pas impactés par les vulnérabilités CVE-2021-4104 et CVE-2021-45046

Zero-Trust, Micro-Segmentation : Guardicore Centra pour la protection de vos biens numériques les plus précieux.

Zero-Trust, Micro-Segmentation : Guardicore Centra for the protection of your most valuable digital assets.

Zero-Trust, Micro-Segmentation : Guardicore Centra for the protection of your most valuable digital assets.

Les systèmes d’information sont conçus aujourd’hui, non seulement pour répondre à un besoin « business », mais également pour s’assurer d’une certaine robustesse face aux tentatives d’utilisations illégitimes du service, ou face aux erreurs. En règle générale, les principes de défense en profondeur sont appliqués : cela consiste à assembler des mécanismes de protection réseau, applicatifs, endpoint pour multiplier les points de contrôles et augmenter les chances de détecter des opérations malveillantes avant qu’elles n’atteignent les données ou processus critiques.

Ces principes représentent en quelque sorte un tronc commun nécessaire pour assurer un niveau de sécurité correct pour tout environnement IT.

Zero-Trust : recentrer la sécurité sur l’asset

Dans certains cas de figure, certaines informations, processus métier peuvent nécessiter un niveau de protection bien supérieur soit :

  • Du fait de contraintes règlementaires strictes, ayant des impacts (financiers ou d’image) potentiellement graves pour l’entreprise. Ces contraintes pouvant être spécifiques à un secteur (finances, médical) ou simplement à la législation en vigueur (LDP, RGPD)
  • Du fait de l’impact intrinsèque pour l’entreprise en cas de vol, compromission, destruction, indisponibilité… (par exemple : données de client bancaire, données médicales, systèmes critiques SCADA …)

Dans ces cas de figure, la solution ne peut plus se baser uniquement sur la sécurité globale de l’environnement, mais directement sur les applications critiques, leurs composants internes et leurs dépendances.

e-Xpert Solutions a récemment inclu la solution GuardiCore Centra dans son cataloge de solutions pour permettre la mise en oeuvre d’une approche de ce type.

Les  avantages de cette approche sont :

  • Visibilité, et contrôle précis et exhaustif de toute les interfaces avec l’application protégée.
  • Visibilité et contrôle précis et exhaustif de tous les échanges internes au fonctionnement de l’application protégée
  • Maintien de la protection même en cas de compromission d’un autre composant du SI, y compris s’il survient sur le même segment réseau (détection des mouvements latéraux)
  • Aucune adhérence à l’emplacement de l’application : elle peut être hébergée dans le datacenter de l’entreprise ou dans le Cloud, et bénéficier des mêmes politiques de sécurité
  • Certaine Indépendance vis à vis de l’insfrastructure réseau pour la définition et mise à jour de la politique de sécurité

Figure: Application Segmentation / Application Fencing – La sécurité recentrée sur l’application et ses composants.

Micro-Segmentation

Autre cas de figure de plus en plus fréquent, la mise à disposition de micro-services simples (sur des systèmes physiques ou virtuels) ou via containers (Docker). C’est notamment le cas dans les approches Open Banking pour la finance, ou plus généralement pour les applications de type Progressive Web App ou Ajax.

Par l’utilisation d’agent logiciel pouvant être installé :

  • Sur des environnements de virtualisation (ESX, Xen)
  • Sur des serveurs Windows, Linux
  • Sur des serveurs hébergeant des systèmes de containers (Docker)

Les agents Guardicore étant au plus près des ressources protégées, la solution permet de mettre en place des politiques de filtrage très précise, prenant en compte jusqu’au processus impliqué et l’utilisateur connecté.

Figure: Micro-segmentation des échanges par processus.

Fonctionnalités de la solution GuardiCore

Visibilité
L’architecture et le mode de fonctionnement de GuardiCore Centra permet également d’avoir une visibilité précise des échanges entre les différentes entités supervisées, jusqu’au processus et utilisateus impliqués. Ces informations pouvant être retrouvées :

  • Sous forme graphique via les « Maps » Guardicore
  • Dans les journaux de la solution Guardicore
  • Dans un SIEM sur lequel Gardicore envoie les informations

Cette fonction repose principalement sur le module « Reveal » de l’agent.

Blocages des requêtes illégitimes
Permet le blocage des requêtes (entrantes ou sortantes) non conformes à une politique de sécurité.
Cette fonction repose principalement sur le module « Enforcement » de l’agent.

Monitoring d’intégrité de fichier
Permet de détecter et d’alerter en cas de modification illégitime de certains fichiers stratégiques sur un système.
Cette fonction repose principalement sur le module « Detection » de l’agent.

Honey Pot
Permet de rediriger un intrus ayant pu pénétrer le système d’information et tentant d’accéder à des systèmes protégés par Guardicore vers des systèmes émulant le comportement de serveur Web, RDP et SSH, et enregistrant les opérations réalisées

Cette fonction repose principalement sur le module « Deception » de l’agent.

Architecture Guardicore Centra

Le schéma ci dessous représente une vue générale des composants Guardicore :

Figure: Architecture générale Guardicore Centra

Les composants apparaissant sont :

  1. Bare Metal (serveurs physique) : installation d’agent sur les serveurs à superviser ou de collecteurs SPAN placés stratégiquement sur certains switch.
  2. Virtual Servers (serveurs virtuels) : installation d’agent sur les serveurs virtuels à superviser ou de collecteurs pour les environnements de virtualisation.
  3. Cloud Instances : installation d’agents sur les systèmes à superviser.
  4. Containers : installation d’agents sur les systèmes à superviser et hébergeant les containers.

Le tout centralement géré par GuardiCore Centra Management and Analysis : composants centraux de la solution Guardicore Centra, par défaut hébergés dans le cloud, mais pouvant également être installé dans l’environnement client. Des interfaces permettent ensuite d’interagir avec des SIEM (logs, traçabilité), CMDB (récupération d’asset et tagging), Orchestration (interaction avec des systèmes tiers pour enrichir les informations sur les assets supervisés).

Enfin l’architecture étagée est concue pour être résiliente et scalable :

  • Les agents rapportant au aggregators, dont la distribution peut être adaptée en fonction du nombre d’agents, mais aussi en fonction des contraintes techniques, réseau, de responsabilité, géographiques …
  • Les collectors sont répartis stratégiquement en fonction de l’architecture (virtualisation, réseau physique)
  • Les aggregators et collectors rapportent à la plateforme de management, et la plateforme de management utilise les aggregators pour distribuer les configurations vers les agents.
en_GB