Model Driven Implementation of Security Management Process

Bruno A. Mozzaquatro

, Ricardo Jardim-Goncalves

and Carlos Agostinho

DEE/FCT, Universidade Nova de Lisboa (UNL), 2829-516 Caparica, Portugal

Centre of Technology and Systems, UNINOVA, 2829-516 Caparica, Portugal

Keywords:

Business Process, MDA, Security Management, Model Transformations, MDSEA.

Abstract:

Services composition involves many time and effort to describe high-level requirements of the business pro-

cess. To this purpose, the Model Driven Service Engineering Architecture (MDSEA) is a methodology to

distinguish the business view and technical point of view in products and services and to agilize the software

development. Such capabilities demand more effective process applied to specify, evaluate, communicate and

design the system as well as system functionalities and security issues. Security aspects are critical when it

involves privacy of data exchange of devices. In this context, the deﬁnition of security artifacts during the

design of a business process consumes time of system funcionalities development. This paper proposes an im-

plementation of a security management process using the methodology MDSEA as support to promote model

transformations from business model to speciﬁc artifacts and conﬁgurations. This support enables to enrich a

solid business model with technical details by specialists.

1 INTRODUCTION

Collaboration among enterprises has become a better

solution towards market opportunities. Its products

and related services result in cooperative networks to

support service life cycle. Services composition re-

quires a lot of time and effort to describe and de-

sign more accurately business details (Bazoun et al.,

2013). However, at high-level requirements of busi-

ness process involves stakeholders to specify, evalu-

ate, communicate and design the system supporting

the service and its lifecycle around enterprise proces-

ses.

Process modeling notations is an appropriately

implementation to separate business details from

technical details of a service system. Usually, busi-

ness details are focused to domain experts to identify

requirements around services and technical details

consist of speciﬁc information about implementation

of this service system (M

unch et al., 2012). Model

Driven Service Engineering Architecture (MDSEA)

is a methodology responsible for supportting service

model transformations from high-level concepts to

speciﬁc artifacts in the process. This methodology

promotes models reuse at different abstraction levels

deﬁning some ways to transform concepts in imple-

mentation (Bazoun et al., 2016).

According to a service system some concerns

about secure issues are needed to take in considera-

tion and to make the proper functioning of the system.

Usually, these details are despised during a business

process model elaboration because it requires secu-

rity professionals within system development teams

(Lambert et al., 2006). Model driven security and ge-

neration of security software artifacts has been a to-

pic of research in recent years (Derdour et al., 2015)

(Brucker et al., 2012) (J

urjens, 2002) (Lodderstedt

et al., 2002).

Model driven security has focused on impro-

ving security quality with separation of functional is-

sues from non-functional aspects of the whole sy-

stem. Usually, well-known languages are used to

achieve security process integration as well as Archi-

tecture Description Languages (ADLs) and Uniﬁed

Modeling Language (UML) (Ren and Taylor, 2005).

Security processes involve security analysis and veri-

ﬁcation of security properties (e.g. availability, conﬁ-

dentiality, integrity) while system requirements at the

design time and runtime (Mozzaquatro et al., 2016).

This paper demonstrates how model transformation

between different abstraction levels of process mo-

dels address the gap between business and technical

security conﬁgurations. It is based on a modeling lan-

guage to facilitate the development of business pro-

cesses using a services composition to enterprises.

Mozzaquatro B., Jardim-GonÃ

galves R. and Agostinho C.

Model Driven Implementation of Security Management Process.

DOI: 10.5220/0006329602290238

In Proceedings of the 5th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2017), pages 229-238

ISBN: 978-989-758-210-3

229

Figure 1: Baseline scenario model.

1.1 Baseline Scenario

This section describes a baseline scenario of a ma-

nufacturing scenario of the H2020 European Pro-

ject: Cloud Collaborative Manufacturing Networks

(C2NET) project, which reﬂects the data collection

from sensors networks. Figure 1 presents a business

process of baseline scenario addressed in this paper.

It is a high-level abstraction model deﬁned by a busi-

ness managers team without technological details.

The process’ workﬂow starts with an activity re-

sponsible to collect device’s information to the data

collection scenario. Start Data Collection activity in-

teracts with the Pilot Manager to provide a set of devi-

ces that it will compose the sensor network. It is for-

warded to the activity called Virtualize Resources to

