Secure Web Engineering Supported by an Evaluation Framework

∗

Preliminary Report on a Web Engineering Approach for Secure Applications

Supported by a Conceptual Evaluation Framework for Secure Systems Engineering

Marianne Busch

Ludwig-Maximilians-Universit

at M

unchen, Oettingenstraße 67, 80538 M

unchen, Germany

1 STAGE OF THE RESEARCH

This paper reports on the progress of the author’s PhD

in the area of security engineering for web applica-

tions. Initially, the work was located at the beginning

of the Software Development Life Cycle (SDLC) with

a focus on design. However, designing a perfectly se-

cure application is worth nothing, if it is not possible

for security engineers to choose appropriate methods,

notations and tools (so called mechanisms) to work

with in each phase of the SDLC. Therefore, we

addi-

tionally develop a conceptual framework for the eval-

uation of these Mechanisms, which is not limited to

the web, and also has a focus on security.

At the moment, almost two-thirds of the work for

the PhD is done, which means that most underlying

ideas are written down but further case studies and

evaluations will follow.

2 OUTLINE OF OBJECTIVES

Daily news tells that web applications are often not

secure enough, which is a threat to the user’s privacy

as well as to the image of companies. Our ﬁrst aim

is to make web applications more secure by taking

security features into account at the very beginning

of the SDLC. During the requirements and design

phases, graphical or textual models can help to get

an overview of a web application and its security fea-

tures. Besides, models can be used for documentation

purposes, and security-related properties in models

can be validated and transformed to artifacts for the

implementation phase. We extend an existing model-

∗

I like to thank my PhD supervisor Martin Wirsing and

my colleague Nora Koch for their support and for fruitful

discussions. This work has been supported by the EU-NoE

project NESSoS, GA 256980.

The term “we”, as used in this paper, refers to a team

effort, however, with substantial contributions by the author.

ing approach in a way that general security features as

secure connections, authentication and access control

on data structures can be represented. Additionally,

we focus on speciﬁc security features, as access con-

trol on the navigation structure of a web application

or automated reactions to denial-of-service attacks.

Collecting and analyzing data of existing secu-

rity engineering methods, notations and tools (mech-

anisms) is of major importance for security and soft-

ware engineers, as it helps them to take decisions

about solutions for upcoming tasks. These tasks can

be related to the design of web applications, but can

as well go beyond web engineering.

To ease the tasks of recording own results and of

getting an overview of existing methods, notations

and tools the Common Body of Knowledge

was im-

plemented as a semantic Wiki within the scope of

the EU project NESSoS. As we are members of this

project, we gained experience working with the CBK

and its underlying ontology and reﬂected on require-

ments for a conceptual evaluation framework. Our

second aim is to provide an approach for the evalua-

tion of methods, notations and tools for the engineer-

ing of secure software systems. Evaluation should

also be possible for vulnerabilities, threats and secu-

rity properties (e.g., integrity). The term “evaluation”

covers the collection, analysis and ﬁner-grained rep-

resentation of (security-speciﬁc) knowledge. Another

requirement is that the core framework is not overly

detailed, but easy to extend.

3 RESEARCH PROBLEM

In this section, research questions are prompted,

which – to the best of our knowledge – were not fully

answered before the author’s work started in 2011.

Generally, secure web applications can be mod-

CBK. http://nessos-project.eu/cbk

Busch M..

Secure Web Engineering Supported by an Evaluation Framework - Preliminary Report on a Web Engineering Approach for Secure Applications

Supported by a Conceptual Evaluation Framework for Secure Systems Engineering.

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

eled on a high-level of abstraction, as UML-based

Web Engineering (UWE) (Koch et al., 2008; Busch

et al., 2011) or on a level where all information for an

implementation is given, as usually done with Action-

GUI (Basin et al., 2011). Advantages of a higher level

of abstraction are that modeling of modern web ap-

plications does not take too much time, quickly pro-

vides an overview and the engineer can go into de-

tails whenever needed. Advantages of lower level of

abstraction are that, ideally, the code of a web ap-

plication can be fully generated from the model, al-

though generated applications are severely limited by

the power of the modeling language.

A large majority of companies strives for attract-

ing customers by using leading-edge technology in

their web pages. Limitations are unwanted, despite

the prospect of web applications that are more secure,

