Fermer

août 31, 2021

Analyse de surface d'attaque logicielle – Perficient Blogs


Tous les systèmes logiciels existent dans un état non sécurisé, ce qui crée le besoin d'un moyen d'effectuer une analyse de la surface d'attaque logicielle. En effet, tout système utile doit se connecter d'une manière ou d'une autre avec le monde extérieur et contient donc au moins un point d'interaction avec ce monde. Ces voies de communication acceptent les données/instructions dans le système et rapportent les résultats du traitement. Les systèmes logiciels modernes basés sur le Web, par opposition aux anciens systèmes client-serveur, sont généralement directement connectés à l'Internet au sens large. Ces points de connexion sont nécessaires pour que le système apporte de la valeur à ses parties prenantes, mais représentent également des opportunités pour les attaquants de suborner le système. pour identifier rapidement les actifs du système logiciel, évaluer divers points d'attaque vulnérabilités définir les contrôles contre ces risques et rapporter les preuves d'atténuation des attaques .


Figure 1. Exemple de modèle de surface d'attaque

Modèle de modèle de surface d'attaque 2

Comme le montre la figure 1, un Modèle de surface d'attaque est une technique permettant d'évaluer et d'évaluer les vulnérabilités d'un système qui sont potentiellement exposés et disponibles pour l'exploitation. Le but de cet exercice est d'identifier les actifs organisationnels qui ont une valeur pour un attaquant et de les associer aux risques appropriés. Le modèle se concentre sur les points d'accès externes, ou « surface », du système cible, car ce sont les points les plus susceptibles qu'un acteur externe/interne cible pour l'accès. Par exemple, un site Web hébergé sur un réseau d'entreprise peut être vulnérable à une variété d'exploits externes tels que le déni de service, les scripts intersites, l'exfiltration de données non autorisée et l'exécution de code malveillant, pour n'en nommer que quelques-uns. Pour atténuer ces vulnérabilités exposées, une série de contrôles sont établis pour éliminer la vulnérabilité ou réduire le potentiel d'exploitation. Des exemples de contrôles pour les « fuites de données » (c'est-à-dire l'exfiltration de données non autorisées) incluent le cryptage, la suppression des informations confidentielles/exclusives inutiles ou l'anonymisation des données.

Identification des actifs

Les actifs d'une organisation sont représentés par tout système, données , ou un artefact qui a de la valeur. Par exemple, un système de ressources humaines d'entreprise contient des données hautement sensibles et/ou privées concernant la rémunération, les attributions de bonus, les attributions d'actions, etc. L'exposition, la perte ou la corruption de ce système aura un impact commercial élevé, et peut-être juridique. L'identification et la caractérisation des actifs dépassent le cadre de cet article, mais pour plus d'informations, veuillez vous référer à la norme ISO 270001/2. Aux fins de la modélisation de la surface d'attaque, il suffit d'identifier tous les composants d'un système logiciel qui sont potentiellement exposés à l'exploitation.

Tableau 1. Exemple de description des actifs du système logiciel

AssetDescriptionValeur DéclarationProfil de menace
Plateforme AEMEnvironnements de développement et de test Adobe Experience Manager hébergés par AWS.Les environnements inférieurs sont essentiels aux efforts de développement ; la perte ou la corruption de celles-ci entraînera un temps/effort supplémentaire pour récupérer les fonctionnalités.Ces plates-formes sont hébergées sur le cloud AWS, ce qui implique le modèle de sécurité partagé. L'organisation est responsable des machines virtuelles, de la configuration du réseau et de la gestion des accès (c'est-à-dire pas de la sécurité physique du centre de données). En tant qu'environnement de développement inférieur, cela constitue une cible d'attaque modérée.
Adobe SharePointCe magasin de données est utilisé comme référentiel principal pour le déploiement de contenu AEMLe contenu du site Web est versionné et maintenu dans ces systèmes pour une utilisation dans des applications Web destinées au public. En tant qu'informations accessibles au public, cela représente une cible d'attaque importante . La perte ou la corruption peut affecter la réputation de l'organisation, la confiance des clients ou limiter le comportement fonctionnel du système

 

