Longtemps confinées derrière une sécurité périmétrique, les applications au sein d’un système d’information étaient protégées avec des équipements réseaux filtrant les entrées et les sorties d’un environnement technique homogène. Cette logique de bastion avait toutefois une faiblesse structurelle. Si l’attaquant parvenait à s’introduire dans le périmètre sécurisé, la compromission des systèmes s’en trouvait grandement facilitée.
Au début des années 2000, l’avènement des applications web et des smartphones oblige les ingénieurs à repenser leurs conceptions logicielles. Cette multiplication des points d’entrée applicatifs et des flux de données associés nécessite de repenser les architectures en matière de cybersécurité.
D’un paradigme où l’utilisateur était connu de l’entreprise, l’application s’ouvrait à des populations d’utilisateurs inconnues et donc moins maîtrisables. Ce changement impacta notamment les équipements dédiés à la sécurité à l’image des firewalls. Initialement conçus pour sécuriser les flux entrants du système d’information, ces derniers évoluèrent vers la sécurisation des flux sortants mais surtout l’analyse de trafic.
Plutôt que de sécuriser des flux de données toujours plus nombreux et sachant que les techniques de contournement du réseau se multipliaient (comme en atteste la généralisation des VPN), les applications se sont sécurisées dès leurs conceptions. Les méthodes de connexion se sont complexifiées en allongeant les mots de passe puis en multipliant les facteurs d’authentification avec l’usage du smartphone. Les formulaires et méthodes de paiement se sont standardisés. Les utilisateurs sont désormais sensibilisés aux règles de sécurité élémentaires.
Malgré tout, les attaques concernant les logiciels et applications web n’ont eu de cesse d’augmenter. Face à cette menace croissante, un ensemble de méthodes et d’outil ont vu le jour pour standardiser la sécurité des développements logiciels et ainsi répondre à la professionnalisation des attaques.
Le DevSecOps : l’automatisation au service de la sécurité
Plutôt que de prétendre sécuriser une application contre l’ensemble des menaces potentielles, méthode qui s’avère coûteuse et peu efficace, les ingénieurs privilégient le pragmatisme et l’évolutivité.
Pragmatisme car les méthodes de développement modernes favorisent des itérations courtes selon le modèle d’amélioration continue. Les équipes développent des petites fonctionnalités livrées rapidement. Puis, elles identifient les éventuelles faiblesses de conception en testant continuellement et en déployant auprès des utilisateurs. Ce qui est valable pour le développement applicatif l’est tout autant pour la sécurité.
Une fois les règles de base mises en œuvre – encore faut-il s’accorder dessus – le réalisme prévaut en identifiant les risques majeurs que l’on souhaite couvrir selon la fameuse loi de Pareto des 20 – 80. 20% des principales mesures de sécurité permettront de parer à 80% des attaques subies. Reste à espérer que les 20% d’attaques restantes ne soient pas trop impactantes…
Le second critère est l’évolutivité car la sécurité applicative est avant tout un processus, qui ne cesse d’évoluer pour s’adapter au périmètre applicatif mais aussi aux techniques et attaques qui se diversifient dans le temps. Rien ne sert d’avoir des contre-mesures exhaustives si ces dernières deviennent rapidement obsolètes.
Il est plus judicieux de développer une culture de résilience applicative favorisant les tests et déploiements de correctifs réguliers pour les utilisateurs.
Ce processus automatisé mêlant développeurs et opérations s’appelle le « DevOps ». La prise en compte de la sécurité est venue enrichir le terme de manière peu originale en tant que « DevSecOps ».
DevSecOps ou Secure Software Development Lifecycle ?
Si le DevSecOps est le terme à la mode, il ne reflète cependant qu’une partie de la sécurité applicative. En effet, il désigne plus une collection d’outils qu’une méthodologie servant un besoin métier. Le Secure Software Development Lifecycle (SDLC) répond ainsi à ce besoin méthodologique permettant de décorréler la sécurité des seuls outils pour l’adapter aux étapes d’un projet. Elle complète ainsi le DevSecOps en lui apportant le versant organisationnel qui lui manquait.
Cette méthodologie regroupe un ensemble de mesures et de bonnes pratiques, qui dépendent du paysage applicatif, des méthodologies employées et bien sûr des compétences humaines afin notamment de modéliser les menaces et d’implémenter leurs remédiations. A ce titre des outils tels que le OWASP Threat Dragon permettent de faciliter la mise en œuvre de cette démarche notamment en ce qui concerne :
- La planification des scénarios d’attaques (1ère étape de conception)
- La rédaction des tests de sécurité qui en découlent
- La mise à jour des applications en fonction des menaces rencontrées en production.
En réponse à ce volet organisationnel, le DevSecOps permet d’outiller la démarche avec des solutions qui se sont spécialisées au fur et à mesure du temps. Leurs points communs est leur capacité d’automatiser diverses tâches.
Citons dans un premier temps, l’analyse de la sécurité du code au travers d’outils SAST – Static application security testing ou DAST pour des scénarios plus Dynamiques.
Une solution SAST permet ainsi aux développeurs de déceler des vulnérabilités applicatives dans leurs codes, là où une solution DAST s’adresse plus aux testeurs pour évaluer la sécurité d’une solution au travers d’un scénario fonctionnel complet comportant les problèmes de configuration, les traitements des erreurs etc. Les deux solutions sont régulièrement utilisées en tandem.
Les scanners de vulnérabilité prennent souvent le relais lors des phases de test et de mise en production pour consolider une vision de sécurité plus globale.
Ces solutions ne sont bien sûr pas exhaustives. Elles constituent des exemples d’un univers riche et polymorphe, qui ne cesse de s’adapter aux menaces externes tout comme aux usages des développeurs.
D’autre part, il est important de mentionner que si ces outils permettent d’identifier des vulnérabilités unitairement, il reste complexe d’établir avec ces outils des scénarios d’attaque combinant successivement plusieurs vulnérabilités.
Perspectives d’évolutions du DevSecOps
Si les perspectives d’évolution sont nombreuses, une troisième typologie d’outil témoigne de l’impact que pourrait avoir l’intelligence artificielle au sein de la sécurité applicative. Il s’agit des RASP – Runtime application self-protection, qui constituent une petite révolution en matière de sécurité applicative. Surveillant en temps réel les usages des utilisateurs, l’objectif de ces solutions est de détecter et bloquer les attaques en tirant parti des informations provenant du logiciel en cours d’exécution via 2 méthodes :
- Un diagnostic environnemental pour collecter les attaques et évènements afin d’enrichir les bases de données antivirales et ainsi permettre aux entreprises d’avoir une connaissance pointue de leur environnement de menaces.
- Une protection des usages applicatifs en interceptant a priori les instructions qui pourraient compromettre le comportement applicatif défini comme standard.
Ces solutions demeurent chères à mettre en œuvre et génèrent des faux-positifs. Elles s’adressent donc à de grande entreprise mais n’en demeurent pas moins un terrain de jeux passionnant dans lequel l’éthique et la surveillance des comportements utilisateurs est au centre des attentions.
Conclusion
Loin d’une image figée et sclérosante pour les utilisateurs, la sécurité applicative est un environnement en perpétuelle mutation. Elle se décline au travers de son versant méthodologique, le Secure Software Development Lifecycle, mise en œuvre par un outillage riche et varié structuré autour du DevSecOps. Ce domaine en plein essor voit les solutions se spécialiser pour répondre à un contexte technologique toujours plus pointu. L’enjeu est de garantir la confiance des utilisateurs dans leurs usages des solutions.
“La confiance n’exclut pas le contrôle.”
Lénine