alphaspirit - Fotolia

Faire avancer la cybersécurité : un défi en forme d’impasse

Les révélations de brèches de sécurité continuent d’être nombreuses, comme si les leçons de celles des années passées n’avaient pas été tirées. Une fausse impression ?

Stéphane Dubreuil est expert du Cercle des Assises de la Sécurité et peut se targuer d'une vaste expérience de la sécurité des systèmes d'information. Il identifie au moins quatre freins à la prise en compte concrète des enseignements qu’il serait possible de retirer des nombreuses brèches de sécurité informatique de plus en plus médiatisées depuis plusieurs années : l'utilisateur, les métiers, la DSI, et la direction… Verbatim.

Présenté ainsi, je conviens bien volontiers que cela ressemble moins à des freins qu'à une impasse ! Cependant, si aucun de ces acteurs n'est sciemment opposé à la mise en œuvre de la sécurité – je ne remets pas en cause la bonne volonté –, aucun d'entre eux n'est réellement prêt à faire de concession sur son périmètre pour que celle-ci soit prise en compte.

L'utilisateur : « comme à la maison »

Du point de vue de l’utilisateur, réseaux, outils physiques – ordinateurs, tablettes, smartphone, etc. – et logiques – bureautique, applications métier – sont associés à des usages. L'utilisateur veut, comme chez lui, les derniers outils avec des connexions ADSL/fibre, sur des outils métiers intuitifs/tactiles et conserver la possibilité de surfer sur "ses" sites (personnels, donc).

De fait, l'utilisateur va donc pousser la DSI à lui fournir les derniers outils dans des temps contraints qui ne permettront pas nécessairement à cette dernière de les intégrer sainement dans l'écosystème informatique.

Au-delà des questions liées à l'intégration des équipements dans un domaine – qui permet d'assurer des stratégies de sécurité adaptées aux outils et aux usages… et qui demande déjà un certain temps –, les applications qui apportent les fonctions de sécurité tels que l'authentification forte, le chiffrement bas niveau – et le recouvrement des données qui va avec –, ou encore l'automatisation de la mise en œuvre du VPN – pour conserver en mobilité les fonctions de sécurité existant au sein de l'entreprise –, ne sont pas nécessairement toutes portées en temps réel sur les derniers systèmes d'exploitation à la mode. Aussi, sous la pression, les DSI peuvent être amenés à fournir à l'utilisateur des outils modérément sécurisé pour le contenter.

De même, l'utilisateur interne à l'entreprise va faire porter sur sa direction métier des attentes – légitimes ? – en termes d'applications. En ces temps de dématérialisation, toutes les données doivent être accessible de partout en un touché de doigt, et tous les processus doivent être informatisés. Aussi, à l'instar de la DSI, il n'est pas rare que, devant les attentes de leurs personnels, les directions métiers fassent évoluer leurs outils sans s'assurer du niveau de sécurité mise en place – droit d'accès aux informations un peu large ou traçabilité des actions succinctes, pour ne citer que cela.

Le métier : le sacrosaint « time-to-market »

Les directions métiers doivent également faire face aux attentes des clients – l'utilisateur externe. On connaît bien le phénomène de prime au premier entrant, quel que soit le secteur d'activité… Une pression forte s'exerce donc sur les délais quand il s'agit de produire une interface numérique avec le client.

Cette pression peut donner lieu à des raccourcis « faciles » dans le développement ainsi il est courant de voir négligée l'analyse de risque, d'oublier les audits – qualité du code, configuration des serveurs, etc. –, autant d'éléments qui ont un coût – financier ou calendaire –, mais qui assurent une certaine robustesse à ces interfaces externes.

Le leitmotiv de la DSI : offrir le service

La DSI est prise dans une course en avant où ses ressources sont massivement investies dans l'offre de service pour ne pas être externalisée. L'infrastructure coûteuse et peu visible – Active Directory, contrôleur de domaine, et autre solutions de type Exchange, serveur d'infrastructure de type DNS, etc. – est trop souvent délaissé au profit des attentes utilisateurs (internes). Or cette infrastructure est la colonne vertébrale du système d’information. Si elle est fragile, tout le système d’information est fragile.

Je n'évoquerai pas ici – cela devrait faire l'objet d'une analyse distincte – les liens entre les outils métiers et les infrastructures de la DSI qui nécessitent de faire évoluer conjointement leurs outils respectifs pour échapper aux vulnérabilités découvertes tout en assurant une compatibilité entre elles – le maintien en conditions opérationnelles (MCO) et en conditions de sécurité (MCS), le patch management et les tests de non régression.

La direction : marge, ROI et intérêt du sujet

En fait si, je vais un peu aborder le MCO et le MCS car, pour la direction, ces deux mamelles de la sécurité ont un coût (significatif) qui peut, dans un secteur concurrentiel, rapidement saper l'intérêt financier lié à la dématérialisation – cette dernière est-elle d’ailleurs un facteur d’économie ou de productivité ?

Aussi, il est tentant de ne pas investir sur le MCO et le MCS, quitte à fragiliser à moyen et long terme les outils mis en place. C’est d'autant plus tentant que le ROI – retour sur investissement – dépend de l'occurrence d'impact du risque qui, lui, reste souvent difficilement estimable.

Le second frein au sein des directions est la compréhension et l'appétence pour les sujets de sécurité. Au regard des coûts, sans cesse plus importants, de l'informatique dans leurs entreprises, les directions souhaitent légitimement savoir pourquoi elles paient et pourquoi c'est important. Il est d’ailleurs raisonnable que les arbitrages financiers soient réalisés par des dirigeants métiers et non par des techniciens informatiques.

Cependant, dès lors que des sujets de sécurité – transverses et systémiques, donc onéreux – sont abordés, cela devient extrêmement laborieux et toutes les paraboles les plus imagées du RSSI ne pourront conserver l'intérêt de responsables qui finiront par faire le nécessaire pour ne plus avoir à traiter ce sujet – ce sera donc globalement non.

Expliquer la nécessité des investissements et les temps de latence/indisponibilité qu'implique le MCO et le MCS au sein des DSI et directions métier est un exemple immédiat du propos : il faut que ça fonctionne pour pas trop cher, et quand ce n'est pas le cas, c'est pénible de devoir subir une longue et inintéressante/incompréhensible explication technique.

La sécurité, un critère secondaire

Pourquoi la sécurité apparaît-elle, au final, comme un critère secondaire pour ces acteurs, alors que l'on découvre quotidiennement dans la presse – spécialisée ou non – que le nombre d'incidents augmente presque aussi vite que les impacts qu'ils produisent ?

Peut-être est-ce dû au caractère intrinsèque du sujet. Comment matérialiser un risque dans un système nativement dématérialisé… Cela manque de concret. Nous nous représentons assez facilement le lien entre l'allumette/le mégot de cigarette/la braise et le white spirit/un bois un peu sec/ le vent sur notre environnement : l'entreprise brûle ; il n’y a plus de travail. Ce lien se fait aussi avec l'eau : fuite, crue, tempête pour des résultats sensiblement similaires… plus de travail.

Mais ce lien est significativement moins évident entre clef USB, spam, code source de mauvaise qualité, absence de MCO et la fin de l'activité... Par contre, les coûts pour s'en prémunir sont très concrets, eux.

Pour approfondir sur Gestion de la sécurité

Close