Best practices for Palo Alto security policy when destination IP/FQDN is dynamic or unknown

[ym-higashi]

Group Company A is implementing surveillance cameras and requires communication to send data from the cameras to an external cloud server. The cloud server (destination) cannot be restricted by IP address or FQDN (only ports can be restricted), so IP addresses and FQDNs must be opened with ANY. ※ Restricted ports are TCP 443 (HTTPS), UDP 123 (NTP), TCP 31000 (TLS) The policy states that since it is necessary to restrict the destination by IP address or FQDN, communication like the above cannot be permitted. Systems using cloud services like AWS are increasing, and situations where IP addresses and FQDNs fluctuate and cannot be restricted, as described above, are likely to become more common in the future. How should policies be configured on Palo Alto to ensure security

[Raido_Rattameister]

Company has policy not to permit traffic to any destination but at the same time permits group of people in the company go and procure cameras without consulting security team who could provide pre-requisites (like requiring camera to use FQDN as destination)?

In this case you either push back and don't allow the traffic or place those cameras into it's own subnet and permit traffic from camera subnet to any IP on ports you mentioned.

[OtakarKlier]

Hello,

I would ensure that the cameras are in a separate vlan that is anchored by the PAN. This way if the cameras are compromised there is no lateral movement. You can initially set the policy to allow any destination country and the ports. Then look at the logs to see what IP's they are going to and perform a reverse DNS lookup. This might just return a generic aws dns name or none at all. You can then just use the block of IP's that are the destination. If it changes in the future, you can adjust accordingly. 

Just a thought.

[martpdelacruz · Accepted solution]

Restrict the devices to a Static-IP/Device-ID so that those specific devices can use the "Any" destination. Pick the specific App-ID for the camera traffic so that if the camera get compromised, the fw will block it bc the traffic won't match the app-id signature. I'd also attach a profile to the rule that whitelists the cloud provider's domain and block everything else. Even with the "Any" IP, the fw will inspect the SSL handshake to make sure it's going to the right place. Since the destination is board, my choice would be to apply a Sec. Profile that has antivirus/wildfire/vuln. protection. One more tip, if the cloud provider is aws/azure provides an ip range list, use an EDL so that the fw can auto update the allowed IPs by itself without manual work. I provided a simple template to give you an idea. I hope this sends you in the right direction. Good-luck

[abayoumi21]

My recommendation in this case is to control the traffic using a URL Category within the Security Policy (under the Service/URL Category tab) that for TLS traffic.

In addition to restricting the source IP addresses, you should also limit the allowed applications using App-ID (such as ssl and ntp), create EDL, and attach appropriate Security Profiles to strengthen the overall security posture of this rule.

Within the URL Category configuration, you can create a custom URL category and define static entries, for example, by matching *.amazonaws.com, to limit access to specific cloud domains rather than allowing unrestricted outbound connections.