« Contrôler les élévations de privilèges irrégulières » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 8 : | Ligne 8 : | ||
== Approche == | == Approche == | ||
Il existe 2 grandes situations dans lesquelles des élévations de privilèges irrégulières pourraient être détectées : | 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. | La première situation sera approfondie dans le cadre de ce Use Case, en se focalisant sur l’environnement Windows. | ||
| Ligne 32 : | Ligne 32 : | ||
# Nombre important de tentatives de connexion infructueuses ; | # Nombre important de tentatives de connexion infructueuses ; | ||
# Activité réseau malveillante (avec adresse IP source et destination). | # Activité réseau malveillante (avec adresse IP source et destination). | ||
Implémentation | === Implémentation === | ||
La technique implémentée repose sur | 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 | === 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) | 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 : | 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 | === Modèles === | ||
Le modèle de détection est différent pour chaque catégorie : | 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 | === 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. | 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 | === 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é. | 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. | 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 | Très faible | ||
== Cloud ou On Premise == | |||
On premise pour les données propriétaire, cloud pour les données publiques. | 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). | 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 | T1068: Exploitation for Privilege escalation / T1069: Permission Groups Discovery | ||
T1222: File and Directory Permissions Modification / T1548: Abuse Elevation Control Mechanisms | T1222: File and Directory Permissions Modification / T1548: Abuse Elevation Control Mechanisms | ||
T1556: Modifiy Authentication process | T1556: Modifiy Authentication process | ||
== Mitre Defend == | |||
User Behavior Analysis (Job Function Access Pattern Analysis, Resource Access Pattern Analysis) Execution isolation (Mandatory Access Control) | User Behavior Analysis (Job Function Access Pattern Analysis, Resource Access Pattern Analysis) Execution isolation (Mandatory Access Control) | ||
== Cyber Kill Chain == | |||
N/A | N/A | ||
Version du 15 juin 2022 à 09:01
| 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 :
- 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[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[modifier | modifier le wikicode]
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[modifier | modifier le wikicode]
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[modifier | modifier le wikicode]
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[modifier | modifier le wikicode]
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[modifier | modifier le wikicode]
- 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[modifier | modifier le wikicode]
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[modifier | modifier le wikicode]
Très faible
Cloud ou On Premise[modifier | modifier le wikicode]
On premise pour les données propriétaire, cloud pour les données publiques.
Autres logiciels nécessaires[modifier | modifier le wikicode]
Cryptographie (les données récoltées ne doivent pas transiter en clair).
Mitre Att@ck[modifier | modifier le wikicode]
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[modifier | modifier le wikicode]
User Behavior Analysis (Job Function Access Pattern Analysis, Resource Access Pattern Analysis) Execution isolation (Mandatory Access Control)
Cyber Kill Chain[modifier | modifier le wikicode]
N/A
