Introduction

Un vaste sujet que Agile, Architecture logicielle et AppSec, il semble évident que je vais beaucoup plus m'intéresser à la partie AppSec, ou du moins étudier ce problème d'un point de vue AppSec. Ce problème ? Oui car il y a un problème, souvent lorsque l'on fonctionne d'un point de vue Agile l'architecture logicielle, en tant qu'expertise, voire un art, est quelque peu, voir beaucoup délaissée. Hors sans une bonne architecture (sécurisée) logicielle on part déjà sur un mauvais pied pour l'AppSec derrière.

Par ou commencer donc ?

Pour cet article j'ai décidé de revoir les concepts d'architecture logicielle, d'agile, de voir comment ils s'intègrent l'un à l'autre (et ce qui ne s'intègre pas), de voir comment l'AppSec et l'architecture logicielle s'intègre puis de faire une synthèse.

Post-Intro - Excuses

J'ai écris cet article en plusieurs fois, et le plan à beaucoup changer, donc il est possible que je me sois répété et que parfois le "plan" ne soit pas clair. En tout cas si vous avez des questions: normalement les commentaires sont ouverts :).

Mais bon ça faisait tellement longtemps que je n'avais pas posté que j'ai décidé de poster celui-ci (et en plus je viens de renouveler le nom de domaine donc ;)).

Architecture logicielle

Oui car l'architecture logicielle c'est quoi au final ?

En soit, un logiciel sert à répondre à un besoin business, ou à un besoin. En soit l'architecture logicielle c'est le moyen de refléter ces besoins en choses un peu plus concrète.

Pour cela il est nécessaire de modéliser quelques petites choses comme:

  • Les structures du système
  • Ses éléments (du système)
  • Les relations entre ces éléments

Et l'architecture permet aussi de définir et de contrôler quelques attribus comme:

  • La déployabilité
  • L'éfficacité énergétique (et c'est aussi important que la sécurité !)
  • L'intégrabilité
  • Les possibilités de modifications
  • La performance
  • La facilité d'utilisation
  • La testabilité
  • La sureté
  • Et bien sûr la sécurité et donc:
    • Disponibilité
    • Intégrité
    • Confidentialité

Architecture et sécurité

Pour être clair: j'adore que l'achitecture logicielle soit bien documentée, car la sécurité y est intégrée. Et surtout cela permet de prendre des décisions d'architecture et de design aux premières étapes de la création d'un logiciel. Et ça c'est vraiment top pour nous (a.k.a les gens qui font de la sécurité logicielle). De même, vous mettez en production des logiciels sans analyse des risques ? J'espère que non. Hors lorsque l'architecture est bien documentée faire une analyse des risques est bien plus simple, efficace et cela peut-être fait dans les premières étapes du développement.

De même, du coté architecture il y a aussi normalement des contrôles à mettre en oeuvre. On peut notamment parler de ATAM Architecture Tradeoff Analysis Method, normalement durant ces contrôles vous revoyez les attributs dont: la sécurité.


Source

Donc en soit, comme dans l'IT, dans le domaine logiciel l'architecture et son contrôle sont des points essentiels pour assurer la sécurité d'un système (enfin d'une application quoi). 

Quel est le problème ?

En soit le problème est souvent que dans un mode de dévelopement agile l'architecture logicielle est comment dire: délaissée. Du moins dans le meilleur des cas on a un schéma sur un tableau, dans le pire: même pas.

Du coup un gros risque de sécurité ici: pour rappel: le #4 du fameux OWASP TOP 10 est: Insecure Design !

Dont la description est:

A new category for 2021 focuses on risks related to design and architectural flaws, with a call for more use of threat modeling, secure design patterns, and reference architectures. As a community we need to move beyond "shift-left" in the coding space to pre-code activities that are critical for the principles of Secure by Design.

Donc délaisser l'architecture est une grande erreur. Car une architecture et le design qui en découle, mal conçue et pensée, ou même voir pas du tout penser, d'un point de vue sécurité c'est très difficile à corriger !

Oui patcher un componsant tiers, ou corriger un XSS ce n'est pas si dur dans la plus part des cas. Si vous devez revoir toutes les communications et les technologies utilisées par plusieurs composants de votre application: bon courage !

Agile et architecture logicielle

Mais rien n'est perdu, avec quelques mesures il est possible de réintégrer de l'architecture, et donc de la sécurité (by design ?) dans votre SDLC.

  • La formation: toujours ! Il faut apprendre, à minima les basiques de l'AppSec et de l'architecture à vos équipes de développement
  • Intégration: security champions, experts sécurité et architectes doivent être intégrés aux équipes de dévelopements et avoir une vue sur des délivrables à venir
  • Iteration 0: cette approche lors de l'iteration 0 d'un projet vous allez vous concentrer sur l'architecture et tout ce qui y est attaché, dont bien sûr la sécurité. Et par la suite à chaque cycle de développement vous mettez à jour et contrôler (bon ça vaudra jamais le Big Design Up Front mais bon)
  • Quality Gates: incluez la mise à jour et le contrôle de la sécurité à chaque Quality Gates: si vous n'avez pas de Quality Gates: bah mettez les en place :).