if modeled thoroughly. This is why the author started

to extend UWE for security features in her Master’s

thesis (Busch, 2011). Beyond the Master’s thesis, in-

teresting questions are:

• How can a high-level modeling language as UWE

be extended so that the result is useful, security-

speciﬁc and more closely related to the web?

• Although not the whole source code can be ob-

tained, which artifacts can be generated?

• Which beneﬁts can be achieved by model-

checking and testing of artifacts?

• Is UWE’s graphical notation enough or might it

be useful to create a textual version?

• If engineers start modeling with UWE, but later

decide that complete model generation is impor-

tant in a certain situation, how can UWE models

be transformed to ActionGUI?

• Can UWE’s security extensions be added to other

web modeling languages, as to (IFML, 2013)?

A challenge is to understand the domain of security

engineering, not only regarding security modeling,

but also regarding the creation of an evaluation frame-

work. For the latter, issues to be examined are:

• How could security-related features, as secu-

rity properties, vulnerabilities and threats, be-

come ﬁrst-class citizens and how could the depen-

dences between mechanisms (method, notations

and tools) and security features be modeled best?

• How would an ontology look like, which can be

used for ﬁnding answers to research questions be-

yond comparing general mechanisms?

• How is the process of data collection and data

analysis speciﬁed, to make sure that emerging re-

search results are comprehensible and valid?

4 STATE OF THE ART

This chapter introduces approaches for secure web

engineering as well as evaluation approaches.

4.1 Secure Web Engineering

Many web engineering approaches exist, which do

not allow to model security features, as e.g., OOHRIA

(Meli

a et al., 2008), OOWS (Valverde and Pastor,

2008), WebML (Brambilla and Fraternali, 2013) and

(IFML, 2013), which is based on WebML.

Security-aware modeling approaches are brieﬂy

introduced in the following [description adapted from

(Busch et al., 2011; Busch et al., 2013)].

Our approach is based on the UWE LANGUAGE

(Koch et al., 2008; Busch et al., 2011). One of the

cornerstones is the “separation of concerns” princi-

ple using separate models for different views. How-

ever, we can observe that security features are cross-

cutting concerns which cannot be separated com-

pletely. Since the extension of the author’s Master

thesis (Busch, 2011), main UWE models have been:

The Requirements Model. deﬁnes (security)

requirements for a project.

The Content Model. contains the data structure

used by the application.

The UWE Role Model. describes a hierarchy of

user groups to be used for authorization and ac-

cess control issues. It is usually part of a User

Model, which speciﬁes basic structures, as e.g.,

that a user can take on certain roles simultane-

ously.

The Basic Rights Model. describes access control

policies. It constrains elements from the Content

Model and from the Role Model.

The Presentation Model. sketches the web applica-

tion’s user interface.

The Navigation State Model. deﬁnes the navigation

ﬂow of the application and navigational access

control policies. The former shows which pos-

sibilities of navigation exist in a certain context.

The latter speciﬁes which roles are allowed to

navigate to a speciﬁc state and the action taken

in case access cannot be granted. In a web appli-

cation such actions can be, e.g., to logout the user

and to redirect to the login form or just to display

an error message. Furthermore, secure connec-

tions between server and browser are modeled.

For each view, an appropriate type of UML diagram

is used, e.g., a state machine for the navigation model.

In addition, the UWE Proﬁle adds a set of stereotypes,

tag deﬁnitions and constraints, which can be down-

loaded from the UWE website (LMU, 2013). Stereo-

MODELSWARD2014-DoctoralConsortium

types can then be applied to UML model elements and

values can be assigned to tags, which are associated to

at least one stereotype.

ACTIONGUI (Basin et al., 2010) is an approach

for generating complete, but simpliﬁed, data-centric

web applications from models. It provides an OCL

speciﬁcation of all functionalities, so that navigation

is only modeled implicitly by OCL constraints. As

described in Section 3, ActionGUI abstracts less from

an implementation than UWE does.

UMLSEC (J

urjens, 2004) is an extension of UML

with emphasis on secure protocols. It is deﬁned

in form of a UML proﬁle including stereotypes for

concepts like authenticity, freshness, secrecy and in-

tegrity, role-based access control, guarded access, fair

exchange, and secure information ﬂow. In particular,

