[PPT] - Quantitative Cyber-Security Colorado State University Yashwant K PowerPoint Presentation

SLIDE 1

1 1

Colorado State University Yashwant K Malaiya CS559 L 17

Quantitative Cyber-Security

CSU Cybersecurity Center Computer Science Dept

SLIDE 2

2

Topics

Questions (lecture only)
Testing
Partitioning, Input mix
Random testing, Detectability Profile
Test Coverage and defects

SLIDE 3

7 7

Colorado State University Yashwant K Malaiya CS 559 Testing

Quantitative Security

CSU Cybersecurity Center Computer Science Dept

SLIDE 4

8

October 23, 2020

8

Faults

Faults cause a system to respond in a way different

from expected.

Faults can be associated with bugs in the

system/software structure or functionality.

– Structure: viewed as an interconnection of components like statements, blocks, functions, modules. – Functionality: Described by the input/output/state behavior, described externally. – Both structure and functionality can be described at a higher level and a lower (finer) level.

Example: a file > classes > methods etc. > statements

SLIDE 5

9

Testing

Testing and debugging is an essential part of software

development and maintenance.

– Static analysis: code inspection – Dynamic: involves execution

Defects cause functionality/reliability and security

problem.

Vulnerabilities are a subset of the defects (1-5%)

– If exploited, allow violation of security related assumptions. – Vulnerability discovery can involve testing with

Random tests (Fuzzing)
Generated tests base on security requirements
The following discussion is general for all defects.

SLIDE 6

10

October 23, 2020

10

Testing

We assume that tests are applied at the inputs and the

response is observed at the outputs of the unit-under- test.

A test detects the presence of a fault(s), if the output is

different from the expected output.

Two test approaches:

– Functional (or Black-box): uses only the functional description of the unit, not its structure to obtain tests. Often random (“fuzzing”) – Structural testing: uses the structural information to generate

tests. Requires more effort, but can be more thorough.

– Combined

SLIDE 7

11

October 23, 2020

11

Random Testing

Termed Black-box, fuzzing when used for vulnerabilities
Random testing is a form of functional testing. In

random testing, each test is chosen such that it does not depend on past tests.

In actual practice, the “random” tests are generated

using Pseudo-random algorithms that approximate randomness.

As we will discuss later, random testing can be effective

for moderate degree of testing, but not for thorough testing.

SLIDE 8

12

October 23, 2020

12

Test coverage

A single test typically covers (i.e. tests for related faults)

several sub-partitions (elements such as functions, branches, statements)

The coverage obtained by a test-set can be obtained

using coverage tools.

The test coverage achieved by a test-set is given by

ratio:

Number of elements covered

coverage = -------------------------------

Total number of elements

SLIDE 9

13

Coverage Tools

There are several code coverage tools: Jcov, Gcov etc.

for Java, C/C++ etc.

– Compilation using the tool, instruments the compiled code to collect metrics covered. – Coverage metrics:

Statements/Blocks
Branches/Edges
Paths
Methods/Functions
Data-flow coverage metrics

– Subsumption hierarchy

Complete Path coverage => 100% Branch coverage
Complete Branch coverage => 100% Statement coverage

Assumptions:

A fault is associated with one or more elements.
Exercising the element may trigger the fault to

create an error

Complete coverage does not guarantee finding

all the faults.

SLIDE 10

14

Testing objectives

Ordinary faults:

– Fault detection: Apply a test input. Is the output what is expected? Triggering fault and propagating error. – Fault location: where is the fault? – Fixing: what will fix the fault? (debugging)

Vulnerabilities

– Apply a slightly unexpected input. Does a program crash or hang? – If it does, examine it to see if it leads to a vulnerability. – Can the vulnerability be exploited?

SLIDE 11

15

Partitioning

Software can be partitioned to ensure that the software is thoroughly

exercised during testing

It is necessary to partition it to identify tests that would be effective

for detecting the defects in different sections of the code.

For testing purposes, a program may be partitioned either functionally
r structurally.
Functional partitioning refers to partitioning the input space of a

program.

– For example, if a program performs five separate operations, its input space can be partitioned into five partitions. – Functional partitioning only requires the knowledge of the functional description of the program, the actual implementation of the code is not required.

