> Bob admins the DC from a workstation. If that workstation is not protected as much as the domain controller, the DC can be compromised.
They both run Windows. The protection class between the two is identical. You can draw as many graphs and lists as you want, but the security of this arrangement is mostly down to timely and accurate Windows Updates.
> Learn to Spot List Thinking
I think in terms of "diffs." I want to know what is _changing_ on my network. I don't ever need an enumeration of things in any particular arrangement and as a human being, whether graph or list, I'm not equipped to use it in any meaningful way.
A difference list is typically very short, reveals intrusion patterns quickly, and is something you can automate easily.
You can do a lot more than just keep Windows up to date. Here are some other things you should do:
1) Use separate accounts and machines for administration tasks. Basically, IT people should never use their e-mail, web browsing, and development machine for system management tasks. They should use a separate machine with a different account for these tasks. The main reason is the system management machine has a much smaller attack surface. Ideally, it should only run a communications program (IRC, Slack, MS Teams, etc.), and the tools the person needs to do their job. Examples of tools people need include SSH, Remote Desktop, kubectl (Kubernetes tool to manage a cluster), etc. The machine should have a web browser BUT the web browser should be restricted to the bare minimum number of sites needed to administer the systems. Examples of acceptable sites include the Azure Portal, the AWS web site, web sites to configure equipment, etc. Examples of things which are not allowed include web mail, documentation, etc. The goal is to have the smallest possible attack surface.
2) People need to be mindful of what they install on their machines. I have seen a lot of people who will install anything which looks useful on their machine. This is a great way to get hacked. Here are the questions people need to ask before installing software.
- Why do I trust the people who wrote the software?
- Why was the software created? What was the motivation of the author?
- How does the author support himself or herself? What would happen if one of the authors was in financial distress?
- How will I know when the software needs to be updated?
- What are the capabilities of the software's authors? Do the authors understand how to write secure software? How do the authors handle security bug reports?
Basically, you ask these questions because you want to avoid malware, and you want to use software which fixes its security problems.
3) Consider putting system management machines on a different network or VPN. Basically, it's harder to hack a machine if you can't easily communicate with it.
4) System management machines should not be listening on any ports (or should have a firewall which blocks all connection attempts). It's harder to break into a machine when an attacker cannot connect to it.
5) Put the system management machines behind a firewall.
6) Consider what happens when an account is eventually hacked. Many people assume that only dumb or incompetent people get hacked. Unfortunately, this is not true. Systems should be designed to assume accounts will get hacked. The best designs limit the blast radius (damage) of account attacks.
7) All users should have limited privileges. Basically, they should get the privileges they need to do their jobs. Very few people should be allowed to have the equivalent of root/Administrator for the entire system (obviously, people may have these permissions for some machines but almost no account should be able to do anything on any system the organization runs).
What I meant is even doing all this you're effectively a single 0-day away from total compromise and are now dependent on specific workarounds or on getting the update that patches the vulnerability.
Because of this I can't consider the security of the AD as any better or worse than the desktop that connects to it and it's pointless to pretend that you can even have this.
We did have a crypto locker that spread on our network this way between our AD machines. It was launched from an email in the sales department, but due to an unpatched RDP credential attack, it quickly got onto the ADs then spread across the entire WAN.
I'm not saying don't do the things you're suggesting but you should prepare the scenario where none of it matters. So one thing you missed which we now have is: WAN KILL SWITCH.
I dunno about that; it sounds like a PC in your sales department could connect to the RDP port on the AD, and the listed controls would have prevented that (RDP port on the DC should be firewalled down to the machines administrators use to connect to them, which per the comment should _not_ include access to emails, just in case the compromise you're describing was actually an email from sales -> system administrator).
They both run Windows. The protection class between the two is identical. You can draw as many graphs and lists as you want, but the security of this arrangement is mostly down to timely and accurate Windows Updates.
> Learn to Spot List Thinking
I think in terms of "diffs." I want to know what is _changing_ on my network. I don't ever need an enumeration of things in any particular arrangement and as a human being, whether graph or list, I'm not equipped to use it in any meaningful way.
A difference list is typically very short, reveals intrusion patterns quickly, and is something you can automate easily.