Back to the Drawing Board

Bringing Security Constraints in an Architecture-centric Software Development

Process

Stefanie Jasser

, Katja Tuma

, Riccardo Scandariato

and Matthias Riebisch

Department of Informatics, Universit

at Hamburg, Hamburg, Germany

Software Engineering Division, Chalmers and Gothenburg University, G

oteborg, Sweden

Keywords:

Software Architecture, Security by Design, Privacy by Design, Secure Software Architecture, Architecture

Erosion, Architectural Decay, Architecture Violations, Architecture Conformance Checking, Architecture

Compliance Checking, Security Constraints.

Abstract:

Today, security is still poorly considered in early phases of software engineering. Architects and software

engineers still lack knowledge about architectural security design as well as implementing it compliantly.

However, a software system that is not designed for security or does not adhere to this design can hardly meet

its security requirements. In this paper, we present an approach we are working on. The approach consists of

two parts: Firstly, we improve the architecture’s security level through model transformation. Secondly, we

derive rules and constraints from the secured architecture in order to check the implementation’s conformance.

Through these activities we aim to support architects and software developers in building a secure software

system. We plan to evaluate our approach in industrial case studies.

1 INTRODUCTION

Designing and implementing a secure software sys-

tem is a highly complex task that can hardly be done

by a non-security expert today. However, it is essen-

tial to consider security as early as possible.

Software architects as well as software develop-

ers usually are no security experts. Hence, designing

secure architectures and implementing a system in a

secure way in compliance with architectural rules and

constraints is a challenging task to most software en-

gineers.

While security solutions such as patterns or tactics

are thought of as encapsulated security expert knowl-

edge, applying them correctly is still difﬁcult. Sup-

posing a solution has been applied correctly, several

difﬁculties arrive afterwards: First, there are uncer-

tainties of the solutions’ interplay and how they im-

pact each other. Second, the security related con-

straints or rules speciﬁed by the software architecture

often remain ambiguous.

The ﬁrst issue is related to the design phase: It is

a complex task to deﬁne an architecture that is secure

as a whole. I. e. a software architecture that uses a

number of security solutions (e. g. patterns or tactics).

These solutions aim at solving different problems and

have to interact in such a manner that the system as a

whole is secure.

The second issue is related to both, the design and

the implementation phase: the deﬁned architecture

actually describes the architects intention. Hence, it

could be named as ”intended architecture” or ”should-

be architecture” (de Silva, 2014). This intended ar-

chitecture deﬁnes rules and constraints that apply for

the software system’s implementation: Software de-

velopers have to implement the software system in

compliance with these rules and constraints in or-

der to avoid vulnerabilities. However, it is likely

that software developers introduce violations of these

constraints while implementing a system. The rea-

son for these violations is commonly (Knodel and

Naab, 2016; de Silva and Balasubramaniam, 2012) at-

tributed to the lack of knowledge about or acceptance

of the software’s architecture, time pressure during

development and out-dated or inadequate documen-

tation.

To keep it’s value, the intended architecture has to

be implemented correctly, i. e. compliantly. Other-

wise, reasoning about fundamental properties of the

system is based on false assumptions about the sys-

tem’s actual architecture. Compliance checking ap-

proaches are used to ensure the system’s adherence to

438

Jasser, S., Tuma, K., Scandariato, R. and Riebisch, M.

Back to the Drawing Board - Bringing Security Constraints in an Architecture-centric Software Development Process.

DOI: 10.5220/0006659904380446

In Proceedings of the 4th International Conference on Information Systems Security and Privacy (ICISSP 2018), pages 438-446

ISBN: 978-989-758-282-0

the rules and constraints. As per (Knodel and Naab,

2016), conformance checking approaches should be

automated to a large extend to deal with time and re-

source constraints.

Both issues – designing a secure architecture and

implementing the software system in compliance with

that architecture – are hard to solve. In this paper,

we will highlight the mismatch between today’s (in-

tended) architecture models and architectural rules

and constraints or information needed for performing

compliance checks, respectively.

Our approach aims to support software architects

and developers in performing those tasks by revising

an architects’ architecture to make it secure, enrich-

ing the intended architecture model with information

needed to derive architectural rules and constraints

and checking the implementation’s compliance with

it. We also examine the information and artefacts

needed to extract the implemented architecture in or-

der to reﬂect the architectural compliance rules.

Basic Concepts

Basic concepts of this paper are:

Software Security. A software system is called se-

cure if it works correctly even if it is under malicious

attack. Software security is achieved by security engi-

neering. Security engineering is about constructively

developing a secure software system, i. e. considering

security concerns from the early phases of the soft-

ware development process.

Secure Design. An architecture or design is called

secure if it does not have any security ﬂaws, i. e. se-

curity requirements and design principles have been

respected and there are no fundamental vulnerabili-

ties caused at the design level.

Architectural Rules and Constraints. A software

architecture constrains the implementation of the sys-

tem: Those rules and constraints must be respected in

order to gain the quality level enabled by the intended

software architecture.

Architectural Compliance. If an actually imple-

mented software system is conform with it’s intended

