Model Checking for Counterexamples: Testing and Security Paul Ammann ISE Department May 1, 2002.

Slides:



Advertisements
Similar presentations
1 Verification by Model Checking. 2 Part 1 : Motivation.
Advertisements

Modeling issues Book: chapters 4.12, 5.4, 8.4, 10.1.
Auto-Generation of Test Cases for Infinite States Reactive Systems Based on Symbolic Execution and Formula Rewriting Donghuo Chen School of Computer Science.
CS 267: Automated Verification Lecture 2: Linear vs. Branching time. Temporal Logics: CTL, CTL*. CTL model checking algorithm. Counter-example generation.
Algorithmic Software Verification VII. Computation tree logic and bisimulations.
Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
An Introduction to the Model Verifier verds Wenhui Zhang September 15 th, 2010.
ECE Synthesis & Verification - L271 ECE 697B (667) Spring 2006 Synthesis and Verification of Digital Systems Model Checking basics.
Model Checking I What are LTL and CTL?. and or dreq q0 dack q0bar.
Paul Ammann & Jeff Offutt
(c) 2007 Mauro Pezzè & Michal Young Ch 9, slide 1 Test Case Selection and Adequacy Criteria.
(c) 2007 Mauro Pezzè & Michal Young Ch 9, slide 1 Test Case Selection and Adequacy Criteria.
Model Checking Inputs: A design (in some HDL) and a property (in some temporal logic) Outputs: Decision about whether or not the property always holds.
Predicate Complete Testing * Thomas Ball * Thomas Ball, A Theory of Predicate-Complete Test Coverage and Generation, Technical Report MSR-TR ,
Introduction to Software Testing Chapter 2.1, 2.2 Overview Graph Coverage Criteria Paul Ammann & Jeff Offutt
© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 1 Temporal Logic Formal Specifications CS Shmuel Katz The Technion.
Lecture 4&5: Model Checking: A quick introduction Professor Aditya Ghose Director, Decision Systems Lab School of IT and Computer Science University of.
1 Today Another approach to “coverage” Cover “everything” – within a well-defined, feasible limit Bounded Exhaustive Testing.
Witness and Counterexample Li Tan Oct. 15, 2002.
Department of CIS University of Pennsylvania 1/31/2001 Specification-based Protocol Testing Hyoung Seok Hong Oleg Sokolsky CSE 642.
ESE601: Hybrid Systems Introduction to verification Spring 2006.
Witness and Counterexample Li Tan Oct. 15, 2002.
Introduction to Software Testing Chapter 9.1 Syntax-based Testing Paul Ammann & Jeff Offutt
System Design Research Laboratory Specification-based Testing with Linear Temporal Logic Li Tan Oleg Sokolsky Insup Lee University of Pennsylvania.
Flavio Lerda 1 LTL Model Checking Flavio Lerda. 2 LTL Model Checking LTL –Subset of CTL* of the form: A f where f is a path formula LTL model checking.
Introduction to Software Testing Chapter 9.4 Model-Based Grammars Paul Ammann & Jeff Offutt
Advanced Technology Center Slide 1 Requirements-Based Testing Dr. Mats P. E. Heimdahl University of Minnesota Software Engineering Center Dr. Steven P.
Introduction to Software Testing
Overview Graph Coverage Criteria ( Introduction to Software Testing Chapter 2.1, 2.2) Paul Ammann & Jeff Offutt.
Coverage Literature of software testing is primarily concerned with various notions of coverage Four basic kinds of coverage: Graph coverage Logic coverage.
Benjamin Gamble. What is Time?  Can mean many different things to a computer Dynamic Equation Variable System State 2.
Introduction to Software Testing Chapter 8.1 Building Testing Tools –Instrumentation Paul Ammann & Jeff Offutt
CS6133 Software Specification and Verification
637 – Introduction (Ch 1) Introduction to Software Testing Chapter 1 Jeff Offutt Information & Software Engineering SWE 437 Software Testing
Introduction to Software Testing Chapter 5.1 Syntax-based Testing Paul Ammann & Jeff Offutt
Software Testing and Maintenance Lecture 2.1 Overview Graph Coverage
Lecture 5 1 CSP tools for verification of Sec Prot Overview of the lecture The Casper interface Refinement checking and FDR Model checking Theorem proving.
Verification & Validation By: Amir Masoud Gharehbaghi
SOFTWARE TESTING. Introduction Software Testing is the process of executing a program or system with the intent of finding errors. It involves any activity.
1 CSEP590 – Model Checking and Automated Verification Lecture outline for July 9, 2003.
Quality Assurance in the Presence of Variability Kim Lauenroth, Andreas Metzger, Klaus Pohl Institute for Computer Science and Business Information Systems.
Workshop on Integrating Software Testing into Programming Courses (WISTPC14:2) Friday July 18, 2014 Introduction to Software Testing.
1 Test Coverage Coverage can be based on: –source code –object code –model –control flow graph –(extended) finite state machines –data flow graph –requirements.
6/12/20161 a.a.2015/2016 Prof. Anna Labella Formal Methods in software development.
Verification vs. Validation Verification: "Are we building the product right?" The software should conform to its specification.The software should conform.
Introduction to Software Testing (2nd edition) Chapter 5 Criteria-Based Test Design Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Graph Coverage Criteria CS 4501 / 6501 Software Testing
CIS 842: Specification and Verification of Reactive Systems
Coverage-Based Test Design CS 4501 / 6501 Software Testing
Paul Ammann & Jeff Offutt
Structural testing, Path Testing
Graph Coverage for Design Elements CS 4501 / 6501 Software Testing
Introduction to Software Testing Chapter 5.1 Syntax-based Testing
Introduction to Software Testing Chapter 5.2 Program-based Grammars
Introduction to Software Testing Chapter 3, Sec# 3.5
Introduction to Software Testing Chapter 3.5 Logic Coverage for FSMs
Graph Coverage for Design Elements CS 4501 / 6501 Software Testing
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
Paul Ammann & Jeff Offutt
Graph Coverage Criteria CS 4501 / 6501 Software Testing
Logic Coverage for Source Code CS 4501 / 6501 Software Testing
Introduction to Software Testing Chapter 5.1 Syntax-based Testing
Paul Ammann & Jeff Offutt
The Zoo of Software Security Techniques
Introduction to verification
Paul Ammann & Jeff Offutt
Presentation transcript:

