14

Click here to load reader

Complexity Measures for Secure Service-Orieted Software Architectures

Embed Size (px)

DESCRIPTION

Muchael Yanguo Liu and Issa Traore

Citation preview

Page 1: Complexity Measures for Secure Service-Orieted Software Architectures

Complexity Measures for Complexity Measures for Secure Service-OrientedSecure Service-Oriented Software Architectures Software Architectures

Michael Yanguo Liu, Issa TraoreMichael Yanguo Liu, Issa Traore

Department of Electrical and Computer Engineering Department of Electrical and Computer Engineering

University of Victoria,University of Victoria, CanadaCanada

Email: yliu,[email protected]: yliu,[email protected]

Page 2: Complexity Measures for Secure Service-Orieted Software Architectures

OverviewOverview

Problem StatementProblem Statement Some Related WorksSome Related Works Our ApproachesOur Approaches Measurement FrameworkMeasurement Framework Empirical StudyEmpirical Study Conclusion and Future WorkConclusion and Future Work

Page 3: Complexity Measures for Secure Service-Orieted Software Architectures

Problem Problem StatementStatement

• Some Related Some Related WorkWork

• Our ApproachOur Approach

• Measurement Measurement FrameworkFramework

• Empirical StudyEmpirical Study

• Conclusion and Conclusion and Future WorkFuture Work

Software systems that run in open environments are facing more and Software systems that run in open environments are facing more and more attacks or intrusions. This situation has brought security concerns more attacks or intrusions. This situation has brought security concerns into the software development process. Generally, software services are into the software development process. Generally, software services are expected not only to satisfy functional requirements but also to be expected not only to satisfy functional requirements but also to be resistant to malicious attacks. resistant to malicious attacks.

Traditional approach to software security engineering referred to as Traditional approach to software security engineering referred to as “penetrate and patch” consists of fixing security flaws after they have “penetrate and patch” consists of fixing security flaws after they have been exploited. It is still an open challenge on how to address security been exploited. It is still an open challenge on how to address security issues in early stage of software development.issues in early stage of software development.

Techniques like threat modelling, misuse identification, attack tree help Techniques like threat modelling, misuse identification, attack tree help analyze software security on architecture level, but still requires human analyze software security on architecture level, but still requires human expertise to be involved for architecture evaluation against security expertise to be involved for architecture evaluation against security concerns.concerns.

The use of software metrics as cost-effective quality predictors is widely The use of software metrics as cost-effective quality predictors is widely accepted in the software community, both in academia and industry. accepted in the software community, both in academia and industry. However, there lack of quantitative and objective approaches for However, there lack of quantitative and objective approaches for security analysis of software products on architectural level.security analysis of software products on architectural level.

Page 4: Complexity Measures for Secure Service-Orieted Software Architectures

Saltzer et.al. summarized in 1975 several security design principles for Saltzer et.al. summarized in 1975 several security design principles for engineering secure software systems. These principles have been so far engineering secure software systems. These principles have been so far used as informally or ad hoc basis by security analysts.used as informally or ad hoc basis by security analysts.

Kazman et. al presented in 1996 the Software Architecture Analysis Kazman et. al presented in 1996 the Software Architecture Analysis Method (SAAM) that is a scenario-based methodology to evaluate quality Method (SAAM) that is a scenario-based methodology to evaluate quality factors of software architecturefactors of software architecture..

To allow security specification and validation using UML, Jurjens To allow security specification and validation using UML, Jurjens proposed a framework to express security-related information explicitly proposed a framework to express security-related information explicitly using UML modeling elements and evaluate such artefact using an using UML modeling elements and evaluate such artefact using an underlying formal model.underlying formal model.

Howard et al. proposed to use attack surface to determine whether one Howard et al. proposed to use attack surface to determine whether one version of software application has less attackability than another. They version of software application has less attackability than another. They define attack surface in terms of system actions that are externally visible define attack surface in terms of system actions that are externally visible to system’s users and the resources accessed or modified by each actionto system’s users and the resources accessed or modified by each action..

Ortalo et al. proposed a measurement framework for assessing the Ortalo et al. proposed a measurement framework for assessing the difficulties of attackers to compromise a software system in terms of difficulties of attackers to compromise a software system in terms of specific attack scenarios. Their measurement is based on a description specific attack scenarios. Their measurement is based on a description model of attack scenarios, so called privilege graph.model of attack scenarios, so called privilege graph.

• Problem Problem StatementStatement

Some Related Some Related WorkWork

