Nous poursuivons ici avec quelques questions – et réponses – complémentaires pour approfondir le sujet.

Combien de rôles dois-je créer ? Combien de rôles chaque utilisateur doit-il avoir ?

Il peut être tentant de concevoir un modèle qui permet de traiter l’ensemble des cas d’usage relevés lors d’une phase de collecte des besoins. Il faut toutefois avoir en tête que le modèle devra vivre et évoluer en fonction des nouvelles applications, des nouvelles unités organisationnelles…

Il n’y a pas de règle générale sur le nombre de rôles à attribuer à chaque utilisateur. Il est parfaitement envisageable de construire son modèle pour n’attribuer qu’un seul rôle par utilisateur, comme il est possible d’en attribuer plusieurs.

Il faut néanmoins trouver un compromis entre la création de rôles trop spécifiques, qui font vite tomber dans le « 1 rôle pour chaque utilisateur », et la création de rôles trop généraux qui n’apportent pas grand-chose et qui entraînent de la surallocation de droits.

Viser 80% de droits attribués via le modèle de rôles et 20% de droits discrétionnaires s’avère déjà un bel objectif.

Bottom Up ou Top down, quelle méthode adopter ?

Deux grandes méthodes sont envisageables lors de la création d’un modèle d’habilitation.

L’approche « Bottom Up » consiste à partir des droits existants et à les analyser pour en déduire un modèle. Par exemple, si tous les collaborateurs du service Comptabilité disposent des mêmes droits, on peut alors créer un rôle dédié à ce service qui contiendra les permissions correspondantes. Dans cette approche, la qualité des données est un prérequis à une modélisation réussie. De mauvaises attributions de droits viendraient en effet ajouter du bruit dans la modélisation et en réduire la pertinence.

L’approche « Top Down » commence par définir le modèle d’habilitation théorique, sur lequel on vient ensuite projeter les habilitations nécessaires. Ainsi par exemple, on peut créer un rôle pour le service Comptabilité et y inclure les permissions que des représentants Métier jugent nécessaire pour accomplir ses missions.

Dans les faits, il est courant d’adopter une approche intermédiaire.

Il est par ailleurs recommandé de travailler de manière itérative, et de valider son approche sur un périmètre pilote avant généralisation. L’implication du Métier dans la définition et la validation de la composition des rôles joue ici un rôle capital.

Comment m’outiller ?

La volumétrie conséquente de droits à traiter et les multiples itérations nécessaires impliquent l’utilisation d’un outillage qui peut être issu du marché ou bien développé en interne (tableaux Excel, base de données, scripts…). Une analyse préalable des besoins doit permettre de s’assurer de l’adéquation de cet outillage.

Au-delà des capacités de création de rôles ou de règles d’attribution de droits, de plus en plus facilités via l’utilisation d’algorithmes tirant parti du machine learning, l’outillage choisi doit notamment permettre de faciliter la mise en qualité des données en amont de la phase de modélisation. Il est également utile de prévoir une fonctionnalité de simulation qui permettra de mettre en évidence les sur- ou sous-allocations engendrées par le nouveau modèle par rapport aux affectations actuelles.

En mode nominal, les solutions IAM du marché offrent diverses possibilités dont il est possible de tirer parti : hiérarchie de rôles, attributions automatiques à la façon d’ABAC, attributions suggérées, dimensions de rôles multiples, etc. Il faudra cependant être attentif à ne pas tomber dans le piège d’un modèle trop compliqué à utiliser et à administrer.

Si le choix de la solution IAM qui supportera le modèle est déjà arrêté, il conviendra de s’assurer que ladite solution permet de prendre en charge toute la complexité souhaitée, quitte à procéder à quelques simplifications ou ajustements du modèle.

Dois-je construire mon modèle d’habilitation avant, pendant, ou après la mise en place de ma nouvelle solution IAM ?

D’une manière générale, il est préférable de concevoir son modèle d’habilitation en amont de la mise en place d’une nouvelle solution IAM. Ce cadrage peut en effet fortement influencer le choix de l’outil, en fonction de l’adéquation des possibilités techniques et des attendus fonctionnels.

Si la qualité des données est satisfaisante, l’implémentation du modèle à proprement parler peut alors se dérouler en même temps que la mise en place de l’IAM. Au besoin, il est envisageable de prévoir une phase de transition où l’ancien outillage peut cohabiter avec le nouveau. Les périmètres prêts pour le passage au nouveau modèle sont ainsi traités dans le nouvel outil, ce qui donne plus de temps pour la migration des périmètres plus compliqués ou qui nécessitent plus de travail. Un planning de migration doit alors être défini et suivi de près pour éviter toute dérive qui prolongerait cette situation.

Combien de temps dois-je prévoir ?

Les projets de mise en place d’un modèle d’habilitation sont en général conséquents. Ils nécessitent la prise en compte de nombreux facteurs et ont un impact important sur l’ensemble des parties prenantes des habilitations (responsables applicatifs, support aux utilisateurs, Métiers…).

D’une part, il est capital de prendre son temps lors de la phase de cadrage des attentes et de conception afin d’assurer la réussite de son projet.

D’autre part, la phase de modélisation peut s’avérer longue et fastidieuse, particulièrement si la volumétrie est importante (en termes de nombre de rôles ou en nombre d’entités à couvrir) ou bien si la qualité des données de base n’est pas satisfaisante et nécessite de la remédiation.

Enfin, la gestion du changement n’est pas à négliger, eu égard aux impacts bien visibles par les utilisateurs. Des formations et une phase de support renforcé sont la plupart du temps nécessaires une fois le modèle mis en place.

Quelle gouvernance mettre en place pour faire vivre mon modèle d’habilitation ?

Le modèle d’habilitation n’est pas statique. Le catalogue des habilitations vit au gré des nouvelles applications, des décommissionnements, des évolutions SI ou Métiers et des réorganisations. Dès la phase de conception, une réflexion sur les principes de gouvernance courante est nécessaire afin de ne pas construire un modèle trop complexe et impossible à maintenir dans le temps.

Si la gestion du modèle est souvent prise en charge par une équipe dédiée aux habilitations, l’implication des autres parties prenantes est essentielle, notamment du côté du Métier qui doit faire part des évolutions de ses besoins. La désignation de correspondants habilitations au sein des directions métiers peut être un moyen de favoriser cette participation.

En conclusion

L’implémentation parfaite d’un modèle d’habilitation n’existe probablement pas. Même s’il n’y a pas d’interdit majeur, la recherche d’un compromis entre attentes et possibilités reste un exercice délicat qui nécessite réflexion, préparation et suivi poussés.

En synthèse, voici 5 bonnes pratiques pour la réussite d’un projet de refonte de son modèle d’habilitation :

1. Prévoir suffisamment de temps pour le projet.
2. Cadrer et piloter avec la plus grande attention pour éviter les dérives en termes d’ambition, de priorités, de charges ou de délai.
3. Communiquer vers, et impliquer les bons contributeurs IT et Métier.
4. Savoir dire « non » lorsque la couverture d’un besoin risquerait de trop détériorer la simplicité d’utilisation ou la capacité de maintenance.
5. Ne pas négliger la conduite du changement auprès des utilisateurs.

Notons que ces bonnes pratiques restent parfaitement applicables à tout projet IAM en général !

Cet article Refondre son modèle d’habilitation : les questions essentielles (2/2) est apparu en premier sur RiskInsight.

Améliorer la connaissances des menaces et des attaquants : plateformes CTI (-Cyber-Threat Intelligence)

La Cyber Threat Intelligence (CTI ou Threat Intel’) est une discipline regroupant la récolte, la consolidation et l’exploitation de toutes les informations sur les cyber-menaces. “Connais ton ennemi” indique Sun Tzu dans l’Art de la Guerre. Bien que cette citation fasse référence aux guerres « physique », le principe reste vrai… et l’est sans doute même davantage pour les luttes « cyber ».

En effet, aujourd’hui, un nombre important de dispositifs de sécurité s’appuient sur une connaissance des attaques : approche par signature des anti-virus et IDS, scénarios de détection ciblés… Même si la tendance s’inverse (notamment avec la détection d’anomalies), la grande majorité des produits de sécurité s’appuient toujours -et continueront de s’appuyer- sur des principes de Threat Intelligence.

Les besoins des entreprises étant de plus en plus spécifiques, et les attaquants de plus en plus spécialisés, les solutions de Threat Intel’ se démocratisent et proposent directement leurs services aux entreprises. En complément des offres commerciales, de plus en plus de plateformes d’échanges et de partenariats permettent de collaborer directement avec d’autres entreprises (de même secteur, zone géographique…).

