Muscler la gestion de crise

Les crises cyber sont des crises particulières : souvent longues (plusieurs semaines), parfois difficiles à cerner (qu’a pu faire l’attaquant ? depuis combien de temps ? quels sont les impacts ?) et impliquant des parties externes elles-mêmes souvent peu préparées sur ce sujet (avocats, huissiers, autorités, fournisseurs, voire les clients…). Il est donc nécessaire d’ajuster les dispositifs existants qui n’ont pas été conçus pour intégrer la dimension cyber.

Acteur opérationnel de la gestion de la crise cyber, la DSI ne doit pas être sur-mobilisée sur l’investigation et la défense au détriment de la production et du secours. Cet aspect constitue un point d’anticipation important à ne pas négliger. Il s’agira donc d’identifier clairement les équipes à mobiliser sur la crise et d’organiser les interventions parallèles d’investigation et de construction de plan de défense.

Au-delà de l’aspect organisationnel, il faudra s’assurer de disposer également de l’outillage d’investigation (cartographie, recherche de signature de l’attaque, SI de gestion de crise indépendant, capacité d’analyse de malware inconnu…), d’assainissement (capacité de déploiement rapide de correctifs ou de « vaccin », isolation en urgence de portions non touchées du SI, isolation réseau…) et de reconstruction (accès rapide aux sauvegardes, accès aux documentations minimum de reconstruction, support des fournisseurs clés sur le SI, capacité à réinstaller massivement des postes de travail…) requis pour comprendre la position de l’attaquant, stopper sa propagation et faire repartir au plus vite l’activité.

La définition d’un guide de gestion de crise, définissant les étapes structurantes, les responsabilités macroscopiques et les points de clés de décision sera un plus. Et parce qu’il est primordial de s’exercer en amont afin d’être prêt le jour où il faut faire face à la crise, la réalisation d’exercice de crise sera un bon révélateur de la situation réelle.

Repenser les dispositifs de continuité

Les dispositifs de continuité doivent également évoluer pour s’adapter aux menaces cyber. Les solutions possibles sont nombreuses et peuvent toucher tous les types de dispositifs de continuité. Le plan de reprise utilisateur peut intégrer par exemple la mise à disposition de clés USB avec un système alternatif. Les collaborateurs pourraient l’utiliser en cas de destruction logique de leur poste de travail.

Certains établissements ont fait le choix de provisionner des volumes de postes de travail de remplacement directement avec leurs fournisseurs de matériel afin de les délivrer rapidement en cas de destruction physique.

Le plan de continuité informatique peut inclure de nouvelles solutions pour être efficace en cas de cyberattaque. La plus emblématique vise à construire des chaînes applicatives alternatives. Il s’agit de « dupliquer » une application sans utiliser les mêmes logiciels, systèmes d’exploitation et équipes de production. C’est une solution extrême, très coûteuse et difficile à maintenir, mais qui est envisagée pour certaines applications critiques dans le monde de la finance (notamment les infrastructures de paiement à caractère systémique).

D’autres solutions moins complexes sont envisagées. Il s’agit par exemple de l’ajout de contrôle fonctionnel d’intégrité dans le processus métier. Son concept repose sur la réalisation de contrôles réguliers, à différents niveaux et à différents endroits dans la chaîne applicative (« multi-level controls »). Ceci permet de détecter rapidement des attaques qui toucheraient par exemple les couches techniques (modification d’une valeur directement dans une base de données) sans avoir été réalisées par les actions métier classiques (via les interfaces graphiques). Ces mécanismes peuvent aussi s’appliquer aux systèmes d’infrastructures, par exemple en réconciliant les tickets de demande de création de compte d’administration avec le nombre de comptes réellement dans le système.

D’un niveau de complexité intermédiaire, il est possible d’envisager la définition de zone d’isolation système et réseau (« floodgate ») que l’on peut activer en cas d’attaques et qui vont isoler les systèmes les plus sensibles du reste du SI. Le SI industriel pourra, à ce titre, constituer à lui seul, une de ces zones d’isolation vis-à-vis du reste du SI.

Ces évolutions, souvent majeures, doivent s’inscrire dans une revue des stratégies de secours existantes afin d’évaluer leur vulnérabilité et l’intérêt de déployer des nouvelles solutions de cyber-résilience, en particulier sur les systèmes les plus critiques. L’évolution des Business Impact Analysis (BIA) pour inclure cette dimension est certainement une première étape clé.

Sans cybersécurité, la cyber-résilience n’est rien

Implémenter ces nouvelles mesures de cyber-résilience nécessite des efforts importants. Des efforts qui seront vains si ces solutions de secours et les systèmes nominaux ne sont pas eux-mêmes déjà sécurisés correctement et surveillés avec attention. Le RSSI est l’acteur clé pour faire aboutir ces démarches souvent entamées mais rarement finalisées. L’aide du Risk Manager (RM) – ou, s’il est désigné, son Responsable du Plan de Continuité d’Activité (RPCA) – sera alors un plus. Il est aujourd’hui communément acquis qu’il est impossible de sécuriser des systèmes à 100%, il faut donc accepter la probabilité d’occurrence d’une attaque et c’est à ce moment-là que le RM ou son RPCA prendra tout son rôle.

