Subject: [OPSAWG] Thoughts on the firewall draft: Policies

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 6 Nov 2012 14:56:55 +0000

http://tools.ietf.org/html/draft-ietf-opsawg-firewalls-01#section-3

I'm copying the list as much as anything to generate discussion and make sure we get the right stuff into the draft.

Thinking about the section on policies, it seems a little disjoint. I find the use of the words "newer" and "modern" a little dismaying; to begin with, I'm not sure that they are newer or even modern; anomaly-based and signature-based intrusion detection has been around for rather a while. The terminology also in effect deprecates the zone-based policy that is in fact pretty common, and is specified in RFC 6092. The notion that firewalls significantly change with the deployment of IPv6 is also, while cherished in some quarters, IMHO naive; if one's corporate policy is that firewalls should implement a certain information security policy with IPv4, I almost guarantee that they will do the same for IPv6 or any other communication service. I think I would prefer to have an actual enumeration and discussion of policies, and leave opinions on them to the "recommendation" sections.

I suspect that there are four broad classes of policy in the field. Happy to hear that there are others. I'm going to state these in Cisco language because I am comfortable with it; if someone else likes other language, I don't have a problem with that - send text.

One is what we call a context-based or zone-based defense. My enterprise network includes some set of systems and connectivity, and I draw a physical or topological perimeter around it. The policy may permit peers outside the domain to access a defined set of systems for a defined set of services - web accesses to the web servers, mail to the mail servers, and so on. Apart from that which is explicitly permitted to be originated from outside the domain, the only sessions permitted to cross the firewall are those that originate from inside the perimeter. To be honest, I think of this perimeter as the CIO peeing on the trees around his territory - he understands that this is prophylactic, and that it provides limited defenses, and uses it as much as anything to take control of his perimeter.

Another is perhaps best described as an open defense. Ingress filtering (filtering of messages based on routing information) is a classic example of this. Even if I have no policy regarding applications crossing my perimeter, I very likely do not permit traffic from outside of my network to provoke attacks within my network. An example of such an attack is someone ending pings to various systems in my network with a source address within, resulting in a ddos on a particular address within my network.

A third, which Warren Kumari commented on, is a policy to interrupt observed attacks. One "observes" an attack using an anomaly-based or signature-based algorithm, perhaps both, and in the event that such an attack is identified, one asks someone upstream to block an identified set of traffic.

A fourth is what we call a role-based defense. In a data center, for example, I may only permit stated sets of tenants to talk with each other. A single administration within the data center may have multiple tenants - storage systems in one, computational resources in another, and so on. Within a corporate network, one frequently finds what look like perimeters around departments like HR or Finance, with anyone in the department being able to access a wide set of resources, but folks outside the department only being able to access a limited set of resources. The screwy thing is that "folks in the department" are one person or one office in each of a number of locations. So the "perimeter" is a set of persons or their computational proxies rather than a physical or topological domain.