Les services rendus par la Threat Intel’ sont multiples. D’une part la Threat Intel’ « stratégique » aide les SOC à mieux connaître le contexte et les menaces spécifiques à leur entreprise. Pour cela, les risques pesant sur chaque écosystème sont étudiés : aspects géographique, politique, idéologique, sectorielle… Ces informations permettent aux équipes sécurités de mieux connaître les menaces les concernant, et d’orienter leurs décisions pour définir leur stratégie « long terme » (solutions à déployer…).

D’autre part, la Threat Intel’ « tactique » donne des informations plus précises sur les méthodes des attaquants et permet notamment au SOC de faciliter la détection et d’adapter les mesures existantes : nouveaux scénarios de menaces à surveiller, ports à bloquer….

En complément de ces approches, la Threat Intel’ « technique » participe grandement à l’analyse des évènements de sécurité en fournissant, sur demande (depuis un SOAR notamment, voir partie suivante), des éléments permettant de juger de la véracité d’une alerte : appartenance d’une IP à un botnet, hash de fichier correspondant à un virus connu…

Les dispositifs de Threat Intelligence figurent donc parmi les outils les plus polyvalents du SOC, en permettant de tirer parti au mieux des dispositifs existant, en restant à jour et priorisant les menaces à détecter, et en orientant vers les prochains outils et mesures à déployer.

Exemples d’éditeurs Threat Intelligence :

Industrialiser et automatiser le processus de réaction : SOAR

Les SOAR (pour Security Orchestration, Automation & Response) sont issus de la combinaison de trois outils du SOC : les SIRP (Security Incident Response Plateform, plus de détails ici), les SOA (Security Orchestration & Automation, les solutions d’industrialisation et d’automatisation) et une partie des fonctionnalités de plateformes de Threat Intelligence. Pour résumer, ce sont des plateformes d’aide et d’automatisation de la réaction aux incidents de sécurité. Ces solutions se rapprochent d’outils de ticketing (ITSM) classiques, mais embarquent des fonctionnalités spécifiques aux problématiques de cybersécurité. Les SOAR offrent principalement trois capacités, chacune liée à l’un des trois types d’outils à leur origine.

Premièrement, comme les SIRP, ils permettent la définition de processus de réaction adaptés à chaque évènement de sécurité. Ceux-ci sont basés sur des playbooks prédéfinis par l’éditeur, publiés par la communauté de la solution, ou créés manuellement pour une meilleure adaptation aux besoins de l’entreprise. Cette tâche impose notamment aux équipes de réaction d’établir un processus clairement défini, les aidant ainsi à se poser les bonnes questions lors de la création de procédures de réaction, et à capitaliser et stocker ces connaissances.

Le gain des SOAR repose cependant davantage sur l’automatisation des différentes étapes suivant la détection. Lors de la phase d’analyse, l’outil va automatiquement enrichir l’évènement de sécurité en allant récupérer des informations de contexte sur le SI (identité dans l’AD, criticité d’une ressource…), et en interrogeant des services de Threat Intelligence externes (via des API) ou proposés avec la solution. Outre l’automatisation de l’enrichissement et des étapes d’analyse, les SOAR facilitent aussi le travail des analystes -investigation de postes, interrogation de VirusTotal… en un clic-  lorsque leur intervention est nécessaire.

Mais l’automatisation ne s’arrête pas là ! Bien que polémique, l’automatisation de la réaction (via la connexion aux équipements de sécurité, héritage du SOA) peut représenter un gain important pour les équipes de sécurité : blocage d’URL, génération de signature de fichier et propagation aux antivirus, blacklisting d’IP…

L’objectif des SOAR est donc clair : faciliter la tâche des équipes en charge de l’analyse et de la réaction, en les aidant à définir des processus et en automatisant les tâches au maximum. Même si les SOAR sont très adaptables, et peuvent donc aider à répondre à toute type d’attaque, ils brillent tout particulièrement pour automatiser le traitement des attaques courantes (ransomware, phishing…), très répétitives et mobilisant les efforts des équipes de réaction.

Une fois ces tâches automatisées, les équipes sécurité en charge de la réaction peuvent se concentrer sur les alertes plus complexes, où leurs connaissances apportent une véritable valeur ajoutée.

À conditions d’être prêt à fournir l’effort initial (formalisation des processus…), les gains en réactivité et en charge attendus sont donc conséquents. Les SOAR sont amenés à changer le mode de travail des équipes SOC, en particulier pour les analystes de premier niveau. Même si ces solutions sont encore peu déployées en France, ils devraient devenir l’un des indispensables du SOC dans les années qui viennent.

Exemples d’éditeurs SOAR :

Même si l’outillage n’est qu’une partie du SOC, chacune de ces solutions présente des avantages certains qui aideront les équipes de détection à rester d’actualité face à l’évolution du SI et des menaces.

Tous ces outils sont prometteurs, et certains arrivent à maturité. Cependant, il est important de garder à l’esprit que l’outillage actuel lève déjà de nombreuses alertes, difficiles à prendre en compte. Il est donc conseillé de finir de déployer et d’industrialiser l’existant (en utilisant un SOAR par exemple), avant de se tourner vers de nouvelles solutions.

Et, comme pour tout produit innovant, il faut savoir garder la tête froide : le déploiement d’une nouvelle solution doit être motivé par des besoins bien définis.

Cet article SOAR, UEBA, CASB, EDR et autres acronymes… suivez la saga de l’été pour comprendre et choisir parmi les nouveaux outils du SOC (3/3) est apparu en premier sur RiskInsight.

Compléter la détection avec de nouvelles approches

Raisonner identité pour détecter les comportements suspects : UEBA

Les technologies UEBA (pour User and Entity Behavioral Analysis), précédemment appelées UBA, sont parmi les derniers nés des outils venant compléter l’arsenal de détection des SOC. Comme leur nom l’indique, leur approche est claire : faire abstraction des considérations techniques des solutions actuelles (SIEM…) en analysant le comportement des utilisateurs et des entités (comprendre terminaux, applications, réseaux, serveurs, objets connectés…).

Le principe est simple, mais son implémentation l’est beaucoup moins. En effet, pour être efficace, les dispositifs UEBA ont besoin de sources nombreuses, avec des formats de données variés. Les sources traditionnelles, telles que le SIEM et le(s) gestionnaire(s) de logs, mais aussi directement certaines ressources (AD, proxy, BDD…) sont souvent utilisées.

Mais afin de parfaire la détection, les solutions UEBA interrogent aussi de nouvelles sources : informations sur les utilisateurs (applications RH, gestion des badges…), échanges entre employés (chats, échanges vidéo, emails…), ou toute autre contribution pertinente (applications métiers à surveiller…).

À partir de toutes ces informations, les solutions UEBA analysent les comportements des utilisateurs (et entités) pour identifier de potentielles menaces. Elles peuvent utiliser des règles statiques, sous forme de signatures à détecter (souvent déjà implémentées dans les solutions SIEM) : connexions simultanées depuis deux endroits différents ou hors des plages horaires classiques…

Mais la véritable force des UEBA réside dans l’utilisation d’algorithmes de Machine Learning pour détecter des modifications du comportement d’utilisateurs ou services : opération métier suspecte, accès à des applications critiques jamais utilisées auparavant lors de congés, transferts de données inhabituels…

Si, à l’origine, les UEBA étaient pensés pour lutter contre les fraudes, leur rôle s’est cependant peu à peu élargi pour couvrir certains périmètres posant habituellement des problèmes aux SIEM : vols de données, compromission -ou prêt- de comptes applicatifs, infection de terminaux ou serveurs, abus de privilèges…

Ainsi, les UEBA se positionnent aujourd’hui en compléments des SIEM, en complétant l’approche « technique » par une vision « utilisateur », et en ajoutant une couche d’intelligence supplémentaire dans l’analyse.

Au vu du marché, il probable que les solutions UEBA cessent d’exister en tant que telles dans les années à venir et s’intègrent à des solutions existantes (SIEM, EDR…), passant de produits à fonctionnalités.

Exemples d’éditeurs UEBA :

Piéger les attaquants : Deceptive Security

La Deceptive Security peut être considérée comme un passage au niveau supérieur des Honey Pots. Des leurres, sous formes de données, d’agents ou d’environnements dédiés, sont répartis à grande échelle dans tout ou partie du SI.

Selon les solutions et les besoins, les outils de Deceptive Security peuvent poursuivre deux buts. En détournant l’attention des attaquants des vraies ressources et en les dirigeants vers de fausses pistes, ils peuvent agir comme moyens de protection.

