In attendance:
Karl Levitt (KL), Jim Hoagland (JH), Michael Gertz (MG), Kimberly Knowles (KK), Premkumar Devanbu (PD)

General News
Negotiating Software Requirements - Apply it to Security Policies
Policy at the Meta Level
Direction for Policy Group

1. General News
1. PD: John Knight is interested in working with us.
2. Sami may fund our proposal
3. Invite more "children" to the Policy group - Chris Wee, Mark Heckman, Dave Peticolas, Nicole Carlson, Jason Schatz, Brant Hashii, Todd Heberlein, Aaron Keen
4. KL: Baiju from Intel is interested in our policy work - Steven Templeton, Christina Chung and Jim Hoagland's work on more unifying view of policies.
5. Should submit UML proposal elsewhere. Other reviewers like it, but Theresa killed it.
2. Negotiating Software Requirements - Apply it to Security Policies
1. KL: You have a requirements engineer and a requirements customer - ask leading questions to determine needs of customer, in a semi-formal way, possibly using decision tables
2. Apply this method to security policies
1. Cost of particular policies, trade-offs, real-time, organizations struggle with security policy
2. Nick Puketza and Scott Miller are looking at this approach for National Semiconductor
1. How to take policies and enforce them
2. Exposing some issues, but not technical
3. MG: Database - Reliability and Availability Definitions - Math measurements
1. Specifications of a system - monitor and compare them
2. Specifications in terms of components system, possible response. Abstract specification of system, otherwise impossible.
4. KL: LaPrie specified vocabulary for transaction systems. John Knight - formality
5. MG: Describe the expected behavior of a system.
3. Policy at the Meta Level
1. PD: Policy language should be at the Meta level rather than the Object level.
1. PD: Policy affects behavior of interpretator. The policy changes the semantics of programs and changes operation semantics
1. Ex. Proxing policy or sandboxing - simulator
2. MG: Policy is then applied to all programs - applied differently to different programs
2. MG: Where is the meta located?
3. KL: Compositional policies - where you can combine policies MG: Generalization
4. MG: From a database perspective, there are integrity constraints that are correct/incorrect - reactive. Can't specify integrity without a schema. Talk at the abstract level, program or component.
5. KL: No structure - confidentiality and availability constraints
1. Mirose - resource allocation in Raju's model, mobile code
2. CPU access - as a resource for scheduling - what mobile code can do. More than program processes that migrate.
3. MG: Components interact - combine them.
6. KL: Availability related to process hogging resources. Confidentiality - access control, influence models.
7. KL: Commercial opportunities - what policy want/tradeoff
4. Direction for Policy Group
1. PD: General issue, improve techniques, formal specification of policies? Implementation strategies? How to extend policy languages?
2. KL: There is a gap between the hard stuff and policy needs. Struggle with interesting language to express.
3. PD: No good implementation techniques?
4. KL: The basic model is okay, discretionary access, Chinese wall, categorize policy, non-interference.
5. PD: Policy Example - Make contact to buy something, promise to hold it for 3 weeks, electronic contract policy - database constraint - certain transactions are allowed, not allowed. Or is it only a security policy if the big 4 are involved: Privacy, integrity, authenticity
6. KL: Are we attacking system specifications? Too broad.
7. PD: Meta model - resource and operations, when to allow actions
8. MG: Just talk about services and actions, but no resources
9. KL: Tray specification (Prelim question) For any sequence of actions, is it legal? What is the value? It doesn't deal with obligations if its good of obligation
10. PD: Transaction logic - Michael Keifer.
11. KL: LaSCO looking at access control - operations that are allowed as a function of the statement. Enforceable policy within implementation
1. PD: No good examples. Problems are not clear. We can do theoretical work, but…
12. KL: Distribution of patches example at the Seclab
1. How do we state policy in terms of the transaction model?
2. MG: All or nothing principle - something you can enforce. Install it nowhere.
3. KL: Express in terms of transactions. Is that a good idea? Reason about policy, completeness, enforcement, performance, tradeoffs, expressability.
4. KL: Event model
5. MG: Transactions - operational - pre/post conditions
6. KL: 1970s issue is still an issue today.
7. PD: Take language semantics - see how to apply to policy
1. KL: Like liveness? Useful to do. Ideal thing would be a vocabulary or a database of properties
2. MG: Common terminology. In medicine, it's well established.
8. PD: Meta model with Ariel and LaSCO
9. JH: The University of Idaho has a webpage of security term definitions.
10. PR: ZED, VDM, used for safety critical systems. Declarative specifications. OCL - Object Constraint Language. Betty Chang
11. KL: Get group together to discuss policies; specify within framework.
12. PD: Security policies in OCL or UML. Model formal language - use to specify security policies. Jason is interested in UML.