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.

Télécommunications : le réseau mobile Orange down

Si l’on demandait aux Français quelle panne les a le plus marqués en 2012, il y a fort à parier qu’ils parleraient d’Orange : au mois de juillet, l’opérateur (et d’autres par ricochet) a subi une interruption de son réseau mobile pendant plusieurs heures suite à un incident logiciel. Moins d’une semaine plus tard, c’était au tour d’O₂ de subir le même sort au Royaume-Uni pour quasiment 24h. Preuve, s’il en fallait une, que l’on ne doit pas considérer la résilience des réseaux mobiles comme une évidence.

Énergie : la plus grosse panne électrique de l’histoire

Il en va de même pour les réseaux électriques. Si la dernière panne générale en France remonte à 1978, des interruptions significatives ont été enregistrées récemment (Chili et Japon en 2011, USA en 2008 et 2003). Fin juillet 2012, l’Inde a établi un triste record : la plus grande panne d’électricité jamais enregistrée, avec 670 millions d’usagers touchés pendant plusieurs jours. En cause : une capacité de production qui a du mal à suivre la croissance de la population et de la demande, combinée à une sècheresse qui a diminué la production hydro-électrique du pays.

Banque et finance : un des bugs les plus coûteux après le blackout aux USA de 2003 et la destruction d’Ariane 5 en 1996

Les pannes et bugs logiciels occupent une bonne place cette année dans le top des causes des incidents majeurs. C’est ce qui s’est passé pour Knight Capital, qui a subi en août l’un des bugs les plus chers de l’histoire : 440 millions de dollars envolés. Un système de trading haute fréquence mal qualifié est à l’origine du désastre, qui ne manquera pas d’alimenter les détracteurs de la finance. Knight Capital est d’ailleurs passé proche de la banqueroute et n’a pu éviter le rachat par un de ses concurrents début 2013.

Dans le secteur bancaire, impossible de passer sur la panne informatique de Royal Bank of Scotland (RBS). Provoquée par une erreur dans un batch, elle a exigé d’importantes et nombreuses opérations manuelles des équipes informatiques ce qui a fortement retardé le traitement. Plus de 15 millions de clients ne pouvaient plus retirer de l’argent ou faire des virements pendant une semaine ! Résultat : 219 millions d’euros de dédommagements pour la banque.

Services informatiques : le cloud, toujours le cloud !

Les belles promesses de résilience de l’informatique dans les nuages avaient déjà pris un sacré coup en 2011, avec des interruptions importantes chez la plupart des acteurs majeurs du secteur. L’année 2012 a fini de tuer le rêve.

Amazon est le grand vainqueur avec au moins 4 pannes majeures en 2012, dont une le jour de Noël. Les causes sont diverses : tempête et panne électrique, bug logiciel, erreurs réseau ou erreur humaine. Chez Microsoft, la panne mondiale d’Azure en février a viré au tragicomique lorsqu’il fut révélé qu’elle provenait d’une erreur logicielle liée à l’année bissextile ! Enfin, bien que moins importantes, Google a aussi connu son lot de pannes en 2012, tout comme Facebook et Twitter.

Catastrophes naturelles : l’ouragan Sandy … entre autres

Impossible de terminer ce panorama sans évoquer les catastrophes naturelles : inondations aux Philippines, séisme en Iran et en Chine, ouragan Sandy en Amérique du Nord… Selon le réassureur allemand Munich Re, les catastrophes naturelles ont causé environ 160 milliards de dollars de pertes en 2012 (400 en 2011 selon la même source, année la plus coûteuse de l’histoire en la matière), sans parler des nombreuses victimes.

Et en bonus…

Moins importants en termes d’impacts que ceux mentionnés ci-dessus, deux exemples d’incidents nous semblent pourtant pouvoir donner matière à réflexion.

En cette année d’élections en France où une nouvelle fois la question du vote électronique a été posée,  deux incidents informatiques ont perturbé des processus électoraux : dans le canton de Vaud en Suisse et lors des primaires du Likoud en Israël.

Pour clore ce panorama, on se doit de citer les actes malveillants, liés à la cybercriminalité notamment, par exemple les importantes attaques DDoS contre des institutions financières aux USA ou l’infection de 30000 PC de Saudi Aramco (première compagnie pétrolière mondiale) par le virus très perfectionné Shamoon. On notera également les révélations du New York Times concernant l’implication des USA et d’Israël dans le virus Stuxnet en 2010, faisant encore monter d’un cran la pression sur la cyber-guerre.

Les années passent, les interruptions d’activité restent

Les années se suivent et ne se ressemblent pas¹, mais les interruptions d’activité, catastrophes et autres bugs informatiques continuent de provoquer des problèmes majeurs.

