[Cybersécurité] OpenSAMM, modèle de maturité pour le développement d’applications sécurisées

OpenSAMM (Software Assurance Maturity Model) est un des projets « Flagship » de l’OWASP (Open Web Application Security Project) permettant d’évaluer, définir et mettre en place une stratégie de sécurité pour les applications.

Le projet propose de découper le développement logiciel en 4 domaines divisés en 12 sous-domaines. On retrouve globalement les différentes étapes du SDLC.

Catégories OpenSAMM

 

Fonctionnement

Chaque sous domaine est divisé en 4 niveaux de maturité.

  • 0 : Niveau implicite de départ
  • 1 : Compréhension initiale et mise en place de pratiques de sécurité
  • 2 : Amélioration de l’efficacité/efficience des pratiques de sécurité
  • 3 : Maîtrise complète des pratiques de sécurité

Pour chaque sous-domaine, plusieurs éléments sont associés à chaque niveau de maturité :

Note : les exemples associés ci-dessous proviennent du niveau de maturité 1 du sous-domaine « Education and Guidance » du domaine « Governance ».

  • L’objectif à atteindre pour compléter le niveau de maturité
    exemple :
    – Fournir aux collaborateurs des ressources documentaires sur le développement et de déploiement sécurisés d’applications
  • Les activités à mener pour atteindre l’objectif
    exemple :
    – Faire une formation de sensibilisation à la sécurité
    – Ecrire et maintenir des guides techniques
  • Les questions à se poser pour évaluer la stratégie de sécurité en place
    exemple : 
    – Les développeurs ont-ils reçu une sensibilisation à la sécurité ?
    – Les membres des équipes projet savent-elles où chercher les guides et bonnes pratiques de développement sécurisé ?
  • Résultats attendus après avoir satisfait les objectifs
    exemple : 
    – Prise de conscience des développeurs sur les problèmes de développement les plus communs
    – Application des règles de sécurité de base sur les logiciels
    – Définition d’un niveau de connaissance minimum en sécurité pour les collaborateurs techniques
    – Mise en place de contrôles de ce niveau minimum de sécurité
  • Les métriques à mesurer et leurs seuils d’acceptation
    exemple :
    – Plus de 50% des développeurs a été sensibilisé durant la dernière année
    – Plus de 75% des développeurs seniors/architectes a été sensibilisé durant la dernière année
    – Commencer le guide technique dans les 3 mois après la 1re formation
  • Les coûts associés
    exemple :
    – Coût de la formation (à construire ou via une prestation)
    – Maintenance du guide technique
  • Les acteurs impliqués
    exemple :
    – Développeurs
    Architectes
  • Les autres sous-domaines liés avec les niveaux associés
    exemple :
    – Policy & Compliance niveau 2
    – Security Requierement niveau 1
    – Secure Architecture niveau 1

 

Comment mettre en place OpenSAMM ?

Pour mettre en place OpenSAMM il faut suivre les différentes étapes proposées :

Etapes OpenSAMM

  • 1 – Prepare – Préparer
    objectif : s’assurer de bien démarrer le projet
    activités :
    – Définir le périmètre
    – Identifier les collaborateurs
    – Communiquer sur l’initiative
  • 2 – Assess – Evaluer
    objectif : identifier et comprendre le niveau de maturité actuel
    activités :
    – Evaluer les pratiques déjà en place
    – Déterminer le niveau de maturité actuel
  • 3 – Set the target – Définir la cible souhaitée
    objectif : définir le niveau cible dans chaque sous-domaine
    activités :
    – Définir la cible souhaitée
    – Estimer les impacts
  • 4 – Define the plan – Définir le plan
    objectif : définir le plan pour arriver à l’objectif souhaité
    activités :
    – Définir le nombre de phases pour atteindre l’objectif
    – Définir le planning
  • 5 – Implement – Mettre en place
    objectif : réaliser le plan défini
    activités :
    – Mettre en place les mesures nécessaires
  • 6 – Roll-out – Mettre à disposition
    objectif : S’assurer que ce qui a été mis en place est utilisé
    activités :
    – Communiquer sur les améliorations
    – Mesurer l’efficacit

 

