The 8th International Common Criteria Conference 8 th ICCC'07 September 25-27, 2007, Rome Semiformal...
-
date post
19-Dec-2015 -
Category
Documents
-
view
222 -
download
2
Transcript of The 8th International Common Criteria Conference 8 th ICCC'07 September 25-27, 2007, Rome Semiformal...
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()
+<<stateAttribute>>+stagestatus : byte
STIntroWorkout
+forward()+back()
+<<stateAttribute>>+stagestatus : byte
TOESecEnvElaboration
+forward()+back()
+<<stateAttribute>>+stagestatus : byte
TOESecObjElaboration
+forward()+back()
+<<stateAttribute>>+stagestatus : byte
TOEReqsElaboration
+forward()+back()
+<<stateAttribute>>+stagestatus : byte
TSSElaboration
+forward()+back()
+<<stateAttribute>>+stagestatus : byte
STRationaleElaboration
+forward()+back()
+<<stateAttribute>>+stagestatus : byte
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()
+<<stateAttribute>>+stagestatus : byte
TOESecEnvElaboration
+forward()+back()+elaborate()+check()
+<<stateAttribute>>+stagestatus : byte
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.
[domain.][group.]family.mnemonic[derived][instance].description[.refinement][.attributes][.operation]
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.
[domain.][group.]family.mnemonic[derived][instance].description[.refinement][.attributes][.operation]
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
+whyNeeded : string+coveringGaps : string+coveringExtras : string
Ogr4Tgr1..*
0..*
+whyNeeded : string+coveringGaps : string+coveringExtras : string
Fgr4FunSec
1..*0..*
Securityobjectives
ParamDA4O
1..*
0..*
ParamDA4RE
1..*
0..*
ParamS4O
1..*
0..*
ParamS4RE
1..*
0..*
+whyNeeded : string+coveringGaps : string+coveringExtras : string
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