November 24th, 1998
3085 ENG II
8:30-9:15 am

In attendance:
Premkumar Devanbu (PD), Michael Gertz (MG), Jim Hoagland (JH), Jeff Rowe (JR), Dan Zerkle (DZ)



Current State of the Proposal
Abstract Focus
Innovative Claims
Next Meeting
  1. Current State of the Proposal
    1. Michael has written a couple of pages. A 4-page technical approach/plan is needed.
  2. Abstract Focus
    1. Policy language has powerful modeling capabilities
    2. Leverage UML and modeling
    3. Tight correlation between description language for system and policies
      1. DZ has a half-implemented language that allows you to model actions directly with systems, services (i.e. sendmail).
      2. The policies are written in terms of actions, services, systems, actions (preconditions and post-conditions)
      3. The language models the user with a set of attributes (ability to carry out actions). The arbitrary user can read a file (world-readable files only). Users without root passwords can never be root. Safety measures prevent root access.
      4. You can search the state of the system and actions available.
      5. Ruleset – rules come with actions and preconditions. The post-condition is that the action is added to the user list.
    4. Traceability and Propagation
  3. Problems
    1. Separation of system and policy.
    2. Current modeling capability is weak.
    3. Static and dynamic
  4. Innovative Claims
    1. Modeling tools and infrastructure including languages, compilers, etc.
      1. Verification, traceability, propagation
      2. Leverage UML tools for security policy modeling
    2. Policy evolution more convenient – make policy implications of system changes obvious
    3. Tight coupling between system and policy
    4. Example: Policy enacted, changes are made, something new is added, policy evolves, possibility that something is missed.
      1. JR: Local policy restricts certain hosts. Service used host-name as access control. Using Sun port-mapper – data portion of packet redirects to other port, so it is possible to circumvent the local policy and have the restrict host gain access
      2. DZ: Explains an example in his modeling system (Graph search algorithm)
      3. PD: A system that misclassifies certain types of files. A description of a service specified by actions. Model services by hand.
    5. PD: Building models from source code
      1. MG: Map UML to security mechanisms
      2. DZ: User gains ability to access systems
    6. MG: Easy to map policy to security mechanism (is not separated)
    7. JR: Scenarios
      1. PD: Behavior of matter – class hierarchy – if inconsistent with ancestors, then raise a flag (preconditions and post-conditions)
      2. DZ: Example: Install a new web server that allows access to a new set of files which may be internal documents. The policy doesn’t change, but there is an alternative entry point. You need to be able to model web servers.
      3. MG: Literature on how to analyze existing systems? Engineering approach – system analysis
        1. JR: SATAN applies
    8. PD: Class framework
      1. DZ: Has a class framework in his system. There are classes of services – a set of variables must be true (Boolean expressions)
        1. Check certain conditions
        2. Abilities of arbitrary functions
    9. Network Management – the science of knowing system protocols, the structure of existing systems, etc.
      1. MG: In a recent workshop on security, one of the main problems was that they just don’t understand existing systems
  5. Next Meeting
    1. Michael and Prem will work on the abstract and confer on Friday. They will send it to Karl.
    2. Jeff/Dan work on Proposal
    3. Meet next Tuesday (to be scheduled)