March 26, 2014 at 15:55Secure Active Directory Management. Part 3 (final)
Today, we are completing a short series of notes regarding the secure management of Active Directory. This material is a translation from Brian Svidergol, 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 a domain controller. The change was successful. In order to make the change, it was necessary to successfully log in to the domain. And then successfully use the remote administration tools (RDP or MMC). This whole story is directly riddled with successful actions, if you do not track them - it is difficult to understand who changed what and when.
Another example: you see a large number of events associated with a failed service account authorization in the domain. It’s great that you can track down failed attempts. It’s bad that you don’t understand why the attempts stopped: either the attacker still 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 propose focusing on the Domain Admins group (although these recommendations apply to all important security groups): you should monitor all changes in group membership, monitor both additions and deletions. Otherwise, you may not know that the attacker temporarily added himself to the Domain Admins, and after doing his thing - left.
Now let's talk about group policies. The wrong GP audit strategy can have dire consequences. For example, an attacker wants to conduct a phishing attack on workstations of your organization, but the current IE settings interfere or reduce the effectiveness of such an attack. A good option for an attacker would be to modify a GPO, a GPO.
Another example: an attacker needs to install malware on all the machines included in the domain. In this case, he can also effectively use group policies to create a new object.
Therefore, continuous monitoring of the GP plays an important role in protecting the infrastructure. You need to track the creation and modification of objects (GPOs), as well as object bindings (GPO links). You also need to know who initiated the change. AD monitoring can be set up relatively quickly if you use dedicated subnets for administrative tasks (recall Part 2). Instead of installing multiple filters on separate servers, IP addresses or containers / groups, you can monitor an entire subnet.
How to reduce the number of alerts?
Everyone 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 exist literally for any server software or equipment. At the moment when all these packages are installed and connected, the administrators are inundated with numerous alerts about “problems” in the infrastructure. As a result, admins stop responding to these alerts if everything is in order. And they start frantically viewing them only in case of incidents when one or several systems have already practically stopped working.
My strategy is quite simple: I look at the console of the monitoring system every time a problem occurs. I am trying to understand if the monitoring system gave us enough information to prevent an incident? Have alerts been sent to the right people? Often administrators receive alerts “by group”, i.e. not only about the systems that they serve, but also about colleagues. Even if admins see a notification, they will not respond, because "anyway, this department will be solved by another department."
To summarize , I propose three simple questions that will help reduce the number of alerts:
The original text of this note 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 a domain controller. The change was successful. In order to make the change, it was necessary to successfully log in to the domain. And then successfully use the remote administration tools (RDP or MMC). This whole story is directly riddled with successful actions, if you do not track them - it is difficult to understand who changed what and when.
Another example: you see a large number of events associated with a failed service account authorization in the domain. It’s great that you can track down failed attempts. It’s bad that you don’t understand why the attempts stopped: either the attacker still 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 propose focusing on the Domain Admins group (although these recommendations apply to all important security groups): you should monitor all changes in group membership, monitor both additions and deletions. Otherwise, you may not know that the attacker temporarily added himself to the Domain Admins, and after doing his thing - left.
Now let's talk about group policies. The wrong GP audit strategy can have dire consequences. For example, an attacker wants to conduct a phishing attack on workstations of your organization, but the current IE settings interfere or reduce the effectiveness of such an attack. A good option for an attacker would be to modify a GPO, a GPO.
Another example: an attacker needs to install malware on all the machines included in the domain. In this case, he can also effectively use group policies to create a new object.
Therefore, continuous monitoring of the GP plays an important role in protecting the infrastructure. You need to track the creation and modification of objects (GPOs), as well as object bindings (GPO links). You also need to know who initiated the change. AD monitoring can be set up relatively quickly if you use dedicated subnets for administrative tasks (recall Part 2). Instead of installing multiple filters on separate servers, IP addresses or containers / groups, you can monitor an entire subnet.
How to reduce the number of alerts?
Everyone 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 exist literally for any server software or equipment. At the moment when all these packages are installed and connected, the administrators are inundated with numerous alerts about “problems” in the infrastructure. As a result, admins stop responding to these alerts if everything is in order. And they start frantically viewing them only in case of incidents when one or several systems have already practically stopped working.
My strategy is quite simple: I look at the console of the monitoring system every time a problem occurs. I am trying to understand if the monitoring system gave us enough information to prevent an incident? Have alerts been sent to the right people? Often administrators receive alerts “by group”, i.e. not only about the systems that they serve, but also about colleagues. Even if admins see a notification, they will not respond, because "anyway, this department will be solved by another department."
To summarize , I propose three simple questions that will help reduce the number of alerts:
- Was there a reaction (action) on the part of administrators to the notification? If not, why? Is it possible to immediately extinguish such alerts? Will this affect working systems?
If so, immediately set up such alerts so that they do not come to administrators. - 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 notifications, add them and delete yourself. Only those responsible for it should receive alerts.
- Do you receive CMC alerts for non-critical incidents? (20% of free space is left on the disk) If yes, delete your number from the newsletter. SMS alerts should only come in case of serious incidents in a productive environment, otherwise you will stop responding adequately to them.
The original text of this note in English.