APPLYING COMPUTER TOOL TO COMMON CRITERIA METHODOLOGY

(1)

Dariusz Rogowski

Institute of Innovative Technologies EMAG

APPLYING COMPUTER TOOL TO COMMON CRITERIA METHODOLOGY

Introduction

The vast majority of users of software and hardware IT (Information Tech- nology) products demand for some kind of assurance that security functionality of these products are reliable and dependable. Developers try to fulfill these de- mands by following the rules of different security standards which impose requirements on development, documentation and evaluation processes. Next these products can be evaluated by an independent licensed laboratory which can issue a certificate stating that the given IT device fulfills its security specification. In this way the user can get more confidence that the certified product will work securely as it is expected.

One of the security standards developers can use in their practice is the Common Criteria for Information Technology Security Evaluation standard (re- ferred to as “Common Criteria” or “CC” throughout this paper), also known as ISO/IEC 15408 [CC12]. The CC standard provides a set of stringent development and evaluation rules for the security functionality of IT products. The first part of the CC standard is a general introduction to the methodology with the explanation of terms and definitions. The second and the third part describe re- spectively security functional and security assurance requirements for IT products and evidence documentation which is needed during the CC evaluation process.

There are many additional documents supporting developers in using the standard. Till now researchers prepared such documents like technical reports [TR09], and user’s guides [PPST07, Dev07, Eval10]. These documents provides methodologies, techniques, documents patterns and practical hints, and recom- mendations which can be used by developers during writing the CC evidence documentation of their IT products. But this guides-based solution is not enough developers-friendly because they still have to do a lot of exhausting work manu-

(2)

APPLYING COMPUTER TOOL TO COMMON… 179

ally what can be the source of many mistakes [RogNow12]. That is why some computer tools were next applied to improve the work with the guidelines and documents patterns.

Some of these software tools were described in [Kane08, Horie09, Hi- gaki10, Trust13]. In [Rog13] I concluded that these tools were mainly dedicated to building only functional specification document of IT product and some of them were not longer supported by producers. Since these publications the situa- tion has not changed much for better – the developers have not still got one inte- grated software tool with built-in documents patterns according to the CC methodology. Thus far applying the CC standard into the daily developers’ practice is very difficult task so there is a huge demand for consulting CC services on the market. But these services are very expensive and developers seek for other cheaper alternatives in the form of supporting software.

The current paper presents the solution to the developers’ problems men- tioned above. This is the computer aiding system which was worked out in the research and development project titled “Common Criteria compliant, Modular, Open IT security Development Environment” (project acronym – CCMODE) [www1]. The computer system called CCMODE Tools automates evidence elaboration, security analysis and facilitates verification of documentation. An- other result of the project was the set of patterns which can be used by developers in making evidence documentation necessary for CC evaluation and certification processes. These results can solve the common problem of lack of computer tools and patterns supporting developers in designing and manufacturing security-enhanced IT products according to the CC rules. This solution improves the quality of IT products development and documentation, and also facilitates the work of developers who are not familiar with the CC standard.

The paper is organized as follows. Section 1 presents the background and three main processes of the Common Criteria methodology. Section 2 delivers the short description of the CCMODE project research stages leading to the elaboration of documentation patterns and software tools. Section 3 gives an overview of the computer tool main modules. The last section contains discussion and conclusions, and states future work focused on further improvements of the tool.

1. The Common Criteria methodology – the primer

The CC standard assures that if IT products are developed and evaluated according to the given requirements then users will place more confidence to these products. This confidence is measured and quantified in CC by EALs

(3)

Dariusz Rogowski 180

(Evaluation Assurance Levels) within the range from EAL1 to EAL7. If a higher level is chosen then the more stringent development process of an IT product should be used by a developer.

The CC methodology comprises three main steps [Rog13, Biał11]: 1) IT security development which is focused on security analysis and working out a spe- cial document called ST (Security Target); 2) IT product development whose aim is to make the product (called in CC language as TOE – Target of Evalua- tion) and to elaborate evidence documentation; 3) IT security evaluation which is conducted by an independent certified evaluation laboratory in order to assess the evidence documentation and security features of the product.

