However, they are also facing increasingly stringent measures under new regulations such as the General Data Protection Regulation (GDPR), which covers all personal data, or the various new regulations on the protection of critical national infrastructures. France is in the vanguard of this activity with its Military Programming Act which applies to the organizations classed as “most critical” in terms of the country’s functioning.

But how can you put in place increasingly sophisticated detection systems, while, at the same time, complying with an ever-stricter regulatory framework?

SOCs ARE BEING STANDARDIZED AT THE EUROPEAN LEVEL—AND GLOBALLY

In the mid-2000s, the implementation of the first SOCs consisted, for the most part, of deploying log collectors based on geographical hubs and the setting up of a central alert management system. However, recent regulatory changes may require modifications to architecture. In France, in particular, within the context of the Military Programming Act, the requirement to set up a “system of log correlation and analysis” (i.e. a SOC equipped by a SIEM system) has been accompanied by a strict regulatory framework, which is set out in its PDIS (Security Incident Detection Service Providers) Requirements Reference Document.

In terms of standardization, this addresses three points in particular:

• First, the framework for surveillance: there is now an obligation to detect certain types of common attacks and implement controls, following recommendations made through audits carried out by qualified bodies, in accordance with the PASSI (Cybersecurity Audit Service Providers) Reference Document. Companies must also put in place a permanent surveillance unit to notify ANSSI (the French national agency for information system security) in the event of an IS being critically compromised.
• The second area addresses the securing of the SOC’s assets: new security measures described in the PDIS Requirements Reference Document demand, in particular, more robust measures for SOC operators and administrators (two-factor authentication, limitations on internet access, etc.). These security measures will be verified by ANSSI through audits, or retrospectively, following the compromise of an IS being notified to it.

Finally—the architecture—where there’s a requirement for greater complexity: partitioning into trust zones and an enlargement to the perimeter of the monitored network are introduced (going beyond the traditional scope of equipment under security surveillance: business servers and handheld devices must also now be monitored). Information related to security incidents (events, analysis reports, and their associated notifications) must also now be retained for as long as the service is provided.

STRONG SECURITY AND CAREFUL HANDLING OF PERSONAL DATA: INCOMPATIBLE GOALS?

To carry out retrospective analyses and, in particular, to determine the origin of cyber-attacks, a good deal of personal and critical data must be collected, stored, and exploited. However, this data is covered by the GDPR, which tends to limit its collection and use.

Google’s recent fine by the AGPD (Spain’s personal data protection authority) highlights the types of issue that a SOC may encounter regarding the processing of personal data:

• Google’s obligations in the processing of personal data and the user’s right to be forgotten were the prime causes of Google’s penalty. In fact, the GDPR intends to offer European citizens the option to access, modify, or delete their data wherever it is stored (including in the cloud). This means that, in practice, companies must know exactly what data is being collected by their SOC, so that they can inform their customers, employees, etc. accordingly—and offer them the option of having it removed at any time. Having said that, the GDPR seems to indicate that preservation of some data is acceptable, where this is necessary for the protection of companies. The details of exactly how this provision will operate are expected to be worked out over the next few years.
• An obligation of transparency with respect to the exploitation of data is the second issue that the AGPD’s action raises. Yet, for PDISs, the obligation to monitor a wide range of equipment gives rise to the collection of a large and varied amount of data. The content of logs will therefore have to be addressed to ensure that only the data needed for security-monitoring activity is collected.
• Finally, the GDPR imposes a requirement to justify the preservation of the data. Yet, PDIS requirements are for data to be kept for at least six months, in order to have the ability to carry out long-term or retrospective analysis; this creates regulatory uncertainty: how far can a company go in ensuring the protection of its IS?

Looking beyond the example of Spain, it’s instructive to compare the different legislative approaches to the notification of incidents. Those dedicated to the protection of personal data target rapid notification in order to limit the impacts on people’s lives; while legislation concerning the protection of critical infrastructure requires limited and highly confidential notifications in order to allow sufficient time for incidents to be correctly managed, without revealing to an attacker the fact that they have been discovered. In the end, the GDPR took into account this type of scenario, but that’s not to say that other texts won’t result in contradictory obligations.

A STRICT—BUT BENEFICIAL—REGULATORY FRAMEWORK

The tightening of the regulatory framework for SOCs, whether direct (via PDIS requirements) or indirect (through the GDPR), will result in a transformation of the IS ecosystem. New types of profiles could thus be integrated into teams, such as the Data Privacy Officer (DPO), which the SOC could consider as a key player in maintaining its long-term compliance.

In addition, these regulations will raise maturity levels among the players who have to comply with them, as well as among those who draw inspiration from them. Already, there are numerous moves toward compliance involving SOC architecture, as well as its processes and governance.

In complying with the regulations, tools also count—and that means looking at innovations such as data-based surveillance (with Data Leakage Prevention [DLP] tools), which can help ensure compliance with respect to the protection of sensitive data.

TOWARD MORE REALISTIC REGULATIONS…

The value of the requirements for many organizations, both as standards and objectives to be met, cannot be disputed.

While the bar may seem high, and regulatory inconsistencies remain, one thing is for sure: the next round of regulatory updates will provide a solid framework for the design and improvement of SOC.

Cet article The SOC – a department undergoing a full regulatory overhaul 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.