Secure Active Directory management. Part 3 (final)
Today we are completing a small series of notes related to secure Active Directory management. This material is a translation of text from Brian Svidergol, the author of Active Directory CookBook.
As always - focus on ideas that will help your infrastructure become more secure. The previous two parts can be found at the links below:
Part 1
Part 2
In this part we are talking about monitoring events related to AD.
')
Why is it necessary to track both successful and unsuccessful operations?
Do you track only failed operations? Unfortunately, you will have to revise the audit strategy, our author believes. Let's give a couple of examples showing how important it is to monitor successfully completed events:
For example, you want to know who changed the settings of the domain controller. The change was successful. In order to make a change, it was necessary to successfully log in to the domain. And then successfully use remote administration tools (RDP or MMC). This whole story is directly permeated by successful actions, if you don’t track them, it’s hard to understand who changed what and when.
Another example: you see a large number of events related to the unsuccessful attempt of the service account to log in to the domain. It is great that you can track down failed attempts. It’s bad that you don’t understand why the attempts stopped: either the attacker managed to log in or he was tired of trying. In both cases, it is better to track both successful and unsuccessful operations.
How to monitor AD?
I suggest focusing on the Domain Admins group (although these recommendations apply to all important security groups): you should monitor all group membership changes, track and add, and delete. Otherwise, you may not know that the attacker temporarily added himself to Domain Admins, and, having done his work, retired.
Now let's talk about group policies. A wrong GP audit strategy can lead to dire consequences. For example, an attacker wants to conduct a phishing attack on the workstations of your organization, but the current IE settings interfere with or reduce the effectiveness of such an attack. A good option for an attacker can be a change in the GPO.
Another example: an attacker needs to install malware on all machines included in the domain. In this case, it can also effectively use group policies, create a new object.
Thus, continuous monitoring of the GP plays an important role in protecting the infrastructure. You need to track the creation and modification of objects (GPO), as well as object bindings (GPO links). You also need to know who initiated the changes. AD monitoring can be configured relatively quickly if you use dedicated subnets for administrative tasks (recall Part 2). Instead of installing multiple filters on individual servers, IP addresses or containers / groups, you can monitor the entire subnet.
How to reduce the number of alerts?
Anyone who has ever installed System Center Operations Manager (SCOM) knows what I'm talking about. Today, monitoring solutions have become more complex and support a huge number of systems. SystemCenter expands with the help of special packages that literally exist for any server software or hardware. At that moment, when all these packages are installed and connected, administrators are overwhelmed with numerous alerts about the “problems” in the infrastructure. As a result, admins stop responding to these alerts if everything is fine. And they start frantically looking through them only in the event of incidents, when one or several systems have actually stopped working.
My strategy is quite simple: I look at the monitoring system console every time a problem occurs. I'm trying to understand if the monitoring system gave us enough information to prevent an incident? Have alerts been sent to the right employees? Often, administrators receive alerts "by group", i.e. not only about the systems they serve, but also for their colleagues. Even if the admins see the alert, they will not react, because "anyway, another department will solve this problem."
Summing up , I suggest three simple questions that will help reduce the number of alerts:
The original text of this note is in English.
As always - focus on ideas that will help your infrastructure become more secure. The previous two parts can be found at the links below:
Part 1
Part 2
In this part we are talking about monitoring events related to AD.
')
Why is it necessary to track both successful and unsuccessful operations?
Do you track only failed operations? Unfortunately, you will have to revise the audit strategy, our author believes. Let's give a couple of examples showing how important it is to monitor successfully completed events:
For example, you want to know who changed the settings of the domain controller. The change was successful. In order to make a change, it was necessary to successfully log in to the domain. And then successfully use remote administration tools (RDP or MMC). This whole story is directly permeated by successful actions, if you don’t track them, it’s hard to understand who changed what and when.
Another example: you see a large number of events related to the unsuccessful attempt of the service account to log in to the domain. It is great that you can track down failed attempts. It’s bad that you don’t understand why the attempts stopped: either the attacker managed to log in or he was tired of trying. In both cases, it is better to track both successful and unsuccessful operations.
How to monitor AD?
I suggest focusing on the Domain Admins group (although these recommendations apply to all important security groups): you should monitor all group membership changes, track and add, and delete. Otherwise, you may not know that the attacker temporarily added himself to Domain Admins, and, having done his work, retired.
Now let's talk about group policies. A wrong GP audit strategy can lead to dire consequences. For example, an attacker wants to conduct a phishing attack on the workstations of your organization, but the current IE settings interfere with or reduce the effectiveness of such an attack. A good option for an attacker can be a change in the GPO.
Another example: an attacker needs to install malware on all machines included in the domain. In this case, it can also effectively use group policies, create a new object.
Thus, continuous monitoring of the GP plays an important role in protecting the infrastructure. You need to track the creation and modification of objects (GPO), as well as object bindings (GPO links). You also need to know who initiated the changes. AD monitoring can be configured relatively quickly if you use dedicated subnets for administrative tasks (recall Part 2). Instead of installing multiple filters on individual servers, IP addresses or containers / groups, you can monitor the entire subnet.
How to reduce the number of alerts?
Anyone who has ever installed System Center Operations Manager (SCOM) knows what I'm talking about. Today, monitoring solutions have become more complex and support a huge number of systems. SystemCenter expands with the help of special packages that literally exist for any server software or hardware. At that moment, when all these packages are installed and connected, administrators are overwhelmed with numerous alerts about the “problems” in the infrastructure. As a result, admins stop responding to these alerts if everything is fine. And they start frantically looking through them only in the event of incidents, when one or several systems have actually stopped working.
My strategy is quite simple: I look at the monitoring system console every time a problem occurs. I'm trying to understand if the monitoring system gave us enough information to prevent an incident? Have alerts been sent to the right employees? Often, administrators receive alerts "by group", i.e. not only about the systems they serve, but also for their colleagues. Even if the admins see the alert, they will not react, because "anyway, another department will solve this problem."
Summing up , I suggest three simple questions that will help reduce the number of alerts:
- Was there a response (action) by administrators to the alert? If not, why? Is it possible to immediately extinguish such alerts? Will this affect the running systems?
If so, immediately configure such alerts so that they do not come to the admins. - Do you receive alerts about systems that other employees are responsible for? If so, do other employees receive the same alerts? If the answer is “yes” again, remove yourself from the mailing list. If other employees are not subscribed to these alerts, add them and delete yourself. Only those responsible for it should receive alerts.
- Do you receive CMC notifications about incidents that are not critical? (20% of free space left on disk) If yes, remove your number from the list. SMS alerts should only come in the event of serious incidents in a production environment, otherwise you will no longer respond to them adequately.
The original text of this note is in English.
Source: https://habr.com/ru/post/217053/
All Articles