the 8th international common criteria conference 8 th iccc'07 september 25-27, 2007, rome...

The 8th International Common Criteria Conference

8thICCC'07September 25-27, 2007, Rome

Semiformal framework for ICT Security Development

Andrzej Białas

tel.: +48 32 3595 159e-mail: [email protected]

Andrzej Bialas, Eng., PhD, Information Security Centre

Information security management systemsand supporting tools

ICT Security development (Common Criteria) and supporting tools

PKI, e-government security – applications, projects

CI2RCO – Critical Information Infrastructure Research Co-ordination (EU FP6)

Institute of Innovationsand Information Society

Wita Stwosza 7, 40-954 Katowice, POLAND

2

Introduction

The development of e-business, e-government or e-health applications, and the critical information infrastructure protection will not be possible if, based on the assurance, trust and confidence technologies do not grow.

The presentation deals with the Common Criteria, i.e. ISO/IEC 15408 approach, one of the well established methodologies concerned with the creation of assurance.

Assurance is the confidence that an entity, i.e. IT product or system, called the TOE (target of evaluation), meets the security objectives specified for it.

3

The assurance foundation is created during a rigorous IT development process.The preciseness and the cost of the elaborated specifications are important.

The paper presents an overview of the Author’s extensive work concerning the IT Security Development Framework (ITSDF) based on the ISO/IEC 15408 and ISO/IEC TR 15446. It concerns better formalization of this development process, and improving specification means used to create the Security Target (ST) or Protection Profiles (PP).

4

Proposed solution:

How to perform the IT security development: rigorously, i.e. more precisely, formally, and consistently,

with the justification of the selected variants, and more effectively, i.e. more quickly and cheaply?

Problem:

1. Elaborating a semiformal model of the IT security development process with the use of the UML/OCL approach, i.e. better formalization of this process

2. Creating a set of semiformal means and methods to build IT security related specifications of the TOEin a more precise and consistent way.

3. Building, on this basis, a computer tool supportingthe IT security development process.

Formalization (Common Criteria)

informal expressed in a natural language

semiformalexpressed in a restricted syntax language with defined semantics

formalexpressed in a restricted syntax language with defined semantics based on well-established mathematical concepts

6

Better formalization of the IT security developmentprocess … leads to the „ITSDF framework” concept

The IT security development process is related to the elaboration of the ST or PP specifications

The Common Criteria standard provides the IT security developers with a general, informal guide only (ISO/IEC TR 15446)

The effectiveness of the IT security development process, which is rather complicated, depends strongly on the developers’ knowledge and expertise

The problem is how to make the developers’ efforts easier

The proposed solution is based on the advantages coming from the commonly used UML/OCL approach and assumes the elaboration of the semiformal model of the whole IT Security Development Framework (ITSDF framework)

7

IT security development (ST elaboration)

1. Establishing the so-called security problem definition (security environment) specification, encompassing the internal/external assets, their owners, threats to assets, OSPs – Organizational Security Policy rules to be satisfied, and the assumptions.

2. Setting security objectives on this basis – for the TOEand its operational environment.

3. Using Common Criteria components catalogues and analyzing the above objectives, working out the sets of functional and assurance requirements for the TOE and for the operational environment.

4. Using functional and assurance requirements, preparingthe TOE summary specification (TSS).

Going to the next, more refined stage, a rationale process is needed

SM_SecurityModel

BCL_BusinessConsumerLevel+createST()+openExistingST()+saveST()

+<<stateAttribute>>+develstage : byte

ST_Elaboration

+forward()+back()

+<<stateAttribute>>+stagestatus : byte

BCLWorkout

STIntroduction ST_SecurityTarget

TOESecurityEnvironment

SecurityObjectives

SecrityRequirements

TSS_TOESummarySpecification

PPclaims

STRationale

1

1

1

1

1

1

1

1

1

11

1

1

1

1

1

ITSDF_ITSecurityDevelopmentFramework1

*

1 1

SL_SecurityLibrary

1 11 1

+forward()+back()


STIntroWorkout

+forward()+back()


TOESecEnvElaboration

+forward()+back()


TOESecObjElaboration

+forward()+back()


TOEReqsElaboration

+forward()+back()


TSSElaboration

+forward()+back()


STRationaleElaboration

+forward()+back()


PreparePPclaims

Existing UML model of the security-related

product or system (EUM_EntryUMLmodel)

11

Cla

sses

res

pons

ible

for

the

inte

rmed

iate

BC

L m

odel

and

the

ST

mod

el d

evel

opm

ent

Cla

sses

rep

rese

ntin

g da

ta s

truc

ture

s of

th

e in

term

edia

te B

CL

mod

el a

nd th

e S

T m

odel

8

IT S

ecu

rity

Dev

elo

pm

ent

Fra

mew

ork

– g

ener

al m

od

el o