S’il est important de mettre des moyens sur leur prévention, il est tout aussi nécessaire de savoir réagir. Le risque zéro n’existe pas et certains accidents sont aussi inattendus qu’inévitables. Dans ce cas,  un PCA accompagné d’une gestion de crise efficace peuvent permettre de limiter grandement les dégâts !

[Article écrit en collaboration avec Gérôme Billois]

¹Voir notre rétrospective des incidents 2011.

Cet article La fin du monde a (presque) eu lieu : revue de 5 incidents marquants en 2012 est apparu en premier sur RiskInsight.

La panne logicielle : un incident complexe à diagnostiquer et à traiter

Les pannes logicielles sont difficiles à diagnostiquer du fait d’interconnexions toujours plus importantes au sein des systèmes d’information, d’une supervision plus complexe et plus « spécifique » que pour les problèmes matériels ainsi que d’impacts plus diversifiés et difficilement prévisibles.

Le PRA se focalise bien souvent sur les pannes matérielles, dont le traitement suit un principe simple : un matériel de secours remplace, de façon plus ou moins automatique, un matériel défaillant.

Ce principe n’est généralement pas applicable pour les pannes logicielles, plus complexes à traiter, à différents niveaux de la chaîne de liaison applicative :

• Données : la réplication fréquemment utilisée pour traiter des pannes matérielles entraîne la propagation rapide de données corrompues vers les infrastructures de secours. Afin de s’en prémunir, des mécanismes de réplication logicielle peuvent être mis en place afin de pouvoir revenir à des états cohérents exempts de données corrompues. En dernier ressort, la restauration de clones ou de sauvegardes (plus longue) peut être utilisée.
• Systèmes applicatifs : développés en interne par l’entreprise ou par des éditeurs tiers, ils visent à répondre à certains besoins métiers précis. Leur déploiement peut ainsi être limité, ce qui réduit les expertises existantes et le nombre de tests conduits lors des changements, pour raisons économiques. Les premiers à migrer en font parfois les frais ! Par ailleurs, le fait de les placer sur des infrastructures de haute-disponibilité de type cluster ne change pas le problème : si le logiciel dysfonctionne, ce sera sur l’ensemble de l’infrastructure, car il n’est souvent pas possible de faire cohabiter plusieurs versions d’un logiciel sur un même cluster.
• Frontaux : ils utilisent souvent des logiciels largement répandus, extrêmement stables, et sont assez peu souvent à l’origine de problèmes logiciels. Des effets de bord sur les systèmes applicatifs peuvent néanmoins apparaître.

Toutefois, l’entreprise n’est pas totalement démunie face à ce type d’incidents, et peut en réduire le nombre en respectant quelques principes évoqués ci-après.

Porter une grande attention à la gestion des changements critiques

Les incidents récents le confirment une nouvelle fois : la majorité des pannes logicielles majeures interviennent lors de changements. Outre les bonnes pratiques généralement évoquées (tester largement et sur des infrastructures proches de la production, préparer le retour arrière sur les aspects techniques et organisationnels, renforcer les équipes et définir des astreintes, …), l’entreprise doit porter une attention particulière aux changements critiques. Elle doit ainsi :

• Identifier ces changements et les partager largement au sein des équipes ;
• Réduire le nombre de changements critiques simultanés (a fortiori s’ils présentent des interdépendances), afin de ne pas accroître les risques et complexifier le diagnostic ;
• Renforcer le contrôle des opérations très sensibles (deux personnes pour une même manipulation par exemple).

Privilégier les architectures asynchrones

Une certaine dichotomie existe pour le traitement des pannes matérielles et logicielles. Si les architectures synchrones sont bien adaptées aux premières, un asynchronisme peut grandement faciliter le traitement des pannes logicielles.

Les architectures asynchrones permettent en effet de ne pas propager immédiatement les erreurs et de revenir plus facilement dans des états cohérents, puis de rejouer les transactions jusqu’à l’instant de la panne. Le découpage du SI qu’elles induisent permet également d’éviter la panne globale des systèmes, en rendant possible l’interruption de certains composants sans impact immédiat pour les autres.

Se mettre en capacité de gérer les erreurs de manière pro-active

L’incident d’Orange l’a montré : les pannes logicielles peuvent se produire de manière progressive, en surchargeant peu à peu le SI.

La mise en place de systèmes de mesure et de supervision, la définition de valeurs de charges et de temps de réponse normatifs et leur comparaison régulière avec l’état actuel des systèmes peut permettre de prévenir les incidents avant que des indisponibilités majeures ne surviennent.

Orange a en ce sens, contrairement à ce qu’évoquent certains observateurs, bien assuré sa gestion de crise. Nombre de ses ingénieurs ont été mis en alerte après les premiers signes de fléchissement du réseau, et la communication qui a accompagné et suivi la panne a été bien maîtrisée.

Utiliser des méthodes de validation formelle ?

