Contrôler les élévations de privilèges irrégulières - Historique des versions

Juliette le 16 février 2023 à 10:18

2023-02-16T10:18:24Z

← Version précédente		Version du 16 février 2023 à 12:18
Ligne 1 :		Ligne 1 :
	{{Cas d'usage		{{Cas d'usage
	\|ShortDescription=Contrôler les élévations de privilèges, à la fois temporaires et permanentes, irrégulières		\|ShortDescription=Contrôler les élévations de privilèges, à la fois temporaires et permanentes, irrégulières
	\|Status=~~Développé~~		\|Status=Listé
	}}		}}
	== Description du use case ==		== Description du use case ==
Ligne 72 :		Ligne 72 :
	== Cyber Kill Chain ==		== Cyber Kill Chain ==
	N/A		N/A
			{{PageSubHeader Cas d'usage}}

FabienG le 25 novembre 2022 à 11:45

2022-11-25T11:45:24Z

← Version précédente		Version du 25 novembre 2022 à 13:45
Ligne 72 :		Ligne 72 :
	== Cyber Kill Chain ==		== Cyber Kill Chain ==
	N/A		N/A


	~~== Détails ==~~
	~~{{PageSubHeader Cas d'usage}}~~

Juliette le 9 novembre 2022 à 13:29

2022-11-09T13:29:14Z

← Version précédente		Version du 9 novembre 2022 à 15:29
Ligne 1 :		Ligne 1 :
	{{Cas d'usage		{{Cas d'usage
	\|~~Name~~=Contrôler les élévations de privilèges irrégulières		\|ShortDescription=Contrôler les élévations de privilèges, à la fois temporaires et permanentes, irrégulières
	\|Status=Développé		\|Status=Développé
	}}		}}
Ligne 75 :		Ligne 75 :

	== Détails ==		== Détails ==
			{{PageSubHeader Cas d'usage}}

194.206.236.81 le 15 juin 2022 à 08:02

2022-06-15T08:02:31Z

← Version précédente		Version du 15 juin 2022 à 10:02
Ligne 33 :		Ligne 33 :
	# 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.		# 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).		# Un modèle est basé sur l'analyse des comptes de service (pour les applications et non les utilisateurs humains).
Ligne 72 :		Ligne 72 :
	== Cyber Kill Chain ==		== Cyber Kill Chain ==
	N/A		N/A







	== Détails ==		== Détails ==

194.206.236.81 le 15 juin 2022 à 08:01

2022-06-15T08:01:12Z

194.206.236.81 le 15 juin 2022 à 07:57

2022-06-15T07:57:54Z

← Version précédente		Version du 15 juin 2022 à 09:57
Ligne 27 :		Ligne 27 :
	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…		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 :		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, …) ;		# 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) ;		# 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 ;		# Horaire des dernières actions effectuées inhabituel ;
	* 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

194.206.236.81 le 15 juin 2022 à 07:54

2022-06-15T07:54:33Z

← Version précédente		Version du 15 juin 2022 à 09:54
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) ;		1. 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.		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.		La première situation sera approfondie dans le cadre de ce Use Case, en se focalisant sur l’environnement Windows.

37.166.99.168 le 14 juin 2022 à 15:30

2022-06-14T15:30:37Z

37.166.99.168 le 14 juin 2022 à 15:28

2022-06-14T15:28:51Z

← Version précédente		Version du 14 juin 2022 à 17:28
Ligne 1 :		Ligne 1 :
	{{Cas d'usage		{{Cas d'usage
	\|Name=Contrôler les élévations de privilèges irrégulières		\|Name=Contrôler les élévations de privilèges irrégulières
	\|Status=~~Listé~~		\|Status=Développé
	}}		}}
	== Description du use case ==		== 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.		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.
	2. 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 :
	1. Une personne malveillante s’approprie un compte à privilèges (ou un compte qu’il ne possède pas) ;		* 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.		* 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.

	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).		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.		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).		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.		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.
	3. Statut
			== 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).		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).
	4. Donné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…		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 :		Grâces à ces informations, des indicateurs de compromission pourront apparaître :

37.166.99.168 : Page créée avec « {{Cas d'usage |Name=Contrôler les élévations de privilèges irrégulières |Status=Listé }} == 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 s... »

2022-06-14T15:22:18Z

Page créée avec « {{Cas d'usage |Name=Contrôler les élévations de privilèges irrégulières |Status=Listé }} == 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 s... »

Nouvelle page

{{Cas d'usage
|Name=Contrôler les élévations de privilèges irrégulières
|Status=Listé
}}
== 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.
2. Approche
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.
3. 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).
4. 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 :
1. Action malveillante ou inhabituelle menée sur le système (changements de paramètres, …) ;
2. Irrégularités géographiques (ex : la requête provient d’un pays où l’entreprise n’est pas implaentée) ;
3. Horaire des dernières actions effectuées inhabituel ;
4. Nombre important de tentatives de connexion infructueuses ;
5. 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

== Détails ==

← Version précédente		Version du 15 juin 2022 à 10:01
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 :
	1. Une personne malveillante s’approprie un compte à privilèges (ou un compte qu’il ne possède pas) ;		# 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.		# 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
	1. L'extraction dans Active Directory (AD) des codes d'événement 4648/4624.		# 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).		# 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.		# 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 :
	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.		# 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)		# 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		# 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.		# 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 :
	1. Isolation Forest pour les faibles sensibilités		# Isolation Forest pour les faibles sensibilités
	2. Détection IQR pour les moyennes et hautes sensibilités (simple quartile)		# 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 ===
	1. Nous ne pouvons pas utiliser les données actuelles ni les données anonymes car elles appartiennent aux clients.		# 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		== 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.
	6. Besoin en temps de calcul		== Besoin en temps de calcul ==
	Très faible		Très faible
	7. Cloud ou On Premise		== 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.
	8. Autres logiciels nécessaires		== 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).
	9. Mitre Att@ck		== 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
	~~10.~~ Mitre Defend		== 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)
	~~11.~~ Cyber Kill Chain		== Cyber Kill Chain ==
	N/A		N/A

← Version précédente		Version du 14 juin 2022 à 17:30
Ligne 6 :		Ligne 6 :

	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.		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 ==		== 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 :
Ligne 28 :		Ligne 27 :
	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…		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 :		Grâces à ces informations, des indicateurs de compromission pourront apparaître :
	1. Action malveillante ou inhabituelle menée sur le système (changements de paramètres, …) ;		* Action malveillante ou inhabituelle menée sur le système (changements de paramètres, …) ;
	2. Irrégularités géographiques (ex : la requête provient d’un pays où l’entreprise n’est pas implaentée) ;		* Irrégularités géographiques (ex : la requête provient d’un pays où l’entreprise n’est pas implaentée) ;
	3. Horaire des dernières actions effectuées inhabituel ;		* Horaire des dernières actions effectuées inhabituel ;
	4. Nombre important de tentatives de connexion infructueuses ;		* Nombre important de tentatives de connexion infructueuses ;
	5. 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