Par défaut sous-estimées par les équipes techniques internes et de défense, souvent sur-privilégiées, les App registrations peuvent permettre des pivots puissants suite à la compromission de l’environnement cloud.

Parmi les services les plus exposés, Microsoft SharePoint se distingue. Présent sur la majorité des tenants M365, souvent configuré de manière permissive, il offre un accès aux fichiers de l’entreprise via SharePoint et des collaborateurs au travers de OneDrive.

Cet article revient sur plusieurs constats observés en opération Red Team : comment une simple App Registration, liée de près ou de loin à SharePoint, peut offrir un accès élargi à votre SI on-premise, et comment l’exploitation de ce maillon faible permet parfois de faire de votre segmentation en Tiers une simple formalité pour l’attaquant.

Introduction aux App Registrations

Dans Microsoft Azure, l’enregistrement d’une application (App Registration) dans Entra ID permet de créer une identité pour cette application, ainsi qu’une Enterprise Application associée. L’App Registration définit l’application (identifiants, clés, permissions), tandis que l’Enterprise Application représente son instance dans le tenant, sur laquelle sont appliquées les politiques d’accès (comme l’authentification conditionnelle portée par les politiques d’accès conditionnels ou les rôles attribués).

Une App Registration contient les informations requises pour s’authentifier auprès d’Entra ID et obtenir des jetons d’accès pour interagir avec des services Microsoft 365 via des API comme Microsoft Graph. Selon les permissions qui lui sont accordées (déléguées (scopes) ou applicatives (rôles)) elle peut lire ou modifier des ressources telles que des mails, des fichiers, des utilisateurs ou des groupes tant que l’Enterprise Application est instanciée dans le tenant.

Généralement utilisées pour enregistrer une application visant à automatiser des processus métiers (gestion des utilisateurs, nettoyage de fichiers SharePoint, supervision de l’activité O365…), elles constituent une surface peu surveillée, mais à fort impact.

En effet, les secrets des App Registrations (certificats, client secrets) sont souvent stockés de manière non sécurisée (dans des dépôts de code, postes de travails, serveurs). Ces secrets permettent de personnifier une application avec des privilèges potentiellement élevés (listés dans l’App Registration) entraînant une persistance discrète sur les ressources de l’entreprise.

Pour un attaquant, compromettre une App Registration revient à s’approprier une identité applicative EntraID disposant d’un accès direct à certaines données de l’entreprise, sans nécessiter de rebond par des comptes utilisateurs interactifs ni MFA. Alors que les sécurités se multiplient autour des comptes utilisateurs (MFA obligatoire, accès conditionnel imposant une adresse IP ou un appareil de confiance), il est souvent constaté que celles-ci ne sont pas encore appliquées aux applications.

Se connecter en tant qu’une App Registration

Les applications Azure peuvent s’authentifier auprès d’Entra ID à l’aide de secrets d’application générés dans l’App registration associée :

• AppId + App Secret: Ce moyen d’authentification, équivalent à l’usage d’un nom d’utilisateur et d’un mot de passe est soumis aux mêmes limitations : il est compliqué d’assurer leur protection car ils peuvent facilement se retrouver stockés de manière non sécurisée, exposés dans les historiques de commandes, etc…

• AppId + Certificat: Cette méthode de connexion est davantage sécurisée, puisque les solutions de sécurité installées sur les machines protègent de manière efficace les certificats installés. Néanmoins, celle-ci est généralement moins utilisée en raison des contraintes d’utilisation qu’elle implique, telle que l’installation du certificat sur chaque machine nécessitant l’utilisation du compte.

Les identifiants et secrets d’une application lui permettent de récupérer un jeton d’accès OAuth2, afin de s’authentifier et d’appeler des API Microsoft (Graph, SharePoint, Exchange, etc.) qu’elle est autorisée à contacter. Ce mode de connexion est généralement difficile à détecter si les journaux d’accès ne sont pas activés ni supervisés.

Les droits d’une App Registration

Chaque App Registration définit les permissions API associées à l’application enregistrée. Elles sont décrites sous forme de rôles ou de scopes, sur différents services Microsoft. A titre d’exemples, ces autorisations d’application peuvent permettre de :

