Security policy language

[Marco Cremonini <cremonini () dti unimi it>]

Thank you all for your comments.
However, there is something I'm still missing from what has been  
said: why are we thinking to a single, complete and comprehensive  
policy language rather than to more languages used to express the  
same policy by different people?

I mean, I agree with all of you that the definition of a complete  
security policy language is almost impossible and probably useless.  
And absolutely agree with Marcus that at the end the complexity will  
become overwhelming.

Jean-Denis wrote that "The problem is that the main part of a  
security policy is not technical but
organizationnal, and have to deal with human behavior!", many of you  
said the same thing and I perfectly agree.
For the same reason we always speak different "languages" with  
different people even when talking about the same issue, and this is  
what I'm thinking to, let people at different organizational levels  
express the security policy, for what they are in charge of, in a  
language that they can understand and we can parse.

For instance, Tina's example "No personal use of Company X e-mail  
facilities is allowed."  is typical enterprise level policy which is  
actually a fuzzy poorly-defined problem from a technical standpoint  
but that's the current enterprise language and often the language  
used by many privacy protection & data management laws and  
regulations. And such vague statement must still be enforced by  
someone in some technical way.

We miss a logical mapping between the meaning of "personal use"  
specified by the enterprise-level policy and all fitering and denials  
implemented somehow by a security admin to enforce it.

The consequence is that no functional constraint can be automatically  
produced from the enterprise statement for the low-level security  
policy (say for instance a content inspection device configuration)  
and there is no way to automatically (or semi-automatically) check  
whether the actual security configuration complies with the "personal  
use" defined by the enterprise policy.

The whole mapping between the enterprise policy and the configuration/ 
verification is a manual task that a human must do, and we all know  
that it is perfectly fine when humans are skilled, expert,  
collaborative etc., but unfortunately this is not the case in most  
situations.

Couldn't we think to different security policy languages, at  
different abstraction layers to let people speak their "own" language?
From an enterprise policy we could derive logical constraints for  
the lower level that could be, say, an "administration level" that  
adds more details about the meaning of "personal use" like, for  
instance "no picture or multimedia attachment can be exchanged", and  
so on until the technical security policy that must specify ports, IP  
addresses or configuration files of security devices.

With a framework that maps policies at different logical levels, a  
partial automatic definition/verification of the security  
configuration with respect to the enterprise security policy  
(perhaps ...) could be done. We avoid fully automated solutions that  
have already proved to be a wrong path but still we could drive  
security configurations.

Ok, I know that this is probably (or certainly) completely  
unrealistic because for real-world policies the complexity is still  
overwhelming, but, at least in theory, why not thinking to a layered  
security policy with every layer expressed with a language that  
people logically in charge of that layer can understand?

Stephen, is this something that resemble somehow to your "think about  
think about developing a grammar specification"?

marco

===================================
Marco Cremonini
Dept. of Information Technology
University of Milan
cremonini at dti.unimi.it
===================================



_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards