+ All Categories
Home > Documents > An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March...

An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March...

Date post: 28-Dec-2015
Category:
Upload: wesley-george
View: 216 times
Download: 2 times
Share this document with a friend
49
An Integrated Approach An Integrated Approach to Security Management to Security Management M. Shereshevsky, M. Shereshevsky, R. Ben Ayed, A. Mili R. Ben Ayed, A. Mili Monday, March 14, 2005 Monday, March 14, 2005
Transcript
Page 1: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

An Integrated Approach to An Integrated Approach to Security ManagementSecurity Management

M. Shereshevsky, M. Shereshevsky,

R. Ben Ayed, A. MiliR. Ben Ayed, A. Mili

Monday, March 14, 2005Monday, March 14, 2005

Page 2: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Target: A Prototype for Managing Security Target: A Prototype for Managing Security Goals and ClaimsGoals and Claims

Composing Claims: Given a set of security measures, Composing Claims: Given a set of security measures, each resulting in a claim,each resulting in a claim,

• Can we add up the claims (resulting from different Can we add up the claims (resulting from different security measures) in a comprehensive manner?security measures) in a comprehensive manner?

• Can we infer specific security properties (probability/ Can we infer specific security properties (probability/ cost of specific attacks)?cost of specific attacks)?

• Can we expose redundancies between claims?Can we expose redundancies between claims?

• Can we expose loopholes/ vulnerabilities?Can we expose loopholes/ vulnerabilities?

Page 3: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Target: A Prototype for Managing Security Target: A Prototype for Managing Security

Goals and ClaimsGoals and Claims

Decomposing Security Goals: Given a security goal we Decomposing Security Goals: Given a security goal we want to achieve,want to achieve,

• How can we decompose it into achievable sub-goals? How can we decompose it into achievable sub-goals? • Dispatch sub-goals to layers/ sites to maximize impact.Dispatch sub-goals to layers/ sites to maximize impact.• Dispatch sub-goals to methods so as to control Dispatch sub-goals to methods so as to control

(minimize?) verification effort.(minimize?) verification effort.• Dispatch verification effort to sub-goals so as to Dispatch verification effort to sub-goals so as to

control (minimize?) failure cost?control (minimize?) failure cost?Issues: Representing, Reasoning about claims and Issues: Representing, Reasoning about claims and

goals.goals.

Page 4: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

OutlineOutline

• Dependability: A Multi-dimensional attributeDependability: A Multi-dimensional attribute• An Integrated Approach to ReliabilityAn Integrated Approach to Reliability• A Uniform Representation for Dependability A Uniform Representation for Dependability

MeasuresMeasures• Inference RulesInference Rules• General ApplicationsGeneral Applications• Specialization: A Prototype for Managing Specialization: A Prototype for Managing

SecuritySecurity

Page 5: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Dependability: A Multi Dimensional Dependability: A Multi Dimensional AttributeAttribute

Four Dimensions to Dependability:Four Dimensions to Dependability:• AvailabilityAvailability: Probability of providing services when : Probability of providing services when

needed.needed.• ReliabilityReliability: Probability of Failure Free Operation.: Probability of Failure Free Operation.• SafetySafety: Probability of Disaster Free Operation.: Probability of Disaster Free Operation.• SecuritySecurity: Probability of Interference Free Operation : Probability of Interference Free Operation

(exposure, intrusion, damage).(exposure, intrusion, damage).

Conceptually orthogonal, actually interdependentConceptually orthogonal, actually interdependent ..

Page 6: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

AvailabilityAvailability

Depends on:Depends on:

• Reliability.Reliability.

• Repair Time.Repair Time.

Dependent on Reliability.Dependent on Reliability.

Related to Security: DoS affects availability.Related to Security: DoS affects availability.

Page 7: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

ReliabilityReliability

Basic Concepts:Basic Concepts:• Fault. Fault. System feature that may cause system System feature that may cause system

to misbehave.to misbehave.• Error. Error. Impact of fault on system state.Impact of fault on system state. Early Early

warning of misbehavior.warning of misbehavior.• FailureFailure. Impact of fault on system (mis) . Impact of fault on system (mis)

behavior. Observable misbehavior.behavior. Observable misbehavior.System feature; State feature; Output feature.System feature; State feature; Output feature.

Page 8: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Reliability, IIReliability, II

Basic Means:Basic Means:• Fault Avoidance. Fault Avoidance. Fault Free Design.Fault Free Design.• Fault Removal. Fault Removal. Debugging/ Testing.Debugging/ Testing.• Fault Tolerance. Fault Tolerance. Error detection and Error detection and