Cet article est issu de notre focus « Cyber-résilience : plier pour ne pas rompre« .

Cet article Cyber-résilience : plier pour ne pas rompre (2/2) est apparu en premier sur RiskInsight.

Face à une cyberattaque majeure, qu’elle soit destructive ou qu’elle entraîne une perte de confiance dans les systèmes clés, le premier réflexe pour une majorité d’entreprises est d’activer le plan de continuité d’activité (PCA). Celui-ci est un élément majeur de la stratégie de résilience des organisations ; afin d’en assurer la survie lorsque surviennent des sinistres d’ampleur entraînant l’indisponibilité de ressources informatiques, d’infrastructures de communication, d’immeubles voire de collaborateurs.

Or les cyberattaques majeures, destructives comme Wannacry ou NotPetya ou provoquant une perte de confiance dans les infrastructures (réseau, gestion des accès, gestion du parc…) comme les attaques ciblées en profondeur (APT), n’ont pas été prises en compte lors de l’élaboration de la majorité des PCA. Ces derniers, focalisés sur un enjeu de disponibilité, n’appréhendent pas les problématiques de la destruction simultanée et de la perte de confiance dans le SI induites par les cyberattaques.

En effet, les dispositifs de continuité du SI, le plus souvent liés aux ressources qu’ils protègent, sont également affectés par ces attaques. Depuis plus de dix ans, les dispositifs de continuité (utilisateurs ou informatiques) ont adopté les principes de mutualisation des infrastructures et de secours « à chaud » à la fois pour répondre aux exigences de reprise rapide et d’une meilleure exploitabilité. De fait, cette « proximité » entre le SI nominal et son secours rend vulnérables les dispositifs de continuité aux cyberattaques.

Quelles vulnérabilités pour les dispositifs de continuité ?

À titre d’exemple, lors d’une intervention de crise suite à l’attaque NotPetya, l’idée d’utiliser les postes de secours présents sur le site de repli a très rapidement été évoquée. Malheureusement ceux-ci avaient été détruits de la même manière que les sites nominaux car ils partageaient les mêmes systèmes de gestion de parcs et les mêmes vulnérabilités. Les investissements et les efforts investis dans les dispositifs de continuité ont semblé à ce moment très vains.

Enfin, les sauvegardes, établies sur une base souvent quotidienne, constituent pour la plupart des organisations le dispositif de dernier recours pour reconstruire le SI.

Malheureusement, en cas de compromission en profondeur, du fait de l’antériorité de l’intrusion (souvent plusieurs centaines de jours avant sa détection), ces sauvegardes embarquent de fait les éléments malveillants : malwares, camps de base, mais aussi les modifications déjà opérées par les attaquants. De plus, la continuité en tant que telle des systèmes de sauvegarde est souvent négligée. Lors de gestion de crise sur NotPetya, les serveurs gérant les sauvegardes ont eux-mêmes été détruits. Les restaurer a pris plusieurs jours vu leur complexité et leur imbrication dans le SI (nécessité de disposer d’un ActiveDirectory pour lancer des restaurations alors que la sauvegarde de l’AD était nécessaire pour le reconstruire, reconstruction de l’index des bandes de sauvegardes détruit avec le reste…).

S’agissant des SI industriels, les constats sont tout aussi manifestes. Les systèmes numériques industriels sont résilients à des pannes techniques ou des incidents mécaniques anticipés. En revanche, ils n’ont que rarement intégré, dès leur conception, les potentialités d’une malveillance humaine et ne disposent souvent pas de mécanismes de sécurité avancés. Du reste, leur cycle de vie long (plusieurs dizaines d’années) les expose à l’exploitation de vulnérabilités parfois anciennes. Enfin l’indépendance des chaînes de contrôle (Systèmes Instrumentés de Sécurité, cf. encadré ci-après) vis-à- vis des systèmes numériques qu’elles supervisent n’est pas toujours appliquée.

Des scénarios d’attaques majeures illustrés par des attaques récentes

La destruction logique ou l’indisponibilité d’une grande partie du système d’information.

Concrétisé par les attaques de vrai-faux rançongiciels Wannacry et NotPetya, ce type d’attaque entraîne une indisponibilité massive du fait du chiffrement des fichiers de données et/ou du système d’exploitation. Les sociétés touchées par ce type d’attaque (Merck, Maersk, Saint Gobain, Fedex… mais aussi Sony Pictures ou Saudi Aramco) ont perdu jusqu’à plus de 95% de leurs systèmes d’information (des dizaines de milliers d’ordinateurs et de serveurs) en un délai souvent inférieur à 1h. La situation au démarrage de la crise est très difficile car il n’y a plus aucun moyen de communication et d’échange au sein de l’entreprise, y compris au sein de la DSI. Les victimes ont communiqué sur des pertes de plusieurs centaines de millions d’euros suite à ces attaques.