architecture, it adheres to all rules and constraints de-

ﬁned by this intended architecture. The term ”archi-

tectural conformance” is used synonymously by some

authors (de Silva and Balasubramaniam, 2012).

Architecture Divergences and Violations. Differ-

ences between the implemented architecture and the

intended architecture are called divergences. They

can be differentiated in missing or inadequate adap-

tions of the intended architecture during software evo-

lution and architecture violations. Architecture viola-

tions are divergences that are caused in the implemen-

tation, i. e. the intended architecture is correct and up-

to-date but not implemented compliantly.

Running Example

Throughout this paper, we use a running example to

illustrate our approach:

Our exemplary software system provides func-

tionality for small and medium-sized enterprises. To

allow ﬂexibility and customization, the system can

be extend by plugins which lead to a diverse code

base. As the plugins’ sources are mainly unknown

they are not trust worthy and, therefore, are assumed

malicious.

In order to protect the system while running un-

trusted code, the architect decides to use a sand-

box pattern (naming inspired by Google’s chromium

project (Google Chromium Project, 2017)). It is ap-

plied to ensure that code from untrusted sources can

be executed securely: Such code must not access con-

ﬁdential information or make persistent changes ille-

gally. The sandbox pattern follows the secure design

principles of least privilege and assumes that the sand-

boxed code is malicious. Figure 1 illustrates the sand-

box pattern’s structure.

Figure 1: Running example: the sandbox pattern.

There are at least two processes needed: the bro-

ker is a privileged controller which manages one or

more target processes:

A target hosts the client-side sandbox infrastructure

and the sandboxed code. The infrastructure code in-

cludes so called interceptions or hooks. Interceptions

are then forwarded to the broker.

The broker manages and controls the target processes.

It deﬁnes a policy per target process. This policy is

used to evaluate interceptions of the targets’ action

requests. The broker uses an interception manager to

forward certain API calls to the broker. If an action is

allowed due to the policy, the broker process performs

it on the target’s behalf.

2 OUR APPROACH

Figure 2 shows the proposed approach towards bring-

ing security constraints in an architecture-centric soft-

Back to the Drawing Board - Bringing Security Constraints in an Architecture-centric Software Development Process

439

Figure 2: Proposed approach.

ware development process. In the design phase the

Data-Flow Diagram (DFD) is commonly included in

the creation of several architectural views. The ar-

chitectural representation is then used to perform a

threat analysis of the (as designed) system. By means

of pattern-based model refactoring, the intended ar-

chitecture is obtained. In this work, we refer to the

intended architecture as the result of the model refac-

toring, including the information gained from threat

analysis. Given the appropriate transformations, se-

curity compliance constraints can be derived from the

intended architecture. The proposed approach does

not envision the identiﬁcation of constraint violations

in the intended architecture, but rather in the imple-

mented instance of the system. To this aim, the for-

malized constraints are used to identify compliance

violations in the extracted architecture.

2.1 Securing Software Architectures

In this section, we discuss the activities in the de-

sign stage of software engineering and focus on how

model refactoring can help identifying rules for com-

pliance.

Security-by-design is a practice within organiza-

tions which enables planning for security in early

phases of the product life-cycle. Designing for se-

curity begins with a disciplinary regard to best prac-

tices (such as threat analysis), security standards (ISO

15408:2009(E), 2009; ISO 27001:2005(E), 2005;

ISO 27000:2009(E), 2009; NIST 800-53, 2013) and

derived security policies. However, in practice prior-

ities are commonly shifted due to a lack of resources

required for thoroughly addressing security issues at

the design phase. As a result, semi-automated ap-

proaches aim to partially analyze and secure the archi-

tectural design. Several design notations encompass

security concepts (van den Berghe et al., 2015), some

of which have emerged in the model-driven develop-

ment domain. Security-design models can be used as

a basis for generating systems and their architectures.

If models are extended with security semantics, for-

mal signatures can be used to reason about security-

related properties of systems.

Our approach bases on a threat analysis of the

architect’s intended architecture that have to be per-

formed as a ﬁrst step. We use the analysis results

as an indication for securing the software architecture

through model transformations:

Software-intensive systems continuously evolve

due to constantly changing requirements, generally

increasing the system’s complexity. In the domain

of model-driven software quality and evolution, mod-

els and their transformations have been studied in the

context of system maintenance (Ivkovic and Konto-

giannis, 2006; Mouheb et al., 2015b; Goul

ao et al.,

2016).

Model transformations have also been studied in

the context of model refactoring for security. The

term refactoring – originally introduced in the context

of object-oriented programming by Opdyke (Opdyke,

1992) – is commonly used to signify source code

modiﬁcation for the purpose of strengthening the code

structure: ”the process of changing a software sys-

tem in such a way that it does not alter the external

behavior of the code, yet improves its internal struc-

ture” (Fowler and Beck, 1999). In the MDE domain,

refactoring is applied on a model level, eventually

leading to source code modiﬁcation for the purpose

of strengthening a certain software quality character-

istic of the system, without changing its external be-

havior (Mens, 2006).

In terms of subsequent architectural compliance