the use of constraints gives criteria to evaluate the se-

curity aspects of a system design, by referring to a

formal semantics of a simpliﬁed fragment of UML.

UMLsec models, compared to UWE models, are ex-

tremely detailed and therefore quickly become very

complex. Tool support is only partly adopted from

UML1.4 to UML2. However, the new tools

have not

been updated for almost two years.

SECUREUML (Lodderstedt et al., 2002) is a

UML-based modeling language for secure systems.

It provides modeling elements for role-based access

control and the speciﬁcation of authorization con-

straints. A SecureUML dialect has to be deﬁned in or-

der to connect a system design modeling language as,

e.g., ComponentUML to the SecureUML metamodel,

which is needed for the speciﬁcation of all possible

actions on the predeﬁned resources. In our approach,

we specify role-based execution rights to methods in

a basic rights model using dependencies instead of the

SecureUML association classes, which avoids the use

of method names with an access related return type.

However, UWE’s basic rights models can easily be

transformed into a SecureUML representation.

A similar approach is UACML (Slimani et al.,

2011) which also comes with a UML-based meta-

metamodel for access control, which can be special-

ized into various meta-models for, e.g., role-based

access control (RBAC) or mandatory access control

(MAC). Conversely to UWE, the resulting diagrams

of SecureUML and UACML are overloaded, as Se-

cureUML uses association classes instead of depen-

dencies and UACML does not introduce a separate

model to specify user-role hierarchies.

There is a set of approaches that address modeling

of security aspects of service-oriented architectures

(SOAs), such as the SECTET framework (Hafner and

Breu, 2008), UML4SOA (Gilmore et al., 2011), and

UMLsec tools. http://carisma.umlsec.de

SecureSOA (Menzel and Meinel, 2009). The ﬁrst one

proposes the use of sequence diagrams for the repre-

sentation of a set of security patterns, in UML4SOA

security features are modeled as non-functional prop-

erties using class diagrams, and the latter relies on

FMC block diagrams and BPMN notation.

4.2 Evaluation Approaches

Evaluation approaches are often tailored to the needs

of a speciﬁc area. We start by introducing general

approaches and continue with security-speciﬁc ones.

This section is adapted from (Busch and Koch, 2013).

General Evaluation Approaches. KITCHENHAM

et al. (Kitchenham and Charters, 2007) specify so

called “Systematic Literature Reviews” in software

engineering. The aim is to answer research questions

by systematically searching and extracting knowl-

edge of existing literature. Our evaluation frame-

work, called SECEVAL, is based on their work, how-

ever SECEVAL is not restricted to literature reviews.

We focus on the use of arbitrary resources, as source

code or experiments which are carried out to an-

swer a security-related research question. In contrast

to Kitchenham’s approach, the process we deﬁne is

generic and thus allows us to reﬁne the way of search-

ing after ﬁrst results indicate a worthwhile direction

for further research.

SIQINU (Becker et al., 2013) is a framework for

evaluating the quality of a product version which can

then be improved. It uses the conceptual framework

C-INCAMI, which speciﬁes concepts and relation-

ships for measurement and evaluation. SIQinU de-

ﬁnes a strategy using UML activity diagrams whereas

C-INCAMI is speciﬁed by a UML class diagram.

MOODY (Moody, 2003) proposes an evaluation

approach which is based on experiments. Practi-

tioners use methods and afterwards answer questions

about perceived ease of use, perceived usefulness and

intention to use. A ﬁgure how Moody’s approach can

be integrated can be found online (Busch, 2013).

The CBK (Common Body of Knowledge) (Beck-

ers et al., 2012) deﬁnes an ontology for software en-

gineers to describe Knowledge Objects (KOs), which

are methods, techniques, notations, tools or standards.

Techniques are methods which do not specify activ-

ities for applying the method. The CBK is imple-

mented as a semantic Wiki and serves as a knowl-

edge base containing all relevant information about

existing KOs. Unlike the CBK, SECEVAL is not im-

plemented yet. In contrast to the CBK, SECEVAL

focuses on security-related features and provides a

ﬁne-grained ontology, which explicitly considers the

SecureWebEngineeringSupportedbyanEvaluationFramework-PreliminaryReportonaWebEngineeringApproachfor

