Thinking Like an Attacker

You have probably heard this statement: “In order to protect from attackers, you should think like the attacker.” Attackers use so-called attack vectors, the activities that lead the path to unauthorized access to an organization's resources. From the other side, an organization's resources need to minimize the attack surface area, the resources that can potentially be attacked. Shutting down unneeded services will minimize the attack surface area. Furthermore, technologies such as the Server Core installation of Windows Server and Nano Server reduce the attack surface area even more. However, some services have to be running and available for business processes, so they need to be protected.

Attackers use a lot of different methods to breach an organization's security. An attack vector might contain multiple components, including:

• Attacks against network components, firewalls, routers, and VPN gateways. Your networking department should already know how to protect the equipment with regular software updates released by networking equipment vendors.
• Attacks against operating systems. These attacks include finding and exploiting vulnerabilities in server or client operating systems.
• Attacks against software products and custom applications. These attacks include exploiting vulnerabilities in applications.
• Attacks against virtualization infrastructure. If an attacker compromises the virtualization host, then all virtual machines could be compromised.
• Malware or malicious software. Malicious software can be differentiated into several types, including:
  • Viruses. Self-replicating malware that infects computers.
  • Trojans. Malware that gives the attacker remote access to the infected system.
  • Ransomware. A new and increasingly more advanced type of malware that encrypts important data. Decryption keys are sold to organizations that pay the ransom fee to the malware authors.
• Phishing. An attack where an individual unintentionally infects their computer with malware by visiting a specially created website or by opening a specially created email. Phishing is an email that attempts to convince a large number of recipients to perform an action (such as opening an email or visiting a website) that triggers an infection.
• Social engineering. Maybe one of the most underestimated but yet one of the most dangerous threats. The goal of this type of attack is to deceive people inside an organization and trick them into revealing security information (such as usernames, passwords, and IP addresses) that would help attackers access corporate data and services. As an example, someone could contact the support department and pretend to be a general manager requesting a password change immediately.

Ethical Hacking

Finding security breaches requires knowledge of operating systems, applications, networking, and security technologies. Many organizations hire IT security professionals as full-time employees or external consultants responsible for securing infrastructure, data, and services. Security professionals regularly perform ethical hacking, which includes running applications and performing procedures in order to try to compromise the security systems of the organization, but with the desired outcome of fixing potential security issues found during the testing. Ethical hacking procedures might include penetration testing, where security professionals try to attack and enter the internal IT infrastructure from the Internet. Some procedures include just scanning to determine which ports are unnecessarily open as a potential surface attack area.

Privileged Access

For a long time now, one of the best principles for securing a Windows Server infrastructure is to grant users and administrators the lowest level of privilege needed so they can perform their everyday activities. That way if an account is compromised, the attackers gain access only to the minimal set of privileges assigned to that account.

For this reason, administrators and developers need to have separate accounts for day-to-day activities such as reading email and browsing content on the Internet, and they should use privileged accounts only when they are performing tasks that require those specific privileges.

You may wonder how do to achieve this. It is much more convenient if you assign rights to groups rather than to users; once a group's security permissions are defined, an administrator can just add or remove users from those groups, where group membership will automatically define the user permission over resources and admin tools.

Furthermore, you can use Group Policy to assign user accounts rights in the Group Policy Editor, which is located under Computer ConfigurationPoliciesLocal PoliciesUser Rights Assignment. The settings are described in Table 8.1.

Securing User Accounts

User accounts in organizations are one of the most sensitive objects that attackers want to obtain. You can configure the security of a user account by opening the properties window of the user account in Active Directory Users and Computers and selecting the Account tab, as shown in Figure 8.1.

The following security options can be configured for an account:

• Logon Hours. The Logon Hours setting can be used to configure when users can use an account. For example, the account can be configured so that users can only use it from 7:00 AM to 8:00 PM Monday to Friday. By default, users can always sign in.
• Log On To. The Log On To settings can be used to limit the computers to which an account can sign in. By default, users can use an account to sign in to any computer in the domain.
• Unlock Account. Used to unlock accounts that are locked because an incorrect password was entered multiple times and the Account Lockout Policy threshold was reached.
• User Must Change Password At Next Logon. This setting is used when an administrator creates a new account or resets a password, so that users can choose their own password that is not known to anyone else.
• User Cannot Change Password. This option is not recommended to be configured because changing the password on regular intervals increases the security.
• Password Never Expires. This option is not recommended to be configured because it makes the accounts easier to compromise.
• Store Password Using Reversible Encryption. Unless there is some legacy application requirement that uses protocol for password authentication, this option is not recommended because it enables passwords to be decrypted,
• Account Is Disabled. Used for disabling or enabling the user account.
• Smart Card Is Required For Interactive Logon. When this option is enabled, it ensures that a smart card must be present for the account sign-in to occur.
• Account Is Sensitive And Cannot Be Delegated. When this option is enabled, it ensures that trusted applications cannot forward an account's credentials to other services or computers on the network.
• Use Only Kerberos DES Encryption Types For This Account. This option configures an account to use only Data Encryption Standard (DES) encryption.
• This Account Supports Kerberos AES 128-bit Encryption. This option allows Kerberos AES 128-bit encryption to occur.
• This Account Supports Kerberos AES 256-bit Encryption. This option turns on Kerberos AES 256-bit encryption.
• Do Not Require Kerberos Preauthentication. Enabling this option is not recommended because it will lower the security of the logon process.
• Account Expires. This option configures expiration dates where accounts do not remain in AD DS after they are no longer needed.

Configuring Account Policy Settings

Account policies are divided into password policies and account-lockout policies. The domain password and account-lockout policies apply at the domain level. They can be configured via the default domain Group Policy Object (GPO) by using the Group Policy Management Editor located under Computer ConfigurationPoliciesSecurity SettingsAccount Policies.

The Domain Password policy can be overridden by configuring a fine-grained password policy that applies to the members of security groups or individual user accounts. Fine-grained password policies are configured by using the Active Directory Administrative Center console.

The password policy defines:

