Cependant, de nouvelles réglementations le soumettent à des contraintes de plus en plus fortes telles que le GDPR (General Data Protection Regulation) visant toutes les données à caractère personnel, ou les différentes lois sur la protection des infrastructures critiques des pays. La France est particulièrement en avance aujourd’hui avec la LPM (Loi de Programmation Militaire [lien EN / lien FR ]) qui s’applique aux organisations les plus critiques pour le fonctionnement de l’Etat.

Comment mettre en place un système de détection de plus en plus fin, tout en s’inscrivant dans un cadre réglementaire toujours plus strict ?

Une standardisation des SOC à l’échelle européenne (et mondiale)

Au milieu des années 2000, la mise en place des premiers SOC consistait, dans la plupart des cas, à déployer un collecteur de logs par plaque géographique et à mettre en place une gestion des alertes en central. Cependant, des évolutions réglementaires récentes peuvent imposer des changements d’architecture. En particulier en France dans le cadre de la LPM, l’obligation de mise en place d’un « système de corrélation et d’analyses de journaux » (autrement dit : SOC outillé par un SIEM) s’est accompagnée d’une structuration règlementaire stricte décrite dans le référentiel d’exigences PDIS (Prestataires de Détection des Incidents de Sécurité [lien FR]).

Trois points sont traités en particulier pour la standardisation :

• D’abord, l’organisation de la surveillance : il existe dorénavant une obligation de détection de certains types d’attaques communes et d’implémentation de contrôles faisant suite à des recommandations réalisées via des audits qualifiés suivant le référentiel PASSI (Prestataires d’Audit de la Sécurité de Systèmes d’information [lien EN / lien FR]). L’entreprise doit également mettre en place une cellule de veille permettant de notifier l’ANSSI en cas de compromission du SI d’importance vitale.
• Le second point concerne la sécurisation des actifs du SOC : de nouvelles mesures de sécurisation décrites dans le référentiel de qualification PDIS imposent notamment un durcissement des postes des opérateurs et des administrateurs du SOC (authentification à deux facteurs, limitations des accès à internet…). Ces mesures de sécurité seront vérifiées par l’ANSSI via des audits ou rétroactivement suite à la notification de compromission du SI.
• L’architecture enfin, avec une complexification de celle-ci : un découpage en zones de confiance cloisonnées ainsi qu’un élargissement du périmètre du réseau surveillé sont imposés (outre les « classiques » équipements de sécurité, les serveurs métiers et les terminaux mobiles doivent maintenant aussi être surveillés). Les informations liées à un incident de sécurité (événements, rapports d’analyses et les notifications associées) doivent également être conservées pendant toute la durée de la prestation.

Sécurisation forte et respect des données personnelles : 2 enjeux incompatibles ?

Afin de pouvoir assurer des analyses a posteriori et notamment d’être capable de déterminer l’origine des cyberattaques, de nombreuses données personnelles et critiques doivent être collectées, conservées et exploitées. Pourtant, ces données sont soumises au GDPR qui tend à l’inverse à limiter leur collecte et leurs usages.

La récente amende de l’AGPD (l’autorité de protection des données à caractère personnel en Espagne) à Google met en lumière des problématiques que pourrait rencontrer le SOC concernant le traitement des données à caractère personnel :

• Le droit à la manipulation des données personnelles et le droit à l’oubli des utilisateurs a été la première cause de condamnation de Google. En effet, le GDPR compte offrir aux citoyens européens la possibilité d’accéder, de modifier ou de supprimer leurs données où qu’elles soient stockées (y compris dans le Cloud). Cela signifie, en pratique, que l’entreprise doit connaître exactement la teneur des données collectées par son SOC pour pouvoir en informer les clients, ses employés… Cela signifie également que ceux-ci devraient pouvoir exiger leur suppression à tout moment. Cependant, le GDPR semble indiquer qu’il est possible de conserver certaines données si celles-ci sont nécessaires à la protection des entreprises. Cette définition est appelée à être discutée dans les années à venir.
• L’obligation de transparence quant à l’exploitation des données est la seconde problématique soulevée par l’AGPD. Cependant, dans le cadre de PDIS, l’obligation de monitorer une grande variété d’équipements va engendrer la récupération d’un grand nombre de données de natures différentes. Un travail sur le contenu des logs collectés va donc être nécessaire afin de s’assurer que seules les données nécessaires à l’activité de surveillance sécurité sont récupérées.
• Enfin, le GDPR impose la justification de la conservation de la donnée. Or PDIS impose de conserver les données sur au moins six mois afin de pouvoir effectuer des analyses sur du long terme ou rétroactivement créant ainsi un flou législatif : jusqu’où peut-on aller pour assurer la protection de son SI ?