Mais surtout, la surveillance de ces leurres peut permettre de détecter des menaces se propageant au sein du SI. En effet, ces leurres n’ayant d’autres utilités que d’appâter de potentiels attaquants ou de divulguer de fausses informations, toute communication avec l’un d’entre eux est nécessairement suspecte.

Ce type de solution ne remplace par les solutions existantes, mais répond à des cas d’usage bien spécifiques, pour lesquels les dispositifs de détection classiques sont peu efficaces : les APT, spécialement conçus pour les contourner, et plus largement les mouvements horizontaux au sein du SI.

Pour plus de détails sur les solutions de Deceptive Security, vous pouvez consulter notre article dédié au sujet ici !

Exemples d’éditeurs Deceptive Security :

Détecter les signaux faibles sur le réseau : sondes « Machine Learning »

Les sondes de détection classiques (IDPS), basées sur l’analyse de trafic et la comparaison avec des signatures d’attaques connues, sont peu efficaces lorsqu’il s’agit de détecter des menaces subtiles (APT…) ou inconnues (0 days…). Pour pallier ce problème, les IDPS nouvelles générations intègrent des capacités de Machine Learning (parfois présenté comme de l’Intelligence Artificielle) dans leur arsenal de détection.

Selon les solutions, deux types d’usage du Machine Learning sont à distinguer. D’une part, l’utilisation de ces algorithmes en mode supervisé, pour apprendre à reconnaître le comportement de certaines attaques ou phases d’attaque lors de leur phase active : commande & contrôle, scans, mouvements latéraux, fuite de données…

Une fois la sonde déployée, l’ajustement des seuils de détection au contexte client est lui aussi basé sur des algorithmes de Machine Learning (comme le font déjà bon nombre de solutions IDPS classiques).

Ce mode de fonctionnement permet un déploiement rapide (solution utilisable out-of-the-box et phase d’apprentissage écourtée), et une meilleure capacité à détecter les attaques caractérisées précédemment. En contrepartie, la détection des attaques non couvertes par l’apprentissage ou complètement inconnues restent difficiles.

A l’opposé de cette approche, des solutions misent sur l’apprentissage non-supervisé pour détecter les attaques. Pour cela, lors du déploiement, les sondes sont positionnées sur le réseau pour observer le trafic, et apprendre à reconnaître le trafic légitime.

Une fois la phase d’apprentissage terminée, les sondes sont capables de détecter des anomalies, et donc de lever des alertes en cas de comportement suspect. Cette approche permet de détecter des attaques inconnues, mais nécessitent généralement une phase d’apprentissage plus longue pour être efficace et atteindre un taux de fausses alertes acceptables.

Dans les deux cas, les sondes « Machine Learning » permettent de compléter l’arsenal des SOC, aujourd’hui majoritairement destiné à détecter des attaques connues, par des capacités de détection capables de distinguer des attaques complexes, méconnues, ou créés pour contourner les dispositifs de sécurité classiques.

Nos premiers retours terrains montrent que ces technologies peuvent en effet détecter des menaces passant au travers des dispositifs de sécurité classiques. Les faux positifs sont cependant très fréquents (la courbe d’apprentissage variant grandement selon les solutions et les contextes), et il reste difficile de juger de l’exhaustivité des menaces détectées.

Les sondes « Machine Learning » ont donc un avenir certain parmi les outils du SOC, même si un gain en maturité reste à réaliser pour qu’elles atteignent leur plein potentiel.

Exemples d’éditeurs de sondes ML :

Pour retrouver notre troisième et dernier article sur cette saga, c’est par ici.

Cet article SOAR, UEBA, CASB, EDR et autres acronymes… suivez la saga de l’été pour comprendre et choisir parmi les nouveaux outils du SOC (2/3) est apparu en premier sur RiskInsight.

Dans un contexte où l’on assiste à une véritable pénurie de compétences cybersécurités, ces problématiques ne peuvent être adressées uniquement par le renforcement des effectifs du SOC. L’utilisation de nouveaux outils, basée sur 4 axes stratégiques, est indispensable pour permettre au SOC d’avoir de l’avance sur les nouvelles menaces.

Ainsi, l’extension de la détection à de nouveaux périmètres permet de protéger de nouvelles parties du SI, aujourd’hui insuffisamment sécurisées (Cloud) ; et des ressources de plus en plus prises pour cibles (attaques ransomware sur les terminaux, attaques ciblées utilisant les AD…).

Dans le même temps, l’adoption de nouvelles approches devient une nécessité pour détecter les attaques ciblées (0days, « low signal » …), dont la subtilité croissante met à mal les dispositifs de sécurité existants.

En complément de nouveaux outils de détection, une connaissance avancée des menaces et des attaquants peut venir améliorer les capacités de détection existantes, aider à la priorisation des incidents à traiter et faire gagner en efficacité lors de la réaction.

Mais les équipes SOC éprouvent déjà des difficultés à traiter les évènements générés par les outils existants. Il est donc primordial d’industrialiser et d’automatiser les interactions entre équipes et systèmes, et, lorsque c’est possible, les étapes d’analyse et de réaction !

Pendant l’été, suivez les épisodes de notre saga pour découvrir les moyens d’outiller ces 4 axes stratégiques !

Étendre la détection à de nouveaux périmètres

Une solution unique pour sécuriser tous les Cloud : CASB

Les CASB (pour Cloud Access Security Broker) adressent un périmètre du SI aujourd’hui mal desservi par les mesures de sécurité classiques : le Cloud. Par sa nature, sa protection nécessite en effet des adaptations par rapport aux SI classiques : pas ou peu de maîtrise des ressources (infrastructures, OS ou applications, selon le type d’offre), localisation à l’extérieur du SI…

Les CASB visent à centraliser et à faire appliquer les politiques de sécurité aux services situés dans le Cloud. Certains fournisseurs Cloud proposent leurs propres services de sécurisation CASB (par exemple Microsoft avec Microsoft Cloud App Security) ; mais, selon les besoins, il est parfois préférable d’utiliser des solutions tierces, même si l’ajout d’un acteur supplémentaire a un coût. En effet, le CASB visant à s’assurer du niveau de sécurité du Cloud, confier ce rôle aux fournisseurs du service à surveiller peut être contre-productif, et l’utilisation d’un « tiers de confiance » est à privilégier.

Dans tous les cas, les CASB sont des solutions variées, pouvant regrouper de très nombreux services, leurs maturités variant selon les éditeurs de solution, les fournisseurs Cloud et le type d’hébergement (IaaS, PaaS, SaaS…).

D’une part, les solutions CASB permettent d’adresser les enjeux spécifiques aux Cloud, en palliant le manque de visibilité sur ces environnements (détection du Shadow IT, statistiques d’utilisation…), et en s’assurant de leur conformité (vérification des configurations…).

D’autre part, elles participent au déploiement des mesures de sécurités classiques sur ce périmètre. En particulier, les enjeux de sécurité de la donnée (DLP et mesures de chiffrement, particulièrement appréciées par les régulateurs) et de détection des menaces (centralisation des logs Cloud pour transmission au SIEM, détection de comportements anormaux -UEBA !, voir partie dédiée-…) font parties des capacités classiques proposées par les éditeurs. En complément, certaines problématiques d’IAM peuvent aussi être adressées par ces solutions (SSO, contextualisation des accès…).

Il existe deux principaux modes de déploiement pour la mise en place de ces fonctionnalités, chacun possédant ses avantages (et inconvénients). Les solutions types proxy sont placées en coupure entre les utilisateurs et le service Cloud.

A l’opposé, dans le cas des solutions de type API, parfois appelées out-of-band, les consommateurs du service Cloud communiquent directement avec celui-ci. Pour chaque accès, le service interroge les API du CASB afin de d’évaluer les risques, et d’autoriser ou non la consommation du service. Les solutions API s’appuient cependant sur les interfaces proposées par le fournisseur Cloud pour fonctionner, ce qui peut limiter certaines possibilités.

Aujourd’hui jeunes et peu matures, les CASB restent peu déployés. Au vu de la démocratisation (déjà bien avancée) des services Cloud, les CASB ont cependant un bel avenir devant eux, et permettront aux équipes SOC d’étendre leur surveillance sur ce périmètre, voué à représenter une partie importante du SI.

Exemples d’éditeurs CASB :

Détection et réaction, le nouveau couteau suisse pour sécuriser les terminaux : EDR (Endpoint Detection and Response)

Les solutions EDR (pour Endpoint Detection and Response) viennent compléter les capacités de détection et de réaction des SOC sur les terminaux (PC, serveurs…).

