KumbangSec: An Approach for Modelling Functional and Security Variabilityin Software Architectures

Varvana Myllarniemi, Mikko Raatikainen, Tomi MannistoHelsinki University of Technology

Software Business and Engineering InstituteP.O. Box 9210, 02015 TKK, Finland

{varvana.myllarniemi, mikko.raatikainen, tomi.mannisto}@tkk.fi

Abstract

Software products often need to vary in terms of func-tionality, but also in terms of quality attributes. We describeKumbangSec, which in an approach for modelling func-tional and security variability applying different architec-tural viewpoints. KumbangSec builds on an existing vari-ability modelling method, Kumbang, by extending it withsecurity engineering concepts. KumbangSec consists of aconceptualisation and a language implementing the con-ceptualisation. The semantics for the conceptualisation hasbeen described using natural language; the syntax for thelanguage has been defined in a grammar. KumbangSec canbe supported with a configurator, which is an intelligent toolsupporting derivation of products that each satisfy specificand different functional and security requirements. Sucha tool, KumbangSec configurator, is currently being devel-oped.

1 Introduction

Quality attributes, such as performance, security andavailability, are important in many industrial software prod-ucts. Quality attribute has been defined as a feature or char-acteristic that affects an item’s quality [16]. Many qualityattributes are architectural, meaning that the architecture ofthe software is critical to their realisation, and these quali-ties should be designed in and evaluated at the architecturallevel [4].

Today, many software product companies have to facethe diversity of customer needs. Instead of developing asingle product as a compromise of these needs, many com-panies offer several software products with slightly varyingcapabilities. Variability is the ability of a system to be ef-ficiently extended, changed, customised or configured foruse in a particular context [36]. Feature models [19] are one

of the first widely known approaches to express variability.Recently, several other approaches to express variability bymodelling have emerged. Modelling methods such as or-thogonal variability modelling [27] and COVAMOF [33]augment other models of software to express variability.These methods can be used at any level of modelling: at therequirements, architecture or detailed design level. In con-trast, Koala [37] and its derivate Koalish [2] are modellingmethods that contain specific constructs for variability andaddress only architectural level modelling. Finally, despitethe lack of explicit constructs for variability, existing mod-elling methods such as UML are used to express variability[11].

However, research on variability rarely addresses qual-ity attributes. In particular, most variability modelling ap-proaches do not have explicit constructs for quality at-tributes. Despite this, there are industrial cases in whichthe products in a product family have different quality at-tribute requirements; such examples of varying qualities in-clude security [10] and performance [25]. Thus quality at-tribute variability needs to be realised [12, 22, 26, 24]. Sincesoftware architecture is critical to the realisation of manyquality attributes, modelling quality attribute variability isrelevant at the architectural level. Further, the fact that soft-ware architecture is a key asset in realising software productfamily variability [6] stresses the importance of addressingquality attribute variability at the architectural level.

In this paper, we describe KumbangSec, which is an ap-proach for modelling functional and security variability insoftware architectures. KumbangSec is built on the con-cepts of product configuration, software architectures, fea-ture modelling, and security engineering. To address func-tional and security concerns, KumbangSec has been or-ganised into four architectural viewpoints [15]: functionalview, component view, deployment view and security pol-icy view.

KumbangSec approach consists of a conceptualisation

and a language. The language has been unambiguouslyspecified in such a way that KumbangSec models can beconfigured with a configurator. A configurator is an intelli-gent tool that enables derivation of products satisfying spec-ified functional and security requirements; such a configu-rator tool is currently being developed.

The rest of the paper is organised as follows. Firstly,Section 2 outlines the background for KumbangSec. There-after, Section 3 introduces KumbangSec. Section 4 dis-cusses the validity of KumbangSec. Finally, Section 5draws conclusions and discusses future work.

2 Previous work

This section discusses the research on which Kum-bangSec is based.

2.1 Quality attributes in software archi-tectures

According to [15], software architecture is the funda-mental organisation of a system embodied in its compo-nents, their relationships to each other, and to the environ-ment, and the principles guiding its design and evolution.

State of the practice is to model and document softwarearchitectures using different viewpoints and views as de-scribed in IEEE Standard [15]. A view is a representationof a whole system from the perspective of a related set ofconcerns. Example viewpoints include module view thatdescribes the decomposition of code units, and deploymentview that describes how software is allocated to physicaldevices. Typically, certain viewpoints are used to answerconcerns related to certain quality attributes; e.g. processview is often used when addressing performance concerns.