SecureApplicationsSupportedbyaConceptualEvaluationFrameworkforSecureSystemsEngineering

phases of the SDLC. Additionally, it deﬁnes a process

for the evaluation of KOs.

Security-speciﬁc Evaluation Approaches.

Security-related frameworks often consider con-

crete software systems for their evaluation. An

example is the OWASP RISK RATING METHOD-

OLOGY

, where the risk for a concrete application

or system is estimated. For SECEVAL, we added

vulnerability-dependent features of the OWASP

model, as e.g., the difﬁculty of detecting or exploiting

a vulnerability. Features that are related to a concrete

system and the rating of a possible attack are intro-

duced as an extension of SECEVAL, which can be

found online (Busch, 2013).

The i* metamodel

is the basis of a vulnerability-

centric requirements engineering framework intro-

duced in (Elahi et al., 2010). The extended,

VULNERABILITY-CENTRIC I* METAMODEL aims at

analyzing security attacks, countermeasures, and re-

quirements based on vulnerabilities. The metamodel

is represented using UML class models.

Another approach which is focused on vulnera-

bilities is described by Wang et al. (Wang and Guo,

2009) Their concept model is less detailed than the i*

metamodel. Their aim is not to describe reality by us-

ing graphical models, but to create a knowledge base

which can then be queried using a language for the

semantic web, called SWRL.

5 METHODOLOGY

To answer the research questions, listed in Section 3,

the following methodological steps are used.

To conduct a LITERATURE REVIEW, similar to

Kitchenham et al. (Kitchenham and Charters, 2007),

helps to get into the topic at the beginning and makes

it easy to stay up-to-date during the work on the PhD.

To prove the applicability of SECEVAL, we plan to

graphically model the knowledge gathered in the lit-

erature review regarding (security) modeling for web

applications.

To fully understand the research questions that

we want to answer, it is necessary to ELICIT RE-

QUIREMENTS for the UWE extension as well as for

SECEVAL. Additionally, small CASE STUDIES can

show, if new ideas are reasonable and consistent to

the whole approach. Towards the end of the PhD, big

case studies are going to make sure that our approach

Risk Rating Methodology. https://www.owasp.org/

index.php/OWASP Risk Rating Methodology

i* notation. http://istar.rwth-aachen.de/

scales and that common, as well as exceptional situa-

tions can be modeled.

Asking for FEEDBACK is crucial, be it by submit-

ting papers or by conducting interviews. To get feed-

back from international senior researchers, who are

experts in various areas of security engineering, we

combined a questionnaire with live-explanations and

discussions, which was very useful for the develop-

ment of SECEVAL. Regarding UWE, it is interesting

to compare the amount of errors in bigger web ap-

plications, which are modeled with UWE, with those

which are implemented traditionally. Unfortunately,

such a big empirical study is out of the scope of the

author’s PhD

, but feedback from students, which are

working with UWE in their bachelor or master’s the-

ses partly ﬁlls this gap, along with the validation by

using case studies.

6 EXPECTED OUTCOME

In this section, an overview of preliminary and ex-

pected results for secure web engineering and for our

security framework SECEVAL is given.

6.1 Secure Web Engineering

We brieﬂy introduce a small case study from (Busch

et al., 2013), named SmartGrid Bonus Application,

before (expected) results are presented, using the

same order as in Section 3. Another case study about

patient monitoring can be found in (LMU, 2013) and

additionally, we are working on a big case study about

the customer web interface in a smart grid home.

Both case studies are built upon requirements from

SIEMENS, which is a partner in the NESSoS project.

Most tools and prototypes, which are mentioned in

this section can also be found at the UWE web page

(LMU, 2013).

Of all UWE models, introduced in Section 4, the

basic rights model and the navigation state model are

most important for modeling security features. Our

case study is a prototype of an energy offer manage-

ment system including optional bonus handling. It

provides two different user roles namely provider and

customer: providers manage and sell energy packages

including optional bonus programs for customers, as

depicted in Figure 1. Customers have the possibility

to buy offered energy packages. Therefore, our ap-

plication lists all available energy offers and the cus-

tomer selects a speciﬁc offer which includes a bonus

code. After buying an energy package, the application

Advice how to do this in a small way are welcome.

MODELSWARD2014-DoctoralConsortium

shows the corresponding bonus code which contains

