Correct Answers: A and B
One of the best features of a Security information and event management (SIEM) tool like Azure Sentinel is correlating important data and finding events that deserve your attention. The Anomalous RDP Login Detection rule does just that. Enabling this rule requires two prerequisites:
You should collect Security events or Windows Security Events with Event ID 4624. This is the event ID for an account successfully logging on to a machine/system. This covers many log in types, including RDP. Without this data, Azure Sentinel would be blind to RDP logins entirely. This process would be completed in the Security Events Data Connector or Windows Security Events (Preview) Data Connector pages within Azure Sentinel.
You should also select an event set other than None. This is a configuration step completed during the data connector implementation described above. This step ensures that the connector detailed in the above step is actually passing data. Options other than None include All events, Common, and Minimal. Although it may seem counterintuitive that there would even be a None event set, this can be used to disable a connector without deleting/removing it. This can be helpful in certain troubleshooting scenarios.
You should not create a data collection rule that includes Event ID 4720. This is the Event ID for the creation of a user account, not for logging on to a machine or system. While it may seem picky to expect a security professional to memorize exact event IDs, it is incredibly helpful to recognize some of the most common ones. Log ins (4624) and user creation (4720) are two that are very critical to know well in the event of conducting time sensitive research of a potential compromise and privilege escalation/account creation incident response (IR) scenario.
You should not let the machine learning algorithm collect 30 days` worth of Windows Security events data. This is, however, a very important time frame in regards to the time after you enable the rule. This rule relies on a machine learning algorithm that ultimately requires 30 days` worth of data before it can build a baseline. This baseline is a profile of your company`s normal user behavior, so you need to allow 30 days of Windows Security events data to be ingested before this rule will result in the discovery of any incidents. Remember, however, that the question only refers to the process to enable the rule and not the generation of incidents thereafter.
Finally, the actual process to enable the rule after these prerequisites are set is fairly simple. Starting in the Azure Sentinel portal, you will click Analytics, and then click the Rule templates tab.
Next, you must choose the (Preview) Anomalous RDP Login Detection rule and simply move the Status slider from Disabled (the default) to Enabled.
Reference:
https://docs.microsoft.com/en-us/azure/sentinel/connect-windows-security-events?tabs=LAA