checking, it would be beneﬁcial for the software ar-

chitects to introduce the notion of ‘checkpoints’ for

compliance already in the design phase. To this

aim we introduce such checkpoints for compliance

by means of architectural refactoring: Enriching the

model with this information aids the formalization of

compliance rules. Lano et al. (Lano and Kolahdouz-

Rahimi, 2014) consider patterns as forms of trans-

formations: “Patterns can in some cases be consid-

ered as forms of transformations: the application of

a pattern rewrites a software model or system with a

problematic structure into a model or system with an

improved structure.” In the domain of aspect oriented

modeling (Mouheb et al., 2015a), previous work has

introduced reusable aspect models with a reﬁnement

process for specifying security design patterns on sev-

eral levels of abstraction, based on System of Security

design Patterns (SoSPA) (Nguyen, 2015).

Design patterns are commonly deﬁned as a set

of problem speciﬁcation, solution speciﬁcation and

transformation rules (Kim et al., 2017). To this aim,

we specify the problem and the solution with a meta-

model and deﬁne the transformation rules to enable

ICISSP 2018 - 4th International Conference on Information Systems Security and Privacy

440

refactoring as described in Section2.3.

2.2 Checking the Implementation’s

Architectural Compliance

Besides the planned architecture of a software sys-

tem that is designed by the system’s architect, there is

the actual architecture. It describes the architecture-

level structure and behavior that are actually imple-

mented. Usually, the actual architecture is not totally

compliant to the planned architecture, i e. the im-

plementation diverges from the planned architecture

to some degree and thereby violates the architectural

constraints. Architecture violations are important to

consider as they

(a) cause incorrect assumptions on the system’s ac-

tual architecture. Subsequently, violations lead to

a lack of comprehension and further architecture

violations.

(b) may cause the system’s failure to comply with it’s

non-functional requirements. In case of security-

related architectural rules and constraints, viola-

tions may introduce vulnerabilities.

In order to monitor and control architecture viola-

tions compliance checks are performed. When these

compliance checks are done, the planned architecture

is not questioned. It is thought of as ideal and deﬁnes

the rules or constraints that must be met by the imple-

mentation.

However, checking the implementations compli-

ance with these rules is a highly complex and exhaust-

ing task. Hence, automation is needed when applying

compliance checking to non-trivial software systems.

Our approach will provide tool-support for conduct-

ing compliance checks based on the revised security

architecture that results from the previous step.

Architectural Rules and Constraints

As a ﬁrst step in performing architecture compliance

checks we need to deﬁne the rules and constraints that

have to be met. We use the secure design that is the

prior step’s output an input for this activity. To be

valuable, the design needs to specify the constraints

and rules that apply for the implementation in a way

that

(a) software engineers know which constraints and

rules they must respect while implementing the

system.

(b) those constraints can be used for automatic or at

least tool-supported conformance checking.

Hence, the constraints must be speciﬁed compre-

hensibly, so that software developers and architects

can be actively aware of them. However, the speci-

ﬁcation must be machine-readable, i. e. formal. As-

suming that the constraints are explicitly modeled that

point is achieved as the revised, secure architecture is

used as an input. However, an important task is to

formalize the architectural constraints regarding the

software systems structure as well as it’s behavior.

To determine a set of common architectural se-

curity constraints and rules, we derive architectural

security constraints from security solutions and best

practices, such as patterns, tactics, frameworks and

reference architectures.

Extracting the Actual Architecture

There are three components of source code analy-

sis: the parser, the internal representation and the

analysis of this representation (Binkley, 2007). The

classic examples of internal source code representa-

tions are control-ﬂow graph (CFG), call graph, ab-

stract syntax tree (AST) and value dependence graph

(VDG). Other representations include trace ﬁles, dy-

namic call graphs, XML like ﬁles, other executable

ﬁles, etc. Code analysis techniques are typically cat-

egorized into static and dynamic analysis techniques.

Static code analysis techniques perform the analysis

’off-line’, e. g. based on a model instance or source

code, without taking the program input into account.

For instance, static techniques for information-ﬂow

control mainly assign security labels to input data,

variables and APIs (Dennings’ approach (Denning

and Denning, 1977)), making it possible to separate

public and private computation. Hence, static analy-

sis can be performed on not executable artefacts such

as an intended architecture model or informal doc-

uments. Static analysis is applicable to all execu-

tions of the program, which inevitably forces approx-

imations. Consequently, such techniques suffer from

a high false-positive rate rejecting many secure pro-

grams. Other static code analysis techniques include

program logics (Banerjee et al., 2008), model check-

ing (Garc

ıa-Ferreira et al., 2014; Marinescu et al.,

2014; Jensen et al., 2015; Zuliani et al., 2013) and the-

orem proving (Bernasconi et al., 2017; Darvas et al.,

2005; Guo et al., 2016). Dynamic code analysis tech-

niques take program input into account (typically a

single input). They use runtime program information

to perform the analysis. This allows greater precision

for the particular input, but causes lower result cor-

rectness guarantees for other program inputs.

In order to perform meaningful compliance

checks on the implemented architecture, our analysis

