Chapter 11
Security with Distributed Enterprise and Retail
Information in this chapter:
• Security Needs and Challenges
• Example Distributed Enterprise and Retail Environment Topologies
The purpose of this chapter is to provide insight into the needs and security challenges of an enterprise or retail environment that has a distributed network infrastructure. The network consists of a corporate core with remote branch offices and mobile users. A branch network can range from a handful of remote employees to a large satellite office consisting of up to a thousand employees. These remote locations require communication back to the company data centers and/or between other remote locations. Distributed communication between remote physical locations would require a secure infrastructure. This chapter will outline a real-world example of a distributed network based on FortiGate technology.
Security Needs and Challenges
It is critical to secure and protect network infrastructure, regardless of how extended it may be. To begin, you must outline the purpose of each network zone along with its associated security requirements.
What are the general needs for the distributed network?
• They could consist of both physically remote office locations and mobile users.
• It is important to be able to access company-provided network resources, such as intranet servers and company email.
What are the security challenges surrounding these needs?
• The communication entering and exiting the company’s infrastructure must be secured. By default, most network communication is unencrypted and could expose sensitive company data. To address this, a high-level form of encryption is needed to secure communication. It is recommended that this be at least 128-bit level encryption, but higher is generally better.
• All levels of communication require access control rules to be specified. This can include restricting access to business-related information and blocking access between specific nodes.
• An authentication policy should provide identification for all user-related functions. This can include enforcing good passwords and tracking activity.
• Threats should be monitored and prevented proactively. Since malicious activity can occur between any network entities, all zones must be appropriately hardened. For example, company employees could attack network resources intentionally or through malware infection. In retail or service environments, networks are often made available to the public and could therefore easily be attacked from within.
The above requirements are typical in business and retail environments. However, there are other drivers for network segmentation. One common example is compliance. Some compliance is mandated by law, such as HIPAA (Health Insurance Portability and Accountability Act), GLBA (Gramm-Leach-Bliley Act), and SOX (Sarbanes-Oxley). Others are enforced contractually, such as PCI-DSS (Payment Card Industry Data Security Standard). As PCI applies to the most industries, we will use that regulation in this example, but we will be focusing on the FortiGate solutions. For additional details on how Fortinet’s other products can address non-network aspects of PCI-DSS compliance, please refer to the latest FortiOS Certification and Compliance guide (http://docs.fortinet.com/fgt/handbook/40mr3/fortigate-compliance-40-mr3.pdf).
Disclaimer
Compliance examples
The scenarios and designs are discussed here to make the reader aware of certain compliance requirements. They are based on the authors’ field experiences. As every network environment varies, so do the ways to meet compliance requirements within them. Please consult a qualified PCI-certified consultant or firm to validate your specific infrastructure.
Example Distributed Enterprise and Retail Environment Topologies
For the deployment example, we’ll highlight the network topology requirements and the common UTM security configuration used to secure the environment for both distributed and core locations.
Network Layout
A distributed environment with the following infrastructure and communication requirements:
1. A remote FortiGate would be deployed in a layer 3 route/NAT mode, which would have two network segments: a private LAN (RFC1918 IP numbering) called Remote_LAN and the Internet.
2. Remote User access would include individual home office workstations, laptops, and mobile devices via the Internet.
3. All remote offices and users must communicate to their company headquarters securely via an IPSec VPN (named Remote_VPN) to access critical resources. In a retail environment, the credit card data leaving the point of sale (POS) system would also be routed securely to the processing server. To meet PCI compliance, the POS data must be separated from other traffic. Therefore, it is essential to have a separated IPSec VPN tunnel (Remote_POS_VPN) to isolate the POS traffic from other traffic heading to the company’s headquarters.
4. Internet access to remote offices would be restricted for web and ftp.
5. Remote access to the Intranet web site is to be limited to only GET and POST requires. Uploading of files and web server “write” access is prohibited.
6. Corporate email is using FortiMail to provide dedicated Anti-spam/Anti-virus for company email.
7. To limit data leaks, the headquarters (HQ) is prohibited from originating communication to remote users.
8. The HQ FortiGate will be deployed in a layer 3 route/NAT mode, which would have three network segments: a private LAN (HQ_LAN), a private DMZ (HQ_DMZ), and an Internet segment with high-speed connectivity. End-user workstations will reside on the HQ_LAN and company servers will be on the HQ_DMZ segment. Communication must take place securely between all HQ network segments.
9. Remote and HQ FortiGates will be centrally managed by a FortiManager at HQ.
10. All FortiGates will log to a FortiAnalyzer at HQ to provide a centralized log repository and reporting on all devices.
Common UTM Deployment Configuration
Continuing with the topology depicted in Figure 11.1, the data and security requirements are:
• To secure communication between a remote location and HQ, a gateway-to-gateway IPSec VPN is required. For retail environments, there would be two separated IPSec VPN tunnel configurations: Remote_POS_VPN and Remote_VPN.
• VPN traffic would operate in a split tunnel configuration, where corporate traffic would route through the VPN and all other traffic would be routed to that location’s Internet Service Provider.
• It is recommended that IPSec be deployed in an interface-based configuration. With an IPSec interface-based configuration, VPN routing between route locations and HQ can be easily implemented using a dynamic routing protocol (OSPF, BGP, RIPv1/v2, ISIS) or static routes.
• All DNS queries would be resolved at the FortiGate local to that network. Thus, FortiOS would be used to handle split DNS, forwarding company-specific domain queries though the VPN and all other queries would be sent to the ISP-defined DNS server.
• To further protect infrastructure from network threats, access controls and UTM features are defined for all communication paths. The following security access control policies are needed on each Remote FortiGate:
- Policy from Remote_LAN to Remote_VPN:
- Firewall or Application Controls: Access controls will be implemented up to layer 4 and/or 7 on permitted traffic to HQ to control access to corporate email and intranet web servers. This would permit only the services SMTPS, POP3S, IMAPS, HTTP, and HTTPS services. All other services will fall under an implicit deny rule.
- IDS/IPS profile: This profile will be tuned to the allowed services and the applications to which they connect.
- In remote retail environments, the policy dictating traffic between Remote_LAN and Remote_POS_VPN will be controlled as follows:
- As the primary purpose of the Remote_POS_VPN is for POS credit card transactions, access control will be implemented up to layer 4.
- The IDS/IPS profile will be tuned to allowed services & application threats.
- The traffic between the Remote_LAN and the Internet will be controlled as follows:
- NAT will provide translation between the private network and the Internet.
- Firewall or Application Controls will be defined to only allow HTTP, HTTPS, and FTP.
- The network Anti-virus profile will be applied to web and FTP.
- The IDS/IPS profile will be tuned to allowed services & application threats.
- The Web Filtering profile will be tuned to allow only specified web categories.
- The implicit deny policy will be used to restrict the following packet flows:
• The IPSec VPN tunnel will terminate at the HQ. The VPN will be in a split tunnel mode, so corporate-related traffic will route through the VPN and all other traffic to the Internet local to that location.
• To further secure and protect the end-user’s workstation, it is recommended that each endpoint run client software that provides the following:
- Web Filtering—this is not necessarily to restrict the end-user from limited web browsing which is an additional layer to filter out malicious web sites.
• Must have the ability to terminate the IPSec VPNs and process traffic through from remote locations and users.
• Interface-based IPSec configuration is recommended. With this configuration, routing decisions can be easily implemented using dynamic routing protocol (OSPF, BGP, RIPv1/v2, ISIS) or static routes.
• To further secure and protect the infrastructure from network threats, access controls and UTM features will be defined on all communication pathways. The following security access control policies are needed:
- Traffic from Remote_VPN to HQ_LAN is to be permitted. Since the remote FortiGates have access controls defined along with UTM-enabled inspection capabilities on the VPN tunnel, there is no need to double system resources. However, to ensure that this does not create a weakness, the configuration of the remote devices must be monitored.
- Retail traffic, from the Remote_POS_VPN to the HQ_LAN will be permitted with up to layer 4 controls on the source to protect credit card data. Additionally, the IDS/IPS profile will be tuned to protect the allowed services and applications.
- The policies between the HQ_LAN and the Internet and the HQ_DMZ and the Internet will be controlled as follows:
- NAT will be used to provide translation between the private network and the Internet.
- Firewall or Application Controls would be defined to allow only HTTP, HTTPS, DNS, and FTP. Since the users at HQ are not using the FortiGate as a DNS server then DNS must be explicitly allowed on both TCP and UDP DNS ports. Network Anti-virus must be enabled for web and FTP.
- IDS/IPS profile is to be tuned to allowed services and application threats.
- Web Filtering profile is to be used to restrict access to only allowed web categories.
- Traffic from Internet to the HQ_DMZ must use a Virtual IP (VIP) or one-to-one static port forwarding to allow email traffic to the Anti-spam gateway relay and the IDS/IPS must be tuned to mail-related threats.
- Traffic from the HQ_LAN to the HQ_DMZ will be controlled with either the Firewall or Application Controls to allow only DNS, SMTPS, POP3S, IMAPS, HTTP, and HTTPS. The IDS/IPS profile will be tuned to protecting these services.
- The implicit deny policy will be used to restrict traffic between the Internet and the HQ_LAN, the HQ_DMZ and Remote_VPN, the HQ_DMZ and the HQ_LAN and the HQ_LAN and the Remote_VPN. The latter couples with the fact that the policy is defined to only allow inbound traffic to the HQ_LAN, so this zone should have no reason to connect outwards.
Tip
Policy for using FortiGate as a DNS server
There’s no need to add DNS service to a rule if end users are pointing their system’s DNS server settings to the FortiGate for processing.
Figure 11.1 Distributed Network Topology
Best Practices
There are some standard practices for a distributed environment with remote locations and users.
Routing Decisions
Network connectivity from remote sites to HQ_LAN will rely on an IPSec gateway-to-gateway tunnel. You should use an Interface-based IPSec VPN for this as they provide a robust way to scale VPN configuration, access control, and routing capabilities. See Chapter 5 for more information on Interface vs. Policy-based IPSec VPN.
An interface-based IPSec VPN can make routing decisions for both static and dynamic protocols. Generally speaking, unless static routes are unmanageable in your environment (usually due to sheer number of routes), the administrative simplicity of static routing is preferable.
Whether static or dynamic routes are used, you should review the maximum values of your model of FortiGate. As smaller devices support fewer routes, the number of potential remote devices and networks will identify the devices you require. This type of an assessment is part of the sizing requirements covered in Chapter 3. Consider the following:
When using static routing, determine the number of routes needed between the remote sites and HQ. Also consider the likely number needed in the future.
If using dynamic routing instead, count the maximum number of routes likely to be needed and check that the existing FortiGate can handle both the number of routes and the number of neighbors to the HQ location.
Also, check the IPSec phase1 and phase2 capacity on all FortiGates, especially the HQ. When using interface-based IPSec VPNs, also check the supported interface count.
Access Controls
Tuning the firewall rules requires an understanding of both the network communication and the organization’s security policy. In an enterprise environment, it is common to tune firewalls at layers 3 and 4, but complexity could arise at other layers. A common problem involves the use of application controls, as many network administrators are not application experts. If you are in this situation, it may help to apply the access control discovery process to application control. Typically, you can leave open access but enable logging so applications can be discovered. This is best done by using FortiOS to define rules up to layer 4, so everything can be locked down to the application layer and then tightened as the discovery process allows. Leveraging the FortiAnalyzer to provide historical logging and data mining capabilities, application reports can be generated to help identify which applications are and are not required.
In our example environment, distributed retail processing involves credit card information being transmitted over the network. It is critical to control traffic into and from these cardholder data environments. Firewall rules affecting this traffic require explicit definition of the allowed source, destination, and service. All unspecified traffic would be blocked. Isolating the cardholder data onto its own network segment can help reduce the PCI scope, but is not technically required. For example, if all POS systems are connected to a dedicated subnet and do not mix with other systems, they can be isolated onto their own VLAN or physical connection.
Since FortiOS can define firewall rules based on the direction of VLAN communication, it can be used to manage critical compliance requirements. Since, in this example, there is a need for POS credit card information and data network communication to occur between remote FortiGates and corporate headquarters, the POS traffic must be segregated from other traffic via dedicated IPSec VPN tunnels. When used with interface-based IPSec tunnels, the routing decisions and access controls can be easily configured and controlled based on the direction of flow between tunnel interfaces.
In addition to our example, other types of network segmentation are seen in enterprise and retail environments. These vary from multiple network paths to the use of non-conventional devices with built-in IP stacks. The network communication flows, however, some network access and security protection will be required. Figure 11.2 shows various network devices that can be segmented onto dedicated physical, logical (VLAN or wireless), or VDOMs for further access controls and UTM security protection.
Figure 11.2 Various Network Segmentations
Examples of segmentation access control includes:
a. Route traffic destined to the Internet through an alternate access method. These often include analog modems, 3G or 4G mobile connections, or dedicated DSL or Cable lines. These connectivity options can be configured for redundancy. Based on layer 2-link status or layer 3-connectivity integrating with the Ping Server feature, failure within these layers can be detected. The FortiGate can be used to leverage static- or dynamic-routing and restrict access to specific paths with firewall rules. Basic load balancing with Equal Cost Multiple Path can be used to take advantage of multiple ISPs (see Chapter 4 for further details).
b. Dedicated POS machines used for credit card processing.
c. Isolated digital signage used for advertisement, menus, or informational purposes.
d. Security cameras used to monitor employee activities and customer use of counter applications.
e. Dedicated classes of Workstations to be used by employees, guests, or customers.
f. Kiosks used for advertisement, in-store online ordering, or for informational purposes.
g. Mobile network/internet access used by employees, guest, or customers.
Note
Multiple Wireless segments
As highlighted briefly in Chapter 2, Fortinet wireless solutions offer multiple SSIDs, each with its own network fully isolated from each other segments using UTM controls. A location could have one SSID wireless for customer/guest usage and another SSID for employee usage.However, if this is done to provide access on the wired side for credit card transactions, be aware that the PCI-DSS wireless rules will still apply, as the FortiGate device itself would be considered in scope.
The examples provided are not complete, as technology evolves, segmentation access controls will also continue to evolve.
Authentication
Authentication can be considered as another layer defense. In the example environment, remote VPN user authentication would provide an excellent additional protection. This way, if an employee were to leave the company, their login credentials could be easily removed from the supported authentication servers (local database, TACACS+, RADIUS, LDAP, and FortiToken) used for the remote VPN authentication. Without a VPN authentication infrastructure, maintaining users’ VPN access could be unmanageably complex.
Implementation of remote IPSec VPN users’ authentication can be accomplished with the XAuth (Extended Authentication) feature covered in Chapter 5. For remote users using the SSL VPN, the authentication mechanism is built into the web browser or the standalone tunnel application.
For the retail distributed environment that must conform to PCI-DSS, two-factor authentication is required for remote VPN users to access the data network. Two-factor authentication is possible with IPSec VPN using XAuth and the FortiToken solution.
Additionally, PCI requires that administrators follow specific password requirements to access the FortiGate. These include a minimum password length of at least seven characters, passwords that contain both numeric and alphabetic characters, and a password change enforced every 90 days (http://docs.fortinet.com/fgt/handbook/40mr3/fortigate-compliance-40-mr3.pdf).
Splash screen and web page redirects are optional and can be applied during authentication. A splash screen could consist of a list of terms and conditions with acceptance as shown in Figure 11.3. If an end-user does not accept the disclaimer then they will be denied access to the network.
Figure 11.3 Splash Screen Disclaimer Web Page
When the wireless feature is used with the FortiGate, a captive portal can be enabled for each SSID, which can provide both terms and conditions and enforce authentication. Figure 11.4 displays an example of a captive portal session.
Figure 11.4 Wireless Captive Portal Disclaimer and Login Web Page
Web page redirects can be configured so users’ browsers default to the company website instead of the locally defined home page. Web page redirects can be configured without authentication, after accepting disclaimer, or after authentication.
Applying UTM Security Profiles
Consider the differences between the UTM profiles defined in the remote site policy definitions for Remote_LAN to HQ_VPN vs. Remote_LAN to Internet. There is no web filtering profile defined on the rule “to HQ_VPN”. The reason there is no need for a web filtering profile on the “to HQ_VPN” rule is, when Remote_LAN accesses only a handful of company web servers, there is no need to perform this function. Having the web filtering profile on the Remote_LAN to Internet policy makes more sense since there are many web site accesses that need to be controlled and monitored.
Also, consider Anti-virus profiles. Anti-virus inspection is supported for web, email, ftp, nntp, and some IM protocols. Therefore, there is no reason to inspect traffic that does not include these protocols. Additionally, if the Anti-virus services are used in the policy, there are times when virus inspection is not necessary, such as the Remote_LAN to HQ_VPN route.
As noted in the Network Topology infrastructure and communication requirements, Remote_LAN communicates to intranet web servers but only via HTTP/S GETs and POSTs. Now, when the intranet site is used as a file repository, using an Anti-virus profile would be wise. Furthermore, with this same policy, email traffic is expected, but since the company is using a dedicated solution (FortiMail) for Anti-spam/Anti-virus of their email, additional inspection on the FortiGate would be redundant. In scenarios where a third-party Anti-spam solution is used at headquarters, it may make sense to enable Anti-virus inspection and Anti-spam on email protocols to provide a second layer of email security which leverages different Anti-virus and Anti-spam databases.
Suggested Maintenance and Monitoring Operations
When there’s a distributed network infrastructure consisting of five or more deployed devices, managing them individually could be cumbersome. Therefore, it is generally recommended to use a central management solution like FortiManager. As discussed in Chapter 9, the FortiManager provides a central management interface for all devices.
More importantly for our example, PCI-DSS requires that logs be retained for a specific period of time. A FortiAnalyzer (Chapter 8) can be used for reporting and data mining. An alternative option to log from the FortiGate devices would be syslog. Configuration for logging to a syslog server from FortiGate can work in parallel with the FortiAnalyzer. Redundant servers can also be defined.
As the distributed environment grows, it is always important to monitor system resources used by the overall security infrastructure. Examples of system resources include CPU, memory, and local storage on the FortiGate. The variables that affect CPU and memory are related to static and run-time features. Static features include an increase in the number of IPSec tunnels, concurrent sessions, static routes, learned dynamic routes, firewall rules and objects, and other variables outlined in the FortiOS Maximum system value guide (http://docs.fortinet.com/fgt/handbook/40mr3/fortigate-max-values-40-mr3.pdf). Run-time features include things like the increased amount of traffic needed for UTM processing. A common example would include using proxy-based Anti-virus scanning where a compressed file must be loaded into memory, uncompressed, then scanned from beginning to end. This can take an unpredictable amount of memory along with ASIC & CPU processing. When the overall system CPU and/or memory hits critical metrics, such as consistent 90–100% CPU or 80%+ memory usage, it is generally a good indication that you have outgrown that particular FortiGate’s ability to handle the load.
Before upgrading the solution to a higher-end FortiGate model, it is highly recommended to first contact Fortinet TAC to assess whether any sort of known issue is causing the high system resources. During this assessment, the TAC would generally provide advice on tuning the system reduce resource usage. FortiGate system resource tuning tips can also be found in the Fortinet Knowledge Base (http://kb.fortinet.com), search for ‘conserved mode’.
If one needs to lower system resource utilization and there is some budget available, you may wish to consider an Active/Active High Availability deployment. As described in Chapter 4, Active/Active HA leverages the FortiGate Clustering Protocol (FGCP) to load balance TCP traffic to other FortiGate devices in the cluster. The ability to offload TCP traffic can decrease system utilization on the primary FortiGate. Given that the majority of the UTM inspection is based on TCP-related traffic such as web and email, offloading these services provides room for growth. For optimal performance, it is recommended that an HA FortiOS FGCP cluster be limited to up to five devices.
In a retail distributed environment where PCI-DSS compliance is required, wireless monitoring is essential. Whether the remote sites or HQ have wireless deployed, you must monitor for rogue wireless access points. This can be done with either the FortiGate models with built-in 802.11 AP (access point) functions or the standalone FortiAP. FortiAP can be implemented to work with most FortiOS devices, so they can act as a wireless controller to manage the FortiAP. A FortiAP can dedicate a radio for monitoring for unauthorized devices (see Chapter 3—FortiAP). Rogue device detection can be logged and optionally configured to be suppressed/blocked from company’s network.