recovery.recovery.

Three successive, increasingly desperate, lines Three successive, increasingly desperate, lines of defense.of defense.

Page 9: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

SafetySafety

Key Concepts:Key Concepts:

• Hazard. Hazard. System feature that makes accidents System feature that makes accidents possible.possible.

• Mishap. Mishap. Operational conditions that makes Operational conditions that makes accident imminent.accident imminent.

• Accident. Accident. Unplanned, undesirable eventUnplanned, undesirable event..

• Damage. Damage. Loss that results from an accident.Loss that results from an accident.

Page 10: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Safety, IISafety, II

Key Measures:Key Measures:• Hazard Avoidance.Hazard Avoidance. Hazard Free design. Hazard Free design.• Hazard Removal. Hazard Removal. Intervene before hazards Intervene before hazards

cause accidents.cause accidents.• Damage Limitation. Damage Limitation. Limit the impact of an Limit the impact of an

accident.accident.

Three successive lines of defense.Three successive lines of defense.

Page 11: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Reliability vs. SafetyReliability vs. Safety

Page 12: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

SecuritySecurity

Key Concepts:Key Concepts:

• Vulnerability. Vulnerability. System feature that makes an System feature that makes an attack possible.attack possible.

• Threat.Threat. Situational condition that makes an Situational condition that makes an attack possible.attack possible.

• Exposure/ Attack. Exposure/ Attack. Deliberate or accidental Deliberate or accidental loss of data and/or resources.loss of data and/or resources.

Page 13: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Security, IISecurity, II

Key Measures:Key Measures:• Vulnerability Avoidance.Vulnerability Avoidance. Vulnerability Free Vulnerability Free

design.design.• Attack Detection and Neutralization. Attack Detection and Neutralization.

Intervene before Attacks cause loss/ damage.Intervene before Attacks cause loss/ damage.• Exposure Limitation. Exposure Limitation. Limit the impact of Limit the impact of

attacks/ exposure. Intrusion-tolerance.attacks/ exposure. Intrusion-tolerance.Three successive lines of defense.Three successive lines of defense.

Page 14: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Special Role of SecuritySpecial Role of Security

• Without security, there can be no reliability Without security, there can be no reliability nor safety. nor safety. All claims about reliability and All claims about reliability and safety become void if the system’s data and safety become void if the system’s data and programs can be altered.programs can be altered.

• Without reliability, there can be no security. Without reliability, there can be no security. Security measures can be viewed as part of the Security measures can be viewed as part of the functional requirements of the system.functional requirements of the system.

Page 15: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Integrated Approach to ReliabilityIntegrated Approach to Reliability

• Three Broad families of methods: Fault Three Broad families of methods: Fault avoidance, fault removal, fault tolerance.avoidance, fault removal, fault tolerance.

• Which works best? Which works best? Spirited debate, dogmatic Spirited debate, dogmatic positions, jokes, etc.positions, jokes, etc.

Pragmatic position: Pragmatic position: use all three in concert, use all three in concert, whenever possible/ warranted.whenever possible/ warranted.

Page 16: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Rationale for Eclectic ApproachRationale for Eclectic Approach

• The Law of Diminishing Returns.The Law of Diminishing Returns.

• Method effectiveness varies greatly according Method effectiveness varies greatly according to specification.to specification.

• Refinement calculus allows us to compose Refinement calculus allows us to compose verification efforts/ claims.verification efforts/ claims.

• Refinement calculus allows us to decompose Refinement calculus allows us to decompose verification goals.verification goals.

Page 17: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Mapping Methods to SpecificationsMapping Methods to Specifications

• Proving: Proving: Reflexive, transitive relations.Reflexive, transitive relations.

• Testing: Testing: Relations that are good candidates Relations that are good candidates for oracles (reliably implemented).for oracles (reliably implemented).

• Fault Tolerance: Fault Tolerance: Unary relations that are Unary relations that are reliably and efficiently implemented.reliably and efficiently implemented.

Page 18: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Composing Verification EffortComposing Verification Effort

• All methods must be cast in a common logical All methods must be cast in a common logical framework.framework.

• Refinement calculus (based on relations) Refinement calculus (based on relations) offers such a common framework.offers such a common framework.

• Specifications and programs are relations; Specifications and programs are relations; refinement ordering between relations; lattice refinement ordering between relations; lattice properties.properties.

Page 19: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Modeling Verification MethodsModeling Verification Methods