Collection Framework (DCF). Each real device will

have a virtual copy in the platform. Next step, the

IT resource (Hub) provides support to data collection

through the Read Data activity. It collects data from

sensors devices and send to the DCF. The Process

Data activity, localized in DCF, ﬁlters data collected

and process according to the needs of the project to

be stored (Data Store activity).

Security activities are not highlighted in this high-

level perspective of the process, but it is intrisic and

should be considered at lower levels following a secu-

rity process by services, archifacts and implementati-

ons. For example, activities in the continuous line re-

quire security concerns about authentication and con-

ﬁdentiality. Dotted line’s activities need the security

requirement of integrity and conﬁdentiality, which de-

ﬁnes ways to protect data collection of sensors net-

work over the public network. In the whole workﬂow,

availability is another requirement essential to ensure

reliability and to maintain the right functioning of the

system.

1.2 Paper Outline

The rest of paper is organized as follow: Section 2

presents the background research of this paper fol-

lowing by related works (Section 2.1), Model Dri-

ven Service Engineering Architecture (Section 2.2),

and a modeling tool called SLMToolBox in Section

2.3. Section 3 describe a detailed security process

through a model tranformation from a business mo-

del. Section 4 describes a methodology of this paper

and his contribution of models transformations based

on MDSEA. Some tests are presented in Section 5.

Finally, conclusions and future works is presented in

Section 6.

2 BACKGROUND RESEARCH

This section describes main subjects involved in this

paper to understand the security process based on the

transformation different abstraction levels of models.

2.1 Literature Review

This section describes some related works regarding

model transformations and model driven representa-

tion of security process. These two categories are out-

lined in this section.

2.1.1 Model Transformations

The authors (De Castro et al., 2011) propose a model

driven approach that apply CIM-to-PIM model trans-

formation from high-level business models to lower-

level information system models. The key advantage

is to use real high-level business models into the pro-

cess using an MDA-based approach that offers mo-

dels of different abstraction levels and model transfor-

mations. The results demonstrate how a model driven

approach helps the alignment process between diffe-

rent views when adoption service oriented approach

for software development.

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

230

The author (Chen, 2015) presents a methodologi-

cal approach for the generation of manufacturing ser-

vice involving steps of a service life cycle. It con-

siders that there is no complete service engineering

methodological approach in the market. However,

the methodology proposed in this paper considers a

bag of assets with i) service modeling based on MD-

SEA, adapted and extended from MDA/MDI appro-

aches; ii) service engineering process to ensure the

customer’s needs within an entire life cycle (Bahill

and Gissing, 1998); iii) service governance frame-

work to control enterprises within a manufacturing

service ecosystem and your respectives interactions

with data and information; iv) service live life cycle

framework to capture, categorize, and structure a set

concepts and issues relating to manufacturing serviti-

zation; and v) SLMToolBox consists several graphi-

cal editors to model manufacturing services and ser-

vice systems from business and functional models.

The fourteen steps deﬁned in the methodology is

considered as reference guidelines to select and cus-

tomize according to needs. Though some limitations

are highlighted by authors as well as the time to le-

arn several models and tools contained in the metho-

dology, not all models are supported by tools, and the

application of this methodological approach would be

more suitable to large companies even though it has

been experimented with success in SME.

2.1.2 Model Driven Security Process

The adoption of model driven security in business

processes is an emerging research area. Some

works explore the model driven approach for process-

oriented systems focusing on access control such as

SecureUML (Basin et al., 2003), UMLSec extension

for UML (J

urjens, 2002).

The authors (Menzel et al., 2009) propose an ap-

proach to describe security requirements at the busi-

ness process layer and their translation to concrete se-

curity conﬁguration for service-based systems. Such

security requirements involve some intentions such as

conﬁdentiality or integrity on an abstract level. In-

formation at the modeling layer is transformed to a

domain-independent security model following the ge-

neration of security conﬁgurations based on the mo-

deled requirements with a pattern and its relationship

to the security model. This pattern is composed of

problem, context, forces and solution. Each pattern

refers to a particular security goal and identiﬁes suit-

able security protocol/mechanism.

Wolter (Wolter et al., 2009) describes a generic

security model that speciﬁes security goals, policies,

and constraints based on a set of basic entities, such

as objects, attributes, interactions, and effects. This

model has an abstraction from technical details and

hence they provide a mapping from this abstract mo-