In the first step the ST document is prepared which says what is to be evaluated in the product. This document describes SPD (Security Problem Defi- nition) – the security problem which is to be solved by the security features built into the product. The security problem describes threats to valuable user’s assets.

Next, in the same document, the security objectives are specified which have to counter the identified threats. These security objectives, expressed in a natural language, are further translated into the language of the CC standard by using SFRs (Security Functional Requirements) components. The ST document describes a specific product and is written by the developer, and it also claims conformance with the declared EAL. The chosen level determines all the requirements which have to be fulfilled during the product development. These requirements are grouped into the packages consisting of SARs (Security Assurance Requirements) components. These all SFRs and SARs are very difficult to follow by developers inexperienced in using the CC rules. This is why documents patterns were built up in the CCMODE project. The patterns have a fixed structure of chapters and sections and have footnotes with hints concerning the CC requirements.

In the second step, according to the written ST and the chosen EAL, the product itself and the rest of the documentation are made. The documentation must follow all the SARs taken from the given EAL package and include issues concerning among others: development of the product – security architecture, product design, functional specification; preparative and operational users guides; aspects of establishing discipline and control in the product development and maintenance during its whole life-cycle; testing the product; vulnerabilities analysis. In this step several documents have to be created and this is why it is a very complex and demanding task for a developer.

In the last step, an independent laboratory makes evaluation tasks according to the Common Evaluation Methodology (CEM) [CEM12]. CEM determines the minimum actions that have to be performed by the evaluator during an evalua-

(4)

tion process where subsystems and modules of the product with built-in security functions are tested and their documentation is verified. After the positive result of the evaluation the product can be further certified by a certification body. The current list of certified products can be found at [www2].

2. Methodology – building the software tool

Little attention has been paid so far to the development of software tools which can support developers in preparing evidence documents. That is why one of the CCMODE project targets was to model and create such a tool which can be based on the design patterns. The details about the building of the CCMODE Tools system and its usage can be found at [Biał12]. At the very first stage of the project the model of a development environment of security-enhanced IT products was worked out. This model was worked out on the basis of such research methods like: security standards documents studies, the surveys and observa- tions of IT products development environments, literature review. This model comprises pattern modules, methods and software which can be used for building similar environments for different types of IT products (software, hardware, etc.). The documents patterns and software models were elaborated by using analysis and logical modeling method.

In the project there were created design patterns for documents. The patterns were made for all security assurance components. Next the patterns were verified and validated by independent experts and developers chosen from the software and hardware industry. The validation was made upon the use cases research method. The developers were to use selected design patterns to make evidence documentation of their software and hardware IT products. As a result of the validation, necessary changes and amendments were incorporated into the patterns. Furthermore, the developers concluded that some automation features should be implemented into the patterns. This enabled to make functional as- sumptions for the software tool.

In the next project stages a prototype of the software tool was developed.

The prototype was next validated in selected development environments in two fields (software and hardware) using the case study method. A few evidence ma- terials were prepared by the testers. These case studies showed what can addi- tionally be implemented in the tool to make the work with documents more ef- fective and simpler. Mistakes in the patterns and the tool were eliminated and some functionality was improved.

(5)

1

m b a s

3

T m n c s

F S

o c c p

q t 182

mod base ana syst

3. R

Too mod nuit can syst

Fig.

Sour

of I cycl cho patt

quir tern

A dule e, e lysi tem

Res

Th ol (

dule ty M

be tem

1. T ce: O

Th T p le m sen tern Th rem ns, t

As a es o eva is, t m an

sul

he (EM

e, e Man e us m an

The g Own

he E prod mod n EA n wh he K ment

term a re

of d alua

test nd th

lts

sys MT) exte nag sed nd p

gene elab

EM duct del.

AL.

hich Kno ts a ms

sult dev ation

ting heir

– C

stem ), D erna gem as proj

eral borat