• Proving: Proving: Proving that P is correct with respect Proving that P is correct with respect to specification V:to specification V:

P P V. V.

• Testing: Testing: Certification testing, Oracle Certification testing, Oracle , test , test data D’, successful test on D.data D’, successful test on D.

P P T, T,

where T = where T = D\D\ . .

Page 20: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Modeling Verification Methods, IIModeling Verification Methods, II

• Fault Tolerance: Fault Tolerance: Upon each recovery block, Upon each recovery block, check condition check condition C, C, invoke recovery routine invoke recovery routine R.R. Because we do not which outcome we have Because we do not which outcome we have each time, all we can claim is:each time, all we can claim is:

P P F, F,

where F = C where F = C R. R.

Page 21: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Cumulating ResultsCumulating Results

• Proving:Proving: P P V. V.

• Testing: P Testing: P T. T.

• Fault Tolerance: P Fault Tolerance: P F. F.

• Lattice Identity: Lattice Identity:

P P (V (VTTF).F).

Cumulating verification results into a compre-Cumulating verification results into a compre-hensive correctness claim.hensive correctness claim.

Page 22: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Lattice PropertiesLattice Properties

Page 23: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Decomposing Verification GoalsDecomposing Verification Goals

Premises:Premises:

• A Complex Specification can be decomposed A Complex Specification can be decomposed into simpler sub-specifications in a into simpler sub-specifications in a refinement-compatible manner:refinement-compatible manner:

S = SS = S1 1 S S2 2 … … SSN.N.

• We can consider each SWe can consider each SI I in turn, mapping it to in turn, mapping it to the method that is most efficient for it.the method that is most efficient for it.

Page 24: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Mapping Specifications to MethodsMapping Specifications to Methods

Page 25: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

A Uniform Representation for A Uniform Representation for Dependability MeasuresDependability Measures

Logical representation of verification results Logical representation of verification results unrealistic:unrealistic:

• Most verification results are best viewed as Most verification results are best viewed as probabilistic, not logical, statements.probabilistic, not logical, statements.

• Most verification results are conditional, Most verification results are conditional, contingent upon different conditions.contingent upon different conditions.

• Many verification results can be interpreted in Many verification results can be interpreted in more than one way.more than one way.

Page 26: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Probabilistic (vs Logical) ClaimsProbabilistic (vs Logical) Claims

• No absolute certainty.No absolute certainty.

• Even highly dependable, totally formal, Even highly dependable, totally formal, verification systems may fail.verification systems may fail.

• We want to quantify level of confidence.We want to quantify level of confidence.

Page 27: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Verification Results are ConditionalVerification Results are Conditional

• Proving: Proving: Conditional on verification rules Conditional on verification rules being consistent with actual compiler.being consistent with actual compiler.

• Testing:Testing: Conditional on testing environment Conditional on testing environment being identical to operating environment.being identical to operating environment.

• Fault Tolerance:Fault Tolerance: Conditional on system Conditional on system preserving recoverability.preserving recoverability.

Page 28: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Multiple InterpretationsMultiple Interpretations

• Testing, first interpretation: P Testing, first interpretation: P D\D\ , , with probability with probability 1.0.1.0.

• Testing, second interpretation: P Testing, second interpretation: P , , with with probability p<1.0, conditional on D being probability p<1.0, conditional on D being representative.representative.

Which interpretation do we choose? Which interpretation do we choose? We do not have to We do not have to choose, in fact. We can keep both, and learn to add/ choose, in fact. We can keep both, and learn to add/ cumulate them.cumulate them.

Page 29: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Characterizing Verification ClaimsCharacterizing Verification Claims

• Goal. Goal. Correctness preservation, recoverability Correctness preservation, recoverability preservation, operational attribute.preservation, operational attribute.

• Reference. Reference. Specification, Safety requirement, security Specification, Safety requirement, security requirement, etc.requirement, etc.

• Assumption. Assumption. Implicit conditions in each method.Implicit conditions in each method.• Certainty. Certainty. Quantified by probability.Quantified by probability.• Stake. Stake. Cost of failure to meet the goal; applies to Cost of failure to meet the goal; applies to

safety and security.safety and security.• Method. Method. Static vs dynamic, others. May affect the cost Static vs dynamic, others. May affect the cost

of performing the verification task.of performing the verification task.

Page 30: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Representing Verification ClaimsRepresenting Verification Claims

• List:List:

(G,R,A,P,S,M)(G,R,A,P,S,M)

G: Goal; R: Reference; A: Assumption;G: Goal; R: Reference; A: Assumption;