technique will include both dynamic and static ele-

ments: Static analysis techniques are used to extract

information on information and control ﬂows, error

Back to the Drawing Board - Bringing Security Constraints in an Architecture-centric Software Development Process

441

handling, the access control policy and the software

system’s structure by identifying code that runs more

concisely. We plan to apply dynamic analysis to ﬁnd

information on the software system’s memory man-

agement as well as time-dependent constraints which

is mainly security-related behavior. This information

may be extracted by data mining approaches such as

sequential pattern discovery (Lo et al., 2007). In our

running example we could check, if the sandboxed

code is exclusively executed within the target.

2.3 Illustration on the Running

Example

Assuming a given DFD has been analyzed for threats

beforehand, we implemented a transformation to a

pattern-based DFD for a preliminary set of possible

DFDs. For illustration purposes, we have deﬁned a

source meta-model of a regular DFD, a target meta-

model of the sandbox pattern and a set of M2M trans-

formation rules using Eclipse Ecore with ATL. When

run, the transformation will refactor the input model

(conforming to the source meta-model) to an output

model (conforming to the target meta-model). Due to

space limitations, we only show the ﬁrst transforma-

tion rule below.

create OUT : SandboxDFD from IN : DFD;

rule DFD2SandboxDFD {

from s: DFD!DFD

to t: SandboxDFD!SandboxDFD (

outerdfdelements<-s.getOuterElements()

->collect (a|thisModule.

DFDEL2SANDEL(a)),

broker<-s.element->select (el|el.

oclIsTypeOf(DFD!PN))->select (e|e.

Type=#BROKER)->collect(a|thisModule

.PN2Broker(a)),

target<-s.element->select (el|el.

oclIsTypeOf(DFD!PN))->select (e|e.

Type=#TARGET)->collect(a|thisModule

.PN2Target(a)))

}

When run on a simple DFD, the transformation im-

poses restrictions in the design by requiring a sepa-

ration of broker, target and outer elements in the di-

agram. Moreover, the broker process is required to

have been initialized before the target process. Upon

executing the transformation rules for the broker and

target, the transformed processes include a reference

to the Inter-Process Communication (IPC) service and

client, respectively.

In our running example, the following architec-

tural rules can be deﬁned for the sandbox pattern:

• At least two components must be involved in a

sandbox pattern’s implementation.

• The control ﬂow must neither start within that

sandbox (”target”) nor the controller process

(”broker”).

• The target must not (directly) access system re-

sources, keyboard or mouse events etc.

• The broker manages all targets’ rights by hosting

the policy engine.

• All control and data ﬂow enters and leaves the tar-

get via the broker component. I. e. the broker in-

tercepts and handles all targets actions.

• All code to be sandboxed is executed only and

solely within the target.

• There may be separate processes for the broker

and each target

However, not all of these constraints can be de-

rived from today’s design models: for instance, time-

dependent constrains can hardly be derived from com-

mon design models which are mostly DFD or UML

models.

An architect could deﬁne additional constraints,

e. g. regarding naming conventions that apply for the

actual project.

The constraints mentioned above can directly be

derived from the applied sandbox pattern in the soft-

ware’s architecture. However, there are further con-

straints such as constraints regarding secure error han-

dling: assuming the broker ﬁnds that an action re-

quested by a target is not allowed due to the policy.

The broker now may inform the target on this failed

execution. Such error messages must not reveal infor-

mation on the system beyond the broker or the bro-

ker’s implementation. To ensure this, the error types

and messages should be custom but not default.

2.4 Formalizing the Architecture

As we want to provide tool support for the confor-

mance checking as well as for the security archi-

tecture improvement we need to formalize the soft-

ware architecture and it’s constraints. This is done

rarely today (Caracciolo, 2016), for instance it is done

in (Pene et al., 2017). The formalization approach

must allow to describe all information needed for the

security analysis, structural as well as behavioral con-

straints. That includes the expression of temporal

characteristics. Due to these and further requirements

like a good documentation and community, we have

limited the eligible ADLs to Alloy (Jackson, 2011)

and π-ADL (Oquendo, 2008).

ICISSP 2018 - 4th International Conference on Information Systems Security and Privacy

442

In our approach, we use Alloy to describe the

rules and constraints of a secure software architecture.

It is a description language for expression structural

and behavioral constraints which allows to explic-

itly model time-dependencies. There is tool-support

available for analyzing and visualizing Alloy models

to identify over- and underspeciﬁcation.

As modeling a complete architecture including all

information needed for security compliance checking

in Alloy is a rather complex task, we plan develop an

export and import mechanism to common UML and

DFD tools in order to ease it’s usage. These tools will

then by extended for our approach, i. e. for provid-

ing the security revision functionality, extending the

models by information needed for deriving architec-

tural constraints from that architecture and specifying

these constraints.

2.5 Evaluation Plan

While we present work in progress in this paper, we

want to outline how we intend to show our approach’s

feasibility:

First, we will apply our approach to two industrial

case studies of different domains. One project is a dis-

tributed system in the context of energy network con-

trols, i. e. critical infrastructures with high demands