del to platform speciﬁc target languages (e.g. XA-

CML or AXIS2) with authorisation and conﬁdentia-

lity constraints deﬁned.

2.2 Model Driven Service Engineering

Architecture

The Model Driven Service Engineering Architecture

(MDSEA) is an approach to distinguish the business

and technical point of view in product and service sy-

stems. This architecture follows Model Driven Ar-

chitecture (MDA) paradigm to provide guidelines for

structuring the speciﬁcations of engineering activities.

On the basis of MDA paradigm, MDSEA proposes a

framework for service system modeling using three

levels: BSM, TIM and TSM (Bazoun et al., 2013).

• Business Service Model (BSM): this level speci-

ﬁes models at high-level and reﬂects the business

perspective of the service system, without consi-

derations between technologies that will be used.

It is the link between domain experts and develop-

ment experts.

• Technology Independent Model (TIM): this level

delivers detailed speciﬁcations of the structure of

the service system, which focuses on the functio-

nal and operational details used for implementa-

tion.

• Technology Speciﬁc Model (TSM): this level pre-

sents procedures to the implementation of the sy-

stem to use a particular type of technology, in-

cluding middleware, operating systems, and pro-

gramming languages. According to these speciﬁ-

cations, the next step consists of the implementa-

tion of the designed service system.

Model-Driven Engineering (MDE) is a practice

for developing model driven applications through the

use of models, allowing concepts closer to the domain

of problems. It involves a software engineering ap-

proach to address system complexity related with Mo-

del Drive Development (MDD) to describe and build

software systems (Atkinson and Kuhne, 2003).

The main aspect to avoid some problems of the

difﬁcult task of developing effective and efﬁcient soft-

ware is automating developments in an information

system life cycle. It suggests the description of a sy-

stem in an abstract way performing transformations in

several steps into real, executable systems (e.g. source

code) (Selic, 2003).

The utilization of models has several meanings,

among which can be cited: i) set of extracts of a sy-

stem under study (Seidewitz, 2003), ii) simpliﬁcation

Model Driven Implementation of Security Management Process

231

of reality (Selic, 2003), and set of formal elements

which describe something that is being developed for

a speciﬁc purpose and can be analyzed by methods

(Mellor et al., 2003). Historically, models have been

used to ensure the efﬁcacy of systems before the su-

perior effort about all system directly. It could be said

that MDE vision develops a principle that “everything

is a model” (i.e., platforms, components, legacy soft-

ware, services, etc.) (Agostinho et al., 2012) (B

ezivin,

2006). These models represent the results a fast deve-

lopment of products and systems based on the com-

munication among product managers, designers, and

member of the development team.

Usually, MDE consists of the model transformati-

ons between layers as depicted in Figure 2. The fol-

lowing sections describe the modeling environment,

called SMLToolbox, to deﬁne a high-level process

and perform transformations according to the MD-

SEA.

Figure 2: Overview of MDSEA (Ducq et al., 2014).

2.3 SLMToolbox Modeling

Environment

This section describes an integrated modeling tool de-

dicated to services lifecycle management with activi-

ties as well as syntactic validation, model transforma-

tion, execution process, modeling process, engineer-

ing process, and workﬂow monitoring and control.

Service Life Management Tool Box (SLMTool-

Box) is a software developed in the frame of the EU

FP7 MSEE project

. SLMToolBox consists in some

facilities to develop a new service or improve an ex-

isting one, within a single enterprise or a virtual en-

terprise (Bazoun et al., 2014). According to Bazoun

http://www.msee-ip.eu/project-overview

(Bazoun et al., 2016), it is an implementation of the

BSM and TIM levels of MDSEA.

SLMToolBox composes several scientiﬁc con-

cepts about service innovation into one tool such as

service modeling, engineering, simulation, monito-

ring, and control (Bazoun et al., 2016). This tool

takes beneﬁts of a model based architecture (valida-

tion, transformation and execution), maintaining the

coherence of the transformation from business requi-

rements to IT implementation (modeling), simulating

the result of the service (engineering), and designing

the governance of the service (monitoring and cont-

rol) as depicted in Figure 3.

Figure 3: Service Life Management Tool Box (Bazoun

et al., 2016).

These four pillars support several goals to enable

elaboration of service descriptions, modeling activi-

ties based on a methodological support, simulation of

business processes providing animation and reports,