• Lire ou modifier des profils utilisateurs (User.ReadWrite.All) ;
• Gérer des objets dans l’annuaire Entra ID (Directory.ReadWrite.All) ;
• Lire, écrire ou supprimer des fichiers SharePoint ou OneDrive (Files.ReadWrite.All) ;
• Lire ou écrire des mails dans toutes les boîtes mails (Mail.ReadWrite) ;
• Etc.

Lors des audits, il est constaté que ces droits sont souvent surdimensionnés par rapport aux besoins réels des applications. Ils peuvent ainsi offrir à un attaquant un levier d’élévation de privilèges majeur s’ils sont récupérés.

D’autre part, un attaquant peut identifier les droits d’une application au travers de l’App Registration associée et compromise en s’authentifiant via l’URL https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token :

Le jeton d’accès obtenu est au format base64, et les droits définis par l’App Registration y sont présents :

Compromission d’App Registrations en opération Red Team

Dans le cadre d’une attaque, il est très fréquent que la compromission s’opère de manière progressive.

Généralement, un premier serveur est compromis, puis un second, etc. jusqu’à atteindre des composants plus critiques de l’infrastructure ou des utilisateurs davantage privilégiés : accès initial, élévation de privilèges, latéralisation, et ainsi de suite.

Ces dernières années, l’implémentation du modèle en Tiers (Tier-0, Tier-1 et Tier-2) au sein des infrastructures Active Directory s’est généralisée, avec par la même occasion une augmentation du niveau de sécurité des SI on-premise. Un nouveau facteur s’est également ajouté avec le développement des agents EDR : la détection !

Dorénavant au sein d’environnements matures, il est plus difficile de compromettre le Tier-0 (contrôleur de domaine, PKI, etc.) par la simple compromission d’un serveur Tier-1, le tout sans se faire détecter par la Blue Team, l’équipe de défense.

Toutefois, au cours de plusieurs opérations au sein d’environnement très variés, SharePoint s’est présenté comme un vecteur d’élévation de privilèges redoutable, et où aucune détection n’a été remontée côté Blue Team.

Plusieurs retours d’expériences d’opérations Red Team illustrant ce propos sont partagés ci-dessous.

Cas n°1 : Administrateur Tier-2 d’un sous-domaine vers la compromission de la forêt Active Directory

Ce cas illustre une opération pour un client international dont le SI se compose de plusieurs milliers de serveurs, qu’il s’agisse de serveurs applicatifs et métiers, industriels, d’infrastructure, etc. La compromission d’un premier serveur a engendré la compromission de comptes administrateurs Tier-1 puis Tier-2.

Dès l’obtention de privilèges d’administration acquis sur des postes de travail (Tier-2), une phase de collecte ciblée s’est amorcée dans le but d’identifier des secrets applicatifs.

Sur plusieurs postes d’utilisateurs à profil technique (équipes DevOps, Cloud, etc.), des scripts PowerShell sont découverts. Certains contiennent des identifiants liés à des App Registrations, avec un AppId, un AppSecret, ainsi que l’identifiant du tenant Azure auquel ils sont associés :

L’exploitation de ces secrets permet à l’attaquant de se connecter directement à la Microsoft Graph API, avec les autorisations déjà consenties définies dans l’App Registration compromise.

L’App Registration identifiée dans ce contexte contient des droits d’application étendus sur O365, notamment :

• User.ReadWrite.All: Lire et modifier tous les profils utilisateurs.
• Directory.Read.All: Lire les données du répertoire.
• Directory.ReadWrite.All: Lire et écrire les données du répertoire.
• Group.ReadWrite.All: Lire et écrire toutes les informations des groupes.
• Files.ReadWrite.All: Lire et écrire tous les fichiers.
• Mail.ReadWrite: Lire, créer, supprimer des mails en toutes les boîtes mails.
• Calendars.ReadWrite: Lire et écrire tous les calendriers.
• Contacts.ReadWrite: Lire et écrire tous les contacts.
• Tasks.ReadWrite: Lire et écrire toutes les tâches.

Parmi cet ensemble de permissions d’application, le droit Files.ReadWrite.All s’avère particulièrement critique et intéressant pour un attaquant, autorisant un accès complet à tous les fichiers stockés sur SharePoint et OneDrive.

