La semaine dernière j’ai participé à la table ronde de la conférence du CLUSIF “Gestion des incidents de sécurité : résilience et amélioration.”
Mon intervention présentait un travail de recherche effectué en 2016-2017, qui peut se résumer par une question: comment éviter que des biais cognitifs ou organisationnels n’impactent la gestion de la sécurité?
En général les décisions en sécurité se prennent sur la base d’avis d’experts, de fournisseurs, de benchmarks ou de discussions avec les pairs.
Mais dans le domaine de la gestion des crises sécurité, qui réclame rapidité d’action et met souvent à mal les usages établis, ces critères sont souvent inopérants ou peu efficaces.
Par ailleurs, comme il est très difficile de créer des modèles de sécurité déterministes, les décisions sécurité dépendent bien davantage que d’autres secteurs des décisions humaines.
Or la rationalité humaine est limitée, erratique, victime de biais cognitifs.
Il existe heureusement des travaux en psychologie, management et gestion des organisations, ainsi que des centaines d’études de cas, qui permettent de faire la chasse aux biais cognitifs et organisationnels.
La méthode que j’ai essayé de concevoir aide ainsi à fiabiliser les décisions de sécurité, en particulier en cas de gestion de crise ou d’incident majeur.
Biais cognitifs? Ce sont des mécanismes de pensée, relativement systématiques, qui provoquent des altérations du raisonnement et du jugement tout en préservant l’apparence de la raison logique.
Disons pour faire simple que les biais cognitifs ressemblent aux illusions d’optique.
La démarche que j’ai adoptée est une transposition de celle de l’OWASP Top 10.
Le principe de cette méthodologie consiste à faire le deuil d’un code exempt de bugs, et donc de vulnérabilités, pour adopter une autre démarche : faire la chasse aux vulnérabilités les plus dangereuses et les plus courantes.
Ainsi transposé au domaine des biais cognitifs et de la prise de décision en sécurité, le principe devient : au lieu de chercher à prendre de bonnes décisions, essayons d’éviter les plus mauvaises.
Quelques exemples:
Dans une organisation, un exercice de redteaming est prévu, ou est peut-être en cours. Suite à une détection suspecte, les analystes du SOC ne lancent dans le SIEM que des recherches qui pourraient confirmer leur idée initiale: il s’agit d’un exercice de redteaming. Le biais cognitif qui est ici à l’œuvre est le biais de confirmation (une tendance à favoriser l’information connue et à ne pas chercher ou négliger ce qui la contredit).
Dans ce cas, une question permet de révéler un tel biais: des options ont-elles été rejetées rapidement, sans analyse sérieuse? – Toute la méthode consiste à instancier les biais identifiés sur des situations de sécurité puis à définir ces questions de révélation.
5 février 2016, 10h30, dans une banque. Le numéro 2 essaie d’imprimer les transactions SWIFT de la veille, pour les contrôler. Mais l’imprimante ne fonctionne pas. Le dirigeant ne s’en inquiète pas outre mesure et quitte le bureau sans avoir effectué son contrôle. Les imprimantes ont déjà dysfonctionné par le passé… En fait, un cyberbraquage était en cours, et un malware bloquait l’impression des transactions frauduleuses (pour un montant de près de 950 millions de dollars, dont plus de 60 millions ne pourront pas être récupérés). Ici, le biais cognitif en cause était la normalisation du danger. Une exposition prolongée à un risque initialement jugé inacceptable entraine qu’il devient la norme. Pour le dire de façon triviale, en s’habituant aux risques on en diminue l’intensité.
Dernier exemple: une cellule de crise a été déclenchée. Un directeur préconise de redémarrer deux serveurs probablement impliqués. Un technicien dit que cela ne résoudra rien. Mais il n’est pas écouté. Décision est prise de redémarrer… Cela ne résout rien. La décision de redémarrer le deuxième serveur est pourtant confirmée par le directeur. Le biais en cause ici était le biais d’engagement: un lien d’attachement entre un groupe ou individu et son action (par exemple par nécessité de se justifier à ses yeux, ou bien aux yeux d’autrui). Une question permet de révéler un tel biais, dans un tel cas: Y a-t-il un responsable qui s’implique trop dans les décisions techniques du fait – par exemple – de ses anciennes fonctions techniques?
J’ai présenté ce travail au cours d’une master class au FIC, à Lille, en janvier 2019: https://www.forum-fic.com/Data/Sites/16/fichiers/FIC2019-Masterclass-BiaisCognitifs.pdf?ts=1550152042
Et l’étude complète se trouve là: http://cryptosec.org/?Securisation-de-la-securite
Quant au petit outil que j’ai développé pour appliquer la méthode, il se trouve là: http://cryptosec.org/biais/
Post written by Inti Rossenbach.
Last week I participated in a panel discussion of the CLUSIF Conference “Security Incident Management: Resilience and Improvement.”
I presented a research project done in 2016-2017, which can be summarized as follows: how to prevent cognitive or organizational biases from impacting security management?
In general, security decisions are made on the basis of experts or provider advices, benchmarks or discussions with peers.
But in the field of crisis management, which requires quick reaction and modifies usual processes, these criteria are often ineffective or inefficient.
In addition, since it is very difficult to create deterministic security models, security decisions depend much more than other activities on human decisions.
But human rationality is limited, erratic, subject to cognitive biases.
Fortunately, there are studies in psychology, management and organization’s management, as well as hundreds of case studies, which make it possible to hunt for cognitive and organizational biases.
The method I tried to design helps to make security decisions more reliable, especially in the event of crisis or major incident.
Cognitive bias? These are relatively systematic thought processes that cause alterations in reasoning and judgment while preserving the appearance of logical reason.
To put it simply, cognitive biases resemble optical illusions.
The approach I have adopted is a transposition of OWASP Top 10.
The principle of this methodology is to forget about a code free of bugs, and therefore vulnerabilities, and to adopt another approach: hunt for the most dangerous and most common vulnerabilities.
Thus transposed to the field of cognitive biases and decision-making in security, the principle becomes: instead of trying to make good decisions, try to avoid the worst.
Some examples:
In an organization, a redteaming exercise is planned, or may be underway. Following a suspicious detection, analysts of the SOC only search in the SIEM pieces of information that could confirm their initial idea: it is a redteaming exercise. The cognitive bias at work here is the confirmation bias (a tendency to favor known information and neglect contradiction).
In this case, a question reveals such a bias: have options been rejected quickly, without serious analysis? - The whole method consists of instantiating the identified biases on security situations and then defining these revelation questions.
February 5, 2016, 10:30 am, in a bank. A top manager tries to print SWIFT transactions from the day before, to control them. But the printer does not work. The manager does not worry too much about it and leaves the office without having made his control. Printers have already malfunctioned in the past … In fact, a cyberheist was underway, and a malware blocked the printing of fraudulent transactions (for an amount of nearly $ 950 million, of which more than 60 million could not be recovered). Here, the cognitive bias involved was the normalization of danger. Prolonged exposure to a risk initially considered unacceptable will make it acceptable.
Last example: a crisis meeting is ongoing. A director recommends restarting two servers likely to be involved. A technician says that it will not solve anything. But he is not listened to. Decision is taken to restart… This solves nothing. Decision is however confirmed by the director to restart the second server. The bias in question here was the commitment bias: an attachment between a group or an individual to his action. A question can reveal such a bias, in such a case: is there a manager who is too involved in technical decisions because - for example - of his former technical functions?
I presented this work during a master class at the FIC, in Lille, in January 2019: https://www.forum-fic.com/Data/Sites/16/fichiers/FIC2019-Masterclass-BisaisCognitifs.pdf
And the complete study is there:
http://cryptosec.org/?Securisation-de-la-securite
As for the modest tool I built to apply the method, it is there: