Specification of security environment of IT security-related products ...

Theoretical and Applied Informatics ISSN 1896-5334 Vol. 18 (2006), z. 2 pp 141 - 157

Specification of security environment of IT security-related products according to Common Criteria ANDRZEJ BIAŁAS Institute of Control Systems 41-506 Chorzów, Długa 1-3, Poland Received 16 January 2006, Revised 04 June 2006, Accepted 01 September 2006

Abstract: The paper concerns IT security development and evaluation processes according to the Common Criteria – CC (ISO/IEC 15408) family of standards, and is based on the results of the author’s earlier works dealing with modelling of these processes. The paper focuses on the workout of the security environment specification based on the previously identified features of an IT securityrelated product, presented in [2]. The security environment presents the nature and scope of the IT security-related product and discusses the threats, policy rules and assumptions of the product working environment. This specification is used for the security objectives definition, which is the basis for further IT security development stages. The UML-based approach was introduced to specify the security environment using predefined generics contained within the design library. It is part of the common development framework and a computer-aided tool developed on the framework. Using the UML in the Common Criteria based IT security development process allows achieving more consistent designs in an easier way. Keywords: Common Criteria, IT security, design, evaluation, development, computer-aiding, security engineering, UML, modelling.

1. Introduction The paper deals with IT security development and evaluation processes according to the Common Criteria – CC (ISO/IEC 15408) family of standards [8]. The development process starts from identifying the features of IT security-related products that can be hardware, software, firmware or even a complex IT system. On this basis the security environment specification is elaborated, being the input for further development stages, i.e. security requirements elaboration, and finally security functions built in these products. These functions require the right assurance level, being precisely evaluated according to [5]. The security environment discussed there

142

strongly influences the product security and cost. The coherency, accuracy and quality of the elaborated specification determines the effectiveness of the whole development process as well. The paper is the direct continuation of [2], where the identification of the basic product features was discussed as the initial stage of the IT security development process. The methodology presented there is based also on the results of the author’s earlier works [1], [3] that concern modelling of the IT security development process and creating the semiformal specification means used to build such models. These means are called generics and components. The Common Criteria standard provides developers with the set of semiformal specification means, i.e. functional and assurance components, however they may be used only for security functional and assurance requirements specification. The standard [9] specifies IT security development process verbally and in an informal way. There are two aims of the paper: − to provide developers with the semiformal specification means to support an elaboration stage, other than security functional and assurance requirements elaboration stage, by using elements called generics, − to specify more formally IT security development procedures by using the semiformal UML (Unified Modelling Language) for their specification. Achieving both aims allows creating the computer-aided tool supporting the developers and evaluators in their hard work. The declared Evaluation Assurance Level (in range: EAL1-EAL7) depends on the degree of rigour assumed for the development, use, maintenance, etc. of the product. Thus stricter discipline in development and evaluation means better assurance. The IT security development and evaluation processes, depending on the declared EAL, are very complicated due to many details, dependencies and feedbacks which should be taken into consideration, and rather difficult rationales. That is why the need of specialized frameworks and computer-aided tools basing on them is important and growing [1], [3], [6], [11-13]. The methods dealing with UML [4] are very promising and provide a unified approach to the products and their security features description. The advantages of the UML approach were used: − in the holistic method of the product features and behaviour specification [10], − for modelling complex security-related products, consisting of other securityrelated products, evaluated or not, requiring advanced composition methods [7], − in the development method and tools of advanced Java smartcards meeting the highest EALs [11]. None of these methods is dealing with the IT security development processes. The more so, they do not fully comply with CC development procedures, presented in [9].

143

