Best practices for securing your AD and maintaining compliance. Active Directory security is often described as a way of controlling the keys to your IT castle — a metaphor that has merit but also important limitations. Active Directory does function as a gatekeeper, determining who has which keys for entering your network, as well as which data and other resources each of those keys can unlock. But unlike a stone building, your IT environment is an incredibly dynamic place, with users constantly coming and going, employees taking on new roles, new applications being added and other being retired, and so on. Therefore, Active Directory security is not a once-and-done event, like changing the locks on a castle, but an ongoing process.
Read on for more tips on securing your Active Directory.
Active Directory security is a delicate balancing act. Continuing the castle metaphor, while a king or queen is free to mandate whatever security measures they desire from their subjects, IT pros must keep business needs firmly in mind. If security measures are too arduous, they will slow critical business processes and drive away talented staff. For example, it’s crucial to ensure that only the right people can access each person’s medical data — but it’s equally essential to ensure that medical teams can see a patient’s diagnoses and prescriptions in time to provide proper care. Plus, users find ways to work around security measures they find too inconvenient: Require them to create complex passwords that must be changed every thirty days, and you’ll soon find a lot of sticky notes on their desks, which undermines your goal of protecting their accounts from unauthorized access.
It’s important to understand that while Active Directory security is closely tied to regulatory compliance, the two things are not identical. Many compliance regulations include requirements that directly affect AD security policies and procedures, but these mandates often extend into many other areas, such as physical access to office buildings, workforce training, and executive accountability. On the flip side, comprehensive AD security involves more than achieving compliance with one or more regulations.
AD security is an essential part of many compliance regulations, including GDPR, CCPA, HIPAA, SOX and PCI-DSS. Failure to secure Active Directory properly can result in many unpleasant consequences, including steep fines from regulators, jail time for executives, inability to process credit card transactions and loss of customer trust.
Active Directory security risks arise primarily from lack of insight into and control over three key factors:
Some of these risks have specific names, such as insider threats, spear-phishing, privilege escalation and lateral movement. However, the best way to address AD security risks is to not to battle each one individually; that approach drives up costs and adds to IT system complexity, compounding the problem instead of solving it.
Instead, the best strategy is to clean up your Active Directory and gain clear visibility into activity across your IT environment. Tools built into Active Directory provide a small fraction of the functionality needed and are time consuming to use, so it’s smart to invest in comprehensive solutions that automate and simplify core processes required for strong Active Directory security.
Active Directory has been around for a long time, so best practices are readily available that are proven to dramatically strengthen AD security and compliance. Implementing the following best practices will help minimize the risks to your IT data and systems — and protect your organization’s future success.
One of the most important AD security best practices
is to regularly review the state of your IT environment and proactively look
for potential security and compliance issues.
Periodically compare
the configuration settings on your Windows endpoints, domain controllers and
other systems to a known good state, and then promptly remediate any
unintended drift or malicious changes.
Be sure to regularly review Group
Policy, which is used to apply standard settings across your users and
computers. Group Policy controls many activities; you can prohibit users from
accessing the Control Panel, using the command prompt or installing software.
Even one improper change to a Group Policy object (GPO), can cause significant
damage. For instance, users might suddenly be able to insert USB drives and
thereby release ransomware or other malware into your systems. Therefore, make
sure that your GPOs work as intended and can quickly spot and revert any
improper or unauthorized changes to them.
Additionally, ensure Windows Server operating systems and other software are up to date on patches and that
you’re using only versions fully supported by vendors.
Perhaps the most fundamental bedrock best practice
for IT security is the least-privilege principle. Give each user exactly the
access they need to do their job, no more, no less. AD allows you to put users
with similar roles (such as all helpdesk admins or all HR staff) into an AD
security group and manage them together. Users can be — and usually are
— members of multiple AD groups, such as project-based groups.
Using
AD security groups is not merely a convenience for administrators; it improves
security by reducing errors in provisioning and deprovisioning, and by
minimizing the complexity of the permissions structure so it’s easier to
say with certainty who has access to what.
No matter how good your prevention efforts are, you will experience cybersecurity incidents, so you need to be prepared to investigate them quickly and respond appropriately. You need to be able to quickly determine where the breach originated, how it unfolded, and exactly what systems and data were involved. That way, you can hold individuals accountable for their actions and take steps to prevent similar incidents from occurring in the future.
As stated earlier least-privilege principle is the
most basic best practice for IT security. If you had to manually assign each
user permissions to each resource individually — and keep those
permissions current as users come and go and change roles within the
organization — you’d be overwhelmed, and your organization would
be at high risk of breaches and compliance failures.
The ability to
create AD security groups and manage permissions for similar users together
reduces the load. Users can — and usually are — members of
multiple AD groups, such as project-based groups. For example, a new sales
manager can be given access to all the right resources just by adding them to
both the Sales security group and the Sales Manager security group. Similarly,
if there’s a new folder or file share that all salespeople need access
to, you can grant the Sales group access, instead of having to add it to the
individual user accounts one by one. Conversely, if a user moves from a Sales
role to a different position, you can remove their access to all Sales
resources by removing them from the Sales group instead of having to
painstakingly look at each resource they have permissions to and determine
whether access is still legitimate.
Using AD security groups is not merely a convenience
for administrators; it improves security by reducing errors in provisioning
and deprovisioning, and by minimizing the complexity of the permissions
structure so it’s easier to say with certainty who has access to what.
Of
particular concern are AD security groups that grant administrative-level
privileges, such as the extremely powerful Enterprise Admins, Domain Admins
and Schema Admins groups, as well as local Administrator account that is
created during the Windows installation and that has full control of the
files, directories, services and other resources on the local computer.
Organizations need to tightly control who is in these privileged access groups
and be alert for any changes to their membership, which could indicate an
attacker or malicious insider attempting to escalate their privileges to gain
access to additional systems or data.
Service accounts are special user accounts that applications and services use log on and perform actions in your IT environment. Unfortunately, service accounts frequently have more permissions than they actually need, increasing security risks. Common reasons for overprovisioning include meekly accepting the requirements specified by the application vendor, failing to properly work through operational challenges, and simply cloning an existing service instead of taking the time to create a new one with the appropriate permissions.
The best practice is to ensure all service accounts comply with the
least-privilege principle. You also need to take special precautions whenever
a service account needs administrative privileges. You should never make a
service account a member of a standard administrative group, such as the local
Administrator or Domain Admins group. Better options are to run the service
under the LocalSystem account, or to create a custom group for the service
account and explicitly deny access to other accounts for that group. And,
whenever possible, it’s prudent to configure service accounts so they
can log on only during a specified period during the day.