Penser un projet Smart City avec la cybersécurité

Il est fondamental d’intégrer les aspects cybersécurité dès le démarrage d’un projet Smart City. En effet, le réaliser plus tard dans le projet pourra s’avérer plus complexe et couteux, avec le risque de ne pas en traiter / pouvoir traiter tous les risques.

Ceci nécessite de repenser l’organisation du projet vis-à-vis de la donnée et de la gouvernance de la sécurité : les principes de sécurité doivent être définis à l’échelle globale du projet et pris en compte par chacun des sous projets composant la Smart City, en fonction de leurs contraintes. Cela est d’autant plus vrai que les Smart Cities impliquent un grand nombre d’acteurs aux cœurs de métier, aux moyens et à la maturité cybersécurité différents. Une vision globale et partagée est indispensable pour s’assurer que chaque élément traite la donnée avec le niveau de sécurité adéquat.

Il convient ensuite de définir les grands principes d’architecture et d’interopérabilité, selon les contraintes inhérentes à la Smart City, liées à l’Edge Computing et au déploiement d’objets en milieu hostile. La résilience du système doit être au cœur des exigences de sécurité, la chute ou la compromission d’un élément ne devant pas entrainer la chute de la totalité du système.

A cet effet, des standards communs doivent être adoptés, en s’appuyant sur des frameworks spécifiques comme ETSI ou OneM2M. Ces derniers augmentent les chances de maintenir des systèmes interopérables évolutifs. Plus généralement, le NIST ou la norme ISO 27002 sont des référentiels de cybersécurité éprouvés sur lesquels il serait intéressant de s’appuyer.

Le mode de développement doit être agile, en intégrant une vision sur le long terme pour anticiper les nouveaux cas d’usage, et en jalonnant court afin de délivrer rapidement les premiers services. La cybersécurité doit être incluse dans les processus de développement, par la définition d’Evil User Stories, permettant d’identifier et de prendre en compte les risques à chaque évolution des services ou du SI, et par la nomination d’experts cybersécurité dans un rôle de support et de validation.

La définition et le maintien d’un niveau de sécurité satisfaisant passera plus que jamais par l’intégration rigoureuse de la sécurité dans toutes les phases du projet, cela pouvant induire des investissements humain et technologique plus importants mais nécessaires.

Protéger les données critiques et régulées

Etant donnée la propension de la Smart City à collecter et traiter de grandes quantités de données, leur protection passera en premier lieu par l’identification des données et des actifs critiques.

La majorité des services proposés par la Smart City sont à destination des citoyens. Par conséquent, des données identifiantes et ainsi potentiellement sensibles vont être collectées. Par ailleurs, une perte de disponibilité ou d’intégrité de certains services pourront avoir de graves répercussions étant donné que certaines composantes du SI ont une prise directe sur le monde physique. Les Smart Cities n’échappent pas aux réglementations, notamment au Règlement Général sur la Protection des Données (RGPD), mais aussi selon les usages au Référentiel Général de Sécurité (RGS), à la Loi de Programmation Militaire (LPM) ou à la directive européenne Network and Information Security (NIS), dont les exigences en matière de protection des données devront être intégrées dans les programmes.

Des niveaux de classification de la sensibilité de la donnée doivent donc être formalisés afin de permettre la priorisation des actions et la mise en place de cadres de traitement des données critiques adaptés tels que le chiffrement et l’anonymisation.

Le problème de l’accès aux données devra aussi être posé. Les acteurs de la Smart City sont nombreux et il sera nécessaire de segmenter la « vision » qu’ils pourront avoir du SI. Cela passera par une phase préalable de définition des profils d’habilitations, nécessaires au respect du principe de moindre privilège, associée à une revue régulière de leurs affectations afin de s’assurer qu’elles soient toujours légitimes.

Opérer sur des environnements de confiance

Le projet Smart City s’appuiera nécessairement sur différents socles techniques et organisationnels. Si ces socles sont au Système d’Information ce que les fondations sont à une maison, il est aisé de comprendre qu’il sera difficile de bâtir quoi que ce soit si cette base est fragile.