The modelling approach is growing. To solve their design problems IT developers commonly use the UML-approach. Apart from design problems, they face IT security problems. It will be easier for them to use the same approach to solve both. That is why a new concept of integrating IT product design and IT security development is proposed. The UML community is increasing thus it is of key importance to facilitate the usage of the CC methodology, especially for wide-spread secure COTS (commercial off-the-shelf) products. 2. General view on the IT security development process according to Common Criteria standard All secured IT hardware or software products and systems are called Target of Evaluation (TOE). They are created on the basis of the security requirements specifications: Security Target (ST) –implementation-dependent and Protection Profile (PP) – implementation-independent. The development process according to Common Criteria, discussed in [1-3], comprises the following phases including their transition rationales: − security environment specification, defined by sets of assumptions, threats and organizational security policies (OSP), elaborated during an analysis: TOE assets, purpose and physical environment; − defining security objectives – for the TOE and its environment; − working out the sets of functional and assurance requirements for the TOE and for the environment by use of the CC components catalogues and analyzing the above objectives; − preparing the TOE summary specification (TSS) including security functions – basing on the security functional and assurance requirements – deals with ST specification only. The result is a coherent ST (or PP) document, whose structure is shown in the Fig. 1, as the example. The development process starts with general identification of the IT security-related product, encompassing its purpose, elements, environment and the assets requiring protection. This kind of identification, discussed in [2], is focused on the features needed for ST or PP development. The paper deals with the elaboration of the security environment specification on this basis, used directly to work out security objectives.

1

144

Fig. 1. Security Target (ST) as the set of classes.

The Security Target (ST) or the Protection Profile (PP) structures, well defined within the CC standard, can be expressed using UML class diagrams. Please note that ST data structure is more representative than PP which does not include TSS specification. 3. TOE security environment data model and its UML representation The Common Criteria evaluation is generally oriented towards the products (including system products), rather than working systems. The systems are built using certified and not certified products. This requires precise and realistic specification of working environment and security policy rules must comply. The paper focuses on the TOE security environment class (Fig. 2), which is responsible for this. Its purpose is to define the nature and scope of the security needs (i.e. concerns) to be addressed by the TOE. Comparing to the CC, this model was slightly extended to express the TOE security environment in a more precise way. It encompasses different types of assets – internal, TOE protected and TOE related, assumptions for the working environment, threats and security policy rules, and different types of subjects representing users and other actors, according to the CC functional paradigm [8]. Please note some dependencies and also assets value attributes used for risk assessment. The threat usually specifies explicitly the threatened asset and the intruder or source of the undesired event, but any OSP may express policy rule concerning the given subject related to the given assets, e.g. data access, information flow.

145

Fig. 2. The class diagram of the CC defined basic elements of the TOE security environment.

To precisely specify various aspects of the TOE security environment, different types of generics were used [1], implemented as the design library containing hundreds of such generics [12]. Generic is a mnemonic name, expressing the set of common features, behaviours or actions, relating to different aspects or elements of IT security system, like subjects, objects, assumptions for the security environment, organizational security policies, threats, security objectives for the TOE and its environment, security requirements for the environment, security functions, as well as vulnerabilities, risks, and impacts. Please note that generics are defined not only for the TOE security environment specification. For TOE assets specification the following generics types were defined : − DAD – data objects and other assets, e.g. DAD.EncKey (representing encryption key), − DAS – asset as service, e.g. DAD.CryptoAPIService (i.e. offered by the Microsoft Windows), − DAE – asset as TOE IT environment, e.g. DAE.ITEquip (within the TOE environment), − DAP – asset included within the TOE physical environment.

146

