Sécurité en développement logiciel

Développement et maintenance des systèmes

La stratégie d’une entreprise développant des logiciels se doit d’envisager les propriétés et les implications de la sécurité des applications, des systèmes et des services utilisés ou fournis par l’entreprise tout au long du cycle de vie d’un projet.

La charte de sécurité de développement des applications, systèmes et services de l’entreprise doit prévoir que les équipes et les personnes mettent en œuvre les mesures de sécurité appropriées dans les applications, les systèmes et les services en cours de développement, en fonction des risques et préoccupations de sécurité identifiés. La charte doit mentionner que l’entreprise dispose des rôles et des responsabilité de sécurité dont la mission est de fournir des lignes directrices de sécurité et d’assurer l’évaluation des risques.

L’entreprise doit mettre en oeuvre un certain nombre de mesures visant à garantir que les produits logiciels et services quelle propose aux utilisateurs soient conformes aux normes les plus strictes sur la sécurité logicielle. Cet article décrit une approche en matière de sécurité logicielle, celle-ci peut s’adapter et évoluer en fonction de l’organisattion et de la culture de l’entreprise.

Consultation et revue de sécurité

S’agissant de la conception, du développement et du fonctionnement des applications et services, les rôles de sécurité inclus les catégories principales de services de consultation suivantes aux équipes de développement, techniques et production :

• Revues de sécurité au niveau de la conception : évaluations au niveau de la conception des risques de sécurité d’un projet et mesures d’atténuation correspondantes, tout en considérant leur caractère approprié et leur efficacité.
• Revues de sécurité au niveau de l’implémentation : évaluation au niveau de l’implémentation des artefacts de code pour mesurer leur fiabilité par rapport aux menaces de sécurité applicables.
• Consultation de sécurité : consultation en continu des risques de sécurité associés à un projet donné et solutions éventuelles aux problèmes de sécurité, souvent sous forme d’exploration de l’espace de conception dans les phases initiales des cycles de vie des projets.

Une multitude de types de problèmes de sécurité peuvent intervenir au niveau de la conception du produit, c’est pourquoi ils doivent être pris en considération et résolus au plus tôt lors de la phase de conception du produit ou du service. La finalité essentielle de la revue de sécurité au niveau conception est de garantir la prise en compte de ces considérations. 

Dans ce cadre, la revue de sécurité au niveau de la conception se fixe les objectifs suivants :

• Fournir une évaluation de haut-niveau des risques de sécurité associés au projet, sur la base d’une recherche des menaces réelles en réalisant une analyse des risques.
• Procurer aux décideurs du projet les informations nécessaires afin qu’ils puissent faire des choix éclairés en matière de gestion des risques et intégrer les considérations de sécurité dans les objectifs d’un projet.
• Fournir des lignes directrices quant au choix et à la mise en œuvre correcte de contrôles de sécurité planifiés (par exemple : protocoles d’authentification ou chiffrement).
• S’assurer que l’équipe de développement dispose de la formation adéquate eu égard aux classes de vulnérabilités applicables, aux schémas d’attaque et aux stratégies d’atténuation appropriées.

Lorsque des projets impliquent des fonctionnalités ou des technologies innovantes, un des rôles de sécurité est chargé de rechercher et d’explorer les menaces, les schémas d’attaque potentiels et les classes de vulnérabilités spécifiques des technologies et fonctionnalités en question. Le cas échéant, l’entreprise peut sous-traiter à des prestataires la consultation de sécurité pour compléter les compétences de l’équipe de sécurité et obtenir une revue indépendante garante d’objectivité afin de valider les revues de sécurité internes.

Sécurité dans le contexte du cycle de vie des logiciels

La sécurité est au cœur du processus de conception et de développement que l’on nomme cycle de vie des logiciels ou Software Devlopment Life Cycle (SDLC) en anglais. L’organisation technique de l’entreprise ne requiert pas que les équipes de développement de produits suivent un processus de développement logiciel particulier, au contraire, les équipes choisissent et mettent en œuvre des processus adaptés aux besoins du projet. Dans ce cadre, un certain nombre de processus de développement logiciel sont utilisés, allant des méthodologies de développement Agile aux processus plus classiques : par étapes, en V ou en cascade.

Sur les illustrations ci-dessous vous pouvez découvrir comment l’intégration de la sécurité se fait dans un cycle en V :

Les processus du développement logiciel

Cycle de développement sécurité

Les processus de revue de la sécurité sont prévus pour fonctionner dans la structure choisie. Leur réussite dépend de la culture technique en matière de qualité et de quelques exigences définies par la direction technique des processus de développement de projet :