Comme leur nom l’indique, les EDR participent à la détection d’attaques. Ceux-ci viennent en effet combler les faiblesses des anti-virus (et autres HIPS) s’appuyant sur des signatures d’attaques précises, et donc inadaptées pour détecter certains types d’attaques, notamment les attaques avancées (APT). Les EDR se basent donc sur d’autres méthodes de détection, les éditeurs proposant généralement une combinaison de techniques habituellement utilisées sur d’autres périmètres.

Parmi ces techniques, la détection d’exploitation de vulnérabilités connues ou de patterns d’attaque (ouverture de port suspects vers des adresses douteuses…), l’analyse de fichiers par une sandbox (émulation locale, soumission dans le Cloud…), et des approches comportementales basées sur du Machine Learning (en particulier les solutions UEBA, cf. partie dédiée) sont utilisées par bon nombre de solutions. Selon les besoins du SOC, les alertes remontées peuvent être intégrées comme sources du SIEM, ou disponibles directement depuis la console de management de la solution.

En plus de ces capacités de détection avancées, les solutions EDR apportent aussi un important gain en visibilité sur les terminaux : liste des processus et services lancés, liste de fichiers dans certains répertoires systèmes… et toute autre information permettant de faciliter l’investigation en cas d’alerte. Certaines solutions ne se limitent pas à récupérer l’état du terminal au moment de la demande, mais permettent aussi de récupérer son historique : génération de logs, récupération de fichiers supprimés…

Mais les fonctionnalités des EDR ne s’arrêtent pas aux étapes de détection et d’analyse. En effet, ces solutions permettent d’effectuer des actions de remédiation à distance, dont la complexité dépend des éditeurs : suppression ou mise en quarantaine de fichiers, arrêt de processus, mise en quarantaine réseau de postes, modification de clés de registre…

Les EDR sont donc des solutions très complètes intervenant à toutes les étapes du processus : de la détection, à l’analyse, jusqu’à la réaction. Elles n’ont cependant pas vocation à remplacer les solutions anti-virus, toujours plus efficaces pour bloquer les attaques connues ; même si l’on observe de plus en plus d’éditeurs proposant des solutions unissant les deux types de fonctionnalités.

Pour plus de détails sur les solutions EDR, vous pouvez consulter notre article dédié au sujet ici !

Exemples d’éditeurs EDR :

Protection des clés du royaume : supervision Active Directory

Les annuaires comptent parmi les composants les plus critiques du SI. En effet, ceux-ci fournissent les fonctionnalités d’authentification et d’habilitation pour la quasi-totalité des ressources du SI, aussi bien techniques que métiers, y compris les plus critiques. Il n’est donc pas étonnant que la compromission d’AD figure parmi les méthodes d’attaque les plus utilisées, car ouvrant de nombreuses portes aux attaquants.

Malgré cette criticité, et bien que les architectures AD soient bien connues et aient peu évolué depuis plusieurs années, leur sécurisation reste perfectible. Cela est en particulier dû à leur mode de fonctionnement spécifique (OU, domaines, arbres, forêts, utilisateurs…), rendant les moyens de protection et de surveillance classiques peu efficaces, en particulier lorsque toute vulnérabilité peut représenter un risque majeur pour le reste du SI.

Les solutions de surveillance AD visent à pallier ce problème en supervisant (en temps réel, ou lors d’audit) les spécificités des annuaires (configuration, état des comptes…), et en y détectant des vulnérabilités susceptibles de causer leur compromission. Pour cela, les solutions de supervision AD possèdent une connaissance très pointue du fonctionnement des AD, et tout particulièrement des enjeux de sécurité liés.

Lorsqu’une vulnérabilité est détectée, une alerte est remontée (par le biais du SIEM, ou directement dans la solution) et des conseils de remédiation peuvent être fournis afin de faciliter le travail des équipes en charge de la correction.

Les outils de supervision AD permettent par ailleurs au SOC de détecter toute modification de configuration (légitime, accidentelle ou malveillante) et de s’assurer en continu du niveau de sécurité de ces composants critiques, compliquant d’autant la tâche de nombreux attaquants.

En complément du renforcement direct du niveau de sécurité de l’AD, ces solutions peuvent aussi être utilisés pour s’assurer de la compliance vis-à-vis de normes ou de contraintes réglementaires (LPM, PCI DSS…).

Ces solutions restent assez peu répandues aujourd’hui, et leur utilisation généralement limitée à des audits ponctuels. Cependant, au vu des importants gains de sécurité associés (détection et conseils de remédiation) et de leur simplicité d’utilisation, ces solutions sont prometteuses et devraient réussir à se faire une place parmi les outils du SOC.

Exemples d’éditeurs de supervision AD :

Pour retrouver notre second article de la saga, c’est par ici.

Cet article SOAR, UEBA, CASB, EDR et autres acronymes… suivez la saga de l’été pour comprendre et choisir parmi les nouveaux outils du SOC (1/3) est apparu en premier sur RiskInsight.

Nous avons proposé 5 facteurs clés de succès pour mener un projet de mise sous contrôle des risques liés aux habilitations des ERP :

Les deux premiers facteurs clés de succès ont été vus dans le précédent article ; les trois derniers sont détaillés ci-après.

3. Industrialiser le déploiement

Services, filières, entités géographiques ou légales… la remédiation des risques sur les habilitations nécessite de passer en revue les comptes utilisateurs de différents – et souvent nombreux – périmètres. Afin de tenir les plannings, de limiter la charge de travail, mais également de rassurer les contributeurs locaux, il est préférable « d’industrialiser » au maximum le déploiement. Cela passe notamment par :

• la définition et la communication d’une méthodologie d’analyse et de remédiation des risques ;
• la mise en place d’outils de pilotage ;
• la mise en place d’outils d’analyse plus ou moins automatisés pour faire face à la volumétrie ;
• la formalisation de supports d’ateliers et de restitution ;
• la documentation de la méthodologie et de l’outil pour former les utilisateurs.

Tous les documents produits dans ce cadre constitueront le « kit » de déploiement utilisé par le projet sur les différents périmètres, et qui pourra également servir après le projet.

« Kit » de déploiement d’un projet de remédiation des risques liés aux habilitations d’un ERP

La méthodologie de déploiement va nécessairement s’articuler autour des activités suivantes, à reproduire pour chaque périmètre :

• Analyse des risques et définition d’indicateurs.
• Ateliers de remédiation des risques portés par les utilisateurs.
• Validation et exécution des plans de remédiation.
• Formation et accompagnement à la montée en compétence.

Cette méthodologie doit néanmoins s’adapter à l’organisation de l’entreprise et aux moyens de chaque entité : effectifs, déclinaisons locales des processus métiers, maturité dans la gestion des risques et des habilitations…

En particulier, il s’agira de mobiliser des sachants locaux aussi bien sur le volet technique des habilitations (correspondants habilitations, responsables applicatifs, responsables sécurité) que sur le volet métier des processus (représentants métiers, responsables de processus, contrôleurs internes, managers d’équipe…). À ce titre, la contribution attendue de leur part et la charge qu’ils devront y consacrer devra être annoncée le plus tôt possible et rester « raisonnable ». Le management local devra donc être impliqué pour garantir la mobilisation des contributeurs et aider dans la prise de décisions.

Lors des ateliers de remédiation, les contributeurs participeront notamment à l’analyse des risques portés par les utilisateurs et seront amenés à étudier différentes stratégies de remédiation telles que celles-ci :

Stratégies à considérer dans un projet de remédiation des risques liés aux habilitations d’un ERP

Il est bien entendu préférable de valider cette méthodologie sur un périmètre pilote, d’une volumétrie limitée tout en restant représentatif de l’entreprise. Suivant le contexte, il peut être plus stratégique de choisir un périmètre a priori « favorable » au projet, ou bien au contraire un périmètre qui demandera de toute façon plus d’accompagnement. Les leçons apprises dans le cadre du pilote permettront d’ajuster la méthodologie et l’outillage qui l’accompagne avant la phase de déploiement généralisé.

4. Bien s’outiller

Les outils mis en place doivent aider à mener à bien la phase projet, mais aussi et surtout être utilisés dans la durée en support de la méthodologie, les deux fonctionnant de concert.

Bien s’outiller, c’est déjà être au clair quant aux contrôles à réaliser a priori (au moment de la demande d’une nouvelle habilitation) et aux contrôles à réaliser a posteriori (une fois que les habilitations ont été données). Avoir beaucoup de contrôles a priori peut certes aider à prévenir plus de risques, mais l’efficacité opérationnelle peut aussi en pâtir (délais, difficultés dans le traitement des demandes), d’où l’intérêt de trouver le bon équilibre.

