What Do the Watson Computer and Network Security Have in Common?

Are you still writing rules for old firewalls? Dealing with ports and protocols is no longer sufficient. Next-generation firewalls drill into traffic to identify the applications traversing the network, and automation can help you build and manage the rules you need to exploit this technology.

By Reuven Harrison, Chief Technology Officer, Tufin Technologies

When the Watson computer beat two all-time "Jeopardy!" champs earlier this year, few of us were surprised. There are some things computers excel at,and parsing big data haystacks for answer needles is one of them. When it comes to analyzing line after line of repetitive information, computers are simply more efficient and accurate than the human brain. Organizations that embrace this kind of automation anywhere in their IT environments are focusing computing resources where they're needed most, which is why most well-designed security automation products tend to deliver significant cost savings and reduce risk.

One area reaping the benefits of automation these days is perimeter security. Few security technologies are more mature or have more enterprise penetration than network firewalls. When the first firewalls were introduced, few people foresaw that rule sets would become so large and complex. Furthermore, most organizations need more than one firewall to protect perimeters and sensitive internal network segments. Multiplying the exponential growth of the number of firewall rules across multiple firewalls spread across multiple data centers, geographies, and vendor platforms makes manual management of rule sets a virtually impossible task for the security teams of medium to large organizations.

Add to the mix the need to manage ongoing compliance mandates (for example, PCI DSS requires quarterly firewall audits), and an already complex management scenario further intensifies. In addition to security and compliance risks, a poorly maintained rule base can also impact performance. The entire rule base is parsed from top to bottom with every network connection, and as the rule base grows, hardware requirements also increase. The more bloated the rule base becomes with rules that are obsolete, redundant, or otherwise not needed, the greater the processing strain on the device - which can result in firewall hardware burning out before its time.

If all these factors aren't enough to set the stage for automation, then the emergence of application-aware or "next-generation" firewalls as the Next Big Thing in firewall technology certainly does.

Unlike traditional stateful firewalls, which deal in ports and protocols, next-generation firewalls drill into traffic to identify the applications traversing the network. A next-generation firewall is a gateway device that looks at a packet from more than just a simple Layer-3 perspective to determine whether it should be allowed through a port. It looks at Layers 3 through 7 and gains an application-level understanding of the packet, allowing it to make more sophisticated decisions.

Technically, we have had the capacity to do next-gen firewall computing for some time, but few enterprises had a pressing need for an application-aware firewall until we had core business services running through port 80 (the standard port for web traffic). Over time, HTTP has become a platform running countless individual applications (or services, in firewall-speak) -- chat, video, file transfer, social networks, games, and even enterprise applications such as Salesforce.com. These applications are all going over the Internet, so network firewalls lump a vastly diverse set of business applications together because all they can see is if they are HTTP or HTTPS applications, to be routed through Port 80 (for HTTP) or Port 443 (for HTTPS). As a result, hackers target their attacks at these ports, knowing that such traffic to the firewall looks like legitimate Web traffic.

Fast-forward to today. Having the ability to filter and manage traffic at the application level increases the relevance of firewalls, but with this new responsibility comes added complexity. Because businesses need to change over time, so do firewall rules. Determining if a change on a network firewall introduced a new threat has already become incredibly hard to do without automation. Rule changes on next-gen firewalls are even harder because they are application-, identity-, and content-aware. Crafting -- not to mention auditing -- granular, application-aware policies and rules are harder -- much harder -- because there are so many more possible decision points.

A typical firewall rule consists of four fields -- source, destination, service (port), and an associated action (such as "Allow," to allow traffic through or "Deny" to block traffic). With network firewalls, the source was always an IP address, regardless of what it represented: a server, a laptop, or a desktop. With next-gen firewalls, the source field becomes much more granular, consisting of User identity (based on information from Active Directory or LDAP, for example), Location, Device Type, Device Status, and Authentication Type (such as RADIUS, TACACS, etc).

A next-gen firewall should be able to understand if an access request originates at the perimeter or is coming out of a VPN connection, and if the end user is using an iPad, Blackberry, or corporate laptop, at Starbucks or at its own headquarter's inner wireless connection. The source field should also tell whether the user was authenticated just with a single factor or a super-secure connection with biometric authentication. Instead of writing a generic rule such as "Allow server A to connect to server B on port 80," firewall administrators can write laser-focused rules: "Allow Joe to use Facebook at 1pm, but block him from using Farmville if he's on his iPad" or "Always block Flickr and YouTube traffic regardless of which port it's being transported on." If rule sets on last-gen devices have become too complex to manage without automation, just imagine how complex the rule sets on next-gen firewalls are.

In the past, adoption of next-generation firewall functionality has lagged, in part because the technology wasn't sufficiently mature and because administrators didn't have the time to spend on complex rule building and audits. Now, the technology has matured, but administrators still don't have the time to spend on even more complex rule building and audits. If anything, they have less time and more on their plate. Without Watson-computer-like automation to manage, change, and audit-rule configurations across all the firewalls in the enterprise, the cost of managing of next-gen firewalls can skyrocket. Sure, the firewall administrators could write simple last-gen rules for the next-gen devices, but then why invest in better firewalls if you don't plan on leveraging the technology as it was designed?

With proper automation, that problem disappears and humans can focus their time and attention on more pressing strategic matters -- such as creating standardized best practices, fine-tuning the corporate risk management framework, or even planning the implementation of the next, next-gen technology. These tasks are critical to the evolution of an organization's network security operations, but, unlike firewall policy management, they don't lend themselves to automation.

Quite the contrary -- future planning and creative problem solving demonstrate the best use of the creativity and ingenuity of the human brain. By accurately assessing what parts of their jobs would most benefit most from the use of Watson-like automation, savvy operations teams can reap all the time and cost savings it offers, providing them with the breathing room needed up to elevate their role to new heights.

"Jeopardy," anyone?

Reuven Harrison is a co-founder and the chief technology officer at Tufin Technologies, a network security company that over the past seven years has pioneered the development of firewall management solutions. Reuven has a diverse background, including a degree in Mathematics and Philosophy from Tel Aviv University and more than 20 years of software development experience (including four years at Check Point Software). Reuven can be reached at Reuven@tufin.com