Hi ATA team

We are a midsize company operating in the public sector. We have approx. 100 000 user accounts, 50 000 clients and 2 000 servers. Today we have a single forest/single domain but with Microsoft new direction with bastion forests (What's new in Active Directory Domain Services (AD DS) in Windows Server Technical Preview, https://msdn.microsoft.com/en-us/library/mt163897.aspx and Shielded VMs and Guarded Fabric Validation Guide for Windows Server 2016, https://gallery.technet.microsoft.com/Shielded-VMs-and-Guarded-44176db3) we believe we have a couple of more forests next year.

We have 12 Domain Controllers spread on 8 VMware clusters in different geographical areas with a total of 90 ESX hosts.

Comments on the information in ATA Deployment Guide (Technical Preview), https://technet.microsoft.com/en-us/library/mt126113.aspx.

Multiple Domain support

An ATA deployment, which consists of one ATA Center and one to four ATA Gateways, can monitor one domain.

ATA should be able to monitor multiple forests and domains. A lot of customers have multiple forests and domains, and with Microsoft new bastion forests I think its a must have.

SEIM/Syslog

Its a good thing with SIEM/Syslog integration. But when it comes to forwarding events from a Domain Controller it should be sufficient with the already built in tools for forward and collect events, we shouldnt have to do the round trip via a SIEM/Syslog for forwarding events. Each Domain Controller should be configured as source and any or all (depending on the closest or network topology) of the ATA Gateways should be configured as collectors. Then the ATA Gateway will have the events locally and can process them.

We hope you will extend the list to include logs from antivirus software (such as SCEP), central firewalls and IPS/IDS as well.

ATA Center

We recommend that the ATA Center be a member of a workgroup and not be a member of the domain.

The ATA Center should be supported in a domain joined environment. For many customers the internal policy is to have all Windows clients and servers joined to the domain and to request a change for workgroup is always cumbersome. Also today most companys run a lot of agents which uses AD on their servers, such as antivirus, inventory, software deployment, monitoring, backup and also configure their servers via GPOs, so the domain join should be supported.

ATA Gateway

The ATA Gateway should be a member of a workgroup and not be a member of the domain.

Same comment as for ATA Center.

Installation of the ATA Gateway as a virtual machine is supported when the domain controllers being monitored are also running as virtual machines on the same virtualization host.

This must change somehow. If we should follow that it would mean that we need to install 90 ATA Gateways for our 12 Domain Controllers.

If it will be possible to have 1 ATA Gateway per cluster it would be fine. Or some agent that we install on the Domain Controller instead of the port mirroring.

Wish list for ATA

Access to the ATA Management console is via a browser.

During the setup we should be allowed to enter a friendly URL for accessing the ATA Management console, for example https://ata-management.contoso.com. The setup would then configure both IIS and the certificate with that friendly URL.

Authentication and authorization

Please make the ATA Console a modern web app with support for AD FS. Take a look at what the Azure Pack team have done with their console where they support either Windows authentication or AD FS. Configure Active Directory Federation Services for Windows Azure Pack, https://technet.microsoft.com/sv-se/library/dn296436.aspx.

Roles

There need to be some type of roles that can access the ATA Console, and if you implement roles, make them AD-groups if Windows authentication or claims if AD FS. For my organization it will be fine with something like below, other organizations might see other needs for their roles.

• ATA Admin (full access and modify)
• ATA Operations (read and assign/close alarms)
• ATA Readers (for the Service Desk when they have a user on call)
• ATA Reports (for the Security teams for reporting)

AD FS and WAP

More and more authentication goes over AD FS so what about extending ATA to also monitor our AD FS and WAP servers the same way you monitor Domain Controllers today?

Azure AD

A lot of companys uses Azure AD and in the new reports in Azure AD there are a couple of them that make sense for ATA to consume, such as the ones under Anomalous activities.

SCOM Management Pack

There should be a SCOM Management Pack for ATA. Both for the overall health and state for ATA Center and Gateway but also with a monitoring dashboard about the events that ATA raises. Its already hard for our operations team with all different consoles they have to monitor. To actually see the event in SCOM would be a huge benefit for them. After that they can always open up the ATA Console for deeper investigation.

Thanks!

Rickard

Hello Rickard,

Thank you very much for the great feedback. This is really appreciated.

Here are some answers to your comments:

Multiple Domain support

This is going to be supported in the GA version. At the current version we support single domain but we can identify forwarded Kerberos activity if we are listening to a DC which act as GC.

SEIM/Syslog

We are continuously adding more data sources to our detection and we expect to have more and more data sources in future versions.

Domain Join

This is a long debate in the security community (to join or not to join a security product to the domain). We support both options and we are going to modify our documentation so it will be clear that both scenarios are supported, and it is up to the customer to choose.

Please keep in mind that with the current design, the center machine does not even need network connectivity to your DCs.

Monitoring virtual DCs from Physical GW

We are researching this scenario at this point and we are going to publish some guidelines around virtual/physical hybrid scenarios, as it seems there are several 3^rd party solutions that can help on those scenarios.

As for installing agent on the domain controller, this is something we are doing our best to avoid, as DCs are most critical asset for the organizations and we are the only cyber-security product that leverage AD as data source without installing any agents on the DC.

Management URL

In the current setup, you have the option to modify the URL to an FQDN in the UI. If you are using your own PKI infrastructure for the certificates you can match the certificate with the machines name.

Authentication, Authorization and RBAC

This is very good and valid feedback and we will consider it for our future versions.

AD FS and WAP

In the scenario of using AD FS If we monitor the DC in the backend, we can see this activity.

Other feedback

We got similar requests from other customers and we will be more than happy to have a chat with you to understand your specific needs. You can contact me directly to arrange such call (my Microsofts alias identical to my forum name).

Thanks again for the great feedback, this is exactly the type of feedback we are looking for and this will help us to make the product even better.

Microsoft ATA team.

Hello Rickard,

Thank you very much for the great feedback. This is really appreciated.

Here are some answers to your comments:

Multiple Domain support

This is going to be supported in the GA version. At the current version we support single domain but we can identify forwarded Kerberos activity if we are listening to a DC which act as GC.

SEIM/Syslog

We are continuously adding more data sources to our detection and we expect to have more and more data sources in future versions.

Domain Join

This is a long debate in the security community (to join or not to join a security product to the domain). We support both options and we are going to modify our documentation so it will be clear that both scenarios are supported, and it is up to the customer to choose.

Please keep in mind that with the current design, the center machine does not even need network connectivity to your DCs.

Monitoring virtual DCs from Physical GW

We are researching this scenario at this point and we are going to publish some guidelines around virtual/physical hybrid scenarios, as it seems there are several 3^rd party solutions that can help on those scenarios.

As for installing agent on the domain controller, this is something we are doing our best to avoid, as DCs are most critical asset for the organizations and we are the only cyber-security product that leverage AD as data source without installing any agents on the DC.

Management URL

In the current setup, you have the option to modify the URL to an FQDN in the UI. If you are using your own PKI infrastructure for the certificates you can match the certificate with the machines name.

Authentication, Authorization and RBAC

This is very good and valid feedback and we will consider it for our future versions.

AD FS and WAP

In the scenario of using AD FS If we monitor the DC in the backend, we can see this activity.

Other feedback

We got similar requests from other customers and we will be more than happy to have a chat with you to understand your specific needs. You can contact me directly to arrange such call (my Microsofts alias identical to my forum name).

Thanks again for the great feedback, this is exactly the type of feedback we are looking for and this will help us to make the product even better.

Microsoft ATA team.

• Proposed as answer by ophirpMicrosoft employee, Owner 18 hours 46 minutes ago

Hello Rickard,

Thank you very much for the great feedback. This is really appreciated.

Here are some answers to your comments:

Multiple Domain support

This is going to be supported in the GA version. At the current version we support single domain but we can identify forwarded Kerberos activity if we are listening to a DC which act as GC.

SEIM/Syslog

We are continuously adding more data sources to our detection and we expect to have more and more data sources in future versions.

Domain Join

This is a long debate in the security community (to join or not to join a security product to the domain). We support both options and we are going to modify our documentation so it will be clear that both scenarios are supported, and it is up to the customer to choose.

Please keep in mind that with the current design, the center machine does not even need network connectivity to your DCs.

Monitoring virtual DCs from Physical GW

We are researching this scenario at this point and we are going to publish some guidelines around virtual/physical hybrid scenarios, as it seems there are several 3^rd party solutions that can help on those scenarios.

As for installing agent on the domain controller, this is something we are doing our best to avoid, as DCs are most critical asset for the organizations and we are the only cyber-security product that leverage AD as data source without installing any agents on the DC.

Management URL

In the current setup, you have the option to modify the URL to an FQDN in the UI. If you are using your own PKI infrastructure for the certificates you can match the certificate with the machines name.

Authentication, Authorization and RBAC

This is very good and valid feedback and we will consider it for our future versions.

AD FS and WAP

In the scenario of using AD FS If we monitor the DC in the backend, we can see this activity.

Other feedback

We got similar requests from other customers and we will be more than happy to have a chat with you to understand your specific needs. You can contact me directly to arrange such call (my Microsofts alias identical to my forum name).

Thanks again for the great feedback, this is exactly the type of feedback we are looking for and this will help us to make the product even better.

Microsoft ATA team.

• Proposed as answer by ophirpMicrosoft employee, Owner Thursday, May 28, 2015 12:50 PM

Hello Rickard,

Thank you very much for the great feedback. This is really appreciated.

Here are some answers to your comments:

Multiple Domain support

This is going to be supported in the GA version. At the current version we support single domain but we can identify forwarded Kerberos activity if we are listening to a DC which act as GC.

SEIM/Syslog

We are continuously adding more data sources to our detection and we expect to have more and more data sources in future versions.

Domain Join

This is a long debate in the security community (to join or not to join a security product to the domain). We support both options and we are going to modify our documentation so it will be clear that both scenarios are supported, and it is up to the customer to choose.

Please keep in mind that with the current design, the center machine does not even need network connectivity to your DCs.

Monitoring virtual DCs from Physical GW

We are researching this scenario at this point and we are going to publish some guidelines around virtual/physical hybrid scenarios, as it seems there are several 3^rd party solutions that can help on those scenarios.

As for installing agent on the domain controller, this is something we are doing our best to avoid, as DCs are most critical asset for the organizations and we are the only cyber-security product that leverage AD as data source without installing any agents on the DC.

Management URL

In the current setup, you have the option to modify the URL to an FQDN in the UI. If you are using your own PKI infrastructure for the certificates you can match the certificate with the machines name.

Authentication, Authorization and RBAC

This is very good and valid feedback and we will consider it for our future versions.

AD FS and WAP

In the scenario of using AD FS If we monitor the DC in the backend, we can see this activity.

Other feedback

We got similar requests from other customers and we will be more than happy to have a chat with you to understand your specific needs. You can contact me directly to arrange such call (my Microsofts alias identical to my forum name).

Thanks again for the great feedback, this is exactly the type of feedback we are looking for and this will help us to make the product even better.

Microsoft ATA team.

• Proposed as answer by ophirpMicrosoft employee, Owner Thursday, May 28, 2015 12:50 PM

Hello Rickard,

Thank you very much for the great feedback. This is really appreciated.

Here are some answers to your comments:

Multiple Domain support

This is going to be supported in the GA version. At the current version we support single domain but we can identify forwarded Kerberos activity if we are listening to a DC which act as GC.

SEIM/Syslog

We are continuously adding more data sources to our detection and we expect to have more and more data sources in future versions.

Domain Join

This is a long debate in the security community (to join or not to join a security product to the domain). We support both options and we are going to modify our documentation so it will be clear that both scenarios are supported, and it is up to the customer to choose.

Please keep in mind that with the current design, the center machine does not even need network connectivity to your DCs.

Monitoring virtual DCs from Physical GW

We are researching this scenario at this point and we are going to publish some guidelines around virtual/physical hybrid scenarios, as it seems there are several 3^rd party solutions that can help on those scenarios.

As for installing agent on the domain controller, this is something we are doing our best to avoid, as DCs are most critical asset for the organizations and we are the only cyber-security product that leverage AD as data source without installing any agents on the DC.

Management URL

In the current setup, you have the option to modify the URL to an FQDN in the UI. If you are using your own PKI infrastructure for the certificates you can match the certificate with the machines name.

Authentication, Authorization and RBAC

This is very good and valid feedback and we will consider it for our future versions.

AD FS and WAP

In the scenario of using AD FS If we monitor the DC in the backend, we can see this activity.

Other feedback

We got similar requests from other customers and we will be more than happy to have a chat with you to understand your specific needs. You can contact me directly to arrange such call (my Microsofts alias identical to my forum name).

Thanks again for the great feedback, this is exactly the type of feedback we are looking for and this will help us to make the product even better.

Microsoft ATA team.

• Proposed as answer by ophirpMicrosoft employee, Owner Thursday, May 28, 2015 12:50 PM

Hello Rickard,

Thank you very much for the great feedback. This is really appreciated.

Here are some answers to your comments:

Multiple Domain support

This is going to be supported in the GA version. At the current version we support single domain but we can identify forwarded Kerberos activity if we are listening to a DC which act as GC.

SEIM/Syslog

We are continuously adding more data sources to our detection and we expect to have more and more data sources in future versions.

Domain Join

This is a long debate in the security community (to join or not to join a security product to the domain). We support both options and we are going to modify our documentation so it will be clear that both scenarios are supported, and it is up to the customer to choose.

Please keep in mind that with the current design, the center machine does not even need network connectivity to your DCs.

Monitoring virtual DCs from Physical GW

We are researching this scenario at this point and we are going to publish some guidelines around virtual/physical hybrid scenarios, as it seems there are several 3^rd party solutions that can help on those scenarios.

As for installing agent on the domain controller, this is something we are doing our best to avoid, as DCs are most critical asset for the organizations and we are the only cyber-security product that leverage AD as data source without installing any agents on the DC.

Management URL

In the current setup, you have the option to modify the URL to an FQDN in the UI. If you are using your own PKI infrastructure for the certificates you can match the certificate with the machines name.

Authentication, Authorization and RBAC

This is very good and valid feedback and we will consider it for our future versions.

AD FS and WAP

In the scenario of using AD FS If we monitor the DC in the backend, we can see this activity.

Other feedback

We got similar requests from other customers and we will be more than happy to have a chat with you to understand your specific needs. You can contact me directly to arrange such call (my Microsofts alias identical to my forum name).

Thanks again for the great feedback, this is exactly the type of feedback we are looking for and this will help us to make the product even better.

Microsoft ATA team.

• Proposed as answer by ophirpMicrosoft employee, Owner Thursday, May 28, 2015 12:50 PM

Hello Rickard,

Thank you very much for the great feedback. This is really appreciated.

Here are some answers to your comments:

Multiple Domain support

This is going to be supported in the GA version. At the current version we support single domain but we can identify forwarded Kerberos activity if we are listening to a DC which act as GC.

SEIM/Syslog

We are continuously adding more data sources to our detection and we expect to have more and more data sources in future versions.

Domain Join

This is a long debate in the security community (to join or not to join a security product to the domain). We support both options and we are going to modify our documentation so it will be clear that both scenarios are supported, and it is up to the customer to choose.

Please keep in mind that with the current design, the center machine does not even need network connectivity to your DCs.

Monitoring virtual DCs from Physical GW

We are researching this scenario at this point and we are going to publish some guidelines around virtual/physical hybrid scenarios, as it seems there are several 3^rd party solutions that can help on those scenarios.

As for installing agent on the domain controller, this is something we are doing our best to avoid, as DCs are most critical asset for the organizations and we are the only cyber-security product that leverage AD as data source without installing any agents on the DC.

Management URL

In the current setup, you have the option to modify the URL to an FQDN in the UI. If you are using your own PKI infrastructure for the certificates you can match the certificate with the machines name.

Authentication, Authorization and RBAC

This is very good and valid feedback and we will consider it for our future versions.

AD FS and WAP

In the scenario of using AD FS If we monitor the DC in the backend, we can see this activity.

Other feedback

We got similar requests from other customers and we will be more than happy to have a chat with you to understand your specific needs. You can contact me directly to arrange such call (my Microsofts alias identical to my forum name).

Thanks again for the great feedback, this is exactly the type of feedback we are looking for and this will help us to make the product even better.

Microsoft ATA team.

• Proposed as answer by ophirpMicrosoft employee, Owner Thursday, May 28, 2015 12:50 PM

Hello Rickard,

Thank you very much for the great feedback. This is really appreciated.

Here are some answers to your comments:

Multiple Domain support

This is going to be supported in the GA version. At the current version we support single domain but we can identify forwarded Kerberos activity if we are listening to a DC which act as GC.

SEIM/Syslog

We are continuously adding more data sources to our detection and we expect to have more and more data sources in future versions.

Domain Join

This is a long debate in the security community (to join or not to join a security product to the domain). We support both options and we are going to modify our documentation so it will be clear that both scenarios are supported, and it is up to the customer to choose.

Please keep in mind that with the current design, the center machine does not even need network connectivity to your DCs.

Monitoring virtual DCs from Physical GW

We are researching this scenario at this point and we are going to publish some guidelines around virtual/physical hybrid scenarios, as it seems there are several 3^rd party solutions that can help on those scenarios.

As for installing agent on the domain controller, this is something we are doing our best to avoid, as DCs are most critical asset for the organizations and we are the only cyber-security product that leverage AD as data source without installing any agents on the DC.

Management URL

In the current setup, you have the option to modify the URL to an FQDN in the UI. If you are using your own PKI infrastructure for the certificates you can match the certificate with the machines name.

Authentication, Authorization and RBAC

This is very good and valid feedback and we will consider it for our future versions.

AD FS and WAP

In the scenario of using AD FS If we monitor the DC in the backend, we can see this activity.

Other feedback

We got similar requests from other customers and we will be more than happy to have a chat with you to understand your specific needs. You can contact me directly to arrange such call (my Microsofts alias identical to my forum name).

Thanks again for the great feedback, this is exactly the type of feedback we are looking for and this will help us to make the product even better.

Microsoft ATA team.

• Proposed as answer by ophirpMicrosoft employee, Owner Thursday, May 28, 2015 12:50 PM

Hello Rickard,

Thank you very much for the great feedback. This is really appreciated.

Here are some answers to your comments:

Multiple Domain support

This is going to be supported in the GA version. At the current version we support single domain but we can identify forwarded Kerberos activity if we are listening to a DC which act as GC.

SEIM/Syslog

We are continuously adding more data sources to our detection and we expect to have more and more data sources in future versions.

Domain Join

This is a long debate in the security community (to join or not to join a security product to the domain). We support both options and we are going to modify our documentation so it will be clear that both scenarios are supported, and it is up to the customer to choose.

Please keep in mind that with the current design, the center machine does not even need network connectivity to your DCs.

Monitoring virtual DCs from Physical GW

We are researching this scenario at this point and we are going to publish some guidelines around virtual/physical hybrid scenarios, as it seems there are several 3^rd party solutions that can help on those scenarios.

As for installing agent on the domain controller, this is something we are doing our best to avoid, as DCs are most critical asset for the organizations and we are the only cyber-security product that leverage AD as data source without installing any agents on the DC.

Management URL

In the current setup, you have the option to modify the URL to an FQDN in the UI. If you are using your own PKI infrastructure for the certificates you can match the certificate with the machines name.

Authentication, Authorization and RBAC

This is very good and valid feedback and we will consider it for our future versions.

AD FS and WAP

In the scenario of using AD FS If we monitor the DC in the backend, we can see this activity.

Other feedback

We got similar requests from other customers and we will be more than happy to have a chat with you to understand your specific needs. You can contact me directly to arrange such call (my Microsofts alias identical to my forum name).

Thanks again for the great feedback, this is exactly the type of feedback we are looking for and this will help us to make the product even better.

Microsoft ATA team.

• Proposed as answer by ophirpMicrosoft employee, Owner Thursday, May 28, 2015 12:50 PM

Hello Rickard,

Thank you very much for the great feedback. This is really appreciated.

Here are some answers to your comments:

Multiple Domain support

This is going to be supported in the GA version. At the current version we support single domain but we can identify forwarded Kerberos activity if we are listening to a DC which act as GC.

SEIM/Syslog

We are continuously adding more data sources to our detection and we expect to have more and more data sources in future versions.

Domain Join

This is a long debate in the security community (to join or not to join a security product to the domain). We support both options and we are going to modify our documentation so it will be clear that both scenarios are supported, and it is up to the customer to choose.

Please keep in mind that with the current design, the center machine does not even need network connectivity to your DCs.

Monitoring virtual DCs from Physical GW

We are researching this scenario at this point and we are going to publish some guidelines around virtual/physical hybrid scenarios, as it seems there are several 3^rd party solutions that can help on those scenarios.

As for installing agent on the domain controller, this is something we are doing our best to avoid, as DCs are most critical asset for the organizations and we are the only cyber-security product that leverage AD as data source without installing any agents on the DC.

Management URL

In the current setup, you have the option to modify the URL to an FQDN in the UI. If you are using your own PKI infrastructure for the certificates you can match the certificate with the machines name.

Authentication, Authorization and RBAC

This is very good and valid feedback and we will consider it for our future versions.

AD FS and WAP

In the scenario of using AD FS If we monitor the DC in the backend, we can see this activity.

Other feedback

We got similar requests from other customers and we will be more than happy to have a chat with you to understand your specific needs. You can contact me directly to arrange such call (my Microsofts alias identical to my forum name).

Thanks again for the great feedback, this is exactly the type of feedback we are looking for and this will help us to make the product even better.

Microsoft ATA team.

• Proposed as answer by ophirpMicrosoft employee, Owner Thursday, May 28, 2015 12:50 PM