La compromission et la perte de confiance dans le système d’information

Il s’agit d’attaques ciblées qui ne remettent en pas en cause le bon fonctionnement du système mais qui visent à donner aux attaquants l’accès à l’ensemble des systèmes de l’entreprise (messagerie, fichiers, applications métiers…), leur permettent d’usurper l’identité de n’importe quel employé et de réaliser des actions en leur nom. Les attaquants peuvent ainsi exfiltrer tout type de données ou réaliser des actions métiers demandant plusieurs validations successives. Ces attaques ont touché de très nombreuses entreprises dans tous les secteurs avec comme conséquences des fraudes massives, comme celles ayant touché la banque du Bangladesh, ou des vols de données financières et de paiements comme celles ayant touchés plusieurs groupes de distribution aux Etats-Unis dont Target ou encore Home Depot. La situation au démarrage de la crise est complexe en raison d’une conjugaison de plusieurs éléments aggravants : perte de confiance dans le système d’information et flou grandissant sur les actions et objectifs. Il s’agit alors d’investiguer discrètement jusqu’à pouvoir déloger l’attaquant et reconstruire un système sain. Les victimes touchées par ces attaques ont fait état d’impacts financiers de plusieurs centaines de millions d’euros.

Cet article est issu de notre focus « Cyber-résilience : plier pour ne pas rompre« .

Cet article Cyber-résilience : plier pour ne pas rompre (1/2) est apparu en premier sur RiskInsight.

Les cyberattaques mettent en lumière les limites de la résilience actuelle et des plans de continuité d’activité

La continuité d’activité est souvent présentée comme un des éléments majeurs de la stratégie de résilience des organisations. Ainsi, face à des sinistres d’ampleur entraînant l’indisponibilité de ressources informatiques, d’infrastructures de communication, d’immeubles voire de collaborateurs, les organisations se sont dotées de plans de continuité d’activité (PCA) de manière à assurer leur survie.

Or les cyber-attaques, dans leur forme moderne, n’ont pas été prises en compte lors de l’élaboration de la majorité des PCA. Ces derniers focalisés sur un enjeu de disponibilité, n’appréhendent pas la problématique de perte de confiance dans le SI induite par les cyber-attaques.

De plus, les dispositifs de continuité du SI, le plus souvent intiment liés aux ressources qu’ils protègent, sont également affectés par ces attaques. En effet, depuis plus d’une décennie, les dispositifs de continuité (repli utilisateurs ou secours informatique) ont adopté les principes de mutualisation des infrastructures et de secours « à chaud » à la fois pour répondre aux exigences de reprise rapide des métiers et au besoin d’une meilleure exploitabilité. De fait, cette « proximité » entre le SI nominal et son secours rend vulnérables les dispositifs de continuité aux cyber-attaques. A titre d’exemple, les postes de secours dédiés et connectés des sites de repli sont aujourd’hui très souvent exposés aux mêmes risques de contamination (et destruction) que les postes nominaux.

Les historiques plans de reprise/secours « à froid » (consistant souvent à activer les systèmes de secours en cas d’incident) concernent désormais de moins en moins d’applications, et il s’agit souvent d’applications secondaires.

Enfin, les sauvegardes, établies sur une base souvent quotidienne, constituent pour la plupart des organisations le dispositif de dernier recours pour reconstruire le SI. Malheureusement, du fait de l’antériorité de l’intrusion (souvent plusieurs centaines de jours avant sa détection), ces sauvegardes embarquent de fait les éléments de compromission : malwares, camps de base, mais aussi les modifications déjà opérées par les attaquants.

La gestion de crise et les dispositifs de continuité doivent être repensés

Les crises cyber sont des crises particulières : souvent longues (plusieurs semaines), parfois difficiles à cerner (qu’a pu faire l’attaquant ? depuis combien de temps ? quels sont les impacts ?) et impliquant des parties externes (autorités, fournisseurs…) eux-mêmes souvent peu préparés sur ce sujet. Ces éléments démontrent qu’il est nécessaire d’ajuster les dispositifs existants. Un des thèmes vise à anticiper des astreintes et des rotations des personnels clés. Au-delà de l’aspect interne, il faudra s’assurer de disposer également des expertises en SSI (investigation numérique, méthode d’attaque…) et de l’outillage de recherche et d’assainissement requis pour comprendre la position prise par l’attaquant dans un SI toujours plus grand et dont les frontières sont de plus en plus difficiles à déterminer. Et parce qu’il est primordial de s’exercer en amont afin d’être prêt le jour où il faut faire face à la crise et anticiper certaines réponses, la réalisation d’exercice de crise sera un bon révélateur de la situation réelle.