• How many previous passwords are remembered. The default value is 24 passwords remembered. This means that when changing a password, users cannot use any of their previous 24 passwords.
• Maximum password age. This is the maximum amount of time that can elapse, in days, before a user must change their password. The default value is 42 days.
• Minimum password age. The minimum length of time that a user must retain a password before changing it. This setting ensures that users do not continually change their password, exhaust the password history, and return to using the same password. The default is one day.
• Minimum password length. The minimum number of characters that a password must include. The default is seven characters.
• Whether password must meet complexity requirements. Passwords must include three of the following four elements: uppercase letters, lowercase letters, numbers, and symbols. This is enabled by default.

The Domain-Account Lockout policy defines:

• How long an account is locked when a user types a specified number of incorrect passwords. The default is no lockout.
• How many incorrect passwords the user may type, in succession, during a specific time period before Windows locks the account.
• How much time must pass before the account lockout counter is reset.

Protected Users, Authentication Policies, and Authentication Policy Silos

Some of the attacks that are happening frequently are pass-the-hash, where an attacker authenticates by using the NTLM hash of the user's password. Since Windows Server 2012 R2 and later, there are new features that prevent these types of attack. By limiting the use of the account with less-secure security and authentication options, Protected Users groups are used to help protect highly privileged user accounts against compromise. A Protected Users group differs from other users because Windows does not cache their credentials locally. User accounts that are members of this group cannot use:

• Default credential delegation
• Windows Digest
• NTLM
• Kerberos long-term keys
• Sign-on offline

If the domain functional level is Windows Server 2012 R2 or higher, user accounts that are members of the Protected Users group cannot:

• Use NT LAN Manager (NTLM) for authentication
• Use DES for Kerberos preauthentication
• Use RC4 cipher suites for Kerberos preauthentication
• Be delegated using constrained delegation
• Be delegated using unconstrained delegation
• Renew user ticket-granting tickets (TGTs) beyond the first 240-minute lifetime

Only user accounts should be added to the Protected Users group. Computer and service accounts should not be added to the Protected Users group.

Using an authentication policy will allow you to configure settings, such as TGT lifetime and access-control conditions, that specify conditions a user must meet before logging in to a computer. For example, you might configure an authentication policy that specifies a TGT lifetime of 180 minutes and limit a user account so that users can use it only with specific devices. Authentication policies require that you set the domain functional level to Windows Server 2012 R2 or newer.

Authentication policy silos allow administrators to define a relationship between the user, computer, and managed service accounts, and they certify that the accounts belong to a single authentication policy silo only. You associate accounts in an authentication policy silo with a silo claim, and you then can use this silo claim to control access to claims-aware resources. For example, you must associate accounts that can access particularly sensitive servers with a specific silo claim.

Delegating Privileges

When you are planning the security permission assignment in an organization, you, as the administrator, might want to choose from the default built-in groups that have a specific set of privileges. For example, a member of the Domain Admins group can perform one specific set of administrative tasks, and a member of the Schema Admins group can perform another set of administrative tasks.

However, in many scenarios, the default security groups won't fit your organization's security requirements. Therefore, you can create new security groups and delegate to them specific and custom security permissions. You can do this by delegating specific rights using the Delegation of Control Wizard. The Delegation of Control Wizard allows you to delegate the following rights:

• Create, delete, and manage user accounts
• Reset user passwords and force password change at next logon
• Read all user information
• Create, delete, and manage groups
• Change group membership
• Manage Group Policy links
• Generate Resultant Set of Policy (Planning)
• Generate Resultant Set of Policy (Logging)
• Create, delete, and manage inetOrgPerson accounts
• Reset inetOrgPerson passwords and force password change at next logon
• Read all inetOrgPerson information

The wizard can also be used to create a custom task that can be delegated. When this is done, the objects are specified within the organizational unit (OU) or folder over which you want to delegate control and the permissions over those objects for which you want to delegate control.

Credential Guard

Credential Guard protects organizations from pass-the-ticket and pass-the-hash attacks by using virtualization-based security that isolates cached credentials, so that only specially privileged system software can access them. Credential Guard can restrict access to the special processes and memory that manage and store authorization and authentication-related data.

Credential Guard includes the following features and solutions:

• Credential Guard takes advantage of hardware security including secure boot and virtualization, where all credentials are isolated from the operating system.
• Credential Guard is managed by using Group Policy, Windows Management Instrumentation (WMI), or Windows PowerShell.

Credential Guard can be deployed only on computers that fulfill certain hardware requirements, such as 64-bit CPU, CPU virtualization extensions plus extended page tables, and Windows hypervisor. If a protected operating system runs on a virtual machine, the Hyper-V host must run Windows Server 2016 or minimum Windows 10 version 1607. The virtual machine must be Generation 2. Enabling Credential Guard on domain controllers is not supported.

To enable Credential Guard, you can use the Group Policy Management Editor's Computer ConfigurationAdministrative TemplatesSystemDevice Guard node, and enable "Turn On Virtualization Based Security" setting, as shown in Figure 8.2.

When you're configuring this policy, it first must be set to Enabled, and then the platform security level is set to Secure Boot or Secure Boot and DMA Protection. After that, the Credential Guard Configuration option must be set to Enabled With UEFI lock or Enabled Without lock.

Encrypting File System

Encrypting File System (EFS) has been around in Windows operating systems for many years. The only prerequisite for deploying EFS is that the disk needs to be formatted with NTFS file system. It encrypts files and folders, allows only authorized users to decrypt data, and prevents unauthorized users from viewing its content, no matter of the type of permissions users have to a file. The process of encryption and decryption is transparent to the user and applications. When encrypting a file or folder, users just need to select a check box to encrypt the contents to secure data, as shown in Figure 8.3.

When users access the encrypted files or encrypted folders, they open them the same way they would open a nonencrypted file. When unauthorized users attempt to open the file, they will receive a message stating that access is denied.

The EFS encryption and decryption processes include the following steps, as shown on Figure 8.4:

