Global Data Center Objects, Policies, and Actions

1. If your data center application inventory includes proprietary custom applications, then create custom applications for them so that you can specify them in Security policy.
2. Configure tight data center best practice Security profiles to prevent threats from disrupting your data center network.
   • Configure the best practice Antivirus profile by cloning the predefined profile and changing the imap, pop3, and smtp decoder values to reset-both in the Action and WildFire Action columns.
   • Configure the best practice Anti-Spyware profile by cloning the predefined strict profile. On the Rules tab, enable single packet capture on medium, high, and critical severity threats for traffic you log. (For traffic you don’t log, apply a separate profile without packet capture enabled.)
     On the DNS Signatures tab, change the Action on DNS Queries to sinkhole if the firewall can’t see the originator of the DNS query (typically when the firewall is north of the local DNS server) so that you can identify infected hosts. DNS sinkhole identifies and tracks potentially compromised hosts that attempt to access suspicious domains and prevents them from accessing those domains. Enable extended packet capture on the sinkholed traffic.
     Allow traffic only to sanctioned DNS servers. Use the DNS Security service to prevent connections to malicious DNS servers.
   • Configure the best practice Vulnerability Protection profile by cloning the predefined strict profile and changing the Packet Capture setting for every rule except simple-client-informational and simple-server-informational to single-packet. If the firewall identifies a large volume of vulnerability threats and that affects performance, disable packet capture for low-severity events.
   • The predefined strict File Blocking profile is the best practice profile. If supporting critical applications prevents you from blocking all the file types the strict profile blocks (you can identify the file types used in the data center from data filtering logs at MonitorLogsData Filtering), clone the strict profile and modify it as needed. If files don’t need to flow in both directions, use the Direction setting to restrict the file type to only the required direction.
   • The predefined WildFire Analysis profile is the best practice profile. WildFire provides the best defense against unknown threats and advanced persistent threats (ATPs).
3. Configure tight data center best practice Decryption profiles to prevent unknown traffic from entering your data center.
   • Perform CRL/OCSP checks to ensure that certificates presented during SSL decryption are valid.
   • SSL Protocol Settings: Set the Min Version to TLSv1.2, the Max Version to Max, and uncheck the SHA1 Authentication Algorithm. (The weak 3DES and RC4 Encryption Algorithms are automatically unchecked when you select TLSv1.2.) Use TLSv1.3 for traffic that supports TLSv1.3 (many mobile applications use certificate pinning, which prevent decryption when using TLSv1.3, so for these applications, use TLSv1.2).
   • SSL Forward Proxy: For Server Certificate Verification, block sessions with expired certificates, untrusted issuers, and unknown certificate status, and restrict certificate extensions. For Unsupported Mode Checks, block sessions with unsupported versions, unsupported cipher suites, and client authentication. For Failure Checks, blocking sessions if resources aren’t available is a tradeoff between the user experience (blocking may negatively affect the user experience) and potentially allowing dangerous connections. If you have to consider this tradeoff, also consider increasing the decryption resources available in the deployment.
   • SSL Inbound Inspection: For Unsupported Mode Checks, block sessions with unsupported versions and unsupported ciphers. For Failure Checks, the tradeoffs are similar to SSL Forward Proxy.
   • SSH Proxy: For Unsupported Mode Checks, block sessions with unsupported versions and unsupported algorithms. For Failure Checks, the tradeoffs are similar to SSL Forward Proxy.
   • Apply the No Decryption profile to traffic you choose not to decrypt because of regulations, compliance rules, or business reasons, except TLSv1.3 traffic (TLSv1.3 encrypts certificate information, so the firewall cannot block traffic based on certificate information). Block sessions with expired certificates and untrusted issuers.
4. Configure traffic blocking rules to deny traffic you know is malicious or isn’t needed for business purposes.
   Logging and monitoring block rules may reveal users and applications you didn’t know were on your network and that may be legitimate or may indicate an attack. The rule order in the Security policy rulebase is critical to prevent shadowing (traffic matching an allow or block rule before it can match the rule you intend the traffic to match). Some rules are almost the same but enable separate reporting for standard and non-standard ports or for user applications and applications from other sources. For each rule, configure Log at Session End on the Actions tab and set up Log Forwarding to track and analyze rule violations.
   • Block all applications from user zones on the application-default port. Place this rule after the rules that allow legitimate application traffic from user zones to identify unknown or unexpected user applications on standard ports.

   • Block all applications from user zones on any port to catch user traffic attempting to use non-standard ports. Place this rule after the preceding application-default block rule to identify unknown or unexpected user applications on non-standard ports, which may be custom applications or evasive applications.

   • Block applications you never want in your data center, such as evasive and commonly exploited applications and applications not required for business. Place this rule after the application allow rules so that, for example, you allow sanctioned file sharing applications before the Filesharing application filter blocks all other file sharing applications.

   • Block all applications from any zone on the application-default port to identify unexpected applications on standard ports. Rule matches may indicate potential threats or application changes that require modifying an allow rule. Place this rule after the application allow rules and the preceding block rule.

   • Block all applications from any zone on any port to identify unexpected applications on non-standard ports. Don’t allow unknown-tcp, unknown-udp, or non-syn-tcp traffic. Place this rule after the application allow rules and the preceding block rule.

   • Block unknown users attempting to run applications on any port to discover unknown users (gaps in User-ID coverage or attackers) and identify compromised devices (including embedded devices such as printers, card readers, and cameras). Place this rule after the application allow rules and the preceding block rule.

   • In addition to blocking unwanted potentially malicious traffic, block Quick UDP Internet Connections (QUIC) protocol, unless for business reasons, you want to allow encrypted browser traffic. Chrome and some other browsers establish sessions using QUIC instead of TLS, but QUIC uses proprietary encryption that the firewall can’t decrypt, so potentially dangerous traffic may enter the network as encrypted traffic. Block both the QUIC application and UDP ports 80 and 443 to force the browser to use TLS. First create a Service (ObjectsServices) that includes UDP ports 80 and 443:
     Use the Service to specify the UDP ports to block for QUIC. In the second rule, block the QUIC application so that the first two rules in your rulebase block QUIC:

5. Install Cortex XDR Agent on all data center endpoints to protect against malware and exploits on the endpoints.
   Cortex XDR Agent protects all endpoints the same way, so the deployment process and malware protection policy best practices are the same for the data center as for any other network area.