The DAD- and DAS-type are used for TOE internal and TOE protected assets specification, while DAE- and DAP-type describe TOE related assets existing within its working environment. In the same way, different types of subjects are distinguished, representing legal or illegal actors: − SNA – represents an unauthorized subject (individual, user, process); may be internal or external to the TOE; usually expresses threat agents, e.g. SNA.CardIntruder (dealing with the smart card); − SAU – represents an authorized subject; may be internal or external to the TOE; usually expresses legal users or administrators, e.g. SAU.CardApp (“Any application software process or parts of the smart card operating system which reside on the card but are not part of the TOE”); − SAH – deals with the source of an undesirable event caused by accidental human actions or errors; − SNH – deals with an undesirable event caused by non-human actions, deals with physical environment, like fire, flood, earthquake, different disturbances or technical failures. Six types of threats to asset protected by the TOE, or placed within the TOE or its environment, were defined: − TDA – concerns direct attacks made by hackers and other intruders, e.g. TDA.AppDataAttack (“Data [DAD] is referred to, inferred, modified, deleted, or added by an unauthorized [SNA]”), − TUA – deals with users’ activities, e.g. TUA.DataAccidDeleted (“Data were undesirably deleted by an authorized person [SAU]”), − TAA – concerns administrators’ activities, − TIT – deals with software (flaws, malicious codes, etc.) and hardware (failures, power disruption, tampering, line tapping, electromagnetic emanation, etc.) aspects, − TPH – deals with technical infrastructure and physical security of the TOE environment, − TFM – concerns force majeures, accidents, catastrophes, terrorism acts, and other undesired events, and failures possible within the TOE environment. The TOE security environment specification may contain a set of rules dealing with the right TOE use within its working environment, called OSP. The following set of types of these rules was defined: − PIDA – deals with identification and authentication, − PACC – specifies access control and information flow control rules, e.g. PACC.DAC (“The right to access specific data objects [DA] is determined on the basis of: the owner of the object [SAU], the identity of the subject attempting the access, and the implicit and explicit access rights to the object granted

147

to the subject by the object owner [SAU]” – this is a well known Discretionary Access Control Policy), − PADT – concerns accountability and security audit, − PINT – concerns integrity, − PAVB – concerns availability, − PPRV – deals with privacy, − PDEX – specifies general secure data exchange rules, − PCON – deals with confidentiality, − PEIT – deals with the right use of software and hardware within the TOE environment, − PEPH – deals with technical infrastructure (media) and physical security of the TOE environment, − PSMN – encompasses security maintenance (management) aspects, − POTL – concerns technical solutions and legislation, obligatorily used within the organization. To describe different forms of assumptions for the environment the following set of their types (compliant with the [9] standard) was specified: − AX – deals with the relevance of the considered threat, − AU – deals with the intended usage of the TOE, − AE – must be satisfied by the TOE environment (in a physical way, for example), e.g. AE.CertGenApp (“There exist assured applications which generate certificates”), − AC – deals with the connectivity aspects of the TOE, e.g. AC.FirewallConn (“The firewall is assumed to be configured as the only network connection between the private network and the hostile network”), − AP – deals with the personnel, − AA – leads to a choice-given assurance requirement. On this basic structure (Fig. 2), the detailed TOE environment specification was developed presented in the Fig. 3 as the class diagram. It specifies all details used for modelling key aspects of the TOE security environment using generics of the above mentioned types. Other generics, predefined and placed into the library or created on demand by developers, are allowed as well. Any generic can be refined to express adequately and more precisely unique design needs. Security environment and security objectives generics have their basic inter-relations assigned, facilitating these items selection during the IT security development process (not discussed there).

148

TOE description Security-related product model TOE security environment DAD asset

1

1

1

DAS asset

DAE asset

DAP asset

*

1 1

Assets

*

Assumptions

*

*

1

*

*

1111

*

1111

*

*

*

*

*

1 AX assumptions

AU assumptions AP assumptions

1 1 1

AC assumptions

AE assumptions

*

*

AA assumptions

*

* Subjects

SNA subject

*

SAU subject

SAH subject

SNH subject

1

Threats

TDA threat

TUA threat

TAA threat

TIT threat

TPH threat

TFM threat

*

1 1 1 1 1 1

* PIDA policy

PACC policy

*

*

OSP *

*

*

* PADT policy

PAVB policy

PINT policy

*

*

*

PPRV policy

*

*

*

111111 111111 PDEX policy

*

* PCON policy

* PEIT policy

* PEPH policy

* PSMN policy

* POTL policy

Uncovered concerns

Fig. 3. The TOE security environment with generics type specification.

The key issue for the model presented there is the assumed TOE security environment paradigm, concerning risk assessment features (Fig. 4). Please note a threat source, expressed by the subjects-type generics, threatened assets, expressed by the DAD- or DAS-type generic and the textual threat scenario (attack method or event, exploited vulnerability). Please note that assets have their owners (usually SAU or SAA-type generic) for management purpose, and their values used during risk assessment. For every threat a simple risk scenario was added, containing event likelihood and impacts. It will be used at the next development stage of security objectives elabo-

149

ration. This simple method allows ordering the risk scenarios by the risk value, aiding to select proper measures. The same approach was applied to define OSPs, which have subject and asset to the given rule assigned. The model also allows separate items dealing with the TOE and/or its operational environment and set relations between them and the assets and the subjects. It is very difficult to specify all security items at the beginning of the development process. But it is even more difficult to decide what should be covered by the TOE only, by its environment or both. The presented framework allows to postpone these design decisions, when more details have been known.

Fig. 4. Basic dependencies between TOE security environment classes.