MT m ts. H A l Ev h ca owl and

and t th velo n m g an

r fu

CC

m c Doc al su ment

an ect

mod tion b

mod Her list o very an b ledg d ac

d de he C

pm meth nd f unct

CMO

cons cum upp t –

add s da

del o base

dule re it of e y as be la

ge B ccom efin

CCM ment

hod flaw tion

OD

sist ment port BC ditio

ata.

of th d on

e su is p evid sura ater

Bas mpa nitio

MO t en dolo w re nalit

DE T

of ts G ting CM ona . A

he C n [Ro

uppo pos denc

anc r edi

se i any ons

ODE nvir

ogy eme ty.

Too

f the Gen g sy or al so

gen

CCM og13

orts ssibl ce d ce co ited s a ying s wh

Da

E T ronm y, a

edia

ols

e fo nera ystem

Inf our nera

MOD ].

s the le to doc

omp d in

sou g do hich

ariu

Tool men and

atio

s sy

follo ator ms, form rce al m

DE T

e co o de um pon

the urce ocu

h ar sz R

ls sy nt m ex n. N

yst

owi r (G

, op mati of mod

Tools

onfi efin ment

nent e Ge e of ume

re a Rog

yste man xtern

Nex

tem

ing Gen ptio

ion assu del o

s sy

figur ne th ts is

t fro enD f co ents also

gow

em nage nal xt s

m m

mo nDo onal Se ura of th

stem

rati he d s de

om Doc onte lik o ac

ski

wa eme su ecti

mai

odu oc), l sec ecur ance he s

m

on desi fine the app ext- ke C

cce as w ent, uppo

ion

n m

ules K cur rity e to sys

of t ired ed a e lis

plic -sen CEM

ssib wor , de orti n de

mo

: E Know

rity Ma o the tem

the d EA auto

t is catio

nsit M.

ble rked esig

ng escr

du

Envi wle sys ana e w m is

dev AL oma con on.

tive It in

d o gn p

sof ibe

ules

iron edge stem agem who

dep

velo lev atica

nne

he com oth

ut w patt

ftw the

s

nme e B ms ( men le C pict

opm vel a ally ecte

elp a mpr her

whi tern ware e m

ent Base

(Bu nt – CCM

ted

ment and y ac d w

abo rise mo

ich ns, k e fo modu

Ma e, E usin – IS MO

in

t en d the ccor with

out t es d odul

int kno or s ules

ana Eva ness SM) ODE

Fig

nvir e TO rdin

the

the desi les.

tegr owle secu s of

agem alua s Co

) w E T gure

ronm OE ng to

e de

CC gn It

rate edg urit f th

men atio

onti whic

Tool e 1.

men life o th esig

C re pat als

es ge ty he

nt on i-

h ls

nt e- he gn

e- t- o

(6)

includes some notions of the project researchers concerning the ways how to re- solve typical security problems with predefined security objectives, threats, as- sumptions, and security policies.

The external systems support versioning of files and documents – Subver- sion (SVN) application; modeling, development and analyses which are made with the usage of UML (Unified Modeling Language) – Enterprise Architect (EA); flaws reporting and flaws remediation – Redmine; management, plans and scenarios of tests – TestLink.

The evaluation module is used to verify the development environment against the CC requirements and to evaluate evidence documents according to the CEM methodology.

After the project is completed and properly configured the edition of the evidence documents can be started by using the GenDoc module.

3.1. Documents generator (GenDoc)

GenDoc is used for editing evidence documents based on the design patterns. In order to evaluate the TOE, an ST document and accompanying documents must be prepared. These additional documents are determined by the chosen EAL. This section shows by the example of ST how the software tool is used for filling in the patterns. The structure of the patterns, context-sensitive help and data links to modules of the CCMODE Tools were described.

The main editor window is depicted in Figure 2. Every pattern was prepared as a tree of data fields which represent chapters, sections and subsections of the output document. The tree is based on the requirements of the given CC compo- nent. Some of the fields are automatically filled in with the information taken from the Knowledge Base and other external software modules such as EA, EMT, SVN, TestLink. In order to create the document, the user must follow all the tree branches and find out which fields have to be completed.