Dans ce contexte, les dispositifs de continuité doivent également évoluer, voire être complètement repensés. Les solutions possibles sont nombreuses, nous pouvons citer en particulier la construction de chaînes applicatives alternatives (non similar facilities), visant à « dupliquer » une application sans utiliser les mêmes logiciels, systèmes d’exploitation et équipes de production. Il s’agit là d’une solution ultime, envisagée pour certaines applications critiques dans le monde de la finance. D’autres solutions, moins complexes, comme l’ajout de contrôle fonctionnel d’intégrité dans le processus métier pour détecter rapidement une attaque (multi-levels controls) ou encore la définition de zone d’isolation système et réseau (floodgate) sont possibles.

Ces évolutions, souvent majeures, doivent s’inscrire dans une revue des stratégies de secours existantes afin d’évaluer leur vulnérabilité et l’intérêt de déployer des nouvelles solutions de cyber-résilience, en particulier sur les systèmes les plus critiques. L’évolution des Business Impact Analysis (BIA) pour inclure cette dimension est certainement une première étape clé.

Sans cybersécurité, la cyber-résilence n’est rien

Implémenter ces nouvelles mesures de cyber-résilience nécessite des efforts importants. Des efforts qui seront vains si ces solutions de secours et les systèmes nominaux ne sont pas déjà sécurisés correctement et surveillés avec attention. Le RSSI est l’acteur clé pour faire aboutir ces démarches souvent entamées mais rarement finalisées. L’aide du Responsable du Plan de Continuité d’Activité (RPCA) sera alors un plus ! Il est aujourd’hui impossible de sécuriser des systèmes à 100%, il faut donc accepter la probabilité d’occurrence d’une attaque et c’est à ce moment-là que le RPCA prendra tout son rôle.

Protéger, détecter, réagir, assainir et reconstruire, voilà donc les piliers d’une cyber-résilience solide. Cyber-résilience qui ne pourra être atteinte que si le RPCA et le RSSI travaillent main dans la main !

Cet article Cyber-résilience : allier les forces du RPCA et du RSSI pour franchir une nouvelle étape est apparu en premier sur RiskInsight.

Parmi les maximes bien connues des risk managers, il y a cette phrase de Donald Rumsfeld en 2002, alors qu’il défendait l’intervention américaine en Irak :

“ […] there are known knowns; there are things we know we know.
We also know there are known unknowns; that is to say we know there are some things we do not know.
But there are also unknown unknowns – the ones we don’t know we don’t know.
And […] it is the latter category that tend to be the difficult ones. ”

Cette citation traduit bien la situation à laquelle les organisations font face :

• « known knowns » : ce sont les risques maîtrisés, dont l’occurrence et les conséquences sont évaluées et connues ;
• « known unknowns » : ce sont les risques identifiés et recensés que les organisations ont choisis d’adresser à court ou moyen terme ;
• « unknown unknowns » : ce sont les événements qui n’ont pas été repérés par le « radar » de la gestion des risques ou dont l’occurrence apparaît infime aux regards des autres risques.

Le Cygne Noir de Nassim Nicholas Taleb : théoriser l’imprévisible

En 2007, Nassim Nicholas Taleb développe dans (The Black Swan, publié en 2007) la théorie dite du « cygne noir ». Elle englobe les « unknown unknows » et caractérise les évènements imprévisibles aux impacts majeurs de nature à totalement changer l’environnement ou le destin d’une organisation. Les exemples sont malheureusement de plus en plus nombreux :

• Catastrophes naturelles : ouragan Katrina aux USA (2005), séisme et tsunami dans l’océan indien (2004) ou au Japon (2011), éruption d’Eyjafjöll en Islande (2010), inondations en Thaïlande et en Australie (2011), etc.
• Catastrophes industrielles : explosion de l’usine AZF (2001), incendie de la plateforme Deepwater Horizon (2010), sinistre des centrales de Fukushima (2011), etc.
• Chocs financiers : choc pétrolier (1973 et 1979), chute d’Enron (2001), faillite Lehman Brothers (2008), fraude Madoff (2008), défauts d’Etats (Mexique 1982, Russie 1998, Argentine 2001, Grèce 2011), etc.
• Phénomènes géopolitiques : chute du mur de Berlin (1989), attentats du World Trade Center (2001), guerre en Irak (2003), printemps Arabe (2011), etc.

Par nature, ces évènements se produisent à une fréquence imprévisible. Toutefois notre dernière décennie a montré l’accroissement de leur résurgence. Pour les seules catastrophes naturelles, 2011 a constitué l’année la plus coûteuse de toute l’histoire de l’industrie de l’assurance (~380 milliards de dollars selon l’ONU).

De plus, conséquence d’un monde globalisé et interconnecté, ces phénomènes ont des impacts collatéraux sur l’ensemble des économies de la planète (entre pays producteurs et consommateurs).

Des évènements que les entreprises ne peuvent plus ignorer

Les grandes organisations, qui agissent aujourd’hui sur un périmètre global, ne peuvent plus ignorer ces risques, susceptibles de les impacter directement ou indirectement via leurs fournisseurs, leurs partenaires et leurs clients.

