POLICY GROUP MEETING
November 17, 1998
11:00 – 1:00
3085 ENG II

In attendance:
Karl Levitt (KL), Premkumar Devanbu (PD), Michael Gertz (MG), Brant Hashii (BH), Jim Hoagland (JH), Jeff Rowe (JR), Dan Zerkle (DZ)

TOPICS
First Hour – Dan Zerkle goes over ADAGE
Second Hour – Discussion on Proposal (DARPA 99-10)


    1) Dan Zerkle discusses ADAGE (see handout notes)

    2) Questions on ADAGE:
            a) MG:  Policy for systems that don’t exist?
                    i) DZ: Yes, explained by targets
            b) KL:  Distributed authorization?
                    i) DZ:  Adage doesn’t have a built in authorization database.  It uses an external database authorization system – the Security Policy Database (SPD)

    3) DZ:  Open Issues for ADAGE
            a) The high-level authorization language and IPD are very dependent on each other.
            b) Implementation is in the works.
            c) Language and theory is set.

    4) PROPOSAL MEETING

    5) Try to get abstract out in one week

    6) Brainstorm Proposal Topics

            a) MG:  Use Unified Modeling Language (UML) to develop system or software.  UML already has specific objects, relationships, actions, privileges, users and group written into the language.  Use UML as a tool for the infrastructure.
                    i) Principal way of extending to security.
                    ii) Currently, we focus on policy, not on the system
            b) DZ:  Model systems – see how policy affects the system.
            c) MG:  Specify policy in terms of objects/actions on a system.  Common language to model system and policy together
                    i) UML general model, META model, core model can be used to extend itself
                    ii) Need a language that’s extensible
                    iii) DZ:  Does UML have safety and likeness checks?
                            (1) MG:  No.  DZ:  We can make safety test.
            d) PD:  Policy language – apply to applications
                    i) Scenarios/Systems – How it would work.
            e) DZ:  Response – what services do we cut off?  Services have to have actions disallowed, prioritized
                    i) PD:  The system and model evolve.  Policy components change.
            f) KL:  We’re starting work with TIS – Adaptation systems – no formal view.
            g) PD:  Traceability of requirements – propagation of effects using sovereign solutions
            h) Security Issues
                    i) UML --> Step/integration of how things are operating
                    ii) JAVA --> UML Mapping
                    iii) UML --> Cobra
            i) KL:  Connection of COBRA Security is useful.  The connection of mobile code is useful.  If we use much anti-logic, the proposal will probably be rejected.
            j) MG:  How do they build the system?  Is there a government standard?
                    i) KL:  It’s built through commercial vendors.  Government standards aren’t an issue.
                    ii) HP is currently using ADAGE or UML in security product

            k) Develop scenarios to identify what’s unique about our product
                    i) Leverage
                    ii) UML – system --> Policy
                    iii) DZ:  Automatically model systems
                            (1) See new system that doesn’t work, put up red flag.
                            (2) IDS sees the red flag and disables access.
                    iv) KL – Expressability – policy that can’t be specified in ADAGE
                    v) MG:  Propagation of effects and repair.  New operation in file COBRASs, notify me to change policy
                            (1) DZ:  Policy should be static; the implementation of policy should evolve.  Database of all different available systems
                    vi) MG:  Events – ADAGE Doesn’t have a sequence of actions (in UML).  Build verification technique on UML
                    vii) KL: Built some models tailored to security policy
                    viii) PD:  Rules – add features to UML; extending analysis tools (pull out from source code)
                            (1) Conservative Model
                            (2) KL:  Edit UML – identify parts to change/modify
                            (3) PD:  Pull out models – feed it into UML

    7) Proposal:  $350,000/year

    8) For Next Meeting:
            a) Dan to write scenarios; Prem or Dan will run them by Jeff
            b) Prem to start 100-200 word abstract
            c) Verification tools, changes, extract conservative policy model from code; policy repair tool.