La cybersécurité constitue de plus en plus un véritable challenge pour les organisations publiques et privées et aussi pour les particuliers. Le développement des cyberattaques et leur sophistication devient une préoccupation de premier ordre pour les décideurs et les utilisateurs à tous les niveaux.

Dans ce contexte de recrudescence des cyberattaques, l’environnement applicatif constitue une des cibles de choix pour les hackers. C’est pour apporter un éclairage sur cette problématique, et dans le prolongement des actions réalisées en 2021 que la DGSSI a organisé une journée de sensibilisation sur la sécurité applicative. Les mots d’ouverture de cette journée ont été prononcés par Mr Abdellah BOUTRIG et Mr Sidi Mohammed DRISSI MELYANI, respectivement Directeur de l’Assistance, la Formation, le Contrôle et l’Expertise à la DGSSI et Directeur Général de l’Agence de Développement du Digital. La DGSSI et l’ADD travaillent, en effet, en étroite collaboration pour développer la culture du développement sécurisé au Maroc.

Organisée dans un format hybride durant la matinée du 12 avril 2022, cette journée a connu la participation de plus de 480 personnes représentant l’ensemble des secteurs d’activité du public et du privé. Cette journée a été animée par des experts et des professionnels internationaux de haut niveau, disposants de plusieurs années d'expérience en particulier dans le domaine de la sécurité applicative.

Le programme de la journée qui a permis de mettre en exergue quelques bonnes pratiques de sécurité à adopter lors du développement d’un logiciel, s’est focalisé principalement sur le référentiel de vérification de la sécurité des applications, ainsi que sur les fondamentaux des tests logiciels.

En effet, le référentiel de vérification de la sécurité des applications, «OWASP, Application Security Verification Standard (ASVS)», fournit une base pour tester les contrôles techniques de sécurité des applications Web et fournit également aux développeurs une liste d'exigences pour un développement sécurisé. Il comprend un total de 286 contrôles et 14 rubriques de vérification, il adopte une approche par famille de fonctions et par niveau d'exigences. Selon le niveau de sécurité requis, ce référentiel propose trois niveaux de contrôle. Pour atteindre le niveau le plus avancé, il faut mener une analyse très approfondie de l'architecture, du code et des tests à tous les niveaux.

Pour les tests logiciels, il y’a lieu de noter que, Selon ANSI/IEEE 1059, le test logiciel est un processus d’évaluation d’un produit logiciel, pour déterminer si le produit répond aux conditions requises ou non. Le processus de test, consiste à évaluer les caractéristiques du produit logiciel, pour les contraintes en termes d’exigences manquantes, de bogues ou d’erreurs, de sécurité, de fiabilité et de performances.

En règle générale, les tests sont classés en trois catégories.

•  Tests fonctionnels ;
•  Tests non fonctionnels ou tests de performance ;
•  Maintenance (régression et maintenance).

Ainsi, la journée a été ponctuée par deux présentations relatives aux tests logiciels animées par les représentants des Comités, Marocain et Français des tests Logiciels et qui ont mis l’accent sur l’importance de ses tests en termes de :

•  Rentabilité : les bogues détectés dans les premières phases du cycle de développement sont moins chères à corriger ;
•  Sécurité : les risques sont connus et éliminés le plus tôt ;
•  Qualité du logiciel : le produit garantie la valeur promise en répondant aux exigences initiales pour obtenir les résultats finaux souhaités.

Les présentations ont également permis de mettre en exergue les fondamentaux des tests de sécurité, à travers la présentation du processus de certification ISTQB. A travers leurs missions complémentaires alliant la mise en œuvre de systèmes sécurisés et la sensibilisation autour du Digital et normes techniques relatifs aux produits et services numériques ; la DGSSI et l’ADD sont conscientes d’ores et déjà de cette problématique, et afin de renforcer davantage les dispositifs mis à disposition des administrations, des établissements publics ainsi que des infrastructures d’importance vitale publiques et privées, pour leur permettre de mener les tests recommandés durant le cycle de développement, ont adopté un référentiel de vérification de la sécurité des applications. Ce référentiel de vérification de la sécurité des applications qui a été brillement animé, par des experts de l’OWASP, intègre plusieurs normes de sécurité, dont les directives NIST 800-63-3 sur l’identité numérique, les recommandations NIST SP 800-57 relatives à la gestion des clés, le Top 10 2021 de l’OWASP, les contrôles proactifs 2018 de l’OWASP, les sections 6.5 de la norme PCI-DSS v3.2.1 ainsi qu’un mappage vers le CWE. Il se base principalement sur la version ASVS 4.0.3 publiée en octobre 2021 par la communauté OWASP et s’applique à tous les modèles de développement logiciel et vise à atteindre deux objectifs majeurs :

1. Aider les organismes à développer et à maintenir des applications sécurisées, (guide de tests unitaires et d'intégration automatisés, guide de formation au développement sécurisé) ;
2. Guider les parties prenantes dans le choix des meilleures offres en matière d'acquisition de logiciels sécurisés auprès des sociétés de développement. Le cadre d'exigences permettra en effet, de mettre à la disposition des parties prenantes, une solution basée sur les bonnes pratiques de développement sécurisé, et permettant de comparer les exigences exprimées avec les offres proposées par les soumissionnaires.

Le référentiel de vérification de la sécurité des applications, comporte trois niveaux de vérification de la sécurité. Le niveau trois représente le niveau d’assurance le plus élevé. Le niveau de vérification à adopter dépendra notamment :

•  De la nature de l’organisme (Infrastructures d'importance vitale, établissement public, banque, administration, etc. ) ;
•  Des exigences légales auxquelles l’organisme est soumis ;
•  De la conformité aux normes de sécurité.

Ces niveaux sont définis comme suit :

•  Niveau 1 : est un niveau d'assurance faible. Il comporte des tests d'intrusions classiques. Ce niveau constitue une première étape, pour sécuriser d’une manière progressive les applications d’une entité. Il est aussi parfois suffisant pour les applications qui ne stockent pas ou qui ne traitent pas de données sensibles, et partant ne nécessitent pas des contrôles rigoureux contenus dans les niveaux 2 ou 3. Les contrôles du niveau 1, peuvent être lancés automatiquement par des outils ou effectués manuellement, sans accès au code source.
•  Niveau 2 : est nécessaire pour les applications, qui contiennent des données sensibles et qui nécessitent une protection adaptée. Ce niveau constitue généralement le niveau recommandé pour la plupart des applications.
•  Niveau 3 : est le niveau le plus élevé et est destiné aux applications critiques, qui traitent des données hautement sensibles, ou qui requièrent un haut niveau de confiance.

En fonction de l’analyse du risque et des exigences métiers, chaque organisme doit déterminer le niveau d’exigence approprié. Dans le même sillage, la journée de sensibilisation a permis de présenter plusieurs solutions susceptibles d'apporter des améliorations, et des mécanismes à adopter, pour d’une part soutenir la mise en place du référentiel de vérification de la sécurité des applications, et d’autres part, faciliter l’automatisation du processus de développement. A ce titre, parmi les solutions présentées et qui pourraient apporter une valeur ajoutée en termes de mise en place des règles de sécurité au niveau d’un SDLC, on peut citer : le Framework SKF et l’API DefectDojo