1. When a user wants to encrypt a file, EFS first generates a random symmetric file encryption key (FEK) for each file that has to be encrypted. EFS then encrypts the file with the generated FEK and encrypts the FEK with the user's public key. EFS stores the encrypted FEK with the user's public key, in the Data Decryption Field (DDF). This ensures that only the user who has the matching private key can decrypt the FEK and then decrypt the file with the FEK.
2. If you define a recovery agent, EFS creates a Data Recovery Field (DRF). A DRF contains the FEK that is encrypted by the data recovery agent's public key. EFS obtains the recovery agent's public key automatically from the recovery agent's file recovery certificate, which is stored in Group Policy.
3. Users can decrypt a file if they have at least Read access permissions to the file. Only users who have a matching private key to the public key that is stored in the DDF or DRF can decrypt the file. To decrypt a file, EFS uses the user's private key to decrypt the FEK. If EFS decrypts the FEK successfully, EFS uses it to decrypt the file content.

BitLocker

While EFS protects files and folders, BitLocker is a volume-encryption technology that encrypts the whole volume to protect data from unauthorized access. BitLocker was introduced for the first time on the Windows Vista operating system; it has the following features:

• BitLocker can encrypt an entire volume or only the used parts of a volume.
• BitLocker can use a Trusted Platform Module (TPM) to protect the integrity of the Windows startup process. BitLocker verifies that the required boot files have not been tampered with nor modified. If the verification process finds files that were modified—for example, by a rootkit or boot sector virus—then Windows does not start.
• BitLocker can require multifactor authentication, such as a PIN or a USB startup key.
• You can configure Network Unlock at Startup for BitLocker. With Network Unlock, the BitLocker-protected device will start automatically when it is connected to a trusted company network; otherwise, you will need to provide a startup PIN.
• BitLocker provides a recovery mechanism, a 48-digit recovery key, or a recovery agent to access the volume data if a TPM fails or the password is lost.
• BitLocker protects the whole volume from offline attacks. After the Windows device starts and users gain access to the protected volume, authorized users can access data on the BitLocker-encrypted volume if they have the appropriate file permissions.
• You can combine BitLocker with EFS. BitLocker encrypts at the volume level, whereas EFS encrypts data at the file level.
• The BitLocker performance overhead is minimal. For most installations, the performance impact is not noticeable. The BitLocker drive encryption architecture is described in Figure 8.5.

Sectors are encrypted by the full-volume encryption key (FVEK). The FVEK is further encrypted with the volume master key (VMK). The FVEK must be stored securely, because it has the capability to decrypt the volume. The FVEK (encrypted with the VMK) is stored on the disk as part of the volume metadata. The VMK is also encrypted (or protected) by one or more key protectors. The default key protector is the TPM, but you can configure additional protectors, such as a PIN and a USB startup key. If the device does not have a TPM, you can configure BitLocker to store a key protector on a USB drive.

For more information on BitLocker, visit the following link: https://docs.microsoft.com/en-us/windows/device-security/bitlocker/bitlocker-overview.

BitLocker uses the AES algorithm with 128-bit keys encryption by default. You can modify this setting with Group Policy—for example, to configure the use of 256-bit keys. BitLocker encrypts each volume sector individually, and part of the encryption key is derived from the sector number. Therefore, each two sectors have different encrypted data, even if the two sectors have the same unencrypted data. The settings in the Group Policy Management Editor are illustrated in Figure 8.6.

Windows Firewall with Advanced Security

Windows Firewall with Advanced Security was introduced in Windows Server 2008, and it has been constantly present in newer operating systems. It provides organizations with the capability to manage ports and protocols that will be used on client and server operating systems. Even though many network admins prefer using only hardware firewalls, turning off Windows Firewall is never recommended, according to the principle of minimizing attack surface area.

Windows Firewall with Advanced Security uses firewall profiles that consist of settings, firewall rules, and connection security rules for related networks at the same security level. Three network profiles are available in the Windows Firewall management console:

• Domain Networks. Represent networks at a workplace that are attached to a domain, which means they communicate with a domain controller.
• Private Networks. Represent nondomain but trusted networks, such as network connections configured with business partner that collaborates with your company.
• Guest or Public Networks. Represent networks in public places and are less secure than the previous two.

Each network location has the following information:

• Windows Firewall State. This refers to whether Windows Firewall is turned on or off.
• Inbound Connections. This provides the status of what will be performed on the incoming connections, such as Allow or Block connections.
• Outbound Connections. This provides the status of what will be performed on the outgoing connections, such as Allow or Block connections.
• Protected Network Connections. This specifies network adapter where the settings will apply.
• Settings. This specifies the settings that control Windows Firewall behaviors, such as notifications, and merging rules configured with Group Policy.
• Logging. This specifies the name, size of the log, as well as data to be logged.

Windows Server 2016 allows multiple firewall profiles to be simultaneously active on a server. For example, a server with two network adapters that is connected to both the internal network and the perimeter network can apply the Domain firewall profile to the internal network and Public firewall profile to the perimeter network.

The Windows Firewall with Advanced Security properties window is displayed on Figure 8.7.

The navigation pane (left pane) provides for more-granular control of firewall rules, connection security rules, and monitoring. When the Windows Firewall with Advanced Security On Local Computer object is selected in the navigation pane, the results pane shows an overview of the firewall configuration with links to the various configuration panes and dialog boxes. Finally, the Actions pane (right pane) provides the following options:

• Import Policy. Allows you to overwrite the current settings with a previously exported policy.
• Export Policy. Allows you to save the current configuration.
• Restore Default Policy. Resets any changes that have been made to the Windows Firewall settings.
• Diagnose/Repair. Starts the Network and Internet Troubleshooting Wizard.

The final tab in this Properties dialog box is the IPsec Settings tab. This tab lets you configure the customized values for IPsec configuration.

As in other network firewall technologies, Windows Firewall with Advanced Security includes Rules as a collection of criteria that define which IP address, port, and protocol you will allow, block, or secure with the firewall, as shown on Figure 8.8.

