1 / 30

Believing the Integrity of a System

Believing the Integrity of a System. Simon Foley Department of Computer Science University College Cork Ireland. ARSPA 2004 Workshop on Automated Reasoning for Security Protocol Analysis. UCC Security Research Distributed Systems. Distributed security architectures. [Mulcahy,Quillinan]

malise
Download Presentation

Believing the Integrity of a System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Believing the Integrity of a System Simon Foley Department of Computer Science University College Cork Ireland ARSPA 2004 Workshop on Automated Reasoning for Security Protocol Analysis

  2. UCC Security ResearchDistributed Systems • Distributed security architectures. [Mulcahy,Quillinan] • Trust Management. [Quillinan,zhou] • Secure Middleware interoperation. [Quillinan,Mulcahy] • Secure Virtual Organizations. [Zhou] • Supporting enterprise security given many users, components, complex procedures, … • but, how does one know whether security has been configured properly?

  3. UCC Security ResearchSecurity Analysis • Security modeling/analysis • access-control, non-interference, … • authentication, non-repudiation, … • non-functional properties. • Properties difficult to model/analyze. • Focus on mechanism validation, does not scale well to enterprise; should consider users, procedures, etc. • May encourage de-clarification:compute not your immature gallinaceans prior to them being produced.

  4. Security Research at UCCConfiguration Analysis • Formal methods `lite’: shallow and pragmatic analysis methods for systems. • Analyze how a system is configured rather than analyzing its underlying mechanisms and protocols. • Secure Interoperation [with Bistarelli,O’Sullivan]. • Secure Services Configuration [with Aziz,Herbert,Swart]. • Integrity [constraints: Bistarelli]. • Encourage clarification: don’t count your chickens before they’re hatched!

  5. Outline of Talk • Introduction • Ad-hoc Approaches to Integrity • Formalizing Integrity • Towards a Logic of Integrity • Conclusions

  6. Security Policy Principal Do Operation Reference Monitor Resource Prevention of unauthorized modification of information. Application System may also contribute to integrity Conventional Integrity Models

  7. Integrity Mechanisms • Access Controls • Well Formed Transactions • Separation of Duties • Cryptographic MACs • Batch Totals • …

  8. validate update trans dep Customer dishonest clerk atm Account dishonest programmer clerk withdraw System ExampleBank Account Management Well formed transaction Access Control Separation of duty Does this system have integrity?

  9. Integrity Models/Criteria • Biba Model, US-DOD Yellow Book, RBAC, Clark Wilson US-Model, GOA Yellow Book, … • Operational/access control oriented models that define how to achieve integrity but not what it is. • Ad-hoc criteria providing for `best practice’. • No guarantee that a user of the system cannot use some unexpected but authorized circuitous route to bypass integrity controls.

  10. Account Integrity of the Enterprise • To properly define integrity it is necessary to model system and infrastructure • Even if the system is functionally correct the infrastructure is likely to fail: SW,HW, users! validate update trans dep Customer atm Infrastructure withdraw System Enterprise

  11. Sample Procedure PURCHASE ORDER PAYMENTS (FIN-P202) GUILFORD COUNTY SCHOOLS 1.0 SCOPE: 1.1 The process for making payments to vendors for purchases initiated by purchase orders. 2.0 RESPONSIBILITY: 2.1 Accounts Payable Technician 3.0 APPROVAL AUTHORITY: […] 4.0 DEFINITIONS: […] 5.0 PROCEDURE: 5.1 Upon receipt of the Vendor’s Invoice AP Technician attaches the yellow copy of the purchase order and the green receiving copy. 5.2 AP Technician checks for errors, makes any corrections, applies audit stamp and initials on invoice. 5.3 Batches of invoices are keyed into the AS400; after each batch an edit report is run and checked and any errors are corrected. 5.4 Batch totals are given to APPA for check printing, APPA submits checks, print registers and submits to accounting; transactions are then closed out for posting. 5.5 AP Technicians receive checks from Data Processing; check copies are attached to invoices and forwarded to accounting for auditing. 5.6 Accounting audits copies and notifies AP of problems; AP makes any necessary changes. 5.7 Accounting returns check copies to AP Technician for filing and distributes checks to vendors. 6.0 ASSOCIATED DOCUMENTS: […] 7.0 RECORD RETENTION TABLE: […] 8.0 REVISION HISTORY: […]

  12. What is System Integrity? • External consistency: “[…] correct correspondence between the data object and the real world.” [ClarkWilson] • Integrity: dependability with respect to absence of improper alteration [IFIP WG10.4] • Dependability: property of a computer system such that reliance can be justifiably placed on the service it delivers [IFIP WG10.4].

  13. Formalizing IntegrityDependability as Refinement • Define the service that system provides. • Refine this to a system implementation that provides this service and is robust to failures in its infrastructure. • system||infrastructure is as dependable as service at its interface.

  14. dep Customer Acct with Bank Service Requirements Service Interface = {dep,with} Acct(0) = dep gAcct(1) Acct(i) = dep gAcct(i+1) [] with gAcct(i-1)

  15. validate update trans dep Customer atm Clerk with Account System Bank Implementation Sys(0) = trans g Sys(1) Sys(i) = (trans g Sys(i+1)) [] (with g Sys(i-1)) Clerk = dep g trans g Clerk Clerk = (dep gClerk) [] (trans gClerk) Enterprise

  16. Bank Dependability • If clerk follows procedures then (Sys(0)||Clerk) is as dependably safe as Acct(0) at the interface {dep,with}. • (Sys(0)||Clerk)@{dep,with} refines Acct(0) • If clerk does not follow procedures then • (Sys(0)||Clerk)@{dep,with} refines Acct(0) • Model threats within infrastructure.

  17. Account ExampleSeparation of Duty • If one clerk follows procedures then (Sys(0)||Clerk1||Clerk2)@{dep,with} refines Acct(0) validate update trans dep Customer log audit atm withdraw System

  18. External Consistency • External consistency: “[…] correct correspondence between the data object and the real world.” [ClarkWilson] • No observable difference (at interface I) between system with reliable infrastructure and the system with unreliable infrastructure. system||infrastructure =I system||infrastructure

  19. validate update trans dep Customer atm Account Clerk withdraw System Enterprise ExampleMACs for Integrity • cheque deposits; protected by MACs • Dishonest clerk cannot forge new transactions • System can determine freshness of transaction • External consistency at {dep,with} (sys(0)||clerk)@{dep,with}=(sys(0)||clerk)@{dep,with}

  20. Threat AnalysisBehavior Paradigm • Integrity Analysis: study effects of normal versus abnormal infrastructure behavior. • Authentication Protocol Analysis: study effects that a generic attacker can have on protocol behavior. • Abnormal infrastructure as a collection of different attackers. • Will approach scale to large configurations?

  21. DeclarificationBank Configuration Analysis • freedom from guile or fraud constitutes the most excellent principle of procedure. • honesty is the best policy.

  22. Threat AnalysisLogic Based Paradigm • Simplify analysis by making only the needed distinctions and no more. • Authentication protocol analysis: behavior of adversary is implicit in deduction rules. • Integrity analysis: infrastructure behavior implicit in deduction rules.

  23. Towards a Logic of Integrity • Principals: users, components, … • Formulae • P believes X • P said X • consistent(X) • Propositional logic operators • and, or, g • K-Axiom • P believes (XgY), P believes X P believes Y

  24. Integrity Analysis • Principals: • Customer, ATM, Clerk, … • Assumptions about principals • Cust believes consistent(dep), … • Idealization of enterprise operation • ATM said consistent(acct) • Goals • Cust believes consistent(acct)

  25. Bank ATM AnalysisCustomer Assumptions • If satisfied, ATM updates account • Cust believes (ATM believes consistent(dep) g (consistent(acct)) • ATM is honest • Cust believes (ATM said X g ATM believes X) • ATM only says things than can be believed • Cust believes ATM believes ((Cust believes X) g X) • Deposit is correct • Cust believes consistent(dep)

  26. Bank ATM Analysis Operation and a Goal • ATM operates properly on deposit • Cust believes (ATM said Cust said consistent(dep)) • Verifiable Goal • Cust believes consistent(acct)

  27. Bank ATM AnalysisSeparation of Duty • Clerk validates deposit. • Cust believes Clerk said Cust said consistent(dep) • One of ATM and Clerk honest • Cust believes (ATM said X g ATM believes X) or (Clerk said X g Clerk believes X) • Error reconciliation is honest • Cust believes (ATM believes consistent(dep) or clerk believes consistent(dep)) g consistent(dep)

  28. Conclusions • Existing integrity approaches ad-hoc. • Scalability of behavior approach • Logic approach has disadvantages. • Variant of Simple Logic, with freshness, cryptographic channels, etc. • Analysis tool based on Theory Generation. • Configuration synthesis. • Cleave gramineous matter for fodder during the period that the orb is refulgent. • Make hay while the sun shines • Advert: funded PhD position available, starting October 2004.

  29. Conclusions • Cleave gramineous matter for fodder during the period that the orb is refulgent. • Make hay while the sun shines • Advert: funded PhD position available, starting October 2004.

More Related