D’un point de vue fonctionnel, il s’agit d’être en mesure de réaliser plusieurs familles de contrôles typiques pour un tel projet, à savoir :

• Contrôles sur la qualité des données : complétude et cohérence des données, respect des nomenclatures…
• Contrôles sur des règles de sécurité IT : comptes orphelins, dormants et administrateurs, permissions temporaires ou rémanentes, comptes IT avec des permissions métier et réciproquement…
• Contrôles sur des règles métier / conformité : écarts entre la fonction et les permissions, écarts de permissions entre les membres d’une même équipe, infractions aux règles de séparation des tâches, accès en dehors du périmètre de responsabilité…
• Contrôles sur les usages et le comportement : usages excessifs ou inhabituels, comportements suspects, scénarios de fraude typiques…

Familles de contrôles typiques pour un projet de remédiation des risques liés aux habilitations d’un ERP

Bien s’outiller, c’est aussi prioriser et automatiser les contrôles qui en valent le coup. Le retour sur investissement doit être évalué au regard de la pertinence de chaque contrôle dans le contexte de l’entreprise (le contrôle ne coûte-t-il pas plus cher que l’impact du risque qu’il est censé couvrir ?) et du gain potentiel lié à l’automatisation (combien économise-t-on par rapport à une réalisation manuelle ?).

La volumétrie et la complexité des modèles d’habilitation des ERP imposent le recours à des outils adaptés : il n’est en effet pas étonnant de voir par exemple des systèmes SAP avec plusieurs milliers de rôles et plus d’une centaine de milliers de permissions fines (transactions et objets d’autorisation).

Les besoins se retrouvent à la croisée de plusieurs marchés logiciels particulièrement dynamiques en ce moment et aux frontières assez poreuses : « Gestion des identités et des accès », « Contrôle continu », « Outils de Gouvernance-Risque-Conformité spécialisés sur un ERP donné »… L’approche, la maturité, la couverture fonctionnelle et le mode de delivery (sur site ou cloud/SaaS) peuvent ainsi varier sensiblement d’un produit à l’autre.

Lors du choix de l’outil, il s’agira de considérer attentivement les éléments suivants :

• L’ergonomie et la facilité d’utilisation – une fois le projet terminé, les utilisateurs de l’outil seront majoritairement « Métier » et peu « IT ».
• Les possibilités de personnalisation – pour que l’outil vienne véritablement en support de la méthodologie (vocabulaire et écrans, règles et contrôles, tableaux de bord et rapports spécifiques à l’entreprise…).
• Le référentiel des contrôles déjà préconfigurés pour l’ERP de l’entreprise – généralement basés sur des bonnes pratiques.
• La capacité à réaliser des contrôles sur d’autres applications et entre applications – dans une logique moyen terme pour l’entreprise.
• Les fonctionnalités d’aide à l’analyse et à la décision – mise en évidence des anomalies, simulation de changements sur les habilitations, analyses approfondies et suggestions de remédiations…

Bien que les outils soient généralement peu « intrusifs » vis-à-vis des applications, il s’agira tout de même d’automatiser et de fiabiliser le transfert des données depuis l’ERP et les autres référentiels éventuels. Les équipes IT concernées devront donc être sollicitées également.

5. S’inscrire dans la durée

Un tel projet n’a de sens que s’il permet de maîtriser efficacement et dans la durée les risques liés aux habilitations. Il s’agit en effet d’éviter que les risques couverts en phase projet ne soient de nouveau présents quelques temps plus tard.

Pour favoriser l’appropriation de la méthodologie et des outils mis en place, il est indispensable d’investir dès le début et tout au long du projet dans la conduite du changement : réunions et lettres d’information régulières, séances de formation et de coaching, documentation et tutoriels… On préfèrera diversifier les canaux et supports d’échange afin de toucher un maximum de personnes sans donner l’impression de les sursolliciter.

Il convient par ailleurs d’aider les futurs responsables des risques liés aux habilitations à inscrire les nouveaux contrôles dans leurs activités récurrentes. On peut ainsi définir à quelles fréquences les contrôles plus ou moins avancés doivent être réalisés, quels sont les objectifs à atteindre ou les seuils de risques à ne pas dépasser. Ces objectifs se doivent d’être réalistes et progressifs : « Visons loin mais jalonnons court. »

Dans une logique de « communauté », il est important de favoriser les échanges entre responsables des différents périmètres afin qu’ils partagent leurs retours d’expérience et leurs bonnes pratiques. Il peut également être intéressant de créer une émulation saine entre les différents périmètres, voire même d’organiser de petits challenges. On veillera néanmoins dans un premier temps à valoriser plus la progression que l’atteinte d’un objectif chiffré donné, les différents périmètres n’ayant probablement pas tous la même situation de départ ni les mêmes moyens.

Enfin, il convient de mettre en place le mode « nominal », garantissant que les risques liés aux habilitations restent sous contrôle une fois le projet terminé. Cela passe notamment par :

• la nomination d’un référent de la méthodologie et de l’outil de contrôle des habilitations ;
• la montée en compétence des équipes techniques pour assurer le maintien en condition opérationnelle des outils et assurer l’évolution des rapports et des contrôles lorsque nécessaire ;
• la documentation et la capitalisation des connaissances acquises durant la phase projet.

La définition d’une feuille de route pour l’extension ultérieure du périmètre est également à envisager, afin de mettre sous contrôle de nouveaux processus, risques, applications, populations…

Inscrire dans la durée la maîtrise des risques liés aux habilitations d’un ERP

En conclusion, c’est possible !

Comme nous venons de le voir au travers de ces deux articles, maîtriser les risques liés aux habilitations d’un ERP nécessite de mener plusieurs chantiers importants, de la mise en place de l’outillage à la conduite d’ateliers avec les métiers, en passant par la formation et la conduite du changement.

Mais avec de la méthode et les bons contributeurs IT et Métiers embarqués dans le projet, rien d’impossible ! Des résultats tangibles peuvent être obtenus dans un délai raisonnable et initier une dynamique d’entreprise pour retrouver la maîtrise des habilitations sur l’ensemble du SI. Les facteurs clés de succès présentés ici sont en effet tout à fait applicables à des applications autres que les ERP.

Cet article ERP : comment mettre sous contrôle les risques liés aux habilitations ? (2/2) est apparu en premier sur RiskInsight.

Qu’est-ce que l’informatique quantique et pourquoi s’y intéresser ?

La manière dont les ordinateurs sont encore très majoritairement conçus aujourd’hui repose sur une architecture principalement séquentielle : les opérations sont effectuées par l’ordinateur les unes après les autres, selon un programme d’instructions écrit par l’homme. Le micro-processeur exécute alors les opérations de façon quasi séquentielle, et c’est ici l’une des principales faiblesses de cette architecture et de ses variantes.

L’informatique quantique viendrait alors combler cette faiblesse en proposant des machines dotées d’une faculté de parallélisme, permettant d’augmenter considérablement la puissance de calculs complexes, la rapidité de traitement et la capacité (théorique) de stockage. Cette technologie s’appuie sur le phénomène de superposition d’états quantiques pour développer des capacités de calcul beaucoup plus importantes que l’informatique classique. En effet, l’information est représentée par des « quantum bits » (qubit) similaires aux bits binaires utilisés dans l’informatique numérique. Pour rappel, le bit peut prendre deux valeurs, 0 ou 1 selon l’état du transistor. Le qubit, peut avoir trois états, le 1, le 0 mais aussi les deux à la fois : c’est ce qu’on appelle la superposition.

Cette capacité de superposition multiplierait le nombre d’opérations complexes réalisables dans un temps limité. Ainsi, là où le traitement d’informations volumineuses peut parfois prendre plusieurs jours, semaines, mois à être traitées par des ordinateurs classiques, les systèmes de l’informatique quantique le traiteraient en quelques secondes.

Malheureusement, cette technologie impose de maintenir l’état quantique pour atteindre de telles capacités de calcul, le problème étant que cet état ne peut être atteint qu’en plaçant l’ordinateur proche du zéro absolu, soit -273 °C, seules températures pour lesquelles le qubit est réellement stable. De manière évidente, il est extrêmement complexe de maintenir de telles températures avec un système simple, peu onéreux et peu encombrant pour une longue période de temps.

L’informatique quantique comme outil de sécurité

