Dans le cadre de leurs activités professionnelles, les développeurs, les pentesters et les professionnels de la sécurité doivent faire face à des processus tels que la gestion des vulnérabilités (VM), le SDLC (sécurisé).
Derrière ces expressions se cachent différents ensembles de pratiques et d’outils utilisés qui sont étroitement liés, même si leurs utilisateurs diffèrent.
Le progrès technologique n'a pas encore atteint le point où un outil peut remplacer une personne pour analyser la sécurité des infrastructures et des logiciels.
Il est intéressant de comprendre pourquoi il en est ainsi et à quels problèmes on doit faire face.
Processus
Le processus de gestion des vulnérabilités est conçu pour surveiller en permanence la sécurité de l'infrastructure et la gestion des correctifs.
Le processus Secure SDLC ("cycle de développement sécurisé") est conçu pour maintenir la sécurité des applications pendant le développement et l'exploitation.
Une partie similaire de ces processus est le processus d'évaluation de la vulnérabilité - évaluation de la vulnérabilité, analyse de la vulnérabilité.
La principale différence entre l'analyse dans VM et SDLC est que dans le premier cas, l'objectif est de trouver des vulnérabilités connues dans un logiciel tiers ou dans une configuration. Par exemple, une version obsolète de Windows ou la chaîne de communauté par défaut pour SNMP.
Dans le second cas, l'objectif est de détecter des vulnérabilités non seulement dans les composants tiers (dépendances), mais principalement dans le code du nouveau produit.
Cela donne lieu à des différences d'outils et d'approches. À mon avis, la tâche de trouver de nouvelles vulnérabilités dans une application est beaucoup plus intéressante, car cela ne se résume pas à l'empreinte digitale de version, à la collecte de bannières, à la force brute de mot de passe, etc.
Une analyse automatisée de haute qualité des vulnérabilités des applications nécessite des algorithmes qui tiennent compte de la sémantique de l'application, de son objectif et des menaces spécifiques.
Le scanner d'infrastructure peut souvent être remplacé par une minuterie, car le . Le fait est que, purement statistiquement, vous pouvez considérer votre infrastructure comme vulnérable si vous ne l'avez pas mise à jour pendant, disons, un mois.
Outils
L'analyse, ainsi que l'analyse de sécurité, peuvent être effectuées sous forme de boîte noire ou de boîte blanche.
Black Box
Avec l'analyse de la boîte noire, l'outil doit être capable de travailler avec le service via les mêmes interfaces via lesquelles les utilisateurs travaillent avec lui.
Les scanners d'infrastructure (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, etc.) recherchent les ports réseau ouverts, collectent des "bannières", identifient les versions logicielles installées et recherchent dans leur base de connaissances des informations sur les vulnérabilités de ces versions. Ils essaient également de détecter les erreurs de configuration telles que les mots de passe par défaut ou l'accès public aux données, les chiffrements SSL faibles, etc.
Les scanners d'applications Web (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, etc.) peuvent également détecter les composants connus et leurs versions (ex. CMS, frameworks, bibliothèques JS). Les principales étapes du crawl sont le crawl et le fuzzing.
Lors de l'analyse, l'analyseur collecte des informations sur les interfaces d'application existantes et les paramètres HTTP. Lors du fuzzing, des données mutées ou générées sont insérées dans tous les paramètres détectés afin de provoquer une erreur et détecter une vulnérabilité.
Ces scanners d'applications appartiennent respectivement aux classes DAST et IAST - Tests de sécurité des applications dynamiques et interactifs.
White Box
Avec la numérisation en boîte blanche, il y a plus de différences.
Dans le cadre du processus VM, les scanners (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, etc.) ont souvent accès aux systèmes en effectuant une analyse authentifiée. Ainsi, le scanner peut télécharger les versions de package installées et les paramètres de configuration directement à partir du système, sans les deviner à partir des bannières de service réseau.
Le scan est plus précis et complet.
Si nous parlons d'analyse en boîte blanche (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, etc.) d'applications, nous parlons généralement d'analyse de code statique et de l'utilisation des outils de classe SAST correspondants - Static Application Security Testing.
Problèmes
Il y a beaucoup de problèmes avec la numérisation ! Je suis amené à m'occuper personnellement de la plupart d'entre eux dans le cadre d'une prestation de service de scanning de bâtiment et de processus de développement sécurisé, ainsi que lors de travaux d'analyse de sécurité.
Je distinguerai 3 principaux groupes de problèmes, qui sont également confirmés par des conversations avec des ingénieurs et des responsables de services de sécurité de l'information dans diverses entreprises.
Problèmes d'analyse des applications Web
- Difficulté de mise en œuvre. Les scanners doivent être déployés, configurés, personnalisés pour chaque application, alloués à un environnement de test pour les scans et implémentés dans le processus CI/CD pour être efficaces. Sinon, ce sera une procédure formelle inutile, ne délivrant que des faux positifs
- Durée de l'analyse. Les scanners, même en 2019, font un mauvais travail de déduplication des interfaces et peuvent scanner un millier de pages avec 10 paramètres chacun pendant des jours, les considérant différents, bien que le même code en soit responsable. Dans le même temps, la décision de déployer en production dans le cadre du cycle de développement doit être prise rapidement.
- Mauvaises recommandations. Les scanners donnent des recommandations assez générales, et il n'est pas toujours possible pour un développeur de comprendre rapidement d'eux comment réduire le niveau de risque, et surtout, s'il faut le faire maintenant, ou si ce n'est pas encore effrayant
- Impact destructeur sur l'application. Les scanners peuvent facilement effectuer une attaque DoS sur une application, et ils peuvent également créer un grand nombre d'entités ou modifier celles qui existent (par exemple, créer des dizaines de milliers de commentaires sur un blog). produit.
- Faible qualité de détection des vulnérabilités. Les analyseurs utilisent généralement un tableau fixe de charges utiles et peuvent facilement passer à côté d'une vulnérabilité qui ne correspond pas au comportement connu de leur application.
- Le scanner ne comprend pas les fonctions de l'application. Les scanners eux-mêmes ne savent pas ce que sont « Internet banking », « paiement », « commentaire ». Pour eux, il n'y a que des liens et des paramètres, donc une énorme couche de vulnérabilités possibles de la logique métier reste complètement découverte ; ils ne penseront pas à faire une double annulation, à espionner les données de quelqu'un d'autre par identification ou à augmenter le solde en arrondissant.
- Incompréhension de la sémantique de la page par le scanner. Les scanners ne peuvent pas lire les FAQ, ne peuvent pas reconnaître les captchas, et d'eux-mêmes, ils ne comprendront pas comment s'inscrire puis se reconnecter, que vous ne pouvez pas cliquer sur « se déconnecter » et comment signer les demandes lors de la modification d'un paramètre. valeurs. Par conséquent, la majeure partie de l’application peut ne pas être analysée du tout.
Problèmes d'analyse du code source
- Faux positifs. L'analyse statique est une tâche complexe qui implique de nombreux compromis. Souvent, vous devez sacrifier la précision, et même les scanners d'entreprise coûteux génèrent un grand nombre de faux positifs.
- Difficulté de mise en œuvre. Pour augmenter la précision et l'exhaustivité de l'analyse statique, il est nécessaire d'affiner les règles d'analyse, et l'écriture de ces règles peut prendre trop de temps. Parfois, il est plus facile de trouver tous les endroits du code avec une sorte de bogue et de les corriger que d'écrire une règle pour détecter de tels cas.
- Absence de prise en charge de la dépendance. Les grands projets dépendent d'un grand nombre de bibliothèques et de frameworks qui étendent les capacités du langage de programmation. Si la base de connaissances du scanner ne contient pas d'informations sur les « puits » dans ces frameworks, cela deviendra un angle mort et le scanner ne comprendra tout simplement même pas le code.
- Durée de l'analyse. Trouver des vulnérabilités dans le code est également une tâche difficile en termes d'algorithmes. Par conséquent, le processus peut être retardé et nécessiter des ressources informatiques importantes.
- Faible couverture. Malgré la consommation de ressources et la durée de l'analyse, les développeurs d'outils SAST doivent toujours recourir à des compromis et analyser tous les états dans lesquels un programme peut se trouver.
- Recherche de reproductibilité. Pointer vers la ligne spécifique et la pile d'appels qui conduisent à une vulnérabilité est une bonne chose, mais en réalité, souvent, le scanner ne fournit pas suffisamment d'informations pour vérifier la présence d'une vulnérabilité de l'extérieur. Après tout, la faille peut également se trouver dans du code mort, inaccessible à un attaquant.
Problèmes d'analyse de l'infrastructure
- Inventaire insuffisant. Dans les grandes infrastructures, en particulier celles géographiquement séparées, il est souvent la chose la plus difficile de déterminer quels hôtes analyser. En d'autres termes, la tâche de numérisation est étroitement liée à la tâche de gestion des actifs.
- Mauvaise priorisation. Les scanners de réseau produisent souvent de nombreux résultats comportant des défauts qui ne peuvent pas être exploités en pratique, mais formellement, leur niveau de risque est élevé. Le consommateur reçoit un rapport difficile à interpréter et il ne sait pas clairement ce qui doit être corrigé en premier.
- Mauvaises recommandations. La base de connaissances du scanner ne contient souvent que des informations très générales sur la vulnérabilité et sur la manière de la corriger, les administrateurs devront donc s'armer de Google. La situation est légèrement meilleure avec les scanners whitebox, qui peuvent émettre une commande spécifique pour corriger
- À la main. Les infrastructures peuvent avoir de nombreux nœuds, ce qui signifie qu'il existe potentiellement de nombreuses failles, dont les rapports doivent être analysés et analysés manuellement à chaque itération
- Mauvaise couverture. La qualité de l'analyse de l'infrastructure dépend directement de la taille de la base de connaissances sur les vulnérabilités et les versions logicielles. Où, , même les leaders du marché n'ont pas une base de connaissances complète, et il y a beaucoup d'informations dans les bases de données de solutions gratuites que les leaders n'ont pas
- Problèmes de patch. Le plus souvent, la correction des vulnérabilités de l'infrastructure consiste à mettre à jour un package ou à modifier un fichier de configuration. Le gros problème ici est que le système, en particulier l'ancien, peut se comporter de manière imprévisible à la suite d'une mise à jour. En effet, vous devrez réaliser des tests d'intégration sur une infrastructure live en production.
Les approches
Comment est-ce possible?
J'aborderai plus en détail les exemples et la manière de traiter bon nombre de ces problèmes dans les parties suivantes, mais pour l'instant, je vais indiquer les principaux domaines dans lesquels vous pouvez travailler :
- Agrégation de divers outils de numérisation. Avec l'utilisation correcte de plusieurs scanners, vous pouvez obtenir une augmentation significative de la base de connaissances et de la qualité de la détection. Vous pouvez trouver encore plus de vulnérabilités que le total de tous les scanners lancés séparément, tout en évaluant plus précisément le niveau de risque et en faisant davantage de recommandations.
- Intégration SAST et DAST. Il est possible d'augmenter la couverture DAST et la précision SAST en partageant des informations entre elles. À partir de la source, vous pouvez obtenir des informations sur les itinéraires existants et, à l'aide de DAST, vous pouvez vérifier si la vulnérabilité est visible de l'extérieur.
- Apprentissage automatique™. En 2015, j'ai (et ) sur l'utilisation des statistiques pour donner aux scanners l'intuition d'un pirate et les accélérer. C'est certainement de la nourriture pour le développement d'analyses de sécurité automatisées à l'avenir.
- Intégration IAST avec autotests et OpenAPI. Dans le pipeline CI/CD, il est possible de créer un processus d'analyse basé sur des outils qui fonctionnent comme des proxies HTTP et des tests fonctionnels qui fonctionnent sur HTTP. Les tests et contrats OpenAPI/Swagger donneront au scanner les informations manquantes sur les flux de données, permettront de scanner l'application dans différents états
- Configuration correcte. Pour chaque application et infrastructure, vous devez créer un profil de numérisation adapté, en tenant compte du nombre et de la nature des interfaces, des technologies utilisées
- Personnalisation du scanneur. Souvent, une application ne peut pas être analysée sans modifier le scanner. Un exemple est une passerelle de paiement où chaque demande doit être signée. Sans écrire un connecteur au protocole de passerelle, les scanners picoreront sans réfléchir les requêtes avec une signature incorrecte. Il est également nécessaire d'écrire des scanners spécialisés pour un type spécifique de défauts, tels que
- Gestion des risques. L'utilisation de divers scanners et l'intégration avec des systèmes externes tels que la gestion des actifs et la gestion des menaces permettront d'utiliser plusieurs paramètres pour évaluer le niveau de risque, afin que la direction puisse obtenir une image adéquate de l'état de sécurité actuel du développement ou de l'infrastructure.
Restez à l'écoute et perturbons l'analyse des vulnérabilités !
Source: habr.com