Au-delà du cas Espagnol, il est intéressant de noter les approches des différents textes sur la notification des incidents. Ceux dédiés à la protection des données à caractère personnel ciblent une notification rapide pour limiter les impacts sur la vie des citoyens, quand les textes sur la protection des infrastructures critiques eux imposent des notifications limitées et très confidentielles pour prendre le temps de gérer correctement l’incident sans révéler à l’attaquant le fait qu’il a été découvert. GDPR a finalement prévu ce cas de figure mais d’autres textes pourraient également être contradictoires.

Un cadre réglementaire strict mais bénéfique

Le durcissement du cadre réglementaire pour le SOC, que ce soit direct (PDIS) ou indirect (GDPR), va engendrer une transformation de l’écosystème. De nouveaux profils pourraient ainsi s’intégrer aux équipes comme le DPO (Data Privacy Officer) que le SOC pourrait considérer comme un acteur clé pour maintenir sa conformité dans la durée.

De plus, ces réglementations vont tirer vers le haut les niveaux de maturité des acteurs soumis à ces référentiels ainsi que de ceux s’en inspirant. D’ores et déjà on observe de nombreux chantiers de mise en conformité touchant tant à l’architecture du SOC qu’à ses processus et sa gouvernance.

Pour satisfaire aux réglementations, l’outillage compte également, et il faut jouer avec les innovations telle que la surveillance orientée sur les données (avec de l’outillage de type Data Leakage Prevention – DLP), qui peut aider à la mise en conformité sur la protection des données sensibles.

Vers des réglementations plus réalistes…

L’apport des référentiels est indéniable, en tant que standard et en tant que cible à atteindre pour nombre d’organisations.

Si la barre peut sembler haute, ou que l’on trouve encore quelques incohérences entre les différents textes, on peut gager que les prochaines révisions apporteront un cadre solide pour la conception et l’amélioration des SOC.

Cet article Le SOC, un service en pleine mutation réglementaire est apparu en premier sur RiskInsight.

Une multitude de textes

La liste est longue, c’est pourquoi il conviendra de s’appuyer sur le (ou les) référentiel(s) le(s) plus adapté(s) : secteur, niveau de criticité de son installation. À ce titre, le CLUSIF, par l’intermédiaire du groupe de travail sur la sécurité des systèmes industriels, animé notamment par Solucom, a publié un panorama des référentiels en la matière. Pas moins d’une cinquantaine de documents ont été analysés et des fiches de lecture permettent d’en avoir une vision synthétique. Les documents ont été répertoriés et catégorisés : des plus introductifs aux plus exhaustifs, allant de quelques pages à plus d’un millier, le guide du CLUSIF précise à quels lecteurs ils sont le plus adaptés (filières SSI ou SII, concepteur/intégrateur/mainteneur).

Les objectifs de ces référentiels sont multiples. Ils peuvent être utilisés comme un véritable outil pour réaliser des audits de sites, définir sa stratégie et les actions associées ou plus simplement évaluer son degré d’alignement et de conformité au standard retenu. De tous, l’IEC 62443 est sans doute le référentiel le plus connu du milieu et propose de nombreux guides qui tentent d’adresser l’ensemble des pans de la sécurité de ces SI. L’ISO a également apporté sa pierre à l’édifice avec la récente norme ISO 27019.

Les États publient également des guides nationaux. Au Royaume-Uni, le CPNI (Center for the Protection of National Infrastructure) propose plusieurs guides thématiques autour de la sécurité des SI industriels. Aux États-Unis, plusieurs entités (DHS, DoE…) ont élaboré des guides sectoriels. Enfin en France, l’ANSSI a également publié ses propres guides.

Certains secteurs ont apporté une réponse propre à leurs spécificités respectives comme l’AIEA qui propose son guide pour les installations nucléaires ou encore le NERC CIP qui oblige les différents opérateurs électriques à être conformes à ses standards.

La réglementation : arme d’amélioration massive de la sécurité ?

Cette abondance de littérature montre qu’il n’y a pas de réel consensus en la matière aujourd’hui. De plus, l’application des bonnes pratiques édictées dans ces documents ne reste finalement qu’un acte de volontariat de la part des entités concernées. Comme cela est souvent le cas, l’adoption de pratiques généralisées passe par la mise en place d’une réglementation (SEVESO par exemple). Et c’est bien ce qu’envisage l’État français au travers de la LPM (Loi de Programmation Militaire) : rendre obligatoire l’adoption de certaines mesures de cybersécurité pour les OIV.

Mais ces avancées françaises ne doivent pas faire oublier la nécessité d’une approche plus globale, a minima européenne. En effet, au-delà des mesures organisationnelles et techniques, La LPM prévoit également le recours à des produits labellisés. Il ne s’agit là que d’un schéma franco-français. Les efforts requis pour obtenir cette labélisation peuvent apparaître comme un frein pour des constructeurs/éditeurs à portée internationale. Avoir une reconnaissance européenne ou internationale de la sécurité de leur produit est donc un élément déterminant et qui aboutira à un réel retour sur investissement.

