Criticité?

Dans l’immatériel!

Pascal Kotté
Mar 28 · 10 min read

L’inventaire des données!

La gestion des risques, la sécurité, sont des domaines qui dépassent le monde numérique. Mais nous avons la fâcheuse tendance à bien les séparer, et que chaque monde: Matériel et immatériel; fasse son analyse de risque dans son coin!

Il est clair que le “piratage” du système d’information est un des risques à traiter, et que celui-ci ne concerne que le département informatique!

Si tu viens de penser que cette assertion est vraie pour ton entreprise, alors, c’est que tu as besoin de mes services: http://callme.kotte.net

La meilleure façon de “pirater” une organisation est d’exploiter ses poubelles papiers, ou de trouver un moyen de s’y introduire physiquement, pour faire le ménage par exemple, ou encore de trouver “une bonne poire” pour assurer la mise en connexion nécessaire pour assurer les premières pénétrations.

La criticité des services numériques

Le piratage est “le risque” immédiatement imaginé quand on parle de risques et criticité de services numériques. Ce n’est pourtant de loin, pas le plus courant. La principale cause de dysfonctionnement d’un service numérique est liée à une opération interne du département informatique: Une mise à jour malheureuse, une migration ou une erreur opérationnelle. La cause suivante est une erreur opérationnelle par les usagers, et de plus en plus souvent, une défaillance du fournisseur de service externe en Cloud, soit directement, soit indirectement par une défaillance du réseau.

source: https://www.slideshare.net/MorrisonHershfield/myths-and-realities-about-designing-high-availability-data-centers (2015)

Distinguer arrêt de services (provisoire) et pertes de données…

Ce n’est pas non plus la même chose de parler de fuites de données, qui exposent des données sensibles ou confidentielles, pouvant nuire au moins à l’image de l’organisation, mais aussi s’exposer à des frais juridiques, en plus de pertes commerciales significatives… Mais c’est une copie qui “fuite”!

https://www.bilan.ch/techno/souriez-et-ne-vous-faites-pas-hacker (REBECCA GARCIA)

Et il est donc bien nécessaire de prévenir aussi le “hacking”, même pour un solopreneur, une startup, une association ou une petite PME…

Savez-vous ce que sont des botnets? Les automates ne font pas de distinctions…

La perte de données, c’est quand un incident provoque une destruction ou une perte irrémédiable et définitive des données. Car des applications et des systèmes, cela peut toujours se reconstruire, mais les data, pas toujours…Même à titre personnel: Si elles sont critiques, c’est localisé à 3 endroits, et au moins à 2 pour les moins critiques, et dans des endroits différents!

source: https://www.ticeo.fr/datasecure.php

Car mettre ses données dans un (seul) “Datacentre” sécurisé, ne suffit pas.

Mais avant d’investir dans des solutions de redondances de stockages, et de reprises en cas d’incidents, il est nécessaire de comprendre les risques, et de mesurer l’importance et criticité de chaque service.

Evaluer les risques

Source: formation-achats.fr

Identifier et inventorier les risques est un travail fastidieux, à traiter avec du bon sens, des experts, et avec les statistiques sur les incidents rencontrés par les autres.

La matrice classiquement utilisée va prendre 2 angles:

  • d’analyse sur l’impact,
  • et la probabilité que cela survienne.

Moi, j’aime bien les représentations dans le monde de la santé, qui vont généralement les positionner afin de faire apparaître les “pires” en premier, et la criticité va de 1, la pire, vers moindre.

Application dans la mesure de criticité d’un service numérique

Dans l’analyse des mesures pour maintenir le bon fonctionnement des services numériques mis à disposition, le département informatique doit recevoir une évaluation de la criticité du service concerné. Et pour les services “Business” (visibles, vs “Infra” invisibles), c’est aux usagers de ces services d’en clarifier l’importance.

Est-ce un service?

  1. Indispensable (voir vital)
  2. Important car nécessaire
  3. Utile (on peut survivre un moment sans)
  4. Futile (on peut s’en passer, mais c’est plus sympa avec!)

Et de leur demander d’expliquer:

  • Pourquoi?
  • Combien de temps peut-on fonctionner sans?
  • Quel est l’impact et les conséquences, au-delà? Et pas seulement en termes financiers…
  • Quelles solutions et contournements sont possibles pour palier?
  • Idées et solutions pour réduire ce risque?

Matrice de criticité simplifiée

  • Importance: 1–4
  • Criticité: 1–6

Importance