The goal of KumbangSec is to enable tool-supportedderivation of products that satisfy varying quality attributerequirements. In order to target this goal, the approachshould include a mechanism for ensuring that quality at-tribute requirements are met. This can be done in two ways.Firstly, the approach can apply well-known quality attributesolutions, such as patterns [31] or tactics [4]. Secondly, theapproach can evaluate quality attributes from the architec-tural models.

When applications are built by reusing existing compo-nents, as is the case with configurable component-basedproducts, the task of evaluating quality attributes from thearchitectural models can utilise information about the char-acteristics of components. The problem of predictable as-sembly [7] is as follows: given a set of components withknow property p, and the composition of these components,how can system-wide property P be evaluated? Several ap-proaches have been presented, e.g., for static memory con-sumption [9], performance [5], and reliability [28]. How-

Figure 1. ISO/IEC 15408 security concepts[17]

ever, some quality attributes, such as security or safety,are more difficult in the sense that their prediction requiresmore information [21]. A prediction mechanism for secu-rity has also been proposed [30]. However, a problem withsecurity is that it is not trivial to come up with a quantitative,composable metric that captures security concepts well.

2.2 Software security

According to ISO/IEC 9126 [18], security is the capa-bility of the software to protect information and data sothat unauthorised persons or systems cannot read or mod-ify them and authorised persons or systems are not deniedaccess to them. That is, security is a composite of confiden-tiality, integrity and availability [3]. Confidentially meansabsence of unauthorised disclosure of information; integritymeans absence of unauthorised system alternations [3]; andavailability means readiness for correct service for autho-rised actions [3].

Figure 1 illustrates high-level security concepts ofISO/IEC 15408 [17]. Security is concerned with the pro-tection of assets from threats [17]; assets are defined to beinformation or resources to be protected with countermea-sures [17]. A threat exploits vulnerability in the software.In order to reduce vulnerabilities, countermeasures are im-posed in the software (see Figure 1).

The definition of ISO/IEC 9126 [18] makes a distinctionbetween authorised and unauthorised persons or systems;these parties are termed as principals (e.g.[29, 20]). In or-der to specify authorisation, an access policy (also calledsecurity policy) should be defined. In the security perpec-tive tactics by Rozanki and Woods [29], access policy isconstructed by first identifying assets and principals, clas-sifying them, and then mapping principal classes to asset

classes. Principals can also be software systems; in fact,some studies on security of component-based software treatcomponents as principals (e.g.[20]).

As noted in ISO/IEC 9126 [18], security also applies todata in transmission. In order to ensure that security poli-cies are not violated when components transmit informationwith each other, Herrmann [13] has proposed an approachfor analysing information flow in component-structured ar-chitectures by labeling pieces of information with accesspolicies. The idea is to prevent information from flowing tounauthorised principals.

The concepts illustrated in Figure 1 are to some extentreflected in the conceptual model of reference architecturesfor software product lines with varying security require-ments [10]. The model consists of three submodels [10].Security submodel deals with risk assessment; core con-cepts include threat, asset, vulnerability, unwanted incidentand risk. An architecture submodel incorporates architec-tural solutions, that is, countermeasures that promise to ad-dress security requirements. A decision support submodelsupports security requirements through scenarios.

2.3 Kumbang

Variability has been studied in the domain of traditionalproducts, i.e. mechanical and electrical ones. This domainof research is called product configuration, and it pertainsto modifying the general design of a product in prescribedways to produce product individuals that match the spe-cific needs of customers [35]. The results include a numberof conceptualisations [34], languages and tools. Recently,these same concepts have been applied to software products[1] [14].

Kumbang [1] is a domain ontology for modelling thevariability in software product families. It includes con-cepts for modelling variability both from an architecturaland feature point of view. From architectural point of view,Kumbang builds on Koala [37], which is an architecture de-scription language developed and used in Philips.

More specifically, the modelling concepts include com-ponents and features with compositional structure, at-tributes, the interfaces of components and connections be-tween these, and constraints. Hence, Kumbang enablesmodelling variability in parallel from an architectural andfeature point of view as well as describing how features areimplemented by the architectural elements.

