Contrôler les élévations de privilèges irrégulières
| Contrôler les élévations de privilèges irrégulières | |
|---|---|
| Statut | Développé |
| Catégorie : Cas d'usage | |
Description du use case[modifier | modifier le wikicode]
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[modifier | modifier le wikicode]
Il existe 2 grandes situations dans lesquelles des élévations de privilèges irrégulières pourraient être détectées : 1. Une personne malveillante s’approprie un compte à privilèges (ou un compte qu’il ne possède pas) ; 2. 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[modifier | modifier le wikicode]
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[modifier | modifier le wikicode]
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 1. L'extraction dans Active Directory (AD) des codes d'événement 4648/4624. 2. Un modèle est basé sur l'analyse des comptes de service (pour les applications et non les utilisateurs humains). 3. 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 : 1. Le High sensitive : S(day, connect) est constant, l’utilisateur qui ne change pas son comportement dans une fenêtre mobile de 60 jours. 2. 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) 3. Low Sensitive : très grande variation avec de grandes amplitudes au-dessus de 200 4. 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 : 1. Isolation Forest pour les faibles sensibilités 2. 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 1. Nous ne pouvons pas utiliser les données actuelles ni les données anonymes car elles appartiennent aux clients.
5. 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. 6. Besoin en temps de calcul Très faible 7. Cloud ou On Premise On premise pour les données propriétaire, cloud pour les données publiques. 8. Autres logiciels nécessaires Cryptographie (les données récoltées ne doivent pas transiter en clair). 9. 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 10. Mitre Defend User Behavior Analysis (Job Function Access Pattern Analysis, Resource Access Pattern Analysis) Execution isolation (Mandatory Access Control) 11. Cyber Kill Chain N/A