Calcul du niveau de maturité d’une organisation

Le niveau de maturité se définit par sous-domaine (« Education & Guidance » par exemple). Il est calculé en fonction d’un barème lié aux réponses aux questions de chaque niveau de maturité.

L’exemple ci-dessous expose le nombre de points à ajouter pour chaque réponse.

Barèmes OpenSAMM

Pour le sous-domaine « Education & Guidance », un exemple de réponses serait  :

  • Have developers been given high-level security awareness training?
    réponse : Once => 0,2 point
  • Does each project team understand where to find secure development best-practices and guidance?
    réponse : Half=> 0,5 point
  • Are those involved in the development process given role-specific security training and guidance?
    réponse : No => 0 point
  • Are stakeholders able to pull in security coaches for use on projects?
    réponse : Some => 0,2 point
  • Is security-related guidance centrally controlled and consistently distributed throughout the organization?
    réponse : Per Team => 0,2 point
  • Are developers tested to ensure a baseline skillset for secure development practices?
    réponse : No => 0 point

Dans ce cas le score est de 1,1, ce qui se traduit par un niveau de maturité 1+.

Aide à la mise en place

Pour aider à la mise en place d’OpenSAMM, l’OWASP met à disposition un fichier Excel permettant de :

  • Evaluer le niveau de maturité par sous-domaine en répondant aux questions. En fonction des réponses, le score par sous-domaine est automatiquement calculé.

Evaluation Excel OpenSAMM

  • Proposer en fonction des réponses données ci-dessus une roadmap pour améliorer les scores. Cette roadmap est composée de 4 phases et propose dans chaque itération d’améliorer un ou plusieurs point. L’évolution du score par phase est indiqué.

Roadmap Excel OpenSAMM

  • Proposer des statistiques sur la situation actuelle et la situation cible.

Statistiques Excel OpenSAMM

Ainsi que des graphiques sur l’avancement proposé par la roadmap

Statistiques Roadmap Excel OpenSAMM

 

Ressources

[Cybersécurité] Secure Software Development Life Cycle (SSDLC)

Le cycle de de vie du développement d’un application est l’ensemble des étapes de réalisation d’un logiciel dans le but de construire un produit de qualité.

L’intégration de la sécurité dans le SDLC intervient à chaque étape de celui-ci et se matérialise de plusieurs manières (threat modeling, review, SAST, DAST, etc.).

Ci-dessous, une liste non-exhaustive d’actions à mener au sein du SDLC pour délivrer une application sécurisée.

Ressources

[Cybersécurité] Surveiller vos dépendances avec Dependency Check de l’OWASP

Selon le Gartner, dans une application, 80% du code est fourni par des dépendances (spring, ORM, parsing de XML/JSON, etc.). Sur 95% des applications qui contiennent des dépendances opensource, 65% contiennent des dépendances vulnérables.

Malheureusement, lorsqu’une dépendance est installée pour un besoin spécifique, le suivi est rarement fait pour se tenir à jour des nouvelles versions et encore moins des vulnérabilités qui pouvant l’affecter.

Dependency Check

L’OWASP propose un outil nommé Dependency Check permettant de lister et vérifier automatiquement pour toutes les dépendances d’une application si une CVE (Common Vulnerabilities and Exposures) a été publiée pour la version utilisée. La base de données utilisée par Dependency Check est le NVD Data Feeds proposée par le NIST.

Dependency Check est actuellement mature pour Java, .NET et expérimental pour Ruby, Node.js, Python et C/C++. Il est disponible sur la forme d’un plugin Maven, un plugin Gradle, une tâche Ant, un plugin Jenkins ou un executable en ligne de commande. Il existe également un plugin Sonarqube permettant d’intégrer directement les résultats dans les « issues » et les « measures ».

