Semiformal framework
for ICT Security Development
Andrzej Białas
The 8th International Common Criteria Conference
8thICCC'07
September 25-27, 2007, Rome
Andrzej Bialas, Eng., PhD,
Information Security Centre
 Information security management systems
and 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 Innovations
and Information Society
Wita Stwosza 7,
40-954 Katowice, POLAND
tel.: +48 32 3595 159
e-mail: [email protected]
2
Introduction
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.
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 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).
3
Problem:
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?
Proposed solution:
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 TOE
in a more precise and consistent way.
3.
Building, on this basis, a computer tool supporting
the IT security development process.
4
Formalization (Common Criteria)
informal
expressed in a natural language
semiformal
expressed in a restricted syntax
language with defined semantics
formal
expressed in a restricted syntax
language with defined semantics
based on well-established
mathematical concepts
Better formalization of the IT security development
process
… 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)
6
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 TOE
and 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, preparing
the TOE summary specification (TSS).
Going to the next, more refined stage, a rationale process is needed
7
ITSDF_ITSecurityDevelopmentFramework
SL_SecurityLibrary
ST_Elaboration
1
BCLWorkout
+<<stateAttribute>>
+develstage : byte
+createST()
+openExistingST()
+saveST()
1
+<<stateAttribute>>
+stagestatus : byte
+forward()
+back()
1
1
Existing UML model of the
security-related
product or system
(EUM_EntryUMLmodel)
SM_SecurityModel
BCL_BusinessConsumerLevel
1
1
STIntroWorkout
+<<stateAttribute>>
+stagestatus : byte
+forward()
+back()
SecurityObjectives
1
1
Classes responsible
for the ST elaboration
SecrityRequirements
1
TSS_TOESummarySpecification
1
PreparePPclaims
1
1
1
+<<stateAttribute>>
+stagestatus : byte
+forward()
+back()
+<<stateAttribute>>
+stagestatus : byte
+forward()
+back()
PPclaims
1
STRationale
1
+<<stateAttribute>>
+stagestatus : byte
+forward()
+back()
1
TOEReqsElaboration
+<<stateAttribute>>
+stagestatus : byte
+forward()
+back()
STRationaleElaboration
TOESecurityEnvironment
1
+<<stateAttribute>>
+stagestatus : byte
+forward()
+back()
TSSElaboration
1
Classes responsible for the intermediate
BCL model and the ST model development
TOESecEnvElaboration
1
TOESecObjElaboration
1
1
+<<stateAttribute>>
+stagestatus : byte
+forward()
+back()
ST_SecurityTarget
STIntroduction
Classes representing data structures of
the intermediate BCL model and the ST model
1
1
*
1
IT Security Development Framework
– general model of the ITSDF (ST example)
1
Classes representing
specification data containers
8
ITSDF as a state machine
EUMexists
EUM analyzing
Done
BCL workout
back(develstate)
forward(develstate)
ST introduction workout
back(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")
Done
TSS rationale
TOE security environment
back(develstate)
forward(develstate)
back(develstate) forward(develstate)
The develstage state attribute points at
the current development stage
Security requirements rationale
TOE security objectives
back(develstate)
forward(develstate)
back(develstate)
forward(develstate)
Security objectives rationale
TOE requirements elaboration
forward(develstate)
back(develstate)
forward(develstate)
back(develstate)
forward(develstate)
TSS for ST workout
back(develstate) Prepare PP claims
2 state attributes: develstage and stagestatus
9
ITSDF – develstage attribute of the state machine
Definition 1: Semantics of the develstage state attribute:
The semantics of enumeration type t develst age  T E of the develstage state attribute is the
function:
I (t devel st age) = lit erals(t develst age)  {  },
where: T E is the enumeration type (always user-defined, being a finite, non-empty set of
enumeration literals), I (t develst age) is a function used for interpreting literals,  -undefined value.
The following interpretation of literals of type t devel st age 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_R
10
Security objectives elaboration stage
TOESecEnvElaboration
*
TOESecurityEnvironment
1
Subjects
1
1
+<<stateAttribute>>
+stagestatus : byte
+forward()
+back()
+elaborate()
+check()
+<<stateAttribute>>
+develstage : byte
+createST()
+openExistingST()
+saveST()
1
1
SecurityObjectiveJustification
+coverage : bool
+whyNeeded : string
+whatIsCovered : string
+coveringGaps : string
+coveredExtras : string
1
Assets
+<<stateAttribute>>
+stagestatus : byte
+forward()
+back()
+elaborate()
+check()
1
TOESecObjElaboration
ST_Elaboration
1
1
SecurityObjectives
Represent other than
"proposed" library objective
items - predefined
or users' defined
1
+dealingTOE : bool
+dealingEnviron : bool
+corrective : bool
+detective : bool
+preventive : bool
+threatDerived : bool
+ospDerived : bool
+assumptDerived : bool
AuxiliaryObjectives
*
1
*
1
Threats
*
ThreatsProposedObjectives
TOE_IT_Objectives
*
*
Environment_IT_Objectives *
*
OSP_ProposedObjectives
EnvironmentAuxiliaryObjectives
*
*
*
*
OSPs
*
AssumptionsProposedObjectives
*
Assumptions
*
11
Security objectives elaboration – general activity diagram
/ develstage=#SEC_OBJ
/ stagestatus=#CHECKED or stagestatus=#CLOSED
/ stagestatus=#ELABORATED
stagestatus=#ELABORATED
:Threats
Transform threats to security objectives starting from these that have objectives proposed
:OSPs
/ develstage≠#SEC_OBJ
Transform OSPs to security objectives starting from these that have objectives proposed
:Assumptions
Transform assumptions to security objectives starting from these that have objectives proposed
:SecurityObjectives
:SecurityObjectives
Gray states concern passing
between stages internal control
TOE-Environment trade-off
/ ForwardCommand
:EnvironmentAuxiliaryObjectives
:TOE_IT_Objectives
:Environment_IT_Objectives
develstage=#SEC_REQ
Overall check of the stage
/ BackwardCommand
/ OK
stagestatus=#CHECKED
The developer decides
/ not OK
develstage=#SEC_ENV
Choose the right development stage to solve the problem
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)
12
Summary of works on the ITSDF framework
– what has been done?
 Analyzing strong and weak points of the IT security development process