Structural partitioning requires the knowledge of the structure at the

code level.

– If a software is composed of ten modules (which may be classes, functions or

ther types of units), it can be thought of as having ten partitions

SLIDE 12

16

Sub-Partitioning

A partition of either type can be subdivided into lower level

partitions, which may themselves be further partitionable at a lower level if higher resolution is needed (Elbaum 2001).

Let us assume that a partition pi can be subdivided into

sub-partitions {pi1, pi2 …pin}.

– Random testing within the partition pi will randomly select from {pi1, pi2 …pin}. It is possible that some of them will get selected more often in a non-optimal manner. – Code within a sub-partition may be correlated relative to the probability of exercising some faults. Thus the effectiveness of testing may be diluted if the same sub-partition frequently gets chosen. – Sub-partitioning has a practical disadvantage when the operational profile is constructed, it will require estimating the operational probabilities of the associated sub-partitions.

SLIDE 13

17

10/23/20

17

Input mix: Test Profile

The inputs to a system can represent different types of
perations. The input mix called “Profile” can impact

effectiveness of testing.

Example:

– elements e1, e2, …ei, …en exercised with probabilities p1, p2, …pi, …pn – Profile then is {(ei, pi)} for all elements

For example a Search program can be tested for text

data, numerical data, data already sorted etc. If most testing is done using numerical data, more bugs related to text data may remain unfound.

SLIDE 14

18

10/23/20

18

Input Mix: Testing “Profile”

The ideal Profile (input mix) will depend on the objective

– A. Find bugs fast? or –

B. Estimate operational failure rate?
A. Best mix for functional bug finding (Li & Malaiya’94)

– Quick & limited testing: Use operational profile (next slide) – High reliability: Probe input space evenly

Operational profile will not execute rare and special cases, the

main cause of failures in highly reliable systems. – Very high reliability: corner cases and rare combinations

B. For security bugs: corner cases and rare combinations

– Vulnerability finders / exploiters look for these.

N. Li and Y.K. Malaiya, On Input Profile Selection for Software Testing, Proc. Int. Symp.

Software Reliability Engineering, Nov. 1994, pp. 196-205.

H. Hecht, P. Crane, Rare conditions and their effect on software failures, Proc. Annual

Reliability and Maintainability Symposium, 1994, pp. 334-337

Input mix: Test Profile

SLIDE 15

19

Modeling Bug Finding Process

The number of bugs found depend on the effort

(measured by testing time) and directedness of testing.

Directedness: looking for bugs

– In elements not yet exercised enough

These will include corner cases

– Where bugs of a specific type (specially vulnerabilities) are likely to be present.

Experience, expertise, intuition

SLIDE 16

20

Nature of faults: Detectability Profile

All faults are not alike.
There is no such thing as an average fault.
As testing progresses, the remaining faults are the ones

harder to find.

SLIDE 17

21

Detection Probability

Detection probability of a fault: if there are N distinct

possible input vectors, and if a fault is detected by k of them, then its detection probability is k/N.

A fault with detection probability 1/N would be

hardest to test, since it is tested by only one specific test and none other.

A fault which is detected by almost all vectors, would

have a detection probability close to 1 and will be found with minimal texting effort. It is a low hanging fruit.

10/23/20 FTC YKM

21

SLIDE 18

22

10/23/20 FTC YKM

22

Detectability Profile of a unit under test

The Detectability Profile of a unit under test describes how

the defects are distributed relative to their detectability.

Total M faults, total N possible input combinations. The set of

faults can be partitioned into these subsets:

𝐼 = ℎ!, ℎ", … ℎ#
Where hk is the number of faults detectable by exactly k
inputs. The vector H describes the detectability profile.

– h1 is the number of faults that are hardest to find. – As testing and debugging continues, harder to find faults will tend to

remain. Easy to find faults will get eliminated soon.

Applicable to software and hardware

Y.K. Malaiya and S. Yang, ""The Coverage Problem for Random Testing”

Proc. International Test Conference, October 1984, pp. 237-245

SLIDE 19

23

