Chapter 5. Implement threat detection solutions
Network administrators in today’s world must face a constant escalation of security threats, and one of the most difficult things about those threats is that they can easily occur without obvious signs of an attack. There are a variety of security tools available that monitor and record the condition of the network and alert administrators to unusual conditions that might indicate an attack in progress, which we’ll cover in this chapter.
Skills in this chapter:
Configure advanced audit policies
Install and configure Microsoft Advanced Threat Analytics
Determine threat detection solutions using Operations Management Suite
Skill 5.1: Configure advanced audit policies
In today’s business environment, enterprise administrators often devote a great deal of time, money, and effort into acquiring, deploying, and maintaining security technologies. In addition to these tasks, however, it is also important to ascertain the effectiveness of these technologies. One way of doing this is through auditing.
The auditing capabilities built into the Windows operating systems enable you to log successful and failed security events, such as logons, account accesses, and object accesses. You can use auditing to track both user activities and system activities. Planning to audit requires that you determine the computers to be audited and the types of events you want to track.
When you consider an event to audit, such as account logon events, you must decide whether to audit successful logon attempts, failed logon attempts, or both. Tracking successful events enables you to determine how often users access network resources. This information can be valuable when planning your resource usage and budgeting for new resources. Tracking failed events can help you determine when security breaches occur or are attempted. For example, if you notice frequent failed logon attempts for a specific user account, you might want to investigate the possibility of an attack.
When an audited event occurs, Windows writes an event to the Security log on the domain controller or the computer where the event took place. If it is a domain logon attempt or another Active Directory-related event, the event is written to the event log on the domain controller. If it is a computer event, such as a drive access, the event is written to the local computer’s event log. Planning an auditing policy for your organization is a matter of deciding which resources on your network you want to monitor and how you analyze the data collected by the auditing process.
This section covers how to:
Implement Auditing Using Group Policy and Auditpol.exe
Implement Auditing Using Windows PowerShell
Create Expression-Based Audit Policies
Configure the Audit PNP Activity Policy
Configure the Audit Group Membership Policy
Enable and Configure Module, Script Block, and Transcription Logging in Windows PowerShell
Determine the differences and usage scenarios for using local audit policies and advanced auditing policies
To create an effective auditing policy, you must decide which computers, resources, and events to audit. You should balance the need for auditing against the potential information overload that would be created if you audited every possible type of event. The basic steps involved in creating an auditing policy for your organization are as follows:
1. Identify the sensitive resources in your enterprise that are most in need of monitoring.
2. Identify the computer, user groups, and other objects that provide access to the sensitive resources you identified in step 1.
3. Select the audit policy settings that you can use to monitor the computers, groups, and other objects you identified in step 2.
4. Decide whether it is more beneficial to audit successes, failures, or both, for the auditing policy settings you have selected.
5. Create an audit policy deployment strategy, in which you decide how many Group Policy objects (GPOs) to use, which AD objects to link them to, and what audit policy settings to configure in each one.
6. Configure the size of your security logs based on the number of events that you anticipate logging. Consider also archiving your security logs to provide a documented history of your audits. Keeping a history of event occurrences can provide you with supporting documentation of resource usage and potential security breach attempts.
Note Configuring Event Log Settings
You can configure Event Log policy settings in the Computer ConfigurationWindows SettingsSecurity SettingsEvent Log container of any Group Policy object.
To implement an auditing policy on an Active Directory network, you define your desired policy settings in Group Policy objects (GPOs) and link them to domain, organizational unit (OU), or site objects. Part of the process of developing an archiving policy includes deciding whether to use local audit policies or advanced audit policies.
Each GPO contains two sets of audit policies: a basic one that has nine settings and an advanced one that has 60. The resources monitored by the two sets of policies overlap, but as you might imagine, the advanced audit policies provide more granular control over the events that are recorded in the Security log.
For example, the basic settings, located in the Computer ConfigurationPoliciesWindows SettingsSecurity SettingsLocal PoliciesAudit Policy container of a GPO, include an Audit Account Logon Events setting, as shown in Figure 5-1. Enabling this setting audits the success and/or failure of all logon attempts.
The advanced settings, located in the Computer ConfigurationPoliciesWindows SettingsAdvanced Audit Policy Configuration container of a GPO, includes four Account Logon settings, as shown in Figure 5-2. These settings distinguish between credential validations, Kerberos authentication activities, and other account logon events. These four advanced settings, combined, are the equivalent of the one basic Account Logon Events setting.
One of the mistakes that many administrators make at first is auditing too much, assuming that more data is always better. Some of the audit policy settings can generate enormous amounts of data, which can quickly fill up your Security logs, place an undue burden on the computers doing the auditing, and provide far more information that the administrators can practically process.
For example, if you want to audit the read accesses to a file or folder, make sure you audit the Read events, not Full Control. Auditing Full Control triggers writes to the log for every action on the file or folder. Auditing uses system resources to process and store events. Therefore, auditing unnecessary events creates overhead on your server and makes it difficult to monitor the logs. The advanced audit policy settings enable you to be more selective in the events and resources you choose to audit, keeping your logs more manageable in the process.
Basic audit policies
Deciding whether to use basic or advanced audit policies requires an understanding of the types of information each policy setting audits. The basic audit policy settings are as follows:
Audit Account Logon Events Logs events related to successful user logons to a domain. The events are logged to the domain controller that processes the request.
Audit Account Management Logs events related to user or group account creation, deletion, renaming, enabling, or disabling.
Audit Directory Service Access Logs user attempts to access Active Directory objects, such as users or OUs, which have system access control lists (SACLs) specified. To generate a log entry for a specific object, a user specified in the SACL must attempt to access the object using one of the permissions granted to that user in the SACL.
Audit Logon Events Logs events related to user logons on a member server or workstation computer. The events are logged on the computer that processes the request.
Audit Object Access Logs user attempts to access non-Active Directory objects, such as files, folders, registry keys, and printers, which have system access control lists (SACLs) specified. To generate a log entry for a specific object, a user specified in the SACL must attempt to access the object using one of the permissions granted to that user in the SACL.
Audit Policy Change Logs events such as user rights assignment changes, establishment or removal of trust relationships, IPsec policy agent changes, and granting or removal of system access privileges.
Audit Privilege Use Logs each instance of a user attempting to exercise user rights. Several user rights are excluded from the settings because they would generate a great many logged events if audited.
Audit Process Tracking Logs process-related events, such as process creation, process termination, handle duplication, and indirect object access.
Audit System Events Logs events such as system startups and shutdowns; system time changes; system event resources exhaustion, such as when an event log is filled and can no longer append entries; security log cleaning; or any event that affects system security or the Security log.
The basic audit policy settings can generate a large number of event log entries, because they are less granular, making it more difficult to analyze the Security log.
Advanced audit policies
The Advanced Audit Policy Configuration folder in a GPO contains ten categories that contain several settings each. Many of the categories correspond to the basic audit settings, but split the auditing capabilities among multiple settings. This enables you to configure an audit policy similar to that of the basic settings, but with greater specificity. You can some of the settings in a category to log successes or failures, while leaving other settings unconfigured. You can also mix configurations within a category by auditing successes for some settings and failures for others.
The advanced audit policy categories are as follows:
Account Logon Contains settings that audit authentication activities based on the account databases the activities use. For example, you can configure settings that audit only Kerberos authentications or only Security Account Manager (SAM) authentications.
Account Management Contains individual settings that enable you to audit changes to user accounts, computer accounts, and each type of group separately.
Detailed Tracking Contains settings that audit specific application and user activities, including Data Protection Application Programming Interface (DPAPI) encryption and decryption, Plug-and-Play hardware detection, process creation and termination, and incoming Remote Procedure Call (RPC) connections.
DS Access Contains settings that audit attempts to access, replicate, and modify Active Directory Domain Services objects. All events generated by these settings are logged on domain controllers.
Logon/Logoff Contains settings that audit individual aspects of interactive and network logon and logoff activities, including account lockouts, IPsec connections, and Network Policy Server connections.
Object Access Contains separate settings that audit attempts to access specific objects or object types, including files, shares, certificates, handles, kernel objects, registry settings, removable storage, and SAM accounts, which have system access control lists (SACLs) specified. To generate a log entry for a specific object, a user specified in the SACL must attempt to access the object using one of the permissions granted to that user in the SACL.
Policy Change Contains settings that audit changes to individual types of security policies, including audit, authentication, authorization, Windows Filtering Platform (WFP), and Microsoft Protection Service (MPSSVC) policies.
Privilege Use Contains settings that audit the use of sensitive and non-sensitive permissions by the users and computers to which they have been assigned.
System Contains settings that audit security-related system changes not included in other categories, including IPsec driver, security state, and system integrity modifications.
Global Object Access Auditing Contains settings that enable you to configure and apply global SACLs to all file system or registry objects. Unlike other audit policy settings, these two include an Advanced Security Settings dialog box in which you create auditing entries, as shown in Figure 5-3. If a file, folder, or registry setting has an SACL applied to it individually, the permissions in the individual SACL are combined with those in the global SACL.
Note Confirming Object Auditing
One of the prominent maintenance issues in Windows auditing has always been the inability to determine which objects have correct SACLs applied to them, except by viewing each object individually. Global object access auditing makes it possible for administrators to confirm that all elements are appropriately configured with SACLs by viewing the Advanced Security Settings dialog box associated with the policy setting.
Windows Server 2016 has some of the advanced auditing policies applied to it by default. You cannot view the existing audit policy settings in the Group Policy objects, but you can display them by running the Auditpol.exe program from the command prompt. Listing 5-1 displays an Auditpol.exe output containing the default audit policy settings for a Windows Server 2016 domain controller.
LISTING 5-1 The default Advanced Audit Policy Configuration settings for a Windows Server 2016 domain controller
Category/Subcategory System Setting
Security System Extension No Auditing
System Integrity Success and Failure
IPsec Driver No Auditing
Other System Events Success and Failure
Security State Change Success
Logon/Logoff
Logon Success and Failure
Logoff Success
Account Lockout Success
IPsec Main Mode No Auditing
IPsec Quick Mode No Auditing
IPsec Extended Mode No Auditing
Special Logon Success
Other Logon/Logoff Events No Auditing
Network Policy Server Success and Failure
User / Device Claims No Auditing
Group Membership No Auditing
Object Access
File System No Auditing
Registry No Auditing
Kernel Object No Auditing
SAM No Auditing
Certification Services No Auditing
Application Generated No Auditing
Handle Manipulation No Auditing
File Share No Auditing
Filtering Platform Packet Drop No Auditing
Filtering Platform Connection No Auditing
Other Object Access Events No Auditing
Detailed File Share No Auditing
Removable Storage No Auditing
Central Policy Staging No Auditing
Privilege Use
Non Sensitive Privilege Use No Auditing
Other Privilege Use Events No Auditing
Sensitive Privilege Use No Auditing
Detailed Tracking
Process Creation No Auditing
Process Termination No Auditing
DPAPI Activity No Auditing
RPC Events No Auditing
Plug and Play Events No Auditing
Policy Change
Authentication Policy Change Success
Authorization Policy Change No Auditing
MPSSVC Rule-Level Policy Change No Auditing
Filtering Platform Policy Change No Auditing
Other Policy Change Events No Auditing
Audit Policy Change Success
Account Management
User Account Management Success
Computer Account Management Success
Security Group Management Success
Distribution Group Management No Auditing
Application Group Management No Auditing
Other Account Management Events No Auditing
DS Access
Directory Service Changes No Auditing
Directory Service Replication No Auditing
Detailed Directory Service Replication No Auditing
Directory Service Access Success
Account Logon
Kerberos Service Ticket Operations Success
Other Account Logon Events No Auditing
Kerberos Authentication Service Success
Credential Validation Success
Audit policy priorities
The basic set of local audit policy settings are included in all Group Policy objects, and in the Local Security Policy tool on every computer. This means that you can configure the basic settings on an individual computer or deploy them to a large number of computers using Group Policy in Active Directory.
The advanced audit policies are only provided in Group Policy objects, so you can only deploy them that way. The basic and advanced audit policies are not compatible with each other. If you configure advanced audit settings in a GPO, any existing basic audit settings are cleared on a computer before the advanced settings are applied. Choosing between the basic and advanced audit policy settings is essentially a matter of how granular you want your auditing to be.
Operating system versions
The basic auditing policies were introduced in Windows 2000, and are therefore applicable to any server or workstation computers running Windows 2000 or later. The advanced auditing policy settings were only introduced in Windows Server 2008 and Windows 7. You can therefore apply those settings only to computers running those operating systems or later.
If you have Windows computers running old and new operating systems on your network, you can place them in separate OUs and create individual GPOs with basic settings for the older operating systems and advanced settings for the newer ones. You can also create a single GPO that contains both basic and advanced audit policy settings, keeping in mind that the older operating systems ignore the advanced settings and the newer ones do not apply the basic settings.
Implement auditing using Group Policy and Auditpol.exe
The best way to implement auditing on computers throughout a network is to deploy the desired settings using Group Policy. By configuring the audit policy settings you want to use in a Group Policy object, you can link the GPO to any domain, site, or organizational unit (OU) object in your Active Directory installation. All of the computers contained in the object to which you have linked the GPO receives and applies the audit policy settings the next time they restart.
The assumption here is that you have already decided what audit policies you intend to deploy and what computers on your network should receive them. Based on these decisions, your audit policy deployment might consist of a single GPO applied to an entire domain, or many GPOs with different auditing configurations, linked to various OUs.
Note Audit Management Prerequisites
To set up and administer an audit policy, you must possess the Manage Auditing and Security Log user right for the computer on which you want to configure a policy or review a log. This right is granted by default to the Administrators group. However, to delegate this task to another user, such as a container administrator, that person must possess the specific right. In addition, any files or folders to be audited must be located on NTFS volumes.
Creating a new auditing GPO
To create a new GPO and configure it to deploy advanced audit policy settings, use the following procedure:
1. Log on to a domain controller using an account with domain Administrator privileges.
2. Open the Group Policy Management console, expand the forest container, and browse to your domain.
3. Expand the domain container, right-click the Group Policy Objects folder and, in the context menu, select New. The New GPO dialog box appears.
4. Create a new GPO with an appropriate name.
5. Right-click the new GPO and click Edit. A Group Policy Management Editor window for this policy appears.
6. Browse the Computer ConfigurationPoliciesWindows SettingsSecurity SettingsAdvanced Audit Policy ConfigurationAudit Policies container. The audit policy categories appear.
7. Select a category and double-click one of the subcategory settings in the right pane. The Properties sheet for the policy you chose appears, as shown in Figure 5-4.
8. Select the Configure the Following Audit Events check box.
9. Select the appropriate check box(es) to audit Success events, Failure events, or both.
10. Click OK to close the setting’s Properties sheet.
11. Repeat steps 7 to 10 to configure additional policy settings.
12. Close the Group Policy Management Editor console.
13. In the Group Policy Management console, browse to the domain, site, or OU object containing the computers you want to configure.
14. Right-click the object and, from the context menu, select Link To An Existing GPO. The Select GPO dialog box appears, as shown in Figure 5-5.
15. Select the GPO you just created and configured and click OK.
16. Close the Group Policy Management console.
Auditing objects
When you enable policy settings that cause a system to audit objects, such as file system elements, registry settings, and Active Directory objects, you must configure the system access control lists (SACLs) for the objects you want to audit.
For example, if you enable the Audit File System setting in the Object Access category, not Security log, events are generated until you configure the SACLs for the files or folders you want to audit. If you add the Trainee group to the SACL for a folder called Spreadsheets and grant it the Read permission, then a Security log event is generated every time a member of the Trainee group reads a file in the Spreadsheets folder. Users who are not members of the Trainee group are be audited when they access the Spreadsheets folder. Members of the Trainee group are not audited when they access files not in the Spreadsheets folder.
To configure the SACLs on file system objects, use the following procedure:
1. Log on to a domain controller, using an account with domain Administrator privileges.
2. Open File Explorer, browse to the file or folder you want to audit, and open its Properties sheet.
3. Click the Security tab, and then click Advanced. The Advanced Security Settings dialog box appears.
4. Click the Auditing tab, and then click Continue to confirm your administrative access.
5. Click Add. The Auditing Entry page appears.
6. Click Select a Principal. The Select User, Computer, Service Account, or Group dialog box appears. Specify the users or groups to be audited and click OK. The users or groups appear in the Auditing Entry dialog box for the object.
7. From the Type drop-down list, specify whether you want to audit failures, successes, or both.
8. Select the basic permissions you want to audit for this object and click OK. The new Auditing entry appears in the Advanced Security Settings dialog box, as shown in Figure 5-6.
9. Create additional auditing entries, if desired, and click OK.
10. Click OK to close the object’s Advanced Security Settings dialog box.
11. Click OK to close the object’s Properties sheet.
12. Close the File Explorer window.
The process of configuring SACLs for registry settings and Active Directory objects is roughly the same as for file system elements. All of the objects have Properties sheets with a Security tab, which provides access to an Advanced Security Settings dialog box. The difference between the object types is the permissions that you can select for an SACL. For example, the Auditing Entry dialog box for an organizational unit object in Active Directory has many more permissions to choose from than a file, as shown in Figure 5-7.
As noted earlier, the policy settings in the Global Object Access Auditing category provide a means of adding permissions to SACLs for all of the file system objects or registry settings on a computer, rather than configuring each object individually. These policies are only applicable for certain uses, however. For example, if you were to configure the SACLs of all the files on a computer with the Read permission for the Domain Users group, the system would add an enormous number of events to the Security log. However, if you wanted to monitor all of the files deleted by your organization’s new hires, you could use Global Object Access Auditing to grant the Delete permission to the Trainee group for all of your file system objects.
Using auditpol.exe
Auditpol.exe is a command prompt utility that you can use to configure audit policy settings directly on a computer or from a script. Auditpol does not modify the settings in a Group Policy object; it applies changes to the actual operating environment of the computer on which you run it.
The basic syntax of Auditpol.exe is as follows:
Auditpol.exe command subcommand options
The commands you can use with Auditpol.exe are as follows:
/get Displays the currently operational audit policies
/set Configures currently operational audit policies
/list Displays the audit policy elements available for selection
/backup Saves the current audit policies to a file
/restore Restores audit policies to the current environment from a file
/clear Clears the currently operational audit policies
/remove Removes per-user audit policies
/resourceSACL Creates SACLs for global object access auditing
To enable a specific audit policy setting using Auditpol.exe, you use the /set command. The subcommands used with the /set command are as follows:
/category:categoryname Specifies one of the nine audit policy categories, either by name or by globally unique identifier (GUID). When you specify a category on the command line with no subcategory, Auditpol configures all of the policy settings in that category.
/subcategory:subcategoryname Specifies one of the available audit policy settings, either by name or by GUID.
/success:enable Configures the specified policies for success auditing. This is the default if the command line lacks both the /success and the /failure options. The /success:disable parameter prevents the policies from performing success auditing.
/failure:enable Configures the specified policies for failure auditing. The /failure:disable parameter prevents the policies from performing failure auditing.
Therefore, an example of an Auditpol command that would configure a system to audit all failed logon attempts would be as follows:
auditpol /set /subcategory:"logon" /failure:enable
When specifying categories or subcategories on the command line, you must use the correct name or substitute a GUID. To display the correct names and GUIDs for the audit policy settings, you can use the following command:
auditpol /list /subcategory:* /v
Auditpol.exe supports the use of wildcard characters in the /category and /subcategory parameters. The /v parameters (for verbose) causes the program to list the GUIDs as well as the names of the categories and subcategories. Listing 5-2 shows the output of this command.
LISTING 5-2 The category and subcategory names for Advanced Audit Policy Configuration settings, with GUID values
Category/Subcategory,GUID
System,{69979848-797A-11D9-BED3-505054503030}
Security State Change,{0CCE9210-69AE-11D9-BED3-505054503030}
Security System Extension,{0CCE9211-69AE-11D9-BED3-505054503030}
System Integrity,{0CCE9212-69AE-11D9-BED3-505054503030}
IPsec Driver,{0CCE9213-69AE-11D9-BED3-505054503030}
Other System Events,{0CCE9214-69AE-11D9-BED3-505054503030}
Logon/Logoff,{69979849-797A-11D9-BED3-505054503030}
Logon,{0CCE9215-69AE-11D9-BED3-505054503030}
Logoff,{0CCE9216-69AE-11D9-BED3-505054503030}
Account Lockout,{0CCE9217-69AE-11D9-BED3-505054503030}
IPsec Main Mode,{0CCE9218-69AE-11D9-BED3-505054503030}
IPsec Quick Mode,{0CCE9219-69AE-11D9-BED3-505054503030}
IPsec Extended Mode,{0CCE921A-69AE-11D9-BED3-505054503030}
Special Logon,{0CCE921B-69AE-11D9-BED3-505054503030}
Other Logon/Logoff Events,{0CCE921C-69AE-11D9-BED3-505054503030}
Network Policy Server,{0CCE9243-69AE-11D9-BED3-505054503030}
User / Device Claims,{0CCE9247-69AE-11D9-BED3-505054503030}
Group Membership,{0CCE9249-69AE-11D9-BED3-505054503030}
Object Access,{6997984A-797A-11D9-BED3-505054503030}
File System,{0CCE921D-69AE-11D9-BED3-505054503030}
Registry,{0CCE921E-69AE-11D9-BED3-505054503030}
Kernel Object,{0CCE921F-69AE-11D9-BED3-505054503030}
SAM,{0CCE9220-69AE-11D9-BED3-505054503030}
Certification Services,{0CCE9221-69AE-11D9-BED3-505054503030}
Application Generated,{0CCE9222-69AE-11D9-BED3-505054503030}
Handle Manipulation,{0CCE9223-69AE-11D9-BED3-505054503030}
File Share,{0CCE9224-69AE-11D9-BED3-505054503030}
Filtering Platform Packet Drop,{0CCE9225-69AE-11D9-BED3-505054503030}
Filtering Platform Connection,{0CCE9226-69AE-11D9-BED3-505054503030}
Other Object Access Events,{0CCE9227-69AE-11D9-BED3-505054503030}
Detailed File Share,{0CCE9244-69AE-11D9-BED3-505054503030}
Removable Storage,{0CCE9245-69AE-11D9-BED3-505054503030}
Central Policy Staging,{0CCE9246-69AE-11D9-BED3-505054503030}
Privilege Use,{6997984B-797A-11D9-BED3-505054503030}
Sensitive Privilege Use,{0CCE9228-69AE-11D9-BED3-505054503030}
Non Sensitive Privilege Use,{0CCE9229-69AE-11D9-BED3-505054503030}
Other Privilege Use Events,{0CCE922A-69AE-11D9-BED3-505054503030}
Detailed Tracking,{6997984C-797A-11D9-BED3-505054503030}
Process Creation,{0CCE922B-69AE-11D9-BED3-505054503030}
Process Termination,{0CCE922C-69AE-11D9-BED3-505054503030}
DPAPI Activity,{0CCE922D-69AE-11D9-BED3-505054503030}
RPC Events,{0CCE922E-69AE-11D9-BED3-505054503030}
Plug and Play Events,{0CCE9248-69AE-11D9-BED3-505054503030}
Policy Change,{6997984D-797A-11D9-BED3-505054503030}
Audit Policy Change,{0CCE922F-69AE-11D9-BED3-505054503030}
Authentication Policy Change,{0CCE9230-69AE-11D9-BED3-505054503030}
Authorization Policy Change,{0CCE9231-69AE-11D9-BED3-505054503030}
MPSSVC Rule-Level Policy Change,{0CCE9232-69AE-11D9-BED3-505054503030}
Filtering Platform Policy Change,{0CCE9233-69AE-11D9-BED3-505054503030}
Other Policy Change Events,{0CCE9234-69AE-11D9-BED3-505054503030}
Account Management,{6997984E-797A-11D9-BED3-505054503030}
User Account Management,{0CCE9235-69AE-11D9-BED3-505054503030}
Computer Account Management,{0CCE9236-69AE-11D9-BED3-505054503030}
Security Group Management,{0CCE9237-69AE-11D9-BED3-505054503030}
Distribution Group Management,{0CCE9238-69AE-11D9-BED3-505054503030}
Application Group Management,{0CCE9239-69AE-11D9-BED3-505054503030}
Other Account Management Events,{0CCE923A-69AE-11D9-BED3-505054503030}
DS Access,{6997984F-797A-11D9-BED3-505054503030}
Directory Service Access,{0CCE923B-69AE-11D9-BED3-505054503030}
Directory Service Changes,{0CCE923C-69AE-11D9-BED3-505054503030}
Directory Service Replication,{0CCE923D-69AE-11D9-BED3-505054503030}
Detailed Directory Service Replication,{0CCE923E-69AE-11D9-BED3-505054503030}
Account Logon,{69979850-797A-11D9-BED3-505054503030}
Credential Validation,{0CCE923F-69AE-11D9-BED3-505054503030}
Kerberos Service Ticket Operations,{0CCE9240-69AE-11D9-BED3-505054503030}
Other Account Logon Events,{0CCE9241-69AE-11D9-BED3-505054503030}
Kerberos Authentication Service,{0CCE9242-69AE-11D9-BED3-505054503030}
Quick check
If you create a Group Policy object that contains both basic and advanced audit policy settings, and you deploy it to an entire domain, what are the effective policies on a computer running Windows 10? On a computer running Windows XP?
Quick check answer
On the computer running Windows 10, any basic auditing policies on the computer would be cleared, and the basic policy settings in the GPO would be ignored. On the computer running Windows XP, the advanced auditing policy settings in the GPO would be ignored, and the basic policy settings applied.
Implement auditing using Windows PowerShell
The native capabilities of Windows PowerShell are limited when it comes to security auditing. You can run Auditpol.exe from a PowerShell prompt, but there are no cmdlets you can use to configure audit policy settings, either directly or in GPOs. However, when you are using Object Access policy settings, you can use PowerShell to configure SACLs for specific objects.
The Get-Acl cmdlet displays the security descriptor for an object, such as a file, folder, or registry key. The security descriptor contains all of the object’s access control lists (ACLs), including the SACL. The syntax for a simple Get-Acl command is as follows:
Get-acl -path filename -audit | format-list
path Specifies the object whose security descriptor you want to display. The -path parameter can specify a folder name, a full path to a specific file, or a location in the registry. Wildcard characters are allowed.
audit Causes the cmdlet to display the SACL information in the security descriptor.
FormatList This is not a parameter, but rather another cmdlet that presents the output of the GetAcl cmdlet in a more readable manner, as shown in Figure 5-8. When you run GetAcl without piping the output to Format-List, the output is displayed as a table in which long values are truncated.
By itself, Get-Acl is interesting and even useful, but its greatest value appears when you use it with the Set-Acl cmdlet, which adds a security descriptor to an object. Using these two cmdlets in combination, you can copy the security descriptor, including the SACL, from one object to another.
By piping the output of Get-Acl for one file to Set-Acl, specifying another file, you can copy the entire security descriptor from one to the other. The command would appear as in the following example:
Get-acl -path "c:docsoldfile.txt" -audit | set-acl -path "c:docs ewfile.txt"
You can also achieve the same result by saving the Get-Acl output to a variable and feeding it to Set-Acl, as in the following example:
$oldsacl = get-acl -path "c:docsoldfile.txt" -audit
Set-acl -path "c:docs
ewfile.txt" -aclobject $oldsacl
Note Copying Sacls With Powershell
To replicate the SACL from one file to another using this technique, be sure to include the audit parameter in the Get-Acl command. If you do not, GetAcl does not include the SACL in its output, so it is not copied to the other file.
Create expression-based audit policies
When you create audit policies to monitor file system elements of registry settings, you use SACLs to specify which elements you want to monitor. You can, for example, monitor access to specific files by specific users or groups. Expression-based audit policies expand this capability by enabling you to specify additional criteria for auditing. Instead of selecting specific files or folders for auditing, you can select documents for auditing based on attributes you have previously defined, such as the country or department with which the documents are associated.
The interface for defining the conditions under which files are audited is part of the Auditing Entry dialog box found in the Global Object Access Auditing policy settings, as well as individual file system elements. For example, using Global Object Access Auditing, you can create a policy that generates audit events for all files from the Finance department that have been modified, or all files from a particular country. You create your own criteria for the expressions using Dynamic Access Control (DAC).
To create an expression-based audit policy, use the following procedure:
1. Open a GPO in the Group Policy Management Editor console.
2. Configure the File System policy in the Global Object Access Auditing category.
3. Open the Advanced Security Settings dialog box.
4. Add an auditing entry.
5. Select a principal.
6. Choose whether to audit Success or Failure.
7. Select the permissions you want to monitor.
8. Click Add a Condition.
At this point, a series of drop-down lists appears at the bottom of the dialog box, with which you can create an expression that limits the scope of the audit policy. The values that appear in the drop-down lists are based on the claim types and resource properties that you configure in Dynamic Access Control. You can create multiple expressions, and the interface provides Boolean operators you can use to control the evaluation of the expressions, as shown in Figure 5-9.
Configure the audit PNP activity policy
Social engineering is a major threat to network security. One of the most common attack vectors associated with social engineering practices is the use of external data storage devices, such as USB flash drives. An attacker provides a user with a document conveniently stored on a flash drive, and when the user inserts it into his or her computer, the system can be compromised by any sort of malware.
In versions prior to Windows Server 2016 and Windows 10, an event log entry was created the first time a user inserted a particular USB device. The log entry identified the device and recorded its first use. However, the system did not create additional log entries when the device was removed and re-inserted.
Windows Server 2016 and Windows 10 have a new audit policy setting that addresses this shortcoming. The Audit PNP Activity policy, found in the Detail Tracking category, generates an event in the Security log each time Plug and Play (PNP) detects the connection of an external device of any type. The policy even generates a new event each time a user connects the same device to the system.
The value of this policy is that administrators can correlate the insertion of a PNP device with other activities on the system. For example, when the introduction of a malware infection is detected on a system at a particular time, a Security log entry recording the insertion of a USB flash drive at approximately the same time can indicate the malware’s avenue of ingress.
The Audit PNP Activity policy setting in a GPO, shown in Figure 5-10, has the same appearance as most other policy settings, but there is a difference in how the system employs it. Despite having checkboxes for both Success and Failure auditing, the policy does not record Failure events, so selecting the failure checkbox has no effect.
Configure the Audit Group Membership policy
One of the most commonly used audit policies is Audit Logon, which tracks the users who log on to a system by generating events in the Security log. This policy enables administrators to monitor and record who accesses a particular system. There is also another policy in the Logon/Logoff category that can provide additional information for this analysis.
The Audit Group Membership policy generates event log entries that list the group memberships of the users that log on to the computer. For an interactive logon, the events are created on the local system. For a network logon, such as a connection to a shared folder, the events are created on the system hosting the resource.
The events generated by the Audit Group Membership policy contain a list of both the local and domain groups to which the logged on user belongs. If the list of groups is too long for one event, the system creates multiple events.
The value of this policy derives from the ability to see which groups have members logging on to a particular computer. In the case of a privileged access workstation, for example, you can use this auditing policy to confirm that all of the users logging on to the workstation belong to the proper group.
As with the Audit PNP Activity policy, the Audit Group Membership policy only audits successes, despite its having a Failure checkbox on its Properties sheet. To enable the policy, you must configure it in a GPO in the normal manner, and you must enable the Audit Logon policy as well.
Enable and configure module, script block, and transcription logging in Windows PowerShell
Windows PowerShell has its own logging capabilities, separate from those of the Windows auditing policies. Starting with Windows PowerShell 5.0, first released in Windows Server 2008 R2, Windows 7, and Windows Management Framework (WMF) 5.0, PowerShell has enhanced logging capabilities that records commands and scripts, output, code blocks, and transcripts of sessions.
To enable and configure the logging capabilities of Windows PowerShell, you Group Policy settings found in the Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsWindows PowerShell folder in any GPO. The policy settings that apply to logging are as follows:
Turn On Module Logging Records pipeline execution events for the specified modules in the Windows PowerShell event log. Module logging might not record all of the commands issued in a session, but it can capture details that the other logging options do not. When you enable the policy, as shown in Figure 5-11, you can click the Show button to specify the modules you want to log, or insert an asterisk (*) to log all modules. Module logging can generate a large number of events, so you should configure your maximum log size accordingly. This policy is the functional equivalent of setting the LogPipelineExecutionDetails property for a module to True. This policy is also present in the User Configuration folder of a GPO, but the Computer Configuration setting takes precedence.
FIGURE 5-11 The Turn On Module Logging Properties sheet
Turn On PowerShell Script Block Logging Records blocks of code as the PowerShell engine executes them, including commands and scripts. This policy can record code obfuscated with Base64, XOR, ROT13, or encryption, and includes the unobfuscated code as well. However, script block logging does not record the output generated by the executed code. Logs are recorded as events in the Windows PowerShell event log. For long script blocks, two or more event log entries might be required.
Note Logging Suspicious Code
Windows PowerShell automatically logs blocks of code that contain suspicious commands or scripts, even if you do not enable the Turn On PowerShell Script Block Logging policy. These event log entries are flagged with a Warning status, while the entries generated by the enabled policy are flagged as Information or Verbose. If you explicitly disable the policy, no code blocks are recorded to the log, including suspicious ones.
Turn On PowerShell Transcription Creates text transcriptions of every PowerShell session, including all of the input and output visible on the PowerShell terminal. A transcript does not include output resulting from executed scripts or written to other destinations. By default, transcripts are saved as unique, timestamped files with names that begin with “PowerShell_transcript” in the user’s Documents folder. When you enable the policy, you can specify an alternative location for the transcript files, as shown in Figure 5-12. Saving the transcript files to a write-only share on a remote computer is a recommended practice, to prevent attackers from deleting them. Selecting the Include Invocation Headers checkbox causes the transcripts to include a timestamp for each executed command. In addition to enabling transcription using Group Policy, you can also manually begin and end a transcript from the PowerShell command prompt, using the Start-Transcript and Stop-Transcript cmdlets.
Skill 5.2: Install and configure Microsoft Advanced Threat Analytics
Microsoft Advanced Threat Analytics (ATA) is a security product that helps to protect an enterprise network from advanced forms of cyberattack. ATA gathers information from Windows logs and uses deep packet inspection techniques to evaluate trends in network traffic to and from domain controllers and the behavior of users, devices, and resources. This way, ATA can detect suspicious activity generated by the various phases of an attack and generate alerts that specify the type of attack that might be in progress and the systems that are involved.
When you first install ATA, it detects evidence of known attack types immediately. Then, in a matter of weeks, ATA begins to recognize the normal behavior of your network and is able to detect suspicious deviations from the norm.
This section covers how to:
Determine Usage Scenarios for ATA
Determine Deployment Requirements for ATA
Install and Configure ATA Gateway on a Dedicated Server
Install and Configure ATA Lightweight Gateway Directly on a Domain Controller
Configure Alerts in ATA Center When Suspicious Activity Is Detected
Review and Edit Suspicious Activities on the Attack Time Line
Determine usage scenarios for ATA
ATA is designed to detect activity in the various phases of what some cybersecurity experts refer to as the kill chain. Originally a military term, the kill chain represents the stages of an attack, from the initial reconnaissance to the attacker’s final actions on the compromised plan. ATA analysis of the data it collects from domain controller traffic and event logs can alert you to activities occurring at any phase of the kill chain.
Some of the most critical phases of an attack that are detectable by ATA are described in the following sections.
Reconnaissance
In a military kill chain, reconnaissance is the selection of a vulnerable target. The same is true in a cybersecurity kill chain. Attackers attempt to identify user accounts that might be susceptible to attack by using various techniques.
These techniques can include sending false requests to a domain controller, to determine if a specific user exists, to obtain a list the users involved in active Server Message Blocks (SMB) sessions, or to obtain Domain Name System (DNS) information. All of these techniques can provide an attacker with the names and IP addresses of active user accounts.
ATA can detect the request messages that attackers use to gather these types of information, and recognize them for what they are.
Compromised credentials
There are various network traffic patterns that can indicate attempts to compromise account credentials or utilize credentials that have already been compromised. ATA uses traffic and behavioral analysis to detect unusual activity that emulates well-known attack techniques.
For example, ATA can recognize when an account displays anomalous resource access patterns, logins during non-working hours, and abnormal numbers of logins. These phenomena can indicate that an account has already been compromised, and the attacker is attempting to make use of it.
ATA can also detect potentially compromising communications, such as passwords transmitted in plain text, and attempts to compromise credentials with brute force methods and authentication requests that don’t conform to the normal protocol.
ATA can also make use of a specialized dummy account called a honey token. This is an unused user account that serves as a lure and a trap for attackers. Any activity occurring that uses the honey token account is certain to be illicit, and ATA can gleam a great deal from the attempts to use that account.
Lateral movement
Lateral movement is an attempt by an attacker in possession of stolen credentials to gain access to other resources using those credentials. ATA detects these attempts by examining account traffic patterns, looking for signs of connections to unusual resources, logons from different workstations, or the use of abnormal devices.
ATA also examines Kerberos and NTLM authentication traffic, looking for signs of common intrusion techniques in which attackers use illicitly obtained Kerberos ticket-granting tickets (TGTs) or NTLM hashes to access additional resources. Attacks like Pass-the-Ticket and Pass-the-Hash are some of the most commonly used means of compromising user account credentials today, and ATA detects them by analyzing not just the packets themselves, but the way in which they are used.
Privilege escalation
Attackers in possession of stolen credentials might try to increase the privileges of those credentials by altering Kerberos TGTs to grant themselves additional permissions. A TGT contains an authorization header that specifies the permissions granted to the user account. By altering this header, the attacker can conceivably use an account that is relatively unprivileged to access highly sensitive resources. ATA can detect these attempts by examining the network packets containing the TGTs for alterations and by analyzing the differences in the ways that the account is being used.
Domain dominance
ATA can detect attackers that attempt to compromise a domain controller directly by posing as another domain controller. By spoofing an authentication ticket encrypted and signed by the KRBTGT service account on a domain controller (also known as the Kerberos Golden Ticket), the attacker can be confirmed as another domain controller, and can then issue TGTs for any resource, request replication of the Active Directory database, and remotely execute code on the domain controller computer.
Determine deployment requirements for ATA
ATA is a wholly on-premise product that does not require cloud resources. It is a standalone product that gathers information from the domain controllers in your enterprise, stores it, and analyzes it for potential threats.
ATA Center
The focal point of the Ata product is a dedicated server known as the ATA Center. This computer is the receiver of the information gathered from your domain controllers, and the place where the threat analysis occurs. The ATA Center performs the following functions:
ATA Gateway configuration Manages the configuration settings for ATA gateways and ATA Lightweight Gateways.
Data storage Uses MongoDB to store all ATA configuration data, information received from gateways, network activity behavior, and threat analysis results.
Threat analysis Parses and analyzes network traffic, analyzes the network’s default behavior patterns, detects well-known attack behaviors.
ATA Console hosting Uses Internet Information Services (IIS) to host the ATA Console intranet site, which provides an ATA configuration interface and displays the results of ATA’s threat analyses.
Alert generation Creates emails and system events to notify administrators when ATA detects suspicious activity.
In most cases, one ATA Center computer can service an entire Active Directory forest. If your enterprise consists of multiple forests, you need one ATA center for each one. In the case of especially large forests, more than one ATA center might be required. Microsoft provides a sizing tool that you can use to determine the correct ATA installation for your enterprise, based on the packet transmission rates of your domain controllers.
The computer that functions as the ATA Center should have two IP addresses on the same subnet, and Internet Information Services (IIS) must be installed. One of the addresses is used to communicate with the network (receive the traffic from the gateways) and one is for IIS, to host the ATA Console.
ATA Gateways
The ATA Center receives the information it uses to perform its analyses from ATA gateways on your network. ATA supports two types of gateways, as follows:
ATA Gateway Runs on a standalone server and gathers information from domain controllers using port mirroring and event forwarding
ATA Lightweight Gateway Runs on a domain controller itself and gathers information locally
Both gateway types perform many of the same functions, including the following:
Capture network traffic transmitted to and from domain controllers
Receive Windows Event information through Windows Event Forwarding
Access Active Directory user and computer object information
Transfer all gathered information to the ATA Center
The standalone ATA Gateway can service multiple domain controllers, up to a maximum of 50,000 packets per second of domain controller traffic. You can install multiple ATA gateways on a network, if more capacity is required. Apart from its capacity, the standalone gateway provides a security advantage; because it is separate from the domain controllers, potential attackers have a harder time learning that ATA is installed on the network. The main disadvantage is that the standalone ATA Gateway requires a server, and a server license, of its own.
ATA Lightweight Gateways service only the domain controllers on which they are installed, and support up to 10,000 packets per second. ATA Lightweight Gateways continually monitor the CPU and memory utilization on the domain controllers where they are running, and throttle their resource usage to ensure that the native functions of the domain controller are not affected.
Less expensive, because a separate server is not required, ATA Lightweight Gateways are an ideal solution for branch offices and cloud-based virtual domain controllers.
Administrators are free to mix ATA Gateways and ATA Lightweight Gateways, all feeding their information to an ATA center, as shown in Figure 5-13.
Computers functioning as ATA Gateways must have at least two network adapters, one for standard management traffic and one for the incoming domain controller traffic supplied by the port mirroring process. Both of the adapters should have static IP addresses. The management adapter should have the usual DNS server and Default Gateway addresses configured, and the DNS Suffix For This Connection text box on the DNS tab of the Advanced TCP/IP Settings dialog box should specify the name of the domain you are monitoring, as shown in Figure 5-14. The port mirroring adapter should have no Default Gateway or DNS server addresses. These settings are to ensure that all traffic but the incoming port mirroring traffic uses the management adapter.
Port Mirroring
Port mirroring is the process by which standalone ATA Gateways receive network traffic from the domain controllers. Port mirroring is not a function of ATA itself; you must configure it in your network switches or virtual machines.
Active Directory domain controllers are responsible for handling all of the authentication traffic for computers that are members of a domain. When an attacker tries to compromise the credentials of privileged accounts, as in a pass-the-hash attack, the evidence of the attack can be found in the traffic transmitted and received by the domain controller.
Therefore, ATA requires access to that domain controller traffic, and port mirroring is the process by which that traffic is replicated and sent to the computer functioning as the ATA Gateway. The gateway then passes that traffic on to the ATA Center.
Note Port Mirroring And ATA Gateways
Only standalone ATA Gateways use port mirroring to receive network traffic from domain controllers. ATA Lightweight Gateways run on the domain controllers, so they already have access to the required traffic.
Under normal conditions, on a physical network, switches are the hardware components that connect the computers together. Each computer is connected to a port on a switch. Network packets transmitted by a computer enter the switch through one of its ports and are forwarded out through another port, the one to which the destination computer is connected. The result is that the only computers that have access to a network packet are the one transmitting it and the one receiving it.
Port mirroring is a switch feature that enables administrators to select a port—in this case, the one to which the domain controller is connected. And you also have a copy of the traffic passing through that port in either direction to another port—in this case, the one to which the computer functioning as the ATA Center is connected.
If you are implementing ATA on physical computers, you must configure your switch to mirror the domain controller traffic to your ATA Gateway computer. If you are using virtual machines, you can usually configure port mirroring on the virtual network adapters in the virtual machines. For example, in Hyper-V, the network adapter in each virtual machine has an Advanced Features page in the Settings dialog box, as shown in Figure 5-15.
When you enable port mirroring, you use the Mirroring Mode drop-down list to specify whether you want that adapter to be the Source or the Destination of the mirrored traffic. If your domain controller and your ATA Gateway are both virtual machines on the same host, you would configure the domain controller as Source and your ATA Gateway as Destination.
When the computers involved in the port mirroring relationship are connected to different switches, or are virtual machines on different hosts, or when one is a physical computer and one a virtual machine, the process of configuring port mirroring is more complicated, and usually involves consulting the documentation for your switching hardware.
Event Forwarding
When the event ID 4776 appears in a computer’s Security log, this indicates that someone tried to log on using NTLM authentication. The message that appears in the log looks like the following:
The domain controller attempted to validate the credentials for an account.
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account: administrator
Source Workstation: WIN-R9H529RIO4Y
Error Code: 0xc0000064
Despite the wording of the message, it is not only domain controllers that log this event. Member servers and workstations generate this when users log on with local SAM accounts. Domain controllers log this event only when they authenticate users with NTLM, not Kerberos.
ATA requires access to these events to detect credential attacks such as Pass-the-Hash. Therefore, you must configure your computers to forward these event messages to your ATA Gateways. There are two ways to do this, as follows:
Security identification and event management (SIEM)/syslog If you have a SIEM or syslog server on your network, you can configure it to forward 4776 events to your ATA Gateway, and configure the ATA Gateway to listen for events forwarded from the server.
Windows Event Forwarding Windows has an Event Forwarding capability that enables you to create a subscription for the ATA Gateway and configure it to select the 4776 events and transmit them.
Install and Configure ATA Gateway on a Dedicated Server
ATA is packaged as a single installation disk or disk image with one Microsoft ATA Center Setup application on it. To deploy ATA in your enterprise, you must first install the ATA Center software on a member server using the disk. Then, you download the ATA Gateway software from within the ATA console interface.
Installing ATA Center
To install ATA Center on your server, use the following procedure:
1. Log on to the server with administrative privileges and run the Microsoft ATA Center Setup file on the ATA installation disk.
2. Select the language to use for the installation and accept the terms of the license agreement.
3. On the Center Configuration page, shown in Figure 5-16, the system’s two IP addresses should appear in the two fields. You can change the proposed location of the database, if desired, and select an SSL certificate generated by your certification authority, if your network has one.
4. When the installation is completed, click Launch to open a browser window and display the Microsoft Advanced Threat Analytics home page, as shown in Figure 5-17.
5. Log on to the site using the same account you used to log on to the server.
6. On the Directory Services page, supply credentials for an account with domain administrator privileges.
7. Click the Gateways link on the left side of the page.
8. Click Download Gateway Setup and save the downloaded file to a location on your local drive.
Install ATA Gateway
Once you have installed the ATA Center and downloaded the ATA Gateway software, you can proceed to install an ATA Gateway on another member server. This server should already be configured as the recipient of the port mirroring traffic from the domain controller you plan to service with the gateway.
To install an ATA Gateway, use the following procedure:
1. Copy the Microsoft ATA Gateway Setup.zip file you downloaded on the ATA Center computer and copy it to the server on which you install ATA Gateway.
2. Extract the contents of the zip file and run the Microsoft ATA Gateway Setup application.
3. Specify the language you want to use and, on the Gateway Deployment Type page, leave the Gateway option selected. The Lightweight Gateway option is grayed out unless you are installing the software on a domain controller.
4. In the Gateway Configuration settings, select an alternate location for the installation and the SSL certificate you used for the ATA Center installation, if desired.
5. In the Gateway Registration section, as shown in Figure 5-18, enter credentials for a member of the local Administrators or Advanced Threat Analytics Administrators group on the ATA Center computer.
6. When the installation is completed, return to the ATA Center computer, sign on the ATA Console again, and click the Gateways link on the left side of the page. The new gateway should appear in the display with a Not Configured status, as shown in Figure 5-19.
7. Click the gateway in the listing to open the configuration screen for your ATA gateway computer, as shown in Figure 5-20.
8. In the Port Mirrored Domain Controllers (FQDN) field, specify the fully qualified domain name of your domain controller (that is, adatumdc.adatum.com, not just adatumdc).
9. In the Capture Network Adapters box, select the adapter that you have configured to receive the port mirroring traffic from the domain controller.
10. Click Save, and the main console screen appears again, this time with the gateway’s Status showing as Starting. In a few minutes, the Status changes to Running.
Once the ATA Center and the ATA Gateway are operational, you must leave them to run, so that they can establish a baseline for the behavior of your network and begin to track anomalous behavior.
Install and Configure ATA Lightweight Gateway Directly on a Domain Controller
The Microsoft ATA Gateway Setup file you downloaded in the previous section can install either an ATA Gateway or a ATA Lightweight Gateway. As you saw when installing the gateway software on a member server, the ATA Lightweight Gateway option was grayed out. When you run Microsoft ATA Gateway Setup on a domain controller, the program recognizes the computer as such and allows the ATA Lightweight Gateway installation.
To install the ATA Lightweight Gateway on a domain controller, the computer must have a processor with at least two cores and also a minimum of six gigabytes of memory. Unlike an ATA Gateway installation, you do not have to configure port mirroring on the switch or the network adapter because the domain controller already has access to the required traffic.
If you are using a virtual machine for your domain controller, be sure to allocate the full amount of memory required and do not use the Dynamic Memory feature in Hyper-V or any similar memory management feature. ATA does not support the use of these technologies.
To install ATA Lightweight Gateway, use the following procedure:
1. Copy the Microsoft ATA Gateway Setup.zip file you downloaded on the ATA Center computer and copy it to the server on which you install ATA Gateway.
2. Extract the contents of the zip file and run the Microsoft ATA Gateway Setup application.
3. Specify the language you want to use and, on the Gateway Deployment Type page, leave the Lightweight Gateway option selected. The Gateway option is grayed out because you installing the software on a domain controller.
4. In the Gateway Configuration settings, select an alternate location for the installation and the SSL certificate you used for the ATA Center installation, if desired.
5. In the Gateway Registration section, enter credentials for a member of the local Administrators or Advanced Threat Analytics Administrators group on the ATA Center computer.
When the installation is completed, the ATA Lightweight Gateway is added to the Gateways page in the ATA Console, and immediately progresses from the Starting to the Running status. There is no need for a configuration procedure, as with the standalone ATA Gateway installation.
Configure alerts in ATA Center when suspicious activity is detected
Once you have installed and configured the ATA components, you can configure the ATA Center to notify you by generating emails or syslog events when it detects suspicious activity. These procedures assume that you already have the mail and/or syslog servers installed, configured, and available for use.
Configuring mail server settings
The first step in configuring ATA to generate mail alerts is to configure the mail server settings the ATA Center uses to send the messages. To configure these settings, use the following procedure:
1. Sign on to the ATA Console and, in the Settings menu (three vertical dots), click Configuration.
2. Click the Mail Server link on the left side of the screen, to display the Mail Server panel, as shown in Figure 5-21.
3. In the SMTP Server Endpoint fields, enter the fully qualified domain name and port number of your outgoing mail server.
4. If your mail server requires a Secured Sockets Layer (SSL) connection, click the SSL switch and, if necessary, the Accept Any Server Certificate switch.
5. If your mail server requires authentication, click the Authentication switch and enter valid credentials in the Username and Password fields.
6. In the Send From field, enter the email address you want to appear in the From field of the messages.
7. Click Save.
Configuring syslog server settings
As with mail alerts, the first step in configuring ATA to generate syslog alerts is to configure the syslog server settings the ATA Center uses. To configure these settings, use the following procedure:
1. Click the Syslog Server link on the left side of the screen, to display the Syslog Server panel, as shown in Figure 5-22.
2. In the Syslog Server Endpoint fields, enter the fully-qualified domain name and port number of your syslog server.
3. In the Transport drop-down list, choose which protocol you want ATA to use to communicate with the server: UDP, TCP, or TLS (Secured Syslog).
4. In the Format drop-down list, choose whether you want ATA to use the RFC5424 or RFC3164 format.
5. Click Save.
Configuring Notification settings
Once you have saved your Mail Server configuration settings, the Configure Mail Notifications button at the top right is enabled. In the same way, saving the Syslog Server settings activates a Configure Syslog Notifications button. Both of these buttons take you to the same place, the Notification Settings panel, which you can also access by clicking the Settings link in the Notifications section on the main ATA Console Configuration page.
To configure the notification settings, use the following procedure:
1. Click the Configure Mail Notifications or Configure Syslog Notifications button, or click the Settings link. The Notification Settings panel appears, as shown in Figure 5-23.
2. In the Language drop-down list, select the language you want ATA to use for the notifications.
3. In the Mail Recipients field, enter the email addresses of the people you want to receive the alert notifications.
4. Click the three switches to specify whether ATA should send notifications in the event of suspicious activity, health issues, and/or available updates.
5. In the Syslog Notifications section, click the three switches to specify whether messages should be sent for new suspicious activity, existing suspicious activity, and/or new health issues.
6. Click Save.
Review and edit suspicious activities on the Attack Time Line
Once ATA is installed and operational, the primary source of information about its results is the Timeline page in the ATA Console. The timeline tracks the suspicious activities that occur on your network day by day, as shown in Figure 5-24. It takes up to a month after the initial installation for ATA to construct a baseline for your network activity, but once this is done, behavior that is out of the norm is reported.
For example, if an administrative user account is only used for interactive logons to a domain every day between 9:00 AM and 5:00PM, and ATA suddenly starts detecting remote logons using that account during the overnight hours, it would flag that as suspicious behavior. It’s not just the remote logon itself that is suspicious, but the atypicality of the timing. ATA then generates an entry on the timeline providing the details of the activity, as shown in Figure 5-25.
Each timeline entry includes information about what resource was accessed, what computers accessed it, what accounts were used to gain the access, and what actions you might consider taking to address the issue. When you click the avatar of a user or computer, the console displays available information about it, as shown in Figure 5-26.
In the timeline, suspicious activities are graded by severity: high, medium, and low, and there is a status indicator you can use to grade your own investigation of the event: open, resolved, or dismissed.
Each timeline entry also has controls that enable you to do the following:
Add your own notes to the activity event.
Share the information in the event by emailing it.
Export the information in the event to a Microsoft Excel spreadsheet.
Display a detailed summary of the event, as shown in Figure 5-27.
Skill 5.3: Determine threat detection solutions using Operations Management Suite
While Advanced Threat Analytics (ATA) is an on-premise security monitoring solution, similar functions are also available from Microsoft in a cloud-based alternative called Operations Management Suite (OMS). OMS is a hybrid network management product that can gather data from your systems—in the cloud and in the data center—and provide a variety of management solutions, including threat detection and log analytics. Compared to Microsoft’s other management products, such as System Center Operations Manager, OMS is relatively easy to set up and use, and does not require an extensive on-premise infrastructure.
This section covers how to:
Determine usage and deployment scenarios for OMS
Determine security and auditing functions available for use
Determine log analytics usage scenarios
Determine Usage and Deployment Scenarios for OMS
OMS is the latest incarnation of a product that was originally called System Center Advisor (SCA) and then Azure Operational Insight. SCA was a tool that provided server configuration best practices advice, and Azure Operational Insight added log analytics capabilities. OMS now adds security and compliance monitoring, as well as backup and disaster recovery services, to make the product into a full-fledged suite.
Exam Tip
When preparing for the 70-744 exam, be sure that when you are studying a large, complex software product like OMS, you concentrate on the features related to threat detection that are likely to be covered in the exam.
Based in the cloud, OMS is essentially a management-as-a-service product that has all of the benefits of a cloud implementation, such as frequent updates and universal availability, while being able to service both your on-premise computers and your cloud servers. OMS is agent-based. You install the Microsoft Monitoring Agent (MMA) software on the computers you want to manage, and the agent sends information, including system logs, network traces, and performance counter data, to the OMS service in the cloud using the Secure Hypertext Transfer Protocol (HTTPS). Then, working in the OMS portal, shown in Figure 5-28, you select the management modules (called solutions) you want to use to analyze the information by the agents.
Note Using OMS With System Center Operations Manager
OMS can function in tandem with the System Center Operations Manager (SCOM) product, funneling all of the agent data through an on-premise SCOM server to the OMS service, or it can function independently, with the data going directly from the agents to OMS. Hybrid implementations are also possible.
Some of the OMS solutions that are currently available include the following:
Alert management Collects alert information from one or more SCOM management groups and provides search, tuning, remediation, and root cause analysis capabilities.
Antimalware assessment Using System Center Endpoint Protection on the client systems, collects information on malware protection status and detected threats
Change tracking Using software inventory information gathered by the agents, displays recent software modifications, broken down by software type, by application, and by computer.
Security and audit Using security, application, and firewall event log information gathered by the agents, provides an overview of potential security issues, including the presence of malware, identity threats, missing updates, and malicious traffic.
Wire data Using only network traffic metadata gathered by the agents, provides network traffic analysis functions without performing packet captures.
Backup Using backup status information gathered from Azure Backup and Windows Server agents, provides a combined interface for backup and recovery processes on both Azure and on-premise servers.
System update assessment Using system state data gathered by the agents, provides a summary of missing updates on the network computers, broken down by computer, update type, and specific update.
AD assessment Using Windows Management Instrumentation (WMI), registry, and performance data gathered by the agents, identifies problems with Active Directory configurations and provides recommended solutions.
Capacity planning Using performance data collected from SCOM management groups integrated with System Center Virtual Machine Manager (VMM) servers, analyzes system usage patterns and predicts future resource utilization.
Note OMS and New Solutions
One of the advantages of cloud-based services is that Microsoft can continually enhance and extend the product, without users having to install software updates. The modular nature of OMS enables Microsoft to continually add new solutions, which typically appear on the portal’s Solutions Gallery page during the latter stages of their development.
Deploying OMS
Compared with the System Center products, deploying OMS on your network is an extremely simple process. The steps for a full hybrid installation are as follows:
1. Log on using a Microsoft account.
2. Create a new workspace.
3. Confirm your email address.
4. Link an Azure subscription.
5. Associate an organization with the workspace.
6. Onboard SCOM.
7. Onboard Windows systems.
8. Onboard Linux systems.
9. Add solutions.
A full hybrid OMS installation monitors both on-premise and Microsoft Azure servers, but an Azure subscription is not required to use OMS. You can create a simple OMS workspace and connect it to your on-premise servers using the following procedure.
1. Open the http://microsoft.com/oms page in your browser and click the Try For Free button and then the Get Started button.
2. Log on using a Microsoft account.
3. Create a new OMS workspace by filling out the form shown in Figure 5-29.
4. Confirm your email address by responding to the message sent to your Microsoft account.
5. Open the initial Microsoft Operations Management Suite portal page (see Figure 5-30).
Deploying agents
To add on-premise computers to OMS, you must install the agents provided in the OMS portal. The portal includes agents for Windows and Linux servers, as well as Azure and System Center. To deploy the agent on a Windows server, use the following procedure:
1. On the OMS portal Overview page, click the Get Started pane.
2. On the Overview | Settings page, click Connected Sources and Windows Servers (see Figure 5-31).
3. Click the Download Windows Agent link for the appropriate platform and note the Workspace ID and Workspace Key values. You need them to install the agent.
4. Copy the downloaded agent file to the first computer you want to add to OMS and execute it. The Microsoft Monitoring Agent Setup Wizard launches.
5. Accept the license terms and the default Destination folder.
6. Select the Connect the Agent to Azure Log Analytics (OMS) checkbox.
7. On the Azure Log Analytics page (see Figure 5-32), paste in the Workspace ID and Workspace Key values you noted earlier.
8. Accept the default Windows Update setting.
9. Click Install, and then click Finish.
10. Repeat the process on all the computers you want to onboard.
Note Mass Agent Deployment
OMS provides the agents as Windows Installer packages, which makes it a simple matter to deploy them to multiple computers using virtually any software distribution product, including System Center Configuration Manager and Group Policy.
As you install each agent, the Windows Servers page in the portal reflects the number of connected servers. This is the first of the three tasks that the Get Started pane calls for you to complete. The second task is to add solutions to your OMS workspace. You do this by clicking the Solutions Gallery button on the portal’s Overview page, as shown in Figure 5-33, selecting the solution you want to use, and click Add on the Details page that appears.
The last of the three tasks that OMS requests you to complete is to specify the Azure subscription you want to connect to OMS. As mentioned earlier, this is not a requirement to use OMS.
When you open the Settings page and click Accounts and Azure Subscription & Data Plan, you can click the Link This Workspace to Azure Subscription hyperlink, a Link Azure Subscription page appears, as shown in Figure 5-34. Here you can link to an existing subscription, create a new subscription, or bypass the page.
Determine security and auditing functions available for use
Once you have OMS operational, using it for threat detection is a matter of selecting the right solutions and making sure that they have access to the right information from your computers. There are several OMS solutions that provide useful threat detection information, some directly and others indirectly.
Antimalware assessment
Malware detection software is the first line of defense against attack, but on a large network, administrators do not want to have to check each server individually, or even plow through hundreds of status alerts generated by the software. The Antimalware Assessment solution is essentially a clearinghouse for information gathered by the System Center Endpoint Protection agent, which you must have installed on your servers. This agent provides OMS with information about the current protection status of the computer and any malware threats it has detected.
On receiving information from the agents, OMS populates the solution with information for the entire network, including a list of the computers with threats detected, a list of threats detected, and lists of computers with and without antimalware protection, as shown in Figure 5-35.
System Update Assessment
Ensuring that your computers have the latest operating system and application security updates installed is one of the most important ways to prevent attacks. Even if your enterprise has an internal protocol in place for testing and deploying updates, using a solution such as Windows Server Update Services (WSUS), the System Update Assessment solution in OMS can provide a valuable overview of what updates are available and which have been installed.
The System Update Assessment solution gathers system state information provided by the agents, and also accesses the Microsoft Update servers to determine what updates have been released. This assessment occurs every 24 hours. OMS then compares the information from the two sources and populates the solution with composite graphs based on the perspectives of the computers and the updates, as shown in Figure 5-36.
Security and Audit
The Security and Audit solution uses information gathered from the Security Event log, the Application Event log, and the Windows Firewall log to assess several different security conditions, some of which overlap with those provided by other solutions. The agents on the computers always send this log information directly to the OMS service, even when the computers are part of a System Center Operations Manager (SCOM) group.
Note Using OMS Security And Audit With SCOM Computers
When computers are members of an SCOM management group, most of the information collected by the agent goes to the SCOM server first, which then relays it to the OMS service. However, depending on the auditing options you select, the logs required by the Security and Audit solution can accumulate extremely large amounts of data, and sending that data directly to OMS can prevent an unnecessary burden on the SCOM server.
By analyzing these logs, the Security and Audit solution evaluates information such as the accounts used to perform logons, the IP addresses of the connecting computers, and their baseline traffic patterns, and performs a threat intelligence assessment, as shown in Figure 5-37.
The solution also has additional capabilities. For example, it can compare the IP addresses of the connecting computers with a list of known malicious IP addresses provided by the Microsoft Threat Intelligence Center.
Determine log analytics usage scenarios
OMS is essentially a log analysis tool that displays its results in a graphical format. The real power of OMS is found in its searching capability, which enables you to perform precise searches to locate specific information. In many cases, clicking a graph on one of the solution pages takes you to a Log Search page, populated with the search string that provided the data for the graph, as shown in Figure 5-38. On this page, you can modify the parameters of the search to display different information, and save the search to a list of favorites.
The results obtained from a log analysis obviously depend on the types of log data provided to OMS. For the Security and Audit solution to function, for example, you must configure your servers to capture pertinent information to the Application, Security, and Windows Firewall logs.
As shown earlier in this chapter, the Windows Security Event log depends on the system’s auditing policy settings for its content, and so therefore does OSM. To supply OSM with the Security log data it needs, you must configure the advanced auditing policies on your servers using Group Policy.
Need More Review? Recommended Auditing Policy Settings
For a detailed listing of Microsoft’s recommendations for advanced auditing policy settings, see https://technet.microsoft.com/windows-server-docs/identity/ad-ds/plan/security-best-practices/audit-policy-recommendations.
For Application log data, you should configure your servers to log information on which executable files, installer scripts, and packages are used in your network. To do this, configure the following settings in a Group Policy object and deploy it to your OSM computers:
Browse to the Computer ConfigurationPoliciesWindows SettingsSecurity SettingsApplication Control Settings folder, open the Properties sheet for the AppLocker and, on the Enforcement tab, select the Configured checkbox and the Audit Only setting for all of the policies there, as shown in Figure 5-39.
Browse to the Computer ConfigurationPoliciesWindows SettingsSecurity SettingsApplication Control SettingsAppLocker folder and create a new rule for each of the four types (Executable Rules, Windows Installer Rules, Script Rules, and Packaged App Rules) using the default settings, the Path option, and an asterisk (*) for the Path value.
Browse to the Computer ConfigurationPoliciesWindows SettingsSecurity SettingsSystem Services folder and configure the Application Identity service to start automatically.
By default, Windows Firewall does not log any of its activities at all, so you must enable its logging by configuring the policy settings as follows:
1. Browse to the Computer ConfigurationPoliciesWindows SettingsSecurity SettingsWindows Firewall with Advanced Security folder.
2. Right-click the Windows Firewall with Advanced Security policy and open its Properties sheet.
3. One each of the three profile tabs, click Customize in the Logging box and, in the Customize Logging Settings dialog box, shown in Figure 5-40, configure the following settings:
Size limit (KB): 100
Logged dropped packets: Yes
Log successful connections: Yes
Chapter summary
Audit policies enable you to record specific events in a computer’s Security event log. Earlier Windows versions included only nine basic audit policy settings, but Windows Server 2016 now had 60 advanced audit policies, providing greater specificity in the events and objects to be audited.
To enable and configure auditing on Windows computers, you can use Group Policy or the Auditpol.exe command prompt utility.
To audit file system elements, registry settings, and Active Directory objects, you must enable an audit policy and configure a system access control list (SACL) for each object you want to audit. Global Object Access Auditing is a feature that enables you to use Group Policy to create SACLs for an entire file system or registry. You can also create expression-based policies based on criteria you configure in Dynamic Access Control (DAC).
Windows Server 2016 and Windows 10 include auditing policies that you can use to help prevent certain types of attacks, including audits of Plug and Play device insertions and group memberships.
Windows PowerShell includes its own logging capabilities, which you can also enable using Group Policy.
Microsoft Advanced Threat Analytics (ATA) is a security monitoring software package that uses information from domain controller events and captured traffic to develop a baseline of your network’s behavior and identify suspicious activities that might indicate an attack in progress.
The ATA architecture calls for a dedicated server running the ATA Center software and one or more gateways that feed information from domain controllers to the ATA Center computer for storage and processing.
ATA includes two types of gateways. ATA Gateway runs on a standalone server and can service multiple domain controllers. ATA Lightweight Gateway runs on a domain controller itself.
Configuration and result reports are available through the ATA console, which runs as an intranet web site on the ATA Center computer. ATA can also generate alerts in the form of emails and syslog messages when a suspicious activity occurs.
Microsoft Operations Management Suite (OMS) is a cloud-based service that provides threat detection and log analytics, among other management services.
OMS requires no on-premise infrastructure, other than an agent installed on each computer to be monitored. For cloud-based servers hosted by Microsoft Azure, you can link an OMS workspace to an Azure subscription.
OMS analyzes log and other information received from its agents and packages the analyses as solutions, which appear as panes in the OMS portal. You select the solutions you want to add to the portal.
Several of the OMS solutions provide information that can help administrators to detect and mitigate security threats. Solutions typically provide graphs and lists of computers, threats, updates, and other elements, along with recommendations for addressing any issues that arise.
To ensure that OMS has access to the data it needs to perform the tasks you select, you must configure your monitored computers to compile logs for specific components, which you typically do using Group Policy.
Thought experiment
In this thought experiment, demonstrate your skills and knowledge of the topics covered in this chapter. You can find answer to this thought experiment in the next section.
You are an IT administrator at Contoso, Ltd. After a recent incident of credential theft that was nearly disastrous for the company, the IT director has asked you to evaluate network management products, and particularly their threat detection capabilities. The director has given you a list of questions that she wants answered for all of the solutions you are considering.
You decide to evaluate two products: Microsoft Advanced Threat Analytics (ATA) and Microsoft Operations Management Suite (OMS). Answer the following questions for each of these two products.
1. What on-premise hardware infrastructure does each of the considered products require?
2. Do the products you are considering require any external software products, such as SQL Server or Microsoft SharePoint?
3. The director is considering moving some of the organization’s application servers to Microsoft Azure, in the cloud. Can the products you are considering evaluate threats originating on Azure servers?
4. Can the products you are considering capture and parse network packets for investigation?
5. Do the products you are considering require the installation of any special software on the computers to be monitored?
Thought experiment answers
This section contains the solution to the thought experiment.
1. ATA requires a minimum of one dedicated server to host the ATA Center application. ATA Gateways are also required, which can run on dedicated servers or be installed on domain controllers. Every domain controller must have access to a gateway. OMS requires no on-premise hardware at all, as it is a cloud-based service.
2. ATA is a self-contained program, which includes a database manager and a web interface, so there is no external software required. However, the ATA Center computer must run the Internet Information Services role supplied with Windows. OMS is a cloud-based service that runs on Microsoft’s computers. It is not an application that runs on your own Azure server, so there is no software to install and maintain.
3. ATA can monitor Azure, as well as on-premise, servers. You must configure your Azure servers with access to an ATA Gateway, just as if they were physical servers on your network. OMS runs in the cloud and can link to an Azure subscription, as well as connect to agents installed in on-premise servers.
4. ATA captures all network traffic transmitted to and from your domain controllers, parses it, and examines the contents for security threats and behavioral anomalies. OMS includes a Wire Data solution that examines network traffic metadata, but it does not capture actual network packets.
5. ATA requires domain controllers to have access to a gateway, which can be installed on the domain controller itself, but the gateways can also run on external servers. OMS requires that every computer being monitored have the Microsoft Monitoring Agent installed, which is supplied with the product.