One will face a similar problem while choosing the way of the TOE security environment specification: the threat based or the OSPs based. For this stage it is vital to provide the trade-off between its elements. 4. TOE security environment elaboration process on the basis of captured features of IT security-related products The TOE security environment is based on the security-related product features discussed in [1-2] and represented by ST introduction class. The general elaboration scheme, as the UML activity diagram, was shown in the Fig. 5. Please note that TOE service and TOE description are the elements of ST introduction, expressing basic TOE functionality. Fig. 5 presents main and auxiliary swimlanes, which will be considered below on separate diagrams.

150

Security Environment Elaboration

Asset and assumptions

Threats

Risk

OSP

:TOE services

Specify assets and assumptions

/ Not all

Analyze TOE service

Specify threats concerning the TOE service :TOE security environment Mark uncovered or partially covered issues

Analyze the risk / All analyzed :TOE security environment Order the risk scenarios :TOE description

:TOE security environment

Security concerns covering analysis :Uncovered concerns

/ Not fully covered

/ Adding the threat is not possible

/ Fully covered / Adding the threat possible

Add threats concerning the TOE service Add OSPs concerning the TOE service :TOE security environment

Fig. 5. TOE security environment elaboration – the general activity diagram.

Please note, that this TOE security environment elaboration diagram is “riskbased” and represents “threat approach”, while only these items that could not be expressed by threats, are expressed by OSPs. This is generally preferred as a more concise means. Threat specification has higher priority than OSPs specification.

151

:ST introduction

Introductory part - the assets and the assumptions

Identify TOE assets and specify them by a DAD/DAS-type generic; assess its value

Identify assets protected by the TOE and specify them by a DAD/DAS-type generic; assess its value

:TOE internal assets

:Assets protected by TOE

Identify IT assets in TOE environment influencing the TOE and specify them by a DAE-type generic; assess its value

:TOE related assets

Identify physical assets in TOE environment influencing the TOE and specify them by a DAP-type generic; assess its value :TOE related assets Specify AX-type generics, excluding some threats within the TOE boundary and its environment :AX assumptions Specify AU-type generics dealing with the TOE intentional usage

:AU assumptions

Assign an AP-type to define appropriate personnel behavior during the use of the TOE within its environment :AP assumptions Assign an AE-type to the environment responsibility in the TOE protection :AE assumptions

Assign AC-type generics (if needed) reflecting connectivity aspects

Analyze special needs, like considerable protected assets value, assign AA-type generics if needed

Define a basic set of subjects of SAU-types and assign them as the primary assets owners

:AC assumptions

:AA assumptions

:SAU subject

:TOE related assets :TOE internal assets Go to the threats specification elaboration

{OR}

:Assets protected by TOE

{OR}

Fig. 6. TOE security environment elaboration – assets and assumptions specification

The first subordinated diagram (Fig. 6) presents introductory TOE developer activities, attempting to specify assets and assumptions. Three different assets specifications were assumed: included within the TOE, protected by the TOE, and those auxiliary environmental assets which should be protected for the whole TOE security. ST introduction data dealing with the data kind and its location are very important during assets identification. For AC-type generics the connectivity aspects are useful, while for AU- and AP-type all information concerning users and data access.

152

:ST introduction

Repeat this for each of the main use cases

The threats specification elaboration

Identify malicious users' activities and specify them by a TUA-type generic :TUA threat

Identify accidental users' activities or errors and specify them by a TUA-type generic

:SAU subject

:TUA threat

Identify malicious administrators' activities and specify them by a TAA-type generic :TAA threat

:Assets Identify accidental administrators' activities or errors and specify them by a TAA-type generic

:TAA threat

Identify sources of undesirable events caused by accidental human actions or errors and specify them by a SAH-type generic :SAH subject

Identify threats triggered by SAH-type influencing the IT assets within the TOE environment and specify them by a TIT-type generic :TIT threat

:SAH subject

Identify threats triggered by SAH-type influencing the techn./phys. assets within the TOE env. and specify them by a TPH-type generic :TPH threat Identify sources of undesirable events (non-human actions) - specify them by a SNH-type generic

:SNH subject

Identify threats triggered by SNH-type influencing the IT/techn./phys. assets within the TOE env. and specify them as TFM generic

Identify unauth. actors - specify them by a SNA-type generic

