Re: Intrusion Detection and Secuirty Policy

[David Collier-Brown <david.collier-brown () canada sun com>]

Bill_Royds () pch gc ca wrote:
| One problem that a  needs to be addressed is a "Security Policy Language"
| which would be a formal notation for writing security policies that would
| be both
| explainable to managers and executives and verifiable in a formal sense.
| There has been work done on this in programming language verification
| (Euclid and stuff from late 70's) but it ended up being too "mathematical"
| for real world use. The tradeoff between ease of use and completnenss has
| always been one of the deisgn problems in all computer software. It is a
| hard problem as any firewall  make can tell you. If you make a nice
| friendly GUI to sell the product, it becomes an obstacle to actually using
| the product in daily business.

        Hmmn...  I just came off a project involving an **engineering-level**
        specification language, were we found that working at the level
        of assertions (exactly as per the ASSERT macro) covered a very
        big set of what we needed to do.

        They were almost too hard for normal programmers: I admit I
        often wrote them backwards during the first months (:-))
        
        As a formal tool, they're rather low-level, and had to be
        extended with implication for a few things (such as saying
        ``if arg2 includes FOO_BIT, arg3 must be non-null'' as
        (arg2 & FOO_BIT == FOO_BIT) -> arg3 != NULL) and seperate
        statements for preconditions and postconditions, in the
        few cases here they were relevant.
        
        Higher-level constructs (protocols) can be expressed in 
        assertions, and, if you're carefull, can be recognized
        in assertions by pattern matching.


| 
|    Perhaps the next security product is not at the detection level but at
| the policy generation level. An expert system that allows one to view
| security policies so that the expected behaviour of both the people and the
| system is compared with past experience and with required data to monitor
| this behaviour. THis kind of high thought level software has always been
| harder to create than circuit level stuff, but it is the most important for
| actually getting results.

        I'll suggest that you can do this at a level **rather like** the
        circuit tools, if you have a small set of operators and operands,
        and well-known realtionships like DeMorgans law...

        As a side note, many firewall filter languages read
        a lot like assertions with hidden ANDs between the rows.

--dave 

David Collier-Brown,  | Always do right. This will gratify some people
185 Ellerslie Ave.,   | and astonish the rest.        -- Mark Twain
Willowdale, Ontario   | davecb () hobbes ss org, canada.sun.com
M2N 1Y3. 416-223-8968 | http://java.science.yorku.ca/~davecb