Dans le cadre de leurs activités professionnelles, les développeurs, les pentesters et les professionnels de la sécurité doivent gérer des processus tels que Vulnerability Management (VM), (Secure) SDLC.
Sous ces phrases se cachent différents ensembles de pratiques et d'outils utilisés qui sont entrelacés, bien que leurs consommateurs soient différents.
Le progrès technique n'a pas encore atteint le point de remplacer une personne par un seul outil d'analyse de la sécurité des infrastructures et des logiciels.
Il est intéressant de comprendre pourquoi il en est ainsi et quels problèmes vous devez affronter.
Les processus
Le processus de gestion de la vulnérabilité est destiné à la surveillance continue de 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 prendre en charge la sécurité des applications pendant le développement et l'exploitation.
Une partie similaire de ces processus est le processus d'évaluation des vulnérabilités - évaluation des vulnérabilités, analyse des vulnérabilités.
La principale différence dans l'analyse au sein de VM et SDLC est que dans le premier cas, l'objectif est de détecter des vulnérabilités connues dans des logiciels 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 les vulnérabilités non seulement dans les composants tiers (dépendances), mais principalement dans le code du nouveau produit.
Il en résulte des différences d'outils et d'approches. À mon avis, la tâche de trouver de nouvelles vulnérabilités dans l'application est beaucoup plus intéressante, car elle ne se résume pas aux versions d'empreintes digitales, à la collecte de bannières, au tri des mots de passe, etc.
L'analyse automatisée de haute qualité des vulnérabilités des applications nécessite des algorithmes qui prennent en compte la sémantique de l'application, son objectif, les menaces spécifiques.
Le scanner d'infrastructure peut souvent être remplacé par une minuterie, comme l'a dit
avleonov . Le fait est que, purement statistiquement, vous pouvez considérer votre infrastructure comme vulnérable si vous ne l'avez pas mise à jour, disons, un mois.
Les outils
La numérisation, ainsi que l'analyse de sécurité, peuvent être effectuées sous forme de boîte noire ou de boîte blanche.
Boîte noire
Lors de la numérisation de la boîte noire, l'outil doit pouvoir travailler avec le service via les mêmes interfaces que celles utilisées par les utilisateurs.
Les scanners d'infrastructure (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, etc.) recherchent des ports réseau ouverts, collectent des «bannières», déterminent les versions logicielles installées et recherchent des informations sur les vulnérabilités de ces versions dans leur base de connaissances. Ils essaient également de détecter les erreurs de configuration, telles que les mots de passe par défaut ou l'accès ouvert aux données, les chiffrements SSL faibles, etc.
Les scanners d'applications Web (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, etc.) savent également déterminer les composants connus et leurs versions (par exemple, CMS, frameworks, bibliothèques JS). Les principales étapes du scanner sont l'exploration et le flou.
Pendant l'analyse, le scanner collecte des informations sur les interfaces d'application existantes, les paramètres HTTP. Lors du fuzzing, tous les paramètres détectés sont remplacés par des données mutées ou générées afin de provoquer une erreur et de détecter une vulnérabilité.
Ces scanners d'applications appartiennent respectivement aux classes DAST et IAST - Dynamic and Interactive Application Security Testing.
Boîte blanche
Les analyses de Whitebox ont plus de différences.
Tout au long du processus, les scanners VM (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 installées des packages et des paramètres de configuration directement depuis le système, sans les deviner sur les bannières des services réseau.
L'analyse est plus précise et complète.
Si nous parlons de l'analyse des boîtes blanches (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, etc.) des applications, alors nous parlons généralement de l'analyse de code statique et de l'utilisation des outils de classe SAST correspondants - Static Application Security Testing.
Les problèmes
La numérisation pose de nombreux problèmes! Je dois m'occuper personnellement de la plupart d'entre eux dans le cadre de la fourniture d'un service pour la création de processus de numérisation et de développement sécurisé, ainsi que pour la réalisation d'analyses de sécurité.
Je vais identifier 3 principaux groupes de problèmes, qui sont confirmés par des conversations avec des ingénieurs et des responsables des services de sécurité de l'information dans diverses entreprises.
Problèmes d'analyse des applications Web
- La complexité de la 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 mis en œuvre dans le processus CI / CD pour être efficaces. Sinon, ce sera une procédure formelle inutile, ne donnant que des faux positifs
- Durée de l'analyse. Les scanners, même en 2019, font mal avec la déduplication d'interface et peuvent scanner des milliers de pages pendant 10 jours avec 10 paramètres sur chacun, les considérant différents, bien que le même code en soit responsable. Dans le même temps, la décision de passer à la production dans le cycle de développement doit être prise rapidement
- Recommandations rares. Les scanners donnent des recommandations assez générales, et il n'est pas toujours possible pour un développeur de comprendre rapidement comment réduire le niveau de risque, et surtout, si cela doit être fait immédiatement ou ne pas avoir peur
- Effet destructeur sur l'application. Les scanners peuvent très bien effectuer une attaque DoS sur l'application, et ils peuvent également créer un grand nombre d'entités ou modifier celles existantes (par exemple, créer des dizaines de milliers de commentaires sur un blog), alors ne lancez pas inconsidérément une analyse dans le prod
- Détection de vulnérabilité de faible qualité. Les scanners utilisent généralement un tableau de charges utiles fixes et peuvent facilement ignorer une vulnérabilité qui ne correspond pas à leur scénario de comportement d'application connu.
- Le scanner ne comprend pas les fonctions de l'application. Les scanners eux-mêmes ne savent pas ce que sont les «services bancaires par Internet», le «paiement» et les «commentaires». Pour eux, il n'y a que des liens et des paramètres, de sorte qu'une énorme couche de vulnérabilités potentielles dans la logique métier reste complètement découverte, ils ne devineront pas à double-écrire, à regarder les données des autres par ID ou à liquider l'équilibre par l'arrondi
- Mauvaise compréhension de la sémantique des pages par le scanner. Les scanners ne savent pas lire la FAQ, ils ne savent pas reconnaître les captchas, par eux-mêmes, ils ne devineront pas comment s'enregistrer, puis doivent se connecter, que vous ne pouvez pas cliquer sur "déconnexion" et comment signer des demandes lors de la modification des valeurs des paramètres. Par conséquent, la plupart des applications peuvent ne pas être analysées du tout.
Problèmes d'analyse du code source
- Faux positifs. L'analyse statique est une tâche difficile à résoudre, qui nécessite de recourir à de nombreux compromis. Souvent, vous devez sacrifier la précision, et même les scanners d'entreprise coûteux produisent une énorme quantité de faux positifs
- La complexité de la 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 dans le code avec une sorte de bogue et de les corriger, que d'écrire une règle pour détecter de tels cas
- Manque de prise en charge des dépendances. Les grands projets dépendent d'un grand nombre de bibliothèques et de cadres 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 même pas le code
- Durée de l'analyse. Trouver des vulnérabilités dans le code est une tâche difficile en termes d'algorithmes. Par conséquent, le processus peut très bien être retardé et nécessiter des ressources informatiques importantes.
- Couverture faible. Malgré la consommation de ressources et la durée de l'analyse, les développeurs d'outils SAST doivent encore recourir à des compromis et analyser pas toutes les conditions dans lesquelles le programme peut être
- Reproductibilité des découvertes. Le fait de pointer vers une ligne et une pile d'appels spécifiques qui conduisent à une vulnérabilité est correct, mais en réalité, le scanner ne fournit souvent pas suffisamment d'informations pour rechercher une vulnérabilité externe. Après tout, une faille peut également être dans le code mort, ce qui est inaccessible pour un attaquant
Problèmes de numérisation d'infrastructure
- Inventaire inadéquat. Dans les grandes infrastructures, en particulier géographiquement séparées, il est souvent le plus difficile de comprendre quels hôtes doivent être analysés. En d'autres termes, la tâche d'analyse est étroitement liée à la tâche de gestion des actifs.
- Mauvaise priorisation. Les scanners de réseau produisent souvent de nombreux résultats avec des inconvénients qui ne sont pas exploitables dans la pratique, mais formellement, leur niveau de risque est élevé. Le consommateur reçoit un rapport difficile à interpréter, et ce qui doit être corrigé en premier n'est pas clair
- Recommandations rares. La base de connaissances du scanner ne contient souvent que des informations très générales sur la vulnérabilité et la façon de la corriger. Les administrateurs devront donc s'armer de Google. La situation est un peu meilleure avec les scanners whitebox qui peuvent émettre une commande spécifique pour corriger
- Travail manuel Les infrastructures peuvent avoir de nombreux nœuds, ce qui signifie qu'il existe potentiellement de nombreuses lacunes, dont les rapports doivent être démontés et analysés manuellement à chaque itération
- Mauvaise couverture. La qualité de l'analyse de l'infrastructure dépend directement du volume de la base de connaissances sur les vulnérabilités et les versions logicielles. Dans le même temps, il s'avère que même les leaders du marché ne disposent pas d'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 correction. Le correctif le plus courant pour les vulnérabilités de l'infrastructure est la mise à jour du package ou la modification du fichier de configuration. Le gros problème ici est que le système, en particulier hérité, peut se comporter de manière imprévisible à la suite d'une mise à niveau. En substance, vous devrez effectuer des tests d'intégration sur les infrastructures vivantes en production
Les approches
Comment être?
Je vais vous en dire plus sur les exemples et comment 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 d'analyse. Avec l'utilisation correcte de plusieurs scanners, une augmentation significative de la base de connaissances et de la qualité de la détection peut être obtenue. Vous pouvez trouver encore plus de vulnérabilités que dans l'ensemble tous les scanners lancés séparément, tandis qu'il est possible d'évaluer plus précisément le niveau de risque et de donner plus de recommandations
- Intégration de SAST et DAST. Vous pouvez augmenter la couverture DAST et la précision SAST en partageant des informations entre eux. De la source, vous pouvez obtenir des informations sur les itinéraires existants et en utilisant DAST, vous pouvez vérifier si la vulnérabilité est visible de l'extérieur
- Machine Learning ™ . En 2015, j'ai parlé (et pourtant ) de l'utilisation de statistiques pour donner aux pirates l'intuition des scanners et les accélérer. C'est certainement un aliment pour le développement de futures analyses de sécurité automatisées.
- Intégration d'IAST avec les autotests et OpenAPI. Dans le cadre du pipeline CI / CD, il est possible de créer un processus de scan basé sur des outils fonctionnant comme des proxy HTTP et des tests fonctionnels fonctionnant sur HTTP. Les tests et contrats OpenAPI / Swagger donneront au scanner les informations manquantes sur les flux de données et permettront de scanner l'application dans différents états
- Configuration correcte. Pour chaque application et infrastructure, vous devez créer un profil de scan adapté qui tient compte du nombre et de la nature des interfaces, des technologies utilisées
- Personnalisation des scanners. Souvent, une application ne peut pas être numérisée sans finaliser le scanner. Un exemple est une passerelle de paiement dans laquelle chaque demande doit être signée. Sans écrire un connecteur au protocole de passerelle, les scanners battront sans réfléchir les demandes avec la mauvaise signature. Il est également nécessaire d'écrire des scanners spécialisés pour un type spécifique de faille, comme la référence d'objet direct non sécurisé
- 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, vous permettront d'utiliser de nombreux 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!