Note : Ces permissions peuvent être « déléguées » et dans ce cas ne s’appliquent que dans le contexte de ce que peut faire l’utilisateur.

Un script PowerShell a été développé par l’équipe Red Team Wavestone (SharePwned) afin d’effectuer des recherches sur SharePoint et OneDrive basées sur des mots-clefs, et télécharger les fichiers souhaités.

Par le biais de ce script et via une recherche sur le nom de domaine de la forêt d’administration Active Directory (admin.xx.xxxx.net), plusieurs fichiers ont été identifiés au sein d’espaces OneDrive d’utilisateurs, puis téléchargés :

Ces fichiers, stockés sur l’espace OneDrive d’utilisateurs à privilèges, permettent d’identifier les serveurs de rebond utilisés pour accéder à la forêt Active Directory d’administration du SI.

Le stockage non sécurisé des secrets sur les postes de travail et espaces Cloud représente une faille de sécurité majeure. Pour autant, l’absence de sécurité et de supervision autour de cette App Registration liée à d’importants privilèges représente une vulnérabilité critique dès lors qu’une Enterprise Application associée est instanciée dans le tenant.

Dans le cas présent, la compromission du Tier-2, puis l’accès en lecture aux fichiers stockés sur les espaces OneDrive des collaborateurs a permis d’identifier rapidement les secrets et rebonds réseaux nécessaires à la compromission du Tier-0 de l’entreprise.

Cas n°2 : Accès distant au réseau d’entreprise du Groupe à partir de la compromission d’une filiale

Ce second cas présente une opération Red Team ciblant une entreprise disposant de nombreuses filiales et dont les réseaux ne communiquent pas entre eux.

Tout d’abord, le SI d’une première filiale a été compromis, ainsi que son tenant Azure.

A des fins de persistances et de recherches, une App Registration a alors été créée par la Red Team, tout en ajoutant l’autorisation d’application Files.Read.All.

En téléchargeant les secrets de l’application lors de sa création, il est une nouvelle fois possible d’utiliser l’outil développé par la RT Wavestone pour effectuer des recherches SharePoint et OneDrive :

En effectuant des recherches de mots de passe, des comptes associés à des solutions d’accès distants à l’entreprise cible du Red Team sont identifiés. En effet, certains membres des équipes Finance de la filiale compromise disposent d’accès à la solution de bureau distant du groupe, et stockent leur mot de passe en clair sur leur espace OneDrive.

Bien qu’un MFA soit configuré pour l’ensemble des utilisateurs de cette solution, seule une approbation de la notification est requise, et aucun code n’est demandé. En noyant les utilisateurs de notifications MFA, l’un d’eux a finalement validé l’authentification, permettant aux opérateurs Red Team d’accéder temporairement à la solution de bureau distant.

Finalement, en accédant à l’application de Finance hébergée sur une machine virtuelle Windows, un accès au réseau interne du groupe est récupéré.

Ainsi, à partir d’une compromission de filiale sans interconnexion directe avec le réseau groupe, l’usage d’App Registrations a permis une fois encore de découvrir des secrets et rebondir sur le SI groupe.

Cas n°3 : Compromission de l’EDR déployé sur les contrôleurs de domaine à partir de la chaîne CICD

La compromission de l’environnement CICD du client (hébergé sur AWS) a mené à la compromission de son serveur GitLab. Avec les droits root sur le serveur GitLab, il est possible d’accéder à sa base de données, et aux secrets qui y sont stockés. Bien que ceux-ci soient chiffrés, il est possible de les déchiffrer via la console GitLab Rails.

Parmi ces secrets, des clientID et clientSecrets Azure d’une App Registration sont récupérés. Ces identifiants d’accès permettent de se connecter à Azure sous l’identité de l’application associée, dans le cas présent sous l’identité de l’application GitLab.

Sur le tenant client, l’application GitLab dispose d’un rôle de contributeur sur les ressources d’une souscription Azure. Cela signifie qu’elle peut gérer les accès aux ressources, et en lire le contenu.

Parmi les ressources accessibles, des secrets sont stockés (et accessibles en lecture) dans un coffre-fort Azure Vault. En particulier, des clientId et clientSecret y sont présents :

Une nouvelle application Azure, nommée xxxxx-NettoyageSharePoint, est ainsi obtenue. Celle-ci possède les permissions nécessaires pour lire l’intégralité de SharePoint et OneDrive.

