ISMS Aspects in Common Criteria Certificates for ...ISMS features, because it may touch all aspects...

ISMS Aspects

in Common Criteria Certificates

for Development Sites

First Results of a study by BSI and SRC, 2005

Bertolt Krüger

6th ICCC 2005

Page 2© SRC Security Research & Consulting GmbH

Contents

I. Introduction and Project background

II. Main Part: Some First Results on ISMS

aspects

III. Summary


I. Project Background

Ongoing study conducted by the German BSI

together with four labs:

� Atsec, SRC, TNO, T-Systems

Study explores the possibility to issue

Certificates for Development Sites

Goal: reduce the redundancy in activities for

a product developer, who needs Common

Criteria evaluations for several products or

who needs assurance in site security for

several customers


I. Background: Possible Approaches

Obvious first approach:

� define an assurance package consisting of components

from the CC classes, which touch secure development and

security of the development environment.

This would include classes like

� ALC (Product Life Cycle, which in particular includes the

security of the development and production site),

� ACM (Configuration Management),

� ADO (which includes delivery procedures for products).


I. Background: Issues be solved

The first, well known, issue:

� Classes ALC, ACM, ADO always have two aspects: Aspects

of the general production site (like physical security

measures) and aspects for the concrete product (like

specific version numbers or project specific development

tools).

� Leads to the necessity to divide the CC classes in some way

in product-specific and non-product specific aspects.

Results on this Aspect will be described in a

presentation by BSI (Frank Sonnenberg )

� Also see that talk for more details on project structure and

motivation for the project


I. Background: Issues to be solved

Two other, closely connected issues:

� maintenance of certificates and

� organisational and management aspects of the security

measures

These issues imply close connection to information

security management.

� connected with standards like the "IT Baseline Protection

Manual" of German BSI, ISO17799 / BS7799, ISO/IEC TR

13335 "Guidelines for the management of information and

communications technology security" and others.


I. Background: ISMS and CC

Therefore first Work Package of of the

project was to analyse coverage of typical

ISMS aspects by ALC (in CC 3.0 ALC will

cover all relevant aspects of former ALC,

ACM, ADO)

This Work Package was conducted by SRC

This presentation will cover results of this

first Work Package


II. ISMS aspects - methods used

The method to investigate ISMS aspects in

CC for this project was as follows:

� We took a study from a former project, where we

defined a “generic” ISMS model

� We investigated, where the elements of this ISMS

are covered by ALC aspects and which specific

issues need to be covered in Site Certification


II. ISMS aspects: Typical ones

Security Policy

Identification and valuation of assets/ Risk

assessment

Definition of security concepts and measures

(including risk acceptance, i. e. the determination

that the measures are sufficient)

Implementation of security measures (safeguards)

Maintaining safeguards

Document management


Security Policy

ISMS aspect: Security Policy

In CC covered by: ALC_DVS.*-2

� In this work unit the evaluators examine the

security policy documents of the developer

Consequence: ALC_DVS shall be part of he

CC-package for Site Certification


Assets/ Risk assessment

ISMS aspect: Identification and valuation of

assets/ Risk assessment

In CC: Not covered explicitly by ALC but

partly covered by

� ASE (the Security Target class) and

� ALC_DVS.2.3C (Justification of sufficiency of

security measures)

Consequence: Include ALC_DVS.2 in CC-

package for site certification. ALC_DVS.1

may not be sufficient.


Assets/ Risk assessment (continued)

In a Site Certification package one may want to add a

refinement to ALC_DVS.2

Refinement could require from the developer

� to provide a classification of assets and

� to provide a justification in the style of risk management,

why his security measures are sufficient to minimise risks

against the assets

� (note that justification of sufficiency as such is already in

ALC_DVS.2 so it is only the methodology of that justification

which needs to be refined)


Definition of security measures

ISMS aspect: Definition of security concepts

and measures and the concluding risk

acceptance step

In CC covered by:

� ALC_DVS.*.1C: Description of security measues

� ALC_DVS.2.3C Justification of sufficiency of

measures

Consequence: ALC_DVS.2 should be part of

Site Certification Package in order to reflect

ISMS good practice


Implementation of security measures

ISMS aspect: Implementation of security

measures (safeguards)

In CC covered by ALC_DVS.*.2C,

ALC_DVS.*.2E (application of procedures)

Consequence: As before, ALC_DVS should

be part of Site Certification package


Maintaining safeguards

ISMS aspect: Maintaining safeguards

In CC: Not explicitly covered by ALC

Consequence: May make sense to add a

refinement to ALC_DVS.2 in the Site-

Certification package

Refinement might require the developer to

describe, how he maintains the quality of

security measures over time (e. g. by internal

audits)


Document management

ISMS aspect: Document management

In CC covered by ALC_CMC

Consequence: ALC_CMC should be a part of the Site

Certification package,

� at least as far as document management is concerned

� (for the technical part of the TOE the CM-Tools may vary

from project to project)

� On the other hand ALC_CMS will almost entirely be product-

dependent, because it is based on the specific configuration

list of the product TOE


Further ALC families: LCD

ALC_LCD: TOE-Life-Cycle may have aspects of all

ISMS features, because it may touch all aspects of

the development environment.

However, we saw no specific impact of ISMS

considerations to the question, which parts of the

Life Cycle model will be TOE dependent or TOE

independent

It may be a good idea to make ALC_LCD an optional

part of the Site Certification Package (in case a

developer has a product independent LC model)