Comprendre les attaquants

Il existe de nombreuses motivations possibles derrière un attaquant du système logiciel. Un « extorqueur » peut simplement rechercher une récompense monétaire pour éviter de causer des dommages aux systèmes cibles ou à la réputation. Un « vandale » en revanche peut être intéressé à causer le plus de dégâts possible. Comprendre les types d'attaquants susceptibles de cibler un système particulier permet de mieux comprendre les moyens et les mécanismes utilisés par ces acteurs et, à son tour, d'identifier les vulnérabilités du système.

Tableau 2. Description des attaquants et des motivations

19659009]Acteur DescriptionObjectifMotivationExtortionnisteCet acteur recherche des opportunités d'insérer un ransomware ou d'autres moyens non destructifs de forcer l'organisation à payer pour retour des données et/ou capacité du système. En règle générale, l'attaque n'expose pas les données privées, mais empêche plutôt l'accès approuvé.Forcer l'organisation cible à payer une rançon pour le retour des données/accès au système.L'argent et la fierté sont des motivations clés.VandalCet acteur cherche à causer autant de perturbations et de destructions de biens que possible. Ils souhaitent perturber l'organisation en bloquant l'accès, en corrompant les données, en insérant de fausses données ou en cooptant d'une autre manière les systèmes de production.Perturbation des activités commerciales, dégradation de la réputation de l'organisation, exposition à des conséquences juridiques / gouvernementales.La fierté, l'activisme ou la vengeance sont des motivations clés.VoleurCet acteur se concentre sur l'accès et l'acquisition de données précieuses. En règle générale, ils accéderont à des systèmes secrètement (parfois pendant des années) collectant des données privées sur les clients, les clients et toute autre cible d'intérêt. Acquisition de données privées à vendre, interruption des activités, espionnage, vol d'identité ou autres moyens de production profiter du vol de données.L'argent est la principale motivation.

Découverte des risques/vulnérabilités

Les systèmes logiciels, et en particulier les applications Web, sont vulnérables à diverses attaques. Des acteurs malveillants recherchent ces points d'attaque afin de découvrir des vulnérabilités qui peuvent être exploitées pour compromettre le système. Le tableau 3 présente une courte collection de ces points d'attaque regroupés sous une catégorie générale de risques. Il existe de nombreuses ressources disponibles pour identifier et détailler les risques potentiels, comme le Open Web Application Security Project®la base de données open source National Vulnerability Databasela HITRUST Alliance et le Center for Internet Security. En catégorisant les vulnérabilités potentielles et en éliminant rapidement celles qui ne sont pas pertinentes pour l'enquête en cours, l'espace d'analyse peut être rapidement défini. Par exemple, une application Web hébergée par un fournisseur de cloud n'a pas besoin de prendre en compte la sécurité physique des serveurs (qui est la responsabilité partagée du fournisseur). Reportez-vous à la Figure 1 pour la hiérarchie des risques, des attaques, des vulnérabilités et des exploits.

Tableau 3. Exemple de risques – Attaques – Vulnérabilités

RiskAttackVulnerabilityConsequenceDescription[19659052]Fonctionnement du systèmeSurveillance insuffisanteDétection d'intrusionAccès système non autorisé inconnuLa journalisation et la surveillance sont le processus d'exécution et de stockage des journaux d'audit pour les connexions afin de détecter les actions non autorisées liées à la sécurité effectuées sur un framework ou application qui forme, transmet ou stocke des données sensibles. Cette vulnérabilité se produit lorsque l'événement de sécurité n'est pas correctement enregistré et/ou que le système n'est pas activement surveillé. Le manque de mise en œuvre de telles pratiques peut rendre les activités malveillantes plus difficiles à détecter, affectant le processus par lequel l'incident est traité. Bien que la journalisation et la surveillance soient universellement importantes pour tous les aspects de la sécurité des données, cette vulnérabilité devient particulièrement aiguë lorsque des acteurs malveillants disposant d'informations d'identification valides (tels que Trusted Insiders) sont autorisés à traverser un système et à exfiltrer des données sans être détectés en raison du manque de journaux d'accès complets.[19659057]Santé de la plate-formeDisponibilité réduite du système/comportement compromis
Autorisation non valideSession SpoofX-Site ScriptingSession utilisateur compromise