on it’s security and safety level. The other project is

on a software that automatically archives enterprise

documents by analyzing their content. Hence, this

software greatly deals with sensitive enterprise data

and requires a high security and privacy level. For

both projects reasonable documentation and an in-

tended architecture are available.

If needed, we will perform additional case stud-

ies using open source projects with security re-

quirements. This could for instance be the Google

Chromium Project or the Apache WildFly Project.

3 RELATED WORK

We address the colliding body of knowledge on se-

curing software architectures and architectural con-

formance checking.

Secure Design Automation. Threat analysis is

a method for identifying, analyzing and prioritiz-

ing threats of early software architectural models.

STRIDE is most commonly used to this aim. This

method’s systematicity and repetitiveness results in a

so called threat explosion, where too many unimpor-

tant threats are identiﬁed and analyzed (Scandariato

et al., 2015). Apart from existing tools – e. g. (tmt,

2016) –, only few attempts at automating STRIDE

were made (Schaad and Borozdin, 2012). Yet, au-

tomation is a promising approach to prevent human

ﬂaws occurring downstream the software production

line (Yskout et al., 2008).

Apart from the software-oriented STRIDE there

are other methods used to perform threat analysis:

CORAS (Lund et al., 2011), PASTA (UcedaVelez

and Morana, 2015), attack trees (Mauw and Oost-

dijk, 2005), Trike (Saitta et al., 2005), to name a

few. J. Berger et al. (Berger et al., 2016) have pro-

posed an approach for a semi-automated architectural

risk analysis. They provide a a tool which automati-

cally extracts architectural vulnerabilities based on an

extended DFD notation and proposes known mitiga-

tions. To create the threat model, formalized rules are

build based on information obtained from lowering

EDFDs to simple graphs. The authors recognize the

need to limit the time spent by security experts and

therefore separate the responsibilities to include the

expert only when needed. However, the knowledge

base rules are used to discover only cataloged vul-

nerabilities, as opposed to ﬁnding all possible threats.

Furthermore, Almorsy et al. (Almorsy et al., 2013)

have introduced an approach for a security risk anal-

ysis by means of formalized signatures of scenarios

and metrics. The authors developed a prototype tool,

which takes as input a (sub)set of design, architecture

and code level artifacts. Using formalized signatures

of attack scenarios and security metrics (with OCL),

the tool is able to identify signature matches in the

incrementally built architectural model.

Closely related to goal-oriented requirements en-

gineering methods, architectural analysis has been

studied in the context of automating the genera-

tion of attack trees (Li et al., 2016; Birkholz et al.,

2010), attack graphs (Sheyner et al., 2002) and at-

tack paths (Chen et al., 2007). Aforementioned ap-

proaches aim toward a static architectural analysis,

where the implemented solution is not the main focus.

For a more complete list of attack and defense mod-

eling methods, we refer the reader to the work of Ko-

rdy et al. (Kordy et al., 2014). Complementary to ar-

chitectural security patterns (Yskout et al., 2012), the

so called problem frames (Beckers et al., 2013) and

treat patterns have emerged. Abe et al. (Abe et al.,

2013) proposed to model negative scenarios (as de-

ﬁned by the CC standard (ISO 15408:2009(E), 2009))

in a semi-automated way with threat patterns and use

them during business process modeling.

Architecture Compliance Checking. A secure de-

sign does not automatically result in a secure soft-

ware system: it must be implemented correctly. Most

approaches for identifying violations of architectural

constraints concentrate on constraints regarding the

Back to the Drawing Board - Bringing Security Constraints in an Architecture-centric Software Development Process

443

static structure of the system, e. g. identifying the al-

lowed and forbidden dependencies between compo-

nents or layers on the architectural level. Such ap-

proaches are usually based on reﬂexion models in-

troduced in (Murphy et al., 2001), dependency struc-

ture matrices or relation conformance rules. This is

mainly related to the software system’s maintainabil-

ity, which is commonly addressed in the related work

(e. g. (Knodel and Naab, 2016), (Berger et al.,

2013)), whereas other quality attributes such as se-

curity are poorly understood today.

There have also been a few approaches that dy-

namically check the conformance at runtime: (Nico-

laescu and Lichter, 2016; de Silva, 2014). Yet, none

of these works consider security constraints. Other

authors use aspect-orientation to dynamically enforce

architecture conformance: (Merson, 2007; Gane-

san et al., 2008; Wang et al., 2007). Another ap-

proach that intends runtime compliance checking is

the SECORIA-approach (Abi-Antoun and Barnes,

2010). Abi-Antoun and Barnes deﬁne some security-

speciﬁc constraints which deﬁne permitted, and pro-

hibited connections based on security requirements.

The authors do not consider changes over time in the

system’s behavior and structure.

4 CONCLUSION: DISCUSSION

AND FUTURE WORK

In this paper we present our work towards an ap-

proach for developing secure software systems. The

approach focuses on the constructive phases of the de-

velopment process, i. e. the design phase, the imple-

mentation phase and the transition between them.

The ﬁrst step in securing the design is to an-

alyze the architectural model for potential security

