Double Key Encryption : la protection sans compromis des données critiques d’entreprise dans le Cloud Azure.

Double Key Encryption: uncompromising protection for business-critical data in the Azure Cloud.

Double Key Encryption: uncompromising protection for business-critical data in the Azure Cloud.

Le challenge de la protection des données dans le cloud

L’adoption des services hébergés est de plus en plus large. Y compris dans des secteurs d’activité historiquement hermétiques à cette approche pour des raisons de sécurité : les données hors du périmètre du S.I. peuvent potentiellement être divulguées.

Dans le cas d’Azure, Microsoft a mis en place il y a déjà quelques années des solutions pour le chiffrement de données basées sur :

  • Des clés générées par Microsoft dans Azure Key Vault
  • Des clés générées par le propriétaire du “tenant” et stockées dans Azure Key Vault (Bring Your Own Key)
  • Des clés générées par le propriétaire du “tenant” et détenues par ce dernier (Hold Your Own Key)

Dans certains cas de figure, les deux premières approches sont trop limitées dans la mesure où la clé ne demeure pas vraiment sous contrôle exclusive de son propriétaire.
Le dernier cas répond à la problématique en contrôlant l’emplacement de la clé. Mais la configuration est souvent complexe, et n’est pas supporté dans la majorité des cas d’utilisation dans Azure.

Double Key Encryption: la solution pour la protection des données critiques dans le cloud.

Microsoft met désormais à disposition une “interface” permettant de repondre précisément à ce besoin: le “Double Key Encryption”. Le principe est relativement simple, utiliser une clé sous contrôle total de l’entreprise propriétaire des données pour le chiffrement des données. Il devient alors impossible pour le fournisseur cloud d’avoir accès au contenu des documents.

Entrust, partenaire de longue date d’e-Xpert Solutions pour ses solutions HSM nShield, a développé un logiciel implémentant DKE. Ce logiciel permet de mettre en place un service DKE, qui, couplé au HSM nShield, garantit un niveau de sécurité très élevé pour les documents chiffrés avec le système.

Le schéma ci-dessous présente les étapes du processus de chiffrement des documents avec le service DKE :

Processus de chiffrement d’un document avec DKE (Source : Entrust)

L’activation de ce processus pour un document est très simple, et consiste à associer un “Label” identifiant un document comme hautement confidentiel. La définition des “Labels” doit être liée à la politique de classification des données de l’entreprise.
Dans la configuration Azure, le paramétrage de ce label est lié à l’URL du service DKE Entrust sous control du propriétaire de l’information:

Configuration d’un label déclenchant DKE.

Il suffit donc à l’auteur d’un document d’ajouter le label défini ci-dessus lors de la création du fichier pour qu’il soit chiffré en utilisant DKE.

Quelles utilisations pour DKE ?

Le service n’a pas réellement vocation à être utilisé pour tous les documents produits par une entreprise, mais plutôt de protéger les biens d’entreprise les plus précieux, ou d’assurer la conformité vis à vis de certaines législation ou règlementations sectorielles.

  • Emplacement géographique imposé pour la clé de chiffrement
  • Contrôle exclusif de la clé par le propriétaire des données
  • Auditabilité de l’utilisation de la clé de chiffrement
  • Stockage de la clé privée sur un HSM

Il est fortement recommandé de mettre en place ou adapter la politique de classification des données de l’entreprise afin de cerner avec précision quels types de documents justifient l’utilisation de DKE dans l’organisation.

Limitations engendrées par DKE

La clé de déchiffrement n’étant plus accessibles par Azure, certaines fonctionnalités ne sont plus disponibles sur les documents protégés par DKE :

  • Règle de transport nécessitant une visibila
  • Microsoft Delve
  • eDiscovery
  • Recherche et indexation
  • Office Web Apps y compris les fonction de “collaboration”

C’est également une raison pour laquelle l’utilisation de DKE doit cibler les documents les plus sensibles seulement.

Double Key Encryption : la protection sans compromis des données critiques d’entreprise dans le Cloud Azure.

TechNews F5: Note of 25 June 2021

TechNews F5: Note of 25 June 2021

Nouvelles fonctionnalités et résolution de Bugs F5.

F5 vient d’annoncer de nouvelles mises à jour concernant certains de leurs produits.

  • NGINX Controller Version 3.18.0

NGINX Controller dans sa version 3.18.0 afin de corriger différents problèmes.

Mise à jour

  • Correction de bugs et améliorations.
  • Amélioration de l’explorateur de données qui permet de voir plus facilement les dimensions de vos données et de prévisualiser les valeurs discrètes.
  • Ajout de la prise en charge de NGINX Plus R23 p1 et R24 p1.

Correctifs de vulnérabilité

  • Communication intra-cluster qui n’utilise pas TLS (5347): Les services de l’espace de noms du contrôleur NGINX utilisent des protocoles en texte clair à l’intérieur du cluster (CVE-2021-23018)
  • Configuration de l’agent visible par l’ensemble des composants (6580): Le fichier de configuration de l’agent « /etc/controller-agent/agent.conf » devient lisible pour tout le monde avec les bits d’autorisation définis et actualisés sur 644. (CVE-2021-23021).
  • Clé API générée avec une cryptographie faible (8867): Les clés API NAAS ont été générées à l’aide d’une chaîne pseudo-aléatoire non sécurisée et d’un algorithme de hachage pouvant conduire à des clés prévisibles. (CVE-2021-23020).
  • Le mot de passe de l’administrateur du contrôleur NGINX divulgué dans les journaux de support « pkg systemd » (22633): Le mot de passe de l’administrateur du contrôleur NGINX peut être exposé dans le « systemd.txt » fichier inclus dans le package de support NGINX. (CVE-2021-23019).