P: Probability; S: Stake; M: Method.P: Probability; S: Stake; M: Method.

Page 31: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Sample RepresentationsSample Representations

Certification Testing:Certification Testing:

• First: Y( First: Y( , , D\D\, true, 1.0, , Testing),, true, 1.0, , Testing),

where D is successful test data. where D is successful test data.

• Second: Y( Second: Y( , , , A, 0.7, , Testing), , A, 0.7, , Testing),

where A is representativity of D.where A is representativity of D.

Page 32: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Sample RepresentationsSample Representations

Formal Verification:Formal Verification:• First: Y( First: Y( , R, A, 0.99, , Proving),, R, A, 0.99, , Proving), where R is system specification, A is condition where R is system specification, A is condition

that the verification method is consistent with that the verification method is consistent with operational environment. operational environment.

• Second: Y( Second: Y( , R, R11, A, 0.995, HighC, Proving) , A, 0.995, HighC, Proving) Y( Y( , R, R22, A, 0.97, LowC, Proving)., A, 0.97, LowC, Proving).

Page 33: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Sample RepresentationsSample Representations

Verifying Initialization Sequence with respect to N:Verifying Initialization Sequence with respect to N:Y( Y( , R, A , R, A B, P, , Proving), B, P, , Proving),

• R is system specification, R is system specification, • A is condition that the verification method is consistent with A is condition that the verification method is consistent with

operational environment, operational environment, • B is condition that the body of the system refines right residual B is condition that the body of the system refines right residual

of R by N (solution to Nof R by N (solution to NX X R). R). Approach also applicable to regression testing; updating claims Approach also applicable to regression testing; updating claims

after maintenance operation. Open issue: negating, overriding, after maintenance operation. Open issue: negating, overriding, replacing previous claims?replacing previous claims?

Page 34: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Sample RepresentationSample Representation

Safety Measure:Safety Measure:Y( Y( , S, A, 0.999, HiC, Proving),, S, A, 0.999, HiC, Proving),

Where Where S S is safety requirement, A is consistency is safety requirement, A is consistency of verification method with operational of verification method with operational environment, HiC is cost of failing to meet the environment, HiC is cost of failing to meet the condition condition P P S. S.

How does security differ from safety/ reliability: How does security differ from safety/ reliability: a different goal or a different reference?a different goal or a different reference?

Page 35: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Inference RulesInference Rules

• Collecting claims is insufficient.Collecting claims is insufficient.• Cumulating/Synthesizing claims (as we did Cumulating/Synthesizing claims (as we did

with logical results) is impractical.with logical results) is impractical.Build inference mechanisms that can infer Build inference mechanisms that can infer

conclusions from a set of claims.conclusions from a set of claims.

We will explore applications of this capability, We will explore applications of this capability, subsequently.subsequently.

Page 36: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Inference RulesInference Rules

Orthogonal Representation, for the purpose of enabling Orthogonal Representation, for the purpose of enabling inferences:inferences:

(S (S R | A) = P. R | A) = P.

Two additional cost functions:Two additional cost functions:

• Verification cost: Verification cost:

Goal Goal Ref Ref Meth Meth Assum Assum Cost. Cost.

• Failure cost: Failure cost:

Goal Goal Ref Ref Cost. Cost.

Page 37: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Inference RulesInference Rules

Derived from refinement calculus:Derived from refinement calculus:(S(S(R(R11RR22) | A) ) | A)

(S(SRR11 | A) | A) (S(SRR22 | A). | A).(S(S(R(R11RR22) | A) ) | A)

(S(SRR11 | A) + | A) + (S(SRR22 | A). | A).(S(S(R(R11RR22) | A) ) | A)

max(max((S(SRR11 | A), | A), (S(SRR22 | A)). | A)).

Page 38: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Inference RulesInference Rules

Derived from Probability Calculus:Derived from Probability Calculus:

• RR11RR22 (S(SRR11 | A) | A) (S(SRR22 | A). | A).

• (A(A11AA22)) (S(SR | AR | A11) ) (S(SR | AR | A22).).(S(SR | A R | A B) = B) =

(S(SR | A) R | A) (S(SR | B) / R | B) / (S(SR).R).

• Bayes’ Theorem.Bayes’ Theorem.

Page 39: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Inference RulesInference Rules

Derived from Cost functions:Derived from Cost functions:

• RR11RR2 2 VC( VC(,R,R11, M, A) , M, A) VC( VC(,R,R22, M, A)., M, A).

• (A(A1 1 A A22) )