Les apports de l’informatique quantique en matière de capacité de résolution et de traitements rapides d’opérations complexes sont très convoités, et principalement dans le domaine de la sécurité informatique, où les mesures de protection et de détection nécessitent de plus en plus de rapidité d’exécution.

Par exemple, la lutte contre la fraude est aujourd’hui l’une des principales problématiques de sécurité du secteur bancaire et a pour enjeu d’exploiter des techniques poussées de détection de fraude, basées sur la collecte, le traitement et l’analyse, en temps réel, de données volumineuses. Ces techniques sont très gourmandes en puissance de calcul et, bien qu’aujourd’hui réalisables par nos ordinateurs les plus performants, elles pourraient être encore plus efficientes avec plus de puissance. Les ordinateurs quantiques, s’ils voient le jour, pourraient ainsi constituer un pilier de la lutte contre la fraude, à travers leur forte capacité (théorique) de stockage et leur rapidité de traitement.

De même, les systèmes quantiques pourraient notamment permettre de détecter et de corriger les erreurs. En effet, le qubit, sur lequel repose tout le fonctionnement de cette nouvelle génération informatique, est en effet très sensible aux perturbations de son environnement (interception, changement de configuration, variations de température, champs magnétiques…). Le qubit peut constituer ainsi, dans ces conditions, un moyen fiable pour garantir l’intégrité des données stockées.

L’informatique quantique comme source de menace

Les communications sécurisées, les systèmes sécurisés de paiements, les transactions financières, les monnaies virtuelles telles que le bitcoin, reposent tous sur des mécanismes cryptographiques, et en particulier sur les protocoles de chiffrement asymétriques. La sécurité de ces protocoles dépend principalement du fait qu’il faudrait plusieurs fois l’âge de la Terre à des ordinateurs classiques pour casser une code par la « force brute ». Pour un ordinateur quantique, ce décryptage est théoriquement réalisable et en très peu de temps. D’où le risque non négligeable pour les systèmes de chiffrement actuels si ces ordinateurs quantiques venaient à être démocratisés.

De plus, plusieurs attaques informatiques telles que les attaques par déni de service (DOS ou DDOS) nécessitent d’exploiter de fortes ressources en termes de traitement informatique qui, à l’aide des futurs ordinateurs quantiques, pourraient devenir facilement exécutables.

C’est précisément pour ces raisons que les instigateurs de l’informatique quantique se focalisent notamment sur le domaine de la sécurité afin de combler les failles qui pourraient potentiellement être occasionnées par l’apparition des ordinateurs quantiques, et espérant ainsi offrir des communications totalement sécurisées aux utilisateurs, en misant sur la cryptographie quantique. En effet, un réseau de communication quantique serait théoriquement inviolable. Toute tentative visant à intercepter la « clé de chiffrement quantique » modifierait l’intégrité physique des données quantiques, changerait alors leurs états (passage au 0 ou au 1 par exemple), et pourraient ainsi déclencher une alerte qui avertirait les personnes concernées. Actuellement, plusieurs laboratoires dans différents pays tentent de tirer le meilleur parti de cette technologie.

Par ailleurs, l’histoire nous a montré que lorsqu’un protocole de chiffrement était devenu « cassable », des solutions de chiffrement plus sécurisées voyaient le jour au même moment. On peut donc imaginer que si un jour un ordinateur quantique permet de casser un chiffrement « classique », une solution de chiffrement plus robuste, potentiellement basée sur la cryptographie quantique, sera disponible.

L’informatique quantique, concrètement…

Dans l’état actuel des recherches, tous ces concepts restent théoriques et seuls quelques embryons d’ordinateurs quantiques existent dans le monde, confinés encore à des laboratoires académiques, au sein des institutions les plus prestigieuses. Une quête dans laquelle IBM et Google se sont déjà lancés depuis plusieurs années. Intel a également rejoint la course à l’informatique quantique en annonçant investir 50 millions de dollars sur le sujet. La France n’est pas en reste, avec notamment le Laboratoire Kastler Brossel qui a reçu récemment un troisième Prix Nobel pour des travaux allant dans ce sens.

Du reste, les avis divergent sur cette nouvelle génération de l’informatique : Le National Institute of Standards and Technology (ou NIST) américain a prévenu que les différentes agences gouvernementales devront être prêtes à adopter de tels systèmes en 2025.  La NSA, l’agence nationale de la sécurité, conseille de mettre en place des processus de sécurité quantique aussi rapidement que possible. A l’opposé, certains cryptographes ne partagent pas cet avis, et ont déclaré lors de la dernière Conférence RSA qu’ils doutent que les progrès dans le calcul quantique et l’intelligence artificielle transformera réellement la sécurité informatique. Aussi, Eleni Diamanti, chercheuse au CNRS et membre de Paris Center for Quantum Computing, affirme pareillement que « même si un qubit est plus puissant qu’un bit, il en faut au moins un millier pour concurrencer les machines actuelles », ce qui est loin d’être concrétisé aujourd’hui, au vu de la complexité de création d’un qubit et de maintien dans des conditions stables.

Cet article Informatique quantique et sécurité : menace ou opportunité ? est apparu en premier sur RiskInsight.

Les 4 clés de l’intégration des services Cloud

1 – Une intégration des données sans couture

Avec l’utilisation de services Cloud, on exacerbe le besoin de mettre en place des plateformes transverses d’échanges entre les différentes ressources, qu’elles soient Cloud ou internes. Cette problématique est essentiellement présente lorsque l’on s’appuie sur des services SaaS.

Il s’agit ainsi soit d’étendre les plateformes d’échanges traditionnelles aux services Cloud si elles offrent des connecteurs vers les interfaces (API) des applications Cloud, soit de s’appuyer sur des services d’échanges relais (Cloud ou internalisés), qui masqueront la complexité des interfaces et de leur évolution.

2 – Une gestion centralisée des identités

Celle-ci est essentielle pour fournir aux utilisateurs un accès sans couture à l’ensemble du SI, qu’il soit en mode Cloud ou non. Elle doit notamment permettre de gérer le cycle de vie des comptes utilisateurs (décommissionnement, gestion du mot de passe…).

Cet aspect est trop souvent négligé. Il arrive par exemple de laisser des accès ouverts à des employés ayant quitté la société, l’exposant à de la surfacturation et à d’importantes brèches de sécurité. La DSI doit donc mettre en œuvre une gouvernance des identités globale ainsi que l’outillage adéquat.

3 – Des référentiels communs de service management

Pour que la DSI puisse garantir les niveaux de services de l’outil informatique (disponibilité, impact des changements, capacité d’évolution…), il est nécessaire qu’elle puisse intégrer les services Cloud à ses référentiels de service management. Ils auront notamment un rôle primordial pour gérer les changements. En effet, les services Cloud évoluent constamment, en cycle rapide, sans que les clients puissent s’y opposer. Les analyses d’impacts doivent donc être précises et le plus automatisées possible. Pour s’adapter au Cloud, les référentiels devront intégrer des ressources fournies en mode as-a-Service, pour lesquels les aspects de localisation ou de dépendance à des ressources physiques ne sont pas connus.

4 – Des portails de services par usage

L’une des composantes essentielles du Cloud est l’aspect self-service. Pour optimiser l’apport des services Cloud, il est primordial de limiter le nombre de points d’entrées pour les demandes de ressources, les déclarations d’incidents et le suivi des consommations, et ce quel que soit le nombre de fournisseurs.

En revanche, il n’est pas nécessaire de se limiter à une seule interface globale pour l’ensemble des services de la DSI. Il s’agit ici de fédérer les différents portails de services qui seront instanciés par typologie d’usage et de population. Pour ce faire, il faut anticiper au plus tôt une cible globale d’intégration puis s’appuyer sur un outillage adapté aux services souscrits et à l’existant. Cet outillage est à déployer progressivement à l’occasion de chaque projet Cloud jusqu’à atteindre la cible.

Une stratégie d’outillage à définir en fonction de la stratégie Cloud

La cible d’outillage sera à définir en fonction de la stratégie Cloud. Dans une stratégie à dominante SaaS, le challenge majeur sera d’intégrer sans couture les nouvelles applications au SI. Il faudra donc en priorité traiter les problématiques d’intégration de données, la gestion unifiée des identités et le portail de services. Si la stratégie Cloud est essentiellement IaaS, les enjeux seront plutôt liés à la gestion de ce nouveau parc de ressources. Il faudra alors se doter rapidement d’un outillage permettant d’adresser la problématique de service management.