En utilisant une première version de l’outil SharePwned, une recherche de secrets est effectuée au sein des espaces OneDrive des collaborateurs. Des secrets stockés de manière non sécurisée sont découverts dans des fichiers de configuration d’outils d’administration, tels que mRemoteNg. Ces fichiers de configuration contiennent généralement des mots de passe chiffrés avec une clé publique connue. Ainsi, il est possible de les déchiffrer et obtenir les mots de passe en clair des utilisateurs :

Le compte récupéré ici dispose de privilèges d’administration sur l’application IAM de l’entreprise.

Après de multiples recherches de documentations sur SharePoint, toujours en utilisant l’outil SharePwned afin de cibler les recherches, l’équipe Red Team a pu comprendre les moyens d’intervention de l’équipe SOC sur le Système d’Information, les coffres-forts où sont stockés leurs secrets, et les droits nécessaires pour y accéder.

Alors, en utilisant le compte administrateur de l’IAM récupéré dans OneDrive, une attaque se basant sur les procédures d’intervention du SOC a été réalisée pour compromettre intégralement le Système d’Information on-premise du client.

Dans ce cas de figure également, des recherches ciblées sur SharePoint et OneDrive ont permis de récupérer de l’information technique très intéressante pour un attaquant, notamment l’agent EDR déployé sur les DC, les secrets nécessaires à son utilisation, les droits à s’attribuer pour y accéder.

Au-delà des mots de passe récupérés (chiffrés ou non) dans l’ensemble des scénarios précédemment décrits, SharePoint et OneDrive représentent un accès à la connaissance du SI pour l’attaquant. Lorsque l’attaquant se veut discret, il doit reproduire au mieux les flux métiers et d’administrations légitimes de l’entreprise. Le prérequis à cela est tout d’abord de les connaître, pour ensuite les comprendre et les appliquer.

Protéger et détecter les usages malveillants des App Registrations

Comme énoncé précédemment, SharePoint et OneDrive ont permis l’obtention de secrets relativement sensibles et compromettants pour les SI clients. Il reste donc primordial de sensibiliser les collaborateurs au stockage sécurisé des secrets et de les outiller à ces mêmes fins.

Malgré cela, il convient d’appliquer des processus et des mesures de sécurité à ces applications afin de leur faire respecter les principes de moindre privilège et de défense en profondeur. Ci-dessous sont listées des recommandations à appliquer à ces App Registrations.

Revue régulière et principe de moindre privilège

Il convient d’inventorier les applications disposant des permissions sur SharePoint et restreindre ces applications au strict minimum. Les permissions en question sont les suivantes :

• Sites.Read.All;
• Sites.ReadWrite.All;
• Sites.FullControl;
• Files.Read.All;
• Files.ReadWrite.All.

Au même titre que pour les utilisateurs et groupes à privilèges, une revue régulière de ces App Registrations est nécessaire.

Gestion et supervision des secrets

Afin d’éviter que des App Secret ne se retrouvent stockés de manière non sécurisée (au sein de scripts, documentations, mails, etc.), il est recommandé de préférer l’usage de certificats de connexion.

De manière générale, les secrets de connexion doivent faire l’objet d’un renouvellement régulier et automatisé.

La création d’une App Registration génère automatiquement la création d’une Enterprise Application. Lorsque celle-ci se voit attribuer des permissions de lecture sur SharePoint, un consentement de la part d’un Global Administrator est nécessaire. Il n’est ainsi pas trivial pour un attaquant de créer ce type d’applications privilégiées et l’ajout d’un secret à une application existante à privilèges sera souvent préférée par l’attaquant.

Il convient donc de superviser la création de nouveaux secrets de connexion sur les applications à privilèges.

Réduire la surface d’exposition

Enfin, il est recommandé de limiter les capacités d’utilisation de ces applications. Il peut s’agir de restrictions sur l’adresse IP source ou encore sur les plages horaires d’utilisation de l’application.

Note : Il n’est pas toujours nécessaire d’appliquer ces mesures en mode « bloquant ». En effet, une détection sans blocage peut déjà permettre à la Blue Team de prendre connaissance de l’attaque et amorcer sa réponse.