Comme toujours, ces socles techniques doivent être couverts par les mesures fondamentales de la sécurité : mise en place de bulles de confiance, durcissement des systèmes, patch management, sécurisation des comptes à privilèges et de leur usage, etc.

Par ailleurs, un système d’information à la surface d’attaque aussi large que celui de la Smart City devra nécessairement rompre avec le modèle de sécurité traditionnel dit « château-fort », en jouant davantage sur des aspects de cloisonnement et de contrôle d’accès à la donnée elle-même. La conformité des actifs au sein du système d’information devra être évaluée continuellement en s’appuyant sur des référentiels de configuration et de durcissement communs. Les systèmes et applications exposés doivent faire l’objet de contrôles et audits, particulièrement pendant la phase de développement, mais aussi pendant la phase d’exploitation.

Par ailleurs, la continuité et la reprise d’activité devront être au cœur de la stratégie de sécurité. Des plans devront être formalisés, mais aussi testés, incluant à la fois les considérations techniques comme la résilience des différents systèmes, incluant la capacité à restaurer des systèmes indépendamment des autres, mais aussi organisationnelles par la réalisation d’exercices de gestion de crise.

Enfin, la Smart City impliquant un grand nombre d’acteurs, toutes les parties prenantes devraient garantir la mise en œuvre de moyens significatifs dans la protection des systèmes d’information impliqués et se conformer aux exigences de la politique de sécurité du projet. Pour cela, ils devront être engagés contractuellement, à minima par l’inclusion d’exigences de sécurité dans les contrats, mais aussi par la formalisation et la mise en œuvre de plans d’assurance sécurité, notamment pour les prestataires les plus critiques. Des contrôles réguliers pourront être commandités afin de s’assurer du maintien du niveau de sécurité dans le temps et adresser les futurs scénarios de risque.

Détecter, réagir et partager

La Smart City ne peut se passer d’un service de détection et de traitement des incidents de sécurité.

Il conviendra de collecter les traces de l’activité sur les systèmes et rechercher les signaux faibles. Face au nombre important d’évènements à traiter, il sera indispensable de définir les risques dont on souhaite se prémunir et de s’appuyer sur des solutions de corrélation afin de faciliter ces recherches. L’utilisation d’outils d’automatisation permettra d’effectuer un premier tri des faux positifs, facilitant le travail des analystes dans la qualification des alertes de sécurité.

La construction du service de détection et de réaction pourra se faire en s’appuyant sur les référentiels PDIS et PRIS. On pourra au besoin recourir à des fournisseurs externes qualifiés sur ces deux services.

Le recours à des services de Cyber Threat Intelligence apportera un gain important d’efficacité dans la création et l’enrichissement des règles de détection du SOC. En effet, il sera ainsi possible d’adopter une posture de détection proactive en effectuant une veille sur les attaques ayant ciblé des Smart Cities et des modes opératoires utilisés. Ceci présentera également l’avantage d’améliorer l’efficacité du service de réaction par l’économie d’un temps d’investigation précieux.

Enfin, le processus de traitement des incidents de sécurité significatifs et majeurs ne pourra se faire sans la formalisation d’une cellule de gestion de crise, composée d’acteurs aux rôles bien définis et formés à cet exercice. Un point d’attention particulier sera porté sur le dispositif de communication externe, la « gravité » d’une crise dépendant autant de l’événement qui en est à l’origine que de la perception qu’en a le monde extérieur.

En conclusion, et comme nous l’avons vu au travers de ces deux articles, la Smart City est une évolution qui s’impose d’elle-même dans une époque où se mêlent à la fois des enjeux démographiques, écologiques et économiques. Ses promesses sont séduisantes, mais le cadre de mise en œuvre peut susciter certaines craintes.

Comme pour n’importe quelle transformation numérique, la garantie d’un niveau de sécurité en adéquation avec les enjeux du projet passera nécessairement par l’identification des failles et des risques de sécurité qu’elle engendre.

A l’ère des cyberguerres et des cybermenaces, la Smart City devrait être considérée comme un Fournisseur de Service Numérique, au sens de la directive NIS, et être protégée par les mesures de sécurité adaptées à ce statut.