:SNA subject

Identify threats triggered by SNA-type influencing the TOE assets and specify them as TDAs

:TFM threat

:TDA threat

Identify threats triggered by SNA-type influencing the IT/tech.l/phys. assets within the TOE env. and specify them as TDAs

Go to the risk analysis

:TDA threat

Fig. 7. TOE security environment elaboration – the threat specification diagram

The second subordinated diagram (Fig. 7) presents threat specifications of different types. During these activities some other actors and their generics are identified – unauthorized and different sources of undesirable events – preliminary sampled in ST introduction [2].

153

The analyzed assets requiring protection (DA-type), their value and vulnerabilities, potential threats agents, sources of undesirable events, etc., allow to create a list of possible threats dealing with the TOE and/or its environment (see attributes – Fig. 4). By adding assessed threats likelihoods and impacts (percentage of the asset value loss), the risk value for these scenarios is assessed. It allows to order them by this value (Fig. 8).

Fig. 8. TOE security environment elaboration – the risk assessment diagram

The analysis of use case diagrams is very helpful while developing the TOE security environment [2]. The diagrams express TOE functionality, i.e. the expected be-

154

haviour. They also support the TOE environment modelling with threats that may disturb this behaviour. :Assets

:ST introduction

:SAU subject

The OSP specif. elaboration Repeat this for each of the uncovered concern :PIDA policy

Identify rules dealing with identification and authentication and specify them by a PIDA-type generic

Identify rules dealing with access control and specify them by a PACC-type generic

Identify rules dealing with audit and specify them by a PADT-type generic

Identify rules dealing with integrity and specify them by a PINT-type generic

Identify rules dealing with availability and specify them by a PAVB-type generic

Identify rules dealing with privacy and specify them by a PPRV-type generic

Identify rules dealing with data exchange and specify them by a PDEX-type generic

Identify rules dealing with aconfidentiality and specify them by a PCON-type generic

Identify rules dealing with right use of software/hardware within the TOE environment (use PEIT-type)

:PACC policy

:PADT policy

:PINT policy

:PAVB policy

:PPRV policy

:PDEX policy

:PCON policy

:PEIT policy

Identify rules dealing with technical/physical security within environment (use PEPH-type)

:PEPH policy

Identify rules dealing with security management (maintenance) within environment (use PSMN-type)

:PSMN policy

Identify rules concerning obligatory technical solutions and legislation (use POTL-type)

:POTL policy

Go to the security environment summary

Fig. 9. TOE security environment elaboration – the OSP specification diagram

155

The last swimlane of Fig. 5 encompasses the elaboration of the semiformal OSP specification (Fig. 9). Its priority is lower than this of the threats specification, as it is suggested in the [9]. Every type of the OSPs has three basic and most important elements: assets – internal, externally protected by the TOE or related, expressed by the DAD-, DAS-type; the authorized subject (SAU-type); and the given policy rule, usually strongly related to the TOE service. The key input data contained in the ST introduction class considered during OSPs elaboration are information dealing with TOE functionality, the users and data access, data flow within the TOE and its working environment, protection needs concerning integrity, availability, and confidentiality, data kind and location, connectivity aspects, etc. It is important to review specified threats against the security concerns, revealing topics not covered, not fully covered, or difficult to cover by threats, and cover them by defining OSPs. Usually some AU- or AP-type specifications should be modified too.

Fig. 10. Security environment elaboration using SecCert computer-aided tool.

5. Conclusions The paper, as the continuation of the work [2], is focused on the TOE security environment elaboration, basing on the previously identified security-related product features. This specification allows to develop successively other stages. The concept presented there was used for the development of the prototype of a computer-aided tool, supporting the whole IT security design and evaluation process

156

[12], shown in the Fig. 10 as the example. Please note security environment generics and their graphic representation. The whole development process is wizard-driven, while wizard is the implementation of the UML activity diagrams. This tool is validated on some real designs concerning digital signature, data encryption and smart card applications, and developed incrementally. Thanks to UML it is possible to specify product features and its security features in a similar way, sometimes using the same tools. The combination of the UML modelling techniques with the Common Criteria development process improves the effectiveness of the IT security development process and leads to wider use of evaluated products to create IT distributed systems.

References [1]