Cet article SharePoint & App Registrations : Vecteur de compromission du SI et RETEX Red Team est apparu en premier sur RiskInsight.

Les attaquants ont bien compris cet enjeu et nous voyons de plus en plus de cyber-attaques touchant les sauvegardes. Comme le souligne le benchmark 2021 des cyber-attaques en France, dans 21% des attaques par ransomware, les systèmes de sauvegarde ont été ciblés jusqu’à être rendus inutilisables.

Quel est le mode opératoire des attaquants pour atteindre les sauvegardes ?

Tout d’abord, les sauvegardes peuvent être touchées en tant que dommage collatéral. Ce fut le cas il y a quelques années lors d’une cyber-attaque chez l’un des clients du CERT-Wavestone : l’infrastructure de gestion des sauvegardes a elle-même été chiffrée par le ransomware et il a fallu la reconstruire avant de pouvoir restaurer les sauvegardes.

Lors d’attaques par ransomware, les attaquants peuvent aussi cibler directement les sauvegardes pour forcer leur cible à payer la rançon. Par exemple, il y a moins d’un an lors d’une réponse à incident du CERT-Wavestone, l’attaquant avait pris soin de détruire toutes les sauvegardes avant de chiffrer le système d’information du client. Il avait pu arriver à ses fins car l’infrastructure de gestion des sauvegardes était administrée à travers un compte dans l’Active Directory. L’attaquant ayant réussi à élever ses privilèges au plus haut niveau, il a pu aisément se connecter sur l’infrastructure de sauvegarde et supprimer toutes les données sauvegardées.

Des premières mesures de protection peuvent déjà fortement réduire le risque

Dans 100% des crises ransomware gérées par le CERT-Wavestone, l’attaquant possédait des comptes d’administration du domaine Active Directory. Pour empêcher l’attaquant d’atteindre les sauvegardes par ce biais, il faut donc séparer l’infrastructure de sauvegarde de l’Active Directory : s’assurer que les comptes d’administration des sauvegardes ainsi que les serveurs de sauvegarde sont hors Active Directory (NB : cela n’empêchera pas cette infrastructure de sauvegarder les ressources gérées dans l’Active Directory).

Pour réduire davantage le risque de compromission d’un compte d’administration, il faut aussi renforcer l’accès d’administration des sauvegardes, avec par exemple une authentification multi-facteur (MFA).

Par ailleurs, les attaques par ransomware se propageant souvent sur le même système d’exploitation, il peut être intéressant d’adopter un système d’exploitation différent pour l’infrastructure de sauvegarde. Sinon, a minima effectuer une copie du catalogue de sauvegarde (base de données contenant les pointeurs vers les sauvegardes) sur un système d’exploitation différent, afin de permettre une restauration rapide de l’infrastructure de sauvegarde en cas de compromission.

En complément, il est parfois possible d’appliquer des mesures de rétention des données sauvegardées au niveau de la technologie de stockage des sauvegardes, comme l’application d’un délai avant la suppression réelle des données ou bien la conservation d’une copie (ou snapshot) sur la baie de stockage. Cela permet de s’accorder un délai d’un ou plusieurs jours avant la perte complète des données en cas de suppression.

Pour aller plus loin…

Différentes initiatives émergent, visant à standardiser les mesures de protection des données face à la menace grandissante (e.g. Secure Tertiary Data Backup Guideline par la HKAB – Hong Kong Association of Banks, Sheltered Harbor aux Etats-Unis…).

Par ailleurs, les éditeurs de solutions de sauvegarde construisent leurs solutions en prenant en compte la menace cyber, avec des fonctionnalités de détection de ransomware, des fonctionnalités d’immutabilité (pour rendre les données sauvegardées complètement inaltérables, même pour un administrateur) ou encore des possibilités d’isolation « hors-ligne » des sauvegardes.

Ces solutions peuvent être adoptées en remplacement ou bien en complément de solutions de sauvegarde existantes. Néanmoins, elles nécessitent souvent des investissements importants. Or comme nous l’avons vu, un certain nombre de premières mesures de protection peuvent déjà fortement réduire le risque. Il convient donc de bien identifier les scénarios de menace redoutés et son niveau d’exposition, ainsi que les éventuels besoins de conformité (réglementations, standards…), afin de définir une feuille de route adaptée de montée en maturité.

