Et si nous parlions sécurité !
il y a 7 ans par olivierChaillot

Cet article mélange beaucoup de notions :sécurité, résilience, hacking et écureuils... Ces notions n'ont pas forcément de liens et varient grandement quand on est un particulier, une PME, un grand groupe, un état.

Ces questions sont difficiles, sensibles, elles nécessitent des moyens (et de la pédagogie) qui sont souvent en dessous du minimum requis, donc je resterais très prudent  et j'exposerai mon point de vue avec humilité ! (un pépin peut arriver à tout le monde...)

Pour répondre à la question quelle est la première cause de perte de donnée ? À mon avis la source est le plus souvent l'utilisateur :

• suppression accidentelle
• insuffisance des backup ,
• installation de tout et n'importe quoi
• ou ce qui arrive le plus souvent un problème d'organisation, le fichier existe, mais est perdu dans un amas de données informe (le fameux dossier archivage ou à trier !  )

Concernant les autres menaces, tous ceux qui sont dans le métier ont été en contact avec des cryptolockers (ou ransomware) et certains d'entre nous victimes. J'avais discuté avec un RSSI d'une célèbre ville de briques roses, qui s’était retrouvé avec des dizaines de To cryptés... Donc cela n'arrive pas qu'aux autres... Et cela n'a rien à voir avec un hacker terroriste,il suffit d'une clé USB vérolée, un compte avec des droits trop importants, un manque de vigilance et c'est plié...

Autre exemple de ce que l'on peut trouver, il est assez facile de trouver des moteurs de recherche qui liste des webcam/équipement actif/hotspot/matériel de sécurité sur lesquelles tu te connectes comme à la maison. Pas besoin d'être un hacker les mots de passe sont juste par défaut...

Bref j'en passe, mais il y aurait tellement à dire sur le sujet...

L'ANSSI a mis à jour sont guide récemment : www.ssi.gouv.fr/actualite/le-nouveau-guide-dhy... 

Bien qu'il ne traite pas le problème des écureuils, positionner la sécurité de son SI par rapport à ces pratiques est un très bon début.

Je rie et j'en rie...

Trêve de plaisanterie en matière de cybersécurité le maillon faible c'est l'humain.

Après si des réseaux d'infrastructures vitaux on des défaillances c'est très souvent parce qu'ils sont vieillissants et mal entretenue.

Les pirates (hackers) profitent de la faiblesse (de l'ignorance) des utilisateurs pour s'infiltrer dans les systèmes, alors que généralement la sécurité de base est souvent suffisante.

Rappeler certains préceptes et inciter au respect de certaines règles comme le fait l'ANSSI, qui a initié le dispositif ACYMA entre autre est une bonne chose.

Il est cependant plutôt conseiller de ne parler que des sujets que l'on connaît, pour ma part je ne suis guère spécialiste des écureuils...

Merci pour cet article.

Même s'il est hors de question de massacrer les écureuils (j'espère qu'un président d'outre atlantique n'a pas lu l'article), il remet en cause la manière dont est abordée la sécurité informatique.

Cela fait un moment que je suis contre la surexploitation des fantasmes par les vendeurs de solutions miracles au détriment une approche calme et posée du problème. Effectivement, la plupart du temps, nous (les marchands urbains d'expertise IT) partons du principe que l'alimentation électrique et la connexion à Internet sont acquises et définitives.

De la même manière que trop peu de mes confrères testent régulièrement le bon fonctionnement des backups, toutes ces histoires de tuyau les dépassent et ils s'en désintéressent...

Personnellement, j'ai déjà eu des dégâts sur des réseaux à cause du chien du veilleur de nuit qui avait rongé les cables (inutile de dire que la puissance du cloud n'a rien changé)

Je savais bien qu'un jour ma certification en ondulique me servirait :-)

Je ne rebondis par sur PascalW avec qui je partage l'analyse parceque je suis plus un homme de mécanisme que de mécanique. L'erreur AMHA vient du mécanisme qui devrait prévoir les défaillances mécaniques qu'elles soit dues aux rongeurs ou aux terroristes. Cette erreur m'est d'autant plus familière et pesante que je l'ai autorisée - par ignorance de l'incomplétude de TCP/IP - pour l'internet alors que ma responsabilité était de la prévenir pour le réseau mondial où se reaccordait internet.

Le problème est simple : TCP/IP est un protocole de bout en bout alors que, selon la RFC 1958, les relations digitales complètes (comprenant au moins la couche OSI six Présentation) se gèrent de frange à frange. Or, la couche six est la base des "services étendus", c'est à dire des services à la relation (téléprésence, contenu, comptabilité, mémorisation, gestion du VGN, reprise du routage, etc. etc.) qui, celle-ci étant absente dans le stack internet, en sont devenus absents dans la proposition client (vs. capacité utilisateur).

En y ayant pas mal pensé, je crois qu'une prévention simple serait d'ajouter à la théorie de la communication la notion du "temps présent". C'est à dire le temps de ce qui se passe en interne, au lieu du temps réel contextuel. Et de repenser tous les algorithmes dans ce contexte opérationnel. Une façon simple étant de passer en multimatique (c'est à dire en multiagents autonomes). Si un échange est interrompu, tout se reconstruit (ou s'interrompt) en fonction de cette interruption de façon qu'en temps présent une interruption en temps réel ne soit pas perceptible. Il y a décallage en temps réel (temps présent commun) mais pas d'infuence sur le traitement interne. Cela repart, et si le temps présent peut se dérouler plus vite (traitement interne) la situation se rétablira d'elle-même en temps réel (ou présent externe au processus considéré).

Ceci implique bien sûr la possibilité d'évacuer la variable temps dans un processus réparti et donc de passer dans ce que l'on peut appeller un "espace des liens". Cela ne semble pas possible en analogique (ou en numérique pseudo-analogique, où l'on cherche a établir une impression de continuité), mais "built-in" en quantification digitale. On va raisonner en avant-écureil et en aprés-écureuil en réduisant la durée écureuil en temps réel à zéro en temps présent.

J'ai bien conscience que cela peut paraître alambiqué, que cela ne résoud pas les conséquences externes et qu'il faut prendre en compte les discontinuités de reprise, mais vu des systèmiques opératives autonomes (SOA, bots) impliquées, cela permet une programmation simplifiée (le processus principal est en temps présent), les processus de reprise (qui gèrent une discontinuité temps réel oubliée en temps présent) étant des add-on qui peuvent gérer à l'identique les ruptures en temps réél externe (ex. auto-organisation critiques).

J'aimerais trouver des compétences erlang avec qui apprendre ce langage qui me parait le seul pour développer ensemble un banc-test sur ce type de systèmique.

Conclusion : les écureuils aiment les noisettes et marrons grillés. On est foutu.

Également dans le fantasme cyber-sécuritaire : www.xkcd.com/538/