Model Checking for Counterexamples: Testing and Security Paul Ammann ISE Department May 1, 2002

© Paul Ammann2 Overview Problem Overview What’s a Model Checker? What’s a Counterexample? Test Criteria and Temporal Logic Some Examples –Testing –Security

May 1, 2002© Paul Ammann3 Contributors NIST – Paul Black, Vadim Okun GMU Faculty – Jeff Offutt, Duminda Wijesekera, CSIS (Sushil Jajodia, Roger Alexander, Chuck Hutchinson, Steve Noel, Brian O’Berry) GMU Students – Aynur Abdurazik, Elina Blank, Wei Ding, Ron Ritchey, Lingya Sun, Linda Xu

May 1, 2002© Paul Ammann4 Problem Overview: Specification-Based Testing Testing is Expensive, so try to reduce cost: –Reuse other development artifacts In this case, a finite state machine description –Automate Formalization of Test Objectives Test Generation/Recognition –Create a new test set with some property –Analyze an existing test set for some property This is Not a Model Checking Talk!

May 1, 2002© Paul Ammann5 Specification-Based Testing Abstraction: Define/Analyze Tests Actual System: Execute Tests

May 1, 2002© Paul Ammann6 What’s a Model Checker? Finite State Model –States, Transitions, Labels –Variety of ways to specify Constraint –Some formula in a suitable logic Model Checker –Verifies formula (we don’t care how), or –Finds a counterexample…

May 1, 2002© Paul Ammann7 Example a a, c b b => AX a true… a => AX b false! Counter: 1, 3, 2, 1

May 1, 2002© Paul Ammann8 What’s a Counterexample? Appears to be a sequence of states –This looks a lot like a test case – Great! In Computational Tree Logic (CTL) –Root of some computational tree that shows formula does not hold –Usually decorated with path information to reach this root Return to counterexample / test case relation later

May 1, 2002© Paul Ammann9 Test Criteria Test Coverage Criteria Widely Used –Control Flow Criteria Statement Coverage, Branch Coverage, etc. –Data Flow Criteria All def-use associations, All defs, All uses, etc. –Mutation Coverage Comprehensive set of syntactic mutations –Predicate Coverage Condition Coverage, MC/DC Coverage, etc. Applicable to Both Code and Specifications

May 1, 2002© Paul Ammann10 Test Requirements Given a Coverage Criterion and an Artifact … Generate a Set of Test Requirements. “State” coverage on model with N states: Requirement 1: Some test must visit state 1 Requirement 2: Some test must visit state 2 … Requirement N: Some test must visit state N

May 1, 2002© Paul Ammann11 Test Criteria and Temporal Logic Express Test Requirements with Temporal Formulae … and Let Model Checker Find the Tests For You: ! EF (state = 1) ! EF (state = 2) … ! EF (state = N)

