Same problem here. I think it's mainly caused by Windows updates modifying the svchost. My solution is to remove the fingerprinting in the svchost firewall rules- just use the path. That way, when updates modify the svchost file, you won't get a pop up. Also, you could make a rule allowing all outbound traffic to your trusted network from svchost. Not 110% secure (who is?) but you have to be able to live with your firewall!
In my opinion, "easiest" and "most secure" do not go hand-in-hand. Easiest configuration would be to allow all traffic in/out from svchost.exe with no fingerprinting or paths, where as the "most secure" method would be to specify exactly what all ports that a legitimate svchost.exe process needs, along with MD5-hashing and path names, for all specific svchost.exe versions across your environment.
As with any application and firewall rule, you'll need to decide how strict your create your rules. Find all necessary ports required by the application (in this example, do port checks on local systems; search Microsoft's articles on svchost.exe; find what ports it's supposed to use and what it is using). Decide how strict you want to make the rule and create the rule based off your decisions.
- Do you want to MD5 hash the executable? You may need multiple rules for all the svchost.exe builds you have in your environment.
- Do you just want to use the executable name, or do you want specific file paths? (malware may use the same filename, but from a different directory).
- What all ports are required for this application to function properly? You may need multiple rules to cover all the inbound/outbound ports.