1 / 49

An Integrated Approach to Security Management

An Integrated Approach to Security Management. M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005. Target: A Prototype for Managing Security Goals and Claims. Composing Claims: Given a set of security measures, each resulting in a claim,

dreama
Download Presentation

An Integrated Approach to Security Management

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. An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005

  2. Target: A Prototype for Managing Security Goals and Claims Composing Claims: Given a set of security measures, each resulting in a claim, • Can we add up the claims (resulting from different security measures) in a comprehensive manner? • Can we infer specific security properties (probability/ cost of specific attacks)? • Can we expose redundancies between claims? • Can we expose loopholes/ vulnerabilities?

  3. Target: A Prototype for Managing Security Goals and Claims Decomposing Security Goals: Given a security goal we want to achieve, • How can we decompose it into achievable sub-goals? • Dispatch sub-goals to layers/ sites to maximize impact. • Dispatch sub-goals to methods so as to control (minimize?) verification effort. • Dispatch verification effort to sub-goals so as to control (minimize?) failure cost? Issues: Representing, Reasoning about claims and goals.

  4. Outline • Dependability: A Multi-dimensional attribute • An Integrated Approach to Reliability • A Uniform Representation for Dependability Measures • Inference Rules • General Applications • Specialization: A Prototype for Managing Security

  5. Dependability: A Multi Dimensional Attribute Four Dimensions to Dependability: • Availability: Probability of providing services when needed. • Reliability: Probability of Failure Free Operation. • Safety: Probability of Disaster Free Operation. • Security: Probability of Interference Free Operation (exposure, intrusion, damage). Conceptually orthogonal, actually interdependent.

  6. Availability Depends on: • Reliability. • Repair Time. Dependent on Reliability. Related to Security: DoS affects availability.

  7. Reliability Basic Concepts: • Fault. System feature that may cause system to misbehave. • Error. Impact of fault on system state.Early warning of misbehavior. • Failure. Impact of fault on system (mis) behavior. Observable misbehavior. System feature; State feature; Output feature.

  8. Reliability, II Basic Means: • Fault Avoidance. Fault Free Design. • Fault Removal. Debugging/ Testing. • Fault Tolerance. Error detection and recovery. Three successive, increasingly desperate, lines of defense.

  9. Safety Key Concepts: • Hazard. System feature that makes accidents possible. • Mishap. Operational conditions that makes accident imminent. • Accident. Unplanned, undesirable event. • Damage. Loss that results from an accident.

  10. Safety, II Key Measures: • Hazard Avoidance. Hazard Free design. • Hazard Removal. Intervene before hazards cause accidents. • Damage Limitation. Limit the impact of an accident. Three successive lines of defense.

  11. Reliability vs. Safety

  12. Security Key Concepts: • Vulnerability. System feature that makes an attack possible. • Threat. Situational condition that makes an attack possible. • Exposure/ Attack. Deliberate or accidental loss of data and/or resources.

  13. Security, II Key Measures: • Vulnerability Avoidance. Vulnerability Free design. • Attack Detection and Neutralization. Intervene before Attacks cause loss/ damage. • Exposure Limitation. Limit the impact of attacks/ exposure. Intrusion-tolerance. Three successive lines of defense.

  14. Special Role of Security • Without security, there can be no reliability nor safety. All claims about reliability and safety become void if the system’s data and programs can be altered. • Without reliability, there can be no security. Security measures can be viewed as part of the functional requirements of the system.

  15. Integrated Approach to Reliability • Three Broad families of methods: Fault avoidance, fault removal, fault tolerance. • Which works best? Spirited debate, dogmatic positions, jokes, etc. Pragmatic position: use all three in concert, whenever possible/ warranted.

  16. Rationale for Eclectic Approach • The Law of Diminishing Returns. • Method effectiveness varies greatly according to specification. • Refinement calculus allows us to compose verification efforts/ claims. • Refinement calculus allows us to decompose verification goals.

  17. Mapping Methods to Specifications • Proving: Reflexive, transitive relations. • Testing: Relations that are good candidates for oracles (reliably implemented). • Fault Tolerance: Unary relations that are reliably and efficiently implemented.

  18. Composing Verification Effort • All methods must be cast in a common logical framework. • Refinement calculus (based on relations) offers such a common framework. • Specifications and programs are relations; refinement ordering between relations; lattice properties.

  19. Modeling Verification Methods • Proving: Proving that P is correct with respect to specification V: P  V. • Testing: Certification testing, Oracle , test data D’, successful test on D. P  T, where T = D\ .

  20. Modeling Verification Methods, II • Fault Tolerance: Upon each recovery block, check condition C, invoke recovery routine R. Because we do not which outcome we have each time, all we can claim is: P  F, where F = C  R.

  21. Cumulating Results • Proving:P  V. • Testing: P  T. • Fault Tolerance: P  F. • Lattice Identity: P  (VTF). Cumulating verification results into a compre-hensive correctness claim.

  22. Lattice Properties

  23. Decomposing Verification Goals Premises: • A Complex Specification can be decomposed into simpler sub-specifications in a refinement-compatible manner: S = S1  S2 … SN. • We can consider each SI in turn, mapping it to the method that is most efficient for it.

  24. Mapping Specifications to Methods

  25. A Uniform Representation for Dependability Measures Logical representation of verification results unrealistic: • Most verification results are best viewed as probabilistic, not logical, statements. • Most verification results are conditional, contingent upon different conditions. • Many verification results can be interpreted in more than one way.

  26. Probabilistic (vs Logical) Claims • No absolute certainty. • Even highly dependable, totally formal, verification systems may fail. • We want to quantify level of confidence.

  27. Verification Results are Conditional • Proving: Conditional on verification rules being consistent with actual compiler. • Testing: Conditional on testing environment being identical to operating environment. • Fault Tolerance: Conditional on system preserving recoverability.

  28. Multiple Interpretations • Testing, first interpretation: P  D\ , with probability 1.0. • Testing, second interpretation: P   , with probability p<1.0, conditional on D being representative. Which interpretation do we choose? We do not have to choose, in fact. We can keep both, and learn to add/ cumulate them.

  29. Characterizing Verification Claims • Goal. Correctness preservation, recoverability preservation, operational attribute. • Reference. Specification, Safety requirement, security requirement, etc. • Assumption. Implicit conditions in each method. • Certainty. Quantified by probability. • Stake. Cost of failure to meet the goal; applies to safety and security. • Method. Static vs dynamic, others. May affect the cost of performing the verification task.

  30. Representing Verification Claims • List: (G,R,A,P,S,M) G: Goal; R: Reference; A: Assumption; P: Probability; S: Stake; M: Method.

  31. Sample Representations Certification Testing: • First: Y( , D\, true, 1.0, , Testing), where D is successful test data. • Second: Y( , , A, 0.7, , Testing), where A is representativity of D.

  32. Sample Representations Formal Verification: • First: Y( , R, A, 0.99, , Proving), where R is system specification, A is condition that the verification method is consistent with operational environment. • Second: Y( , R1, A, 0.995, HighC, Proving)  Y( , R2, A, 0.97, LowC, Proving).

  33. Sample Representations Verifying Initialization Sequence with respect to N: Y( , R, A  B, P, , Proving), • R is system specification, • A is condition that the verification method is consistent with operational environment, • B is condition that the body of the system refines right residual of R by N (solution to NX  R). Approach also applicable to regression testing; updating claims after maintenance operation. Open issue: negating, overriding, replacing previous claims?

  34. Sample Representation Safety Measure: Y( , S, A, 0.999, HiC, Proving), Where S is safety requirement, A is consistency of verification method with operational environment, HiC is cost of failing to meet the condition P  S. How does security differ from safety/ reliability: a different goal or a different reference?

  35. Inference Rules • Collecting claims is insufficient. • Cumulating/Synthesizing claims (as we did with logical results) is impractical. • Build inference mechanisms that can infer conclusions from a set of claims. We will explore applications of this capability, subsequently.

  36. Inference Rules Orthogonal Representation, for the purpose of enabling inferences: (S  R | A) = P. Two additional cost functions: • Verification cost: Goal  Ref  Meth  Assum  Cost. • Failure cost: Goal  Ref  Cost.

  37. Inference Rules Derived from refinement calculus: • (S(R1R2) | A)  (SR1 | A)  (SR2 | A). • (S(R1R2) | A)  (SR1 | A) + (SR2 | A). • (S(R1R2) | A)  max((SR1 | A), (SR2 | A)).

  38. Inference Rules Derived from Probability Calculus: • R1R2  (SR1 | A)  (SR2 | A). • (A1A2) (SR | A1)  (SR | A2). • (SR | A  B) = (SR | A)  (SR | B) / (SR). • Bayes’ Theorem.

  39. Inference Rules Derived from Cost functions: • R1R2  VC(,R1, M, A)  VC(,R2, M, A). • (A1  A2)  VC(,R, M, A2)  VC(,R, M, A1). • R1R2  FC(,R1)  FC(,R2).

  40. General Applications Providing dependability: • Deploy eclectic approaches. • Dispatch goals to methods to control verification costs. • Dispatch verification effort to verification goals to control failure costs. • Budget verification cost. • Minimize / assess failure risk (probability, severity of failure).

  41. General Applications Assessing dependability: • Deploy eclectic/ diverse approaches. • Record all measures in knowledge base. • Updating knowledge base as system evolves. • Maximize coverage. • Minimize overlap. • Budget verification cost. • Minimize / assess failure risk (probability, severity of failure).

  42. General Applications Certifying dependability: • Deploy eclectic/ diverse approaches. • Budget certification cost. • Target certification effort (certification goal inferred from claims established by certification activity).

  43. Security Specific Considerations • Unbounded Cost. • Distributed Measures. • Distributed Control. • Focus on Components • Refinement by Parts: Requirements RA, RB; components CA, CB.

  44. A Prototype for Managing Security Theoretical/ Modeling steps. • Adapting/ specializing dependability model to security properties. • Exploring Security in the broader context of dependability (clarifying dependencies). • Modeling security measures (vulnerability avoidance, attack detection and neutralization, intrusion tolerance, exposure limitation, etc). • Representing such measures in a uniform knowledge base.

  45. A Prototype for Managing Security Experimental/ Empirical steps. • Designing, Coding inference rules. • Modeling / Representing Claims, Rules. • Specifying query capabilities. • Selecting a sample system (modeling security aspects, relations to dependability). • Experimenting with query capabilities. • Build a demo.

  46. Sample Queries • Can we infer (S  R | A)  P. for a given , R, A, P? • Provide lower bound for (S  R | A). • Provide Upper Bound for weighted failure cost, for given , R, A.

  47. Conclusion • Premise: Consider security in the broader context of dependability, of which it depends. • Premise: Exploit analogies between aspects of dependability to migrate methods. • Premise: Capture all measures taken during design and maintenance in uniform representation, that lends itself to inferences.

  48. Prospects Eclectic, yet Integrated, Approach. • Allows us to model diverse approaches, and combine their results. • Allows us to measure claims. • Allows us to budget cost, risks. • Support Tool.

  49. Relevant Wisdom Une Science a l’age de ses instruments de mesure. Louis Pasteur. A Science is as advanced as its measurement tools.

More Related