La proposition de services sécurisés, respectueux des données de leurs usagers est une condition sine qua none au succès d’un projet Smart City, dont les bénéfices n’auront d’égal que l’ampleur de l’impact d’une cyberattaque réussie.

Cet article Les enjeux de Cybersécurité autour de la Smart City (2/2) est apparu en premier sur RiskInsight.

« Une ville intelligente et durable est une ville novatrice qui utilise les nouvelles technologies pour améliorer la qualité de vie, l’efficacité des services urbains ainsi que la compétitivité, tout en respectant les besoins des générations actuelles et futures dans les domaines social et environnemental. »,  Institution spécialisée des Nations Unies pour les Technologies de l’Information et de la Communication.

Augmentation de la population urbaine, urgence écologique et transition énergétique, contraintes sur les finances publiques, besoin de réinventer le lien entre le service public et l’usager, augmentation du confort de vie des habitants, etc. : toutes ces problématiques sont autant de défis que la Smart City pourrait contribuer à adresser et qui poussent les collectivités à investir dans cette direction.

Afin de répondre à ces enjeux d’aujourd’hui et de demain, la Smart City va devoir créer une synergie entre différents domaines tels que la gestion intelligente du trafic, le développement de nouveaux modes de transports, l’optimisation de la consommation d’énergie et de la gestion des déchets, la protection des biens et des services, la domotique etc.

Tous ces services pourront être fédérés autour d’un centre de contrôle unique qui assurera une liaison montante et descendante donnant la possibilité de collecter des informations sur l’état des services et/ou d’agir directement sur l’infrastructure.

Une nouvelle cible pour les cyber attaquants

De nombreuses villes en France et dans le monde, se sont emparées du sujet Smart City pour faire face aux défis énoncés précédemment : de grandes métropoles bien sûr, mais également des villes de tailles plus modestes.

En parallèle de ces initiatives, il devient de plus en plus fréquent d’observer des attaques d’origine cyber cibler des villes. A titre d’illustration, en 2019, 22 municipalités américaines ont été victimes de cyberattaques. Les pertes se chiffrent en millions. Le gouverneur de Louisiane est allé jusqu’à décréter l’état d’urgence à la suite d‘attaques contre plusieurs villes de son Etat. Mais ces attaques ne se limitent pas aux Etats-Unis, comme peuvent en témoigner les attaques en France sur les villes de Sarrebourg (Moselle), Sequedin (Nord), Huez (Oisans), La Croix-Valmer (Var) ou encore de Nuits-Saint-Gorges (Côtes-d’Or).

Ainsi, la question est désormais de savoir pourquoi les Smart Cities présentent un nouveau terrain de jeu pour les Cyber Attaques et comment s’en protéger.

La Smart City induit un changement de paradigme

Mener un projet Smart City nécessite de modifier les façons habituelles de procéder par la mise en place d’un système d’information d’un nouveau genre, mêlant de nombreuses problématiques et générant de nouveaux risques en matière de CyberSécurité.

Une architecture complexe

La ville intelligente est en partie caractérisée par la structure nouvelle de son architecture. Son système d’information atypique compile à la fois les contraintes d’un système d’information de gestion, celles d’un système d’information industriel et celles d’un système d’information IoT.

Ainsi, son SI de gestion aura une propension à collecter et traiter un grand nombre de données alors que son SI industriel aura la caractéristique d’être en prise directe sur le monde physique : gestion de l’eau, des feux de circulation, de la signalisation routière variable, de bornes rétractables, de l’éclairage intelligent, pilotage de voitures autonomes, etc. et la conciliation des enjeux de ces deux mondes n’est pas chose facile : là où le monde industriel met traditionnellement l’accent sur la disponibilité, le monde IT se concentrera sur l’intégrité et la confidentialité des informations et des traitements, considérant par ailleurs que la Smart City renforcera la dimension informatique et numérique existante des systèmes industriels.