The semantics of Kumbang is rigorously described usingnatural language and a UML profile. A language based onthe Kumbang ontology likewise called Kumbang has beendefined. Kumbang has been provided with formal seman-tics by defining and implementing a translation from Kum-bang to WCRL (Weight Constraint Rule Language) [32],a general-purpose knowledge representation language with

formal semantics.Kumbang addresses only functional aspects of config-

urable software products. This means that using Kumbang,it is possible to derive configurations in which the com-ponent architecture satisfies functional requirements, whichare specified through features. It is possible to model qual-ity attribute variability with features [14]. However, Kum-bang does not provide explicit constructs for modellingquality attributes, which makes it more difficult to addressquality attribute variability.

3 KumbangSec

In this section, we describe KumbangSec that builds onthe concepts outlined in Section 2. KumbangSec is an ap-proach that includes a conceptualisation and a language formodelling component-based products that satisfy varyingfunctional and security requirements. The ultimate goal ofKumbangSec is to provide intelligent tool support for deriv-ing these products from family models. Firstly, Section 3.1gives an overview of the approach. Thereafter, Section 3.2describes the conceptualisation KumbangSec is based on,and how this conceptualisation makes a distinction betweeninstances and types. Finally, Section 3.3 describes the lan-guage that implements the conceptualisation.

3.1 Overview of KumbangSec approach

3.1.1 Basic ideas

KumbangSec is an approach for modelling component-based architectures from functional, compositional and se-curity point of view. KumbangSec builds on Kumbang lan-guage [1] by extending it with concepts from security engi-neering.

KumbangSec is organised to reflect the idea of separatearchitectural viewpoints discussed in IEEE 1471-2000 stan-dard [15]. The viewpoints in KumbangSec are feature view-point, component viewpoint, deployment viewpoint, and se-curity policy viewpoint. Features mean user visible char-acteristics of a system. Components refer to the reusedsoftware entities that are connected to form an application.Deployment shows the software components operating onphysical devices and networks; this information is neededin order to analyse security threats. Security policy speci-fies the threats and applied countermeasures; countermea-sures are realised within the component architecture. Theviewpoints can be linked with constraints in such a way thata change in one viewpoint is reflected to other viewpointsas well.

The foundation of Kumbang, and therefore also of Kum-bangSec, lies on the dichotomy between types and in-stances, and between a configuration model and configu-ration, respectively. The situation is illustrated in Figure 2.

Figure 2. Metamodel of KumbangSec config-uration models, configurations, types and in-stances.

A configuration describes one particular software productvariant, while a configuration model describes the rules andthe structure upon which valid configurations can be con-structed. A configuration contains instances of types de-fined in the configuration model. Types in the configurationmodel contain variability, while instances in the configu-ration do not; a configuration has been resolved from allvariability. This dichotomy is similar to development forreuse and development with reuse; domain and applicationengineering in family based development; and types and in-stances in object oriented programming.

A corollary of this position is that we need to capture aconfiguration model only, since a configuration can be de-rived from the configuration model by selecting one variantfor each variation point. Therefore, KumbangSec providesa language that can be used for describing configurationmodels. An essential aspect of this language is that it canbe translated to a form that enables tool support for derivingconfigurations from configuration models.

3.1.2 Security in KumbangSec

In order to address security, KumbangSec conceptualisesassets, principals, threats and countermeasures.

In component-based systems and component models, in-formation is not usually explicitly modelled, but is encap-sulated in the components and their connections. In orderto support explicit reasoning about security, KumbangSeccontains concepts for modelling assets. An asset in Kum-bangSec is information that needs to be protected. However,only information that is relevant to security reasoning needsto be modelled. Since the number of different assets can beconsiderable, it is possible to classify assets that have simi-lar security requirements into groups; such a group is calledan asset class.

Instead of considering stakeholders as principals, Kum-bangSec adopts the approach by Khan and Han [20] to treatsoftware components as principals. However, componentsrepresent different stakeholders through their origin or rolein the system. In a similar fashion to assets, principals canbe classified into principal classes.

Typically, threats and countermeasures that are relevantto an application are very much dependant on the domainat hand. As a consequence, it is difficult to come up witha fixed set of threats and countermeasures that are suitableto all applications. Therefore, threats and countermeasurescan be specified in the configuration model to match secu-rity requirements at hand.

