Quels risques dans le monde de l’IoT ?

L’avènement de l’IoT a permis l’apparition de millions de nouveaux usages potentiels pour les consommateurs et les entreprises. Mais avec ces nouveaux usages émergent certains risques plus marqués dans le domaine des objets connectés.

Figure 1 – Des risques métier et technologiques plus marqués dans le monde de l’IoT

Ces risques métier et technologiques, pouvant induire des impacts potentiellement forts pour les consommateurs et les entreprises, doivent ainsi être identifiés dès les phases amont d’un projet IoT.

Quelle méthodologie projet pour assurer la sécurité d’un objet connecté ?

Même si les thématiques sécurité à aborder dans le cadre d’un projet IoT sont communes à tout autre projet, notre conviction est qu’il est nécessaire de structurer les réflexions autour du cycle de vie de l’objet concerné.

Le schéma ci-dessous met en évidence l’ensemble des étapes du cycle de vie d’un objet connecté.

Figure 2 – Un cycle de vie permettant d’aborder l’ensemble des thématiques sécurité

Regardons quelques questions que soulève cette approche.

1. Phase de conception, de fabrication et de distribution

Cette première phase permet d’adresser les questions liées à la conception de l’objet en regard des enjeux métier, de la cible utilisateurs (B2B, B2C, B2E), de l’environnement de déploiement (contrôlé ou non) et de la criticité de l’usage :

• Quelles sont les contraintes réglementaires s’appliquant aux usages de mon objet ?
• Quelle identité lui donner et comment la créer ?
• Comment assurer la sécurité matérielle et logicielle des secrets et des données stockées dans l’objet ?
• Comment initialiser l’état d’un objet sur la plate-forme de gestion et s’assurer qu’il n’a aucun droit sur le SI avant l’étape d’initialisation ?

Les choix mis en œuvre lors des phases de fabrication sont essentiels car ils déterminent les caractéristiques et capacités de base de l’objet. Un certain nombre seront dès lors immuables tout au long de la vie de l’objet et imposeront des contraintes fortes dans les étapes suivantes.

Par ailleurs, bien que la fin de la phase de fabrication marque le début de l’existence de l’objet sur la plate-forme de gestion d’objet, il n’y a encore aucune raison d’envisager une interaction avec le SI. Toute interaction ayant lieu avant l’association de l’objet à un utilisateur (physique ou moral) signifierait qu’il a été détourné dans l’étape de distribution. Tout accès au SI avant l’étape d’initialisation doit donc être strictement limité à la seule mise à jour du firmware (version N installée en usine et version N+1 disponible lors du déballage) ou à la pré-personnalisation de l’objet (paramétrage de fonctionnement ou injection de secret non liés à l’utilisateur). Au-delà de la sécurité du SI, un objet inutilisable avant toute phase d’appairage réduira le risque de vol de cet objet en usine ou lors de sa distribution.

2. Phase d’initialisation

La phase d’initialisation matérialise l’étape d’association (ou d’appairage) entre un objet et son propriétaire. Toute donnée générée par l’objet (ou action réalisée) est alors déclarée comme appartenant à son propriétaire (ou étant imputable à celui-ci). Dès lors, le principal enjeu est d’assurer un niveau d’association utilisateur/objet fiable et correspondant aux enjeux métier :

• Niveau d’association requis faible (situation à faible risque) : un employé déclare l’usage d’un système d’identification de présence en salle de réunion ;
• Niveau d’association requis fort (situation à fort risque) : lors de l’achat d’une serrure connectée, un consommateur fournit un numéro de série et code secret à usage unique pour autoriser son application mobile à déverrouiller la porte de son domicile.

Attention néanmoins à trouver le bon équilibre entre l’expérience utilisateur et la sécurité. La robustesse de l’association attendue pourra varier selon la nature des services auxquels le client a souscrit.

3. Phase d’utilisation

La définition des usages des objets connectés est l’étape la plus anticipée par les entreprises mais de nombreux aspects de la sécurité restent négligés. Outre les cas d’usage métier, il convient donc de se poser des questions complémentaires telles que :

