Re: [fw-wiz] Security policy language

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

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

Relevant Pages

  • Re: [fw-wiz] Firewalling at the domain users level instead of network level
    ... security policy. ... > alternatives in terms of security. ... > so different from the ISO-17799 consultants and certifications we were just ... My home firewall isn't a certified product. ...
  • Re: [fw-wiz] Where do firewall Admins Sit in An Company
    ... Security should also be reviewing logs and usage as well. ... constant review and maintenance and firewall policy is no different. ... If the firewall administrators sit in a non-security group what type ...
  • Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
    ... people who should be writing security policy for deployment are those ... also known as "security professionals". ... IOW smack may be great idea, but you written it in wrong language. ... while you should have written it in SELinux policy ...
  • Re: open port w script or....
    ... tx for the help, but when i check GP, i only find a policy to control the ... security center, not the firewall, can you specify where I can find that? ... > Microsoft MVP - Windows Security ...
  • Re: Do I need a firewall
    ... The default policy of just about every decent firewall out there ... to stop an infected server causing havoc elsewhere on the net. ... >configuring the OS for high security seems the best and most affordable ...