Threats and countermeasures are specified in a securitypolicy. One threat can be addressed by several countermea-sures. A countermeasure represents a constraint that is im-plemented by the component and deployment architecture.In order to achieve finer granularity, one countermeasurecan be selected individually for different elements; for ex-ample, it is possible to specify for each network which kindof encryption to use.

To exemplify how threats and countermeasures can berepresented, we have modelled three threats to confiden-tiality and integrity, and corresponding countermeasures tothem. Firstly, information should not flow to unautho-rised components; this threat is addressed by preventingsuch connections between components. Secondly, mali-cious components may try to access or modify informationin the memory; this can be prevented by instantiating com-ponents into separate, restricted processes. Thirdly, con-nections that transmit assets over networks are vulnerableto eavesdropping; this can be addressed by encrypting suchconnections.

3.1.3 Variability in KumbangSec

As is illustrated in Figure 2, configuration models describethe types from which instances in configurations are instan-tiated. Therefore, configuration models specify variability,whereas all variability has been bound in configurations.

There are four kinds of variability in KumbangSec.Firstly, functional variability is specified through fea-

tures. This variability is achieved through subfeature struc-tures, in which the number and types of subfeatures canvary. Further variability can be achieved through attributes.

Secondly, security variability is specified through secu-rity policy. Threats cannot be varied, but for each threat, thedesired countermeasures (if any) can be varied.

Thirdly, architectural variability is specified throughcomponent and interface structures. For each component,the number and types of contained components can vary.Further, interfaces can be optional, and interfaces can bebound in different ways. Finally, variability can be achievedby characterising components with attributes.

Finally, it is possible to vary deployment by varying thenumber and types of devices that are deployed to networks.

For further discussion about variability in types, pleaserefer to Section 3.2.2.

Figure 3. KumbangSec instance metamodel

3.2 KumbangSec conceptualisation

The following describes the conceptualisation uponwhich KumbangSec is based. We first describe the con-cepts that are reflected in the configuration, that is, Kum-bangSec instances. Thereafter, we discuss how Kum-bangSec types are used to characterise instances in the con-figuration model.

3.2.1 KumbangSec instances

A configuration in KumbangSec consists of instances thatare features, components, interfaces, bindings, assets, net-works, devices, threats, and countermeasures. Figure 3shows the metamodel of these instances. A configurationprovides a set of features, and adheres to a security policy.Components provide or require interfaces that can be boundtogether, and can form structures in terms of other compo-nents as parts. Components are deployed to devices, whichreside on networks. Components handle and store assetsand transfer them through interfaces.

Feature instances The basic representation of a func-tional requirement in KumbangSec configuration is a fea-ture. Since the number of features in a typical applicationcan be considerable, features can be composed into hierar-chies. Thus there can be is-subfeature-of relation betweentwo features in a configuration. Feature hierarchies form a

Figure 4. An example how components aredeployed to devices and networks

tree; a configuration contains exactly one root feature. Fur-ther, features can be characterised with attributes: a featurecan be attached with an attribute that is a name/value pair.

Component and interface instances The basic buildingblock of KumbangSec component architecture is a compo-nent. The components in KumbangSec configuration areconceptually much akin to Koala components. However,any component technology with similar concepts can beused for implementing KumbangSec components.

A component can specify a number of interfaces, whichare sets of operation specifications. The interfaces that acomponent specifies have a direction, i.e., interfaces are ei-ther provided or required. A provided interface offers itsoperations for other components to use, while a required in-terface states that the component needs other components toprovide the operations. Interfaces can be bound with eachother according to the rules specified in [37].

Components can be organised into hierarchies. A com-ponent can contain other components; thus components arein a compositional relation with each other, and this hierar-chy forms a tree. Also, components may be characterisedwith attributes. An attribute is a name/value pair that can beused, e.g., for parameterisation of the component.

Device and network instances Software components inthe configuration may be deployed to separate physical de-vices; these devices are deployed in a network. Figure 4illustrates an example situation of deployment. A net-work can contain several different devices, but devices can-not contain other devices. Networks can form hierarchiesthrough subnets similarly as, e.g., corporate intranet is a partor subnet of Internet.

