I thought I would write this blogpost to describe what I think is best practices in terms of installation of Microsoft Advanced Threat Analytics. The product is meant to reveal advanced attacks in your infrastructure. It is therefore important to understand that you should assume breach when installing this product. This could be a little paranoid, but if we assume breach we should assume that you have advanced attackers inside your network already and installation should be done accordingly.
Here are my best practices that I try to follow during installation of Microsoft Advanced Threat Analytics:
- Never join ATA Center or ATA gateway to the domain. Leave them in workgroup. (This does not apply to the Lightweight gateway released in 1.6)
- When creating the account that is used by the gateway to talk to Active Directory, don’t name it Microsoft-ATA-ServiceAccount. Obfuscate the account. Let it blend in with all the other accounts. Having an easily identifiably account could make the attacker aware of you installing Microsoft Advanced Threat Analytics.
- When giving name to the servers don’t name them ATA-GW01 or MS-ATACenter01. Give them names that does not let the attacker aware of what you are installing.
- Do not use the same password on the local administrator account as you use else in the domain. Remember that you should assume breach and if the attacker has dumped all your passwords, they will try them.
- Do not use certificates from your current PKI solution. Use self-signed certs.
When configuring the HoneyToken account, make the password easy to guess and give the account a cool name. A name like oracledba, sqlmaster or something like that. You could type the password in the description field, but that could probably be too obvious.Honey tokens are designed to create an alert even if the usage of the Honey token account is unsuccessful. (Thanx to Tom Aafloen for pointing that out). I would therefore recommend to create the honey token with a password that is impossible to guess and make it a lucrative account to try to hack. Give it domain admin/Enterprise admin rights, full dba rights and so on. That way the attacker will probably target that account.
- Only allow access to the ATA-Center console from certain management ip-adresses.
- Do hardening of the ATA servers and make sure they automatically install Windows updates.
- Do an internal penetration test to verify that it will detect an advanced attack.
I will try to keep this post updated with more best practices in the future.
Microsoft has written a blogpost about best practices for securing ATA here: https://blogs.technet.microsoft.com/enterprisemobility/2016/06/10/best-practices-for-securing-advanced-threat-analytics/