Glossaire

  • CVE (Common Vulnerabilities and Exposures) : Dictionnaire public maintenu par le MITRE et permettant d’identifier des vulnérabilités sur des composants logiciel

Exemple :

CVE-2017-9787 – When using a Spring AOP functionality to secure Struts actions it is possible to perform a DoS attack when user was properly authenticated. Solution is to upgrade to Apache Struts version 2.5.12 or 2.3.33.

  • CWE (Common Weakness Enumeration) : Classe de vulnérabilités

Exemple : SQL Injection

  • CPE Confidence : Indice de confiance sur la reconnaissance d’une dépendance et de sa version
  • Evidence : Preuve permettant de déterminer le nom et la version d’une dépendance

Exécution via Jenkins

En intégrant le plugin Jenkins (mode job et pipleline disponibles), Dependency Check peut être exécuté à chaque fois qu’une build est déclenchée.

Les résultats sont ensuite mis à disposition via un lien sur la page « status » de la build :

L’intégration peut être directement faite dans Sonarqube via un plugin :

Les métriques sont disponibles dans l’onglet « Measures » de chaque projet. Suite aux changements intervenus sur Sonarqube 6.x, le détail des vulnérabilités ne peut pas être consulté directement en cliquant sur les liens proposés mais doit être accédé depuis l’onglet « Issues ».

Les métriques Dependency Check peuvent également être intégrées dans le calcul des « quality gates ».

Ligne de commande

Pour télécharger l’exécutable, rendez-vous ici.

Pour lancer une analyse sur une application java, utilisez la commande suivante :

$ ./bin/dependency-check.sh --project Testing --out . --scan [path to jar files to be scanned]

Le résultat est un fichier HTML. Exemple : dependency-check-report

On retrouve une vue un peu plus détaillée que dans les rapports Jenkins ou Sonarqube avec notamment la notion de « confiance » dans l’analyse d’une dépendance.

Pour déterminer qu’un projet utilise ou non une dépendance dans une version donnée, Dependency Check va analyser certains éléments de l’application (pom.xml, Manifest, nom des jars, etc.) et récolter des preuves (evidence) permettant de dresser une liste des dépendances avec leurs versions.

Le nombre de preuves (Evidence Count) est donc mentionné dans les rapports ainsi qu’un indice de confiance dans l’identification de la dépendance et de sa version.

Conclusion

La mise en place d’un outil comme Dependency Check dans une plateforme d’intégration continue permet d’être alertée sans effort sur la présence de vulnérabilités liées à des dépendances au sein d’un application. N’oubliez pas qu’environ 80% du code de votre application n’a pas été écrit par vous.

Ressources

[Cybersécurité] Scanner les vulnérabilités d’un site web avec Arachni

Arachni est un scanneur de vulnérabilités web écrit en Ruby (cross-plateforme) par Tasos Laskos et permettant d’automatiser la détection d’un grand nombre de failles (XSS, SQL Injection, Local File Injection, Remote File Injection, etc.). Il est disponible sous la forme d’une interface web, une application console et une API REST.

Types de scans

Arachni permet de faire des scans actifs ou passifs.

Scans actifs

Ils testent la présence de failles sur les pages web visitées, par exemple :

  • Envoie de code malicieux dans les formulaires pour tester les injections SQL ou XSS
  • Injection de chemins vers des fichiers locaux dans les URLs (/etc/passwd par exemple)

Scan passifs

Ils sont non intrusifs et ne laissent pas de traces dans les bases de données des application testées. Ils se décomposent en 3 types de détection :

  • Vérification de configuration (utilisation de HSTS, présence du flag HTTP_ONLY sur les cookies, etc.)
  • Récupération d’informations (méthodes HTTP autorisées, dossiers communs, listing de répertoires, etc.)
  • Présence d’informations sensibles (présence d’adresses IP, de numéros de sécurité sociales américains, emails dans les pages HTML)

Configuration

