- [Instructor] Our Microsoft Advanced Threat Analytics architecture will vary based on our site topology and our need for scale, which will drive some key decisions around how ATA captures event data. In higher-scale scenarios, ATA monitors our domain controller network traffic by utilizing port mirroring to an ATA Gateway using physical or virtual switches. Microsoft provides an ATA sizing tool to help you make the right role selection based on the event volume in your environment.
If we deploy the ATA Lightweight Gateway directly on our domain controllers, it removes the requirement for port mirroring. In addition, ATA can leverage Windows Event Forwarding, forwarded directly from our domain controllers or from a security information event management system, and analyze the data for attacks and threats. The ATA Center receives data from any ATA Gateways and/or Lightweight Gateways that we deploy.
The ATA Gateway is installed on a dedicated server that monitors the traffic from our domain controllers using either port mirroring or a network TAP. The ATA Lightweight Gateway is installed directly on our domain controllers and monitors their traffic directly without the need for a dedicated server or configuration of port mirroring. It's an alternative to the ATA Gateway. And ATA deployment can consist of a single ATA Center connected to all ATA Gateways, to all ATA Lightweight Gateways, or to a combination of Gateways and Lightweight Gateways.
Let's talk for a moment about what the ATA Center does. After receiving the parse traffic from a Gateway or a Lightweight Gateway, the ATA Center does the heavy lifting around analysis, enabling detection of anomalies, and warning us of suspicious activities, including managing the Gateway and the configuration settings, receiving data from the Gateways and Lightweight Gateways, running the various deterministic algorithms to detect advanced attacks based on the attack kill chain.
It runs the ATA Console and optionally, sends emails and raises events when suspicious activity is detected. So, what do the Gateway and Lightweight Gateways roles do? Understanding what they do and how they differ are key to determining which you should use in different scenarios. These roles capture and inspect domain controller network traffic. This is port mirrored traffic for a Gateway and local traffic of the domain controller for a Lightweight Gateway.
They receive Windows events from security information event management systems, or from Syslog servers, or from domain controllers using Windows Event Forwarding. They also retrieve data about users and computers from our Active Directory domains. They perform resolution of network entities, such as users, groups, and computers, and they transfer relevant data to our ATA Center. Now, some features work differently depending on whether we're running a Gateway or a Lightweight Gateway.
The Lightweight Gateway can read events locally without the need for Event Forwarding. The domain synchronizer role is the Gateway responsible for synchronizing all entities from a specific Active Directory domain proactively. One Gateway is chosen randomly from the list of candidates to serve as the synchronizer, and if that synchronizer is offline for more than 30 minutes, another candidate is chosen instead.
Now, if there's no domain synchronizer available for a specific Active Directory domain, ATA won't be able to proactively synchronize entities and their changes. Bear in mind that by default, all ATA Gateways are synchronizer candidates because the ATA Lightweight Gateways are more likely to be deployed in branch sites and on small domain controllers. They are not synchronizer candidates by default. The Lightweight Gateway includes a monitoring component which evaluates the available compute and memory capacity on a domain controller on which it's running.
The monitoring process runs every 10 seconds and dynamically updates the CPU and memory utilization quota on the Lightweight Gateway process to ensure the domain controller has at least 15% of free compute and memory resources, so in that respect, it's self-policing. No matter what happens on the domain controller, this process always frees up resources to make sure the domain controller's core functionality is not affected. In order to work with ATA, we want to make sure of the following.
If we're using Gateways, we have to set up port mirroring for the domain controller that will be monitored and set the Gateway as the destination. If some, but not all of our domain controllers are monitored, detections will be less effective. To enhance ATA's detection of pass-the-hash, brute force, and modification to sensitive groups, ATA needs Windows Events with certain IDs, which we can configure to be forwarded from our security event information management system or from our domain controllers directly via Windows Event Forwarding.
And that's ATA planning and architecture in a nutshell.
- Configuring virtual-based security
- Securing email
- Implementing post-breach defense
- Protecting the cloud with Azure AD
- Using Windows Defender ATP
- Managing privileged access in Azure