a gift voucher, e.g., for online shops. Finally, the cus-

tomer gets a conﬁrmation for the ordered energy.

Figure 1: UWE: Navigation States Example.

In order to model the data structure man-

aged by our case study, we use UWE’s CON-

TENT MODEL. Basically, it comprises two domain

classes, EnergyOffer and BonusProgram, which

are also used in Figure 2. An instance of the

class EnergyOffer represents a speciﬁc energy of-

fer launched by an energy provider including start

and end date. Each object of EnergyOffer can

include an arbitrary number of BonusProgram in-

stances. A BonusProgram instance stands for an ad-

ditional bonus customers get, after they have bought

the corresponding EnergyOffer.

Figure 2: UWE: Basic Rights Example.

In order to model RBAC constraints we use

UWE’s BASIC RIGHTS MODEL, depicted in Fig-

ure 2. Basically, it uses classes of the CONTENT

MODEL on the left-hand side in combination with

user roles on the right-hand side. Access permis-

sions were deﬁned by stereotyped dependencies: for

our application, a provider has no restricting con-

straints. By contrast, there is only a limited set of per-

missions for users taking on the role of a customer:

they are only allowed to read instances of the class

EnergyOffer and to call the methods buyOffer()

and generateBonusCode().

At the moment, we are working on more web-

security speciﬁc content, which is not shown in the

example above. It will e.g. be possible to use UWE

for modeling application behavior in case of panic- or

under-ﬁre mode. The panic mode is useful for tumul-

tuous regions around the world, where users might be

physically forced to sign in an online service to per-

form certain tasks. This can e.g., be mitigated by a

second password, which changes the web application

in a predeﬁned way. The under-ﬁre modeling ele-

ments refer to the application’s behavior under denial-

of-service attacks.

Artifacts which can be extracted from UWE mod-

els are e.g. RBAC rules. We use the model to text

transformation language XPand to transform UWE

models to XACML

and to code snippets. For

the latter, we implemented a prototypic transforma-

tion of the data structure, roles and RBAC rules to

Apache Wicket with Apache Shiro and Hibernate

(Wolf, 2012).

Exporting XACML policies, which can include

RBAC policies from the Basic Rights model as well

as from the navigational states model, is implemented

in a tool called UWE2XACML. In (Busch et al.,

2012), it is also explained how XACML can be trans-

formed in FACPL, a formal policy language with the

advantage of fully speciﬁed semantics.

Additionally, XACML can be used to generate

tests by using a tool chain, including UWE2XACML,

X-CREATE

for generating XACML requests, a

PDP (Policy Decision Point which responds to

XACML requests), as suggested in (Bertolino et al.,

2013). The advantage is that policies are modeled

at a high level of abstraction so they are easy to un-

derstand and to maintain, whereas policies written in

XACML tend to become lengthy and error-prone.

Constraints like “a customer can only get access to

a bonus code after he bought an energy package” can

be inferred from navigational state models (cf. transi-

tions in Figure 1). To extract so called Secure Nav-

igation Paths (SNPs) and to use them both for au-

tomatic testing and for the generation of a monitor,

which shields the web application from illicit access

sequences, is described in (Busch et al., 2013). The

associated tool MagicSNP is an extension of a plugin

for MagicDraw 17.0

, called MagicUWE, which we

XACML 2.0. http://docs.oasis-open.org/xacml/2.0/

X-CREATE. http://labsedc.isti.cnr.it/tools/xcreate

MagicDraw. http://magicdraw.com/

SecureWebEngineeringSupportedbyanEvaluationFramework-PreliminaryReportonaWebEngineeringApproachfor

SecureApplicationsSupportedbyaConceptualEvaluationFrameworkforSecureSystemsEngineering

implemented to ease the creation of UWE models.

Another transformation we considered is the

model-to-model transformation from UWE to Action-

GUI, described in (Busch and Garc

ıa de D

ıos, 2012).

Some engineers prefer textual models and as this

is a matter of taste and both types have advantages and

disadvantages, we aim at providing a Domain Spe-

ciﬁc Language (DSL) for UWE, called TEXTUAL-

UWE. The focus is on creating an intelligible lan-

guage, which is not only easy to read but also ex-

ploitable by algorithms. As we want to open the way

to expressive algorithms, we decided to use Scala

, a