Cet article se veut être une introduction à la protection des sauvegardes contre les cyber-attaques. Nous aurons l’occasion d’approfondir le sujet dans le cadre de futures publications.

Cet article Cyber-attaques : quels risques sur les sauvegardes et comment s’en protéger ? est apparu en premier sur RiskInsight.

Pourquoi assurer son SI industriel ?

On définit les systèmes d’information industriels comme des systèmes « logiques » permettant de piloter des outils de production « physiques » (chaînes de montage, machines-outils, fours, scanners médicaux, climatisations, aiguillages, pipelines…). De plus en plus ouverts, ils se positionnent comme un intermédiaire entre le système d’information « classique » de l’entreprise, et sa chaine de production physique.

De par son positionnement clé pour l’entreprise, la sensibilité des données et systèmes qu’il manipule et son ouverture accrue sur le SI de l’entreprise (voire parfois sur internet), le SI industriel devient de plus en plus souvent la cible d’attaques aux motivations différentes (destruction, espionnage, gain financier…). Les récentes attaques révélées en Allemagne par le BSI avec la compromission du système de contrôle du haut fourneau ou en Corée du Sud avec le vol de données sur les réacteurs nucléaires ne font que confirmer la probabilité d’attaques de ces systèmes.

En plus des dommages matériels (destruction de ses outils de production) et immatériels (frais de reconstruction des données, frais d’expertise…) pour l’entreprise, les conséquences de ces attaques peuvent être considérables et dépasser le cadre même de l’entreprise : fuite radioactive, déraillement d’un train…

Face à ce risque majeur, et l’impossibilité à la fois d’empêcher la totalité des attaques et d’absorber l’ensemble des impacts, le besoin d’assurabilité de ces systèmes se fait ressentir.

Les assurances traditionnelles ne répondent pas au besoin

Les assurances traditionnelles, et notamment les assurances « Dommages », peuvent répondre à certains risques liés aux SI industriels. Elles permettent notamment de couvrir les dommages matériels liés à une panne informatique, ou à un incendie. De même, les polices « Responsabilité Civile » peuvent couvrir les dommages aux tiers suite à un incident sur le SI industriel.

Pour autant ces contrats traditionnels trouvent parfois leurs limites dans un contexte cyber.

En effet, ces assurances couvrent très rarement les dommages immatériels, quel que soit le scénario de sinistre, et encore moins si le scénario est une cyberattaque. De fait, les frais de reconstitution des données et d’expertise technique (par exemple pour les investigations numériques suite à une attaque) sont rarement couverts par ces assurances.

De plus, la plupart de ces contrats ont des exclusions liées la cause du sinistre et excluent les cyberattaques. Il est parfois possible de « racheter » ces exclusions moyennant une hausse de la prime annuelle, mais ce n’est pas toujours le cas et la couverture se limite quasiment toujours aux dommages matériels.

La cyberassurance est-elle la solution ?

Se présentant comme l’assurance des risques cyber, on pourrait naturellement imaginer qu’elle couvre complètement les besoins d’assurance des SI industriels relatifs au risque de cyberattaque. Malheureusement, il n’en est rien : si certains contrats commencent à proposer des solutions couvrant la particularité logique/physique des SI industriels, la plupart n’y répond que partiellement.

Le premier frein à la couverture totale est le fait que la cyberassurance couvre majoritairement les dommages immatériels, puisque destinée principalement aux systèmes d’information « classiques ». En effet, l’impact naturel associé à une cyberattaque est une atteinte aux données, et non au matériel. Avec cette approche, de nombreux frais sont couverts : frais de reconstruction des données, frais d’expertise, frais de notification, frais de justice…. Pour autant, l’ensemble des dommages matériels, et notamment sur les systèmes physiques industriels détruits, ne sont pratiquement jamais couverts, ce qui entraine un manque notable dans la couverture du risque pour un SI industriel, et peut ainsi freiner la souscription d’une cyberassurance.

Par ailleurs, au vu des impacts importants liés aux SI industriels qui peuvent dépasser le cadre même de l’entreprise, certains assureurs excluent directement dans leur police la couverture de l’ensemble des frais liés à ces systèmes, qu’ils soient immatériels ou matériels. Le risque n’est alors pas (ou peu) couvert.