A configuration that has more than one device is dis-tributed. A binding that crosses device borders is a dis-tributed binding, which represents communication over net-work.

Asset, threat and countermeasure instances Assets areattached to components in three different ways. Firstly, acomponent may handle an asset, which means it stores it inrandom access memory. Secondly, a component may alsostore the asset in a permanent storage, for example to a fileon the disk. Thirdly, a component may transmit an asset toanother component via its interfaces.

Security policy specifies how threats are addressed withcountermeasures. Each configuration has one security pol-icy, which lists a number of threats. For each threat, a num-ber of countermeasures can be selected to address the threat.In the most simple case, a countermeasure selection is eitherapplied or not applied; in the former case, the countermea-sure is enforced in the architecture, while in the latter casenot. In general, a countermeasure can be characterised witha selection, which acts as a parameter for implementing thecountermeasure in the architecture. For example, a counter-measure that encrypts communication may be attached witha selection SSL 2.0, RSA 128 bit encryption, which specifiesthe encryption protocol to use.

3.2.2 KumbangSec types

As is illustrated in Figure 2, types are the elements in theconfiguration models, from which instances in the configu-rations are instantiated.

Figure 5 illustrates the metamodel of KumbangSectypes. All instances in Figure 3 have a respective type,and vice versa. However, there are two exceptions to thisrule. Firstly, binding instances are defined solely upon theirconnected interface instances, and thus they need no infor-mation from the types. Secondly, principal classes and as-set classes do not have respective instances, since they arealready instantiated by component instances and asset in-stances, respectively.

A distinctive difference to the metamodel of instances(Figure 3) is the use of definitions. A definition separatestyping from the structure, and acts as a point of variabil-ity. For example, a part definition specified by a componenttype C states what kind of components a component instan-tiated from C can contain. As an example, a part definitionnamed database in component type Server may specify thatpossible component types are Oracle and mySQL and thatcardinality is (0, 1). This means that a component instanceof type Server may contain zero or one Oracle or mySQLcomponent instances. Similar compositional structures canbe defined between features, or between networks and de-vices or devices and components.

Another example is the use of attribute definitions. At-tribute value types specify the value range of attributes; forexample, attribute value type Boolean may specify valuerange (yes, no). Attribute value types are attached to fea-ture and component types through attribute definitions; for

Figure 5. KumbangSec type metamodel

example, feature type Map may define an attribute defini-tion zoomable of type Boolean.

To summarise, variability may occur in the composi-tional structure of networks, features, and components; inattributes; and in what interfaces components contain andwhich bindings between interfaces exist. The variability incompositional structures is specified using part definitions:the number and type of parts an entity has may vary. Fea-tures and components can be parameterised using attributes.Similarly, interfaces may be defined optional and be of dif-ferent types. Finally, security policies can vary how coun-termeasures are applied.

3.3 KumbangSec language

In order to use KumbangSec concepts for modellingproduct families, a language that captures the conceptual-isation described in Section 3.2 has been developed. Thelanguage has been constructed in such a way that it enablesdevelopment of tool support. Since KumbangSec configu-rations are derived from KumbangSec configuration mod-els (Figure 2), only a language for specifying configurationmodels is required. The language represents KumbangSectypes (see metamodel in Figure 5).

KumbangSec language is specified using XML. Kum-bangSec grammar has been described as an XML schema,whereas the configuration models are XML instance docu-ments from the schema. XML was chosen due to its wide-spread use; for example, a number of parsers and editors areavailable for XML.

The XML schema that represents KumbangSec gram-mar has been specified. Each definition and each type inKumbangSec type metamodel (Figure 5) has its own XMLschema data type in the grammar.

For example, the XML schema definition for Compo-nentType is illustrated in Figure 6(a). This snippet statesthat each component type has a name, a principal class, de-fines any number of interfaces, any number of componentparts, any number of attributes and any number of assets.Finally, a component type can specify constraints on its el-ements.

An example of the corresponding component type spec-ification is shown in Figure 6(b). It specifies a componenttype named ServerMain that belongs to principal class In-House. Further, the component type contains two inter-faces, named TransmitInterface and StorageInterface, andspecifies that is handles an asset nodeLocation belongingto asset class Location. A component instance instantiatedfrom type ServerMain is visualised in the lower part of Fig-ure 7.