• Inbound and outbound rules explicitly allow or block traffic that matches the criteria in the rules. For example, you can configure a rule to allow HTTP traffic from the internal network through the firewall but block the same traffic if it is coming from the Internet.
• For Windows Server roles and features, you do not have to create the rules. For example, enabling Microsoft Internet Information Services (IIS) automatically adjusts Windows Firewall to allow the appropriate traffic. You can change the default action to allow or to block all connections regardless of any rules.

IPsec

IPsec is a suite of protocols that can help protect data in transit through a network by providing authentication, integrity checking, and encryption. IPsec is a set of industry-standard, cryptography-based protection services and protocols.

Its original purpose was to secure traffic across public networks, but many organizations have chosen to implement IPsec to address perceived weaknesses in their own private networks that might be susceptible to exploitation.

If you implement it properly, IPsec provides a private channel for sending and exchanging potentially sensitive or vulnerable data, where applications that communicate over the network are not aware of IPsec because only endpoints are responsible for performing the processes of authentication and encryption/decryption.

IPsec has the following characteristics:

• Offers mutual authentication before and during communications
• Forces both parties to identify themselves during the communication process
• Enables confidentiality through IP traffic encryption and digital packet authentication

IPSEC MODES

You can configure IPsec in one of two modes, as shown in Figure 8.10:

• Transport mode. Use transport mode when you enable end-to-end communications between two hosts. In this mode, which is the default mode, the data payload is encrypted, but the header data remains unchanged.
• Tunnel mode. In this mode, the entire original packet is encrypted and becomes the payload of a new packet, which then is transmitted between IPsec-aware routers. Tunnel mode enables IPsec-aware routers to encapsulate and encrypt network traffic from hosts that are not IPsec aware, transmit that traffic over an unsecured network, and then decrypt it for use on the destination network by other hosts that are not IPsec aware.

Privileged Access Workstations

One way to mitigate the risk of an attack on an administrator's credentials is to use a Privileged Access Workstation (PAW)—or secure administrative host—that represents a computer that is used only for performing administrative tasks.

PAWs are configured with following options:

• Only authorized users can sign in to the PAW.
• Device Guard and AppLocker policies should be configured to allow only authorized applications to run on PAW.
• Credential Guard should be configured to protect the credentials.
• BitLocker should be configured to protect the boot environment and the hard disk data.
• Configure PAW to control access by using a firewall.

You can also configure a PAW as a jump server that represents a PAW that can be accessed remotely by using Remote Desktop protocol. If not configured securely, jump servers can be compromised if they are accessed by a compromised computer.

Local Administrator

Each computer has a Local Administrator account. The Local Administrator account allows IT operations personnel to sign in to the computer if they cannot establish connectivity to the domain, or if the computer is not a domain member. Managing passwords for the Local Administrator account for every computer in the organization can be challenging, especially if the number of computers is very large.

Local Administrator Password Solutions (LAPS) provides organizations with a central repository for Local Administrator passwords for domain-member machines with the following functionalities:

• Unique Local Administrator passwords are on each computer managed with LAPS.
• It randomizes and changes Local Administrator passwords regularly.
• It stores Local Administrator passwords and secrets securely within AD DS.
• It configures permissions control access to passwords and secrets.
• LAPS retrieves and transmits encrypted passwords to the client.

LAPS is downloaded from Microsoft Download Center and is configured through a Group Policy client-side extension. LAPS requires an update to the Active Directory schema performed by running the Update-AdmPwdADSchema cmdlet, which is included in a Windows PowerShell module that becomes available when you install LAPS on a computer. Security permission for update the schema require membership of Schema Admins group and this cmdlet should be executed on a computer that is in the same Active Directory site as the computer that holds the Schema Master role for the forest. LAPS requirements also include .NET Framework 4.0 and Windows PowerShell 2.0 or newer to be installed.

The LAPS process runs every time Group Policy refreshes, and it includes the following steps:

1. LAPS determines if the password of the Local Administrator account has expired.
2. If the password has expired, LAPS performs the following steps:
   1. Changes the Local Administrator password to a new random value based on the configured parameters for Local Administrator passwords.
   2. Transmits the new password to AD DS, which stores it in a special confidential attribute associated with the computer account of the computer that has had its Local Administrator Account password updated.
   3. Transmits the new password-expiration date to AD DS, where it is stored in a special confidential attribute associated with the computer account of the computer that has had its Local Administrator Account password updated.

Authorized users can read passwords from AD DS, and an authorized user can initiate a Local Administrator password change on a specific computer.

Several steps need to be taken to configure and manage passwords by using LAPS. The first set of steps involves configuring AD DS. It starts by moving the computer accounts of computers that want to use LAPS to manage passwords to an OU. After the computer accounts are moved into an OU, the Set-AdmPwdComputerSelfPermission cmdlet is used to assign computers in an OU the ability to update the password of their Local Administrator account when it expires.

For example, to allow computers in the London OU to update their passwords by using LAPS when they expire, the following command should be used:

Set-AdmPwdComputerSelfPermission -Identity "London"

By default, accounts that are members of the Domain Admins and Enterprise Admins groups can access and view stored passwords. You can use the Set-AdmPwdReadPasswordPermission cmdlet to allow customized groups to access to Local Administrator password.

For example, to assign the LondonAdmins group the ability to view the Local Administrator password on computers in the London OU, the following command should be used:

Set-AdmPwdReadPasswordPermission -Identity "London" -AllowedPrincipals "LondonAdmins"

The next step is to install the GPO templates into AD DS. After the templates are installed, the following policies can be configured:

• Enable Local Admin Password Management. This policy will enable LAPS and will allow you to manage the Local Administrator Account password centrally.
• Password Settings. This policy allows configuration of the complexity, length, and maximum age of the Local Administrator password. The default is to utilize uppercase and lowercase letters, numbers, and special characters. The default password length is 14 characters, and the default password maximum age is 30 days.
• Do Not Allow Password Expiration Time Longer Than Required. When enabled, the password updates according to the Domain Password Expiration policy.
• Name of Administrator Account to Manage. Use this policy to identify custom Local Administrator accounts.

You can view the passwords assigned to a computer by using one of the following methods:

