Comment développer de nouvelles applications ou ajouter des nouvelles fonctionnalités à des applications en production sans introduire de nouvelles vulnérabilités ou compromettre une infrastructure en mode Run ?

La réponse à cette question est, en effet nous pouvons le faire à condition d’intégrer les préoccupations de sécurité ou de cybersécurité dès les premières phases du cycle de développement de l’application et tout au long de ce cycle. Ce type de démarche est bien connu par les professionnels sous l’acronyme S-SDLC (Secure Software Development LifeCycle) ou de manière abrégée la « Security by Design ».

Cette approche, inspirée de la norme ISO/IEC 27034:2011, est aujourd’hui recommandée dans tous les développements d’applications et parfois exigée dans les projets qui touchent directement ou indirectement à la sûreté de fonctionnement des appareils, et par ricochet à la sécurité des personnes (Transport, IoT, Avionique, Nucléaire).

Si l’on analyse bien l’approche “security by design”, nous remarquons qu’elle consiste en fait à inclure la notion de risque dans un projet dès la phase de conception. C’est donc un travail d’identification des vulnérabilités de l’application elle-même, des évènements redoutés voire parfois des scénarios de sinistre majeur impliquant l’indisponibilité de l’application.

Dans certains projets, on cite également les approches “privacy by design”. En fait ces approches viennent en support à la « security by design » et font référence à la protection des données personnelles des utilisateurs. Ce sont des approches qui encadrent à tous les niveaux, le stockage et/ou le partage de la donnée personnelle avec des tiers.

La « Security by Design » permet donc de modéliser les risques et les menaces de la solution en amont de la phase de conception ; l’idée étant d’intégrer les mécanismes de protection plus tôt et de manière plus efficiente au produit.

En pratique, Il existe plusieurs modèles de S-SDLC : ceux définis par le NIST 800-64, les référentiels OWASP CLASP, Microsoft SDL et enfin par la méthodologie Agile (concept de Security focused stories et Security Sprints). La différence entre ces approches réside dans la répartition de la démarche de sécurisation dans les étapes de développement.

Les principes S-SDLC s’appliquent aussi bien aux cycles de vie des applications embarquées qu’aux grands projets d’applications SI. La méthodologie est similaire mais s’articule pour les grands projets de transformation digitale des SI autour de la notion de cyber-risque de cyber menaces tels qu’elles sont définies par des nouveaux référentiels et règlementation en vigueur.

En termes de gouvernance, ces mêmes phases sont également encadrées par des accords entre le maître d’œuvre et le maître d’ouvrage dans lesquels les priorités, les engagements et les exigences sont consignées (aussi bien en mode Build que Run).

Nous pouvons estimer aujourd’hui que la mise en place d’un S-SDLC augmenterait le coût global substantiellement en fonction des enjeux et de la taille du projet (Source : US-CERT, Estimating Benefits from Investing in Secure SDLC, revisé en Juillet 2013  ). Mais cet investissement est revalorisé par  la diminution des coûts liés à la maintenance et la gestion des incidents en mode Run.

Le S-SDLC et sa déclinaison Cyber S-SDLC permettent donc de maîtriser les menaces potentielles en amont des projets. De manière plus précise, l’approche implémente des processus SSI efficaces (y compris la sensibilisation des acteurs du projet aux enjeux de la sécurité et de la cybersécurité) qui permettent de garantir l’intégrité des infrastructures, des données et des applications en production tout au long du cycle de vie des projets.

En conclusion, la «cyber » security by Design  est une démarche qui peut être enrichie, adaptée et appliquée selon le contexte de chaque métier. Elle participe à la mise en place d’une bonne hygiène informatique et permet une maîtrise optimale du niveau de sécurité de l’infrastructure. Elle dissuade les pirates en limitant la surface d’attaque du SI ou de l’application sur une petite échelle.

Pensons RoR (Return on Risk) et non RoI (Return on Investment) en adopant de telles démarches dans nos projets car cela nous permet de valoriser la sécurité et la cybersécurité par des tableaux de bord plus pertinents affichant des indicateurs plus significatifs.

Article rédigé par Karim Slimani, Directeur de Projet chez Formind