f th

e IT

SD

F (

ST

exa

mp

le)

Classes responsiblefor the ST elaboration

Classes representing specification data containers

9

ITSDF as a state machine

BCL workout

EUM analyzingDone

EUMexists

ST introduction workout

TOE security environment

TOE security objectives

TOE requirements elaboration

TSS for ST workoutPrepare PP claims

forward(develstate)

Security objectives rationale

Security requirements rationale

TSS rationale

forward(develstate)

Done

back(develstate)

back(develstate)

back(develstate)

back(develstate)

back(develstate)

back(develstate)

back(develstate)

back(develstate)

back(develstate)

forward(develstate)

forward(develstate)

forward(develstate)

forward(develstate)

forward(develstate)

forward(develstate)

forward(develstate)

EUM - Existing UML model is an input for the BCL model. When EUM does not exist, the BCL is elaborated straight on the user's requirements

Every development stage (stagestatus state attribute) can be#ELABORATED ("Under development"),#CHECKED ("Stage positively checked - ready for the rationale", #CLOSED ("All stages checked and the rationale finished")

The develstage state attribute points at the current development stage

2 state attributes: develstage and stagestatus

10

ITSDF – develstage attribute of the state machine

Definition 1: Semantics of the develstage state attribute: The semantics of enumeration type tdevelstage T E of the develstage state attribute is the function: I(tdevelstage) = literals(tdevelstage) { }, where: T E is the enumeration type (always user-defined, being a finite, non-empty set of enumeration literals), I(tdevelstage) is a function used for interpreting literals, -undefined value. The following interpretation of literals of type tdevelstage is assumed:

I(e1) = I(BCL): “Business/consumer level model elaboration”, I(e2) = I(ST_INTRO): “ST introduction elaboration”, I(e3) = I(SEC_ENV): “Security environment (concerns) elaboration”, I(e4) = I(SEC_OBJ): “Security objectives elaboration”, I(e5) = I(SEC_REQ): “Security requirements elaboration”, I(e6) = I(TSS): “TSS elaboration”, I(e7) = I(PP_C): “Preparing PP claims”, I(e8) = I(SEC_OBJ_RAT): “Security objectives rationale”, I(e9) = I(SEC_REQ_RAT): “Security requirements rationale”, I(e10) = I(TSS_RAT): “TSS rationale”.

11

Security objectives elaboration stage

+createST()+openExistingST()+saveST()

+<<stateAttribute>>+develstage : byte

ST_Elaboration

11

11

TOESecurityEnvironment

Assets

Subjects

Threats

OSPs

Assumptions

1

*

1

*

1

*

1

*

+forward()+back()+elaborate()+check()


TOESecEnvElaboration

+forward()+back()+elaborate()+check()


TOESecObjElaboration

TOE_IT_Objectives

Environment_IT_Objectives

EnvironmentAuxiliaryObjectives

AuxiliaryObjectives

ThreatsProposedObjectives

OSP_ProposedObjectives

AssumptionsProposedObjectives

+dealingTOE : bool+dealingEnviron : bool+corrective : bool+detective : bool+preventive : bool+threatDerived : bool+ospDerived : bool+assumptDerived : bool

SecurityObjectives

+coverage : bool+whyNeeded : string+whatIsCovered : string+coveringGaps : string+coveredExtras : string

SecurityObjectiveJustification

1

1Represent other than"proposed" library objectiveitems - predefined or users' defined

1

*

*

1

*

*

*

*

*

*

*

1*

*

12

Security objectives elaboration – general activity diagram

:Threats

:OSPs

:SecurityObjectives :SecurityObjectives

:Assumptions

:Environment_IT_Objectives

:EnvironmentAuxiliaryObjectives:TOE_IT_Objectives

Transform OSPs to security objectives starting from these that have objectives proposed

Transform assumptions to security objectives starting from these that have objectives proposed

TOE-Environment trade-off

Transform threats to security objectives starting from these that have objectives proposed

/ OK

/ not OK

/ develstage=#SEC_OBJ

/ develstage≠#SEC_OBJ

/ stagestatus=#ELABORATED

/ stagestatus=#CHECKED or stagestatus=#CLOSED

/ ForwardCommand

/ BackwardCommand

Gra

y st

ate

s co

nce

rn p

assi

ngbe

twe

en s

tag

es in

tern

al c

ontr

ol

stagestatus=#ELABORATED

Overall check of the stage

The developer decides

Choose the right development stage to solve the problem

stagestatus=#CHECKED

develstage=#SEC_REQ

develstage=#SEC_ENV

Example 1: Using the OCL constraints to define an operation to find security objectives items covering both the TOE and its environment aspects.

SecurityObjectives::commonITObjectives(p:GenFamily) pre: post: result=self.TOE_IT_Objectives.p->intersection

(self.Environment_IT_Objectives.p)