Documentation

Double Key Encryption : la protection sans compromis des données critiques d’entreprise dans le Cloud Azure.

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.
Double Key Encryption : la protection sans compromis des données critiques d’entreprise dans le Cloud Azure.

TechNews F5: Note of 7 June 2021

TechNews F5: Note of 7 June 2021

Nouvelles fonctionnalités et résolution de Bugs F5.

F5 vient d’annoncer de nouvelle mise à jour concernant une partie de leurs produits.

  • OS APM BIG-IP v13
  • BIG-IP Edge Client

BIG-IP APM dans sa version 13 passe en version 13.1.4.1 afin de corriger différents problèmes.

Correctifs de vulnérabilité

  • Amélioration des nouvelles pratiques concernant l’authentification sur Active Directory.
  • Correction du TMM qui peut se bloquer lors du traitement du trafic FastL4 avec le profil d’inspection de protocole. (CVE-2021-23000)
  • Correction des vulnérabilités TMM. (CVE-2021-23007)
  • Correction de la vulnérabilité BIG-IP APM pour Edge Client. (CVE-2020-5893)

Corrections de modifications de fonctionnalités :

  • Possibilité de perte d’efficacité, lorsque les ports sources, forment une séquence arithmétique sur les lames i15000, i15800, i5000, i7000, i10000, i11000 et B4450.
  • Modification d’ « enforce-tls-requirements » pour qu’elle soit activée sur le profil HTTP/2 lorsque la renégociation est activée sur le profil client-ssl pouvant entraîner un échec de validation.
  • La modification des connexions SSH de gestion simultanée est illimitée.

Correction des incidents TMOS

  • Correction des flux de tunnel point à point qui n’actualisent pas les entrées de connexion ; trafic abandonné/rejeté.
  • Le basculement de groupe HA peut échouer à terminer la transition d’état actif/veille.
  • Le système peut ne plus répondre après la mise à nouveau de la dernière mise à jour. (v13.1.4.1).
  • Les lames secondaires se déconnectent après l’élection d’un nouveau serveur principal Crash TMM (SIGFPE) lors du démarrage sur un invité vCMP.
  • Erreur de pool de dernier recours pour la commande de modification pour Wide IP.
  • TMM ne démarre pas lors de l’utilisation de plus de 11 interfaces avec plus de 11 vCPU.
  • Une entrée non spécifiée peut perturber la fonctionnalité prévue dans le proxy iHealth.
  • TMM reçoit un descripteur rx invalide du matériel HSB.
  • Mcpd peut manquer sa pulsation haute disponibilité (HA) su un très grand nombre de membres du pool est configuré.
  • Fuite de mémoire dans icrd-child en raison de l’utilisation simultanée de REST.
  • Vulnérabilité du jeton d’omission de l’analyseur Freetype (CVE-2015-9382).

BIG-IP Edge Client passe en version 7.2.1.3. Cela permet la résolution d’incident de sécurité.

Cette nouvelle version n’apporte pas de nouvelle fonctionnalité ou d’améliorations, mais résout 2 problèmes :

  • Correction du problème ou le client Windows Edge ne suis pas les meilleures pratiques lorsque le cache du navigateur Windows et la fonctionnalité de contrôle de session sont utilisés. Le nettoyeur de cache n’est plus fonctionnel. Possibilité de rencontrer une fenêtre contextuelle Internet Explorer ou Edge Client avec le message suivant même s’il n’est pas pris en charge. « Chargement du contrôle de nettoyage du cache. Veuillez patienter… Cliquez ici pour ignorer le changement et continuer. » Cliquez sur le lien ignoré le chargement pour continuer à vous connecter au client Edge.
  • Correction du problème CVE-2020-5896 qui permettait l’exécution de fichiers.exe et MSI signés en raison de faibles autorisations de fichiers et de dossiers dans le dossier temporaire du service d’installation Windows du client Edge.

Documentation

Double Key Encryption : la protection sans compromis des données critiques d’entreprise dans le Cloud Azure.

Mise à jour de sécurité du Serveur Microsoft Exchange

Mise à jour de sécurité du Serveur Microsoft Exchange

Une nouvelle publication concernant la correction de vulnérabilité, est apparue pour les serveurs Microsoft Exchange.

Cette publication fait suite aux vulnérabilités découvertes au sein des serveurs ayant comme versions

  • Exchange Server 2013
  • Exchange Server 2016
  • Exchange Server 2019

Ces nouvelles mises à jour sont spécifiques à certaines versions des serveurs précédemment énoncés:

  • Exchange Server 2013 CU23
  • Exchange Server 2016 CU19 et CU20
  • Exchange Server 2019 CU8 et CU9

Microsoft met à disposition par l’intermédiaire de GitHub un script permettant la réalisation d’inventaire des serveurs Exchange dans l’environnement professionnel. L’execution du script a pour vocation la réalisation d’un listing de l’ensemble des serveurs présents ainsi que la connaissance de leur potentiel niveau de retard sur les mises à jour (UC et SU) au sein de l’éditeur.

Documentation

Lien GitHub:

en_GB