Dans ce domaine, des directives européennes sont également attendues, en particulier celle dédiée à la sécurité des réseaux et des infrastructures (NIS). Elles légitimeront davantage les initiatives sur le territoire français. L’ENISA a d’ailleurs publié les bases d’un schéma de certification de la sécurité des Smart Grid à portée européenne. Avec une approche progressive, ce que tend à faire l’État français, la réglementation obtiendra l’adhésion des industriels. La tendance va vers une adaptation des mesures avec une personnalisation opérateur par opérateur sans pour autant s’éloigner d’une cible ambitieuse. La publication prochaine des décrets d’application, puis des arrêtés de la LPM, permettra de le vérifier.

Enfin, pour ceux qui ne sont pas immédiatement concernés en tant qu’opérateur critique, nul doute qu’ils bénéficieront de l’élan global de ces démarches et pourront bien évidement s’en inspirer en complément des guides, normes et standards déjà existants.

Cet article Normes, standards et réglementations : de réels leviers pour la sécurisation des SI Industriels ? est apparu en premier sur RiskInsight.

La standardisation est l’une des caractéristiques du Cloud. Si l’entreprise veut en tirer tous les bénéfices, opérationnels comme économiques, elle doit accepter et faire accepter aux utilisateurs un degré de standardisation important. Le déploiement du Cloud en entreprise implique un changement de posture pour la DSI et une évolution radicale dans les mentalités, au sein des équipes informatiques comme du côté des Métiers.

Le challenge principal pour les équipes de maîtrise d’ouvrage et de conception du SI va avant tout être de trouver le bon point d’équilibre entre les besoins de personnalisation des services Cloud et le niveau de standardisation imposé par les fournisseurs.

En outre, les équipes informatiques vont devoir apporter toute leur expertise pour mettre en cohérence des Clouds multiples et ainsi former un SI homogène. Bien qu’habituées à des environnements complexes, elles devront également intégrer un cadre moins flexible qu’auparavant.

Faire évoluer les fonctions techniques

Avec le développement du Cloud, la spécialisation des compétences est de moins en moins d’actualité : la tendance est au profil multi-généraliste. On le voit par exemple avec la mise en place de services SaaS, comme la bureautique et la messagerie : le besoin d’experts techniques sur ces périmètres auparavant internalisés est de plus en plus faible.

Avec un SI hybride, intégrant des services Cloud et des composants hébergés en propre, la coordination technique devient un enjeu majeur. Ce sera tout particulièrement le cas sur des actions opérationnelles comme la mise en œuvre des changements ou la résolution des incidents. La présence de ces profils techniques, capables de comprendre ce SI multi-facettes et de coordonner les fournisseurs, constituera même très vite un impératif pour la DSI.

On assistera aussi à la montée en puissance de profils techniques très spécifiques, conséquence directe de l’évolution de l’architecture du SI dans le contexte Cloud. Les compétences d’intégration technique des SI (architecture, orchestration, intégration de données, etc.) vont ainsi être amenées à se développer, avec un objectif clé : garantir la cohérence du SI. Des compétences sécurité (fédération d’identité, gestion des habilitations) vont également se développer.

Renforcer les fonctions de management des services

Le phénomène d’externalisation, croissant ces dernières années, a poussé au développement de compétences de pilotage des activités externalisées, mais aussi à une réduction de la prise en charge en interne des activités opérationnelles de la DSI (production, développement…).

Cette transition du « faire » au « faire faire » est encore plus marquée dans un contexte Cloud, où le niveau de standardisation requis va imposer à la DSI d’industrialiser encore plus ses activités. Les démarches de définition et de mise en place de services et de lignes de services ont conduit à l’apparition de fonctions de type « Service Manager » ou « Service Delivery Manager », dont le rôle est de coordonner la production du service et sa bonne fourniture au client.

Ces rôles doivent fortement se renforcer sur le pilotage des volumes consommés afin d’accompagner avec proactivité les clients dans la gestion de leur demande. De cette manière, les service managers peuvent être responsabilisés sur l’équilibre économique de leur service et plus seulement sur les engagements de qualité de service et de performance opérationnelle.

Anticiper dès aujourd’hui les impacts RH du Cloud

Il est crucial de bien accompagner la transition des compétences associées aux externalisations croissantes induites par le Cloud. Une méthode classique consiste à mettre en place une démarche de Gestion Prévisionnelle des Emplois et Compétences (GPEC), aussi connue sous le nom de Talent Management.

