Best Practices for Securing Advanced Threat Analytics

First published on CloudBlogs on Jun 10, 2016
Today we are discussing best practices for securing Advanced Threat Analytics (ATA). ATA is somewhat unique in its role within a network environment. Like many other security products, ATA is typically deployed and managed as a system by the IT Operations Team, but the detections ATA provides are of key value to the Security Operations Team. In this post, we will discuss protecting ATA as a system and the pros & cons related to certain choices which must be made when deploying ATA.

Operating System and Components of the Operating System

Security Baseline

As with all operating systems, it is recommended to apply a baseline security policy to the operating system. We recommend the Windows Server 2012 R2 / Internet Explorer 11 baseline be applied to ATA Center and Gateway and the appropriate OS / IE baseline for the ATA Lightweight Gateway. Note: If you apply the Internet Explorer 11 baseline to Windows Server 2012 R2, opening IE on the Center and connecting to the ATA console will fail. This is because the baseline changes the “Local Intranet” security settings. You can fix this by adding the IP or URL for the console to the Site to Zone Assignment list in group policy, rather than the IE GUI which is by the baseline.

Patching

With any good security policy patching is a must. A majority of successful attacks occurring today are due to unpatched software in an environment. We recommend applying patches to the operating system in accordance with Microsoft best practices and your internal patching policy. In ATA 1.6, we added Microsoft Update for ATA components. We recommend you patch ATA as quickly as possible to enable new features and new detections. The ATA Center gets updates from Microsoft Update and can automatically apply updates to the ATA gateways. This can be configured globally, as seen below, on the ATA General configuration page.

Or per gateway, as seen below, if the global configuration is not enabled.

Domain Join or Workgroup

To domain join or not, that is the question. There are advantages to each side and depending on if you ask IT Ops or Security Ops you will get a very different answer. We recommend you evaluate each option and choose what best fits your needs and capabilities. Domain Join – From an IT Ops perspective this is recommended. It brings central management to ATA as a system. Group Policy, patching, monitoring and reporting are much easier to accomplish when ATA is centrally managed and domain joined. But from a security perspective, you have a system which is monitoring that same domain for compromise. If I use the mindset of “assume breach” and an attacker compromises the domain ATA is joined too, the attacker could thus work around ATA or disable ATA altogether. In ATA 1.6, we enhanced health monitoring which should help reduce this risk or likelihood of an attacker being successful at disabling ATA. Workgroup – From a security operations perspective this is recommended. It allows the ATA system to remain out of band removing the opportunity of an attacker to disable the ATA system, especially if you are using port mirroring and the full gateway. From an IT Operations perspective, this increases operations overhead. Now policies have to be applied manually. Patching, monitoring and reporting do not fit into the centralized process IT has created. Other things to consider include Windows Event Forwarding, ATA console authentication and PKI. In a domain-join scenario these are much easier to configure and get working. In a workgroup, additional steps and configuration will be required. For smaller organizations, domain join will likely be the best option. The risk of disabling or getting around ATA is low and with a smaller number of IT personnel, centralized management is key. For large organizations, either configuration option works, due to the larger number of staff and tools which work across workgroup machines. The security posture may be preferred.

To sum up:

Note: For customers deploying dedicated Admin (Red) Forest solutions in their environments. ATA could be hosted inside this dedicated forest. This would allow for the pros of both Domain Join and Workgroup, without the Cons.

Firewall

I am only going to discuss the Windows Firewall here but the same principle applies if you have disabled Windows Firewall and are using a 3rd Party firewall. It is recommended to enable and use a firewall to protect ATA roles. We have documented all the ports, protocols, direction and destinations here . Note: ATA will create or enable required rules automatically in Windows Firewall so no configuration is needed.

IIS

ATA Center does create its own website and AppPool. We recommend you disable the default website as it won’t be used.

Certificates

ATA can be installed with self-signed certificates or public certificates. We recommend using certificates from a public or internal CA hierarchy, if available. The certificates must be CSP based vs KSP. Fallback to self-signed certificates if CA signed certificates are not available.

Management Agents Like the domain join decision, this one gets a bit tricky. Do we install configuration management tool (i.e SCCM), monitoring tool (i.e. SCOM), Antivirus manager, name your agent on the ATA Center or Gateway? It depends on the same previous arguments. If an attacker can compromise SCCM, they could push a package and disable or break ATA and if the system is monitored then it’s health should be alerted on very quickly. As with domain join, we recommend what is right for your organization.

ATA and Components of ATA

ATA Gateway vs ATA Lightweight Gateway

One security decision which must be considered is whether to use the full or Lightweight Gateway. The full gateway allows out of band monitoring via port mirroring. The Lightweight Gateway is a service on the domain controller, which if compromised, could be disabled or manipulated, allowing the attacker to conceal themselves for some time. There are instances, like branch office or cloud Domain Controllers, where port mirroring is not an option. This is why it’s important to monitor the health of ATA and understand when a gateway is not responding. When possible we recommend the full gateway for both security and capacity/resource reasons and use the Lightweight Gateway when port mirror is not available.

MongoDB

By default, ATA does not open network access to MongoDB. ATA is configured to connect locally to the database. No other security guidance is recommended.

Honey Token Accounts

We recommend honey tokens with Domain Admin like privileges be configured with long complicated passwords. You can disable the account, but a good attacker will likely see this and ignore it. The long password won’t stop the attacker from doing things like Pass the Hash, but it will stop attacks like dictionary attacks on the password. If the account has privileged access, we recommend you respond quickly or look to automate orchestration around response. If the attacker uses the account, you need the ability to respond and stop the attacker quickly or they will be able to further compromise the network.

Naming Objects

Security by obscurity is a violation of Kerckhoffs' Principle, which holds that a system should be secure because of its design, not because the design is unknown to an adversary. If the attacker is good, it doesn’t matter if you name the ATA Service account “Sarah” or name the Servers “NotATAGW”. The attacker will figure out. We recommend you follow your organizations naming standards, so someone doesn’t delete Sarah’s account months later after install.

AV Exclusions

An up to date list of articles regarding AV exclusions is kept here . We recommend configuring the AV exclusions for the operating system per the provided link. It is also recommended to exclude the MongoDB database directory which by default is C:\Program Files\Microsoft Advanced Threat Analytics\Center\MongoDB\bin\data.

Alerting Configuration

Ensure you enable encryption for the alerting configuration, if available. Syslog can use TLS and e-mail can use SSL.

The Basics Always Apply

Most of these are the basics of good security and I didn’t cover everything. Things like random local administrator passwords, credential tiering for ATA Administrators, and keeping ATA a purpose built system (no additional roles, websites) should also follow your organizations standards.

For questions or feedback contact me directly: Nicholas DiCola ndicola@microsoft.com Principal Program Manager C+E Security CxP Team