Re: [fw-wiz] Security policy language
- From: "Tina Bird" <tbird@xxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 24 Jan 2007 09:56:19 -0800
Marco Cremonini wrote:
The problem is: We would like to implement/adopt a high-levelspecific fw rules.
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
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
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.
you learned about firewall A to speed up "translation" for firewall B, atFrom there if you're sufficiently stubborn, you might be able to use what
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 goodsince I can't
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
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
- Re: [fw-wiz] Security policy language
- From: Avishai Wool
- Re: [fw-wiz] Security policy language
- Prev by Date: Re: [fw-wiz] Security policy language
- Next by Date: Re: [fw-wiz] Security policy language
- Previous by thread: Re: [fw-wiz] Security policy language
- Next by thread: Re: [fw-wiz] Security policy language