Architecture logicielle et AppSec

En plus des points contrôle sécurité prévue dans les bonnes pratiques d'architectures logicielles, les équipes AppSec doivent aussi contrôler l'architecture sur les points suivants (je parle ici pour des applications Web/Cloud/SaaS):

  • S-SDLC: contrôler régulièrement sur les bonnes pratiques de sécurité ont été suivis (lors des quality gates), participer à la revue de l'architecture
  • Authentification/Autorisation: Vérifier que l'architecture de l'application et de ces divers composants respecte bien les bonnes pratiques dans le domaine: tout est authentifié, centralisé, à jour, que des logs soient générés et envoyés à un SIEM, vérifier que l'application se repose sur un mécanisme de gestion des autorisation unique et revue (contrôlé), contrôler les poliques de gestion des accès, ...
  • Input/Ouput: vérifier que l'architecture prévoit les points de contrôle et le type d'inputs/outputs acceptés
  • Chiffrement: vérifier ce qui est prévue pour le chiffrement at rest et le chiffrement des communications, l'architecture des éventuelles PKI, ...
  • API: vérifier que les APIs respectent, ou vont respecter des standards connues et documenter
  • Build et conf: contrôler les configurations prévues, les guides de durcissements, si des AV/EDR sont prévues, les contrôles prévues dans le pipelines CI/CD, etc ...
  • Et bien d'autres points:
    • Communications
    • Logs et management des erreurs
    • Protection de la vie privée

Attention à la mode "shift-left"

Souvent on pense que le shift-left améliore la sécurité des applications et c'est vrai, mais attention à sa définition ! En effet, mettre des outils dans les pipelines de dévelopement pour détecter les vulnérabilités au plus tôt c'est très bien, mais cela donne un faux sentiment de sécurité. Ceci pour plusieurs points:

  • Cela ne doit pas empêcher les contrôles en fin de chaine (attention des bug bounties ce n'est pas le top non plus j'y reviendrais peut-être un jour: mais c'est aussi un outil parmis d'autres à utiliser)
  • Il faut vraiment faire du shift-left: pour éviter le insecure design, donc du shift-left sans ce que j'ai décris précédement: vous allez avoir des problèmes !

Oui malheureusement, les outils ne règlent pas tout, même une IA dont tout le monde parle (qui invente des fonctions qui n'existent pas quand elle ne trouve pas celle qui correspond à la demande, qui invente des explications sur des réglementations aussi quand elle ne les connaît pas), comme pour la sécurité IT ça fait des années que les vendeurs disent que leurs outils vont régler tous les problèmes (j'ai été ingénieur pour un intégrateur donc je connais le discours :)), hors ce n'est jamais le cas. Oui il faudra toujours de l'humain, et pour la revue d'architecture, pour le moment les outils bah ... Mais encore faut-il qu'il y ait une architecture ! Notez que c'est pareil pour les pentests, même si les DASTs et autres outils s'améliorent pour le moment ça ne vaut jamais un pentesteur expérimenté.

Du coup, s'il vous plaît: forcer vos équipes à penser archi, à documenter, à contrôler sinon vous allez avoir des problèmes !

Comment on fait du coup ?

Il faut savoir une chose, l'architecture et l'AppSec ne modifient pas que les systèmes mais aussi les organisations. Vous devez donc penser votre organisation pour refléter les besoins en architecture et en sécurité.

Si on veut une vue simpliste cela pourrait être ceci:

Ensuite commencez par définir les besoins de vos systèmes, notamment en terme de sécurité, voyez si ceci est reflété dans vos documents d'architecture. Vous n'en avez pas: faites un projet pour documenter vos applications: ça va sans doute être long je vous préviens.

Une fois fait: l'analyse de risques: sur vos applications mais aussi les pipelines CI/CD bien sûr.

Quel framework d'analyse des risques: il y en a beaucoup, en France on a même le notre, mais si vos clients internationaux vous demande cela ils risquent de ne pas comprendre. Mieux vaut se baser sur des choses comme le NIST 800-30.

En gros ce que vous devez identifier (je laisse en anglais):

  • Threat actor
  • Likelihood of initiation
  • Threat event
  • Likelihood of exploitation
  • Vulnerability
  • Predisposing Conditions with pervasiveness
  • Security Controls with effectiveness
  • Impacts

Et pour cela il vous faudra des experts cybersécurité/AppSec.

Une fois cela fait vous aurez déjà un meilleure vue des mesures que vous avez à mettre en oeuvre.

Par la suite pour chaque cycle, vous devez reproduire ce process en mode plus light bien sûr: du style un petite analyse par délivrable pour voir s'il y a des besoins de securité pour ce dernier et si oui documenter les menaces et probables vulnérabilités. Et bien sûr prévoir les mesures encore !

Pour cela quelques exercices de threat modeling peuvent être intéressants.

Double documentation et double revue ?