De plus, il faut considérer la raison d’être d’un système d’information IoT qui est de collecter des données au plus près de leurs sources, par le déploiement d’objets connectés, multiples points d’entrée sur le SI dans des environnements potentiellement hostiles. Par conséquent, ces objets seront exposés unitairement à des attaques physiques contre lesquelles il n’était pas nécessaire ou plus facile auparavant de se prémunir (ex : accès physique à un port série ou USB, remplacement de la mémoire flash, etc.).

Enfin, les systèmes qui composent la Smart City doivent être en capacité d’évoluer rapidement de manière à bénéficier des innovations des acteurs du marché. L’enjeu est de réussir à construire un SI flexible en capacité de pouvoir répondre à des usages encore non identifiés à l’heure actuelle tout en prévoyant des systèmes capables d’être maintenus dans le temps, à l’échelle d’une ville intelligente construite pour des dizaines d’années.

Le paradoxe de l’interopérabilité

Par ailleurs, une démarche Smart City se veut inclusive afin de tirer parti des forces de l’ensemble des acteurs du territoire. Cela induit de gérer des systèmes hétérogènes, mêlant nouvelles et anciennes briques technologiques, et de maitriser l’ouverture de son SI.

La polymorphie des Smart City complexifie la définition de politiques de sécurité globales. Leurs mises en œuvre évoluent parallèlement au développement de nouvelles technologies, rendant obsolètes, ou inapplicables, les politiques de sécurité d’une autre génération. Cette problématique est déjà présente dans le monde industriel depuis des années, où les contraintes opérationnelles font qu’il est parfois impossible de faire évoluer des systèmes devenus vulnérables.

Au-delà de la politique de sécurité, si l’interopérabilité entre des systèmes multigénérationnels permet de développer de nouvelles fonctionnalités créatrices de valeur pour l’usager, elle implique aussi l’utilisation de protocoles disparates pouvant induire des failles de sécurité. Une approche de « sécurité by design » consisterait à identifier le besoin actuel et ses évolutions potentielles, afin d’être capable de proposer un cahier des charges intégrant à la fois les réponses concrètes au besoin fonctionnel mais aussi les clauses de sécurité minimales permettant de déployer le service avec un niveau de confiance satisfaisant. Toutefois, ceci est susceptible de s’opposer au principe d’inclusivité de la Smart City.

L’importance de la donnée

Un enjeu opérationnel et politique

L’information remontée du terrain est d’une importance prégnante parce qu’elle permet de piloter la Smart City : aide aux prises de décisions, communication d’informations aux citoyens, planification d’événements, et évaluation des politiques publiques. Si la donnée en elle-même n’est pas forcément critique, cela n’est plus vrai lorsqu’elle est agrégée dans un ensemble plus large. Des erreurs dans la collecte ou le traitement de la donnée pourront à la fois provoquer des dysfonctionnements opérationnels dans les services ou des choix inadaptées à la conjoncture.

Par ailleurs, la construction de la Smart City est faite par couche. Progressivement, de nouveaux services apparaissent et se développent. Historiquement silotés, la tendance est à la recherche de synergies entre les différents services pour créer toujours plus de valeur ajoutée pour l’usager. Ces interconnexions grandissantes et cette superposition induisent une complexité telle qu’en cas de panne, il existe un risque, si l’on n’y prend pas garde, de voir l’ensemble de l’infrastructure s’écrouler, par propagation de l’erreur, ou parce que chaque service est devenu dépendant des autres.

La sécurité: une demande qui émane des citoyens eux-mêmes

Elabe et Wavestone ont réalisé une enquête qualifiant l’importance de la donnée dans les services publics de demain, et sur les enjeux auxquels devront faire face les parties prenantes de tels projets.

Parmi ces enjeux réside l’utilisation qui est faite de la donnée à caractère personnel de l’usager. Globalement, les citoyens sont favorables à l’idée de la transformation numérique des services publics, et à fortiori à la Smart City en tant que service public, mais restent soucieux de la finalité des traitements de leurs données.

Cependant, une part non négligeable de la population, soit entre 30% et 50% n’est pas favorable à la cession de ses données même si cela pourrait permettre de faire des économies, gagner du temps ou réduire son empreinte carbone. Cela pourrait être dû au fait que 76% de la population interrogée estime que l’administration n’est pas apte aujourd’hui à assurer la sécurité des données qu’elle collecte.

