Create User-to-Data-Center Application Whitelist Rules

1. Enable the appropriate user access to your internal corporate DNS servers (don’t enable access to external DNS servers).
   This rule restricts access to your corporate DNS servers, which reduces the attack surface and helps protect DNS entries about internal hosts and services. To avoid discovery by public DNS queries, DNS entries for internal corporate resources aren’t stored in publicly available DNS servers, so the only way an attacker can learn those entries is to compromise the corporate DNS server, so your DNS servers are attractive targets.

   At the internet gateway (network perimeter), block all DNS traffic to public DNS servers. Do not allow DNS traffic to go out to the internet.
   This rule is an exception to the best practice of not allowing “any” user in policy rules because users need to access DNS services before they log in. This rule safeguards access to DNS services. To create this rule:

   • Restrict access to the appropriate Destination Zone in the data center, IT infrastructure.
   • Configure an address group for the DNS Servers and restrict access to only that group.
   • Prevent access using any application except dns.
   • Apply the full suite of Security Profiles to the rule to protect against malware, vulnerabilities, C2 traffic, and known and unknown threats. If an attacker hijacks your DNS server, the attacker can redirect traffic to phishing websites that look like the legitimate websites users are trying to access.
   • Log DNS activity so that you can track and analyze violations of the rule, which may indicate an attempted attack.
2. Allow the necessary IT personnel secured, privileged access to data center servers for management and maintenance.
   This rule shows how to safeguard access to critical systems for users who have privileged accounts. Privileged accounts require a high level of trust and grant administrative access to critical systems that contain your company’s most valuable data, so you must tightly control and monitor privileged accounts. Leverage App-ID to specify only the applications IT users need to manage data center devices so that the firewall denies access for all other applications. In this example, a group of IT users needs administrative access to manage data center servers.

   IT privileged access for data center server management should be limited to management interfaces only, and should be on a dedicated VLAN so that server management traffic is separate from other traffic. The management interfaces should be on the same subnet. Don’t allow this type of access on data interfaces. If the IT group uses SSH or RDP for management access, don’t allow SSH or RDP access for other purposes.

   Your IT networking team’s organization determines whom to allow IT privileged access. For each type of privileged access, group servers and other devices by their access requirements. Allow only the necessary IT users to access each set of servers, using only applications required for device management.
   To create this rule:

   • Because only a subset of IT users may manage data center servers, leverage User-ID to create a group specifically for IT users who require that level of privileged access (in this example pantac2012\IT-superusers).
   • Create a static address group (IT-Server-Management) that contains the management interface addresses of the servers you want the pantac2012\IT-superusers to manage and restrict the Destination to that address group in the IT-server-access-DC zone.
   • Allow only the applications the IT superusers need to perform their business duties, on the default ports. In this example, the rule allows the ssl, ssh, and ms-rdp applications.
     The allowed applications are examples. Allow the applications your IT department uses to manage data center servers. In some cases, applications over SSL may require the addition of the specific application to be identified correctly by App-ID.
   • Attach the best practice security profiles to the rule to protect against malware, vulnerabilities, C2 traffic, and known and unknown threats.
   • Log activity so that you can track and analyze violations of the rule, which may indicate an attempted attack.

   IT personnel also manage switches, routers, and other devices in the data center. If the same group of IT users manages those resources using the same applications, you can add them to the destination zone and address so that the rule allows IT superusers to access the management interfaces of those devices. If different IT user groups manage different sets of data center resources or use different applications, create separate, tight security policy rules for each user group and each set of applications.

   Because user groups that have privileged accounts have access to critical systems, when you Create User-to-Data-Center Authentication Policy Rules, require MFA to prevent access if attackers compromise their credentials. Create corresponding authentication policy and decryption policy rules for each privileged access rule.
3. Allow access for employee user groups that have legitimate business reasons to communicate with data center servers.
   This rule shows how to limit each user group’s (or in some cases, an individual user’s) access to only the necessary applications and servers. For example, engineers need to access development servers in the data center. To create the security policy rule, create a dynamic address group that contains the IP addresses of all of the data center development servers that the group uses, identify the applications the engineers need to use on those servers, and construct the rule based on those groups.

   To create this rule:

   • Specify the engineering user groups that need access to engineering servers in the data center, in this example, pantac2012\apiusers and pantac2012\engg.
   • Restrict access to the data center development servers by creating a dynamic address group (Dev-Servers) for them and setting it as the Destination Address.
   • Restrict access to only the applications required for business purposes on the default ports.
   • Attach the best practice security profiles to the rule to protect against malware, vulnerabilities, C2 traffic, and known and unknown threats.
   • Log activity so that you can track and analyze violations of the rule, which may indicate an attempted attack.

   Use the same method to create granular whitelist access rules for each user group (if required, you can do this for individual users as well), so that each group can only use legitimate applications running on default ports to access only the sets of servers that they have business reasons to access. For example, allow only the group of Finance users who need access to servers that contain PCI to access those servers, using only the sanctioned finance applications required to accomplish business goals.

   Similar to the whitelist rule for engineering user access to data center servers, this rule allows users in the pantac2012\finance-users and pantac2012\accounting-users groups to use only the specified applications to access only the servers in the Fin-Servers dynamic address group. The rule applies the best practice security profiles to allowed traffic and logs activity.
4. Allow targeted, limited data center access to contractors, partners, customers, and other third-parties.
   This rule shows how to tightly control access for third-party users so that they can use only the applications they need on only the servers they need. For example, a company hires a group of SAP developer contractors. The SAP developers need to access the SAP database in the data center and make SQL queries. However, SQL also runs on production databases that the SAP developers should not access. The company needs to control three access vectors:

   • User group—SAP developer contractors.
   • Applications—MS-SQL and SAP.
   • Servers—SAP database servers only. Deny all other data center server access.

   The combination of User-ID to isolate the SAP contractor user group, App-ID to limit the group to using only the necessary applications, and a dynamic address group that limits access to only the SAP database servers in the data center enables the company to provide exactly the access the SAP contractors need to perform their duties, but no more.
   To create this rule:

   • Specify the Source Zone and User to limit access to users in the pantac\sap-contractors group coming from the Contractors zone.
   • Restrict the Destination to the SAP database servers (SAP DB Server dynamic address group) in the SAP-Infra zone.
   • Allow the SAP contractors to use only the applications they need to perform their business duties, on the default ports. In this example, the rule allows the ms-sql-analysis-service, mssql-db, mssql-mon, and sap applications.
   • Attach the best practice security profiles to the rule to protect against malware, vulnerabilities, C2 traffic, and known and unknown threats.
   • Log activity so that you can track and analyze violations of the rule, which may indicate an attempted attack.
   Granular whitelist security policy rules prevent all but the access required for business purposes and reduce risk by reducing the attack surface. Create similar whitelist rules for each third-party group that requires access to your data center.
   Instead of trusting third-party users and companies to secure their credentials, require multi-factor authentication (MFA; Create User-to-Data-Center Authentication Policy Rules) to prevent access if attackers steal credentials or otherwise compromise third-party systems. MFA authentication would have prevented several high-profile data breaches that occurred over the past several years.