threats. This non-trivial task raises questions about

threat granularity (when to stop detailing threats),

stopping conditions of analysis, quality assurance of

analysis results, to name a few. To this aim, our future

work will include semi-automated approaches reduc-

ing manual intervention and helping the exploration

of the problem space in a computerized fashion.

The presented approach extracts compliance con-

straints from the resulting secure design as a result

of threat analysis. Therefore, the soundness of the

secured architecture is of utter importance. In order

to complement the security requirements reﬁnement

during threat analysis, we plan to explore the potential

of design ﬂaw detection. We plan to realize this de-

tection by mining documented design ﬂaws by using

techniques such as graph pattern matching. We will

analyze design ﬂaw and issue catalogs (e. g. OWASP)

to ﬁnd ﬂaws and issues or identiﬁcation criteria in or-

der to ﬁnd them in an input architecture model.

Regarding the pattern-based model transformation

presented in this approach, we are interested in how

to maintain the conﬂicts introduced by several non-

functional concerns. For example, security require-

ments commonly effect safety requirements. Further,

changes in the design model due to the transforma-

tions must not obstruct or corrupt solutions which

have been applied to the input design models to en-

able other non-functional quality characteristics.

Besides our future work on secure design trans-

formation, more work has to be done on checking the

implementations compliance with the resulting secure

design: Architectural design needs to be good to en-

able sound compliance checking as architectural rules

depend on the amount of information provided. I. e.

the design model needs to comprehensibly present the

constraints that apply to the implementation. An es-

sential challenge related to today’s architectural mod-

els is their lack of information about security solu-

tions: an adequate notation for architecture models is

needed. To preserve compatibility and comprehensi-

bility common notations such as DFD or UML mod-

els should be enriched with more security semantics.

Architectural constraints will be derived from these

enhanced architecture models. To perform the confor-

mance checking, the constraints must be speciﬁed in

a formal way. To further support software engineers

in applying our approach we will provide a catalog

of frequently used transformations as a result of the

common solutions’ analysis (e. g. common ﬂaws, pat-

terns). This catalog will also comprise frequent con-

straints and rules derived of such security solutions.

As previously mentioned, we will apply a hybrid

approach to extract the actual architecture from the

system, i. e. we will combine static and dynamic anal-

ysis techniques. To enable checking for compliance

of the implemented architecture, our techniques need

to be able to extract the required information for re-

ﬂecting compliance rules. For example, information

gained from control and data ﬂow analysis, as well

as information about behavioral aspect of the system.

Further investigations about the required information

for extraction, as well as the source of this infor-

mation in the implemented architecture (e. g. source

code, AST, CFG, executable ﬁles, etc.) is needed.

Another challenge related to security architecture

compliance checking is to display architecture viola-

tions clearly and comprehensibly. This is an essential

usability requirement of our approach as we need to

give adequate feedback on software system’s compli-

ance with it’s intended architecture.

ICISSP 2018 - 4th International Conference on Information Systems Security and Privacy

444

REFERENCES

(2016). Sustainable Application Security

microsofts new threat modeling tool.

blog.secodis.com/2016/07/06/microsofts-new-

threat-modeling-tool/. Accessed: 2017-11-15.

Abe, T., Hayashi, S., and Saeki, M. (2013). Modeling se-

curity threat patterns to derive negative scenarios. In

Software Engineering Conference), volume 1, pages

58–66. IEEE.

Abi-Antoun, M. and Barnes, J. M. (2010). Analyzing

security architectures. In 25th IEEE/ACM Interna-

tional Conference on Automated Software Engineer-

ing, pages 3–12.

Almorsy, M., Grundy, J., and Ibrahim, A. S. (2013). Auto-

mated software architecture security risk analysis us-

ing formalized signatures. In International Confer-

ence on Software Engineering, pages 662–671. IEEE

Press.

Banerjee, A., Naumann, D. A., and Rosenberg, S. (2008).

Expressive declassiﬁcation policies and modular static

enforcement. In IEEE Symposium on Security and

Privacy, pages 339–353. IEEE.

Beckers, K., Hatebur, D., and Heisel, M. (2013). A

problem-based threat analysis in compliance with

common criteria. In 8th International Conference on

Availability, Reliability and Security, pages 111–120.

IEEE.

Berger, B. J., Sohr, K., and Koschke, R. (2013). Extract-

ing and analyzing the implemented security architec-

ture of business applications. In 17th European Con-

ference on Software Maintenance and Reengineering,

pages 285–294. IEEE.

Berger, B. J., Sohr, K., and Koschke, R. (2016). Automat-

ically extracting threats from extended data ﬂow di-

agrams. In International Symposium on Engineering

Secure Software and Systems, pages 56–71. Springer.

Bernasconi, A., Menghi, C., Spoletini, P., Zuck, L. D., and

Ghezzi, C. (2017). From model checking to a tempo-

ral proof for partial models. In International Confer-

ence on Software Engineering and Formal Methods,

pages 54–69. Springer.

Binkley, D. (2007). Source code analysis: A road map.

In Future of Software Engineering, pages 104–119.

