Il est maintenant largement convenu que, à l’instar de la gestion de la qualité, il est souhaitable de mettre en oeuvre la SSI dans le cadre d’un système de management (ISO27001 par exemple). Il n’en demeure pas moins que cette approche a pour effet de concentrer le traitement des risques sur les vulnérabilités liées à l’administration système et réseau. Or, les attaques ciblent toutes les composantes des systèmes modernes, en particulier, les applications à chaque étape de leur cycle de développement et d’exploitation. Cette notion de cycle de vie des systèmes est souvent négligée. Dans le meilleur des cas – quand on s’y intéresse – on ne regarde que les menaces dues aux erreurs d’utilisation ou au trafic de données vers ou provenant de ces applications.
Au milieu des années 80, le gouvernement américain a déclaré l’industrie des logiciels « industrie stratégique », ce qui a eu pour conséquence d’orienter le « génie logiciel » vers une formalisation de ce cycle de vie. Ainsi est né le « Modèle de capacité de maturité » (Capability Maturité Model – CMM) dont la caractéristique est d’appréhender les systèmes comme un ensemble de processus collaboratifs. Cette approche s’est déclinée en un ensemble de méthodes, tels que « System Engineering » (SE‐CMM), Software Engineering (SW‐CMM), Software Acquisition (SA‐CMM), Integrated Product Development (IPD‐CMM), Ressources Humaines (P‐CMM), Supplier Sourcing (SSCMM), etc. Curieusement, jusqu’au début des années 90, ces formalismes n’intégraient pas la SSI : « la sécurité de l’application, quelqu’un (un spécialiste) ou quelque chose (un produit) s’en occupera et de toute façon, c’est un problème d’exploitation ; l’analyse et la conception doit se concentrer sur la seule satisfaction des utilisateurs ».
Le SSE‐CMM (System Security Engineering ‐ Capability Maturity Model) comble cette insuffisance. Partant des concepts de l’ingénierie des systèmes (utilisés par exemple dans le génie logiciel), il permet d’établir le principe suivant : plus un processus est arrivé à maturité, plus les résultats seront adéquats et cohérents et cela sans égard à l’approche ou la méthode utilisée. Le « modèle de maturité » ne décrit pas une façon de faire, mais des pratiques généralement utilisées. Il prend en compte toutes les étapes du cycle de vie (conception, développement, exploitation…), tous les éléments d’une entité (gestionnaires, structure d’organisation, ingénierie…), les interrelations internes (logiciels, matériels, élément humain, exploitation…) et externes (partenaires, fournisseurs, certification, …). Le SSE‐CMM définit les niveaux de maturité. Ces niveaux sont déterminés par la façon dont un organisme exécute, contrôle, maintient et fait le suivi d’un processus. Il propose un modèle d'auto‐évaluation de l'ingénierie de sécurité des systèmes – c’est son intérêt principal ‐, en revanche, il ne permet pas d’effectuer une évaluation de la sécurité des systèmes (au sens des Critères Communs), et ne constitue pas une méthode de gestion de la sécurité au sens entendu par l’ISO27000 … même si tous ces aspects sont bien entendu liés.
Ce document est protégé. Contacter Th.Mouthuy à in2p3 pour obtenir la clef