• Our ApproachOur Approach

• Measurement Measurement FrameworkFramework

• Empirical StudyEmpirical Study

• Conclusion and Conclusion and Future WorkFuture Work

Page 5: Complexity Measures for Secure Service-Orieted Software Architectures

• Problem Problem StatementStatement

• Some Related Some Related WorkWork

Our ApproachOur Approach

• Measurement Measurement FrameworkFramework

• Empirical StudyEmpirical Study

• Conclusion and Conclusion and Future WorkFuture Work

Abstractions of software services S1, S2, …, Sn

using an appropriate

model

Attack scenarios A1, A2, …, Am

Compute metrics values for S1, S2, …, Sn

Security evaluation results for S1, S2, …, Sn

in terms of attack scenarios A1, A2, …, Am

Metrics based representations of

software services S1, S2, …, Sn

Predefined internal security metrics based on

the specific service model

Compute attackability for S1, S2, …, Sn

regarding A1, A2, …, Am

Predefined Prediction Rules

Page 6: Complexity Measures for Secure Service-Orieted Software Architectures

• Problem Problem StatementStatement

• Some Related Some Related WorkWork

• Our ApproachOur Approach

Measurement Measurement FrameworkFramework

• Empirical StudyEmpirical Study

• Conclusion and Conclusion and Future WorkFuture Work

Internal Security Attributes with Formalized Properties

Service Complexity

Service Coupling

Service Excess Privilege

Service Mechanism Strength

Page 7: Complexity Measures for Secure Service-Orieted Software Architectures

Security Measurement Abstraction – USIE Model

• Problem Problem StatementStatement

• Some Related Some Related WorkWork

• Our ApproachOur Approach

Measurement Measurement FrameworkFramework

• Empirical StudyEmpirical Study

• Conclusion and Conclusion and Future WorkFuture Work

User

ControlUnit Component_Inputvalidator

UpdateAccount

ValidateInput

successful

response

Failed

{OR}

Table_Users

SetAccount

<<Securitymechanism>> <<Resource>>

<<,Read>>

<<Execute,Read>>

GetAccount

<<,Write>>

UpdateAccount

SM

Component_InputValidator

{E.R

}

ExclusiveExclusiveRS

Table_users

{R}

NLRS

Table_users

{W}

SequrntialSequrntial

RegisterAccount

Login

LogoutUpdateAccount

ProcessPayment

Delivery

CheckoutCarts

AND

The dependencies among the supporting services of the Ordering Service can be characterized as follows: 1) service register is always active before the other supporting services; 2) services logout and update account are always active after login; service delivery is active after service process payment; 3) service process payment is active only after both service checkout cart and login are active.

Page 8: Complexity Measures for Secure Service-Orieted Software Architectures

Sample Service Complexity Metric• Problem Problem StatementStatement

• Some Related Some Related WorkWork

• Our ApproachOur Approach

Measurement Measurement FrameworkFramework

• Empirical StudyEmpirical Study

• Conclusion and Conclusion and Future WorkFuture Work

,, ,cs cs cs cs csU N E L=< < > csU

Measure of Service Complexity: Given a composite service cs and its USIE model

, the Average Service Depth (ASD) for

is defined as

( ) ( )

( )( )

:

1, .( )

0, .

i cs

i cs

i i

n Ncs

i

n N

ii

NumOfServiceDependency n IsAtomicService n

ASD UIsAtomicService n

Where

if n is an atomic service nodeIsAtomicService n

otherwise

=

↓= ■○

( )

.i

i

NumOfServiceDependency n The number of service nodes depending

directly or indirectly on n

=

Page 9: Complexity Measures for Secure Service-Orieted Software Architectures

Attackability Measures for URL Jumping Attack

• Problem Problem StatementStatement

• Some Related Some Related WorkWork

• Our ApproachOur Approach

• Measurement Measurement FrameworkFramework

Empirical Empirical StudyStudy

• Conclusion and Conclusion and Future WorkFuture Work

Generally, we compute the relative attackability by the ratio ReAttack ward

AttackEffort

.

Measure of URL Jumping Attack Effort:

( )

exp related to .

URL Jumping i

i

AttackEffort service

The number of URLs loited the service

-

=

Measure of URL Jumping Attack Reward:

Re ( )

1, ln .

0, .

URL Jumping i

i

Attack ward service

if a URL Jumping vu erability is found in serviec

otherwise

-

↓= ■○

Page 10: Complexity Measures for Secure Service-Orieted Software Architectures