Le succès de la Smart City réside donc aussi dans la capacité des parties prenantes à rassurer les usagers sur l’usage et la protection de leurs données.

Ainsi, nous avons vu que la Smart City induisait un changement de paradigme qui, associé aux fortes attentes du grand public sur la sécurité de ses données, nécessitait d’adapter son approche. En effet, à mesure que la Smart City se développe, l’activité urbaine devient de plus en plus dépendante de ses services, accroissant d’une part ses besoins de sécurité, mais aussi l’intérêt que lui porte les cyber attaquants. Fort de ces constats, l’enjeu sera donc d’identifier quelle démarche mettre en œuvre pour prendre en compte les risques de Cyber Sécurité et, à défaut de les supprimer totalement, les réduire. Nous vous en parlerons dans un second article.

Cet article Les enjeux de Cybersécurité autour de la Smart City (1/2) est apparu en premier sur RiskInsight.

Différentes contraintes à prendre en compte pour assurer le succès d’un projet

Tout au long de la vie du projet, la prise en compte des contraintes du run doit tendre à s’affiner au fur et à mesure que se précise la vision de la cible attendue. De cette analyse doit alors découler un plan d’actions permettant d’anticiper la future arrivée en production du projet et d’y préparer les équipes de run.

Cette attention est déterminante dans le succès d’un projet informatique et surtout dans la pérennité de son exploitation car c’est un prérequis indispensable :

• Dans l’identification des sujets centraux du transfert de connaissance vers les équipes de run ;
• A l’acquisition de toutes les compétences requises pour la bonne exploitation du futur système par ces mêmes équipes ;
• A la définition de modalités de « service management » claires et partagées.

Impliquer les équipes de run : clé de réussite du passage du build au run

Bien sûr, le passage du build au run se prépare à travers une bonne documentation du projet – et de préférence une documentation validée par les équipes d’exploitation –, par la définition et/ou la contractualisation de services auprès de l’exploitant, par l’implémentation d’une matrice de rôles et responsabilités claire et complète et enfin par la mise en œuvre progressive de processus de gestion des incidents, des demandes et des changements.

Cependant, le véritable succès de ce transfert des équipes de build vers les équipes de run réside aussi – et surtout – dans l’implication des équipes de run dès la phase de design du projet afin d’influer sur l’architecture du système, d’améliorer le coût de son cycle de vie et de prévenir les risques liés à son exploitation.

Mais comment impliquer les interlocuteurs du run dans le projet ? Sachant que les équipes de build et celles de run sont généralement issues de direction différentes. Qui est supposé diriger qui ? Qui est force de décision sur le projet ? À quel moment se fait la bascule du pouvoir de décision ?

Quelques bonnes pratiques de DSI pour mobiliser les équipes de run

Autrefois, la réponse d’une DSI à l’implication du run dans le projet passait par la désignation d’un ou plusieurs interlocuteurs privilégiés au sein de ces équipes de run. Ces « référents » avaient en charge d’assurer la coordination avec les équipes de build et d’acquérir dans le même temps toute la connaissance projet. Mais très vite, ces collaborateurs devenaient des points de contention, leur implication créant un problème de gouvernance récurrent : qui les pilote ?

Aujourd’hui, d’autres réponses émergent. Parmi les plus judicieuses, résident notamment :

• La création d’équipes projet « mixtes », composées autant de personnes venues du build que de personnes venues du run  et détachées sous une direction unique ;
• La création d’instances de gouvernance autour de l’architecture impliquant à la fois les responsables de run et du build pour assurer la prise en compte des contraintes d’exploitation dès la phase de design du système ;
• La réalisation de Proof of concept (POC) pour éprouver les modalités de service management : l’ensemble de mon processus est-il clairement maîtrisé et connu de tous ? Les différentes parties prenantes sont-elles bien définies et en capacité de réaliser leurs actions ?. Ce POC permet également de faciliter la montée en compétences des interlocuteurs de run sur la prise de décision : quoi faire et dans quel cas ?
• La mise en œuvre de périodes probatoires à l’issue de la mise en production pendant lesquelles les équipes de run prennent progressivement la responsabilité du système tout en conservant un support des équipes de build ;
• La mise à disposition de socles normalisés portés par des offres de services standardisées permettant d’inverser le problème : il n’appartient plus au run de répondre aux exigences du build. Au contraire, il devient de la responsabilité du projet de s’inscrire dans les standards d’exploitation définis.

