POLICY MEETING
August 25, 1999
3085 ENG II
3:00-4:00pm
In attendance:
Karl Levitt (KL), Michael Gertz (MG), Jim Hoagland (JH), Brant Hashii (BH) and Dave Peticolas (DP)
- Proposals due September 20th
- Develop a policy language
- PLEDGE, ADAGE, John Zao at BBN.COM - already have policy languages sponsored
- Offer reasoning and a model
- Specification at a high level - project down to enforcement sites
- JH: Why operational easier that declarative? Can be extended
- TIS - Policy proposal with Sue Rho - couple policy into mission statement in terms of resources in needs (when/how long)
- Her policy should cover ours.
- MG: Higher order logic to specify any type of policy? What is the problem with using HOL? Developing ontology - it's a design model.
- How to integrate heterogeneous policy? How to establish common policy? Temporal logic, transition graph, deontic language (Cuppens). Modeling concept - abstract à projection problem.
- DP: Don't want to implement relation.
- MG: 3 levels of architecture: conceptual, … physical levels
- KL: Inheritance, extensibility
- HOL: Can write theories, sub-theories, predicates. Formal methods - too abstract.
- MG: Model package - ontology, domain-vocabulary. Conceptualize at domain, provide ontology to access rights
- For specifying policy: at network, host and application level
- Composition (refinement) - system model
- Capability of firewall (connection blocking)
- Achieve policy by blocking certain connections
- Rule for transformation - ad hoc
- Scott Miller's Thesis
- Josh Goodman - Filtering Postures - filtering routers - certain connections don't go through
- No way to enforce some policies - can't specify all the capabilities of a computer - how closely tied policy is to the system
- Projection - deciding on rules for firewall - what engine is going to generate rules - CYC, theorem prover
- MG: Many levels to do reasoning, consistency, completeness, synthesis
- Need examples of policy statements - what can/can't be specified
- Domain is too big or access control
- Safety vs. liveness (not in LaSCO)
- Make policies readable
- Program transformation for executables - rule-driven, large knowledge-base
- Conditional access control
- When a grade for a student can be released
- Liveness - a grade must be released by a certain time
- Projection - prevent something - access control or detection - killing user from system
- Service - software company connect through a network with a web server, database system
- Access control on the database
- Ecommerce service in network environment
- Translate into military environment
- Describe the environment/system/network - computer application
- Iterative process, projection - expert driven
- Proof -checking - user could enforce policy in certain places
- How policies are enforced - by single or many components
- Cost model - properties of web server - $/hour
- Quality of service
- Track history - log -who can access log
- Chinese Wall; deducible security - non interference property
- Level of encryption/authentication needed
- MG: Platform - specific mechanism
- DNS for network
- Security service for DNS
- Policy for each software component
- KL: Store mapping of authoritative service
- Synthesize Steven Cheung systems
- Reactive - recursive, iteratively up and down DNS chain
- Wrapper - product of transformation
- Policy - mechanisms
- Query DNS server - response within two minutes -don't know how to implement
- Assignments
- MG, KL: Outline for proposal
- All: Scenarios for policy
- Mechanisms - what to describe, filtering router, firewall, Miro work, wrapper, how to utilize/administrate the service