multi-paradigm programming language. For our work

we use the functional style, as it allows writing short

and precise algorithms to support TextualUWE. We

are working on algorithms to check security features

of TextualUWE models, as e.g., which part of the web

application can be reached by a user which is asso-

ciated to a certain role. Further veriﬁable features

are to ﬁnd inconsistencies in the model or to check

what happens when parts of pages (so-called naviga-

tion nodes) are illegally accessed.

A transformation from graphical UWE models to

TextualUWE is currently under construction (Rze-

haczek, 2013) – it works for the small case study

shown above. For implementing the transformation

we use Acceleo, as it is mightier than XPand. It trans-

forms MagicDraw projects, exported using the XML

Metadata Interchange (XMI) format, to our DSL.

As soon as we added all web speciﬁc security fea-

tures we plan to integrate, we are going to use the

concepts for IFML and report on needed extensions,

due to the fact that the navigation structure cannot be

modeled in IFML.

6.2 Conceptual Evaluation Framework

Our evaluation framework SECEVAL provides a

structure for data as well as a structure for perform-

ing a data analysis on the collected data (i.e., meth-

ods, notations and tools in the context of security

properties, vulnerabilities and threats). We grouped

these concepts in three packages: Security Context,

Data Collection and Data Analysis. Figure 3 shows

SECEVAL’s ontology represented as a UML class di-

agram. We selected UML, as we think it ﬁts our needs

best. Deliverable D2.4 (Busch and Koch, 2013) of

the NESSoS project includes a detailed description of

SECEVAL. This section is adapted from D2.4 and fo-

cuses exemplarily on the security context.

The SECURITY CONTEXT package is used to

specify the object-oriented data structure we use for

Scala. http://scala-lang.org

Figure 3: SECEVAL: Model Overview.

describing methods and related security features, no-

tations and tools. The classes Method, Notation and

Tool inherit general attributes, as e.g., a problem de-

scription and whether or not it is based on standards,

from the abstract class Mechanism. Additionally, a

tool can support methods and a notation can be used

for several methods.

Having a well-deﬁned data structure which is ex-

tensible is one thing, collecting concrete data the

other. The package DATA COLLECTION contains the

search process as well as research questions which

should be investigated.

Research questions deﬁne what is inside and out-

side the scope of research. Before specifying the re-

search questions, a basic understanding of the con-

text is needed, therefore a dependency, stereotyped by

“use”, points from ResearchQuestion to the pack-

age SecurityContext. Queries can be deﬁned ac-

cordingly. They are used to ﬁnd matching sources

containing data which might help to answer the re-

search questions. Please note that for us the term “re-

search question” does not have to refer to scientiﬁc

research questions.

After collecting data, the source data may con-

sist of, e.g., some papers, several websites or code.

The process of extracting information from the data

is called DATA ANALYSIS. An analysis strategy de-

ﬁnes criteria which are important for answering the

research question, like costs or preconditions. These

criteria are used to classify information which is ex-

tracted from the sources. Information can also be pro-

cessed, for example one could calculate annual costs

for tools. The instructions used for those calculations

are referred to as AnalysisAlgorithm in Figure 3.

Each piece of information (processed or not) can re-

late to classes of the security context model, e.g., a

tool can be described using information from the web-

site of the tool. However, information does not have

MODELSWARD2014-DoctoralConsortium

Figure 4: SECEVAL: Security Context.

to be related to a context model’s class.

Figure 4 shows a more detailed data structure of

the Security Context package, as attributes and enu-

merations are shown.

During our experience with the CBK, we noticed

that tools as well as methods would be better de-

scribed according to their usage in the SDLC, because

attributes which are used to describe a method or tool

are related to the SDLC phases it covers. As far as we

know, no phase-related attributes are needed to de-

scribe features of notations. Figure 5 also depicts our

Method class. The abstract class MAreasOfDev is a

wildcard for detailed information about the method.

A method can support several development phases.

The phases of the SDLC are the same we have chosen

to classify tools and methods in the NESSoS project

(Busch and Koch, 2011): requirements, design, im-

plementation, testing, assurance, risk & cost, service

composition and deployment.

The full MagicDraw 17.0 model of SECEVAL and

all diagrams (including the overall process and full

details of method and tool description according to

phases within the SDLC) can be downloaded from the