• Documentation de conception revue par les pairs.
• Conformité aux lignes directrices de style de codage.
• Revue de code par les pairs.
• Tests de sécurité multi-couches.

Les exigences ci-dessus représentent la culture d’ingénierie logicielle, dans laquelle les objectifs clés sont la qualité, la fiabilité et la maintenabilité des logiciels. Tandis que la finalité première de ces exigences est d’encourager la création d’artefacts logiciels irréprochables en matière de qualité logicielle, les bonnes pratiques de sécurité suggèrent également qu’ils représentent des « moteurs » significatifs et évolutifs en faveur de la réduction de l’incidence de failles de sécurité dans la conception logicielle :

• L’existence d’une documentation de conception suffisamment détaillée constitue une condition préalable du processus de revue de sécurité au niveau de la conception, dans la mesure où lors des premières phases du projet, c’est en général le seul artefact disponible pour élaborer les évaluations de sécurité. Bon nombre de classes de failles de sécurité au niveau implémentation s’apparentent finalement à des défauts fonctionnels courants, à faible risque. La plupart des failles au niveau implémentation sont le résultat d’omissions très simples de la part du développeur.
• Avec des développeurs et des réviseurs de code formés aux schémas de vulnérabilité en vigueur et aux méthodes permettant de les éviter, une culture du développement basée sur la revue par les pairs, insistant sur la création d’un code de haute qualité est un moteur important et évolutif vers une base de code sécurisée.

Les développeurs logiciels de l’équipe de sécurité collaborent avec d’autres développeeurs de l’entreprise sur le développement et la validation de composants réutilisables conçus et implémentés pour permettre aux projets logiciels d’éviter certaines classes de vulnérabilités. Parmi les exemples figurent les couches d’accès aux données conçues pour résister aux failles d’injection de langage de requête SQL, ou les structures de modèles HTML avec défenses intégrées contre les vulnérabilités XSS.

Formation à la sécurité

Reconnaissant l’importance d’une main-d’oeuvre technique formée aux pratiques de codage sécurisé, le responsable sécurité met en place une campagne de communication et un programme de formation à l’intention des équipes, dont le contenu est le suivant :

• Formation des nouveaux développeurs à la sécurité
• Création et gestion d’une documentation complète sur les pratiques sécurisées de codage et de conception
• Références ciblées et contextuelles à la documentation et aux supports de la formation (par exemple, des outils automatisés de test des vulnérabilités fournissent aux ingénieurs des références à la documentation de formation et de fond en rapport avec les bugs ou classes de bugs spécifiques mis en évidence par l’outil)
• Présentations techniques sur les rubriques relatives à la sécurité
• Newsletter sur la sécurité distribuée à l’ensemble des équipes et destinée à informer la main-d’œuvre technique des menaces, schémas d’attaque, techniques d’atténuation, bibliothèques liées à la sécurité, meilleures pratiques et lignes directrices, etc. recensés récemment
• Ateliers sécurité, sous forme de conférences récurrentes à l’échelle de l’entreprise, qui réunit les développeurs des différentes équipes travaillant sur la sécurité et propose des présentations techniques détaillées sur les sujets de sécurité

Tests et revue de sécurité au niveau implémentation

L’entreprise doit appliquer un certain nombre d’approches pour continuer de réduire l’incidence de failles de la sécurité au niveau de l’implémentation dans ses produits et services :

• Revues de sécurité au niveau implémentation : réalisées par les rôles de sécurité, généralement lors des dernières phases du développement de produits, les revues de sécurité au niveau implémentation visent à valider la résistance d’un artefact logiciel aux menaces de sécurité applicables. Ces revues sont généralement constituées d’une réévaluation des menaces et contremesures identifiées lors de la revue de sécurité au niveau conception, de revues ciblées sur le code critique pour la sécurité, de revues de code sélectives permettant d’évaluer la qualité du code du point de vue de la sécurité, et de tests de sécurité ciblés.
• Tests automatisés des failles dans certaines classes de vulnérabilités pertinentes. Pour ces tests, il faut utiliser aussi bien des outils développés en interne que des outils disponibles sur le marché.
• Tests de sécurité réalisés par des ingénieurs de la qualité logicielle dans le contexte des actions menées en matière de test et d’évaluation de la qualité logicielle globale du projet.

Services de consulting

Nous menons les projets de conseils en sécurité avec une offre de services très diversifiée et adaptée à vos besoins, par exemple :

• Audit des processus de développement logiciel
• Rédaction d’une charte sécurité pour les développeurs
• Sensibilisation à la sécurité des développements et du SI
• Mise en oeuvre des processus de revue de la sécurité
• Réalisation d’analyse de risques projet et produit