Exemple: 1 indispensable, 2 nécessaire, 3 on peut survivre sans un moment, 4 futile (c’est mieux avec, mais on peut survivre sans, définitivement)

La criticité ci-après peut sembler redondante avec cette importance, et elle est souvent lié, mais pas nécessairement. Si cela est effectivement redondant, on peut supprimer cette “Importance”.

Criticité

  1. Majeur (1h max)
  2. Critique (4h max)
  3. Important (48h ok)
  4. Normal (7 jours-ok)
  5. Accessoire (1 mois ok)
  6. Inutile, ou “ça peut servir” (si cela tombe en panne, on ne répare pas…)

Chaque service sera associé à une “valeur”, qui peut correspondre à ce que le monde économique appelle des “SLA” (Service-Level Agreement). Celle-ci est une donnée majeure dans un catalogue de services.

En gardant à l’esprit que ceci est une simplification, et que le “bon sens” doit rester l’arbitre.

Par exemple: Le logiciel qui traite la paye, peut rester en panne 3 semaines, les trois premières du mois, mais pas 3 jours, à la fin du mois.

Et attention, un service “infra” qui va soutenir plusieurs services “business” ne va pas se contenter de prendre la valeur du plus critique de ces services. S’il soutien une grande quantité de ceux-ci, il doit probablement devenir d’une criticité maximale, y compris si aucun des services supportés n’est maximal.

Détail: Si un service “Infra” ne soutien qu’un seul service “Business”, c’est que ce n’est pas un service “Infra”, c’est une des briques du service “Business” concerné, et il doit fusionner avec!

Mais c’est insuffisant pour qualifier la façon de sécuriser ce service

Le fait que ce service soit nécessairement remis en service plus ou moins rapidement, ne va pas suffire à déterminer s’il est important, ou pas.

Le fichier à jour des membres d’une association est nécessaire pour envoyer la convocation, une fois par an. Donc si l’application qui me permet d’envoyer les convocations ne fonctionne plus, ce dont j’ai besoin, c’est d’une solution pour envoyer ces convocations, très rapidement si je réalise cela au moment d’avoir à envoyer ces convocations! Et si fichier n’est plus disponible?

Data

Les applications sont les interfaces nécessaires pour traiter des données, mais ce sont les données qui sont importantes. Et pourtant, nous faisons des catalogues de services, des listes d’applications, et payons des licences, sans parfois savoir quelles données elles vont manipuler, et pour qui…

Toutefois lors de sinistres, ou de fuites, nous réalisons bien vite que les données sont le sang de l’informatique, les applications en sont le cœur ou les poumons…

Une cartographie des données est nécessaire: http://data.ict-a.ch afin de bien comprendre en particulier : A quelle fréquence dois-je en assurer la réplication. Généralement, le nom du groupe de données correspond au nom de l’application qui les manipule. Mais parfois, plusieurs applications opèrent sur un même groupe de données. On récupère alors des informations importantes sur ces données:

  • Source Localisation: L’URL ou l’UNC de stockage de ces données.
  • Format: Une indication si ce sont des formats binaires (spécifiques à une application) ou standards (et lesquels, soit nativement, soit par exports, si possibles automatisés). Cela peut aussi être un “snapshot” d’une image de disque, voir des “delta-snapshot” (réplication du contenu d’un disque, dans un état “cohérent”, voir multiples copies cohérentes du contenu d’un disque, optimisées pour ne pas dupliquer des données non modifiées).

Note technique: Si les fichiers concernés sont “ouverts” et ne peuvent être sujet à une réplication immédiate dans un Cloud par exemple, alors il est inutile de “faire semblant” d’en assurer une sauvegarde “temp réel”, et il faut mentionner le risque de perte d’1 jour de travail. On doit alors décider si on peut vivre avec, ou si on doit prendre des mesures. C’est parfois simplement une action manuelle informée aux utilisateurs (1 export manuel, fermeture à midi), qui deviennent responsables de le faire, ou pas…

Personnelles?

A cause des lois, la RGPD (GDPR européenne) ou LPD (en Suisse, avec une nLPD à venir en 2022), il est nécessaire de “savoir” si nos données incluent:

  • Des données personnelles (de personnes physiques)
  • Des données personnelles sensibles (finance,politique,religion,santé….)

Chacun des fichiers avec des données personnelles avec des ressortissants UE depuis 2018 doit être associé à un responsable du traitement. Cela sera aussi le cas en Suisse dès 2022.