web (Busch, 2013). There, the OWASP and Moody

extension of SECEVAL, which was mentioned in Sec-

tion 4 can also be found.

In (Busch and Koch, 2013), we use SECEVAL for

a case study in which we evaluate vulnerability scan-

ners for testing security features of web applications.

Additionally, we plan to update our knowledge about

secure web engineering approaches by conducting an

evaluation based on SECEVAL. A long-term objec-

tive is to implement SECEVAL as a knowledge base,

similarly to the CBK.

In summary, it can be stated that our approach for

engineering secure web applications and our concep-

tual evaluation framework SECEVAL, tackle the prob-

lem of securing applications during the SDLC. Con-

sequently, a long-term impact could be the reduction

of security ﬂaws and of necessary security patches.

Figure 5: SECEVAL: Details of Methods (excerpt).

SecureWebEngineeringSupportedbyanEvaluationFramework-PreliminaryReportonaWebEngineeringApproachfor

SecureApplicationsSupportedbyaConceptualEvaluationFrameworkforSecureSystemsEngineering

REFERENCES

Basin, D., Clavel, M., and Egea, M. (2010). Automatic

Generation of Smart, Security-Aware GUI Models.

In Engineering Secure Software and Systems, volume

5965 of Lecture Notes in Computer Science, pages

201–217. Springer.

Basin, D., Clavel, M., Egea, M., Garc

ıa de Dios, M. A.,

Dania, C., Ortiz, G., and Valdazo, J. (2011). Model-

Driven Development of Security-Aware GUIs for

Data-Centric Applications. In Aldini, A. and Gorri-

eri, R., editors, Foundations of Security Analysis and

Design VI, volume 6858 of Lecture Notes in Computer

Science, pages 101–124. Springer Berlin Heidelberg.

Becker, P., Papa, F., and Olsina, L. (2013). Enhancing the

Conceptual Framework Capability for a Measurement

and Evaluation Strategy. 4th International Workshop

on Quality in Web Engineering , 6360:1–12.

Beckers, K., Eicker, S., Heisel, M., and (UDE),

W. S. (2012). NESSoS Deliverable D5.2 –

Identiﬁcation of Research Gaps in the Com-

mon Body of Knowledge. http://www.nessos-

project.eu/media/deliverables/y2/NESSoS-D5.2.pdf.

Bertolino, A., Busch, M., Daoudagh, S., Koch, N., Lonetti,

F., and Marchetti, E. (2013). A Toolchain for Design-

ing and Testing XACML Policies. In Proceedings of

ICST 2013.

Brambilla, M. and Fraternali, P. (2013). Large-scale Model-

Driven Engineering of web user interaction: The

WebML and WebRatio experience. Science of Com-

puter Programming.

Busch, M. (2011). Integration of Security As-

pects in Web Engineering. Master’s the-

sis, Ludwig-Maximilians-Universit

at M

unchen.

http://uwe.pst.iﬁ.lmu.de/publications/BuschDA.pdf.

Busch, M. (2013). SecEval – Information and Figures.

http://www.pst.iﬁ.lmu.de/ busch/SecEval/.

Busch, M. and Garc

ıa de D

ıos, M. A. (2012). Ac-

tionUWE: Transformation of UWE to ActionGUI

Models. Technical report, Ludwig-Maximilians-

Universit

at M

unchen. Number of Report: 1203.

Busch, M., Knapp, A., and Koch, N. (2011). Modeling Se-

cure Navigation in Web Information Systems. In Gra-

bis, J. and Kirikova, M., editors, 10th International

Conference on Business Perspectives in Informatics

Research, LNBIP, pages 239–253. Springer Verlag.

Busch, M. and Koch, N. (2011). NESSoS De-

liverable D2.1 – First release of Method

and Tool Evaluation. http://www.nessos-

project.eu/media/deliverables/y1/NESSoS-D2.1.pdf.

Busch, M. and Koch, N. (2013). NESSoS Deliverable D2.4

– Second Release of the Method and Tool Evaluation.

to appear.

Busch, M., Koch, N., Masi, M., Pugliese, R., and Tiezzi,

F. (2012). Towards model-driven development of ac-

cess control policies for web applications. In Model-

Driven Security Workshop in conjunction with MoD-