Mais comment les appréhender ? A la différence des risques « traditionnels », impossible de prévoir où, quand et comment ces évènements peuvent se produire. Cela impose un changement de paradigme dans la manière de les adresser, qui fera l’objet d’une prochaine tribune.

Cet article Les chocs extrêmes : des risques que les entreprises globales ne peuvent plus se permettre d’ignorer (partie 1) est apparu en premier sur RiskInsight.

Si la gestion de crise lors d’une attaque doit suivre les 4 principes clés évoqués dans notre précédent article, elle doit surtout en intégrer l’anticipation dans ses mécanismes.

Une stratégie à moyen terme basée sur l’anticipation des attaques ciblées

Dès aujourd’hui, il est nécessaire de refondre les processus de gestion de crise. Les scénarios de cybercriminalité doivent être inclus dans les procédures opérationnelles (modalités de réponse, SI spécialisé…). Les relations avec les autorités compétentes doivent être créées ou renforcées dans le but d’accélérer la phase de mobilisation de ces acteurs et de maîtriser les circuits de communication.

Une stratégie de communication claire doit être définie en fonction des acteurs évoluant dans et autour de l’organisation. Les obligations de demain (notification aux clients des fuites de données à caractère personnel…) doivent être anticipées afin de garantir le moment venu un respect des règlementations en vigueur. De ce fait, il ne sera plus possible de garder la confidentialité sur le fait qu’une crise est en cours.

Les attaques ciblées étant souvent constituées d’une somme d’incidents unitaires, il est nécessaire de revoir en parallèle les processus de gestion des incidents pour s’inscrire dans une démarche itérative, garantissant un état de veille constant, une rapidité d’intervention et une prise de recul.

À moyen terme, évaluer son attractivité et connaître ses actifs clés permettent de déterminer les informations attirantes pour des attaquants. Le secteur d’activité et le positionnement sur le marché sont des éléments déterminants. Au-delà de données internes, les relations entretenues avec certains partenaires et / ou clients peuvent augmenter l’attractivité du SI aux yeux d’attaquants. Cette évaluation doit s’inscrire dans une revue régulière des risques avec les métiers.

Enfin, il faut mettre en place des mesures avancées pour permettre une sécurisation renforcée des cibles identifiées avec les métiers en sanctuarisant les périmètres les plus sensibles (applications métiers clés, VIP / COMEX…) mais aussi les systèmes techniques clés (serveurs et postes d’administration, infrastructure à effet d’amplification comme la télédistribution ou l’Active Directory).

Des approches plus actives (demande de fermeture des sites utilisés pour l’exfiltration, honeypot …) peuvent être envisagées.

Complexifier l’attaque pour en diminuer sa rentabilité

Les attaques ciblées représentent un challenge pour les grandes organisations qui ne sont pas habituées à gérer ce type de crise silencieuse, à grande échelle, mêlant métier et SI et entraînant une perte de confiance dans ce dernier. Leur gestion nécessite de revoir les processus en place mais également de prévoir des actions pour rendre l’attaque plus difficile, faciliter leur détection et renforcer les capacités de réaction.

La mise en place de ces éléments permettra de complexifier les actions de l’attaquant et, à terme, de rendre l’attaque moins rentable ! C’est certainement une des clés de réponse face à ces nouvelles menaces.

Lire la première partie

Pour en savoir plus, lire le focus attaques ciblées, une refonte nécessaire de la gestion de crise.

Cet article Attaques ciblées : comment gérer le risque en amont ? est apparu en premier sur RiskInsight.

La cybercriminalité ne cesse de croître. Les cas concrets se multiplient.

Les retours d’expérience montrent la difficulté à gérer des crises d’un nouveau type. Ces attaques ciblées sont souvent des crises silencieuses qui atteignent directement la confidentialité des données sans remettre en cause le fonctionnement visible du SI. Ces crises sont difficiles à matérialiser, à traiter et finalement à clore de manière définitive.

Comment réagir à ces attaques ? Quelles démarches et organisations doit-on mettre en place pour se préparer au mieux ? Quelles actions de traitements doivent être mises en œuvre ?

Refondre les piliers de la gestion de crise

Une attaque ciblée n’est pas une crise SI mais bien une crise métier

En effet, si cette attaque a lieu c’est pour voler ou altérer des données métiers. Il est donc primordial d’impliquer les métiers et d’identifier les enjeux métiers actuels (contrats importants, fusion / acquisition, R&D…) afin d’anticiper les cibles de l’attaque et d’agir pro-activement. Dans le même esprit, et suivant les contextes, un support auprès d’entités étatiques peut également être recherché. Les équipes SI, malgré leur vigilance, ont un périmètre d’observation trop large pour être attentives sur tous les fronts. Identifier les cibles métiers majeures permettra de focaliser l’attention sur les périmètres sensibles.

Augmenter sa visibilité sur le système d’information

