> mjr wrote:

> >Marco Cremonini wrote:

> >The problem is: We would like to implement/adopt a high-level
> >specification language for the definition of a security policy,
> >something that should let to specify the policy at organizational
> >level. Such a policy should then be translated into

> specific fw rules.
> Here's one question -- can you actually completely describe a
> sensible policy in terms of just firewall rules?? My guess is
> that to establish a fully worked policy you'll need to include
> user-level specifications, authentication states, log actions to
> take, encryption levels, and potentially even application-level
> controls.

I may be picking nits, but I think the problem is even further up the org
chart than Marcus has described. For the (appallingly) rare organization
that has up-to-date, written policies on (say) network usage, an appropriate
policy statement ends up looking like:

"All network connections entering the Company X corporate infrastructure
must implement strong encryption, certificate- or 2-factor-based user
authentication, and inactivity timeouts of 30 minutes."

[Or the ever-popular *cough* "No personal use of Company X e-mail facilities
is allowed." ;-)]

The policy describes a set of required security features -- it's then
(usually) up to the network and system administrators to figure out how to
create that environment on whichever systems they manage, leading into the
joy of developing processes, system baselines and standard configurations.

Creating a language to describe the enterprise level policy, therefore, is
one big fuzzy poorly-defined problem.

> A typical statement that a fully worked policy might need to
> implement could look like:
> "Allow any users in group FOO to access data from
> table BAR on host BLECH once they have authenticated
> over an encrypted link."

*Then* you get into the horrible situation of having to take the policy
which is "words for humans," determine which of the various systems in an
enterprise will be affected by the policy, and figure out what configuration
changes are required for implementation. As mjr implied, if you're doing it
for a single kind of system -- a firewall -- you've at least got a chance of
summarizing the various properties you can control (userID, usergroup,
network protocol, application layer controls, src/dst address, etc), and
then creating a logical language encapsulating that information.

>From there if you're sufficiently stubborn, you might be able to use what

you learned about firewall A to speed up "translation" for firewall B, at
least if you make sure that firewalls A and B have similar architectures.

But what about the DMZ web server? It allows offsite connections, and you
more than likely have crypto and auth controls on it, but it's fer d*mn sure
that you can't describe its configuration in the same way as you describe
the firewalls. If you don't include it, however, you're missing a
significant point of entry into the environment, and you can't really claim
that your policy language is comprehensive or even close to complete.

> >I'm puzzled because it's not a new problem, but I can't find good
> >references. Several standards, especially in the XML-Web Services
> >area, have been proposed by W3C, OASIS etc., to define security
> >policies, but to me they seem quite useless in our case

> since I can't
> >see how and why Web Services should be integrated in this context.

> I think that may be your problem. What happens is that trying
> to fully specify a policy description language becomes a huge
> plate of spaghetti. Eventually your policy description language
> becomes, urrrr, C. So many people who approach the problem
> try to approach it for a simple application: firewall rules or
> XML or whatever. Even that is hard.

The closest I've seen anyone get is Avishai Wool's firewall rules parser.
It's been a couple of years, so I can't speak for its condition now, but at
the time I looked at it it was the nearest thing I'd ever seen to a tool for
comparing firewall security configurations across multiple devices and
(eventually) multiple firewall vendors.

But that's a *long* way from a "security policy language." It's a poorly
defined goal: it incorporates machines, networks, workflow, business
practices *and* political maneuvering all in one big bowl o' muck.

cheers -- tbird

firewall-wizards mailing list