In attendance:
Karl Levitt (KL), Nicole Carlson (NC), Jim Hoagland (JH), Chris Wee (CW), Rick Crawford (RC)

TOPICS:

Review Proposal Tasks
Advantage of Using LaSCO over GrIDS
Next Meeting

1) Review Proposal Tasks a) Take LaSCO policies and translate them into GrIDS rulesets.

b) Modify GrIDS to allow addition of new rulesets and features. (This has become necessary).

c) Design and implement a tool that translates LaSCO to GrIDS

i) JH: Overall strategy for converting a LaSCO policy into a GrIDS graph is to have the GrIDS graph represent a partial match of the system to LaSCO policy. Any graph that you have, the ruleset is a partial template of the policy.

ii) JH: Tricky aspects – can’t do it with standard GrIDS ruleset language. Label policy edges A & B. A & B could be part of the same match or may not be. KL: Match both of them – the order is not specified. JH: A&B are domain predicates. A type of policy edge that will include the system edge.

(1) KL: You would set up a separate graph. Complicated – you could get another A coming in. Then dispose of graph, then use as a requirement. iii) JH: Introduce typing mechanism (as a ruleset enhancement). You have a list of types listed in the ruleset, for each type it matches to send it through the ruleset at that type. X comes in, matches a. It allows you to create multiple copies of an edge for this kind of scheme. (1) CW: Could we just allow it to create multiple copies without a typing function?

(2) JH: Yes, probably, but the typing function is cleaner.

(3) CW: Expose policy to ruleset rider? JH: Yes. Alternative to precondition rule. With existing precondition rule, they say whether they want the edge for the graph.

(4) KL: GrIDS is type-less right? RC: User-defined types.

(5) CW: Introducing typing into a conventional programming language can help with writing programs, because you clarify your thinking about data and variables. It’s not clear the rule writer knows what he will be seeing, I’m not sure it adds anything.

(a) JH: Aimed towards translating LaSCO policies into GrIDS rulesets automatically. I want this type of traffic to match this edge.

(b) CW: You could do that without exposing the typing in the GrIDS rulesets. Is the idea to change the GrIDS ruleset or translator?

(c) JH: Optional ruleset feature they could use if they want to. You could also use preconditions.

(d) CW: Does it allow attribute labels in GrIDS? Are you extending GrIDS language for "kind"?

(i) JH: It’s special – "kind" attribute can be hidden unless you choose to use it. RC: User-defined enumerated type. The user can feed LaSCO policy into translator, but someone will have to look at the code. It will help debug the translator. 2) Advantage of using LaSCO over GrIDS a) KL: Presumably, you can say things more abstractly in LaSCO – its cleaner. Say everything we want in one graph or several graphs– GrIDS is clumsy.

b) KL: What are some of the abstractions we have in LaSCO that aren’t in GRIDS? Type kinds – domain and requirements

i) JH: Use assessment rules to test requirements.

ii) KL: When you assess a graph (in traditional GrIDS), the key is the number of nodes in the graph. Can you think of uses for that in LaSCO? JH: Only in special cases.

iii) KL: One of main uses for GrIDS is to detect worms. Can you detect a worm in LaSCO?

(1) JH: You could do it, but it would be clumsy. If you’re looking for a certain pattern, you could call it a worm. c) RC: LaSCO policies are easier for people to understand and write. Automatically maps policy to code.

d) CW: Start by mapping out a set of 3 non-trivial examples. Do that with Nicole, who can learn rulesets.

e) JH: We're using most of the features available in GrIDS.

f) JH: Data sources that identify data sources as inputs in LaSCO (provide features that can be referenced in a policy).

g) JH: Domains can also have predicates that restrict. It can make reference to other attributes to the host. What’s important about that is that when you get an edge report in, you can’t tell just by report whether or not it matches. You need to maintain your known state about the host. For each node type and each host, making a different kind of node called a state node that keeps track of other attributes - maintained for each node type and host. That requires extra state. Have it never timeout basically.

i) KL: Some intrusion detection systems actually face this – match activity with pattern – string matching using state machines etc. How complicated does the matching have to get? Arbitrary string matching? Do we so note a match? Do things timeout? (1) RC: More complicated than string matches.

(2) JH: Anything that you can express in a LaSCO predicate, you can enforce in a GrIDS ruleset language with one exception.

(3) Variable added in LaSCO policies, variables to values. One thing we came up with in defining the semantics for LaSCO was variable conditions, a set of established variable bindings and other conditions. What we do in each of these template graphs that we build, we maintain the variable conditions so far.

(a) RC: When false it is as if a timeout had occurred.

(b) JH: You could just ignore it. If you try to merge two graphs, then you try to merge their variable conditions. Or you could essentially destroy it. I propose a mechanism to destroy the attribute, which, if set at the end of all the graph mergings, will be thrown away.

[This figure caption added by JH 5/9/99: The lower 2 graphs on left side were graphs I drew to depict GrIDS ruleset graphs being used as a template for the (abstract) LaSCO policy at the top of the left side (see 1:c:ii in notes above). Here a, b, and x are system edges that match only A, only B, and both A and B, respectively. On the right side, the large node is a depiciton of a state node with maintained attributes d, e, and f, gleened from node reports. Other depictions on that side were part of a disclosure that nodes have types too (something I had not mentioned before for simplicity's sake).]
 
3) Next Meeting a) KL: For next time in two weeks, try Chris suggestions of examples. You might want do rulesets at different levels.
b) JH: We should be able to do that task if we didn't have to worry about it being in a GrIDS hierarchy.