Pour analyser l’attaque et proposer des contre-mesures efficaces, il est nécessaire de détecter et de rapprocher les successions d’incidents unitaires et d’événements suspicieux. Pour cela la mobilisation des équipes d’experts « forensics » est essentielle. Ils seront à même de comprendre le fonctionnement des codes malicieux utilisés pour l’attaque et de pouvoir proposer des plans d’actions techniques pertinents. Ces ressources, encore trop rares aujourd’hui, devront être rapidement mobilisées.

L’utilisation d’outils pour capter les « signaux faibles » (analyses de journaux, sondes réseaux et détection d’intrusion) est également un vrai plus malheureusement encore peu généralisé. Notre retour d’expérience montre qu’il est possible de déployer rapidement ce type d’outil pendant une crise mais il nécessite un degré d’expertise fort pour être efficace.

S’astreindre à prendre du recul face à une multitude d’attaques silencieuses et trompeuses

Il est important de prendre régulièrement du recul, malgré la multitude d’évènements, pour comprendre la finalité de l’attaque, son évolution et définir le mode de réponse. La cellule de pilotage devra donc être séparée des opérations les plus « terrains » pour garder ce recul nécessaire.

Attention également à la logique de diversion, souvent mise en oeuvre par les attaquants (attaque en déni de services, sur d’autres serveurs peu critiques…). Il est conseillé dans ce genre de situation de rester focalisé sur les cibles potentielles définies avec les métiers et vigilants pendant les périodes d’inactivité de l’organisation (HNO, week-end, jours fériés).

Une limite souvent rencontrée dans une telle crise est la mobilisation de trop nombreux acteurs décisionnels au regard d’un faible nombre d’acteurs opérationnels en capacité à réaliser les actions. La longue durée d’une attaque (pouvant s’étaler sur plusieurs mois) nécessite la mise en place d’un rythme de gestion différent d’une crise classique. Une organisation adaptée doit être mise en place dans la durée, en prévoyant des rotations des acteurs impliqués.

Disposer d’un SI de crise parallèle et indépendant

L’expérience montre que les attaquants réussissent souvent à prendre le contrôle de l’Active Directory ou encore de la messagerie. Ils sont alors en mesure « d’écouter » les décisions prises par la cellule de crise et de les anticiper. Pour réagir efficacement durant la crise, il est donc crucial de disposer de postes de travail durcis hors des domaines d’administration classique et d’un service de messagerie spécifique. L’utilisation de services Cloud est possible. Attention cependant, les attaquants ayant pu également compromettre les messageries personnelles de tout ou partie des collaborateurs…

Admettre la perte de confiance dans le SI et la regagner

La découverte d’une intrusion majeure a souvent pour conséquence une perte de confiance en son SI vu le nombre et la criticité des serveurs compromis. Pour reprendre le contrôle de ceux-ci, il est souvent nécessaire de reconstruire des socles sains, et en particulier de réinstaller complètement l’Active Directory. À partir de ces socles sains, il sera alors possible de recréer progressivement des zones de confiance en privilégiant les fonctions les plus sensibles de l’organisation.

Les investissements liés à ces plans de reconstruction peuvent être très lourds (nos retours d’expérience montrent qu’ils dépassent fréquemment la dizaine de millions d’euros) et l’attention ne doit en aucun cas être relâchée dans ces zones assainies pour éviter une nouvelle attaque. Il faudra alors mettre en place tous les processus nécessaires pour garantir leur sécurité (administration sécurisée, analyse des journées, filtrage réseaux, gestion des accès fins…).

À suivre …

Cet article Attaques ciblées : une refonte nécessaire de la gestion de crise est apparu en premier sur RiskInsight.

Le RaaS : fer de lance des « Cloud Recovery Services »

Comme pour beaucoup de ce qui tourne autour du cloud, il est parfois difficile de donner une définition précise de ce dont on parle, tant une même appellation peut cacher des offres différentes. Nous utiliserons la définition suivante : « Cloud Recovery Service => secours d’un système d’information sur une infrastructure virtualisée, hébergée par un tiers, disponible à la demande et facturée à l’utilisation. »

L’éventail des possibilités est très large :

•  d’une sauvegarde externalisée des données critiques en mode cloud (« Backup-as-a-Service ») …
•  …en passant par la construction par le client lui-même de son secours sur la base d’une prestation de type « IaaS » [2] …
•   …jusqu’à une offre complètement managée intégrant le suivi du SI nominal et des mécanismes de bascule planifiés. C’est ce type de prestations que l’on retrouve sous l’appellation « Recovery-as-a-Service ».

 Quel est l’intérêt de passer au RaaS ?

L’utilisation du RaaS résulte avant tout d’un choix économique. Sur le papier du moins, le secours paraît adapté au modèle de facturation du cloud (pas de sinistre > allocation limitée de ressources > coût d’utilisation réduit), alors qu’un secours traditionnel implique de stocker, héberger et faire évoluer des infrastructures, des serveurs et des applications sur un site de secours.

