POLICY MEETING
August 11, 1999
3085 ENG II
3:00-4:00pm

In attendance:
Karl Levitt (KL), Michael Gertz (MG), Raju Pandey (RP), Jim Hoagland (JH), Aaron Keen (AK) and Dave Peticolas (DP)

  1. Projecting Policy Down
    1. Object-oriented model - resources, availability, map down, command and control system
      1. Info from source to other source reliably
      2. Translated into other low-level
      3. Sensors that tell if something is wrong.
    2. Trust - Coalition Partners
    3. Dynamic changes to what is allowed
    4. MG: Level of abstraction - specific à global
      1. KL: If there's an attack, need mechanisms to detect and respond
      2. RP: Policy statements - most we can lose is 3 sites
        1. Quantify sites
        2. Translate to low-level policies
      3. KL: Conflict in policy
        1. Local policy - defensive weapons only
        2. Confine to something we can do - automatic programming
      4. RP: Local systems/local policy
        1. MG: Assumption - assume we have all local and global information - not realistic
        2. RP: Don't have to know how they implement policy - only that they can comply. Feasibility can be done at high-level abstraction.
        3. MG: For each translation, must know the source capabilities
          1. Expressiveness of global policy - need resource description -- gives you language to specify policies
          2. Need containment - can't specify more on high-level than you can do at low level
        4. RP: Derive policy bottom-up. Translate top-down
        5. MG: Don't have complete descriptions - translation mechanism is ad hoc.
    5. MG: Need an ontology - vocabulary of domain model - concepts, terms, synonyms. Specify policies - everyone knows how things are related.
      1. Access control mechanism, instances, sub-concepts
      2. KL: Confine program and automatic programming; resource model programs available that can access resources at certain times. Virtual firewalls
        1. Graph or flow model - map virtual resources to concrete resources
      3. MG: First map resources
        1. Relationship among concepts
        2. Mapping from ontology to the system
        3. Reasoning mechanisms at a high level
    6. KL: Reasoning - DARPA is sour on automatic reasoning; CYC
      1. RP: Resource model - low-level
        1. Software architectures - higher level than object level translated into actual implementation. Guide to build your systems
        2. MG: Tricky if you include timing.
    7. RP: List of policies needed.
    8. MG: Classification is needed.
    9. RP: Come up with architecture. Assuming ontology will be complete.
      1. MG: Extend domain model by extending ontology
      2. RC: Policy description language - resource model or ontology
      3. MG: Policy for database schema - structure, relationship more easily
      4. RC: Database schema is static à rich semantics, persistent hierarchies
        1. Certain integrity constraints - no sense to do it in UNIX
        2. Mid-level schema to do grunt-work
    10. KL: Ontology gives us schema. Ontology for policy. Interoperability of languages
      1. Temporal - theoretical measurements
      2. Description framework
      3. Sharable ontology - information systems
      4. Rules à mapping of limited domain