13

Summary of works on the ITSDF framework – what has been done?

Analyzing strong and weak points of the IT security development processand identifying developers’ needs concerning computer aided processes

Elaboration of the general UML model of ITSDF framework and its processes responsible for particular development stages – classes responsiblefor development stages and the containers of the specification data

Models refinement using OCL and building mathematical model of ST and PP Software implementation – wizard driven tool Development of extra facilities:

o risk analysiso TOE-environment responsibility trade-off supporto rationale support (covering analyses and visualization relationships)o self-evaluation facilitieso evidences and documentation managemento reporting facilities and automatic ST/PP generation

Validation and improvement with the use of the existing and newly created STs

14

Improving specification means … leads to the „enhanced generics” concept

The Common Criteria standard provides developers with specification means (a language) only for the security requirement specification stage, i.e. with the semiformal, security components

Specification style and preciseness for stages other than requirements depend strongly on the developers’ knowledge and expertise. The common understanding of these specifications by a CC consumer is required

For this reason the improvement, unification and extension of the specification means is an important issue

The proposed solution is based on creating a set of semiformal means, called enhanced generics, can be used for other IT security development stages, and has features comparable with the well understood components features

15

Means and ways to build the IT security specifications

IT security development stage Used Proposed

TOE description Informal (textual)Informal (textual), semiformal UML models

Security problem definition (Security environment)

Informal(textual, simple generics)

Semiformal generics

Security objectivesInformal(textual, simple generics)

Semiformal generics

Requirements

functional for the TOESemiformal CCfunctional components

Semiformal CCfunctional components

assurance for the TOESemiformal CC assurance components

Semiformal CCassurance components

functional for the environmentInformal(textual, simple generics)

Semiformal generics

assurance for the environmentInformal(textual, simple generics)

Semiformal generics

Trusted security functionsInformal(textual, simple generics)

Semiformal generics

16

Generics

Enhanced generics

mnemonic names that express common features, behavioursor actions of different IT security aspects or elements.

Format:

Parameterization of generics

Operations on generics – iteration, refinement, assigning value to parameter or leaving it uncompleted

Defining any generic on the basisof the other (derivation)

Grouping generics by theirdomains of application

Assigning attributes

Building generics chains – proposing solutions to elementary security problems

Features:

[domain.][group.]family.mnemonic[derived][instance].description[.refinement][.attributes][.operation]

17

Generics groups and families – basic taxonomy

+assetValue

DAgrGeneric

SgrGeneric

FgrGeneric

+paramDAgr+paramSgr

REgrGeneric

+paramDAgr+paramSgr+dealingTOE : bool+dealingEnviron : bool+corrective : bool+detective : bool+preventive : bool

OgrGeneric

+paramDAgr+paramSgr

AgrGeneric

+paramDAgr+paramSgr+dealingTOE : bool+dealingEnviron : bool

PgrGeneric

+riskValueAssess() : uint

+paramDAgr+paramSgr+dealingTOE : bool+dealingEnviron : bool+eventLikelihood+assetValLoss

TgrGeneric

Generics by the IT security issues (groups); please note families specified for each group, e.g. #DAD,#SNA,#TDA,#PIDA,#OACC; families encompass sets of generic items withdistinguished mnemonic names

GenGroup

1

*

1*

1

*

1* 1

*

1

*

1

*

+genoper()

+domain+group+family+mnemonic+derver+insnum+description+refinement+genattrib

Generic