10/23/20 FTC YKM

23

Detectability Profile: software

Adam’s Data for a large IBM software product. Note

bugs with high detection rates are mostly gone.

Adam's data (Product 1) 5 10 15 20 25 30 35 40 0.017 0.053 0.167 0.526 1.667 5.263 16.67 52.63 Detection rate Defects with this detection rate

Adams, IBM Journal of Research and Development, Jan. 1984

SLIDE 20

24

10/23/20 FTC YKM

24

Detectability Profile: software

Regardless of initial profile, after some initial testing, the profile will

become asymmetric.

In the early development phases, inspection and early testing are

likely to remove most easy to test bugs, while leaving almost all hardest to test bugs still in.

SLIDE 21

25

10/23/20 FTC YKM

25

Coverage with L random vectors

What fault coverage is achieved by applying L test vector?

hk out of M defects detectable by exactly k vectors: detection

probability k/N

P{a defect with dp k/N not detected by a vector} =
P{a defect with dp k/N not detected by L vectors} =
Of hk faults, expected number not covered is
Expected test coverage with L vectors

) 1 ( 1 C(L)

1

å

=

=

N k k L

M h N k

) 1 ( N k

L

N k ) 1 ( -

k L h

N k ) 1 ( -

Coverage Obtained by L Vectors

0.975 0.274 Cr L ( ) 16 1 L 5 10 15 20 0.25 0.5 0.75 1 vectors expexted coverage

SLIDE 22

26

10/23/20 FTC YKM

26

Coverage Obtained by L Vectors

3

1

L

N

1 k

10 ] ... 03 . 84 . 3 . 6 9 . 4 . 6 1 [4.2

1

C(15) Adder, Full CECL For estimated. be to need H

f

elements lower

nly

Thus impact. an have test) to hard are that faults (i.e. k low

nly

with terms L, large For Random) (for ) 1 ( 1

1

C(L) 87) (McClusky tests PR For

×

+ + + + + + + =

»

=

å å

= =

N

k k L k k N k L N

M h N k M h C C

0.999 0.274 Cr L ( ) Cpr L ( ) 16 1 L 5 10 15 20 0.5 1

c11/10

Pseudorandom (PR) testing: a vector cannot repeat, unlike in true Random testing.

SLIDE 23

27

10/23/20 FTC YKM

27

Detectability Profile: Software

Software detectability profile is

exponential

Justification: Early testing will

find & remove easy-to-test faults.

– Inspection, unit testing, integration testing, system testing, ..

Testing methods need to focus
n hard-to-find faults.

0.2 0.4 0.6 0.8 1 1.2 5 10 15 20 k

Hard to test Low hanging fruit

As testing time progresses, more of the faults are clustered to the left.

SLIDE 24

28

10/23/20 FTC YKM

28

Coverage with L random vectors

Testing may be directed rather than random because

Tester may wish to focus on functionality not adequately exercised

by random testing (for example recovery code)

Tester may wish to focus on more critical sections of the code.
The probability of detecting a fault can be give by pi, where pi may

be greater or less than k/N. P{a defect with dp pi not detected by L vectors} = (1 − 𝑞!)"

Where 𝑞! > #

$ if the previous tests are not repeated, or the test

has a good idea of where to look.

When the exhaustive set (ES) of inputs are applied, then

P{a defect with dp pi not detected by ES} ≈ 0

– Unlikely in most real situations.

Directed testing

SLIDE 25

29

Some common models

Several models for ordinary bug finding process.

Termed Software Reliability Growth Models (SRGMs).

Exponential SRGM: assumes bug finding rate l(t) is

proportional to remaining bugs at time N(t). 𝜇 𝑢 = − 𝑒𝑂 𝑢 𝑒𝑢 = 𝛾'𝑂(𝑢)

Which has the solution

𝜇 𝑢 = 𝛾$𝛾!𝑓%&!'

Where β0 and β1 are parameters to be determined. Β0

represents the initial number of bugs and β1 a measure

f test effectiveness.

SLIDE 26

30

Defect Density

Exponential defect finding model is

𝜇 𝑢 = 𝛾!𝛾"𝑓#$!%

β0 represents the initial number of bugs.
If the initial defect density is D(0), and the software size

(measured in 1000 lines of code, i.e. KLOC) is S, then 𝛾! = 𝐸(0)×𝑇

The initial defect density is a function of the software

development process and the degree of prior defect removal.

The defect finding rate gradually declines, it takes infinite

time to find them all according to the exponential model.

The final defect density is sometimes used as a release

criterion.

SLIDE 27

31

10/23/20

31

SRGM : “Logarithmic Poisson”

If testing combines random and directed testing, the

Logarithmic Poisson arises.

Logarithmic Poisson model, by Musa-Okumoto, has been

found to have a good predictive capability

Applicable as long as µ(t) < N(0). Practically always satisfied.
Parameters bo and b1 don’t have a simple interpretation.

An interpretation has been given by Malaiya and Denton (What Do the Software Reliability Growth Model Parameters Represent?).

t) + (1 = (t)

1

b

b µ ln t + 1 = (t)

1 1

b

b b l

Y.K. Malaiya, A. von Mayrhauser and P. Srimani, “An Examination of Fault Exposure Ratio,” IEEE Trans. Software Engineering, Nov. 1993, pp. 1087-1094.

SLIDE 28

32

10/23/20

32

References

Y. K. Malaiya, S. Yang, “The Coverage Problem for Random Testing,” IEEE International Test

Conference 1984, pp. 237-245.

Y.K. Malaiya, A. von Mayrhauser and P. Srimani, “An Examination of Fault Exposure Ratio,” IEEE
Trans. Software Engineering, Nov. 1993, pp. 1087-1094.
S. C. Seth, V. D. Agrawal, H. Farhat, "A Statistical Theory of Digital Circuit Testability," IEEE Trans.

Computers, 1990, pp. 582-586.

K. Wagnor, C. Chin, and E. McCluskey, “Pseudorandom testing. IEEE Trans. Computer, Mar. 1987,
pp. 332—343.
E. N. Adams, "Optimizing Preventive Service of Software Products," in IBM Journal of Research

and Development, vol. 28, no. 1, pp. 2-14, Jan. 1984.

J R Dunham, "Experiments in software reliability: Life-critical applications," IEEE Tran. SE, January

1986, pp. 110 - 123

H. Hashempour, F.J. Meyer, F. Lombardi,, "Analysis and measurement of fault coverage in a

combined ATE and BIST environment," Instrumentation and Measurement, IEEE Transactions on , vol.53, no.2, pp.300,307, April 2004.

SLIDE 29

33 33

Colorado State University Yashwant K Malaiya CS 559 Coverage based approaches

Quantitative Security

CSU Cybersecurity Center Computer Science Dept

SLIDE 30

34

10/23/20 FTC YKM

34

Test Coverage Measures

Structiral:

– Statement or Block coverage – Branch or decision coverage

Data-flow:

– P-use coverage: p-use pair: variable defined/modified - use as predicate – C-use coverage: similar -use for computation

Subsumption hierarchy:

– Covering all branches cover all statements – Covering all p-uses cover all branches

Test Coverage Measures

SLIDE 31

35

10/23/20 FTC YKM

35

Test Coverage Measures

Test case A =2, B=0, X=4

– Covers branches a, c, e – Covers all the statements

Test case A =1, B=1, X=1

– Covers branches a, b, d

Two test cases for 100%

branch coverage.

Test Coverage Measures

SLIDE 32

36

10/23/20 FTC YKM

36

Modeling : Defects, Time, & Coverage

Malaiya, Li, Bieman, Karcich, Skibbe, 1994 Li, Malaiya, Denton, 1998

SLIDE 33

37

10/23/20 FTC YKM

37

Coverage Based Defect Estimation

Coverage is an objective measure of testing

– Directly related to test effectiveness – Independent of processor speed and testing efficiency

Lower defect density requires higher coverage to

find more faults

Once we start finding faults, expect coverage vs.

defect growth to be linear

SLIDE 34

38

10/23/20 FTC YKM

38

Logarithmic-Exponential Coverage Model

Hypothesis 1: defect coverage growth follows

logarithmic model

Hypothesis 2: test coverage growth follows

logarithmic model

1 ) ( ), 1 ln( ) (

1

£ + = t C t N t C b b 1 ) ( ), 1 ln( ) (

1

£ + = t C t N t C

i i i i i

b b

SLIDE 35

39

10/23/20 FTC YKM

39

Log-Expo Coverage Model (2)

Eliminating t and rearranging,
For “large” Ci, we can approximate

etc. cov use

p

cov, branch : ; parameters : , , coverage test : coverage, defect : where 1 )], 1 ) (exp( 1 ln[

2 1 2 1

i a a a C C C C a a a C

i i i i i i i i

£

+

=

i i i

C B A C +

=

SLIDE 36

40

10/23/20 FTC YKM

40

10 20 30 40 50 60 70 80 90 100 Coverage Defects

i knee i i i i

C C C B A C > +

=

,

Linear Approximation after the knee

Coverage Model, Estimated Defects

Only applicable after the knee
Assumptions : Stable Software

C0

95%

SLIDE 37

41

10/23/20 FTC YKM

41

Cknee D0

Location of the knee

Based on interpretation through logarithmic

model

Location of knee based on initial defect density
Lower defect densities cause knee to occur at

higher coverage

Parameter estimation : Malaiya and Denton (HASE

‘98)

÷ ÷ ø ö ç ç è æ

min

min

1 E D E

SLIDE 38

42

10/23/20 FTC YKM

42

Data Sets Used: Vouk and Pasquini

Vouk data

– from N version programming project to create a flight controller – Three data sets, 6 to 9 errors each

Pasquini data

– Data from European Space Agency – C Program with 100,000 source lines – 29 of 33 known faults uncovered

SLIDE 39

43

10/23/20 FTC YKM

43

Data Set: Pasquini

5 10 15 20 25 30 35 40 45 50 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80 84 88 92 96 100 Branch Coverage Defects Model Data

Defects vs. Branch Coverage

Defects Expected Fitted Model

SLIDE 40

44

10/23/20 FTC YKM

44 Data Set: Pasquini

10 20 30 40 50 60 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80 84 88 92 96 100 P-Use Coverage Defects Model Data

Defects vs. P-Use Coverage

Defects Expected Fitted Model

Q: Will linear relation hold at very high coverage?

SLIDE 41

45

10/23/20 FTC YKM

45

Estimation of Defect Density

Measure Coverage Achieved Expected Defects Block 82% 36 Branch 70% 44 P-uses 67% 48

Estimated defects at 95% coverage, for

Pasquini data (assume 5% dead code)

28 faults found, and 33 known to exist

SLIDE 42

46

10/23/20 FTC YKM

46

Data Set: Vouk 3

2 4 6 8 10 12 14 36 40 44 48 52 56 60 64 68 72 76 80 84 88 92 96 100 P-Use Coverage Defects Model Data

Defects vs. P-Use Coverage

Defects Expected Fitted Model

SLIDE 43

47

10/23/20 FTC YKM

47

Coverage Based Estimation

Data Set: Pasquini et al

10 20 30 40 50 60 2 62 123 184 246 307 368 427 488 549 611 672 733 792 853 914 976 1037 1098 1157 1218 Test Cases Defects Defects

Estimates are stable

SLIDE 44

48

10/23/20 FTC YKM

48

Current Methods

Development process based models allow for a

priori estimates

– Not as accurate as methods based on test data

Sampling methods often assume faults found as

easy to find as faults not found

– Underestimates faults

Exponential model

– Assume applicability of exponential model – We present results of a comparison

SLIDE 45

49

10/23/20 FTC YKM

49

The Exponential Model

Data Set: Pasquini et al

5 10 15 20 25 30 5 65 126 187 249 310 371 430 491 552 614 675 736 795 856 917 979 1040 1101 1160 1221 Test Cases Defects Estimate Defects Found

Estimate rises as new defects found Estimates very close to actual faults

SLIDE 46

50

Fuzzing and Coverage

Directed Fuzzing is used for guiding vulnerability

discovery.

Fuzzing is directed using test coverage.

SLIDE 47

51

10/23/20 FTC YKM

51