Pour analyser l’impact RH lié au Cloud, les DSI doivent justement se doter d’une véritable cartographie de ces emplois et compétences. Les déformations RH provoquées à court terme par les décisions connues en matière de Cloud peuvent ainsi être évaluées et faire l’objet de plans d’actions de redéploiements optimaux.

Par ailleurs, une identification des impacts potentiels à moyen / long terme doit être réalisée. Elle permet d’évaluer les plans d’actions RH et management à dérouler en matière de mobilité, formation, gestion de carrière et objectifs. Autant de transformations à prendre en compte.

Cet article Cloud : une nécessaire transformation des compétences et des pratiques est apparu en premier sur RiskInsight.

Une adoption motivée par réduction des coûts et recherche d’agilité

Malgré la dynamique du marché et la promesse de gains sous-jacente, les DSI des grandes entreprises tardent à se mettre en mouvement, réagissant plus au Cloud qu’elles ne l’anticipent. Elles le privilégient essentiellement pour des usages à risques techniques limités et à ROI rapide, principalement en IaaS et en SaaS.

SaaS : une utilisation massive des services standardisés

Le SaaS est aujourd’hui le principal vecteur d’adoption du Cloud. L’adoption du SaaS est centrée sur les fonctions support dont l’usage est standardisé (bureautique, messagerie, CRM, paie…). Le SaaS est également fortement sollicité pour les services de sécurité (antivirus, proxy, services de tests d’intrusion…) qui nécessitent une puissance de calcul importante, des évolutions en cycle court ainsi qu’une disponibilité maximale pour des employés de plus en plus mobiles.

PaaS : une adoption encore confidentielle

C’est le segment le moins bien appréhendé par les grands groupes aujourd’hui. Il correspond à la fourniture d’une plateforme d’exécution de code informatique. Il permet la mise à disposition d’une application en limitant très fortement les opérations sur les couches sous-jacentes (systèmes, bases de données, serveurs d’applications…). Le PaaS reste aujourd’hui cantonné chez les grands comptes à des usages « jetables », comme des prototypes ou des sites web temporaires (événementiels).

IaaS : des déploiements essentiellement en mode « privé »

Le modèle IaaS, fourniture de machines virtuelles (VMs) et ressources associées depuis un Cloud, qu’il soit public ou privé, permet d’introduire davantage d’agilité. Les grandes entreprises déploient aujourd’hui beaucoup de IaaS privés, dans l’optique de capitaliser sur leurs compétences internes et leurs investissements en infrastructures. De son côté, le IaaS public est mis en œuvre de façon très ciblée, par exemple pour une filière web, ou dans une logique de « bac à sable ».

Pour autant, grâce à la consolidation à grande échelle, c’est le modèle public qui permet d’obtenir les gains fonctionnels et financiers les plus importants. C’est pourquoi les stratégies de déploiement de IaaS privés sont ou doivent être considérés comme une étape sur une trajectoire plus ou moins long terme de généralisation d’IaaS public.

Un avenir qui promet plus d’innovation et de valeur ajoutée

La 1ère phase d’adoption du Cloud est motivée par la recherche d’économies et l’optimisation du niveau d’agilité. Ces prochaines années, le marché devrait évoluer pour offrir des solutions avec une valeur ajoutée de plus en plus forte, pour répondre à la fois aux offreurs en quête de relais de croissance et aux entreprises utilisatrices souhaitant optimiser leur marge en se recentrant sur leur cœur de métier.

Le SaaS devrait s’imposer dans les entreprises comme le choix par défaut. Les éditeurs de logiciels vont proposer de manière systématique leurs solutions en mode SaaS, en partenariat avec les fournisseurs IaaS. Ils s’assureront ainsi des revenus constants et proposeront à leurs clients des services très industrialisés, flexibles et au meilleur coût.

L’usage du PaaS devrait exploser lorsque les problématiques de portabilité des applications, bien souvent surestimées, seront résolues. Il devrait alors devenir le socle d’exécution par défaut de toutes les applications qui ne seraient pas consommées en SaaS. Ces plateformes vont s’enrichir pour fournir aux développeurs un maximum d’accélérateurs et de nouvelles possibilités (composants et connecteurs pré-packagés, services de sécurité, réseaux de distribution de contenus… ) et donc en faire un choix par défaut dans les filières de développement.

Par ailleurs, les éditeurs de progiciels devraient rapidement proposer leurs solutions en mode pré-packagé pour les plateformes PaaS du marché. Le IaaS devrait perdurer pour adresser des besoins applicatifs très spécifiques. Mais il ne permettra pas d’aller chercher toutes les économies d’échelle d’une approche Cloud.

 Ce sont le SaaS et le PaaS qui porteront le marché demain.

Cet article Le Cloud : quelle réalité marché derrière les nuages ? est apparu en premier sur RiskInsight.