Des méthodes reposant sur la preuve formelle permettent d’assurer la sûreté logicielle. Elles nécessitent des expertises pointues et un processus de développement bien plus lourd et long que les méthodes traditionnelles, et restent aujourd’hui confinées aux systèmes embarqués critiques.

Leur utilisation pour d’autres usages pourra être envisagée, mais le compromis entre coûts de développement et couverture de risques s’avèrera difficile à trouver !

Cet article Pannes logicielles : la zone d’ombre du PRA (Plan de Reprise d’Activité) 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.

Des métiers sur-sollicités

Les Directions métiers sont aujourd’hui sur-sollicitées par une filière risques qui peine souvent à mettre en cohérence les démarches de recensement et de traitement des différentes typologies de risques (RH, juridique, SI, qualité, continuité…). La multiplicité des acteurs, démarches et planning entraîne une perte générale de lisibilité pour les métiers, qui en réaction s’impliquent moins dans le processus de management des risques.

Créer un cadre unifié pour la gestion des risques

Il est nécessaire de repenser les filières risques pour une meilleure intégration des différents canaux de remontée et de traitement des risques. Vis-à-vis des métiers, ces changements doivent se traduire par des sollicitations plus cohérentes, favorisant ainsi leur adhésion.

Deux axes majeurs pour opérer cette transformation : la convergence des pratiques et la rationalisation de la gouvernance des risques  (voir notre article à ce sujet).

Un retour sur investissement difficile à percevoir

Difficile pour le métier d’évaluer à quel point le travail fourni dans le cadre de la gestion des risques a permis d’atteindre le résultat escompté si on ne le lui montre pas clairement ! Le gain associé aux efforts consentis est en effet difficilement perceptible, car le premier résultat d’une gestion de risques efficace, c’est bien l’absence de perturbations majeures sur les activités. La filière risques doit ainsi faire l’effort de mesurer les gains associés à ses actions, afin de mieux valoriser ces dernières auprès des métiers et leur faire comprendre l’intérêt qu’ils ont à s’impliquer.

Développer le « marketing de la filière risques »

Pour favoriser l’adhésion des Métiers, la filière risques doit développer sa capacité à intervenir en mode projet ou en phases d’étude à leur demande, en sortant d’un mode de fonctionnement aujourd’hui trop basé sur le récurrent.

Elle doit pour cela apprendre à se vendre, en assurant la promotion des services qu’elle peut offrir aux Métiers et des résultats qu’elle obtient. Cela doit contribuer, si ce n’est à inverser, au moins à rééquilibrer les flux de sollicitations entre les deux parties. Ces derniers partent en effet aujourd’hui majoritairement de la filière risques et non des Métiers, contrairement à la quasi-totalité des autres directions support ! La filière risque dispose de plusieurs moyens pour ce faire, au travers par exemple :

• de la structuration de « l’offre de la filière risque » : comment et sur quoi cette dernière se propose d’intervenir auprès des métiers, à leur demande ;
• de la valorisation des résultats obtenus, en trouvant des indicateurs pertinents et des exemples concrets pour les différentes typologies de risques ;
• de la détection des nouvelles opportunités qui apparaissent aux Métiers grâce à la bonne gestion des risques (moyens de valorisation en externe par exemple)

Un refus trop fréquent du risque

La filière risques est souvent perçue comme l’entité qui « sur-traite » voire refuse systématiquement le risque, plutôt que celle qui valorise la prise de risque maîtrisée.

Les métiers, au cours du processus de décision, attendent pourtant que les pertes potentielles soient analysées au regard des gains attendus. Réaliser cet exercice difficile et décider « en toute connaissance de cause » est de plus en plus complexe pour eux, et la filière risque peut les aider en cela, que ce soit sur un plan stratégique ou opérationnel.

S’aligner sur les objectifs des Métiers et veiller à ne pas sur-traiter les risques

La filière risques doit passer du refus trop fréquent du risque à l’assistance au métier dans la conduite de ses choix stratégiques et opérationnels, pour lui permettre d’atteindre ses objectifs en prenant des risques maîtrisés. Le gestionnaire de risques doit devenir un des soutiens indispensables dans les équipes chargées de mener des études ou projets stratégiques, via sa capacité à analyser de manière large et détaillée les risques et valider que la prise de risques permettra de générer de la valeur et est conforme à « l’appétence au risque » qu’exprime le métier. Dans un cadre plus opérationnel, il doit s’assurer que les projets intègrent bien la notion de risque tout en conservant ses missions récurrentes de cartographie et traitement.

Mais il doit surtout développer son rôle de conseil « à la demande du métier », en veillant à ne pas imposer des processus et solutions qui viseraient à « sur-traiter » les risques et donc à diminuer la performance de l’entreprise.

Cet article Transformer la relation avec les métiers : une évolution nécessaire pour la filière risques est apparu en premier sur RiskInsight.