and implementation of service system’s governance.

The modeling architecture adopted by the SLM-

ToolBox composes three modeling levels of MDSEA:

BSM, TIM, and TSM. Each level has a set of graphi-

cal modeling languages according to the level’s vie-

wpoint. It enables non-expertise humans to organize

elements around domains of expertise by separating

and decomposing the concerns. For example, BSM

and TIM use graphical modeling languages to repre-

sent in more details certain aspects of the service mo-

del, namely as BSM Templates, Extended Actigram

Star (Bazoun et al., 2016), GRAI Grid, and UML to

BSM level; and TIM Templates, BPMN 2.0, UML,

and DEVS (Atomic and Coupled Models) to TIM le-

vel.

At BSM level, Extended Actigram Star Editor mo-

dels offer the elements of connectors which represent

cooperation between entities within the same organi-

zation or different organizations. On the other hand,

at TIM level, BPMN 2.0 provides an integrated editor

with Eclipse platform to provide an intuitive modeling

tool for the business rules, graphical edition with sup-

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

232

Figure 4: BPMN of the security process representated in SLMToolBox.

port for the BPMN domain.

SLMToolBox enables to create new diagrams

using the combination of ATL (Atlas Transformation

Language) and XSLT (eXtensible Stylesheet Lan-

guage Transformations) in two ways: create a new

BPMN diagram by the standard way, or to create a

new diagram from an existing EA*. The transforma-

tion of EA* model to BMPN model is performed by

ATL. XSLT is used to generate the graphical diagram

view of the model, resulting in a BPMN diagram.

More speciﬁc information can be obtained in re-

ferences (Bazoun et al., 2013) (Bazoun et al., 2014)

(Bazoun et al., 2016).

3 SECURITY PROCESS

In this section we describe a security process com-

posed by activities required in the business model of

a scenario of H2020 European Project: Cloud Colla-

borative Manufacturing Networks (C2NET) project.

This project designed a cloud-based system to data

collection in manufacturing enterprises. The business

model was presented to be followed in this paper in

Section 1.1.

This security process has an important role to pro-

tect security properties namely: availability, conﬁden-

tiality, integrity. The objective of this process is to en-

sure these security requirements providing activities

in the workﬂow to protect data exchange of sensors

devices.

Basically, the model presented in Figure 1 demon-

strates only information about data collection activi-

ties using C2NET platform. Some security details

and activities needs to be added to protect the system,

which involves external users and data exchange over

public network.

Following the MDSEA methodology, an advan-

tage of the model transformation between BSM to

TIM is the addition of technological details about the

process. Figure 4 presents the BPMN diagram, which

is the product of this model transformation using the

modeling tool SLMToolBox. Also, this diagram con-

tains more details of the data collection as well as Pu-

blish Conﬁgurations, which involves the registration

of conﬁgurations of resources in the C2NET platform.

In addition, some activities were added to ensure se-

curity properties such as Availability, Conﬁdentiality,

and Integrity. Availability consists of tasks to main-

tain the system operable and accessible to authorized

users. Conﬁdentiality means that information should

be available only those person authorized. Main se-

curity mechanisms to protect unauthorized access are

cryptography and access controls. Integrity means en-

sure the trustworthiness, origin, correctness of infor-

mation. It is based on integrity of information but also

to the origin integrity.

A brief overview of security services and activities

of the EU FP7 C2NET project is described in Table 1

and 2. These activities follow the workﬂow to regis-

Model Driven Implementation of Security Management Process

233

Table 1: Data collection activities of the workﬂow.

Activity Description

Virtualize Re-

sources

Sends information about resour-

ces to the Hub.

Publish Conﬁ-

gurations

Registers resource’s conﬁgurati-

ons in the cloud platform (DCF).

Read Data Collects data about resources.

Process Data Analyzes ﬁltered data about re-

sources.

Store Data Stores all information of resour-

ces in database.

Table 2: Security activities of the workﬂow.

Activity Description

User Authenti-

cation

Identiﬁes the pilot manager in

the data collection platform. e.g.

Single Sign On.

Resources Se-

curity Analy-

sis

Veriﬁes resource’s characteris-

tics and its security risks to

adopt suitable security mecha-

nisms. e.g. Security professio-

nal analysis

Runtime

Security

Monitoring

Uses security tools to monitor

resources and services. e.g. In-