ELS 2012. ACM Digital Library.

Busch, M., Koch, N., and Wirsing, M. (2014). SecEval: An

Evaluation Framework for Engineering Secure Sys-

tems. submitted.

Busch, M., Ochoa, M., and Schwienbacher, R. (2013).

Modeling, Enforcing and Testing Secure Navigation

Paths for Web Applications. Technical Report 1301,

Ludwig-Maximilians-Universit

at M

unchen.

Elahi, G., Yu, E., and Zannone, N. (2010). A vulnerability-

centric requirements engineering framework: analyz-

ing security attacks, countermeasures, and require-

ments based on vulnerabilities. Requirements Engi-

neering, 15(1):41–62.

Gilmore, S., G

onczy, L., Koch, N., Mayer, P., Tribas-

tone, M., and Varr

o, D. (2011). Non-functional Prop-

erties in the Model-Driven Development of Service-

Oriented Systems. SOSYM, 10(3):287–311.

Hafner, M. and Breu, R. (2008). Security Engineering for

Service-Oriented Architectures. Springer.

IFML (2013). Interaction Flow Modeling Lan-

guage (IFML), FTF – Beta 1. OMG standard.

http://www.omg.org/spec/IFML/.

urjens, J. (2004). Secure Systems Development with

UML. Springer. Tools and further information:

http://www.umlsec.de/.

Kitchenham, B. and Charters, S. (2007). Guidelines for

performing Systematic Literature Reviews in Soft-

ware Engineering. Technical Report EBSE 2007-001,

Keele University and Durham University Joint Report.

Koch, N., Knapp, A., Zhang, G., and Baumeister, H. (2008).

UML-based Web Engineering: An Approach based on

Standards. In Web Engineering: Modelling and Imple-

menting Web Applications, Human-Computer Interac-

tion Series, pages 157–191. Springer.

LMU (2013). UWE – UML-based Web Engineering Home-

page. http://uwe.pst.iﬁ.lmu.de/.

Lodderstedt, T., Basin, D., and Doser, J. (2002). Se-

cureUML: A UML-Based Modeling Language for

Model-Driven Security. In Proc. 5th Int. Conf. Uni-

ﬁed Modeling Language (UML’02), volume 2460 of

Lecture Notes in Computer Science, pages 426–441.

Springer.

Meli

a, S., G

omez, J., P

erez, S., and D

ıaz, O. (2008). A

Model-Driven Development for GWT-Based Rich In-

ternet Applications with OOH4RIA. In ICWE’08,

pages 13–23. IEEE.

Menzel, M. and Meinel, C. (2009). A Security Meta-model

for Service-Oriented Architectures. In Proc. 2009

IEEE Int. Conf. Services Computing (SCC’09), pages

251–259. IEEE.

Moody, D. L. (2003). The Method Evaluation Model:

a Theoretical Model for Validating Information Sys-

tems Design Methods. In Ciborra, C. U., Mercurio,

R., de Marco, M., Martinez, M., and Carignani, A.,

editors, ECIS, pages 1327–1336.

Rzehaczek, K. (2013). Transformation of graphical UWE

models to a textual DSL. Bachelor Thesis.

Slimani, N., Khambhammettu, H., Adi, K., and Logrippo,

L. (2011). UACML: Uniﬁed Access Control Model-

ing Language. In NTMS 2011, pages 1–8.

Valverde, F. and Pastor, O. (2008). Applying Interac-

tion Patterns: Towards a Model-Driven Approach for

MODELSWARD2014-DoctoralConsortium

Rich Internet Applications Development. In Proc. 7th

Int. Wsh. Web-Oriented Software Technologies (IW-

WOST’08).

Wang, J. A. and Guo, M. (2009). Security Data Mining in an

Ontology for Vulnerability Management. In Bioinfor-

matics, Systems Biology and Intelligent Computing,

2009. IJCBS ’09. International Joint Conference on,

pages 597–603.

Wolf, K. (2012). Sicherheitsbezogene Model-to-Code

Transformation f

ur Webanwendungen (German).

Bachelor Thesis.

SecureWebEngineeringSupportedbyanEvaluationFramework-PreliminaryReportonaWebEngineeringApproachfor

SecureApplicationsSupportedbyaConceptualEvaluationFrameworkforSecureSystemsEngineering