IEEE.

Birkholz, H., Edelkamp, S., Junge, F., and Sohr, K. (2010).

Efﬁcient automated generation of attack trees from

vulnerability databases. In Working Notes for the 2010

AAAI Workshop on Intelligent Security, pages 47–55.

Caracciolo, A. (March 2016). A Uniﬁed Approach to Archi-

tecture Conformance Checking. Dissertation, Univer-

sit

at Bern, Bern.

Chen, Y., Boehm, B., and Sheppard, L. (2007). Value driven

security threat modeling based on attack path analysis.

In 40th Annual Hawaii International Conference on

System Sciences, pages 280a–280a. IEEE.

Darvas,

A., H

ahnle, R., and Sands, D. (2005). A theo-

rem proving approach to analysis of secure informa-

tion ﬂow. In International Conference on Security in

Pervasive Computing, pages 193–209. Springer.

de Silva, L. (2014). Towards Controlling Software Archi-

tecture Erosion Through Runtime Conformance Mon-

itoring. Dissertation, University of St. Andrews, St.

Andrews.

de Silva, L. and Balasubramaniam, D. (2012). Controlling

software architecture erosion: A survey. Journal of

Systems and Software, 85(1):132–151.

Denning, D. E. and Denning, P. J. (1977). Certiﬁcation of

programs for secure information ﬂow. Communica-

tions of the ACM, 20(7):504–513.

Fowler, M. and Beck, K. (1999). Refactoring: improving

the design of existing code. Addison-Wesley Profes-

sional.

Ganesan, D., Keuler, T., and Nishimura, Y. (2008). Archi-

tecture compliance checking at runtime: An industry

experience report. In The 8th International Confer-

ence on Quality Software, pages 347–356.

Garc

ıa-Ferreira, I., Laorden, C., Santos, I., and Bringas,

P. G. (2014). A survey on static analysis and model

checking. In International Joint Conference SOCO14-

CISIS14-ICEUTE14, pages 443–452. Springer.

Google Chromium Project (2017). Sandbox pattern.

Goul

ao, M., Amaral, V., and Mernik, M. (2016). Quality in

model-driven engineering: a tertiary study. Software

Quality Journal, 24(3):601–633.

Guo, X., Dutta, R. G., Mishra, P., and Jin, Y. (2016). Scal-

able soc trust veriﬁcation using integrated theorem

proving and model checking. In IEEE International

Symposium on Hardware Oriented Security and Trust,

pages 124–129. IEEE.

ISO 15408:2009(E) (2009). ISO/IEC common criteria for

information security evaluation. Standard, Interna-

tional Organization for Standardization (ISO) and En-

ternational Elecrotechnical Commission (IEC).

ISO 27000:2009(E) (2009). ISO/IEC Information

technology-security techniques-Information security

management systems-Overview and Vocabulary.

Standard, International Organization for Standard-

ization (ISO) and Enternational Elecrotechnical

Commission (IEC).

ISO 27001:2005(E) (2005). ISO/IEC Information

technology-security techniques-Information security

management systems-Requirements. Standard, Inter-

national Organization for Standardization (ISO) and

Enternational Elecrotechnical Commission (IEC).

Ivkovic, I. and Kontogiannis, K. (2006). A framework for

software architecture refactoring using model trans-

formations and semantic annotations. In 10th Eu-

ropean Conference on Software Maintenance and

Reengineering, pages 10–pp. IEEE.

Jackson, D. (2011). Software Abstractions: Logic, Lan-

guage and Analysis. MIT Press, Cambridge, 2nd ed.

edition.

Jensen, C. S., Møller, A., Raychev, V., Dimitrov, D., and

Vechev, M. (2015). Stateless model checking of event-

driven applications. In ACM SIGPLAN Notices, vol-

ume 50, pages 57–73. ACM.

Kim, D.-K., Lu, L., and Lee, B. (2017). Design pattern-

based model transformation supported by qvt. Journal

of Systems and Software, 125:289–308.

Back to the Drawing Board - Bringing Security Constraints in an Architecture-centric Software Development Process

445

Knodel, J. and Naab, M. (2016). Pragmatic Evaluation of

Software Architectures. The Fraunhofer IESE Series

on Software and Systems Engineering. Springer Inter-

national Publishing, Cham and s.l.

Kordy, B., Pi

etre-Cambac

es, L., and Schweitzer, P.

(2014). Dag-based attack and defense modeling: Dont

miss the forest for the attack trees. Computer science

review, 13:1–38.

Lano, K. and Kolahdouz-Rahimi, S. (2014). Model-

transformation design patterns. IEEE Trans. Software

Eng., 40(12):1224–1259.

Li, T., Paja, E., Mylopoulos, J., Horkoff, J., and Beckers, K.

(2016). Security attack analysis using attack patterns.

In IEEE 10th International Conference on Research

Challenges in Information Science, pages 1–13. IEEE.

Lo, D., Khoo, S.-C., and Liu, C. (2007). Efﬁcient mining

of iterative patterns for software speciﬁcation discov-

ery. In 13th ACM SIGKDD International Conference