Mais à y regarder de plus près, les économies ne sont pas toujours au rendez-vous et varient grandement en fonction des applications. Si certaines d’entre elles, peu consommatrices de données, sont les candidates idéales pour le RaaS (des études indépendantes font état d’environ 80% d’économies [3] pour leur secours par rapport à l’approche traditionnelle), le ROI pour les applications plus lourdes et/ou pour lesquels les exigences de continuité sont plus fortes s’avère discutable. En effet, plus les RTO et RPO seront exigeants, plus le niveau de service devra être élevé (allocation renforcée de ressources, mécanismes de réplication des données site-à-site, liens sécurisés, supervision 24/7, etc.) entraînant une envolée des coûts à la clef.

Le RaaS s’assimile, à ce stade de sa maturité, au mieux à du « warm recovery ». En effet, il est aujourd’hui illusoire de penser que les solutions proposées permettront de la haute-disponibilité : délais d’activation, délais relatifs aux opérations de bascule notamment au niveau du réseau, délais de restauration en cas de corruption des données, etc.

En outre, le RaaS repose essentiellement sur des mécanismes de virtualisation de serveurs (le plus souvent restreints aux architectures Intel x86, à l’exception de quelques fournisseurs), que ne supportent pas tous les progiciels du marché, a fortiori les applications propriétaires des clients.

Ainsi, le fait de vouloir tirer pleinement parti de la compétitivité économique du RaaS tout en répondant aux besoins Métiers réduit son utilisation à une certaine catégorie d’applications. Ce faisant, il cantonne le RaaS en tant que solution complémentaire à un secours traditionnel, ce qui peut paradoxalement devenir une source de complexité, du fait de la cohabitation de deux SI de secours. Néanmoins, deux cas d’usage du RaaS émergent pour les organisations concernées :

•  La couverture des applications virtualisées ou éligibles à la virtualisation à coût optimisé
•  L’extension du secours à des périmètres qui n’auraient pas pu être intégrés au Plan de Continuité Informatique de l’organisation, pour une meilleure couverture au meilleur coût.

A qui s’adressent les offres RaaS ?

Étant donné son modèle économique et sa structure technique, le RaaS semble plus adapté aux moyennes structures (qui n’ont pas souvent la surface financière pour mettre en œuvre et gérer en propre un site de secours) et notamment à celles qui ont opéré la virtualisation de leur SI. Les études prospectives [4] le montrent : ce sont elles qui tireront la croissance de ce marché dans les prochaines années.

Les grandes organisations déjà dotées de Plans de Continuité Informatique seront probablement moins intéressées mais pourront néanmoins trouver dans le RaaS des réponses ciblées à certains de leurs besoins.

Le RaaS : une offre mature ?

Comme pour nombre de cloud services, le RaaS n’a pas encore atteint sa pleine maturité : en témoigne le foisonnement des offres et des prestataires notamment aux États-Unis et au Royaume-Uni. Au-delà des acteurs historiques de la continuité informatique se positionnent des pure-players des cloud recovery services et de plus en plus des hébergeurs informatiques, convertis au cloud.

Le marché se structure, les offres évoluent en recherchant notamment de la complémentarité avec les cloud services : des initiatives d’interopérabilité entre services IaaS et RaaS se font jour pour assurer du secours « cloud-to-cloud » par exemple.

A ce stade et en terme de couverture de risques, le RaaS doit faire ses preuves. Concrètement les infrastructures dévolues au RaaS reposent sur encore peu de datacenters. Le client qui souhaitera se prémunir de sinistres affectant des zones géographiques particulières (ou étendues) devra se rapprocher du fournisseur de service RaaS qui l’intéresse pour vérifier que son ou ses sites ne sont pas exposés aux mêmes risques.

En France, le marché reste jeune et sans retour d’expérience significatif de déploiement. Les grands offreurs français s’appuient, aujourd’hui, sur les infrastructures anglo-saxonnes ou nord-américaines de leur maison-mère (ce qui potentiellement impacte la qualité de service, le niveau de sécurité, les engagements contractuels, etc.). Reste donc aux acteurs, anciens comme nouveaux, à démontrer toute la pertinence de leurs offres, en particulier sur la gamme des services managés, probablement les plus recherchés par les DSI.

[1] On rencontre également l’acronyme DRaaS (Disaster Recovery-as-a-Service)

[2] IaaS : Infrastructure-as-a-Service

[3] « Disaster Recovery as a Cloud Service : Economic Benefits & Deployment Challenges »

[4] « Gartner Says 30 Percent of Midsize Companies Will Use Recovery-as-a-Service by 2014 »

Cet article Recovery-as-a-Service (RaaS) : une révolution pour le secours informatique ? est apparu en premier sur RiskInsight.

En matière de disponibilité, les promesses du cloud n’engagent que ceux qui y croient !

L’Hyper Cycle 2011 du Gartner a positionné en août dernier le cloud dans sa phase de « désillusion ». Force est de constater que les incidents à répétition que rencontrent les grands noms du cloud depuis l’année passée ne font que confirmer cette état de « disgrâce ».  Petit rappel des deux faits marquants de ce début d’année.