In order to give formal semantics to KumbangSec, Kum-bangSec has been provided with a translation to WCRL(Weight Constraint Rule Language) [32]. WCRL is a form

of logic programming, using which one can specify a setof atoms, statements concerning atoms and rules that ex-tend these statements [32]. Further, this translation makes itpossible to utilise smodels [32] inference engine to automat-ically verify whether the configuration matches the rules ofthe configuration model.

The translation to WCRL utilises the fact a translationfrom Kumbang to WCRL has already been defined [1].Therefore, KumbangSec is provided with the translation byfirst translating KumbangSec to Kumbang, and then usingthe existing translation to WCRL. The translation betweenKumbangSec and Kumbang treats assets, devices and net-works as special kind of components, and policies as specialkind of features.

Figure 6(c) illustrates part of the WCRL that has beentranslated from the component specification in Figure 6(b).The first line specifies that component of type ServerMainis an InHouse component. The second and the third linespecify the two interfaces this component has. The fourthline specifies that this component defines an asset namednodeLocation.

4 Evaluation

In this section, the validity of KumbangSec is evalu-ated from the following viewpoints. How well does Kum-bangSec address the problem; are the conceptualisation andlanguage sound; and can KumbangSec be applied in prac-tice, integrated with component implementation technolo-gies and supported with tools?

Addressing the problem. The aim of KumbangSec is tostudy how security variability and functional variability canbe modelled from architecture point of view. To target thisaim, several existing approaches are integrated into one.The novelty of KumbangSec is combining existing con-cepts to model variability, while the concepts themselvesare based on existing studies. Therefore, the soundness ofKumbangSec concepts can be argued from these existingstudies.

For functional and architectural variability, KumbangSecis based on Kumbang, which in turn is based on fea-ture modelling, Koala, and traditional product configurationconcepts. For security variability, KumbangSec extendsKumbang with established security concepts that underliemany studies, including ISO/IEC standard 15408 [17] andsecurity model presented in [10].

However, it is yet unknown how well this combination ofconcepts addresses the problem. For example, it is unknownwhether explicit concepts for risks or vulnerabilities shouldbe included, or how well the conceptualisation supports def-inition of different kinds of threats and countermeasures.

Figure 6. Example translations from a weather station network configuration model. (a) A snippetfrom the XML schema that defines how component types are specified. (b) An example componenttype specification in a configuration model. (c) Few lines of the WCRL that is produced from thecomponent type specification.

Figure 7. A screenshot of KumbangSec configurator under development (some inconsistencies withcurrent conceptualisation may occur)

Soundness of conceptualisation and language. To ad-dress the problem of modelling functional and security vari-ability, KumbangSec conceptualisation has been defined.The concepts and their relations have been specified usingnatural language and metamodels. Further, the separationbetween instances and types has been specified.

To implement the conceptualisation, KumbangSec lan-guage has been defined. The semantics of KumbangSeclanguage follows the semantics of KumbangSec conceptu-alisation. The syntax of the language has been described us-ing an XML schema, which validates that the language canbe captured with a grammar. Moreover, using the grammar,it has been possible to parse XML instance documents thatrepresent KumbangSec configuration models.

Further, KumbangSec has been given a semantics byproviding a translation to WCRL. This validates that the ap-proach can be subjected to automated reasoning.

Practical feasibility. KumbangSec has been used tomodel two small configurable products. Firstly, we havemodelled a weather station network that is loosely based ona real software product family. Secondly, we are currentlymodelling a map viewer application for Nokia 770 Inter-net Tablet. This application is currently being developed todemonstrate the approach.

Hence, it has been shown that it is possible to modelproducts using KumbangSec. However, the limitation tothis validity is that no industrial products have been mod-elled. Further, there is no general knowledge on how easilyKumbangSec constructs can be used for capturing productcharacteristics. Further studies on KumbangSec applicabil-ity are therefore required.

Integration with component implementation technol-ogy. The scope of KumbangSec is high-level variabilitymodelling. That is, KumbangSec is not limited to any par-ticular component implementation technology, but it can beintegrated with any approach that is compatible with theconceptualisation, and is able to enforce the specified coun-termeasures.

At the moment, we are integrating KumbangSec witha component technology developed within the researchproject.