(7)

1

F S

t r n t s t i s

m

s c p s t p c m 184

Fig.

Sour

the read nec the sele tion in th sou

men

sect cial part syst ture prod call mai

2. T ce: O

Ev inf dy t ess

inf ecte ns, t he d rce

A nt c Th tion l plu t of tem es w

duc ly u in f

The m Own

very form to u

ity form ed a

tips data s – After an b he m n w

ug- f th m. T whic ct. T uplo featu

main elab

y fi mati use

to c mati and s an a fi the r co be g mo whic in s he C The

ch h The oade

ure

n wi borat

ield ion

– it cha ion cu nd g

ield e ex omp gen

st im h is soft CCM

plu help e se

ed t s of

indo tion b

d ha n to t co ange n an

rren guid d; ex xtern pleti

erat mp s ou twa MO ug-i p in cur to t f th

ow o base

as it be omp

e an nd r

ntly deli xam

nal ing ted porta

utsi are w ODE

in s n d rity the p he p

of th d on

ts o de pris ny i requ y ed ines mple sys all by ant ide was E To supp efin pro pro lug

he G n [Ro

own elive ses t

info uire dite s w es – stem

the a u

par the s de ool port ning oble oper g-in

enD og13

n co ered the orm eme ed b whic – sa m fr e in

ser rt o e sc evel

s sy ts d g th em r se too

Da

Doc a ].

onte d. T

tex matio

ents bran

h h amp from nform

and of th ope lop yste deve he s

def ectio

ol w ariu

appl

ext h The xt w on s tak nch help ple m w mat d sa he S e of

ed em elop secu fini ons were

sz R

licat

help e fo whic

in i ken of p th

of i whic

tion aved ST p f th

in t and per urit tion of e de

Rog

tion

p w ollow

ch i it; C n fro f the

e u info ch th n in d in

patt e C the d u rs b ty p n (S f the

escr gow

with

whic win is re Com om e pa user orm he d n the n the tern CC m

CC uses

y a prob SPD e ST ribe

ski

h the

ch g ng t ead mm the atte

to mati data e pa e SV n is met CMO s ba appl blem D) m T do ed.

e ST

give type dy to mon

e C ern;

wr on a w atter VN

the tho OD asic lyin m th mad ocu

T pat

es g es o o us Cri CC s

hin rite

for were

rn, rep e se dol DE p

fea ng w hat de i ume

ttern

guid of h se b iteri stan nts

dow r the

do the posi ecur logy proj atur wiz

is t in th ent.

n

deli help by t

ia h nda

– t wn e gi own e ou

itory rity y. T ject res ard to b he p In

ines p ar the help ard

thes pro iven nloa

utpu y of y pr That t. T of ds an

be s plug

the s an re d use p –

acc se a ope n da aded ut ev

f the obl t is The

the nd solv g-in e ne

nd h dist er w

com cord are er in

ata d.

vide e pr lem wh plu e EA

infe ved n is ext

hint ting with mpr ding inte nfor fiel

enc roje m de hy t ug-i A e ferri d by s au sub

ts ab guis hout

rise g to erpr rma ld;

ce d ect.

efini the n is exte ing y th utom bsec

bou shed t th es a o th reta atio

dat

docu

itio spe s th erna fea he IT

mati ctio

ut d:

he ll he a- on

ta

u-

n e- he

al a-

T i-

n

(8)

3

i t r d p

F S

s

•

• 3.2.

ing tion ronm drag prob

Fig.

Sour

sect

• A t f t h

• A p r p

• O d . Pl

Th suc nal

men g-an blem

3. B ce: O

In tion Ass tion form type hard Ass pro ron pro OSP dur

ug- he p ch sec nt, nd- m d

Basic Own

n Fi ns o set – n, p

m):