data and other assets{group=#DAgr}families: #DAD,#DAS,#DAE,#DAP

subjects - legal or illegal{group=#Sgr}families: #SNA,#SAU,#SAH,#SNH

threats{group=#Tgr}families: #TDA,#TUA,#TAA,#TIT,#TPH,#TFM

organizational security policy (OSP rules){group=#Pgr}families:#PIDA,#PACC,#PADT,#PINT,#PAVB,#PPRV,#PDEX,#PCON,#PEIT,#PEPH,#PSMN,#POTL

assumptions for the environment{group=#Agr}families: #AX,#AU,#AE,#AC,#AP,#AA

security objectives{group=#Ogr}families:#OIDA,#OACC,#OADT#OINT,#OAVB,#OPRV,#ODEX,#OCON,#OEIT,#OEPH,#OSMN

sec. requirements for the environment{group=#REgr}families:#REIT,#REPH,#RENIT

trusted securityfunctions (TSF){group=#Fgr}family: #F

1

*

18

Generics example – (dot notation vs. UML notation) 1/2

TDA.CrpAnal.Card attacker [paramSNA] may compromise [paramDAD] – user data being encrypted by the TOE or the key needed to calculate the plain text from cipher text. Refinement: To perform this attack the intruder has to know the cipher text but is neither able to use the decryption function of the TOE nor to observe the behaviour of the TOE during the cryptographic operation.

DAD.PlainText.

Plain document to be encrypted.

SNA.HighPotIntrud.

Intruder having high level skills, enough resources and deep motivation to perform a deliberate attack.


DAD.EncKey_D2.

Cryptographic keys used as input parameter for encryption or decryption.

PlainText:DADItem

CrpAnal:TDAItem

EncKey_I0_D2:DADItem

HighPotIntrud:SNAItem

ST BSI-DSZ-CC-0153: First Evaluation of Philips P8WE5032 Secure 8-bit Smart Card Controller, Philips Semic. Hamburg

19

Generics example – (iteration) 2/2

TDA.CrpAnal_I0.Card attacker [paramSNA <=SNA.HighPotenIntrud] may compromise [paramDAD <=DAD.PlainText] – user data being encrypted by the TOE or the key needed to calculate the plain text from cipher text.


CrpAnal_I0:TDAItem

TDA.CrpAnal_I1.Card attacker [paramSNA <=SNA.HighPotenIntrud] may compromise [paramDAD <=DAD.EncKey_D2] – user data being encrypted by the TOE or the key needed to calculate the plain text from cipher text.

CrpAnal_I1:TDAItem

DAD.PlainText

DAD.EncKey_D2 SNA.HighPotIntrud

OCON.BlockCipher.

The TOE will ensure the confidentiality of keys during a cryptographic function performed by the TOE

Both instances are covered by:

ST BSI-DSZ-CC-0153: First Evaluation of Philips P8WE5032 Secure 8-bit Smart Card Controller, Philips Semic. Hamburg

20

Par

amet

eriz

atio

n a

sso

ciat

ion

s an

d s

ecu

rity

P

aram

eter

izat

ion

ass

oci

atio

ns

and

sec

uri

ty

(co

veri

ng

) as

soci

atio

ns

(co

veri

ng

) as

soci

atio

ns

Subjects and assets

Threats, OSPs and assumptions

Securityrequirements

Security functions (SF)

DADItem SNAItem SAUItem

TDAItem

OCONItem OEITItem

REITItemFunComp

ParamDA4T

1..*

0..*

ParamS4T

1..*

0..*

ParamDA4O

1..*

0..*

ParamS4O

1..*

0..*

+whyNeeded : string+coveringGaps : string+coveringExtras : string

FunSec4Ogr1..*

0..*

FItem


Ogr4Tgr1..*

0..*


Fgr4FunSec

1..*0..*

Securityobjectives

ParamDA4O

1..*

0..*

ParamDA4RE

1..*

0..*

ParamS4O

1..*

0..*

ParamS4RE

1..*

0..*


REgr4Ogr

1..*

0..*

+dispname()

+class+family+mnemonic+description+refinement

FunSecClass

GenParAssoc

SecAssocSupporting chains (items proposed to cover other items)„threat->objective->requirement->security functions”

Expresses generics parameters (being assets or subjects)allowing iteration

21

Summary of works on the specification means improvements – what has been done?

Analyzing the IT security development process and identifying the developers’ needs concerning specification means

Informal definition of the dot separated generics

Defining the generic syntax (grammar/BNF) and semantics (Richter’s approach, the same as the one used for the OCL)

Development of generic UML/OCL models and taxonomy

Defining parameterization association classes (GenParAssoc)

Defining association classes concerning mutual covering of items belonging to the neighbour stages (SecAssoc)

Defining the UML/OCL models of the CC components

Reaching a unified representation of generics and components allowing its software implementation

Defining navigation functions: participating(), navends(), roles(), multiplicieties() and full class descriptors

Software implementation – design library for different application domains

Library validation and optimization using existing and newly created STs

The ITSDF software implementation – design library

23

The ITSDF framework software implementation

Design tree

Wizard

Visuali-zation

The ITSDF software implementation – design visualization

The ITSDF software implementation – ST evaluation

26

Features helping to achieve the assurancefor an IT product or system in a more efficient way

the IT security development process is defined more precisely (i.e. in a semiformal way) and developers are guided and supported at any stage, from the preliminary analyses to the final rationale

developers are provided with the unified and semiformal specification means (“a language”) for any development stage; enhanced generics attached to the CC components have the same possibilities as the components

the software tool, being the IT security development framework implementation, offers additional advantages (similarly to other computer-aided tools), e.g. automation, reusability, reporting, statistics, auxiliary analyses, documentation management, decision support, visualization, better compliance with the information security management standards, self-evaluation, etc.

The research, modelling and case-study on other existing examples of security targets and protection profiles are almost completed and now the technology transfer can start

CC v3.1 implementation, composite / complex TOE development and packages, library optimization

PLANNED WORKS:

27

Thank youfor your attention

e-mail: [email protected]

Institute of Innovationsand Information Society

the 8th international common criteria conference 8 th iccc'07 september 25-27, 2007, rome...

Documents