Deux types d’acteurs constituent actuellement le marché de l’outillage Cloud, qui est en phase d’évolution rapide. D’un côté, des startups aux offres fonctionnellement riches mais dont la pérennité n’est pas toujours assurée. De l’autre, des fournisseurs traditionnels avec des offres qui sont soit balbutiantes, soit issues de rachats récents, donc peu intégrées au reste de leur gamme et en passe de subir des évolutions majeures.

Ces solutions n’étant pas pleinement satisfaisantes, deux stratégies de déploiement s’offrent aux entreprises.

Si l’on est dans un rythme d’adoption du Cloud plutôt lent, mieux vaut temporiser en s’appuyant sur l’outillage existant et en l’adaptant au cas par cas. Par exemple, des transferts de fichiers non automatisés peuvent suffire dans un 1er temps pour assurer le provisioning des identités. Cette stratégie évite d’investir dans des solutions peut-être non pérennes, au prix d’un surcoût modéré en opérations.

En revanche, si l’on souhaite adopter une démarche volontariste et cadencée vers le Cloud, il n’est plus possible de temporiser au risque de voir exploser ses coûts d’opérations. Il faut donc expérimenter ce que le marché sait fournir ! L’outillage Cloud-ready, qu’il permette l’intégration de données, la gestion des identités et le service management ou offre un portail de service, embarque de toute façon un ensemble de connecteurs vers  les fournisseurs du marché. Charge ensuite à l’éditeur de la solution de les maintenir à jour en fonction des évolutions apportées par les fournisseurs Cloud.

Dans tous les cas, un impératif : rester en veille permanente pour adapter sa stratégie aux évolutions des standards, à leur niveau d’adoption par le marché et aux mouvements de consolidation.

Cet article Sans maîtrise, le Cloud n’est rien… est apparu en premier sur RiskInsight.

Microsoft, géant de l’industrie logicielle, a lancé début 2010 l’outil Service Manager SCSM en s’appuyant sur sa suite System Center. Après une nouvelle version sortie début 2012 (SCSM 2012) et un Service Pack 1 disponible depuis janvier 2013, Microsoft confirme sa volonté de consolider sa position sur toute la chaîne de gestion des services IT. Pour autant, il n’apparaît pas encore dans le radar Gartner. Quel est donc le potentiel de cette solution ?

Quel sont les enjeux des outils ITSM ?

Les outils ITSM permettent à la DSI de se professionnaliser et d’améliorer sa qualité  de service, sa réactivité vis-à-vis des utilisateurs et de mieux piloter la production informatique.

Le choix et le déploiement d’un outil ITSM est impactant en termes de délai, les décisions doivent être prises avec un horizon à moyen terme (5 ans). De plus, c’est un outil visible, utilisé par de nombreux acteurs de la DSI et servant l’ensemble des utilisateurs. Dans un environnement d’entreprise de plus en plus changeant, l’enjeu d’adaptabilité de l’outil est donc primordial. Il doit apporter la souplesse permettant d’intégrer et de se séparer facilement de nouveaux périmètres, groupes supports et prendre en compte de nouveaux paramètres.

Le besoin de plus en plus prégnant de maîtriser les coûts informatiques et l’utilisation de plus en plus  large de services externalisés imposent également aux outils de répondre aux besoins de reporting et de mesure des SLA et OLA souvent complexes.

Le cloud en tant que tendance de fond se décline également sur les outils ITSM. Les solutions SaaS peuvent séduire des clients adeptes de solutions « clé en main ».

Enfin, les utilisateurs sont de plus en plus habitués à des interfaces user friendly pour leurs usages personnels. Ils deviennent de plus en plus exigeants sur l’ergonomie des outils professionnels. Les interfaces doivent donc être simples, intuitives et proposer des temps de réponse courts.

Le choix d’un outil sera donc guidé par les spécificités de chaque DSI, comme sa taille, son mode d’organisation (dispersion géographique, périmètres externalisés), ses engagements contractuels (catalogue et niveaux de service, impacts financiers liés à la mesure des engagements de services). L’enjeu pour les éditeurs sera de répondre à ces attentes diverses.

Qu’apporte la solution Microsoft ?

Tout comme ses principaux concurrents, System Center Service Manager 2012 permet d’outiller de façon intégrée les principaux processus :

• Front-office : gestion des incidents et gestion des demandes basée sur un module de gestion du catalogue de services.
• Back-office : gestion des problèmes, des changements, des mises en production et des configurations.

Du point de vue définition et design, les processus pris en charge sont basés sur MOF (Microsoft Operations Framework), largement appuyé sur le référentiel internationalement reconnu ITIL V3.

La spécificité de l’outil tient principalement à son appartenance à la famille Microsoft :

• Il est accessible à travers deux canaux dont l’interface est facilement prise en main car conçue dans « l’esprit » Microsoft : un client riche, ou console, à destination des équipes IT, et un portail web aux fonctionnalités plus limitées à l’usage des utilisateurs finaux.
• Il permet des interconnections natives avec les autres produits de la firme : l’Active Directory pour le peuplement de la solution, SCCM pour la gestion de configuration ou encore le portail Sharepoint pour le partage de la base de connaissance et la publication des reporting.
• La solution de reporting embarquée est l’un des atouts de cet outil. Basée sur les services de business intelligence issus de la technologie Microsoft SQL et elle permet d’automatiser la production des tableaux de bord publiables directement sur SharePoint.

Quelles entreprises peuvent en tirer le meilleur bénéfice ?

Le déploiement de cet outil met en avant la question du subtil équilibre à trouver entre l’adaptation de l’outil aux processus et l’adaptation des modes de fonctionnement de l’entreprise aux contraintes des éditeurs.

• Les possibilités d’adaptation de l’outil aux processus de l’entreprise éloignés des standards ITIL ou dotée d’une organisation avec de nombreux sites ou périmètres infogérés restent plus compliquées. Une personnalisation à l’aide du module « Authoring Tool » et de programmation XML devient nécessaire mais n’est supportée que lorsqu’elle est réalisée par Microsoft.
• L’ergonomie du portail web reste un point à améliorer au regard des capacités de Microsoft : le nombre de clic gagnerait à être réduit et une fois encore la personnalisation est difficile du fait d’une structure en Silverlight totalement verrouillée.
• D’un point de vue technique, l’interface web pour les utilisateurs n’est prise en charge que sur les plate-formes Windows Vista et ultérieures.

Compte tenu de ces caractéristiques, Microsoft répond plus particulièrement aux besoins d’entreprises souhaitant s’appuyer avant tout sur la console back-office ou aux entreprises de taille moyenne qui n’auront besoin que d’un faible niveau de personnalisation et qui pourront s’appuyer sur une solution clé en main et un cadre de référence standard.

Cet article Microsoft, challenger sur le marché des outils IT Service Management (ITSM) ? est apparu en premier sur RiskInsight.

« Allo Bernard ? C’est Jacques ! Ton pro est sur répondeur, heureusement Philippe avait ton perso.

Désolé de te réveiller, mais  notre SI est tombé. Apparemment, une mise en production s’est mal passée. Quelle application ? Aucune idée.

Philippe m’a chargé de mobiliser la cellule de crise. Du coup, tu peux regarder la procédure et appeler Simone avant de venir s’il te plait ? Rappelle-moi si tu ne retrouves pas le numéro. J’espère qu’elle sera là, c’est vraiment la galère on est en pleine clôture.

Envoie-moi un SMS pour me dire quand  tu arrives. Au fait, tu sais où on se retrouve ? Non ? À l’Atlantis, salle du conseil. On verra en arrivant comment on prévient les collaborateurs.»

Bien que fictives, ces quelques lignes – qui évoqueront peut-être à certains des souvenirs – mettent en évidence les points clés d’un début efficace de gestion crise et les difficultés afférentes.

En effet, les différents acteurs doivent réussir à se contacter, relayer une information exacte, obtenir de la visibilité sur les disponibilités et, éventuellement, alerter massivement les collaborateurs ; alors même qu’ils sont en situation de stress, pas ou peu préparés, que les procédures et annuaires sont oubliés voire non mis à jour et que les moyens de communication habituels ne sont pas forcément disponibles.

Impossible dès lors de s’assurer que l’alerte a été correctement transmise jusqu’aux derniers maillons et que la mobilisation suffit à adresser la crise rencontrée. Sans parler de la probable difficulté à informer l’ensemble des collaborateurs de l’organisation.

Au vu de ces difficultés, le recours à un outillage spécifique à ces premières phases de crise peut se révéler pertinent.

Industrialiser l’alerte : des outils offrant de nombreuses fonctionnalités couvrant différents aspects de la gestion de crise