e (A dwa sum vid nme vid P (O res,

-in t plu elem urit sec -dro defi

c ele elab

igur of th – th proc tra Ass are mpti de s nt t de a

Org or

too g-in men ty p curit op o initi

eme borat

re 3 he t he u cess ansf set t dev ion secu that ll o gan gui

ol fo n ha nts poli ty f obje

ion

nts o tion.

3 th tool user s, s ferr typ vice

– it urity t do of it

isat idel

A

or d as t of ices func ects and

of th

here lbox r’s syst red, e):

e.

t is y fu oes

s se tion line

PPL

defi the SP s, se ctio s w d it

he p

e ar x [C goo tem

pr bus

ma unc no ecur nal es im

LYIN

nin for PD a

ecu onal with ts so

lug-

re t CC1 ods m da oce sine

ade ction ot m

rity Sec mpo

NG C

ng s rm o as ( urity l req

spe olut

-in to

the 12]

tha ata, esse ess

on nali meet y fun

curi osed

COM

sec of a (Fig y ob qui ecia tion

oolb

fol : at h

da ed,

pro

the ity t th nct ity d by

MPU

urit a sp gure bjec

rem al w n.

box

llow

have atab

stor oce

e op of hese ion Po y or

UTER

ty p peci e 3 ctiv men wiza

win

e to base red ss,

pera the e as nalit licy rga

R TO

prob ial t

): a ves f nts,

ards

ng m

o be e. T d, di cry

atio e TO ssum ty a y) – niz

OOL

ble tool asse for sec s w

main

e pr The

ispl ypto

onal OE.

mpt anym

– th atio

L TO

m lbox ets,

TO curit whic

n o

rote as laye ogra

l en . If tion mor his

on i O CO

x w thr OE, ty f ch f

obje

ecte ssets

ed, aph

nviro f the ns, t

re.

des in th

OMM

with reat sec func faci

ects

d b s c etc hic k

onm e T the

scrib he o

MON

h obj ts, a curi ctio ilita

s of

by th an c., th

key

men TOE TO

bes ope

N…

bjec assu ity ons.

ate c

f SP

he T hav he y, so

nt in E is OE

s se erati

ts n ump obj Th crea

PD

TOE ve

ass oftw

n or pla ma

ecur ion

need ptio ect hese

atio

an

E, e the ets ware

rder ace ay n

rity al e

ded ons, ive e ar on o

d R

e.g.

e fo can e ap

r to ed in

not

rul envi

d for , or

s fo re th of s

Rea

.: in orm n h ppl

be n a be

les, iron

r de rgan or e he m secu

liza

nfor (A have icat

ab an e abl

pr nme

18

efin nisa envi mai urit

atio

rma Asse e th

tion

le t envi

le t

roce ent.

85

n- a- i- in ty

on

a- et he n,

to i- to

e- .

(9)

1

•

r i

( a t s o

F S

186

• S e t

• T

• S s

• S i p t

• S c

• S s n

rela its u

(Fig a th thre scri on a

Fig.

Sour

Sub elem that Thr Sec sho Sec imp pro tive SFR curi Sec scri nica

Th ation usag Th gure hrea eat iptio an a

4. T ce: O

bjec men t co reat curi ould curi plem

vid es fo Rs (

ity curi iptio al m he ns b ge c he o e 4 at d occ on asse

Thre Own

ct – nts) onta – it ty o d ac

ty o men ding for t (Se obj ty f on mec too betw can obj 4 an defin

curr of t et.

eat d elab

– ac ) th ain o

t co obje chie

obje nts t g its the ecur ject fun of h chan olbo

wee n be

ect nd 5

niti renc the

detail borat

ctive hat p or r onsi ecti eve ecti tech s se

TO rity tive

ctio how nism ox a

en t fou s ar 5) ion ce a

thr

ls w tion.

e en per rece

st o ive in o ive hni ecur OE).

Fu es fo

on – w th ms t also the und re d wit

wh and reat

windo

ntity rform

eive of an for orde

for cal rity . unct

or th – it he T that o in

obj d in drag th d hich d th

t wh

ow

y in ms e in n ad r the er t r en and y fu

tion he T

sho TOE t th nclu ject my gge deta h co e v hich

n th op nfor dver e TO to so nviro d p unct

nal R TOE ows E s he T udes ts. M y pa ed-a

aile ons valu h sh

Da

he T pera

rma rse OE olv onm proc

tion

Req E in s th atis TOE s co Mo aper and- d d ists ue o how

ariu

TOE ation ation acti – i e it men cedu nalit

quir n th he g sfie E us onn re d r [R -dro desc s of of p ws a

sz R

E (u ns o n).

ion it co ts pa nt – ural ty (

rem he f gene

s al ses

ecto deta Rog

opp crip f: m poss adv

Rog

use on

per onsi art – the

l m (wh

ment form eral ll th for ors ails g14]

ped ptio mne sibl vers

gow

ers, obj

rfor ists of t e op meas

hich

ts) m of

l im he S thi

an ab ].

sym ns.

mo e a e a

ski

thr ject

rme s of the pera sure h is

– th f th mple

SFR s pu nd r

out

mbo Fi onic sse ctio

reat ts (p

ed b f a s sec atio es to

de

hes he C

eme Rs.

urp eali t the

ols gur c thr

t lo ons

ag pas

by a set o curi onal o as efin

se a CC r

enta It p ose izat e pl

wh re 4 rea osse

per ent ssiv

thr of o ity p

l en ssis ed

are a requ atio prov e.

tion lug-

hich 4 d t na es c

rfor s, p ve e

reat obje prob nvir st th by

a tr uire on o vid

n in -in

h ha epi ame caus rme

proc entit

age ectiv

blem ronm he T

the

rans eme of th es t

nsta and

ave cts e; t sed ed b

cess ties

ent ves m.

men TOE e se

slati ents he S the

nce d th

dia the the

by by a

ses, s in

on s tha

nt o E in ecur

ion s.

SFR gen

es f he e

alog e ex

lik y a a th

, ha n th

an a at th

of th n co rity

n of

Rs a nera

for m exam

g w xam elih thre hrea

ardw e T

asse he T

he T orre y ob

f the

and al t

mak mpl

wind mpl hoo eat;

at a war TOE

et.

TOE

TOE ectl bjec

e se

d de tech

kin le o

dow le o od o

; de agen re E,

E

E ly c-

e-

e- h-

ng of

ws of of e- nt

(10)

F S

h i

l t r o

t

F S Fig.

Sour

how ing

lem tion requ on t

the

Fig.

Sour 5. R ce: O

In w th to t A m de

ns w uire the p

In use

6. T ce: O

Ratio Own

n Fi his s the t A use fini whic eme pre n th er (F

The Own

onal elab

igur secu thre er s ition ch s ents def he re

Figu

SPD elab

le wi borat

re 5 urity eat i elec n of supp . Th fined

esu ure

D gra borat

indo tion.

5 th y ob

is e cts f the port he d d se lt, t e 6).

aphi tion b

A

ow f

he s bjec

ffec all t e TO t us dedu

ecur the .

ical base

PPL

for th

secu ctiv ctiv the OE sers ucti rity

gra

mod d on

LYIN

he c

urity e is ve (i nec E. M s wi ions y obj aph

del n [Ro

NG C

chose

y ob s ach it m

cess More ith c s are ject hical

og14 COM

en th

bjec hiev mean

sary e ov cho e ba tive

l fo

].

MPU

hrea

ctiv ved ns th y sy ver t oosin

ased es, a orm

UTER

at an

ve ra d. If hat ymb

the ng d on and m of

R TO

nd se

atio f the the bols plu sec n th thre f SP

OOL

ecur

onal e se giv s in ug-in

urit he w eats PD

L TO

rity o

le d ecur ven ord n o ty o weig s sto

and O CO

obje

deta rity thre der t

ffer obje ghts ored d its

OMM

ectiv

ailed obj eat to c rs w ectiv s pa

d in s so

MON

ve

d de ject

is c com wiza ves aram n the olut N…

escr ive coun mple

ards and mete

e kn tion

ript is m nter ete t s wi d se ers o now n ar

tion met red) the ith i ecur of th wled

e w de t the ).

sec infe rity he o dge work

emo en t

curit errin y fun obje bas ked

onstr the

ty p ng f ncti ects se.

d ou 18

rate trac

prob func iona s an

ut b 87

es c-

b- c- al nd

y

(11)

This graphical form of SPD can be easily analyzed by the developer because all the elements of SPD with its solution together with the relations between them are gathered in one place. The solution implementation is showed by SFRs and security functions.

Next this SPD is automatically uploaded to the ST document and can be ed- ited in the documents generator (GenDoc) application. There is no place here to describe the whole methodology of the SPD elaborating because it is an exten- sive topic but the reader can find more details about the SPD issue in the following paper [Biał13].

Discussion and conclusions

The paper presented the computer-aided tool – CCMODE Tools. The tool was worked out in order to support developers in designing and manufacturing IT products according to the stringent rules of the CC standard. Using the CC methodology by users not familiar enough with the standard is very difficult and time consuming task.

The results of the described project are: the EMT application which helps in projects management, the GenDoc tool which supports creating evidence documents, and finally the plug-in application which facilitates elaboration of the SPD and its solution.

For the developers the CCMODE Tools system delivers the complete solution which facilitates writing evidence documents and security analysis of the IT product that is to be evaluated and certified. The context-sensitive help connected to every module of the CCMODE Tools allows the developers to concentrate on building the content of the documents only. Developers are not distracted by think- ing about the form of the documents or by searching necessary requirements in the CC standard. The tools facilitates and speeds up the IT security development process, and improves the quality of evidences because they include all details required by the considered assurance components and best practices.

For the researchers the results of the CCMODE project can pave the way for using the CC standard in early stages of developing security features for their prospective IT security-enhanced products. The results could be also the starting point for seeking and improving the risk analysis methods of choosing the best security objectives for the given threats.

The CCMODE Tools system can be used for developing security functionality of different types of IT products (hardware, software, firmware, systems).

For example the CC methodology and CCMODE Tools were used in an experi-

(12)

mental laboratory of the EMAG Institute – SecLab [BiałFli14] for development of intelligent sensors for the mining industry and specialized software. The tool was also validated on the example of a data diode [Rog14] and a biometric system [Biał13]. Thus the tool can be used by developers for a wide range of IT products and system.

There are of course some limitations of the presented software solution. It concerns mainly the knowledge base which does not include help with all possible answers for developers problems. It does not also include all suitable security objectives which can counter all likely threats which are used in defining the security problem. The knowledge base should be constantly extended and tuned by using feedback from developers on practical usage of the tool. Further, the documents generator application GenDoc produces evidence documents which sometimes have to be manually complemented in some sections by developers.

It has reasons in the limited structure of the evidence patterns and limited automation features of the GenDoc application. There will be always some activities which cannot be automated and information which have to be written down manually. But in spite of these drawbacks the CCMODE Tools system supports the developers in such a way that gives a great chance to evaluate IT products successfully in a independent Common Criteria evaluation laboratory.

Future researches will be focused on enhancing the risk analysis module of the plug-in and on extending the knowledge base. The plug-in could implement the costs of security measures, probability of threats, costs of possible assets losses, etc. These could support users in decision making according to security objectives and costs of their implementation. The knowledge base data could be extended by adding new guidelines and new relations between the SPD objects (threats, security objectives, and SFRs) used by the inferring wizards.

References

[Biał11] Białas A. (red): Zastosowanie wzorców projektowych w konstruowaniu zabezpieczeń informatycznych zgodnych ze standardem Common Criteria.

Wydawnictwo Instytutu Technik Innowacyjnych EMAG, Katowice 2011.

[Biał12] Białas A. (red): Komputerowe wspomaganie procesu rozwoju produktów informatycznych o podwyższonych wymaganiach bezpieczeństwa. Wy- dawnictwo Instytutu Technik Innowacyjnych EMAG, Katowice 2012.

[Biał13] Białas A.: How to Develop a Biometric System with Claimed Assurance.

Proceedings of the 2013 Federated Conference on Computer Science and Information Systems (FedCSIS), pp. 775-780.

(13)

[BiałFli14] Common Criteria Compliant It Product Development in the Experimental Seclab Laboratory. Proc. of CSS’2014, Uniwersytet Ekonomiczny, Ka- towice (accepted for publication).

[CC12] Common Criteria for Information Technology Security Evaluation, part 1-3, ver. 3.1, rev. 4, 2012.

[CEM12] Common Methodology for Information Technology Security Evaluation (Version 3.1, Revision 4) Evaluation Methodology. CCMB, September 2012.

[Dev07] Guidelines for Developer Documentation According to Common Criteria Version 3.1, BSI, 2007.

[Eval10] Guidelines for Evaluation Reports According to Common Criteria Version 3.1, Version 2.00, BSI, 2010.

[Higaki10] Higaki W.H.: Successful Common Criteria Evaluations. A Practical Guide for Vendors. Create Space Independent Publishing Platform, 2010.

[Horie09] Horie D., Yajima K., Azimah N., Goto Y., Cheng J.: GEST: A Generator of ISO/IEC15408 Security Target Templates. In: Computer and Informa- tion Science 2009, SCI 208. R. Lee, G. Hu, H. Miao (eds.). Springer- Verlag, Berlin, Heidelberg 2009, pp. 149-158.

[Kane08] Kane I.: Automated Tools for Supporting CC Design Evidence. 9th Inter- national Common Criteria Conference, Jeju 2008.

[PPST07] The PP/ST Guide, Version 1, Revision 6.2, BSI, 2007.

[Rog13] Rogowski D.: Computer-aided Tool Based on Common Criteria Related Design Patterns. In: Business Informatics. J. Korczak, H. Dudycz, M. Dyczkowski (eds.). Wrocław University of Economics Research Pa- pers 2013, No. 3(29), pp. 111-127.

[Rog14] Rogowski D.: Software Support for Common Criteria Security Develop- ment Process on the Example of a Data Diode. In: Advances in Intelligent and Soft Computing. Vol. 286. W. Zamojski et al. (eds.). Springer 2014, pp. 363-372.

[RogNow12] Rogowski D., Nowak P.: Pattern Based Support for Site Certification. In:

Complex Systems and Dependability AISC Vol. 170. W. Zamojski et al.

(eds.). Springer-Verlag, Berlin, Heidelberg 2012, pp. 179-193.

[TR09] ISO/IEC TR 15446 – Information Technology – Security Techniques – Guide for the Production of Protection Profiles and Security Targets. JTC 1/SC27, Berlin 2009.

[Trust13] Trusted-labs. www.trusted-labs.com, accessed May 2013.

[www1] http://www.commoncriteria.pl.

[www2] http://www.commoncriteriaportal.org/, 2014.

(14)

ZASTOSOWANIE NARZĘDZI KOMPUTEROWYCH W METODOLOGII COMMON CRITERIA

Streszczenie

Artykuł obejmuje prezentację rozwiązania, jakim jest system informatyczny opra- cowany w ramach projektu badań i rozwoju pt. Common Criteria compliant, Modular, Open IT security Development Environment (CCMODE). System informatyczny zwany CCMODE Tools automatyzuje opracowanie dowodu, analizę bezpieczeństwa i ułatwia weryfikację dokumentacji. Proponowany system jest rozwiązaniem dla doskonalenia ja- kości rozwoju i dokumentacji produktów technologii informacji oraz ułatwia pracę pro- jektantom, którzy nie znają standardu CC. W artykule przedstawiono podstawy i główne procesy metodologii Common Criteria, umieszczono krótki opis projektu CCMODE, scharakteryzowano główne moduły systemu, sformułowano wnioski i określono kierun- ki dalszych badań.