Hi there, want to know more about Microsoft Advanced Threat Analytics (ATA)? You’ve come to the right place. In this blog post I’d like to share some fundamentals of the product and platform to get you started right away.
Microsoft acquired Aorato in 2014 which was a security company. They are now part of Microsoft and responsible for the development of ATA. ATA is generally available since august 2015.
Microsoft ATA is part of the Enterprise Mobility Suite and basically is an on-premises platform that helps protect your enterprise from multiple types of advanced targeted cyber attacks and insider threats. Microsoft ATA detects multiple suspicious activities, focusing on several phases of the cyber-attack kill chain including reconnaissance, compromised credentials, lateral movement, privilege escalation and domain dominance.
You have to understand that ATA only detects attacks within the internal network. It’s not designed to detect attacks against external firewalls or through phishing, malware and exploits. For instance, it won’t detect a macro with a malicious payload that’s able to use an exploit in Excel. However it will detect the steps taken from the compromised client like mentioned in the previous paragraph. Back in November I’ve presented about ATA during Experts Live 2016. My session contained a demo which is now available as video, check it out.
Let’s move on. What are the key components of Microsoft Advanced Threat Analytics?
- ATA Center server
- ATA Console
- ATA Gateway
- ATA Lightweight Gateway
ATA Center server
Is the actual server that processes all information that’s being sent from the gateways. It’s also responsible for detection, profiling, machine learning and behavioral analysis. It stores all data in the dedicated MongoDB (yep, that’s right, no SQL or other DB type) which is also installed on the ATA Center server. Now keep in mind that it’s only possible to deploy this on-premise. It’s not supported (for now) to deploy the ATA Center server in Azure or any other 3rd party cloud provider.
On top of it, it’s serving the ATA Console, the nice web based management GUI. The console is hardcoded on port 443 (HTTPS), you can’t change this but you are able to change the Center service port (also default on 443). This port is required for communication with the gateways.
Notice: During the installation you have to specify a default domain user with read permissions within your Active Directory Forest. Please note that if you have set any special ACL’s on OU’s, give this account read permissions. Second, give it read persmission on the Deleted Objects container. ATA detects mass deletion from AD, nice.
At the time of writing, version 1.7 update 1 is the most recent release. You might have thought of it, but does ATA stretch beyond the Active Directory Forest? The answer is, nope. Cross-forest isn’t an option, but there are rumors (mentioned at Microsoft Ignite) that it might be added to the next version. This will enable you to deploy one ATA Center server for multiple Active Directory Forests instead of one ATA Center server per Forest!
ATA Gateway and Lightweight Gateway
The ATA Gateway and Lightweight Gateway are responsible parsing all network traffic from your domain controllers to the ATA Center server. If you compare at functional level, they are equal. The big difference is that you deploy the Gateway on a dedicated physical of virtual server and make use network port mirroring. The Lightweight Gateway is being deployed on the actual domain controller itself and runs as a service.
Port mirroring is something you have to think about, this can get quite complex to implement (affinity with hypervisor hosts if you have a virtual gateway server) but if you really have the requirement to be stealthy, it’s the way to go. Take a look at the table below to to see which gateway might suite you best.
|ATA Gateway||Out-of-band solution, difficult to detect by attacker. More secure.||Higher||Deployment next to domain controller (out-of-band) on dedicated server.||Support for maximum of 50.000 packets/sec|
|ATA Lightweight Gateway||No dedicated physical or virtual server required. No port mirroring.||Lower||Installed on domain controller||Support for maximum of 10.000 packets/sec|
The Lightweight Gateway will give you more flexibility and eases the deployment of ATA. Because it’s installed on a domain controller it contains a component that monitors the available system resources. The Gateway process can be quite demanding for resources so the fundamental idea is that it will never interfere with the core tasks of a domain controller.
If, for some reason, the usage of CPU, memory and disk is high, the Lightweight Gateway will partial drop packets and stop functioning if it exceeds the defined threshold.
Tweaking this threshold is beyond the scope of this blog post but you can read more about it here.
From the ATA Console you’d have to download your Gateway package. This .exe installer contains both types of gateways and will detect if it’s run on a dedicated server of domain controller, silent install options are supported.
Nice to know: one ATA Gateway can support multiple domain controllers.
ATA supports the following operating systems
|2008 R2 SP1||2012||2012 R2||2016|
|ATA Center / Console||•||•|
|ATA Lightweight Gateway||•||•||•||•|
Windows Server core is supported for all components but the Lightweight Gateway only on 2012 and higher, no 2008 R2.
This is a very important part when planning ATA in your environment. Luckily the Microsoft ATA team developed a sizing tool, which is available for download here. This tool will create a baseline of all domain controllers in your network. It will use Windows performance counters to measure the amount of network packets per second that passes your domain controllers. After a run (default 24 hours) the tool generates a csv file with the statistics.
Now, at this point you’d have to focus on the busy packets per second. The busy packets per second is the average of the busiest 15 minutes during the 24 hour run. This value is most important, please size according to the capacity planning baselines, documented here.
Domain Joined vs Workgroup
This is up to you. The ATA Center server and Gateway server can be domain joined or part of a workgroup. From a security perspective the workgroup option is more safe because detection of an ATA infrastructure is more difficult, there isn’t any information related to ATA stored in Active Directory. From a management view, the domain joined option is better. It’s integrated with AD so you’re able to manage the platform with AD accounts and even fully use the available RBAC groups.
Any more important things to know about ATA? Well, here some extra stuff to be aware of.
- Certificates are required. Default you get self signed, issued from PKI is supported.
- Cert specs: bitlength 2048, Cryptographic Service Provider (CSP)
- Product updates from Windows Update client, WSUS / SCCM supported.
- Gateways are updated from ATA Center server.
- MongoDB is only locally accessible from ATA Center server, not from network.
- Active Directory Forest is boundary (at least for version 1.7)
- SCOM management pack is in development.
- Deploy this product in production straight away, lab or test environments do not add any value (no user activity)
Microsoft Advanced Threat Analytics is a powerful platform to detect attacks in the early stages of the attack kill chain. If you already have implemented other security products like Alienvault or Splunk, compare those products against ATA, it could close the gap in addition to the other products to get full detection coverage.