'Shift security left' (la sécurité le plus tôt possible) est un paradigme répandu dans le secteur informatique. S’il est très facile à comprendre, il n’est pas évident à mettre en œuvre. Son adoption exige plus que la simple utilisation des technologies : il s'agit d'un changement de culture, d'une approche intégrée de la sécurité des applications et d'un processus d'apprentissage continu. La plupart des start-ups sont désireuses de l'adopter, mais elles tombent sur des obstacles lors de son application dans la pratique. Sirris vous propose une solution : 'le plan le plus simple d'amélioration du profil de sécurité en 3 semaines'.
Les stratégies existantes sont peut-être adaptées aux entreprises ayant un profil de sécurité défini, mais il n'existe pas de lignes directrices communes sur la manière d'aborder la sécurité des applications, surtout si les ressources et l’expertise de la start-up sont limitées. Quelles sont les mesures de base à prendre afin de disposer d'un plan d'amélioration de la maturité de la sécurité clair et d'être prêt à répondre aux questions des clients sur la confiance et la sécurité ?
Animés par la passion de trouver une solution pragmatique qui fonctionne vraiment pour les start-ups, nous avons mené un travail de recherche et de réflexion de près de trois mois chez Sirris. Résultat : le plan le plus simple d'amélioration du profil de sécurité en 3 semaines. Il s'inspire de la philosophie DevSecOps et des normes OWASP.
Dans les articles précédents, nous avons expliqué les actions de la première et de la deuxième semaine. Quelles sont les dernières étapes du plan d'amélioration de la sécurité le plus simple ?
Troisième semaine : réaliser des examens de code manuels pour les modules d'authentification et de cryptographie
Nous proposons de consacrer la troisième semaine à l'examen manuel du code. La norme de sécurité applicative la plus pragmatique, OWASP ASVS, stipule directement que la maturité de sécurité de niveau 2 ne peut pas être atteinte sans examen manuel. Les exigences de niveau 2 sont recommandées pour toutes les applications qui traitent n'importe quel type de données personnelles ou sensibles. En d'autres termes, il s'agit d'applications qui collectent des données clients de quelque nature que ce soit. Bref, il est fort probable que votre start-up doive elle aussi le faire !
En effet, les analyseurs de code statique tels que SonarQube (voir notre article de blog précédent) sont capables de trouver ou de signaler la majorité des problèmes de code standard. Toutefois, les modules et bibliothèques traitant des données sensibles exigent une attention particulière. Il n'est pas facile d'organiser un tel examen pour un référentiel de code complet. Dans la plupart des cas, un savoir-faire spécifique en matière de sécurité requis nécessaire et l'opération prend un temps considérable. La quantité de travail peut être réduite en assurant en premier lieu l'examen des modules de sécurité les plus critiques. Nous proposons de débuter par les modules d'authentification et de cryptographie au cours de la troisième semaine du plan d'amélioration de la sécurité. Même sans savoir-faire particulier en matière de sécurité, il est possible de se conformer aux exigences de sécurité et aux bonnes pratiques. Même si vous n'êtes pas un expert en cryptographie, l'élément important est que tous les algorithmes et approches normalisés industriellement soient connus et limités. Bien que la spécification et la terminologie puissent sembler effrayantes pour un profane, le choix est très simple et direct. Il n'est pas difficile de vérifier que les algorithmes, paramètres et valeurs sont corrects. Voici les étapes que nous proposons :
1. Choisissez vos fragments de code sensibles. OWASP Security Knowledge Framework permet d'automatiser ce processus. Les fragments doivent être courts et correspondre à une exigence spécifique en matière d'authentification ou de cryptographie :
