An Integrated Approach to Security Management

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.