Quelles que soient les approches adoptées, celles-ci visent toutes le même eldorado : trouver le parfait équilibre entre objectifs du build et contraintes du run… et ainsi assurer la réussite totale du projet !

Cet article Le passage du build au run : un sujet trop souvent négligé ? est apparu en premier sur RiskInsight.

Qu’attend-t-on d’un architecte aujourd’hui ?

L’architecture d’entreprise est l’art de construire des représentations simples, complètes et opérantes, supports à la prise de décision managériale dans des contextes de mise en œuvre de SI.

L’architecte a donc pour objectif de ramener de l’ordre dans le chaos et de résoudre des problèmes de conception dans des environnements complexes. Il est le garant de la cohérence  du SI et de son environnement, ce qui l’amène à appréhender des problématiques aussi bien techniques qu’humaines.

Pour ce faire, il doit pouvoir combiner la méthodologie et la rigueur de l’ingénieur (savoir-faire d’expert) avec des compétences que l’on attribue traditionnellement à la filière managériale : orientation client (appréhension des dimensions culturelle, politique et commerciale des problématiques) ainsi que leadership et communication (l’architecte doit savoir s’adresser tantôt à un spécialiste technique tantôt à un décideur).

La combinaison de ces compétences requiert des « aspirants architectes » une disposition d’esprit que la formation saura aiguiser !

Quelle est l’offre de formation en France ? Est-elle suffisante ?

L’acquisition des compétences requises se heurte à la rareté de l’offre de formation :

• L’offre de formation initiale est assez limitée : si certains cursus ingénieurs abordent la question de l’architecture dans sa globalité, le plus souvent, seules des notions techniques se rapportant au métier d’architecte sont traitées. Elles sont rarement mises en perspective comme participant à une fonction clé de la DSI de demain. Au global, le marché français ne doit pas sortir plus de 50 jeunes architectes bien formés par an !
• L’offre de formation continue est un peu plus riche mais est dominée par un grand nombre de formations de « sensibilisation » courtes, au contenu très hétérogène et au niveau technique douteux. Il existe néanmoins quelques formations solides à l’instar du CESAMES ou d’autres cursus, principalement intra-entreprise (Thales, IBM, etc.), qui se déclinent sur la durée, généralement 1 an, avec un accompagnement tout au long du parcours.

Finalement, n’est-ce pas plus simple de former des collaborateurs prédisposés ?

Oui, le développement de la formation continue reste le moyen le plus efficace à disposition des entreprises pour faire émerger des profils « architectes » au sein de leurs équipes. Cela passe par deux actions clés : détecter parmi les collaborateurs les architectes en devenir et se doter de parcours pour assurer leur montée en compétence.

Qui plus est, cette approche permet d’alterner des cours théoriques avec des séquences de mise en pratique au sein de l’entreprise.

D’ailleurs, le défi en matière de gestion des carrières pousse à revenir sur deux idées reçues :

• la mobilisation en tant qu’architectes de profils juniors n’est pas aberrante : leur manque d’expérience peut certes dans un premier temps limiter leur capacité à aborder des problématiques complexes, mais ils peuvent progresser s’ils sont bien accompagnés !
• le recours au marché reste un moyen de palier ponctuellement au manque de ressources internes ; cela constitue même une opportunité non négligeable pour accélérer la montée en compétence de ses propres équipes.

Une chose est sûre : les entreprises doivent aujourd’hui prendre en considération cette ressource incontournable qu’est devenu l’architecte. À elles de s’en donner les moyens.

Cet article DSI : formez des architectes ! est apparu en premier sur RiskInsight.