La prise en compte de la cyber sécurité dans les cycles de développement est une activité primordiale. Plusieurs référentiels de bonne pratique sont disponibles. Par exemple, la norme ISO 27034 fournit un cadre pour renforcer la sécurité du processus de développement. Autres exemples, le modèle BSIMM, SAMM et SSDF. SAFECode est une association internationale qui se focalise sur les bonnes pratiques visant à améliorer la sécurité dans les développements. Cette organisation publie et met à jour régulièrement son référentiel de sécurisation du cycle de développement. Comment identifier les exigences. Comment gérer les composants externes « OpenSource » ou et propriétaires. Comment gérer les problèmes de sécurité. Comment traiter les vulnérabilités découvertes dans ses applications.

Mesures de sécurité applicative

Les prérequis pour identifier et appliquer les mesures de sécurité applicative sont issus du cycle suivant

1. Modélisation des menaces.
2. Sélection des mesures appropriées.
3. Communication avec les équipes de développements.
4. Validation lors de la mise en œuvre.
5. Audit de conformité.

Conception

Les principes de conception sécurisée ne sont pas nouveaux. On peut citer ainsi la simplicité, l’interdiction par défaut, la médiation obligatoire (concept repris dans les architectures Zero-Trust), le moindre privilège, l’acceptabilité ou la défense en profondeur. Les revues de conception et d’architecture doivent être intégrées aux programmes de sécurité. L’utilisation de la cryptographie que ce soit pour le chiffrement, le contrôle d’accès ou la signature électronique doit être minutieusement contrôlée pour ne pas être vecteur de failles. Par exemple l’utilisation de TLS entre deux API doit respecter les standards en vigueur (version, longueurs de clés, gestion des clés, choix des algorithmes…). Autre exemple, la gestion des identités et des accès doit être standardisés (par exemple mise en œuvre de SAML en fédération d’identités et authentification unique).

Développement

C’est la phase qui peut amener de nombreuses erreurs, sources de failles de sécurité. En fonction des langages et des environnements de développement, des standards doivent définis. Il faut rester réaliste en publiant des référentiels internes applicables et connus des développeurs. Les outils (SAST, DAST) intégrés aux plates-formes de développement s’ils ne sont pas suffisants restent très intéressants pour aider les développeurs à respecter ces standards. En France, l’ANSSI publie et met à jour régulièrement un guide de développement sécurisé en langage C. Autre exemple, un référentiel de développement sécurité sous Android. De nombreux guides très utilisés par la communauté sont publiés par l’OWASP.

Gestion des composants externes

La réutilisation de composants tierces est fréquente. Il peut s’agir par exemple d’une librairie open source ou bien d’un composant propriétaires, comme une API. Le référentiel du MITRE CWE (Common Weakness Enumeration) référence ainsi dans ce domaine le CWE 477, le CWE 657 ou le CWE 242.

Chaque exigence de sécurité doit être tracée afin d’être formellement vérifiée. Une bonne pratique est de gérer les mesures par application dans un ADLM (Application Development Lifecycle Management).

Test et validation

Cette phase de test et de validation est importante. Elle reste vraie quelle que soit la méthode de développement. Les outils de test automatique sont généralement classés en six catégories :

1. Analyse statique (SAST - Static Analysis Security Testing).
2. Analyse dynamique (DAST - Dynamic Analysis Security Testing).
3. Fuzzing.
4. Analyse de la composition logicielle (SCA - software composition analysis).
5. Scan de vulnérabilités.
6. Scan de configurations des plateformes (par exemple liés à des guides de durcissement CIS).

Les tests manuels comprennent les tests d’intrusion et toutes les phases de vérification définie dans le processus. Par exemple la vérification manuelle que des exigences liées à la gestion des identités des accès sont mises en œuvre et efficaces.

Prise en compte des vulnérabilités

Malgré toutes les précautions prises par les équipes de développement, il est impératif de prévoir comment prendre en compte les nouvelles vulnérabilités logicielles découvertes après la publication d’une version. Deux normes donnent des recommandations pour encadrer ce processus :

• La norme ISO 29147.
• La norme ISO 30111.

De plus en plus d’éditeurs précisent dans un fichier security.txt public les contacts et le processus qui permet aux chercheurs découvrant des vulnérabilités de les contacter. Cela fait actuellement l’objet d’une normalisation auprès d’un groupe de l’IETF. Le FIRST, une organisation internationale de CERT/CSIRT publie également un document intéressant pour définir ce processus. Le PSIRT (Product Security Incident Response Team) est défini par le FIRST comme service en charge de ce processus.

Source : FIRST - www.first.org

Pour en savoir plus sur les 20 meilleures formations sur la sécurité des systèmes d’information, téléchargez gratuitement notre livre blanc ci-dessous :