Il était une fois la Sécurité des SI…
Les standards et les pratiques régissant la Sécurité Informatique s’articulent toujours autour d’une approche top-down. Cet « écosystème » prend naissance à partir de directives générales provenant de normes internationales ou sectorielles, des législations…qui se traduisent en Politique Générale de Sécurité des Systèmes d’information qu’une entreprise formalise et veille à appliquer. Pour ce faire, des analyses de risque (selon des approches diverses : MEHARI, EBIOS…) sont réalisées. L’idée étant d’apprécier l’exposition de l’entreprise (dans la totalité de son activité ou sur une partie) aux menaces potentielles, afin de cibler les investissements et les efforts à déployer sur les différentes composantes de son Système d’Information.
L’Output de ces travaux se concrétise sur le plan opérationnel par un ensemble de procédures, best practices, kits de durcissements…mis en œuvre par l’entreprise. Celle-ci s’appuie alors sur ses fournisseurs et intégrateurs IT mais aussi sur des solutions techniques ad hoc (appelées alors Solutions de Sécurité). Ces mesures techniques (mais aussi organisationnelles) ont pour vocation de réduire les risques auxquels l’entreprise est exposée.
Ces dispositifs sont alors orchestrés par des mécanismes et des processus de supervision, de reporting et de gestion d’incidents dont le but est de contrôler l’efficience des mesures mis en œuvre et éventuellement les ajuster selon les résultats qu’elles auront réalisés. C’est ce qui est communément appelé cycle PDCA (Plan, Do, Check, Act), ou encore roue de Deming.
Un modèle parfait ? Non !
En théorie efficace, le modèle de management de la sécurité montre souvent ses limites en particulier par rapport à la complexité (voire la lourdeur) de sa mise en œuvre. C’est un système qui mobilise beaucoup de ressources (en efforts et investissements). Dans certains cas de figure, il peut même s’avérer contre-productif car il met en jeu des processus peu résilients aux changements et aux évolutions. Cette limitation prend tout son sens pour les grandes entreprises ayant des SI complexes.
Tous ceux qui ont pratiqué les métiers de la Sécurité Informatique (ou du moins côtoyé des intervenants les pratiquant) tout aussi bien sur l’aspect conceptuel (RSSI, risk management…) qu’opérationnel, se sont certainement confrontés des choix cornéliens donnant lieu à des dilemmes et débats.
D’un côté les prérogatives Sécurité (souvent qualifiées de rigides), de l’autre celles du Business (toujours plus ambitieuses) !
J’ai un business innovant et porté vers le digital. Qu’est-ce que je fais ?
Aux antipodes des processus Sécurité classiques, le contexte business actuel est régi par de nouvelles règles de jeu. Les méthodologies de gestion de projet agiles, couplées aux techniques DevOps bousculent les concepts de sécurité et les mettent à rude épreuve ! On parle de time-to-market, mais encore de cycles de vie très courts pour les changements et les déploiements (quelques semaines, voire quelques jours contre quelques mois à quelques années pour les cycles classiques).
Paradoxalement, pour rassurer les consommateurs des services digitaux, les besoins en sécurité sont accrus du fait de l’exposition et des risques croissants qui pèsent sur les plateformes et les données.
Le décalage entre les besoins des Product Owners et des Sponsors d’une part et la capacité à satisfaire les besoins en sécurité d’autre part n’a jamais été aussi compliqué à gérer. Nous assistons à un véritable « face off » Business Sécurité ! C’est tout de même un affrontement qui ne doit pas déboucher sur un vainqueur car Business et Sécurité ne peuvent avancer que de pair.
Nous sommes probablement à l’aube d’un tournant dans les technologies utilisées et le mind-set du métier Sécurité.
La suite dans un prochain article. Pour échanger à ce sujet, prenez contact avec iDNA contact@idna.fr
