Even with more advanced features and supposed higher throughput than ever before, firewalls are not able to keep up with modern demands or advanced threats. Users are more distributed than ever, and so is data. Threats are
Your network is more complex than ever before. Your employees are accessing any application they want, using work or personal devices. Often times, these applications span both personal and work related usage, but the business and security risks are often ignored. Prospective employees are asking about application usage policies before accepting their new job. Adding another layer of complexity is the concern about the effectiveness of your cybersecurity posture. Is your business a target for a cyberattack? Is it a question of when, as opposed to if? And are you as prepared as you could be? The complexity of your network and your security infrastructure may limit or slow your ability to respond to these and other cybersecurity challenges.
When increasing complexity limits or slows the decision-making process, it's always helpful to focus on the fundamentals. Remember the three fundamental functions that your firewall was designed to execute:
Over time, these fundamental functions were nullified by the very traffic they were meant to control. Applications evolved at a faster pace than the firewall. As a result, these firewalls have trouble exerting the control needed to protect digital assets.
Port hopping, the use of non-standard ports and the use of encryption are a few of the ways in which applications have become more accessible. These same techniques are also used by cyberattackers, both directly in the cyberthreats they create and indirectly by hiding the threats within the application traffic itself. Further complicating these challenges is the fact that your employees are using these applications to get their jobs done. Some examples of the applications and threats found on your network include:
To address these challenges, there has been an increased focus on the fundamentals of the firewall. Every network firewall vendor is rethinking how they identify and control traffic based on the application itself, instead of just the port and protocol. Collectively, firewalls that are capable of exerting an application-centric approach to firewall control are now described as "next-generation," and every firewall vendor acknowledges that application control is an increasingly critical part of network security.
There are two obvious reasons for this renewed focus on the fundamentals. First, applications and the associated threats can easily slip by port-based firewalls as well as the additive threat prevention elements. Second, the firewall is the only place at which all the traffic flowing across your network is seen, and it is still the most logical location to enforce access-control policies. The value of this renewed focus is obvious: Your security posture should improve, while the administrative effort associated with firewall management and incident response should shrink or, at a minimum, remain constant.
The next-generation firewall is well defined by Gartner® as something new and enterprise-focused, "incorporating full-stack inspection to support intrusion prevention, application-level inspection and granular policy control." Most network security vendors are now offering application visibility and control by either adding application signatures to their IPS engine or offering you an add-on license for an application control module. In either case, these options are additive to a port-based firewall, and do little to help you focus on the fundamental tasks your firewall is designed to execute.
How effectively your business operates is heavily dependent upon the applications your employees use and the content that the applications themselves carry. Merely allowing some, then blocking others, may inhibit your business. If your security team is looking at next-generation firewall features and capabilities, the most important consideration is whether the next-generation firewall will empower your security team to safely enable applications to the benefit of the organization. Consider the following:
If the answers to the above questions are "yes," then your decision to transition from legacy firewalls to next-generation firewalls is easy to justify. The next step is to consider the alternative solutions that firewall vendors are providing. When evaluating the available alternatives, it is important to consider the architectural differences between the next-generation firewall offerings and the associated impacts in terms of real-world functions/features, operations and performance.
In building next-generation firewalls, security vendors have taken one of two architectural approaches:
Both approaches can recognize applications, but with varying degrees of success, usability and relevance. Most importantly, these architectural approaches dictate a specific security model for application policies – either positive (define what is allowed; deny all else), or negative (define what to block; allow all else).
The remainder of this Buyer's Guide is broken down into three sections. The first section introduces 10 Things Your Next Firewall Must Do, which should be viewed as proof points that the architecture and control model outlined above are critical to delivering on the promise of identifying and safely enabling applications at the firewall. The remaining sections delve into how these 10 things should be used to select a vendor through the request for proposal (RFP) process and how you should physically evaluate the firewall solution.
Firewall selection criteria will typically fall into three areas: security functions, operations and performance. The security functions element corresponds to the efficacy of Firewall selection criteria will typically fall into three areas: security functions, operations and performance. The security functions element corresponds to the efficacy of the security controls and the ability of your team to manage the risk associated with the applications that are traversing your network. From an operations perspective, the big question is, "Where does application policy live, and how hard or complex is it for your team to manage?" The performance difference is simple: Can the firewall do what it's supposed to do at the required throughput your business needs? While each organization will have varied requirements and priorities within the three selection criteria, the 10 things your next firewall must do are:
Business case: Application developers no longer adhere to standard port/protocol/ application development methodology. More and more applications are capable of operating on non-standard ports or can hop ports (e.g., instant messaging applications, peer-to-peer file sharing, or VoIP). Additionally, over non-standard ports (e.g., RDP, SSH). In order to enforce application-specific firewall policies where ports are increasingly irrelevant, your next firewall must assume that any application can run on any port. The concept of any application on any port is one of the fundamental changes in the application landscape that is driving the migration from port-based firewalls to next-generation firewalls. Any application on any port also underscores why a negative control model can't solve the problem. If an application can move to any port, a product based on negative control would require beforehand knowledge or have to run all signatures on all ports, all the time.
Requirements: This one is simple. You must assume that any application can run on any port, and your next firewall must classify traffic by application on all ports all the time, by default. Traffic classification on all ports will be a recurring theme throughout the remaining items; otherwise, port-based controls will continue to be outwitted by the same techniques that have plagued them for years.
Business case: A small number of the applications on your network may be used to purposely evade the very security policies you have in place to protect your organization's digital assets. Two classes of applications fall into the security evasion tools – those that are expressly designed to evade security (e.g., that can be adapted to easily achieve the same goal (e.g., remote server / desktop management tools).
RDP and TeamViewer, are typically used by support and IT professionals to work more efficiently. They also are frequently used by employees to bypass the firewall, establishing connections to their home or other computer outside of the network. Cyberattackers know these applications are commonly used, and there are publicly documented cases in both the Verizon Data Breach Investigations Report (DBIR) and the Mandiant® report where these remote access tools were executed in one or more of the attack phases.
To be clear, not all of these applications carry the same risks – remote access applications have legitimate uses, as do many encrypted tunnel applications. However, these same tools are increasingly being adopted by attackers as part of their ongoing persistent attacks. Without the ability to control these security evasion tools, organizations cannot enforce their security policies, exposing themselves to the very risks they thought their controls mitigated.
Requirements: There are different types of circumvention applications – each using slightly different techniques. There are both public and private external proxies (see proxy.org for a large database of public proxies) that can use both HTTP and HTTPS. Private proxies are often set up on unclassified IP addresses (e.g., home computers) with applications such as PHProxy or CGIProxy. Remote access applications such as RDP, TeamViewer or GoToMyPC have legitimate uses, but due to the associated risk, should be managed more closely. Most other circumventors (e.g., Ultrasurf, Tor, Hamachi) have no business use case on your network. Regardless of your security policy stance, your next firewall needs to have specific techniques to identify and control all of these applications, regardless of port, protocol, encryption, or other evasive tactic. One more consideration: Applications that enable circumvention are regularly updated to make them harder to detect and control. So it is important to understand that your next firewall should identify these circumvention applications; it is also important to know how often that firewall's application intelligence is updated and maintained.
Business case: Currently, SSL accounts for about 14 percent of global application traffic bandwidth . Given the increasing adoption of HTTPS for many high-risk, high-reward applications that end-users employ (e.g., Gmail, Facebook), and users' ability to force SSL on many websites, your security team has a large and growing SSL-encrypted traffic. Certainly, a next-generation 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 HTTPS from unclassified websites in Eastern Europe) can be decrypted via policy. SSH is used nearly universally and can be easily configured by end users for non-work purposes in the same manner that a remote desktop tool is used. The fact that SSH is encrypted also makes it a useful tool to hide non-work related activity.
Requirements: The ability to decrypt SSL is a foundational element – not just because it's an increasingly significant percentage of enterprise traffic, but also because it enables a few other key features that would end up incomplete or ineffective without the ability to decrypt SSL. Key elements to look for include recognition and decryption of SSL on any port, inbound and outbound; policy control over decryption, and the necessary hardware and software elements to perform SSL decryption across tens of thousands of simultaneous SSL connections with predictable performance. Additional requirements to consider are the ability to identify and control the use of SSH. Specifically, SSH control should include the ability to determine if it is being used for port forwarding (local, remote, X11) or native use (SCP, SFTP and shell access). Knowledge of how SSH is being used can then be translated into appropriate security policies.
Business case: Application platform developers such as Google , Facebook, Salesforce or Microsoft provide users with a rich set of features and functions that help to ensure user loyalty but may represent very different risk profiles. For example, allowing WebEx is a valuable business tool, but using WebEx Desktop Sharing to take internal or regulatory compliance violation. Another example may be Google Mail (Gmail) and Google Talk (Gtalk). Once a user is signed into Gmail, which may be allowed by policy, they can easily switch context to Gtalk, which may not be allowed. Your next firewall must be able to recognize and delineate individual features and functions so that an appropriate policy response can be implemented.
Requirements: The ability to decrypt SSL is a foundational element – not just because it's an increasingly significant percentage of enterprise traffic but also because it enables a few other key features that would end up incomplete or ineffective without the ability to decrypt SSL. Key elements to look for include recognition and decryption of SSL on any port, inbound or outbound; policy control over decryption; and the necessary hardware and software elements to perform SSL decryption across tens of thousands of simultaneous SSL connections with predictable performance – an additional requirement to consider.
Requirements: Your next firewall must continually classify each application, monitoring for changes that may indicate when a different function is being used. The concept of "once and done" traffic classification is not an option as it ignores the fact that these commonly used applications share sessions and support multiple functions. If a different function or feature is introduced in the session, the firewall must note it within the state tables and perform a policy check. Continual state tracking to understand the different functions that each application may support, and the different associated risks, is a critical requirement for your next firewall.
Business case: Unknown traffic exists in small amounts on every network, yet to you and your organization, it represents significant risks. There are several important elements to consider with unknown traffic. Is it categorized? Can you minimize it through policy control? Can your firewall easily characterize custom your firewall help you determine if the unknown traffic is a threat?
Unknown traffic is also strongly tied to threats in the network. Attackers are often forced to modify a protocol in order to exploit a target application. For example, to attack a web server, an attacker may need to modify the HTTP header so much that the resulting traffic is no longer identified as web traffic. Such an anomaly can be an early indication of an attack. Similarly, malware will often use customized protocols as part of its command and control model, enabling security teams to root out any unknown malware infections.
Requirements: By default, your next firewall must classify all traffic on all ports – this is one area where the earlier explanation about architecture and the security control model becomes very important. Positive (default deny) models classify everything; negative (default allow) models classify only what they're told to classify. Classifying everything is only a small part of the challenge that unknown traffic introduces. Your next firewall must give you the ability to see all unknown traffic, on all ports, in one management location and quickly analyze the traffic to determine if it is (1) an internal or custom application, (2) a commercial application without a signature, or (3) a threat. Additionally, your next firewall must provide you with the necessary tools to not only see the unknown traffic but to systematically manage it by controlling it via policy, creating a custom signature, submitting a commercial application PCAP for further analysis, or performing a forensic investigation to determine if it is a threat.
Business case: Organizations continue to adopt a wide range of applications to enable the business – they may be hosted internally or outside of your physical location. Whether it's hosted by SharePoint®, Box.com, Google Docs™, Microsoft Office 365™, or an extranet application hosted by a partner, many organizations
SSL or can share files. In other words, these applications may enable the business, but they can also act as a cyberthreat vector. Furthermore, some of these applications (e.g., 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 blindly allowing the applications and the (potential) associated business and cybersecurity risks.
This tendency to use non-standard ports is highly accentuated in the world of malware. Since malware resides in the network, and most communication involves a malicious client (the malware) communicating to a malicious server (command and control), then the attacker has full freedom to use any port and protocol combination he chooses. In fact, in a recent three month analysis, 97 percent of all unknown malware delivered via FTP used completely non-standard ports.
Requirements: Part of safe enablement is allowing an application and scanning it for threats. These applications can communicate over a combination of protocols (e.g., SharePoint uses CIFS, HTTP and HTTPS, and requires a more sophisticated firewall policy than "block the application.") The first step is to identify the application (regardless of port or encryption), determine the functions you may want to allow or deny, and then scan the allowed components for any of the appropriate threats – exploits, viruses/malware, or spyware, or even confidential, regulated, or sensitive information.
Business case: Your users are increasingly outside the four walls of the organization, oftentimes accessing the corporate network on smartphones or tablets. Once the domain of road warriors, now a significant portion of your workforce is capable of working remotely. Whether working from a coffee shop, applications via Wi-Fi, wireless broadband, or by any means necessary. Regardless of where the user is, or even where the application being employed might be, the same standard of firewall control should apply. If your next firewall enables application visibility and control over traffic inside the four walls of the organization, but not outside them, it misses the mark on some of the riskiest traffic.
Requirements: Conceptually, this is simple – your next firewall must have consistent visibility and control over traffic, regardless of where the user is. This is not to say that your organization will have the same policy for both; for example, some organizations might want employees to use Skype™ when on the road, but not inside headquarters, where others might have a policy that states users may not download Salesforce. com attachments unless they have hard-disk encryption turned on. This should be achievable on your next firewall without introducing significant latency for the end user, undue operational hassle for the administrator, or significant cost for the organization.
Business case: Many organizations struggle with incorporating more information feeds, more policies, and more management into overloaded security processes and people. In other words, if your team can't manage what it's already got, adding more devices, managing interfaces along with associated policies and information doesn't help you reduce your team's administrative effort nor does it help reduce incident response time. The more distributed the policy is (e.g., a port-based firewall allows port 80 traffic, IPS looks for and blocks threats and applications, and a secure web gateway enforces URL filtering), the harder it is to manage that policy. Which policy does your security team use to enable WebEx? How do they determine and resolve policy conflicts across these different devices? Given that typical port-based firewall installations have thousands of rules, adding thousands of application signatures across tens of thousands of ports is going to increase complexity by several orders of magnitude.
Requirements: Your business is based on applications, users and content, and your next firewall must allow you to build policies that directly support your business initiatives. Shared context across the application, user, and content in all aspects – visibility, policy control, logging and reporting – will help you simplify your security infrastructure significantly. A firewall policy based on port and IP address, followed by separate policies for application control, IPS and anti-malware will only complicate your policy management process and may end up inhibiting the business.
Business case: Many organizations struggle with the forced compromise between performance and security. All too often, turning up security features on your firewall means accepting significantly lower throughput and performance. If your next-generation firewall is built the right way, this compromise is unnecessary.
Requirements: The importance of architecture is obvious here too – in a different way. 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. From a software perspective, the firewall must be designed to do this from the beginning. Furthermore, given the requirement for computationally intensive tasks (e.g., application identificati on, threat prevention on all ports, etc.) performed on high traffic volumes and with the low tolerance for latency associated with critical infrastructure, your next firewall must have hardware designed for the task as well – meaning dedicated, specific processing for networking, security and content scanning.
Business case: Many organizations struggle with the forced compromise between performance and security. All too often, turning up security features on your firewall means accepting significantly lower throughput and performance. If your next-generation firewall is built the right way, this compromise is unnecessary.
Requirements: The importance of architecture is obvious here too – in a different way. 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. From a software perspective, the firewall must be designed to do this from the beginning. Furthermore, given the requirement for computationally intensive tasks (e.g., application identificati on, threat prevention on all ports, etc.) performed on high traffic volumes and with the low tolerance for latency associated with critical infrastructure, your next firewall must have hardware designed for the task as well – meaning dedicated, specific processing for networking, security and content scanning.
Business case: The explosive growth of virtualization and cloud computing introduces new security challenges that are difficult or impossible for legacy firewalls to manage effectively due to inconsistent functionality, disparate management, and a lack of integration points with the virtualization environment. In order to protect traffic flowing in and out of the data center within your virtualized environments and in the public cloud, your next firewall must support the same functionality in both a hardware and virtualized form factor.
Requirements: The dynamic setup and tear down of applications within a virtualized data center exacerbates the challenges of identifying and controlling applications using a port- and IP address-centric approach. In addition to delivering the features already described in 10 Things Your Next Firewall Must Do in both hardware and virtualized form factors, it is imperative that your next firewall provide in-depth integration with the virtualization environment to streamline the creation of application-centric policies as new virtual machines and applications are established and taken down. This is the only way to ensure you can support evolving data center architectures with operational flexibility while addressing risk and compliance requirements.
Your users continue to adopt new applications and technologies, often times to get their jobs done but with little regard to the associated business and security risks. In some cases, if your security team blocks these applications, it may hinder your business.
Applications help your employees get their jobs done and maintain productivity in the face of competing personal and professional priorities. Because of this, safe application enablement is increasingly the correct policy stance. To safely enable applications and technologies on your network and the business that rides atop them, your network security teams need to put in place the appropriate policies governing use, and also the controls capable of enforcing them.
10 Things Your Next Firewall Must Do describes the critical capabilities that will allow organizations to safely enable application usage and ultimately, the business. The next steps are to translate those requirements into actionable steps by selecting a vendor through an RFP process and formally evaluating solution offerings, ultimately resulting in the purchase and deployment of a next-generation firewall.
Typically, when selecting firewalls, IPS or other critical security infrastructure components, organizations will utilize an RFP as a means of ensuring that the specific needs are addressed. According to the Gartner's Magic Quadrant for Enterprise Firewalls 2016, "Enterprises with traditional firewalls seek to have firewalls that have application and user visibility, and to require enforcement options in their next refresh." As new deployment opportunities occur, organizations should expand their RFP selection criteria to include application visibility and control offered by next-generation alternatives. The previous section established the 10 key requirements your next firewall must do. This section will translate those requirements into tools you can use to identify and select a next-generation firewall.
There are many elements to consider when evaluating how effectively a vendor can deliver application visibility and control in the firewall. The firewall architecture, specifically its traffic classification engine, will dictate how effectively
it can identify and control applications, instead of just ports and protocols. As mentioned earlier, the very first thing a new firewall of any type must do is accurately determine what the traffic is and then use that result as the basis for all security policy decisions.
In this model, the firewall policies are traditional positive control (block all, except that which you expressly allow). A positive model means you can control and enable applications, which is a critical requirement in the always-on, always connected-world that businesses are faced with today. Bolting on IPS-like elements that look for applications means that a negative control model is used (allow all, except that which is expressly denied by the IPS). A negative model means you can only block applications. The differences are analogous to turning the lights on in a room to see and control everything (positive) vs. using a flashlight in a room to see and control only what you are looking at (negative). Using this add-on to identify and block "bad" events is simply a patch and not the full solution because it is designed to look only at a partial set of traffic to avoid impeding performance, and cannot cover the breadth of cyberattacks and applications.
The RFP must determine the details around how the firewall architecture facilitates the identification and control of the entire spectrum of applications including business, personal or other, as well as protocols, no matter which port, SSL encryption or other evasive technique is in use. Consider the following questions and statements when issuing an RFP for next-generation firewalls.
A wide range of applications can be used to circumvent security controls. Some, such as external proxies, and non-VPN related encrypted tunnels are designed with circumvention as a goal. Others, such as remote server/desktop management tools have evolved to where non-IT or non-support staff employees use them to circumvent control mechanisms. As a means of security, SSL is becoming a standard configuration for many end-user applications, yet the problem arises when the use of SSL may be masking inbound threats or outbound data transfer. Today, SSL accounts for about 14 percent of global application traffic bandwidth3 in some way. So it is important to determine the respective next-generation firewall vendors that address this category of applications. Consider the following questions and statements when issuing an RFP for next-generation firewalls.
In today's always-connected world, controlling applications means more than merely allowing or denying; it is about safely enabling applications to the betterment of the business. Many "platforms" (Google, Facebook, Microsoft) make different applications available to the user after their initial login. It is imperative that you determine how the firewall vendor monitors the state of the application, detects changes in the application, and classifies the change in state. Consider the following questions and statements when issuing an RFP for next-generation firewalls.
Every network has some unknown application traffic; the typical source is an internal or custom application, but it may also be an unidentified commercial application or, worst case, some malicious code. The key elements to determine through the RFP and the evaluation process are a specific description of how the vendor enables you to systematically manage the unknown traffic, which represents a higher business and security risk. Consider the following questions and statements when issuing an RFP for next-generation firewalls.
Threats are increasingly tied to a variety of applications both as vectors for exploits and infection as well as ongoing command and control of infected devices. For this reason, analysts are consistently recommending that enterprises consolidate traditional IPS and threat prevention technologies as a component of the next-generation firewall. Consider the following questions and statements when issuing an RFP for next-generation firewalls.
Modern network users assume the ability to connect and work from many locations beyond the traditional perimeter of the network. These users must remain protected even in instances where they are beyond the network perimeter, using a PC, a smartphone or a tablet. The goal of this section is to determine what capabilities are available to secure these remote users and how this level of protection differs when the user is on or off of the physical network. Consider the following questions and statements when issuing an RFP for next-generation firewalls.
Management is a critical element for implementing effective network security. In moving to your next firewall, a key goal must be to simplify security management wherever possible by adding application visibility and control. Consider the following questions and statements when issuing an RFP for next- generation firewalls.
Real-world performance is a critical component of a security deployment. Application control requires a far deeper investigation of traffic than port-based firewalling and as such, is far more computationally intensive. Adding threat inspection and policy control to that same traffic only adds to the processing burden placed on the firewall. It is critical to determine the performance on the network when all security features are enabled and analyzing a real-world mix of traffic. Consider the following questions and statements when issuing an RFP for next- generation firewalls.
Your firewall must provide a flexible networking architecture that includes support for dynamic routing, switching and VPN connectivity, and enables you to deploy the firewall into nearly any networking environment. Consider the following questions and statements when issuing an RFP for next-generation firewalls.
Every organization has varied requirements over and above the items listed within this document. Examples may include company viability, customer references and quality of customer support. The recommended best practices for an RFP are to be very systematic in driving the vendors towards proving that their offering delivers the claimed functionality.
Once the final vendor, or the "short-list" of vendors, has been selected via the RFP, the next step is to physically evaluate the firewall using traffic patterns, objects and policies that are accurate representations of the organization's business. This section provides some recommendations on how to physically evaluate a next-generation firewall. The evaluation will give you the ability to see, in a real-world environment, how well a firewall vendor will address the key requirements. Note that the tests suggested below represent a sample of the next-generation firewall functions required, and are meant as guidelines from which a more detailed, step-by-step test plan can be developed.
The goal of this section is threefold. First, verify that the first task the device under test (DUT) executes is traffic classification based on the application identity, not the network port. Second, verify that the DUT classifies applications regardless of evasive tactic, such as hopping ports, non-standard ports, or other evasive tactic, as a means of enhancing accessibility. Third, determine that the application identity becomes the basis of the firewall policy, as opposed to an element within a secondary policy.
With more and more applications using SSL encryption and the use of SSH for alternative purposes, you need to evaluate the ability to identify and control application using SSL and SSH.
Determine if the application classification mechanisms continually monitor the state of the application, looking for changes in the application, and more importantly, if the change in state is classified correctly. Many "platforms" (Google, Facebook, Microsoft) enable different applications once the user initially logs in. Tracking that change in the application state is a critical component to a next-generation firewall.
Determine the ability for the DUT to identify and control specific functions within an application. Function-level control is critical to enabling the use of an application, yet exerting some level of control to address the associated business and security risks. File transfer is a common example, but other examples may include administrative functions, VoIP features, social media posting, and chat capabilities within the parent application.
All networks have a small amount of unknown traffic, and you need to determine how quickly you can identify what the unknown traffic is and take an appropriate action.
To protect your network, you will need to strictly control the exposure to threats and reliably prevent known and unknown threats present within allowed application traffic. You need to test the ability of the DUT to enforce security in a real-world environment, including previously unknown threats; threats carried by applications running on non-standard ports; and threats obscured by compression, all the while meeting enterprise performance requirements.
First, determine if the DUT can protect remote users by applying the same policy as used internally; and second, determine the management effort and deployment complexity.
You need to look at the complexity of managing the DUT in terms of separate devices, as well as the difficulty (number of steps, clarity of UI, etc.) of the task at hand.
Application control is far more computationally intensive than traditional port-based firewalling, therefore it is critical to validate that the target DUT can perform adequately when identifying and controlling applications.
If target deployment location is a virtualized data center, then you should pick and choose the tests above to ensure that the firewall functionality in a virtualized form factor is adequately tested. For virtualized environments, additional considerations should include:
Verify that the DUT supports a flexible networking architecture that enables you to deploy the firewall into nearly any networking environment.
The evaluation and testing process for network security products will vary from organization to organization, and in nearly all cases, will expand beyond the scope of this document. Examples may include checking the overall stability of the DUT and testing the responsiveness of customer support. The recommended best practices for a firewall evaluation is to build a specific set of evaluation criteria and put each device through the entire suite of tests, documenting in detail the results so that the final selection can be made in a systematic manner.
At one time, the concept of allowing an employee to use an external or personal application for work-related purposes was unheard of. Today, employees are always online and are continually using the latest applications, oftentimes melding personal and work-related usage. Summarily blocking these applications is equivalent to blocking the business.
10 Things Your Next Firewall Must Do validates the fact that the best location to execute secure application enablement is at the firewall by using the application identity and traditional positive control model (firewall) policies that allow administrators to define, based on the business, which applications are enabled and which are denied. It should be clear after using the tools within this document that attempts to claim secure application enablement using a negative control model, IPS-like, bolt-on approach are unrealistic.