Slideshow 10 Things Your Next Firewall Must Do

  • October 18 2016, 6:30am EDT
More in
11 Images Total

10 Things Your Next Firewall Must Do

Palo Alto Networks started selling next-generation firewalls in 2007 and has gathered critical and specific requirements from thousands of clients that informed this list of requirements for today’s next-generation firewalls.

1.<TAB>Your next firewall must identify and control applications on any port, not just standard ports including applications using HTTP or other protocols.

If any application can run on any port, your next firewall must classify traffic by application and on all ports—all of the time. Otherwise, security controls will continue to be outwitted by the same techniques that have plagued them for years.

Content Continues Below

2. Your next firewall must identify and control circumventors: proxies, remote access and encrypted tunnel applications.

There are different types of circumvention applications, each using slightly different techniques. There are both public and private external proxies that can use both HTTP and HTTPS (see for a large database of public proxies). Private proxies are often set up on unclassified IP addresses, such as home computers, with applications like PHProxy or CGIProxy. Remote access applications like MS RDP or GoToMyPC can have legitimate use, but due to the associated risk these should be managed. Most other circumventors such as Ultrasurf, Tor and Hamachi don’t have business uses. Regardless of the policy stance, your next firewall needs to have specific techniques to deal with all of these applications.

3. Your next firewall must decrypt outbound SSL

Today, more than 15 percent of network traffic is SSL-encrypted and in some industries it is more than 50 percent. The firewall must be flexible enough that certain types of SSL-encrypted traffic can be left alone (e.g., web traffic from financial services or healthcare organizations), while other types (e.g., SSL on non-standard ports and HTTPS from unclassified web sites in Eastern Europe) can be decrypted via policy. Key elements to look for include recognition and decryption of SSL on any port, policy control over decryption, and the necessary hardware and software elements to perform SSL decryption across tens of thousands of simultaneous SSL connections with good performance and high throughput.

4. Your next firewall must provide application function control (SharePoint Admin vs. SharePoint Docs)

Many applications have significantly different functions, presenting different risk profiles and value to the user and organization. Examples include WebEx vs. WebEx Desktop Sharing, Yahoo Instant Messaging vs. the file transfer feature, and regular Gmail vs. sending attachments. In regulated environments or in organizations heavily dependent on intellectual property, this is a significant issue. Your firewall should continually evaluate the traffic and watch for changes. If a different function or feature is introduced in the session, the firewall should note it and perform a policy check. Understanding the different functions of each application and the different associated risks is equally important.

Content Continues Below

5. Your next firewall must scan for threats in allowed collaboration applications like SharePoint, and MS Office Online

Many infected documents are stored in collaboration applications, along with some documents that contain sensitive information. Some of these applications, such as Sharepoint, rely on supporting technologies that are regular targets for exploits (e.g., IIS, SQL Server). Blocking the application isn’t appropriate but neither is allowing a threat into the organization. Part of safe enablement is allowing an application and scanning it for threats. These applications can communicate over a combination of protocols (Sharepoint, HTTPS and CIFS), and require a more sophisticated policy than “block application.”

6. Your next firewall must deal with unknown traffic by policy, not by just letting it through.

By default, your firewall should attempt to classify all traffic. This is one area where architecture and security discussion become very important. Positive (default deny) models classify everything, while negative (default allow) models classify only what they are told to classify. For custom developed applications, there should be a way to develop a custom identifier so that traffic is counted among the “known.” The security model plays into these requirements again—a positive (default delay) model can deny all unknown traffic so what you don’t know can’t hurt you. A Negative (default allow) model allows all unknown traffic so what you don’t know will hurt you. For example, many botnets will use port 53 (DNS) for communication back to their control servers. If your next firewall lacks the ability to see and control unknown traffic, bots will be able to drive right through, unimpeded.

7. Your next firewall must identify and control applications sharing the same connection.

Applications share sessions. To ensure users are continuously using an application “platform,” whether it’s Google, Facebook, Microsoft, Salesforce, LinkedIn or Yahoo, application developers integrate many different applications which often have very different risk profiles and business value. Let’s look at Gmail, which has the ability to spawn a Google Talk session from within the Gmail UI. These are fundamentally different applications and your firewall should recognize that and enable the appropriate policy response for each.

Content Continues Below

8. Your next firewall must enable the same application visibility and control for remote users as for on-premise users.

Regardless of where the user is or even where the application they’re employing might be, the same standard of control should apply. If your next firewall enables application visibility and control over traffic inside the four walls of the enterprise, but not outside, it misses the mark on some of the riskiest traffic.

9. Your next firewall must make network security simple, not more complex with the addition of application control.

Many enterprises struggle with incorporating more information feeds and more policies, and more management into already overloaded security processes and people. In other words, if teams cannot manage what they’ve already got, adding more management, policies and information doesn’t help. Further, the more distributed the policy is (e.g., port-based firewall allows port 80 traffic, IPS looks for/blocks threats and applications, and secure web gateway enforces URL filtering), the harder it is to manage that policy. Where do admins go to enable WebEx? How do they resolve policy conflicts across these different devices?

10. Your next firewall must deliver the same throughput and performance with application control fully activated.

Many enterprises struggle with the forced compromise between performance and security. All too often, turning up security features in the network security realm means turning down throughput and performance. If your next-generation firewall is built the right way, this compromise is unnecessary. Cobbling together a port-based firewall and other security functions from different technology origins usually means there are redundant networking layers, scanning engines and policies, which translates to poor performance.