Tool support. Finally, the validity of the approach canbe demonstrated by building a configurator tool to supportderivation of products based on KumbangSec configurationmodels. We are currently developing KumbangSec configu-rator by extending previously developed Kumbang configu-rator [23]. The configurator utilises smodels [32] inferenceengine for implementing the configuration reasoning in anefficient manner. Further, it is being developed in Java pro-gramming language on top of Eclipse platform [8].

A preliminary screenshot of KumbangSec configurator isillustrated in Figure 7. The current results seem to indicatethe feasibility of constructing such a configurator.

5 Conclusions

We have presented KumbangSec, which is an approachfor modelling functional and security variability in softwarearchitectures. To address functional and security concerns,KumbangSec has been organised into functional view, com-ponent view, deployment view and security policy view.KumbangSec approach consists of a conceptualisation anda language. They have been constructed in such a way thatthey can be supported with a configurator, which is an in-telligent tool that enables derivation of products satisfyingspecified functional and security requirements.

However, the work is still in progress. We are workingon developing a configurator tool that supports derivationby extending existing Kumbang configurator. Further, weare validating the approach by modelling product familiesor configurable products with KumbangSec language.

There are several directions to which this approach canbe extended.

Firstly, KumbangSec assets are considered to be infor-mation. However, it is possible that also resources or oper-ations could be treated as assets that need protection. Weseek to extend the concept of asset to cover also these, e.g.,by classifying interfaces in components according to assetclasses.

Secondly, more threats and countermeasures should bemodelled to study how the conceptualisation can be used tocapture different kinds of security characteristics.

Finally, different aspects of quality may require differ-ent concepts and viewpoints. It has proven to be laborousto extend existing languages with new concepts in such away that existing tools can be reused efficiently. There-fore, we are currently working on a meta-language, usingwhich concrete languages can be specified; correspondingconfigurator tool implementation can be generated from thespecification.

Acknowlegments

This research is being carried out in participation ofNokia within Trust4All ITEA project. The authors ac-knowledge Nokia and all other participants of Trust4Allproject who have provided feedback and comments on thiswork.

References

[1] T. Asikainen, T. Mannisto, and T. Soininen. Kumbang: Adomain ontology for modelling variability in software prod-

uct families. Advanced engineering informatics journal, Ac-cepted, 2007.

[2] T. Asikainen, T. Soininen, and T. Mannisto. A Koala-basedapproach for modelling and deploying configurable softwareproduct families. In Proc. of Workshop on Product FamilyEngineering, 2003.

[3] A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr. Ba-sic concepts and taxonomy of dependable and secure com-puting. IEEE Transactions on Dependable and Secure Com-puting, 1(1), 2004.

[4] L. Bass, P. Clements, and R. Kazman. Software Architecturein Practice. Addison-Wesley, 2nd edition, 2003.

[5] E. Bondarev, M. R. V. Chaudron, and P. H. N. de With. Aprocess for resolving performance trade-offs in component-based architectures. In Proceedings of International Sympo-sium on Component-Based Software Engineering, 2006.

[6] P. Clements and L. Northrop. Software Product Lines—Practices and Patterns. Addison-Wesley, 2001.

[7] I. Crnkovic, H. Schmidt, J. Stafford, and K. Wallnau.Anatomy of a reseach project in predictable assembly. InProc. of 5th Workshop on Component-Based Software Engi-neering, 2002.

[8] Eclipse, http://www.eclipse.org/.[9] E. Eskenazi, A. Fioukov, D. Hammer, and M. Chaudron.

Estimation of static memory consumption for systems builtfrom source code components. In Proceedings of the9th IEEE Conference and Workshops on Engineering ofComputer-Based Systems, 2002.

[10] T. E. Fægri and S. Hallsteinsen. A software product linereference architecture for security. In T. Kakola and J. C.Duenas, editors, Software Product Lines—Research Issuesin Engineering and Management. Springer, 2006.

[11] H. Gomaa. Designing Software Product Lines with UML:From Use Cases to Pattern-Based Software Architectures.Addison-Wesley, 2004.

[12] S. Hallsteinsen, T. E. Fægri, and M. Syrstad. Patterns inproduct family architecture design. In Proc. of Workshop onProduct Family Engineering, 2003.

[13] P. Herrmann. Information flow analysis of component-structured applications. In Proceedings 17th Annual Com-puter Security Applications Conference (ACSAC 2001),2001.