• View the properties of the computer account with Advanced Features enabled in Active Directory Users and Computers by examining the ms-Mcs-AdmPwd attribute.
• Use the LAPS user interface (UI) app.
• Use the Get-AdmPwdPassword Windows PowerShell cmdlet, which is available through the AdmPwd.PS module when you install LAPS.

Just Enough Administration

In previous sections, we mentioned that one of the best practices for users is to have enough security permissions to perform the job and nothing more. Just Enough Administration (JEA) is a technology that helps administrators achieve this security best practice by granularly defining what actions are allowed on specific resources by running Windows PowerShell commands. Once JEA is configured, an authorized user can connect to a specially defined endpoint and use a specific set of Windows PowerShell cmdlets, parameters, and parameter values. For example, a JEA endpoint can be configured to allow an authorized user to restart a specific service, such as the IIS, but not have permissions to restart any other service or perform other administrative actions.

JEA performs tasks by using a virtual account rather than the user's account. The benefits of this method include:

• The user's credentials are not saved on the remote system, so the user's credentials cannot be compromised.
• The user account that is used to connect to the endpoint does not need to be with administrative permissions. It only needs permission to be allowed remote connections.
• The virtual account is limited to the system on which it is hosted. The virtual account cannot be used to connect to remote systems. Attackers cannot use a compromised virtual account to access other protected servers.
• The virtual account has Local Administrator privileges but is limited to performing only the activities defined by JEA. The virtual account can be configured with membership of a group other than the Local Administrators group to further reduce privileges.

JEA is supported on Windows Server 2016 and Windows 10 version 1511 or later operating systems. If Windows Management Framework 5.0 is installed, then JEA functions on minimum Windows 7 and Windows Server 2008 R2 operating systems. JEA also needs PowerShell, which is enabled on each computer running minimum Windows Server 2012. Optionally, you might enable PowerShell module and script blocking as we described earlier in this chapter.

Role-Capability Files

JEA needs role-capability files that enable specifying actions that can be performed in a Windows PowerShell session. Only actions that are listed in this file will be allowed.

You can create a role-capability file by using the New-RoleCapabilityFile cmdlet, which creates a file with a .psrc extension. Once created, the role-capability file can be edited as needed.

Role-capability files support the components shown in Table 8.3.

Let's see some examples. For example, to allow the Restart-Service cmdlet to be used only for DNS service, we should provide the following entry in the role-capability file:

VisibleCmdlets = @{ Name = 'Restart-Service'; Parameters = @{ Name='Name'; ValidateSet = 'DNS'}}

Session-Configuration Files

When deploying JEA, you should register and configure an endpoint. When configuring an endpoint, you should define who will have access to the JEA endpoint, which roles will be assigned to the object accessing the endpoint, and the name of the endpoint.

To create a new session-configuration file, you should use the New-PSSessionConfigurationFile cmdlet, which will create a file with the .pssc file extension.

Session configuration files have the components shown in Table 8.4.

One server can have multiple JEA endpoints, and each JEA endpoint can be used for a different administrative task. For example, you can use one endpoint to perform IIS administrative tasks and a different endpoint to perform DNS administrative tasks. Users do not have to have administrative permissions to connect to an endpoint. Once connected, users are assigned administrative permissions assigned to the virtual account configured in the session-configuration file.

JEA endpoints are created by using the Register-PSSessionConfiguration cmdlet. When using this cmdlet, you specify an endpoint name and a session-configuration file hosted on the local machine.

For example, to create the endpoint named IISManagement by using the IISManagement.pssc session-configuration file, run the following command:

Register-PSSessionConfiguration -Name 'IISManagement' -Path IISManagement.pssc

Connecting to a JEA endpoint is done by using the Enter-PSsession cmdlet from a Windows PowerShell session. For example, in order to connect to JEA endpoint named IISManagement on computer NY-DC1, using credentials from user Paul in the Contoso domain, run the following command:

Enter-PSSession -ComputerName NY-DC1 -ConfigurationName IISManagement -Credential ContosoPaul

After completing the administrative tasks, you can use Exit-PSSession cmdlet to end the interactive session.

The first step of deploying JEA is to test the configuration. If the test is successful, the configuration can be deployed to other computers by copying the role-capability files and session-configuration files to the target computer, and creating JEA endpoints on that computer. You can use JEA Desired State Configuration (DSC) that allows central deployment of JEA to computers within the organization that have their configuration maintained by DSC. Furthermore, by using DSC, users and role mapping can be centrally managed.

Enhanced Security Administrative Environment

Enhanced Security Administrative Environment (ESAE) forests represent a specific architectural approach to designing Active Directory infrastructure. In ESAE, a dedicated administrative Active Directory forest hosts privileged access workstations, security groups, and accounts with administrative permissions, while resources and non-admin user accounts are located in a separate production forest. The ESAE forest is configured with a one-way trust relationship from the production forest to the administrative forest, which means that administrative forest accounts will have permissions to access the production forest resources.

The ESAE forest should be a single-domain Active Directory forest in order to avoid complexity. Furthermore, ESAE forest hosts only a small number of accounts to which strict security policies must be applied. No applications are deployed in the ESAE forest, because it is used only for hosting admin accounts.

The ESAE forest servers need to be configured in the following ways:

• Installation media should be validated.
• Servers should run the most recent version of the Windows Server operating system.
• Servers should be updated automatically with security updates.
• Security compliance manager baselines should be used as the starting point for server configuration.
• Servers should be configured with secure boot, BitLocker volume encryption, Credential Guard, and Device Guide.
• Servers should be configured to block USB storage.
• Servers should be on isolated networks. Inbound and outbound Internet connections should be blocked.

ESAE forests have the following benefits:

• Locked-Down Accounts  Standard nonprivileged user accounts in the ESAE forest can be configured as highly privileged in the production forest. For example, a standard user account in the ESAE forest is made a member of the Domain Admins group in a domain in the production forest. It is possible to lock down the standard user account hosted in the ESAE forest so that it cannot sign on to hosts in the ESAE forest and can only be used to sign on to hosts in the production forest. This design is more secure if an account is compromised while it is used in the production forest, because the attacker cannot use that account to perform administrative tasks in the ESAE forest.
• Selective Authentication  ESAE forest design allows organizations to leverage the trust relationship's selective authentication feature. For example, sign-ins from the ESAE forest will be restricted to specific hosts in the production forest. This is another method that helps limit credential exposure. For example, you can limit credential exposure when you configure selective authentication so that privileged accounts in the production forest can be used only on privileged access workstations or jump servers.