Target Application: The Online Flower Shop System

AdministratorService

Flower Shop Service

CustomerService

AddFlower

Clear Carts

ClearSessions

AddArrangement

ClearGuestBook

SaveArrangement

ClearUsers

Arrangement Management

Service

User ManagementService

Flower Management

Service

SaveFlower

Arrangement Service

Flower Service

Account Service

Payment Service

MiscellaneousService

SelectArrangement

BuyArrangement

RemoveArrangement

SelectFlower

BuyFlower

RemoveFlower

RegisterAccount

Login LogoutUpdateAccount Process

PaymentDelivery

CheckoutCarts

ShowArrangement

Details

ShowFlowerDetails

SearchFlower

SignGuestBook

SendEmail

Shopping Service

OrderingService

• Problem Problem StatementStatement

• Some Related Some Related WorkWork

• Our ApproachOur Approach

• Measurement Measurement FrameworkFramework

Empirical Empirical StudyStudy

• Conclusion and Conclusion and Future WorkFuture Work

Page 11: Complexity Measures for Secure Service-Orieted Software Architectures

Study Environment

Database Server

Application Server

Internet

Attack Workstation

• Problem Problem StatementStatement

• Some Related Some Related WorkWork

• Our ApproachOur Approach

• Measurement Measurement FrameworkFramework

Empirical Empirical StudyStudy

• Conclusion and Conclusion and Future WorkFuture Work

Page 12: Complexity Measures for Secure Service-Orieted Software Architectures

• Problem Problem StatementStatement

• Some Related Some Related WorkWork

• Our ApproachOur Approach

• Measurement Measurement FrameworkFramework

Empirical Empirical StudyStudy

• Conclusion and Conclusion and Future WorkFuture Work

Measurement Results

1.71Customer Order Service3

0.5Customer Shopping Service2

0.25Administrator Service1

ASD(Servicei)ServiceiNo.

Table 1. Metric Values of Service Complexity

0.3330.143020

0.50.2019

0.20.25018

0.250.2017

0.3330.143016

0.3330.333015

0.1670.25014

0.50.25013

0.250.25012

0.250.2011

0.3330.25010

10.16709

0.20.2508

0.20.16707

0.250.206

0.3330.2505

0.50.14304

0.333103

0.250.16702

0.20.2501

Order Service

Shopping Service

AdministratorService

ExperimentNo.

Table 2. Relative URL Jumping Attackability(Attack Award = 1)

Page 13: Complexity Measures for Secure Service-Orieted Software Architectures

• Problem Problem StatementStatement

• Some Related Some Related WorkWork

• Our ApproachOur Approach

• Measurement Measurement FrameworkFramework

Empirical Empirical StudyStudy

• Conclusion and Conclusion and Future WorkFuture Work

Analysis of the Results

0.96063620

0.96943919

0.47437218

0.76722417

0.96063616

0.63219015

0.34513914

0.93489913

0.63219012

0.76722411

0.79930610

0.9999919

0.4743728

0.7438947

0.7672246

0.7993065

0.9927404

-0.0297153

0.8502002

0.4743721

Correlation CoefficientsExperiment No.

0

2

4

6

8

0.0 0.2 0.4 0.6 0.8 1.0

Series: ASDSample 1 20Observations 20

Mean 0.715782Median 0.767224Maximum 0.999991Minimum -0.029715Std. Dev. 0.262823Skewness -1.202200Kurtosis 4.232450

Jarque-Bera 6.083392Probability 0.047754

Table 3. Correlation Coefficients for ASD Metric and Relative URL Jumping Attackability

Figure 6. Analysis Results of Correlation Coefficients

Page 14: Complexity Measures for Secure Service-Orieted Software Architectures

In this work, we have proposed a framework which can be used to assess systematically and objectively attackability in early stage of software development.

Using this framework, we have studied through empirical investigation the relationship between a service complexity metric and the URL Jumping attackability.

We recognize that it is not sufficient to infer a general correlation between the measured structural complexity and the likelihood of successful attack based on only one case study. Although many empirical studies would be required to draw a general conclusion, the current study is a good step in this direction.

In the future, we plan to investigate using the methodology of case study more empirical relationship between various attackability and software security related attributes.

• Problem Problem StatementStatement

• Some Related Some Related WorkWork

• Our ApproachOur Approach

• Measurement Measurement FrameworkFramework

• Empirical StudyEmpirical Study

Conclusion and Conclusion and Future WorkFuture Work