trusion Detection Systems.

Security

Threat Analy-

sis

Analyzes security alerts genera-

ted by the monitoring tools. e.g.

Correlation between threats and

security solutions.

Corrective

Action

Reacts a threat and change se-

curity policies to restablish right

functioning of the sensors net-

work. e.g. Security professional

ter resources (e.g. sensors devices) and send theirs

conﬁgurations between DCF and Hub of the C2NET

platform. The model transformation of business mo-

del into the BPMN diagram is depicted in Figure 4.

BPMN model contains more details about data col-

lection and security activities, which are described in

Section 3.1 and 3.2.

3.1 Design Time Approach

Design time is an approach to establish some con-

ﬁgurations before the start of the system, at least

pre-conﬁgured deﬁnitions. Activities of Data Col-

lection (Virtualize Resources and Publish Conﬁgura-

tions) and Security (User Authentication, Resource

Security Analysis) are pre-conﬁgured tasks essential

to manage resources at the run time approach.

Virtualize Resources activity consists of receive

device’s information to be registered in the cloud-

based platform. Publish Conﬁgurations activity is re-

sponsible to the process of the dissemination of de-

vice’s information.

User authentication is an activity responsible to

lot. Once registered, authorized users are identiﬁed

and allowed to send resources information to the plat-

form. Also, it prevents unauthorized users from ma-

king improper or unauthorized modiﬁcations to re-

sources, which maintain the consistency of the sy-

stem. This activity uses authentication services with

different protocols to autenticate users such as Single-

Sign On (SSO), username/password veriﬁcation or hi-

brid (both).

Resource Security Analysis is an activity respon-

sible to verify potential solutions to detected threats in

the system. It uses a knowledge database to analyse

this information (Mozzaquatro et al., 2015).

3.2 Run Time Approach

Run time approach is responsible to perform some

tasks during the execution of the system, maintai-

ning correct functioning of the system, but also to re-

cover of an anomaly behavior. It involves tasks of

resources analysis and management within data col-

lection scope and security issues such as Data Col-

lection (Read Data, Process Data and Store Data) and

Security activities (Runtime Security Monitoring, Se-

curity Threat Analysis and Corrective Action).

In the security context, there is an activity to con-

ﬁgure security tools responsible to the resources mo-

nitoring to identify potential threats such as Runtime

Security Monitoring. Several security tools are suita-

ble to monitor in realtime resource’s behavior such as

ﬁrewall (Hossain and Raghunathan, 2010), intrusion

detection systems (Patel et al., 2016) (Butun et al.,

), proxies, etc. Usually, these tools generate security

alerts of an anomaly based on detection rules. Each

tool send security alerts to an activity responsible to

identify the reason of the detection.

This activity is Security Threat Analysis, which

consists in the identiﬁcation of reasons of each ano-

maly detection considering previous information (e.g.

knowledge base). Depending on threat’s security le-

vel, an activity of the workﬂow is responsible to re-

alize revise and recover conﬁgurations of resources

(Corrective Action). So, if there exists solutions for

detected threats, it will be corrected without stop the

system. In contrast, the system will be stopped and a

security expert will perform manual conﬁgurations to

block this threat.

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

234

4 MODEL TRANSFORMATION

BASED ON INFORMATION

SECURITY PROCESS

This section describes a methodology used to support

model transformation from a business model (high-

level) to security speciﬁcations (low-level). Figure 5

presents the methodology and its models transforma-

tions until achieve the detailed process with execution

of security services.

Initially, the business model is represented in Ex-

tended Actigram Star (EA*) in high level of ab-

straction. The diagram depicted in Figure 1 is mo-

deled within the modeling tool SLMToolBox.

Figure 5: Adopted methodology to models transformations

and execution of security services.

This part is important to specify the model at the

global level with few details of services running be-

tween differents business perspectives and indepen-

dent from technologies. The ﬁrst model transforma-

tion in Figure 5, depicted as (1), consists in the col-

lection of information and requirements at BSM level

to the TIM level. This translation aims to save effort

and reduce errors by automating models development

when possible.

The model transformation (2) between EA* and

BPMN diagrams enables to add more details about

the process’ workﬂow. It follows the Ecore metamo-

del approach to deﬁnes the structure of the Extended

Actigram Star and BPMN models. For that, XML

Metadata Interchange (XMI) is used to save source

and target models and also mapping rules. This rules