Privileged Access Management

Privileged Access Management (PAM) is a technology that grants administrative permission to admin users for a limited amount of time instead of permanently. It uses temporary membership of a security group that has been delegated privileges, instead of permanent membership of a security group. PAM increases security because rights are assigned temporarily instead of permanently, and PAM can be configured so that privileges are assigned when requested or assigned only after approval has been requested and granted.

When implemented, PAM can provide the following security improvements:

• All accounts that need admin privileges are standard user accounts. Privileges are granted only after being requested and approved. If a user account used by an admin team becomes compromised, the attacker gains no additional rights beyond those assigned to a standard user account.
• All requests for privileges are logged.
• Privileges are temporary. This makes it much more difficult for members of the IT Operations team to carry out unauthorized activities.

Once privileges are granted, a user must establish a new session by opening a new Windows PowerShell session or by signing out and signing in again to leverage the new group memberships configured for their account.

In order to deploy a PAM solution, you will also need to deploy Microsoft Identity Manager (MIM) 2016. MIM functionality includes managing users, credentials, policies, and access within an organization, including hybrid and cross forests scenarios.

The architecture of deploying PAM in an organization is shown on Figure 8.11.

A PAM deployment consists of the following components:

• Administrative Forest. An administrative, or bastion, forest is configured as an ESAE management forest.
• Microsoft Identity Manager (MIM) 2016. A product that is used to manage accounts and group membership from so called bastion forest. A bastion forest is a separate forest contains the accounts that administer the production forest.
• Production Forest. This is the forest that hosts the organization resources.
• PAM Client. A client software that interacts with the MIM PAM functionality and is used to request access to a PAM role.
• PAM Component Service. Manages the life cycle of the privileged accounts.
• PAM Monitoring Service. Monitors the production forest and duplicates changes to the administrative forest or the MIM service.
• PAM REST API. Can be used to enable a custom client to interact with PAM.
• MIM Service. The MIM server manages the privileged account management process.
• MIM Portal. The MIM Portal is a SharePoint site. It provides management and configuration functionality.
• MIM Service Database. The MIM service database can be hosted on SQL Server 2012 or SQL Server 2014. It holds configuration and identity data that the MIM Service uses.

PAM uses shadow accounts and shadow groups that represent a copy of the account and groups that exists in the production forest. When a user is added to a PAM role, MIM adds the user's shadow account in the administrative forest to the shadow group in the administrative forest. When the user logs in by using this account, their Kerberos token will then include a security identifier that matches the security identifier of the original group from the production forest.

A shadow user is created by using the New-PAMUser cmdlet, where a trust relationship must exist between the production forest and bastion forest. You must also specify the source domain and source account name. For example, to create a new shadow user based on the George account in the Contoso.com domain, you should use the following command:

New-PAMUser –SourceDomain Contoso.com –SourceAccountName George

You can configure the following PAM role settings by using the MIM portal web interface:

• Display Name  The name of the PAM role.
• PAM Privileges  A list of security groups to which a user that is granted access to the role is temporarily added.
• PAM Role TTL(sec)  This is the maximum amount of time that the member can be granted this role. The default is 3,600 seconds (1 hour).
• MFA Enabled  MIM's PAM functionality can be integrated with Azure Multi-Factor Authentication. MFA requires two forms of authentication. This second form of authentication can include a text message or a telephone call.
• Approval Required  You can configure PAM role membership to be granted only if a PAM administrator approves the request.
• Availability Window Enabled  When configured, the PAM role can be used only during certain hours.
• Description  Provides a description of the PAM role.

Finally, by combining PAM with JEA, you maximize the level of security by limiting who can perform administrative tasks, you granularly control what tasks are allowed to be performed, you secure privileged user accounts by isolating them in the separate forest, and you limit the time duration where administrative privileges are assigned. However, this infrastructure adds complexity for managing and maintaining such a solution. Therefore, you should carefully analyze your organization's business requirements and decide what security scenario and solution you will deploy.

Software Restriction Policies

Software Restriction Policies (SRPs) were introduced in the Windows Server 2003 operating system, and they provide administrators with the capability to specify which applications can run on client computers. An SRP contains rules and security levels and is configured through Group Policy.

Rules govern how SRP answers to an application that is being run or installed and are based on one of the following criteria:

• Hash. A cryptographic fingerprint of the file.
• Certificate. A software publisher certificate that signs a file digitally.
• Path. The local or Universal Naming Convention (UNC) path to where the file is stored.
• Zone. The Internet zone.

Each applied SRP can be configured with a security level that determines how an operating system responds to different types of applications. The three available security levels are listed here:

• Disallowed. The software that the rule identifies will not run, regardless of the user's access rights.
• Basic User. The software that the rule identifies as a standard user is allowed to run.
• Unrestricted. The software that the rule identifies is allowed to run unrestricted by the SRP.

SRPs can be configured at the following location in the Group Policy Management Editor:Computer ConfigurationPoliciesWindows SettingsSecurity SettingsSoftware Restriction Policies, as shown in Figure 8.12.

AppLocker

AppLocker was introduced with the Windows Server 2008 R2 operating system, and it controls which applications users can run. AppLocker is applied through Group Policy to computer objects within an organizational unit (OU). Individual AppLocker rules can be applied to individual Active Directory Domain Services (AD DS) users or groups. AppLocker can be used to monitor or audit the application of rules. By using the AppLocker technology, administrators can control how users can access and use files such as .exe files, scripts, Windows Installer files (.msi and .msp files), dynamic-link libraries (DLLs), and packaged applications, such as Windows Store apps.

AppLocker can be used to restrict software that is not allowed in a company, is not supported or used in the company anymore, or is limited for usage only in specific departments.