on Knowledge discovery and data mining, pages 460–

469. ACM.

Lund, M. S., Solhaug, B., and Stølen, K. (2011). A guided

tour of the coras method. In Model-Driven Risk Anal-

ysis, pages 23–43. Springer.

Marinescu, R., Kaijser, H., Miku

cionis, M., Seceleanu, C.,

onn, H., and David, A. (2014). Analyzing indus-

trial architectural models by simulation and model-

checking. In International Workshop on Formal Tech-

niques for Safety-Critical Systems, pages 189–205.

Springer.

Mauw, S. and Oostdijk, M. (2005). Foundations of at-

tack trees. In ICISC, volume 3935, pages 186–198.

Springer.

Mens, T. (2006). On the use of graph transformations for

model refactoring. Lecture Notes in Computer Sci-

ence, 4143:219.

Merson, P. (2007). Using aspect-oriented program-

ming to enforce architecture. Technical Report

CMU/SEI-2007-TN-019, Software Engineering Insti-

tute, Carnegie Mellon University, Pittsburgh, PA.

Mouheb, D., Debbabi, M., Pourzandi, M., Wang, L., Nouh,

M., Ziarati, R., Alhadidi, D., Talhi, C., and Lima, V.

(2015a). Aspect-Oriented Security Hardening of UML

Design Models. Springer.

Mouheb, D., Debbabi, M., Pourzandi, M., Wang, L., Nouh,

M., Ziarati, R., Alhadidi, D., Talhi, C., and Lima,

V. (2015b). Model-Driven Architecture and Model

Transformations, pages 35–45. Springer International

Publishing, Cham.

Murphy, G. C., Notkin, D., and Sullivan, K. J. (2001). Soft-

ware reﬂexion models: Bridging the gap between de-

sign and implementation. IEEE Trans. Software Eng.,

27(4):364–380.

Nguyen, P. H. (2015). Model-driven security based on a

uniﬁed system of security design patterns. Technical

report, University of Luxembourg.

Nicolaescu, A. and Lichter, H. (2016). Behavior-based ar-

chitecture reconstruction and conformance checking.

In Muccini, H. and Harper, K. E., editors, WICSA

2016, pages 152–157, Piscataway, NJ. IEEE.

NIST 800-53 (2013). Security and Privacy Controls

for Federal Information Systems and Organizations.

Standard, National Institute of Standards and Technol-

ogy (NIST)).

Opdyke, W. F. (1992). Refactoring object-oriented frame-

works.

Oquendo, F. (2008). Dynamic software architectures: For-

mally modelling structure and behaviour with pi-adl.

In 3rd International Conference on Software Engi-

neering Advances, pages 352–359.

Pene, L., Hamza, L., and Adi, K. (2017). Compliance veri-

ﬁcation algorithm for computer systems security poli-

cies. In International Conference on E-Technologies,

pages 96–115. Springer.

Saitta, P., Larcom, B., and Eddington, M. (2005). Trike

v. 1 methodology document [draft]. dymaxion.

org/trike/Trike v1 Methodology Documentdraft.pdf.

Scandariato, R., Wuyts, K., and Joosen, W. (2015). A

descriptive study of microsofts threat modeling tech-

nique. Requirements Engineering, 20(2):163–180.

Schaad, A. and Borozdin, M. (2012). Tam 2: automated

threat analysis. In 27th Annual ACM Symposium on

Applied Computing, pages 1103–1108. ACM.

Sheyner, O., Haines, J., Jha, S., Lippmann, R., and Wing,

J. M. (2002). Automated generation and analysis of

attack graphs. In IEEE Symposium on Security and

privacy, pages 273–284. IEEE.

UcedaVelez, T. and Morana, M. M. (2015). Risk Centric

Threat Modeling: Process for Attack Simulation and

Threat Analysis. John Wiley & Sons.

van den Berghe, A., Scandariato, R., Yskout, K., and

Joosen, W. (2015). Design notations for secure soft-

ware: a systematic literature review. Software & Sys-

tems Modeling, pages 1–23.

Wang, C.-M., Huang, C.-C., Chen, H.-M., and Wang, S.-T.

(2007). Conformance checking of running programs

in dynamic aspect-oriented systems. In 14th Asia-

Paciﬁc Software Engineering Conference, pages 183–

190, Los Alamitos, Calif. IEEE Computer Society.

Yskout, K., Scandariato, R., De Win, B., and Joosen, W.

(2008). Transforming security requirements into ar-

chitecture. In Availability, Reliability and Security,

2008. ARES 08. Third International Conference on,

pages 1421–1428. IEEE.

Yskout, K., Scandariato, R., and Joosen, W. (2012).

Does organizing security patterns focus architectural

choices? In Proceedings of the 34th International

Conference on Software Engineering, pages 617–627.

IEEE Press.

Zuliani, P., Platzer, A., and Clarke, E. M. (2013). Bayesian

statistical model checking with application to state-

ﬂow/simulink veriﬁcation. Formal Methods in System

Design, 43(2):338–367.

ICISSP 2018 - 4th International Conference on Information Systems Security and Privacy

446