• Comment assurer la mise à jour régulière des objets connectés ?
• Quels rôles entre les différents acteurs de l’entreprise pour le maintien de la couche système d’exploitation de l’objet ? de la couche applicative ? du module réseau ?
• Quels besoins de détection et de réaction en cas de compromission d’un objet ?
• Comment tirer parti du SIEM (Security Information and Event Management) et du SOC (Security Operation Center) de l’entreprise pour les incidents de sécurité techniques (compromission logicielle de l’objet) ? pour les incidents de sécurité métier (détournement de l’usage ou vol d’un objet) ?
• Comment maintenir la rétrocompatibilité des protocoles et des API utilisés par différentes versions d’un même type d’objet ?
• Quels modèles de rôles et d’interactions entre les différentes populations agissant sur l’objet ?

Sur cette dernière question, et à titre d’exemple, le schéma ci-dessous illustre la complexité possible des interactions et du modèle de rôle sur un objet tel qu’un véhicule connecté.

Figure 3 – Exemple d’un modèle de rôle et d’interaction avec un véhicule connecté (travaux menés avec l’IMT Atlantique)

4. Phase de revente

La revente est aujourd’hui l’étape la plus négligée lors de la conception d’un objet mais elle n’en reste pas moins critique. Cet événement concerne essentiellement les objets à destination du marché B2C soulevant des enjeux très spécifiques :

• Comment détecter et prendre en charge le cas de la revente d’un objet entre particuliers ?
• Quels principes de privacy-by-design mettre en œuvre pour protéger les secrets et données de l’ancien propriétaire lors d’une remise à zéro d’un objet ?
• Comment supprimer les droits d’accès du précèdent propriétaire à l’objet ?
• Quels moyens pour réinitialiser un objet dans un état stable et intègre avant un nouvel appairage ?

La difficulté majeure concerne la détection de l’événement de revente permettant de déclencher des processus de désappairage objet/utilisateur, de réinitialisation de l’état de l’objet…

Notre expérience nous permet d’identifier certaines circonstances pouvant signaler un changement de propriétaire.

Figure 4 – Exemples d’événements pouvant signaler un changement de propriétaire

Malgré ces exemples, nous constatons que la revente reste un événement complexe à identifier. C’est pourquoi certaines entreprises font tout simplement le choix de ne pas autoriser la revente d’un objet via un contrat de location. L’objet doit dès lors être restitué lors de la résiliation du service ; à défaut il doit être rendu inutilisable. Ce modèle est comparable à celui de la location d’une box Internet auprès d’un FAI (Fournisseur d’Accès Internet).

5. Fin de vie et recyclage

Bien qu’indispensable, nous avons actuellement peu de recul sur cette étape mais les enjeux sont multiples :

• Révoquer les droits accès sur le SI d’un objet en fin de vie ;
• Renouveler l’identité d’un l’objet recyclé ;
• Assurer le remplacement d’un objet défectueux en en réassociant un nouveau avec le même propriétaire et les mêmes données ;
• Détecter l’inactivité d’un objet pour déclencher un remplacement.

Les principaux risques sont la perte de la maîtrise des accès sur le SI de l’entreprise via des identifiants associés à des objets recyclés, la divulgation de données personnelles de l’ancien propriétaire ou encore le surcoût de licence pour des données induites par des objets considérés hors parc.

Une capacité d’action face aux risques variable selon la nature du projet ?

À ce stade de votre lecture vous vous dîtes probablement que cet article vous concerne peu car vous faites l’acquisition de modules ou d’objets connectés préconçus ?

Faux, vous êtes exposés aux mêmes risques ! Même si vous ne faites qu’acquérir ou accueillir des objets connectés au sein de votre SI, adresser l’ensemble des problématiques listées ci-dessus vous permettra d’alimenter le contenu d’un cahier des charges à destination de vos fournisseurs.