and 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 responsible
for 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
o
o
o
o
o
risk analysis
TOE-environment responsibility trade-off support
rationale support (covering analyses and visualization relationships)
self-evaluation facilities
evidences and documentation management
reporting facilities and automatic ST/PP generation
 Validation and improvement with the use of the existing and newly created STs
13
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
14
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 objectives
Informal
(textual, simple generics)
Semiformal generics
functional for the TOE
Semiformal CC
functional components
Semiformal CC
functional components
assurance for the TOE
Semiformal CC
assurance components
Semiformal CC
assurance components
functional for the environment
Informal
(textual, simple generics)
Semiformal generics
assurance for the environment
Informal
(textual, simple generics)
Semiformal generics
Informal
(textual, simple generics)
Semiformal generics
Requirements
Trusted security functions
15
Enhanced generics
Generics
mnemonic names that express common features, behaviours
or actions of different IT security aspects or elements.
Format:
[domain.][group.]family.mnemonic[derived][instance].description[.refinement][.attributes][.operation]
Features:
 Parameterization of generics
 Operations on generics – iteration,
refinement, assigning value to
parameter or leaving it uncompleted
 Defining any generic on the basis
of the other (derivation)
 Grouping generics by their
domains of application
 Assigning attributes
 Building generics chains –
proposing solutions to elementary
security problems
16
Generics groups and families – basic taxonomy
Generic
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 with
distinguished mnemonic names
data and
other assets
{group=#DAgr}
families: #DAD,
#DAS,#DAE,#DAP
subjects legal or illegal
{group=#Sgr}
families: #SNA,
#SAU,#SAH,#SNH
*
DAgrGeneric
+assetValue
SgrGeneric
*
*
+domain
+group
+family
+mnemonic
+derver
+insnum
+description
+refinement
+genattrib
+genoper()
* sec. requirements
for the environment
{group=#REgr}
families:#REIT,#REPH,
#RENIT
REgrGeneric
1
1
1
+paramDAgr
+paramSgr
GenGroup
*
1
1
TgrGeneric
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
+paramDAgr
+paramSgr
+dealingTOE : bool
+dealingEnviron : bool
+eventLikelihood
+assetValLoss
+riskValueAssess() : uint
PgrGeneric
+paramDAgr
+paramSgr
+dealingTOE : bool
+dealingEnviron : bool
trusted security
functions (TSF)
{group=#Fgr}
family: #F
FgrGeneric
1
1*
1
AgrGeneric
security objectives
{group=#Ogr}
families:#OIDA,#OACC,#OADT
#OINT,#OAVB,#OPRV,#ODEX,
#OCON,#OEIT,#OEPH,#OSMN
+paramDAgr
+paramSgr
*
OgrGeneric
*
assumptions
for the environment
{group=#Agr}
families: #AX,#AU,
#AE,#AC,#AP,#AA
+paramDAgr
+paramSgr
+dealingTOE : bool
+dealingEnviron : bool
+corrective : bool
+detective : bool
+preventive : bool
17
Generics example – (dot notation vs. UML notation) 1/2
[domain.][group.]family.mnemonic[derived][instance].description[.refinement][.attributes][.operation]
TDA.CrpAnal.
CrpAnal:TDAItem
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.
PlainText:DADItem
Plain document to be encrypted.
DAD.EncKey_D2.
EncKey_I0_D2:DADItem
Cryptographic keys used as input parameter for encryption or decryption.
SNA.HighPotIntrud.
HighPotIntrud:SNAItem
Intruder having high level skills, enough resources and deep motivation to perform a
deliberate attack.
ST BSI-DSZ-CC-0153: First Evaluation of Philips P8WE5032 Secure 8-bit Smart Card Controller, Philips Semic. Hamburg
18
Generics example – (iteration) 2/2
[domain.][group.]family.mnemonic[derived][instance].description[.refinement][.attributes][.operation]
CrpAnal_I0:TDAItem
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.
DAD.PlainText
DAD.EncKey_D2
SNA.HighPotIntrud
TDA.CrpAnal_I1.
CrpAnal_I1:TDAItem
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.
OCON.BlockCipher.
Both instances are covered by:
The TOE will ensure the confidentiality of keys during
a cryptographic function performed by the TOE
ST BSI-DSZ-CC-0153: First Evaluation of Philips P8WE5032 Secure 8-bit Smart Card Controller, Philips Semic. Hamburg
19
Parameterization associations and security
(covering) associations
Expresses generics parameters (being assets or subjects)
GenParAssoc allowing iteration
DADItem
ParamDA4T
ParamS4T
SNAItem
SAUItem
Subjects and assets
0..*
0..*
0..*
0..*
0..*
ParamDA4O
ParamS4O
0..*
0..*
0..*
1..*
1..*
Threats, OSPs and assumptions
ParamDA4O
TDAItem
ParamS4O
ParamS4RE
Ogr4Tgr
+whyNeeded : string
+coveringGaps : string
+coveringExtras : string
1..*
1..*
0..*
1..*
1..*
ParamDA4RE
1..*
OCONItem
OEITItem
Security
objectives
REgr4Ogr
FunSec4Ogr
+whyNeeded : string
+coveringGaps : string
+coveringExtras : string
1..*
0..*
+whyNeeded : string
+coveringGaps : string
+coveringExtras : string
1..*
0..*
1..*
FunComp
1..*
REITItem
Security
requirements
FunSecClass
Fgr4FunSec
+whyNeeded : string
+coveringGaps : string
+coveringExtras : string
1..*
0..*
FItem
SecAssoc
+class
+family
+mnemonic
+description
+refinement
+dispname()
Security functions (SF)
Supporting chains (items proposed to cover other items)
„threat->objective->requirement->security functions”
20
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
21
The ITSDF software implementation – design library
The ITSDF framework software implementation
Design
tree
Wizard
Visualization
23
The ITSDF software implementation – design visualization
The ITSDF software implementation – ST evaluation
Features helping to achieve the assurance
for 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
PLANNED WORKS:
CC v3.1 implementation, composite / complex TOE development and packages,
library optimization
26
Thank you
for your attention
e-mail: [email protected]
Institute of Innovations
and Information Society
27