Une évolution en vue ?

Cependant, avec la demande croissante des acteurs de l’industrie, les cyberassureurs commencent à intégrer la couverture des dommages matériels (voire humains) à leur police. Pour autant, il est à noter que des sous-limites (limitation de garantie pour certains frais) contraignantes y sont souvent associées, ce qui peut parfois en limiter considérablement l’intérêt. Cependant, dans un marché fortement concurrentiel et compte tenu des impacts associés, cet argument peut rapidement apparaitre comme différenciateur.

Il existe un « vide » dans la couverture assurantielle des risques cyber pour les systèmes d’information industriels. Les assurances traditionnelles montrent un certain nombre de limites en excluant souvent les scénarios cyber, et a contrario les cyberassurances couvrent rarement les dommages matériels, pourtant centre de coût clé des SI industriels. Pour autant, les cyberassurances commencent à proposer des solutions avec une couverture plus globale incluant les dommages matériels. Mais la demande doit continuer d’augmenter et le marché se démocratiser pour atteindre une couverture optimale des SI industriels. Pour 2016 ?

Cet article Assurer son système d’information industriel contre une cyberattaque, c’est possible ? est apparu en premier sur RiskInsight.

Les chiffres donnent le vertige : lors de la préparation de son introduction en Bourse, Facebook a évalué ses 850 millions d’amis à 100 milliards de dollars.

De son côté, Google recentre de plus en plus ostensiblement son business model sur la collecte et la valorisation des données relatives à ses utilisateurs et du profilage qu’il en déduit.

Car ces données à caractère personnel constituent bien, des mots mêmes de Viviane Reding, la devise des marchés numériques d’aujourd’hui. Et la commissaire européenne à la Justice d’en déduire : et comme toute monnaie, celle-ci requiert stabilité et confiance. Ce n’est que lorsque les consommateurs pourront avoir pleinement confiance en la protection de leurs données qu’ils continueront à les confier aux entreprises et autorités, à acheter en ligne et à accepter de nouveaux services.

La vie privée à l’heure des nouvelles frontières du numérique

Jusqu’à présent, le droit européen en matière de protection des données à caractère personnel se fonde sur une Directive de 1995, écrite alors qu’Internet n’en était qu’à ses balbutiements.

Depuis, la part d’Internet dans les communications mondiales est passée de 1% à plus de 97%. Cette internationalisation des échanges de données, en parallèle de la monétisation croissante des données, met en évidence les limites et insuffisances de la législation actuelle.

En ce sens, le projet de refonte dévoilé le 25 janvier dernier est doublement intéressant.

Tout d’abord, là où l’on attendait une nouvelle Directive, la Communauté a publié un Règlement : bien loin d’une coquetterie de juriste, il s’agit d’affirmer une approche radicalement différente de celle qui était jusqu’alors en œuvre et fortement décriée. Un Règlement a ceci de spécifique qu’il s’applique directement aux membres, sans qu’ils aient à l’intégrer à leur droit national. En effet, alors que les frontières existent de moins en moins pour les flux de données, il a été estimé que les disparités dans les traductions nationales du droit communautaire en la matière coûtent à elles seules jusqu’à 2,3 milliards par an aux entreprises.

L’objectif, réaffirmé en introduction du document, est donc bien de s’adapter à un monde ouvert et d’harmoniser la protection des données au niveau européen.

Les enjeux, ensuite, ont très clairement évolué. En 1995, le législateur mettait le citoyen au cœur de ses préoccupations, puisqu’il entendait le protéger contre l’informatisation croissante des entreprises et des États. En 2012, maturité aidant, les enjeux économiques et commerciaux sont passés au premier plan : il ne s’agit plus uniquement de protéger la vie privée – ce droit à la vie privée est passé dans les mœurs – mais d’apporter confiance au citoyen (et consommateur) et sécurité juridique aux opérateurs privés et publics.

Les réseaux sociaux en ligne de mire

Un Règlement donc, pour la forme.

Sur le fond, cette proposition s’attaque sans surprise aux nouveaux enjeux liés au développement des réseaux sociaux.