Białas A.: IT security development – computer-aided tool supporting design and evaluation, In: Kowalik J, Górski J., Sachenko A. (editors): Cyberspace Security and Defense: Research Issues, NATO reference: ARW 980492, NATO Science Series II, vol. 196, Springer 2005.

[2]

Białas A.: Identifying the features of the IT security-related products for the IT development process according to Common Criteria, Archiwum Informatyki Teoretycznej i Stosowanej, Polska Akademia Nauk, tom 17 (2005), zeszyt 1, pp. 3-18, 2005.

[3]

Białas A.: IT security modelling, In: Arabnia, H. R., Editor; Liwen He & Youngsong Mun, Associate Co Editors, Proceedings of the 2005 International Conference on Security and Management (The World Congress In Applied Computing - SAM'05: June, Las Vegas, USA), ISBN# 1 932415 82 3, 2005, Publisher: CSREA Press.

[4]

Booch G., Rumbaugh J., Jacobson I.: UML- Przewodnik uŜytkownika, Wyd. II, Wydawnictwa Naukowo-Techniczne, Warszawa 2002, (The Unified Modelling Language – User Guide).

[5]

Common Evaluation Methodology for Information Technology Security, Part 1: Introduction and General Model, Part 2: Evaluation Methodology, 1997,1999.

[6]

CCToolbox: http://cc-control.sparta.com/

[7]

Galitzer S.: Introducing Engineered Composition (EC): An Approach for Extending the Common Criteria to Better Support Composing Systems, Published in the Workshop for Application of Engineering Principles to System Security Design (WAEPSSD) Proceedings, September 2003.

[8]

ISO/IEC 15408, Information technology – Security techniques – Evaluation criteria for IT security (Common Criteria, Part 1-3), 1999.

[9]

ISO/IEC 15446, Information technology – Security techniques – Guide for the production of protection profiles and security targets.

[10] Jürjens J.: UMLsec: Extending UML for Secure Systems Development, UML 2002, Dresden, LNCS, Springer-Verlag, 2002.

157

[11] Lavatelli C.: EDEN: A formal framework for high level security CC evaluations, e-Smart’ 2004, Sophia Antipolis 2004. [12] SecCert:

http://www.iss.pl

[13] TL SET, TL FIT

http://trusted-logic.fr

Wypracowanie specyfikacji otoczenia zabezpieczeń w procesie projektowania według Wspólnych Kryteriów dla produktów teleinformatycznych zawierających elementy zabezpieczeń

Streszczenie Artykuł dotyczy zagadnień projektowania i oceny bezpieczeństwa produktów teleinformatycznych zawierających elementy zabezpieczeń, zgodnie z wymaganiami określonymi we Wspólnych kryteriach oceny zabezpieczeń teleinformatycznych (ISO/IEC 15408) i w standardach z nimi związanych. Wykorzystując wyniki wcześniejszych prac autora, dotyczących formalizacji i modelowania procesu projektowania zabezpieczeń oraz opracowania środków (pewnego rodzaju języka) do tworzenia specyfikacji projektowych, w artykule skupiono uwagę na sposobie wypracowania specyfikacji otoczenia zabezpieczeń na podstawie określonej wcześniej charakterystyki produktu teleinformatycznego (urządzenia, programu, oprogramowania układowego, systemu). W tym sensie artykuł stanowi bezpośrednią kontynuację rozwaŜań zawartych w pracy [2]. Specyfikacja otoczenia zabezpieczeń wyraŜa potrzeby odnoszące się do zapewnienia bezpieczeństwa produktu. Zawiera załoŜenia dotyczące środowiska jego funkcjonowania, występujące w nim zagroŜenia oraz sformalizowane reguły polityki bezpieczeństwa, których naleŜy przestrzegać podczas jego uŜytkowania. Specyfikacja ta pozwala na zdefiniowanie celów zabezpieczeń, które są transformowane na wymagania, a potem na funkcje zabezpieczające (nie dyskutowane w artykule). W celu poprawy efektywności procesu projektowania oraz zapewnienia moŜliwości budowy komputerowego narzędzia wspomagającego, zastosowano język modelowania UML oraz zbiór tak zwanych generyków, opisujących elementarne zagadnienia bezpieczeństwa, stanowiący uzupełnienie, jako środka specyfikacji, komponentów zawartych w standardzie Wspólne kryteria.