En conclusion, quelle que soit la nature de votre projet IoT, il est essentiel de concevoir votre objet en structurant les réflexions autour de son cycle de vie : de sa fabrication à sa mise au rebut. Il faut dès lors, à chaque étape, aborder l’ensemble des thématiques sécurité pertinentes : sécurité réseau / applicative / matérielle, standards, détection et réaction, gouvernance, maintien en condition de sécurité…

Figure 5 – Thématiques de sécurité majeures pour

Cet article Une approche par le cycle de vie pour la sécurité de l’IoT est apparu en premier sur RiskInsight.

Pourquoi le sujet du Records Management nous intéresse-t-il si particulièrement ? Il a grandement gagné en importance ces deux dernières années avec la publication du RGPD (Règlement général sur la protection des données, ou GDPR en anglais). Ce règlement est en réalité une opportunité pour les entreprises de transformer un sujet de conformité en un indéniable atout métier qui doit être traité aux niveaux les plus stratégiques.

Avoir une cartographie des données de l’entreprise, détaillant leurs lieux de stockage, les finalités des traitements associés et les processus auxquels elles sont associées permettra d’améliorer les résultats opérationnels et sera l’une des clés pour améliorer la performance des entreprises.

La première étape de la formalisation du Records Management passe bien évidement la mise en conformité au RGPD. Les actions menées apporteront de la clarté aux métiers sur leurs activités, de l’information sur ce qui doit être protégé au département traitant de la Sécurité, de l’information aux clients sur le traitement de leurs données. Ces derniers n’en seront que plus satisfaits dans un contexte où la transparence et le contrôle de l’information relatif à leurs données sont des facteurs clés de la confiance accordée à l’entreprise et de sa valeur perçue.

Cette cartographie des données sera alors un vecteur pour la réduction des coûts de stockage et de sécurité de l’information. En effet, les informations essentielles et critiques devant être maintenues et protégées seront clairement identifiées et différenciées de celles qui ne le sont pas et ne nécessiteront pas de mécanismes de protection onéreux.

Par où commencer ? Il n’est pas nécessaire de faire appel à une armée d’experts en Records Management pour atteindre les objectifs fixés. Il s’avère que les métiers et leurs employés, ayant acquis un précieux savoir au fil des années sur le fonctionnement de l’entreprise, ses traitements et processus seront les plus grands atouts dans la définition du Records Management.

Trois étapes sont nécessaires pour définir et implémenter une stratégie de Records Management (ou Data Management) pour les entreprises :

1. Créer une politique de Records Management
2. Créer un registre des applications et et des partenaires en usage au sein de l’entreprise (registre pouvant être basé sur le catalogue de services)
3. Implémenter la politique de Records Management sur les applications et services identifiés afin de gagner en efficacité et faire des économies

La politique de Records Management

Chaque métier a des raisons différentes (légales, réglementaires, opérationnelles, etc.) de conserver des archives et ces données. Par exemple, un service client pourrait avoir la nécessité d’enregistrer les conversations téléphoniques à des fins de qualité ou de formation, de la même manière que dans un contexte de transaction financière elle devra enregistrer les conversations téléphoniques de ses employés, pour être en conformité avec la réglementation (MiFID).

La politique de Records  Management devra donc couvrir l’ensemble de ces besoins.

Chaque entité se doit d’être en mesure de préciser les types de données traitées, ainsi que les caractéristiques de son stockage, afin que la politique puisse être construite efficacement suite à des entretiens ciblés avec des responsables métiers expérimentés.

Une fois l’inventaire des différents types d’archivages obtenus, il conviendra de peser les différents impératifs (légaux, réglementaires et opérationnels) pour déterminer la période de rétention adéquate pour chacun des types d’archivages :

• La réglementation impose habituellement une durée minimale (par exemple, l’enregistrement audio des conversations est de 5 ans minimum avec MiFID II) ;
• La législation fixe de son côté une durée de rétention minimale ou maximale (par exemple, la CNIL demande de ne pas conserver les données personnelles plus longtemps que le temps nécessaire au traitement).

La politique de Records Management doit ainsi contenir le type des données archivées, les durées et raisons de rétention.

Le registre des applications et des partenaires