Elle pose ainsi de nouvelles règles, spécifiques au traitement des données à caractère personnel relatives aux enfants de moins de 13 ans, qui sera désormais soumis à l’autorisation de leurs parents. Elle instaure également explicitement un droit à l’oubli numérique, y compris pour les données rendues publiques par la personne. Les pratiques de profilage, telles que celles mises en œuvre par Google, requerront quant à elles le consentement explicite des personnes concernées.

En réaction à la démocratisation d’Internet, elle rend de plus obligatoire la mise en place de canaux électroniques pour l’exercice des droits d’accès et de modification, tout en imposant un délai raisonnable du traitement des demandes.

Une amende à 500 millions de dollars

Si chaque État reste maître dans la définition des sanctions pénales en cas de non-respect des exigences du Règlement, les sanctions administratives sont, elles, considérablement augmentées puisqu’elles pourront atteindre 1 million d’euros ou 2% du chiffre d’affaires mondial de l’entreprise. À titre d’illustration, la sanction maximale prononcée l’année dernière par la CNIL à l’encontre de Google s’élevait à 100 000 €. Demain, elle pourra s’élever à près de 500 millions de dollars…

Vers l’obligation d’un système de management de la protection des données à caractère personnel

Ultime raffinement de l’existant, directement inspiré des meilleures pratiques du marché, cette proposition de Règlement pourrait accélérer la mise en œuvre de systèmes de management de la protection des données à caractère personnel.

On connait les systèmes de management tels que définis dans les normes ISO : par exemple, la qualité, dans l’ISO 9001 (SMQ), la sécurité, dans l’ISO 27001 (SMSI), ou encore l’environnement, dans l’ISO 14001 (SME).

De manière analogue, figurent en effet explicitement dans le texte :

• A l’instar de l’analyse de risque, qui guide la mise en œuvre des mesures de sécurité dans un SMSI, l’obligation :

– De conduire des analyses d’impacts relatifs à la vie privée sur les traitements les plus sensibles.

– De prendre en compte la protection des données à caractère personnel dès la conception des systèmes (le privacy by design anglo-saxon), en fonction des coûts des mesures de sécurité et de l’état de l’art en la matière.

• A l’instar du contrôle, ensuite, qui fonde l’amélioration continue dans les différents systèmes de management cités, un devoir d’audit de l’efficacité des mesures par le responsable de traitement.

Argument complémentaire, si besoin en était, pour la mise en place de tels systèmes : si les formalités déclaratives disparaissent, en contrepartie de l’obligation de désigner officiellement un correspondant aux données à caractère personnel (le CIL français), l’obligation de notification des violations aux traitements de données à caractère personnel, actuellement valable pour les opérateurs télécoms, s’appliquera à l’ensemble des secteurs.

Les critiques de la CNIL

Ce projet de Règlement constitue ainsi une volonté de synthèse entre les meilleures pratiques du marché et des réponses pragmatiques aux difficultés des organismes, en particulier multinationaux, à répondre aux exigences actuelles.

Dans sa volonté d’harmonisation et de renforcement de la coopération européenne en la matière, la Commission propose ainsi un fonctionnement en mode guichet unique : si le justiciable peut s’adresser à l’autorité de contrôle (les CNIL européennes) de son choix, chaque entreprise est placée sous la responsabilité d’une autorité unique, en fonction de la localisation de son siège européen.

Et c’est là que le bât blesse.

Dans un communiqué publié début mars, la CNIL s’est ainsi fait la voix des nombreux détracteurs de cet aspect du Règlement. Intitulé La défense de la vie privée s’éloigne du citoyen, cet article fait état de l’opposition ferme de la commission à ce principe, qui constitue, selon ses termes, une véritable régression vis-à-vis des droits des citoyens.

Pour autant, la majorité des autres points du Règlement ont d’ores-et-déjà emporté l’adhésion de nombreux spécialistes du sujets, juristes et opérationnels. Les organismes seraient donc bien avisés dès maintenant de les intégrer à leur réflexion afin d’être à même de respecter les futures exigences légales.

Et Facebook ne s’y est pas trompé, qui a fait figurer en bonne position parmi les risques mentionnés dans son dossier d’introduction en bourse le durcissement de la législation en matière de données à caractère personnel.

Cet article La vie privée à 27 : encadrer la ruée vers l’or numérique est apparu en premier sur RiskInsight.