Description: [coming soon]

Why It's Important: [coming soon]

Learn More

Description: Specifies whether a Remote Desktop Session Host server requires secure RPC communication with all clients or allows unsecured communication. You can use this setting to strengthen the security of RPC communication with clients by allowing only authenticated and encrypted requests. If the status is set to Enabled, Remote Desktop Services accepts requests from RPC clients that support secure requests, and does not allow unsecured communication with untrusted clients. If the status is set to Disabled, Remote Desktop Services always requests security for all RPC traffic. However, unsecured communication is allowed for RPC clients that do not respond to the request. If the status is set to Not Configured, unsecured communication is allowed. Note: The RPC interface is used for administering and configuring Remote Desktop Services.

Why It's Important: This setting helps protect the system by making sure that any remote management traffic is encrypted and authenticated. It blocks untrusted or unsecured connections that could be used by attackers to control or spy on the system. Think of it like requiring a secure, verified phone line for sensitive conversations—so no one can eavesdrop or impersonate someone else. It’s a key part of keeping remote access safe and locked down.

Learn More

Description: Specifies that link local multicast name resolution (LLMNR) is disabled on client computers. LLMNR is a secondary name resolution protocol. With LLMNR, queries are sent using multicast over a local network link on a single subnet from a client computer to another client computer on the same subnet that also has LLMNR enabled. LLMNR does not require a DNS server or DNS client configuration, and provides name resolution in scenarios in which conventional DNS name resolution is not possible. If you enable this policy setting, LLMNR will be disabled on all available network adapters on the client computer. If you disable this policy setting, or you do not configure this policy setting, LLMNR will be enabled on all available network adapters.

Why It's Important: This policy is like disabling a public intercom system that lets anyone on the network respond to name requests. By turning off LLMNR, SHIELD reduces the risk of spoofing attacks where malicious devices impersonate legitimate ones to intercept traffic or credentials. It helps enforce stricter name resolution practices and ensures that only trusted DNS infrastructure is used, improving overall network security.

Learn More

Description: Specifies that a multi-homed DNS client should optimize name resolution across networks. The setting improves performance by issuing parallel DNS, link local multicast name resolution (LLMNR) and NetBIOS over TCP/IP (NetBT) queries across all networks. In the event that multiple positive responses are received, the network binding order is used to determine which response to accept. If you enable this policy setting, the DNS client will not perform any optimizations. DNS queries will be issued across all networks first. LLMNR queries will be issued if the DNS queries fail, followed by NetBT queries if LLMNR queries fail. If you disable this policy setting, or if you do not configure this policy setting, name resolution will be optimized when issuing DNS, LLMNR and NetBT queries.

Why It's Important: Specifies that a multi-homed DNS client should optimize name resolution across networks. The setting improves performance by issuing parallel DNS, link local multicast name resolution (LLMNR) and NetBIOS over TCP/IP (NetBT) queries across all networks. In the event that multiple positive responses are received, the network binding order is used to determine which response to accept. If you enable this policy setting, the DNS client will not perform any optimizations. DNS queries will be issued across all networks first. LLMNR queries will be issued if the DNS queries fail, followed by NetBT queries if LLMNR queries fail. If you disable this policy setting, or if you do not configure this policy setting, name resolution will be optimized when issuing DNS, LLMNR and NetBT queries.

Learn More

Description: This policy setting configures secure access to UNC paths. If you enable this policy, Windows only allows access to the specified UNC paths after fulfilling additional security requirements.

Why It's Important: This policy is like requiring both parties to show ID before exchanging sensitive documents. By hardening UNC paths, SHIELD ensures that access to network shares is protected by strong authentication and integrity validation. It helps prevent attackers from intercepting or tampering with file transfers over the network, especially in environments.

Learn More

Description: This policy setting allows you to specify which boot-start drivers are initialized based on a classification determined by an Early Launch Antimalware boot-start driver. The Early Launch Antimalware boot-start driver can return the following classifications for each boot-start driver: - Good: The driver has been signed and has not been tampered with. - Bad: The driver has been identified as malware. It is recommended that you do not allow known bad drivers to be initialized. - Bad, but required for boot: The driver has been identified as malware, but the computer cannot successfully boot without loading this driver. - Unknown: This driver has not been attested to by your malware detection application and has not been classified by the Early Launch Antimalware boot-start driver. If you enable this policy setting you will be able to choose which boot-start drivers to initialize the next time the computer is started. If you disable or do not configure this policy setting, the boot start drivers determined to be Good, Unknown or Bad but Boot Critical are initialized and the initialization of drivers determined to be Bad is skipped. If your malware detection application does not include an Early Launch Antimalware boot-start driver or if your Early Launch Antimalware boot-start driver has been disabled, this setting has no effect and all boot-start drivers are initialized.