Une fois la politique de Records Management définie, la prochaine étape sera de la décliner sur les différents Systèmes d’Information de l’entreprise. Pour cela, la première brique de cette implémentation sera la construction d’une vue descendante (top-down en anglais) de l’ensemble des applications en service, via une consultation globale des équipes IT, RH, métiers et de sourcing. La revue de ces applications par les équipes Sécurité et de Direction sera alors nécessaire pour deux raisons :

• Vérifier que cette liste est cohérente avec les applications ajoutées dans le radar des équipes Sécurité suite aux demandes des utilisateurs ;
• Donner de la visibilité sur le Shadow IT en usage.

Cette liste finalisée et revue sera alors un ciment solide pour l’implémentation de la politique de Records Management de l’entreprise. L’organisation pourra ainsi tirer parti de la complétude de cette liste pour échanger régulièrement avec les équipes IT, RH, métiers et de sourcing, permettant de réduire le risque de perte de données au travers d’applications ou de partenaires non supervisés.

Il sera par la suite nécessaire de cartographier les systèmes d’information avec les différents types d’archives, leurs impératifs et leurs caractéristiques de rétention afin de pouvoir implémenter la politique de Records Management.

Implémentation de la politique de Records Management

Avoir défini sa politique de Records Management, la cartographie des archives dans le SI n’aura été qu’un exercice de conformité réglementaire si elle n’est pas appliquée par la suite. C’est effectivement l’implémentation de la politique qui apportera toute la valeur ajoutée en termes de performance et d’économies pour l’organisation.

Un exemple parlant est celui des sauvegardes de restauration. Il est possible de définir comme seule finalité pour ces sauvegardes la restauration des données perdues en cas d’incident majeur sur le réseau de l’entreprise. Dans ce cas, il faudra alors décrire dans la politique que la durée de rétention est d’une semaine pour les sauvegardes journalières, pas plus d’un mois pour les sauvegardes hebdomadaires, pas plus d’un an pour les sauvegardes mensuelles, etc. Mettre en place ce type de politique permettra d’économiser énormément d’espace de stockage et apportera de la clarté sur la gestion des sauvegardes aux équipes opérationnelles. Evidemment, il faut en parallèle ségréguer les enregistrements devant rester sauvegardés plus longuement pour des raisons opérationnelles, réglementaires et légales.

Les entreprises n’ayant pas défini de politique de Records Management auront des difficultés à valider les périodes de rétention pour les différents traitements. Elles auront également tendance à définir des périodes de rétention trop longues générant des coûts inutiles et induisant potentiellement un risque légal pour l’entreprise. Pour reprendre l’exemple des sauvegardes de restauration, si ces données sont stockées sans protection (chiffrement par exemple) et volées alors qu’elles n’avaient plus d’intérêt pour leur finalité initiale de restauration, elles seront exploitables par un tiers malveillant et leur divulgation implique divers risques pour l’entreprise.

Une fois l’implémentation de la politique de Records Management lancée, il est recommandé de revoir les diverses stratégies de l’entreprise liées à celle-ci : Sécurité de l’information, juridique, conformité, métier, etc. afin de les aligner et de les compléter grâce à cette nouvelle connaissance sur les données et traitements de l’entreprise. Des bénéfices additionnels pourront en être tirés au-delà du domaine du Records Management : concentration de la sécurité de l’information sur les données sensibles, identification des traitements les plus à risque pour l’entreprise afin de les sécuriser, d’en identifier une alternative moins sensible, voire de les interrompre en cas de fort impact potentiel dû à un manque de conformité.

Les gains que l’entreprise peut espérer d’une stratégie de Records Management claire et formalisée sont maintenant plus évidents : conformité avec les réglementations et lois sur la protection des données, meilleure performance opérationnelle, et actions de sécurité de l’information mieux ciblées. Afin de maximiser ces bénéfices, il est important d’intégrer le juridique, la conformité, la sécurité de l’information et la stratégie métier dans cette initiative : ils créeront les synergies nécessaires à la réussite du projet.

Cet article Comment faire du Records Management un atout pour les entreprises? est apparu en premier sur RiskInsight.