Modifier Cas d'usage : Contrôler les élévations de privilèges irrégulières

Description free text : Enregistrez pour pouvoir passer à l'éditeur visuel.

== Description du use case == Contrôler les élévations de privilèges, à la fois temporaires et permanentes, irrégulières. Il faut donc définir les conditions dans lesquelles l’élévation de privilèges semble légitime, mais aussi identifier toute potentielle déviation. Pour commencer, le contrôle d’élévation de privilèges pourrait s’appliquer sur les comptes de services. En effet, les comptes de services ne sont censés être utilisés que par des applications, donc par conséquence le moindre accès depuis une IP différente peut décrire une situation inhabituelle. == Approche == Il existe 2 grandes situations dans lesquelles des élévations de privilèges irrégulières pourraient être détectées : # Une personne malveillante s’approprie un compte à privilèges (ou un compte qu’il ne possède pas) ; # Une personne malveillante crée un compte utilisateur standard et lui ajoute des privilèges. La première situation sera approfondie dans le cadre de ce Use Case, en se focalisant sur l’environnement Windows. L’objectif est de créer des profils d’usage relatifs aux administrateurs. Il s’agit donc de définir le comportement habituel d’un utilisateur de compte à privilèges et de mesurer les déviations par rapport à ce comportement (grâce à l’IA). Ces déviations peuvent être révélées par des indicateurs de compromission. Ces indicateurs de compromission doivent se baser sur des éléments représentatifs d’une menace, qui permettent ainsi de faciliter la détection d’événements similaires à l’avenir. Les indicateurs à prendre en compte doivent être définis, puis priorisés. Une collection de données centralisée puis une corrélation des événements permettront d’identifier de potentielles actions inhabituelles (tel un SIEM). Des alertes seront remontées à un tableau de bord (mis à jour en temps réel) qui proposera une vue d’ensemble sur les déviations par rapport aux profils d’usage. Des faux positifs sont à prévoir (car un administrateur peut en effet se connecter à un horaire inhabituel pour corriger un problème), mais l’algorithme se perfectionnera avec le temps - grâce à de l’apprentissage. == Statut == Ce modèle pourrait être exécuté dans la sandbox du Campus Cyber. Les données à utiliser ou proposer seront peut-être synthétiques (ou anonymisées). == Données == Une multitude de données pourraient être utilisées pour nourrir l’algorithme. Par exemple, les dernières actions effectuées par l’utilisateur, l’horaire et le lieu de l’action, les actions régulièrement effectuées, le rôle de l’employé, etc… Grâces à ces informations, des indicateurs de compromission pourront apparaître : # Action malveillante ou inhabituelle menée sur le système (changements de paramètres, …) ; # Irrégularités géographiques (ex : la requête provient d’un pays où l’entreprise n’est pas implaentée) ; # Horaire des dernières actions effectuées inhabituel ; # Nombre important de tentatives de connexion infructueuses ; # Activité réseau malveillante (avec adresse IP source et destination). === Implémentation === La technique implémentée repose sur : # L'extraction dans Active Directory (AD) des codes d'événement 4648/4624. # Un modèle est basé sur l'analyse des comptes de service (pour les applications et non les utilisateurs humains). # Des variables primaires extraites de cette seule source : le compte de service (user name)/ le journal des événements dans l'horodatage / Source IP / Destination Ip. === Calcul de variables/variables composites === La variable clé utilisée est le nombre d'événements : la somme de toutes les occurrences d'événements par type d'événement et par utilisateur, soit S(day, connect) Cette somme d'événements est ensuite divisée en 3 catégories : # Le High sensitive : S(day, connect) est constant, l’utilisateur qui ne change pas son comportement dans une fenêtre mobile de 60 jours. # Medium : S(day, connect) varie un peu de +/-1 à +/-200 dans la même fenêtre (disons qu'il a une moyenne de 10, il peut varier de 9 à 210) # Low Sensitive : très grande variation avec de grandes amplitudes au-dessus de 200 # Note : la valeur de seuil a été fixée expérimentalement à la vue de la distribution des valeurs. === Modèles === Le modèle de détection est différent pour chaque catégorie : # Isolation Forest pour les faibles sensibilités # Détection IQR pour les moyennes et hautes sensibilités (simple quartile) === Analyse === Le test est effectué sur les 7 jours après les 60 jours d'entraînement. La sortie attendue est la magnitude de la déficience : le delta entre la prévision du modèle (avec IQR semble difficile, à creuser) et la variation réelle. === Base de données === # Nous ne pouvons pas utiliser les données actuelles ni les données anonymes car elles appartiennent aux clients. == Catégories d'algorithmes utilisés == L’algorithme peut être basé sur de l’apprentissage supervisé (Régression Linéaire / Arbre de décision) ou non supervisé. Actuellement nous disposons d’une implémentation se basant sur la distribution (écart par rapport au quartile) et à une implémentation du Isolation Forest. == Besoin en temps de calcul == Très faible == Cloud ou On Premise == On premise pour les données propriétaire, cloud pour les données publiques. == Autres logiciels nécessaires == Cryptographie (les données récoltées ne doivent pas transiter en clair). == Mitre Att@ck == T1068: Exploitation for Privilege escalation / T1069: Permission Groups Discovery T1222: File and Directory Permissions Modification / T1548: Abuse Elevation Control Mechanisms T1556: Modifiy Authentication process == Mitre Defend == User Behavior Analysis (Job Function Access Pattern Analysis, Resource Access Pattern Analysis) Execution isolation (Mandatory Access Control) == Cyber Kill Chain == N/A

Catégories liées[modifier | modifier le wikicode]