Why It's Important: This policy is like inspecting every tool before it’s used to start a machine. By controlling which boot-start drivers can run, SHIELD ensures that only trusted or essential components are loaded during startup. It helps prevent rootkits and other early-stage malware from compromising the system before traditional security tools are active. This strengthens the system’s defenses at its most vulnerable point—during boot—and supports a secure foundation for the operating environment.

Learn More

Description: This policy setting controls how the RPC server runtime handles unauthenticated RPC clients connecting to RPC servers. This policy setting impacts all RPC applications. In a domain environment this policy setting should be used with caution as it can impact a wide range of functionality including group policy processing itself. Reverting a change to this policy setting can require manual intervention on each affected machine. This policy setting should never be applied to a domain controller. If you disable this policy setting, the RPC server runtime uses the value of "Authenticated" on Windows Client, and the value of "None" on Windows Server versions that support this policy setting. If you do not configure this policy setting, it remains disabled. The RPC server runtime will behave as though it was enabled with the value of "Authenticated" used for Windows Client and the value of "None" used for Server SKUs that support this policy setting. If you enable this policy setting, it directs the RPC server runtime to restrict unauthenticated RPC clients connecting to RPC servers running on a machine. A client will be considered an authenticated client if it uses a named pipe to communicate with the server or if it uses RPC Security. RPC Interfaces that have specifically requested to be accessible by unauthenticated clients may be exempt from this restriction, depending on the selected value for this policy setting.

Why It's Important: This policy is like requiring a verified badge before letting someone into a secure system. By restricting unauthenticated RPC clients, SHIELD ensures that only trusted, verified systems can communicate with sensitive services. It helps prevent remote attacks, blocks anonymous access, and strengthens the overall security of the operating system. This is especially important for protecting encrypted drives and maintaining the integrity of system-level communications.

Learn More

Description: Specifies whether a Remote Desktop Session Host server requires secure RPC communication with all clients or allows unsecured communication. You can use this setting to strengthen the security of RPC communication with clients by allowing only authenticated and encrypted requests. If the status is set to Enabled, Remote Desktop Services accepts requests from RPC clients that support secure requests, and does not allow unsecured communication with untrusted clients. If the status is set to Disabled, Remote Desktop Services always requests security for all RPC traffic. However, unsecured communication is allowed for RPC clients that do not respond to the request. If the status is set to Not Configured, unsecured communication is allowed.

Why It's Important: Requiring secure RPC communication helps prevent unauthorized access and protects sensitive data during remote desktop sessions. It blocks unsecured or unauthenticated requests, reducing the risk of man-in-the-middle attacks and credential theft. SHIELD enables this policy to ensure that only trusted and secure clients can connect. It’s like requiring a verified badge before letting someone into a secure meeting—only those who meet the security standard are allowed in.

Learn More

Description: Allow Microsoft Edge to pre-launch at Windows startup, when the system is idle, and each time Microsoft Edge is closed.

Why It's Important: This policy is like preventing an app from quietly starting up behind the scenes without permission. By blocking Edge prelaunch, SHIELD helps reduce unnecessary background activity, improves system performance, and ensures that browser sessions only start when explicitly initiated by the user. It also minimizes potential attack surfaces and supports tighter control over application behavior in managed environments.

Learn More

Description: Determines whether a user can install and configure the Network Bridge. Important: This settings is location aware. It only applies when a computer is connected to the same DNS domain network it was connected to when the setting was refreshed on that computer. If a computer is connected to a DNS domain network other than the one it was connected to when the setting was refreshed, this setting does not apply. The Network Bridge allows users to create a layer 2 MAC bridge, enabling them to connect two or more network segments together. This connection appears in the Network Connections folder. If you disable this setting or do not configure it, the user will be able to create and modify the configuration of a Network Bridge. Enabling this setting does not remove an existing Network Bridge from the user's computer.

Why It's Important: This policy prevents users from creating or modifying network bridges on domain-connected devices. It helps maintain network integrity and security by stopping unauthorized bridging of network segments, which could expose internal resources or allow unintended traffic between networks.

Learn More

Description: [coming soon]

Why It's Important: [coming soon]

Learn More