measures ssdlc
En savoir plus sur diverses mesures de sécurité à mettre en œuvre pour un SDLC ou SSDLC sécurisé:
La technologie se développant rapidement, les menaces de piratage et de vol de données sécurisées liées à la sécurité ont également augmenté en conséquence. Ainsi, il ne fait aucun doute que la croissance de la technologie lance des défis aux fabricants de logiciels pour s'assurer que leur logiciel est solide et robuste contre les menaces et les vulnérabilités de sécurité.
Un logiciel ne peut pas être publié, même s'il fonctionne parfaitement pour la fonctionnalité prévue, sauf s'il s'avère hautement sécurisé et répond aux normes de sécurité et de confidentialité spécifiées et réglementées, en particulier dans des secteurs tels que la défense, la finance et la santé qui impliquent des données personnelles et financières. .
On ne peut pas se permettre d'avoir un défaut de sécurité dans le produit lorsqu'il est déployé, qu'il soit de gravité élevée ou moyenne. Il est donc essentiel de protéger le logiciel et les données de tout type d’attaque, de menaces malveillantes, de vulnérabilités et d’assurer la fiabilité du logiciel pour l’utilisateur final.
Contrairement à notre développement logiciel traditionnel, les tests à la dernière phase après le développement de l'ensemble du logiciel ne sont pas plus efficaces. Avec la mise en œuvre des concepts Agile, DevOps et ShiftLeft, il est essentiel de réaliser des tests au début ainsi qu'à chaque phase du cycle de vie de l'application.
Cela dit, la sécurité du logiciel ne peut pas être construite ou même testée à la dernière étape et doit donc être construite à chaque phase pour assurer la sécurité totale du logiciel.
Ce que vous apprendrez:
Mesures de sécurité pour SSDLC
Vous trouverez ci-dessous les différents moyens de mesures liées à la sécurité qui peuvent être mis en œuvre tout au long du cycle de vie du développement logiciel afin de garantir un SDLC ou un SSDLC sécurisé et, dans la mesure du possible, les défauts ne sont pas autorisés à passer à la phase suivante.
Les diverses analyses et évaluations de la sécurité auxquelles la sécurité doit être intégrée dans les phases SDLC sont.
- Phase des exigences
- Phase de planification
- Phase d'architecture et de conception: Évaluation des risques de sécurité basée sur la conception.
- Phase de développement: Secure Code Analysis, une analyse statique du code pour la sécurité.
- Phase de mise en oeuvre: Analyse dynamique du code, un test de sécurité des applications.
- Test - Phase de pré-déploiement: Test de pénétration et analyse de vulnérabilité.
# 1) Phase des exigences
- Principalement, afin de garantir que les mesures de sécurité nécessaires sont intégrées dans le logiciel, Exigences spécifiques liées à la sécurité doivent être clairement saisis pendant la phase des exigences avec suffisamment de détails et les résultats attendus.
- Tout en identifiant les cas d'utilisation et les scénarios commerciaux typiques, un ensemble clair de Cas d'utilisation et scénarios liés à la sécurité à des fins de vérification doivent être identifiés afin de capturer les fonctionnalités de sécurité et de concevoir des scénarios de test de sécurité.
Vous trouverez ci-dessous quelques exemples illustrant les exigences explicites liées à la sécurité qui peuvent être capturées.
Sec-Req-01: Le système doit avoir des mesures d'authentification en place à toutes les passerelles et points d'entrée.
Sec-Req-02: Le système doit implémenter l'authentification via un écran de connexion sécurisé.
Sec-Req-03: Les DONNÉES PERSONNELLES seront cryptées au repos.
# 2) Phase de planification
À un niveau élevé, mais pas seulement limité à ceux-ci, les points suivants doivent être pris en compte lors de la phase de planification.
applications pour télécharger des vidéos sur youtube
- Une forte, Équipe de sécurité dédiée , fonctionnant en dehors du PMO (project management office) de l'équipe programme, composé de Agent de sécurité, architectes de sécurité, testeurs de sécurité être formé pour mener et gérer toutes les activités liées à la sécurité du programme de manière impartiale. Pour chacun de ces rôles, un RnR (rôles et responsabilités) et un RACI clairs sont définis.
- Tout escalades, ambiguïtés liés aux problèmes de sécurité doivent être traités par le PSO (Product Security Officer) afin que l'équipe de sécurité fonctionne correctement et aide à prendre les bonnes décisions.
- Un robuste Stratégie de test de sécurité il faut identifier comment mettre en œuvre les exigences liées à la sécurité, comment, quand et quoi tester, quels outils doivent être utilisés à chaque étape.
- Il est obligatoire d'impliquer le Point de contact sécurité pour toutes les discussions techniques / d'examen liées au programme afin que l'équipe de sécurité soit au courant de tout changement survenant dans le programme.
# 3) Phase d'architecture et de conception
Le fait d'accorder plus d'attention aux aspects de sécurité dès le début de la phase de conception aidera à prévenir les risques de sécurité et à réduire les efforts considérables dans les modifications de conception ultérieurement dans le SDLC.
Lors de la conception du logiciel et de l'infrastructure sur laquelle le logiciel sera hébergé, tous les Implémentations de conception de sécurité doivent être bien conçus avec la participation des architectes de la sécurité.
Toute ambiguïté et tout conflit entre les aspects fonctionnels et non fonctionnels de la conception et de l'architecture doivent être résolus grâce à des séances de brainstorming impliquant les bonnes parties prenantes.
Au cours de cette phase, une évaluation détaillée des risques liés à la sécurité des produits, parfois également appelée «Évaluation statique» doit être effectuée par l'équipe d'experts Sécurité.
Évaluation des risques de sécurité comprend un examen des programmes du point de vue de la sécurité au stade de la conception / architecture préliminaire pour identifier les failles liées à la sécurité du point de vue de la conception et augmenter en conséquence le produit Risques de sécurité à l'équipe de projet pour y remédier et éviter d'entrer dans la phase suivante.
Ces évaluations sont effectuées sur la base des directives, normes et contrôles de sécurité organisationnelle / industrielle décrits dans ces documents. Par exemple. UXW 00320, UXW 030017
Lors de l'évaluation des risques liés à la sécurité du produit:
qu'est-ce que le test de la boîte noire avec l'exemple
- Les exigences, les fonctionnalités, les récits d'utilisateurs et leurs documents de conception sont examinés, en fonction des détails, des artefacts partagés par l'équipe du projet, Par exemple. Documents de conception (HLDD et LLDD). Les évaluations impliquent également des discussions avec les membres de l'équipe de projet concernés en cas d'absence de documents ou pour clarifier le cas échéant.
- Les lacunes sont identifiées lors de la mise en correspondance des exigences de sécurité du programme par rapport aux normes établies et aux autres meilleures pratiques. Parfois, des modèles de menaces sont également développés en fonction des lacunes identifiées.
- Ces lacunes sont identifiées comme des risques de sécurité potentiels, notamment la suggestion de mesures d'atténuation possibles pour la mise en œuvre, sont soulevées et gérées.
- Une fois que ces atténuations sont mises en œuvre par l'équipe de projet, elles sont vérifiées pour la fermeture via des cas de test appropriés conçus par l'équipe de test du système.
- La matrice de gestion des risques, qui assure la traçabilité, est préparée pour suivre ces risques. L'approbation et la signature avec le risque résiduel seront prises par l'architecte de sécurité et le PSO.
Les modèles de menaces typiques identifiés lors de la phase de conception sont liés à la validation des entrées, à la gestion de l'audit / des journaux, aux configurations et aux chiffrements. L'identification des risques comprend les vulnérabilités d'attaque telles que les mots de passe faibles, les attaques simples par force brute, etc.,
Les examens typiques incluent les risques liés à l'accès aux données personnelles, à l'accès aux pistes d'audit, à la mise sur liste noire des entités, au nettoyage des données et à la suppression.
Exemples de scénarios de test:
- Vulnérabilité de Buffer Overflow: Pour s'assurer qu'en fuzzing manuellement les paramètres, il ne devrait pas être possible de ralentir le serveur et de forcer le serveur à ne pas répondre (déni de service).
- Désinfection des données: Pour garantir une désinfection appropriée des données pour chaque entrée et sortie afin que l'attaquant ne puisse pas injecter et stocker le contenu malveillant dans le système.
# 4) Phase de développement
Analyse du code sécurisé est un Évaluation du code statique méthode utilisée pour évaluer la Code de sécurité des différentes fonctionnalités du logiciel utilisant un outil de numérisation automatisé. Exemple: Fortifier.
Cette analyse est effectuée à chaque enregistrement / construction de code pour analyser le code généré pour les menaces de sécurité. Cette évaluation est généralement effectuée au niveau de la User Story.
- Les scans Fortify via des plugins doivent être installés sur les machines du développeur.
- Fortify doit être intégré au modèle de build.
- Une analyse automatisée sera effectuée sur toutes les versions sur une base quotidienne.
- Le résultat de l'analyse sera analysé par l'équipe de sécurité pour les faux positifs.
- Les défauts identifiés par cette évaluation sont soulevés et gérés jusqu'à la fermeture, de sorte que l'infiltration est minimisée / remise à zéro au niveau suivant.
Exemples de scénarios de test:
- Pour s'assurer que les données sensibles ne sont pas envoyées en texte brut pendant la transmission des données.
- Pour garantir une transmission sécurisée des données, les API externes doivent être déployées sur un canal HTTPS.
# 5) Phase de mise en œuvre
Analyse de code dynamique n'est rien d'autre que les tests de sécurité des applications, également appelés tests OWASP (Open Web Application Security Project). L'analyse de vulnérabilité et les tests de pénétration (VAPT) doivent être effectués lors de la phase de mise en œuvre / de test.
Cette analyse évalue les binaires et certaines configurations d'environnement et renforce encore le code pour les exigences de sécurité.
Dans le cadre de cette analyse, le Comportement dynamique ou les fonctionnalités de diverses fonctionnalités des programmes sont analysées pour détecter les vulnérabilités liées à la sécurité. Des cas d'utilisation et des scénarios commerciaux stipulés sont également utilisés pour effectuer une analyse de code dynamique.
Cette activité est effectuée sur le Constructions de test en utilisant divers outils de sécurité avec une approche automatisée et manuelle.
- Les outils d'interface utilisateur HP WebInspect, Burp Suite, ZAP et SOAP sont généralement utilisés pour vérifier les vulnérabilités par rapport aux bases de données de vulnérabilité standard ( Exemple: Top 10 de l'OWASP )
- Cette activité est cependant principalement automatisée, en raison de certaines restrictions d'outils, un certain travail manuel peut être nécessaire pour trier les faux positifs.
- Ceci est idéalement effectué dans un environnement séparé (System Testing Environment), où le logiciel prêt pour les tests est déployé.
- Les vulnérabilités doivent être soulevées et mises à jour avec les atténuations suggérées.
Les modèles de menaces typiques identifiés au cours de cette analyse sont liés à la validation des entrées, à l'authentification et à la gestion de session interrompues, à l'exposition des données sensibles, au XSS et à la gestion des mots de passe.
Exemples de scénarios de test:
- Gestion des mots de passe: Pour s'assurer que les mots de passe ne sont pas stockés en texte brut dans les fichiers de configuration ou n'importe où dans le système.
- Fuite d'informations système: Pour garantir que les informations système ne fuient à aucun moment, les informations révélées par printStackTrace pourraient aider l'adversaire à partir d'un plan d'attaque.
# 6) Test - Phase de pré-déploiement
Tests de pénétration , Pen Test en bref et Infra VAPT (Vulnerability Analysis and Penetration Testing) , est le test holistique complet avec solution complète et les configurations (y compris le réseau) qui est idéalement réalisé dans un environnement de pré-production ou de production.
Ceci est principalement effectué pour identifier les vulnérabilités de base de données et les vulnérabilités de serveur ainsi que toutes les autres vulnérabilités. Il s'agit de la dernière étape des tests de sécurité qui serait effectuée. Cela inclut donc également la vérification des défauts et des risques signalés précédemment.
- Des outils comme Nessus, Nmap, HP Web Inspect, Burp Suite, ZAP qui sont disponibles sur le marché sont utilisés pour effectuer des tests de stylet.
- L'analyse des applications Web à l'aide d'outils automatisés et leur exploitation pour une vérification plus approfondie sont effectuées au cours de ces tests. Les tests sont effectués pour simuler le comportement de l'attaquant réel et peuvent donc inclure également quelques tests négatifs.
- Vulnérabilité de l'infrastructure L'évaluation comprend l'analyse, l'analyse et l'examen de la configuration de la sécurité de l'infrastructure (réseaux, systèmes et serveurs) pour identifier les vulnérabilités et vérifier la résilience face aux attaques ciblées.
- Ceci est réalisé dans un environnement de pré-production ou de type production, où le logiciel prêt à être déployé est testé et simule ainsi l'environnement en temps réel.
- Les vulnérabilités sont identifiées à l'aide de scanners et de techniques manuelles pour éliminer les faux positifs. En outre, des scénarios commerciaux en temps réel seront réalisés lors des tests manuels.
- Un rapport final sur l'ensemble de l'analyse de sécurité qui est effectuée pour l'ensemble du programme sera produit, soulignant l'état des éléments à haut risque le cas échéant.
Exemples de scénarios de test:
- Pour garantir que les méthodes HTTP vulnérables ne sont pas activées.
- Pour garantir que les informations sensibles des autres utilisateurs ne sont pas visibles en texte clair sur le réseau.
- Pour garantir que la validation du téléchargement de fichier est mise en œuvre pour éviter le téléchargement d'un fichier malveillant.
Résumé tabulaire pour SSDLC
Le tableau ci-dessous résume les différents aspects de l'analyse de sécurité qui sont expliqués ci-dessus.
Phase SDLC | Analyse clé effectuée | Que fait exactement dans ces évaluations | Saisir | Les outils utilisés | Production |
---|---|---|---|---|---|
Conditions | Pour s'assurer que les exigences de sécurité sont capturées efficacement. | Les exigences sont analysées. | Documents sur les exigences / témoignages d'utilisateurs / fonctionnalités | Manuel | Les exigences de sécurité sont intégrées dans les spécifications des exigences. |
Planification | Équipe de sécurité à mettre en place Préparation de la stratégie de test de sécurité. | Équipe identifiée et mise en place. Stratégie préparée, revue et approuvée avec les parties prenantes. | Néant | Manuel | Configuration de l'équipe de sécurité avec RnR et RACI définis. Document de stratégie de test de sécurité approuvé. |
Conception | Évaluation des risques de sécurité | Examen de la documentation relative au programme pour identifier les failles de sécurité. Discussion avec l'équipe. Les risques sont identifiés et des mesures d'atténuation sont suggérées. | Documents relatifs au projet: HLDD, LLDD. | Revue manuelle | Risques de conception identifiés. Matrice de gestion des risques avec les atténuations suggérées. |
Développement | Analyse du code sécurisé (évaluation statique) | Les scanners de sécurité sont connectés aux machines du développeur. Outil de sécurité intégré au modèle de construction. | Code développé | Automatisez les scanners (Fortify). Triage manuel des faux positifs. | Défauts de code sécurisé. Matrice de gestion des risques avec atténuation. |
Mise en œuvre | Analyse de code dynamique (évaluation dynamique) | Test de sécurité des applications effectué. | Version testée à l'unité Environnement de test dédié | Outils de test de sécurité (HP WebInspect, Suite Burp, ZAP Triage manuel des faux positifs. | Défauts d'analyse de code dynamique. Matrice de gestion des risques avec atténuation. |
Test / pré-déploiement | Test du stylo, Infra VAPT | Test de pénétration et Infra VAPT à l'aide de scénarios en temps réel. Vérification des risques / défauts signalés précédemment. | Prêt à déployer la version. Pré-production ou production comme environnement. | Outils de test de sécurité (Nessus, NMAP, HP WebInspect) Triage manuel des faux positifs. | Matrice de gestion des risques avec atténuation. Rapport final de test de sécurité avec l'état des risques. |
Conclusion
Ainsi, avec la mise en œuvre de tous ces aspects liés à la sécurité intégrés à travers les différentes phases du SDLC, aide l'organisation à identifier les défauts de sécurité au début du cycle et permet à l'organisation de mettre en œuvre les atténuations appropriées, évitant ainsi les Défauts de sécurité à haut risque dans le système Live.
L'étude montre également qu'une majorité des défauts de sécurité sont induits dans le logiciel lors de la phase de développement, c'est-à-dire lors de la Phase de codage , dans lequel le codage n'a pas suffisamment pris en charge tous les aspects de sécurité, quelle qu'en soit la raison.
Idéalement, aucun développeur ne voudrait écrire un mauvais code qui compromet la sécurité. Ainsi, afin de guider les développeurs sur la façon d'écrire un logiciel sécurisé, le prochain tutoriel couvre Meilleures pratiques et directives de codage pour les développeurs, pour assurer une meilleure sécurité du logiciel.
Nous espérons que ce tutoriel sur Secure SDLC ou SSDLC vous a été utile !!
lecture recommandée
- Phases, méthodologies, processus et modèles du SDLC (cycle de vie du développement logiciel)
- 10 meilleurs outils de test de sécurité des applications mobiles en 2021
- 19 puissants outils de test de pénétration utilisés par les professionnels en 2021
- Directives de test de sécurité des applications mobiles
- Test de sécurité réseau et meilleurs outils de sécurité réseau
- Test de sécurité (un guide complet)
- Top 4 des outils de test de sécurité Open Source pour tester une application Web
- Guide de test de sécurité des applications Web