La configuration d’Arachni fonctionne avec des « checks » et des profils.

Checks

Les checks correspondent aux actions qui seront effectuées par Arachni. Ils sont divisés en 2 catégories : Actif et Passif

Actifs

  • Code injection
  • Code injection (php://input wrapper)
  • Code injection (timing)
  • CSRF
  • File Inclusion
  • LDAPInjection
  • NoSQL Injection
  • Blind NoSQL Injection (differential analysis)
  • OS command injection
  • OS command injection (timing)
  • Path Traversal
  • Response Splitting
  • Remote File Inclusion
  • Session fixation
  • Source code disclosure
  • SQL Injection
  • Blind SQL Injection (differential analysis)
  • Blind SQL injection (timing attack)
  • Trainer
  • Unvalidated redirect
  • Unvalidated DOM redirect
  • XPath Injection
  • XSS
  • DOM XSS
  • DOM XSS in script context
  • XSS in HTML element event attribute
  • XSS in path
  • XSS in script context
  • XSS in HTML tag
  • XML External Entity

Plus d’informations sur Github

Passifs

  • Allowed methods
  • Backdoors
  • Backup directories
  • Backup files
  • CAPTCHA
  • Common administration interfaces
  • Common directories
  • Common files
  • Cookie set for parent domain
  • Credit card number disclosure
  • CVS/SVN users
  • Directory listing
  • E-mail address
  • Form-based File Upload
  • HTTP Strict Transport Security
  • .htaccess LIMIT misconfiguration
  • HTML objects
  • HttpOnly cookies
  • HTTP PUT
  • Insecure client-access policy
  • Insecure cookies
  • Insecure CORS policy
  • Insecure cross-domain policy (allow-access-from)
  • Insecure cross-domain policy (allow-http-request-headers-from)
  • Interesting responses
  • localstart.asp
  • Mixed Resource
  • Origin Spoof Access Restriction Bypass
  • Password field with auto-complete
  • Private IP address finder
  • SSN
  • Unencrypted password forms
  • WebDAV
  • Missing X-Frame-Options header
  • XST

Plus d’informations sur Github

Profils

Les profiles rassemblent ensuite un ou plusieurs « checks » au sein de la configuration d’un scan. Parmi les autres options disponibles, on retrouve par exemple :

  • Exclure des paths
  • Configuration de l’audit du site web
  • Configuration du fingerprinting pour ne jouer que les payloads correspondants aux applications ou technologies utilisées sur le site web audité (gain de performance)
  • Gestion des plugins
  • Gestion des paramètres HTTP (proxy, nombre de requêtes, etc.)

Lors du lancement d’un scan, il suffit ensuite de renseigner l’URL a auditée et le profil choisi.

Interfaces web

L’interface web est complète en permettant les actions suivantes :

  • Configuration des comptes utilisateurs
  • Gestion des profiles
  • Gestion des agents permettant de déporter la charge sur d’autres machines
  • Planification des scans
  • Lancement et consultation des scans

Lancement d’un scan

start_scan

A noter qu’il est possible de déporter la charge du scan sur une ou plusieurs autres machines en fonction des agents configurés (dispatchers).

 

Liste des vulnérabilités détectées

 

liste_vulnerabilites

Les vulnérabilités sont regroupées en fonction de leurs sévérités et de leurs types.

 

Détails d’une vulnérabilité

details_vulnerabilite_1details_vulnerabilite_2

Dans chaque détail, il y a la requête HTTP envoyée ainsi que la réponse reçue avec une mise en évidence de la faille détectée (ici du XSS).

Mon avis

J’ai testé initialement Arachni pour effectuer une recherche automatisée de failles XSS sur une application volontairement vulnérable. Après avoir tester ZAP et xsser, Arachni semble être l’outil qui a détecté les failles que j’attendais. Attention toutefois à correctement configurer les profiles pour ne sélectionner que les éléments pertinents. Sans une configuration spécifique, le scan pourra durer plusieurs heures pour un site très simple. Les rapports sont complets et permettent l’identification et la correction rapide des problèmes.

Sources

Notes

Attention, les tests automatisés ne remplacent pas les tests manuels

[Cybersécurité] Principe et implémentation de HSTS (HTTP Strict Transport Security)

HTTPS est devenu quasiment obligatoire sur tous les sites web et particulièrement sur ceux contenant des formulaires. Même si ce n’est pour le moment qu’une indication non bloquante, Firefox émet une erreur lors de la visite d’une page non sécurisée contenant des formulaires (en savoir plus).

Warning Firefox formulaire HTTP

Pour rappel, la mise en place du protocole HTTPS est maintenant facilitée par l’initiative Let’s Encrypt.

Problématique

Traditionnellement, sur un site web implémentant HTTPS, un utilisateur qui souhaite accéder à la version HTTP est redirigé via une HTTP 301 sur la version HTTPS :

Redirection HTTP vers HTTPS avec HTTP 301

 

Par exemple sur LinkedIn :

Redirection HTTP vers HTTPS Linkedin

Ce scenario sera répété à chaque fois que l’utilisateur tente d’accéder au site web en utilisant le protocole HTTP.

Le problème avec ce mécanisme de redirection c’est que la première requête sur http://monsite.com est transmise en clair sur le réseau. On imagine qu’elle peut contenir des cookies sans le flag « secure », des données de formulaires, etc. Toutes ces données peuvent être interceptées par une attaque de type « Man in the middle ».

Pour éviter cet aller/retour, il faut indiquer au navigateur que le site souhaité doit être accédé en HTTPS et qu’il doit donc remplacer le HTTP par le HTTPS.

Implémentation

Pour avertir le navigateur que le site doit être utilisé en HTTPS, il faut rajouter le header « Strict-Transport-Security » dans les réponses HTTP renvoyées par le site web.

hsts_header

Ce header dispose de plusieurs paramètres :

  • max-age (obligatoire) : durée pendant laquelle le navigateur va accéder au site web uniquement en HTTPS. La valeur conseillée étant généralement de 1an (31536000s).
  • includeSubDomains (facultatif) : permet d’appliquer HSTS aux sous-domaines
  • preload (facultatif) : permet d’être ajouté à la liste de preloading

Le scenario est donc maintenant le suivant :

Scenario HSTS

Grâce à ce mécanisme, seul le premier accès au site web contient un aller/retour en HTTP. Tout le reste se fait en HTTPS. Afin d’éliminer ce dernier échange non sécurisé, nous allons utiliser le preloading.

Les navigateurs Chrome, Firefox, IE et Edge intègre une liste de sites web implémentant HSTS. Ils savent donc que ces sites web doivent être accédés uniquement en HTTPS. Pour s’inscrire sur cette liste, il faut se rendre sur la page mise à disposition par l’équipe Chromium : https://hstspreload.appspot.com.

Certains pré-requis doivent être satisfaits pour être éligible :

  • Avoir un certificat valide
  • Rediriger le HTTP vers le HTTPS (comme décrit ci-dessus)
  • Tous les sous-domaines doivent être en HTTPS
  • le sous-domaine www doit exister
  • Avoir le header HSTS (comme décrit ci-dessus) avec les paramètres « includeSubDomains » et « preload ».

Une fois inscrit, il faut attendre la mise à jour de chaque navigateur. Une fois chargé dans les différents navigateurs, le scenario est le suivant :

HSTS avec preload

Compatibilité

HSTS est supporté par les derniers navigateurs (http://caniuse.com/#feat=stricttransportsecurity):

Compatibilité HSTS

Sur les navigateurs ne supportant par HSTS, le header est simplement ignoré.

Vérification

Pour vérifier que le site web dispose d’un header HSTS valide et qu’il est bien préloadé dans les différents navigateurs, il est possible d’utiliser des outils en ligne comme https://www.ssllabs.com.

Vérification HSTS

Liens utiles