[14] L. Hotz, K. Wolter, T. Krebs, J. Nijhuis, S. Deelstra, M. Sin-nema, and J. MacGregor. Configuration in Industrial Prod-uct Families—The ConIPF Methodology. IOS Press, 2006.

[15] IEEE Std 1471-2000. IEEE recommended practice for ar-chitectural description of software-intensive systems, 2000.

[16] IEEE Std 610.12-1990. IEEE standard glossary of softwareengineering terminology, 1990.

[17] ISO/IEC 15408-1. Information technology—securitytechniques—evaluation criteria for IT security—part 1: In-troduction and general model, 1999.

[18] ISO/IEC 9126-1. Software engineering—product quality—part 1: Quality model, 2001.

[19] K. Kang, S. Cohen, J. Hess, W. Novak, and A. Peterson.Feature-oriented domain analysis (FODA) feasibility study.Technical Report CMU/SEI-90-TR-21, ADA 235785, Soft-ware Engineering Institute, 1990.

[20] K. Khan and J. Han. Composing security-aware software.IEEE Software, 19(1):34–41, 2002.

[21] M. Larsson. Predicting Quality Attributes in Component-based Software Systems. PhD thesis, Malardalen University,2004.

[22] M. Matinlassi. Quality-driven software architecture modeltransformation. In Proc. of Working IEEE/IFIP Conferenceon Software Architecture, 2005.

[23] V. Myllarniemi, T. Asikainen, T. Mannisto, and T. Soini-nen. Kumbang configurator—a configuration tool for soft-ware product families. In IJCAI-05 Workshop on Configu-ration, 2005.

[24] V. Myllarniemi, T. Mannisto, and M. Raatikainen. Qualityattribute variability within a software product family archi-tecture. In Short paper in Conference on the Quality of Soft-ware Architectures (QoSA), 2006.

[25] V. Myllarniemi, M. Raatikainen, and T. Mannisto. Inter-organisational approach in rapid software product familydevelopment—a case study. In Proc. of International Con-ference on Software Reuse (ICSR), 2006.

[26] V. Olumofin, F.G.; Misic. Extending the ATAM architectureevaluation to product line architectures. In Proc. of WorkingIEEE/IFIP Conference on Software Architecture, 2005.

[27] K. Pohl, G. Bockle, and F. van der Linden. Software ProductLine Engineering. Springer, 2005.

[28] R. Reussner, H. Schmidt, and I. Poernomo. Reliability pre-diction for component-based software architectures. Journalof Systems and Software, 66(3), 2003.

[29] N. Rozanski and E. Woods. Software Systems Architecture.Addison-Wesley, 2005.

[30] V. S. Sharma and K. S. Trivedi. Architecture based analysisof performance, reliability and security of software systems.In Proceedings of the 5th International Workshop on Soft-ware and Performance, 2005.

[31] M. Shaw and D. Garlan. Software Architecture–Perspectiveson an Emerging Discipline, chapter 2. Prentice Hall, 1996.

[32] P. Simons, I. Niemela, and T. Soininen. Extending and im-plementing the stable model semantics. Artificial Intelli-gence, 138(1–2), 2002.

[33] M. Sinnema, S. Deelstra, J. Nijhuis, and J. Bosch. COV-AMOF: A framework for modeling variability in softwareproduct families. In Proc. of Software Product Line Confer-ence (SPLC 2004), 2004.

[34] T. Soininen, J. Tiihonen, T. Mannisto, and R. Sulonen. To-wards a general ontology of configuration. AI EDAM (Artifi-cial Intelligence for Engineering Design, Analysis and Man-ufacturing), 12(4):357–372, 1998.

[35] T. Soininen, J. Tiihonen, T. Mannisto, and R. Sulonen. Spe-cial issue: Configuration (guest editorial introduction. AIEDAM (Artificial Intelligence for Engineering Design, Anal-ysis and Manufacturing), 17(1–2), 2002.

[36] M. Svahnberg, J. van Gurp, and J. Bosch. A taxononomy ofvariability realization techniques. Software—Practice andExperience, 35(8), 2005.

[37] R. van Ommering, F. van der Linden, J. Kramer, andJ. Magee. The Koala component model for consumer elec-tronics software. IEEE Computer, 33(3):78–85, 2000.