Effectivement, avec ce que j'ai décris l'on peut penser que le travail de l'architecture et de l'AppSec se recoupe, et du coup cela créé des doubles contrôles/doubles documentation/doubles revues: et ceci est vrai.

Néanmoins il est ceci n'est pas une mauvaise chose. Le truc c'est de ne surtout pas surcharger les équipes de développments avec des questionnaires, des meetings et des audits !

Il faut mutualiser ! C'est assez simple à comprendre: lorsque l'AppSec fait un assessment quelconque: invitez l'architecture. Lorsque l'architecture revoit la sécurité dans le cadre d'assessment ATAM par exemple: invitez l'AppSec. Oui car il n'y a rien de pire pour les équipes de développement que de répéter des tâches/meetings/réponses sur des sujets identiques mais à des équipes différentes: Vous pouvez perdre l'adhérance de vos équipes à la sécu ou à l'archi si vous faîtes cette erreur !

La double documentation: ce n'est pas un soucis, ce permet d'apporter plusieurs points de vue sur un risque. Effectivement si l'équipe architecture pense qu'un risque est réduit même voir traité, mais que ce n'est pas le cas pour l'équipe AppSec cela peut créer des discussions salutaires !

Mais du coup pour les équipes architecture: comment documenter un risque sécu ?

Plusieurs choix:

  • Reprendre la "nomenclature" AppSec
  • Faire un lien faire la documentation AppSec
  • Documenter la sécurité (du moins les risques) comme un "quality attribute": Source/Stimulus/Artifact/Environment/Response/Response Measures ....

Quality attribut - sécurité

Une façon propre de documenter la sécurité d'un point de vue architecture logicielle c'est d'utiliser les bonnes pratiques du SEI. Pour résumer il s'agit de quelque chose de très proche de ce que j'ai expliqué lors du chapitre sur l'analyse des risques. La représentation est la suivante:

Source: Software Architecture in Practice (4th Edition)

 

User story & Evil User story

Une très bonne pratique à mettre en oeuvre est aussi la création d'Evil User Story. En soit lorsque vous créez une User story avec une nouvelle fonctionnalité pour vos utilisateurs, faites une petites Evil user story pour décrire ce qu'un utilisateur malveillant pour tenter sur cette feature. C'est une excercice assez intéressant, qui sensibilise les développeurs et qui peut être assez fun à faire en plus.

D'un point de vue pratique cela ressemble à une analyse de risques, vous devez décrire les threat actors possibles, ce qu'ils peuvent tenter et vos possibles vulnérabilités.

Source: OWASP Brazil 2009

Pour résumer

  1. Formation
  2. Security by design
  3. Iteration 0 avec une architecture évolutive
  4. Evil user story
  5. Quality gates et Threat modeling
  6. DevSecOps (il faudra que je fasse un la dessus et sur le SRE aussi :)) et Management des risques

En soit pour un intégration de l'AppSec + architecture il faudrait:

Pour chaque itération (à part la 0):

  1. Sélection des stories à traiter et revue des besoins de sécurité
  2. Actualisation et revue de l'architecture (ATAM-based)
  3. Evil user story et threat modeling
  4. Implementation (avec contrôle par SAST/DAST/...)
  5. Revue du status de traitement des risques et des vulnérabilités (Quality Gate)
  6. Petit dernier coup de DAST, pentest si besoin, ...
  7. Mise en prod
  8. Bug bounty

Petite checklist avant mise en production

Si on se concentre juste sur l'archi logicielle bien sûr

  • L'architecture est documentée et à jour
  • L'architecture a été revue par l'AppSec
  • Les architectes et l'AppSec sont d'accords sur les risques
  • Tous les risques ont été traités

Conclusion

Oui, l'architecture pour beaucoup d'équipes de dévelopment ce n'est pas "cool", ça fait pas "hype". De même que le management des risques pour l'AppSec. Bah oui, du texte, des desseins, des diagrammes, des structures ... pas top: on préfère faire un beau code ou réussir une exploitation c'est beaucoup mieux !

Mais c'est nécessaire: voir indispensable ! Bon pour votre blog wordpress non, mais si vous faites des applications plus importantes alors là oui ! Si vous ne passez pas par ces étapes vous allez avoir des soucis pour sûr !

Effectivement si vous faîtes, ou avez fait de la sécurité "IT", cela vous viendrez à l'idée d'être capable de dire que vous êtes capables d'evaluer les risques sans aucune archi réseaux, liste des systèmes et différents assets ? Bien sûr que non ! Dans le domaine logicielle c'est la même chose ! Il est IMPOSSIBLE d'atteindre un niveau de sécurité descend sans aucune architecture logicielle documentée !

Lectures

La suite sur le blog

J'hésite: soit encore un post sur la crypto, soit une analyse de vulnérabilité récente (PHP ou OpenSSL sont mes cibles préférées), soit un article sur le Web3 Bullshit et quels outils utilisés pour faire du décentralisé et chiffré.

Dites moi si vous avez une préférence.

Legal

Voilà, ce texte est bien sûr en licence CC BY-SA 4.0 (legal)

Les images de type mémes ont été générées avec memegenerator.