is implemented using Atlas Transformation Language

(ATL). It relies on XSLT transformation conforms to

the BPMN modeler requirements.

The mapping rules creates correspondences and

links between concepts and their relations from EA*

and BPMN language. The modeling tool SLMTool-

Box supports the transformation and the mapping of

activities with human interaction (e.g. Pilot Mana-

ger).

The second model transformation (3) is an enri-

chment of the BPMN model, in which specialized hu-

mans resources add more technological details in the

process. In this paper, we intend to improve security

aspects around the business process with speciﬁc de-

tails about security activities as depicted in Figure 4.

The model transformation (4) is the uniﬁcation of

differents BPMN of the process in a unique BPMN

diagram. The business process management suite

(jBPM) imports an BPMN diagram. (5) and (6) re-

present the integration and execution of the workﬂow

in the jBPM suite. In the execution, some security ser-

vices implemented in Web Services (JAX-RS techno-

logy) are instantiated and used by the workﬂow (7).

5 TESTS

This section describes the execution of the process ba-

sed on a Business Process Management (BPM) Suite,

which is responsible to control the execution of the

process and enable perform services calls. This ap-

proach is essential to produces the services orchestra-

tion based on the model driven service engineering

architecture.

The uniﬁed BPMN is imported to the Kie Work-

bench to execute following services calls. This en-

vironment requires some conﬁgurations of the work-

ﬂow as well as variables to control the process’ work-

ﬂow, and also, request calls to Web Services are deﬁ-

ned.

Figure 6 presents a workﬂow within the KIE

Workbench. This solution has an integration for rule

orchestration/ﬂow offering process management of a

combination of processes, rules and events.

To simplify the workﬂow, the uniﬁed BPMN im-

ported centralized different pools/lanes in a unique

pool. In this case, there is a abstraction of these details

in the execution of the process. Two types of activi-

ties are used in this process to perform services calls

and users tasks to interacting with human resources to

receive inputs and show the service’s results.

The process is composed by some user tasks at

design time to deﬁne conﬁgurations about data col-

lection and runtime security monitoring. For exam-

ple, the manufacturing pilot manager is responsible to

virtualize his resources in the C2NET platform. So,

a set of resource’s conﬁgurations need to be uploaded

in this tasks to be published in the platform. Conside-

ring security issues, a security service is responsible

to collect information about resources to be imple-

mented some security mechanisms to protect them.

Model Driven Implementation of Security Management Process

235

Figure 6: BPMN of security management process.

Figure 7: Form of a security alert generated by a security tool.

This information will be used by the runtime security

monitoring service to start speciﬁc tools according in-

formation collected.

After to publish conﬁgurations in the C2NET plat-

form, the workﬂow starts two parallels tasks such as

Data Collection and Security Monitoring, respecti-

vely. Data collection tasks are responsible to read data

of resources in the sensor network that it will be pro-

cessed based on data ﬁltering according to data stan-

dards of the C2NET project.

Meanwhile, security mechanisms are used to mo-

nitor resources based on previous information about

devices. Each mechanisms report security alerts when

an anomaly is detected. These alerts are important to

the security process to identify potential solutions ba-

sed on the threat detected. In order to facilitate the

interoperability across a wide range of security me-

chanisms, IETF INtrusion Detection Platforms Wor-

king Group (Debar et al., 2007), established since

2007, has deﬁned a standard interoperable message-

type formats to carry alerts or notiﬁcations correspon-

ding to events as well as parameterization commands.

Many research contributions and projects have adop-

ted the XML-IDMEF that are available in different

languagues such as C, C++ Java and Python.

Security alerts are formatted based on this stan-

dard format, which each alert IDMEF-Message is

composed with such information: CreateTime, De-

tectTime, AnalyzerTime, Source (Node, User, Pro-

cess or Service), Target (Node, User, Process or

Service), Classiﬁcation, Assessment, AdditionalData

(Debar et al., 2007).

Some information are used in this paper to des-

cribe a security alert to identify mechanisms that can

be used to recover by a human resource. In this paper,

a form is used to show detailed information about an

anomaly detection of a security tool. Follow section

will describe an execution of the workﬂow based on

detected threat and forwarded to corrective action.

The execution of workﬂow allows to perform se-

veral services calls and to provide an interaction with

human resources based on some model transforma-

tion from business models to BPMN diagram. In this