AppLocker settings are configured at the following location in the Group Policy Management Editor: Computer ConfigurationPoliciesWindows SettingsSecurity SettingsApplication Control Policies, as shown in Figure 8.13.

AppLocker uses the Application Identity service to verify a file's attributes. You should configure this service to start automatically on each computer on which you are applying AppLocker

Rules in AppLocker are defined based on the file attributes that it derives from the file's digital signature. File attributes in the digital signature include the following:

• Publisher name
• Product name
• File name
• File version

Allow and Deny are rule actions that permit or forbid the execution of applications based on an application list that is configured. If you choose Allow Action, your organization's computers will run only those applications that are specifically allowed. If you choose Deny Action, your organization's computers will run all applications except those that are on a list of denied applications.

An AppLocker policy has two modes of enforcement: Enforce and Audit Only. If you choose Enforce, AppLocker will enforce all rules and audit all events. If you choose Audit Only, AppLocker will only evaluate the rules and it will write events to the AppLocker Log. You can use the Audit Only option to help you evaluate what could happen if AppLocker is configured with the Enforce option, so you can test scenarios before actually enforcing them.

Device Guard

Device Guard is a new feature, introduced in Windows Server 2016, and it is a combination of hardware and software components ensuring that only trusted and authorized applications are allowed to run on a computer. Device Guard uses virtualization-based security to isolate the code integrity service and run it alongside the Windows kernel in a hypervisor-protected container. Administrators can configure what applications can run on the computer where Device Guard is implemented. This is done using a Code Integrity policy to protect the environment. The location of the Code Integrity policy is in the file: C:WindowsSystem32CodeIntegritysipolicy.p7b.

Device Guard includes the following technologies:

• Virtual Secure Mode  Virtual Secure Mode is a virtual shell that isolates the Local Security Subsystem Service LSASS.exe process from the operating system. In Windows 10 and Windows Server 2016, the hypervisor is on top of the hardware, and it interacts directly with the hardware to allow sharing of the hardware with virtual guests.
• Configurable Code Integrity (CCI)  CCI verifies the code that the Windows operating system is executing. It doesn't allow nonauthorized applications to be started.
• Virtual Secure Mode Protected Code Integrity  Configurable Code Integrity policies have two components: user mode code integrity (UMCI) and kernel mode code integrity (KMCI). The KMCI offers memory management improvements over the previous Windows versions, and it allows organizations to set their own KMCI and UMCI settings. Configurable Code Integrity should be running along with other security solutions, such as antivirus software or AppLocker.
• Platform and Unified Extensible Firmware Interface (UEFI) Secure Boot  Secure Boot was introduced in Windows 8 and ensures that boot loader code and firmware are protected from tampering by malicious code. This feature requires UEFI booting and Secure Boot option enabled in the UEFI.

Advanced Threat Analytics

Advanced Threat Analytics (ATA) is a separate product by Microsoft that you can install on Windows Server, and it has an intrusion detection system (IDS) functionality. IDS systems detect attacks and alert security admins. Different vendors provide security products known as intrusion prevention systems (IPS), which not only detect but also prevent attacks.

ATA is a network-based intrusion-detection system (NIDS) that uses both signature-based and anomaly-based detection. ATA helps identify known malicious attacks and techniques, security issues, and risks by using a signature-based method. In addition, the anomaly-based detection analyzes, learns, and identifies normal and abnormal entity (user, devices, and resources) behaviors. ATA is an on-premises solution that monitors Active Directory activity. It examines Active Directory Domain Services (AD DS) traffic to understand authentication patterns. ATA is a behavior analytics tool, which means that a malicious hacker can no longer hide behind a valid user account. Attackers do not know the normal user behavior of the account that is captured in the baseline, so even if they try to make some changes slowly, ATA would detect a change in the pattern for that user.

After ATA is installed, the system is in the analyze phase; this is a simple, nonintrusive port-mirroring configuration that copies all Active Directory–related traffic, while remaining unseen for attackers. It studies all AD DS traffic and collects relevant events from SIEM and other sources.

After the analysis phase comes the learning phase. In this phase, ATA automatically starts learning and outlining object behavior. It identifies normal behavior for objects and learns nonstop to update the activities of users, devices, and resources.

The third phase is the detection phase; it arises automatically with no user involvement. It looks for abnormal behavior and identifies suspicious activities. It raises red flags only if abnormal activities are contextually aggregated.

The last phase is the alert phase. In this phase, ATA reports all suspicious activities on a simple, functional, and actionable timeline. It identifies who, what, when, and how. For each suspicious activity, ATA provides recommendations for investigation and remediation.

Deploying ATA is nonintrusive and does not affect production systems. ATA listens and gives reports based on the traffic it monitors, so there is no effect on the network.

For more information on Advanced Threat Analytics, visit the following link: https://docs.microsoft.com/en-us/advanced-threat-analytics/what-is-ata.

Auditing

The Windows Server operating system includes tools for analyzing logs that contain security audit information. Those tools provide auditing functionality that you can use to detect any unusual activity or attempts for unauthorized access.

An audit policy monitors different security-related activities and stores the results of that monitoring in audit logs. Audit policies are managed on a domain level by using the Group Policy Editor under the Computer Configuration node. In Computer Configuration, expand PoliciesWindows SettingsSecurity SettingsLocal Policies and then click Audit Policy, as shown in Figure 8.14.

Table 8.6 defines each audit policy on a Windows Server 2016 domain controller.

Of course, every organization should customize their auditing policy according to their own security and compliance regulations. Besides auditing logon events, organizations might choose to audit different levels of access on file servers, such as successful or unsuccessful attempts to access specific folders and their content.

To configure file-level auditing, the following three steps must be completed:

1. Specify the auditing settings.
2. Enable an audit policy.
3. Evaluate the events in the security log.

You can audit access to a file or folder by adding auditing entries to its SACL. To do this, the following steps must be performed, as illustrated in Figure 8.15.