Souvent initiée par « sniffing » (la saisie de données réseau non cryptées via l'utilisation d'un contrôleur réseau en mode Monitor), la vulnérabilité Session Spoof est déclenchée lorsqu'un acteur spécialisé hautement qualifié obtient les identifiants (numéro de séquence TCP et accusé de réception TCP Numéro) de la session de service Web active d'un utilisateur. L'acteur peut ensuite utiliser les identifiants actuels pour créer un paquet de données falsifié qui peut être envoyé à partir de n'importe quelle connexion Internet pour tromper le service que la session de l'acteur est légitime, fournissant à l'acteur le contrôle d'accès des informations d'identification que l'utilisateur mettait en œuvre. L'usurpation de session est rarement utilisée par les acteurs modernes, car les fournisseurs d'OS ont développé des défenses contre ces attaques ; cependant, selon certaines estimations, ce chiffre atteint jusqu'à 35 % des systèmes Web modernes encore vulnérables à l'usurpation de session.

Usurpation d'identité d'en-têteSession utilisateur compromise
Réponse automatiséeSession utilisateur compromise

Définition des contrôles

Les contrôles sont définis comme des mécanismes techniques, procéduraux ou administratifs utilisés pour empêcher ou atténuer une ou plusieurs vulnérabilités (voir ISO 270001, Annexe A pour plus de détails sur les catégories de contrôle). Pour le modèle de surface d'attaque, les points clés sont le type de contrôle, la vulnérabilité spécifique ciblée, le mécanisme d'atténuation et les preuves d'atténuation qui en résultent. Des exemples de contrôles courants sont indiqués dans le tableau 4. Dans le cadre de l'approche d'analyse du modèle de surface d'attaque, une fois qu'un ensemble de vulnérabilités potentielles est identifié, l'étape suivante consiste à rechercher quels contrôles (le cas échéant) ont été appliqués. Comme le montre également le tableau 4, le mécanisme utilisé pour l'atténuation (et la preuve de son efficacité) est lié à la manière dont le contrôle est mis en œuvre. ]Mécanisme d'atténuation

Preuve d'atténuationÉtablir un processus de configuration sécurisé pour l'infrastructure réseauDisponibilité des ports publicsAutomatiser l'accès aux ports/restreindre la configuration du réseauRapport de disponibilité des ports réseauPare-feu WebApp/AWS CloudWatchIntrusion AwarenessSurveillance du trafic réseau pour les sources non valides et/ou les modèles de paquets
  • Rapport d'intrusion du pare-feu
  • Rapport de configuration du pare-feu
  • Rapport AWS CloudWatch
Alarme d'équilibrage de chargeSanté de la plate-formeÉvaluation du fonctionnement de la plate-forme via le contrôle de santé (c'est-à-dire ' demande).Rapport de disponibilité du système/plate-formeProcessus de correctif
  • Distribution de logiciels malveillants
  • Désactivation du moniteur de sécurité
  • Exploitation de composants
Assurer l'application en temps voulu de tous les correctifs de mise à niveau et de sécuritéRapport d'atténuation des vulnérabilitésSSH Secure Key AccessLog Data AccessGestion des accès secrets partagés pour les journaux de la plate-formeMise en œuvre de SSH sécurité de la plate-forme avec rotation périodique des clés

Utilisation du modèle de surface d'attaque pour l'enquête

La clé d'une enquête de sécurité efficace est de garantir une approche cohérente et approfondie. Le modèle présenté ici fournit des indications pour une telle approche, mais ne doit pas être considéré comme le seul moyen de mener une modélisation de la surface d'attaque. En fin de compte, il suffit d'une erreur de sécurité critique pour faire la une des journaux.

