FRirewalls and information flow control policy

-------------------------------------------------------------------

This document is not part of the "Zorp Anatomy" series.
It does not talk about the inner workings of Zorp,
but talks about more general questions related to firewalling.

Thanks to Attila Kósa for asking the questions.

-------------------------------------------------------------------

One function of firewalls is controlling the information flow.
In other words the firewall should enforce the organisational information
flow control policy. This is a mandatory access control policy,
and because of its mandatoryness, it should be enforced in all
mechanisms of the organisation pertaining to information, not
just IT.
All of the current network perimeter security solutions (nearly all,
because we have the DragonFly) solves this problem by giving more
or less (less) effective tools to the hand of firewall administrator
to enforce a discretionary access control policy. From this
discretionary access control we will create mandatory access control
by hoping that the firewall admin
1. respects the information flow modell
2. have the necessary information on the security properties of
 the objects and subjects
3. the tools used are adeqate to enforce the information flow control
 policy
4. did not do a mistake, or if did, this mistake can be detected and
 corrected

Let's see the above points one by one

1. It is very rare that we even have a formulation of the information
flow control bolicy beyond such vague definitions like "the sensitive
data of the organisation should be protected" or "resources of the
organisation should be protected from unauthorized access".
From these expressions one can draw an information flow control policy
with more or less difficulties, but it is very rare.
Because of that the firewall administrators used to configure the
rules by intuition, and have hard times explaining the reasons
for them to those who are not interested in security.

2. As soon as a system exceeds the size which can be overviewed by
one individual (I can show an example where it is succeded in one
single PC:), there will be some delimination of functions ideally.
It is often comes with the fact that the enforcement of security
policy and the knowledge of security attributes will not be focused
in the same brain. This problem is more acute than it seems to be:
the security attributes are defined by the user and developer/integrator
in a way that they don't even know that they do it. The firewall admin
can try to dig it up from them, but it is very hard. This can be
made much easier by making definition of security attributes an
explicit activity without which the system does not function.

3. It os not easy to build a timber house with a penknife. The
packet filtering routers and firewalls can solve some very basic
problems. To enforce the information flow policy, you need more, like
covert channel reduction. Given the current state of network protocolls,
the firewall have very few chance to do it, even if it can handle every
single protocol element. Even Zorp is not close to this goal,
and other firewalls have no chance in it. 
Let's consider its configuration overhead. With a configuration
based on discretionary access control you will have configuration
items on the magnitude of (N*K)*(N*K-1)/2*(P*Q), where
N=number of hosts, K=number of security levels by hosts,
P=number of protocols, Q=number of protocol elements by protocol.
With 10 hosts and 5 protocols you have 7500 things to configure
theoretically, and it is even something in order of 3000 in
practice. This can be lowered by clever configuration tricks,
until you arrive to the concept of describing not the connections
but the definition of objects and subjects. Because the rest
is a function of it.

4. Everyone make mistakes (even me very rarely:). It os more so if
you have to configure 3000 things in one afternoon. In this cases it
is helpful if you have only few possibilities to err. For example the
system is failsafe. It seems that a connection does not adhere to the
information flow control policy? The firewall logic should deny it.
The firewall admin have a relatively good feedback this way: the user
will cry if a connection is really needed. The number of security
attributes is fewer than the number of firewall rules with discretionary
access control. That means that overviewing the attributes is not too complex,
and simple rules based on zone hierarchy (like the ones in the current
Zorp policy) make pinning the problems more easy, or lessen the
number of attributes to overview drastically.
And another advantage: this way delimination of functions can say
that defining security attributes is not the role of the firewall
administrator. One less problem:)