Dans le premier article de notre série consacrée à ATA nous avons évoqué les fonctions globales du produit, dans la deuxième partie nous avons parcouru toutes les étapes nécessaires à l’installation du produit, maintenant explorons les différents paramétrages et quelques fonctions de cette solution.
Paramétrage de Microsoft ATA
Tableau de bord et menu rapide vers les fonctions principales
| Vous pouvez lancer la console web de gestion de Microsoft ATA en utilisant l’icône sur le bureau : |  |
La console web se lance sur la page principale de la solution ATA qui est une espèce de tableau de bord des différentes alertes :
Les trois petits points verticaux en haut en droite de la page permettent d’accéder au menu rapide avec les raccourcis vers les différentes fonctions d’ATA :
|
|
Configuration globale – La page de « Configuration »
| Pour accéder à la page de configuration globale, utiliser le menu rapide qui est en haut à droite de la page principale : |  |
System / Center
Cette page permet de visualiser ou d’ajouter des URLs permettant d’accéder à la page web ATA pour un administrateur :
System / Gateways
Cette page permet de visualiser les différentes Gateway sur le réseau (= les agents) installées sur les contrôleurs de domaine Active Directory (mode Light Gateway) ou les Gateway classiques ATA – Cette page permet aussi de récupérer le package d’installation d’une Gateway :
System / Updates
Cette page permet d’activer ou désactiver les updates de package pour les Gateway déployées. Imaginons que nous réalisions une mise à jour du package central ATA, avec une mise à disposition d’une nouvelle version de package pour les Gateway, il serait possible d’activer une mise à jour automatique sur les Gateway actuellement déployées :
En production, je ne suis pas certain que le paramètre d’auto-update soit une excellente idée…
Data Sources / Directory Services
Cette page permet de paramétrer le domaine Active Directory qui fournira des informations à ATA ainsi que le compte de service de connexion (si vous ne savez pas ce qu’est un Single label domain, consultez cette page : https://support.microsoft.com/en-us/help/2269810/microsoft-support-for-single-label-domains)
Data Sources / SIEM
Cette page permet d’utiliser une source de données provenant d’un SIEM pour obtenir les évènements depuis les contrôleurs de domaine, de manière indirecte. Si vous pouvez déployer des passerelle Light sur les contrôleurs de domaine, il n’y a à mon avis pas grand intérêt à récupérer en plus des logs provenant d’un SIEM. Par contre, cette fonction est très utile si :
- Vous avez déjà un SIEM en place
- Le SIEM actuellement en place réalise la collecte des évènements de vos contrôleurs de domaine (quel que soit le mode, agent, Event Forwarding, etc.)
- Votre société interdit l’installation d’agent supplémentaire sur les contrôleurs de domaine
Les évènements du SIEM sont envoyés vers la passerelle ATA via Syslog, la passerelle ATA agissant comme serveur Syslog dans ce cas. Si vous voulez en savoir plus sur cette partie, veuillez consulter cette URL : https://docs.microsoft.com/fr-fr/advanced-threat-analytics/install-ata-step6
En fonction des retours que j’aurais sur ce post, il est possible que je réalise un autre post sur ce blog dans quelques semaines qui documentera l’usage de SPLUNK + ATA.
Data Sources / VPN
Non, votre serveur ATA n’est pas un serveur VPN ! Néanmoins il permet d’agréger les informations provenant d’une passerelle VPN afin d’améliorer la corrélation des différents évènements. L’idée est ici d’alimenter ATA avec les informations de connexions VPN entrantes pour les nomade (VPN PC à site). Pour ce, il faut paramétrer votre passerelle VPN pour envoyer des évènements via le protocole RADIUS à une de vos passerelles ATA.
| Il est à noter que dans ce cas, votre centre ATA doit pouvoir accéder à Internet et plus particulièrement à ti.ata.azure.com avec HTTPS (port 443) pour définir les adresses IP externes utilisées. Dans ce cas vous pourrez collectez des données de ce type :Si vous désirez en savoir plus sur cette fonction, merci de consulter cette URL : https://docs.microsoft.com/fr-fr/advanced-threat-analytics/vpn-integration-install-step |
 |
Detection / General
Cette page vous permet de paramétrer des « Honeytoken accounts » – personnellement j’adore cette fonction !
Le principe est ici de créer un compte dans votre annuaire Active Directory afin « d’attirer » des personnes réalisant une attaque vers ces comptes, qu’il s’agisse d’un mouvement latéral ou d’une tentative d’élévation de privilèges (mouvement en escalade). Le principe est de créer un ou plusieurs comptes Active Directory avec des noms évocateurs faisant croire à l’attaquant qu’il a intérêt à faire le focus dessus, si ces comptes sont utilisés ou si il y a des tentatives d’actions dessus, c’est qu’une attaque est en cours.
Si vous voulez en savoir plus sur ce type de comptes, je vous conseille la lecture de ce PDF : http://www.eurecom.fr/fr/publication/1275/download/ce-pougfa-030914b.pdf
Si vous désirez utiliser ces contremesures, je vous conseille d’essayer ce scripts PS permettant d’automatiser la création de ce type de comptes et bien plus : https://github.com/JavelinNetworks/HoneypotBuster
Detection / Exclusions
Quel que soit l’outil de détection, la réponse aux faux positifs est un problème récurrent, cette page vous permettra d’exclure des éléments par type d’attaque afin de ne pas réaliser du bruit sur vos détections d’attaque :
Notifications and Reports / Language
Cette page vous permet de choisir la langue pour les rapports et les notifications. A noter, le choix de cette langue n’affecte pas la langue de l’interface elle-même que nous avons évoqué plus haut :
Notifications and Reports / Notifications
Cette page vous permet de paramétrer deux éléments importants, les comptes ou DLs qui recevront éventuellement un email en cas d’activité suspecte et un serveur Syslog vers lequel envoyé les évènements suspects. A noter, ici ATA agit comme client Syslog, ceci n’a rien à voir avec le fait qu’une passerelle ATA reçoivent des événements au format Syslog pour les transmettre au centre ATA (dans le cas la passerelle ATA agit comme serveur Syslog)
A noter la configuration d’un serveur Syslog de destination nécessite le paramétrage préalable d’un serveur Syslog dans la partie « Syslog Server » que nous verrons plus loin dans Notifications and Reports / Syslog server – donc à ce stade la fonction est ici désactivée et n’est pas paramétrable :
Notifications and Reports / Scheduled reports
Cette page permet de paramétrer à qui doivent être envoyé les rapports d’activité :
A noter que l’usage de cette fonction nécessite d’avoir au préalable paramétrer un serveur de messagerie pour relayer les messages – paramétrage que nous avons dans la section suivante :
Notifications and Reports / Mail server
Cette page vous permet de paramétrer le serveur de messagerie de votre choix :
Notifications and Reports / Syslog server
Cette page vous permet donc de paramétrer un serveur Syslog vers lequel envoyé les éléments collectés par ATA. Si vous n’avez pas de serveur Syslog et que vous êtes sous Windows, je vous conseille Kiwi Server qui est ma référence en ce domaine depuis plus de 10 ans : https://www.solarwinds.com/free-tools/kiwi-free-syslog-server
Voilà ! notre troisième article sur Microsoft ATA est terminé – la prochaine fois nous allons explorer la base de données MongoDB qui se cache derrière ATA et nous réaliserons quelques attaques pour vérifier que notre installation ATA est bien capable de nous aider à combattre les envahisseurs !