simple example, the data collection process emcom-

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

236

pass a security monitoring service to identify potential

threat in the sensor network.

Figure 7 demonstrated a human task (Corrective

Action) responsible to the perform some conﬁgurati-

ons to recover a detected threat. This interaction with

a security expert is enriched with the result of Secu-

rity Threat Analysis, which proposes security mecha-

nims or only changes in security polices to recover an

anomaly to the network.

This security analysis enables to identify false po-

sitives that can occur and it must not interrup the

workﬂow. In contrast, some problems can result to

the end of the workﬂow. For instance, if an threat re-

sults in a critical problem for the infrastructure.

In this context, the human receive detailed infor-

mation about detected threats and security solutions

to be implemented.

6 CONCLUSIONS AND FUTURE

WORKS

Cooperative networks include organizations and busi-

nesses that are owned and managed by the people pro-

viding products and supplying of services. The crea-

tion of new services requires time and effort to design

effective services. The adoption of a methodology of

the Model Driven Service Engineering Architecture

(MDSEA) implements the process of model transfor-

mation from business details to speciﬁc artifacts.

The paper presented a implementation of a secu-

rity management process in a business model of the

manufacturing scenario of C2NET project as well as

the execution of model transformations following a

methodology MDSEA to enrich speciﬁc details du-

ring the process.

Due to the facility to construct services based on

model driven engineering behind manufacturing en-

terprises, the methodology MDSEA could be imple-

mented to demonstrate the transition between busi-

ness models to security artifacts and implementati-

ons. This implementation of the security management

process provided a view to understand how to enrich

a simple business model based on a methodology as

well as transforming high-level abstraction models to

add speciﬁc details of security activities.

As future works, we intend to use model dri-

ven engineering to support services development that

should to be executed in this security management

process. Also, the integration of ontology-based so-

lution need to be studied for the adoption of an

ontology-based framework to support making deci-

sion in realtime.

ACKNOWLEDGEMENTS

The research leading to this work has received fun-

ding from CAPES Proc. N

: BEX 0966/15-0 and

European Commission’s Horizon 2020 Programme

(H2020/2014-2020) under grant agreement: C2NET

: 636909.

REFERENCES

Agostinho, C.,

Cern

y, J., and Jardim-Goncalves, R. (2012).

Mda-based interoperability establishment using lan-

guage independent information models. In Interna-

tional IFIP Working Conference on Enterprise Intero-

perability, pages 146–160. Springer.

Atkinson, C. and Kuhne, T. (2003). Model-driven deve-

lopment: a metamodeling foundation. IEEE software,

20(5):36–41.

Bahill, A. T. and Gissing, B. (1998). Re-evaluating systems

engineering concepts using systems thinking. IEEE

Transactions on Systems, Man, and Cybernetics, Part

C (Applications and Reviews), 28(4):516–527.

Basin, D., Doser, J., and Lodderstedt, T. (2003). Model dri-

ven security for process-oriented systems. In Procee-

dings of the eighth ACM symposium on Access control

models and technologies, pages 100–109. ACM.

Bazoun, H., Ribault, J., Zacharewicz, G., Ducq, Y., and

Boy

e, H. (2016). Slmtoolbox: Enterprise service pro-

cess modeling and simulation by coupling devs and

services workﬂow. International Journal of Simula-

tion and Process Modelling.

Bazoun, H., Zacharewicz, G., Ducq, Y., and Boye, H.

(2013). Transformation of extended actigram star

to bpmn2.0 and simulation model in the frame of

model driven service engineering architecture. In

Proceedings of the Symposium on Theory of Mo-

deling & Simulation-DEVS Integrative M&S Sympo-

sium, page 20. Society for Computer Simulation In-

ternational.

Bazoun, H., Zacharewicz, G., Ducq, Y., and Boy

e, H.

(2014). Slmtoolbox: An implementation of mdsea for

servitisation and enterprise interoperability. In Enter-

prise Interoperability VI, pages 101–111. Springer.

ezivin, J. (2006). Model driven engineering: An emer-

ging technical space. In Generative and transformati-

onal techniques in software engineering, pages 36–64.

Springer.

Brucker, A. D., Hang, I., L

uckemeyer, G., and Ruparel, R.

(2012). Securebpmn: Modeling and enforcing access

control requirements in business processes. In Procee-

