Help CenterWhen using Network Control with dynamic ACLs/Objects, it is imperative that you structure your policy hierarchy correctly. Effective policy ordering is critical for maintaining the performance of Network Control within your organization. Failure to do so could slow policy enforcement and effectiveness.
Inefficient policy creation and ordering can result in unnecessary traffic and fallback web queries to ThreatLocker's data centres. This has the potential to slow down the rate at which your Network Control policies are being handled, which can in some instances cause network slowness in your environment.
When setting up your Network Control policy list, broad dynamic ACLs using Objects should be placed just above the Default Deny policy for an organization. An example of a broad dynamic ACL would be one that has a ‘Source’ of ‘Organization’ and a ‘Destination’ of ‘All’ IP addresses and ‘All Ports’.
This broad dynamic ACL is not set to look for specific IP addresses and therefore will increase logging and slow down policy enforcement. On a public facing web server for example, when many of the connecting machines are not running ThreatLocker, a local handshake can not take place; necessitating fallback calls to Threatlocker's Data Centres to establish whether the connecting machines are running ThreatLocker.
This type of broad dynamic ACL should ideally be placed below specific, more narrowly targeted policies. These policies can be set with individually allowed IP addresses and ports instead of setting the ‘Destination’ elements to ‘All’ and 'All Ports'. Once a more specific policy has been set up, it is important that this policy be placed towards the top of the policy hierarchy, while broader policy ranges be set closer to the bottom.
By arranging your policies as such, this allows network traffic to match the more specific rules that have been placed first, thereby improving efficiency and response time. The broad dynamic ACL will then act as a fallback if network traffic is not first caught by a policy towards the top of the hierarchy. Prioritizing specificity ensures your environment remains scalable and responsive. Always install broad policies low in the hierarchy to avoid unnecessary processing.