Further ALC families: DEL

Delivery procedures have no specific counterpart in

the ISMS world. From the ISM-point-of-view they are

an example of security relevant

organisational/technical procedures (for which of

course all the ISM methods like risk analysis apply)

So the ISM-analysis gives no specific hint for Site

certification aspects of delivery.

However, if a developer wants to prepare for Re-Use

in an efficient way, he defines a number of delivery

methods in advance a way, which doesn’t depend on

a specific product


Further aspects: Site Visit

Site visits: there needs to be some time frame

defined after which the scheme will require a new

site visit in order to check that methods are still

applied correctly, even if their definition hasn’t

changed.

for ISMS it is a routine issue to have regular audits

This is done similarly today in the BSI scheme: If the

last site visit at a developer’s site was more then two

years ago, a new site visit is necessary for the next

evaluation, even if nothing has changed in the

definition of the ALC related measures.


Further aspects: Site Visit (continued)

For a technical product, once certain technical

security functions are defined and implemented and

the implementation is the same for all samples of the

TOE, one evaluation gives assurance for the future.

In contrast, for organisational measures, even if the

are used unchanged for several years in an

organisation, one has to check regularly that they

are still applied correctly

Re-Auditing is common in ISMS assessment

schemes and might be defined (for example as a

refinement to ALC_DVS) in the Site certification

package or as a scheme requirement


Further ALC aspects: FLR

ALC_FLR can be seen as a specific kind of

maintenance activity. Therefore it could be

mapped into the ISMS maintenance process.

FLR-Procedures can be defined nearly

entirely TOE-independent

So this might be an optional component in a

Site Certification Package


Further ALC aspects: TAT

ALC_TAT can contain TOE-dependent and

TOE-independent sections - some tools may

be used only for one product others for many

products.

It will be up to the developer to declare,

which tools fall in which category. There is

nothing ISMS specific here.

So ALC_TAT should be optional in the Site

Certification package


III. Summary: Overall Result

All important aspects of an ISMS are reflected in one place or

the other in ALC of CC 3.0 (which covers ALC, ACM, ADO from

2.1)

Some Issues need further investigation in order to claim that all

aspects are covered sufficiently

Main result: The “obvious” approach is feasible from

the ISMS point of view

� Define a Site Certificate based on a suitable package from

ALC (will all be covered by class ALC only in CC 3.0)

� Some Site-Certifications specific resp. ISMS-motivated

aspects may be covered by suitable refinements of the

assurance components


III. Sum.: Site Certification Package

The following ALC components shall be mandatory

parts of the Site Certification package:

� ALC_DVS.2 (ALC_DVS.1 is not sufficient) and

� ALC_CMC.* (in order to cover at least document

management- this may be specified more exactly by a

refinement saying that all documents describing site

security need to be covered by the CM-system).

(Note: These are the components necessary from

ISMS perspective. There may be others from the CC-

perspective itself.)



Some refinements to CC components make sense in

order to reflect good ISMS practise. Most should fit

to ALC_DVS.2.

� A classification of assets in the Development Site and a

discussion in the style of risk management, why security

measures are sufficient to minimise risks against these

assets. This is a refinement to the document on sufficiency

of measures, which is needed anyway.

� Some method of regular re-auditing should be part of a Site

Certification scheme. Typical time frames of re-audits are

between one and two years. This may be defined as a

refinement (but may also need some specific scheme

guidance related to certificate maintenance).



Refinements continued:

� a refinement, which requires the developer to

describe, how he maintains the quality of security

measures over time (e. g. by internal audits)


I III. Sum.: Site Certification Package

ALC_LCD, ALC_TAT, ALC_DEL might be optional

components of Site Certification

� Developer should include them, if these aspects will not

change rapidly for future TOEs (or he may be able to

describe several variants, which cover all future cases.)

� New variants (of life-cycle-models, tools or delivery

methods) may be added in form of a Re-Evaluation of the

Site, which may still be more effective than doing it for every

product TOE separately.

ALC_FLR might also be optional

We assume that ALC_CMS cannot (easily) be part of

site certification, since this family includes very TOE-

specific issues (like configuration list).


III. Summary: Relations to other projects

Connections to the evaluation of IT systems as

discussed in the ongoing ISO project 19791

"Security assessment of operational systems" and to

ISMS standards?

Site Certification concentrates on the aspect of

development and production sites, so it is possible

to work with the development environment related

aspects of the CC

For a future evaluation strategy for general ISMSes

one will need coverage of all CC aspects - so this

project is no direct alternative to 19791 or ISMS-

standards.


III. Summary: “Disclaimer”

Note that all results presented here are

preliminary and are no official BSI proposal

for a Site Certification package.


Contact

SRC Security Research & Consulting GmbH

Bertolt Krüger

Graurheindorfer Str. 149a

53117 Bonn

Germany

Tel. +49-(0)228-2806-122

Fax: +49-(0)228-2806-199

E-mail: [email protected]

www: www.src-gmbh.de

Bundesamt für Sicherheit in der Informationstechnik

Frank Sonnenberg

Godesberger Allee 185-189

53175 Bonn

Germany

Tel: +49-(0)228-9582-470

Fax: +49-(0)228-9582-455

E-mail: [email protected]

www: www.bsi.bund.de

Date post:	02-Jun-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

ISMS Aspects in Common Criteria Certificates for ...ISMS features, because it may touch all aspects...

Documents