Le 29 février à 1h45 (GMT), la plate-forme de cloud services Windows Azure tombe sur 4 de ses 6 plaques mondiales pendant une durée oscillant entre 12h et 48h. Cette interruption de services a son origine dans un bogue logiciel générant une erreur de calcul de dates sur les années bissextiles ; à la décharge de Microsoft,  il est vrai qu’Azure ouvert en 2010 n’a pas connu d’autre année bissextile que 2012. Cette panne a laissé sur le carreau plusieurs sites clés, dont la fameuse place de marché du gouvernement britannique, le « CloudStore ».

Ce 7 mars vers 5h (GMT), le service Facebook tombe en panne plus de 3 heures sur les plaques  Europe, Afrique et Moyen-Orient. Principale cause avancée, celle de la défaillance des serveurs DNS européens de Facebook entraînant l’inaccessibilité du site. Pointés du doigt, les Anonymous ont démenti être mêlés à cet incident. En tout état de cause, le communiqué officiel de Facebook ne laisse filtrer aucune explication. Rappelons-nous que Facebook avait déjà rencontré un problème de configuration BGP en août 2010.

Ces deux incidents majeurs font écho aux non moins médiatiques pannes rencontrées par les promoteurs du cloud computing ; remémorons-nous les incidents de Google (trois en 2009, celle de 05/2010, puis de 02/2011 et 09/2011), d’Amazon et de son service EC2 (12/2010, 04/2011, 08/2011), du précurseur Salesforce.com (02/2008, 01/2009, 01/2010) et du plus récent VMware Cloud Foundry (05/2011).

S’agissant de « résilience », les atouts du cloud ont maintes fois été présentés, on citera en substance :

• Taux de disponibilité avantageux (Salesforce.com affiche 99,9%)
• Répartition et duplication des ressources sur des lieux géographiques différents
• Accessibilité permanente, en tout point du globe
• Standardisation de l’offre technique, facilitant sa reproductibilité sur les datacenters

Pour autant, le cloud n’en reste pas moins une machinerie complexe par construction ; du fait de l’empilement des services qui le composent, du volume des ressources qui le constitue et, paradoxalement, de leur répartition sur le globe.

Au-delà de cette complexité qui impacte les gestes d’exploitation et de maintenance au quotidien s’ajoutent également les risques posés par le modèle de standardisation retenu. Les effets d’une erreur de manipulation, d’un bogue ou d’une vulnérabilité se font ressentir rapidement sur tout ou partie des infrastructures sous-jacentes.

Difficile dans ces conditions, face à des offres « boîtes noires » peu dissertes sur leur fonctionnement interne, d’accorder un crédit sans limite aux niveaux de disponibilité avancés. Du reste, le cloud public, universel dans son usage et par sa fréquentation, ne permet pas de préjuger de la manière et avec quelle priorité seront traitées, en cas de sinistre, les entreprises (grandes ou petites) en regard des individuels que nous sommes.

Des axes de progrès pour une meilleure résilience du cloud

Ces incidents à répétition témoignent d’une maturité encore insuffisante du marché et des fournisseurs, qui fonctionnent encore pour certains « au coup par coup ». Pour autant, le tableau n’est pas si noir, le modèle vertueux d’amélioration continue se met en place, sous l’impulsion notamment de l’alliance CSA (cloud security alliance)  qui promeut de bonnes pratiques en matière de sécurité et de résilience du cloud, des exigences d’acteurs clefs et /ou de gouvernements (PCI DSS, FISMA, HIPAA, etc.) et, il faut bien le dire, au gré des incidents vécus.

D’autant que la problématique de continuité tout comme de sécurité est au cœur des préoccupations des fournisseurs de service ; en affectant la confiance de leurs clients, présents et futurs, elle touche directement leur business model. Rappelons-nous enfin que l’une des promesses essentielles du cloud computing est d’améliorer la résilience du service rendu, parce qu’il est précisément « partout dans le nuage ».

A y regarder de plus près, le nombre d’incidents rencontrés par les acteurs du cloud est équivalent sinon inférieur à ce que rencontrent les entreprises. Le principal facteur aggravant tient au fait que la surface d’impact est sans commune mesure avec celles des SI des entreprises (ce sont des dizaines de milliers voire de millions d’usagers qui sont touchés).

Les fournisseurs de service entrent doucement dans la phase de maturation de leurs offres ; ils renforcent progressivement leurs dispositifs de continuité, prennent davantage en compte le facteur humain (source indéfectible d’erreur !) et apprennent aussi à mieux communiquer auprès de leurs clients.

Mais il ne faut pas croire au cloud « infaillible ». Aussi, les entreprises consommatrices de services cloud doivent-elles prévoir des processus de continuité de leurs métiers les plus sensibles et de préservation de leurs données les plus critiques.

C’est enfin le prochain challenge des fournisseurs que de prouver et démontrer les performances de leurs services cloud face à ceux des SI des grandes organisations !

Cet article Panne Facebook : symptomatique de la résilience du cloud computing ? est apparu en premier sur RiskInsight.