Confidentialité?

  • Ultra-secret: Pertes lourdes et poursuites juridiques (La fuite de ces données peuvent mettre l’entreprise en péril, ex. secret de fabrication fondamental, accords ou activités légalement discutables dans certaines juridictions);
  • Secret: Pertes financières (plans, formules, stratégies, secret de fabrication ou d’organisation, importants mais non critiques, individuellement… Il faudra se demander si l’ensemble ne devient pas ‘ultra-secret’);
  • Confidentiel: La fuite de ces données n’entraînent rien de catastrophique, à part un dégât d’image (mettre secret si cela a un impact financier grave), mais elles portent sur des informations que ne sont pas censé être en accès libre hors des groupes concernés (internes et externes). Par exemple: Des données personnelles assujetties à la GDPR ou la LPD (‘Secret’ uniquement si des revenues se font directement sur celles-ci).
  • Interne: Accessibles à une partie ou totalité des membres internes et partenaires externes à l’organisation, mais il ne faudrait pas les retrouver sur le Net, car cela nuirait à l’image ou pourrait générer des interprétations négatives.
  • Publique: Elles ne sont pas facilement accessibles, mais elles pourraient être partagé en public sans conséquences négatives significatives. Mais il ne faut pas le faire sans valider la forme avec les responsables de la communication.
  • Publiée: Elles sont téléchargeables sur l’Internet (et sont donc autorisé à être diffusées)

Les volumes!

On oublie très souvent de le prévoir, mais le département IT a tendance à regarder l’évolution des espaces de stockage, en surveillant les disques. Or ce qui est important, c’est de connaître les volumes et les localisations des données sensibles ou importantes. Il est aussi nécessaire de planifier les augmentations de ces volumes. C’est une bonne idée de déléguer si possible cela au responsable du traitement de ces données.

Une fonction qui est accessoire en général, mais qui va devenir obligatoire dès 2022 en Suisse, pour les data incluant des données personnelles.

  • Volume initial: en Go/To
  • Volume annuel en plus à prévoir…

Les réplications!

Il nous faut comprendre la tolérance à la reprise sur incidents.

Avant même de se demander combien de copies sauvegardées, et où, il faut déjà déterminer la nécessaire occurrence des sauvegardes. Et bien entendu, tous les utilisateurs vont réclamer une sauvegarde immédiate et en temps réels. Coup de chance, grâce au Cloud cela devient “presque” facile… Ou pas.

  • Intervalle de sauvegarde: 0h (immédiat, journalisation second endroit), 24h (sauvegarde dans la nuit).
  • Nombre de répliques: Il sera peut-être nécessaire de dupliquer ces informations sur les sauvegardes pour chaque réplique, car on peut avoir plusieurs répliques de formats et caractéristiques différentes. On peut ainsi doubler la réplique immédiate, avec le même intervalle (mais une autre destination!), ou assurer une réplique avec un décalage de 24h max (dans la nuit)…
  • Profondeur des répliques: Que ce soit via des sauvegardes incrémentielles, ou des “snapshots”, on aime bien disposer des 7 ou 30 derniers jours, et des 12 derniers mois… Mais parfois, nous disposons d’un “versioning” pour chaque version, plusieurs fois dans la journée, et sur plusieurs années. On peut dans le Cloud définir ce type de paramètres, ou les subir. Mais il faut les connaître, et quand on paye le stockage au volume, il est parfois pertinent de réduire cela, si les outils le permettent.
  • backup localisations des répliques: Géographiquement, il est inutile de donner des indications qui ne fournissent pas clairement le lieu effectif de stockage de ces données, y compris dans un Cloud: Lequel et où (Microsoft Zurich, Microsoft Genève?)

Il est pertinent de documenter aussi la forme, et de valider la “durée de vie” de ces sauvegardes. Bandes numériques DLT? (3 à 5 ans), Amazon glacier (infini, tant que c’est payé)…

  • backup volumes: Le contrôle des volumes effectifs des répliques, voir même leurs coûts de stockage (indicatif, et à contrôler), serait un plus appréciable (sauvegardes et archivages).

Toutes ces informations composent l’inventaire “data” (data-groups) d’une organisation, et cet inventaire doit être corrélé avec le catalogue des services.

Photo by Mitchel Lensink on Unsplash

Conseillers Numériques Suisses Romands

Le réseau des experts indépendants du digital pour des…

Conseillers Numériques Suisses Romands

Le réseau des experts indépendants du digital pour des tranformations informatiques durables et responsables.

Pascal Kotté

Written by

Réducteur de fractures numériques, éthicien digital, Suisse romande.

Conseillers Numériques Suisses Romands

Le réseau des experts indépendants du digital pour des tranformations informatiques durables et responsables.