VC(VC(,R, M, A,R, M, A22) ) VC( VC(,R, M, A,R, M, A11).).

• RR11RR2 2 FC( FC(,R,R11) ) FC( FC(,R,R22).).

Page 40: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

General ApplicationsGeneral Applications

Providing dependability:Providing dependability:• Deploy eclectic approaches.Deploy eclectic approaches.• Dispatch goals to methods to control verification Dispatch goals to methods to control verification

costs.costs.• Dispatch verification effort to verification goals to Dispatch verification effort to verification goals to

control failure costs.control failure costs.• Budget verification cost.Budget verification cost.• Minimize / assess failure risk (probability, severity of Minimize / assess failure risk (probability, severity of

failure).failure).

Page 41: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

General ApplicationsGeneral Applications

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

of failure).of failure).

Page 42: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

General ApplicationsGeneral Applications

Certifying dependability:Certifying dependability:

• Deploy eclectic/ diverse approaches.Deploy eclectic/ diverse approaches.

• Budget certification cost.Budget certification cost.

• Target certification effort (certification goal Target certification effort (certification goal inferred from claims established by inferred from claims established by certification activity).certification activity).

Page 43: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Security Specific ConsiderationsSecurity Specific Considerations

• Unbounded Cost.Unbounded Cost.

• Distributed Measures.Distributed Measures.

• Distributed Control.Distributed Control.

• Focus on ComponentsFocus on Components

• Refinement by Parts: Requirements RA, RB; Refinement by Parts: Requirements RA, RB; components CA, CB. components CA, CB.

Page 44: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

A Prototype for Managing SecurityA Prototype for Managing Security

Theoretical/ Modeling steps.Theoretical/ Modeling steps.• Adapting/ specializing dependability model to Adapting/ specializing dependability model to

security properties.security properties.• Exploring Security in the broader context of Exploring Security in the broader context of

dependability (clarifying dependencies).dependability (clarifying dependencies).• Modeling security measures (vulnerability Modeling security measures (vulnerability

avoidance, attack detection and neutralization, avoidance, attack detection and neutralization, intrusion tolerance, exposure limitation, etc).intrusion tolerance, exposure limitation, etc).

• Representing such measures in a uniform Representing such measures in a uniform knowledge base.knowledge base.

Page 45: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

A Prototype for Managing SecurityA Prototype for Managing Security

Experimental/ Empirical steps.Experimental/ Empirical steps.

• Designing, Coding inference rules.Designing, Coding inference rules.

• Modeling / Representing Claims, Rules.Modeling / Representing Claims, Rules.

• Specifying query capabilities.Specifying query capabilities.

• Selecting a sample system (modeling security Selecting a sample system (modeling security aspects, relations to dependability).aspects, relations to dependability).

• Experimenting with query capabilities.Experimenting with query capabilities.

• Build a demo.Build a demo.

Page 46: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Sample QueriesSample Queries

• Can we infer Can we infer

(S (S R | A) R | A) P. P.

for a given for a given , R, A, P?, R, A, P?

• Provide lower bound for Provide lower bound for

(S (S R | A). R | A).

• Provide Upper Bound for weighted failure Provide Upper Bound for weighted failure cost, for given cost, for given , R, A., R, A.

Page 47: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

ConclusionConclusion

• Premise: Consider security in the broader Premise: Consider security in the broader context of dependability, of which it depends.context of dependability, of which it depends.

• Premise: Exploit analogies between aspects of Premise: Exploit analogies between aspects of dependability to migrate methods.dependability to migrate methods.

• Premise: Capture all measures taken during Premise: Capture all measures taken during design and maintenance in uniform design and maintenance in uniform representation, that lends itself to inferences.representation, that lends itself to inferences.

Page 48: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

ProspectsProspects

Eclectic, yet Integrated, Approach.Eclectic, yet Integrated, Approach.

• Allows us to model diverse approaches, and Allows us to model diverse approaches, and combine their results.combine their results.

• Allows us to measure claims.Allows us to measure claims.

• Allows us to budget cost, risks.Allows us to budget cost, risks.

• Support Tool.Support Tool.

Page 49: An Integrated Approach to Security Management M. Shereshevsky, R. Ben Ayed, A. Mili Monday, March 14, 2005.

Relevant WisdomRelevant Wisdom

Une Science a l’age de ses instruments de mesure.Une Science a l’age de ses instruments de mesure.

Louis Pasteur.Louis Pasteur.

A Science is as advanced as its measurement tools.A Science is as advanced as its measurement tools.


Recommended