Limiter la portée du système pour se concentrer sur une zone à risque limité. Entreprendre une grande enquête initiale entraînera une confusion pour les équipes de développement. Il fournira également des opportunités pour les vulnérabilités manquées. Une bonne règle empirique consiste à garder chaque enquête centrée sur un seul domaine fonctionnel, tel qu'un site Web ou un ensemble de micro-services.

Travailler avec les zones à risque en tant qu'unité, car les contrôles sont souvent liés. En tirant parti des diverses similitudes de vulnérabilité, il est beaucoup plus facile d'identifier les contrôles appropriés. Par exemple, lorsque l'on considère les risques liés aux données, un contrôle courant sur une grande variété de vulnérabilités consiste à utiliser le cryptage. De même, les vulnérabilités de session utilisateur peuvent souvent être atténuées en utilisant un serveur Web correctement configuré qui tire parti de la gestion de session moderne.

Éliminez les vulnérabilités potentielles qui ne sont pas pertinentes. Pour la plupart des systèmes, tous les risques/vulnérabilités possibles ne sont pas présents. À titre d'exemple, la gestion de session n'est généralement pertinente que pour les systèmes Web ; un système de gestion de base de données n'aurait pas les mêmes risques. Limiter l'espace de vulnérabilité à un petit ensemble aide également à l'identification des contrôles pour la raison indiquée ci-dessus.

Notez les zones de conséquences potentielles à haut risque. Toutes les vulnérabilités ne sont pas égales en termes d'impact potentiel sur l'entreprise. Par conséquent, il est recommandé de classer les vulnérabilités identifiées en fonction de la valeur de l'actif impliqué et de la conséquence potentielle d'une attaque réussie. Notez toutes les vulnérabilités sans atténuation adéquate et classez-les par conséquence (c. Il ne suffit pas d'indiquer dans la documentation qu'un contrôle particulier est en place, il est également nécessaire de prouver que la vulnérabilité a été atténuée. Par exemple, si des serveurs proxy sont utilisés pour lutter contre les accès non autorisés au réseau, un test périodique doit être exécuté pour s'assurer que les configurations d'adresses réseau sont toujours en place et fonctionnent.

Conclusion

Il existe de nombreuses techniques pour effectuer évaluations des menaces pour la sécurité. L'approche du modèle de surface d'attaque s'est avérée efficace et complète lors de l'enquête sur les vulnérabilités et les contrôles du système. Comme l'illustre cet article, des efforts importants sont déployés en amont pour créer un cadre risque/vulnérabilité pour un ensemble donné d'actifs. Cependant, une fois construit, le même cadre peut ensuite être appliqué à une grande variété de systèmes logiciels/réseau. Par conséquent, cette approche est recommandée pour les systèmes de soutien aux entreprises critiques dans le cadre d'une approche d'évaluation de la sécurité complète.

À propos de l'auteur <!–:   blieberman, Director–>

Ben Lieberman est actuellement un directeur dans le groupe de livraison Perficient Inc., DevOps. Le Dr Lieberman a plus de vingt-cinq ans d'expérience dans le développement de logiciels et de systèmes dans un large éventail d'industries, notamment les finances, le gouvernement, les télécommunications, les sciences de la vie, les services de voyage et les systèmes de lancement spatial. Il possède une grande expérience sur plusieurs sujets de développement de logiciels, notamment l'analyse des exigences, l'analyse et la conception de systèmes, le développement de systèmes sécurisés, la gestion de la configuration et le déploiement automatisé (alias DevSecOps). Il possède également une expérience de développement direct dans plusieurs langages, notamment Java, C#, C++ et Salesforce (APEX), et travaille directement avec les équipes de développement sur les pratiques de livraison agile. Le Dr Lieberman est un écrivain professionnel accompli avec un livre (« L'art de la modélisation logicielle », Auerbach Publishing) et plus de trois douzaines d'articles informatiques professionnels à son actif. Le Dr Lieberman est titulaire d'un doctorat en biophysique et génétique de l'Université du Colorado, Anschutz Medical Center, Denver, Colorado.

En savoir plus sur cet auteur




Source link