dings of the 17th ACM symposium on Access Control

Models and Technologies, pages 123–126. ACM.

Butun, I., Morgera, S. D., and Sankar, R. A survey of

intrusion detection systems in wireless sensor net-

works. IEEE Communications Surveys & Tutorials,

16(1):266–282.

Model Driven Implementation of Security Management Process

237

Chen, D. (2015). A methodology for developing service in

virtual manufacturing environment. Annual Reviews

in Control, 39:102–117.

De Castro, V., Marcos, E., and Vara, J. M. (2011). Applying

cim-to-pim model transformations for the service-

oriented development of information systems. Infor-

mation and Software Technology, 53(1):87–105.

Debar, H., Curry, D. A., and Feinstein, B. S. (2007). The

intrusion detection message exchange format (idmef).

IETF, NEtwork Working Group.

Derdour, M., Alti, A., Gasmi, M., and Roose, P. (2015).

Security architecture metamodel for model driven se-

curity. Journal of Innovation in Digital Ecosystems,

2(1):55–70.

Ducq, Y., Agostinho, C., Chen, D., Zacharewicz, G., and

Goncalves, R. (2014). Generic methodology for ser-

vice engineering based on service modelling and mo-

del transformation. Manufacturing Service Ecosy-

stem. Achievements of the European 7th FP FoF-

ICT Project MSEE: Manufacturing SErvice Ecosy-

stem (Grant No. 284860). Eds. Weisner S, Gugliel-

mina C, Gusmeroli S, Doumeingts G, pages 41–49.

Hossain, M. S. and Raghunathan, V. (2010). Aegis: A lig-

htweight ﬁrewall for wireless sensor networks. In In-

ternational Conference on Distributed Computing in

Sensor Systems, pages 258–272. Springer.

urjens, J. (2002). Umlsec: Extending uml for secure

systems development. In International Conference

on The Uniﬁed Modeling Language, pages 412–425.

Springer.

Lambert, J. H., Jennings, R. K., and Joshi, N. N. (2006).

Integration of risk identiﬁcation with business process

models. Systems engineering, 9(3):187–198.

Lodderstedt, T., Basin, D., and Doser, J. (2002). Secureuml:

A uml-based modeling language for model-driven se-

curity. In International Conference on the Uniﬁed Mo-

deling Language, pages 426–441. Springer.

Mellor, S. J., Clark, T., and Futagami, T. (2003). Model-

driven development: guest editors’ introduction. IEEE

software, 20(5):14–18.

Menzel, M., Thomas, I., and Meinel, C. (2009). Secu-

rity requirements speciﬁcation in service-oriented bu-

siness process management. In Availability, Reliabi-

lity and Security, 2009. ARES’09. International Con-

ference on, pages 41–48. IEEE.

Mozzaquatro, B. A., Jardim-goncalves, R., and Agostinho,

C. (2015). Towards a reference ontology for security

in the internet of things. In IEEE International Works-

hop on Measurement and Networking, pages 1–6.

Mozzaquatro, B. A., Melo, R., Agostinho, C., and Jardim-

Goncalves, R. (2016). An ontology-based security

framework for decision-making in industrial systems.

In Proceedings of the 4th International Conference

on Model-Driven Engineering and Software Develop-

ment, pages 779–788.

unch, J., Armbrust, O., Kowalczyk, M., and Soto, M.

(2012). Process modeling notations and tools. In Soft-

ware Process Deﬁnition and Management, pages 111–

138. Springer.

Patel, H. B., Jinwala, D. C., and Patel, D. R. (2016). Base-

line intrusion detection framework for 6lowpan devi-

ces. In Adjunct Proceedings of the 13th International

Conference on Mobile and Ubiquitous Systems: Com-

puting Networking and Services, pages 72–76. ACM.

Ren, J. and Taylor, R. (2005). A secure software architec-

ture description language. In Workshop on Software

Security Assurance Tools, Techniques, and Metrics,

pages 82–89.

Seidewitz, E. (2003). What models mean. IEEE software,

20(5):26.

Selic, B. (2003). The pragmatics of model-driven develop-

ment. IEEE software, 20(5):19.

Wolter, C., Menzel, M., Schaad, A., Miseldine, P., and Mei-

nel, C. (2009). Model-driven business process security

requirement speciﬁcation. Journal of Systems Archi-

tecture, 55(4):211–223.

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

238