May 1, 2002© Paul Ammann12 Advantages of Using a Model Checker Some test requirements are infeasible –Example: Maybe State x is unreachable. –Model checker identifies these A single test may satisfy multiple requirements –Straightforward to identify Additional payoff from modeling effort –Modeling is expensive, so amortize the cost Very expressive mechanism

May 1, 2002© Paul Ammann13 Example Test the case where the North South traffic flows, traffic from the South stops for left turning traffic from the North, and then traffic from the South resumes, all without East West traffic flowing: ! EF(NtoS.light = G & StoN.light = G & E(EW.light = R U NtoE.light = G & E(EW.light = R U StoN.light = G)))

May 1, 2002© Paul Ammann14 Traffic Light Example Note Intermediate States Not Specified, But…...… EW.light = R NtoE.light = G NtoS.light = G StoN.light = G Counterxample includes All states needed in test

May 1, 2002© Paul Ammann15 Counterexample for Traffic Light State 1: NtoS.light = R, StoN.light = R, NtoE.light = R, EW.light = R State 2: NtoS.light = G, StoN.ligtht = G State 4: StoN.light = Y -- not explicitly specified State 5: StoN.light = R -- not explicitly specified State 6: NtoE.light = G State 7: NtoE.light = Y -- not explicitly specified State 8: NtoE.light = R -- not explicitly specified State 9: NtoS.light = G

May 1, 2002© Paul Ammann16 What about Existing Test Sets? Regression Test Suites are a Fact of Life –What is missing? –What is redundant? For First Question –Transform Test Suite to (subset of) finite state model Keep states and transitions test suite traverses –Evaluate against test requirements

May 1, 2002© Paul Ammann17 Existing Test Set Example

May 1, 2002© Paul Ammann18 First Test Case: 3, 1, 2, 4,

May 1, 2002© Paul Ammann19 Second Test Case: 3, 4, 7,

May 1, 2002© Paul Ammann20 Third Test Case: 3, 4, 7, 2,

May 1, 2002© Paul Ammann21 Resulting State Machine Evaluate Test Requirements Against This Finite State Machine

May 1, 2002© Paul Ammann22 Example: MC/DC Coverage Criterion Used in Certification of Certain Commercial Avionics Software Idea: Test a decision with N conditions without using 2^N tests (Use N+1 instead) Example: A and (B or C) –2 tests with respect to A, where B, C set so that A determines value of decision: A true in one test, false in other test. B, C have same values in both tests. –Similar for B, C (This looks like 2N tests, but its not…)

May 1, 2002© Paul Ammann23 So, What’s the Problem? Is the counterexample/test relation 1 to 1? If so (this is traditional model checking), we have a problem: How do I make B and C keep the same values on two separate tests? –!EF ( A & (B | C)) -- first test req for A –!EF ( !A & (B | C)) -- second test req for A If not, what is the relation?

May 1, 2002© Paul Ammann24 Possible Counterexample A B !C !A B !C … … This is two tests, not one, but it is only 1 counterexample. !(EF ( A & B & !C) & EF (!A & B & !C)) Details: See Duminda’s paper with Lingya and me.

May 1, 2002© Paul Ammann25 Another Example: Safety Testing Specification-Based Testing Tuned to Safety Properties Notion of dangerous actions - Test these! Based on a mutation model Two types of tests: failing tests and passing tests Family of coverage criteria based on temporal operators Model checker (SMV) automates test generation Note: Use “safety” in the sense of Leveson

May 1, 2002© Paul Ammann26 Dangerous Traces D(Dangerous)-trace: A trace from original state Machine (M), whose last state can be extended, first with a transition from M’-M, and possibly further with transitions from M+ in such a way that safe predicate P is violated Traces can be dangerous in a variety of interesting ways: AX, EX, AF, EF M original state machine M’-M In mutant but not in original machine M+ Union of M and M’ A dangerous trace Turn point P is violated

May 1, 2002© Paul Ammann27 Testing Network Security Idea: Finite State Model for Network –Attributes are vulnerabilities, attacker acccess, connectivity –Transition relation defined by possible exploits Basis of TVA project in CSIS lab Original paper, Ritchey and Ammann (Oakland 2000) Closely related work at CMU

May 1, 2002© Paul Ammann28 Results of Approach Model Checker needs some work –Counterexample is single attack path –Really want all attack paths Special case of relating counterexamples to test cases. Basically, “and” operators (logical or temporal) require multiple tests to “cover” –Also sets of key exploits

May 1, 2002© Paul Ammann29 Status of TVA Approach Fairly decent scaling so far, at least for model checking Looking at alternative computation engines Looking at monotonic analysis