On distingue classiquement deux besoins d’alerte distincts lorsqu’une organisation doit faire face à une crise. Le premier est de monter le plus rapidement possible la cellule de crise appropriée à la nature du sinistre. Le second est d’alerter largement ses collaborateurs –  éventuellement organisés en différentes populations – de façon pro active, tout en s’enquérant de leur condition (ce que ne permet pas l’usage d’un numéro vert).

Pour ce faire, il est possible de recourir à ce que les américains appellent un EMNS : Emergency Mass Notification System, ou outil d’alerte et de communication d’urgence, qui vise à éviter les écueils décrits plus haut grâce à différentes fonctionnalités.

En amont, un tel outil permet de définir des schémas d’alerte, listant les personnes à prévenir (sans limitation de nombre), l’éventuelle escalade, les moyens de communication à utiliser (mail, téléphone, serveur vocal interactif, sms voire fax, en distinguant les canaux principaux de ceux à activer en cas d’échec), et enfin la teneur du message, qui peut bien sûr être adaptée le jour J.

En cas d’alerte à déclencher, la personne d’astreinte dispose de différents moyens d’activation. Le principal est un portail internet, mais il est aussi possible de lancer une activation par d’autres médias (téléphone, sms, etc.).

Une fois l’alerte lancée, l’outil permet de suivre la progression du processus : échec ou succès des appels, retours des personnes contactées, etc.

Cette richesse fonctionnelle a pour contrepartie l’exploitabilité de la solution. Les interfaces sont riches et leur maitrise n’est pas immédiate, du moins en ce qui concerne le paramétrage.

La mise en place d’un tel outil peut aussi demander un investissement non négligeable, voire un développement spécifique pour assurer l’interface avec des éléments du SI de l’organisation comme l’annuaire des contacts. Les coûts d’entrée peuvent donc être élevés.

Au quotidien le coût est principalement constitué de l’abonnement, ces outils étant le plus souvent proposés en mode SaaS, notamment pour ne pas les exposer aux mêmes risques que ceux des clients. Les communications sont facturées à l’usage.

Un marché des EMNS loin d’être uniforme à travers le monde

Ces outils se sont principalement développés aux Etats-Unis, sous l’impulsion de réglementations fédérales (NFPA 72 2012 et DoD UFC 04-021-01). En mars dernier, le Gartner a mené une revue des EMNS présents sur le marché américain, qui a recensé plus de 50 fournisseurs ; 13 ont fait l’objet d’une étude détaillée, et 4 ont été positionnés dans le quadrant des leaders : Everbridge, MIR3, SendWordNow et AtHoc .

Pour autant, aucun de ces acteurs majeurs n’est présent en Europe, où l’on trouve généralement un acteur prépondérant par pays : Fact24 en Allemagne, AlarmTilt au Luxembourg, DolphinSystemsSikado en Suisse, etc.

Certains, comme Fact24 et AlarmTilt sont néanmoins présents sur le marché français, mais celui-ci reste atypique. Peu développé, il est en effet essentiellement adressé par des acteurs du telemarketing ou de la relation client qui ont su adapter leurs plates-formes à la transmission d’alertes (par exemple la solution GALA, qui équipe la majorité des préfectures, basée sur l’offre ContactEveryOne d’Orange ou la solution push SMS de Jet Multimedia).

Se positionnent également des acteurs issus de la surveillance et de l’alerte industrielle, avec des outils en mesure de s’interfacer avec différents canaux de communication pour proposer un service équivalent à un EMNS.

Consulter le marché pour trouver l’outil qui saura accompagner une organisation de crise définie au préalable

Avant d’envisager le recours à un EMNS, il est nécessaire d’être au clair sur sa gestion de crise et sur les modalités d’alerte et d’information de ses collaborateurs : acteurs mobilisés, messages délivrés, information avec acquittement de collaborateurs, etc. Comme à chaque fois, l’outil doit venir accompagner un processus en place, et non pas permettre de le définir.

Une fois ce pré-requis atteint,  le recours à EMNS est de nature à accélérer les phases d’alerte et accompagner le dispositif de crise. Ceci est d’autant plus vrai pour les organisations de grande taille, géographiquement réparties ou ayant des modalités d’astreinte complexes.

Reste dès lors à trouver le bon outil, qui saura répondre au besoin, être disponible le jour J, et dont on est sûr que les communications seront transmises, le tout à un coût raisonnable. Pour y parvenir, il faudra se demander quelles sont les fonctionnalités qui serviront à accompagner la gestion de crise, et être en mesure de les distinguer de celles qui constitueront un plus. Puis consulter le marché sur cette base pour trouver l’outil adéquat.

Cet article Alerter en cas de crise : faut-il passer par un EMNS (Emergency Mass Notification System)? est apparu en premier sur RiskInsight.

Qu’en est-il des aspects sécurité de la dernière mouture de l’OS ?

Les deux versions précédentes (Vista et Windows 7) avaient fait l’objet d’une communication sécurité appuyée.

Windows 8 ne déroge pas à la règle, et de nombreux détails sont d’ores et déjà connus : Microsoft annonce plusieurs évolutions substantielles des outils de protection, mais ce n’est pas là que se trouve la vraie révolution qui se prépare.

Des évolutions et de nouvelles fonctions de sécurité

Tout d’abord, les mécanismes existants sont presque tous améliorés (chiffrement BitLocker, contrôle des logiciels AppLocker, ainsi que l’ASLR qui charge le système dans des zones mémoire aléatoires pour éviter les attaques). L’antimalware Windows Defender sera capable de détecter de nouveaux types de logiciels malveillants, et le navigateur Internet Explorer 10 gagnera en robustesse.

Ces annonces ne changeront pas à elles seules le paysage sécuritaire de Windows. Une fonction faisant son apparition méritera tout de même une attention particulière : Windows-to-Go.

Elle permettra d’utiliser une version portative du poste de travail Windows 8 de l’entreprise, sur clé USB. Les opportunités d’usage sont multiples : fourniture d’un « poste virtuel » entreprise aux prestataires à moindre coût, tests applicatifs, clés prêtes à l’usage en cas de déclenchement d’un plan de continuité informatique… Il s’agit même d’une réponse possible aux problématiques de BYOD.

Malgré ces évolutions, les cellules de veille et de gestion de la sécurité, ainsi que les éditeurs de solutions ont encore de beaux jours devant eux : les failles de sécurité ne disparaîtront pas par magie à court terme !

Un renouveau par les fondamentaux

La base de l’OS a cependant pris un tournant significatif vers une sécurité plus moderne.

Si l’on peut se féliciter des améliorations apportées aux fonctions de sécurité, il faut reconnaître que d’autres changements touchant au fonctionnement-même de Windows, vont être les porteurs d’une sécurité « by design », moins monolithique, et intégrée au cœur du système.

Windows 8 adopte en effet une approche qui rappelle celles des principales plates-formes mobiles du moment :

• L’utilisation d’un « magasin » d’applications vérifiées, qui va tendre à assainir l’écosystème Windows, en tentant de trouver un équilibre entre contrôle des applications et liberté d’installation.
• Une  isolation inter-applicative permettant d’éviter qu’un programme malveillant en contamine un autre.
• Le Secure Boot, mécanisme n’autorisant Windows à se lancer que si la séquence de démarrage est vérifiée comme étant  intègre, offre une piste de réponse aux rootkits (ces virus furtifs qui s’installent dans les couches basses du système, et qui ont causé des dégâts dans plusieurs grandes sociétés ces dernières années). Windows 8 abandonne par ailleurs l’utilisation du BIOS historique, pour son successeur, l’UEFI.

C’est ici que se joue le futur de la sécurité de l’OS. Microsoft tente ainsi de se mettre à la page, y compris dans le monde de la mobilité après le démarrage poussif de Windows Phone 7.

La disponibilité de Windows 8 sur les PC et tablettes (peut-être les smartphones ?) sera donc un argument de poids, en particulier pour les entreprises souhaitant éviter une trop grande fragmentation de leur parc, et donc de leur sécurité.

Reste un obstacle de taille : la rétrocompatibilité. Même si Microsoft fait des efforts importants dans ce domaine, il faudra a minima des années pour que le parc, matériel mais surtout applicatif (en particulier les applications métier) s’adapte à ce modèle de sécurité, qui est donc plutôt une cible à long terme.

En attendant la sortie du système à l’automne, il est déjà possible de le tester facilement, par exemple sur une machine virtuelle, et se faire son avis sur les avancées et les opportunités à venir !

Cet article Windows 8 : des évolutions sécurité à court terme, une révolution à long terme ? est apparu en premier sur RiskInsight.