1. Open the Properties dialog box of the file or folder, and then click the Security tab.
2. On the Security tab, click Advanced.
3. Click Auditing.
4. To add an entry, click Edit. The Auditing tab will open in Edit mode.
5. Click Add, and then select the user, group, or computer to audit.
6. In the Auditing Entry dialog box, select the type of access to audit.

By using one or more of the access levels, you can audit for successes, failures, or both as the specified user, group, or computer attempts to access the resource.

You can audit successes for the following purposes:

• Audit successful accesses to verify security permissions so that you do not allow some users more permissions than they need for specific folders.
• Audit successful accesses to identify access from users who shouldn't have been allowed, which might indicate an unauthorized privilege.
• Audit failed accesses to monitor attempts to access a resource by unauthorized users.
• Audit failed accesses to identify failed attempts to access a file or folder to which a user does require access. This indicates that the permissions are not sufficient to meet a business requirement.

Once you have completed setup in the security descriptor of a file or folder, you should then enable auditing. The appropriate audit policy setting must be defined within Group Policy. The policy setting must be applied to the server that contains the object being audited.

Now you have completed the Group Policy settings and you are ready to monitor and analyze events in the server's security event logs, which are located in the Event Viewer console, under Windows LogsSecurity.

These security auditing improvements can help organizations comply with important business-related and security-related rules by tracking precisely defined activities, such as:

• An administrator modifying settings or data on servers that contain sensitive information
• An employee accessing an important file
• The correct SACL being applied to every file, folder, or Registry key on a computer or file share

ADVANCED AUDIT POLICY SETTINGS

Windows Server 2016 also contains advanced audit policy settings in the Group Policy Management Editor located under Computer ConfigurationPoliciesWindows SettingsSecurity Settings, as shown in Figure 8.16.

These are the settings:

• Account Logon  These settings enable auditing of the validation of credentials and other Kerberos-specific authentication and ticket operation events. The validation of credentials in a domain environment occurs on domain controllers, which means that the auditing entries are logged on domain controllers.
• Account Management  You can enable auditing for events that are related to the modification of user accounts, computer accounts, and groups with these settings. This group of auditing settings also logs password change events.
• Detailed Tracking  These settings control the auditing of encryption events, Windows process creation and termination events, and remote procedure call (RPC) events.
• DS Access  These audit settings involve access to AD DS, including general access, changes, and replication.
• Logon/Logoff  This group of settings audits standard logon and logoff events. They also audit other account-specific activity, such as Internet Protocol security (IPsec), Network Policy Server, and other uncategorized logon and logoff events.
• Object Access  These settings enable auditing for any access to AD DS, the Registry, applications, and file storage
• Policy Change  When you configure these settings, internal changes to audit policy settings are audited.
• Privilege Use  When you configure these settings, Windows Server audits attempts at privilege use within the Windows environment.
• System  These settings are used for auditing changes to the state of the security subsystem.
• Global Object Access Auditing  These settings are for controlling the SACL settings for all objects on one or more computers. When settings in this group are configured and applied with Group Policy, the configuration of the policy setting determines SACL membership, and the SACLs are configured directly on the server itself.

Organizations that have deployed Dynamic Access Control can leverage Expression-based auditing that will bring them additional auditing capabilities, such as auditing files and folders based on their specific classification, user, or action. For example, based on a folder classification, it will be audited automatically for security access.

EVENT LOG FORWARDING

Analyzing security logs on many different servers can be a challenge to perform. Therefore, you can use event forwarding in Windows Server where a remote computer forwards the events. There are two types of event forwarding: source-initiated and collector-initiated. In order to collect security events from computers, you must verify that winrm service is running as an administrator. Use the following command in Windows PowerShell:

winrm qc

After the event source computer is configured, you, as an administrator, should run the following command in Windows PowerShell at an elevated command prompt on the collector computer.

wecutil qc

You must then add the computer account of the collector computer to the Event Log Readers group on each of the source computers, by using Add-ADGroupMember cmdlet to add a computer to the Event Log Readers Active Directory group.

Add-ADGroupMember –identity 'Event Log Readers' –members AuditSRV$

After the configuration is complete, you will be ready to create a new subscription to specify the events you want the event sources to forward to the event collector. To create a new subscription, perform the following steps:

1. Run Event Viewer as an administrator.
2. In the console tree, click Subscriptions.
3. On the Actions menu, click Create Subscription and complete the requested information as shown in Figure 8.17.

   

4. In the Subscription Name box, type the name you want for the subscription.
5. In the Description box, type an optional description.
6. In the Destination Log box, select the log file where the collected events will be stored.
7. Click Add, and then select the computers from which events will be collected. Click Select Events to display the Query Filter dialog box. Use the controls in the Query Filter dialog box to specify the criteria that events must meet to be collected.
8. In the Subscription Properties dialog box, click OK. The subscription will be added to the Subscriptions pane, and if the operation was successful, the status of the subscription will be Active.

Nowadays IT departments rely on Windows PowerShell to automate administrative tasks. Therefore, you can use Windows PowerShell, which provides cmdlets for security auditing and analyzing audit logs, as described in Table 8.7.

WINDOWS POWERSHELL CMDLET	DESCRIPTION
Clear-EventLog	Deletes all entries from specified event logs on a local or remote computer
Get-Event	Gets the events in the event queue
New-Event	Creates a new event
New-EventLog	Creates a new event log and a new event source on a local or remote computer
Remove-Event	Deletes events from the event queue
Remove-EventLog	Deletes an event log or unregisters an event source
Show-EventLog	Displays the event logs of the local or remote computer in the Event Viewer
Write-EventLog	Writes an event to an event log
Limit-EventLog	Sets the event log properties that limit the size of the event log and the age of its entries

Windows PowerShell allows you to retrieve specific events based on certain criteria. For instance, if you want to retrieve the newest 50 security events, you can run following command:

Get-EventLog -Newest 50 -LogName "Security"

If your security department requests that all administrative commands be logged in a separate log, you can enable logging by using the LogPipelineExecutionDetails property of the PowerShell module and setting it to value $true. You can also enable logging by configuring Group Policy in Administrative Template/Windows Components/Windows PowerShell, as shown in Figure 8.18.