10 things your next firewall must do

As hackers ramp up network attacks, end point protection is a first line of defense.


10 ways your next firewall needs to protect your network

Palo Alto Networks started selling next-generation firewalls in 2007 and has gathered critical and specific requirements from thousands of clients, and that guidance is the basis for formulating this list of requirements for key capabilities for network firewalls.



1. Identify and control applications on any port, not just standard ports

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.



2. Identify and control circumventors

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 proxy.org 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 because of the associated risk, these should be managed. Most other circumventors, such as Ultrasurf, Tor and Hamach,i don’t have business uses.



3. 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 (such as 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. 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.



5. Scan for threats in allowed collaboration applications

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. Deal with unknown traffic by policy, but not just by 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.” 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. 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 that often have very different risk profiles and business value. For example, Gmail can 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.



8. Enable the same application visibility and control for all users, whether remote or on-premise

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. Make network security simple, not more complex, by adding application control

Many enterprises struggle with incorporating more information feeds and more policies, and more management into already overloaded security processes and people. 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, 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. Deliver the same throughput and performance if application control is fully activated

Many enterprises struggle with the compromise between performance and security. Typically, turning up security features means turning down throughput and performance. If your 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. Given the requirement for computationally intensive tasks performed on high traffic volumes with the low tolerance for latency associated with critical infrastructure, your firewall should have hardware designed for the task as well—meaning dedicated and specific processing for networking, security (including SSL termination) and content scanning.



Looking for more?

The complete report from Palo Alto Networks is available here.



More for you

Loading data for hdm_tax_topic #care-team-experience...